Может ли человек успешно работать ПМ-ом в ИТ, не разбираясь в программироании?

ПМ - тимлид, что ли?

Может. Работа связана.

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

Тимлид - это постановка задач, планирование и распределение людских ресурсов, контроль исполнения. Каким боком здесь программинг?

> Тимлид - это постановка задач, планирование и распределение людских ресурсов, контроль исполнения. Каким боком здесь программинг?

Как человек не разбирающийся в программировании может делать планирование и контроль исполнения? Заставить программиста запланировать, а потом спросить "сделал или нет"? Такого тимлида на перле и Mail::Smtp написать можно...

Преположим программист X срывает дедлайн уже третий раз. Действия тимлида не разбирающегося в программировании ?

> Заставить программиста запланировать, а потом спросить "сделал или нет"? Такого тимлида на перле и Mail::Smtp написать можно...

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

Может. Результаты при этом можно наблюдать экстремально феерические.

// Артём, советую подучить разницу между «может» и «должен».

> Преположим программист X срывает дедлайн уже третий раз. Действия тимлида не разбирающегося в программировании ?

Мычание.

>> Преположим программист X срывает дедлайн уже третий раз. Действия тимлида не разбирающегося в программировании ?

> Мычание.

У меня было проще - лишение премиии :) Пару раз завалил дедлайны - стал более трезво оценивать свои силы... и накидывать процентов 20-30 на "непредвиденные творческие затыки". Но зато когда нужна была дополнительная информация - у меня на столе появлялись таблицы, графики, описание техпроцесса... если надо - девочка с производства подбегала и объясняла... точно также по завершении модулей или логических блоков оно начинало тестироваться, при этом я работал дальше над следующим модулем, а на стол ложился список с выявленными недочётами... У меня остались самые хорошие воспоминания от того тимлида, хотя в программировании он был... ну на уровне "открыть документ, набить текст, послать на печать". Руководитель и организатор от Бога, что тут сказать. Впрочем, раз на раз не приходится... :)

> У меня было проще - лишение премиии :) Пару раз завалил дедлайны - стал более трезво оценивать свои силы... и накидывать процентов 20-30 на "непредвиденные творческие затыки".

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

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

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

А в чем их работа заключается-то? Они делают небольшие и/или примитивные проекты? Если да, вопросов более нет.

Если нет - как не разбирающийся в программировании ПМ способен убедиться, что расписание реалистично, мэйлстоуны можно проверить, девелоперы не увлеклись разработкой супер-мега-common-framework'а c одной стороны но и не лепят грязные хаки с другой и тд?

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

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

> У меня было проще - лишение премиии :) Пару раз завалил дедлайны - стал более трезво оценивать свои силы... и накидывать процентов 20-30 на "непредвиденные творческие затыки".

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

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

С точки зрения быдлокодера всё так и есть. Ламо можно обманывать и крутить сроки на МПЧ. Такого же быдлокодера (даже если тот нифига не понимает в управлении) обмануть уже не удаётся, приходится напрягаться, работать.

> А в чем их работа заключается-то? Они делают небольшие и/или примитивные проекты? Если да, вопросов более нет.

Данные менеджеры управляют проектами федерального уровня высшей сложности, не имеющих аналогов в России.

> Если нет - как не разбирающийся в программировании ПМ способен убедиться, что расписание реалистично, мэйлстоуны можно проверить, девелоперы не увлеклись разработкой супер-мега-common-framework'а c одной стороны но и не лепят грязные хаки с другой и тд?

На то он и менеджер чтобы уметь это определять. В любом случае, даже "менеджер программист" в код в крупных проектах не смотрит.

> я уж не говорю о том что ПМ будет делать если образовались 2 девелопера или группы с разными мнениями о том в какую сторону далее двигать проект. Автоматом выберет товарища с большим стажем/харизмой/зп ?

Всегда все мнения можно привести к "удобоваримому" виду, которые понятны даже не программисту.

> Данные менеджеры управляют проектами федерального уровня высшей сложности, не имеющих аналогов в России.

федерального уровня - ох не ЕГАИС ли это случайно...

> На то он и менеджер чтобы уметь это определять. В любом случае, даже "менеджер программист" в код в крупных проектах не смотрит.

Это где как - Джоэл Спольски вон пишет что Гейтс там детально по спекам и коду шарился :-)

> Всегда все мнения можно привести к "удобоваримому" виду, которые понятны даже не программисту.

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

