Баттл что должен и что не должен уметь менеджер
Прочитал в канале коллеги Петра Жаркова рассуждения о том, что должен уметь РП и что — не должен.
И сразу руки зачесались набить свои варианты ответа, ибо у меня получилось почти на все вопросы ответить примерно наоборот.
На самом деле, это — вполне нормально, так как:
во-первых, двух одинаковых РП — не бывает,
а во-вторых: работаем мы с Петром уж в слишком разных ландшафтах. Я — в крупной корпорации, а Петр — как раз-таки нет.
Так или иначе, инициирую дружеский баттл и предлагаю моим читателям решить, чей ответ кому ближе или может добавить свое мнение в комментариях.
Цитатой
оформлены ответы Петра
а знаком
✈️ — мои ответы.
А должен ли РП быть аналитиком?
на больших проектах — нет, а на маленьких, где он сам себе аналитик — да. Ибо как с заказчиком то договариваться по объемам? 🤷♂️
✈️ В больших проектах — нет, т. к. если он будет аналитиком — то упустит из фокуса менеджерские вопросы.
И еще будет сопровождать написанные собой ТЗ и иные документы уровня постановки задачи, а еще и участвовать в аналитических встречах.
Вместо менеджерских, разумеется.
Должен ли РП уметь писать ТЗ?
в больших компаниях для этого есть аналитики, но если компания небольшая, то желательно.
А уже если компания хочет при этом расти не разорившись на пути — почти обязательно.
✈️ В больших компаниях и больших проектах — это будет БТ (бизнес-требования), а от него уже будет N ТЗ.
РП уметь писать ТЗ не должен — слишком глубокий уровень детализации.
БТ менеджер должен уметь писать, чтобы уметь их прочитать и согласовать. Писать же в идеале должен аналитик.
Если РП не будет читать БТ или не увидит разницы между написанным и желаемым в проекте — его может настичь сильное разочарование где-нибудь на этапе тестирования.
А должен ли РП понимать в разработке?
В большом проекте — это только навредит, ибо проблемы должны решать ответственные.
В небольшом иногда очень помогает прийти поглядеть на АПИ и спросить, а нафига ребята так все усложняют, когда вот это сюды, это туды и вообще ребятушки, почему простейшее апи на 2 часа, а оценка в тикете у вас на 2 дня, расскажите, че как? 😎
✈️ Должен. По трем причинам:
1. Если он не понимает инструментарий — он не может валидировать оценку. А это приходится делать в том случае, если суммарная оценка всех приводит к реализации за границей дедлайна или бюджета.
2. Знание разработки защищает РП от манипуляций со стороны исполнителей вида «на лоха прокатит»
3. Позволяет предметно принимать участие в конструктивных дискуссиях, вида: можно ли упростить реализацию и сократить сроки без сильных потерь на стороне клиента? А вот этот функционал переносем как техдолг в следующий релиз.
Должен ли РП вести проектный план?
Вроде всегда должен, но вот и нет.
В небольшой компании Генеральному будет плевать на твои Гантты: ты сам помнишь свои дедлайны — ну и молодец, не грузи окружающих, главное — делай 👍
А в большой — обязательно должен.
✈️ Наоборот. В больших компаниях и больших проектах Gantt никто читать не будет, потому что это невозможно (сотни строк).
Top-менеджеры как раз будут смотреть на дорожные карты (ДК), из которых им понятно:
в плане проект или нет, есть ли ключевые риски их уровня и где им нужно вмешаться.
Будет ли РП «под капотом» вести план проекта (я — рекомендую) или он вполне может обойтись согласованной со всеми ДК — вопрос его предпочтений. Результат определит, насколько удачно он выбрал инструмент управления планом.
Должен ли РП уметь в риски?
на больших проектах — научится сам собой, потому что именно там учишься понимать фразу надо было подумать заранее» особенно остро 🙈
на небольших проектах весь список рисков помещается в голове, решается тамже, и вообще: фигня вопрос. главное ввязаться, а там как-нибудь выкрутимся 🔥
✈️ Да должен! Это и есть основной скилл РП.
Только в больших проектах рисков — сотни (иногда тысячи) и все их тщательно вести и тем более по одному митигировать — не выйдет.
И как раз в больших проектах работает принцип «главное ввязаться, а там — выкрутимся» и уделять внимание тем рискам, которые проект могут потопить или по которым нужно решение сверху. Остальные — закрыть самому или делегировать.
Должен ли РП знать ПМБоК?
На больших проектах — даже если знать не будет, то научится. Просто в какой-то момент станет ясно что вот они, домены пмбучные, оказывается, вот что они так назвали, ок.
А на маленьких — он суперизбыточен и вообще: пофигу ваш пмбук, лучше расскажите как из Ж О П и А написать СЧАСТЬЕ за три дня? 🥵
✈️ На больших проектах РП научится не PMBOK’у, а внедрять большие проекты в этом конкретном ландшафте.
В котором, о чудо, PMBOK знают единицы, а решения принимаются точно не исходя из него.
И да, написать СЧАСТЬЕ за три дня — это как раз свойство корпораций, потому что KPI, КПЭ, плюс пообещали тем, кого нельзя обмануть, да еще и от рынка надо не отстать, а лучше — опередить.
Должен ли быть полный стек документации по проекту?
так то должен , но полнота драматически зависит от размера проекта:
— на небольших достаточного простого ФТ или юзерсторей.
— на больших, реально больших, поневоле поймешь, что ГОСТы хорошие люди придумали, аж обнять хочется 🤗
✈️ На больших проектах в больших корпорациях работает принцип: «Лучше быть здоровым и богатым, чем бедным и больным».
И конечно, любой РП скажет, что он за подготовку максимального комплекта идеальной документации, да вот только сроки так поджимают, тут бы работающий MVP до прода довести.
Так что любой менеджер в начале проекта скажет, что он — за максимальную и удобную для всех документацию, а по факту получится та, на которую хватит ресурсов и времени.
Должны ли быть формализованные процессы в компании?
В большой компании — необходимы, потому что иначе хаос и хрень поймешь, что творится, а маленькой — вредят, потому что замедляют работу, а выяснить можно просто спросив ответственного 💯
✈️ Как раз в большой компании — работает принцип «спроси ответственного», потому что во-первых регламентов намного больше, чем человек может прочитать и тем более удержать в голове, а во-вторых регламенты чаще не успевают меняться под реальность, особенно с учетом затрат на их согласование.
А вот в малой компании, где ключевых людей — единицы, а вопросов, по которым к ним обращаются — бесконечное число, лучше все-таки создать базовые регламенты и правила игры и их придерживаться
===
Итак, чьи ответы тебе ближе или больше нравятся?
