Парадокс начинающего менеджера. Основные советы

32 комментария
Парадокс начинающего менеджера. Основные советы
Что должен делать начинающий менеджер, чтобы не привести свою группу в плачевную ситуацию? В этой статье мы выделим несколько полезных советов. Самый главный – как перестать быть техническим специалистом и стать руководителем. Совет 1. Не готовы руководить - лучше не руководите Как показывает опыт - в том числе и наш личный - принять такое решение совсем не просто. Особенно когда за плечами десятилетие работы техническим специалистом. Интуитивно или нет, технический специалист понимает, что начав по-серьезному заниматься менеджментом, он начнет, и очень быстро, терять свои технические навыки. С одной стороны, вполне понятно желание цепляться за свои знания как за гарантию занятости в будущем. Понятно желание забрать себе всю самую интересную работу. С другой стороны... а готовы ли вы на самом деле сделать шаг к руководящей позиции? Ведь возможных вариантов всего три:
  • остаться хорошим техническим специалистом;
  • переучиться на хорошего руководителя;
  • стать плохим руководителем и посредственным техническим спецом. Прогресс-то на месте стоять не будет.
Полный уход в руководство требует определенной доли смелости и в чем-то авантюризма, желания нырнуть с головой в полностью новый мир и посмотреть, что из этого получится. Если вы не готовы принять это решение, с очень большой вероятностью "цепляние" за техническую сферу закончится тем, что вы станите самым узким местом в проекте. Совет 2. Примите то, что другие будут делать работу иначе Мы всегда полушутя-полусерьезно говорим, что каждый уважающий себя программист стремится переписать код, оставленный другим программистом. Это не хорошо и не плохо - это жизнь. Однако с привычкой переписывать или дописывать код за другими заниматься руководящей работой категорически противопоказано. Просто потому, что два человека не в состоянии написать одинаковый код. Поэтому ваши программисты всегда будут делать немножко не то и не так, как вы их попросили. Всегда! Бороться с этим бесполезно, это нужно просто принять. Переделывать код за подчиненными в рекордно короткие сроки убивает у группы мотивацию делать что угодно - ведь "умный" руководитель все-равно все переделает. Задача руководителя - руководить, а не код писать. Сконцентрируйтесь на руководстве. Умейте объяснить, какой результат должен получиться в итоге - и добивайтесь получения этого результата. Совет 3. Не старайтесь чинить все подряд Программистам не нравится то, что в коде есть баги. Особенно, когда код писал этот самый программист. И тем более, когда этим кодом хотел что-то показать или доказать. Но хуже багов могут быть только недоделки или "недополучилки", когда получилось несколько не так круто, как задумывалось. В отличие от программиста руководитель имеет дело с множеством проблем, более или менее срочных или важных. Никому не нравится, что в проекте или в бизнес-области с регулярным постоянством появляются незапланированные проблемы, требующие – внимания, часто немедленного. И особо неприятно, когда эти проблемы вырастают из недавно принятых мудрых решений. Интуитивно кажется, что браться надо за то, что является срочным. Тушение пожаров дает чувство удовлетворенности, но никогда не решит важных задач. Срочное редко бывает важным, а важное редко бывает срочным (Д. Эйзенхауэр). Сконцентрируйтесь вначале на важных, а потом на срочных проблемах. При этом очень важно понимать источники проблем. Совет 4. Преодолейте чувство бесполезности Помнится, в бытность молодыми и горячими программистами нам казалось, что наше руководство - это просто бесполезная надстройка, которая ничего не делает, не помогает, а только мешает. Зарплату платят, конечно, но на этом польза от них и заканчивалась. ;-) Как исполнитель на проекте, вы постоянно заняты работами. А вот руководителю постоянно что-то делать в проекте не надо. Руководитель организовал работу, раздал задачи, убедился, что все знают, что и к какой дате надо сделать - и, собственно, все. Мавр сделал свое дело. Мавру пора удалиться менеджить заинтересованные стороны и управлять рисками. Это достигается посредством общения, а не через написание кода. У вчерашнего исполнителя может возникнуть ступор: все работают, а я - нет. Чем бы мне таким заняться, где бы мне тут на коленке подпрограммировать. Не надо. Исполнение - не ваша работа, у вас своей хватает. Для группы вы гораздо полезнее в решении управленческих вопросов. Совет 5. Не нужно всем нравиться. Нужно выдать результат Всем нам известно такое понятие как "вписаться в коллектив". Это очень хорошо и здорово, когда получается; и очень плохо и некрасиво, когда нет. А когда вы переходите в руководство - в какой именно коллектив вы собираетесь вписываться? В коллектив своих подчиненных? В коллектив других руководителей калибром поменьше или побольше? В коллектив смежных команд? Свежеиспеченные руководители пытаются "сдружиться" со всеми. Это не нужно. Нужно выстраивать рабочие отношения. Нет смысла понравиться всем - вас в итоге просто перестанут считать самостоятельной единицей. Нужно выдавать результат, а не заботиться о том, что о вас подумают другие. Мы часто говорим: у нас море недостатков, и всего одна сильная сторона, мы всегда деливерим то, под чем подписываемся. Больше сильных сторон и не нужно. Совет 6. Умейте сказать «нет» Как исполнителя вас не раз заставляли говорить "да" в ответ на то, с чем вы не согласны. Написать код за не очень реальный срок. Исправить все баги к 1-му января. Собственно говоря, нам с детства говорят, что безоговорочно делать то, что говорят родители или старшие - это хорошо. В руководстве умение сказать нет не менее важно, чем умение выполнять то, что просят. Особенно когда просят взять на группу работу сверх того, что группа в состоянии вытянуть. У любого коллектива есть потолок того, что он может сделать. Кроме того, жизнь есть жизнь, и непредвиденные ситуации возникают регулярно. У вашей группы должна быть возможность на эти непредвиденные ситуации реагировать. Если у вашей группы не будет этой возможности, скорее всего, вы не сможете сделать то, что обещали. Другое дело, что просто сказать нет - это неконструктивно. Говоря "нет" начальнику или клиенту, нужно всегда предлагать альтернативу решения его проблемы. Поймите бизнес-контекст вопроса "за сколько вы это сделаете?" и вы поймете, что именно от вас хотят услышать. Совет 7. Держитесь своих решений Сложные решения, немало которых вам придется принять, принимаются в условиях неопределенности. У вашей группы на руках два проекта - можете ли вы взять третий, ведь где гарантия того, что эти два проекта закончатся строго по плану? С течением времени многие обстоятельства, конечно, прояснятся, что будет играть либо за, либо против вашего решения. Клиенты или ваше собственное руководство могут начать критически обдумывать решения, принятые вами, и задавать вопросы - и это нормально. Главное, чтобы вы раз за разом выдавали одну и ту же аргументацию принятия (или непринятия) конкретного решения. Ведь если аргументация, данная вами разным участникам, не совпадает, значит, вы в чем-то врете. Другое дело, что руководитель не обязан объяснять свои решения подчиненным. Это, конечно, не значит, что он может совсем не отвечать на вопросы - это тоже контрпродуктивно. Просто в некоторых случаях необходимо напоминать, кто кому подчиняется. Особенно это касается чувствительных, жестких или непопулярных решений, таких как, например, увеличение зарплаты или увольнение. Совет 8. Ваша группа - ваша защита Самое страшная ситуация в менеджменте, которую можно представить: к вам приходит руководитель группы и говорит: я не согласен с тем и с этим. Делаем так и эдак. Если не будет по-моему, ухожу я, а за мной моя группа. Можно, конечно, отмахнуться и сказать: ну и уходи. Руководитель без поддержки группы - пустое место и меняется, как перчатка. С другой стороны, через "туман войны" не всегда видно, какова вероятность того, что группа уйдет вместе с руководителем. Если большая часть группы может пойти за своим руководителем, пусть даже в относительно короткое время, тут уже возникает масса нюансов, обострения которых никто не хочет. Или же, скорее всего, вряд ли захотят сию минуту. Самый простой способ добиться расположения группы - не давать чужим "бить" своих подчиненных: никогда, ни за что, и не при каких обстоятельствах. Даже если ваш подчиненный совершил самую ужасную в мире глупость - он один из вашей группы. Поэтому претензии к подчиненным принимаются вначале руководителем. А там посмотрим. Разумеется, это далеко не полный список, чему надо учиться, когда принял решение руководить. Если вам не чужда эта тема, а вопросы, подобные указанным выше, не дают покоя, приглашаем вас принять участие в тренинге «Управление командой технических специалистов» 12-13 января в Минске. Тренинг проводится командой iTrainings.ru в партнерстве с компанией Itransition. Тренер: Константин Кондратюк Аудитория: Тренинг предназначен для менеджеров среднего звена, руководителей проектов и специалистов. Требуемые знания и профессиональный опыт: Для прохождения тренинга не требуются специальные знания в области управления командами, желателен опыт руководства или участия в проектах и знания в области общего менеджмента. Программа тренинга (2 дня, 16 часов):
  • Введение
  • Психотипы технических специалистов и их мотивация
  • Основные проблемы при управлении техническими специалистами
  • Цели и задачи команды в рамках организации (SMART)
  • Управление командой на разных фазах жизненного цикла проекта
  • Жизненный цикл команды
  • Аудит существующей команды
  • Правила построения эффективной команды
  • Управление эффективностью работы команды
  • Сложные сотрудники
  • Управление конфликтом
  • Переговоры с сотрудниками
