Недавно, предложили стать Project Manager'ом немаленького проекта.
Я (имхо ) неплохой программер, но все свои проекты реализовывал в одиночку. Т. е. ни опыта руководства программерами, ни опыта работы под руководством "вождя" не имею

Что мне лучше почитать, чтобы вникнуть в эту сферу (лучше всего в инете)?
Где достать рекомендации по составлению ТЗ, архитектуре, управлению программерами?

Поздравляю и сочувствую одновременно.

Здравствуйте, Аноним, Вы писали:

А>Недавно, предложили стать Project Manager'ом немаленького проекта.
А>Я (имхо ) неплохой программер, но все свои проекты реализовывал в одиночку.

Я бы на твоем месте отказался. На полном серьезе.

Здравствуйте, bkat, Вы писали:

B>Я бы на твоем месте отказался. На полном серьезе.
Но ты представь, это будет мой первый бесценный опыт в качестве Team Leader'а!

З. Ы. Я только выпустился из универа

Здравствуйте, bkat, Вы писали:

B>>Я бы на твоем месте отказался. На полном серьезе.
А как нормальные люди вообще становятся Team Leader'ами — у них же тоже был первый проект!

B>>>Я бы на твоем месте отказался. На полном серьезе.
W>А как нормальные люди вообще становятся Team Leader'ами — у них же тоже был первый проект!

Безусловно. Но если нет опыта работы в команде — будет очень трудно.

Почитай "Мифический человеко-месяц" Брукса. Видел его в инете.
Потом зависит от языка. Например применительно к Java есть книга "Горький вкус Java" где описаны часто распространенные анти-паттерны и способы решения проблем.

Здравствуйте, warlockonline, Вы писали:

W>А как нормальные люди вообще становятся Team Leader'ами — у них же тоже был первый проект!
Некоторые изначально ими были

Здравствуйте, Ogre, Вы писали:

O>Почитай "Мифический человеко-месяц" Брукса. Видел его в инете.
O>Потом зависит от языка. Например применительно к Java есть книга "Горький вкус Java" где описаны часто распространенные анти-паттерны и способы решения проблем.

Спасибо, то что надо!

Здравствуйте, Ogre, Вы писали:

O>Почитай "Мифический человеко-месяц" Брукса. Видел его в инете.
O>Потом зависит от языка. Например применительно к Java есть книга "Горький вкус Java" где описаны часто распространенные анти-паттерны и способы решения проблем.

Я уж лучше Дейла Карнеги посоветовал бы почитать
А серьёзно — если проблем нет с английским, то ходи сюда www.cio.com. Почитывай статейки, через некоторое время твоё мировозрение изменится (если нет, то бросай всё и уходи обратно в программеры).

P.S. Поздравлять с назначением на эту должность не буду — выскажу соболезнования

Здравствуйте, Аноним, Вы писали:

А>Где достать рекомендации по составлению ТЗ, архитектуре, управлению программерами?

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

Здравствуйте, Mishka, Вы писали:

M>Я уж лучше Дейла Карнеги посоветовал бы почитать

Имхо, Дейл Карнеги не сильно увязывается с нашим менталлитетом...

Здравствуйте, Mystic, Вы писали:

M>Здравствуйте, Mishka, Вы писали:

M>>Я уж лучше Дейла Карнеги посоветовал бы почитать

M>Имхо, Дейл Карнеги не сильно увязывается с нашим менталлитетом...

Значит менталитет менять надо. В управление проектами главное soft skills, а им в России не учат. Знаешь сколько у меня проблем из-за русского менталитета? На голом IQ далеко не уедешь

Здравствуйте, Mishka, Вы писали:

M>>>Я уж лучше Дейла Карнеги посоветовал бы почитать

M>>Имхо, Дейл Карнеги не сильно увязывается с нашим менталлитетом...

M>Значит менталитет менять надо. В управление проектами главное soft skills, а им в России не учат. Знаешь сколько у меня проблем из-за русского менталитета? На голом IQ далеко не уедешь

Я бы не сказал, что менталлитет русского человека так уж плох. Он другой, и подход нужен другой... Менталлитет можно понимать как шкалу ценностей. Одна из задач Team Leader, в частности и состоит в том, чтобы на нужное место назначить нужного человека.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, bkat, Вы писали:

