Agile в зависимости от контекста
В прошлой статье мы обсудили влияние размера команды на применение “гибких” подходов в проектах. В этот раз попробуем разобраться в влиянии производственного контекста на этот выбор.
Начнем с определения терминов, которые будем использовать.
Контракт — понятие аутсорс разработки, которое не имеет смысла в продуктовой разработке, там есть внутренний заказчик и ваши с ним взаимоотношения строятся по совсем другим правилам.
Рассмотрим 3 основные силы проекта:
Заказчик— инвестор, владелец бизнеса, который заинтересован получить бизнес выгоду от проекта
Команда — технические и не только специалисты, которые выполняют проект, хотят создавать крутые системы, использовать модные технологии, уникальные продукты и так далее
Пользователи — люди, которые будут использовать полученный результат, в своей повседневной жизни. Могут получать выгоду как для бизнеса, так и для себя.
Между этими тремя силами возникает обмен ценностями: бизнес дает команде инвестиции/плату, команда дает пользователям результат(программный продукт, систему, процесс), пользователи дают бизнесу выгоду от использования результата работы команды, это может быть как прямая выгода (увеличение дохода), так и косвенная(уменьшение расходов).
Можно это выразить попробовать выразить наглядно в виде формулы:
E (QV) ≥ C×T
где Е — выгода от результата с параметрами качество(Q) и объем(V) должна быть больше чем стоимость(С) и длительность выполнения проекта(T)
Перейдем, непосредственно, к контекстам
- Внутренняя разработка и внедрение
Проект создается выполняется внутри компании, все три стороны являются частью компании и у них достаточно плотная коммуникация и быстрая обратная связь.
Здесь могут быть свои нюансы, например, бюджет может быть ограничен условно, цели проекта размыты, конечные пользователи могут быть против изменений и саботировать внедрение. Проект может быть инициирован кем то сверху без достаточного экономического обоснования и без продуманного ТЗ. Корпоративная политика может играть критическую роль в успехе или провале проекта. Наибольшую роль играет объем выполненных работ и качество, меньше обращают внимания на бюджет и длительность.
Гибкий подход здесь представляется наилучшим решением, ввиду неопределенности конечной цели проекта и реакции пользователей на его внедрение. Постоянная демонстрация промежуточных версий позволит быстро понять степень соответствия результата ожиданиям внутреннего заказчика и пользователей и, если они вступают в конфликт, эскалировать этот вопрос до того, как будет потрачено еще больше денег и времени на никому не нужный функционал.
Основная роль руководителя проекта в данном контексте — управление ожиданиями как заказчика, так и пользователей. Он также внимательно следит за истинными причинами инициации данного проекта, изменением внутренней политики, собирает обратную связь как можно чаще.
Обычно в данном случае на руководителе проекта лежит обязанность сбора требований, написания документации, ТЗ, прототипирование, проверка гипотез.
Типовые риски включают: разрастание объема работ, превышение бюджета и сроков, внесение существенных изменений на поздних этапах проекта, “золочение”, невнятность целей проекта, смена заинтересованных лиц проекта в течении проекта.
Рекомендации: частая демонстрация промежуточных результатов, контроль экономической выгоды от продолжения проекта, учет затрат, по возможности выделять команду отдельно от своих департаментов и требовать соответствующих полномочий для управления, при отсутствии специалистов соответствующей квалификации внутри компании отдавать разработку на аутсорс или выделять IT отдел, как отдельную структуру (псевдоаутсорс).
2. Заказная разработка (аутсорс)
В этом контексте из 3х сторон команда уже не на стороне заказчика, это приводит к некоторым потерям/разрывам в коммуникации. Общение строится более формально и с меньшей периодичностью. Возникают конфликты на почве неучтенных или неуточненных требований, когда в контракте прописали высокоуровневые требования и их оценили, а на практике все оказалось сложнее, дороже и дольше. Заказчик не хочет доплачивать, исполнитель не хочет делать за свой счет, начинаются торги и долгие переговоры.
Интерес заказчика/бизнес — получить программную систему, которая позволит ему получить какую то выгоду в его бизнесе, интерес исполнителя — выполнить контракт с прибылью для себя. Проблема в том, что бизнес не всегда представляет лучший способ получить необходимую выгоду, а исполнитель хочет продать наиболее готовое решение из имеющихся у него или технологию, с которой ему выгоднее всего работать, даже если она не совсем подходит заказчику для достижения его бизнес целей. В итоге может возникнуть ситуация, когда проект завершен, система внедрена, но она не используется, либо не приносит ожидаемых выгод. Исполнитель получил свою прибыль, но заказчик не будет с ним больше работать, поскольку его цели не достигнуты. Роль руководителя в данном контексте — избежать подобной ситуации, равно как и ситуации, когда из-за постоянных изменений, доделок, исправлений контракт перестает быть рентабельным для исполнителя, то есть управление ожиданиями.
На первый план выходит стоимость, на втором месте — время. Качество и объем становятся в конце данного списка. Бизнес среда меняется очень быстро и затянувшийся дорогой проект может уже не иметь смысла для бизнеса, например, если конкуренты вышли на рынок раньше с похожим продуктом.
В этом контексте имеет смысл использовать гибридный подход, например water-scrum-fall, особенно при типе контракта Fixed Price. Таким образом мы выделяем фазу сбора и утверждения требований отдельно от разработки, впоследствии не давая возможности заказчику внести изменения в проект за счет исполнителя и уменьшая количество необходимых переделок в проекте.
В случае, когда заказчик активно использует гибкие подходы в своей работе и готов уделять много своего времени участию в проекте, а также тип контракта Time&Material — полностью agile подход тоже окажется эффективным (очень редкое явление пока что).
Типичные риски: разрастание объема проекта, неготовность инфраструктуры и пользователей на стороне заказчика к внедрению, разрывы в коммуникациях (неполные, противоречивые требования), результат проекта не используется или не приносит ту выгоду, которую ожидалось, не учтена полная стоимость владения, включая внедрение, обучение и поддержку (а не только разработка).
Рекомендации: управлять ожиданиями заказчика, прилагать усилия по выявлению будущих пользователей и наличия контакта с ними, частые демонстрации промежуточного результата с тестированием будущими пользователями и получение обратной связи, добиваться раннего внедрения (закрытого beta тестирования будущими пользователями) перед внедрением и в контрольных точках, быть не просто исполнителями, а интеграторами, разбираться в бизнес-домене заказчика, консультировать его, помогать внедрять результат.

