rec

Некоторые рекомендация для менеджеров проектов

Все программисты — оптимисты.

Фредерик П.Брукс.

Лучшее - враг хорошего. Если кому-то в голову пришла "блестящая идея", лучше ее отложить, и работать по плану.

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

Сколько народу надо?

Один из значимых факторов успеха проекта - небольшое число разработчиков. Группа из 20 и более программистов тратит значительно больше усилий, чем группа из 5 человек. Согласно статистике, чтобы написать проект из 50 тыс. строк кода, большая команда тратит 99 человеко-месяцев, а маленькая - 19 человеко-месяцев. При этом оптимальный размер группы разработчиков - 5-7 человек.

Когда задание нельзя распределить между несколькими работниками из-за ограничении на последовательность выполняемых работ, привлечение дополнительных сил не влияет на график его выполнения. Чтобы выносить ребенка, нужно девять месяцев, независимо от того, сколько женщин будет к этому привлечено [2].

По результатам анализа 491 проектов последних трех лет [1], в которых только новых или модифицированных строк кода (СК) насчитывалось от 35 тыс. до 90 тыс. (средний размер проекта составил 57,412 строк с разбросом +/- 3 тыс. СК), выявлено однозначное преимущество небольших команд - и в плане скорости выполнения заказа, и в плане сроков, и в плане бюджета.

В процессе анализа все проекты были разбиты на пять групп с соблюдением двух условий:

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

Три небольшие подгруппы тратят в среднем меньше времени на проект, чем две большие. Время работы трех групп из 3-7 программистов составило 75% времени работы двух групп из 9-20 программистов. Резкий скачок в потреблении группой ресурсов происходит, когда число разработчиков становится большим или равным 8 человекам.

Если каждая часть задачи должна отдельно координироваться с каждой другой частью, затраты возрастают как n(n-1)/2. Между тремя работниками в три раза больше попарных взаимосвязей, чем между двумя; между четырьмя — в шесть раз больше, Если, однако, для совместного решения вопросов нужно проводить совещания трех, четырех и более работников, ситуация становится еще хуже. Дополнительные затраты на обеспечение связи могут полностью нейтрализовать эффект разбиения первоначальной задачи на части. Добавление людей лишь удлиняет сроки выполнения работ, а не укорачивает их.

Литература и источники

Планета КИС Методологии Дайджест.htm. Сколько народу нужно?

Фредерик П.Брукс. Мифический человеко-месяц.