B>>Я бы на твоем месте отказался. На полном серьезе.
А>Но ты представь, это будет мой первый бесценный опыт в качестве Team Leader'а!

А>З. Ы. Я только выпустился из универа

Какая планируемая длительность у проекта?
Сколько народу в команде?
Разделена ли команда на группы, удаленные географически?
Команда новая, или уже сработалась?

Здравствуйте, bkat, Вы писали:

А>>Я (имхо ) неплохой программер, но все свои проекты реализовывал в одиночку.

B>Я бы на твоем месте отказался. На полном серьезе.

Зачем так категорично... Не Боги горшки обжигают.

Здравствуйте, Mystic, Вы писали:

M>Здравствуйте, bkat, Вы писали:

А>>>Я (имхо ) неплохой программер, но все свои проекты реализовывал в одиночку.

B>>Я бы на твоем месте отказался. На полном серьезе.

M>Зачем так категорично... Не Боги горшки обжигают.

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

Я бы лично не захотел себе руководителя без опыта.
Пусть на других учится

Здравствуйте, bkat, Вы писали:

B>Какая планируемая длительность у проекта?
5 месяцев
B>Сколько народу в команде?
3 человека, включая меня, один их которых еще не набран
B>Разделена ли команда на группы, удаленные географически?
Нет, все будет происходить в одном помещении 6 дней в неделю, 8 часов в сутки.
B>Команда новая, или уже сработалась?
Одного человека я знаю достаточно давно, мы с 1-го курса осваивали программинг вместе

Здравствуйте, <Аноним>, Вы писали:

А>Здравствуйте, bkat, Вы писали:

B>>Какая планируемая длительность у проекта?
А>5 месяцев
Советую добавить сюда еще годик.

B>>Сколько народу в команде?
А>3 человека, включая меня, один их которых еще не набран
У меня также было

B>>Разделена ли команда на группы, удаленные географически?
А>Нет, все будет происходить в одном помещении 6 дней в неделю, 8 часов в сутки.
Программистам настоятельно не рекомендуется работать больше 40 часов в неделю. Делай выводы.

B>>Команда новая, или уже сработалась?
А>Одного человека я знаю достаточно давно, мы с 1-го курса осваивали программинг вместе
Это либо хорошо, либо плохо.
Хорошо, если он будет с пониманием относиться к твоим проблемам, неопытности.
Плохо, если он откажется признавать в тебе авторитет и начальство и начать самостоятельно себя разруливать или прыгать через голову. Если такой поворот вероятен, то лучше до проекта откажись от его услуг. Т.е. есть аксиома управления людьми, что либо друг, либо подчиненный, но не оба.

Здравствуйте, <Аноним>,

Может все же зарегистрируешься???
Чувствую я, что ты можешь стать частым посетителем данного форума...

Здравствуйте, mikkri, Вы писали:

А>>5 месяцев
M>Советую добавить сюда еще годик.
Через 5 месяцев нам надо выпустить отностиельно работающую версию, с которой смогут работать пользователи. Если поднапрячься, то можно втроем уложиться

B>>>Сколько народу в команде?
А>>3 человека, включая меня, один их которых еще не набран
M> У меня также было

B>>>Разделена ли команда на группы, удаленные географически?
А>>Нет, все будет происходить в одном помещении 6 дней в неделю, 8 часов в сутки.
M>Программистам настоятельно не рекомендуется работать больше 40 часов в неделю. Делай выводы.
Возможно. Надо еще поискать инфы...

B>>>Команда новая, или уже сработалась?
А>>Одного человека я знаю достаточно давно, мы с 1-го курса осваивали программинг вместе
M>Это либо хорошо, либо плохо.
M>Хорошо, если он будет с пониманием относиться к твоим проблемам, неопытности.
Maybe отноительно тебя я и неопытен, но у меня есть опыт разработки — 2 проекта, последний из которых по схожей тематике был выполнен мною за полгода и использованием C# и MS SQL Server — пользователи довольны до сих пор
M>Плохо, если он откажется признавать в тебе авторитет и начальство и начать самостоятельно себя разруливать или прыгать через голову. Если такой поворот вероятен, то лучше до проекта откажись от его услуг. Т.е. есть аксиома управления людьми, что либо друг, либо подчиненный, но не оба.
Нет. Думаю, что этого не должно быть

Здравствуйте, Аноним, Вы писали:

