Управление разработкой проекта на 20 человеко-лет

[Дмит_рий]

Управление разработкой проекта на 20 человеко-лет

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

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


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


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

2. Проектирование сейчас происходит пракически устно. К такому проекту лучше приступить с грамотным ТЗ и архитектурой. Какими средствами автоматизации можно пользоваться на стадии проектирования архитектуры?

3. Какие основные подводные камни таких проектов? С чем вы реально сталкивались?

 

[fisher]

>>один ПМ все координирует
один на 15-20 челровек? он же умрет недожив до.

>>Какими средствами автоматизации можно пользоваться на стадии
>>проектирования архитектуры?
на стадии проектирования - бумагой и ручкой (лучше фломастером и доской). без шуток - имхо так просто быстрее. если надо документировать - просто фотографировать/сканить рисунки, писать пометки и ключевые слова.

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

 

[grigori]

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

Какие основные подводные камни таких проектов?

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

 

[StUV]

Примерная оценка трудозатрат: 20 человеко-лет.

На текущий момент есть слаженная команда из 6 человек

бред =)

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

т.е. сократить сроки исполнения с 3 до 1 года?..
интересно, а что думает по этому поводу спонсор ? =)))))

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

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

в любом случае - задумываться сейчас о "двойках-тройках" нет никакого смысла...

 

[Кром]

Судя по всему примерная оценка взята с потолка, так как нет ни плана ни тз. С таким же успехом можно сказать и 40 и сто лет. Поэтому не надо над этим зацикливаться вообще.

Нанимать сторонних аналитиков, кстати, совершенно необязательно. Еще неизвестно куда они заведут проект.

1. есть мнение, что команды из 5 человек достатчно на начальном этапе для любого проекта. Потом на выявленные направления подключать новых людей.
По второму есть и так достаточно информации.
3. Заказчик всегда хочет все и сразу. Главное выбрать из списка требований и пожеланий самое основное. Т.е. если предполагается система из сотни модулей, необходимо выбрать, скажем, пять основных и договориться, что система начнет работать с этим минимальным набором. Это -обязательно. Затем сконцентрироваться на этих модулях и реализовать их в максимально сжатые сроки. Отдать заказчику на тестирование и, в идеале, запустить проект.
Пока этого не произойдет можно считать, что вы даже не начали работать, зато после этого наступит просветление и взаимопонимание. Заказчик начнет понимат что он хочет, ПМ - сколько же на самом деле уйдет человеко-лет, а программист - как же это все делать.

Собственно, повторил fisher'a.

 

[an_kalinovski]

Для начала почитайте Фредерика Брукса "Мифический человекомесяц"...

 

[StUV]

Нанимать сторонних аналитиков, кстати, совершенно необязательно. Еще неизвестно куда они заведут проект.

нет никакого проекта =)

 

[Дмит_рий]

Автор оригинала: fisher
на стадии проектирования - бумагой и ручкой (лучше фломастером и доской). без шуток - имхо так просто быстрее. если надо документировать - просто фотографировать/сканить рисунки, писать пометки и ключевые слова.

У нас в офисе доска размером пять на два метра, на которой как раз сейчас и происходит разработка архитектур и т.п. Этой доски хватает, чтобы расписать, например, подсистему кредитов для финансового софта в очень укрупненной форме. А это только песчинка в той системе, о которой я говорю. Чтобы более или менее подробно расписать все подсистемы поданобится досок 100. Это как минимум 100 фотографий. Их нужно будет отсортировать, связать между собой. А если понядобятся изменения, то заново на доску переносить? Так даже, наверное, не проектировали во время написания книжки Брукса, о которой тут упомянули Средства автоматизации все таки нужны, чтобы можно было нарисовать крупную схему, потом опуститься в каждый блок и детализировать до уровня, когда потом по схеме любой новый член команды все поймет.

Когда я еще в универе учился мы практиковались на Design/IDEF, BPWin и т.п. Какими CASE средствами вы реально пользуетесь сейчас для описания архитектуры системы?

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

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

-~{}~ 16.08.06 10:24:

Автор оригинала: StUV
т.е. сократить сроки исполнения с 3 до 1 года?..
интересно, а что думает по этому поводу спонсор ? =)))))

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

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

