Заказчик на объекте принимает работу у подрядчика. Заказчик смотрит: вырыта глубокая узкая круглая яма, на дне которой горит прожектор. Он гневно спрашивает:
– Что за чёрт?!
Подрядчик:
– Всё сделано по чертежу, вот, посмотрите.
Заказчик, переворачивая чертеж вверх ногами:
– Это должен был быть маяк!
Все знают этот старый анекдот. Но вот вопрос, почему подрядчик копал яму по чертежу, и даже не подумал его перевернуть? Хочется ответить, что просто неграмотный и не перевернул чертеж.
Да, возможно, это и так. Ну, а, если ошибся чертежник и переворачивать чертеж по правилам не было нужно? Почему возможна такая дикая нестыковка с ожиданиями заказчика?
Ответ простой – подрядчик исполнял задание, не задумываясь о бизнес-задачах заказчика! Он просто не знал, зачем заказчику то, что он делает. Возможно, заказчик собирался указывать путь кораблям? Но это предположение. Может быть, маяк ему нужен был совсем для другого, и тогда нужно было бы строить совсем другой маяк, или вообще не маяк?
Подрядчик всего этого не знал и не спросил, вот и получился анекдот вместо результата.
К сожалению, непопадание в ожидания и потребности заказчика – одна из животрепещущих проблем создания ИТ-решений. Такие промахи в состоянии погубить проект целиком, испортить репутацию и расшатать нервы всем участникам.
Давайте посмотрим, почему это происходит и как это можно улучшить.
Как начинается разработка
Как начинается разработка ИТ-решения?
Обычно у кого-то из ответственных лиц возникает идея «пора бы это автоматизировать». Подтолкнуть к этому жизнь может с разной стороны, например, побуждающими факторами могут быть:
– Конкуренция и то, что у других компаний данный процесс работает лучше.
– Время на принятие решений и выполнение операций превышает желаемое.
– Оптимизации и прочие внутрикорпоративные движения повышения эффективности.
– Желание стать более современным и цифровизированным подразделением.
– Хайп на рынке, влияние внешнего маркетинга.
– Вера в чудесное новое решение всех проблем.
– Новости законодательства и отраслевых регуляторов.
– Воля вышестоящего руководства.
Кроме того, может быть и множество других причин. Здесь важно, что появляется воля лица, принимающего решения, которая может быть выражена в выделении на создание ИТ-решения некоторого количества ресурсов (финансовых, временных, экспертных и др.), что должно привести к автоматизации какого-то участка бизнеса и изменить показатели, характеризующие этот участок, соответственно ожиданиям.
Появляется критерий «соответствие ожиданиям», то есть:
– ожидания должны быть сформированы;
– ожидания должны быть формализованы до метрик или категорий, которые позволили ли бы определить меру соответствия ситуации этим ожиданиям;
– для метрик и категорий определены целевые значения.
В реальности так бывает редко. Обычно ожидания сродни мечте или иллюзорному образу «светлого будущего». При этом воля (или драйв, как нынче модно говорить) имеется, а, значит, есть и движение к мечте.
Особенность мечты, как мы все знаем из многочисленных трудов по мотивации, в том, что пока не выстроен более-менее измеримый и непротиворечивый образ этой мечты, движение носит хаотический характер, а шансов достичь цели немного.
Более того, велик шанс не понять, что цель уже достигнута и разочароваться. Увы, все тоже самое, часто с куда большими затратами, верно и для создания ИТ-решений.
Чем более размыты и абстрактны ожидания, тем меньше шансов на удовлетворенность результатами проекта.
Итак, ключевые факторы начала разработки это:
– Желание, или даже мечта, драйв;
– Возможность привлечь для создания решения необходимые ресурсы;
– Понимание целей того, что собрались сделать, и вера в бизнес-полезность этого.
Пока мы говорили о желании, мечте, но всем известно, что разработка ведется на основе требований. И если мечты и желания исследуются поэтами, писателями, психологами, то требования – область деятельности аналитиков, менеджеров продуктов и разработчиков.
Немного остановимся, на том, что такое требование и каковы его свойства.
