Чем сложнее и объемнее задача, которую вы собираетесь решить
в ходе проекта, тем труднее будет сдать ее заказчику. Объем, на котором это
становится практически невозможно, не так уж и велик. При сдаче работы объемом
более 100 часов у вас гарантированно будет по крайней мере одна проблема.
Задачу объемом более 300 часов вообще невозможно сдать без критической потери
времени, денег и нервных клеток. Какой-нибудь «этап» «классического» проекта
объемом 500-600 часов вообще не сдается, там решения о приемке с оформлением
проектных и финансовых документов и реальное выполнение работ находятся в двух
параллельных вселенных, жители которых не даже знают о существовании друг
друга.
Поэтому, если вы и впрямь настроены выполнить для заказчика
работу таким образом, чтобы вы ее сдали, он ее принял и получил именно то, что
хотел, необходимо разбить ее на как можно мелкие отдельные задачи. Сколь мелки
должны быть эти задачи? Главный принцип звучит так: если участок разработки можно сдать отдельно, его надо сдавать отдельно.
Все, что можно сдать отдельно, независимо от других доработок, должно
оформляться, как отдельная задача, которая проходит отдельную сдачу-приемку.
Главному принципу противоречит необходимость проведения для
каждой задачи определенных управленческих процедур: подготовки точной
формулировки, согласования с заказчиком объемов и срока работы, подготовки контрольного
примера, собственно сдачи-приемки. Полный жизненный цикл для задачи на один час
– это через чур. Поэтому оптимальный объем для отдельной задачи находится в
диапазоне от 20 до 80 часов, наиболее удобный объем составляет 40 часов.
Так как внедрение 1С:ERP, как правило, заключается в большом числе отдельных доработок
на разных участках системы, то большинство отдельных проектных задач спокойно
укладываются в этот интервал. Таким образом, соблюдать это правило при
подготовке и согласовании с заказчиком списка задач не так уж и сложно.
Тем не менее, в крупных проектах может возникнуть
необходимость разработать какой-то большой блок или целую подсистему, которые
предполагают сдачу заказчику целиком. Объем у такой работы может быть
значительный, что однозначно приведет ее в зону риска. Что можно сделать в
такой ситуации?
Прежде всего, к подобной разработке нужно отнестись
максимально ответственно, понимая, что она является рискованной просто из-за
своего объема. Планируемую крупную разработку необходимо тщательно
проанализировать. Цель анализа – вытащить из единого блока максимум задач,
которые можно описать и сдать заказчику отдельно. В идеале, вся разработка
должна быть разбита на отдельные задачи приемлемого размера, и часто это,
действительно, удается.
Иногда это требует специальных договоренностей с заказчиком,
который обычно согласен пойти навстречу, ведь чем сложнее разработка, тем
труднее ему принять ее. Например, часто можно договориться вынести в отдельные
задачи разработку отчетов и печатных форм, разработку прав доступа, создание облегчающих
работу сервисных функций, улучшения интерфейса и красивый дизайн форм,
автоматический запуск по расписанию и «защиту от дурака».
При этом, разумеется, есть риск потерять связность вашего
большого блока, особенно, если работа занимает длительное время и разные задачи
поручены разным разработчикам. Если этот риск высок, и ваш заказчик разделяет
ваши опасения, имеет смысл кроме задач разработки запланировать подготовку
сквозных контрольных примеров для проверки единой и согласованной работы разных
функций, созданных в нескольких предшествующих задачах. Сквозной контрольный
пример – это сложный сценарий действий пользователя (или пользователей),
который включает несколько последовательных операций в системе, имеющих общую
цель, и дающих конкретный конечный результат.
Проверка набора выполненных задач на сквозном контрольном
примере проводится только после сдачи заказчику каждой задачи в отдельности.
Недостатки, выявленные в ходе проверки сквозного примера, не могут являются для
заказчика поводом отыграть назад и объявить уже сданные задачи
«некачественными». Договоренность об этом между вами и заказчиком должна быть
достигнута еще «на берегу», до начала работы над крупным блоком, или, еще лучше
– до начала проекта. Устранение выявленных в ходе проверки на сквозном
контрольном примере недостатков включается в план последующей разработки, как новая
задача.
В ходе разработки крупного программного модуля может
быть подготовлено 2-3 промежуточных сквозных примера, и один – финальный, проверяемый
после завершения всех задач, из которых состоит разработка модуля. Создание,
согласование с заказчиком и последующее прохождение сквозного контрольного
примера в разрабатываемой системе – сложная трудоемкая работа. Которая сама по себе
является отдельной задачей, а следовательно ее необходимо заранее
предусмотреть, согласовать с заказчиком и включить в план работ.
Комментариев нет:
Отправить комментарий