Некоторые замечания и размышления по поводу "Мифического человеко-месяца" Фредерика Брукса.

Эссе - это удобная отмазка, чтобы не писать большие труды.
NYQ , ИЗ ЭССЕ "ЖУЮЩИЙ БУБЛИК"

Ну и пошла же у вас, братцы, мода вставлять везде эпиграфы!
NYQ , ИЗ ЭССЕ "ЗАПИВАЮЩИЙ БУБЛИК ЧАЕМ"

Многие программисты знакомы с классическим трудом, упомянутым в заглавии этого эссе. Будучи написанным аж тридцать лет назад, в докиберкоммунистические времена, когда за машинное время брали деньги (феодалы-варвары!), будучи с некоторыми дополнениями переизданным 10 лет назад, во времена, когда только начинали наивно верить в тогда еще покрытое завесой мистики визуальное программирование (блаженны верующие!), этот труд упорно не хочет морально устаревать, несмотря на то, что он далеко не пророческий и по большому счету является дитём своего времени. Я лично люблю эту книгу за то, что к ее спокойной, выкристолизованной чистоте можно обратиться, когда плывешь в штормящем море грязи реалий современной разработки ПО. Я лично люблю эту книгу за то, что автор нейтрально описывает как различные подходы, так и собственные ошибки. Многие современные книги, претендующие на ту же роль, гораздо более апологетичны: "Се, пришел я к вам не с классическим программированием, кое сосет, но с экстремальным, да будут забанены навечно те, кто необратится!" - вот, что часто можно в них услышать. Но, как я уже сказал, МЧ-М не является ни пророческим трудом, ни священным писанием. Поэтому нам, удобно ездящим на его горбу, весьма легко и незатруднительно вставлять свои пять копеек, что сейчас и последует. В своих заметках я не претендую на новизну и скорее всего ни один человек высказывал аналогичные мысли, я просто изложил то, что было у меня на уме.

Замечание I. Архитекторы и архитектура - давайте называть вещи своими именами!