А>[skip]

Кстати, в ваших комнандах PM были "играющими тренерами"? Т. е. совмещали организацию процесса, дизайн архитектуры и кодинг?

Я рассчитываю принять непосредственное учатие в разработке бизнес-логики

B>>>>Команда новая, или уже сработалась?
А>>>Одного человека я знаю достаточно давно, мы с 1-го курса осваивали программинг вместе
M>>Это либо хорошо, либо плохо.
M>>Хорошо, если он будет с пониманием относиться к твоим проблемам, неопытности.
А>Maybe отноительно тебя я и неопытен, но у меня есть опыт разработки — 2 проекта, последний из которых по схожей тематике был выполнен мною за полгода и использованием C# и MS SQL Server — пользователи довольны до сих пор

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

Здравствуйте, mikkri, Вы писали:

B>>>>>Команда новая, или уже сработалась?
А>>>>Одного человека я знаю достаточно давно, мы с 1-го курса осваивали программинг вместе
M>>>Это либо хорошо, либо плохо.
M>>>Хорошо, если он будет с пониманием относиться к твоим проблемам, неопытности.
А>>Maybe отноительно тебя я и неопытен, но у меня есть опыт разработки — 2 проекта, последний из которых по схожей тематике был выполнен мною за полгода и использованием C# и MS SQL Server — пользователи довольны до сих пор
M>ИМХО, я не понты кидаю, а пытаюсь советом помочь.
M>Работа менеджера проекта в корне отличается от работы программиста. Т.е. тебе придется в первую очередь управлять людьми, а в этом, как ты признавался раньше, опыта у тебя нет.

Sorry, неправильно тебя понял
Но то, чем я возможно займусь будет сочетать в себе все — формализация задачи, построение архитектуры, распределение задач между программерами, кодинг: человек оркестр .
Правда стоит ли быть им? PM, конечно же должен очень хорошо знать все используемые технологии и непосредственно учавствовать в разработке архитектуры (если нет менеджеров младшего звена). Остается ли время у PM для кодинга?

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

Здравствуйте, Аноним, Вы писали:

А>Sorry, неправильно тебя понял
А>Но то, чем я возможно займусь будет сочетать в себе все — формализация задачи, построение архитектуры, распределение задач между программерами, кодинг: человек оркестр .

То что описано — это не Project Management. Таким занимаются team leader или senior software developer. Ну на крайняк — software architect. Но точно не project manager. Последний общается с клиентами, выбивает из них деньги, договаривается о сроках выполнения проекта и функциях разрабатываемой программы, следит, чтобы проект был выполнен в срок. Такие люди НИКОГДА не пишут код, в очень редких случаях они могут заниматься разработкой архитектуры. Если же на тебя повесят все эти функции, то лучше откажись сразу — опыт ты приобретёшь отвратный (на собственной шкуре испытал).

Здравствуйте, <Аноним>, Вы писали:

А>Но то, чем я возможно займусь будет сочетать в себе все — формализация задачи, построение архитектуры, распределение задач между программерами, кодинг: человек оркестр .


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

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

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

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

Кстати, по своему опыту могу дать два критически важных совета:
1) не забывай про выявление и учет требований; никогда не допускай никаких изменений без записи соответствующего требования (дотошность должна быть адекватна политической ситуации в компании и сложившимся устоям).
2) внедри с самого начала итеративную разработку, т.е. для каждого релиза четко определяй состав учитываемых требований, а все новые и измененные требования всегда отправляй в новый релиз. В критических случаях "убивай" сделанную в текущем релизе работу и начинай писать его заново.

Собственно, это были две моих основных ошибки в свое время.

Здравствуйте, Mishka, Вы писали:

M>То что описано — это не Project Management. Таким занимаются team leader или senior software developer. Ну на крайняк — software architect. Но точно не project manager. Последний общается с клиентами, выбивает из них деньги, договаривается о сроках выполнения проекта и функциях разрабатываемой программы, следит, чтобы проект был выполнен в срок. Такие люди НИКОГДА не пишут код, в очень редких случаях они могут заниматься разработкой архитектуры. Если же на тебя повесят все эти функции, то лучше откажись сразу — опыт ты приобретёшь отвратный (на собственной шкуре испытал).



