Культуры программных проектов (Энтони Лаудер)

Автор: Энтони Лаудер (Anthony Lauder), англичанин, в разработке ПО с 1987 года, поработал в куче контор — Англия, Штаты (включая Силиконовую Долину), и в конце концов, на удивление, осел в Праге (Чехословакия).

Что важно понимать об авторе — это не методолог, не писатель, не тренер, не маркетолог-продавец, не фантазер, а достаточно успешный практик (разработчик, project and product manager, консалтер,…) у которого, наконец-то, дошли руки, отрефлексировать свое понимание и написать книгу.

В течение нескольких следующих лет консалтинга я стал замечать, что и другие люди задают похожие вопросы:

Почему наш начальник заставляет нас следовать методологии, которая очевидно нам не подходит?

Почему программисты не делают того, что им говорят?

Почему я не могу внедрить у нас в компании методологию АБВ?

Постепенно до меня дошло, что людям не нужно говорить как они должны работать, они хотели понять, почему разные люди делают работу по-разному.
Они спрашивали меня не столько о методологиях, сколько о том, как методологии срабатывают или дают осечку в конкретных культурах разработки приложений. И не только это, но и:

Если это наша культура, то что нужно сделать, чтобы изменить её? См. предисловие

Software Project Cultures: Книга свежая, 2008 год, на бумаге вовсе не публиковалась, автор просто выложил ее в вебе http://sites.google.com/site/anthonylauder/SoftwareProjectCultures.pdf и она стала набирать популярность.

Путь очень схожий с книжкой Книберга — «SCRUM from Trenches» — свободная публикация привела к популярности, и к переводам добровольцев.

Так и здесь, нашлись переводчики на русский язык — Альберт Мустафин (кстати, коллега автора книги), сделал русский перевод (к сожалению, все-таки с кучей смысловых ошибок, если бегло читаете на английском — лучше ---), так что прочитать книгу можно в виде набора постов в блоге Алекса Орлова (о котором мы уже писали), а для желающих оффлайн чтения (на ебуках или КПК), есть и PDF-верстка (куда переводчик добавил немного картинок).

Рецензия Стаса Фомина

Собственно подробно пересказывать содержание книги смысла нет — книга доступна, нет никаких преград, чтобы в один клик перейти к ее чтению, не тратя время на длинные пересказы. К тому же книга читается легко, перевод добротный, ну и все-таки есть желание «посмотреть трейлер фильма», то ниже есть подборка понравившихся мне цитат.

А ключевые идеи (в моем понимании) следующие. Вспоминая известный софизм Горгия «Если что и существует, то оно не познаваемо. Если оно и познаваемо, то знание невозможно передать…», понимаешь, что он прав — знание о эффективной разработке ПО очень трудно зафиксировать на бумаге — в виде текстов, регламентов, правил (даже эвристических), даже основанных на метриках и статистике. Все это не работает, получившиеся таким образом толстые своды best practices и методологий — не работают, являя собой лишь кладбища мертвой информации. В то время, как опытные ПиЭмы таки как-то набирают опыт и применяют его на проектах разных типов.

Так вот, первая мысль в том, что люди усваивают знания не с нуля, а в привязке к «общечеловеческому культурному слою», выражая новые сложные понятия из ITшных областей в виде метафор — живых аттракторов из общечеловеческой культуры. И упаковка знаний в метафоры — наиболее емкая и гибкая, позволяет адаптироваться к решению изменяющихся задач. В тему хочется процитировать широко известного в узких кругах Левенчука: «Задать правильную метафору -- это очень сильное действие. Метафора позволяет буквально увидеть одну систему "внутри головы", и потом пытаться перенести соответствующие образы на совсем другие системы» [1]

Вторая мысль — если начать классифицировать все многообразие парадигм разработки программных проектов с помощью метафор, то выделяются четыре ключевых аттрактора, четыре ключевых парадигмы разработки, каждая из которых была в свое время доминирующей, причем объективно, для того развития программных и аппаратных технологий. Это:

Научная разработка. 1970-1990. Подходы Кнута и Дейкстры, Literate proramming, программа как статья и теорема.
Заводская разработка. 1980-2000. Waterfall в тяжелой форме — быдлокодинг по спецификациям.
Архитектурная (дизайнерская). 1995-2005. CASE-средства, RUP, UML, дизайн первичен, DDD.
Сервисная модель. 2000-… Agile, SCRUM, VDD, FDD, юзабилити, максимальная клиентоориентированность …

Очень полезно взглянуть (даже не читая книги) на #Ключевая таблица.

