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

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

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

По мнению Дэвида Майстера, существует три обобщённых типа проектов – «Мозги», «Седина» и «Процедуры» (Brains, Grey hair, Procedures). Первый тип – решение ранее неизвестных задач, например, создание сервиса для новой банковской бизнес-модели. Такой проект в большой степени похож на исследовательскую работу, и специалисты, работающие над ним, должны быть опытными профессионалами, имеющими сложившийся подход к поиску нестандартных решений.

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

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

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

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

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

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

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