Якийсь час назад були тільки програмісти, які сиділи і писали програми. Багато програмістів до сих пір вважають, що так можна. Але тут є проблема: якщо так робити, то програми не буде. Адже, програмісти самі по собі складний програмний продукт не роблять. Тому що вони програмують, а не стежать за випуском продукту.
На вході програмісти отримують технічне завдання, а на виході видають програмний код, який буде виконувати те, що написано в ТЗ. Все це виглядає добре і здорово, але, по-перше, технічне завдання повинно бути кимось складено. По-друге, якщо в шістдесятих ви могли дати ТЗ і чекати результатів два роки, без видимих змін, то в сучасному бізнес-світі таке неможливо. Якщо у вас нічого не змінилося за місяць, це вже говорить про застій і проблеми в бізнесе. Тому зараз технічне завдання змінюється безперервно.
Виходить, що програмісти отримали технічні завдання, в які вносяться правки з боку замовника кожні кілька днів. Якісь частини стають важливіші, якісь просто викидаються, якісь додаються. Значить або програмісти повинні працювати з цим, тобто самостійно розуміти, розставляти і міняти пріоритети, або це повинен робити хтось інший.
Так і з’явилися дві ролі – Project Manager і Product Owner. Project Manager отримує від замовника вхідні вимоги, оформлені, як правило, ніяк.
Project Manager повинен задати питання замовнику, зробити refining вимог, щоб передати формалізоване ТЗ команді. Project Manager повинен пояснити пріоритети, пограти зі Скоуп, тобто з об’ємом робіт, і головне – привести проект до фіналу. Якщо в тих же шістдесятих команда отримувала ТЗ, його імплементували, тестували і випускали, то зараз так не вийде. Правки надходять безперервно, і якщо чекати, що всі вимоги будуть виконані, проект в реліз вийде ніколи. Project Manager регулює обсяг робіт, стежить за тим, щоб команда не переоцінила свої сили і зробила його в строк, управляє ризиками, і багато іншого.
Project Owner – це хранитель інформації про продукт. В першу чергу його роль в тому, щоб бути decision-maker-му. І на нього ж зваляться всі шишки, якщо команда зробить не те, що потрібно бізнесу.
У діалогах з командою він представляє бізнес. Ця роль є джерелом інформації для Project Manager-а, тому що він говорить команді, що треба робити зараз, а що потім.
У багатьох компаніях Product Owner і Project Manager – це одна і та ж людина. Але це не правильно. Це конкуруючі ролі, як прокурор і адвокат. Project Manager грає на боці команди розробників. Він намагається зробити менше роботи, максимально стиснути Скоуп. Тоді як Product Owner виступає з боку замовника, з боку бізнесу. Він вимагає розширити Скоуп, додати завдання. Він розповідає, що саме потрібно, без чого не можна запуститися, а без чого можна обійтися.
Часто буває, що Product Owner – це представник замовника. Але в цьому випадку у нього виникає напруга з Product Manager-ом. Product Owner може ескаліровати проблеми керівництву, і тоді напруга починається вже між компаніями. Тому команди розробників швидко зрозуміли, що простіше тримати Product Owner-а в штаті. Тоді замовник бачить доброго і ласкавого Product Owner-а, а всі конфлікти з приводу Скоуп залишаються всередині.
Дуже часто Product Owner-а ще називають бізнес-аналітиком. Начебто це зовсім різні посади. Бізнес-аналітик аналізує бізнес і визначає, що з цього витягти. Але насправді бізнес-аналітик – це просто інша особа Product Owner-а. Product Owner це відповідальна особу для Project Manager, це людина, яка відповідає за сторону бізнесу і каже, що ми робимо, що немає. А для замовника це бізнес-аналітик.
Кому підходить ця робота? В першу чергу людям, які добре розбираються з бізнес-домені, тобто добре знають предметну область. Наприклад, якщо це медицина, підійде лікар або просто людина з медичною освітою. Він буде пояснювати розробникам, чому тут повинна бути саме ці дані, і як на це впливають результати УЗД. Ні програмісти, ні Project Manager цього самі не зрозуміють, тому що вони в цьому не розбираються. Якщо це роботи в галузі будівництва, непогано, щоб це була людина з досвідом роботи інженером виконробом, який знає, де яке рішення може підійти, тому що він знає, як цим будуть користуватися.
Кому за психотипом підійде ця робота? Людям уїдливим, які люблять розбиратися в деталях, які трохи перфекціоністи і не люблять, коли погано. Це він буде наполегливо вимагати, щоб ця кнопка була на один піксель більше, тому що незручно. А Project Manager буде з ним будується і вимагати, щоб ця вимога перенесли на наступні ітерації.
Це людина з аналітичним мисленням, кому важливо розібратися в усьому, залізти в усі внутрянка бізнесу, прорахувати навіть самі непередбачувані ситуації.
Ще непогані Product Owner-и виходять з тестувальників. Робота це почасти нагадує роботу тестувальника в плані рефайна вимог – він з’ясовує, що і як має працювати, чому, чи буде воно зручно, і чи дійсно вам воно треба.
Професій в IT величезна кількість, більшість з них програмуванням не займається. Це роблять тільки програмісти, devops-інженери і трошки automation QA. Решта програмуванням не займаються. І в IT все більше потрібно представників інших областей, бо дуже багато бізнесів треба автоматизувати.
