Цель стадии и характер работ
Стадия разработки – вторая часть «рана» в цикле выпуска новой версии продукта. Здесь фокус смещается с системного уровня на инструментальный. Это не означает, что поиск решений заканчивается, и начинается чисто механическая работа. Разработка требует не меньше изобретательности от специалистов, чем проектирование, но на другом уровне абстракции. Цель стадии разработки – воплотить решения в реальности.
Мне нравится думать об этом как о совместной работе композитора и исполнителей. Я видел, как профессиональные музыканты тщательно готовятся к выступлению. От их интерпретации произведения зависит, почувствует ли слушатель задуманное композитором. То же касается связки драматурга, режиссера и актеров. Чтобы история, описанная в сценарии фильма, ожила для зрителя, от режиссера вместе с актерами требуется огромная работа. Важно учитывать каждый нюанс, но всегда остается место для импровизации. Похожим образом проектировщики работают с командой разработчиков, чтобы достичь идеального «звучания» продукта.
Требования к участникам
После прохождения контрольной точки, которая разделяет детальное проектирование и разработку, ответственность переходит к следующей версии гибкой команды. Ключевые участники становятся режиссерами, сверяются с моделью продукта и добиваются от разработчиков «правильной» игры.
Требования к специалистам формируются на стадии проектирования и команда дополняется новыми членами. От них не ожидают мультидисциплинарности, как от ключевых участников. Они должны профессионально владеть инструментами и быть компетентными в выбранном технологическом стеке, будь то серверная или клиентская разработка, верстка интерфейсов или программирование сценариев голосовых систем, настройка платежных шлюзов или обучение нейронных сетей. Их задача – качественная реализация новой версии продукта выразительными средствами, определенными архитектурой системы.
Способ оценки и планирования
При переходе к стадии разработки рабочий процесс в проекте меняется и приобретает более предсказуемый характер. Неопределенность на этой стадии должна достичь своего возможного минимума. Все, что предшествовало разработке в проекте, делалось именно с этой целью. Объем работы, который предстоит выполнить, существенно превышает тот, что был на стадии проектирования, и значит, чем меньше потерь, связанных с неэффективным использованием ресурсов, тем лучше. Грубо говоря, сделать дизайн двадцати экранов мобильного приложения – это одно, а запрограммировать их – совсем другое. Особенно когда это включает в себя сложную внутреннюю логику системы. Если разработчикам придется каждый раз тратить лишнее время на проработку нерешенных проектировщиками вопросов, то в итоге часы сложатся в дополнительные дни, недели или месяцы, которые не позволят проекту вписаться в расчетные сроки и границы бюджета.
Так что предсказуемость – это то, что ожидается на данной стадии. Она закладывается еще во время проектирования, в момент защиты проектировщиками своих решений. Специалисты, знакомясь с ними, одновременно оценивают их с точки зрения возможных трудозатрат на реализацию. Если модель продукта полна и подробна, разработчики могут точно оценить работу.
Дополнительное преимущество состоит в том, что сразу имея на руках всю необходимую информацию, есть возможность учесть взаимное влияние задач друг на друга. Элияху Голдратт в своей теории ограничений писал: «Оптимизируйте систему в целом, а не ее отдельные части». Так и здесь, общий взгляд на задачи позволяет построить оптимальный технологический процесс разработки всей стадии целиком, бережно используя время специалистов и доступный бюджет.
Критерий прохождения контрольной точки
У стадии разработки есть две заинтересованные стороны, которые могут подтвердить ее успешное завершение. Для прохождения контрольной точки, отделяющей новую версию продукта от пользователей, нужно получить одобрение со стороны бизнеса и проджект-раннера вместе с ключевыми участниками, выполняющими проектирование. Бизнесу нужен работающий продукт, а проджект-раннеру – завершение проектного цикла.
Каждая сторона оценивает результат со стороны интересующих ее свойств готового продукта и своей способности оценить их качества. Бизнес проверяет продукт с точки зрения его потребительских качеств, то есть «работает/не работает», и то, насколько функции соответствуют ожиданиям. Аргумент команды о том, что «все тесты пройдены», не будет убедителен. Поэтому бизнес хочет посмотреть на систему в действии, и единственный способ подтвердить успешное прохождение контрольной точки в глазах бизнеса – показать реальную работоспособность продукта.
Проджект-раннер выступает своеобразным адвокатом проектной команды, а заодно и более тонким ценителем их работы. Он налаживает контакт между бизнесом и специалистами, выступает в роли переводчика для сторон, которые говорят на разных языках. Он управляет ожиданиями бизнеса и помогает найти соответствие между требованиями и функциями продукта. Он также понимает внутреннее устройство системы и способен дать более полную оценку результатов работы специалистов.
Будучи доверенным лицом бизнеса, проджект-раннер может вынести вердикт о готовности новой версии. Для этого он смотрит не только на внешнее поведение системы, но и на ее реализацию. Это его совместная работа с ключевыми участниками, которые спроектировали очередной «ран». Она включает в себя как классическое тестирование, когда система рассматривается как черный ящик, который должен вести себя в соответствии с требованиями, так и то, что мы называем «алгоритмическим тестированием».
Часто то, что «выглядит как утка, крякает как утка и плавает как утка», уткой все же не является. Например, разработчики могли неверно интерпретировать внутреннюю логику системы, описанную в спецификации, и запрограммировать поведение, которое не приводит непосредственно к ошибкам в работе продукта, но сказывается на надежности или имеет долговременные последствия для накапливаемых в системе данных. Такие дефекты нельзя выявить, наблюдая за системой снаружи. Чтобы избежать таких ситуаций, необходимо проверить реализацию, «посмотреть код» на соответствие требованиям. Это можно сделать только в прямом контакте, когда разработчики защищают свой код, объясняя и показывая проектировщикам, как были реализованы те или иные части спецификации. Опыт подсказывает, что такой подход радикально повышает надежность продукта и сокращает период стабилизации.
Важно помнить, что цель – не узнать о плохом результате в конце стадии, а периодически отслеживать ход работ и вовремя давать обратную связь, чтобы у команды было время учесть замечания. Ставить перед фактом, показывая только итоговый вариант – плохая идея. И здесь важна инициатива не только проектной команды, но и бизнеса. Он должен рассматривать себя как участника проекта, а не как «клиента», который ждет сразу готовый результат. Работа на стадии разработки должна быть построена так, чтобы к моменту ее завершения продукт был готов, и прохождение контрольной точки было в некотором роде формальностью.
Модель продукта
Может показаться, что раз модель продукта на стадии разработки служит для команды «сценарием к эпизоду», то она остается без изменений. Поскольку процесс разработки тоже связан с принятием решений, он вносит коррективы в ранее принятые решения на стадии проектирования, и если при этом модель служит способом их структурированного хранения, то она неизбежно обновляется. И здесь важно не упустить этот аспект, оставив все на уровне кода или верстки.
В этой книге много раз было сказано, что проектная документация – это не скучные документы, фиксирующие решения, а инструмент коммуникаций между участниками. Если на стадии разработки выясняется, что какие-то решения оказались ошибочными или неполными, то разработчики сообщают об этом в контексте проектных артефактов, например, спецификации или дизайна интерфейса, а проектировщики отвечают им, уточняя документацию.
Одним из способов добиться этого является схема работы, при которой результаты работы принимается только в случае, когда они соответствуют актуальной модели продукта. В результате у всех участников вырабатывается доверие к документации, и они опираются на нее при принятии решений. В случае с гибкой командой, которая на разных стадиях проекта может отличаться по составу, это вообще единственный способ сохранить «память» о продукте.
Глава 10Принцип вовлеченности бизнеса
Структура главы:
• Ответственность бизнеса
• Действующий бизнес
• Стартапы
• Customer Development и архитектура бизнеса
Ответственность бизнеса
В компаниях, где бизнес-модель выстроена вокруг цифровых технологий, многое не похоже на традиционные отрасли. Чем сложнее инструменты, тем меньше работает подход «Чтобы на утро все было готово!» Не будет готово ни утром, ни днем, ни даже вечером. Если бизнес хочет строить свою работу вокруг сложных технологических инструментов, ему придется отказаться от принципа «Клиент всегда прав» в отношениях со специалистами и принять свою часть ответственности за результат проекта.
Да, проджект-раннер помогает владельцу сформулировать схему решения, основанную на цифровых продуктах, и тем самым вносит свой вклад в построение компании, но он не придумывает за него бизнес. Проектная команда во главе с проджект-раннером отвечает за «технологический продукт». Они делают «Газель», но не создают транспортную компанию. Владелец должен обернуть «технологический продукт» инфраструктурой, чтобы получить на выходе «бизнес-продукт». Только он понимает всю схему работы будущей компании и может сформулировать высокоуровневые требования к ее частям, включая цифровые сервисы.
Однако, даже если бизнес принимает свою ответственность и ясно обозначает требования к будущему цифровому продукту, неопределенность сохраняется на протяжении всего проекта. Особенно это заметно, когда работа идет в формате сериала и предполагает выпуск промежуточных «эпизодов». С каждой новой версией неопределенность только накапливается. Команда не получает обратной связи и в конце проекта продукт и реальность, проводником которой должен был бы быть бизнес, расходятся настолько, что не имеют между собой никакой связи.