Методы обучения
  • Теоретическая часть - 50%
  • Практика - 40%
  • Тесты - 10%
Стоимость участия: 2 800 000 рублей с НДС Место проведения: г. Минск, ул. Кульман 1 Скачать программу и зарегистрироваться на тренинг вы можете здесь.

Горячие события

Конкурс EY Entrepreneur Of The Year 2020
31 мая — 31 мая

Конкурс EY Entrepreneur Of The Year 2020

ISsoft Insights 2020
6 июня — 6 июня

ISsoft Insights 2020

Минск
GoWayFest 4.0
11 июля — 11 июля

GoWayFest 4.0

Минск

Читайте также

«Прошу терпения и понимания». Гендиректор Itransition написал сотрудникам о кризисе
«Прошу терпения и понимания». Гендиректор Itransition написал сотрудникам о кризисе

«Прошу терпения и понимания». Гендиректор Itransition написал сотрудникам о кризисе

32 комментария
Антикризисные меры: в A1QA оклады урезают на 20%
Антикризисные меры: в A1QA оклады урезают на 20%

Антикризисные меры: в A1QA оклады урезают на 20%

Коронакризис, который предрекают всем отраслям, уже коснулся белорусского ИТ. CEO компании A1QA Светлана Правдина объявила об антикризисных мерах в компании. 
108 комментариев
Сколько в Минске кандидатов на роль технического топа в серьёзной ИТ-компании? Обсуждаем с Pandadoc (ищут), Mapbox (перестали искать), Flo (нашли) и рекрутерами
Сколько в Минске кандидатов на роль технического топа в серьёзной ИТ-компании? Обсуждаем с Pandadoc (ищут), Mapbox (перестали искать), Flo (нашли) и рекрутерами

