а чи готовий менеджер передати питання бюджету, управління очікуваннями, навчити команду управляти ризиками та самостійно вирішувати конфлікти?
Готовий. Якщо команда зможе все це робити без участі менеджера — отже менеджер ідеально виконує свою роботу.
і чи багато менеджерів хто на справді це вміє роботи?
Не знаю. Не проводив подібних досліджень. Але сумно, що ви стикаєтесь із такими.
бо звалювати все на «команда не готова», «розробники не зрілі» — це як визнання своєї некомпетентності
Тоді не працюйте з такими менеджерами. Не всі РМи компетентні і це правда. Проте не варто «натягувати» негативний досвід на всіх РМів.
А ще оці різні «коли буде готове? ну що там? вже зробив?»
Це приклад дуже поганого менеджементу — мікроменеджменту, про що і йдеться в статті. Мені прикро, що є менеджери чия робота обмежена питанням «ну шо там?».
ІМХО, в хорошій скіловій команді на нормальному проекті — РМ не потрібен, бо там і без нього все налагоджено та працює.
Згоден. Але аби все працювало і без РМа, хтось «все» має налаштувати. Повністю без РМа навряд чи вийде обійтись. Чи готова команда взяти на себе питання бюджету, ризиків, управління очікуваннями клієнта, вирішення конфліктів, контрактних питань тощо? Гадаю, що ні. Але команда може чудово створювати продукт без вказівок «як».
Мабуть дуже сіньйор ПМ може пропонувати міграції на інші технології, поки, що таких не бачив) Що мабуть підтверджує брак досвіду.
Головна ціль РМ побачити opportunity. Як я писав вище, РМ не самостійно визначає, що можна «кудись мігрувати».
Ніколи не приходила думка, що в різних компаніях обов’язки можуть відрізнятись? Те що у вас техлід не робить в іншій компанії може робити.
Так, в цій статті мова переважно про РМа. Хоча описане можна застосувати до будь-якої ролі.
Так, РМ іноді займається і розвитком бізнесу, і його робота не обмежена лише проектом. Більше того, якщо РМ заглиблений суто в проект і не розуміє бізнес-цінність продукту який створює команда, то може повести проект у хибному напрямку.
Зазвичай сіньйор РМи прають з клієнтом (аккаунтом) і розвивають бізнес в межах цього аккаунту (не одноосібно). Працюючи з клієнтом, РМ розуміє бізнес і може пропонувати додаткові сервіси (нові проекти), технічний аудит, рефайнмент процесів, міграцію на інші технології тощо. Це часто можна зустріти у великих аутсорсах.
Іноді все ж доводиться робити не лише те що до вподоби, а й те що необхідно.
1:1 мітинги має проводити безпосередній керівник, котрий безпосередньо працює з членом команди. Якщо у менеджера на проекті 5 команд, то він буде, вірогідно, працювати з техлідами/тімлідами/СМами, а не з кожним інженером окремо.
У менеджера можуть бути й інші обов’язки, зокрема: розвиток бізнесу в межах аккаунту, робота зі стейкхолдерами, робота з ризиками (особливо під час війни).
Мені сумно, що у вашому досвіді був менеджер робота якого обмежувалась питанням «ну шо там?»
Привілеї — це закріплені у корпоративній політиці правила поведінки.
А якщо ви вважаєте, що з вами вчинили несправедливо ви можете, посилаючись на ту ж корпоративну політику, поскаржитись на цей випадок несправедливої поведінки.
Не бачу тут «привілеїв», коли чоловікам надають виключне інституціолізоване право на кращі умови роботи, ніж жінкам.
Зрештою якщо ви знаєте компанії, де привілеї дійсно надано чоловікам — поділіться будь ласка, назвами таких компаній.
Можете навести приклад компанії в якій чоловікам надано привілейований статус?
Гадаю, що запровадження квот на певну групи людей (за будь-якими ознаками, не лише за статтю), обов’язково призведе до погіршення якості праці — так як підбір персоналу буде відбуватись за ознаками котрі непов’язані із виконанням задач на посаді.
Дуже гарне зауваження. Свіжий погляд це те чого іноді не вистачає в багтьох довготривалих проектах.
По-перше, жодних проблем не бачу.
По-друге,
часто відрізняється від того, що відбувається на практиці.
Повертаючись до суті питання: проблема про яку йдеться в статті не про те хто буде проводити 121 — TechLead чи TeamLead, а те як уникнути овертаймів і мікроменеджменту.
Половина статті це суб’єктивна думка, бо (там де нема посилань на дослідження) це опис досвіду. А досвід річ суб’єктивна. Погоджуватись чи не погоджуватись up to you. Ваш повчальний тон вважаю недоречним.