Полностью согласен. Над этим идет работа с заказчиком. Меня сейчас интересует больше техническая сторона проекта: как грамотно управлять, где визуализировать архитектуру и т.п. Как я уже писал выше, у нас есть довольно большой опыт разработки, НО нет опыта работы над системами такого размера. Ясно, что некоторые методы, которые используются сейчас, просто не могут работать при увеличении объема в 10 раз. Например, разработка архитектуры на доске с фломастером.

в любом случае - задумываться сейчас о "двойках-тройках" нет никакого смысла...

Смысл есть, т.к. поняв тонкости большой разработки заранее можно:
1. Подготовиться.
2. Оценить риски, затраты на управление, потребность в ресурсах и т.п.

Сможете поделиться своим опытом работы над большими системами?

 

[StUV]

Дмит_рий
читайте Г.Буча
в начале действительно удобно пользоваться доской/бумагой
потоим можно перейти и на rational rose...

 

[voituk]

+1 за бумагу, ручку, доску, фломастер, сканер, фотоапарат, желательно ксерокс

 

[Дмит_рий]

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

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

По второму есть и так достаточно информации.

Информация есть. Очень интересно услышать реальный опыт людей. С одной стороны можно пользоваться доской и фломастером при разработке ядра Linux, с другой можно на rational rose проектировать простой веб-сайт. И то и другое возможно, но средства не соответствуют задаче.

Вы какого размера системы пишете и каким софтом пользуетесь при проектировании?

Главное выбрать из списка требований и пожеланий самое основное.

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

 

[fisher]

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

>>Какими CASE средствами вы реально пользуетесь
>>сейчас для описания архитектуры системы
почти никакими

>>Это как минимум 100 фотографий.
>>Их нужно будет отсортировать, связать между собой
100 это немного! связать-отсортировать - возьмите любую wiki.

 

[Дмит_рий]

Автор оригинала: fisher
Брукс безнадежно устарел.

С этим я согласен. Привел ее специально для an_kalinovski
Хотя многие принципы, описанные, Бруксом применими к нашему времени. И вообще понимание того, что сегодняшние проблемы разработки были еще 25-35 лет назад наполняют оптимизмом

>>Какими CASE средствами вы реально пользуетесь
>>сейчас для описания архитектуры системы
почти никакими

А системы какого размера делаете? И в "почти" что входит?

100 это немного! связать-отсортировать - возьмите любую wiki.

Вы так реально работаете? А как изменения в эти картинки вносите? Перерисовываете на доске?
Какие системы так проектируете?

 

[Alexandre]

Например, разработка архитектуры на доске с фломастером

вполне нормально... мы всегда так и делали на летучках.

Какими CASE средствами вы реально пользуетесь

EnterpriceArhitect но не промышленно.

 

[bgm]

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

P.S. Если есть вопросы - в приват.

 

[StUV]

Дмит_рий
Вашей доски вполне достаточно для отрисовки модульной архитектуры вашей системы

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

В процессе проектирования приложения в целом - раз в день собирайте своих архитекторов около этой доски + поставьте экран на котором с проектора каждый бы показывал текущее архитектурное решение своего модуля

общая схема на доске + обсуждение проектных решений позволит в процессе проектирования изменять интерфейсы модулей и т.д.

Какое средство визуального проектирования вы выберете - особой роли не играет
я для отрисовки модульной структуры + диаграмм процессов использую RR, а для отрисовки небольшой системы классов мне вполне хватает power designer + под линукс очень порадовали последние версии umbrella.

 

[fisher]

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

 

[Дмит_рий]

Спасибо всем за ответы, особенно fisher, StUV, Кром. Ответы понятны.

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

 

[StUV]

вот здесь етсть интересные статьи:
http://russian.joelonsoftware.com/

 

[Long]

Дмит_рий, реально - лучше доски для проектирования трудно что-то придумать. если хотите и у добство и производительность - пользуйтесь доской. даже не бумагой и ручкой. а уже потом можете переносить в case.
очень рекомендую Deadline ДеМарко (http://www.ozon.ru/context/detail/id/2449712/) - читаеется за 2 дня, много дельных мыслей.
зы. fisher, если будешь на встрече - постараюсь тоже приехать, и наконец вернуть книжку