Сколько в Минске кандидатов на роль технического топа в серьёзной ИТ-компании? Обсуждаем с Pandadoc (ищут), Mapbox (перестали искать), Flo (нашли) и рекрутерами

24 комментария
Председатель совета директоров Itransition: «Задержание главы инвестфонда Baring Vostok не скажется на текущих планах компании»
Председатель совета директоров Itransition: «Задержание главы инвестфонда Baring Vostok не скажется на текущих планах компании»

Председатель совета директоров Itransition: «Задержание главы инвестфонда Baring Vostok не скажется на текущих планах компании»

1 комментарий

Обсуждение

-1

Требуемые знания и профессиональный опыт:

Для прохождения тренинга ,< желателен> опыт руководства или участия в проектах и знания в области общего менеджмента.

Отличнейшая( основа для воспитания типичного белорусского менеджера.

-1

Забыли указать что "возможны студенты старших курсов"

Максим  Гулевич
Максим Гулевич Дизайнер в EPAM
2

Меня терзают смутные сомнения....

omg
omg
0

...что предыдущие посты про мотивацию это вирусная реклама данных курсов? :)

Максим  Гулевич
Максим Гулевич Дизайнер в EPAM
2

как-то так совпало, да )

-1

Я не имею к этому никакого отношения, это случайность... Видно важная тема, раз всех так беспокоит....

