Блог

Зачем вашей компании проджект-менеджер?

Редакция Lodoss Team
0

Директор Lodoss Team, Никита Ващенко

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

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

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

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

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

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

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

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

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

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

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

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

  1. Неэффективная реализация

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

  1. Неправильная оценка проектов

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

  1. Общение с клиентом

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Резюме

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

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

Впервые опубликовано на портале CMS Magazine.

0