Pull to refresh

Восход разработчикономики (окончание)

Reading time 9 min
Views 22K
Original author: Венкатеш Рао
(начало статьи здесь)

Управление рисками при инвестировании в программистские таланты


С другой стороны — этот эффект не имеет названия; возможно, его следовало бы именовать «десятикрадничеством» — плохие разработчики будут стоить вам отнюдь не незначительного ухудшения производительности труда. Нет, по целому ряду трудноуловимых причин они способны катастрофически саботировать сложную программную систему. Плохим разработчиком, построившим угрожающе полную ошибок или из рук вон плохо спроектированную систему, в её основание заложена тикающая бомба замедленного действия, и чтобы разгрести руины после того, как она рванёт, потребуются вложения, тысячекратно превосходящие сэкономленное на старте. Хуже того, работа по разбору завалов потребует привлечения усилий гораздо большего количества хороших разработчиков, и на более длительное время.

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

Вызванный «проблемой 2000 года» кризис не был порождением плохого проектирования; его причиной было проектирование прагматичное — что называется, «средней руки». Теперь представьте себе, во что обойдётся починка — на протяжении десятков лет — по-настоящему плохо спроектированных ключевых узлов сегодняшних программных систем. Хуже того, представьте себе, что могут натворить талантливые «десятикратники», перешедшие на Тёмную Сторону (то есть сознательно ставшие «стокрадниками»). Или хорошие парни, оставляющие «чёрные ходы» в разработанных ими системах как страховой полис на случай, если ОАО НПП „ХХХ“ не оплатило разработку этого приложения.

В итоге инвестирование в разработчиков как капитал не заключается всего лишь в найме программистов и последующей сортировке их по уровню таланта. Секрет — в их сортировке и распределении по уровням риска.

Традиционно, когда речь заходит о человеческом капитале, управляющие попросту не задумываются об управлении рисками. Даже если они думают о нём не как о традиционном ресурсе, то в лучшем случае — в терминах твёрдой цены на единицу прибыли. Типичный менеджер по найму будет разговаривать с вами фразами вроде «стоимость найма на эту позицию эквивалентна шести месяцам предлагаемой вами заработной платы».

Такая бухгалтерская логика попросту не работает в отношении программистов.

Но софтверные компании думают по-другому. Они вполне управляются с сортировкой по уровням таланта и риска — как на уровне индустрии в целом, так и на уровнях индивидуальных карьер, — а не на уровне трудовых отношений. Как же им это удаётся?

Жизненный цикл программистского таланта


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

Затем они удерживают таланты на своём крючке при помощи соревнований, усовершенствованных видов практикумов (типа Google Summer of Code) и прочих механизмов «занятости, но не совсем работы» на всём протяжении обучения в колледже. Далее компании нанимают большинство из них, наблюдают за их производительностью, и сортируют таланты по уровням потенциальной окупаемости и риска.

Конечно, они должны не забывать предлагать великолепные бесплатные буфеты; кроме того, им необходимо предусмотреть соответствующие механизмы для страховки от некомпетентности — чтобы удерживать под контролем хаос, который способны устроить плохие программисты. Они должны вкладываться в технологии (скажем, как Google в Python) с прицелом на таланты, а не на рынок.

Отношения не прекращаются даже когда прекращается трудоустройство. Талантливые программисты настолько ценны, что вы просто вынуждены организовывать открытые экосистемы (основанные на API, доступе к источникам ценной информации вроде картографических данных, и элементах открытых исходных кодов), чтобы сохранить их в своей технологической вселенной даже после их ухода от вас. Бывший программист Microsoft будет по-прежнему ценен для этой компании — если он будет повсюду продвигать мысль, что «надо бы нам приобрести продукты Microsoft».

По мере того, как разработчик матереет, ему становится всё труднее и труднее переключаться с одной технологии на другую — и в какой-то момент он останется «подсевшим» на одну из них — скажем, Java, С++ или Facebook API — на всю оставшуюся жизнь; тогда можно ожидать, что с ней он и состарится. Когда эта технология достигнет своей зрелости, ценность «сидящего» на ней таланта начнёт понижаться — равно как и стоимость его удержания. Буфеты станут победнее, вознаграждение за труд усохнет, отток персонала снизится, и талант уйдёт в закат вместе с технологией. Это в какой-то мере даже мелодраматично: как капитан, скрывающийся в волнах, стоя на мостике своего тонущего судна.