0

Кто знает, почему у всех тренеров студийные фотки, где они держат пиджак в руке или закидывают его за плечо? У них, что один свадебный фотограф?

0

Я смотрю на честное открытое лицо этого человека и всей душой верю что этот жизнерадостный колобок за два миллиона восемьсот тысяч обучит любого быть эффективным менеджером. Любого. За два дня и шестнадцать часов. Всей душой. Да.

-1

личико прямо лоснится...красавец)!

2

тренеров не по внешнему виду оценивают, а по результату. нужно поспрашивать тех, кто знает его.

вообще, обсуждать физические черты человека некультурно как-то. он же не на фотоконкурсе.
ps хотя фотку я бы посоветовал товарищу сменить:)

0

думаю дело не во внешности, на а в языке тела на фото

2

Полностью согласен, что некультурно... Я был на докладе Константина по данной тематике на одном из форумов SEF.by. Доклад оставил наилучшие впечатления.

-4

Был в сентябре в Москве на тренинге Управление проектами у этого мужика. Там еще второй тусовался, Алексей Янчук его зовут. Кстати, наш белорус, заканчивал БГУИР, работал в Саме. И цена была совсем не минская - что-то вроде 500 баксов за два дня. Сам бы не платил, конечно, но заказчику было пофиг ) За что ему благодарен, т.к. тренинг был отличный. Жаль, не смогу попасть сюда, т.к. буду в Москве в эти даты (

Anonymous
Anonymous программист в Itransition
-1

Да они оба наши, я сталкивался с Константином, когда он был техническим директором Sam Solutions лет восемь назад. Очень грамотный специалист. На тренинге не был, сказать ничего не могу.

1

чет слишком много стало всего с приставкой 'i'

-2

Прошу прощения, что наверное достану своим троллингом уже не только авторов материала, но и просто уважаемых посетителей данного сайта.
Такое фото (сидя на стуле, чуть наклонившись, вроде как чуть открывшись публике:) тоже у всех тренеров есть. Осталось ещё только разместить третье знаменитое фото: стоя, выпрямив спину, скрестив руки (кстати, спорное с точки зрения психологии, т.к. это показатель не только уверенности, но и враждебности, типа у женщины - "руки-в-боки").
Задача: показать какой у нас солидный тренинг, серьезные коучи, что 2,8 ляма есть за что платить.
Решение, как получилось: посмотрите у нас есть галстук и пиджак, мы можем сфотать на зеркалку, а потом выложить безобразно мелкое фото, так, что пару постов будут обсуждать лицо.
Хотя понятное дело, мелкие детали при уменьшении создают не очень красивую текстуру, а еще плюс jpeg. Можно было и подчистить, "на люди" всё таки выкладывается.
Решение как надо: Есть ссылка на тренера, кто захочет посмотреть, посмотрит. Там, кстати, нормальная большая фотография и все вопросы отпадают. Если это не Кармен Электра в бикини, особого смысла постить фото вообще нет. Если уж очень хочется показать, как мы позитивны и открыты, все эти психологические штучки, то просто предварительно трезво глянуть, что получается при уменьшении и подшлифовать, как было сказано выше (30 секунд работы). Ну а если уж идти до конца, то где белоснежная голливудская улыбка, закатанные рукава? Где закатанные штанины и босиком по пляжу? Нет? Ну так может и не стоило... По поводу пиджаков, 2.8 млн - студенты явно не пойдут, а кто из своего кармана будет платить или принимать решение о направлении подчиненных, того пиджаком не впечатлишь, свои деловые пиджаки есть, а может уже и патек-филиппы. Уже у цивилизованных, насколько я понимаю, все эти штуки обаяния деловым стилем вроде давно отошли, даже не глядя на гиков из ИТ, которые пиджаки и не носили никогда. Как то бросилась в глаза какая то очередная реклама "магазина на диване" или как там его, где интеллигентного вида мужичек профессионально втюхивал очередной пылесос или нож (уже не помню) в спортивных штанах типа абибас. Такого раньше в рекламах что то не замечал.
P.S. Вышесказанное никак не характеризует ни тренинг, ни самого тренера. Обсуждается только подача рекламной статьи. Выше писали, что полезный тренинг и очень опытный и грамотный коуч. Не вижу смысла в этом сомневаться, достаточно взглянуть на регалии, так сказать. А так, идея та же, что и в половине предыдущих моих постов. Если делать, то стараться делать профессионально. Если на свой креатив не хватает, буржуйские идеи хочется тырить, то хотя бы тырьте и реализовывайте качественно, а не по нашему постсовковому, как придется.
Еще раз прошу прощения, за пост не совсем в тему.

0

Какой то Вы злой

-2

Ну что вы. Максимум нездоровая обостренная педантичность и чуточку цинизма. Вот злости тут вообще ни капли нет.
Если серьезно, просто сайт dev.by мне очень нравится. Пока ребята стараются и внимательны к деталям, все вполне неплохо смотрится, + к их карме.
Кстати, любой адекватный товарищ, прочитав комментарий, просто улыбнется. И если вместо банального copy-paste следующий раз (хоть раз из сотни), вспомнив этот пост, включит голову и постарается придумать что то необычное, то чем он плох? А к самому же тренингу и таким серьезным специалистам, его проводящим, могу относиться только с глубоким уважением, о чем и написал.

1

Очень полезные советы!!!

0

А можно не следовать некоторым советам?

Цитата: "Другое дело, что руководитель не обязан объяснять свои решения подчиненным. Это, конечно, не значит, что он может совсем не отвечать на вопросы - это тоже контрпродуктивно. Просто в некоторых случаях необходимо напоминать, кто кому подчиняется. Особенно это касается чувствительных, жестких или непопулярных решений, таких как, например, увеличение зарплаты или увольнение."

Почему, каждый раз, когда я забивал на объяснение чего-либо программисту из своей комманды (либо недостаточно объяснял), а говорил в итоге "просто сделай", всё это заканчивалось тёрками с вышестоящим начальством, и как следствие - нужно уже было объяснять всё 2 раза и выслушивать начальство "ты с ним по-аккуратнее, он считается ценным специалистом"? Почему-то программисты не любят делать по-другому, если искренне считают, что правильно - именно так как они хотят. Если же добиться полного взаимопонимания, или же вместо - "просто делай" сказать "давай сделаем так, чтобы мы во всём разобрались и не осталось сомнений, почему лучше так или иначе". Это немного относится и к тому, что "каждый программист делает всё по своему" - так тоже пробовали - в итоге получалось, что код просто удаляли и переписывали заново, либо годами пользовались корявыми интерфейсами.

Увеличение зарплаты - здесь вообще без объяснений никак, если конечно, не хочешь, чтобы программист ушел в другое место работать.

"Мы всегда полушутя-полусерьезно говорим, что каждый уважающий себя программист стремится переписать код, оставленный другим программистом. Это не хорошо и не плохо - это жизнь."
Есть программисты, которые всегда пишут в стиле кода, присутствующего на проекте. О рефакторинге даже не думают. И не сказал бы что их так уж и мало.

"стать плохим руководителем и посредственным техническим спецом. Прогресс-то на месте стоять не будет."
Где-то читал, что из хороших программистов получаются плохие руководители и был реально расстроен. У нас в компании - почти все менеджеры - бывшие хорошие программисты (команды 10-20 человек). Которые занимаются обсуждением архитектуры приложения, на лайве могут подправить что-нибудь по-быструхе, в горячую избу войти. И, конечно, в курсе всех последних технологий - трехполье, ворд, эксель :)

