Автор: Ольга Романова, Project Manager, DataArt

Более восьми лет я работаю в IT-индустрии, в частности, пять лет на позиции проджект-менеджера (РМ). По моим наблюдениям, проблемы в управлении очень похожи и кочуют из проекта в проект. Типичные ошибки не зависят от географии,  масштаба проекта и его сложности, компетенции команды и разделения ролей. Что уж говорить — многие из них совершала и я. Мне стало интересно, насколько мои выводы подтверждаются опытом не-РМ: разработчиков, аналитиков, тестировщиков. 

В феврале 2021 года я провела опрос участников команд разработки в офисах Украины и России. В опросе предлагалось выявить наиболее частые и раздражающие моменты при взаимодействии с руководителями проектов. 

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

ЧАСТЬ ПЕРВАЯ. СТАТИСТИЧЕСКАЯ 

Больше половины всех участников отметили, что плохая постановка задач — наиболее распространенная боль команд разработок. Второе и третье место с небольшим отрывом делят:

1. Недостаточное погружение  РМ в суть проекта, непонимание прикладной области. При этом многие опрошенные указали, что с радостью провели  бы онбординг, чтобы помочь товарищу-руководителю, но... РМы их не часто об этом просят. По меткому замечадного из респондентов, непонимание проекта и отсутствие технической грамотности часто приводит к ошибкам планирования.
2. Игнорирование вопросов и неудобных рисков, выявленных командой, уход от проблемы. Эта тема, пожалуй, заслуживает отдельной статьи и, по моему опыту, такое поведение связано не только с навыками риск-менеджмента, но и с лидерскими качествами менеджера.

Что касается постановки задач, антирейтинг наиболее раздражающих и — увы! — при этом наиболее частых проколов руководителей проектов возглавляют пустые или недостаточные описания задач. Более 70 % респондентов отметили этот пункт. 

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

ЧАСТЬ ВТОРАЯ. РЕФЛЕКСИВНАЯ 

Пожалуй, тут я поделюсь только собственным опытом и не буду претендовать на абсолютное знание. 

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

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

Отличный вариант — привлечение к этому процессу бизнес-аналитика (BA). В его задачи входит детальное описание требований, дизайн краевых случаев. Вместе с тем, все-таки РМ, а не BA совместно с командой ставят задачи и планируют.

В истинных Agile-командах роль РМ в привычном понимании нивелируется. Agile говорит о ценности команды, способной самоорганизоваться, поставив себе достижимые и четкие задачи самостоятельно. Зачем такой команде руководитель, ставящий и контролирующий задачи? Вместе с тем, противоречий я не вижу. 

Не столь важно, кто технически описал задачу и поставил ее, если проджект-менеджер проконтролировал и организовал конечный результат: убедился, что в команде понимают,  кто, что и зачем должен сделать. Таким образом, любая докрутка задач и их логическое выстраивание — для меня зона ответственности РМ. 

Отдельно скажу о проджект-менеджерах, которые доводят задачи сверху с минимальным согласованием с командой. Чем плох этот подход?

1. Знания одного человека всегда ограничены. Можно быть классным РМ, но твои коллеги могут иметь больше опыта в отдельных сферах. Опираясь только на свои знания, можно что-то пропустить или повести команду не оптимальной дорогой.
2. Назначение задач сверху без обсуждения исключает второе мнение в команде, возможность проявить инициативу другими участниками и может подорвать экологичность отношений. 
3. Ограничение роста команды. Мы растем не только когда берем сложные задачи, но и когда несем за них ответственность. Не давая возможности эту ответственность проявить, РМ ограничивает развитие команды.

РМ всегда — лидер проекта, и, в конечном счете, отвечает за его доставку. Я очень люблю термин ownership — он емко отражает мое видение ответственности. Я глубоко убеждена, что а) личная ответственность и вовлеченность проджект-менеджера; б) корректная постановка задач — важные факторы успеха любого проекта. 

Обратная связь моих бывших и нынешних коллег подтверждала и подтверждает: все любят быть на одной волне и в едином контексте. Без исключений для РМ.

ЧАСТЬ ТРЕТЬЯ. ИРОНИЧНАЯ 

В моем детстве был мультик про чертенка под номером 13. Забавный такой мульт о перевернутом мире. А если бы чертенок вырос, понял свое призвание и стал преподавать в школе проджект-менеджеров? Пожалуй, вот что он мог бы посоветовать своим ученикам в плане постановки задач. 

1. Пишите длинные описания задач.

Чем длиннее, тем лучше! Не в наших обязанностях — поддерживать фокус команды на главном. Лучше написать все что можно и потом сказать: «О, я же говорил!» — или «Вот тут внизу (видите, где зачеркнуто и потом мелким шрифтом?) было написано...»

2. А лучше вообще не пишите.

С другой стороны, кто их будет читать? Можно вообще не составлять описания задач — и себе время сэкономите, и команде. Высший пилотаж — вставить единственное предложение с изложением сути прямо в поле названия, а описание оставить пустым. Команда и так должна быть в контексте. На то и Agile. 

3. Ставьте задачи голосом.

Больше совещаний! И меньше заметок. Все вопросы лучше обсуждать голосом — рассказать ведь намного быстрее, чем что-то записывать. Ну и что, что вся команда потратит лишний час рабочего времени на очередной звонок. Зато не нужно ломать голову, составляя описания в JIRA. Люди у нас тут все неглупые, по результатам разговора сами разберутся, что делать, а что нет.

4. Чем больше источников правды, тем лучше.

Больше источников, больше! Стандарт вашего проекта должен быть таким: доска задач (можно и несколько, чего мелочиться), Confluence, какой-нибудь отдельный документ в облачном хранилище и, желательно, диаграмма, которую никто и никогда не будет обновлять. Все изменения вносите молча и куда попало. Настоящий разработчик должен быть сыщиком: пусть покажет свои способности — помучается, но найдет все нужные требования и самостоятельно разрешит все конфликты.

5. Никогда не анализируйте задачу.

Если клиент или продакт-оунер поставили задачу в письменном виде, ни в коем случае не анализируйте ее! Вы не бизнес-аналитик, ваше призвание — управлять, ваша обязанность — спрашивать: «Когда будет готово?!»

6. Пренебрегайте критериями приемки и краевыми сценариями.

Все-таки это работа тестировщика. Или архитектора. Или бизнес-аналитика. В вашем проекте их нет? Значит, разобраться придется разработчику. Хотя лучше бы клиенту самому обо всем подумать заранее.

7. Не устанавливайте связи задачи с эпиком или связанными компонентами.

Все и так понимают о чем речь. Если не понимают — надо работать над контекстом, все же есть в JIRA!

Все перечисленные выше пункты, конечно, не руководство к действию, а ирония и самоирония по поводу наших ошибок. А что думаете вы?

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

Английская версия статьи доступна в личном Medium-блоге автора.