Около 10 лет назад я столкнулся с неприятной проблемой, мы сдавали клиентам работы, а в... — 25 мая 2026 г. в 06:18:37.867
Около 10 лет назад я столкнулся с неприятной проблемой, мы сдавали клиентам работы, а в ответ часто слышали “это не то, что мы хотели”. Один или два раза такое можно списать на то, что не поняли друг друга. Но когда это начало повторяться почти постоянно, стало понятно, проблема не в конкретном клиенте и не в конкретном проекте, а в подходе. Я начал разбираться и быстро уперся в простую вещь - нормального технического задания у клиента в этих случаях не было. Были хотелки, обрывки мыслей, устные договоренности, примеры “как у них”, фразы “ну вы же специалисты” и ощущение, что все всё поняли. А потом начинается разработка, и в конце выясняется, что каждый представлял результат по своему. Тогда я усилил этап подготовки ТЗ. Мы стали подробнее фиксировать требования, сценарии, роли, ограничения, логику работы и ожидаемый результат. Проблема “это не то, что мы хотели” ушла. Казалось бы, вот оно решение. Но дальше появилась новая проблема - ТЗ хорошее, работа сделана, ко мне вопросов нет, потому что всё выполнено как согласовали, а результата в бизнесе нет. Сотрудники системой не пользуются, руководители не смотрят отчеты, данные заполняются криво, автоматизация вроде есть, но хаос никуда не делся. И вот тут я понял вторую важную вещь - хорошее ТЗ не спасает, если оно описывает плохой процесс. Бардак автоматизируется идеально. После этого я начал заходить глубже. Перед ТЗ стал разбирать процессы как они есть на самом деле. Не как думает собственник или руководитель, а как сотрудники реально работают каждый день. Где теряются заявки, где данные врут, где люди обходят систему, где работа дублируется в таблицах, где процесс держится на одном человеке, где автоматизация нужна, а где она просто замаскирует проблему. И только после этого появлялось нормальное ТЗ. Сначала описываю текущую ситуацию, потом смотрю хотелки заказчика, потом правим сам процесс, и только потом решаем, что именно нужно автоматизировать. Вот тогда всё начало работать. Не идеально, конечно, в бизнесе вообще редко бывает идеально, но результат стал совсем другим. Так я плавно перешел от разработки ради разработки к бизнес архитектуре. Сейчас мне намного интереснее не “сделать кнопку”, а понять, зачем эта кнопка нужна, кто будет на нее нажимать, что должно произойти после этого и какой управленческий результат получит собственник. ИИ здесь сильно усилил мою работу. Он помогает быстрее собирать прототипы, проверять логику, писать код, формулировать документы, разбирать варианты решений, но он не заменит понимание бизнеса, процесса и конечной цели. ИИ это большая машина. Если посадить за нее человека без понимания, он быстро накопает ям не там, где нужно. Моя задача теперь не копать руками, а направлять эту машину, не давать ей уходить в дебри и следить, чтобы результат был нужен бизнесу, а не просто красиво выглядел в коде. Код дешевеет. Инструментов становится больше. А понимание, что именно нужно делать, наоборот становится дороже.