Читаем Метод параноика. Как взять под контроль неопределённость в проектах при создании цифровых продуктов для бизнеса полностью

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

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

Другая ситуация, когда клиенту нужно сделать аналогичное решение, как у конкурентов. В этом случае лучший выбор – это подрядчик, уже обладающий отраслевым опытом и выполнивший несколько подобных проектов. Когда компания занимается похожими проектами, в результате формируется сложившаяся структура команды. Например, когда мы в «ГАЛС СОФТ» создавали приложения для СМИ, у нас на проекте всегда был руководитель проекта, интерфейсный дизайнер, технический архитектор, он же лидер группы разработки, пара разработчиков для каждой из мобильных платформ и тестировщик. Работа команды укладывалась в один и тот же проектный цикл, состоящий из одних и тех же этапов. Более того, если разрабатываемые продукты имеют схожую функциональность, то и состав, и объем задач у каждого из участников был похож от проекта к проекту. Таким образом обычно строится работа над проектами типа «Седина».

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

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

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

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

Перейти на страницу:

Похожие книги

Управление рисками
Управление рисками

Harvard Business Review – ведущий деловой журнал с многолетней историей. В этот сборник вошли лучшие статьи авторов HBR на тему риск-менеджмента.Инсайдерские атаки, саботаж, нарушение цепочек поставок, техногенные катастрофы и политические кризисы влияют на устойчивость организаций. Пытаясь их предотвратить, большинство руководителей вводят все новые и новые правила и принуждают сотрудников их выполнять. Однако переоценка некоторых рисков и невозможность предусмотреть скрытые угрозы приводят к тому, что компании нерационально расходуют ресурсы, а это может нанести серьезный, а то и непоправимый ущерб бизнесу. Прочитав этот сборник, вы узнаете о категориях рисков и внедрении процессов по управлению ими, научитесь использовать неопределенность для прорывных инноваций и сможете избежать распространенных ошибок прогнозирования, чтобы получить конкурентное преимущество.Статьи Нассима Талеба, Кондолизы Райс, Роберта Каплана и других авторов HBR помогут вам выстроить эффективную стратегию управления рисками и подготовиться к будущим вызовам.Способность компании противостоять штормам во многом зависит от того, насколько серьезно лидеры воспринимают свою функцию управления рисками в то время, когда светит солнце и горизонт чист.Иногда попытки уклониться от риска в действительности его увеличивают, а готовность принять на себя больше риска позволяет более эффективно им управлять.Все организации стремятся учиться на ошибках. Немногие ищут возможность почерпнуть что-то из событий, которые могли бы закончиться плохо, но все обошлось благодаря удачному стечению обстоятельств. Руководители должны понимать и учитывать: если люди спаслись, будучи на волосок от гибели, они склонны приписывать это устойчивости системы, хотя столь же вероятно, что сама эта ситуация сложилась из-за уязвимости системы.Для когоДля руководителей, глав компаний, генеральных директоров и собственников бизнеса.

Harvard Business Review (HBR) , Сергей Каледин , Тулкин Нарметов

Карьера, кадры / Экономика / Менеджмент / Финансы и бизнес
Чистый Agile. Основы гибкости
Чистый Agile. Основы гибкости

Прошло почти двадцать лет с тех пор как появился Манифест Agile. Легендарный Роберт Мартин (Дядя Боб) понял, что пора стряхнуть пыль с принципов Agile, и заново рассказать о гибком подходе не только новому поколению программистов, но и специалистам из других отраслей. Автор полюбившихся айтишникам книг «Чистый код», «Идеальный программист», «Чистая архитектура» стоял у истоков Agile. «Чистый Agile» устраняет недопонимание и путаницу, которые за годы существования Agile усложнили его применение по сравнению с изначальным замыслом.По сути Agile — это всего лишь небольшая подборка методов и инструментов, помогающая небольшим командам программистов управлять небольшими проектами,… но приводящая к большим результатам, потому что каждый крупный проект состоит из огромного количества кирпичиков. Пять десятков лет работы с проектами всех мыслимых видов и размеров позволяют Дяде Бобу показать, как на самом деле должен работать Agile.Если вы хотите понять преимущества Agile, не ищите лёгких путей — нужно правильно применять Agile. «Чистый Agile» расскажет, как это делать разработчикам, тестировщикам, руководителям, менеджерам проектов и клиентам.

Роберт Сесил Мартин , Роберт С. Мартин

Программирование, программы, базы данных / Менеджмент / Финансы и бизнес