Аналогично и бизнес зачастую не различает специализации подрядчиков, и называют всех просто «разработчиками», независимо от того, идет ли речь про дизайнеров мобильных интерфейсов или про инфраструктурных серверных инженеров. Очевидно, что, если рассматривать цифровые продукты в качестве ключевых инструментов современного бизнеса, такой подход дает все что угодно, кроме хорошего результата. Ведь если вы хотите получить продукт, который решит ваши задачи, необходимо четко их сформулировать и найти тех, кто лучше всего подойдет для их реаизации.
Здесь кроется основное противоречие. Чтобы перейти от задач бизнеса к их решению на уровне конкретных цифровых продуктов, нужно находиться на стыке обеих сфер деятельности. Но специалисты часто не понимают язык бизнеса, а бизнес не разбирается в том, как устроена индустрия создания цифровых продуктов. Поэтому одни настаивают на четкой постановке задач на техническом уровне, а другие ждут, что от них требуется только заплатить и ждать результат. Возможно, такой подход бы сработал, но только когда бизнес знает, кто именно решит его задачу.
Продюсерский подход как основа «Метод параноика» позволяет устранить описанное противоречие. Он объясняет, как выстроить отношения между бизнесом и специалистами, кто должен находиться между ними на пересечении разных компетенций и как перейти от замысла к конкретному воплощению. В конечном счете успех проекта зависит не только от подходящей конфигурации команды, но и от организации работы таким образом, чтобы могли проявиться лучшие качества участников.
Для этого нужно понимать, кто основные игроки IT-экосистемы и по каким правилам идет игра. Если вы в индустрии, это описание поможет вам системно посмотреть на профессиональный мир вокруг вас. Если вы ищете помощь в создании мобильного приложения или цифрового сервиса для бизнеса, эта глава даст понимание, как классифицировать задачу и к кому обратиться.
Первое, что нужно знать об отрасли разработки программных продуктов – все зависит от конкретных людей. В рамках одной задачи и одного проектного процесса у двух, казалось бы, схожих по квалификации специалистов будет совершенно разный результат. Понятие типовой производительности в час – иллюзия, корни которой уходят в индустриальные времена, когда рабочий должен был выдавать норму выработки в рамках налаженного технологического процесса, например, на конвейере по производству машин или гамбургеров. Это означает, что точная предварительная оценка проекта невозможна в принципе. Связано это не только с индивидуальной скоростью работы, но и с тем, что разные специалисты по-разному решат одну и ту же задачу. На этом сложности только начинаются.
Помню, как впервые прочитал книгу Дэвида Майстера «Управление фирмой, оказывающей профессиональные услуги». На тот момент компании «ГАЛС СОФТ» было уже 10 лет, и, к своему удивлению и восторгу, я нашел в этой книге ответы на большинство накопившихся вопросов. Я был поражен, как все просто складывалось. Майстер писал про юридические и консалтинговые компании, я же адаптировал описанную модель под реалии IT-индустрии. В итоге после анализа нашей деятельности мы кардинально изменили формат работы с клиентами, а с некоторыми из них даже завершили проекты, чтобы сфокусироваться на приоритетных задачах. Всем, кто занимается проектной деятельностью, настоятельно рекомендую прочесть как минимум две книги – «Управление фирмой, оказывающей профессиональные услуги» и «Истинный профессионализм».
По мнению Дэвида Майстера, существует три обобщенных типа проектов – «Мозги», «Седина» и «Процедуры» (Brains, Grey Hair, Procedures).
«Мозги» – это решение новых задач, например, создание сервиса для новой банковской бизнес-модели. Такие проекты похожи на исследовательскую работу, и специалисты, работающие над ними, должны быть опытными профессионалами с навыками поиска нестандартных решений.
Второй тип, «Седина», ориентирован на проекты, где клиент заинтересован в отраслевых или технологических наработках подрядчика. Примером может служить обращение розничной сети к компании, которая имеет опыт внедрения программ лояльности. Такая компания уже выработала подходящие решения, на реальных проектах выявила сильные и слабые стороны технологии, сформировала процесс внедрения и создала команду, способную данное решение внедрять, запускать и поддерживать.