четверг, 7 февраля 2019 г.

Тактика внедрения 5. Нарезка задач и сквозной контрольный пример

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

Комментариев нет:

Отправить комментарий