Как не превратить разработку в пожар: почему мы держим связь с заказчиком в режиме 24/7

Казалось бы, разработка сайта имеет мало общего со спасением уникальных тропических лесов Амазонки от лесных пожаров. Срочность тут имеет условный характер, а спешить можно медленно. Но вообще-то это не так. За 20 лет работы на рынке мы в WEZOM твердо уяснили, что срочность – это срочность. Хоть на пожаре, хоть в разработке сложного IT-продукта. Без оперативной и постоянной связи с заказчиком в разработке не обойтись.

Без заказчика ничего не выйдет

По данным исследования Standish Group (SG), лишь около трети реализованных за последние 5 лет проектов в IT (31%) могут считаться полностью успешными. Успешный проект – тот, который уложился в заявленные сроки, не вышел за рамки утвержденного бюджета и полностью удовлетворил заказчика.

Более половины проектов в IT проседают как минимум по одному из этих критериев, а потому причисляются к «спорным». Около 20% и вовсе названы провальными – это миллиарды долларов убытков, «слитые» бюджеты и утраченные возможности.

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

Заказчики – тоже люди

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

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

В конце концов, некоторые заказчики банально «перегорают» и теряют интерес. Разработка – технически сложный и очень растянутый во времени процесс – месяцы кропотливого труда специалистов.

Команда разработки сталкивается с необычной дилеммой – нужно поддерживать вовлеченность заказчика в работу. Без этого весь проект может просто провалиться – повлечь за собой если и не финансовые, то имиджевые потери.

Проблема времени

Коммуникация подрядчика и заказчика – это всегда проблема времени. С одной стороны, обе стороны крайне загружены и с трудом тянут свой тайм-менеджмент. С другой стороны, успешная разработка требует четкого следования плану, не терпит срыва сроков по согласованиям и фидбеку.

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

В работе с заграничными заказчиками это может наложиться на проблему часовых поясов. Скажем, клиент из США хочет задать неотложные вопросы в свое рабочее время, а представитель подрядчика по эту сторону Атлантики в это время спит.

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

Тушение пожаров

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

Условно говоря – кто-то кого-то не понял. Острый для заказчика вопрос (сроки, деньги, функционал, отчетность) был проговорен не до конца, и он намерен урегулировать его немедленно.

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

Подобные «пожары» мы стремимся тушить максимально быстро, а в идеале – свести их риск к минимуму. Даже мелочь, которую не обсудили вовремя, может навредить проекту.

О технических моментах и говорить не стоит – если заказчик уже начал использовать ключевые элементы нового проекта в своем бизнесе, технические проблемы часто грозят ему прямыми убытками.

Как мы с этим справились?

Как обеспечить вовлеченность клиента в проект, решить проблему времени, вовремя «тушить пожары» и справляться с их вредными последствиями? И желательно добиться этого без перерасхода ресурсов и нервов сотрудников?

Методом проб и ошибок мы пришли к выводу, что лучший способ – закреплять за каждым заказчиком персонального менеджера. Он готов закрывать любые вопросы по проекту в режиме 24/7 и обеспечивать максимально быструю обратную связь.

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

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

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

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

И это работает?

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

Многое зависит от профессиональности менеджеров (мы, к примеру, ими очень гордимся). Наконец, важен сам принцип – готовность компании стать для клиента не просто «руками», но и полноценным партнером, c головой погрузиться в специфику его бизнеса.