...и должен ли РП уметь писать ТЗ?

Этому холивару, по-моему, ровно столько же лет, сколько лет проектному управлению в IT.

Границы управления проектами просты: инициация - планирование – исполнение – завершение. Это знает даже джун. Сделай устав, план, делай статусы каждую неделю, а потом проведи финальный показ функционала – и твой проект ждет успех. Все так, правда?

Неправда, так не получается. Оказывается, надо провести нормальный сбор требований на базе качественной постановки задачи, сделать качественное ТЗ, затем сделать детальные спецификации, которые потом разложить в to do на разработку и так далее, и так далее.

Для этого есть соответствующие люди. Должны быть. Но они есть не всегда. Или они есть, но они не обладают достаточной квалификацией. И вот тут начинается «серая зона» ответственности РП, где его может выручить умение в «бизнес-аналитику».  Ну или где РП может гордо сказать, что задач по аналитике нет в его должностной инструкции и пусть все идут нафиг, он не нанимался.

Это очередная статья о том, чего не рассказывают на курсах РП: о навыках, которые потребуются Руководителю проектов с самого первого дня работы. Если вам интересны такие истории, читайте другие мои статьи на Хабре и подписывайтесь на мой ТГ канал "Морковка спереди, морковка сзади".

Я не буду здесь говорить про огромные проекты, где есть проектный офис и должен быть РП-методолог, который нужен исключительно для выстраивания проектных процессов и контроля их исполнения. Таких проектов относительно мало. Большинство проектов ведутся по методологии, которая уже есть в компании (кстати, отсутствие методологии тоже является методологией) и там методологов нет. Зато есть многорукие РП, которых часто грузят аналитикой непонятно зачем.

Дальше я объясню, как так выходит, что теоретически верное распределение ответственности Руководитель проекта – Бизнес-аналитик не выполняется в реальной жизни и как с этим дальше жить.

Заодно, господа менеджеры – почитайте и поглядите, что именно будет вас ждать на вашем новом месте работы, о таком обычно не рассказывают на собеседованиях ?

Для понимания, когда от РП требуется превращаться в аналитика, надо поглядеть, что должно происходить в работе РП в теории, и что реально происходит на практике. Как уже раньше писал, имеет смысл рассматривать три типа РПшников: продуктовые, внутренние и внешние. Поехали)

Продуктовый Руководитель проектов

1. Теоретический:

   1. Продакт ставит ему задачу на разработку, выступая и как аналитик, и как заказчик.

   2. Проджект отвечает за ее доведения до продакшена.

   3. Если задача большая, привлекается аналитик, который на основании общей постановки от продакта делает детальную постановку на разработку.

   4. РП в данном случае – техническая функция по согласованию времени релизов разными командами.

2. Реальный:

   1. Продакта нет или у него не хватает времени детализировать. Аналитика вам не набрали, а пока «надо подхватить работу самому».

   2. А еще надо релизить фичи, затрагивающие несколько внутренних и внешних команд, и надо очень точно понимать очередность выкладки доработок. А для этого надо точно знать: что, для чего и куда добавляется (а этого без понимания техники не сделать).

   3. А еще одна из команд срывает сроки поставки, и весь ваш план релиза идет по бороде, и надо срочно придумывать, как быть, и есть ли вариант частичного релиза под фича флагами и тд. И придумывать придется вам: аналитика нет, своей команды нет, и крайний именно вы. Вот тут понадобится стать на время аналитико-менеджером, поговорить с архитектором, поговорить с лидами команд и, в зависимости от техники, сделать новый план релиза.

Итого: Продуктовый РП должен понимать систему на уровне неплохого аналитика, иначе ему будет сложно принимать быстрые и точные решения, а во многих компаниях чистый администратор вообще не приживется (ибо зачем он, когда столько техники).

Внутренний Руководитель проектов

1. Теоретический:

   1. Бизнес ему отгружает Функциональные требования.

   2. РП передает их во внутреннюю команду или подрядчику.

   3. Те делают из ФТ ТЗ, приносят вам понятную смету, план или КП, РП ее согласует, и проект поехал.

   4. Далее, если есть сложности – их решает ваш внутренний аналитик или сам подрядчик (ну а для чего иначе он нужен вообще?)