У этого сценария заката жизни программистов и их судов есть пара исключений. По-настоящему талантливые сохраняют в себе вечнозелёной способность перелицевать себя под наисвежайший, находящийся на подъёме набор технологий, когда того ни пожелают. Второе исключение — это случай Большой Ж. Если бомба замедленного действия, забытая некомпетентными разработчиками в древних геологических пластах системы, внезапно рванёт, распространяя дрожь землетрясения сквозь более новые пласты, убелённые сединами ветераны могут внезапно обнаружить свои умения вновь востребованными (мы уже имели возможность наблюдать это в небольшом масштабе перед 2000-м годом, но исправление тогдашнего бардка потребовало не так уж много талантов; хотя можно представить ожидающие нас в будущем более критичные сбои, которые потребуют от вышедших на пенсию героев и героинь вернуться на свои рабочие места, чтобы всё исправить — в стиле фильма "Армагеддон".

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

И вы должны найти способ красиво сплавлять ветеранов на покой — гораздо более вежливо (и более затратно), чем в других отраслях, — ведь они могут оказаться вашим спасательным кругом в случае, если всё начнёт рассыпаться на глазах. Хотя пока это ещё не так очевидно, но по мере того, как поколение беби-бумеров уходит на пенсию (а вместе с ними — и знания о ранних геологических пластах съеденной программным обеспечением планеты), управление рисками, связанными с устаревшим ПО, станет крупным бизнесом. Когда из жизни начнут уходить последние ветераны, всё ещё помнящие старые, как кости мамонта, но всё ещё используемые программы, мы окажемся в ситуации, у которой не имеется исторических прецедентов.

Если вам удастся успешно провернуть всё вышеописанное, то для вас — крупной софтверной компании — вложения, которые вы сделали в 12-летнего школьника, будут приносить доход на протяжении всей его жизни — неважно, будет ли он работать на вас напрямую, или нет. В начале вас будут ожидать исключительно расходы; к 18-летию (или около того) он начнёт приносить вам первые дивиденды; к 30 годам вернёт ваши вложения; обеспечит страховку для бизнес-модели по мере того, как ваша компания достигает зрелости (например, значительная причина, по которой Java по-прежнему актуальна, заключается в том, что в неё по-прежнему вложена уйма талантов), и наконец, обеспечит вас страховкой от неурядиц (кстати, это и есть тот самый «поток», которым вы должны управлять, в отличие от «запаса» игроков на скамейке).

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

Программное обеспечение пожирает мир — сорок третий год подряд


Как недавно отметил Алан Кэй, один из первопроходцев сегодняшней — съеденной программами — планеты, у Интернета нет кнопок «стоп», «завершение работы» или «обратная перемотка». Когда он появился, история, можно сказать, началась с нуля. Программное обеспечение начало подъедать докомпьютерные пласты цивилизации — и откладывать на их место свои.

В один прекрасный день мы оценим чрезвычайную важность происходящего, и заменим маркеры «до н.э / н.э.» на «до э.И. / э.И.» («до эры Интернета / в эру Интернета»), точкой отсчёта которых будет 29 октября 1969 года — день, когда был запущен Интернет (иными словами, я пишу эту статью в 43 году э.И.).

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

И тут мы подходим к ныне знаменитому тезису Дэвида Кирпатрика о том, что любая компания сегодня — это софтверная компания.

Мы только начинаем понимать, что программное обеспечение стало центральным для функционирорвания любой компании — вне зависимости от того, что она производит или какие услуги предоставляет.

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

Но это вот-вот изменится.

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

Выжившие обнаружат себя во всё возрастающей зависимости от тех, кто вовремя позаботился обеспечить себя значительными залежами программистов. Ваша компания не способна обеспечить свои собственные IT-нужды? Не беда: их обеспечит Microsoft — небесплатно, конечно. Ваши сотрудники — даже не имеющие никакого отношения к ПО, будут, по большому счёту, контролироваться Google, Apple, Facebook и им подобными, устанавливающими планку их ожиданий посредством рынков ПО, обращённых на потребителя (та самая консьюмеризация IT, о которой так долго твердили все, кому ни попадя).

Могут ли индустрии, не связанные с программным обеспечением, вообще оставаться конкурентоспособными? Это непросто, но и не невозможно. Крупнейшей фишкой, которую они могут поставить на кон, являются накопленные ими данные. В борьбе с давлением консьюмеризации IT со стороны ваших сотрудников и Микрософто-размягчением (игра слов: Microsoftening — Microsoft + softening, «размягчение» — прим. перев.) вашей бизнес-модели со стороны IT-отдела, ваше единственное оружие — это доступ к данным, которые не являются программами.

Я напишу об этом как-нибудь в другой раз. Если вы не знаете, как управляться с единственным оружием, которое у вас есть, оно вскоре будет выбито из ваших рук (картографическая, кино-, музыкальная, новостная, издательская и ресторанная индустрии уже ощутили это на своём горьком опыте).

Взгляд со стороны талантов


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

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

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

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

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

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

Результатом становися новый тип экономики. Добро пожаловать в мир разработчикономики!


P.S. От переводчика
Артемий Лебедев недавно высказался на эту же тему, хоть и менее пространно.
Tags:
Hubs:
+9
Comments 7
Comments Comments 7

Articles