Очень часто, когда обсуждают подходы к проектированию и проектному управлению проводят аналогии со строительством или машиностроением. Не стала исключением и моя статья про аджайл https://habr.com/ru/articles/972230/
Конечно всякие аналогии имеют свои границы применимости, но в случае сравнения строительства и разработки ПО об этой границе забывают. Между тем она есть и даже люди далекие и от первого и от второго быстро поймут эту разницу, если просто о ней написать.
Основная разница заключается в сравнении стоимости проектирования и создания итогового продукта. Для сравнения я также решил привести пример из машиностроения с созданием серийного продукта. Имеются фундаментальные различия экономических моделей этих отраслей в аспекте тиражирования решений и распределения стоимости по этапам жизненного цикла.
Для подкрепления мнения некими данными я попросил нейросеть Qwen набросать примерные оценки по стоимости.
Стоимостная характеристика трех отраслей: строительство, машиностроение, разработка ПО.
Строительство: много материальных затрат на этапе производства
В строительстве классическое распределение затрат выглядит так:
Проектирование: 5-10% от общей стоимости
Материалы: 50-60%
Строительно-монтажные работы: 30-40%
Пуско-наладка и сдача: 5-10%
Физическая реальность создает "точку невозврата". После заливки фундамента изменить его параметры практически невозможно без полного демонтажа. Каждый этап жестко зависит от предыдущего, и ошибка на ранней стадии многократно усиливается на последующих. Тиражирование в строительстве означает создание типовых проектов, но даже при этом каждый объект уникален из-за особенностей грунта, климатических условий и инфраструктуры.
Машиностроение: баланс между разработкой и производством
Машиностроение занимает промежуточное положение:
НИОКР и проектирование: 20-30%
Создание прототипов и испытания: 15-25%
Освоение производства (оснастка, станки, линии): 30-40%
Серийное производство: 10-20% на единицу продукции
Здесь ключевой момент — амортизация разработки на количество единиц продукции. Чем больше тираж, тем ниже себестоимость единицы. Но первоначальные затраты на разработку и освоение производства огромны. Изменения после запуска серийного производства чрезвычайно затратны — часто проще разработать новую модель, чем модифицировать существующую линию.
IT-разработка: "бесплатное" тиражирование
В IT-разработке принципиально иное распределение:
Проектирование и анализ: 30-40%
Разработка: 40-50%
Тестирование и внедрение: 20-30%
Поддержка и развитие: 15-25% годовых от стоимости разработки
Самая революционная особенность IT — практически нулевая стоимость тиражирования. Разработка программного продукта может стоить миллион долларов, но выпуск миллиона копий обойдется в несколько рублей за штуку. Это создает уникальную экономическую модель, где можно позволить себе эксперименты и итерации.
Сравнительная таблица: от проектирования до тиражирования
Критерий | Строительство (Промышленный объект) | Машиностроение (Сложный агрегат) | Разработка ПО (Корпоративная система) |
|---|---|---|---|
Суть продукта | Уникальный материальный объект, привязанный к местности | Материальное изделие, которое может быть воспроизведено серийно | Виртуальный продукт (код, данные, логика), не привязанный к физическому носителю |
Доля стоимости проектирования | Относительно низкая (5-15%), основная стоимость — материалы и работы | Значительная (7-20% и более от стоимости изделия), определяет успех всего проекта | Доминирующая. Стоимость первой копии близка к стоимости всего проекта |
Экономика изменений | Экспоненциальный рост. Изменение проекта после заливки фундамента или постройке стен ведёт к убыткам и необходимости сносить и начинать заново | Высокая стоимость на этапе НИОКР, снижается с началом сери��. Изменения в серийной модели требуют перепроектирования | Линейная и управляемая. Стоимость правки зависит от архитектуры: изменение модуля умеренно, смена ядра — дорого, но возможно |
Процесс тиражирования | Фактически отсутствует. Каждый новый объект — новый проект с полным циклом изысканий, проектирования и строительства | Является целью. После дорогой стадии проектирования идут относительно дешёвые серийное производство и сборка | Развёртывание копий ПО на новых площадках (инсталляция, настройка) составляет малую долю бюджета |
Пример масштабирования | Для строительства второго здания по тому же проекту потребуется ~95% тех же затрат, что и для первого | Себестоимость 100-го серийного насоса будет на порядок ниже, чем первого опытного образца | Затраты на подключение 10-го или 10000-го пользователя к системе ничтожны по сравнению с затратами на её разработку |
Ключевой парадокс для заказчика | Дешевле семь раз отмерить (спроектировать), чем один раз перестроить | Инновационный проект (без аналогов) сложно оценить, так как не с чем сравнивать | Бесполезно требовать полное и неизменное ТЗ в начале, так как продукт должен адаптироваться к рынку |
Почему в IT можно начинать с весьма "сырого" продукта?
В машиностроении нельзя создать мотоцикл, а потом превратить его в автомобиль. Для этого потребуется полностью перепроектировать платформу, перенастроить производственные линии, переобучить персонал. Стоимость такой "эволюции" будет сравнима со стоимостью разработки нового автомобиля с нуля.
В строительстве аналогичная ситуация. Фундамент гаража не выдержит нагрузки от многоэтажного дома. Стены сарая не станут несущими для башни. Физические законы не обойти.
Но в IT физических ограничений нет. Вы можете начать с простого веб-сайта-одностраничника, добавить базу данных и админку (MVP), интегрировать платежные системы и мобильное приложение (первая версия приложения), а затем создать распределенную облачную платформу с искусственным интеллектом. Каждый этап строится на предыдущем, но при необходимости можно переписывать отдельные компоненты полностью без полного перезапуска проекта.
Это возможно благодаря:
Нулевой стоимости копирования - можно создать сотню экспериментальных версий без финансовых потерь
Модульной архитектуре - компоненты можно заменять независимо друг от друга
Быстрому циклу обратной связи - пользователи тестируют изменения в реальном времени
Стоимостные риски и их управление
Строительство: страхование через детализацию
В строительстве основной риск — физическая невозможность или чрезвычайная стоимость исправления ошибок. Поэтому:
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 проектов:
Архитектурный фундамент - закладывайте понятную архитектуру с возможностью масштабирования, но не надо сразу ударяться в создание микросервисов и прочие архитектурные излишества https://t.me/limsaccreditation/1857
Итеративное наполнение - добавляйте функции постепенно, получая обратную связь на каждом этапе. Первоначальный план при этом будет постоянно меняться, адаптироваться. Концентрируйтесь на важных и востребованных функциях.
Управление техническим долгом - регулярный рефакторинг - это инвестиция в будущую гибкость. При этом надо пересматривать не только код, но и документацию продукта.
Бесплатное тиражирование - используйте преимущество нулевой стоимости копирования для быстрого тестирования гипотез и масштабирования успешных решений.
Вывод
Итерации и необходимость обратной связи в it сфере обусловлены фундаментальными причинами, связанными со стоимостью этапов проектирования и разработки. Без итеративного подхода можно впустую прожигать бюджет на никому не нужное проектирование и дальнейшую разработку продукта, которым никто не будет пользоваться.
Как написали в комментариях к мой предыдущей статье, сам Уинстон Ройс — автор термина Waterfall — в той самой статье 1970 года описывал недостатки каскадной модели, предлагая заменить их итеративной моделью. Таким образом дело не в Agile и настроениях разработчиков, итерации - это самая эффективная модель разработки с экономической точки зрения.
