Денис Бесков (beskov) wrote,
Денис Бесков
beskov

Categories:

«Заказчик не знает, чего хочет»

Взаимные обвинения

В ИТ-разработке, а сюда можно включить как разработку ИС, так и ПО и, возможно, СКС, часто можно встретить такие высказывания программистов и администраторов:
  • заказчик сам не знает, чего хочет (идиот!)
  • заказчик не прописал чёткие требования (бестолковый!)
  • заказчик опять захотел переделку, которая противоречит текущей архитектуре системы (вот придурок!)
Т.е. разработчики обвиняют заказчика в нечёткости, неполноте и изменчивости требований.

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

Взгляд со стороны

Давайте разыграем небольшую сценку.
Пациент приходит к врачу:

Пациент: Здравствуйте, доктор! Вы знаете, у меня что-то плечо болит. Я хочу, чтобы оно перестало. Дайте мне пожалуйста рецепт на что-то типа Бисептола.

Доктор: Ага, так и запишем — «Иванов А.Е., болит у него нечто». Вот вам рецепт.

Спустя несколько дней:

Пациент: Добрый день. Вы знаете, ни черта не помог этот Бисептол, только сильнее болеть стало. Дайте мне пожалуйста какой-нибудь Фервекс.

Доктор: Ну что ж, Фервекс так Фервекс, держите.

Проходит ещё несколько дней, новая сцена с похожим паттерном.
Что думает пациент? «Вот идиот этот доктор, даёт всё время что-то бестолковое»?
Что думает доктор? «Вот идиот этот пациент, сам не знает, чего хочет»?

Очевидное-невероятное

Насколько возможна такая сценка? Только при том условии, что доктор — никакой не доктор, а в лучшем случае — лаборант, и даже не врач. Почему? Потому что мы понимаем, что для успешного излечения нужно:
  1. Исследовать историю болезней пациента;
  2. Установить текущие симптомы;
  3. Выполнить необходимые анализы и обследования;
  4. Установить на основе вышеизложенного диагноз;
  5. Назначить соответствующее лечение.
Причём это обязанности врача, в широком смысле - медицинского учреждения.

Почему заказчик не работает аналитиком

Ошибка номер 1 — Полагать, что Заказчик в принципе может полно и качественно сформулировать целевые свойства системы, достаточные для её проектирования и реализации.

Заказчик знает, чего хочет. Вот только знание это в своих формулировках «решить такую-то проблему; чтобы налоговая не могла привязаться; поднять уровень продаж за счёт интернета» явно недостаточно для начала проектирования. И это не его проблема, и это не повод для обвинения его.

Потому что, в очередной раз - типичный заказчик не эксперт в IT-области, он не знает с достаточной для качественной постановки не только технических, но и функциональных требований о возможностях, свойствах и ограничениях ПО как такового и отдельных его полуфабрикатов как следствие.

Типичный заказчик — не эксперт в формулировке требований к продуктам, системам и ПО. Его этому никто никогда и нигде не учил.

Дай бог, чтобы заказчик был экспертом хотя бы в своей предметной области (!), хотя опять же требовать от него этого нельзя.

Зрелость IT-инженерии

Проблема не в том, что заказчик не умеет и не понимает, как и какие требования выдвигать к продукту.

Проблема в том, что IT-разработчики, с удовольствием соглашаясь, когда их называют «инженерами", не владеют дисциплиной Software Requirements (в более широком контексте - Requirements Engineering), входящей в набор Software Engineering Body of Knowledge (SWEBOK), выполнение процесса которой ложится на них в малых проектах. Индустрия придумала для таких проектов workaround для дисциплины «Требования к ПО» в виде RAD и Agile-практик, но в России ими в основном пользоваться не умеют.

Проблема в том, что IT-компании в лице их менеджеров не умеют и не могут поставить процесс разработки промышленным образом в средних (а иногда — и больших) проектах, выделить роль бизнес/системного аналитика и ресурсы на её отработку.

В результате получается, что «лечение» заказчика производится на основе как-то задокументированных отзывов, впечатлений заказчика о своих проблемах и возможностях развития, без исследования, постановки диагноза, выбора методов «лечения». Т.е. имеет место так ненавистный мне «процесс исполнения желаний» (волюнтаризм в выдвижении и исполнении требований), а не зрелая инженерная деятельность. Немудрено, что желания меняются, т.к. меняется настроение, меняется понимание истинных проблем (т.к. исследование проиходит неявно в ходе реализации и убеждения неработоспособности реализованного).

Бизнес и ИТ как Сцилла и Харибда

В отличие от врачевания человеческого тела, где предметная область, какой-бы сложной она ни была, всё-таки одна, в IT-разработке чаще всего мы имеем как минимум 2 предметные области конкретную сферу традиционного или инновационного бизнеса и собственно IT. Поэтому в случае нетрививальной предметной области бизнеса обязательно надо потратить время на понимание устройства бизнеса, идентификацию настоящих проблем (Root Cause Analysis) и возможностей, выработку принципиальных способов решения проблемы на уровне бизнеса (автоматизация, расширение, скупка активов, реорганизация процессов, свёртывание бизнеса), выработку концептуального способа решения бизнес-задач на уровне системы, определение требований как системных свойств, их приоритезацию и постановку процесса управления изменениями (которые неизбежны).

И тут действительно нужны разные навыки и квалификация — как для 1) исследования и моделирования на уровне бизнеса, так и 2) на уровне формулировки требований к системе. Далеко не каждый системный архитектор способен хотя бы на второе, как минимум — потому что эта деятельность требует другой точки зрения на систему, как максимум — потому что его этому просто нигде не учили.

Пиррова победа работы «с проектирования»

Поэтому когда я слышу «заказчик не знает толком, чего он хочет» то мне тут же становится понятно, что кто-то в окружении говорящего (возможно, он сам), экономит на обучении и персонале, создавая себе в лучшем случае Пиррову победу — проект сдан, деньги получены, но бизнес-эффект нулевой, заказчик несчастен, бюджет превышен, разработчики вымотаны переработками. Как вариант — IT-компания не хочет делиться бюджетом с консультантами, способными выполнить работу по качественной постановке задачи на проектирование и курировать её реализацию.

P.S. Забавно, что Business Analysis Body of Knowledge тоже в основном требованиям посвящён, а совсем не анализу бизнеса, как хотелось бы.
Subscribe

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 62 comments