И сейчас, доминирующим трендом является распространение сервисной модели — именно в этом суть Agile-движения, а не ее частностях — итерациях, минимизация бюрократии и командном самоуправлении. Именно сервисность является основополагающем камнем, а не многообразие переводов Agile — (проворный-гибкий-шустрый — это все частности).

Но нельзя сказать, что эта модель была хороша всегда и везде — просто сейчас сложились условия, когда разработка стала реально мощной и быстрой, стало возможно на ходу менять не только рюшечки и бантики, но даже фундамент — архитектуру, библиотеки — если того требует клиент — строительно-водопадные метафоры перестали работать. Т.е. с таким подходом нельзя было выиграть в 1990 — там бы гарантированно проиграли заводскому подходу, и сейчас, местами еще выигрывает «завод» (как в Motorola, на длинных проектах), местами даже в заказной разработке, в новой предметной области правильно стартовать с архитектурного подхода и DDD, и лишь потом переходить к максимальной сервисности. В исследовательских задачах (и очень критических областях — разработка нового железа и т.п.) — вполне применим даже научный подход.

И все же тренд однозначен — если разработчики достаточно мощны, компания добротна и занимается заказной разработкой, то она должна конкурировать в первую очередь «сервисностью» (а не гордится заводскими характеристиками — «у нас минимальная себестоимость жигуля в строкочеловекочасах»).

Т.е. некотором смысле это не конкурирующие равнозначные модели — «здесь мы делаем дизайн», а «здесь мы стараемся лизать заказчика», нет, скорее считается что каждая новая модель включает старую, т.е.

«Да, мы умеем делать дизайн, причем разный, но не он главное — а важно удовлетворение заказчика, для этого мы готовы даже менять его при изменении требований, мы теперь такие умные, что умеем делать это на лету».
«Да, мы тоже уделяем внимание минимизации себестоимости, reusability, и прочим экономичным практикам, но это у нас не самоцель».

В любом случае, важно:

Понять, к каком типу относится ваша компания сейчас.
Понять, какого типа она должна быть, и как надо себя позиционировать перед клиентами. Как дешевый завод? Как элитное дизайн-ателье? Как мощных суперменов, способных работать практически в любых технологиях, лишь бы удовлетворить клиента любой ценой (дорого, но satisfaction garanteed). И понять, что «завод» — это не вершина качества («у нас не Мастерская, а настоящий Завод!»), а весьма устаревшая и ограниченная модель.
Понять, как менятся:
- Каких людей надо убирать:
  - Взаимодействие людей живущих в разных парадигмах — мучительно и неэффективно
  - Менять «заводскую ориентацию» на «сервисную» у человека часто нереально, проще уволить,
- Каких надо нанимать.
  - Для HR-ов возможно будет полезен приведенный опросник.
- Какие оргмероприятия и как проводить, что можно сделать эволюционно, а где придется ломать через колено.

И в любом случае, это очень правильный базис, чтобы оценивать IT-ситуации (проекты, команды), эффективно общатся с людьми другой культуры (заказчиками, клиентами, подрядчиками, сотрудниками), ну и правильно позиционировать себя.

