13 вредных советов для проектного менеджера

Независимо от своего опыта, люди склонны ошибаться, и от этого никто не застрахован. За время своей работы я собрал перечень основных ошибок, которые часто совершают project менеджеры. Основанные на этих ошибках «вредные советы» не претендуют на эксклюзивность и не охватывают всех ситуаций, которые могут с вами приключиться, но точно входят в список самых распространённых. Вы можете не следовать этим советам, но, как говориться, предупрежден — значит вооружен!

1) Не оговаривайте всех деталей с клиентом

Как часто у вас возникала ситуация, что при решении какого-либо вопроса вы с клиентом с полуслова приходили к единому решению, однако по прошествии всего цикла разработки и после представления результата клиенту получали ответ, что он имел ввиду совсем другое?

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

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

2) Не фиксируйте результаты телефонных и устных переговоров в переписке

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

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

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

3) Не уточняйте ТЗ

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

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

4) Соглашайтесь на все доработки без оценки

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

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

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

5) Не следите за ходом выполнения работ

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

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

6) Подолгу не отвечайте клиенту

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

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

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

7) Работайте по своему особому графику

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

Нестыковка во времени знакома всем project менеджерам, которые работают с иностранными клиентами.

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

8) Передавайте информацию между техническими специалистами своими словами

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

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

9) Делегируйте общение с клиентом вашим разработчикам

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

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

10) Перекладывайте всю работу над ошибками на ваших сотрудников

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

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

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

11) Используйте только один канал связи

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

Благо в наше время есть огромное разнообразие средств связи. Например, вы можете установить плагин в вашу почту, который будет сигнализировать, что письмо было открыто и прочитано. Также можно пробовать использовать мессенеджеры, в которых явно указывается, что сообщение было прочитано (facebook messenger, viber).

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

12) Храните информацию о проекте как попало

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

К примеру, у меня такая ситуация возникала, когда файлы по проекту были равномерно распределены в почте, dropbox, google drive и skype. Очень важно выработать единую структуру хранения файлов по проекту, которая позволит вам избежать лишней траты времени на то, чтобы объяснить коллеге, где находится нужный ему файл.

13) Реагируйте эмоционально на любые спорные ситуации по проекту (бонус)

В качестве бонуса хотел бы заметить, что работа project менеджера заключается в общении — и не только с разработчиками, но и с клиентами. А люди, как известно, бывают разные, с особыми запросами и манерой общения.

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