Зачем нужно делать оценки
Оценка очень важна как для клиента, так и для компании-разработчика, и неточность в этой оценке, неспособность предусмотреть все факторы, приводит к неприятностям для обеих сторон. Клиент испытывает разочарование, когда разработчик сдвигает сроки сдачи проекта. Для разработчика же неточная предварительная оценка чревата превышением бюджета проекта, а соответственно – работой в убыток.
Введение
Успешно завершить программный проект непростое дело. Можно найти множество объективных и не очень объективных причин, почему тот или иной проект потерпел неудачу. Когда проект провален, уже неважно по чьей вине это случилось, важно лишь, что были потрачены усилия разработчиков, материальные средства, время заказчика, и все это напрасно: результатом недовольны обе стороны – и заказчики, и разработчики. Причем, даже если в провале проекта есть вина самого заказчика, что, признаться, бывает очень и очень редко, то для разработчика это все равно оборачивается потерей клиента. В этом и заключается принцип «клиент всегда прав» – клиент, какой бы он ни был, имеет право получить результат, соответствующий его ожиданиям. Следовательно, надо построить так процесс разработки, чтобы он приводил к успешному завершению проекта.
Важной составляющей процесса разработки является управление требованиями. Под управлением требований мы понимаем комплекс мер, направленных на сбор требований от заказчика, планирование к разработке, ранжирование по степени важности, оценку по времени и стоимости.
Процесс управления требованиями должен решать следующие задачи:
1. Документировать все требования заказчика.
Нет необходимости лишний раз говорить о том, что все требования заказчика должны быть задокументированы. В зависимости от размеров проекта может меняться только степень детализации, неизменным остается лишь факт, что все, что должно быть реализовано в программном продукте, должно быть где-то записано и с заказчиком должна быть проведена работа по согласованию этих требований.
2. Достичь понимание требований до того, как начнется их реализация.
Это позволит уменьшить риски, что заказчик получит не то, что ожидает.
3. Помочь определить несоответствия между результатами и требованиями.
Чем лучше задокументированы требования, тем легче тестировать полученный результат. Что опять же уменьшает риски того, что заказчик будет разочарован результатом.
4. Установить обязательства исполнителей.
Реализация требований сопряжена с временными и денежными затратами. Процесс управления требованиями позволяет установить контроль за этими параметрами.
5. Установить двусторонний контроль по отслеживанию требований.
В процессе разработки требования могут меняться: что-то уточняется, что-то добавляется, что-то отменяется. Эти события могут повлиять на стоимость и сроки выполнения проекта. Поэтому необходимо, чтобы обе стороны (и разработчики, и заказчик) имели актуальное представление о текущих требованиях. Только в этом случае возможно успешно завершить программный проект.
6. Управлять изменениями.
Требования меняются в процессе разработки. Это факт. И с этим не нужно бороться – нужно лишь эффективно управлять.
В этой статье мы опишем способ управления требованиями с помощью XPlanner (www.xplanner.org), решающий все перечисленные задачи.