Хорошие менеджеры проектов нуждаются в программировании? [закрыто]

Иногда я терпеть не могу, когда руководители проектов просят меня оценить время для выполнения различных задач. Оценка - это предположение, и догадки могут быть неверными. Как правило, плохие требования и документация приводят к неправильным предположениям.

Поэтому я часто задаюсь вопросом, пытались ли менеджеры проектов когда-либо пытаться угадать, сколько времени займет задача X и Y, и насколько сложно присвоить ей номер, основываясь на том, что мало известно и получено от клиента.

Мой вопрос: нужно ли руководителям проектов иметь опыт программирования?

Или, может быть, вопрос в том, должны ли хорошие менеджеры проектов быть хорошим программистом раньше? Есть ли какая-то корреляция?

Управление ИТ-проектами определенно не то же самое, что управление другими типами проектов. Однажды я слышал о менеджере проектов без опыта работы с ИТ. В итоге он расстроил программистов и в основном отпугнул их.

С другой стороны, программист, который становится менеджером проекта, может стать управляющим, думая, что он может что-то исправить, если он (-ы) не сможет заставить программистов делать это должным образом (это было моей проблемой в подобных ситуациях)

Менеджер с сильным техническим образованием обычно лучше понимает, как «думает» их команда. Всегда лучше иметь менеджера, который вас понимает, не так ли?

Нет. Два совершенно разных навыка. Плохой менеджер проекта не обязательно тот, кто не понимает ИТ, и наоборот.

Быть разумным, рациональным, организованным, понимать цели проекта и связанный с ним бизнес , а также хороший мотиватор вовсе не зависит от способности программировать.

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

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

Аргумент в пользу способности менеджеров проектов без технического образования напоминает мне кое-что из этого:

Я честно думаю, что ответ - нет. Для того, чтобы стать хорошим менеджером проекта, нужен целый набор компетенций, и быть программистом не входит в их число. Хороший менеджер проекта может управлять любым проектом любого типа, учитывая, что в команде проекта есть хорошие люди, которые знают, что они делают. Главное качество, которым должен обладать менеджер проекта - это навыки общения . Работа менеджера проекта заключается в координации задач проекта и поддержании связи между заказчиком, проектными группами и любыми другими заинтересованными сторонами. Он / она должен всегда знать, как продвигается команда и сталкиваются ли они с препятствиями, но ему не нужно знать, в чем заключается проблема или что вам нужно для ее устранения, если это не затрагивает другого человека в команде, чье время должны быть скорректированы, чтобы помочь решить проблему.

Что касается оценки, это реальность жизни на любой работе. Вы никогда не могли бы построить дом вовремя, если бы электрик не мог сказать вам, сколько времени ему понадобится, чтобы выполнить электромонтаж - когда вы узнаете, чтобы забронировать парня на стенах? Я согласен с тем, что в ИТ очень сложно давать оценки из-за большого количества невесомых. Клиенты не всегда знают, чего они хотят, и они забывают рассказать вам кучу вещей. То, что я делал, это примерно подсчитал, сколько времени я думал, что это займет, а затем умножьте его на 2! И хороший менеджер программы не должен распинать вас, когда ваша оценка окажется неправильной, это вызовет у него некоторые головные боли, чтобы перестроить расписание, поговорить с клиентом, объяснить начальникам, что это будет стоить дороже, и т.д ... Но это часть их работы - опять же, в основном то, что требуется.

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

Наконец, я не говорю, что для управления ИТ-проектом не требуется никаких навыков в области ИТ - ИТ-специалисты, которые просто не могут вульгарно говорить то, что говорят для простого народа (!), Это помогает узнать Основной жаргон, чтобы иметь возможность общаться с ними! Также важно знать основные шаги - вам нужно настроить сервер, прежде чем запускать на нем веб-сайт. Я не смог бы справиться со строительным проектом, если бы не знал, что электрика должна закончить проводку, прежде чем я закрою стены!

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

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

Я не думаю, что менеджер проекта ИТ-проекта требует ИТ-фона. Но он / она должен определенно понимать ИТ и должен знать, как работают ИТ-проекты.

Хотя ИТ-опыт является дополнительным преимуществом, его отсутствие не делает менеджера ИТ-проектов не очень хорошим. Также наличие ИТ-фона не является решающим фактором.

Я работал с обоими типами, и у каждого был свой уникальный набор качеств и проблем.

С ИТ-фоном:
- Понял бы, когда мы говорим об ошибке производительности, потому что код не многопоточный
- Но, в некоторых ситуациях, сказал бы: «Эй, да ладно, это просто добавление 4 строк кода, вы можете сделать это за 10 дней»

Без ИТ-знаний:
- Было бы очень удобно вести переговоры об удобном изменении срока
- Для проекта без каких-либо требований (вообще, пока), иногда говорили бы: «Можем ли мы дать приблизительную оценку в 100 дней и упомянуть 30% буфер».

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

@NimChimpsky Я согласен.

Дело в том , что , а не как (Active Listening - хороший инструмент).

Оценка работает для небольших технических задач, но для планирования вам нужно работать вместе, чтобы увидеть всю сложность. И вы не соперники.

Это определенно помогло бы, особенно если бы они не были хорошим менеджером проекта. Для хорошего менеджера проекта это действительно важно.

Нет.

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

Хороший или плохой менеджер проекта может иметь любой опыт:

Плохие менеджеры с техническим образованием могли быть опытными программистами, которые не понимают трудностей новичков, сталкивающихся с обычными, «простыми» понятиями, такими как указатели.

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

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

Технические знания не предопределяют квалификацию программиста в качестве менеджера, потому что навыки, требуемые в обоих заданиях, совершенно разные. Так что нет.

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

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

