Xpoint
   [напомнить пароль]

Управление проектом на 20 человеко-лет

Метки: [без меток]
2006-08-15 01:42:31 [обр] Дмитрий[досье]

Есть инвестор, который хочет вложиться в разработку софта. Довольно большая система, включающая ERP, CRM и все остальные аббревиатуры, которые мы все знаем. Все это с едином логином. Примерная оценка трудозатрат: 20 человеко-лет.
На текущий момент есть слаженная команда из 6 человек (программисты, дизайнер интерфесов и т.п.). Все люди знают свое дело. Управляется команда через самописную систему управления проектами - таски, проекты и т.п. Проектов такого размера еще команда не делала. Понятно, что под такой проект численность работников нужно увеличить до 15-20 человек. В связи с этим хочется масштабироваться правильно, без больших напрягов.

У кого был опыт руководства проектами такого размера и такой командой?

  1. Какие есть эффективные способы деления - по тройкам, где один отвечает за звено или просто по задачам распределять и один ПМ все координирует? Какие есть рекомендации по построению эффективной команды для достижения максимальной производительности?
  2. Проектирование сейчас происходит пракически устно. К такому проекту лучше приступить с грамотным ТЗ и архитектурой. Какими средствами автоматизации можно пользоваться на стадии проектирования архитектуры?
  3. Какие основные подводные камни таких проектов? С чем вы реально сталкивались?
спустя 3 дня [обр] Сергей Сирик(16/737)[досье]

Дмитрий[досье]
Ф. Брукс "Мифический человекомесяц". И смама по себе книжка замечательная, а для приведенного примера особенно - там похожих масштабов проект как пример приводится. И небольшая. Т.е. за день прочитаете.

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

Второй, и самый главный, подводный камень - разрабатываемая система это ПРОДУКТ!!!, что принципиально отличается от заказного софта.
- Кто у вас требования продуцирует??
- Кто изучает целевую аудиторию, конкурентов и т.д.? Входят ли эти работы в указанные 20 человеко-лет? Кто определяет "правильность" продукта (справа должна быть кнопочка или слева???), и кто перед кем несет ответственность за "правильность" решения.
- Каков план выхода на рынок: год работаем и пытаемся продать сразу большой ящик в составе ксерокса-принтера-факса, или сначала пытаемся сделать и продать принтер, а потом продолжить???
- Это один продкут или семейство продкутов?? Т.е. один большой продукт, умеющий усе, или несколько продуктов, объединенных общей идеологий, схожестью интерфейсов и общим логином ("общий логин" кстати оочень настораживает :)
- Какие у вас основные ограничивающие факторы: время (надо кровь из носу сделать до Главной Выставки, а то потом опять год ждать), бюджет?

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

спустя 8 часов [обр] Александр aka Efreeti(0/111)[досье]

Дмитрий[досье]
Если ваш инвестор готов участвовать в разработке требований и вообще как-то жить с проектом (или есть человек с его стороны, который четко понимает какие задачи должен софт выполнять) то лучше использовать XP.
Во-первых вы получите гибкость разработки, т.е. ежели что, можете достаточно сильно отклониться от первоначальных идей.
Во-вторых упроститься управление командой (т.е. кол-во программистов как бы делится на два) и планирование.
Ну и в-третьих, чертвёртых и двадцатых - все остальные преемущества можно прочитать в любой книжке по XP:) Я позволю себе её не пересказывать.

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

спустя 2 часа 26 минут [обр] Сергей Сирик(16/737)[досье]

Александр aka Efreeti[досье]
Ага, только и стоить проект будет практически в два раза дороже по трудоресурсам, т.е. 40 человеколет :) Парное программирование отнюдь не значит, что вдвоем одну задачу сделают именно что в два раза быстерей, т.е. программеров именно в два раза больше, а не меньше. И управление ими соответственно усложнится.

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

спустя 4 часа 53 минуты [обр] Александр aka Efreeti(0/111)[досье]

Сергей Сирик[досье]
Ага, только ошибки в анализе и проектировании при тяжелой методологии будут стоит существенно больше.
Да и тот факт, что прогеры пишут в парах, да и ещё и тесты колбасят отнюдь не означает учетверение сроков. Сроки поползут конечно, однако надёжность возрастёт.
Впрочем я не настаиваю на своей правоте, т.к. в таких больших проектах я не участвовал. Это просто предложение автору рассмотреть и такой вариант.

P.S. Инвестор их чуть не разогнал скорее всего именно потому, что они были "поклонниками", а не работниками нацеленными на рез-т.

Powered by POEM™ Engine Copyright © 2002-2005