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

Когда мы создали Lodoss Team, первое время занимались разработкой сайтов и мобильных приложений на заказ. Кроме самих основателей в нашу команду входили только разработчики. Технический директор, Антон Репьев контролировал веб-направление, я руководил созданием мобильных приложений, Дмитрий Ковалев был директором по продажам. Мы думали, что это идеальная схема, в которой нет ничего лишнего: программисты работают над продуктом, мы администрируем. Оказалось, что наши представления были далеки от идеала.

В этой статье мы расскажем, как прошли путь от небольшой команды, состоявшей только из разработчиков, до IТ-компании c тонко настроенными бизнес-процессами.

Как мы работали без менеджеров

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

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

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

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

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

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

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

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

Переломный момент в нашей работе наступил, когда мы осознали три главных проблемы работы без менеджеров.

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

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

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

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

Работа с менеджерами: первый опыт

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

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

Мы сделали паузу и попытались ответить на вопрос, где же находится зона ответственности проджект-менеджера, чем все-таки он должен заниматься. Мы выделили три главных момента.

Проджект-менеджер должен уметь:

Контролировать сроки работы над проектом и производительность коллектива.

Определять слабые и проблемные места проекта, устранять их, если нужно, оперативно перестраивать работу в команде.

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

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

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

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

Дальше — больше. Кроме проджект-менеджеров в компании появилось и другие должности, вся работа с клиентскими проектами пошла по-другому, а это потребовало оптимизировать и перенастроить все бизнес-процессы.

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

Вот как на данный момент выглядит экосистема работы на проектами.

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

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

Менеджер по продажам выявляет главную проблему заказчика и продает ее решение с помощью проекта.

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

Резюме

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

• Если над проектом работает больше двух разработчиков — вам нужен проджект-менеджер. В идеале, вообще оградить программистов от общения с клиентами;

• Директор — не менеджер-проектов, он решает глобальные стратегические задачи. Не пытайтесь контролировать все сами;

• Чтобы все заработало недостаточно придумать новую должность. Настройте бизнес-процессы и создайте прозрачные и понятные системы мотивации сотрудников.

Сергей Орехов
Директор по развитию digital-студии PINKMAN

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

Молодым студиям при работе с менеджерами проектов стоит обратить внимание на два важных момента.

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

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

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

Василий Вишняков
Генеральный директор интернет-агентства Bquadro

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

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

Максим Мамонов
Директор USERSTORY

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

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

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

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

Полина Приходько
UX desinger WEZOM

Дополню совсем немного:

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

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

Автор статьи дает крайне дельный совет и им будет грех не воспользоваться: «Если над проектом работает больше двух разработчиков — вам нужен проджект-менеджер.»

Конечно, нужно быть внимательным к уровню профессионализма кандидатуры на эту должность.

PM — однозначно должен оптимизировать процесс разработки, разруливать факапы, следить за качеством производства и вписаться в ваш коллектив.

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

Пару простых предложений, на которые стоит обратить внимание:

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

• Lean — методика бережливого производства, есть пару интересных и понятных книг, автором которых является Элияху Голдратт.

• Посещайте актуальные конференции и прислушивайтесь к советам, рекомендациям опытных специалистов.

• Не скупитесь и с уважением относитесь к вашей команде.

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

Константин Нефедов
Управляющий партнер digital-агентства «ДАЛЕЕ»

По первому однозначного ответа дать нельзя — очень зависит от самого человека, его скилов и бэкграунда.

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

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

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