Как управлять процессом разработки: шпаргалка для заказчика

В своем докладе на BitrixDay Алексей Бородкин, директор по продуктам в Notamedia, рассказал, как сделать процесс системной разработки управляемым. Мы законспектировали выступление Алексея и предлагаем вам разобраться, чем отличается управляемая разработка от стихийной.

Стихийная разработка

Я не буду рассказывать о том, что качественный продукт – это хорошо. Любой на рынке скажет вам: «Мы динамично развивающаяся команда молодых специалистов, которая создает высококачественные решения, ориентированные на бизнес». Но никто не сможет объяснить, что такое качество, какой смысл в это вкладывается. Понятие качества размывается настолько, что мы вообще не понимаем, как это выстрелит в деньгах для заказчика.

Вместе с «качеством» размывается и само понятие разработки. И тогда мы получаем упомянутую выше стихийную разработку. Вот как выглядит этот процесс в глазах многих разработчиков:

• Сперва идут какие-то формальности. Мы должны подписать документы, чтобы сказать клиенту: вот ТЗ, давай, нормально. Заложим риски на дизайн и разработку, на случай, если клиент будет ерепениться. Перезаложимся раза в два-три, клиент все равно ничего в этом не понимает.
• Этап гарантии и сдачи давайте проскочим побыстрее, потому что не дай боже клиент что-то там заметит. А если все-таки заметит, мы вот эти заложенные риски используем. А если дальше будет возмущаться, всегда можно сказать: «Вот этого в ТЗ не было, допкост (дополнительные расходы – прим.ред), давай деньги плати».
• В итоге: переделки, переделки, переделки.

Самое интересное наступает, когда заканчивается срок гарантии, и разработчик говорит: «Ну наконец, живите дальше с вашим вот этим продуктом». К чему все это приводит?

1. Заказчик получает не продукт, а мутанта с кучей переделок.
2. Завышается стоимость разработки, потому что, во-первых, разработчик закладывает туда риски, которые не соответствуют продукту. Во-вторых, он все переделки пытается списать под «не было в ТЗ, давайте допкост», потому что это ему выгодно.
3. Тратится огромное количество менеджерских ресурсов.
4. В итоге возрастает стоимость владения этим продуктом, потому что разработка занимает огромное количество времени, тратятся ресурсы, и мы потом с этим мутантом ничего не можем сделать. Потому что развивать его возьмется не любой разработчик.

Корпоративный портал Битрикс24

Карл Вигерс, патриарх системного проектирования, посчитал для американского рынка, что 40% бюджетов на разработку тратится на пустые переделки. Потому что не договорились, не поняли, не синхронизировались.

Не верите Карлу Вигерсу? Барак Обама устроил в США реформу здравоохранения. Это был грандиознейший скандал несколько лет назад.

В рамках реформы разработали гору разных систем: медицинских, обслуживающих и так далее. В итоге, когда они были созданы, оказалось, что программы не могут контактировать между собой. Ни один разработчик не знал, как устроена платформа, для которой они продукт пишут. Не было ни ТЗ, ни описания. И они потратили на этот проект несколько млрд долларов, а потом несколько сотен миллионов потратили на переделки. Обама назвал это самым неуспешным проектом чуть ли не в истории США.

Что мы имеем, когда разработка строится стихийно:

• мы неэффективно тратим ресурсы: нервы, деньги, время, мотивацию,
• проект становится неуправляемым, потому что мы не знаем, куда он идет,
• мы не можем его развивать, потому что не знаем, что получим в итоге.

Лучшее решение с такими продуктами – срыть все под корень и строить с нуля по уму.

Управляемая разработка

Чтобы перейти к описанию управляемого процесса, сначала разберемся, чем вообще занимается разработчик.

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

Что мы имеем на рынке разработки? Приходит заказчик к разработчику и говорит: я хочу такой-то продукт и у меня такие-то потребности. И происходит следующий диалог:
— Так, мясо какое вам надо?
— А какое бывает?
— А какое вам надо?
— Я не знаю, а какое бывает?
— Так, началось, ну давайте выбирайте.

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

А, по-хорошему, заказчик должен приходить с задачей и уходить с продуктом. Кстати, что такое продукт? Объясняю на примере интернет-магазина.