Брукс говорит: "Под архитектурой системы я понимаю полную и подробную спецификацию интерфейса пользоватея" (стр. 31 русского перевода, стр. 45 оригинала). Несомненно, каждый из нас имеет право понимать под тем или иным термином практически все, что угодно, однако не только я, но и современные словари несколько расходятся с мнением Брукса. Согласно, например, открытому энциклопедическому словарю Wikipedia, архитектура ПО есть "согласованный набор абстракций, задающий дизайн каждого аспекта всей программной системы". В коментариях поясняется, что в число "всех аспектов" входят как требования заказчика и спецификация ввода-вывода, так и логическая структура проектируемой программной системы. Как Брукс, так и остальной мир согласен с тем, что архитектор отвечает за верхний уровень разработки продукта - он является идеологом проекта. Однако по какой-то мистической причине автор МЧ-М остается вполне довольным проделанной работой архитектора, как только тот закончит общение с заказчиком по поводу того, как продукт будет выглядеть с точки зрения пользователя. Он прямо заявляет, что после того, как архитектор отработал свое, разработчики могут удовлетворять сформированные им требования десятками разных способов. Возможно во времена Брукса священные программистские войны еще не имели места, потому что спорить например о том, какой компилятор лучше, при том, что в природе есть всего один компилятор для данной машины (я утрирую), было бессмысленно, но почему-то мне кажется, что выбор был не настолько беден, а плюрализм мнений не настолько зачаточен. Из моих наблюдений сдается мне, что главная работа архитектора заключается не в том, чтобы согласовать с заказчиком эскизы пользовательского интерфейса, а в том, чтобы спустить разработчикам четкую, обладающую запасом гибкости и прочности, непротиворечивую структуру продукта и указать, каким образом и при помощи каких технологий будут реализованы составные части этой структуры и как они будут между собой общаться. Если пустить эту задачу на самотек фантазии и/или комплексов разношерстных разработчиков, то в результате получится продукт, который слеплен из этих самых фантазий и комплексов и крайне уродлив и ненадежен внутри. Я утверждаю, что каждый такой безответственно разработанный продукт будет убит либо на стадии использования при первой же нештатной ситуации, либо когда наступит пора его модернизировать и какой-то несчастный откроет крышку "согласованного пользовательского интерфейса". На самом деле требования с заказчиком может обсудить и кто-нибудь другой - например кот Мурзик, любимец коллектива. Уж очень он приятный на ощупь и мурлычет красиво! Архитектору общаться с заказчиком - терять время, как свое собственное, так и заказчика. Архитектор вообще плохо приспособлен к общению с гуманоидами - ведь он же есть технарь и таковым должен оставаться. Мне очень жаль, но на должность генерального конструктора самолетов не ставится эргономист, который набил руку в определении наиболее приятного на взгляд пассажира цвета обивки кресел. Наймите технически подкованного посредника с хорошо подвешенным языком (можем предложить нашего кота на пол-ставки). Мозги архитектора нужны не для того, чтобы ублажать заказчика сладкими речами и обещаниями, мозги архитектора нужны для того, чтобы разрулить месиво требований (и если надо, предложить заказчику рацуху) и построить структуру, которая не только их удовлетворяет, но и имеет определенный (зависит от проекта, см. следующее замечание) задел на будущее. Архитектор обязан знать, какие инструменты и технологии доступны на сегодняшний день (и уметь ими пользоваться!!!) и как с их помощью реализовать придуманную структуру - если разработчики будут дивиться, программировал ли в своей жизни тот идиот, который все это придумал - то горе такому архитектору. Далее архитектор обязан плотно работать с разработчиками, поганой метлой загоняя их отклонения обратно в спроектированную структуру. Архитектор также должен иметь право не только нещадно браковать написанный код, но и увольнять неисправимых. Более того, архитектор обязан сам программировать наиболее ответственные участки, потому что если человек разлюбил программировать, то в нем уже не будет огня, вдохновения, запала, который необходим для проектирования программных систем. У теоретиков масса другой работы, им нечего делать за столом архитектора. Без всего этого террора никогда не получить качественнный продукт. Если вы все еще думаете, что архитектура - это всего лишь "полная и подробная спецификация интерфейса пользоватея", то я уверен, вам понравится следующий пример. Мне приходилось наблюдать, как один разработчик, в силу своей генетической несовместимости с программированием, не мог спокойно жить с двоичным представлением. В результате этот уникум пересылал все целочисленные значения исключительно в текстовом виде. Потому что "так ему понятнее". Пока он это делал на полноценном настольном компьютере, на его причуды смотрели сквозь пальцы, лишь только посмеиваясь. Но когда дело дошло до того, что другим пришлось тащить за собой громоздкий сишный код функций sprintf и sscanf на двух общающихся между собой платах с весьма ограниченными по своим ресурсам процессорами, посыпались нецензурные ругательства. А все потому, что на этого чудилу не было управы в виде архитектора, который бы три раза пытался бы научить его программировать нормально, а на четвертый просто уволил. Мораль: если вы пустите на самотек то, что делается внутри продукта, то вы получите, к примеру, бортовой компютер, в котором закрылками управляет код написанный на ассемблере, в то время как элероны рулятся Java-кодом с задействованием виртуальной машины (о ужас!), причем после каждого внесенного изменения, эти две несовместимые вещи заново нужно "женить". Если вы думаете, что процесс "женитьбы" есть проявление кармы и с ним нужно мириться, то поставьте себя на место толковых программистов, которые вынужденны непосредственно заниматься этими бракосочетаниями (очень меткий каламбур!) по ночам (а как же, криворукие-то, которые наплодили все это, просто не потянут эту работу) и послушайте, как изощренно они при этом ругаются. Все эти упражнения в ненормативной словестности закончатся единственным образом - толковые ребята уволятся, а криворукие останутся, даже и не заметив ни пропажи толковых ребят, ни собственной вины или ошибки. Факт заключается в том, что программисты, если их не направлять в нужное русло, дрейфуют по воле ветра собственных предрассудков и комплексов. Не совершая интервенцию в то, что они делают, нельзя ожидать, что результаты их параллельной работы будут соответсвовать принципу "концептуальной целостности", пропагандируемой не только Бруксом, но и любым другим здравомыслящим архитектором. Брукс декларирует этот принцип, но по непонятной мне причине не хочет прилагать реальных усилий к его осуществлению. Резюмируя, повторю: архитектура - это прежде всего логическая (компонентная) структура продукта и реалистичный план создания этих компонентов, а не только требования заказчика; архитектор - это прежде всего тиран, стоящий на страже концептуальной целостности, а не только пресс-секретарь для клиента.

