Должен ли МП быть технарем?
Извечный вопрос: должен ли МП быть технарем, т.е. иметь опыт работы в качестве рядового аналитика, разработчика, тестировщика в ИТ? Чтобы наконец-то его для себя разрешить, попробую обновлять этот пост регулярно, пополняя наблюдениями с полей, подтверждающими или опровергающими эту гипотезу.
11.03.2014
Утро: новенький МП (выходец не-из-ИТ, но очень умный толковый человек) жаловался, что ему не хватает технического опыта: он не может принимать решения о ходе проекта, не понимая при этом работы членов команды.
Некоторые менеджеры в таком случае любят говорить: зачем технический опыт, ведь можно поспрашивать экспертов и сделать вывод на основе их мнений.
Я считаю:
Как МП обоснует этот подход и план работ заказчику, да и членам команды, если он не понимает:
Вечер: меня пытался залечить один опытный тестировщик, что тестирование проекта невозможно, и что ему нужна тьма времени на тестирование т.к. там недостаточно детально проработаны требования и тяжело сделать тестовые данные. При этом используя кучу профессионального жаргона и умных слов.
Если бы на моем месте был МП, не владеющий терминологией RUP и большим техническим опытом и знаниями, не знаю, чем бы это кончилось. Скорее всего МП бы отказался от идеи продать тестирование заказчику, т.к. слишком уж неоправданно высока была бы цена, а почему она такая объяснить бы он не смог. Заказчик бы покрутил и у виска. Тестировщик ушел бы довольный - МП бы пошел у него на поводу.
12.03.2014
Ни в одной методологии на МП не ложится ответственность за проект, если у него нет квалификации.
МП должен понимать заказчика - его термины и понятия. МП должен понимать команду.
МП не тех - либо заказчик увидит, что он не сечет, либо, что он никто. Уровень квалификации обратно пропорционально как часто звать эксперта.
16.03.2014
МП требуется планировать работы. А среду работ есть работы для программистов: создать такой-то компонент, другой, третий. И МП должен понимать, что это за компоненты, к каким фичам они относятся и соответственно эти работы распределять в плане. Хотя, конечно, если аккуратно ведется трассировка, то это превращается в почти механическую задачу. Но трассировку еще контролировать надо - как она ведется...
Или в SCRUM в-принципе все работы - фичи, понятные пользователю и тут как бы не надо быть тех. спецом. Но периодически возникают вопросы относительно не только фич, но и рефакторинга и KISS, и тут опять же надо понимать.
18.03.2014
Разработчик сказал, что не может продолжать работать над проектом, т.к. проект только начался и ему слишком тесно вместе с другим разработчиком в общей базе кода. МП принял взвешенное решение отложить подключение данного разработчика на 2 недели, чтобы была создана общая база кода. МП должен понимать как распараллелить задачи между разработчиками - покомпонентно.
27.06.2014
Подумалось следующее: мы хотим, чтобы менеджер проекта нес ответственность за проект. Что в частности означает, что он должен: 1) знать когда привлекать того или иного специалиста (аналитика, разработчика, тестировщика, архитектора и т.д.), значит он уже должен знать где кто нужен. 2) уметь на каком-то уровне проверить качество работы человека. Например, разработчики говорят, что аналитик плохо наанализировал - МП должен уметь понять, кто прав, кто виноват. Иначе придется вовлекаться функциональным руководителям, а может даже и директору.
Получается, что есть такой спектр силы: от менеджера до функционального руководителя. Чем сильнее менеджер, тем меньше нужен функциональный руководитель. На одной стороне шкалы сильный менеджер, который может в-принципе, весь проект делать сам, обаладает квалификацией всех своих подчиненных, но вынужден делегировать, т.к. он не может всё делать сам, но он может всё проверить, что те делают. Т.е. он делегирует рядовым, те просто как его рабочие руки. Но вся полнота власти остается за ним. Но есть еще функциональные руководители и им, наверное, делегируется проверка качества работы и обучение соответствующего специалиста: аналитика - начальник аналитиков, разработчика - начальник разработчиков и т.д. Но на приктике же вроде бы такого нет на заводах например?.. Там конечный результат контролирует тестировщик?..
Вообще, Мицберг про это дело пишет, что у проектного и функционального руководителя власть и ответственность примерно одинаковые. Возможно как раз по этой причине...
11.03.2014
Утро: новенький МП (выходец не-из-ИТ, но очень умный толковый человек) жаловался, что ему не хватает технического опыта: он не может принимать решения о ходе проекта, не понимая при этом работы членов команды.
Некоторые менеджеры в таком случае любят говорить: зачем технический опыт, ведь можно поспрашивать экспертов и сделать вывод на основе их мнений.
Я считаю:
- Если всегда спрашивать мнение эксперта, то зачем нужен МП? Если он всегда спрашивает мнение всех, то он либо коуч, обладающий техниками вытягивания решения из людей. Либо он секретарь, который выполняет функцию перенаправления потоков информации нужным лицам - умеет просто отделять какие вопросы к кому должны идти. Но ни в том, ни в другом случае он точно не должен тогда нести ответственности за проект - ни коуч, ни секретарь ответственности за решения, сделанные экспертами, не несут.
- Эксперты - люди узкой направленности и часто их немного на компанию. Они "пилятся" между многими проектами и не знают их контекст достаточно хорошо. А контекст часто играет важную роль.
- У экспертов мало времени и за каждым решением к ним не побегаешь.
- Практика практикой, а как говорит Талеб, платонизм никто не отменял: практика - штука обманчивая, можно очень легко связать причинно-следственной связью события, которые на самом деле ей не связаны. Нужен научный подход, а не интуитивный. А для научного подхода нужны хотя бы фундаментальные теоретические знания, а не практические.
Как МП обоснует этот подход и план работ заказчику, да и членам команды, если он не понимает:
- Почему сначала нужны юзкейсы (для того, чтобы мы не просто абстрактно исследовали интеграцию со сторонними сервисами, а фокусированно на нужных кейсах).
- Почему нужно сделать сначала прототип и проверить риски, а не делать все сразу (чтобы проверить и продумать архитектуру решения до того, как она уже солидно обрастет "мясом" и ее будет очень тяжело менять).
Вечер: меня пытался залечить один опытный тестировщик, что тестирование проекта невозможно, и что ему нужна тьма времени на тестирование т.к. там недостаточно детально проработаны требования и тяжело сделать тестовые данные. При этом используя кучу профессионального жаргона и умных слов.
Если бы на моем месте был МП, не владеющий терминологией RUP и большим техническим опытом и знаниями, не знаю, чем бы это кончилось. Скорее всего МП бы отказался от идеи продать тестирование заказчику, т.к. слишком уж неоправданно высока была бы цена, а почему она такая объяснить бы он не смог. Заказчик бы покрутил и у виска. Тестировщик ушел бы довольный - МП бы пошел у него на поводу.
12.03.2014
Ни в одной методологии на МП не ложится ответственность за проект, если у него нет квалификации.
МП должен понимать заказчика - его термины и понятия. МП должен понимать команду.
МП не тех - либо заказчик увидит, что он не сечет, либо, что он никто. Уровень квалификации обратно пропорционально как часто звать эксперта.
16.03.2014
МП требуется планировать работы. А среду работ есть работы для программистов: создать такой-то компонент, другой, третий. И МП должен понимать, что это за компоненты, к каким фичам они относятся и соответственно эти работы распределять в плане. Хотя, конечно, если аккуратно ведется трассировка, то это превращается в почти механическую задачу. Но трассировку еще контролировать надо - как она ведется...
Или в SCRUM в-принципе все работы - фичи, понятные пользователю и тут как бы не надо быть тех. спецом. Но периодически возникают вопросы относительно не только фич, но и рефакторинга и KISS, и тут опять же надо понимать.
18.03.2014
Разработчик сказал, что не может продолжать работать над проектом, т.к. проект только начался и ему слишком тесно вместе с другим разработчиком в общей базе кода. МП принял взвешенное решение отложить подключение данного разработчика на 2 недели, чтобы была создана общая база кода. МП должен понимать как распараллелить задачи между разработчиками - покомпонентно.
27.06.2014
Подумалось следующее: мы хотим, чтобы менеджер проекта нес ответственность за проект. Что в частности означает, что он должен: 1) знать когда привлекать того или иного специалиста (аналитика, разработчика, тестировщика, архитектора и т.д.), значит он уже должен знать где кто нужен. 2) уметь на каком-то уровне проверить качество работы человека. Например, разработчики говорят, что аналитик плохо наанализировал - МП должен уметь понять, кто прав, кто виноват. Иначе придется вовлекаться функциональным руководителям, а может даже и директору.
Получается, что есть такой спектр силы: от менеджера до функционального руководителя. Чем сильнее менеджер, тем меньше нужен функциональный руководитель. На одной стороне шкалы сильный менеджер, который может в-принципе, весь проект делать сам, обаладает квалификацией всех своих подчиненных, но вынужден делегировать, т.к. он не может всё делать сам, но он может всё проверить, что те делают. Т.е. он делегирует рядовым, те просто как его рабочие руки. Но вся полнота власти остается за ним. Но есть еще функциональные руководители и им, наверное, делегируется проверка качества работы и обучение соответствующего специалиста: аналитика - начальник аналитиков, разработчика - начальник разработчиков и т.д. Но на приктике же вроде бы такого нет на заводах например?.. Там конечный результат контролирует тестировщик?..
Вообще, Мицберг про это дело пишет, что у проектного и функционального руководителя власть и ответственность примерно одинаковые. Возможно как раз по этой причине...