Разница распределения стоимости в строительстве, машиностроении и программировании — основа для внедрения итераций

Очень часто, когда обсуждают подходы к проектированию и проектному управлению проводят аналогии со строительством или машиностроением. Не стала исключением и моя статья про аджайл https://habr.com/ru/articles/972230/ ^[1]
Конечно всякие аналогии имеют свои границы применимости, но в случае сравнения строительства и разработки ПО об этой границе забывают ^[2]. Между тем она есть и даже люди далекие и от первого и от второго быстро поймут эту разницу, если просто о ней написать.
Основная разница заключается в сравнении стоимости проектирования и создания итогового продукта. Для сравнения я также решил привести пример из машиностроения с созданием серийного продукта. Имеются фундаментальные различия экономических моделей этих отраслей в аспекте тиражирования решений и распределения стоимости по этапам жизненного цикла.
Для подкрепления ^[3] мнения некими данными я попросил нейросеть Qwen набросать примерные оценки по стоимости.

Стоимостная характеристика трех отраслей: строительство, машиностроение, разработка ПО.

Строительство: много материальных затрат на этапе производства

В строительстве классическое распределение затрат выглядит так:

• Проектирование: 5-10% от общей стоимости

• Материалы: 50-60%

• Строительно-монтажные работы: 30-40%

• Пуско-наладка и сдача: 5-10%

Физическая реальность создает “точку невозврата”. После заливки фундамента изменить его параметры практически невозможно без полного демонтажа. Каждый этап жестко зависит от предыдущего, и ошибка ^[4] на ранней стадии многократно усиливается на последующих. Тиражирование в строительстве означает создание типовых проектов, но даже при этом каждый объект уникален из-за особенностей грунта, климатических условий и инфраструктуры.

Машиностроение: баланс между разработкой и производством

Машиностроение занимает промежуточное положение:

• НИОКР и проектирование: 20-30%

• Создание прототипов и испытания: 15-25%

• Освоение производства (оснастка, станки, линии): 30-40%

• Серийное производство: 10-20% на единицу продукции

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

IT-разработка: “бесплатное” тиражирование

В IT-разработке принципиально иное распределение:

• Проектирование и анализ: 30-40%

• Разработка: 40-50%

• Тестирование и внедрение: 20-30%

• Поддержка и развитие: 15-25% годовых от стоимости разработки

Самая революционная особенность IT — практически нулевая стоимость тиражирования. Разработка программного продукта может стоить миллион долларов, но выпуск миллиона копий обойдется в несколько рублей за штуку. Это создает уникальную экономическую модель, где можно позволить себе эксперименты и итерации.

Сравнительная таблица: от проектирования до тиражирования

Почему в IT можно начинать с весьма “сырого” продукта?

В машиностроении нельзя создать мотоцикл, а потом превратить его в автомобиль. Для этого потребуется полностью перепроектировать платформу, перенастроить производственные линии, переобучить персонал. Стоимость такой “эволюции” будет сравнима со стоимостью разработки нового автомобиля с нуля.

В строительстве аналогичная ситуация. Фундамент гаража не выдержит нагрузки от многоэтажного дома. Стены сарая не станут несущими для башни. Физические законы не обойти.

Но в IT физических ограничений нет. Вы можете начать с простого веб-сайта-одностраничника, добавить базу данных и админку (MVP), интегрировать платежные системы и мобильное приложение (первая версия приложения), а затем создать распределенную облачную платформу с искусственным интеллектом ^[7]. Каждый этап строится на предыдущем, но при необходимости можно переписывать отдельные компоненты полностью без полного перезапуска проекта.

Это возможно благодаря:

1. Нулевой стоимости копирования — можно создать сотню экспериментальных версий без финансовых потерь

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

3. Быстрому циклу обратной связи — пользователи тестируют изменения в реальном времени

Стоимостные риски и их управление

Строительство: страхование через детализацию

В строительстве основной риск — физическая невозможность или чрезвычайная стоимость исправления ошибок. Поэтому:

• 80-90% рисков управляются на этапе проектирования

• Используются детальные 3D-модели и BIM-технологии

• Предусматриваются запасы прочности в конструкциях

• Стоимость изменений после начала строительства кратно превышает стоимость проектирования

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

Машиностроение: управление через прототипирование

В машиностроении риски распределены между разработкой и производством:

• Создаются физические прототипы для проверки концепций

• Проводятся ресурсные испытания в экстремальных условиях

• Используются CAD/CAM системы для виртуального моделирования

• Освоение производства идет поэтапно с постоянной доработкой

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

Разработка ПО: управление через итерации

В программировании и разработке ПО риски управляются иначе:

• Риск несоответствия требованиям минимизируется через постоянную обратную связь

• Технические риски снижаются через рефакторинг и технический долг

• Рыночные риски управляются через A/B тестирование и постепенный rollout

• Безопасность обеспечивается через непрерывное тестирование и обновления

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

Практические примеры от нейросети Qwen

Строительство: Burj Khalifa
Стоимость проектирования составила около $100 млн из общего бюджета $1.5 млрд. Изменения в процессе строительства были минимальны — любое отклонение от проекта могло привести к катастрофе. Тиражирование невозможно — это уникальный объект.

Машиностроение: Tesla Model 3
Разработка и освоение производства обошлись в $2+ млрд. Но при производстве 500,000 автомобилей в год себестоимость единицы становится конкурентоспособной. Изменения в процессе производства требуют остановки линий и перенастройки оборудования.

IT разработка: Facebook
Начинался как простой сайт для студентов Гарварда. Стоимость тиражирования для миллиарда пользователей — доли цента на пользователя в месяц. Изменения вносятся ежедневно без остановки сервиса. Первоначальная разработка стоила тысяч долларов, текущая стоимость компании — сотни миллиардов.

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

Следовательно сравнение разработки ПО со строительством некорректно именно из-за разного распределения затрат. Поэтому проектное управление в разработке ПО просто обязано опираться прежде всего на итерации и сбор обратной связи, а не на исходное ТЗ и проектные документы.

Золотая середина для IT-проектов:

1. Архитектурный фундамент – закладывайте понятную архитектуру с возможностью масштабирования, но не надо сразу ударяться в создание микросервисов и прочие архитектурные излишества https://t.me/limsaccreditation/1857 ^[8]

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

3. Управление техническим долгом – регулярный рефакторинг – это инвестиция в будущую гибкость. При этом надо пересматривать не только код, но и документацию продукта.

4. Бесплатное тиражирование — используйте преимущество нулевой стоимости копирования для быстрого тестирования гипотез и масштабирования успешных решений.

Вывод

Итерации и необходимость обратной связи в it сфере обусловлены фундаментальными причинами, связанными со стоимостью этапов проектирования и разработки. Без итеративного подхода можно впустую прожигать бюджет на никому не нужное проектирование и дальнейшую разработку продукта, которым никто не будет пользоваться.
Как написали в комментариях к мой предыдущей статье, сам Уинстон Ройс — автор термина Waterfall — в той самой статье 1970 года описывал недостатки каскадной модели, предлагая заменить их итеративной моделью. Таким образом дело не в Agile и настроениях разработчиков, итерации – это самая эффективная модель разработки с экономической точки зрения ^[9].