Здравствуйте, 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, ...)
> тоже могут дать хороший результат.

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