Несколько лет назад я прочитал книгу Артёма Крылова «Дедлайнер. Как все успеть и выжить в условиях цейтнота». Формально это книга про управление делами и временем. Но для меня она оказалась книгой про другое: как вести большой проект, где нельзя махнуть рукой на детали, потерять задачи, забыть договорённости и надеяться, что команда “как-нибудь сама разберётся”.

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

Мы применили подход из «Дедлайнера» в разработке собственного программного обеспечения. В течение трёх лет небольшой командой примерно из пяти человек мы создавали all-in-one платформу для бизнеса. Бюджет разработки составил около $500 000. По нашей оценке, если бы такой продукт делался в более хаотичной модели, с постоянными переделками и слабой подготовкой задач, он мог бы стоить около $1 млн или больше.

То есть мы сделали продукт примерно в два раза дешевле потенциальной рыночной стоимости разработки.

Речь идёт о полноценной платформе для управления бизнесом: CRM, управление проектами, задачи, календари, склад, подрядчики, контент, почта, интеграции с мессенджерами, телефонией и BPMN-автоматизация на базе Camunda. По сути, это конструктор рабочего пространства компании, где можно собрать систему под продажи, проекты, операционные процессы и сложные бизнес-процессы.

Я управлял этим проектом как product manager и project manager одновременно: отвечал за продуктовую логику, приоритеты, постановку задач, декомпозицию, контроль разработки и движение всей команды.

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

В разработке сложного SaaS-продукта всё работает ровно так же.

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

После прочтения книги я стал смотреть на разработку как на систему фиксации, декомпозиции и последовательного исполнения. Сначала мы должны были превратить хаотичную идею продукта в понятную карту действий. И уже потом отдавать задачи разработчикам.

Самая дорогая ошибка в разработке — начинать писать код, когда ещё непонятно, что именно должно быть сделано.

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

Мы старались работать иначе.

Перед тем как задача попадала в разработку, она проходила несколько уровней подготовки.

Разработчик не получал задачу в стиле “сделать модуль проектов” или “добавить CRM”. Он получал конкретное описание: какие сущности есть, как они связаны, что происходит при действии пользователя, какие есть ограничения, какие автоматические события запускаются, какие роли имеют доступ, какие состояния должны быть учтены.

Это сильно меняло экономику разработки. Мы не покупали часы хаоса. Мы покупали часы реализации.

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

Во многих IT-проектах команда технически готова работать, но продуктовая часть постоянно отстаёт. Разработчик закрывает задачу и спрашивает: “Что дальше?” Начинается срочное планирование, созвоны, уточнения, обсуждения, пересборка приоритетов. Деньги идут, команда ждёт, темп падает.

Мы старались, чтобы к моменту активной разработки у команды уже был подготовленный backlog на месяцы вперёд. Это был не список фантазий, а набор описанных и декомпозированных задач.

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

План, конечно, менялся. В живом продукте это нормально. Но изменения вносились в систему, а не в пустоту. Это важная разница.

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

Хороший пример — CRM-модуль. Его нельзя поставить разработчику одной фразой “сделать сделки”. Для разработчика такая постановка бесполезна: непонятно, какие сущности нужны, как они связаны, какие сценарии должны работать и где границы задачи.

Поэтому перед разработкой мы раскладывали модуль на конкретные проектные вопросы.

Такой подход занимал время до разработки, зато экономил время во время разработки. Разработчик работал не с туманной идеей, а с подготовленной логикой.

All-in-one платформа — это огромная задача. Если смотреть на неё целиком, она выглядит почти неподъёмной: CRM, проекты, задачи, склад, календарь, интеграции, почта, телефония, мессенджеры, роли, права, отчёты, BPMN, интерфейсы, настройки, уведомления, тестирование, баги, релизы.

Такой продукт невозможно “просто сделать”. Его можно только разложить.

Мы превращали большую цель в маршрут:
Идея продукта → функциональный блок → пользовательский сценарий → требование → техническое задание → задача → подзадача → оценка в часах → исполнитель → разработка → тестирование → исправление → релиз

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

Например, “сделать BPMN-автоматизацию” — это слишком крупная и абстрактная формулировка. Для работы её нужно разобрать: какие процессы пользователь сможет запускать, какие события будут стартовыми, какие роли участвуют, какие условия возможны, какие статусы фиксируются, как система обрабатывает ошибки, как это связано с CRM и задачами.

После такой декомпозиции большая и страшная задача превращается в набор нормальных рабочих задач.

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

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

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

Разработчик должен был писать код, а не угадывать бизнес-логику. Продуктовая и проектная работа заключалась в том, чтобы максимально снять неопределённость до того, как задача попадёт в разработку.

Это позволило небольшой команде сделать продукт, который в другой модели мог бы потребовать гораздо большего бюджета.

В разработке деньги исчезают не только в зарплатной ведомости. Чаще всего они сгорают в неопределённости.

Мы не избежали всех ошибок. Это невозможно в реальной разработке. Были баги, переделки, спорные решения, технические ограничения. Но мы избежали главной проблемы — системного хаоса.

Именно это помогло удержать бюджет примерно на уровне $500 000.

В итоге мы вывели на рынок полноценную all-in-one платформу для управления бизнесом. Сейчас в ней работают пользователи, а продукт продолжает развиваться.

В системе есть CRM, управление проектами, задачи, календари, склад, работа с подрядчиками, управление контентом, интеграции с почтой, мессенджерами, телефонией и автоматизация процессов.

Отдельно стоит отметить BPMN-автоматизацию на базе
Camunda. В большинстве CRM автоматизация часто работает по простой логике: если произошло событие А, выполнить действие Б. Но реальные бизнес-процессы намного сложнее: условия, роли, согласования, ожидания, параллельные ветки, возвраты назад, исключения, контроль сроков.

Camunda позволила нам добавить в продукт возможность проектировать более сложные процессы. Это приблизило платформу к уровню конструктора бизнес-процессов, а не обычной CRM с простыми триггерами.

Один из моих главных уроков за три года разработки: думать прямо в коде слишком дорого.

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

Гораздо дешевле думать до кода.

До кода можно спорить, менять схему, переписывать описание, уточнять сценарий, удалять лишнее, переставлять приоритеты. Всё это стоит дешевле, чем переделывать уже написанную систему.

Для нас разработка начиналась не с программиста, а с подготовленной задачи. Программист подключался тогда, когда было понятно, что именно нужно реализовать и зачем.

Если перевести идеи книги на язык разработки, получилась такая схема:

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

Если вы делаете SaaS, CRM, ERP, платформу, маркетплейс, личный кабинет или любой другой сложный IT-продукт, не начинайте с поиска программиста как с единственного решения проблемы.

Сначала создайте систему постановки задач.

Опишите функциональность. Разберите сценарии. Зафиксируйте требования. Подготовьте ТЗ. Разложите всё на задачи. Оцените объём. Определите исполнителей. Постройте backlog. И уже потом запускайте разработку.

В нашем случае рабочий контур выглядел так:

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

За три года мы небольшой командой разработали сложное программное обеспечение с бюджетом около $500 000. По нашей оценке, аналогичная разработка в более хаотичной модели могла бы стоить примерно в два раза дороже.

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

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

Когда это есть, команда работает быстрее, спокойнее и дешевле.

Когда этого нет, код становится местом, где компания оплачивает собственный хаос.