Какое-то время назад были только программисты, которые сидели и писали программы. Многие программисты до сих пор считают, что так можно. Но тут есть проблема: если так делать, то программы не будет. Ведь, программисты сами по себе сложный программный продукт не делают. Потому что они программируют, а не следят за выпуском продукта.
На входе программисты получают техническое задание, а на выходе выдают программный код, который будет выполнять то, что написано в ТЗ. Все это выглядит хорошо и здорово, но, во-первых, технические задание должно быть кем-то составлено. Во-вторых, если в шестидесятых вы могли дать ТЗ и ждать результатов два-года, без видимых изменений, то в современном бизнес-мире такое невозможно. Если у вас ничего не изменилось за месяц, это уже говорит о застое и проблемах в бизнесе.Поэтому сейчас техническое задание меняется непрерывно.
Получается, что программисты получили технические задание, в которое вносятся правки со стороны заказчика каждые несколько дней. Какие-то части становятся важнее, какие-то просто выкидываются, какие-то добавляются. Значит или программисты должны работать с этим, то есть самостоятельно понимать, расставлять и менять приоритеты, или это должен делать кто-то другой.
Так и появились две роли — 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 все больше нужно представителей других областей, потому что очень многие бизнесы надо автоматизировать.