Этот подход из серии "сразу в бой". Приобретенный опыт позволит с глубоким смыслом вчитываться в многие классические книги про ИТ (методологии, управление проектами и т.п.). Следующее прозрение возможно, как я думаю , только при работе в проектам от 100 человеко-лет.

Всем спасибо за помощь!!!


...скоро начнется самое интересное и страшное..

Здравствуйте, Аноним, Вы писали:

А>Что мне лучше почитать, чтобы вникнуть в эту сферу (лучше всего в инете)?
А>Где достать рекомендации по составлению ТЗ, архитектуре, управлению программерами?
По моему шанс есть, если делать как-нибудь так:

Ни в коем случае не надо никем управлять. Твоя задача — ненавязчиво координировать работу команды и разрешать конфликты (т. е. не допускать непродуктивной командной активности). В твоей ситуации (маленькая группа, отсутствие опыта) команда равноправных программеров — то что надо. Пусть все прочитают про MSF — этого для начала достаточно. При этом, не надо пытаться во всем ему следовать — используйте отдельные элементы, которые очевидны и кажутся разумными всем членам команды. Основная установка — "мы все вместе учимся работать". Тогда все будет хорошо.

Здравствуйте, mikkri, Вы писали:

M>Этот подход из серии "сразу в бой". Приобретенный опыт позволит с глубоким смыслом вчитываться в многие классические книги про ИТ (методологии, управление проектами и т.п.).

Это точно, будет книги почитывать, сидя без работы и думая, что же я такого сделал не правильно
С другой стороны если он таки справится или, не справившись, быстро отойдёт, то это черта будущего менеджера.
Но меня всё равно не переубедить — разработчик и project manager — это два разных пути, так что либо одно, либо другое.

Здравствуйте, Mishka, Вы писали:

M>Но меня всё равно не переубедить — разработчик и project manager — это два разных пути, так что либо одно, либо другое.

С профессиональной точки зрения — да.
Одновременно преуспеть в обеих испостасиях вряд ли выйдет.
Но в целях просвящения — можно один-два раза попробовать.

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

G> Основная установка — "мы все вместе учимся работать". Тогда все будет хорошо.

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

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

Здравствуйте, Gaperton, Вы писали:

G>Ни в коем случае не надо никем управлять. Твоя задача — ненавязчиво координировать работу команды и разрешать конфликты (т. е. не допускать непродуктивной командной активности). В твоей ситуации (маленькая группа, отсутствие опыта) команда равноправных программеров — то что надо. Пусть все прочитают про MSF — этого для начала достаточно. При этом, не надо пытаться во всем ему следовать — используйте отдельные элементы, которые очевидны и кажутся разумными всем членам команды. Основная установка — "мы все вместе учимся работать". Тогда все будет хорошо.

Imho в такой ситуации (маленькая группа и отсутствие опыта) как раз более подойдут облегченные методологии разработки, то же XP. Она будет легче в освоении, способствует взаимному обучению, привьет (или попытается привить) навыки коммандной работы, быстро даст результаты, ... Afair для MSF нужны менеджеры продукта и программы, разработчик, инструктур, тестер и логист — многовато для комманды из 4 человек. Однако и здесь тоже есть подводные камни — если нет человека, уже использовавшего ХР на практике, то результат может быть не очень хороший.
Хотя и более формальные методологии (UP, MSF, ...) тоже могут дать хороший результат. Диаграммы, схемы, графики разработки, развешанные по стенам, вселяют уверенность в руководство, что тоже немаловажно

Здравствуйте, Mishka, Вы писали:
M>в очень редких случаях они могут заниматься разработкой архитектуры. Если же на тебя повесят все эти функции, то лучше откажись сразу — опыт ты приобретёшь отвратный (на собственной шкуре испытал).
По своему опыту могу сказать — не стоит даже пытаться совмещать архитектора с PM, по крайней мере, если заказчик внешний.
Дело в том, что интерес PM в том, чтобы команда как можно меньше сделала, и как можно больше получила. Хороший PM всегда старается отказать в реализации того или иного требования (например, указать, что оно выполнимо через существующую функциональность).
Хороший архитектор, наоборот, играет на стороне заказчика — ему хочется впихнуть в бюджет как можно более "классное" приложение. Он готов часами выслушивать пожелания заказчика, пытаясь представить, как они ложатся в видящуюся ему схему.
Эти две противоборствующие стороны, в итоге, сходятся на каком-то продукте.
Если слаба "архитектурная жилка", то результатом будет слабое, неудобное и тяжеловесное приложение. Оно будет формально соответствовать поставленной задаче, но в нем не будет "огонька". Заказчик заплатит, и больше никогда не придет.
Если слаб PM, то проект будет непрерывно раздуваться, сроки и бюджеты будут нарушаться, а заказчик, который только вчера говорил "ах как классно вы сделали эту штучку в окне XXX, давайте немедленно сделаем это во всех остальных операционных системах", будет рвать и метать и говорить, что ему надо совсем не то, а намного проще и дешевле.
Антагонистические роли довольно-таки тяжело совмещать в одном человеке. Либо будет преимущество одной из ролей, либо кто-то уедет на белой Газели.