• У нас есть задачи заказчика: он должен получать доход, обеспечивать доставку, оформление заказа и так далее;
• С другой стороны, мы должны обеспечить задачи пользователя. Он должен подбирать товар, класть в корзину, получать его, оплачивать;
• У нас есть внешние условия: конкурентная среда, внешние сервисы, с которыми наш магазин будет связан, 1С и много всего другого.

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

И они должны формулироваться из бизнеса, а не на основе вопросов заказчику: а какое вы хотите меню, горизонтальное или вертикальное. Это не важно, так как дело разработчика – предложить оптимальный вариант. Заказчик должен оперировать только задачами.

Если мы следуем этой логике, вот как изменяется процесс разработки:

• подготовка становится не каким-то формальным этапом, а процессом проработки продукта. Когда мы прорабатываем интерфейсы, пишем ТЗ;
• процесс дизайна расцветает другими красками, так как мы оцениваем его не с позиции «нравится-не нравится», а с точки зрения того, будет ли он полезен в рамках этого продукта;
• появляется понимание продукта, так как заказчик еще на этапе аналитики и проектирования видит продукт и понимает, что получит в итоге;
• появляется прогнозируемая стоимость разработки, потому что есть ТЗ и прототип. Разработчик может назвать точную сумму;
• есть четкие ожидания. Поскольку этот процесс строится в тесном контакте с заказчиком, он знает, что ожидать;
• снижаются денежные и временные риски;
• рационально расходуются ресурсы менеджера – мы не заставляем его кодить, выискивать мелкие ошибки в верстке;
• минимизируется стоимость владения, потому что разработка предсказуема, занимает минимум времени и масштабируема. Мы знаем, что делать с этим впоследствии, так как у нас есть актуальная документация и понимание внутренней структуры.

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

Итеративный подход

Если мы хотим еще больше максимизировать качество, можем перейти к итеративному подходу. Что это такое? Например, мы создаем сайт спортивного СМИ. Большой ресурс, на котором есть и статистика, и репортажи, и статьи. При итеративном подходе разработчик не кидается делать одновременно все эти составляющие, так как они могут впоследствии измениться.

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

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

Хитрость в том, что на каждом из этапов есть постоянный анализ, проектирование и тестирование. Это дает возможность уже через месяц получить правильный результат. А не так: «Мы два месяца думали, вот вам ТЗ».

Сложно себе представить сервис, который будут разрабатывать 1,5 года, в итоге он выйдет и окажется очень полезным. Не бывает такого, мы не можем это спрогнозировать. Скорее всего, надо будет переделывать. А переделки – это еще полгода. И вот мы опять понимаем, что не успели.

В случае с итеративной разработкой такого бага не будет. Так как:

• мы можем проверять гипотезы. Если пользователям что-то не нравится, можно исправить. Мы готовы к изменениям. Происходит проверка гипотез на реальных пользователям;
• мы готовы к развитию;
• эффективно расходуются средства. К тому же, у нас уже через пару месяцев есть маленький продукт, с которого можно получать деньги;
• появляется колоссальная управляемость, потому что заказчик может каждый момент вмешаться в проект и направить его в нужное русло;
• есть понятный результат каждый месяц;
• качество возрастает.

Точки внимания для заказчика

На что стоит обратить внимание, когда вы выбираете компанию-разработчика и начинаете работать с ней над продуктом:

1. У разработчика должны быть выстроены процессы проектирования. Если он говорит «давайте ТЗ подпишем, а там разберемся», это не дело. Разработчик должен рассказывать, во что этот процесс выльется в плане ресурсов и денег.
2. У вас в компании должен быть специально выделенный человек, который будет заниматься продуктом. И лучше, чтобы это был не менеджер. Так как у менеджера система ценностей направлена на соблюдения бюджетов и сроков, скорее всего он пожертвует всем остальным, чтобы соблюсти их. Нужен отдельный человек, который станет адвокатом проекта и будет отстаивать его интересы и перед заказчиком, и перед разработчиком.
3. И последнее: я призываю внимательно относиться к затратам на проекте, понимать, какие работы идут на пользу бюджету, и вкладывать в мозги.

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

Полностью выступление Алексея доступно в видеозаписи:

Фото обложки: Kat Tomilloso, Flickr.com