Мы производим гвозди по ГОСТу: как идеально выполнить неправильное ТЗ
ТЗ согласовано, разработка выполнена правильно – а в системе закреплено правило, которого компания никогда не принимала. Такое происходит, когда автоматизация доходит до развилки, для которой есть несколько разумных вариантов работы, но нет ни единого бизнес-решения, ни человека с полномочием его принять. ИТ должно обнаружить эту точку, подготовить варианты, показать последствия и дать рекомендацию. Решение о том, как должен работать процесс, остаётся за бизнесом. Практический инструмент статьи – реестр непринятых решений процесса.На тестовой эксплуатации менеджер создал обычную заявку на закупку. Основной объём составляли канцтовары, плюс в той же заявке было несколько мониторов. Система проанализировала состав, определила преобладающую категорию и автоматически направила всё категориальному менеджеру по канцтоварам. Маршрут сработал, заявка не потерялась, права доступа были корректны, алгоритм выполнился ровно так, как его запрограммировали.Проблему обнаружил один вопрос: а мониторы он теперь тоже должен закупать?Алгоритм не был случайным или заведомо нелепым. Он выглядел вполне логично и даже подтверждался историческими данными. Неприятность состояла в другом: никто в компании не принимал решения, что именно так должен работать процесс закупок. К моменту тестирования это решение уже существовало, только существовало оно не в регламенте и не в решении владельца процесса, а в коде.Чтобы понять, как оно туда попало, надо вернуться к началу проекта. В подписанном техническом задании была совершенно нормальная строка: Читать далее