Метод параноика. Принципы создания цифровых продуктов для бизнеса в условиях неопределенности

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

<p>Способ оценки и планирования</p>

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

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

Дополнительное преимущество состоит в том, что сразу имея на руках всю необходимую информацию, есть возможность учесть взаимное влияние задач друг на друга. Элияху Голдратт в своей теории ограничений писал: «Оптимизируйте систему в целом, а не ее отдельные части». Так и здесь, общий взгляд на задачи позволяет построить оптимальный технологический процесс разработки всей стадии целиком, бережно используя время специалистов и доступный бюджет.

<p>Критерий прохождения контрольной точки</p>

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

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

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

Будучи доверенным лицом бизнеса, проджект-раннер может вынести вердикт о готовности новой версии. Для этого он смотрит не только на внешнее поведение системы, но и на ее реализацию. Это его совместная работа с ключевыми участниками, которые спроектировали очередной «ран». Она включает в себя как классическое тестирование, когда система рассматривается как черный ящик, который должен вести себя в соответствии с требованиями, так и то, что мы называем «алгоритмическим тестированием».