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