Заказчик. Повадки и особенности.

Одна из самых главных проблем в отношениях Программистов и Заказчиков - неправильное понимание сущности самого процесса разработки.

Традиционно, программирование сравнивалось с другими инженерными областями - строительством, например. Заказчики (да зачастую и сами программисты) рассуждали так: написать программу - это как здание построить.  Смотрите сами:
- обговорить и согласовать спецификации - это все равно, что с архитектором обговорить проект;
- писать код - это все равно, что строить;
- тестировать - все равно, что готовить здание к приемке;
- начать использовать - все равно, что вселиться в дом.
Выглядит похоже, не правда ли? Здание год строится и программу заказчику год пишут. Там 50 программистов и тут 50 строителей. Чего же эти яйцеголовые умничают, пудрят нам мозги и срывают сроки? Поучились бы у строителей как надо работу в срок сдавать. Я не имею в виду Российских строителей.

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

Заметили? Разработка программы - это не строительство стен. Это разработка проекта.

А строительство стен - это компиляция! Это перевод проекта в форму, которую можно непосредственно использовать!

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

Стало быть, старая добрая Waterfall модель, которая понятна как программистам, так и заказчикам, отражает неправильную концепцию. Не думаю, что проект здания для заказчика делается таким же образом. Проект здания делается итерациями - постепенным сближением того, что заказчик хочет и того, что реально будет сделано. Если разработка проекта здания затягивается, вряд ли кому придет в голову нанять еще 10 архитекторов, чтобы быстрее спроектировать его.

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

Часто можно слышать от разработчиков: "Заказчики никогда не знают, чего они хотят". Это не верно. Заказчик обычно знает, что он хочет. Не имея пока реального опыта, он просто не может это обьяснить и не знает, как этого достичь. Согласитесь, пожив в двух разных квартирах, любой из нас сможет сказать, какая лучше и обьяснить почему. Значит, мы знаем, что для нас лучше.

Представьте на секунду, что у строителей и архитекторов появилась возможность совершенно бесплатно построить здание по своему проекту за два часа. Просто дать команду машине и оно будет построено. И так же, по команде, оно может быть перестроено в любой момент. Что изменится в работе архитектора? Архитекторы смогут показывать заказчикам дома изнутри, давать им пожить там немного. Более того, заказчик даже мог бы вселиться и начать жить и все еще иметь возможность перестроить какие-то части дома. Интересно,  будут ли в этих сказочных условиях  существовать реликты-архитекторы, которые  соберут пожелания, чтобы только через месяц дать заказчику готовое здание, отвергая все возражения словами: "Как сказали, так я и сделал".

Так вот, господа программисты, то о чем так долго мечтали строители и архитекторы - свершилось! Только не у них, а у нас - программистов. И не свершилось, а всегда было. Сменив модель (вот она, Системная Метафора!), все сразу становится на свои места.

Так давайте воспользуемся этой возможностью. Давайте показывать Заказчику результат в процессе работы. Давайте дадим ему возможность менять свои решения после того, как он попробует пожить в здании. Это просто. Это то, что предлагает XP. Делайте проект так, чтобы в любой момент можно было построить по нему здание (Частая интеграция, Unit тесты). Не делайте сложных конструкций, пока они не понадобились. Пробуйте технические решения на моделях.

Так что же такого делает XP для Заказчика? Во-первых, оно дает механизмы для соблюдения Билля о правах Заказчика. Мы можем показывать Заказчику работающую систему в любой момент. Заказчик может попробовать в действии новые функции по окончании каждой итерации. Заказчик может изменить свои требования в любой момент, не теряя при этом остальных функций.

Что XP требует от Заказчика? В принципе, не больше, чем архитектор. Заказчик должен сформулировать то, что он хочет. Заказчик должен посмотреть на эскиз или результат первой итерации и сказать - получил ли он то, чего хотел. Заказчик должен оперативно отвечать на вопросы разработчиков, чтобы те могли принимать обоснованные решения.

Хорошо, скажете вы, если бы у всех был такой заказчик, то и проблем бы не было. Нашему Заказчику некогда, он занят другими делами.

Попытайтесь проанализировать причины такого поведения. Они могут быть следующими:

• Заказчик не собирается утруждаться в обьяснениях, поскольку, "он вас нанял не для того, чтобы тратить свое время и время своих людей". Я бы попросту не брал бы такой заказ. Продукт, разработанный в таких условиях имеет минимальные шансы на успех. В конце концов, есть намного более эффективные и интересные способы потратить год своей жизни.
• Заказчик очень хочет помочь, но физически не успевает. Это очень характерно для американцев (по крайней мере, тех, которых я видел). В этом случае часто помогает подход "Дайте знать, когда вы сможете поучаствовать в планировании следующей итерации, а пока мы займемся другим проектом (или рефакторингом или автоматизацией тестов)". Обычно, подобные Заказчики очень чутко реагируют на остановку процесса разработки по их вине.
• Заказчик знает не больше вашего. Действительно, бывают случаи, когда Заказчик знает, что он хочет, но не имеет опыта в предметной области (например, потому что область новая и никто в ней не имеет опыта). В этом случае, становитесь сами себе Заказчиком. Изучайте предметную область, проводите юзабилити тесты, думайте за вашего потенциального пользователя. Проводите бета-тестирование. Выпускайте ранние версии для ограниченного тестирования. Вы сами найдете десятки способов испытать ваш продукт, как только примете тот факт, что вы сам себе Заказчик.