А>Кстати, в ваших комнандах PM были "играющими тренерами"? Т. е. совмещали организацию процесса, дизайн архитектуры и кодинг?

А>Я рассчитываю принять непосредственное учатие в разработке бизнес-логики

Мои пять копеек:
Имхо, необходимость в "чистом" руководителе возникает, когда количество исполнителей достигает 5-7 человек (из личного опыта). Так что не переживай, попрограммить время будет

Здравствуйте, Аноним, Вы писали:

А>Недавно, предложили стать Project Manager'ом немаленького проекта.
А>Я (имхо ) неплохой программер, но все свои проекты реализовывал в одиночку. Т. е. ни опыта руководства программерами, ни опыта работы под руководством "вождя" не имею

А>Что мне лучше почитать, чтобы вникнуть в эту сферу (лучше всего в инете)?
А>Где достать рекомендации по составлению ТЗ, архитектуре, управлению программерами?

Тут уже писали про Горький вкус Java. Добавлю:
Кент Бек и мартин Фаулер — Серия книжек про экстремальное программирование. Рефакторинг.
Йодан. Путь камикадзе (самое то для тебя как начинающего ). Там именно о том, как выжить в заваливающихся проектах.
Была еще чья-то книжка про создание программистской команды, но я не помню ни автора, ни названия Поищи в гугле по запросу "создание команды (программистов?)"

Здравствуйте, Roman Avramov, Вы писали:


А>>Кстати, в ваших комнандах PM были "играющими тренерами"? Т. е. совмещали организацию процесса, дизайн архитектуры и кодинг?

А>>Я рассчитываю принять непосредственное учатие в разработке бизнес-логики

RA>Мои пять копеек:
RA>Имхо, необходимость в "чистом" руководителе возникает, когда количество исполнителей достигает 5-7 человек (из личного опыта). Так что не переживай, попрограммить время будет

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

Здравствуйте, LaptevVV, Вы писали:

LVV>Йодан. Путь камикадзе (самое то для тебя как начинающего ). Там именно о том, как выжить в заваливающихся проектах.

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

Здравствуйте, Igor Trofimov, Вы писали:

iT>Она из самых сложных задач для руководителя, имхо — оценка реальных сроков разработки туманного в начале (обычно) проекта, да еще и разработки пока незнакомой командой.

Присоединяюсь
Это было, по-моему, ещё у Брукса: самое сложное для начинающих менеджеров проекта — оценка сроков и их занижение из-за боязни заявлять слишком большое время разработки. Поэтому по началу при оценке сроков надо пользоваться правилом "удвой и добавь ещё".

Александр

> G>Пусть все прочитают про MSF — этого для начала достаточно.
> G>При этом, не надо пытаться во всем ему следовать -
> G>используйте отдельные элементы, которые очевидны
> G>и кажутся разумными всем членам команды.
>
> как раз более подойдут облегченные методологии разработки,
> то же XP.
> Хотя и более формальные методологии (UP, MSF, ...)
> тоже могут дать хороший результат.

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

> Но точно не project manager. Последний общается
> с клиентами, выбивает из них деньги, договаривается
> о сроках выполнения проекта и функциях разрабатываемой
> программы, следит, чтобы проект был выполнен в срок.

Не в пику предыдущему докладчику, а просто для справки.
Project manager, как его все чаще понимают, является
техническим руководителем проекта. Утряской денежных
вопросов с клиентами и определением стратегии занимается
program manager. Также часто все денежные и договорные
вопросы передаются account manager-у.

