Меня немного просто раздражает позиция — ты работаешь в области Х менеджером, иди получи по ней высшее образование, отработай 10 лет исполнителем, а потом иди в ней руководить.
Роль менеджера — обесценивается, все привыкли что менеджер — это чувак, который ничего не понимает ни в чем, но всегда требует заполнить ТШ и сделать задачу за 3 секунды качественно.
Хорошего менеджера, кроме прочего, отличает внимательность к деталям (и желание разбираться в любой мутной воде на проекте), чрезмерная тяга к планированию и контролированию вверенных ему проектов или процессов.
Для такого менеджера ситуация «я уже год работаю на другую компанию, а меня спалили потому что я отчет оценил крайне неадекватно» невозможна в принципе.
Хотя плохих менеджеров — большинство, это не значит что такими надо быть.
В 12 (4 государственные (внезапно одни из наименее бюрократизированных), 2 ~ 300 чел (одна очень бюрократизирована), 1 — 2000 чел, 2 — 100 чел, 3 < 20. 3 из них ИТ и только ИТ (и одна ИТ — та, что наиболее бюрократизирована). В маленьких компаниях — нормальных менеджеров (и нормального менеджмента) не видел. Видел хорошо доработанный и старательно примененный эджайл, который избавлял от необходимости в сильном менеджменте и регламентах.
Я скажу что хорошо делались проекты по fixprice в наиболее бюрократизированной компании. Хорошо — это в срок, в бюждет и без 19000500 обращений по гарантии, с клиентами которые возвращались.
>> Тот, не будучи ИТ-специалистом, их читал и кивал головой, ок, разбирайся.
Вот я бы вот тут напрягся. У меня в команде много разных людей, и неадекваты тоже есть, и их видно. Когда вам человек замечания на документ простой не может написать 3 дня, вы о его стиле работы сделаете вывод сразу. Еще есть hr'ы которые свой хлеб у нас не зря едят и не берут кого попало, есть и функциональные руководители, кто смотрит загрузку постоянно и разбирается в предметной области лучше меня.
>> А сроки в ИТ — штука вообще сложно прогнозируемая.
В проектах типа MS Word — соглашусь ) В проектах типа обновляем ERP в компании на 2000 человек — не соглашусь, обычно все проблемы со сроками из за некомпетентности/желания сделать 33 проекта и получить бабла с 33 заказчиков одновременно.
>> Но у меня достаточно компетенций в каждой из областей
Вот именно, достаточно. Не надо 4 высших образования иметь, что бы понимать чем занимается бухгалтер или программист — если у вас есть схожий опыт работы, вы просечете это очень быстро. Если вы работали 5 лет аналитиком в ИТ компании, поверьте вы будете разрабов видеть насквозь. Хотя ни разу строчки кода не напишете.
>> не нужно быть семи пядей во лбу, чтобы знать на достаточном для эффективной коммуникации уровне всё вышеперечисленное, и многое другое
Вот и я про то же. Не надо уметь программировать самому — надо сесть и разобраться, загуглить, спросить экспертизу у коллег.
Я ПМом работаю и работал с многими компаниями и экспертизы часто в чем то не хватало — области заказчиков разные, один лекарства производит, другой мебелью торгует. Но садились и разбирались быстро, привлекали оперативно экспертов, и задачи клиентов решали — желание было.
Про нужно — согласен )
Но, ограниченная экспертиза ПМа в области какой то — плохой способ управления. ПМ который 22 проекта сделал похожих, оценит риски намного лучше, чем ПМ без проектов с подобным скоупом, стейкхолдерами и ограничениями, но со знанием разработки )))
Хирург не может строить ракеты, но он может стать главным врачем в клинике. В клинике, где будут хирурги, терапевты, стоматологи, патологоанатомы, водители, уборщицы, строители и даже менеджеры по продажам, а даже IT.
И хирург этого всего не должен уметь. А точнее — дожен знать все по верхам и уметь подключать экспертизы.
Если тебе начитотдела ИТ говорит что делать сайт клиники — 10 млн, ты даешь заму задачу сделать RFP, позвонить в консалтинг, собрать 5 КП и 5 оценок RFP и выдать 5 КП. После чего либо начальник ИТ отдела идет на мороз за некомпетентность, либо тебе специально обученный менеджер по продажам в КП объясняет ПОНЯТНО почему это столько стоит — и это поверьте мне более чем реально сделать, переведя конкретные трудозатраты на язык бизнеса.
А вы видели хоть одного менеджера, который не умеет читать на языке, котором ведет проект? Или писать на нем? Или вы думаете задачи в трекере и ответы о тестировании и внедрении пишутся на языках программирования? Или, для того что бы менеджеру организовать отчетность о тестировании или разработке на проекте — нужно программирование знать?
Да и ИТ редко попадают из строительства или филологии, так или иначе опыт работы в ИТ у всех менеджеров в ИТ обычно есть (скорее всего аналитика, но может быть и сисадминство, техподдержка, продажи). Совсем уж левых людей тут нет — дворника или поэта ПМом работать внезапно не возьмут.
Для того что бы понимать что делают программисты — программировать не надо.
Для того что бы быть уверенным, что у тебя нормально сварен шов — надо посмотреть отчет о тестировании сварки, и если он провален — заставить команду сварки (через ее руководителя) сделать так, что бы он был ок. Как заставить — методов материальной и нематериальной мотивации у менеджера полно — например, уверенно объяснить что после еще одного проваленного шовного теста будет увольнение и уголовное преследование.
А сидеть и учиться швы варить — и тем более учить этому сварщиков — неправильно. Это значит, что менеджер у себя ситуацию не контролирует вообще, если он до такого доходит, и проектом управлять не способен.
А программист не перегруженное слово? ) ИМХО так же как менеджер используется. Только в случае с разработчиком — все вникают в ньюансы, на чем кодишь, бэкэнд, фронтэнд, ДБ или что то еще.
С менеджером — тыжменеджер, значит дожен уметь все (и вот теперь кодить, внезапно тоже!).
Вы какого то менджера описываете, не у которого нет навыков разработки, а который просто на проекте ничего не делает. Менеджер у вас что, не читал договор, не читал регламенты проведения рефакторинга, не читал регламенты выдачи релизов? Если нет — то гоните его, он на работе у вас видимо на другую контору работает.
По поводу рисков — поверьте, их взвесить грамотно не могут люди даже в своей области работающие. Пример — одну из самых известных компаний в Москве по консалтингу в сфере рисков закрыли за уклонение от налогов. Этот риск они не учли.
Тоже мне бином Ньютона! Думаете разработчик, который ниче не делает на работе, сидит и рандомные строчки кода набирает? Он сидит на пикабу, в викеюшке, телефоне, да где угодно. Да, если он на апворке работает парралельно, наверное не разработчик не отличит корпоративную среду разработки от некорпоративной.
Но нормальный менеджер это спалит в первый день, когда оцененные задачи на день не будут выполнены.
Менеджер обычно сам карьерист, чуть более успешно подсевший на уши топ-менеджерам ))) Или вы думаете менеджеры не думают о карьере, не умеют шантажировать руководство, не умеют выгодно показать результаты свой (часто, весьма не столь упорной) работы?
Во многих организация — плохие менеджеры. Менеджмент в России на уровне — я начальник, ты дурак. Но не везде, есть и нормальные управленцы, которые к команде относятся как к своему кошельку и знают, где в тот или иной момент какая монетка, и какого она достоинства. Опять же вопрос оплаты — за 50-80 тыщ вы ждете что менеджер будет решать такие проблемы? Да ему наплевать что там в организации происходит, он на пикабу сидит весь день, еще год не выгонят, а там новую работу найдет.
Про недостаток исполнителя все очень просто — если это не недостаток планирования, и не внешняя среда — это недостаток исполнителя. Никакой магии тут нет и быть не может.
В моем понимании, менеджер хороший знает чем у него сотрудники на проектах занимаются.
Почему сотрудники как менеджеру вам не докладывали о текущих задачах, их статусах? Почему вам странным не показалось, что человек простые задачи делает долго, просирает сроки? Сколько осталось таких сотрудников в вашей организации, экспертизы которых у вас нет? Сисадмин полгода не разворачивает АД? Аналитик не пишет спеку 2 недели? Саппорт не закрывает инциденты годами? Вам для работе в такой команде нужна компетенция каждого, и за каждого придется сделать минимум одну задачу?
Теоретически, менеджеру надо 2 стендапа что бы понять, что сотрудник на работе занят не работой.
На практике есть 3 типа менеджеров — микроменеджеры, делающие отчеты, макроменеджеры — в заботах о стратегии компании на ближайшие 10000 лет и не знающие чем занимается конкретно сейчас их команда, и нормальные менеджеры, которые умеют управлять в среднесрочной и долгосрочной перспективе, но при работе с новой командой — начинают с анализа краткосрочных задач.
Я встречал компании, в ИТ которых руководили женщины сильно старше 50. И ИТ работала отлично, хотя женщины ни фига в ИТ не понимали — они понимали в управлении людьми, и держали руку на пульсе. Каждый день, анализируя скоуп задач отдела/команды и спрашивая со всех когда и какой результат будет, анализируя причины успехов и факапов.
Есть ли уверенность, что человек 1-2 года занимавшийся разработкой на Дельфи, будет экспертом, начав управлять в компании использующей Java-стек?
Эффективность проектного менеджера в моем понимании — более быстрое и дешевое достижение проектных целей, в т.ч. в долгосрочной перспективе. Для этого надо коучить команду оценивать и кодить, а не оценивать и кодить самому.
Управлять рисками можно с помощью управления рисков.
Если менеджер не способен из каждого участника команды выжать возможные риски и правильно их оценить, значит он должен разбираться во ВСЕЙ области проекта.
Внедряешь 1С — знай весь бухучет, федеральные законы по учету, законы по выплате ЗП, правила аудита, программирование, системное администрирование (WinSrv, unix; PosgreSQL, MS SQL), базы данных, сети. Не хилый такой ПМ получается.
Если ХОРОШИЙ ПМ обещал что то заказчику — значит этот CR он обработал заранее, согласно процедуре управления изменениями, в которой должны быть прописаны люди, которых решение затрагивает и от них было получено согласие, после чего обещание было озвучено заказчику.
Если менеджер считает что процедуру управления изменениями придумали бюрократы из PMI, а заказчику можно обещать вот так, на свое усмотрение — видимо, у вас плохой, негодный менеджер — аналог такого менеджера, это разраб, который код в релиз самовольно дописал и никому не сказал, а потом пришел и сказал — «я уже включил это в релиз, да ни тестирование, ни релиз-менеджер, ни ПМ, ни заказчик, ни аналитика не в курсе».
Не уверен, что эти инструменты нельзя противопоставить.
Когда ты на переговорах показываешь экспертизу — это не всегда сыграет в твою пользу, ибо ты сказал «Ага, я немного разбираюсь в БД, эти работы должны стоить дороже», а тут вышел датабэйс-девелопер (которого неделю назад переманили из яндекса) и твою точку зрения разложил и обосновал меньшую цену.
Если бы ПМ не сказал «Я разбираюсь» — можно было бы просто взять таймаут. Тут же заказчик будет давить «Вы же сказали что у вас есть экспертиза и потратили наше время на ваши объяснения, а когда мы привели аргументы вы теперь берете таймаут? Это стиль работы вашей компании?».
Навык лишний конечно не помешает. Но это не значит что надо в переговорах с пациентами этими навыками аппелировать, особенно когда ты не полностью в теме. Занимайтесь своим делом, и тем, что вы знаете профессионально. Разраб не лезет в менеджмент проектов, водитель такси не лезет в политику, патологоанатом не лезет лечить людей, и т.д.
Поверьте, если вы как менеджер, будете в переговорах использовать программирование, вместо переговорных навыков и навыков управления заказчиком, пролетите вы очень быстро.
Пример — у нас был подрядчик, с менеджером, который очень хорошо разбирался в предметной области (не разраб, а скорее консультант).
Он круто объяснил нашей команде на встрече что к чему, мы не все поняли, и не стали окать решение. Вместо того что бы додавить нас, и направить нам письменно решение о выборе функционала со сроками ответа, он положился на наше «Ну казалось бы мы ок».
Когда пришле время вставлять решение в документацию — мы написали что мы не ок, и просим дополнить документ 100500 схем, таблиц и описаний.
Менеджер в шоке позвонил — мы же договаривались до другого? Мы сказали что не договаривались ни до чего, наше «казалось бы ок», не значит что мы подписываемся под чем то. По договору вы должны документ с нашими хотелками — это наша хотелка. То, что вы не запросили и не задокументировали решение (хотя бы в почте, не говоря уж про протокол встречи и его согласование) — проблема вас, как менеджера, за вас это никто не сделает.
А был бы вместо него нормальный менеджер, который бы просто прислал протокол в почте — с запросом на согласование или обозначением, что если замечаний в течении 2 рабочих дней нет, протокол считается согласованным, переговорная позиция подрядчика была бы совсем другая )))
Но обычно, человек забивает на менеджмент и полагается на навыки прогера, а это не верно в корне.
Роль менеджера — обесценивается, все привыкли что менеджер — это чувак, который ничего не понимает ни в чем, но всегда требует заполнить ТШ и сделать задачу за 3 секунды качественно.
Хорошего менеджера, кроме прочего, отличает внимательность к деталям (и желание разбираться в любой мутной воде на проекте), чрезмерная тяга к планированию и контролированию вверенных ему проектов или процессов.
Для такого менеджера ситуация «я уже год работаю на другую компанию, а меня спалили потому что я отчет оценил крайне неадекватно» невозможна в принципе.
Хотя плохих менеджеров — большинство, это не значит что такими надо быть.
Я скажу что хорошо делались проекты по fixprice в наиболее бюрократизированной компании. Хорошо — это в срок, в бюждет и без 19000500 обращений по гарантии, с клиентами которые возвращались.
Вот я бы вот тут напрягся. У меня в команде много разных людей, и неадекваты тоже есть, и их видно. Когда вам человек замечания на документ простой не может написать 3 дня, вы о его стиле работы сделаете вывод сразу. Еще есть hr'ы которые свой хлеб у нас не зря едят и не берут кого попало, есть и функциональные руководители, кто смотрит загрузку постоянно и разбирается в предметной области лучше меня.
>> А сроки в ИТ — штука вообще сложно прогнозируемая.
В проектах типа MS Word — соглашусь ) В проектах типа обновляем ERP в компании на 2000 человек — не соглашусь, обычно все проблемы со сроками из за некомпетентности/желания сделать 33 проекта и получить бабла с 33 заказчиков одновременно.
>> Но у меня достаточно компетенций в каждой из областей
Вот именно, достаточно. Не надо 4 высших образования иметь, что бы понимать чем занимается бухгалтер или программист — если у вас есть схожий опыт работы, вы просечете это очень быстро. Если вы работали 5 лет аналитиком в ИТ компании, поверьте вы будете разрабов видеть насквозь. Хотя ни разу строчки кода не напишете.
>> не нужно быть семи пядей во лбу, чтобы знать на достаточном для эффективной коммуникации уровне всё вышеперечисленное, и многое другое
Вот и я про то же. Не надо уметь программировать самому — надо сесть и разобраться, загуглить, спросить экспертизу у коллег.
Я ПМом работаю и работал с многими компаниями и экспертизы часто в чем то не хватало — области заказчиков разные, один лекарства производит, другой мебелью торгует. Но садились и разбирались быстро, привлекали оперативно экспертов, и задачи клиентов решали — желание было.
Но, ограниченная экспертиза ПМа в области какой то — плохой способ управления. ПМ который 22 проекта сделал похожих, оценит риски намного лучше, чем ПМ без проектов с подобным скоупом, стейкхолдерами и ограничениями, но со знанием разработки )))
И хирург этого всего не должен уметь. А точнее — дожен знать все по верхам и уметь подключать экспертизы.
Если тебе начитотдела ИТ говорит что делать сайт клиники — 10 млн, ты даешь заму задачу сделать RFP, позвонить в консалтинг, собрать 5 КП и 5 оценок RFP и выдать 5 КП. После чего либо начальник ИТ отдела идет на мороз за некомпетентность, либо тебе специально обученный менеджер по продажам в КП объясняет ПОНЯТНО почему это столько стоит — и это поверьте мне более чем реально сделать, переведя конкретные трудозатраты на язык бизнеса.
Да и ИТ редко попадают из строительства или филологии, так или иначе опыт работы в ИТ у всех менеджеров в ИТ обычно есть (скорее всего аналитика, но может быть и сисадминство, техподдержка, продажи). Совсем уж левых людей тут нет — дворника или поэта ПМом работать внезапно не возьмут.
Для того что бы понимать что делают программисты — программировать не надо.
Для того что бы быть уверенным, что у тебя нормально сварен шов — надо посмотреть отчет о тестировании сварки, и если он провален — заставить команду сварки (через ее руководителя) сделать так, что бы он был ок. Как заставить — методов материальной и нематериальной мотивации у менеджера полно — например, уверенно объяснить что после еще одного проваленного шовного теста будет увольнение и уголовное преследование.
А сидеть и учиться швы варить — и тем более учить этому сварщиков — неправильно. Это значит, что менеджер у себя ситуацию не контролирует вообще, если он до такого доходит, и проектом управлять не способен.
С менеджером — тыжменеджер, значит дожен уметь все (и вот теперь кодить, внезапно тоже!).
По поводу рисков — поверьте, их взвесить грамотно не могут люди даже в своей области работающие. Пример — одну из самых известных компаний в Москве по консалтингу в сфере рисков закрыли за уклонение от налогов. Этот риск они не учли.
Но нормальный менеджер это спалит в первый день, когда оцененные задачи на день не будут выполнены.
Во многих организация — плохие менеджеры. Менеджмент в России на уровне — я начальник, ты дурак. Но не везде, есть и нормальные управленцы, которые к команде относятся как к своему кошельку и знают, где в тот или иной момент какая монетка, и какого она достоинства. Опять же вопрос оплаты — за 50-80 тыщ вы ждете что менеджер будет решать такие проблемы? Да ему наплевать что там в организации происходит, он на пикабу сидит весь день, еще год не выгонят, а там новую работу найдет.
Про недостаток исполнителя все очень просто — если это не недостаток планирования, и не внешняя среда — это недостаток исполнителя. Никакой магии тут нет и быть не может.
Почему сотрудники как менеджеру вам не докладывали о текущих задачах, их статусах? Почему вам странным не показалось, что человек простые задачи делает долго, просирает сроки? Сколько осталось таких сотрудников в вашей организации, экспертизы которых у вас нет? Сисадмин полгода не разворачивает АД? Аналитик не пишет спеку 2 недели? Саппорт не закрывает инциденты годами? Вам для работе в такой команде нужна компетенция каждого, и за каждого придется сделать минимум одну задачу?
Теоретически, менеджеру надо 2 стендапа что бы понять, что сотрудник на работе занят не работой.
На практике есть 3 типа менеджеров — микроменеджеры, делающие отчеты, макроменеджеры — в заботах о стратегии компании на ближайшие 10000 лет и не знающие чем занимается конкретно сейчас их команда, и нормальные менеджеры, которые умеют управлять в среднесрочной и долгосрочной перспективе, но при работе с новой командой — начинают с анализа краткосрочных задач.
Я встречал компании, в ИТ которых руководили женщины сильно старше 50. И ИТ работала отлично, хотя женщины ни фига в ИТ не понимали — они понимали в управлении людьми, и держали руку на пульсе. Каждый день, анализируя скоуп задач отдела/команды и спрашивая со всех когда и какой результат будет, анализируя причины успехов и факапов.
Эффективность проектного менеджера в моем понимании — более быстрое и дешевое достижение проектных целей, в т.ч. в долгосрочной перспективе. Для этого надо коучить команду оценивать и кодить, а не оценивать и кодить самому.
Если менеджер не способен из каждого участника команды выжать возможные риски и правильно их оценить, значит он должен разбираться во ВСЕЙ области проекта.
Внедряешь 1С — знай весь бухучет, федеральные законы по учету, законы по выплате ЗП, правила аудита, программирование, системное администрирование (WinSrv, unix; PosgreSQL, MS SQL), базы данных, сети. Не хилый такой ПМ получается.
Если ХОРОШИЙ ПМ обещал что то заказчику — значит этот CR он обработал заранее, согласно процедуре управления изменениями, в которой должны быть прописаны люди, которых решение затрагивает и от них было получено согласие, после чего обещание было озвучено заказчику.
Если менеджер считает что процедуру управления изменениями придумали бюрократы из PMI, а заказчику можно обещать вот так, на свое усмотрение — видимо, у вас плохой, негодный менеджер — аналог такого менеджера, это разраб, который код в релиз самовольно дописал и никому не сказал, а потом пришел и сказал — «я уже включил это в релиз, да ни тестирование, ни релиз-менеджер, ни ПМ, ни заказчик, ни аналитика не в курсе».
Когда ты на переговорах показываешь экспертизу — это не всегда сыграет в твою пользу, ибо ты сказал «Ага, я немного разбираюсь в БД, эти работы должны стоить дороже», а тут вышел датабэйс-девелопер (которого неделю назад переманили из яндекса) и твою точку зрения разложил и обосновал меньшую цену.
Если бы ПМ не сказал «Я разбираюсь» — можно было бы просто взять таймаут. Тут же заказчик будет давить «Вы же сказали что у вас есть экспертиза и потратили наше время на ваши объяснения, а когда мы привели аргументы вы теперь берете таймаут? Это стиль работы вашей компании?».
Навык лишний конечно не помешает. Но это не значит что надо в переговорах с пациентами этими навыками аппелировать, особенно когда ты не полностью в теме. Занимайтесь своим делом, и тем, что вы знаете профессионально. Разраб не лезет в менеджмент проектов, водитель такси не лезет в политику, патологоанатом не лезет лечить людей, и т.д.
Пример — у нас был подрядчик, с менеджером, который очень хорошо разбирался в предметной области (не разраб, а скорее консультант).
Он круто объяснил нашей команде на встрече что к чему, мы не все поняли, и не стали окать решение. Вместо того что бы додавить нас, и направить нам письменно решение о выборе функционала со сроками ответа, он положился на наше «Ну казалось бы мы ок».
Когда пришле время вставлять решение в документацию — мы написали что мы не ок, и просим дополнить документ 100500 схем, таблиц и описаний.
Менеджер в шоке позвонил — мы же договаривались до другого? Мы сказали что не договаривались ни до чего, наше «казалось бы ок», не значит что мы подписываемся под чем то. По договору вы должны документ с нашими хотелками — это наша хотелка. То, что вы не запросили и не задокументировали решение (хотя бы в почте, не говоря уж про протокол встречи и его согласование) — проблема вас, как менеджера, за вас это никто не сделает.
А был бы вместо него нормальный менеджер, который бы просто прислал протокол в почте — с запросом на согласование или обозначением, что если замечаний в течении 2 рабочих дней нет, протокол считается согласованным, переговорная позиция подрядчика была бы совсем другая )))