Метод параноика. Глава 1. Как устроена индустрия создания цифровых продуктов02.10.2019 13:33

Предисловие

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

Компания «ГАЛС СОФТ», которую я создал в 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», переходя к модели аутстаффинга.

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

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

Полный текст статьи читайте на CMS Magazine