> Была еще чья-то книжка про создание программистской команды, но я не помню ни автора, ни названия
Поищи в гугле по запросу "создание команды (программистов?)"

Время — деньги. Создание команды разработчиков программного обеспечения.
Эд Салливан.
http://shmakov.ru/news/shownews.php?textID=28

Еще есть Фергюс О'Коннэл "Как успешно руководить проектами. Серебряная пуля"
http://shmakov.ru/news/shownews.php?textID=13

Здравствуйте, mikkri, Вы писали:

M>Кстати, на мелких проектах в Москве очень распространена схема, когда один человек — все умеющее чудо, и два-три рядовых программиста и, может быть, один тестировщик.

И не только в Москве.

Здравствуйте, Mishka, Вы писали:

M>Я уж лучше Дейла Карнеги посоветовал бы почитать

Бррр, Карнеги.
Я бы порекомендовал лучше Роберт Чалдини, "Психология влияния".
Толковая книжка, несмотря на попсовое название.

M>А серьёзно — если проблем нет с английским, то ходи сюда www.cio.com. Почитывай статейки, через некоторое время твоё мировозрение изменится (если нет, то бросай всё и уходи обратно в программеры).

Интересная ссылочка.

Здравствуйте, S-SH, Вы писали:

SS>Не методология является определяющей в проекте, а потребность
SS>менеджера иметь возможность управлять проектом и контролировать
SS>эффективность разработки. Смотреть, анализировать, делать выводы,
SS>если не получается (только если не получается) — обращаться
SS>к методологиям, и затем внедрять какие-то методики и практики.
SS>Применение каждой методики должно иметь ясный, конкретный результат
SS>в улучшении производительности и качества конечного продукта.
SS>Если же вы хотите внедрить какую-то методику, аргументируя словами
SS>"следовало бы", "не помешало бы", "так будет по науке", то знайте -
SS>она вам лишняя.

Я и не говорил, что методология является решающим фактором для успеха проекта. Однако, если у человека нет опыта управления проектами по разработке ПО, совсем не лишним (имхо) было бы почитать что-нибудь по методологиям разработки. Разве в применении инкрментно-итеративного подхода, вариантов использования или постоянной интеграции есть что-то плохое?
"Смотреть, анализировать, делать выводы" — это конечно хорошо, даже очень. Только понравится ли такой подход заказчику, когда за его деньги будут "делать выводы"?
Поясните, пожалуйста, фразу: "Применение каждой методики должно иметь ясный, конкретный результат в улучшении производительности и качества конечного продукта. Если же вы хотите внедрить какую-то методику, аргументируя словами "следовало бы", "не помешало бы", "так будет по науке", то знайте — она вам лишняя." Тогда по вашему с маленьком проекте, разрабатываемом 2 людьми в течении месяца, конкретного улучшения можно достичь применяя ЛЮБУЮ методологию, даже что-то типа ISO 9001?

Здравствуйте, Slam, Вы писали:

S>Здравствуйте, mikkri, Вы писали:

M>>Кстати, на мелких проектах в Москве очень распространена схема, когда один человек — все умеющее чудо, и два-три рядовых программиста и, может быть, один тестировщик.

S>И не только в Москве.

В других городах не работал, утверждать не могу

Здравствуйте, Mishka, Вы писали:

M>Значит менталитет менять надо. В управление проектами главное soft skills, а им в России не учат. Знаешь сколько у меня проблем из-за русского менталитета?

Ну так это у тебя не в России проблемы. Понятно что с чужим менталитетом трудно. А в Росии очень даже ничего, пользоваться здесь исключительно западными подходами чревато. Например строгий формализм, так любимый многими западными менеджерами, скорее всего приведет к некачественному проекту.

Здравствуйте, S-SH, Вы писали:
SS>Не в пику предыдущему докладчику, а просто для справки.
SS>Project manager, как его все чаще понимают, является
SS>техническим руководителем проекта. Утряской денежных
SS>вопросов с клиентами и определением стратегии занимается
SS>program manager. Также часто все денежные и договорные
SS>вопросы передаются account manager-у.
Угу. Но эти роли — взаимодополняющие, а не антагонистические. По крайней мере, явных противоречий в них я не заметил. Возможно, это опять же эффект малости масштаба — в проектах, в которых участвовал я, эти роли настолько хорошо сочетались, что не было специального разделения. В тех случаях, когда выделялся account manager, это себя не оправдывало — накладные расходы на синхронизацию "понимания статуса" превышали реальный выигрыш за счет разгрузки ПМ.

