Баттл что должен и что не должен уметь менеджер

Баттл что должен и что не должен уметь менеджер

Прочитал в канале коллеги Петра Жаркова рассуждения о том, что должен уметь РП и что - не должен.
И сразу руки зачесались набить свои варианты ответа, ибо у меня получилось почти на все вопросы ответить примерно наоборот.

На самом деле, это - вполне нормально, так как:
во-первых, двух одинаковых РП - не бывает,
а во-вторых: работаем мы с Петром уж в слишком разных ландшафтах. Я - в крупной корпорации, а Петр - как раз-таки нет.

Так или иначе, инициирую дружеский баттл и предлагаю моим читателям решить, чей ответ кому ближе или может добавить свое мнение в комментариях.

Цитатой

оформлены ответы Петра

а знаком
✈️ - мои ответы.

А должен ли РП быть аналитиком?
на больших проектах – нет, а на маленьких, где он сам себе аналитик – да. Ибо как с заказчиком то договариваться по объемам? 🤷‍♂️

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

Должен ли РП уметь писать ТЗ?в больших компаниях для этого есть аналитики, но если компания небольшая, то желательно.
А уже если компания хочет при этом расти не разорившись на пути – почти обязательно.

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

А должен ли РП понимать в разработке?
В большом проекте - это только навредит, ибо проблемы должны решать ответственные.
В небольшом иногда очень помогает прийти поглядеть на АПИ и спросить, а нафига ребята так все усложняют, когда вот это сюды, это туды и вообще ребятушки, почему простейшее апи на 2 часа, а оценка в тикете у вас на 2 дня, расскажите, че как? 😎

✈️ Должен. По трем причинам:
1. Если он не понимает инструментарий - он не может валидировать оценку. А это приходится делать в том случае, если суммарная оценка всех приводит к реализации за границей дедлайна или бюджета.
2. Знание разработки защищает РП от манипуляций со стороны исполнителей вида "на лоха прокатит"
3. позволяет предметно принимать участие в конструктивных дискуссиях, вида: можно ли упростить реализацию и сократить сроки без сильных потерь на стороне клиента? А вот этот функционал переносем как техдолг в следующий релиз.

Должен ли РП вести проектный план?
Вроде всегда должен, но вот и нет.
В небольшой компании Генеральному будет плевать на твои Гантты: ты сам помнишь свои дедлайны – ну и молодец, не грузи окружающих, главное - делай 👍
А в большой - обязательно должен.

✈️ Наоборот. В больших компаниях и больших проектах Gantt никто читать не будет, потому что это невозможно (сотни строк).
Top-менеджеры как раз будут смотреть на дорожные карты (ДК), из которых им понятно:
в плане проект или нет, есть ли ключевые риски их уровня и где им нужно вмешаться.
Будет ли РП "под капотом" вести план проекта (я - рекомендую) или он вполне может обойтись согласованной со всеми ДК - вопрос его предпочтений. Результат определит, насколько удачно он выбрал инструмент управления планом.

Должен ли РП уметь в риски?

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

✈️ Да должен! Это и есть основной скилл РП.
Только в больших проектах рисков - сотни (иногда тысячи) и все их тщательно вести и тем более по одному митигировать - не выйдет.
И как раз в больших проектах работает принцип "главное ввязаться, а там - выкрутимся" и уделять внимание тем рискам, которые проект могут потопить или по которым нужно решение сверху. Остальные - закрыть сам или делегировать.

Должен ли РП знать ПМБоК?
На больших проектах – даже если знать не будет, то научится. Просто в какой-то момент станет ясно что вот они, домены пмбучные, оказывается, вот что они так назвали, ок.
А на маленьких - он суперизбыточен и вообще: пофигу ваш пмбук, лучше расскажите как из Ж О П и А написать СЧАСТЬЕ за три дня? 🥵

✈️ На больших проектах РП научится не PMBOK'у, а внедрять большие проекты в этом конкретном ландшафте.
В котором, о чудо, PMBOK знают единицы, а решения принимаются точно не исходя из него.
И да, написать СЧАСТЬЕ за три дня - это как раз свойство корпораций, потому что KPI, КПЭ, плюс пообещали тем, кого нельзя обмануть, да еще и от рынка надо не отстать, а лучше - опередить.

Должен ли быть полный стек документации по проекту?так то должен , но полнота драматически зависит от размера проекта:
- на небольших достаточного простого ФТ или юзерсторей.
- на больших, реально больших, поневоле поймешь, что ГОСТы хорошие люди придумали, аж обнять хочется 🤗

✈️ На больших проектах в больших корпорациях работает принцип: "Лучше быть здоровым и богатым, чем бедным и больным".
И конечно, любой РП скажет, что он за подготовку максимального комплекта идеальной документации, да вот только сроки так поджимают, тут бы работающий MVP до прода довести.

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

✈️ Как раз в большой компании - работает принцип "спроси ответственного", потому что во-первых регламентов намного больше, чем человек может прочитать и тем более удержать в голове, а во-вторых регламенты чаще не успевают меняться под реальность, особенно с учетом затрат на их согласование.
А вот в малой компании, где ключевых людей - единицы, а вопросов, по которым к ним обращаются - бесконечное число, лучше все-таки создать базовые регламенты и правила игры и их придерживаться

===
Итак, чьи ответы тебе ближе или больше нравятся?