0

Просто у менеджера и исполнителей разная информация. Чтобы объяснить решение, нужно поделиться информацией. Это не всегда приемлемо по срокам, это не всегда разрешено.
Объяснять надо задачи ("что ты должен сделать, что я хочу получить"), а не решения ("не начинай делать эту задачу, подожди").
Судя по описанной вами ситуации, когда подчиненные и руководство общаются через вашу голову, либо ваше руководство не достаточно умное, либо оно недостаточно вам доверяет.

0

>>Судя по описанной вами ситуации, когда подчиненные и руководство общаются через вашу голову, либо ваше руководство не достаточно умное, либо оно недостаточно вам доверяет.

Если бы вышестоящий менеджмент так же сказал "просто делай" - вероятность потери разработчика повысилась бы существенно.

>>Просто у менеджера и исполнителей разная информация. Чтобы объяснить решение, нужно поделиться информацией. Это не всегда приемлемо по срокам, это не всегда разрешено.
>>Объяснять надо задачи ("что ты должен сделать, что я хочу получить"), а не решения ("не начинай делать эту задачу, подожди").

Для примера "не начинай делать эту задачу, подожди"

Скорее всего будет так:
- не начинай делать эту задачу, подожди
- ок

В редких случаях:
- не начинай делать эту задачу, подожди
- почему
- заказчик ещё деньги не перечислил

0

Полностью согласен с вами по первому пункту. Говорится, "...руководитель не обязан объяснять свои решения подчиненным". Руководитель не обязан объяснять свои решения подчиненным во время войны )))) Когда время на объяснение приказа критически важно и может привести к пагубным последствиям. Для решения этого вопроса придумали присягу, воинскую обязанность, "звездочки" и т.д. Вот пока ИТ-компании не введут "воинскую повинность", руководитель обязан комментировать свои решения и "корона не упадет" снизойти с небес на грешную землю и пообщаться с подчиненными. Здесь чем меньше в человеке начальника и чем больше руководителя, для дела в общем случае полезнее.
А вот по поводу, когда менеджер (бывший программист) на все руки мастер: и поуправлять, и код, если надо, подправить, здесь очень тонкий момент. Если на самом деле так, и менеджер "пашет" за двоих, полностью справляясь с обязанностями управления, да еще на уровне тех.лида молодняк учит и пожары тушит, то снимаю шляпу, держите его двумя руками и платите ему два оклада - менеджера и разработчика. Но реально, такое возможно гораздо реже, чем кажется и имеет место быть. И это опять же пресловутая проблема инженера выросшего в менеджера. Человек склонен в первую очередь заниматься тем, что умеет, а не тем, что необходимо. Если он не может найти себе задач в сфере управления и его постоянно тянет, что-нибудь "поделать ручками", например, когда при первом удобном случае, он сам лезет править код, а не дает поручение его переделать, встает все тот же вопрос, не потеряли ли мы хорошего программиста приобретя неважного менеджера. "Должность изменилось, сознание не поменялось", как уже здесь писалось.
Все это ещё раз доказывает, любым советам "умных книжек и профи" нельзя слепо следовать. Все очень специфично и требует предварительного "переваривания" при проецировании на свою действительность.

agentcooper
agentcooper PM в SK hynix memory solutions Eastern Europe
0

"Если на самом деле так, и менеджер "пашет" за двоих, полностью справляясь с обязанностями управления, да еще на уровне тех.лида молодняк учит и пожары тушит, то снимаю шляпу, держите его двумя руками и платите ему два оклада - менеджера и разработчика."

Team Lead - менеджер и Tech Lead в одном лице. Очень популярный персонаж и совсем не редкий. В абсолютном большинстве случаев речь при этом идет о небольших командах. Team Lead - развилка в карьере, дальше нужно решать: идти по технической ветке, по менеджерской или остаться тимлидом - профессия сама по себе замечательная и очень ценится, хотя и не позволяет прокачать по полной обе ипостаси. Примерно как в RPG прокачивать одного персонажа и воином и магом.

Через эту позицию проходят практически все пиэмы, попавшие в менеджеры из технарей.

1

"Team Lead - менеджер и Tech Lead в одном лице" - тут, пожалуй, пошел спор о понятиях - если у вас трое подчиненных, это ещё не делает вас менеджером (даже если в трудовой так назовут). Это может удаваться, пока у вас нет действительно серьезной менеджерской загрузки, и пока вы не принимаете действительно сложных решений. На двух стульях сидеть не получится, при таком раскладе неминуемо один из скилов начнет отставать от потребностей.

agentcooper
agentcooper PM в SK hynix memory solutions Eastern Europe
1

"если у вас трое подчиненных, это ещё не делает вас менеджером"

Пиэмом становятся тогда, когда
а) берут на себя ответственность за результат (проекта или его части).
б) начинают заниматься пиэмскими задачами - PMBOK определяет 9 областей знаний: Integration, Scope, Time, Cost, Quality, Human Resources, Communications, Risk and Procurement.

Пиэмом (и очень высокого класса) можно быть вообще без подчиненных или с командой минимального размера. Лет 10 назад я в качестве технического эксперта (менеджером я на тот момент был и сам, но не слишком опытным) некоторое время работал в команде из двух человек - PM и я. Это был presales-проект для Renault - мы готовили старт более крупного проекта. Я рожал технические идеи и доказывал их технарям заказчика. Бруно занимался планированием, рисками, политическими аспектами - всем тем, чем и должен заниматься PM. Проект был достаточно сложен организационно и свой хлеб он отрабатывал по полной.

"На двух стульях сидеть не получится, при таком раскладе неминуемо один из скилов начнет отставать от потребностей."

Получится, если не увеличивать масштаб задач. Тимлид команды из 8-10 человек скорее всего не сможет сразу возглавить большой и сложный проект или департамент. И не сможет сразу выступить архитектором/техлидом большого продукта. Зато при управлении небольшой командой и/или проектом он более эффективен чем связка пиэм/архитектор и/или tech. lead - потому что может совмещать обе роли, сильно уменьшая затраты (коммуникационные прежде всего) на управление.

0

Не могу не плюсануть за такой красивый ответ.

0

Года 4 назад, на первом проекте, который я манагерил, - у меня в команде был один человек - я сам :)

agentcooper
agentcooper PM в SK hynix memory solutions Eastern Europe
0

Так и должно быть - редко кто доверит управлять людьми человеку, не проверив вначале может ли он управлять хотя бы собой :) .

1

"Другое дело, что руководитель не обязан объяснять свои решения подчиненным"
Думаю, эта фраза вполне могла появится только из-за того, что это рекламная статья. Мол давайте в менеджеры, вам не нужно ничего будет никому объяснять. Хотя нужно будет объяснить заказчику, почему девелопер сказал, что интеграция с АПИ оценена в 60 часов, когда в мануале написано, что это занимает не более получаса. Потом объяснять почему девелопер не уложился в свою оценку и синтегрировал за 80 часов. Ну и объяснения девелоперу, почему зп у него не 2000 баксов, когда он месяц назад пришел в компанию на 500, и, конечно же по рабочим моментам.

Понятно, что если у менеджера в команде 3 человека - он может и попрограммировать. Если 10 - уже врят ли. Но участия в обсуждении архитектуры приложения, использования каких-то технологий - только поможет. Хотя бы будет легче объяснять, почему оценка на таск 60 часов а не 15 минут. Если 100 человек команда - тут уже не знаю :) Может тогда и сработает: "стать плохим руководителем и посредственным техническим спецом. Прогресс-то на месте стоять не будет.", но кто плохому руководителю даст 100 человек (в IT сфере, конечно ;))?

0

Отличная статья, жаль что обрывается на самых интересных местах, но ведь реклама же.
За два или три дня тренер, конечно же, не обучит ВСЕМУ, но поможет повернуть мозги в нужное русло. Учиться, в конечном счете, каждому приходится самостоятельно.
Специальных знаний для прохождения тренинга не требуют наверное потому, что тренинг рассчитан на практиков, а большинство практиков у нас вырастает из технических специалистов. Что им следует знать, расскажут, а теоретические тонкости, кому интересно, поищут уже сами.
Что касается цены - лично для меня дорого, но для бывшего лидпрогера, которого выдвигают на руководящую должность, или действующего PM'a вполне подъемная цифра.

agentcooper
agentcooper PM в SK hynix memory solutions Eastern Europe
0

"Что касается цены - лично для меня дорого, но для бывшего лидпрогера, которого выдвигают на руководящую должность, или действующего PM'a вполне подъемная цифра."

Редко кто сам платит за такие тренинги - как правило платят компании (иногда частично). Самому подписываться - я бы не советовал. IMHO для самоподготовки лучше подходит чтение хорошей литературы и прослушивание бесплатных вэбинаров. За свои деньги я бы рекомендовал слушать человека, который априори является для вас авторитетом (кто бы сюда привез Боэма или Брукса или Крачтена). Либо тренинг, который дает не знания, а навыки (например переговорные) - то, что по книгам берется плохо. Либо специальный тренинг при подготовке к какой-нибудь сертификации. На "просто тренинги" раскалывайте работодателей :) .