Замечание II. Проект проекту рознь.

Фредерик Брукс без сомнения был не в одной переделке, прежде чем сесть писать свою замечательную книгу. И действительно, его богатый опыт нашел достойное отражение в этом опусе. Он вполне реалистично смотрит на вещи, утверждая, скажем, что написать программу и программную систему - две большие разницы. Он тщательно рассматривает десятки разных видов классических ловушек, которые ожидают разработчиков. Он открыто указывает на те места, в которых ответ можно получить, только набив несколько шишек на собственном опыте. Однако что напрочь отсутствует в его книге, так это признание того факта, что не все проекты одинаковы. Отчасти этому есть оправдание - во времена написания книги не было ни коробочных продуктов, ни бедных заказчиков, ни в конец уверовавших в бескрайнюю магию хай-тека клиентов, которым позарез нужна "система учета карамелек на конвейере" буквально к завтрашнему утру. Сорок-тридцать лет назад разработка почти всех программных продуктов происходила по технологии "дайте нам немерянно бабла и терпеливо ждите три года, пока команда из пяти тысяч человек построит для вас новую модель компьютера и снабдит ее необходимыми программами". О наглых парнях, которые хотят получить решение своих проблем за $3.99 тогда никто еще не слыхивал. Но сегодня реалии изменились - невозможно давать советы о том, как писать программы и руководить их написанием, не поинтересовавшись, а что собственно пишется. Потому что заказчики, будь то непосредственные или опосредованные, сегодня варьируются от серьезных мужиков с ядерными чемоданчиками до типа пацанов с джойстиками. Давайте попробуем раскидать этот балаган по полочкам. Существует такая модель, в которой стиль работы (не важно, программиста, плотника или повара) раскладывается по трем ортогональным осям-ортам: Качество, Время, Стоимость. Так вот, спекулятивно в этой модели утверждается, что ни один супермен не может находиться в точке (1,1,1), то есть делать работу одновременно качественно, бысторо, и дешево, как любят обычно лгать в вашем отделе продаж. Также спекулятивно утверждается, что лучшее, чего можно добиться - это единицы по двум из трех осей, то есть возможно делать работу одним из трех способов:

• Медленно, но качественно и дешево
• Дорого, но качественно и быстро
• Некачественно, но дешево и быстро

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

• Быстро, но некачественно и дорого
• Дешево, но некачественно и медленно
• Качественно, но медленно и дорого

Вот тут-то и вступают в игру заказчики со своими нуждами, распределяясь по типам проектов:

• Быстрые проекты - коммерческие проекты, в которых срок поставки играет решающую роль. Обычно это либо коробочный ширпотреб, либо заказное ПО с малой алгоритмической нагрузкой для финансовых целей - каждый просроченный день означает жуткие убытки для конторы, которая к примеру играет на бирже или выпускает туалетную бумагу. Заказчики обычно чудовищно далеки от какого-либо интереса к тому, что творится внутри продукта - им хватает проблем с курсом доллара и расцветкой рулонов. Поверьте мне, парить этих ребят, к примеру, преимуществами кроссплатформенности - идея не из лучших. Если же говорить о ширпотребе, то название говорит само за себя. Вот не нужна никому троекратно избыточная система предотвращения сбоев в текстовом редакторе и все!
• Дешевые проекты - обычно это заказное ПО для маленьких клиентов. Ну нет у них денег на то, чтобы щедро оплатить не только примочку к их бухгалтерской программе, но и все эти бизнес-ужины и командировки первым классом. У них еще одна стиральная машина намедни сломалась, теперь из пяти только две работают, клиенты уходят в соседнюю прачечную, а вы тут со своими прожектами. Не парьте бедных людей!
• Качественные проекты - это те проекты, в которых начинка преобладает над экономической составляющей. Типичные примеры - это авиация, космонавтика и медицина. Это одна из причин, почему простые смертные, вроде нас, не летают на выходные на другие континенты, не проводят отпуска на орбите и не делают пластические операции только потому, что им надоела прошлогодняя форма подбородка - кто-то очень богатенький и неторопливый должен платить за качественную разработку жизненно важных систем.