Интересно, бывают ли ситуации, при которых соединение технического руководителя с финансовым противопоказано (при условии, что эти активности в сумме занимают не более 100% его времени)?

> Интересно, бывают ли ситуации, при которых соединение
> технического руководителя с финансовым противопоказано
> (при условии, что эти активности в сумме занимают
> не более 100% его времени)?

Очевидно, в ситуации когда у технического руководителя
недостаточно квалификации для урегулирования финансовых
вопросов. Или она не сравнима с квалификацией финансового
руководителя. Т.е. речь о "качестве решений".

В общем случае —

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Mishka, Вы писали:

M>>Значит менталитет менять надо. В управление проектами главное soft skills, а им в России не учат. Знаешь сколько у меня проблем из-за русского менталитета?

AVK>Ну так это у тебя не в России проблемы. Понятно что с чужим менталитетом трудно. А в Росии очень даже ничего, пользоваться здесь исключительно западными подходами чревато. Например строгий формализм, так любимый многими западными менеджерами, скорее всего приведет к некачественному проекту.

Западные менеджеры применяют формальные методологии гораздо осторожнее
чем в России. Это у нас многие идеи доводятся до абсурда (заставь дурака молиться...)
Почему я так думаю? Ну например, у них не принято кричать на подчиненных
и начальство очень даже прислушивается к мнению тех, кем руководит...

> не лишним было бы почитать что-нибудь по методологиям
> разработки.

Да, лучше почитать. Но, если начинать читать, то
обязательно читать не про одну методологию.

> Разве в применении инкрментно-итеративного подхода,
> вариантов использования или постоянной интеграции
> есть что-то плохое?

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

> понравится ли такой подход заказчику, когда за его
> деньги будут "делать выводы"?

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

> Тогда по вашему с маленьком проекте, разрабатываемом
> 2 людьми в течении месяца, конкретного улучшения
> можно достичь применяя ЛЮБУЮ методологию, даже
> что-то типа ISO 9001?

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

Здравствуйте, AndrewVK, Вы писали:

AVK>Ну так это у тебя не в России проблемы. Понятно что с чужим менталитетом трудно. А в Росии очень даже ничего, пользоваться здесь исключительно западными подходами чревато. Например строгий формализм, так любимый многими западными менеджерами, скорее всего приведет к некачественному проекту.

Строгий формализм канул в лету уже достаточно давно. Теперь все пытаются создать так называемые "self managed teams". То есть все друг с другом вежливы, никто не знает где начальник, где подчинённый. "Please" и "sorry" звучат на каждом шагу. Даже поругаться не с кем . Нельзя говорить, что человек не прав, но если всё таки нужно, то приходится идти долгим обходным путём, что раздражает, и однажды сведёт меня в могилу.
Иногда хочется указать другим, что делать — не получиться, будь ты трижды умным и опытным, всё равно нужно сделать так, чтобы все были счастливы. А, как известно, русский менталитет не заточен на деланье других людей счастливыми

Здравствуйте, S-SH, Вы писали:

>> не лишним было бы почитать что-нибудь по методологиям
>> разработки.

SS>Да, лучше почитать. Но, если начинать читать, то
SS>обязательно читать не про одну методологию.

Согласен на 100%!

>> понравится ли такой подход заказчику, когда за его
>> деньги будут "делать выводы"?

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

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

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, AndrewVK, Вы писали:

AVK>>Здравствуйте, Mishka, Вы писали:

M>>>Значит менталитет менять надо. В управление проектами главное soft skills, а им в России не учат. Знаешь сколько у меня проблем из-за русского менталитета?

AVK>>Ну так это у тебя не в России проблемы. Понятно что с чужим менталитетом трудно. А в Росии очень даже ничего, пользоваться здесь исключительно западными подходами чревато. Например строгий формализм, так любимый многими западными менеджерами, скорее всего приведет к некачественному проекту.

А>Западные менеджеры применяют формальные методологии гораздо осторожнее
А>чем в России. Это у нас многие идеи доводятся до абсурда (заставь дурака молиться...)
А>Почему я так думаю? Ну например, у них не принято кричать на подчиненных
А>и начальство очень даже прислушивается к мнению тех, кем руководит...

