Categories: Разное

Коммуникация в веб-проекте. Как наладить взаимодействие в IT проекте

Любой проект – это взаимодействие людей. Есть заказчик, есть менеджер, есть другие роли на проекте.

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

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

Что самое важно для коммуникации на проекте?

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

 

  1. С кем общается заказчик. В моем понимании для заказчика должен быть 1 вход в проект – менеджер проекта. Именно через него заказчик должен решать всевозможные вопросы по проекту, а не тормошить программистов или других специалистов. Очень неприятная ситуация, когда заказчик сказал что-то одному человеку, а требует это с другого человека. И потом еще предъявляет, что вы что-то забываете. Это неприятно и неправильно. Поэтому сразу договаривайтесь, чтобы все хотелки и все-все было через 1 человека.

 

  1. Типы взаимодействия. Важно разделять 2 типа – что делать и что обсудить.

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

 

  1. Выработка и прояснение правильных ожиданий. Все заинтересованные лица в проекте должны знать что им следует ожидать от других участников проекта. Не должно быть такого, что заказчик заказал будку, а ожидает, что ему построят дворец. Необходимо явно прописывать ожидания в договоре, техническом задании или других документах. И я бы рекомендовал еще дополнительно вслух их проговорить, чтобы было однозначное понимание. Т.е. вы должны как минимум сделать 2 вещи:

– понять, что ожидает от вас другие люди на проекте

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

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

 

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

Руслан Раянов

Recent Posts

Кто такой Product-owner? #понятия_веб_разработки #вебликбез

https://falconspace.ru/blog/bazovye-voprosy-i-ponyatiya-v-sfere-sozdaniya-veb-proektov - Основы веб-разработки. Базовые понятия для владельца сайта

16 часов ago

Что такое бизнес-логика? #понятия_веб_разработки #вебликбез

https://falconspace.ru/blog/bazovye-voprosy-i-ponyatiya-v-sfere-sozdaniya-veb-proektov - Основы веб-разработки. Базовые понятия для владельца сайта

2 дня ago

Кто такой Fullstack разработчик? #понятия_веб_разработки #вебликбез

https://falconspace.ru/blog/bazovye-voprosy-i-ponyatiya-v-sfere-sozdaniya-veb-proektov - Основы веб-разработки. Базовые понятия для владельца сайта

3 дня ago

Что такое Баг? #понятия_веб_разработки #вебликбез

https://falconspace.ru/blog/bazovye-voprosy-i-ponyatiya-v-sfere-sozdaniya-veb-proektov - Основы веб-разработки. Базовые понятия для владельца сайта

4 дня ago

Что такое Юзабилити? Что такое UX/UI? #понятия_веб_разработки #вебликбез

https://falconspace.ru/blog/bazovye-voprosy-i-ponyatiya-v-sfere-sozdaniya-veb-proektov - Основы веб-разработки. Базовые понятия для владельца сайта

5 дней ago

Удаленная работа с клиентами: как организовать?

Поскольку коммуникация и взаимодействие клиента с поставщиком — краеугольный камень продаж в целом и формирования…

5 дней ago