Взаємодіючи із замовником та іншими стейкхолдерами, не треба покладатися на усні домовленості. Клієнт може попросити тебе швиденько додати одну невелику фічу в поточний реліз. Ти погодишся, але щось піде не за планом. Команда розфокусувалась, запланований обсяг робіт не виконано, зате фіча на проді. І пояснюй потім замовнику, що ми домовлялись про це на міті. Він може все заперечити одним лише питанням «Де це прописано?».
Тому все, що стосується графіку, бюджету, вимог до проєкту має бути зафіксованим, проаналізованим, погодженим із замовником та задокументованим.
Уяви ситуацію: проєкт із розробки CRM-системи. Ти в гарних стосунках із замовником, усе фіксуєш та плануєш. Замовник говорить: «Хочу функцію відслідковування кількості повідомлень у чатах». Ти відповідаєш: «Зробимо!». Через деякий час він знову: «Хочу модуль для підрахунку KPI працівників». Ти йому: «Уже запланував». І так кілька разів. У результаті, наче все погодили і зробили, але після релізу зрозуміло, що нікому ці функції не потрібні і ніхто ними не користується.
До вимог потрібно підходити прагматично. Не погоджуватись із кожною ідеєю замовника, а проводити аналіз і дослідження. Ставити питання: «Для чого вона нам?», «Кому вона буде корисна?», «Як вона наближає нас до цілей проєкту?» тощо.
Іноді хочеться якомога більше догодити клієнту, особливо, якщо ти в гарних стосунках із ним. Але твій альтруїзм може тебе погубити.
Якщо замовник гаряче просить розробити нову фічу за 5 днів, і навіть розробники дають приблизно таку ж часову оцінку, не погоджуйся. Скажи, що за твоїми розрахунками задача потребує 7 днів і не менше. Шанс зробити вчасно і залишитись «людиною слова» у цьому випадку буде вищим, ніж коли підеш на поступки і команда не вкладеться в дедлайн на 1 день.
Звичайно, ніхто не хоче смикати людину 10 разів на день різними запитаннями. Через це ловиш себе на думці: «Ну, тут і так усе зрозуміло. Навіщо когось чіпати». А потім виявляється, що у клієнта було зовсім інше бачення. І тепер потрібно безкоштовно переробити фічу.
Ми спираємося на особистий досвід. І те, що здається очевидним нам, може бути сумнівним для інших. Коли мова йде про проєкти, де помилка коштуватиме дуже дорого, кожне припущення потрібно перевіряти.
Коли Junior PM або BA приходить у нову команду, він не знає, що це за люди, які між ними стосунки, які в них сильні та слабкі сторони. Дехто може бути класним розробником, але краще розуміє графічне представлення вимог. Хтось, навпаки, може бути відмінним дизайнером, і розуміє, який макет сторінки потрібно зробити без зайвих слів. Але на старті ми цього не знаємо.
Безпечна стратегія – на початку вважати, що ніхто не вміє читати вимоги, і описувати їх максимально детально (за шаблоном, із блок-схемами, із зображеннями, якщо потрібно). У майбутньому ж ти зрозумієш особливості команди.
Професія PM відповідальна і вимагає управління командою професіоналів. Але Junior-спеціалісту буває досить складно керувати людьми з більшим досвідом. Великою помилкою буде прийти і відразу будувати внутрішні процеси та налагоджувати комунікацію.
Твоя перша задача – познайомитись із командою, зрозуміти як вона працює, за якими правилами, заручитись підтримкою формальних і неформальних лідерів. Не страшно зізнаватись у тому, що ти чогось не знаєш. Страшніше робити вигляд, що ти все знаєш. Тому будь чесним та став питання, якщо щось не зрозуміло.
Уяви ситуацію, коли PM контролює виконання кожної задачі, погоджує кожне рішення команди, присутній на кожному мітингу, перевіряє всю документацію на проєкті. Це справжнісінький жах.
Завдання PM – налаштувати процеси в команді так, щоб вони працювали автоматично, без його втручання. Якщо ти все правильно зробиш, то до тебе звернуться лише у випадку непередбаченої ситуації на проєкті.
Читай також: Кар’єра в ІТ: стань Project Manager’ом з нуля
Розширте свої знання на нашому повному курсі навчання fullstack в навчальному центрі Freshcode
GIT, HTML, CSS, JavaScript, TypeScript, Штучний інтелект, React, Redux, Linux, Node.js, PostgreSQL та MongoDB, Клієнт-серверна взаємодія, Docker, UNIT-тести, Спільна робота над проєктом, Індивідуальний проєкт.
Перейти
Розширте свої знання на нашому повному курсі навчання проєктному менеджменту в навчальному центрі Freshcode
Введення в ІТ, Технічна грамотність менеджера, Дослідження особливостей проєкту, Оцінка та планування задач, Контроль та реліз проєкту, Інструментарій розробника та штучний інтелект, Організація командної взаємодії, Закриття проєкту, Особливості продажів в ІТ.
Перейти