Пролог
Привет! Я — Настя, руководитель проектов в Митре. Сегодня поговорим про организацию работы аналитиков, дизайнеров, копирайтеров, верстальщиков, программистов, тестировщиков – все и так знают, что это тот еще хардкор, и мы разберем его поподробнее.
Руководителю проекта нужно постоянно жонглировать десятками задач для разных исполнителей, учитывать их занятость, контролировать бюджет, сроки и качество, модерировать пожелания заказчиков. И при всём при этом продолжать держать цель проекта в голове – и не только в своей.
Чайка-менеджмент (это когда менеджер прилетел, нашумел и улетел, оставив после себя полный хаос в головах коллег) — лишь одна из немногих болей управления командой. В этой статье поговорим и о некоторых других, часть советов может показаться очевидными, но по своему опыту знаю, что в рабочей суматохе нередко забываются даже такие простые истины, так что напомнить об этом никогда не помешает. Открывайте заметки и фиксируйте главное – лишним не будет :)
Глава 1
Давайте команде концептуальные вводные
Важно, чтобы вся команда понимала цели и задачи работы — что ждет РП, что хочет заказчик. Вроде бы очевидно, но на деле мы часто забываем предупредить команду, что на текущем проекте, например, не нужен креатив и надо сделать всё четко по ТЗ. Или наоборот – ждем от дизайнера или разработчика классных предложений, а они до этого на трех проектах отработали, где не было места каким-то новым идеям. Шаг влево, шаг вправо — сами знаете что.
Забить на передачу команде бизнес-цели — классика. Вот только если в кейсе «Это лендинг для новой модели кроссовок» дизайнер вполне и сам догадается, что кнопка «Заказать» должна быть, условно, большая и красная, то на практике чаще встречаются куда менее очевидные бизнес-задачи.
пример из практики
Заказчик на сайте планировал разместить массу информации, снимающей вопросы целевой аудитории. При этом требовалось еще и разгрузить колл-центр заказчика и менеджеров, отвечающих на вопросы потребителей. Второе требование не было передано в полном объеме в отдел дизайна. Что вышло в итоге? С первой частью — грамотно распределить блоки полезной информации — справились на ура, а вот со второй вышел эпик-фейл — телефоны горячих линий и формы обратной связи оказались слишком акцентными, что привлекло бы гораздо больше внимания пользователей, чем нужно было заказчику. При приемке макетов РП вспомнил требование и заметил нестыковку, но перед демонстрацией макетов заказчику нашей команде пришлось потратить лишнее время на правки.
Хорошо, если на проекте работают опытные классные программисты, тогда они и сами вас замучают вопросом: «Для чего это нужно? Какую бизнес-задачу заказчика это решает?» — и это не праздный интерес. Зная цель, спецы смогут предложить оптимальный способ реализации той или иной фичи. Однако тут стоит помнить, что не каждый опытный программист (или дизайнер, или кто угодно другой) способен проанализировать поставленную задачу с точки зрения бизнес-логики, и это вполне нормально.
Глава 2
Ставьте задачи с головой
Постановка задач — отдельная тема. Проблемы тут зачастую две:
- сделаю всё сам – кажется, так будет быстрее
- поставлю задачу быстро-быстро кое-как, потому что куча других дел и ничего не успеваю – и вообще, чего там расписывать, всё же и так понятно
Но так не работает, причем в обоих случаях. В первом, зачастую, появляются проблемы с делегированием или, возможно, доверием в команде – тогда в первую очередь руководителю проектов нужно с этим разбираться, а не тащить всё на себе. Во втором случае – частое заблуждение и нежелание подумать на несколько простых шагов вперед. Ставишь задачу с недостаточным количеством информации, часть проговариваешь с командой голосом и потом в задаче не фиксируешь – будь готов по итогу получить невнятный результат с кучей ошибок и переделок.
Глава 3
Общайтесь с командой
Необходимость проведения еженедельных / ежедневных дейликов с командой, ретроспектив определяется внутренними процессами студии и той методологией разработки, которая применяется при работе. Если в компании нет четких правил, регламентирующих проведение регулярных встреч с командой, это не значит, что вы можете такими встречами полностью пренебречь. Ведь они позволяют контролировать работу – выявлять проблемы и оперативно решать их, разбирать вопросы от команды, лучше понимать ход проекта (есть ли отставание по срокам, какие моменты нужно как можно скорее обсудить с заказчиком).
Глава 3.1
А в каком формате общаться?
Выбор формата и частоты взаимодействия зависит от сложности и длительности разработки и от особенностей команды. Например, на простых проектах можно ограничиться еженедельными созвонами в скайпе / зуме / дискорде / телеграме – тем более после пандемии часть сотрудников продолжает работать на удаленке. А вот крупная сложная разработка, особенно в активной фазе, может потребовать ежедневных встреч — там и у разработчиков много вопросов генерируется и контроля нужно больше.
Глава 3.2
Вот только для галочки не надо
Сам ход таких мероприятий нужно тщательно модерировать, чтобы они не превращались в балаган или в собрание для галочки. Подготовьте заранее вопросы к команде, место, куда будете фиксировать важные моменты, определите тайминг – в среднем для простого проекта нужно минут 10, для сложного – 20-30. Желательно, чтобы встречи проходили в одно и то же время в одном и том же месте (или с использованием одного и того же инструмента для онлайн-общения). И не забывайте фиксировать договоренности и вопросы, потому что «что не было записано, того не было».
Видела я, как на ретро РП фиксирует всё сказанное в отдельную тетрадочку: красиво выделяет важные моменты цветными маркерами, пишет буковки с завитушками и вот это вот всё. А потом с этими записями ничего не происходит – не инициируются улучшения по выявленным в ходе проекта проблемам, не распространяются на всю компанию успешные практики, примененные в разработки. Просто собрались, поболтали час, написали красивую бумажку и разошлись. Вот не надо так. Собираясь проводить ретро, вы, как РП, скорее всего, и так предполагаете, что может быть озвучено командой. Ну так подумайте еще на шаг вперед: а что со всем этим вы потом будете делать? Если не знаете, тогда зачем вам ретро?
Глава 4
Хвалите и благодарите
После сдачи сложной и длительной разработки я всегда пишу в общий чат компании большое сообщение с благодарностью каждому участнику этого проекта. Публичная благодарность и похвала — классная мотивация. А мне потом очень приятно видеть лайки на этом сообщении и получать благодарность в ответ :)
Эпилог
Помните, что иногда косячат все. Я тоже ошибаюсь: то задачу поставлю как попало, то посчитаю, что все должны делать только так, как я говорю, и не спорить – да и много чего еще. Главное во всём этом, не забывать, как делать хорошо и правильно и продолжать к этому стремиться ;)
Ну и на десерт немного вредных советов – закрепим, так сказать:
- Приходите к разработчикам просто так – про что-нибудь поорать. А еще ловите дизайнеров у туалета или на кухне и рассказывайте им о новых задачах. Все ведь очень любят чайка-менеджмент.
- Если у вас есть задача, которую обычно делают за 8 часов, поставьте оценку 4 часа — поди удастся каким-то чудом сделать ее в два раза быстрее.
- Запретите членам команды с вами спорить — ишь, что удумали, конфликты на пустом месте разводить! Ты РП, тебе виднее – все должны делать, как ты сказал.
- И сами не спорьте с командой — программисты (дизайнеры, аналитики, тестировщики…) же всегда всё знают и никогда не ошибаются.
- Ругайте за косяки прилюдно – с глазу на глаз не так продуктивно! Пусть все знают, что кто-то ошибся!
- Не рассказывайте команде об успехах проекта, а то еще загордятся сильно. Хвалить тоже не надо, и так сойдет :)
