Организация товарного производства программ. Часть 3.

Рассмотрим, как соотносится с проблемами разделения труда широко известный метод бригады главного программиста (хирургической бригады). Его можно интерпретировать как децентрализацию и изменение мотивации специализированных служб. В отличие от традиционной организации исполнители вспомогательных работ здесь не руководят основным исполнителем и не равноправны с ним. В бригаде возможно интерактивное взаимодействие исполнителей, поскольку критическое звено (главный программист) защищено от нежелательных прерываний своим положением и помощниками (заместитель и администратор). Главный программист получает задания на работу и обязательные к исполнению указания только от своего руководителя — главного программиста следующего уровня. В идеале он отвечает за качество компонента также перед руководителем и заинтересован именно в качестве, а не в благополучном прохождении материалов через независимые службы контроля. Для проверки качества главный программист может обращаться к своим сотрудникам или к независимым службам при условии, что именно он будет оценивать степень существенности полученных замечаний. Может применяться также облегчающая раннее обнаружение ошибок методика «структурного просмотра». Изменение мотивации и возможности реального влияния на исполнителей представляется более существенным, чем формальное членство в бригаде, но при совместительстве узких специалистов в нескольких бригадах необходимо помнить, что чрезмерная загрузка увеличит время их отклика на запросы или даже переведет в пакетный режим взаимодействия.

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

Например, такими отношениями, при которых успехи и неудачи считаются общими и вместо упрека «опять у тебя ошибки» говорят: «теперь у нас меньше еще не обнаруженных ошибок» (такой подход называют «неэгоистичным программированием»).

Рассмотренные вопросы актуальны для любой области производства. Специфика систем ПО заключается в сочетании их беспрецедентной сложности с творческим характером многих видов работ. В каждой системе происходят нормальные энтропийные процессы, разрушительная сила которых нарастает с увеличением размеров и сложности системы. Уровень планирования и организации труда, степень удачности компромиссов между дисциплинирующим и творческим началом определяют предельный уровень сложности, при котором созидательные процессы еще доминируют над процессами разрушения. Казалось бы, надежное хранение информации не представляет особых трудностей, но попробуйте приостановить или замедлить реализацию программного проекта — прагматическая ценность промежуточных материалов будет быстро снижаться из-за модификации целей работы, нестабильности коллектива, деактуализации материалов и утери возможностей их интерпретации. Достигнутый уже в 70-е годы в программировании уровень организации коллективного творческого труда следует признать крупным достижением, оказывающим влияние и на другие области жизни.

Исторически сложившаяся терминология порождает иллюзию, что основной задачей реализации программных проектов является создание систем ПО, причем неоднократно предпринимались попытки зафиксировать эту точку зрения в регламентирующих документах. На практике большинство проектов связано не с созданием, а с сопровождением систем ПО, их совершенствованием, адаптацией к конкретным применениям. Сейчас даже при собственно разработке ПО обычно имеются исходные материалы, свойства которых оказывают решающее влияние на выбор инструментальных средств, планирование и организацию работ. В предельных, но все более частых случаях результатом программного проектирования может быть «непрограммное информационное средство». Например, получив задание на разработку автоматизированной системы управления, можно путем программных экспериментов установить, что целесообразнее провести адаптацию объекта управления к какой-то из существующих систем ПО. Результатом успешной реализации программного проекта здесь являются, конечно, не экспериментальные программы, а документы, описывающие характер и способы проведения необходимых модификаций объекта.