Я бы не стал обобщать. Некомпетентность, глупость, болезненное самолюбие, и другие качества людей с неразумным корпоративным поведением, знаете-ли, лишены национальности. Это явления транскультурные. За примерами — к книге "путь камикадзе", "peopleware", у Джоела есть кое что. Вот, например:

"Я начальник &mdash; ты дурак" и команда клоунов

Две истории

Здравствуйте, Gaperton, Вы писали:

G>Здравствуйте, Аноним, Вы писали:

А>>Здравствуйте, AndrewVK, Вы писали:

AVK>>>Здравствуйте, Mishka, Вы писали:

M>>>>Значит менталитет менять надо. В управление проектами главное soft skills, а им в России не учат. Знаешь сколько у меня проблем из-за русского менталитета?

AVK>>>Ну так это у тебя не в России проблемы. Понятно что с чужим менталитетом трудно. А в Росии очень даже ничего, пользоваться здесь исключительно западными подходами чревато. Например строгий формализм, так любимый многими западными менеджерами, скорее всего приведет к некачественному проекту.

А>>Западные менеджеры применяют формальные методологии гораздо осторожнее
А>>чем в России. Это у нас многие идеи доводятся до абсурда (заставь дурака молиться...)
А>>Почему я так думаю? Ну например, у них не принято кричать на подчиненных
А>>и начальство очень даже прислушивается к мнению тех, кем руководит...

G>Я бы не стал обобщать. Некомпетентность, глупость, болезненное самолюбие, и другие качества людей с неразумным корпоративным поведением, знаете-ли, лишены национальности. Это явления транскультурные. За примерами — к книге "путь камикадзе", "peopleware", у Джоела есть кое что. Вот, например:

Я не обобщаю...
Это исключительно мой личный опыт.
Российские управленцы, на мой взгляд, авторитарны.
Средний европейский менеджер будет выглядить откровенной
"тряпкой" в России. Про американский менеджмент знаком только по наслышке.
Ну восток и азия скорей всего еще более авторитарны, чем Россия.

Здравствуйте, Аноним, Вы писали:

А>Я не обобщаю...
А>Это исключительно мой личный опыт.
А>Российские управленцы, на мой взгляд, авторитарны.
А>Средний европейский менеджер будет выглядить откровенной
А>"тряпкой" в России. Про американский менеджмент знаком только по наслышке.
А>Ну восток и азия скорей всего еще более авторитарны, чем Россия.

Ты обобщаешь свой личный опыт. Это конечно правильно, так и надо. Но не стоит забывать, что есть разница между личным опытом и, например, социологическим исследованием. Личный опыт — он у каждого свой, непохожий на опыт других.

Вот например здесь мой личный опыт расходится с твоим с точностью до наоборот:
А>>Западные менеджеры применяют формальные методологии гораздо осторожнее
А>>чем в России. Это у нас многие идеи доводятся до абсурда (заставь дурака молиться...)
А>>Почему я так думаю? Ну например, у них не принято кричать на подчиненных
А>>и начальство очень даже прислушивается к мнению тех, кем руководит...

"Немцы педантичные зануды", "все японцы трудоголики", "американцы тупые и жирные", "все евреи жадные", "все чеченцы отмороженные бандиты", "все русские раз%:?дяи".

Проблема в том, что обяснение причин поведенческих реакций людей сводится к обозначению их национальности ("национальному менталитету"). Это проявление известной в психологии хрени под названием "феномен самоидентификации". Он состоит в том, что ВСЕ люди склонны объяснять причины своих поступков ситуационно (я не дал денег в долг, т.к. у меня в этом месяце много расходов), а чужих — навешивая ярлыки (он не дал мне денег в долг потому что он жадный).

Со всем согласен...
Сам отлично представляю опасность обобщения личного опыта.

В общем это мое частное мнение, основанное на личном опыте.
Призываю никаких выводов не делать

> Со всем согласен...
> Сам отлично представляю опасность обобщения личного опыта.
>
> В общем это мое частное мнение, основанное на личном опыте.
> Призываю никаких выводов не делать

Ну почему же? Можно сделать вывод, что Аноним(ы), не смотря на
категоричность собственных выводов могут иногда признавать их
субъективность...