3. Продуктовая разработка
В этом контексте у нас меняются цели проекта. Если в предыдущем случае это была бизнес выгода для заказчика, то в этом случае — это успешный продукт на рынке, который приносит выгоду или удобство для большого количества бизнесов или частных лиц. Круг пользователей становится настолько широк, что для их опроса мы делаем репрезентативную выборку и работаем с ней. Также в этом контексте существенную роль начинают играть конкуренты нашего продукта.
На первый план выходит время, затем качество. Качество — как соответствия ожиданиям пользователей и то, насколько успешно продукт решает их проблему. Бюджет и объем проекта сильно зависят от качества и идут после него по важности.
Если в среднем по индустрии успешно завершаются чуть больше 50% проектов, то в продуктовой разработке эта цифра хорошо если 10%, но в этих проектах возврат многократно превышает вложения.
Причин провала может быть множество. Типичные риски: неправильное понимание рынка/потребителя, неэффективность команды, действия конкурентов, изменения законодательства.
В данном контексте лучше всего работают Agile подходы (lean, kanban, XP, Scrum) и итеративная разработка на основе быстрой обратной связи, аналитики, продуктовых исследований, продаж.
Рекомендации: быстрая обратная связь, не бояться существенных изменений бизнес модели на основе полученных данных(pivot), нанимать продуктового менеджера с опытом в этом бизнес-домене (и ещё десятки книг про стартапы с их рекомендациями, очень модная сейчас тема).