Так вот, не нужно быть пророком, чтобы понять, что для успешного выживания в любой из этих трех категорий (которые кстати не дискретны, но плавно перетекают друг в друга), нужны не только совершенно различные тактики поведения, но и еще абсолютно непохожие друг на друга люди, делающие работу! Нижеследующее не является проявленим какого-либо снобизма - "все профессии нужны, все профессии важны". Аналогично и с типами проектов - для каждой реалии требуются свои меры и люди и все они заслуживают уважения за свой труд. Однако то, что они различны - никуда не денешь. Поэтому бесполезно и непродуктивно упираться рогом и требовать от коробочников, чтобы они писали каждый компонент сами, исключительно на высшем уровне качества и при этом еще и получали удовольствие. Также бесполезно и непродуктивно требовать от оборонщиков, чтобы они "заставили работать эту чертову бомбу к полудню, а не то...". И наконец, самое непродуктивное - это парить честно зарабатывающего себе на хлеб программиста-индивидуала всякими заумными архитектурами, абстракциям и тонкостями эстетического восприятия изящных программных конструкций. Просто смиритесь с тем, что те идеалы, под которыми вы лично подписываетесь, будь то качество, скорость или стоимость - не универсальны и далеко не всем нужны. Чем нервничать, гораздо легче найти ту нишу, где вы будете поняты. Например, я не умею программировать быстро и дешево. Ну не умею и все. Могу конечно на одном дыхании сваять какую-нибудь утилиту, но на большой продукт у меня дыхалки не хватит в таком темпе, чтобы не останавливаться и не истязать себя, как можно сделать качественней. Поэтому я со спокойной душой работаю медленно и не очень беспокоюсь по поводу того, во сколько я обхожусь конторе. Поэтому я не делаю звездных коробочных продуктов и не работаю на финансовую сферу - пусть этим занимаются ребята, которые в этом деле более талантливы, чем я. Иными словами, нельзя дать всем архитекторам и программистам единый совет по поводу организации труда и технологии производства. Нужно обязательно диффиренциировать по специфике проекта. Вот что получается, если обобщить взаимоотношения архитектуры и этой самой специфики:

• Дешевые проекты - не нужно туманить мозги никакими архитектурами. Ценность вашей работы в том, чтобы прачечная снова работала и зарабатывала живые деньги, из которых будет оплачен и ваш честный труд.
• Быстрые проекты - занимайтесь архитектурой, резьбой по моржовой кости и даже гжелью, но ровно до тех пор, пока укладываетесь в сроки, ведь все равно продукт скорее всего будет выброшен, когда он породит нужное количество прибыли.
• Качественные проекты - уделяйте вопросам архитектуры и качества больше времени, чем собственно разработке, иначе вы преступным образом выкините на ветер деньги заказчика. И прекратите мнить из себя спецназ программирования!

Для каждой из этих категорий существуют свои пропорции, в которых следует разбивать проектное время на виды деятельности, а не единая на всех и вся схема "треть-шестая-четверть-четверть", пропагандируемая Бруксом (стр. 18 русского перевода, стр. 20 оригинала).

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

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

Замечание III. Эта мифическая операционная бригада.