Один мой знакомый так классифицировал партнеров по переговорам: "Партнеры делятся на вменяемых и невменяемых. Если ты разговариваешь с человеком и видишь, что он тебя не слышит, то это невменяемый человек." Несколько грубая модель, но в нашем случае она подходит. Есть Заказчики, которые понимают, что они хотят, но при этом все время находятся не здесь. Они хотят участвовать в принятии буквально всех решений, будут спорить о преимуществе комбо-боксов перед списками, в то время, как система вообще не работает. Из их уст постоянно будут выскакивать реплики типа "нам необходимо здесь использовать XML" или "без интеграции с Palm Pilot эта система управления предприятием не будет продаваться".

Просто будьте последовательными. Процесс планирования XP позволяет Заказчику (да и вам тоже) посмотреть в глаза реальности. Даже невменяемые заказчики, будучи поставлены перед выбором - "что реализовывать в первую очередь - редактирование информации на экране или посылку ее по ИК порту на мобильный телефон Nokia" - смогут сделать адекватный выбор.

Если с расстановкой приоритетов между задачами XP неплохо справляется, то вот с оценкой результатов работы невменяемым заказчиком дела обстоят сложнее. Сделав 90% работы по обеспечению бизнес-функций сайта, но не закончив графику, вы сталкиваетесь с тем, что Заказчик считает, что ничего не готово. Или наоборот - после демонстрации красивого эскиза, Заказчик думает, что осталось закончить совсем немного. Это то, что Джоэл Сполски называет "эффектом айсберга". С точки зрения XP ключ здесь - в частых релизах. Заставляйте Заказчика пользоваться реализованными бизнес-функциями сразу после их выпуска. Не ждите "полной картинки", не давайте Заказчику откладывать обзор. Дайте ему возможность пользоваться тем, что уже реализовано. Если графический дизайн - часть вашего продукта, включайте дизайнера в команду. Планируйте задачи для него. Пусть законченные части выглядят законченными и наоборот.

Если ваш Заказчик патологически склонен вмешиваться в технические или дизайнерские решения, будьте мудрым. Займите его. Попросите его выбрать цветовую гамму, или поставьте перед проблемой выбора между вертикальным и горизонтальным меню.

Обратите внимание: XP говорит что у вас в команде должен быть Заказчик. Не Заказчики. Это не всегда соответствует действительности. Зачастую вы работаете с компанией, в которой существует Политика. Несколько подразделений борятся за место на главной странице. CEO ненавидит радио-кнопки и настаивает на чекбоксах. CFO на самом деле боится потерять власть и поэтому все расчеты начислений должны проверяться вручную. Не давайте себе быть втянутым в Политику. Требуйте одного голоса от Заказчика (одного представителя, или комитет с едиными решениями) и работайте с ним не отклоняясь от требований XP.

XP декларирует - Заказчик должен быть в команде  среди разработчиков. Это хорошо так говорить Кенту Беку который сидел в Крайслере и клепал для них же расчет зарплаты. А что делать бедному российскому кодеру, у которого Заказчик находится на расстоянии 11 часовых поясов? Я думаю, здесь надо вернуться к истокам такого требования. Зачем XP требует присутствия Заказчика? Для того, чтобы не писать длинные спецификации, являющиеся еще одним звеном в передаче информации (и местом где эта информация теряется). Есть еще и другие побочные эффекты, но это главная причина.

Итак, если физическое присутствие невозможно, то можно ли все еще отказываться от написанной документации? Можно. Наш опыт показывает, что при 12-ти часовой задержке между вопросом и ответом, все еще можно планировать работу и уточнять User Story. Если Заказчик не спит, или разработчики остаются попозже, то это время еще более сокращается. ICQ делает присутствие Заказчика почти физическим.

Также можно эффективно использовать принцип XP - замена документации кодом. Очень хорошо работает практика коммуникации через приемочные тесты. То есть, если возникает вопрос: "Как система должна работать в таком-то случае?", сформулируйте его следующим образом: "Вот тестовый сценарий. Опишите ожидаемое поведение системы." При этом чем ближе язык пользователя к языку описания теста, тем меньше информации теряется, и тем более эффективным оказывается взаимодействие. Некоторые команды даже разрабатывали языки тестовых скриптов, понятные для Заказчика, которые потом автоматически интерпретировались в функциональные тесты.

Никто не даст вам все ответы на все вопросы. Надеюсь, здесь достаточно идей, чтобы двигаться вперед. Любите своего Заказчика. Заботьтесь о нем. Воспитывайте неразумного. Вовлекайте и интригуйте. Рассейте его страхи. Докажите, что вы непохожи на тех уродов, с которыми он работал до вас.