Давайте рассмотрим вопрос с другой строны. Если ПМу в программировании разбираться не надо, то в чем ему надо разбираться? Какие у него таланты? Заниматься администрированием и произносить мотивирующие речи перед сотрудниками? Или что-то еще?

а как человек может работать пистолетом макарова?

Считаю что не может. Моя работа связана с разработкой софта.

У нас именно такая ситуация ))

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

Не сможет. Не нужен. Оба варианта правильные.

> Если нет - как не разбирающийся в программировании ПМ способен убедиться, что расписание реалистично, мэйлстоуны можно проверить, девелоперы не увлеклись разработкой супер-мега-common-framework'а c одной стороны но и не лепят грязные хаки с другой и тд?

По опыту. Вообще, SA!=программист.

к логопеду

Так как расшифровывается точно загадочная аббревиатура "ПМ" ? В гугле забанили

ПМ == Пистоле́т Мака́рова

Проект-Менеджер.

Просто Мария.

Post Meridiem (после полудня)

Премьер-Министр

Ну и пистолет Макарова, само собой. Выбирай.

Чуть не забыл самое главное...

Павлик Морозов!

А как же Post Mortem, Post Modern, etc?

> А как же Post Mortem, Post Modern, etc?

Фантазии не хватило... :( Старый становлюсь. Пойду повешусь.

> На то он и менеджер чтобы уметь это определять.

Не владея предметной областью как он будет это делать? Спросит у гадалок, колдунов и шоманав?

> В любом случае, даже "менеджер программист" в код в крупных проектах не смотрит.

Это что за шлепок говна, который избыточность и компактность кода не проверяет? Как минимум количество глобальных переменных обязан смотреть.

> Всегда все мнения можно привести к "удобоваримому" виду, которые понятны даже не программисту.

Всегда все алгоритмы обязательно надо привести к «удобоваримому» виду. Только не зная предметной области ПМ будет делать х**ню или не делать ничего. Что в целом равноценно.

Всё неверно. «ПМ» — это «Путин Медведев».

> Считаю что не может. Моя работа связана с разработкой софта.

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

Чтобы стать нормальным ПМ-ом надо лет 10 поработать "быдлокодером".

>Чтобы стать нормальным ПМ-ом надо лет 10 поработать "быдлокодером".

Но этого недостаточно.

> Чтобы стать нормальным ПМ-ом надо лет 10 поработать "быдлокодером".

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

Временной фактор тут роли вообще не играет.

PM может не быть программистом, но в том случае, если в команде проекта есть ярко выраженный (желательно официально) ведущий программист.

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

Но не должен.

Это как «кухарка может управлять государством», но выйдет очень хреново.

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

И абсолютно столько же мега-супер-навороченых разработчиков, которых клиент нагибает как хочет, которые не могут написать грамотно Proposal Document, и которые от любых проблем на проекте прячутся в свой супер-мега-фреймворк, а потом лепят отмазы "я баг фиксил" после срыва очередного майлстоуна. Которые не имеют ни малейшего понятия о рисках и управлении изменениями и требованиями.

> стиль программирования на 2-3х языках.

Ага! Поверхностно изучить 2-3 язычка, вместо того, чтобы разбираться во фрейморках Жабы, которые действительно нужны:

http://cnews.ru/news/line/index.shtml?2008/07/29/309897 :)))

> ортогональность

Псевдонаучные термины - для теоретиков (ныне анонимных) типа Луговского. :))

PS. Сам изучил 2 языка - Жабу (для денег) и Obj-C (для дома:))

Пардон, ПМ работает с клиентами или с проектом? Если какие-то контакты у него с клиентом и есть то только по техническим вопросам.

Ну и далее есть варианты основанные на условиях:

ПМ со знаниями в программировании делает поддерживаемый проект.

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

ПМ по совместительству работающий с клиентами должен получать другие деньги.

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

> Ага! Поверхностно изучить 2-3 язычка, вместо того, чтобы разбираться во фрейморках Жабы, которые действительно нужны:

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

> Псевдонаучные термины

Для быдлокодера любой термин кроме тех, которые он почерпнул на быдлорге псевдонаучны. Я угадал.

> типа Луговского

А что он написал или сделал, кроме как срать на ЛОРе? Хоть раз он умное слово применял не для мотивации своего высера, а для описания какой-то технической детали обсуждения?

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

В читалку. Курить http://www.visualpatterns.com/agilejava.php

