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

Да, мы должны опираться на результаты проектирования, чтобы выбирать участников проекта, но и сам процесс формирования команды является проектированием. В «Методе параноика» проектирование пронизывает весь проект от начала и до конца. Это означает, что на очередной контрольной точке проекта мы должны использовать три правила принципа проектирования и по отношению к участникам команды.

«Железобетонное» правило

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

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

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

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

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

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

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