— Ах да, мы изучали бизнес-процессы и получили результат: анализ бизнес-процессов показал, что процессов по-факту нет!
— Да что вы говорите, серьёзно?
— И поэтому мы создали для заказчика ДОКУМЕНТ.
Потому что по-факту, когда анализ бизнес-процессов показывает, что процессов нет — у тебя ДОКУМЕНТ НИ О ЧЁМ.
А когда ты имеешь документ ни о чём — ты спокойно называешь его «СТРАТЕГИЯ».
Все довольны, идём дальше.
(С) Степан Эрнстович Внедряй!
Всем кто работает с конкретным клиентом, знакома проблема расплывчатости рамок при строгих ограничениях сроков и бюджета на реализацию?
Эта проблема имеет две ключевые причины:
Во-первых – Клиент тратит время и деньги на ИТ не для удовольствия, если он не получит точные сроки и бюджеты проекта, он не сможет спланировать свою рентабельность и свое развитие – это угроза бизнесу и билет на выход для топ-менеджеров.
Во-вторых – Сама природа информации и изменчивость окружения не дает полностью просчитать — как должна работать система до ее полной готовности, даже более того – до вывода из эксплуатации. Бессмысленно кивать на некомпетентность клиента – даже самый подготовленный клиент не способен заранее дать идеальное ТЗ.
Есть два популярных способа – как с этим бороться.
Во-первых — можно сделать запас по срокам и деньгам (Попросить много денег сразу).
Во-вторых – можно детально прописать рамки и ограничения таким образом, чтобы клиент заплатил потом. («В справочнике не должно быть больше 799,98 элементов»)
В первом случае обычно тендер выигрывает кто-то другой. Во втором случае клиент не может адекватно заложить резерв на своей стороне, поэтому на просьбу оплатить доп. требования отвечает — что денег нет, сроки жесткие, или есть гораздо меньше чем нужно.
Но если с одной стороны нельзя просить много денег, и с другой стороны нельзя честно прописать все ограничения то, как тогда зарабатывать?
А очень просто — Надо больше работать с разделом «Ни о чем» ©.
По-другому этот раздел называется «Цели и задачи проекта».
Дело в том, что без этого раздела ТЗ это всегда компромисс между противоречивыми требованиями всех пользователей, а из трудов доктора Голдратта мы знаем – что компромисс никогда не приводит к успеху.
Успеха добивается тот, кто устраняет источник конфликта интересов, а не тот, кто ищет компромиссы.
Практика создания информационных систем и статистика запоротых проектов полностью это подтверждает – главная причина неудачи почти всегда в том, что команда проектирования не смогла понять и правильно интерпретировать требования.
После чего с точки зрения одной стороны «Клиент сам не знает — чего хочет, причем бесплатно», а для другой стороны «У разработчиков в голове опилки, и руки кривые».
А по сути, просто не решенный конфликт интересов пользователей перешел в новую форму.
Решение конфликта в понимании природы термина «Use Case».
Перевод «Вариант действий», но каких действий? Для чего действий?
Если подходить к этому вопросу как «Пользователь знает для чего», то мы засовываем голову в песок, потому что нам отлично известно — что пользователь не знает что ему на самом деле надо.
Другое дело если мы понимаем что «Проблема – это система, не дающая удовлетворительного результата из вложенных ресурсов и усилий субъекта».
Тогда «Use Case», это вариант действий, который решает проблему.
Иными словами «Use Case» это вариант действий, который дополняет проблему так, что бы она дала пользователю нужный результат из вложенных ресурсов и сил.
То есть если мы перед проектированием подробно узнаем у пользователя — «Какой результат он хочет получить?» и «В чем этот результат не удовлетворяет его?», а потом опишем это в «Целях и задачах проекта», то в дальнейшем при проектировании системы мы будем решать проблему, а не искать компромиссы.
Следовательно, мы получим способ уложиться в бюджет и 100%-й критерий отсечения требований и «хотелок» пользователей – все, что не требуется для решения бизнес-проблемы, то не обязательно для реализации.
При этом если мы понимаем бизнес-проблему и утвердили с клиентом, по сути, система должна решить только ее, то мы можем не прописывать ограничения проекта на 300 страниц.
Получается не надо слушать Степана Эрнстовича – именно документы «ни о чем», и разделы «Цели и задачи» на самом деле ключ к деньгам и успеху, если их конечно правильно написать.
