Почему на сложных проектах необходим IT-продюсер

3-4 минуты на прочтение

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

§ Классический пример

Давайте представим себе некую абстрактную компанию. Не малый, конечно, бизнес — нечто более крупное. Это может быть, например, региональный транспортный оператор.

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

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

§ Проблема компетенций

Дело в том, что агентства, даже самые крупные, всегда обладают некоей ограниченностью компетенций.

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

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

§ Проблема выбора

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

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

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

Привет, реверсивное оправдание, ты подорожало.

§ Проблема мнимого финала

Итак, подрядчики подобраны, и приступают к работе.

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

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

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

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

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

Нет.

§ Проблема разрозненности

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

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

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

§ Продюсер цифровых решений

Да, вы всё правильно поняли. Именно предупреждением возникновения всех описанных выше проблем и занимается IT-продюсер.

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

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

§ В заключение

У этой статьи нет задачи описать ореол компетенций продюсера или дать инструкцию по его поиску (спойлер: на hh.ru не найдёте).

Если интересно узнать о профессии побольше, можете почитать книгу моего партнёра по Цифровой артели Eleven — Вадима Митякина. И пишите свои вопросы в комментариях.

Павел Шерер
Павел Шерер

Продюсер, аналитик, продуктовый дизайнер IT-решений, Telegram-канал

Павел Шерер
Метод параноика

Книга про создание цифровых продуктов, которую пишет мой партнёр Вадим Митякин

Поделиться:

User Story Mapping Предыдущая статья User Story Mapping и функциональная архитектура

Комментарии (0)

Добавить комментарий

Нет соединения с сервером.Сервер получил неверные данные, попробуйте еще раз.
Войдите, чтобы комментировать статью: