Comments 110
Честно говоря, я не понимаю, почему многие противопоставляют скилл программирования у менеджера другим скиллам. Т.е. если он вдруг умеет программировать, то он перестанет уметь думать, управлять, понимать особенности продукта, общаться с заказчиком, <впишите ещё какой-то более важный скилл для менеджера>?
Конечно же, навык программирования у менеджера в ИТ вторичен. Но если он есть, то он действительно в ряде кейсов повышает эффективность менеджера, поэтому воспринимать его в штыки не нужно.
Конечно же, навык программирования у менеджера в ИТ вторичен. Но если он есть, то он действительно в ряде кейсов повышает эффективность менеджера, поэтому воспринимать его в штыки не нужно.
можно примеры где программирование полезно менеджеру
Например в разговоре с заказчиком
нее там программирование не нужно, чтоб отбривать тупые и слишком сложные для данного бюджета идеи нужен архитектор/лид который скажет сколько будет стоить ещё одна кнопочка которая делает всё хорошо, менеджер об этом не знает, а потому может пообещать сделать то что ему кажется просто ведь он же умеет «программировать»
Именно там и оно и пригодится. Менеджер в идеале сам должен адекватно оценивать объем и стоимость работ, а не доверять в этом архитектору/лиду. Обсуждение условий с заказчиком, это его непосредственная ответственность и квалификация, а не техлида. Тем более что интересы техлида нередко противоположны интересам заказчика, а точка сделки будет где-то посередине. И хороший менеджер знает, где заказчик пытается занизить цену, а где техлид завышает оценку, и заставляет обоих идти на компромисс. Но чтобы это сделать, ему действительно нужно понимать хотя бы в общих чертах, что и как будет делаться в рамках данного технического задания.
всё конечно зависит от сложности продукта, там где раз, раз и в продакшен и самый опытный девелопер это всё таки ещё джуниор тогда знание программирования на просто необходимо чтоб ускорить процесс, накидал быстренько ТЗ и отдал делать, программист уже по шаблону залепит всё что надо и можно в продакшен пихать, а там где программисты делают более сложные штуки желание менеджера оценить задачу исходя из своих знаний приводит всегда к проблемам, для менеджера важнее выяснить важность поставленной задачи от клиента, чтоб он мог так сказать совершить сделку между технической частью и бизнесом, а не потакать клиенту с любыми просьбами лишь бы тот денег дал, а там программисты как-нибудь справятся, хаков налепят если нужно, проект то большой одним хаком больше одним меньше, ещё и на суппорте можно заработать…
Вы правы. Но сделка — это почти всегда компромисс. Её не нужно перегибать ни в сторону заказчика, ни в сторону программистов. Заказчику свойственно необоснованно занижать сроки и стоимость, тимлидам/архитекторам — наоборот, завышать, причём тоже зачастую без веских оснований. Про программистов я обобщений делать не буду, тут бывает зоопарк мнений, от «да я сегодня сделаю» (для задачи, которую по факту он будет неделю в запарке решать) до «ну, недели две» (для задачи, которую он сделает за полдня).
Т.е. нужно таскать с собой на встречу с клиентом ещё и «кузнеца» тимлида? Или встречаться итерационно: М+З, М+ТЛ, М+З, М+ТЛ… пока не придёт взаимопонимание?
Поверьте, если вы как менеджер, будете в переговорах использовать программирование, вместо переговорных навыков и навыков управления заказчиком, пролетите вы очень быстро.
Пример — у нас был подрядчик, с менеджером, который очень хорошо разбирался в предметной области (не разраб, а скорее консультант).
Он круто объяснил нашей команде на встрече что к чему, мы не все поняли, и не стали окать решение. Вместо того что бы додавить нас, и направить нам письменно решение о выборе функционала со сроками ответа, он положился на наше «Ну казалось бы мы ок».
Когда пришле время вставлять решение в документацию — мы написали что мы не ок, и просим дополнить документ 100500 схем, таблиц и описаний.
Менеджер в шоке позвонил — мы же договаривались до другого? Мы сказали что не договаривались ни до чего, наше «казалось бы ок», не значит что мы подписываемся под чем то. По договору вы должны документ с нашими хотелками — это наша хотелка. То, что вы не запросили и не задокументировали решение (хотя бы в почте, не говоря уж про протокол встречи и его согласование) — проблема вас, как менеджера, за вас это никто не сделает.
А был бы вместо него нормальный менеджер, который бы просто прислал протокол в почте — с запросом на согласование или обозначением, что если замечаний в течении 2 рабочих дней нет, протокол считается согласованным, переговорная позиция подрядчика была бы совсем другая )))
Пример — у нас был подрядчик, с менеджером, который очень хорошо разбирался в предметной области (не разраб, а скорее консультант).
Он круто объяснил нашей команде на встрече что к чему, мы не все поняли, и не стали окать решение. Вместо того что бы додавить нас, и направить нам письменно решение о выборе функционала со сроками ответа, он положился на наше «Ну казалось бы мы ок».
Когда пришле время вставлять решение в документацию — мы написали что мы не ок, и просим дополнить документ 100500 схем, таблиц и описаний.
Менеджер в шоке позвонил — мы же договаривались до другого? Мы сказали что не договаривались ни до чего, наше «казалось бы ок», не значит что мы подписываемся под чем то. По договору вы должны документ с нашими хотелками — это наша хотелка. То, что вы не запросили и не задокументировали решение (хотя бы в почте, не говоря уж про протокол встречи и его согласование) — проблема вас, как менеджера, за вас это никто не сделает.
А был бы вместо него нормальный менеджер, который бы просто прислал протокол в почте — с запросом на согласование или обозначением, что если замечаний в течении 2 рабочих дней нет, протокол считается согласованным, переговорная позиция подрядчика была бы совсем другая )))
Поверьте, если вы как менеджер, будете в переговорах использовать программирование, вместо переговорных навыков и навыков управления заказчиком, пролетите вы очень быстро
Речь шла не про «вместо», а «вместе с»
Не уверен, что эти инструменты нельзя противопоставить.
Когда ты на переговорах показываешь экспертизу — это не всегда сыграет в твою пользу, ибо ты сказал «Ага, я немного разбираюсь в БД, эти работы должны стоить дороже», а тут вышел датабэйс-девелопер (которого неделю назад переманили из яндекса) и твою точку зрения разложил и обосновал меньшую цену.
Если бы ПМ не сказал «Я разбираюсь» — можно было бы просто взять таймаут. Тут же заказчик будет давить «Вы же сказали что у вас есть экспертиза и потратили наше время на ваши объяснения, а когда мы привели аргументы вы теперь берете таймаут? Это стиль работы вашей компании?».
Навык лишний конечно не помешает. Но это не значит что надо в переговорах с пациентами этими навыками аппелировать, особенно когда ты не полностью в теме. Занимайтесь своим делом, и тем, что вы знаете профессионально. Разраб не лезет в менеджмент проектов, водитель такси не лезет в политику, патологоанатом не лезет лечить людей, и т.д.
Когда ты на переговорах показываешь экспертизу — это не всегда сыграет в твою пользу, ибо ты сказал «Ага, я немного разбираюсь в БД, эти работы должны стоить дороже», а тут вышел датабэйс-девелопер (которого неделю назад переманили из яндекса) и твою точку зрения разложил и обосновал меньшую цену.
Если бы ПМ не сказал «Я разбираюсь» — можно было бы просто взять таймаут. Тут же заказчик будет давить «Вы же сказали что у вас есть экспертиза и потратили наше время на ваши объяснения, а когда мы привели аргументы вы теперь берете таймаут? Это стиль работы вашей компании?».
Навык лишний конечно не помешает. Но это не значит что надо в переговорах с пациентами этими навыками аппелировать, особенно когда ты не полностью в теме. Занимайтесь своим делом, и тем, что вы знаете профессионально. Разраб не лезет в менеджмент проектов, водитель такси не лезет в политику, патологоанатом не лезет лечить людей, и т.д.
Отсутствие протокола и фиксации договорённости вообще не связано с навыками программирования.
Напрямую — да.
Но вообще, вот ехал как раз и думал — а разработчику надо уметь менеджерить проекты? )
Кто то согласен доплачивать разрабу, за то что он менеджерил какие то проекты?
Но вообще, вот ехал как раз и думал — а разработчику надо уметь менеджерить проекты? )
Кто то согласен доплачивать разрабу, за то что он менеджерил какие то проекты?
Но вообще, вот ехал как раз и думал — а разработчику надо уметь менеджерить проекты?
И да после того, как я поработал менеджером и вернулся обратно в разработку — я гораздо лучше стал понимать и заказчиков и менеджеров.
Скажу более — стал гораздо лучше понимать: а зачем вообще нужно то, что я программируют, как на это смотрит заказчик, какие у него приоритеты и пр. и пр.
Есть две позиции: моя хата с краю, в должностных обязательствах у меня этого нету и делать я это не буду
И — вовлечённость в работу, когда ты понимаешь, что хотя должность называется иначе, но без твоей помощи не обойдётся — и готов её оказывать.
Первый приводит к нормальным результатам только если организация процессов оооочень хорошая.
Вторая подразумевает, что тимлиду приходится иногда менеджерить.
Но почему за это нужно доплачивать, если обходится без переработок?
Так-то, у тимлида зп обычно не меньше, чем у менеджера (а то и побольше)
Есть две позиции — у меня в должностных обязанностях есть организация процессов, и я занимаюсь ей и только ей. Поэтому она у нас оооочень хорошая.
Если будет оставаться значительное время, которое я не захочу потратить на саморазвитие — пожалуй, буду участвовать еще где то (но 99,9% такого не будет).
Вторая — это я возьмусь за все подряд, что то получится лучше, что то хуже — фиг с ним. Тут вот бардак и кроется.
Процессы хорошие можно наладить — можно, было бы у руководства компании желание.
Обычно да у ТЛ больше, но у тимлида обычно за квалификацию ЗП.
Если тимлид будет вместо повышения квалификации заниматься менеджментом, на рынке ему будет себя тяжелее продать, чем тимлиду, который занимался саморазвитием в плане разработки/архитектуры вместо менеджмента.
Если будет оставаться значительное время, которое я не захочу потратить на саморазвитие — пожалуй, буду участвовать еще где то (но 99,9% такого не будет).
Вторая — это я возьмусь за все подряд, что то получится лучше, что то хуже — фиг с ним. Тут вот бардак и кроется.
Процессы хорошие можно наладить — можно, было бы у руководства компании желание.
Обычно да у ТЛ больше, но у тимлида обычно за квалификацию ЗП.
Если тимлид будет вместо повышения квалификации заниматься менеджментом, на рынке ему будет себя тяжелее продать, чем тимлиду, который занимался саморазвитием в плане разработки/архитектуры вместо менеджмента.
Есть две позиции — у меня в должностных обязанностях есть организация процессов, и я занимаюсь ей и только ей.
Это называется формализм. Это нормально работает, когда
а) процесс типовой и отлаженный.
б) при этом всё хорошо, все ключевые сотрудники на местах и доступны, нештатных ситуаций нет, нестандартных решений принимать не нужно.
Но любой сбой, и такая схема разваливается. Сотрудники, привыкшие к работе по узким должностным обязанностям, включают, как я это называю, синдром детского паровозика. Знаете, когда он упирается в стенку? Стоит на месте и непрерывно: «Чух-чух-чух!»
Чух-чух-чух, это не моя ответственность. Чух-чух-чух, я отправил запрос неделю назад, ожидаю ответа, задержка не по моей вине. Чух-чух-чух, согласуйте задачу с А, Б и С. Б на больничном, заместитель Б в командировке? Ну тогда давайте подождем.
И как бы вы не старались, что бы вы не сделали, у вас нет возможности избежать таких ситуаций при строгой формализации. Вот поэтому крупные компании настолько неповоротливы в принятии решений и в реализации проектов.
И тут даже нет смысла приводить успешные кейсы. Они есть, но их на общем плане настолько мало, что их даже неловко объяснять успешным руководством, это просто удача.
Да, на противоположной стороне находится тот самый бардак, когда все хватаются за всё, и нельзя найти ответственного. Но оптимальная схема, она как раз где-то посередине между полюсами. Когда есть и прописанные процессы/обязанности, и запас гибкости в системе.
Это называется формализм. Это нормально работает, когда
а) процесс типовой и отлаженный.
б) при этом всё хорошо, все ключевые сотрудники на местах и доступны, нештатных ситуаций нет, нестандартных решений принимать не нужно
У кого-то в должностных обязанностях будет написано «разобраться в проблеме и сделать\доработать инструкцию для решения проблемы» и никакого «чух-чух-чух» не будет.
Просто у нас очень часто подход «если придумал не правильное решение — будем наказывать» Вот если бы ты подождал, то…
Все крепки задним умом.
Или вы предлагаете прогаммисту считать НДС при растаможке вместо главбуха (болеет), только на том основании, что он когда-то писал такой код?
Много кому лечили зубы, все «знают» как сверлить пломбировать (на себе все проверили). Давайте зубы по этому приниципу лечить? Апендицит резать?
Программист не знающий всех нюансов предметной области в медицине сам «улучшит» код, ведь аналитик то болеет…
Где граница — сюда лазить не стоит? Не зря должностые инструкции написаны. Не кровью (как техника безопастности), но, думаю, «отсидками» точно…
P.S. Где-то читал, что было правило при проведении трибунала: при рассмотрении дела обязаны были исходить только из той информации, что была доступна обвиняемомую в момент совершения действия или бездействия
В какой то цикл мы уже уходим — что бы нормально отладить процессы, надо что бы процессы отладки были отлажены.
В любом случае — абсолютно идеально описать процессы нельзя, на 99,99999 можно — но на 100 — нельзя.
Но это не значит, что можно их не описывать.
Чух-чух — это не моя ответственность — а чья — ага, это за Васей — чух-чух.
Чух-чух — это не моя ответственность — а чья — ага, не знаю — шеф у нас проблема — чух-чух.
Пример с А — Б — очень простой — кидаем Б запрос на согласование, в котором пишем, что если в течении 24 часов не придет ответ — считается согласованным. Б отвечает — прекрасно, Б не отвечает — еще лучше.
Или вы считаете что ПМ который берет на себя обязательства, которые заранее выполнить не может — хороший?
Успешных кейсов — мало, но надо следовать именно им. Ибо равняться всегда надо на вершину. А если говорить, ну ладно, у них тоже днище — проект не сделать. Это бизнес, это проекты, тут не ждут тех кто в командировке, и здесь не работают те, кто не умеет быстро договорится (по крайней мере за разумные деньги).
Крупные компании в реализации проектов неповоротливы? Ничего себе… а кто тогда проекты то все делает? ИПшники?
В любом случае — абсолютно идеально описать процессы нельзя, на 99,99999 можно — но на 100 — нельзя.
Но это не значит, что можно их не описывать.
Чух-чух — это не моя ответственность — а чья — ага, это за Васей — чух-чух.
Чух-чух — это не моя ответственность — а чья — ага, не знаю — шеф у нас проблема — чух-чух.
Пример с А — Б — очень простой — кидаем Б запрос на согласование, в котором пишем, что если в течении 24 часов не придет ответ — считается согласованным. Б отвечает — прекрасно, Б не отвечает — еще лучше.
Или вы считаете что ПМ который берет на себя обязательства, которые заранее выполнить не может — хороший?
Успешных кейсов — мало, но надо следовать именно им. Ибо равняться всегда надо на вершину. А если говорить, ну ладно, у них тоже днище — проект не сделать. Это бизнес, это проекты, тут не ждут тех кто в командировке, и здесь не работают те, кто не умеет быстро договорится (по крайней мере за разумные деньги).
Крупные компании в реализации проектов неповоротливы? Ничего себе… а кто тогда проекты то все делает? ИПшники?
Чух-чух — это не моя ответственность — а чья — ага, не знаю — шеф у нас проблема — чух-чух.
Именно. Шеф и юридическая или финансовая ответственность — акции, собрание акционеров, банкротство.
Если у вас есть голосующие акции — вы такой-же Шеф, если нет — то вы «сервис».
А мнение «сервиса» нафиг никому не нужно (если это не его работа советовать).
Не очень понятно, почему МТС и Lenovo мне должны советовать как правильно «красить облака», тем более что их совета не спрашивали.
В любом случае — абсолютно идеально описать процессы нельзя, на 99,99999 можно — но на 100 — нельзя.
Если мне не изменяет память, то книги по экономике 19 начала 20 века упоминали изменчивость окружения (клиенты, конкуренты, форс-мажор) и готовность к реакции и адаптации к этим изменениям.
Таков мир.
А разве я говорю, что не надо менять процессы? Надо, процессы идеальными бывают редко больше 1 недели ))) Но несущественные изменения вносятся по ходу — именно поэтому в компаниях есть вики-системы где лежат регламенты.
Про шефа — в корне не соглашусь, есть лица, принимающие решения по определенным вопросам не просто так.
Вы такой же шеф, но пример — у вас есть CR который затрагивает спонсора, вы принимаете по нему решение, оно правильное, но спонсор будет несколько в афиге как минимум. Минимум — предупредить его, нормальный ход — написать письмо с описанием решения и просьбой подтвердить.
А брать все на себя — подход в мелких компаниях или шарагах.
Про шефа — в корне не соглашусь, есть лица, принимающие решения по определенным вопросам не просто так.
Вы такой же шеф, но пример — у вас есть CR который затрагивает спонсора, вы принимаете по нему решение, оно правильное, но спонсор будет несколько в афиге как минимум. Минимум — предупредить его, нормальный ход — написать письмо с описанием решения и просьбой подтвердить.
А брать все на себя — подход в мелких компаниях или шарагах.
Тимлид, который не умеет менеджерить управлять вообще себя не продаст как тимлид, по крайней мере там, где понимание обязанностей тимлида классическое, где его основная ответственность вести команду к достижению поставленных перед нею задач.
Да, он может быть самым квалифицированным разработчиком в команде и при достаточной квалификации, самоорганизованности и мотивированности команды бОльшую часть времени заниматься непосредственно разработкой (или тащить почти все задачи команды на себе, если команда так себе), но в целом это не обязательно. Для архитектурных решений, сложных технических задач, менторства и т. п. есть ведущие разработчики, техлиды, архитекторы, а тимлид — должность прежде всего менеджерская, team manager можно её назвать. Сильно пересекается по обязанностями с project/product manager в области управления командой в случае "одна команда — один проект/продукт", но вот в других случаях разница становится заметной: тимлид непосредственный начальник членов команды, а ПМы — или начальники начальника для них, или внутренний заказчик, а тимлид — "прокси", "адаптер" между бизнесом и командой.
Да, всякое бывает в реальности, где-то гендир/CEO, например, может подойти к любому разработчику (через 3+ уровне иерархии) и сказать ему срочно переключиться на что-то "нужно было вчера" без чёткой постановки задачи, а потом отчитывать тимлида за то, что другие задачи вовремя не сделаны. Но в целом основная обязанность тимлида — это руководство командой, а не применение технических знаний и навыков.
Менеджерить уметь наверно не нужно, но быть «в теме» — стоит. Как минимум чтобы отличать нормальный менеджмент от не очень нормального, ну и на своем уровне какие то решения принимать.
Никогда не поверю.
И Роберт Чалдини тоже.
И Роберт Чалдини тоже.
В оригинальной статье смешивается навык программирования и опыт работы программистом.
Навык программирования — это макросы и прочая автоматизация рутинных задач, то чем должен обладать продвинутый/опытный пользователь, что позволяет эффективно пользоваться компьютером. Менеджер — совершенно не исключение. Этим навыкам довольно быстро овладевают даже представители явно творческих профессий, потому что избавляют их от бездумного кнопконажимательсва.
А опыт «промышленной» разработки ему не требуется — это явно не этап профессионального развития управленца.
Навык программирования — это макросы и прочая автоматизация рутинных задач, то чем должен обладать продвинутый/опытный пользователь, что позволяет эффективно пользоваться компьютером. Менеджер — совершенно не исключение. Этим навыкам довольно быстро овладевают даже представители явно творческих профессий, потому что избавляют их от бездумного кнопконажимательсва.
А опыт «промышленной» разработки ему не требуется — это явно не этап профессионального развития управленца.
можно примеры где программирование полезно менеджеру
В статье именно это и описано довольно хорошо.
Менеджер оторванный от реалий того, что может сделать программист, и потому подходит фантастично VS Менеджер, который знаком с программированием не по наслышке, и потому подходит реалистично.
как раз таки наоборот в этой статье ни слова про умение программировать, как правильно написал Busla чуть выше, менеджер должен уметь программировать на уровне автоматизации своих менеджерских процессов, нехер лезть туда где ты не специалист, а если и бывший специалист то тогда менеджерские качества у таких «менеджеров» обычно никакие, очень немногие могут преуспеть с столь разных областях сразу, но мы явно не из них иначе бы эту статью не читали
нехер лезть туда где ты не специалист
об этом уже написано в самой статье. зачем вы повторяете?
давайте я вам пожую свою мысль:
зачем нужны программистские навыки менеджеру — чтобы ориентироваться.
и это тоже очень хорошо изложено в самой статье.
человек первый раз вошел в менеджеры и не смог найти общего языка с программистами.
сделал выводы, подучился программистской специфики.
и вошел второй раз в менеджеры.
мне правда непонятно зачем этот тут пережевывать по многу раз в комментариях — в самой статье именно это уже описано.
Делайте свою работу, программисты и инженеры сделают свою сами
Вероятно, ответ кроется в этом. Вопрос в том, как менеджер использует этот навык. Если начинает не доверять технической команде и начинает проверять их архитектурные решения чтобы точно убедиться что они верно понимают задачу, тогда это, вероятно, вредит процессу больше, чем приносит пользу, потому что это растрата ресурсов, и вероятное негодование со стороны команды. Еще хуже, когда менеджер начинает продавливать (именно продавливать, не предлагать) свои технические решения.
Как вы видите повышение эффективности менеджера если он знает программирование?
У него всегда под рукой должен быть тех. лид команды или архитектор для больших или важных встреч, поэтому ему эти навыки в целом почти не нужны, для этого есть другие люди из его команды.
Как вы видите повышение эффективности менеджера если он знает программирование?
Менеджеру это скорее полезный навык, позволяющий повысить положительные риски и понизить отрицательные. Команда и технологии — это инструмент менеджера и он обязан их хотя бы понимать.
К примеру — корректно проектными метриками оперировать. Корректно понимать жизненный цикл решения. Корректно организовать работу с проектной документацией.
Корректно посчитать бюджет проекта.
Корректно объяснить Клиенту «почему именно так» и «что будет если ...».
Когда приходит менеджер проекта и говорит — я уже пообещал что «мы ЭТО сделаем к....» — это просто ()o().
Хотя бы что бы понимать, куда ему самому не стоит лазить без команды. Если менеджер проекта сможет просмотреть проектную документацию и найдет там проблемы, хотя бы на уровне не покрытого или противоречивого требования — вообще будет хорошо.
Управлять рисками можно с помощью управления рисков.
Если менеджер не способен из каждого участника команды выжать возможные риски и правильно их оценить, значит он должен разбираться во ВСЕЙ области проекта.
Внедряешь 1С — знай весь бухучет, федеральные законы по учету, законы по выплате ЗП, правила аудита, программирование, системное администрирование (WinSrv, unix; PosgreSQL, MS SQL), базы данных, сети. Не хилый такой ПМ получается.
Если ХОРОШИЙ ПМ обещал что то заказчику — значит этот CR он обработал заранее, согласно процедуре управления изменениями, в которой должны быть прописаны люди, которых решение затрагивает и от них было получено согласие, после чего обещание было озвучено заказчику.
Если менеджер считает что процедуру управления изменениями придумали бюрократы из PMI, а заказчику можно обещать вот так, на свое усмотрение — видимо, у вас плохой, негодный менеджер — аналог такого менеджера, это разраб, который код в релиз самовольно дописал и никому не сказал, а потом пришел и сказал — «я уже включил это в релиз, да ни тестирование, ни релиз-менеджер, ни ПМ, ни заказчик, ни аналитика не в курсе».
Если менеджер не способен из каждого участника команды выжать возможные риски и правильно их оценить, значит он должен разбираться во ВСЕЙ области проекта.
Внедряешь 1С — знай весь бухучет, федеральные законы по учету, законы по выплате ЗП, правила аудита, программирование, системное администрирование (WinSrv, unix; PosgreSQL, MS SQL), базы данных, сети. Не хилый такой ПМ получается.
Если ХОРОШИЙ ПМ обещал что то заказчику — значит этот CR он обработал заранее, согласно процедуре управления изменениями, в которой должны быть прописаны люди, которых решение затрагивает и от них было получено согласие, после чего обещание было озвучено заказчику.
Если менеджер считает что процедуру управления изменениями придумали бюрократы из PMI, а заказчику можно обещать вот так, на свое усмотрение — видимо, у вас плохой, негодный менеджер — аналог такого менеджера, это разраб, который код в релиз самовольно дописал и никому не сказал, а потом пришел и сказал — «я уже включил это в релиз, да ни тестирование, ни релиз-менеджер, ни ПМ, ни заказчик, ни аналитика не в курсе».
Противопоставлять скиллы, это всё равно как спорить: жене нужно лучше готовить или лучше воспитывать детей. Философски (т.е. вообще) — это глупый и ненужный спор. Предметный же, к конкретной ситуации и по конкретному человеку, то — чего ему не хватает, то и нужно подтягивать. Остальное — пусть будет. Рано или поздно понадобится.
> Учитесь писать ТЗ и переводить с языка заказчика на язык задачи… техническое задание, которое можно будет согласовать, подписать и приступить к работе.
В этом вся разница между вашей и оригинальной статьёй. Её писали в Яндексе, а там нет такого, чтобы менеджер замыкал общение с «заказчиком» (внутренний заказчик — тоже заказчик) или пользователем на себя. А потом спускал кодерам готовое ТЗ (я начальник, ты дурак).
По моим ощущениям, разработчики (как минимум лиды) всегда принимают участие в выработке ТЗ, понимании потребностей, даже формулировке. То есть берут на себя какую-то частичку менеджерской задачи. Значит и менеджерам не зазорно немного окунуться в код, чтобы быть на одной волне со своей командой.
В этом вся разница между вашей и оригинальной статьёй. Её писали в Яндексе, а там нет такого, чтобы менеджер замыкал общение с «заказчиком» (внутренний заказчик — тоже заказчик) или пользователем на себя. А потом спускал кодерам готовое ТЗ (я начальник, ты дурак).
По моим ощущениям, разработчики (как минимум лиды) всегда принимают участие в выработке ТЗ, понимании потребностей, даже формулировке. То есть берут на себя какую-то частичку менеджерской задачи. Значит и менеджерам не зазорно немного окунуться в код, чтобы быть на одной волне со своей командой.
Навык программирования по идее делает менеджера экспертом. Если этот менеджер занимается продвижением IT-технологий, то этот навык даст ему дополнительное более глубокое понимание продукта и его возможностей, и как следствие, уровень компетенции. Это неизменно должно привести к более эффективной работе. Лично мое мнение.
Есть ли уверенность, что человек 1-2 года занимавшийся разработкой на Дельфи, будет экспертом, начав управлять в компании использующей Java-стек?
Эффективность проектного менеджера в моем понимании — более быстрое и дешевое достижение проектных целей, в т.ч. в долгосрочной перспективе. Для этого надо коучить команду оценивать и кодить, а не оценивать и кодить самому.
Эффективность проектного менеджера в моем понимании — более быстрое и дешевое достижение проектных целей, в т.ч. в долгосрочной перспективе. Для этого надо коучить команду оценивать и кодить, а не оценивать и кодить самому.
Одно из качества ПМа это лидерство.
Чтобы проявиться это качество в команде разработчиков, нужно знать, как разработчики выбирают лидеров.
Понимание, таких, казалось бы простых вещей, приходит с опытом или после прочтения правильной литературы.
P.s. да, и разработчики лидером считают, явно не того, кто круче «коучит» команду.
Чтобы проявиться это качество в команде разработчиков, нужно знать, как разработчики выбирают лидеров.
Понимание, таких, казалось бы простых вещей, приходит с опытом или после прочтения правильной литературы.
P.s. да, и разработчики лидером считают, явно не того, кто круче «коучит» команду.
Все верно, команду «коучить» не просто мало ))) Важно уметь разруливать ситуации, брать на себя (и требовать с других) ответственность, уметь договариваться, говорить нет, иметь иметь хороший опыт подобной работы в ИТ и проектах и т.д. и т.п.
А сейчас 80% ПМов что я вижу — могут только «накоучить» команду. Не редко до того, что команда идет на hh.ru от такого руководителя, и часто до того, что проект перестает быть проектом и начинает быть обузой для компании.
А сейчас 80% ПМов что я вижу — могут только «накоучить» команду. Не редко до того, что команда идет на hh.ru от такого руководителя, и часто до того, что проект перестает быть проектом и начинает быть обузой для компании.
UFO just landed and posted this here
Учитесь писать ТЗ и переводить с языка заказчика на язык задачи.
В RegionSoft нет аналитиков?
Вообще-то мне правда интересно. Из текста следует, что менеджер пишет ТЗ и передает его разработчикам. Навык полезный, конечно, не спорю. Но сколько ТЗ может написать один менеджер и где его аналитики?
Почему же пишет и передаёт? С ТЗ может работать не один человек. Всё же интеграционные проекты — большая и сложная история, это вам не пару мест в браузере открыть. Всё пишем, всё успеваем, сроки не факапим, никто не жаловался. Остальные подробности раскрыть не могу :-)
Жаль, что не можете, вроде не самый страшный секрет.
Я могу. В RegionSoft менеджеры никогда не писали ТЗ, поскольку это не их компетенция. ТЗ пишут постановщики задач, которые являются экспертами в области как бизнес-процессов, так и стека технологий. ТЗ пишется в процессе предпроектного обследования предприятия, которое планируется автоматизировать, либо после этого обследования. В этом процессе обычно принимают участие эксперты и представители группы разработки. При необходимости могут быть подключены и менеджеры, но исключительно для целей ориентации в потребностях заказчика. По факту готовности ТЗ и согласования его с заказчиком, оно передается в группу разработки, где над его реализацией работают программисты.
Я разработчик. Если я даю менеджеру обратную связь о блокировках в тасках, техническом долге, новых проблемах, предлагаю очевидные технические улучшения, в общем, делаю все, чтобы повысить эффективность, то я — хороший разработчик. Я проявляю обычную, очевидную инициативу и всем в итоге лучше. Менеджер может делать то же самое, только с другой стороны. Самый простой пример — отсутствие блокирующих тасков. Пример посложнее — уменьшить переключение контекстов разработчиками.
Умение программировать и понимание особенностей процесса изнутри — не может быть лишним. Это абсолютно очевидно. Нужно это конкретному менеджеру или нет — пусть сам решает.
Умение программировать и понимание особенностей процесса изнутри — не может быть лишним. Это абсолютно очевидно. Нужно это конкретному менеджеру или нет — пусть сам решает.
Я менеджер.
Я ставлю задачи разработчику, и они либо сделаны, либо нет.
Если они не сделаны, это плохо — первое, что я сделаю — я посмотрю, правильно ли я их поставил. Если нет — будут работать над постановкой, если да — узнаю у разработчика, почему мы сделали задачи плохо.
Сделать задачи плохо по моему мнению можно по трем причинам — недостаток планирования, недостаток исполнителя, внешние факторы. Первое я уже рассмотрел выше — мне остается понять, недостаток ли это исполнителя или внешние факторы. Если внешние — моя задача их убрать (например, разраба отвлекает другой ПМ — я поговорю с ним на предмет разделения времени, а так же обращусь к руководству с проблемой политики разбиения ресурсов на мелкие части).
Если это проблема исполнителя я буду искать причину — может он недостаточно квалифицирован (надо научить или перевести на другую работу, анализируя почему я дал ему задачу не соответствующую квалификации) или мотивирован (например разраб думает на работе вместо задач о том, что бы найти место пожирнее — моя задача понять мотивацию и подумать что он может сделать для компании, что бы мы платили ему много, а он приносил нам максимальную пользу).
Если наоборот, разработчик приходит ко мне с инициативами или решенными задачами, раньше сроков и в меньшие часы — для меня это сигнал, что я обладаю ценным ресурсом и моя задача аккуратно удержать его, следя за тем, что бы он не перегорел. А так же понять его мотивацию и передать ее другим участникам команды.
Зачем мне нужно умение программировать здесь? Что бы тыкать разраба что он не уложился в тайминг, вместо того что бы понять, почему мы пролошились с оценкой задачи, или почему сотрудника на другой проект выдергивает другой менеджер (не умеющий програмировать).
Потыкаю я его 2-3 раза, он свалит к конкурентом, посоветовав мне воспользоваться моим «умением программировать» что бы допилить проект самостоятельно.
Я ставлю задачи разработчику, и они либо сделаны, либо нет.
Если они не сделаны, это плохо — первое, что я сделаю — я посмотрю, правильно ли я их поставил. Если нет — будут работать над постановкой, если да — узнаю у разработчика, почему мы сделали задачи плохо.
Сделать задачи плохо по моему мнению можно по трем причинам — недостаток планирования, недостаток исполнителя, внешние факторы. Первое я уже рассмотрел выше — мне остается понять, недостаток ли это исполнителя или внешние факторы. Если внешние — моя задача их убрать (например, разраба отвлекает другой ПМ — я поговорю с ним на предмет разделения времени, а так же обращусь к руководству с проблемой политики разбиения ресурсов на мелкие части).
Если это проблема исполнителя я буду искать причину — может он недостаточно квалифицирован (надо научить или перевести на другую работу, анализируя почему я дал ему задачу не соответствующую квалификации) или мотивирован (например разраб думает на работе вместо задач о том, что бы найти место пожирнее — моя задача понять мотивацию и подумать что он может сделать для компании, что бы мы платили ему много, а он приносил нам максимальную пользу).
Если наоборот, разработчик приходит ко мне с инициативами или решенными задачами, раньше сроков и в меньшие часы — для меня это сигнал, что я обладаю ценным ресурсом и моя задача аккуратно удержать его, следя за тем, что бы он не перегорел. А так же понять его мотивацию и передать ее другим участникам команды.
Зачем мне нужно умение программировать здесь? Что бы тыкать разраба что он не уложился в тайминг, вместо того что бы понять, почему мы пролошились с оценкой задачи, или почему сотрудника на другой проект выдергивает другой менеджер (не умеющий програмировать).
Потыкаю я его 2-3 раза, он свалит к конкурентом, посоветовав мне воспользоваться моим «умением программировать» что бы допилить проект самостоятельно.
Зачем мне нужно умение программировать здесь?
Вот, например, типовой кейс в моей жизни девять лет назад. Прихожу я работать этим самым менеджером в одну контору. Получаю тасклист отдела, директор просит по-возможности ускорить разработку отчетов, чтобы хотя бы через месяц их запустить в работу. Вижу отчет, который уже месяц делается. Расспрашиваю разработчика, почему так долго. Рассказывает про сложные выборки, про нестандартный дизайн, что структура отчета не ложится на схему данных CRM и т.д. Ту же байку, которую рассказывал предыдущему руководителю. Читаю техническое задание, открываю дизайнер отчетов, делаю его за пару часов. Ещё раз расспрашиваю разработчика, уже прижав к стенке. Выясняю, что он взял хорошую халтурку, и делает её в рабочее время, а этот проект отложил. Все равно же никто не проверит.
Поэтому случаи разные бывают (с) Все люди могут навешать лапши несведущему в какой-то теме человеку в своих интересах, и программисты тут не исключение.
В моем понимании, менеджер хороший знает чем у него сотрудники на проектах занимаются.
Почему сотрудники как менеджеру вам не докладывали о текущих задачах, их статусах? Почему вам странным не показалось, что человек простые задачи делает долго, просирает сроки? Сколько осталось таких сотрудников в вашей организации, экспертизы которых у вас нет? Сисадмин полгода не разворачивает АД? Аналитик не пишет спеку 2 недели? Саппорт не закрывает инциденты годами? Вам для работе в такой команде нужна компетенция каждого, и за каждого придется сделать минимум одну задачу?
Теоретически, менеджеру надо 2 стендапа что бы понять, что сотрудник на работе занят не работой.
На практике есть 3 типа менеджеров — микроменеджеры, делающие отчеты, макроменеджеры — в заботах о стратегии компании на ближайшие 10000 лет и не знающие чем занимается конкретно сейчас их команда, и нормальные менеджеры, которые умеют управлять в среднесрочной и долгосрочной перспективе, но при работе с новой командой — начинают с анализа краткосрочных задач.
Я встречал компании, в ИТ которых руководили женщины сильно старше 50. И ИТ работала отлично, хотя женщины ни фига в ИТ не понимали — они понимали в управлении людьми, и держали руку на пульсе. Каждый день, анализируя скоуп задач отдела/команды и спрашивая со всех когда и какой результат будет, анализируя причины успехов и факапов.
Почему сотрудники как менеджеру вам не докладывали о текущих задачах, их статусах? Почему вам странным не показалось, что человек простые задачи делает долго, просирает сроки? Сколько осталось таких сотрудников в вашей организации, экспертизы которых у вас нет? Сисадмин полгода не разворачивает АД? Аналитик не пишет спеку 2 недели? Саппорт не закрывает инциденты годами? Вам для работе в такой команде нужна компетенция каждого, и за каждого придется сделать минимум одну задачу?
Теоретически, менеджеру надо 2 стендапа что бы понять, что сотрудник на работе занят не работой.
На практике есть 3 типа менеджеров — микроменеджеры, делающие отчеты, макроменеджеры — в заботах о стратегии компании на ближайшие 10000 лет и не знающие чем занимается конкретно сейчас их команда, и нормальные менеджеры, которые умеют управлять в среднесрочной и долгосрочной перспективе, но при работе с новой командой — начинают с анализа краткосрочных задач.
Я встречал компании, в ИТ которых руководили женщины сильно старше 50. И ИТ работала отлично, хотя женщины ни фига в ИТ не понимали — они понимали в управлении людьми, и держали руку на пульсе. Каждый день, анализируя скоуп задач отдела/команды и спрашивая со всех когда и какой результат будет, анализируя причины успехов и факапов.
В моем понимании, менеджер хороший знает чем у него сотрудники на проектах занимаются. Почему сотрудники как менеджеру вам не докладывали о текущих задачах, их статусах?
А как вам доклады без хотя бы общего знания сути выполняемых ими задач помогут адекватно оценить их корректность? Вот тот сотрудник добросовестно целый месяц докладывал предыдущему руководителю о работе, которую он проводит. Якобы. Тот, не будучи ИТ-специалистом, их читал и кивал головой, ок, разбирайся. Поэтому без соответствующей компетенции вы не в состоянии дать оценку, простая задача или не простая.
А сроки в ИТ — штука вообще сложно прогнозируемая. Вы почти всегда можете оценить общий объем работ, но вы не сможете оценить случайные проблемы с совместимостью каких-то компонент, или нюансы работы в окружении какого-то конкретного клиента и т.д., а всё это может всплыть в процессе работы совершенно произвольно. Всё, что вы можете — накинуть какой-то оверхед к посчитанной оценке на риски. И потом ещё доказывать вашему заказчику, что без него никак.
На практике есть 3 типа менеджеров
На практике есть разные составы команд и разные условия работы. У вас под рукой может быть профильный руководитель по какому-то направлению. А может не быть. И тогда будьте добры, проверяйте работу сами.
Вам для работе в такой команде нужна компетенция каждого
Именно поэтому у вас и зарплата выше. Я сейчас работаю директором небольшой ИТ-компании. И знаете, я не профессиональный маркетолог, бухгалтер, HR, финансист. Но у меня достаточно компетенций в каждой из областей, чтобы понимать, чем занимается мой маркетолог, мой бухгалтер, мой HR, и я могу понимать цифры в отчетности, да и при желании самостоятельно их посчитать. И да, даже самому себе быстро сделать отчёт. Это не даже близко не нужная мне компетенция с профессиональной точки зрения, но с её помощью я могу в разы быстрее получить нужные мне цифры, чем буду сначала объяснять начальнику отдела разработки, что мне нужно, а потом ждать результата. Это экономит время и деньги.
А самое главное выяснилось уже в процессе работы: не нужно быть семи пядей во лбу, чтобы знать на достаточном для эффективной коммуникации уровне всё вышеперечисленное, и многое другое. Поэтому я абсолютно серьезно говорю, что эти навыки не нужно противопоставлять. Они прекрасно сочетаются вместе.
>> Тот, не будучи ИТ-специалистом, их читал и кивал головой, ок, разбирайся.
Вот я бы вот тут напрягся. У меня в команде много разных людей, и неадекваты тоже есть, и их видно. Когда вам человек замечания на документ простой не может написать 3 дня, вы о его стиле работы сделаете вывод сразу. Еще есть hr'ы которые свой хлеб у нас не зря едят и не берут кого попало, есть и функциональные руководители, кто смотрит загрузку постоянно и разбирается в предметной области лучше меня.
>> А сроки в ИТ — штука вообще сложно прогнозируемая.
В проектах типа MS Word — соглашусь ) В проектах типа обновляем ERP в компании на 2000 человек — не соглашусь, обычно все проблемы со сроками из за некомпетентности/желания сделать 33 проекта и получить бабла с 33 заказчиков одновременно.
>> Но у меня достаточно компетенций в каждой из областей
Вот именно, достаточно. Не надо 4 высших образования иметь, что бы понимать чем занимается бухгалтер или программист — если у вас есть схожий опыт работы, вы просечете это очень быстро. Если вы работали 5 лет аналитиком в ИТ компании, поверьте вы будете разрабов видеть насквозь. Хотя ни разу строчки кода не напишете.
>> не нужно быть семи пядей во лбу, чтобы знать на достаточном для эффективной коммуникации уровне всё вышеперечисленное, и многое другое
Вот и я про то же. Не надо уметь программировать самому — надо сесть и разобраться, загуглить, спросить экспертизу у коллег.
Я ПМом работаю и работал с многими компаниями и экспертизы часто в чем то не хватало — области заказчиков разные, один лекарства производит, другой мебелью торгует. Но садились и разбирались быстро, привлекали оперативно экспертов, и задачи клиентов решали — желание было.
Вот я бы вот тут напрягся. У меня в команде много разных людей, и неадекваты тоже есть, и их видно. Когда вам человек замечания на документ простой не может написать 3 дня, вы о его стиле работы сделаете вывод сразу. Еще есть hr'ы которые свой хлеб у нас не зря едят и не берут кого попало, есть и функциональные руководители, кто смотрит загрузку постоянно и разбирается в предметной области лучше меня.
>> А сроки в ИТ — штука вообще сложно прогнозируемая.
В проектах типа MS Word — соглашусь ) В проектах типа обновляем ERP в компании на 2000 человек — не соглашусь, обычно все проблемы со сроками из за некомпетентности/желания сделать 33 проекта и получить бабла с 33 заказчиков одновременно.
>> Но у меня достаточно компетенций в каждой из областей
Вот именно, достаточно. Не надо 4 высших образования иметь, что бы понимать чем занимается бухгалтер или программист — если у вас есть схожий опыт работы, вы просечете это очень быстро. Если вы работали 5 лет аналитиком в ИТ компании, поверьте вы будете разрабов видеть насквозь. Хотя ни разу строчки кода не напишете.
>> не нужно быть семи пядей во лбу, чтобы знать на достаточном для эффективной коммуникации уровне всё вышеперечисленное, и многое другое
Вот и я про то же. Не надо уметь программировать самому — надо сесть и разобраться, загуглить, спросить экспертизу у коллег.
Я ПМом работаю и работал с многими компаниями и экспертизы часто в чем то не хватало — области заказчиков разные, один лекарства производит, другой мебелью торгует. Но садились и разбирались быстро, привлекали оперативно экспертов, и задачи клиентов решали — желание было.
Если наоборот, разработчик приходит ко мне с инициативами или решенными задачами, раньше сроков и в меньшие часы — для меня это сигнал, что я обладаю ценным ресурсом и моя задача аккуратно удержать его, следя за тем, что бы он не перегорел.
Если вы не умеете программировать — вам подсядут на уши карьеристы, и вы их не отличите от нормальных разработчиков. Во многих местах, в которых я работал — есть карьерист, который искусно присаживается на уши менеджерам. Такова жизнь.
мне остается понять, недостаток ли это исполнителя
Если вы не умеете программировать — как вы это поймете? Во многих местах, где я работал — есть врун-лентяй, который искусно спихивает ответственность от себя во все стороны, при этом держится на плаву с помощью выполнения простых тасков, дающих простой и объемный видимый результат. Этот врун на столько привык так себя вести, что почти никто (и даже он сам) не понимают, что он на самом деле врет. Понимают только специалисты, которые работают с ним бок о бок и периодически доделывают не свою работу.
В общем, тут можно бесконечно продолжать.
Я не говорю, что вам это нужно — выбор то за вами. Жизнь ваша и карьера — тоже ваша. Вполне себе можно быть руководителем подразделения, не зная специфики внутреннего устройства самого подразделения. У нас так пол страны устроено. Вопрос только в уровне профессионализма, который вы хотите достичь. Вот и все. Так что спорить не о чем.
Менеджер обычно сам карьерист, чуть более успешно подсевший на уши топ-менеджерам ))) Или вы думаете менеджеры не думают о карьере, не умеют шантажировать руководство, не умеют выгодно показать результаты свой (часто, весьма не столь упорной) работы?
Во многих организация — плохие менеджеры. Менеджмент в России на уровне — я начальник, ты дурак. Но не везде, есть и нормальные управленцы, которые к команде относятся как к своему кошельку и знают, где в тот или иной момент какая монетка, и какого она достоинства. Опять же вопрос оплаты — за 50-80 тыщ вы ждете что менеджер будет решать такие проблемы? Да ему наплевать что там в организации происходит, он на пикабу сидит весь день, еще год не выгонят, а там новую работу найдет.
Про недостаток исполнителя все очень просто — если это не недостаток планирования, и не внешняя среда — это недостаток исполнителя. Никакой магии тут нет и быть не может.
Во многих организация — плохие менеджеры. Менеджмент в России на уровне — я начальник, ты дурак. Но не везде, есть и нормальные управленцы, которые к команде относятся как к своему кошельку и знают, где в тот или иной момент какая монетка, и какого она достоинства. Опять же вопрос оплаты — за 50-80 тыщ вы ждете что менеджер будет решать такие проблемы? Да ему наплевать что там в организации происходит, он на пикабу сидит весь день, еще год не выгонят, а там новую работу найдет.
Про недостаток исполнителя все очень просто — если это не недостаток планирования, и не внешняя среда — это недостаток исполнителя. Никакой магии тут нет и быть не может.
есть и нормальные управленцы
Да ладно?
Да. Только стоят, как и профессионалы в любой другой области очень дорого :-) Поэтому компании предпочитают за 30-80к купить кого попало и «обучить».
Причём обучают на живых сотрудниках, в итоге — сотрудники от таких рукойводителей бегут, карма вышеупомянутых рукойводителей — в глубоком минусе, к руководителям вообще — отношение резко отрицательное (проблемы руководителя и работодателя меня, как рядового сотрудника, не волнуют), организации теряют хороших сотрудников, и чёрный список плохих работодателей растёт и растёт. Ну и заодно работодатели могут даже не мечтать о лояльности своих сотрудников. Так держать, косторезы!
Да, вот еще в догонку к первому комментатору: будучи разработчиком, я сразу же спалю, что человек занят на рабочем месте не тем, чем должен. Моментально спалю. Уверен, что разработчики даже не подумают в открытую врать менеджеру, зная, что он в прошлом — сам разработчик.
Тоже мне бином Ньютона! Думаете разработчик, который ниче не делает на работе, сидит и рандомные строчки кода набирает? Он сидит на пикабу, в викеюшке, телефоне, да где угодно. Да, если он на апворке работает парралельно, наверное не разработчик не отличит корпоративную среду разработки от некорпоративной.
Но нормальный менеджер это спалит в первый день, когда оцененные задачи на день не будут выполнены.
Но нормальный менеджер это спалит в первый день, когда оцененные задачи на день не будут выполнены.
Любой менеджер должен знать сферу в которой он работает. Соответственно, хороший руководитель в ИТ-сфере, должен знать (а лучше иметь профильное образование) в области ИТ (например, программирование, если он управляет разработкой) и, кроме этого, в каждом проекте погружаться в предметную область заказчика. Только так он может управлять специфичными рисками проекта. Если у менеджера нет такой экспертизы — он не сможет грамотно взвесить риски, о которых ему сообщает команда/заказчик и проект станет уязвимым. В итоге инициатива в управлении проектом перейдет либо к команде (отсюда все стоны вида «менеджер не понимает почему прямо сейчас нужен рефакторинг. Следующую версию мы уже собрать не сможем.») либо к заказчику («вы не учли то, то и то, хотя это было очевидно/мы это обсуждали см. ТЗ… Решайте эту задачу бесплатно в рамках багфиксинга»).
Вы какого то менджера описываете, не у которого нет навыков разработки, а который просто на проекте ничего не делает. Менеджер у вас что, не читал договор, не читал регламенты проведения рефакторинга, не читал регламенты выдачи релизов? Если нет — то гоните его, он на работе у вас видимо на другую контору работает.
По поводу рисков — поверьте, их взвесить грамотно не могут люди даже в своей области работающие. Пример — одну из самых известных компаний в Москве по консалтингу в сфере рисков закрыли за уклонение от налогов. Этот риск они не учли.
По поводу рисков — поверьте, их взвесить грамотно не могут люди даже в своей области работающие. Пример — одну из самых известных компаний в Москве по консалтингу в сфере рисков закрыли за уклонение от налогов. Этот риск они не учли.
Менеджер у вас что, не читал договор, не читал регламенты проведения рефакторинга, не читал регламенты выдачи релизов?
Извините за нескромный вопрос, в скольких компаниях вы работали? В одной крупной и до безобразия бюрократизированной? В 99% компаний-разработчиков нет и никогда не будет ни регламентов проведения рефакторинга, ни многих других регламентов. Эти решения разработчики принимают самостоятельно.
В 12 (4 государственные (внезапно одни из наименее бюрократизированных), 2 ~ 300 чел (одна очень бюрократизирована), 1 — 2000 чел, 2 — 100 чел, 3 < 20. 3 из них ИТ и только ИТ (и одна ИТ — та, что наиболее бюрократизирована). В маленьких компаниях — нормальных менеджеров (и нормального менеджмента) не видел. Видел хорошо доработанный и старательно примененный эджайл, который избавлял от необходимости в сильном менеджменте и регламентах.
Я скажу что хорошо делались проекты по fixprice в наиболее бюрократизированной компании. Хорошо — это в срок, в бюждет и без 19000500 обращений по гарантии, с клиентами которые возвращались.
Я скажу что хорошо делались проекты по fixprice в наиболее бюрократизированной компании. Хорошо — это в срок, в бюждет и без 19000500 обращений по гарантии, с клиентами которые возвращались.
По поводу рисков — поверьте, их взвесить грамотно не могут люди даже в своей области работающие.
Надеюсь Вы не станете утверждать, что, при прочих равных условиях, наличие профильных знаний у менеджера не способно уменьшить вероятность возникновения рисков при управлении проектом? (Речь, конечно же, идет об обычных менеджерах, а не об их широко известных «эффективных» коллегах)
Разделяю мнение многих комментаторов — основная задача менеджера это управление, а не копание в технических деталях, однако, все мы живем в реальной жизни, а на практике профильные знания часто позволяют видеть проект более целостно.
При прочих равных условиях, нет.
Но обычно, человек забивает на менеджмент и полагается на навыки прогера, а это не верно в корне.
Но обычно, человек забивает на менеджмент и полагается на навыки прогера, а это не верно в корне.
Надеюсь Вы не станете утверждать, что, при прочих равных условиях, наличие профильных знаний у менеджера не способно уменьшить вероятность возникновения рисков при управлении проектом?
В этом и задача упраления рискам — что и как сделать так, что бы отрицательный риск(и) выбранные из идентифицированных возникли с минимальной вероятностью или минимизровать их ущерб.
Например — если есть риски «нет компетенций по XYZ», то нужно решить что делать:
- обучать самому перед! началом проекта
- нанять специалиста
- исключить «XYZ» или заменить на «ABC»
- обучать самому по ходу проекта, скорректировав план и бюджет
- отказаться от проекта
- зарезервировать некоторый «бюджет» если риск сработает
Или вы хотите сказать, что пункты 1...4 не снижают веростность риска?
Все в ваших руках :)
Замечательно написано о том, что действительно делает из человека в менеджерской должности настоящим менеджером. Браво. Снимаю шляпку перед теми трудностями, которые пришлось пройти, чтобы всё это осознать.
Хотелось бы дополнить парой комментариев для подчинённых: если видите, что руководитель не успевает сделать что-то из вышеперечисленного, не стесняйтесь сделать это за него. Не надо сидеть ровно и тем более ныть, что меня, мол, недостаточно замотивировали, или ТЗ не совсем понятное, или ещё чего-там-ещё-кто-не-организовал. Это надо вам самим. Менеджерская работа по-хорошему дожна быть сделана, и не обязательно самим менеджером. Она вернётся сторицей в виде хорошо выполненного проекта или слаженностью команды. А систематическая помощь менеджеру со стороны подчинённого рано или поздно возвращается ростом зарплаты и/или карьерным ростом. Потому что сотрудник, который самоорганизуется в работе, куда как ценнее для работодателя, чем тот, с которым надо няньчиться.
Хотелось бы дополнить парой комментариев для подчинённых: если видите, что руководитель не успевает сделать что-то из вышеперечисленного, не стесняйтесь сделать это за него. Не надо сидеть ровно и тем более ныть, что меня, мол, недостаточно замотивировали, или ТЗ не совсем понятное, или ещё чего-там-ещё-кто-не-организовал. Это надо вам самим. Менеджерская работа по-хорошему дожна быть сделана, и не обязательно самим менеджером. Она вернётся сторицей в виде хорошо выполненного проекта или слаженностью команды. А систематическая помощь менеджеру со стороны подчинённого рано или поздно возвращается ростом зарплаты и/или карьерным ростом. Потому что сотрудник, который самоорганизуется в работе, куда как ценнее для работодателя, чем тот, с которым надо няньчиться.
А систематическая помощь менеджеру со стороны подчинённого рано или поздно возвращается ростом зарплаты и/или карьерным ростом.
Мне кажется, вы — плохой менеджер, который ставит блокирующие таски, а впоследствии ищет виноватого. Карьерным ростом заканчивается стремление к карьерному росту (но это не точно). Ростом зарплаты заканчивается стремление больше зарабатывать (но это тоже не точно). Альтруизм — это альтруизм, и не больше.
Хотелось бы дополнить парой комментариев для подчинённых: если видите, что руководитель не успевает сделать что-то из вышеперечисленного, не стесняйтесь сделать это за него.
А потом намекнуть, чтобы заплатили, как начальнику? Или попросить отрефакторить кусочек кода? )
Мне кажется, вы — плохой менеджер, который ставит блокирующие таски, а впоследствии ищет виноватого
Не вижу из чего Вы делаете такие далеко идущие и столь категоричные выводы, да ещё и в форме персонального обвинения. Как бы намекаю, что наезд был мимо тазика. И Вы явно путаете карьеру и карьеризм.
Дальше уже не лично Вам, так что «вы» будет уже обезличенным, и по правилам русского языка будет писаться с маленькой буквы. Поясню свою мысль, так как вижу, что нашёлся кто-то, кто коммент staticY выше плюсанул.
В специальности ИТ так же хорошо, как и в других сферах бизнеса, замечательно работает правило «спасение утопающих — дело рук самих утопающих». Если менеджер на вашем проекте — чудак на букву «м», то не стесняйтесь работать за него. Если за счёт этого вытянете проект, то в компании это должны оценить. Это шанс стать более полезным для компании, то есть для карьерного роста. Это хорошее основание поднять должность и/или зарплату. А если не оценят, то поменяете работу и с имеющимся опытом будете претендовать опять же на более высокую должность и зарплату.
А если менеджер адекватный, но просто не успевает или что-то упускает по каким-либо другим причинам (см. в статье развесистый список того, что делает хороший менеджер), то тоже будет только польза по тем же самым причинам. Это шанс для вашего карьерного роста. И я не зню ни одной причины не помогать менеджеру, если такая возможность представилась.
Выводы не бог весть какой глубины, но почему-то молодёжь к ним приходит очень долго, считая, что лишь углубленное изучение фреймворков (читай: технической части) открывает пути карьеры. А работодатель платит деньги не за знание фреймворков, а за решение конкретных задач бизнеса. И не каких-то там «тасков», а скорее проектов, если оставаться в ИТшной терминологии. Фреймворки же могут пригодиться решать поставленные задачи быстрее или лучше, а могут и не пригодиться…
Если менеджер на вашем проекте — чудак на букву «м», то не стесняйтесь работать за него. Если за счёт этого вытянете проект, то в компании это должны оценить.
Это хорошее основание поднять должность и/или зарплату. А если не оценят, то поменяете работу и с имеющимся опытом будете претендовать опять же на более высокую должность и зарплату.
У нас разные подходы к карьерному росту. Я расту за счет роста своего профессионализма в своей технической сфере, потому что я не хочу становится директором по продажам (оставляю это место тем, кто больше ничего не умеет). Я предоставляю бизнесу хорошо продуманный человеческий интерфейс для воплощения бизнесовых хотелок в виде программного кода/архитектуры. Какие делать хотелки и за какие сроки и прочее планирование — это не моя юрисдикция, в моей юрисдикции навалом другого более сложного планирования.
Да, я иногда залажу в смежную область управления. Просто потому что не хочу превратиться в аутиста, который замкнут и оторван от мира. Я в курсе, как у ребят сверху обстоят дела и знаю, как они продают продукт, который я пишу. Знаю, что про продукт говорят клиенты. Но я не делаю не свою работу. Потому что не вижу в этом никакого смысла, ибо у меня свой бизнес — «Написание программного обеспечения как услуга», в котором есть своя карьерная лестница, которая не основывается на понятиях «не стесняйтесь работать за него и тебя, возможно, повысят». Для меня подобный подход — бред.
ИМХО помощь предложить стоит. Но сделать за него — клиника. Что будет если отчет о статусе проекта заказчику разработчик пришлет? )
UFO just landed and posted this here
Вот, да. Менеджер очень перегруженное слово и тыкается везде где придется. Из моей практики видно следующее, на ранних стадиях «менеджмент» это дополнительный навык к основному, те программист с навыками менеджмента может быть техлидом или тимлидом так как дополнительно к организации технической архитектуры он может еще организовать ресурсы под нее, что собственно очень логично. Перевес случается когда дело доходит до так называемого General Manager, те Менеджер который организует других менеджеров, вот там чистый менеджмент как основной навык и проявляется. Еще есть куча литературы которая обсуждает эти грабли, The Pragmatic programmer, Software Architecture in Practice, тот же SWEBOK неплохо проходится по этому поводу и все это крутится вокруг понимания процесса SDLC в принципе
А программист не перегруженное слово? ) ИМХО так же как менеджер используется. Только в случае с разработчиком — все вникают в ньюансы, на чем кодишь, бэкэнд, фронтэнд, ДБ или что то еще.
С менеджером — тыжменеджер, значит дожен уметь все (и вот теперь кодить, внезапно тоже!).
С менеджером — тыжменеджер, значит дожен уметь все (и вот теперь кодить, внезапно тоже!).
Да то же самое конечно, поэтому я думаю важно не забывать приставку. Из топика не сильно понятно но я думаю речь идет о так называемом project manager если да то это административная роль фокус которой направлен на администрирование сроков, затрат, качества выпускаемого продукта, вот тут www.apm.org.uk/resources/what-is-project-management все написано. В чистой роли project manager может не знать ничего о программировании и это будет ок потому как его специализация это администрирования проекта. При этом у него даже может не быть подчиненных итп так как он администрирует проект а не людей. Как то так
Как мне кажется, тут не про менеджера, а про специалиста в общем. Обладание смежными навыками временами даёт хорошую выгоду. Когда ты понимаешь как устроенно всё у коллег тебе проще с ними взаимодействовать. Например, если вы работаете в веб студии, которая не только разрабатывает, но и продвигает сайты, знания базового сео ещё и на этапе создания и продумывания решений могут позволить избежать ошибок и по итогу меньше претензий будет у сеошника и меньше придётся переделывать. Также и в разработке ПО, бекграунд менеджера может помочь вам подсказать менеджеру какие-то не очевидные риски. Да эти навыки, вторичны, но помогут выделиться из общей массы в лучшую сторону.
Менеджер, по моему существенному опыту в крупных, и средних но богатых, конторах- это лишь приказчик, следящий за исполнением планов и подгоняющий реальных исполнителей. План обычно верстается заказчиком, аналитиком исполнителя и бухгалтерами с обеих сторон. Получение заказа обычно обеспечивает «продавец», «босс», «кто-то ещё», умеющий ходить в баню, проверенный на откаты и вхожий в места «необщего пользования».
В таком окружении менеджеру лучше не тратить времени на специальность (в среднем. в общем), а сразу тренироваться в способности чуять и удовлетворять нужды начальства любыми средствами. Да и платят менеджерам побольше. Но работа нервная, всё зависит не от тебя.
Помню, увольнялся в 2016 году, и разговорился тогда с нашим молодым руководителем департамента, практически менеджером. Его прямые слова: — да, я и сам был и работал программистом. А потом смотрю, манагерам то больше платят. Так что-же, думаю, я тут делаю? И переквалифицировался в менеджеры.
Человек он был неплохой в целом, но принимал жёсткие решения по отношению людей, в два раза его старше, легко. Мог опоздать на совещание на час, а потом позвонить ожидающим его в зале сотрудникам и сказать: — а я тут кофе пью и скоро приду.
Хотя воспитывался у нормальных советских людей, знаю точно, не из-за бугра его прислали.
Предыдущего в той же конторе прислали из-за бугра. Был активным, вежливым, шустрым, не опаздывал, и говорил с акцентом, после длительного пребывания в США. В целом с ним было даже легче, проще, определённее. даже живее, хотя и от личности зависит. Ведь менеджер — это чисто американская должность в американского типа экономике. которая тырит реальные ресурсы со всего мира за свои виртуальные деньги и позволяет себе больше трат на обеспечение своего внутреннего спокойствия.
Всё — ПМСМ!
В таком окружении менеджеру лучше не тратить времени на специальность (в среднем. в общем), а сразу тренироваться в способности чуять и удовлетворять нужды начальства любыми средствами. Да и платят менеджерам побольше. Но работа нервная, всё зависит не от тебя.
Помню, увольнялся в 2016 году, и разговорился тогда с нашим молодым руководителем департамента, практически менеджером. Его прямые слова: — да, я и сам был и работал программистом. А потом смотрю, манагерам то больше платят. Так что-же, думаю, я тут делаю? И переквалифицировался в менеджеры.
Человек он был неплохой в целом, но принимал жёсткие решения по отношению людей, в два раза его старше, легко. Мог опоздать на совещание на час, а потом позвонить ожидающим его в зале сотрудникам и сказать: — а я тут кофе пью и скоро приду.
Хотя воспитывался у нормальных советских людей, знаю точно, не из-за бугра его прислали.
Предыдущего в той же конторе прислали из-за бугра. Был активным, вежливым, шустрым, не опаздывал, и говорил с акцентом, после длительного пребывания в США. В целом с ним было даже легче, проще, определённее. даже живее, хотя и от личности зависит. Ведь менеджер — это чисто американская должность в американского типа экономике. которая тырит реальные ресурсы со всего мира за свои виртуальные деньги и позволяет себе больше трат на обеспечение своего внутреннего спокойствия.
Всё — ПМСМ!
К названию статьи вспоминается:
Стив Джобс
«I think everybody in this country should learn how to program a computer because it teaches you how to think»
(“Думаю каждый в этой стране должен учиться программированию, потому что это учит людей думать”).
Стив Джобс
Сколько менеджеров выпускается ежегодно из ВУЗов России и ближнего зарубежья? Тысячи, если не десятки. Кто из них может реально сформулировать в чем его задача, как выпущенного специалиста? Почти никто. Но они не виноваты, потому понятине менеджера у нас «расплылось» и дискредитировалось.
Чтобы оценить масштаб вакханалии можно просто взглянуть на нейминг позиций некоторых банков и организаций. Самая начальная или, вообще, низшая позиция обычного работника нередко называется «менеджер по чему-то там». В одном из банков вовсе у разработчиков и админов позиции назывались примерно, как «менеджер по разработке чего-то там» и «менеджер по обеспечению чего-то там». Смысл в том, что номинально менеджер — это управленец. Номинально управленцу уметь программировать не нужно, ведь с этим не нужно спорить? Но здесь в дело вступает контекст нашего рынка труда и как он формировался. Так уж получилось, что наш рынок труда не узкоспециализированный.
Хочешь не хочешь, а в любой сфере приходится ни то, что заниматься, но точно хотя бы вникать в темы не своей зоны ответственности. Конкретно в случае с менеджерами, если это не супер топ-менеджер гос. уровня, то скорее всего он, как и все подобные, находится в условиях конкуренции. И именно в рамках этой конкуренции и рождаются такие «сайд скиллы», как программирование у менеджеров.
Это не только менеджеров касается. У меня есть друг, который с самого выпуска работает в сфере продаж. Он настоящий продажник и уже имеет много лет опыта, но тем не менее, он изучает психолгию и даже психиатрию, поведенческие модели, в общем читает много подобной литературы. Уж не знаю, на сколько это полезно в его сфере, но судя по тому, что он весьма успешен, то думаю — да.
Несомненно, программирование, как сайд-скилл — это плюс для менеджера, особенно если он работает в IT сфере. Но, честно говоря, в статье я увидел серьезные пересечения зон отвественности. Например, на уровне кода проект должен знать максимум тим-лид, а уж менеджер проекта, которого я вижу product-owner'ом в данном контексте, подобного знать не должен. Он должен знать как его продукт решает user-кейсы и stories, которые спустились от аналитиков, что тоже мелькает в статье в зоне отвественности менеджера. В общем материал хороший, но очень субъективный :)
Чтобы оценить масштаб вакханалии можно просто взглянуть на нейминг позиций некоторых банков и организаций. Самая начальная или, вообще, низшая позиция обычного работника нередко называется «менеджер по чему-то там». В одном из банков вовсе у разработчиков и админов позиции назывались примерно, как «менеджер по разработке чего-то там» и «менеджер по обеспечению чего-то там». Смысл в том, что номинально менеджер — это управленец. Номинально управленцу уметь программировать не нужно, ведь с этим не нужно спорить? Но здесь в дело вступает контекст нашего рынка труда и как он формировался. Так уж получилось, что наш рынок труда не узкоспециализированный.
Хочешь не хочешь, а в любой сфере приходится ни то, что заниматься, но точно хотя бы вникать в темы не своей зоны ответственности. Конкретно в случае с менеджерами, если это не супер топ-менеджер гос. уровня, то скорее всего он, как и все подобные, находится в условиях конкуренции. И именно в рамках этой конкуренции и рождаются такие «сайд скиллы», как программирование у менеджеров.
Это не только менеджеров касается. У меня есть друг, который с самого выпуска работает в сфере продаж. Он настоящий продажник и уже имеет много лет опыта, но тем не менее, он изучает психолгию и даже психиатрию, поведенческие модели, в общем читает много подобной литературы. Уж не знаю, на сколько это полезно в его сфере, но судя по тому, что он весьма успешен, то думаю — да.
Несомненно, программирование, как сайд-скилл — это плюс для менеджера, особенно если он работает в IT сфере. Но, честно говоря, в статье я увидел серьезные пересечения зон отвественности. Например, на уровне кода проект должен знать максимум тим-лид, а уж менеджер проекта, которого я вижу product-owner'ом в данном контексте, подобного знать не должен. Он должен знать как его продукт решает user-кейсы и stories, которые спустились от аналитиков, что тоже мелькает в статье в зоне отвественности менеджера. В общем материал хороший, но очень субъективный :)
За всех менеджеров не скажу, скажу за менеджеров проектов.
В PMI PMBOK (6) роль менеджера проекта сравнивается с ролью дирижера оркестра — он хорошо разбирается в музыке, умеет играть на каких-то инструментах, обладает определенным опытом в музыке и организации.
Но вот вопрос — вы выдели хотя бы на одном концерте, что бы дирижер оставил пост, бросил палочку и сел за инструмент? )))
Даже если кто то играет не в ноты, дирижер не сядет на его место. Хороший дирижер строит оркестр и не допускает, что бы на концертах такое случалось — делает много репетиций, ищет людей, развивает их, не дает им срулить за день до концерта и т.д.
Представляете ли вы что главный конструктор летательных аппаратов тратит свое время на то, что занимается сваркой или заклепкой швов? Представляете ли вы себе, что бы главных архитектор крупного здания (например, ГЗ МГУ) сам приехал класть кирпичи и делать лепнину (всего лишь лет 500 на это бы у него ушло)?
То же и с ПМом — как бы вы хорошо не кодили, идите делать это в свободное время, на OpenSource или на upwork.
ПМ должен заниматься пмством, если, например, команда плохо делает оценки — он должен обозначить это риском, подумать о развитии команды, подключить людей с экспертизой. Если он ставит оценки сам — он очень плохой ПМ — он не может эффективно наладить работу на проекте, найди общий язык с командой и руководством, объяснить какие ресурсы нужны для проекта и защитить свое мнение.
В PMI PMBOK (6) роль менеджера проекта сравнивается с ролью дирижера оркестра — он хорошо разбирается в музыке, умеет играть на каких-то инструментах, обладает определенным опытом в музыке и организации.
Но вот вопрос — вы выдели хотя бы на одном концерте, что бы дирижер оставил пост, бросил палочку и сел за инструмент? )))
Даже если кто то играет не в ноты, дирижер не сядет на его место. Хороший дирижер строит оркестр и не допускает, что бы на концертах такое случалось — делает много репетиций, ищет людей, развивает их, не дает им срулить за день до концерта и т.д.
Представляете ли вы что главный конструктор летательных аппаратов тратит свое время на то, что занимается сваркой или заклепкой швов? Представляете ли вы себе, что бы главных архитектор крупного здания (например, ГЗ МГУ) сам приехал класть кирпичи и делать лепнину (всего лишь лет 500 на это бы у него ушло)?
То же и с ПМом — как бы вы хорошо не кодили, идите делать это в свободное время, на OpenSource или на upwork.
ПМ должен заниматься пмством, если, например, команда плохо делает оценки — он должен обозначить это риском, подумать о развитии команды, подключить людей с экспертизой. Если он ставит оценки сам — он очень плохой ПМ — он не может эффективно наладить работу на проекте, найди общий язык с командой и руководством, объяснить какие ресурсы нужны для проекта и защитить свое мнение.
Но вот вопрос — вы выдели хотя бы на одном концерте, что бы дирижер оставил пост, бросил палочку и сел за инструмент?
А вы видели хотя бы одного дирижера, который не умеет читать ноты и не знает партитуры инструментов? Да и играть дирижеры тоже умеют на чём-либо, все они так или иначе когда-то были музыкантами.
Точно так же главный конструктор летательных аппаратов знает технологии сварки швов и заклепок, знает, когда и в каких условиях их применять, как технические, так и экономические аспекты технологий. И когда-то он крутил гайки.
Речь тут идет про «понимать, что делают программисты», а не про «программировать в команде».
А вы видели хоть одного менеджера, который не умеет читать на языке, котором ведет проект? Или писать на нем? Или вы думаете задачи в трекере и ответы о тестировании и внедрении пишутся на языках программирования? Или, для того что бы менеджеру организовать отчетность о тестировании или разработке на проекте — нужно программирование знать?
Да и ИТ редко попадают из строительства или филологии, так или иначе опыт работы в ИТ у всех менеджеров в ИТ обычно есть (скорее всего аналитика, но может быть и сисадминство, техподдержка, продажи). Совсем уж левых людей тут нет — дворника или поэта ПМом работать внезапно не возьмут.
Для того что бы понимать что делают программисты — программировать не надо.
Для того что бы быть уверенным, что у тебя нормально сварен шов — надо посмотреть отчет о тестировании сварки, и если он провален — заставить команду сварки (через ее руководителя) сделать так, что бы он был ок. Как заставить — методов материальной и нематериальной мотивации у менеджера полно — например, уверенно объяснить что после еще одного проваленного шовного теста будет увольнение и уголовное преследование.
А сидеть и учиться швы варить — и тем более учить этому сварщиков — неправильно. Это значит, что менеджер у себя ситуацию не контролирует вообще, если он до такого доходит, и проектом управлять не способен.
Да и ИТ редко попадают из строительства или филологии, так или иначе опыт работы в ИТ у всех менеджеров в ИТ обычно есть (скорее всего аналитика, но может быть и сисадминство, техподдержка, продажи). Совсем уж левых людей тут нет — дворника или поэта ПМом работать внезапно не возьмут.
Для того что бы понимать что делают программисты — программировать не надо.
Для того что бы быть уверенным, что у тебя нормально сварен шов — надо посмотреть отчет о тестировании сварки, и если он провален — заставить команду сварки (через ее руководителя) сделать так, что бы он был ок. Как заставить — методов материальной и нематериальной мотивации у менеджера полно — например, уверенно объяснить что после еще одного проваленного шовного теста будет увольнение и уголовное преследование.
А сидеть и учиться швы варить — и тем более учить этому сварщиков — неправильно. Это значит, что менеджер у себя ситуацию не контролирует вообще, если он до такого доходит, и проектом управлять не способен.
Думаю, в вашем примере менеджер должен всё же уметь отличать визуально сварочный шов от скотча.
А что, для этого надо специально учится?
Почти все сколь-нибудь успешные менеджеры в какой-либо отрасли выросли из рядовых специалистов в этой отрасли. Люди, которые изначально учились «просто управлять», попав в живую рабочую среду, проходят через боль и страдания, прежде чем начинают хоть как-то работать. И выживают далеко не все :)
Ну ок, сварщик говорит менеджеру "тут нужно 3 часа варить", варит час и 2 часа имитирует бурную деятельность.
Ну, Вы привели отличные примеры.
Оркестром не будет управлять прораб, ракеты не строят главные хирурги, дирижер не уследит за торговым центром.
Edit: это был ответ на предыдущий коммент, прошу прощения. Менеджеру хабрахбара: на последний комментарий первого уровня всегда очень трудно создать ответ.
Хирург не может строить ракеты, но он может стать главным врачем в клинике. В клинике, где будут хирурги, терапевты, стоматологи, патологоанатомы, водители, уборщицы, строители и даже менеджеры по продажам, а даже IT.
И хирург этого всего не должен уметь. А точнее — дожен знать все по верхам и уметь подключать экспертизы.
Если тебе начитотдела ИТ говорит что делать сайт клиники — 10 млн, ты даешь заму задачу сделать RFP, позвонить в консалтинг, собрать 5 КП и 5 оценок RFP и выдать 5 КП. После чего либо начальник ИТ отдела идет на мороз за некомпетентность, либо тебе специально обученный менеджер по продажам в КП объясняет ПОНЯТНО почему это столько стоит — и это поверьте мне более чем реально сделать, переведя конкретные трудозатраты на язык бизнеса.
И хирург этого всего не должен уметь. А точнее — дожен знать все по верхам и уметь подключать экспертизы.
Если тебе начитотдела ИТ говорит что делать сайт клиники — 10 млн, ты даешь заму задачу сделать RFP, позвонить в консалтинг, собрать 5 КП и 5 оценок RFP и выдать 5 КП. После чего либо начальник ИТ отдела идет на мороз за некомпетентность, либо тебе специально обученный менеджер по продажам в КП объясняет ПОНЯТНО почему это столько стоит — и это поверьте мне более чем реально сделать, переведя конкретные трудозатраты на язык бизнеса.
Поверьте, я и не собираюсь с Вами спорить. Тем более, что PMI и творение его, PMBoK также уважаю. Не считая, правда, никакие инструкции конечной истиной, доверяю в большей мере здравому смыслу.
Но Ваша позиция Специалиста по проектному ведению мне понятна. Она немного узка (потому доводы в танце часто запутываются), но имеет право на жизнь. Особенно в достаточно крупных компаниях, где можно найти реальный обезличенный слой деятельности.
Я же думаю, что многие тут, за главные навыки роли "менеджер" принимают именно работу с людьми. Это талант к умениям, который в равной степени распределен между специалистами всех видов (часто достается и контроллерам проектов, да).
Ролей "менеджер" очень много, влезать на них можно с любой стороны. Но лучше так, чтобы люди в процессе — все еще уважали, а не одергивали в раздражении.
Меня немного просто раздражает позиция — ты работаешь в области Х менеджером, иди получи по ней высшее образование, отработай 10 лет исполнителем, а потом иди в ней руководить.
Роль менеджера — обесценивается, все привыкли что менеджер — это чувак, который ничего не понимает ни в чем, но всегда требует заполнить ТШ и сделать задачу за 3 секунды качественно.
Хорошего менеджера, кроме прочего, отличает внимательность к деталям (и желание разбираться в любой мутной воде на проекте), чрезмерная тяга к планированию и контролированию вверенных ему проектов или процессов.
Для такого менеджера ситуация «я уже год работаю на другую компанию, а меня спалили потому что я отчет оценил крайне неадекватно» невозможна в принципе.
Хотя плохих менеджеров — большинство, это не значит что такими надо быть.
Роль менеджера — обесценивается, все привыкли что менеджер — это чувак, который ничего не понимает ни в чем, но всегда требует заполнить ТШ и сделать задачу за 3 секунды качественно.
Хорошего менеджера, кроме прочего, отличает внимательность к деталям (и желание разбираться в любой мутной воде на проекте), чрезмерная тяга к планированию и контролированию вверенных ему проектов или процессов.
Для такого менеджера ситуация «я уже год работаю на другую компанию, а меня спалили потому что я отчет оценил крайне неадекватно» невозможна в принципе.
Хотя плохих менеджеров — большинство, это не значит что такими надо быть.
Боюсь, что я снова (как и в тексте о 22 двух одинаковых проектах) не совсем понимаю Вашу мысль. Т.е. требование образования в предметной области приводит к некомпетентности в этой самой области?
Ну, еще раз, я такого требования не встречал. Мне кажется, Вы обсуждаете логическую ловушку, а не реальную проблему — дело в том, что необязательность профильного образования не означает нежелательность такого образования. В статье самым первым пунктом идет знание устройства продукта от и до. Это тем более нужно, если вы не просто контролируете поток абстрактных документов, но и работаете с людьми, мотивируете (да просто понимаете) их, например. И это реально сложно сделать, если вы никогда не были программистом, или, хотя бы, тестировщиком. Если не умеете представлять себе проект в терминах и понятиях (хотя бы) организации кода. Изучить это возможно, спец образование не нужно. Но время и усилия — да.
В конце-концов — сами прикладные программисты такой же пример универсального солдата — по хорошему — надо стать экспертом в той области, что ты автоматизируешь. Вот я, например, именно за это профессию и выбрал. Образования нет, но в итоге — прилично разбираюсь во многих областях деятельности. Мало того — именно это, а не знание синтаксиса ЯП оказывается тем самым полезным (и приятным) богажом, который остается с тобой в путешествии по жизни.
Скажем так, самый лучший ПМ которого я видел — не был программистом, но очень хорошо работал с людьми, понимал всех и каждого и на проекте был порядок.
А ПМов я видел много, и хороших и с PMP и с Prince2 сертификатами, и с яндекса, и с иностранных компаний.
А вот типичный плохой ПМ — это программист, которого поставили во главе проекта, без знаний и умений в менеджменте, стабильно загоняющий проекты в минус, и ненавидимый и стейками и командой.
Впрочем, самые хорошие разрабы — которых я встречал, без образования программистов (но с ВО, например, с образованием радиотехнического факультета/физики).
А ПМов я видел много, и хороших и с PMP и с Prince2 сертификатами, и с яндекса, и с иностранных компаний.
А вот типичный плохой ПМ — это программист, которого поставили во главе проекта, без знаний и умений в менеджменте, стабильно загоняющий проекты в минус, и ненавидимый и стейками и командой.
Впрочем, самые хорошие разрабы — которых я встречал, без образования программистов (но с ВО, например, с образованием радиотехнического факультета/физики).
Вот-вот. Мне как раз и кажется, что у большей части комментаторов нет перед глазами или в памяти примеров хорошего менеджемента. Отсюда и попытки нафантазировать, что мне бы, мол, как программисту, наверняка было бы легче взаимодействовать с менеджером, который умеет программировать. А вот встретив хорошего менеждера, человек невольно задаётся вопросом, почему же он так хорош и чем именно это определяется. И оказывается внезапно, что отнюдь не знаниями в программировании.
Снова, отвечающий за ведение проектов и не знающий, как это делать — не справится с ответственностью, независимо от того, программист он, или шахтер.
Отвечающий за проект в шахте и не знающий ничего об особенностях поведения в забое — рискует независимо от наличия сертификации PMP/Prince2 и что там появится дальше.
Хм, а к ПМам других требований кроме РМР что ли и нет?
В Москве, везде где я был на собеседованиях — понимание цикла разработки ПО, понимание технологического стека (условно, можешь не знать как настроить IIS, но что это такое понимать обязан, обязан понимать разницу между MS SQL и PostgreSQL для проектов (например ага, у нас софт поддерживает подключение первого и не поддерживает второго), скиллы в аналитике (BPMN например прочитать процесс) и т.д.
Не скажу, что нужны прямо глубокие знания во всем, но по верхам — знать надо. И больший приоритет всегда имеет человек, который знает разработку по верхам, но знает еще и бизнес-анализ и предметную область, чем человек, который знает только разработку, пусть и глубоко.
В командах обычно есть тимлиды, оценка задач и ответственность за это лежит на них.
Если кто то узнает что тимлид/ведущий разраб/архитектор соврал при оценке (хотя казалось бы чем он заинтересован, ведь не ему делать эти работы), с ним будет очень серьезных разговор.
У тимлидов есть KPI по попаданию в оценки, т.е. написал ПМу что это разрабатывать 100 часов, а работал 120 (или 80 что тоже плохо, ибо ресурсы стоят) — будет минус к жирной годовой премии тимлидской.
Так и живем.
В Москве, везде где я был на собеседованиях — понимание цикла разработки ПО, понимание технологического стека (условно, можешь не знать как настроить IIS, но что это такое понимать обязан, обязан понимать разницу между MS SQL и PostgreSQL для проектов (например ага, у нас софт поддерживает подключение первого и не поддерживает второго), скиллы в аналитике (BPMN например прочитать процесс) и т.д.
Не скажу, что нужны прямо глубокие знания во всем, но по верхам — знать надо. И больший приоритет всегда имеет человек, который знает разработку по верхам, но знает еще и бизнес-анализ и предметную область, чем человек, который знает только разработку, пусть и глубоко.
В командах обычно есть тимлиды, оценка задач и ответственность за это лежит на них.
Если кто то узнает что тимлид/ведущий разраб/архитектор соврал при оценке (хотя казалось бы чем он заинтересован, ведь не ему делать эти работы), с ним будет очень серьезных разговор.
У тимлидов есть KPI по попаданию в оценки, т.е. написал ПМу что это разрабатывать 100 часов, а работал 120 (или 80 что тоже плохо, ибо ресурсы стоят) — будет минус к жирной годовой премии тимлидской.
Так и живем.
Я продолжаю считать, что тот вид менеджера, который описываете Вы — в лучшем случае "управляющий", специалист по исполнению процессов. Все ситуации разные, но часто это очень нужный вид специалиста, не спорю. В таких PM всегда выбирал себе толковых девчонок. Толковых настолько, чтобы принять факт того, что это должность обслуживающая, а никак не руководящая. Это очень сложный, но важный момент. Уверен, что описывая первые две итерации — автор данной статьи упоминает, по сути, те же грабли. Неосознанная попытка вести себя как решающее судьбу начальство, а не администратор, который помогает "реальным творцам" удержаться в рамках процесса.
Руководитель же, в моем понимании — это тот, кто берет ответственность (принимает решения и т.п.) за других людей. Хотите Вы этого, или нет, но люди должны добровольно делегировать эту ответственность такому "лидеру". Уважать его мнение (а не абстрактный пункт инструкции/стандарта). В статье Яндекса (как мне показалось) — речь шла о менеджере продукта, о том, кто принимает решения не только по процессу, но и о творчестве, о том, что и как творить. О руководителе, а не администраторе. И "тимлид" тут действительно оказывается ближе к PM Яндекса, чем к PM как Project Manager.
У кого-то из американских профессоров видел хорошую аналогию — понятие Т-менеджмент. Где ножка в букве "Т" — это предметная экспертиза (те самые 10 тыс. часов), а перекладина — "management leadership", что-то вроде "управленческого руководительства/лидерства". Перекладина висеть не может, но и "ножке" желательно быть пропорциональной — не слишком короткой или длинной.
Да, и хочу уточнить — предыдущий ответ меня вынудила написать вот эта фраза:
написал ПМу что это разрабатывать 100 часов, а работал 120 (или 80 что тоже плохо, ибо ресурсы стоят) — будет минус к жирной годовой премии тимлидской.
Вот когда такой ПМ начнет брать ответственность (хотя бы частично) за ошибки тимлида на себя, поймет, что его работа — в первую очередь — помочь тимлиду не ошибиться, поделится своей премией — можно будет поздравить его с небольшой перекладиной ;)
В один из первых визитов в Англию меня удивляло расположение на шоссе огромных знаков-предупреждений о фотокамере-спидометре. Что-то вроде: за километр, потом за 500 метров, потом за 300, потом за 100. На мой глупый советский вопрос — зачем же предупреждать, ведь водитель сбросит скорость, профессор, сидящий за рулем внимательно посмотрел на меня и с удивлением сказал: "так ведь это им и нужно". Не поймать, а помочь проехать безопасно.
PM и есть управляющий, и в первую очередь он должен планировать, мониторить, рапределять задачи, докладывать и эксалировать.
Там, где РМ и швец и жнец и на дуде игрец — хороших проектов не жди (либо, работа просто не проектная).
У ПМа и так забот обычно полон рот — тщательное планирование сложных проектов — трудоемкая задача, анализ и мониторинг рисков — требуют времени и усилий, постоянный анализ и взаимодействие со стейкхолдерами — кто что обещал и кто на что забил, процессы проектного офиса нуждаются в улучшении, ресурсы надо планировать как минимум в среднесрочной перспективе (а есть еще и долгосрочная), чендж-менеджмент вообще отдельная песня, актуализация бюджета и его прогноз, для того что бы получить проект надо поучаствовать в пресейле, заказчики и спонсоры не могут по русски и все надо переводить на инглиш/дойч, и т.д. и т.п.
Не говоря уж об участии в судах, разборах полетов, ревью проектов и команд, и т.д. и т.п.
Да, есть ПМы, кто не планирует ресурсы в проджекте, мне вон подрядчики на 3000 человеко-часов планы присылают на 10 строчек, но говорю — это подход ПМа-разгильдяя.
Есть и разработчики, кто и в системном администрировании да, и в починке примусов )))
Правильный ПМ несет ответственность за бюджет, сроки, скоуп (очень часто еще за ресурсы) — и имено в рамках этого отвечает перед руковдством (не тимлид косячнул при оценке, а я косячнул при планировании, в следующий раз накину на дурного тимлида или не буду иметь с ним дело, пусть в другую команду идет). Он берет на себя эту ответственность и несет ее. Плохие ПМы отвечают за кодстандарт в организации, за команды, за полив цветов и т.д. и т.п. Таких я знаю много — получают они крайне мало. Творчества такого я тоже встречал на своем карьерном пути — вагон, выражение «Война план покажет» — прямо описывает подход к планированию 90% ПМов которых я знаю.
А вот людей, кто возьмет проект в треугольнике, и придет к тебе с результатом в этом треугольнике — я знаю единицы.
Есть функциональные руководители — лидеры, и как правило хорошо понимающие в своей области люди. Но получают они сильно меньше ПМов годных. Но есть и проблема — годному ПМу тяжело найти место за пределами Мск — проектного подхода нет, все эджайлить желают в плохом смысле этого слова.
Насчет администратора и руководителя — вопрос философский. У правильного ПМа — стейкхолдеры — финдиректора компаний, ИТ-директора, главы казначейств, главные инженеры — абы какие проекты эти люди не берут (да и дорого платить человеку с РМР которых хочет 200к в месяц за внедрение проекта, который 5м в год приносит).
А руководители — есть тоже разные, есть топ-менеджменты (среди которых я ведущих себя как решающих судьбу не встречал, только в госах), есть те кто шушерой «руководит» — эти иногда выпендриваются, но как правило до первого оффера их сотрудника, далее продолжают то же с джунами. Иногда нормальные люди, болеющие за команду и результат.
Там, где РМ и швец и жнец и на дуде игрец — хороших проектов не жди (либо, работа просто не проектная).
У ПМа и так забот обычно полон рот — тщательное планирование сложных проектов — трудоемкая задача, анализ и мониторинг рисков — требуют времени и усилий, постоянный анализ и взаимодействие со стейкхолдерами — кто что обещал и кто на что забил, процессы проектного офиса нуждаются в улучшении, ресурсы надо планировать как минимум в среднесрочной перспективе (а есть еще и долгосрочная), чендж-менеджмент вообще отдельная песня, актуализация бюджета и его прогноз, для того что бы получить проект надо поучаствовать в пресейле, заказчики и спонсоры не могут по русски и все надо переводить на инглиш/дойч, и т.д. и т.п.
Не говоря уж об участии в судах, разборах полетов, ревью проектов и команд, и т.д. и т.п.
Да, есть ПМы, кто не планирует ресурсы в проджекте, мне вон подрядчики на 3000 человеко-часов планы присылают на 10 строчек, но говорю — это подход ПМа-разгильдяя.
Есть и разработчики, кто и в системном администрировании да, и в починке примусов )))
Правильный ПМ несет ответственность за бюджет, сроки, скоуп (очень часто еще за ресурсы) — и имено в рамках этого отвечает перед руковдством (не тимлид косячнул при оценке, а я косячнул при планировании, в следующий раз накину на дурного тимлида или не буду иметь с ним дело, пусть в другую команду идет). Он берет на себя эту ответственность и несет ее. Плохие ПМы отвечают за кодстандарт в организации, за команды, за полив цветов и т.д. и т.п. Таких я знаю много — получают они крайне мало. Творчества такого я тоже встречал на своем карьерном пути — вагон, выражение «Война план покажет» — прямо описывает подход к планированию 90% ПМов которых я знаю.
А вот людей, кто возьмет проект в треугольнике, и придет к тебе с результатом в этом треугольнике — я знаю единицы.
Есть функциональные руководители — лидеры, и как правило хорошо понимающие в своей области люди. Но получают они сильно меньше ПМов годных. Но есть и проблема — годному ПМу тяжело найти место за пределами Мск — проектного подхода нет, все эджайлить желают в плохом смысле этого слова.
Насчет администратора и руководителя — вопрос философский. У правильного ПМа — стейкхолдеры — финдиректора компаний, ИТ-директора, главы казначейств, главные инженеры — абы какие проекты эти люди не берут (да и дорого платить человеку с РМР которых хочет 200к в месяц за внедрение проекта, который 5м в год приносит).
А руководители — есть тоже разные, есть топ-менеджменты (среди которых я ведущих себя как решающих судьбу не встречал, только в госах), есть те кто шушерой «руководит» — эти иногда выпендриваются, но как правило до первого оффера их сотрудника, далее продолжают то же с джунами. Иногда нормальные люди, болеющие за команду и результат.
Менеджер должен быть адекватным. Будь он экспертом или профаном в предметной области, он должен понимать предел своих компетенций и обращаться к настоящим экспертам при необходимости.
Согласен, что полным профаном в программировании менеджер быть просто не имеет права быть, но вместе с тем ему просто незачем иметь идеальные скиллы в этом, ибо тогда нет необходимости в программисте. А вот вопросы взаимопонимания стоит, наверное, рассматривать больше с точки зрения человеческих качеств и командной работы.
Никто ничего не противопоставляет. Но Менеджер — это в первую очередь управленец.
Жду статью «Нужно ли менеджеру уметь программировать».
Вы не поверите, но это статья как раз написана как продолжение вот этой — Нужно ли менеджеру уметь программировать
Sign up to leave a comment.
Менеджеру нужно уметь думать, а не программировать