Это самый комичный пункт моего эссе. Напомню, что Брукс, основываясь на опыте Эриксона, Сакмана и Гранта, продвигает (стр. 23-27 русского перевода, стр. 29-35 оригинала) идею Миллза о том, что наиболее эффективно разработка ПО организуется, если находить звездных программистов и обставлять их десятком вспомогательных сотрудников, каждый из которых является специалистом строго определенного профиля, дабы вместе они делали за него всю "черную" непрограммисткую работу, по аналогии, как медсестры держат "скальпель, зажим, тампон, спирт, еще спирт и огурец" для хирургов. Эта идея настолько замечательна, насколько она и фантастична. В принципе нет ничего плохого в стремлении мечтать. Вот например шейхи, едва родившись, уже начинают мечтать о многочисленном гареме. Но не все из них доживают до совершеннолетия - придворные интриги, знаете ли. Точно также не нужно у программиста отнимать удовольствие от фантазии, в которой он только кодирует себе на радость, а 10 человек (включая двух секретарш, по Бруксу) с готовностью точат ему карандаши, носят пиццу, пишут за них документацию, а иногда даже и комментируют неземные шедевры в его исходниках и смотрят с почитанием на ореол, который светится вокруг этого легендарного героя нашего времени. Я, знаете ли, сам не прочь повитать в облаках собственных грез. Так вот, когда вы закончите мечтать и вернетесь на эту забытую всеми планету, то приготовьтесь к порции горькой реальности - ни у каких программистов не бывает секретарш, ни двух, ни одной, ни даже половины или четверти! Звиняйте, вы не по адресу обратились, вам нужно было в важные руководители идти с такими амбициями, а мы тут уголь долбим в шахте. На деле в 95% случаев получается, что именно программист точит карандаши, читает стандарты и законы, говорит с клиентами, кормит кота Мурзика и прочищает унитаз, прежде чем заняться своими непосредственными обязанностями - вытаскиванием зажеванного листа бумаги из принтера в соседнем отделе. В принципе нет ничего зазорного и порочного в том, чтобы освобождать программиста от работы не по специальности - в конце концов каждый должен заниматься своим делом. Проблема в том, что вы рискуете досрочно завершить жизнь высшего руководства от острого приступа смеха, когда будете пытаться объяснить, что одного программиста должен обслуживать коллектив, больший по своему числу, чем коллектив, который обслуживает это самое (часто очень самовлюбленное) высшее руководство. Идея слишком радикальна, чтобы ее всерьез воспринимали карлы марксы и фридрихи энгельсы вашей конторы. Да и честно говоря, я не думаю, что код, написанный таким образом, способен окупить зарплату десяти дополнительных человек. В дополнение к этому, не следует забывать о пункте два, где говорилось, что проект проекту рознь. Чем более качественный и дорогой продукт вы хотите получить, тем больше людей нужно выставлять на подмогу программисту. Рецепт "дайте пану 10 душ прислуги" не только не универсален, но и способен привести к таким последствиям, как банкротство коробочной конторы или потеря связи с реальностью у программиста-индивидуала. По моему скромному разумению, размер бригады не только должен варьироваться в зависимости от специфики проекта, как я указал одним предложением выше, но еще и его качественному составу следует быть несколько иным. Дело вот в чем. Согласно Бруксу, у хирурга в подчинении есть один "второй пилот" - единственный человек, который умеет программировать во всей бригаде, кроме самого хирурга. Понятно, что помимо разработки продукта, хирург еще и должен учить это подмастерье на будущего хирурга, иначе откуда будут у нас браться новые сияющие лучезарным ореолом герои-одиночки? К сожалению, не все ученики становятся рыцарями-Джедаями и отсекают пакши мужикам с черным ведром на голове, спасая таким образом светлое будущее Галлактики и всех ее IT-контор. Поэтому мое предложение таково - гораздо продуктивнее, и с точки зрения работы и с точки зрения воспитания подрастающего поколения, иметь более одного непосредственного работника на каждого мастера-прораба. Вообще мне кажется, что аналогия со строительством тут более уместна - разработка ПО есть скорее кропотливое строительство с элементами изобратательства, нежели точно выверенное кратковременное оперативное вмешательство. В зависимости от потребностей и специфики проекта, такой прораб, являясь также линейным архитектором, рулит командой из 3-10 программистов-исполнителей (плюс таким количеством спецов других направлений, которое он может занять на полную ставку), при этом сам (в обязательном порядке) непосредственно занимаясь программистскими работами, которые требуют особого мастерства. Таким образом талантливый мастер освобождается от большей части рутинного кодирования, что позволяет надеяться, что он не только не возненавидит программирование, но и не захлебнется и не поступится качеством, когда прессинг внешних обстоятельств будет штурмовать команду. Такой мастер не только сможет учить своих подчиненных ремеслу программирования, но еще и отсеивать из команды необучаемых и добавлять новые таланты, причем право нанимать (в пределах бюджета, естественно) и увольнять (в пределах гуманности и реалий рынка труда) должно быть только и только у мастера, а ни у каких-либо начальников отделов и прочих важных персон. Обучать же одного человека, как рекомендует Брукс, так же расточительно, как и нанимать для учителя-гуру десяток обслуги. Что еще нужно отметить, так это то, что администрация обязана воспринимать голос даже одного мастера очень серьезно. Я говорю о том, что часть специалистов будет совместно использоваться несколькими бригадами - это к примеру консультанты по законодательству и контрактному праву, адвокаты, патентоведы, специалисты по области приложения, эргономисты, художники и прочие специфические работники, не находящиеся в прямом подчинении бригадира потому что ему нечем занять их все рабочее время. Если мастер говорит руководству, что он не получает четких ответов или адекватных услуг от своего внешнего по отношению к бригаде консультанта (который, повторюсь, не является подчиненным мастера!), то руководство обязано делать что-то с этим консультантом, потому что из-за него одного вся бригада работает вхолостую. Далее. Что если нужна работа над очень большим проектом? Я не буду вводить читателей в заблуждение, притворяясь, что мне известна панацея, способная развязать нелинейно растущий клубок накладных расходов, как материальных, так и управленческих. Книга Брукса в этом случае является более адекватным чтивом, нежели слепленное мною за несколько часов эссе, ибо там очень подробно и на основе обширного опыта описываются рецепты вертикальной интеграции и масштабирования команд разработчиков. Единственное, что хотелось бы озвучить мне лично, так это то, что вне зависимости от методов масштабирования, использовать не очень адекватный строительный материал, а именно мифическую операционную бригаду, не есть продуктивная тактика. Именно поэтому я и предлагаю, как мне кажется, более приемлимый для сегодняшних реалий кирпичик - бригады под управлением мастер-архитекторов. Если все же попытаться посмотреть на то, как такие бригады поддаются масштабированию в рамках больших проектов, требующим нескольких бригад, то получается следующее: над линейными мастерами-архитекторами ставится архитектор более высокого уровня, для которого все мастера являются такими же линейными работниками, как для мастера - его программисты-ученики. При этом каждой бригаде необходимо выдавать максимально изолированный участок работы (и да, я не на словах, а на деле знаю, как нелегко иногда изолировать участки, но тут все зависит именно от качества архитектуры), а последующую интеграцию участков производить исключительно силами вышестоящего архитектора (вот где ему найдется обязательная работа программистом) и подчененной ему бригаде, только уже мастеров. При необходимости данную структуру можно продолжать ввысь на некоторое разумное число уровней (у меня нет соответстующего опыта, чтобы утверждать, есть ли предел такому росту и каков он). Карьерное продвижение ввысь по этой лестнице должно на 80% процентов определяться архитекторскими способностями человека и на 20% - организаторским (сюда не включается харизма учителя, при помощи которой он должен уметь повести за собой учеников - она просто обязательна), потому что мы не хотим построить человеконенавистнические взаимоотношения начальник-на-гольфплощадке-подчиненный-в-кубике, мы хотим построить строгие, но гуманные и честные отношения учитель-ученик, а для этого абсолютно необходимо, чтобы ученики на деле видели проявления способностей учителя как подтверждение его авторитета, а не под страхом увольнения подчинялись поставленному над ними функционеру, который "даже не понимает, чем мы тут занимаемся и какие проблемы решаем, пока он там сидит на троне". Ментальности учителя и ученика должны совпадать, чтобы они могли работать в унисон - они оба должны являться технарями одного пошиба, которым интересно быть друг с другом. По этой причине необходимы две вещи - во-первых, из этой лестницы нужно на самых ранних этапах отсеивать людей с непомерными или даже президенсткими амбициями ("мне плевать, что я буду делать, лишь бы это было повыше на служебной лестнице"), четко проговаривая программистам и линейным архитекторам, что они никогда в этой конторе не поднимутся выше должности главного архитектора, потому что выше этой должности талантливым технарям и даже технарям-гениям делать нечего, а во-вторых, ввиду того, что на огранизаторские способности мы отвели 20%, в обязательном порядке к мастерам нужно приставлять микроэкономистов-консультантов по бюджету, которые будут адвокатами, но в тоже время и советниками при получении и расходовании денег. Такой консультант может делиться советом с десятком мастеров, но при этом он должен иметь идеологическую независимость от руководства, дабы мастера не рассматривали его как шпиона или ревизора и не занимались порочной практикой укрывательства, которая приводит к показухе, театру и в конечном итоге непродуктивности и банкротству. И еще одна рекомендация - дабы исключить гниение талантов, администрация должна обеспечить мастеру право на веское слово в пользу создания новой бригады на основе подчиненного ему таланта. Таким и только таким образом можно разрулить ситуацию, в которой начальник гнобит и прячет (или вообще ездит на горбу) превосходящего его по талантам подчиненного только потому, что тот угрожает его выстраданной начальственной должности. Таланты нужно использовать, а не губить, и тут полная изоляция от начальника, в которого уперся этот талант, а ни какие не "равноправные сотрудничества", "неофициальные партнерства" и "широкая свобода действий", есть единственный выход, потому что все эти мифические сотрудничества, партнерства и свободы приводят только к безответственности, политическим и карьерным играм, конфликтам и неудовлетворенности всех сторон. Если ты достаточно крут, то для твоего мастера должна быть создана благоприятная атмосфера, в которой он скажет администрации - вот этот парень очень хорош, он потянет бригаду сам, сделайте для него бригаду или, если не можете сделать ее сейчас, правдиво скажите мне, сколько ему еще терпеть, пока он ее не получит.

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

