Почему хороший IT-продукт начинается не с кода

Когда разговор о новом продукте начинается с вопроса «на чём будем писать», я обычно предлагаю сделать паузу. Язык, фреймворк и список экранов понадобятся позже. Сначала важно понять, какую работу продукт должен изменить и почему это вообще стоит делать.

Код — это станок. На хорошем станке можно быстро изготовить и полезную деталь, и очень дорогую ненужную вещь. Разница не в скорости разработки, а в том, насколько точно мы увидели проблему до старта.

Сначала не функция, а неудобный день

Люди редко формулируют потребность в терминах продукта. Руководитель говорит: «Нам нужен личный кабинет». Менеджер просит «кнопку выгрузки». Собственник хочет «навести порядок». За этими фразами могут скрываться совершенно разные ситуации: заказ теряется между отделами, клиент не понимает статус, сотрудник каждый вечер сводит таблицы вручную.

Поэтому я начинаю не с перечня функций, а с обычного рабочего дня. Что происходит до проблемы? Кто замечает её первым? Куда человек идёт дальше? Что он делает в обход системы? Сколько раз одни и те же данные переписываются? Такое наблюдение звучит медленнее, чем старт разработки, но именно здесь появляется будущая ценность продукта.

Например, просьба «сделать портал для заявок» может оказаться задачей не про портал. Иногда достаточно убрать два согласования, дать исполнителю понятный статус и связать обращение с ответственным. Красивый интерфейс без этого только быстрее доставит старый беспорядок до нового экрана.

Хорошая формулировка выдерживает вопрос «что изменится»

После разговора я стараюсь записать задачу одной короткой фразой: «После запуска диспетчер видит исключения до звонка клиента», «менеджер не спрашивает склад о каждом остатке», «руководитель видит, где заказ остановился». Если такая фраза не получается, начинать разработку рано.

Она не заменяет техническое задание. Зато не даёт ему превратиться в каталог кнопок. В любой спорной точке команда может вернуться к исходной пользе и проверить: приближает ли новая функция этот результат или просто добавляет работы.

Гипотеза должна быть достаточно маленькой

Большие слова вроде «автоматизировать продажи» опасны тем, что в них помещается всё. Лучше выбрать один повторяемый участок: первое обращение, расчёт предложения, передача заказа, контроль просрочки. Для него можно честно назвать пользователя, действие и заметный признак улучшения.

Такой подход не обедняет замысел. Он делает его проверяемым. Вместо года разработки «платформы» команда за несколько недель получает ответ: новый порядок действительно снимает боль или мы красиво автоматизировали не тот шаг.

Именно здесь MVP полезен как способ учиться, а не как повод выпустить сырой продукт. Первая версия не обязана быть маленькой по числу строк. Она обязана быть небольшой по числу допущений, которые мы проверяем одновременно.

Кому и за что придётся платить

Даже внутренний продукт имеет цену. За него платят временем сотрудников, вниманием руководителей, интеграциями и последующей поддержкой. Внешний продукт добавляет ещё вопрос: кто принимает решение о покупке и какую альтернативу он выбирает сегодня — таблицу, сотрудника, конкурирующий сервис или отказ от действия.

Я бы не ждал полной финансовой модели для первого разговора. Но ответить на простые вопросы нужно: чья жизнь станет проще, что будет происходить быстрее или надёжнее, и почему это важно именно сейчас. Без этого команда измеряет активность — задачи закрыты, макеты готовы, релиз состоялся — но не понимает, нужен ли результат бизнесу.

Архитектура появляется после границ

Технологическое решение становится осмысленным, когда понятны границы первой версии. Какие данные являются источником правды? С чем обязательно нужно связаться? Где ошибка недопустима? Какие действия останутся ручными, пока это разумно? Тогда разговор про готовый сервис, собственную разработку или интеграцию становится предметным.

На странице направлений работы я описываю эту роль как соединение бизнес-задачи и технического решения. Мне важно не просто выбрать стек, а оставить компании систему, которую можно развивать без постоянного героизма.

Что сделать до первого спринта

• описать один конкретный рабочий эпизод, а не будущую платформу целиком;
• поговорить с теми, кто выполняет работу, и с теми, кто отвечает за её результат;
• зафиксировать, что будет считаться улучшением после запуска;
• отделить обязательные связи с другими системами от приятных идей «на потом»;
• выбрать самый короткий путь проверить главную гипотезу.

Код остаётся важной частью продукта. Но он должен отвечать на уже понятный вопрос, а не заменять его. Если хотите спокойно разобрать исходную задачу до сметы и списка технологий, можно связаться со мной через сайт.

Почему список требований часто маскирует неопределённость

На старте почти всегда можно собрать длинный список: кабинет, уведомления, роли, отчёты, интеграция, мобильная версия. Сам по себе он не плохой. Проблема в том, что у каждого пункта обычно нет ответа на два вопроса: что именно он меняет в работе и что случится, если отложить его на месяц. Поэтому я разделяю требования на три корзины. В первой — то, без чего нельзя проверить основную пользу. Во второй — то, что делает эту пользу удобнее или надёжнее. В третьей — хорошие идеи, которые пока не получили своего сценария.

Это не бюрократия. Такой разбор защищает команду от ситуации, когда десять разумных функций вместе не дают закончить ни одну задачу пользователя. Он также помогает честнее говорить о сроках: часть решений можно принять позже, когда появится реальное использование, а не предположение на совещании.

Нужно договориться, чему мы поверим после запуска

До разработки полезно выбрать несколько наблюдаемых признаков. Не обязательно строить сложную систему метрик. Для внутреннего процесса это могут быть время от обращения до ответа, число возвратов на уточнение, доля заказов без ручного поиска информации. Для внешнего продукта — повторное использование ключевого сценария, доля пользователей, дошедших до результата, число обращений в поддержку по одному и тому же месту.

Важно не подменять результат активностью команды. Количество выпущенных экранов, закрытых задач и проведённых встреч говорит, что работа идёт. Но не отвечает, стал ли продукт полезнее. Я предпочитаю зафиксировать исходную точку простыми словами и вернуться к ней через несколько недель после запуска.

Кого позвать в первый разговор

Один заказчик редко видит весь путь. Руководитель знает, какой итог нужен бизнесу. Сотрудник на операции видит исключения и реальные обходы. Технический специалист понимает ограничения существующих данных и интеграций. Важно дать каждому говорить о своём, а не требовать сразу готовое решение. Тогда первые противоречия становятся не конфликтом, а материалом для проектирования.

Если в компании пока нет единого ответа, это тоже ценный результат. Его лучше заметить до разработки, чем обнаружить после того, как два отдела получили разные ожидания от одного релиза. На странице проектов видно, почему результат для меня важнее набора инструментов: технология должна поддерживать согласованную работу, а не создавать новый слой разночтений.

Первый релиз должен оставлять путь назад

Полезная первая версия не обязана мгновенно выключать старый порядок. Иногда разумно запустить её на одном типе заявок, в одном отделе или с ручной проверкой результата. Это не признак слабости решения, а способ увидеть реальные данные без риска для всей операции. После такого запуска проще решить, где нужна интеграция, где — обучение, а где — изменение правила.

Хороший продукт начинается не с отказа от кода. Он начинается с дисциплины: сначала понять работу и гипотезу, затем выбрать небольшой проверяемый шаг, а уже потом строить решение, которое не стыдно поддерживать годами.