ПМ не делает проект - проект делают разработчики. Качество обеспечивают тестеры. Задача ПМ-а - руководить проектом.

ПМ не работающий с клиентом - это абстракция. Для кого делается этот проект?

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

Все упирается не в некие абстрактные аксиомы, а в вполне себе банальные требования того самого клиента. Если клиент хочет быстро и качественно - ПМ должен посчитать насколько это будет дорого. Есди быстро и дешево - насколько некачественно. И обьяснить это клиенту.

> Для понимания кода фреймворки знать не обязательно

Ну это Вы Роду Джонсону напишите. :)

> диалекты для разработчиков

Какие еще "диалекты"? :)) В Java "диалекты" - это супер!!! :))) Просто мечтаю выучить J++ и J#:)) MegaLOL! :)))))))))))

> ПМ не делает проект - проект делают разработчики. Качество обеспечивают тестеры. Задача ПМ-а - руководить проектом.

Значит таки ПМ работает с проектом, а не с клиентом.

> ПМ не работающий с клиентом - это абстракция. Для кого делается этот проект?

ПМ работает с задачей поставленной клиентом. Выуживание из клиента технических деталей и прочей ерунды — задача аналитика, а не ПМ. Если у ПМ таки возникнет какой-то технический вопрос, он может спросить клиента. Это единственный вероятный случай их контакта.

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

Ты дурак, да?

> Все упирается не в некие абстрактные аксиомы, а в вполне себе банальные требования того самого клиента.

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

> Ну это Вы Роду Джонсону напишите. :)

Мне почему-то кажется, что он прекрасно всё знает и без меня.

> Какие еще "диалекты"?

Почитай про компактность в программировании, я тебе лектором не нанимался. За такие лекции очень приличные деньги обычно платят.

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

> Пока не вижу ответа на главный мой вопрос - для кого делается проект.

Уясни для себя простой вопрос: Кем для кого делается проект?

// Нафиг вообще нужен ПМ, когда код пишут программисты. Пусть клиент с ними и работает. Хуле нам то морякам. Скажу по секрету, у нас — моряков все клиенты умеют излогать детали проекта простым техническим языком.

> Потом буду отвечать на все остальное.

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

Он успешно работает

> Преположим программист X срывает дедлайн уже третий раз. Действия тимлида не разбирающегося в программировании ?

Уволить программиста. :-) вникать в тонкие материи и компилировать KDE под FreeBSD никому не интересно. Интересно -- это заработать денег, а чтобы их разработать, надо все сдать в срок. задача ПМа -- обеспечить функционирование коллектива, отчетность -- программирование тут не причем. Более того -- ПМ должен быть идеологически близок к заказчику, и уметь с ним разговаривать на его языке. у программистов это плохо получается.

Руководитель проекта может не быть программистом. Может не знать ни одного языка кроме бейсика. Но он, зараза, должен понимать, что в какие сроки и какими силами делается. Иначе на задачу "добавить поле в форму" он отведёт две недели, и разработчики десять дней будут пинать балду, потому что планом не предусмотрено никакой другой работы, а на задачу "перевести склад с системы А на систему Б" он отведёт два месяца, и разработчики будут ночевать в офисе, без выходных и отпусков.

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

> С заказчиком должен работать менеджер по взаимодействию с бизнесом. Позволю себе не согласится.

Вообще у ПМ-а базовых дисциплин не так много. И разработка среди них не числится. А именно: - Интеграция - Рамки проекта (scope) - График/время - Стоимость - Качество - Люди - Коммуникации - Риски - Контракты

> федерального уровня - ох не ЕГАИС ли это случайно...

ГАС Выборы :) И подобные.

> Это где как - Джоэл Спольски вон пишет что Гейтс там детально по спекам и коду шарился :-)

Читал Спольски. Он, если мне не изменяет память, говорил только про спеки.

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

Приводящему тоже зарплату платят. Пару раз "полный капец" и его уволят. В нормальном проекте таких ситуаций не должно быть в принципе.

> Давайте рассмотрим вопрос с другой строны. Если ПМу в программировании разбираться не надо, то в чем ему надо разбираться? Какие у него таланты? Заниматься администрированием и произносить мотивирующие речи перед сотрудниками? Или что-то еще?

Подбирать команду, мотивировать ее на выполнение задания, разбирать конфликты, строить графики работ, следить за бюджетом, общаться с клиентами (очень важно уметь <b>управлять</b> ожиданиями клиента), заниматься логистикой и много чего еще.