Правильный фокус - заказчик

Автор: Александр Якима (www.enter-agile.com)

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

В чем суть этой проблемы? Мы не будем сейчас говорить о причинах, номинально
выходящих за рамки влияния команды разработчиков, тем не менее, могущих привести к
потере заказчика (резко поднятые рейты1, упразднение определенных пунктов в контракте, низкий темп стаффинга2 и т.д). Мы поговорим об ошибках команды, которые приводят к проблеме и, что хуже всего, незаметны для самой команды.

Итак, основная суть:

Один и тот же софтверный продукт имеет две основные проекции: 1) заказчика и 2)
команды разработчиков. Итак, если мы производим цилиндрический вал:


заказчик может видеть его так:



а мы - так:


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

1. В течение проекта значительно важнее, не освоение необходимых технологий или бизнес-области, а определение персональных взглядов, приоритетов, видения, настроения, бизнес-зависимостей, фобий, привычек, планов и ожиданий заказчика. Это очень непростая задача в силу многих факторов, часть из которых мы рассмотрим. Но это не означает, что ее не нужно решать. Успех бизнеса будет напрямую зависеть именно от этого. Несколько моментов:

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

2. Отслеживание и своевременное "закрытие" всех без исключения открытых вопросов от
заказчика крайне важно. Ни один пункт не может тихо раствориться в инбоксе или
исчезнуть в избирательной памяти сразу после общения с заказчиком по телефону.

3. Команда не разрабатывает ПО, а кладет деньги на два банковских счета. Один из них -
текущий, краткосрочный. Команда кладет туда деньги, если успешно сдает итерацию, релиз, проводит успешное привью и т д. И, соответственно, снимает деньги с него, если
проваливает итерацию, или релиз. Вкратце, баланс на этом счету отражает текущее
положение дел в отношениях команда-заказчик. Другой счет - долгосрочный. Он отражает общую картину впечатления заказчика о команде, репутацию команды. Команда кладет сюда деньги, когда, например, демонстрирует глубокие знания в бизнес-области проекта, какие-то изначально необязательные, но сейчас очень интересные заказчику скилы, когда находит правильный эмоциональный тон, приносящий обоюдное удовлетворение от общения и т д. По сути, первый (текущий) счет дает возможность заказчику ответить на вопрос, "выполняет ли команда свои текущие обязательства?", второй (долгосрочный) ассоциируется для заказчика с вопросом: "почему мы сотрудничаем именно с этой конкретной командой?". Счета - это всего лишь удобная метафора, позволяющая легко представлять себе прямые последствия действий команды. Провалили итерацию: минус $100 с текущего счета. Задали глупый вопрос на демо, свидетельствующий о некомпетентности - сняли $300 с долгосрочного счета. Сдали успешно релиз: + $800 на текущий. Предложили новую фичу, которая пришлась по душе продуктовой команде - положили автоматически + $1K на долгосрочный. Кто-то из команды преуспел в изучении английского и недавно приятно удивил заказчика эффектной идиомой - плюс $250 на тот же счет. Опять таки, все это относительные цифры и важно только то, чтобы команда обрела интуитивное чувство того, как их каждое действие воспринимается заказчиком.

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

Хочу обратить внимание на то, что изначально команда разработчиков должна очень много
в себе изменить, чтобы захотеть увидеть эти принципы в жизни и начать их применять.
Принятие того, что успех проекта зависит на 20% от умения общаться (учитывая знание
языка заказчика), 20% от умения вести переговоры, 20% от самодисциплины в
отслеживании открытых вопросов, 20% от умения продавать и только на оставшиеся 20%
от умения разрабатывать ПО, - для многих факт с которым не так легко смириться. Но
рынок сам ставит свои требования, и вскоре серьезно смогут конкурировать только
специалисты, представляющие себе процесс разработки ПО органически включающий в
себя вышеописанные (нетехнические) качества. Время "раздутых технарей" постепенно
уходит, и в этом нет ничего плохого или хорошего. Это просто новое измерение для
конкурентоспособности в ИТ. Все ли команды смогут эффективно себя реализовать в новом современном образе, требующем значительно больше предпринимательских качеств, нежели технических навыков? Нет. Потому что для многих - это вопрос кардинального изменения своих мировоззренческих позиций. Смогут преобразоваться только те команды, которые способны отказаться от примитивно-эгоистического самоудовлетворения своим кодом в пользу сбалансированности и способности самим контролировать свое будущее, видя реальные причины событий в их бизнесе.

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

Как все сказанное выше соотносится с гибкими методами разработки? Не ставят ли эти
принципы Agile на задний план?

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

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

No comments:

Post a Comment

 
Powered by Blogger