Ну, люди на собеседовании обычно ведут себя не слишком адекватно :).
Множество раз замечал, как собеседуемые не отвечают на простейшие вопросы только потому, что считают: «здесь серьёзные люди и серьёзное собеседование — значит вопрос с подвохом. Ну не могут же они такую элементарную вещь спрашивать»…
Никто и не говорил, что важно что это за люди. Важно то, насколько люди профессиональны, мотивированы и понимают суть своей работы.
При любом, даже самом лучшем процессе плохой программист хорошего кода не напишет. Обратное изредка случается. Хотя тоже из области фантастики.
Кстати, любой процесс увеличивает производительность в среднем на 5-10%. Максимум — на 35%. Роберт Гласс исследовал в своё время.
Так что, всего хорошо в меру, но увлечение процессом и игнорирование people management'а губительно для команды.
Почитайте «Успешные проекты и команды» Демарко и Листера. Это (наряду с Бруксом) — классика из обязательной к прочтению профессиональными ПМами. Уверен, ваше мнение немного поменяется.
Да. Насчёт успеха вы выразились гораздо точнее. Действительно, плохо произведённый проект тоже может быть успешным.
С другой стороны, не думаю, что ПМ может принимать решение о смене приоритетов. Это должны решать всё те же маркетологи.
А вообще — всё сильно зависит от конкретной ситуации. Функции, которые разные фирмы возлагают на руководителя проектов, сильно разные. Это видно даже из этого обсуждения.
Конечно. Именно поэтому рост прибыли не входит в сферу ответственности руководителя проекта. Конечно, хороший ПМ должен быть заинтересован в росте прибыльности компании, но отвечает он только за успех проекта.
Если успешный проект не ведёт к росту прибыли — это уже ошибки стратегического масштаба.
Сравнение с машиной совершенно некорректно. Я абсолютно с тем же успехом могу спросить, заставите ли вы на самолёте единственного пилота разносить обед пассажирам вместо стюардессы? Или, продолжая сравнение, будете ли вы требовать от этого водителя, чтобы он во время движения играл на волынке и занимался финансовым анализом ситуации на рынке плюшевых медведей?
Может быть, мы просто про разные сферы деятельности говорим? Я, к сожалению, про завод ничего сказать не могу, т.к. совершенно не знаком с предметом. Возможно, для завода такой подход и пройдёт, хотя тоже сомневаюсь.
Вообще — если сфера ответственности определена чётко и KPI вы заявляете менеджеру при найме, то это его вопрос соглашаться на эту работу или нет.
Я бы никогда не согласился взять ответственность «за всё». Просто потому, что никто не сможет делать «всё» эффективно. А за свою работу менеджер отвечает всегда, если уж взялся делать.
Да. Менеджер-программист — это боль. Задачи совершенно разные. Тимлид вполне нормально ставит задачи и распределяет работу, но вот, когда к этому добавляются бюджет, сроки и разговорчивый заказчик, всё становится плохо.
Такой проект обычно умирает. Если только программист не перестаёт писать практически полностью и не становится «нормальным» ПМом.
Ну, собственно, именно это я и хотел сказать. когда писал про линейных руководителей. Они и техническими специалистами могут быть вполне, не обязательно ПМами. Другое дело, что на них будет дополнительная ответственность за их часть команды.
Ну и, кстати, про небольшие компании — у таких компаний проекты с количеством человек больше 7 встречаются редко.
«Конкретная работа» — абсолютно не конкретная формулировка. Чуть более конкретная, чем: «задача ПМа, чтобы компания зарабатывала деньги» :).
Что в вашем понимании «результат»?
Если вас как бизнесмена интересуют лишь деньги на счёте — это, вроде, нормально. Хотя, конечно, стратегическое развитие компании тоже в вашей компетенции.
Вы, вероятно, путаете руководителя проектов и, скажем, руководителя направления или директора компании. Но у них специфика такая, что непосредственно проектами они напрямую не руководят.
Понимаете, в вашем комментарии очень нечётко определено «отвечает за результат своего труда». А менеджер должен отвечать за конкретные вещи: поиск заказчиков, текущее общение с клиентами, аналитика, бюджет и сроки, люди, продажи, бизнес-стратегия. Согласитесь, тяжеловато всё это на одного грузить.
«Отвечать за всё» = «не отвечать ни за что». Человек должен заниматься конкретной работой, а не интегрировать в себе задачи пяти должностей. Это как два зайца, за которыми, как известно, гнаться не советуют.
Вот когда человеку чётко сказано, за что он отвечает, тогда и эффект есть.
Если это не прекращается и команда не растёт профессионально, значит надо задуматься об эффективности вашей работы с программистами.
Если же всё нормально, то через некоторое время у вас будет отличная профессиональная команда, да и лояльная, к тому же, т.к. все будут понимать. что именно вы их воспитали.
Плохо это. Не хорошо. Менеджер проекта отвечает за успех проекта. За то, что он будет сдан вовремя и не выйдет из бюджета. За то, что команда после его окончания не разбежится и получит какие-то новые знания, профессионально вырастет. За то, что заказчик будет доволен результатом и захочет работать с вами дальше.
Но соглашусь с вами: наиболее важная (я бы даже сказал — решающая) составляющая в успехе проекта — это хорошая команда, поэтому работе с людьми надо уделять наибольшее внимание. Но ограничиваться только этим — опасно.
Спасибо за то, что разъяснили. Изначально я понял вас совсем по другому. Сделал вывод, что хороший менеджер вообще не может происходить из программистов. Опровержений — миллион, честно говоря :).
А по ответу — действительно, быть одновременно хорошим менеджером и хорошим программистом невозможно. Именно по тем причинам, которые вы описываете. Тут я с вами полностью согласен.
Почитайте Гласса — Факты и заблуждения профессионального программирования. Он в предисловии как раз говорит о том, что не нужно рваться в менеджеры — можно оставаться техническим специалистом.
Не знаю, где как, а у нас в компании некоторые технические специалисты получают гораздо больше ПМов.
Главная проблема в том, что «фича вылезла как подразумеваемая». Если она будет чётко заявлена — проблем не будет: да, каталог будет, стоит $2000, но, поскольку пока материала нет, мы это отложим до второй версии.
Я так понял, что не в материалах дело, а в том, что ни он ни аналитики не думали о каталоге на этапе формирования ТЗ.
По поводу недостатка материалов работает грамотный договор, в котором чётко прописано, к каким дата должен заказчик придоставить всё, что от него требуется: наброски интерфейсов, данные, тексты.
Если такого нет, или сроки не указаны, то вполне реален простой именно из-за того, что «ещё и нет материалов для этого каталога»
> Но а «это вы мне не заказывали» это всегда сложная история, когда клиент после сдачи сайта говорит «а где мой каталог товаров???», и на ответ «вы его не заказывали» начинают ругаться что «как я мог не подумать, что его вид деятельности обязательно подразумевает каталог!»…
Это, вполне возможно, недоработка аналитиков. Уже писали про то, что задача не «сделать сайт», а «увеличить прибыль путём привлечения новых клиентов с помощью вебсайта». Поэтому аналитику самому немного в шкуру заказчика залезть надо.
Каждый должен заниматься своим делом. Тренировать команду должен тимлид, а не руководитель проекта.
Руководитель проекта должен профессионально руководить: работать с людьми, со сроками, с бюджетом, с топами, иногда — с заказчиком (хотя это уже дело аккаунта). Организовать нормальную работу команде, сделать так, чтобы ничего не мешало, чтобы были чёткие задачи, чёткие сроки, чёткие требования. Ну и ещё много всего.
Для поддержки профессиональной компетентности как программиста нужно постоянно быть «в теме». Для этого нужно, как минимум, постоянно писать. Это время. Время, которое он мог бы потратить на совершенствование себя как руководителя.
Множество раз замечал, как собеседуемые не отвечают на простейшие вопросы только потому, что считают: «здесь серьёзные люди и серьёзное собеседование — значит вопрос с подвохом. Ну не могут же они такую элементарную вещь спрашивать»…
Но это уже тема отдельной статьи…
При любом, даже самом лучшем процессе плохой программист хорошего кода не напишет. Обратное изредка случается. Хотя тоже из области фантастики.
Кстати, любой процесс увеличивает производительность в среднем на 5-10%. Максимум — на 35%. Роберт Гласс исследовал в своё время.
Так что, всего хорошо в меру, но увлечение процессом и игнорирование people management'а губительно для команды.
Почитайте «Успешные проекты и команды» Демарко и Листера. Это (наряду с Бруксом) — классика из обязательной к прочтению профессиональными ПМами. Уверен, ваше мнение немного поменяется.
С другой стороны, не думаю, что ПМ может принимать решение о смене приоритетов. Это должны решать всё те же маркетологи.
А вообще — всё сильно зависит от конкретной ситуации. Функции, которые разные фирмы возлагают на руководителя проектов, сильно разные. Это видно даже из этого обсуждения.
Если успешный проект не ведёт к росту прибыли — это уже ошибки стратегического масштаба.
Может быть, мы просто про разные сферы деятельности говорим? Я, к сожалению, про завод ничего сказать не могу, т.к. совершенно не знаком с предметом. Возможно, для завода такой подход и пройдёт, хотя тоже сомневаюсь.
Вообще — если сфера ответственности определена чётко и KPI вы заявляете менеджеру при найме, то это его вопрос соглашаться на эту работу или нет.
Я бы никогда не согласился взять ответственность «за всё». Просто потому, что никто не сможет делать «всё» эффективно. А за свою работу менеджер отвечает всегда, если уж взялся делать.
Такой проект обычно умирает. Если только программист не перестаёт писать практически полностью и не становится «нормальным» ПМом.
Ну и, кстати, про небольшие компании — у таких компаний проекты с количеством человек больше 7 встречаются редко.
Что в вашем понимании «результат»?
Если вас как бизнесмена интересуют лишь деньги на счёте — это, вроде, нормально. Хотя, конечно, стратегическое развитие компании тоже в вашей компетенции.
Вы, вероятно, путаете руководителя проектов и, скажем, руководителя направления или директора компании. Но у них специфика такая, что непосредственно проектами они напрямую не руководят.
На практике: проекты с командой из 4 человек и более съедают 100% времени, 2-3 — 75%. 1 человек — около 25-30%.
Для проектов > 7-10 человек необходимо делить проект на подпроекты и ставить во главе каждого линейного руководителя.
«Отвечать за всё» = «не отвечать ни за что». Человек должен заниматься конкретной работой, а не интегрировать в себе задачи пяти должностей. Это как два зайца, за которыми, как известно, гнаться не советуют.
Вот когда человеку чётко сказано, за что он отвечает, тогда и эффект есть.
Если же всё нормально, то через некоторое время у вас будет отличная профессиональная команда, да и лояльная, к тому же, т.к. все будут понимать. что именно вы их воспитали.
Но соглашусь с вами: наиболее важная (я бы даже сказал — решающая) составляющая в успехе проекта — это хорошая команда, поэтому работе с людьми надо уделять наибольшее внимание. Но ограничиваться только этим — опасно.
А по ответу — действительно, быть одновременно хорошим менеджером и хорошим программистом невозможно. Именно по тем причинам, которые вы описываете. Тут я с вами полностью согласен.
Не знаю, где как, а у нас в компании некоторые технические специалисты получают гораздо больше ПМов.
А пределы роста есть только локальные.
По поводу недостатка материалов работает грамотный договор, в котором чётко прописано, к каким дата должен заказчик придоставить всё, что от него требуется: наброски интерфейсов, данные, тексты.
Если такого нет, или сроки не указаны, то вполне реален простой именно из-за того, что «ещё и нет материалов для этого каталога»
Это, вполне возможно, недоработка аналитиков. Уже писали про то, что задача не «сделать сайт», а «увеличить прибыль путём привлечения новых клиентов с помощью вебсайта». Поэтому аналитику самому немного в шкуру заказчика залезть надо.
Руководитель проекта должен профессионально руководить: работать с людьми, со сроками, с бюджетом, с топами, иногда — с заказчиком (хотя это уже дело аккаунта). Организовать нормальную работу команде, сделать так, чтобы ничего не мешало, чтобы были чёткие задачи, чёткие сроки, чёткие требования. Ну и ещё много всего.
Для поддержки профессиональной компетентности как программиста нужно постоянно быть «в теме». Для этого нужно, как минимум, постоянно писать. Это время. Время, которое он мог бы потратить на совершенствование себя как руководителя.