Comments 13
Ты знаешь, мне кажется, что тебе не хватает знаний работы с людьми. Переговоры, решение конфликтов, убеждение, мотивация и типология людей, как люди ведут себя, в каких ситуациях и почему именно так.
То есть требуется еще знания психологии. Но ведь какой нюанс — психология подразумевает два правила: культурные различия и быть «вне процесса».
Культурные различия — подразумевает что вы не должны судить только по своим критериям, но и должны знать чужие (особенно если "… иншааллах", говядина для индусов и т.д.).
Быть вне процесса — не ругатья с «ленивым программером», а смотреть как с ним ругается Пупкин.
Обучение психологии — лет пять учебного заведения.
Таким образом в нормальном мире — проектный менеджер будет готов лет после 15 обучения и некоторой практики :)
Или под Management Soft Skills — подразумевется нечто другое? Есть какой-то чеклист, тесты-сертификаты для Soft Skills?
Таким образом в нормальном мире — проектный менеджер будет готов лет после 15 обучения и некоторой практики :)
Ну, судя по всему, да. Такая же Байда с преподаванием, можно сколь угодно хорошо знать свой предмет, но без психологии, нормальной, от общей, до социальной, теории способностей и прочей полезной фигни, вкупе с методикой, хорошо сформулированной, по конкретному предмету, а не из разряда «делай так», только обдирать нерадивых клиентов получится, или просиживать штаны с неблагодарными тварями в универе)
А это мин. 15 лет + 2-5 лет на конкретную скилловую нишу в области своей проф компетентности. Зря, что ли на хабре столько статей за бездарный менеджмент?
UFO just landed and posted this here
На мой взгляд, задается (обозначается?) весьма интересная проблема: использование всяких PMBok (Scrum) это движени в сторону более формализированного общения и взаимодействия. Попытки минимизировать какие-то субъктивные критерии и мехнизмы в проектном управлении.
А после делается рекомендация — надо применять «Soft skill», а это движение ровно в противоположную сторону.
Что-то вроде «я тебя не буду бить ногами если ты ...»?
Не вижу разницы между «бить ногами физически» и «психологическим давлением» что бы вести проект внутри команды. Либо карты на стол и соблюдение условий с обеих сторон — или одна из сторон начинает «вооруженный нейтралитет».
Изначально это не верная стратегия (на мой взгляд), хотя иногда необходимое зло.
А после делается рекомендация — надо применять «Soft skill», а это движение ровно в противоположную сторону.
Что-то вроде «я тебя не буду бить ногами если ты ...»?
Не вижу разницы между «бить ногами физически» и «психологическим давлением» что бы вести проект внутри команды. Либо карты на стол и соблюдение условий с обеих сторон — или одна из сторон начинает «вооруженный нейтралитет».
Изначально это не верная стратегия (на мой взгляд), хотя иногда необходимое зло.
UFO just landed and posted this here
Вы же понимаете, что soft skills это общее название всего, что относится к взаимодействию с людьми? Это даже не вопрос менеджмента, это обязательное качество любого участника команды, просто менеджмент их более интенсивно использует.
Программисты между собой никак не общаются что бы код написать? или тестеры? или бухгалтера? А бизнес аналитикам общение не требуется? или все эти «ресурсы» между собой никак не общаются?
Возьмем к примеру такую «простую» штуку, как «Communication Plan» — документ регламентирующий процессы общения (кто, когда, о чем и как должен быть информирован) внутри команды\проекта.
Его же придумали по какой-то причине? Устав армейский, регламентирующий общение. Формализированные нотации (UML, IDFx, BPMN и т.д.)
В этом то все и дело.
Все человеческое общение сводится к первому шагу — общий словарь понятий (глоссарий). Не будет его — дальше не имеет смысла. Выделять какую-то группу "… их более интенсивно использует"? Это заблуждение.
Работа менеджера это именно коммуникации И настройка и поддержание процессов.
Мне больше нравится другое определение — менеджер, это человек который должен решать те проблемы, для которых еще нет решений (инструкций). Результат его работы — это инструкции, как поступать в некоторой ситуации, что бы достичь результата.
Для поддержания процесса — достаточно надсмотрищика или любой системы с движком бизнес процессов :)
Ни о каком «движении в противоположную сторону» речь не может идти от слова совсем.
Плодятся новые сущности (процессы), просто «потому что Soft Skills»? так это выглядит.
а помножил бы estimates на pi сразу и проблемы бы не было :)
А я не имел никакой власти над Дмитрием.
Т.е. у человека не было полномочий даже, какой же он менеджер?:)
По статье — воды много, результата мало. Тот же PMBoK, вид сверху. Там говорится: вот, возьмите шаблон процесса и всё будет идеально, здесь же — про Soft Skills, с тем же результатом, только даже без описания совершённых действий. Хотя в жизни всегда нужен баланс и учёт рисков. В каком-то проекте не критично будет просто задать план проекта, распределить роли и забыть про него (когда команда даже без тебя в состоянии не напрягаясь вытащить его, т.е. её навыки, как технические, так и «гибкие» достаточны или избыточны для этого проекта), в каком-то обсуждать и договариваться как внутри команды, так и за её пределами.
В этой ситуации я бы ещё в середине проекта (когда моя команда постоянно нарушает сроки, т.е. или не компетентна, или занята другими делами) привлёк аналитика (если самостоятельно не разбираюсь в данной технологии) + да, пообщался с другими руководителями, в чьих проектах моя команда также участвует сейчас.
Если проблема в компетенции, то обучение\замена команды\перенос сроков в соответствии с этим.
Если проблема в том, что команда занята на других проектах, то обсуждения\договоры\мотивация-демотивация\смена команды\согласование графика работ. Например, 3/2 — 2 дня человек мой, 3 дня нет.
Проблема ещё часто в том, что многие не учитывают снижение эффективности человека при переключениях (если 2 проекта, то до 30% рабочего времени, у некоторых больше, у некоторых меньше). И это также необходимо закладывать в календарные сроки.
Как определить, когда нужно подключать дополнительного аналитика или начать паниковать? В этом как раз помогает выстроенный процесс, наличие плана проекта и т.д. Т.е. управление — это не только Soft Skills или Hard Skills. Это скорее умение достичь результата используя сбалансированные ресурсы и инструменты (командные и личные качества и скиллы\шаблоны\процессы).
А что в итоге сделали-то? Так подробно к этому подводили, аж на две части растянули, а по сути только общий вывод даже без примеров…
«- Вовочка, расскажи нам про верблюдов!
- Ну, верблюды живут в Африке...
- А суть-то, суть?
- А суть они под пальмы!»
Мда. Я ждал 2-ой части но это просто фиаско. Само собой выражение — "я попробую" не приемлемо. Советую автору почитать "Законы победителей" Бодо Шефер. Там как раз рассказывается о том, что значит эта безтолковая фраза. По большей части то, с чем столкнулся автор — это обычные ничем не замотивированные офисные лентяи. Тут хорошо могла бы помочь известная книга "Бесжалостный менеджмент". Ибо автор был руководителем но не считал себя сам таковым.
Добрый день!
Очень хотелось бы увидеть третью часть с подробным описанием, как и что делал ваш друг :)
Первые две части были отличным вступлением.
А в целом то, что не хватает полномочий — это норма для менеджеров проектов.
В таком случае можно сделать так:
1. Коммит от нач. отделов по срокам его подчинённых. Можно и перед заказчиком.
Это справедливо — разделять ответственность с владельцем ресурсов. Часто нач. отделов не беспокоит, чем его подчинённые заняты если не прилетает эскалаций и «все тихо».
2. Разбивка задачи на более мелкие с расстановкой промежуточных вех и коммиты под них от исполнителей.
Работа занимает всё отведённое на неё время. (с) Паркинсон.
Проваливают строки = эскалация в мягкой форме, пытаетесь договориться о SLA и за чей счёт дальше гуляем. Далее по ситуации.
3. Понять на сколько интересен проект исполнителям, если не интересен, то попробовать изменить на тех, кому интересен.
Казалось бы, банально, но часто рядовых гребцов даже не спрашивают, что они хотят и кто бы их мог заменить.
Из «софт» составляющей:
1. Налаживать рабочие отношения с нач. отделами.
2. Перенимать авторитет заказчика и заинтересованных лиц в проекте (если он — авторитет есть).
3. Налаживать рабочие отношения с исполнителями.
Менее формально артефакты PMI (PMBoK) можно составить так:
Устав проекта = договорённости с заинтересованными лицами и исполнителями, можно устно и в почте подкрепить договорённости: как, кто и что будет делать для проекта.
План управления проектом = аналогично как с уставом, можно на берегу или в процессе договориться с членами команд:
1) Что делать если заказчик меняет скоуп проекта.
2) Что делать если исполнитель ошибся с оценкой.
3) Что делать если исполнитель не выполнил согласованные работы в срок.
и т.п.
Два артефакта могут по ходу изменяться или наполняться новыми договорённостями, это не отлитые в бетон вещи.
Всё достаточно банально и не претендую на полноту, но сила в простых вещах.
Очень хотелось бы увидеть третью часть с подробным описанием, как и что делал ваш друг :)
Первые две части были отличным вступлением.
А в целом то, что не хватает полномочий — это норма для менеджеров проектов.
В таком случае можно сделать так:
1. Коммит от нач. отделов по срокам его подчинённых. Можно и перед заказчиком.
Это справедливо — разделять ответственность с владельцем ресурсов. Часто нач. отделов не беспокоит, чем его подчинённые заняты если не прилетает эскалаций и «все тихо».
2. Разбивка задачи на более мелкие с расстановкой промежуточных вех и коммиты под них от исполнителей.
Работа занимает всё отведённое на неё время. (с) Паркинсон.
Проваливают строки = эскалация в мягкой форме, пытаетесь договориться о SLA и за чей счёт дальше гуляем. Далее по ситуации.
3. Понять на сколько интересен проект исполнителям, если не интересен, то попробовать изменить на тех, кому интересен.
Казалось бы, банально, но часто рядовых гребцов даже не спрашивают, что они хотят и кто бы их мог заменить.
Из «софт» составляющей:
1. Налаживать рабочие отношения с нач. отделами.
2. Перенимать авторитет заказчика и заинтересованных лиц в проекте (если он — авторитет есть).
3. Налаживать рабочие отношения с исполнителями.
Менее формально артефакты PMI (PMBoK) можно составить так:
Устав проекта = договорённости с заинтересованными лицами и исполнителями, можно устно и в почте подкрепить договорённости: как, кто и что будет делать для проекта.
План управления проектом = аналогично как с уставом, можно на берегу или в процессе договориться с членами команд:
1) Что делать если заказчик меняет скоуп проекта.
2) Что делать если исполнитель ошибся с оценкой.
3) Что делать если исполнитель не выполнил согласованные работы в срок.
и т.п.
Два артефакта могут по ходу изменяться или наполняться новыми договорённостями, это не отлитые в бетон вещи.
Всё достаточно банально и не претендую на полноту, но сила в простых вещах.
Уважаемые читатели. Подозреваю, что вы искали в этой статье очередную серебряную пулю в стиле «сделай вот так и еще вот эдак и любой проект будет у тебя успешен». Увы, вынужден огорчить. Менеджмент так не работает. Хотя в этом есть и хорошая сторона. Если бы он работал по принципу «если… то...» — тогда руководителя проектов запросто мог бы заменять скрипт. К счастью, вероятность того, что в ближайшие 10-15 лет нормального и обученного руководителя заменит нейросеть или искусственный интеллект всего 3,5% процента. И это значит, что нестандартные задачи, связанные с управлением людьми — крайне трудно алгоритмизируются.
Многие из комментаторов сразу же бросаются решать описанную ситуацию, рассказывая что-то вроде «да я бы...». Возможно вы правы. Возможно, ваш вариант бы сработал. Возможно. Дьявол в деталях. Не бывает ни одного похожего проекта и в каждом слишком много тонкостей.
Спорить про определения, «что такое soft skills» просто не имеет смысла. В блоге на сайте компании есть статья с одноименным названием. Там написано то, как мы понимаем этот термин и что с ним делать.
Очевидно, что у героя статьи не хватало множество навыков руководителя. И я уверен, многие начинающие менеджеры попадали в похожие ситуации. Если же данная статья поможет им не наступать на подобные грабли и почитать некоторые книги, статьи или сходить поучиться управлению проектами — то польза от статьи уже есть.
И еще раз напомню, что в менеджменте не бывает серебряных пуль. Не бывает однозначных решений, особенно там, где ключевой фактор успеха проекта — это команда. Люди.
Успехов вам в ваших проектах!
Многие из комментаторов сразу же бросаются решать описанную ситуацию, рассказывая что-то вроде «да я бы...». Возможно вы правы. Возможно, ваш вариант бы сработал. Возможно. Дьявол в деталях. Не бывает ни одного похожего проекта и в каждом слишком много тонкостей.
Спорить про определения, «что такое soft skills» просто не имеет смысла. В блоге на сайте компании есть статья с одноименным названием. Там написано то, как мы понимаем этот термин и что с ним делать.
Очевидно, что у героя статьи не хватало множество навыков руководителя. И я уверен, многие начинающие менеджеры попадали в похожие ситуации. Если же данная статья поможет им не наступать на подобные грабли и почитать некоторые книги, статьи или сходить поучиться управлению проектами — то польза от статьи уже есть.
И еще раз напомню, что в менеджменте не бывает серебряных пуль. Не бывает однозначных решений, особенно там, где ключевой фактор успеха проекта — это команда. Люди.
Успехов вам в ваших проектах!
Sign up to leave a comment.
Путь IT-менеджера (часть #2)