Предисловие

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

Компания «ГАЛС СОФТ», которую я создал в 2002 году, тоже не была исключением. За 15 лет существования компании, вплоть до момента, когда я придумал новый формат — продюсирование ИТ-проектов, мы выполнили больше тысячи проектов и для большинства из них привлекали внешних участников. Очень быстро мы поняли, что недостаточно передать подрядчику простую постановку задачи в виде требований к продукту. Количество возможных интерпретаций и способов реализации могло быть каким угодно, но самое главное, что результат работы мог быть непредсказуемым. Постепенно, все больше ключевых проектных решений, мы начали принимать на своей стороне и уделять проектированию много внимания. Нашим языком общения с другими членами команд стала проектная документация. Это был единственный способ локализовать неопределенность, от которой зависела успешность проектов, которые мы выполняли для наших клиентов.

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

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

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

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

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

Самые интересные проекты начались, когда мы занялись мобильными приложениями. Нашим первым проектом было создание мобильного приложения для livejournal. com. В тот момент в 2009 году ЖЖ был жив как никогда и нам повезло создать приложения для Android и Windows Phone. Безусловно это были непростые проекты, не в последнюю очередь по нашей вине. Тогда мы только искали оптимальный процесс, который бы объединял работу проектировщиков, дизайнеров и разработчиков. В дальнейшем мы создали приложения для Ведомостей и Афишы. А спроектированное и разработанное нами мобильное приложение издательского дома Коммерсантъ стало одним из лучших приложений в мире для СМИ по версии Google в 2014 году. На тот момент мы еще не до конца отладили проектный процесс, но важность предварительного проектирования поняли в полной степени и это давало свои результаты.

Почитать ещё:
ИД Коммерсантъ
Мобильное приложение «Ъ» попало в топ-лист сервисов для Android 2014 года по версии Google.

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

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

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

Так появилась роль продюсера ИТ-проектов и метод параноика.

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

Почитать ещё:
How do you do, Eleven 2018?
На фотографиях герои моей сегодняшней истории, люди, внесшие максимальный вклад в развитие бюро Eleven за последний год.

Сейчас, в 2019 году, когда модель найдена и проверена на нескольких крупных проектах, я пишу эту книгу, чтобы обобщить накопленный опыт работы и привлечь внимание клиентов и профессионалов к новому формату работы над проектами. В книге я хочу рассказать ключевые принципы, которые лежат в основе этой модели работы, раскрыть схему проектного процесса, позволяющего разделять проектирование и разработку, при этом вести проект итерационно, показать приемы и необходимые артефакты проектирования, объяснить структуру построения проектной документации. Кроме этого, мне важно уделить внимание принципам мотивации людей, участвующих в таких проектах, ведь человеческий фактор в создании продуктов — самый важный.

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

Поиск модели

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

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

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

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

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

Прочтите первые несколько глав книги Дэвида Майстера, там отлично показана разница между типами проектов
Дэвид Майстер — Управление фирмой
С этой книги начался период, когда я начал заниматься бизнесом осмысленно.

Какие бывают проекты

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

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

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

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

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

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

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

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

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

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

Кто и как делает проекты

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

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

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

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

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

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

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

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

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

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

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

Основные задачи из этой области — технологические. Например, разработка новой платформы для колл-центра с технологией генерации и распознавания голоса или создание комплексной системы автоматизации выборов в крупной стране. В обоих примерах компании-подрядчику потребуется выполнить большой объем работы внутри после получения требований к проекту. Таким образом работают системные интеграторы и технологические R&D-центры. Кстати, они также прибегают к услугам компаний из других квадрантов, например, передают разработку на аутсорсинг «фармацевтам», оставляя на своей стороне задачи проектирования и координации работы над проектом.

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

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

Деньги

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

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

Нужно помнить, что то, как вы оцениваете свою деятельность, в конечном счете влияет на то, как вы эту деятельность организуете. Именно поэтому сначала я хочу обратить внимание на параметр времени.

Большинство считает по календарным периодам. Так сложилось и причина — бухгалтерский учет. Но не только. Кроме того, что бухгалтерам так удобно считать (в конечном счете это не их прихоть, а реальность в виде законодательства), есть бизнес-модель компании.

Бизнес-модели

Самая распространенная модель — ресурсная. Это когда у вас есть как у компании ресурсы и вы ими торгуете. В случае с заказной разработкой ресурсы — это рабочие часы специалистов. При этом как вы упаковываете эти часы для клиента — сдаете каждого разработчика в аренду по T&M или продаете целиком команду на проект, не имеет значения. Важно то, что чем больше у вас ресурсов, тем потенциально больше вы можете на них заработать. А вот то, как реализуется этот потенциал, определяет отношение количества проданных часов к календарному периоду времени.

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

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

