Как не потратить месяцы на автоматизацию, которая не окупится?
«Слушай, у меня есть идея для нового инструмента. Он сэкономит мне море времени».
Такую фразу я слышу примерно раз в месяц – от людей умных, внимательных и искренне уставших от рутинных задач. Они воодушевлены, уверены в пользе идеи и уже мысленно работают с новой автоматизацией.
Один из этих разговоров произошел с ревитчиком в моей прошлой компании. Его мечтой был инструмент, который автоматически отображал бы наклонные колонны в графических ведомостях – то, что Revit до сих пор не делает нативно. Каждый раз, когда проект включал наклонные элементы в железобетонной конструкции, ему приходилось вручную обходить ограничения программы. Годы раздражения сделали свое дело, и он был уверен: такая автоматизация точно стоит того.
«И сколько времени это тебе экономит?» – спросил я.
«Ох… очень много. Я на этом застреваю постоянно».
Мы вместе открыли шаблон проектного устава и начали заполнять. Спустя 15 минут мы оба смотрели на появившиеся цифры.
Разработка инструмента заняла бы около 6–8 недель. Применялся бы он только к проектам железобетонных конструкций с наклонными колоннами – примерно 15% от всего проектного объёма компании. И даже там ручной обход занимал всего пару часов. Окупаемость? Где-то за пределами 18 месяцев. Возможно, никогда – если изменится типовая структура проектов.
Мы отказались от этой идеи.
Почему «отличные идеи» часто оказываются провальными
Инженер, по сути, был прав:
инструмент действительно бы ускорил работу, снизил количество ошибок и избавил от рутины.
Но «полезно» еще не означает «выгодно».
И именно на этом уровне большинство проектов автоматизации рушатся – не из-за плохого кода, а из-за того, что никто не задал неприятных вопросов на старте.
Устав проекта многие считают бюрократией, чем-то громоздким и тормозящим инновации. Но на самом деле грамотный устав – это не формальность. Это фильтр, который заставляет оценить реальность до того, как вы закопаетесь в разработку на десятки часов.
А с ИИ создание устава – дело 20-30 минут.
Документ, который защищает вас от бессмысленной работы
Со временем я довел свой шаблон проектного устава до девяти ключевых разделов.
Никаких «формальных заполнителей». Каждая секция отвечает на вопрос о жизнеспособности проекта.
Разберем последовательно.
1. Краткое резюме
В нескольких предложениях нужно сформулировать:
- что вы хотите разработать
- какую задачу это решает
Если на этом этапе формулировка плавает, – значит, идея еще не созрела.
2. Цели и метрики проекта
Именно здесь обычно исчезает аргумент «сэкономит много времени».
Цель должна быть сформулирована по SMART.
Например:
«Сократить время аннотации наклонных колонн с 30 до 5 минут на проект».
Важно заранее определить, по каким метрикам вы будете мерить успех.
Нет метрики – нет повода говорить об эффективности.
3. Обоснование
На этом шаге нужно очень детально описать текущую реальность:
- как часто возникает задача
- кого она затрагивает
- насколько критичны последствия
- что будет, если все оставить как есть
Именно здесь мой коллега понял, что «делаю два раза в месяц» – не аргумент для разработки инструмента на несколько недель.
4. Выгоды, затраты, ROI
Далее – честная математика.
Оцените выгоды: экономия времени, снижение ошибок, уменьшение риска.
Оцените затраты через условные категории:
- S – 2 недели разработки
- M – месяц
- L – полгода
- XL – год и более
Теперь сопоставьте:
Если инструмент экономит 50 минут в месяц, а на разработку нужно 160 часов, то окупаемость – 192 месяца, или 16 лет.
После таких расчетов «куча времени» внезапно выглядит иначе.
5. Область работ и ограничения
Не менее важно четко определить:
- что инструмент делает
- чего он точно не делает
Так вы защищаете проект от потери фокуса и хаотичных ожиданий.
6. Ожидаемые результаты
Здесь нужно конкретизировать – что именно вы создаёте:
- UI-макеты
- Revit-плагин
- Dynamo-скрипт
- API-интеграция
Чем точнее список, тем меньше путаницы.
7. Команда проекта
Определите:
- кто будет разработчиком
- кто принимает ключевые решения
- кто отвечает за корректировки
8. План внедрения
Новый инструмент – это не только код.
Нужны:
Если инструмент никто не использует, ROI – превращается в бесконечность.
9. Макеты и прототипы
Даже набросок на бумаге помогает увидеть UX и заранее поймать ошибки.
Что показал устав проекта
Когда мы заполнили устав для инструмента наклонных колонн, получилась следующая картина:
Цели
Сократить время с 90 до 5 минут.
Обоснование
Только 2 проекта в месяц.
Процесс медленный, но рабочий.
Риски минимальные.
Экономика
- Экономия: 50 минут в месяц
- Стоимость разработки: ~160 часов
- Окупаемость: 16 лет
Устав не «убил» проект.
Его убили цифры.
Документ лишь заставил это увидеть.
Три ключевых вывода
1. Новичкам в автоматизации
Не бросайтесь в код с головой.
Сначала – расчеты. Потом – решение.
2. Опытным разработчикам
Вы знаете, как разрабатывать инструменты.
Теперь важно научиться понимать, какие инструменты разрабатывать – не стоит .
Устав – ваш способ защитить себя от ненужной работы.
3. Руководителям
Требуйте уставы.
Не как бюрократию, а как фильтр.
Проекты, которые проваливаются на этапе устава, провалятся и в разработке и в применении.
Реальная победа
Мы отказались от инструмента автоматизации для наклонных колонн.
Но через полгода техник пришел с другой идеей – автоматизацией фундаментов.
Мы снова прошли через устав.
На этот раз цифры сошлись.
Инструмент был создан, внедрен, и к моему уходу из компании уже окупился дважды.
Устав не только спас нас от ненужной разработки – он дал способ уверенно различать стоящие проекты. А это ценнее любой «экономии времени».
