НАЧНЕМ С ПОНИМАНИЯ
Перефразируя классику про редкую птицу, способную долететь до середины Днепра, скажу, что редкий разработчик дочитал книгу “SQL” Мартина Грабера до места, где он объясняет непосредственно консерваторию всего процесса разработки – как получить знание того, что все-таки предстоит сделать. Вот этот отрывок (выделено мной):
Итак, в своей базе данных вы должны моделировать те области деятельности, управление которыми требуется вашим клиентам, и по возможности закладывать в него больше, чем они считают нужным на данном этапе. При обсуждении вопросов с заинтересованными лицами учитывайте следующее:
- Вы должны получить информацию как от конечных пользователей, так и от руководства. Конечные пользователи знают больше подробностей о данных и о выполняемой работе, тогда как менеджеры определяют круг задач, которые должна решать база.
- Зачастую лучще опрашивать людей группами, чтобы получить эффект “мозгового” штурма и более эффективно использовать время. Задавайте вопросы, допускающие разные варианты ответов. В этом случае пользователи дадут вам больше информации, чем при ответах на конкретные вопросы.
- Для начала лучше всего встречаться с людьми непосредственно, имея под рукой записную книжку. Позже, когда вам потребуется только уточнить некоторые детали, можно использовать электронную почту. Вы получите все ответы в письменном виде.
- В основном вы должны расспрашивать людей об их обязанностях, каким образом они их выполняют, какая информация им для этого нужна и что является результатом. Постарайтесь понять логическую стуктуру самой информации.
- Вы должны попытаться определить бизнес-правила. Разрабатываемая схема должна отражать реальные правила, а не абстрактный вариант, который хорошо укладывается в модель данных. Это было проиллюстрированно в таблицах-примерах, где продавцы иногда могут обслуживать покупателей, которые к ним не прекреплены. Ситуации такого рода следует обрабатывать как можно аккуратнее.
Очень важно приложить максимум усилий к тому, чтобы попытаться понять, зачем что-то надо пользователю, вместо того, чтобы удовлетвориться простым знанием что ему надо (тупо записать [в лучшем случае(!)] его хотелку к себе в блокнот). От этого будет зависеть то, как дальше пойдет вся разработка. Будете ли вы искривлять пространство консерватории проекта вблизи массы черной дыры непонимания процессов, происходящих у пользователя, либо строить ровный и крепкий фундамент для последующего развития системы. Вам решать: хоронить проект сразу или же поднапрячься таки с пониманием пользовательских процессов.
Неплохо сообщает сходную мысль Макс Крайнов в теме “Семь Навыков Высокоэффективных Продуктоводов” своего блога. Позволю себе процитировать для полноты картины (последнее предложение выделено мной):
- Задавайте вопрос “почему?”, а не “что?”. Почему заказчику одна функция продукта нужна больше, чем другая? Какой ответ будет на вопрос: “в какой цвет мне покрасить потолок – в красный или синий”? Допустим, заказчик отвечает “в синий”. Продуктовод красит потолок в синий цвет, а потом вдруг выясняется, что его придётся перекрашивать в чёрный цвет. В чём проблема? Проблема в том, что продуктовод не удосужился поинтересоваться, а чем, собственно, обоснован выбор синего цвета. Если известно, что хочет контрагент (продукт, условие договора, повышение зарплаты и т.п.), то появляется больше возможностей удовлетворить эту требность наиболее выгодным для себя образом. Ответ на вопрос “что хочет клиент?” даёт факт, а на вопрос “зачем он это хочет?” – понимание.
На вопрос всех времен и разработчиков “Почему пользователи сами не знают чего хотят” Сергей Корнилов отвечает в своем блоге таким выводом (выделено автором):
- Второй вывод – существует нестыковка между тем что люди говорят, что они хотят, и тем что они на самом деле хотят. Когда пользователи просят вас добавить новую функцию в программу, стоит смотреть на эту просьбу в разрезе «будут ли реально они ей пользоваться» и «что они хотят на самом деле». Точный ответ может дать только тестирование прототипа новой функции на живых пользователях.
И вот еще что. Помните, что клиент сам не понимает иногда того, чего хочет. Это серьезно, а не смешно. Сей прискорбный факт может быть обусловлен целым рядом причин, начиная от закостенелых привычек работать “как в той программе”, программисты которой его и не спрашивали, что же ему по сути надо, заканчивая банальной некомпетентностью на искомой должности. С уверенностью можно констатировать, что грамотный заказчик – редкая удача для разработчика. И никогда не расслабляйтесь, потому что последнее правило также работает и в обратную сторону.
Ссылки:
