По данным исследования B1 и Центра оценки и развития проектного управления, только 48% российских компаний завершают большинство проектов в рамках изначальных сроков, бюджета и объема работ. У остальных сдвигается хотя бы один из этих трех параметров.
В кризис запаса на такие сдвиги нет. Продукт нужен через несколько недель, и если пытаться уложить в них все задуманное, проблемы вылезут в день запуска.
Расскажу на своем опыте, как уложить разработку в два месяца, если над продуктом одновременно работают несколько независимых команд. Отдельно остановлюсь на приоритетах при нехватке времени, на координации между участниками и на том, когда разработку стоит притормозить, чтобы не допустить критической ошибки.
Как принимать решения при ограниченных сроках и высокой цене ошибки
Когда сроки сжаты, требований всегда больше, чем команда успевает сделать. Пользовательские сценарии, интеграции с внешними сервисами, платежи, инструменты поддержки и дополнительные функции обсуждаются одновременно, и время легко уходит на второстепенное.
Поэтому я делю требования на три группы:
- Без чего пользователь не выполнит основное действие;
- Что может сломать продукт после запуска: платежи, передача данных, безопасность;
- Что можно доделать после релиза.
Первыми проверяются интеграции. Если продукт зависит от внешнего сервиса, платежной системы или обмена данными между несколькими системами, их нужно проверить до того, как команда возьмется за второстепенные функции. Ранняя проверка сразу показывает реальные ограничения: каких данных не хватает, где системы несовместимы, какие требования придется пересмотреть. В начале проекта на такие исправления уходят дни, в конце — недели.
Как выстроить координацию параллельных процессов разработки без потери качества
То, что несколько команд работают по плану, еще не значит, что продукт готов. Каждая может закрывать свои задачи в срок, а полный пользовательский сценарий при этом не проходит. Чаще всего ломается стык: компоненты по отдельности работают корректно, но данные между ними передаются неправильно или нужные процессы вообще не связаны.
С этим мы столкнулись при запуске платформы ваучеров Lufthansa Group во время пандемии COVID-19. Платформа должна была помочь пассажирам сохранить стоимость неиспользованных билетов и потратить ее позже на новый перелет. Правила при этом учитывались сразу для нескольких авиакомпаний группы: Lufthansa, SWISS, Austrian Airlines, Brussels Airlines и Air Dolomiti. Над проектом работали пять команд из разных организаций. Одни отвечали за бронирования и ваучеры, другие за обмен данными с системами авиакомпании, платежи, поддержку и коммуникации.
По отчетам отдельные направления шли по плану, но понять по этим отчетам, готов ли продукт к запуску, было нельзя, поэтому мне пришлось поменять организацию работы:
- Команды отказались от оценки готовности проекта через отдельные задачи и сосредоточились на проверке сквозных пользовательских сценариев.
- Первым контрольным сценарием выбрали путь пассажира с отложенным бронированием, который получает ваучер на новый перелет. Он проходит через несколько систем, так что на нем можно было проверить все ключевые интеграции.
- Руководители проектов регулярно сверяли прогресс, изменения и риски между командами. Если спор возникал на стыке систем, к обсуждению подключали технических лидов.
- Для всех участников ввели общие этапы проверки и единые критерии готовности, хотя внутри команд разработку организовывали каждый по-своему.
Если вы планируете параллельную разработку, договоритесь о паре-тройке сквозных сценариев еще до старта активной работы и проверяйте их на каждом этапе. По моему опыту, именно такие проверки показывают проблемы в интеграциях, обмене данными и взаимодействии команд, которые в обычных статус-отчетах почти не видны.
Когда замедлить разработку правильнее, чем ускорить
Замедление разработки становится оправданным, когда команда обнаруживает факторы, которые могут повлиять на результат запуска. В этот момент важно не пытаться быстро закрыть возникший вопрос, а проверить, какие изменения он может вызвать для всего продукта.
На практике стоит пересмотреть план в пяти случаях:
- В процессе работы появляется новый пользовательский сценарий, который не был предусмотрен на старте. В такой ситуации важно проверить, какие системы участвуют в этом сценарии, какие данные должны передаваться между ними и какие дополнительные действия потребуются от команды после запуска.
- Команды по-разному понимают одну и ту же бизнес-логику. Скажем, для одной определенный статус означает, что операция завершена, а другая использует его как промежуточный этап. Пока единое понимание процесса не зафиксировано, дальше идти нельзя, иначе ошибка всплывет на интеграции.
- Изменение кажется локальным, но на деле задевает нескольких участников. Прежде чем за него браться, нужно составить полный список связанных компонентов и решить, какие команды будут участвовать в доработке.
- Технически сценарий работает, но не сходится с тем, как все устроено в операционке. Например, система корректно обрабатывает запрос пользователя, а у поддержки нет инструментов для нестандартных случаев. Здесь стоит пройти весь путь пользователя после запуска, а не только его техническую часть.
- Команда не может подтвердить, что решение соответствует исходным требованиям. Если участники начинают опираться на предположения вместо согласованных данных, лучше выделить время на дополнительную проверку и только потом продолжать.
Лишний день на такую проверку обходится дешевле, чем исправления после релиза. В проектах с высокой ценой ошибки скорость разработки во многом зависит от того, как рано команда находит проблемы.
Что отличает команды, которые быстро выводят продукт на рынок
Команды, которые быстро выводят продукты на рынок, обычно заранее проверяют несколько организационных факторов. Перед запуском полезно ответить на несколько вопросов:
- Понятно ли команде, какого результата нужно добиться к запуску? Если каждый формулирует цель по-своему, разработка быстро распадается на набор отдельных задач. Поэтому до начала работы стоит зафиксировать, какой пользовательский сценарий считается успешным и по каким признакам команда поймет, что продукт готов.
- Может ли команда объяснить, какие ограничения она приняла? Быстрый запуск всегда означает выбор. У зрелых команд есть список решений, которые они осознанно отложили. Например, отдельные операции какое-то время обрабатываются вручную, а редкие сценарии ждут следующей версии, если от них не зависит основная функция.
- Понимают ли участники проекта последствия изменений? Требования по ходу разработки меняются постоянно. Оценивать стоит не только саму доработку, но и то, как она отразится на сроках, архитектуре, операционных процессах и соседних частях продукта.
- Использует ли команда процессы для принятия решений? Методология сама по себе запуск не ускоряет. Толк от встреч, статусов и правил есть тогда, когда с их помощью команда быстро находит проблемы, фиксирует решения и идет дальше.
По опыту, скорость выпуска продукта зависит прежде всего от того, насколько хорошо команда управляет ограничениями. Чем раньше все понимают, что входит в первую версию, какие решения приняты и что еще нужно проверить, тем больше шансов выйти на рынок вовремя.
Вместо вывода
Если коротко, вот о чем стоит договориться до старта, чтобы запуститься быстро и не потерять в качестве:
- Зафиксируйте критерии готовности до начала разработки. Команда должна заранее понимать, какие системы участвуют, какие данные передаются и что придется делать команде после запуска.
- Ограничьте количество решений, которые команда принимает одновременно. Чем больше изменений появляется в процессе разработки, тем сложнее оценивать их влияние на сроки и качество. Новые требования стоит добавлять только после оценки того, какие части продукта они затронут.
- Проверяйте самые сложные участки в начале проекта. Интеграции, внешние зависимости и нестандартные сценарии требуют больше времени на проверку, поэтому их лучше тестировать до того, как команда завершит основную часть разработки.
- Оставляйте в первой версии только функции, которые необходимы для запуска. Дополнительные возможности можно переносить на следующие этапы, если они не влияют на основной пользовательский сценарий.
- Фиксируйте принятые ограничения и отложенные решения. Это помогает команде понимать, какие компромиссы были сделаны для запуска и какие вопросы нужно вернуться после выхода продукта.
Быстрый запуск держится на том, насколько рано команда понимает границы первой версии: что в нее входит, что отложено и почему, какие участки проверены, а какие держатся на допущениях. Когда это записано и известно всем командам, два месяца на запуск — реальный срок. Когда нет, проблемы первым находит пользователь.
Источник: Томас Хеллстром, ведущий разработчик, IDT Corp.