2. Реальный:

   1. Аналитика вам не дали – он перегружен на других критичных работах или его вообще нет – иди с подрядчиком договаривайся.

   2. Внутренняя команда освободится только через полгода: «вас много, а я одна» и вообще идите-ка вы все в беклог!

   3. Подрядчик при виде вашего ФТ презрительно морщится и отказывается по такому г… работать, особенно при тех сроках, которые вы озвучили.

   4. Выбранный в итоге подрядчик хочет вас надурить, предоставляя завышенные сметы на работы или пытаясь сдать неработающую систему, да еще постоянно ноет, что все выполнено по ТЗ (которое вы в глаза не видели, понадеявшись на чужой профессионализм).

   5. Тут вас тыкают морковками вообще со всех сторон:

      1. Бизнес – за то что вы нифига не можете сделать работу.

      2. Подрядчик – за то что вы нифига не можете сделать с безумным заказчиком.

      3. Ваш Руководитель – за то, что не смогли заранее увидеть проблему между бизнесом и подрядчиком (и ему плевать, что аналитика нет, он то как-то без аналитика справляется!)

   6. Вот тут бы и надо стать на время аналитиком-продуктологом, послушать ваш бизнес, понять, что действительно они хотят и какие метрики важны, самому проверить, что в ФТ это описано, самому проверить (да-да ребятушки, самому), что это есть в ТЗ, а потом вместе с исполнителями проверить, что критичные фичи для бизнеса готовы. И показать вашему бизнесу именно то, чего он ждет.

Итого: Внутреннему РП надо быть немного продактом и немного аналитиком, если он хочет, чтобы его не тыкали морковками в разные неподходящие места).

К сожалению, я вижу очень много внутренних РП, которые устраняются от этой работы, превращаясь просто в администраторов. Ребят, вам же самим потом будет Очень больно, читайте ТЗ и понимайте, о чем там речь.

Внешний Руководитель проектов

1. Теоретический:

   1. Заказчик приходит к нему с понятным ФТ или даже ТЗ, в котором описаны все процессы подлежащие автоматизации, все потоки информации и бла бла бла.

   2. Его аналитик детализирует все в задачи для команды.

   3. Его QA все это тестирует и потом сдает заказчику совместно с аналитиком.

   4. Все хлопают в ладоши, а РП идет в банкомат за премией.

2. Реальный:

   1. К вам приходит сейлз с просьбой помочь заказчику сформулировать проблему. ТЗ нет, ФТ нет, заказчик понятия не имеет, чего хочет, бюджета на аналитику нет, но надо «сделать это по быстрому». Вот тут вам пригодится навык аналитика первый раз: быстро понять, что надо, отрисовать на коленке схемку процесса и согласовать подход с бизнесом заказчика. Это пресейл.

   2. Дальше на основании сделанного «по быстрому» ФТ вам дают аналитика на три дня (инвестбюджет нерезиновый) для написания «простого ТЗ» в помощь заказчику, у которого ресурсов на написание тоже нет. А ваш аналитик говорит, что ему надо 2 недели. Но 2 недели у вас нет, а денег для компании заработать хотелось бы. Вот тут пригодится навык «сесть и написать ТЗ за три дня», которое потом вы вместе с лидом разработки декомпозируете в работу. Да, методологически это неправильно. Зато быстро. А скорость на пресейле решает практически всегда.

   3. Вы пришли в компанию, где нет культуры разработки и люди не знают, что такое ТЗ. Им надо все это объяснить, найти хороший шаблон и научить делать. Да, так тоже бывает. Вот тут понадобится побыть аналитиком: найти шаблон и пояснить новичкам аналитикам, что, где и зачем должно быть написано.

   4. На сдаче-приемке заказчик начинает ругаться, аналитик и QA не могут ответить и надо их поддержать. Тут понадобится то, что вы делали в первом пункте выше: встать и напомнить заказчику, о чем договаривались. А для этого надо самому договариваться по критичным функциям.

   5. Ну и я молчу про кучу технических проблем, возникающих по ходу проекта, когда и аналитики, и разработчики будут разводить руками и звать именно вас для разрешения их спора. И для этого тоже понадобиться вникать в технику.

Итого: внешний РП не умеющий на коленке написать ТЗ — это, максимум, миддл. Этому придется учиться. А РП не умеющий разобраться в технике – просто администратор проектов с соответствующей зарплатой.

А есть еще небольшие проекты, где невыгодно держать фул-тайм аналитика и фултайм менеджера, а выгодно как раз смешать обе роли.

Так надо или нет РП становиться аналитиком?

На 100% становиться им не нужно, но во всех трех возможных ролях РП требуется навык им побыть, чтобы понять

• что за фичу он делает (он = его команда);

• зачем она бизнесу;

• как она работает (необязательно до названия поля в БД, но на уровне обмена параметрами – надо);

• решить сопутствующие проблемы.

Вы можете всего этого не знать искать такое место, которое максимально близко к идеальному, но:

А) Таких мест исчезающе мало.

Б) Там тоже все может пойти не по плану: аналитик ушел/занят/надо срочно, заказчик просит лично вас. И все равно придется вникать.

Так что по всему этот навык лучше иметь, чем не иметь.

А дальше уже вопрос соблюдения баланса между работой РП и Аналитика и слежения за тем, чтобы вам не сели на шею. Такое тоже легко может случиться, если вы молча взяли на себя две роли и тащите их на одной зарплате. Такие работники очень выгодны компании, но не надо в такое превращаться, это win-lose, а мы тут топим за win-win.

Поэтому учитесь в бизнес-анализ и ставить границы. И то и то пригодится.