Мы решили не спорить из-за пустяков.
Теперь мы спорим о том, что считать пустяками.
— «Разбирайтесь сами!» — говорит владелец небольшой IT компании в ответ на утренние жалобы PM-а и сейлза друг на друга.
— «Еще один заваленный из-за ваших споров проект — оба пойдете на выход».
Что частенько происходит между продажами и менеджментом на проекте? Испорченный телефон при описании требований, необъективная оценка проекта, недовольные заказчики и загнанные бешеным темпом разработчики — проблемы, ответственность за которые эти ребята перебрасывают друг другу будто горячую картошку. Почему так происходит? Как правильно распределить ответственность между данными специалистами? Как подружить PM и Sales на проекте? Давайте разбираться!
Роли PM и Sales менеджеров в проекте
Тандем проектного менеджера и менеджера по продажам — это супер-сила, способная придумать и продать правительству план по взлому Пентагона, или завалить проект по разработке калькулятора. Тут как повезет.
Основная задача Sales менеджера — это поиск и привлечение выгодных для фирмы клиентов и убеждение их в том, что вы — именно та команда, которая сможет реализовать идею правильно и в срок, или даже раньше срока. В этот момент, клиент должен полюбить фирму и работать с ней (читай: платить ей) всегда.
Деятельность сейлза, в основном, кратковременна и реализуются в период предпродажи проекта. Стремясь заинтересовать и удержать клиента, менеджер по продажам инстинктивно занижает стоимость проекта и обещает немного больше, чем, возможно, сможет выполнить его команда.
Задачей проектного менеджера является объективная оценка объема работ, отсеивание невыполнимых фич, планирование и контроль выполнения проекта. А еще закладывание определенного количества буферных часов на каждый таск, аккуратное откладывание релизов, проведение удачных (и не очень) демо.
Деятельность данного специалиста не ограничивается конкретной фазой, наоборот, IT-управленец несет ответственность за проект от его начала и до самого конца. Именно поэтому данный специалист старается давать минимальные гарантии клиенту и завышать стоимость работ, закладывая как можно больше рисков.
Из-за конфликта интересов мы можем столкнуться с ситуацией, когда специалисты отказываются коммуницировать друг с другом, перетягивая одеяло инициативы на себя.
Проблемы взаимодействия на примерах
Мы пообщались с представителями обеих враждующих (или не обязательно враждующих) групп и совместными усилиями выделили наиболее часто встречающиеся проблемы на проекте.
Оценка проекта без участия PM-а и команды
Обязанности Sales и Project Manager на стадии инициации могут быть не разграничены, именно поэтому случаются ситуации, когда оценку проекта дает менеджер по продажам, исходя из опыта своих предыдущих сделок. В таких ситуациях, из-за отсутствия на этапе оценивания PM-а и команды, процесс разработки часто выходит за оговоренные рамки сроков и бюджета. Часто и сами PM-ы, не понимая важности стадии пресейла, не считают нужным посвящать менеджера по продажам в сложность проекта, полагая, что потом сами по ходу смогут уточнить все необходимые детали. К сожалению, именно эти детали имеют прямое влияние на конечную стоимость проекта и настроение заказчика.
Сокрытие проблем на проекте
Инстинкт защитника, присущий PM-ам, не позволяет свободно говорить о проблемах на проекте. Как итог — менеджер по продажам получает сорванные сроки, разгневанного клиента и неоплаченные часы.
Отсутствие инструкций по коммуникациям
Непрописанная политика коммуникаций на каждой стадии проекта также часто стоит на пути к успешному завершению работ. Ранее никак не связанные с IT-сферой клиенты, после пройденной стадии предпродажи машинально стараются коммуницировать только с менеджером по продажам, уже успевшим войти в доверие. Ничего страшного в этом нет, но испорченный телефон и несвоевременная передача просьб и «хотелок» может изрядно подпортить нервы всем участникам проекта.
Отсутствие отчетности от PM-а на проекте
ТЗ со всеми дополнениями, список выполненных задач вне первоначальных договоренностей, отчет за потраченные часы, follow up по каждому митингу — отсутствие этих документов здорово снижает боевой дух Sales-менеджера на стадии закрытия проекта.
Продажа джунов на сложные проекты
«Пусть учится», — говорит Sales-manager, продавая junior разработчика на сложный проект. То, о чем думает проектный менеджер, краснея перед заказчиком на очередном митинге, здесь мы описывать не будем.
Как PM-у ужиться с сейлзом и не завалить проект
Проекты, рожденные в условиях безоговорочной дружбы проектного менеджера и менеджера по продажам, обычно самые успешные. Ведь у одного участника тандема есть ключ от сердца заказчика, у второго — от сердец членов команды. Но как и в любые отношения, отношения сейлза и PM-а требуют установки определенных правил и их выполнения. Давайте посмотрим на основные законы общения Sales и PM.
Правило 1: Обсудите схему взаимодействия
Начиная сотрудничество, PM и Sales должны оговорить стадии предпродажи, выполнения и закрытия проекта, разграничить зоны ответственности, определить политику коммуникаций и, конечно, поделиться друг с другом собственными профессиональными ценностями. Двум капитанам будет гораздо легче работать вместе, если оба понимают и принимают взгляды своего коллеги.
Правило 2: Правильная оценка = здоровый проект
Правило для Sales manager: как бы ни чесались руки наобещать клиенту всего побольше и вечный двигатель в придачу — посоветуйтесь с менеджером, которому предстоит вести проект. Возможно, «совсем небольшая демка для заказчика» окажется вполне себе серьезной работой на пару месяцев, а от некоторого функционала и вовсе придется отказаться.
Правильно 3: Не игнорировать стадию предпродажи
Когда менеджер по продажам просит «rough estimate», не стоит относиться к его просьбе халатно и отказываться вникать в проект. Чем больше деталей PM узнает на стадии оценки проекта, тем меньше стресса он будет испытывать в процессе его разработки.
Правило 4: Довольный клиент = щедрый клиент
И речь сейчас совсем не о качественном продукте. При переходе проекта от стадии предпродажи к стадии сбора требований и последующей разработки очень важно, чтобы сейлз передал (а менеджер перенял) правильную манеру общения с клиентом. Заказчик уже с нами, а значит ключик к его сердцу найден. Так почему бы не использовать его для укрепления отношений?
Правило 5: Отчетность и двухсторонняя коммуникация
Как уже было сказано ранее, задача PM-а качественно разработать проект, задача Sales — выгодно его продать. Регулярная коммуникации менеджмента и продаж поможет не только качественно собрать требования, но и удерживать клиента в благостном настроении на протяжение всего срока сотрудничества. А подробное документирование PM-ом всего, что происходит, ускорит процесс закрытия проекта и сведет к минимуму потерю прибыли компанией.
Продавать или не продавать — вот в чем вопрос
Существуют ситуации, когда вышеперечисленные правила не работают. Это как раз те ситуации, когда сейлзу очень нужно сделать продажу, а PM-у — прикрыть попы любимых разработчиков от возможных сложностей. Но и такие кейсы не являются безвыходными.
Когда есть вкусный проект, но команды для него нет
Представьте ситуацию, когда денежный клиент и старинный друг фирмы обращается к менеджеру по продажам с идеей пусть даже небольшого, но интересного проекта. Его успешное выполнение сулит хороший доход и укрепление партнерских отношений с заказчиком. Но вот беда — все разработчики заняты и взять проект просто некому. Сейлз говорит: «Ну надо!» — ПМ говорит: «Но некогда!» — и начинаются недопонимания.
Что делать в такой ситуации? Ответ гениальный — сесть и подумать.
Что может со своей стороны сделать сейлз:
- Постараться отодвинуть время официального начала проекта к сроку, когда разработчики будут свободны для новой работы.
- Если не работает первый вариант — затянуть процесс подписания договора, сбора требований, обсуждения всех деталей. Возможно, растянуть стадию дизайна на более долгий срок.
- Обсудить вопрос с PM-ом и, придя к консенсусу, отказаться от менее важного проекта.
Что может сделать со своей стороны ПМ:
- Постараться впихнуть второй проект своей команде, чередуя занятость проектами по дням. Практика плохая, но это работает.
- Высвободить из команды специалиста для выполнения инфраструктурных задач по новому проекту.
Есть команда, но нет технологий, которые хочет заказчик
Ситуация, когда приходит проект с незнакомыми команде технологиями, также достаточно распространена. Проект интересен с финансовой стороны и крут по содержанию, но команда не знакома с фреймворком или даже языком.
Что со своей стороны может сделать сейлз:
- Отказаться от проекта.
- Убедить клиента в том, что на «наших» технологиях будет работать круче.
- Набросить на существующую оценку (если ее осмелились дать) как можно больше рисков.
Что со своей стороны может сделать ПМ:
- До последнего отказываться от проекта и мотать нервы менеджеру по продажам.
- Оперативно нанять специалиста под проект.
- Найти энтузиастов, готовых к развитию в своей команде (и умножить их оценки как минимум на 2).
Заказчик отказывается делать ТЗ на свой проект
Просто невозможно не вставить фразу: «Без ТЗ — результат ХЗ». Если проект стоящий, то данный конфликт определенно нужно решать.
Что может сделать со своей стороны сейлз:
- Убедить клиента в том, что ТЗ — это хорошо и бесплатно для него в данной ситуации.
- Привлечь PM-а ко всем митингам с клиентом, чтобы помочь ему сформировать понимание проекта и понять, что не так страшен черт, как его малюют, и вообще «мы такие проекты 100 раз делали!».
- Записывать абсолютно все слова клиента, чтобы избежать формулировок «я такого не говорил», «я за это платить не буду», «мы обсуждали эту фичу в начале проекта».
Что может сделать со своей стороны PM:
- Отстаивать важность документации до последнего удара сердца.
- Смириться и начать документировать все, что слышит сам и все, что слышит Sales записывать тоже. Готовить внутреннюю спецификацию проекта для себя и команды.
- Фиксировать все запросы на изменения от клиента.
- Максимально часто проводить демо для клиента и сверяться с его ожиданиями.
Как итог ко всему перечисленному хотим сказать: общение — ключ ко всему. Помните, что эффективные коммуникации формируют здоровую атмосферу в команде и позволяют получать удовольствие от проекта.
Вы в одной лодке, господа. Да воцарит мир между продажами и разработкой!
Спасибо за помощь и консультацию Анастасии Горде