Характерная черта ресурсной модели — это возможность клиента заменить ресурсы одного подрядчика на ресурсы другого или даже перейти на свои, наняв в штат специалистов требуемой квалификации. Это ограничивает возможности роста часовой ставки и вводит понятие рынка услуг. Если компании продают часы специалистов схожей квалификации, то они неизбежно конкурируют друг с другом. Способов конкуренции немного — цена, уровень опытности специалистов и управленческое качество предоставления услуг (качество коммуникаций, возможность оперативного расширения команды, координация работы специалистов на стороне подрядчика).

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

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

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

Ценность услуги в такой модели формируется не себестоимостью, от которой дальше рассчитывается стоимость для клиента путем добавления приемлемой для рынка наценки, а ценностью, которой услуга обладает в масштабах бизнеса клиента. Если, например, новая технология позволяет клиенту зарабатывать дополнительные 10% или наоборот экономить те же 10%, то при обороте компании в 100 млн. рублей ценность услуги составит 10 млн. р. Именно о таком порядке стоимости услуг необходимо вести разговор, а не о часовой ставке. Часто одного часового общения между с клиентом достаточно, чтобы повлиять на бизнес клиента. Вы же не будете говорить о стоимости часа в несколько миллионов рублей? Конечно, эта модель имеет и обратную сторону, когда одно и тоже решение или технология даст пропорционально меньший результат в абсолютных значениях в бизнесе меньшего масштаба.

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

Приходы и расходы

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

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

Если клиент покупает не просто часы специалистов, а конкретные результаты работы, например, дизайн-макеты сайта или в целом спроектированное и разработанное мобильное приложение, то это проектная работа. Для такой работы характерны нерегулярные поступления, т. е. оплата клиента, привязанная к этапам проекта, а не к календарным отрезкам. Более того, каждый этап может иметь разную стоимость, т. к. от этапа к этапу может быть задействован разный состав проектной команды. Стоимость может рассчитываться как по фактически отработанным командой часам («работа по T&M»), так и быть фиксированной («fixed price»). В случае с ресурсной бизнес-моделью, а большинство проектов так или иначе выполняются в этой модели, способ расчета стоимости («работа по T&M» или «fixed price») просто вопрос того, кто несет риски, клиент или подрядчик.

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

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

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

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

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

Любая компания, имеющая регулярные расходы, пытается добиться как можно более регулярного поступления оплат от клиентов. А регулярные поступления возможны в случае, когда команда специалистов как можно дольше работает над одним и тем же проектом и ее состав не меняется. Именно с этим связана любовь компаний-разработчиков к скраму, т. к. у проекта нет разных по стоимости этапов, а команда максимально однородна и специалисты взаимозаменяемы. Работа над проектом разбита на равные отрезки времени — спринты, за которые удобно выставлять регулярные счета. Дело как обычно в деньгах, а вовсе не в каком-то волшебном качестве скрама. Другим вариантом является то, что компания специализируется на одинаковых проектах, либо старается работать по модели аутстаффинга, передавая своих сотрудников на как можно больший срок в проекты клиентам. И то и другое характерно для проектов типа «процедуры» и «седина».

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

Доступность специалистов

Разные типы проектов требуют разных специалистов. Когда сходятся звезды и на проекте собирается нужная команда, все получается. Причем я говорю не просто про потребность в высококлассных разработчиках или талантливых дизайнерах. Для проектов часто нужны специалисты со средней компетенцией, но важно, чтобы их было много и их стоимость укладывалась в бюджет. Например, если проект типа «Процедуры» попытаться сделать командой, которая обычно делает проекты типа «Мозги», то в минусе будут все — клиент, который сильно переплатит, специалисты, т. к. для них это будет неинтересная работа, компания-подрядчик, из которой эти специалисты уволятся, если такая ситуация будет регулярной.

Схема наглядно показывает, как выглядит расхождение потребностей в специалистах требуемого уровня для проектов, которыми занимается компания и ее фактический состав. Как видно, дело может быть и в уровне компетенции, и в требуемом количестве специалистов нужной компетенции.

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

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

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

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

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

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

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

Проектирование

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

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

Почитать ещё:
Чем проектирование отличается от дизайна
Большинство клиентов под проектированием понимает «нарисовать интерфейс», а если проще сделать дизайн.

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

Качественное проектирование включает в себя как минимум три аспекта — функциональное, интерфейсное и техническое. В этой главе я только упоминаю их, в следующих частях книги я рассмотрю эту тему подробнее.

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

Продюсирование и метод параноика

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

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

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

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

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

По аналогии я назвал ключевую роль проектной команды продюсером, а в целом метод продюсирования ИТ-проектов методом параноика.

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

Если вы разделяете наш восторг относительно содержания первой части, рекомендуем также посмотреть диалог Сергея Гурова с Вадимом Митякиным. Среди обсуждаемых тем: влияние психотипа основателей компаний на реализуемые проекты, откуда берутся лучшие проектировщики, ключевые принципы и правила работы.