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

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

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

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

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

Сила и слабость фиксированных команд

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

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

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