Шкідливі поради проджект-менеджеру: як ставити задачі, щоб їх не виконували з першого разу

27 квітня
Ольга Романова, Project Manager
Шкідливі поради проджект-менеджеру: як ставити задачі, щоб їх не виконували з першого разу
Понад вісім років я працюю в IT-індустрії, зокрема п'ять — на позиції проджект-менеджера. За моїми спостереженнями, зазвичай проблеми в керуванні є дуже схожими та кочують із проекту в проект. Типові помилки не залежать від географії, масштабу проекту та його складності, компетенції команди та поділу ролей. Що вже казати — таких помилок припускалась і я. Мені стало цікаво, наскільки мої висновки підтверджуються досвідом не-РМ: розробників, аналітиків, тестувальників.

У лютому 2021 року я провела опитування серед учасників команд розробки в офісах в Україні та Росії, щоб виявити найбільш часті та дратівливі моменти при взаємодії з керівниками проектів. Результати опитування — точніше, солідарність учасників у відповідях на деякі запитання та їхня кореляція з моїми особистими спостереженнями — здивували мене.

ЧАСТИНА ПЕРША. СТАТИСТИЧНА

Більше половини учасників зазначили, що погана постановка задач є найпоширенішою біллю команд розробки. Друге і третє місця з невеликим відривом ділять:

  • Недостатнє занурення РМ у суть проекту, нерозуміння прикладної сфери. При цьому більшість опитаних вказали, що з радістю провели б онбординг, щоб допомогти товаришеві-керівнику, але PM їх не часто про це просять. За влучним зауваженням одного з респондентів, нерозуміння проекту і відсутність технічної грамотності часто призводять до помилок планування.
  • Ігнорування питань і незручних ризиків, виявлених командою, відхід від проблеми. Ця тема, мабуть, заслуговує на окрему статтю і, згідно з моїм досвідом, така поведінка пов'язана не лише з навичками ризик-менеджменту, а і з лідерськими якостями менеджера.

Що стосується постановки задач, антирейтинг найбільш дратівливих і, на жаль, найчастіших проколів керівників проектів очолюють порожні або недостатні описи задач. Понад 70 % респондентів зазначили цей пункт.

При цьому багато хто готовий пробачити менеджеру і граматичні помилки, і неправильне вживання термінів, але не відсутність зрозумілого викладу суті задачі. Разом із тим, більше половини респондентів зізналися, що величезний список дочірніх і пов'язаних задач теж навряд робить їх щасливішими, а роботу — простішою.

ЧАСТИНА ДРУГА. РЕФЛЕКСИВНА

Мабуть, тут я поділюся власним досвідом і не претендуватиму на абсолютне знання.

Задача має бути зрозумілою для того, хто її виконує та приймає, її формулювання має містити необхідний контекст і посилання на потрібні джерела, описувати тонкощі реалізації та підтримувати фокус команди. Після прочитання задачі людина має усвідомити, чого від неї хочуть, навіщо це потрібно проекту, та уявляти, як вона буде досягати результату, хоча б у першому наближенні. Якщо такого розуміння не виникло — імовірно, у нас проблеми.

Друге питання — наскільки за це відповідає керівник проекту. Залежно від фреймворку, який використовує менеджер, можливі різні сценарії та ступені розвитку самоорганізації в командах, і різні акценти на ролі РМА, зокрема його участі у постановці задач.

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

У справжніх Agile-командах роль РМ у звичному розумінні нівелюється. Agile говорить про цінності команди, здатної самоорганізуватися, поставивши собі досяжні й чіткі задачі самостійно. Навіщо такій команді керівник, що ставить і контролює задачі? Разом із тим, протиріч я не бачу.

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

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

  • Знання однієї людини завжди обмежені. Можна бути класним РМ, але твої колеги можуть мати більше досвіду в окремих сферах. Спираючись лише на свої знання, можна щось пропустити або повести команду не оптимальним шляхом.

  • Призначення задач зверху без обговорення виключає другу думку в команді, можливість проявити ініціативу іншими учасниками та може підірвати екологічність відносин.

  • Обмеження зростання команди. Ми зростаємо не лише коли беремо складні задачі, а й коли несемо за них відповідальність. Не даючи можливості цю відповідальність проявити, РМ обмежує розвиток команди.

РМ завжди є лідером проекту та, в кінцевому підсумку, відповідає за його доставку. Я дуже люблю термін ownership — він ємко відображає моє бачення відповідальності. Я глибоко переконана, що важливими факторами успіху будь-якого проекту є:

а) особиста відповідальність і залученість проджект-менеджера;

б) коректна постановка задач.

Зворотний зв'язок від моїх колишніх і нинішніх колег підтверджував і підтверджує: усі люблять бути на одній хвилі та в єдиному контексті. Без винятків для РМ.

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

Image

Ілюстрація автора статті

У моєму дитинстві був мультик про чортеня під номером 13. Кумедний такий мульт про перевернутий світ. А якби чортеня виросло, зрозуміло своє покликання і стало викладати у школі проджект-менеджерів? Мабуть, ось що воно могло б порадити своїм учням щодо постановки задач.

1. Пишіть довгі описи задач

Чим довше, тим краще! Не наш обов'язок — підтримувати фокус команди на головному. Краще написати все що можна і потім сказати: “О, я ж казав!” або “Ось тут внизу (бачите, де закреслено і потім дрібним шрифтом?) було написано...”.

2. А краще взагалі не пишіть

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

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

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

4. Що більше джерел правди, то краще

Більше джерел, більше! Стандарт вашого проекту має бути таким: дошка задач (можна й декілька, чого розмінюватись на дрібниці), Confluence, якийсь окремий документ у хмарному сховищі та, бажано, діаграма, яку ніхто й ніколи не оновлюватиме. Усі зміни вносите мовчки та абикуди. Справжній розробник має бути детективом: нехай покаже свої здібності — помучиться, але знайде всі необхідні вимоги та самостійно розв’яже всі конфлікти.

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

Якщо клієнт чи продакт-оунер поставили задачу в письмовому вигляді, ні в якому разі не аналізуйте її! Ви не бізнес-аналітик, ваше покликання — керувати, ваш обов'язок —питати: “Коли буде готово?!”.

6. Забудьте про критерії приймання та крайові сценарії

Це робота тестувальника. Або архітектора. Або бізнес-аналітика. У вашому проекті їх немає? Значить, розібратися доведеться розробнику. Хоча краще б клієнту самому про все подумати заздалегідь.

7. Не встановлюйте зв'язку задачі з епіком або пов'язаними компонентами

Всі й самі розуміють, про що йдеться. Якщо не розуміють — треба працювати над контекстом, все ж є у Jira!

Всі перераховані вище пункти, звісно, є не керівництвом до дії, а іронією та самоіронією з приводу наших помилок.

Текст висловлює особисту думку автора, відкритого і для печивка, і для тухлих помідорів.

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

  • Україна, Remote.UA; Україна, Дніпро; Україна, Київ; Україна, Львів; Україна, Одеса; Україна, Харків; Україна, Херсон
    18 листопада
  • Україна, Remote.UA; Україна, Дніпро; Україна, Київ; Україна, Львів; Україна, Одеса; Україна, Харків; Україна, Херсон
    1 липня
  • Україна, Дніпро; Україна, Київ; Україна, Львів; Україна, Одеса; Україна, Харків; Україна, Херсон
    25 червня
  • Україна, Одеса
    25 червня