Как уменьшить пропасть недопонимания между разработчиками и менеджерами проектов
Переводчик-фрилансер Дарья Савина адаптировала статью блога Codementor, которая поможет примирить менеджера проекта с разработчиками и научит их понимать друг друга.
Обучение в онлайн-университете: курс «Product Manager»
Разработчики и руководители проектов не всегда знакомы лично, но многие разработчики скажут, что их менеджер просто ужасен. Мы спросили разработчиков на Реддите, почему они так считают, и получили ответы:
- «Для них приоритетны все направления»;
- «Он знает о проекте меньше меня»;
- «Встреча. Они все любят встречи. Слишком много встреч»;
- «Не принимают нет в качестве ответа»;
- «Не могут сказать нет клиентам».
В этой статье мы рассмотрим наиболее распространенные причины недопонимания и предложим решения для обеих сторон. Мы будем писать с точки зрения и менеджеров проектов, и разработчиков.
Советы менеджерам
Сначала определите объем и требования
Объем задач и требований к проекту поможет оценить сроки. Прежде чем согласиться на предложенный объем, руководители проектов и разработчики должны иметь четкое представление о бизнес-целях клиента. Заметьте: и менеджеры проектов, и разработчики.
Когда обе стороны поняли бизнес-цели проекта, клиент должен определить свои приоритетные задачи. Ответственность менеджера — донести до клиента, что основные цели — это те, что определяют успех проекта.
Затем руководители проектов и клиенты достигают соглашения о масштабах проекта и приоритете задач, учитывая сроки и стоимость работ. Это заставляет клиентов направить свои желания в практическое русло и решить, какие из них наиболее важны, а какие выходят за рамки необходимых или превышают намеченный бюджет.
Привлекайте разработчиков на ранней стадии проектной консультации. Когда разработчики понимают цель продукта и задачи клиента, они могут своевременно дать менеджеру совет и свести к минимуму ошибки и недопонимания.
Оценивайте сроки
Время на разработку трудно планировать точно. Проект нужно разбить на функции, а функции на небольшие эпизоды, каждый из которых должен оцениваться в зависимости от сложности и доступных ресурсов. Идеальный эпизод — тот, в котором не может быть более проработанных и чётких деталей, чем есть сейчас.
Кроме того, менеджеры проектов часто считают, что разработчики склонны недооценивать свои возможности, из-за чего многие команды за время проекта увеличиваются в 1,5 раза, чтобы выполнить чрезмерно амбициозные планы. Не обещайте того, чего не сможете выполнить.
Если клиент требует точных оценок, оцените диапазон и озвучьте его верхний предел. Не бойтесь сказать клиенту «нет», если он настаивает на нереальных сроках. Помните: нужно не обещать, а выполнять.
При работе над новым проектом, где нельзя предсказать объем и требования, в рамках Agile многие команды используют относительные, а не абсолютные оценки. Относительные оценки основываются не на количестве времени, а на сравнительном уровне затрачиваемых усилий. Использовать можно любую единицы, которые предпочитает команда: размеры футболок, цвета мармеладных мишек, города и так далее. Чтобы эти произвольные единицы можно было использовать, вам нужно создать и отсортировать их под ваш коллектив.
Если ваша команда знает алгоритм работы над проектом, можете использовать абсолютную оценку и установить количество часов или дней на задачу.
Цель абсолютных и относительных оценок — разбить весь объем работ на спринты, уменьшить их сложность и сделать их более прозрачными. Для абсолютной оценки это означает, что если вы получаете высокие числовые значения, нужно разбить задачу на несколько мелких. Для относительной оценки, например, для мармеладных мишек, если вы получаете красных медведей, а красные мишки определяются как высокий уровень усилий, нужно разбить задачи на более мелкие — желтых мишек. По мере того, как команда будет проходить больше спринтерских циклов, сроки станут оцениваться более точно.
Сократите количество совещаний
«Я пережил очередное совещание, которое могло быть просто рассылкой по электронной почте» — прокомментировал один пользователь Reddit.
Проработайте структуру и план встречи. У собрания должны быть временны́е рамки, а каждый участник должен понимать, о чем ему следует рассказать и какие встречные вопросы ему могут задать.
В Codementor разработчики ежедневно проводят 15-минутные встречи, где рассказывают, над чем работают, что получается и какие есть трудности. Особое внимание уделяется проблемам, чтобы предотвратить остановку работы.
Разработчикам не нравится, когда их приглашают на собрания для простой связи или обновлений, которые можно рассылать по электронной почте. Один пользователь Reddit прокомментировал это так: «Встреча из разряда обновление статуса одновременно раздражает и оскорбляет, и вы просто сходите с ума от ярости, когда снова на неё попадаете».
Чтобы избежать ненужных и неэффективных встреч, используйте систему учета задач для организации времени. Задачи можно ранжировать и вытаскивать из упорядоченного списка, например, используя карточки Trello. Вы также можете использовать Standuply для асинхронных встреч в Slack. Программа управления проектами будет моментально информировать участников, когда задача поставлена, находится в процессе или выполнена. Это исключит ненужные совещания.
Вот 5 программ для управления проектами:
- Jira;
- ActiveCollab;
- LiquidPlanner;
- PivotalTracker;
- SprintGround.
Помните, что вы в одной команде
Менеджер проекта — лидер команды, и его задача — защищать ее. Когда руководство сталкивается с трудными вопросами или невыполнимыми запросами клиентов, старайтесь самостоятельно решить эти вопросы, чтобы разработчики продолжили выполнять свою работу. Не позволяйте клиентам напрягать участников команды крайними сроками или влезать в работу проекта.
Хотя задача проект-менеджеров — защищать свою команду и помогать им справиться с проблемами, эти неприятные аспекты работы могут быть сведены к минимуму, если они действительно будут брать на себя полную ответственность за проект: своевременно обновлять и доносить информацию, сообщать о задержках и изменять условия для обеих сторон. Консультируйтесь с разработчиками относительно любых просьб об изменениях от клиента. Убедитесь, что они следят за временем и рабочие журналы ведутся должным образом, а не заочно перед проверкой.
Будьте скромнее
Когда нужно внести изменения, менеджеру следует спросить, а не поставить перед фактом. У разработчиков должен быть выбор: «Если возможно…» намного лучше, чем «Мне нужно, чтобы ты…»
В большинстве случаев разработчики знают о технологии больше, чем их руководитель, поэтому менеджеру следует использовать это и не упускать любую возможность посоветоваться с разработчиком, чтобы получить хороший результат.
Идеальный менеджер проекта глазами разработчика
- Понимает и учитывает ограничения, в том числе время, бюджет и ресурсы.
- Собран в процессе подготовки и во время работы.
- Ведет проект по плану на всех этапах и придерживается его.
- Предан проекту, команде и клиенту.
- Ему всегда хватает энергии и энтузиазма.
- Знает технические составляющие и их важность для бизнес-целей проекта.
- Способен направлять команду в нужное русло.
- Сосредоточен на целостной картине проекта и конечной цели.
- Доверяет членам команды, может эффективно делегировать обязанности и не мешать им.
Советы разработчикам
Ответственность за эффективные рабочие процессы и здоровую профессиональную среду не только на руководителе проекта, поэтому вот три совета разработчикам.
Объясняйте доступно
Если хотите, чтобы менеджер понял, почему одна функция занимает больше времени, чем другая, или почему происходят технические задержки, объясните всё с точки зрения ваших общих бизнес-целей. Это также поможет менеджеру донести суть до клиента.
Спрашивайте и предлагайте
Задавайте вопросы на начальных этапах проекта. Убедитесь, что вы понимаете цель процессов и не бойтесь рассуждать о направлениях и этапах работы. Это поможет согласовать ваши цели с задачами менеджера и клиента. Если видите потенциальные риски или проблемы, говорите об этом как можно скорее и предлагайте альтернативы. Если недовольны коммуникациями или структурой собраний, не жалуйтесь, а предлагайте свои варианты.
Уважайте друг друга
Как и в любых рабочих отношениях, нужно взаимное уважение. Разработчики и менеджеры проектов не всегда согласны друг с другом, но обе стороны понимают, что каждый просто выполняет свою работу. Покажите эту статью своему менеджеру, чтобы вместе работать над улучшением взаимопонимания.
Резюме
- Обсудите и вместе установите критерии оценки времени и качества работы.
- Продумайте и утвердите процесс коммуникации.
- Признайте уникальные навыки и вклад друг друга в общий проект.
- Помните: разработчики и менеджеры должны делать продукт, а не враждовать.
Читать еще:»7 идей для онбординга нового разработчика в штат»
Мнение автора и редакции может не совпадать. Хотите написать колонку для «Нетологии»? Читайте наши условия публикации. Чтобы быть в курсе всех новостей и читать новые статьи, присоединяйтесь к Телеграм-каналу Нетологии.
Полный текст статьи читайте на Нетология
