вторник, ноября 07, 2006

Как читать требования

Заказчик на объекте принимает работу у подрядчика. Тот подводит его к выкопанной шахте диаметром 3 метра и глубиной 50 метров, заглядывают туда, на дне горит прожектор.
Заказчик - что за херня???
Подрядчик - вот же чертеж!! по нему и сделали.
Заказчик -



(переворачивая чертеж на 180 градусов) - это маяк!!!

Что ни говори, а требования надо уметь читать.
"Обеспечить формирование произвольных отчётов" - это что значит? Произвольных из списка? Или надо дать возможность конструировать отчёты самостоятельно?
"Работать под управлением любых современных операционных систем". Включая QNX, MorphOS и AmigaOS?
"Не содержать интерпретируемого кода". Компиляция из MSIL в native код во время выполнения считается в вашем клубе за интерпретацию или только reflection? А если я внутри кода сам компилирую вызовы getters и setters, чтобы не связываться с reflection - это тоже интрепретация? Как нет? Я же получаю имена с помощью

GetType().GetProperties()[0].PropertyType
И таких нюансов каждый может придумать с десяток за минуту. Как же быть, чтобы не построить маяк?

Мы перепробовали много методик. В том числе и заказчик on-site, как это практикуется в XP. Трудно сказать, каков должен быть идеальный путь выяснения настоящего смысла требований, но я могу рассказать про тот, который работает у нас.

  1. Как это ни смешно, но требования надо получить в письменном виде с расстановкой приоритетов.
  2. Взять таймаут на составление вопросов по требованиям. В зависимости от проекта это может занять как 1, так и 14 дней (говорю о типичных величинах для обычных проектов; если вам заказали написание сервера баз данных или компилятор для операционки новейшего автономного пылесоса с функцией барокамерного холодильника - я пас). Все вопросы, от серьёзных (полное непонимание), до ерундовых (почти всё понятно - и это самое опасное) тщательно запротоколировать.
  3. С блокнотом вопросов, диктофоном, ангельским терпением и колодой визиток выдвинуться в расположение заказчика, заранее предупредив его о том, что есть вопросы. В наши цели не входит беседовать с парнем, который только второй день работает или которого пригнали отдуваться из-за того что он не успел спрятаться.
  4. Объясните, чего вы хотите и непременно убедитесь, что сидящий напротив понимает, о чём идёт речь. А то будет как с полотёром Басова в "Шагаю по Москве". Это сильно портит настроение и плюс к тому это зря потраченное время: придётся то же самое спрашивать повторно.
  5. Делайте, что хотите, но обязательно расположите к себе собеседника. Учтите, что в то время, пока вы выполняете одну работу, интервьюируете, он - две. Отвечает вам и по-прежнему обязан делать то, за что ему платят в организации деньги: заниматься основными средствам, ругаться по поводу капитального ремонта труб или обеспечивать выборы своего директора в местную думу. Нам везло и особых сложностей не возникало - достаточно было за сутки узнать номер телефона выделенного человека, чтобы фазу знакомства сделать менее жёсткой.
  6. Задайте кумулятивный вопрос ("для чего вам нужна эта программа?")и слушайте, включив диктофон. Не перебивайте. Некоторые люди обладают настоящим даром - объяснить сложнейший процесс, такой, как остановка и запуск котельной, своими словами так, что всё поймёт и ребёнок.
  7. Уйдите на перерыв.
  8. Вцепитесь в человека, обрушив на него все вопросы, которые только у вас есть.
  9. Повторяйте пункт 8, пока вопросов больше не останется. Если это длится больше пары дней - дело нечисто. Или требования не соответствуют тому, что нужно сделать, или вы не в состоянии понять, чего от вас хотят. Первое - очень плохо. Второе - ужасно. Попросите в таком случае себя заменить.
  10. Ответы у вас есть, можно согласовывать план реализации требований

Логично и правильно, что выяснением требований занимаются специально обученные люди, аналитики. Но кто в небольшой организации может себе позволить ребят, уволившихся из какого-нибудь Капитал-Инвеста (название вымышленное, и любые совпадения случайны) с оклада в 150 тысяч рублей в месяц? Это не могут сделать и более крупные организации, чем ваш (и наш) гаражный кооператив из пяти человек. Поэтому нацеливайтесь на то, что требованиями вы будете заниматься самостоятельно. Для того, чтобы потом писать лучший код.

И ради бога, помните про маяк!

2 комментария:

Unknown комментирует...

по-хорошему, есть еще кучи-кучи-кучи ньюансов. Но, в общем, все так и есть.
: работайте с требованиями постоянно, подтверждайте и перепроверяйте все свои знания и сомнения.
Короче, в этой области (работа с заказчиком) хорошо получается использовать практики ХР. У меня по этому поводу есть несколько хороших книжек - например, Кента Бека "ХР: Планирование" и еще одна... Playing to win, не помню авторов.

Das Ich комментирует...

Практики XP? Это которое же? Чтобы представитель заказчика постоянно присутствовал в команде разработки?

Бек сам не верит, в то, что пишет. С чего бы верить мне, который пробовал?