Льоша влаштувався працювати продактом в одну цікаву компанію. Льоша розуміє як влаштований процес і як генерувати гіпотези для зростання метрик. Але Льоша нічого не розуміє в управлінні проєктами: не може нормально спланувати реліз фічі, не розуміє, кого треба залучити із зацікавлених сторін, який образ результату тощо.
У реальності таких Льош на ринку відсотків 80. Тобто, знання продуктової частини може бути цілком собі непоганим, але з плануванням і реалізацією проблеми.
Життя не справедливе, чому так?!
Тому що люди в продукт приходять із різних галузей. Хтось із маркетингу, хтось із розробки, хтось хз звідки ще. Багаж знань різний, не факт, що ти з проєктного управління вийшов, а отже, і скілів немає.
Але постривай, цього ж можна навчитися?
Так, але ні на практиці. Тому що всі освітні продуктові програми дають саме шматок продуктовий: фічі, метрики, методології та інше. Проєктна частина нібито мається на увазі по-дефолту. Це ж отже всі знають, що треба управляти очікуваннями, планувати, чекати прогрес і прикидати ризики…
Знають, але не роблять. Мовчать, але не застосовують. А далі ми отримуємо хаос, завдання, що злітають із плану, і підсмажену попку на грилі.
(◕‿◕) Ми у Telegram: Анонси нових статей та бонусні матеріали
Особливо відсутність проєктних навичок спостерігається на завданнях масштабу “більше, ніж спринт”. Залежності, зв’язки, координація різних команд, ось де починається фарш.
І що робити?
Круто зганяти повчитися на якийсь інтенсив. Або самостійно вивчити проєктні практики через статейки, відео і розмови з чинними проєктними експертами.
А якщо зовсім ліньки мені?
Мені теж, тому я намагаюся прогнати соковиту задачку через невеликий список запитань:
- Навіщо? Яку проблему вирішує завдання?
- Що? Яка мета? Що буде на виході? Цифри?
- Як? Як прийдемо до рішення? Які варіанти рішень? Які основні етапи та віхи?
- Хто? Хто буде робити? Кого зачіпає? Хто зацікавлені особи? Хто приймає фінальне рішення?
Шліфуємо відповіді на ці запитання блоком про вимоги, терміни, ризики, ресурси.
Що важливо
Що, відповідаючи на запитання в шаблончику, ви себе дисциплінуєте й отримуєте на виході очікуваний результат.
І так, не варто засмучуватися, якщо проєктних навичок у вас немає. Нещодавно був на навчанні топменеджменту з купою “великих” людей, побачив, що і там багатьом подібних знань явно не вистачає. Тому беремо шаблон і прокачуємося. Якщо зверху статті та відео, то вогонь. А, якщо повчитися ще куди підете, то взагалі бомба.
P.S. Чек-лист проєкту трохи перетинається з моїм брифом на завдання і непогано його доповнює. Може в майбутньому докручу бриф до версії 2.0, де будуть обидва шматки. А ось, як виглядає його поточна версія.
- Анотація, короткий опис завдання
- Терміни, коли хочемо реалізувати
- Яке завдання/проблему користувача вирішує реалізація завдання?
- Як це завдання/проблема вирішується зараз? Чи є поточне рішення?
- Користувацький сценарій, як з боку користувача виглядає рішення, опишіть по кроках
- Цільова аудиторія, для кого
- Аналітика, що будемо міряти
- Який період виміру даних? Скільки часу треба для заміру
- Які показники вважати успішними? Який образ результату
- Дизайн, який вигляд матиме рішення
- Конфіг, чи потрібно щось налаштовувати, вимикати/вмикати без релізу
- Критерії готовності
- код перевірений (код рев’ю)
- функціональні тести пройдено
- верстка відповідає макетам (дизайн рев’ю)
- є розмітка по SEO (для WEB)
- є лічильники аналітики та розмітка подій
- є короткий опис-документація в базі знань
- завдання прийнято PO