• Заставлять программистов одеваться определенным образом - мои рваные джинсы и длинная майка никак отрицательно не влияют на результаты труда (наоборот, они влияют положительно, так как я чувствую себя комфортно и думаю лучше).
• Заставлять их приходить и уходить с работы в строго определенное время - у нас тут не конвейер и не торговая точка, так что если человек поспит лишний час после ночи программирования или не будет вынужден ходить к начальнику на поклон, чтобы "отпроситься к врачу", то всем нам от этого только лучше.
• Просматривать их почту и сетевые логи - во-первых, нанимают работника для получения результата (вот и спрашивайте с него по результатам), а не для того, чтобы он восемь часов подряд изображал вид бурной деятельности, вместо того, чтобы честно сделать свою работу и полазить по интернету или рубануться в халф-лайф, а во-вторых, если вы так боитесь, что он ищет себе альтернативное место работы, то лучше вам не тратить силы на тщетные попытки изолировать его железным зановесом от остального мира (он сходит на monster.com и без вас из дому, да еще и посмеется над вами), а почесать собственную репу в раздумьях, как сделать так, чтобы к нам шли, а не от нас уходили. Заниматься взамным самообманом - это крайне непродуктивная тактика. Оставьте этот маразм исчезающему виду - диктаторам.
• Заставлять их общаться с клиентами или пользователями - помните, что для этих целей мы можем вам предложить на пол-ставки специально обученного, пушистого на ощупь и приятного на вид кота Мурзика!

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

Замечание IV. Уф, всех организовали и построили. А программить-то как?