По моему мнению, любая крайность плоха; Люди с недостаточным опытом программирования могут слепо доверять своим программистам (Шепард следует за овцами); Люди со слишком большим опытом могут постоянно подвергать сомнению усилия своей команды (микроуправление).

Лично я думаю, что тот, кто хорошо разбирается в основных концепциях программирования, но понимает, что они не являются «горячим выстрелом», - идеальный тип менеджера.

Определенно.

Я должен быть осторожен с этим, потому что он основан на реальных историях, но я постараюсь объяснить мою боль.

Я работаю инженером-программистом, и у нас есть менеджер проектов, с которым я много работаю в последнее время. У него нет технической подготовки, и, похоже, это его совсем не интересует, но это не проблема (у каждого свои интересы). Если вам не нравятся технические ноу-хау, потому что это немного «странно», чем ваше, НО, если ваша работа - разговаривать с заказчиком на техническом уровне, важно иметь технические знания, которых он не имеет. иметь.

В любом случае, есть парень, который ничего не понимает о том, как работает сервер, как работает веб-страница, как работает программирование и так далее. Иногда я чувствую, что он НИЧЕГО не знает. Поэтому каждый раз, когда я пытаюсь объяснить ему, что мы должны делать сейчас или в чем проблема, то, что мы имеем в данный момент, он ничего не понимает. И он не такой парень, который сказал бы: «Подожди секунду. Можешь повторить, что я действительно не совсем понимаю». Нет, он из тех парней, которые не хотят показывать, что ничего не поняли за весь разговор.

Но это не заканчивается здесь, потому что он тогда звонит клиенту и говорит что-то, что в принципе не соответствует действительности. И в итоге мы должны созвониться с клиентом, чтобы еще раз прояснить ситуацию.

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

Кстати, так как я работаю с ним, моя работа больше не веселая.

Я бы сказал, да, он должен иметь некоторый опыт программирования. Если менеджер не имеет ни малейшего представления о том, на что это похоже, программировать, он получит нереальные оценки для разработки и исправления ошибок. Кроме того, он не понимает каких-либо технических проблем достаточно хорошо, чтобы принять решение. Программисты в команде могут лгать ему, и он может не осознавать, также программисты могут сказать ему проблему, и он может подумать, что они бредят

Технические навыки не делают хорошего менеджера, хорошие управленческие навыки делают. Это может быть полезно, если менеджер провел свое время в «окопах», так как он может оценить процесс, который не может иметь непрофессионал. Тем не менее, это также может привести к некоторому контролю, который даже у менеджеров-неспециалистов нет. Они могут попытаться сделать всю работу самостоятельно или внимательно изучить вашу работу.

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

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

Кажется, есть некоторая путаница:

ПМ не босс разработчиков . Лицо, ответственное за команду разработчиков (руководитель группы, менеджер) и занимающееся наймом и оценками, должно решить, достаточно ли вы работаете.

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

Вы можете быть премьер-министром, если вы: A) понимаете, как управлять проектами B) понимаете процесс разработки. Ни один из них не требует знания кодирования, но это может помочь.

Определение того, достаточно ли программисты выполняют работу, не является обязанностью руководителя, если только он не выступит в роли руководителя группы. Чтобы узнать, действительно ли кто-то «выдувает дым» во время выполнения задачи, у менеджера всегда будет преимущество, если он понимает, что с этим связано.

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

Мне вспоминается старая поговорка: «Не нужно быть сумасшедшим, чтобы работать здесь, но это помогает».

Короткий ответ заключается в том, что практический опыт кодирования не является обязательным условием хорошего программного обеспечения, но обычно это предпочтительнее. Для того, чтобы стать умелым руководителем, важно понимать процесс разработки (независимо от используемой методологии) и полагать, что разработчики хотят и могут выполнять свою работу. Опыт разработки дает практические знания об этом процессе, поэтому он помогает. Премьер-министры, которые продвигаются по служебной лестнице в компании, дополнительно знают корпоративную культуру (и кодовую базу), и поддерживают связь с другими давними членами команды разработчиков, поэтому IMO вместо лучших менеджеров продвигается изнутри. быть привезенным извне. Если кто-то за пределами компании может управлять командой лучше, чем кто-то изнутри, это ОЧЕНЬ неправильно.

Одна вещь, которую я упомянул, это связь между PM и командой разработчиков. Это как на межличностном, так и на техническом уровне. Ключ здесь - это общение; разработчики должны чувствовать, что они могут доставлять проблемы, как технические, так и межличностные, в ПМ, и ПМ должен понимать членов команды разработчиков, когда они описывают проблему.

Что касается специфики вашего вопроса, оценка именно такова; обоснованное предположение относительно количества (в отличие от гипотезы, которая является более общим прогнозом результата будущего события). Менеджер обычно либо математически, либо интуитивно применяет некоторый модификатор, основываясь на ваших последних оценках в сравнении с фактическими сроками. Agile встраивает это в процесс оценки; клиент интуитивно оценивает сложность требований, затем разработчики делают то же самое, а затем разработчики фактически выходят и разрабатывают решение, предоставляя менеджерам точки данных для расчета соотношения точек требований к баллам dev, а dev баллов - человеку требования

Короче говоря, менеджер примет вашу оценку по номиналу только в одном из трех сценариев:

• Вы были довольно точны с вашими оценками аналогичных задач в прошлом.
• Он находится под давлением, и ваша оценка лучше, чем он думал.
• Он ищет причину уволить тебя.

Если это та последняя ситуация, на рабочем месте будет много других подсказок, которые, возможно, вам следует убрать.

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