Уважаемые читатели. Подозреваю, что вы искали в этой статье очередную серебряную пулю в стиле «сделай вот так и еще вот эдак и любой проект будет у тебя успешен». Увы, вынужден огорчить. Менеджмент так не работает. Хотя в этом есть и хорошая сторона. Если бы он работал по принципу «если… то...» — тогда руководителя проектов запросто мог бы заменять скрипт. К счастью, вероятность того, что в ближайшие 10-15 лет нормального и обученного руководителя заменит нейросеть или искусственный интеллект всего 3,5% процента. И это значит, что нестандартные задачи, связанные с управлением людьми — крайне трудно алгоритмизируются.
Многие из комментаторов сразу же бросаются решать описанную ситуацию, рассказывая что-то вроде «да я бы...». Возможно вы правы. Возможно, ваш вариант бы сработал. Возможно. Дьявол в деталях. Не бывает ни одного похожего проекта и в каждом слишком много тонкостей.
Спорить про определения, «что такое soft skills» просто не имеет смысла. В блоге на сайте компании есть статья с одноименным названием. Там написано то, как мы понимаем этот термин и что с ним делать.
Очевидно, что у героя статьи не хватало множество навыков руководителя. И я уверен, многие начинающие менеджеры попадали в похожие ситуации. Если же данная статья поможет им не наступать на подобные грабли и почитать некоторые книги, статьи или сходить поучиться управлению проектами — то польза от статьи уже есть.
И еще раз напомню, что в менеджменте не бывает серебряных пуль. Не бывает однозначных решений, особенно там, где ключевой фактор успеха проекта — это команда. Люди.
Любимая тема — переводить вопросы ответственности в плоскость мотивации и дисциплины.
За задачу должен отвечать один человек, и не только нести ответственность, но и быть способным сделать задачу. В некоторых случаях (конечно же в придуманных мною :) ) оказывается так, что за некоторые части одной задачи отвечают разные люди. А за сборку частей в целое вообще не отвечает никто. И вот то, что у этих частей никак не получается сыграть в упомянутый Вами «Квартер» — виновато отсутствие у частей мотивации и только в этом причина.
К сожалению, я не могу согласиться с такой точкой зрения. Она загубила множество хороших проектов, команда, и карьер. Одно из работающих решений, как избежать размазывания ответственности — описано в статье.
И вот еще один момент: многие руководители любят придумывать разные позиции и должности, лишь бы как-то мотивировать своих подчиненных красивым «шильдиком», красивым названием должности. Мол, а давайте назовем Team Lead'а Руководителем проектов. Это же круче звучит. И никого совсем не беспокоит, что круг обязанностей такого свежеиспеченного руководителя проектов сильно не дотягивает до стандартного, описанного во многих методологиях. Частично еще и по этой причине находятся люди, не видящие разницы между приведенными в статье схемами.
Судя по Вашим комментариям, я не смог донести в своей статье то, что пытался. И диаграммы 1 и 3 не одинаковые.
Мне только немного удивительно, т.к. статья про зоны ответственности, а Вы не довольны названиями должностей. Ну значит будем считать, что с названиями я ошибся. Главное, что у вас все хорошо — и желаю Вам, чтобы так и оставалось.
Вы совершенно правы, такое заблуждение действительно есть — будто бы PM — это продолжение развития TL. Мне показалось не логичным выносить это явным образом, т.к. картинка с двумя карьерными лестницами должна была именно это продемонстрировать и без дополнительного указания.
Задача описать «куда может развиваться TL» — в статье не стоит, ровно поэтому путь в архитекторы — не озвучен (он существует и это хороший и экологичный путь).
Тема завоевания уважения — это тема отдельной статьи. Разве IT-управленец уважение команды получает автоматом? Нет. Ему точно также приходится его завоевывать. И в данной ситуации на старте все равны. Кому-то будет легче в процессе, а кому-то труднее. В то же время знание и умение отличать UML от XML — никак на уважении не сказываются, ибо зоны ответственности менеджера и разработчика — сильно отличаются. Это разработчику как раз положено понимать такое отличие, а начальник за другое отвечает (к примеру за своевременную выплату зарплаты этому разработчику). И для зоны ответственности руководителя — отличать XML от UML — зачастую не требуется. Да, такое знание поможет говорить на одном языке с подчиненными, но только поможет. А может и не помочь, как мы можем наблюдать в сотнях и тысячах проектных команд.
И вот ровно для того, чтобы технические лидеры команды не отторгали начальника — он как раз и должен обладать просто обычными Soft Skills и быть вменяемым и толковым человеком (грамотность в тех-части — не является критически обязательной для такого отторжения или принятия).
Кстати, на эту тему есть как свои «за», так и некоторые «против». Не все так однозначно или, если хотите, здесь нет черного и белого. На финальную эффективность могут повлиять многие внешние факторы (факторы среды и окружения).
Да, примерно так. Только я бы разделил: владельцы такого кафе обратную связь так и не получили, а вот умный и предприимчивый посетитель сразу понимает, что рядом нет конкуренции и если может/хочет — откроет свое кафе.
Многие из комментаторов сразу же бросаются решать описанную ситуацию, рассказывая что-то вроде «да я бы...». Возможно вы правы. Возможно, ваш вариант бы сработал. Возможно. Дьявол в деталях. Не бывает ни одного похожего проекта и в каждом слишком много тонкостей.
Спорить про определения, «что такое soft skills» просто не имеет смысла. В блоге на сайте компании есть статья с одноименным названием. Там написано то, как мы понимаем этот термин и что с ним делать.
Очевидно, что у героя статьи не хватало множество навыков руководителя. И я уверен, многие начинающие менеджеры попадали в похожие ситуации. Если же данная статья поможет им не наступать на подобные грабли и почитать некоторые книги, статьи или сходить поучиться управлению проектами — то польза от статьи уже есть.
И еще раз напомню, что в менеджменте не бывает серебряных пуль. Не бывает однозначных решений, особенно там, где ключевой фактор успеха проекта — это команда. Люди.
Успехов вам в ваших проектах!
За задачу должен отвечать один человек, и не только нести ответственность, но и быть способным сделать задачу. В некоторых случаях (конечно же в придуманных мною :) ) оказывается так, что за некоторые части одной задачи отвечают разные люди. А за сборку частей в целое вообще не отвечает никто. И вот то, что у этих частей никак не получается сыграть в упомянутый Вами «Квартер» — виновато отсутствие у частей мотивации и только в этом причина.
К сожалению, я не могу согласиться с такой точкой зрения. Она загубила множество хороших проектов, команда, и карьер. Одно из работающих решений, как избежать размазывания ответственности — описано в статье.
И вот еще один момент: многие руководители любят придумывать разные позиции и должности, лишь бы как-то мотивировать своих подчиненных красивым «шильдиком», красивым названием должности. Мол, а давайте назовем Team Lead'а Руководителем проектов. Это же круче звучит. И никого совсем не беспокоит, что круг обязанностей такого свежеиспеченного руководителя проектов сильно не дотягивает до стандартного, описанного во многих методологиях. Частично еще и по этой причине находятся люди, не видящие разницы между приведенными в статье схемами.
Мне только немного удивительно, т.к. статья про зоны ответственности, а Вы не довольны названиями должностей. Ну значит будем считать, что с названиями я ошибся. Главное, что у вас все хорошо — и желаю Вам, чтобы так и оставалось.
Задача описать «куда может развиваться TL» — в статье не стоит, ровно поэтому путь в архитекторы — не озвучен (он существует и это хороший и экологичный путь).
И вот ровно для того, чтобы технические лидеры команды не отторгали начальника — он как раз и должен обладать просто обычными Soft Skills и быть вменяемым и толковым человеком (грамотность в тех-части — не является критически обязательной для такого отторжения или принятия).
Думаю, нужны еще статьи на эту тему…