понедельник, 2 ноября 2015 г.

Про хорошую постановку задачи

Неопределенность, скрытая в нечёткой постановке задачи, приводит не только к ошибкам в предварительных оценках. Очень часто фактический результат выполнения задачи не соответствует ожидаемому. Вот представим, к примеру, что у нас есть сад, в котором растёт яблоня. На яблоне растут яблоки. Нужно собрать яблоки. Есть требование - чтобы яблоки не сгнили, их нужно укладывать в один слой. На первый взгляд - все просто. Сорвать яблоки, аккуратно сложить в один слой - и готово! 

А на следующий день идет снег. Яблоки, разложенные на траве в полном соответствии с требованиями, гниют и замерзают. Команда техподдержки спешно бегает по саду, спасая случайно уцелевшие яблоки.

Основная причина подобных казусов кроется в недосказанности очевидного. Насколько различается понимание слова "очевидно" - настолько и результат отличается от желаемого.
Например, бизнес-требования описывают свойства результата с точки зрения заказчика. Но разработчик работает совсем в других понятиях, результат его работы - программный код - связан с требованиями только косвенно. Для разработчика, который не всегда хорошо знаком с реальными проблемами заказчика, требования подобны описанию слона слепыми мудрецами. Если не знать, что в итоге должен получиться слон, то результат может получиться самый неожиданный.
Акцент на действии, а не на результате побуждает сразу действовать. Слышим "собрать яблоки" - и бежим собирать. Куда именно собирать определяется на ходу, и необязательно этот выбор оказывается удачным. Спрятанные за нечёткой формулировкой не принятые решения увеличивают вариабельность конечного результата

Чтобы избежать подобных проблем, очень важно между фазой сбора требований и непосредственной реализацией потратить время на подготовку чёткой постановки задачи. Для уменьшения неопределенности лучше всего начинать с конца - постараться максимально подробно представить, как должен выглядеть конечный результат, и описать в задаче способ его достижения. И не забыть про исключительные ситуации.
При таком подходе всплывают на поверхность все недосказанности, неучтённые дополнительные задачи. Полученная постановка будет включать в себя ответы на большинство вопросов, которые возникнут по ходу выполнения задачи. Все важные решения будут приняты на этапе формулировки задачи, а не на этапе решения.

Вернёмся к случаю с яблоками. Яблоки должны лежать где? Наверное, в ящиках. У нас есть ящики? Сколько их нужно? Какие это должны быть ящики? Выбрали ящики, запустили отдельную цепочку работ по оценке нужного количества и закупке ящиков. Думаем дальше - куда ставить ящики? Вряд ли на улицу. Будем ставить их в сарай во дворе. Там есть место? Запускаем работы по подготовке и резервированию места для ящиков в сарае. Теперь думаем про исключительные ситуации. Спрашиваем у заказчика: "Как поступать с червивыми или гнилыми яблоками?". Получаем ответ, что складывать в мусорные мешки под деревом. Отправляем заказ на мусорные мешки. Ожидаемый результат - ящики с яблоками стоят в сарае, мешки с гнилыми и червивым под яблоней.

Теперь мы готовы сформулировать задачу по сбору яблок:
"Собрать яблоки с дерева в ящики. Ящики взять в сарае. Яблоки раскладывать в один слой, заполненные ящики поставить в сарай на свободное место справа от двери. Гнилые и червивые яблоки складывать в мусорные мешки. Мешки оставить под яблоней."

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

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

Эволюционная разработка программных систем

Программный продукт — это место где разработчики виртуально встречаются с пользователями. И часто с этой встречи обе стороны уходят разоч...