Pull to refresh

Разработка ПО: 2. Наследство

Reading time 4 min
Views 1.3K
В предыдущей заметке был сделан вывод, что индустрия разработки ПО молода и подвержена влиянию фактора роста настолько, что рано говорить об апробированности и применимости каких-либо методик в долгосрочной перспективе, а их выбор диктуется причинами часто отличающимися от заявляемых.



Если искать аналогии в плане управления, то весьма схожем с производством ПО может показаться строительство. Мало того, менеджеров по разработке ПО нередко знакомят с управлением проектированием и строительством зданий и инженерных сооружений.

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

(В качестве иллюстрации фотография проекта А.Гауди «Sagrada Familia», степень выхода которого за сроки и бюджет до сих пор не могут даже приблизительно оценить)


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

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

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

Цели подобного материального производства и требования к продукту относительно просто задать, так как измерение материального мира достаточно устоявшаяся область. 8 этажей означает 8 этажей за очень редкими исключениями, нагрузка в 150 килограмм на метр может увеличиться до предельных 300 килограмм или среднеэксплуатационных 50 но не превратиться в десять тон на километр.

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

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

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

Мало похоже и то, как влияет на процесс бюджет. Если у нас оказывается маленький санузел или низкий потолок, это вовсе не означает что архитектор идиот или у строителя оторвался кусок рулетки. Просто это низкобюджетный проект, так как потенциальный клиент не готов платить за большее. (Часто ли вам попадались жилые здания с санузлами, в которые нельзя войти или потолком с высотой полтора метра? А сервер, который не выдержал нагрузки?).

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

Я считаю, что разработка ПО уникальная область и говорить о «схожих областях» человеческой деятельности можно лишь только лишь в целях упрощения понимания некоторых терминов, связанных со стадиями разработки и управления ей. Любое более детальное сравнение выявит скорее массу принципиальных различий, нежели возможность для проведения параллелей.

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

В следующей заметке я хочу рассмотреть, что становится основным камнем преткновения при переносе существующих каскадных методик в область разработки и оценки ПО
Tags:
Hubs:
+37
Comments 11
Comments Comments 11

Articles