Например, над одной конференции, я наблюдал классическую иллюстрацию — докладчик, рассказывая о usability, высказал мысль о важности понимания usability тестировщиков и вообще, важности сбора usability. На что один известный специалист задал неуменный вопрос «Зачем проблемы юзабилити тестировщику, его должно волновать только соотвествие продукта спецификациям». Классическое столкновение на уровне непонимания между «сервисной» и «заводской» моделью! Еще классный пример такого конфликта («спецификации против THE USER DOESN'T CARE») — это свежая история «Linux, memcpy, glibc, и чертов Flash» (рекомендую!).

Поэтому настоятельно рекомендуется не только ПиЭмам, но и HRам и маркетологам. Впрочем, книга интересна и разработчикам, и тестировщикам, ну в общем, читайте все!

Ключевая таблица

Доминирующие Метафоры ↓ Культуры →	Заводская	Дизайнерская	Сервисная
Разработка приложений – это	Конвейер	Дизайн Архитектуры	Удовлетворение клиента
Аспекты продукции Программы	Жёсткие	Гибкие	Мягкие
Дизайн – это	Проект	Техническая деятельность	Людская деятельность
Требования	Записываются	Моделируются	Делятся
Аспекты людей ↓
Менеджеры – это	Командиры и Надзиратели	Лидеры	Референты
Команды – это	Рабочие	Эксперты	Сотрудники
Заказчики – это	Покупатели	Деловые люди	Короли
Аспекты рисков ↓
Содержание	Фиксировано	Уточняемо	Вечно меняется
Время – это	Деньги	Качество	Изменения
Качество	Проверяется	Это Стабильность	Это приёмка клиентом
Деньги – это	Стоимость	Производительность	Незначимое
Аспекты Контроля ↓
Успех – это	Соответствие нормам	Продукция с правильным дизайном	Счастливые Заказчики
Неудача	Наказуема	Код-Спагетти	Выявляется рано
Растрата	Небрежность	Бюрократия	Низкая ценность
Прогресс – это	Завершение задачи	Улучшение дизайна	Частые поставки

Избранные Стасом Фоминым цитаты

По мере вашего вливания в коллектив вы замечаете, что компания сильно зависит от настроений нескольких талантливых высоко оплачиваемых программистов. Похоже, что эти ребята никогда не могут дать точную оценку времени для задач. Когда они что-то производят, то часто оказывается, что половина написанного заказчику вовсе не нужна. И даже хуже — то, что заказчику всё-таки нужно, оказывается довольно ненадёжным. [2]

Действительно ли мир полон дурных боссов? Проекты полны некомпетентных работников? Технические ребята всегда зацикливаются на своих гиковских штучках в ущерб общему успеху проекта?
Конечно, существует много конкурирующих методологий, каждая из которых предписывает разные правила, стараясь захватить доминирующую позицию. Наиболее заносчивые попытались предпринять войну методологий с маркетинговой уловкой: они называют свои правила best practices. Их цель - уменьшение чувства неуютности новичков при адаптации этих правил и увеличение неуютности при адаптировании альтернатив, которые, разумеется, worse practices, из-за которых проекты проваливаются.
Вместо того, чтобы начать подробное обсуждение небольших различий двух типов диаграмм, я спросил, а работает ли для них RUP вообще. Тимлид признался, что создание всяких диаграмм на самом деле замедляет проекты, а потому лучшие из его программистов старались использовать инструменты, которые генерировали диаграмы автоматически прямо из приложения, когда оно уже было написано.
Таким образом получается, что метафоры - это живые существа, уменьшающие наш страх перед неизвестным. Они более активны, чем списки предписанных правил или статистических значений, так как могут меняться и адаптироваться к меняющимся обстоятельствам. Тогда как начинающие полагаются на предписанные правила и следуют дорогой, проложенной другими, опытные люди полагаются на собственные статистические значения, чтобы принимать решения, подходящие к ситуации, а эксперты используют эволюционирующие метафоры как генераторы новых правил и статистики, чтобы построить мосты к незнакомым ситуациям.
Это, по моему мнению, и есть разница между экспертами и остальными: Эксперты эволюционируют метафоры, которые составили основу успеха их предыдущего опыта, и которые они постоянно используют для преобразования незнакомой среды в родную стихию. Метафоры используются экспертами, как факелы для освещения дороги.
Я заметил, что при каждом возникавшем кризисе на проектах Эн сразу же вспоминала свою лучшую метафору: держи хаос на кухне (в нашем случае разработчиков), спрятанным от посетителей (заказчиков). [3]

Мой коллега услышал о новой книге о DDD (Domain Driven Design). Он подумал, что она может быть интересной, и спросил меня, о чём это. Я объяснил, что это означает достаточно тщательное исследование области бизнеса, чтобы построить её модель в программном виде. У меня не было возможности углубиться в более детальное объяснение, так как он сразу же понял эту метафору о построении модели и, следуя её значению, закатил мне длинную лекцию на тему DDD, о которой у него вдруг оказались глубокие познания!
Начальники надеялись, что простого увеличения мозговой силы будет достаточно. Вновь нанятым сотрудникам пришлось встроиться в конфликтующую культуру, что убило в зародыше те улучшения, которые они могли привнести. Они не могли работать своими проверенными способами и были вынуждены использовать методики, которые по их мнению были причинами неудач. Большинств из них уволилось в первые несколько недель. Некоторые приспособились: им пришлось наречь себя наёмниками; они делали ненавистную работу за большие деньги.
Разумеется, существует множество метафор, которые люди используют или могут использовать для усиления отрицательного мнения, часто по отношению к культурам и методологиям, которые они не очень хорошо знают. Такие метафоры могут быть довольно заразными и убедительными.
Кстати, это неплохое определение методологии, описанной книгой с правилами: это место для успокоения разбросанных костей мёртвых метафор, когда-то развитых их автором. Потеря подкрепляющих метафор, на основе которых были составлены эти правила, лишает нас богатой коллекции смысловых интерпретаций, которые можно было бы развивать дальше. Мы понятия не имеем, как прикрепить плоть к костям. Нам остаётся лишь слепо следовать предписанным правилам методологии, которая есть ничто более, чем след замороженных интерпретаций автора.
Изучив требования я открыл текстовый редактор и начал набирать некий код: небольшой тест, проверяющий одно из требований. Архитектор предостерёг меня, что если начальник отдела меня увидит за этим делом, то мне сделают суровый выговор. Но ведь настоящие архитекторы зданий создают мини-копии конструкций и тестируют их, попробовал оправдаться я. Но он сказал, что к нам это не имеет отношения. Методологическая книга говорит, что архитекторам нельзя писать код; они рисуют высокоуровневый дизайн, который затем передаётся старшим разработчикам, которые пишут детальный дизайн, которые в свою очередь дорабатываются младшими разработчиками. Эта буквальная интерпретация их методологии показалась мне ненормальной, поскольку архитекторы не имели возможности убедиться в надёжности их дизайна. [4]

Дизайнерская Культура: Разработка приложений - это архитектурный дизайн

Архитектура - это концептуальная основа, на которой строится продукт. Наиболее удачные архитектуры создаются с рассчётом на возможные изменения желаний клиента, а потому имеют некоторую встроенную гибкость.

Сервисная Культура: Разработка приложений - это удовлетворение заказчика

Клиенты хотят вести с нами дела, если мы помогаем им в удовлетворении их самых критичных желаний. Это означает фокусироваание больше на их успехе, а не на своём личном. [5]

Когда я впервые услышал о методологиях, к которым тянутся люди Сервисной Культуры, их в основном называли Легковесными методологиями. Те, кто придумал эту метафору, надеялись, что люди поймут подразумеваемое отсутствие бюрократии. И тем не менее, многие ассоциировали Легковесность с ненадёжностью, а потому решали, что нет смысла их рассматривать. Методолологии быстро переименовали в Проворные (Agile).
К сожалению, как я заметил, слово Проворные тоже не без изъяна. Эта метафора наводит некоторых людей на образы о проектах, завершающихся очень быстро. Этот факт зацикливает их на скорости и желании ещё больше ускориться. И хотя эти методологии действительно могут помочь ускорить проекты, это не является их главной идеей. Их соль (по крайней мере из моего опыта) состоит в непрерывном слежении за результатами и удовлетворении меняющихся нужд заказчиков.
Вот почему я предпочитаю название Сервисная Культура в качестве метафоры для этих методологий. Я обнаружил, что эта метафора заставляет новичков исследовать ассоциации, в результате чего им приходят на ум образы, более соответствующие образам людей, которые уже используют «Проворные» методологии. [6]

Первый вопрос был очевиден: «Можете сказать, что это за решения?» На что начальник ответил: «О каждом решении вы узнаете в нужное время. По мере принятия решений мы будем передавать их вашим менеджерам. Ваша работа будет состоять в их выполнении. А теперь, господа, пицца и напитки ждут вас в конце зала.»
Нельзя считать, что культура прижилась, пока эти новые взгляды не перейдут с уровня разума на уровень эмоций. То есть, основополагающая метафора культуры должна перейти головы в сердце. Только тогда взгляды превратятся в ценности, и лишь тогда люди станут инстинктивно придерживаться новой культуры и преуспевать в ней.
Странно, но команды иногда выигрывают от враждебно настроенных людей. Враждебность обеспечивает команду врагами, а враги помогают команде объединиться и сфокусировать свои усилия. Враг даёт команде кого-то, с кем можно соревноваться, тем самым усиливая сплочённость команды. Конкурент на рынке — это замечательный враг, ибо не даёт команде расслабиться и заставляет их творить и адаптироваться, чтобы выжить и победить.
Законная власть: Это когда статус и авторитет основаны на вашем звании. Команды вынуждены делать что-то, потому что их босс так сказал: Менеджер отдаёт приказы, а подчинённые выполняют.

Власть пряника: Тут менеджер предлагает награду, желанную для команды. Менеджер выдвигает требования, а команда следует указаниям, чтобы повысить свои шансы на бонус, повышение зарплаты или продвижение в карьере.

Принудительная власть: Менеджер раздаёт приказы, а члены команды могут быть наказаны за неподчинение. Менеджеры запугивают людей понижением статуса, заморозкой зарплаты или даже потерей работы, если они не будут делать то, что им сказано.
[7]

Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».

Репликация: База Знаний «Заказных Информ Систем» → «Культуры программных проектов (Энтони Лаудер)»