5 soft - Работа с проектами

Каскадная модель

Любой проект на протяжении своей жизни проходит следующие этапы:

Аукцион или торги.
Разработка технического задания (ТЗ).
Разработка функционального дизайна (ФД).
Подробная оценка сроков.
Разработка.
Поддержка.

Аукцион На данном этапе заказчик готовит краткое или полное ТЗ, или просто излагает идею проекта, то есть то, что он хочет получить в результате разработки. Наши главные задачи на данном этапе:

Анализ предоставленного ТЗ или составление краткого ТЗ, в случае его отсутствия.
Анализ предоставленного ФД или составление краткого ФД, в случае его отсутствия.
Предварительная оценка сроков. Она должна быть максимально точной для текущего варианта ФД и ТЗ.

Данные три этапа делаем бесплатно.

Оценка срока, предоставляемая в торгах (АО - аукционная оценка) равна сумме предварительной оценки сроков (оплачиваемое заказчиком время),30% на управление проектом (оплачиваемое заказчиком время), 30-40% на непредвиденные обстоятельства (Например: заболел и т.п.) Это неоплачиваемое заказчиком время.

Предоставляемая оценка является приблизительной и мы имеем возможность изменить ее после того как у нас появиться конечная версия ТЗ и ФД. Мы должны уведомить заказчика, что данная оценка сделана из расчета, что все будет сделано самым простым для нас способом. АО подается заказчику на торги. Мы не занижаем сроки. Оценка сроков должна быть реальной и обоснованной. Если заказчик просит аргументировать оценку, мы всегда имеем возможность предоставить ему документ (в виде excel таблиц, проекта msproject и т.п.)

Важно понимать, что даже если заказчик предоставит подробное ТЗ, то у нас в любом случае будут вопросы и дополнения к нему и ФД. Об этом факте мы обязательно должны уведомить заказчика. Время, которое будет затрачено на вопросы и уточнения ТЗ и ФД, или на подготовку полного ТЗ и ФД (если таковые не были предоставлены заказчиком) должно оплачиваться. То есть главное правило - Заказчик должен платить за составление подробного ТЗ и подробного ФД. Если заказчик не соглашается оплачивать данную работу, и отказывается предоставить какой-либо свой вариант, то дальнейшее сотрудничество мы исключаем.

Техническое задание ТЗ, как правило, не может разработать не программист (человек должен хорошо ориентироваться в аналитике, технологиях, базах данных и т.д.).

В случае предоставления технического задания заказчиком мы должны:

Тщательно проанализировать его. Желательно, чтобы в данном процессе участвовало несколько человек. Можно провести параллельный анализ, а затем объединить накопившиеся вопросы, неоднозначности, предложения.
Список вопросов и предложений посылается заказчику одним пакетом
После ответа заказчика нужно повторить еще раз пункты 1) и 2) с учетом поступившей от клиента информации. Цикл анализа должен повторяться до тех пор, пока полученное ТЗ устроит и нас и заказчика.

В случае если мы сами разрабатываем ТЗ, мы обязаны:

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

Примечание: Не стоит недооценивать важность анализа ТЗ. Так как это может вылиться в очень серьёзные проблемы. Например, в неправильную оценку сроков, а, следовательно, в задержку сроков сдачи готового продукта, что может вызвать нежелательные конфликтные ситуации.

Функциональный дизайн

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

Функциональный дизайн, как правило, может быть разработан не программистом. Для составления ФД необходимо знать, как работать с компьютером, уметь работать в офисных приложениях, браузерах, ориентироваться в аналитике. Но, все-таки, для определенного вида задач, например, если разрабатываемая система независима от графического интерфейса, например, использование сторонних файловых хранилищ, разработка API и т.п., целесообразнее привлекать именно программиста.

Примечание: Не стоит функциональный дизайн путать с web-дизайном, т.к. это разные вещи. Web-дизайн разрабатывается отдельно от разрабатываемой системы, т.к. для него нужно свое ТЗ и свой ФД (flash, ajax и др. динамические эффекты), что нужно обсудить с заказчиком еще до разработки ТЗ. Система и web-дизайн должна делаться параллельно, дабы избежать противоречий. В случае если web-дизайн делает заказчик самостоятельно, то мы должны обговорить с ним следующий момент - лучше всего будет начать делать web-дизайн после разработки нами ФД. Если же заказчику важнее сохранить именно ту форму web-дизайна, которую он заранее приготовил, то мы должны будем тщательно проанализировать подготовленный web-дизайн перед составлением ФД. Время, потраченное на данный анализ, включается при этом в ФД.

Функциональный дизайн должен быть законченным продуктом, то есть даже если мы не будем делать этот проект, мы должны сделать его качественно, разрешить все спорные моменты, сделать так, чтобы после его прочтения не возникали вопросы. После этого можно отправлять ФД заказчику. Нужно объяснить заказчику, что ФД - документ по которому он и мы будем проверять качество программного продукта.

Подробная оценка сроков Подробная оценка сроков (ПОС) - документ, который содержит временные оценки (сроки), за которые мы гарантированно должны выполнить ту или иную задачу, для всех элементов ФД. При составлении ПОС мы действуем по следующему алгоритму:

При составлении ПОС мы поступаем аналогично, как поступали в ТЗ (задействуем несколько человек), но обязательно берем в расчет индивидуальные особенности (умения, навыки) разработчика - человека, который непосредственно является исполнителем. То есть, обязательными участниками составления ПОС должны быть разработчики. Обычно ПОС оформляется в виде файла Excel или MSProject. Очень важно, чтобы в оценке сроков не было задач с оценкой более 12-16 часов. Если таковые обнаружились, значит нужно разбить ее на подзадачи и для каждой подзадачи выполнить оценку отдельно. Данный лимит установлен для того, чтобы минимизировать ошибки в оценке. После того как мы сделали ПОС, нужно добавить 30% времени на тестирование и отладку и 30% - неоплачиваемый буфер на непредвиденные обстоятельства. В случае, если проект крупный, и для его разработки необходимо более одного программиста, дополнительно добавляем еще оплачиваемые 30% на управление проектом, при этом буфер на непредвиденные обстоятельства сокращён до 20%.

Заказчику оценка сроков должна предоставляться в кратком виде. То есть суммарный срок мы предъявляем аналогичный, но задачи объединяем в более крупные (такие чтобы было понятно даже не программисту). Разделяем проект на смысловые этапы разработки - контрольные точки (MILESTONE). Получаем документ в формате, который приведен в таблице 1.

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

По данному документу мы и заказчик будем контролировать нашу совместную работу, а именно ее стоимость и продолжительность.

Таблица 1

Milestone	Human/hour	Dollars/hour
1	210	6
Большая задача 1	100
Большая задача 2	50
Большая задача 3	60
2	150	7
Большая задача 4	50
Большая задача 5	75
Большая задача 6	25
...	...	...
Summary	800	1024

Разработка Разработка проекта производиться в рабочем порядке согласно установленным уставу, кодексу и нотациям.

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