Взаимные обвинения
В ИТ-разработке, а сюда можно включить как разработку ИС, так и ПО и, возможно, СКС, часто можно встретить такие высказывания программистов и администраторов:
- заказчик сам не знает, чего хочет (идиот!)
- заказчик не прописал чёткие требования (бестолковый!)
- заказчик опять захотел переделку, которая противоречит текущей архитектуре системы (вот придурок!)
Т.е. разработчики обвиняют заказчика в нечёткости, неполноте и изменчивости требований.
Ну а заказчики, как вы сами понимаете, зачастую обвиняют «программистов» в том, что «мягкая оснастка» не такая уж мягкая, если на доработку уходят месяцы, что программа не делает очевидных вещей, те вещи, которые проговаривались и описывались, делаются в системе совсем не так и т.д. и т.п.
Взгляд со стороны
Давайте разыграем небольшую сценку.
Пациент приходит к врачу:
Пациент: Здравствуйте, доктор! Вы знаете, у меня что-то плечо болит. Я хочу, чтобы оно перестало. Дайте мне пожалуйста рецепт на что-то типа Бисептола.
Доктор: Ага, так и запишем — «Иванов А.Е., болит у него нечто». Вот вам рецепт.
Спустя несколько дней:
Пациент: Добрый день. Вы знаете, ни черта не помог этот Бисептол, только сильнее болеть стало. Дайте мне пожалуйста какой-нибудь Фервекс.
Доктор: Ну что ж, Фервекс так Фервекс, держите.
Проходит ещё несколько дней, новая сцена с похожим паттерном.
Что думает пациент? «Вот идиот этот доктор, даёт всё время что-то бестолковое»?
Что думает доктор? «Вот идиот этот пациент, сам не знает, чего хочет»?
Очевидное-невероятное
Насколько возможна такая сценка? Только при том условии, что доктор — никакой не доктор, а в лучшем случае — лаборант, и даже не врач. Почему? Потому что мы понимаем, что для успешного излечения нужно:
- Исследовать историю болезней пациента;
- Установить текущие симптомы;
- Выполнить необходимые анализы и обследования;
- Установить на основе вышеизложенного диагноз;
- Назначить соответствующее лечение.
Причём это обязанности врача, в широком смысле – медицинского учреждения.
Почему заказчик не работает аналитиком
Ошибка номер 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 тоже в основном требованиям посвящён, а совсем не анализу бизнеса, как хотелось бы.
Что забыл?Далее в программе — на основании чего и как именно формируется план разработки.