Любой проект – это взаимодействие людей. Есть заказчик, есть менеджер, есть другие роли на проекте.
И внутри проекта происходит множество различных взаимодействий. Чем больше людей на проекте, тем сложнее отслеживать и формализовать эти взаимодействия?
А зачем вообще формализовать эти взаимодействия? Дело в том, что если нет стандартов или протоколов взаимодействия, то сразу очень многое становится зависимым от личности конкретных людей. В первую очередь от личности заказчика и личности менеджера. Если менеджер толковый и опытный, то он и без дополнительных правил доведет проект до успешного завершения. Но если заказчик или менеджер не обладают необходимым опытом в запуске проектов, то начинают возникать проблемы. Их можно предупредить если четко задать процессы взаимодействия от процесса. Т.е. формализация позволяет снизить риски того, что проект по инициативе отдельных лиц забредет не в те степи.
Что самое важно для коммуникации на проекте?
- Скорость реакции. Если на проекте взаимодействие идет через переписку по почте, а письма пишутся 1 раз в день, то возникают дикие задержки. Это плохой знак для проекта, т.к. любое решение задерживается на 24 часа + если возникают вопросы, то все затягивается на неимоверно долгий срок.
- Формат общения. Что вы используете для взаимодействия? Личные встречи, звонки по телефону, звонки скайп, почту, мессенджеры. У каждого способа есть свои плюсы и минусы. Мы за общение по скайпу. Личные встречи обычно занимают значительно больше времени. Телефон не обеспечивает общую визуализацию текущего положения проекта. Переписка – вообще самый плохой вариант.
- Интенсивность общения. Необходимо выбрать правильную интенсивность общения между заказчиком и группой разработки. У нас были заказчики, с которыми звонки проходили по 5 часов каждый день, а были заказчики, которые пишут раз в неделю. И то и другое – не очень хорошо для проекта. В идеале плотно работать с заказчиком на этапе создания задания, а на этапе выполнения проекта – просто показывать результат 1 раз в неделю.
- С кем общается заказчик. В моем понимании для заказчика должен быть 1 вход в проект – менеджер проекта. Именно через него заказчик должен решать всевозможные вопросы по проекту, а не тормошить программистов или других специалистов. Очень неприятная ситуация, когда заказчик сказал что-то одному человеку, а требует это с другого человека. И потом еще предъявляет, что вы что-то забываете. Это неприятно и неправильно. Поэтому сразу договаривайтесь, чтобы все хотелки и все-все было через 1 человека.
- Типы взаимодействия. Важно разделять 2 типа – что делать и что обсудить.
Что делать – это задачи, которые требуется просто внедрить в проект. Задачи должны быть заведены в системе управления проектом. Что обсудить – это когда есть вопросы или сомнения по проекту у заказчика, и он хочет обсуждения. У нас была такая ситуация – когда заказчик просто мешал все в один файл, и это ужасно раздражало программистов. Приходится разделять и самостоятельно решать – что есть задача, а что есть мысли заказчика вслух. Задачи фиксируем в задачнике, а обсуждения – в скайпе или другом средстве плотного общения.
- Выработка и прояснение правильных ожиданий. Все заинтересованные лица в проекте должны знать что им следует ожидать от других участников проекта. Не должно быть такого, что заказчик заказал будку, а ожидает, что ему построят дворец. Необходимо явно прописывать ожидания в договоре, техническом задании или других документах. И я бы рекомендовал еще дополнительно вслух их проговорить, чтобы было однозначное понимание. Т.е. вы должны как минимум сделать 2 вещи:
– понять, что ожидает от вас другие люди на проекте
– явно и прямо сказать другим, что вы ждете от них в плане работы на проекте.
Простой пример: менеджер подразумевает, что он будет давать отчет 1 раз в неделю по проекту, а заказчик полагает, что ему каждый день будут писать детальный отчет что и кто делал на проекте + звонить и спрашивать про следующий шаг. Это опасный путь. Лучше сразу все проговорить и придерживаться этих договоренностей.
Все эти моменты уже могут значительно улучшить ваш проект. Попробуйте оценить свое текущее взаимодействие по проектам и написать план как его можно улучшить.