Мысли, которые не удалось удержать в голове...

Фермер против индустриального рабочего в программировании

Да-да, очередной кросс-пост с персонального блога.

Все-таки как многому может научить история в самых необычных областях. Например, в разработке софта. Сегодня я хотел бы поговорить о двух стилях работы групп на примере фермера и индустриального рабочего.

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

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

Ключевыми признаками жизни фермера являлись:

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

А потом на смену фермерам пришли индустриальные рабочие. Рабочий – это по сути раб, продающий время своей жизни в розницу, по часам. Тут уж не попрохлаждаешься, даже в межсезонье. Но и ответственность уже не твоя, а менеджера. Эй, ты, чего стоишь, вон возьми эту коробку, отнеси в третий цех! И все за что ты отвечаешь – это чтобы коробка прибыла в третий цех, и то, если кто удосужится проверить. А то, что эта коробка там никому не нужна – это не твое дело. Для этого менеджер есть, чтобы думать, где какие коробки нужны. Ему за это деньги платят. Собственно, менеджмент и вырос как суррогат личной ответственности работников, когда выполняющие работу уже не отвечают и не заинтересованы в том, чтобы их работа приносила реальную пользу фирме.

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

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

Как ни смешно (или грустно, это как посмотреть), в программировании также доминируют эти два стиля – программист-фермер и программист-рабочий.

Программист-фермер отвечает за свою функциональность, свой код, и без необходимости не лезет «через межу» и не мешает соседу, если тот сам не попросит. Программист-фермер работает от зари до зари, а то и больше, когда это приносит результат – чтобы разблокировать других членов группы, выпустить продукт вовремя, срочно доделать то, что нужно было вчера. Программист-фермер может взять месяц отпуска в «межсезонье» и ожидает, что за время его отсутствия никто на его участок не навалит мусора, и вообще, без необходимости соваться не будет. А если необходимо, то будут соваться только члены его группы, те, кто уже помогал ему в работе и знают, куда сваливать мусор, а куда не надо. Более того, даже и без отпуска, он может приходить на работу попозже, уходить пораньше, когда его участие не нужно для бизнеса, и – о, ужас – егосовершенно не волнует вопрос этики и пропуска оплачиваемого времени, поскольку он не на время работает, а на результат. Вот не было бы результата – это было бы для него этической проблемой. А буква контракта с обязанностью работать не менее восьми часов в день с двумя пятнадцати-минутными перерывами на туалет – это ж бред, неужто кто-то этого не понимает? Тем более, что все равно приходится большую часть года по 10-12 часов в день вкалывать, а не 8 как в контракте прописано. Увы, некоторые не понимают. Не понимают программисты-рабочие и менеджеры подобного пролетариата от клавиатуры.

Программист рабочий – это рабочий. Он день за днем, месяц за месяцем, год за годом работает положенные ему 10-12-14 часов, которые требует индустриальная потогонная система при отсутствии профсоюзов, выполняет то, что ему сказал менеджер, и ему глубоко до лампочки, получится у менеджмента что или нет. Конечно, вслух он этого обычно не говорит, поскольку система социалистической-индустриальной пропагадны не терпит подобных высказываний вслух, тем не менее, ему действительно глубоко безразличен результат, даже если он и понимает, какой же результат ожидается. Что тоже не часто случается. Программист-рабочий имеет взгляды идеально подогнанные под взгляды его менеджера. У программиста-рабочего нет времени полежать на завалинке и повырезать узорные наличники на окна, или там проследить за состоянием старого сарая на заднем дворе. Сарай – это вообще не его забота. А наличники... Какие там наличники? Пошли вы со своими Кижами! Тут нам надо детали клепать, да побольше и побыстрее! Или там, баги править. Что, кстати, правда, багов в коде написанном программистами-рабочими хватает. Только успевай править и вносить новые. Вот и получаются опусы вроде, «Ты на два часа раньше кончил, пойди почини им вот этот баг!» - «Да, ты что??? Мне пару дней надо разобраться, что у них там и как работает!» - «А ты не разбирайся. Ты просто баг почини. Вот у тебя пара часов есть, так давай, не дури...»

Забавно, что большинство «методик разработки софта» рождались именно как ответ на чаяния менеджеров осуществить своего рода «огораживание» как в Англии, согнать программистов-фермеров с их земель и запереть в больших фабриках.

Я думаю, у читателей уже сложилось ощущение, какой стиль программирования я уважаю, а какой не очень. Подозреваю, что кто-то уже строчит злобный комментарий, насчет моей «устарелости», и вообще, что переход от феодализма к капитализму был «прогрессивным» и «более эффективным», а потому и в программировании то же самое будет, и нечего тут переть супротив прогресса… Так? Так да не так.

Да, норма эксплуатации промышленного рабочего выше чем крестьянина. А вот насчет эффектиности – это еще большой вопрос. Давайте подумаем, а что собственно оптимизировали при переходе к модели промышленных рабочих? Появлились промышленные рабочие с появлением ткацких станков и прочих машин, неизмеримо повышавших производительность труда. Машина была дорогая, приставленный к ней рабочий – дешевый. Если машина засорялась и производила хуже, медленнее или грозила сломаться – ее останавливали и чинили, чистили. Рабочий при этом простаивал, а то и вообще ничего не получал. Или проводил время у другой машины. Машина была дорогая, рабочий – дешев. С более дорогим ресурсом вы хотите делать правильные вещи. С более дешевым ресурсом – просто загрузить его до предела, если сломается, ну и фиг с ним. Вы не хотите, чтобы дорогая машина сломалась, вы готовы пожертвовать временем ее работы, чтобы она еще работала долго и эффективно. Вам все равно, если рабочий сломается, заболеет или там просто несчастен – на улице стоит очередь из таких же. Я доступно обьясняю?

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

С фермерами тоже не все так просто. Устарелая модель фермера-крестьянина базируется на том, что барон понятия не имел, когда сеять, когда собирать урожай, и вообще как и что делать. Его волновал только результат. В результате, фермер-крестьянин был не просто эксплуатируемым материалом, он был эксперт. Он имел доменное знание и лучше своего барона-менеджера знал, что и когда делать, чтобы получить результат. Вы обратили внимание, что это по сути определение «работника знания» по Дрюкеру? Коими программисты и являются, между прочим.

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

И вопрос тут прежде всего делает ли переход от программистов-фермеров к программистам-рабочим производство софта более дешевым и быстрым?

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

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

Кроме, конечно, случаев, когда к программисту-рабочему относились как к программисту-фермеру, в случае чего тот обычно заваливал свой кусок работы, что тоже трудно назвать эффективным. Но это уже дефект менеджмента – наняли не того человека. Это, кстати, указывает на еще один немаловажный момент. Разница между программистом-фермером и программистом-рабочим, а в равной мере между лидером креативных работников и менеджером индустриальных рабочих, в первую очередь не в квалификации, а в культуре. Помните, мы недавно говорили о культуре (видео здесь) и как ее тяжело менять? Во-во.