Привет, друзья!
По результатам статьи «Как мне стать project manager’ом в IT, если до этого я работал(-а) на похожей позиции, но не в IT?» возникли вопросы, а что же делать Team Leads (TL), которые уже работают в IT? Как этим Team Leads стать руководителями проектов? В данной статье намеренно не будет упоминаться позиция Tech Lead, которая в моем понимании ничем не отличается от Team Lead, с точки зрения роста из нее в PM. Таким образом сокращение TL можно читать как Team Lead, так и как Tech Lead.
Сразу подчеркну, что материала на эту тему не просто много, а очень много, и уложить его в одну статью совершенно нереально. Более того, уложиться даже в несколько статей — это тоже почти безнадежная задача. Буквально каждый пункт, о котором дальше пойдет речь — тянет за собой многочисленные тренинги, огромное количество книжек, статей в Интернет, обсуждений с наставниками и много, много, очень много лично вашей практики в работе над собой. А потом все перечисленные время-, сило- и нерво-затраты повторить еще разок.
Если после прочтения данного вступления вы все еще считаете, что вам почему-то все равно необходимо вырасти из TL в Project Manager’а, и вы готовы вкладывать время и силы в свое развитие — welcome читать дальше. Если вы не готовы вкладывать в себя и учиться, практиковаться, учиться и снова практиковаться — дальше читать смысла нет. Не тратьте свое время.
Чтобы избежать некоторой путаницы, стоит упомянуть, что разбираю в этой статье только вариант «TL->PM». Опцию «Инженер->TL» не рассматриваю для сокращения объема статьи.
Как же TL становится PM в обычной жизни? Основные варианты следующие:
1. Больше некого. Команда разрослась и назначить кого-то надо, а других кандидатур нет.
2. Единственный, кто в в теме (knowledge holder). Знает о технической стороне проекта почти все.
3. Несколько TL’ей, одна позиция. Выбирают кого-то одного.
3. «Мотивация» TL новым названием должности. Вашу позицию просто переименовали, но делаете вы тоже самое, что и раньше. Мотивация — очень спорный термин в данном случае, поэтому в кавычках.
5. Новая вакансия PM (новый или пилотный проект, куда нужен PM).
6. TL уже работает как PM. Выполняет те функции, которые должен делать PM, т.е. уже действительно готов быть PM.
Заблуждения
Оказавшись в роли PM, наш Lead остался внутри ровно тем же самым человеком, что и был до этого, то есть Lead’ом (кроме пункта 6 из списка выше). Все заблуждения о роли и функциях PM, которые PM действительно должен выполнять — у нашего Lead’а сохранились неизменными. Что же это за заблуждения?
1. Я отличный TL, помогаю своей команде, примерно 50% своего времени пишу код (если Lead группы разработчиков) или занимаюсь тестированием (если Lead группы тестировщиков), или занимаюсь спецификациями и требованиями (если Lead группы аналитиков). Значит в роли PM придется делать примерно тоже самое, только еще лучше, еще качественнее, еще быстрее. Это как next level в умениях, которые у меня уже есть.
2. Раз уж я делаю свою работу превосходно, то остальные тоже должны делать свою работу как минимум «на отлично».
3. Я должен разбираться во всем, что умеют мои подчиненные, чтобы «в случае чего» я был способен выполнить работу за любого из них. Причем разбираться на уровне, превосходящем уровень моих подчиненных.
4. Я же крутой TL, а теперь всего-лишь пару новых отчетов буду делать сверх своих обычных обязанностей — легко справлюсь!
5. PM получает большую зарплату, а работает меньше — я тоже так хочу!
6. PM должен только делать отчеты, сидеть на встречах и созвонах с заказчиком — это легко — справлюсь!
Признайтесь честно (никто ведь не узнает, кроме вас самих) — у вас есть хотя бы одно из этих шести заблуждений?
Мы зачастую даже не подозреваем, как много требуется освоить, чтобы быть PM’ом! И мы этого не знаем не потому, что мы глупые. Зачастую это просто потому, что нам никто об этом не сказал, и мы остались в плену наших вышеописанных заблуждений. А открыть для себя этот «дивный новый мир» — мы сами не способны, потому что он ну совсем другой. И сейчас станет немного яснее, почему это так.
Карьерная лестница
Обычно, в головах большинства сотрудников IT эта лестница выглядит следующим образом:
На самом же деле она совсем другая, более правильно сказать — это разные карьерные лестницы:
А раз это разные лестницы, то и набор умений (skill set), необходимый для этих лестниц — разный! Скажу больше, он не просто разный, а совершенно разный. Фактически — это совсем другая профессия. Вы меняли в своей жизни профессию хотя бы раз? Вот переход между этими лестницами — примерно тоже самое. Можете прикинуть, сколько времени в среднем занимает освоить новую профессию хотя бы на уровень «средненько». Забегая вперед скажу — это несколько лет минимум.
Более того, знания, которые вам помогали на лестнице №1, на второй лестнице будут иногда вам мешать. Вы рискуете попасть в ловушку оценки сроков — я бы сам как <разработчик|тестировщик|аналитик> сделал бы эту задачу за столько-то дней, значит и мои новые подчиненные сделают ее ровно за такой же срок. Это серьезная ошибка начинающих руководителей, выросших из TL!
Вторая распространенная ошибка — желание «кодить». Да, да, именно кодить (либо тестировать, либо работать с требованиями). Project Manager не должен этого делать ни в коем случае! Получается, что если вы переходите на позицию PM и перестаете кодить, ваши навыки как разработчика (тестировщика, аналитика) — падают. За полгода работы на PM позиции (лестница №2), ваши навыки из лестницы №1 просядут, но не критично. Через год — уже критично и вернуться назад будет очень сложно. Возможно, но действительно сложно. И возврат потребует еще примерно полгода-год обратного «привыкания». Почему может захотеться возвращаться? Об этом дальше.
Не забываем про шесть распространенных заблуждений. Они, если были, то никуда не делись. И серьезно мешают вам быть PM’ом. Избавляйтесь от них максимально оперативно!
Подводные камни
Итак, вы PM, выросший из TL. С какими неочевидными на первый взгляд неожиданностями вы столкнетесь?
1. Код. Необходимо перестать «писать код». Да, еще раз — перестаньте это делать. Немедленно. Иначе вы не PM.
2. Знания. Ваши старые знания как специалиста могут вам мешать. Осознать этот факт сложно. Еще сложнее его принять.
3. Деградация. Вы деградируете как специалист (лестница №1).
4. Начальство. Вам требуется понимание, как на самом деле думает заказчик/начальство (это и репортинг на них, и переписка/коммуникация). Вы теперь на другой стороне баррикад, и понимать эту сторону — обязательно. Особенно заказчика. Он вдруг перестает быть врагом, генерирующим «странные» пожелания, и становится тем, чью позицию и чей взгляд вам жизненно необходимо выяснить и понять. Многие PM’ы не могут добиться этого навыка годами.
5. Не свой. Вы больше не свой, если стали руководить своими коллегами. Они вдруг резко перестают делиться с вами своими переживаниями, мнениями и ситуацией в проекте. Ведь вы приобрели власть награждать и наказывать. А неверно сказанное ими слово может повлечь лишение бонуса или любые другие нехорошести для них. Вот и не делятся.
Одновременно с таким серьезным ударом по вашей картине мира происходит изменение зоны вашей ответственности. Теперь вы отвечаете не только за часть «кода», но и за людей, за все delivery (time, quality, scope, customer satisfaction, etc.), иногда еще и за бюджет с зарплатами, и контракт.
Это кардинально другой уровень ответственности. Далеко не все готовы и способны его выдерживать. Особенно, если вы хотели быть PM’ом из-за 4, 5 и 6 заблуждения (см. выше). Только представьте — теперь вам будет прилетать по шапке не только за ваш собственный провал, но и за провал каждого вашего подчиненного! Если у вас 10 подчиненных, то это в 10 раз больше «прилетаний по шапке», чем у вас было до этого. Именно на этом фокусе с ответственностью многие разворачиваются назад, пока еще не поздно, и пока вы не деградировали как специалист. А данная деградация неумолима. Кстати, усидеть одной Ж на двух стульях — не получится. Быть полноценным PM, одновременно профессионально закрывая вопросы TL — не приведет ни к чему хорошему. Вы провалите оба направления, причем с не слабым риском для всей своей карьеры, а возможно и для своего здоровья, что уже совсем не здорово.
Всем ли надо быть PM’ами?
Вспомните принцип Питера Лоуренса (Dr. Laurence Johnston Peter) или перечитайте одноименную книгу.
Как определить тех,кому действительно нужно кто хочет становиться PM’ом?
А действительно ли они этого хотят? Что говорит их поведение, факты, результаты?
TL должен хотеть и быть способным стать PM’ом!
Если вы руководитель и выбираете, повышать ли вашего TL — подумайте, сможет ли он выполнять совершенно новые обязанности? Способен ли он это делать? А хочет ли? Одних его словестных заявлений — недостаточно. TL должен фактами, поступками демонстрировать, что он хочет и может (способен) быть PM. Поручите ему пилотный проект, дайте возможность делать ошибки, поддержите его на «сложных поворотах» и по результатам пилотного проекта обсудите с TL уровень его готовности к новой роли (а не позиции). А если готовность еще пока не 100%, то что надо, чтобы стало 100%. Составьте список с датами и четкими milestones. Если TL готов по этому списку идти — он потенициальный PM. Если он не готов вкладываться и не осознает всего вышеописанного — значит это не его. Возможно, пока не его.
Если вы TL, и хотите быть PM‘ом — учитесь и практикуйтесь быть PM’ом независимо от планов вашего руководителя. Если ваш руководитель вам помогает — отлично. Вам очень повезло. Без шуток. Такая помощь — очень дорого стоит. Если ваш руководитель вам не помогает — это не плохо, просто вам придется приложить чуть больше сил. Демонстрируйте ему не на словах, а на деле, с фактами, что вы готовы брать на себя ответственность за других и уже делаете это (вот список, когда это происходило и какими положительными результатами закончилось). Попросите себе маленькую песочницу, пилотный проект, где вы могли бы потренироваться. Где могли бы совершать ошибки (их все совершают) без критического риска для основного проекта. Попросите вашего руководителя о помощи в виде советов. Один час в неделю. Полчаса в день. Любой удобный для него регулярный time slot. Не бойтесь ошибаться. Не бойтесь спрашивать. Составьте с руководителем план, что вам надо освоить, чтобы стать PM. Не пугайтесь, если план получится большой. Помните — это совсем другая профессия. И знания с навыками там нужны совсем другие.
В завершение:
1. TL стоит осознать, что «сидеть на попе ровно» != «гарантированный рост в PM через несколько лет».
2. Мышление в стиле «встал и сделал» — ровно то, что требуется от PM. Мышление в стиле «зарплата-кредит-Египет» — то, что вроде как еще годится для TL, но совсем не подходит для PM.
3. Проявляйте проактивность — кому больше всех надо?
4. Важно восприятие себя и своей роли в команде, проекте, компании.
5. Действительно необходимо уметь работать с людьми.
6. Критически важна постоянная готовность работать над собой, учиться и меняться, брать на себя ответственность за других.
Все это и многое друге — Soft Skills, без которых вы останетесь TL, но внешне оденете погоны PM (новое написание должности). Погоны, конечно, греют душу, но внутри-то вы все тот же TL. А оно вам надо? Ради этого ли вы все затевали?
Ну как, вы осознали что вам предстоит? Действительно осознали? Все еще хотите стать PM? Если да, то пересмотрите еще раз список заблуждений и подводных камней. Да, да, вернитесь прямо сейчас к этим спискам и пересмотрите их внимательно, даже если вы их пока помните.
Пересмотрели? Вы все еще тут? Тогда именно для вас в следующей статье я напишу, с чего, на мой взгляд, стоит начинать, чтобы начать перестраивать свой mind set в сторону «быть PM», если вы действительно готовы это делать — готовы становиться настоящим руководителем (об одной из черт которого говорит Simon Sinek в своем выступлении на TED).
Мотивация, чтобы быть PM — это желание сделать нечто такое, что один человек сам не может сделать в принципе.
P.S.: оригинал этой статьи (и другие интересные материалы) можно прочесть в моем блоге: consultpm.com
Поделитесь этой статьей с друзьями.
Like и Share — приветствуются и дают плюс в карму.
Спасибо и успехов вам!
По результатам статьи «Как мне стать project manager’ом в IT, если до этого я работал(-а) на похожей позиции, но не в IT?» возникли вопросы, а что же делать Team Leads (TL), которые уже работают в IT? Как этим Team Leads стать руководителями проектов? В данной статье намеренно не будет упоминаться позиция Tech Lead, которая в моем понимании ничем не отличается от Team Lead, с точки зрения роста из нее в PM. Таким образом сокращение TL можно читать как Team Lead, так и как Tech Lead.
Сразу подчеркну, что материала на эту тему не просто много, а очень много, и уложить его в одну статью совершенно нереально. Более того, уложиться даже в несколько статей — это тоже почти безнадежная задача. Буквально каждый пункт, о котором дальше пойдет речь — тянет за собой многочисленные тренинги, огромное количество книжек, статей в Интернет, обсуждений с наставниками и много, много, очень много лично вашей практики в работе над собой. А потом все перечисленные время-, сило- и нерво-затраты повторить еще разок.
Если после прочтения данного вступления вы все еще считаете, что вам почему-то все равно необходимо вырасти из TL в Project Manager’а, и вы готовы вкладывать время и силы в свое развитие — welcome читать дальше. Если вы не готовы вкладывать в себя и учиться, практиковаться, учиться и снова практиковаться — дальше читать смысла нет. Не тратьте свое время.
Чтобы избежать некоторой путаницы, стоит упомянуть, что разбираю в этой статье только вариант «TL->PM». Опцию «Инженер->TL» не рассматриваю для сокращения объема статьи.
Как же TL становится PM в обычной жизни? Основные варианты следующие:
1. Больше некого. Команда разрослась и назначить кого-то надо, а других кандидатур нет.
2. Единственный, кто в в теме (knowledge holder). Знает о технической стороне проекта почти все.
3. Несколько TL’ей, одна позиция. Выбирают кого-то одного.
3. «Мотивация» TL новым названием должности. Вашу позицию просто переименовали, но делаете вы тоже самое, что и раньше. Мотивация — очень спорный термин в данном случае, поэтому в кавычках.
5. Новая вакансия PM (новый или пилотный проект, куда нужен PM).
6. TL уже работает как PM. Выполняет те функции, которые должен делать PM, т.е. уже действительно готов быть PM.
Заблуждения
Оказавшись в роли PM, наш Lead остался внутри ровно тем же самым человеком, что и был до этого, то есть Lead’ом (кроме пункта 6 из списка выше). Все заблуждения о роли и функциях PM, которые PM действительно должен выполнять — у нашего Lead’а сохранились неизменными. Что же это за заблуждения?
1. Я отличный TL, помогаю своей команде, примерно 50% своего времени пишу код (если Lead группы разработчиков) или занимаюсь тестированием (если Lead группы тестировщиков), или занимаюсь спецификациями и требованиями (если Lead группы аналитиков). Значит в роли PM придется делать примерно тоже самое, только еще лучше, еще качественнее, еще быстрее. Это как next level в умениях, которые у меня уже есть.
2. Раз уж я делаю свою работу превосходно, то остальные тоже должны делать свою работу как минимум «на отлично».
3. Я должен разбираться во всем, что умеют мои подчиненные, чтобы «в случае чего» я был способен выполнить работу за любого из них. Причем разбираться на уровне, превосходящем уровень моих подчиненных.
4. Я же крутой TL, а теперь всего-лишь пару новых отчетов буду делать сверх своих обычных обязанностей — легко справлюсь!
5. PM получает большую зарплату, а работает меньше — я тоже так хочу!
6. PM должен только делать отчеты, сидеть на встречах и созвонах с заказчиком — это легко — справлюсь!
Признайтесь честно (никто ведь не узнает, кроме вас самих) — у вас есть хотя бы одно из этих шести заблуждений?
Мы зачастую даже не подозреваем, как много требуется освоить, чтобы быть PM’ом! И мы этого не знаем не потому, что мы глупые. Зачастую это просто потому, что нам никто об этом не сказал, и мы остались в плену наших вышеописанных заблуждений. А открыть для себя этот «дивный новый мир» — мы сами не способны, потому что он ну совсем другой. И сейчас станет немного яснее, почему это так.
Карьерная лестница
Обычно, в головах большинства сотрудников IT эта лестница выглядит следующим образом:
На самом же деле она совсем другая, более правильно сказать — это разные карьерные лестницы:
А раз это разные лестницы, то и набор умений (skill set), необходимый для этих лестниц — разный! Скажу больше, он не просто разный, а совершенно разный. Фактически — это совсем другая профессия. Вы меняли в своей жизни профессию хотя бы раз? Вот переход между этими лестницами — примерно тоже самое. Можете прикинуть, сколько времени в среднем занимает освоить новую профессию хотя бы на уровень «средненько». Забегая вперед скажу — это несколько лет минимум.
Более того, знания, которые вам помогали на лестнице №1, на второй лестнице будут иногда вам мешать. Вы рискуете попасть в ловушку оценки сроков — я бы сам как <разработчик|тестировщик|аналитик> сделал бы эту задачу за столько-то дней, значит и мои новые подчиненные сделают ее ровно за такой же срок. Это серьезная ошибка начинающих руководителей, выросших из TL!
Вторая распространенная ошибка — желание «кодить». Да, да, именно кодить (либо тестировать, либо работать с требованиями). Project Manager не должен этого делать ни в коем случае! Получается, что если вы переходите на позицию PM и перестаете кодить, ваши навыки как разработчика (тестировщика, аналитика) — падают. За полгода работы на PM позиции (лестница №2), ваши навыки из лестницы №1 просядут, но не критично. Через год — уже критично и вернуться назад будет очень сложно. Возможно, но действительно сложно. И возврат потребует еще примерно полгода-год обратного «привыкания». Почему может захотеться возвращаться? Об этом дальше.
Не забываем про шесть распространенных заблуждений. Они, если были, то никуда не делись. И серьезно мешают вам быть PM’ом. Избавляйтесь от них максимально оперативно!
Подводные камни
Итак, вы PM, выросший из TL. С какими неочевидными на первый взгляд неожиданностями вы столкнетесь?
1. Код. Необходимо перестать «писать код». Да, еще раз — перестаньте это делать. Немедленно. Иначе вы не PM.
2. Знания. Ваши старые знания как специалиста могут вам мешать. Осознать этот факт сложно. Еще сложнее его принять.
3. Деградация. Вы деградируете как специалист (лестница №1).
4. Начальство. Вам требуется понимание, как на самом деле думает заказчик/начальство (это и репортинг на них, и переписка/коммуникация). Вы теперь на другой стороне баррикад, и понимать эту сторону — обязательно. Особенно заказчика. Он вдруг перестает быть врагом, генерирующим «странные» пожелания, и становится тем, чью позицию и чей взгляд вам жизненно необходимо выяснить и понять. Многие PM’ы не могут добиться этого навыка годами.
5. Не свой. Вы больше не свой, если стали руководить своими коллегами. Они вдруг резко перестают делиться с вами своими переживаниями, мнениями и ситуацией в проекте. Ведь вы приобрели власть награждать и наказывать. А неверно сказанное ими слово может повлечь лишение бонуса или любые другие нехорошести для них. Вот и не делятся.
Одновременно с таким серьезным ударом по вашей картине мира происходит изменение зоны вашей ответственности. Теперь вы отвечаете не только за часть «кода», но и за людей, за все delivery (time, quality, scope, customer satisfaction, etc.), иногда еще и за бюджет с зарплатами, и контракт.
Это кардинально другой уровень ответственности. Далеко не все готовы и способны его выдерживать. Особенно, если вы хотели быть PM’ом из-за 4, 5 и 6 заблуждения (см. выше). Только представьте — теперь вам будет прилетать по шапке не только за ваш собственный провал, но и за провал каждого вашего подчиненного! Если у вас 10 подчиненных, то это в 10 раз больше «прилетаний по шапке», чем у вас было до этого. Именно на этом фокусе с ответственностью многие разворачиваются назад, пока еще не поздно, и пока вы не деградировали как специалист. А данная деградация неумолима. Кстати, усидеть одной Ж на двух стульях — не получится. Быть полноценным PM, одновременно профессионально закрывая вопросы TL — не приведет ни к чему хорошему. Вы провалите оба направления, причем с не слабым риском для всей своей карьеры, а возможно и для своего здоровья, что уже совсем не здорово.
Всем ли надо быть PM’ами?
Вспомните принцип Питера Лоуренса (Dr. Laurence Johnston Peter) или перечитайте одноименную книгу.
Как определить тех,
А действительно ли они этого хотят? Что говорит их поведение, факты, результаты?
TL должен хотеть и быть способным стать PM’ом!
Если вы руководитель и выбираете, повышать ли вашего TL — подумайте, сможет ли он выполнять совершенно новые обязанности? Способен ли он это делать? А хочет ли? Одних его словестных заявлений — недостаточно. TL должен фактами, поступками демонстрировать, что он хочет и может (способен) быть PM. Поручите ему пилотный проект, дайте возможность делать ошибки, поддержите его на «сложных поворотах» и по результатам пилотного проекта обсудите с TL уровень его готовности к новой роли (а не позиции). А если готовность еще пока не 100%, то что надо, чтобы стало 100%. Составьте список с датами и четкими milestones. Если TL готов по этому списку идти — он потенициальный PM. Если он не готов вкладываться и не осознает всего вышеописанного — значит это не его. Возможно, пока не его.
Если вы TL, и хотите быть PM‘ом — учитесь и практикуйтесь быть PM’ом независимо от планов вашего руководителя. Если ваш руководитель вам помогает — отлично. Вам очень повезло. Без шуток. Такая помощь — очень дорого стоит. Если ваш руководитель вам не помогает — это не плохо, просто вам придется приложить чуть больше сил. Демонстрируйте ему не на словах, а на деле, с фактами, что вы готовы брать на себя ответственность за других и уже делаете это (вот список, когда это происходило и какими положительными результатами закончилось). Попросите себе маленькую песочницу, пилотный проект, где вы могли бы потренироваться. Где могли бы совершать ошибки (их все совершают) без критического риска для основного проекта. Попросите вашего руководителя о помощи в виде советов. Один час в неделю. Полчаса в день. Любой удобный для него регулярный time slot. Не бойтесь ошибаться. Не бойтесь спрашивать. Составьте с руководителем план, что вам надо освоить, чтобы стать PM. Не пугайтесь, если план получится большой. Помните — это совсем другая профессия. И знания с навыками там нужны совсем другие.
В завершение:
1. TL стоит осознать, что «сидеть на попе ровно» != «гарантированный рост в PM через несколько лет».
2. Мышление в стиле «встал и сделал» — ровно то, что требуется от PM. Мышление в стиле «зарплата-кредит-Египет» — то, что вроде как еще годится для TL, но совсем не подходит для PM.
3. Проявляйте проактивность — кому больше всех надо?
4. Важно восприятие себя и своей роли в команде, проекте, компании.
5. Действительно необходимо уметь работать с людьми.
6. Критически важна постоянная готовность работать над собой, учиться и меняться, брать на себя ответственность за других.
Все это и многое друге — Soft Skills, без которых вы останетесь TL, но внешне оденете погоны PM (новое написание должности). Погоны, конечно, греют душу, но внутри-то вы все тот же TL. А оно вам надо? Ради этого ли вы все затевали?
Ну как, вы осознали что вам предстоит? Действительно осознали? Все еще хотите стать PM? Если да, то пересмотрите еще раз список заблуждений и подводных камней. Да, да, вернитесь прямо сейчас к этим спискам и пересмотрите их внимательно, даже если вы их пока помните.
Пересмотрели? Вы все еще тут? Тогда именно для вас в следующей статье я напишу, с чего, на мой взгляд, стоит начинать, чтобы начать перестраивать свой mind set в сторону «быть PM», если вы действительно готовы это делать — готовы становиться настоящим руководителем (об одной из черт которого говорит Simon Sinek в своем выступлении на TED).
Мотивация, чтобы быть PM — это желание сделать нечто такое, что один человек сам не может сделать в принципе.
P.S.: оригинал этой статьи (и другие интересные материалы) можно прочесть в моем блоге: consultpm.com
Поделитесь этой статьей с друзьями.
Like и Share — приветствуются и дают плюс в карму.
Спасибо и успехов вам!
