Главная / Статьи / Системы качества / Конвейерное производство заказного ПО и система качества / Часть 1. Конвейер – предпосылка для создания системы качества

Часть 1. Конвейер – предпосылка для создания системы качества


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

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

Еще более занимательными сегодня представляются попытки превратить в технологию телефонию 20-30-ых годов нынешнего (еще 20-ого) столетия. “Технология” подбора девушек-телефонисток по психологическим и эргономическим тестам (с применением идей великого Фрейда!), “технология” движений рук при втыкании штекера в гнездо, толстые тома инструкций, которые “регламентировали” ответы на шутки телефонных хулиганов и прочие чудеса инженерного гения. Технология не получилась до тех пор, пока не был изобретен электромеханический шаговый искатель.

Попытки фирмы ЕМЕ превратить в технологию “традиционную” технику разработки программ в группах программистов (которую мы “с высоты” нынешнего уровня развития называем кустарной) никогда не прекращались и до 1998 года были сколь упорными, столь и безуспешными. “Ты, Иван Иваныч, будешь разрабатывать только отчеты, а ты, Петр Петрович, будешь заниматься только бухгалтерией”. Попытки такого рода можно сравнить с бессмертным Крыловским: “Ты, Мишенька, садись против альта, а я, пожалуй, сяду против вторы…”.

Еще одна организационная структура, которую фирма ЕМЕ прошла на пути к конвейеру называлась (отчасти в шутку) “Живительная сила”. Основная идея “живительной силы” заключалась в предоставлении максимальной организационной свободы руководителю группы программистов. По существу, руководитель группы становился самостоятельным (в какой-то мере) предпринимателем. Он участвовал в переговорах, определял стоимость работ, формировал техническое задание, брал на работу программистов, начислял их и свою заработную плату и так далее. Фонд заработной платы определялся бюджетом проекта, так что руководитель мог платить себе очень большую зарплату при условии высокой эффективности работы группы. Название “живительная сила” означало, что под “живительными лучами”, то есть деньгами заказчиков, будут вырастать хорошие группы и отмирать плохие, задача руководства - только осуществлять отбор. Независимость руководителя должна была обеспечить свободу его организационных решений – что лучше делать, поручать работу малому числу дорогих профессионалов или большому числу неопытных новичков, поручать один проект одному-двум программистам или делить все работы на всех членов группы и так далее.

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

Также как и в классических случаях из истории технологии, переход к конвейеру на фирме ЕМЕ связан с серьезным техническим нововведением (можно сказать изобретением). В 1998 году был разработан новый интерфейс системы управления базами данных. Он ориентирован на Windows-95/98/NT и называется “Трехслойный пользовательский интерфейс”. Детальное описание возможностей этой конструкции не входит в задачу данной статьи, лишь одна существенная деталь будет нас интересовать. Конструкция интерфейса предлагает обширные возможности для визуального конструирования диалогов и отчетов. Эта вещь в современных базах данных вполне привычна. Особенностью же является следующее: к каждому органу диалога (полю ввода или кнопке), а также к каждой колонке или ячейке или запросу отчета, можно привязать внешнюю программу на С++. Для этого достаточно задать имя библиотеки DLL и точку входа в этой библиотеке.

Эта особенность сама по себе разрешает фундаментальное противоречие: желание объединить визуальное конструирование с применением компилируемого кода. Высокое качество программного изделия не может быть достигнуто с применением интерпретируемого (то есть не компилируемого) программного кода. С другой стороны, требования открытости, гибкости и быстроты программирования легче всего достигнуть, применяя визуальные средства конструирования систем. (Автор отдает себе отчет в спорности данного тезиса, поэтому можно рассматривать его лишь как мнение.)

Совместив, таким образом, в единой конструкции визуальное и низкоуровневое программирование, мы создали серьезную предпосылку для создания программистского конвейера. Стало возможным жестко организационно отделить конструирование систем (мы называем этот процесс “сборка системы”) от разработки алгоритмов на языке программирования. “Конструкторы систем” (постановщики задач) и “прикладные программисты” (те, кто собирает и внедряет готовые проекты) вообще могут не уметь программировать в общепринятом смысле этого слова.

Очевидно, что простое разделение труда еще не конвейер. Заказные проекты характерны наличием еще одного фундаментального противоречия, которое удалось разрешить фирме ЕМЕ. Это противоречие между уникальностью изделий и их функциональной насыщенностью. Нельзя разрабатывать “с нуля” проект за проектом. Это противоречит самой сути термина “технология”. “Технологичность” это “повторяемость”, это “развитие и усложнение на основе точной и дешевой повторяемости”. Технологичность в заказных проектах фирмы ЕМЕ обеспечивает Метапроект.

Мы уже говорили, что основную алгоритмическую нагрузку в системах ЕМЕ несут функции, которые подключаются к диалогам, отчетам и запросам. Эти функции при подключении к диалогу настраиваются на имена диалогов, органов диалогов, колонок отчетов, имена таблиц и полей базы данных. Таким образом, функция не ориентируется на определенный проект. Она работает с именами на русском языке. Эта система имен в совокупности составляет некую вербальную модель той части реального мира, который когда-либо автоматизировала фирма ЕМЕ. Функции накапливаются в библиотеках в качестве овеществленного интеллектуального потенциала фирмы. Множество всех таких функций в совокупности с обобщенной структурой банка данных и системой имен диалогов, печатных форм и запросов и называется “Метапроект”.

Метапроект возник по вполне объективным причинам. Когда число проектов фирмы ЕМЕ перевалило за 50, в них накопилось большое количество интересных механизмов, коммерческих и технических решений, учетных и управленческих подсистем. Демонстрируя потенциальным клиентам различные проекты, в которых эти “изюминки” были реализованы, мы обещали реализовать эти механизмы в новых проектах. На практике же, перенос программного кода из одного проекта в другой был практически невозможен.

Логические противоречия в структурах данных, расхождения в именах, в интерфейсах, приводили к тому, что перенос узлов из одного проекта в другой по стоимости был соизмерим с разработкой тех же механизмов заново.

Смотрите также…