Программисты и профессиональные спортсмены

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

Представим себе, что лет через десять мы настраиваемся в Сети на ежедневный Hack Center Live Action Report и становимся свидетелями такого (для наших дней звучащего фантастично) обмена мнениями:

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

Дэйл, я в курсе, что пресса возложила вину за провал Megasoft в этом сезоне именно на Аду, но не думаю, что эти борзописцы справедливы. Вспомни, что Кладж Байтбангер, который должен был проектировать архитектуру системы, вышел из игры в самом ее начале. Он так и не сформулировал законченные требования к интерфейсу, и вся команда оказалась в трудном положении. И несмотря на то, что Кладж был быстро заменен, Ада оказалась уже не в состоянии добиться хорошего результата.

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

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

Где правит бал талант

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

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

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

В профессиональном спорте, как мало в какой иной области человеческой деятельности, сложилась традиция не жалеть сил и средств на выявление и культивирование талантов. Чем явно отличается большой спорт от программной индустрии, так это точностью, с которой способности атлета и его результаты могут быть измерены, интерпретированы и переведены в денежные бонусы. Так, если один спортсмен способен пробежать 40 ярдов за 4.3 секунды, а другой - за 4.4 секунды, то разница в одну десятую стоит 1 млн. долл. в год, если речь идет о профессионале из Национальной Футбольной Лиги. И это справедливо - ведь разница в 2% транслируется в драматическую разницу в способности забить тачдаун - те немногочисленные звезды, которые могут пробежать 40 ярдов за 4.3 секунды столь поразительно быстры, что качественно превосходят - по объективному конечному результату - тех, кто просто достаточно быстр. Владельцы команд как раз из такого простого измерения скорости бега способны легко оценить возможные голы, значит - победы команды, и соответственно больший доход. Отсюда мало-мальски проницательные финансовые аналитики дают обоснованную оценку экономической ценности незначительного, на первый взгляд, увеличения скорости бега, что является оправданием для дифференциации в уровне оплаты. Вот такую практику и надо бы адаптировать для программной индустрии.

Уроки спорта

Какие же полезные уроки может извлечь индустрия программирования из практики профессионального спорта с его акцентом на таланты? Иными словами, какие практические стороны работы с кадрами, отработанные в спорте, стоит адаптировать в фирмах-разработчиках ПО?

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

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

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

Пока же немногие программистские фирмы ищут и затем целенаправленно наблюдают за деятельностью талантливых кандидатов. Как правило, просто дается объявление о вакансиях, а затем остается выбрать среди тех, кто на эти объявления откликнулся, говоря при этом: "Мы делаем все, что можем". Едва ли! Если вы сравните производительность своих лучших сотрудников и всех остальных, то обнаружите, что экономия на процедурах поиска и набора - мнимая, влетающая в конечном счете в копеечку. Чем меньше внимания менеджеры уделяют подбору персонала, тем больше усилий они затрачивают при управлении самим производственным процессом. Вспоминаю, как один известный менеджер сказал со вздохом: "Победители побеждают сами; остальные нуждаются в постоянном надзоре". Может быть это и упрощение, но этот человек определенно понимал, когда и на что он может позволить себе тратить свое дорогостоящее время.

Денежное вознаграждение. Некоторые из наиболее радикальных изменений, перед необходимостью которых стоят фирмы по производству ПО, связаны с системой денежных компенсаций. Фирмы уже начинают адаптировать практику выплаты премиальных, оговариваемых при заключении контракта; до сих пор именно эти "signing bonuses" были отличительной чертой профессионального спорта. Еще недавно только исполнительные менеджеры получали заранее оговоренные премии, привязанные к результатам, то ныне такого рода премии все чаще предлагаются и инженерам-программистам. Я не сомневаюсь, что по мере того, как все больше осознается значимость талантов в производственном процессе софтверных организаций, становится явными радикальные изменения в системе денежных компенсаций.

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

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

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

Некоторые выводы

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

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

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

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

Вилл Куртис и модель People CMM

Билл Куртис - соучредитель и главный научный сотрудник компании TeraQuest Metrics, помогающий программистским фирмам модернизировать технологии их процессов разработки. Доктор Куртис, автор более 100 статей и член редколлегий 7 журналов, является крупнейшим авторитетом в области "peopleware" - относительно нового раздела Software Engineering, связанного с человеческим фактором в процессе разработки ПО. В начале 90-х г. он возглавлял "Software Process Program" в ведущем мировом центре программной инженерии - Software Engineering Institute (SEI) при Carnegie Mellon University - и в этом качестве стал соавтором Модели зрелости процесса разработки ПО (Capability Maturity Model - CMM) - наиболее признанной в мире и приобретшей de facto статус стандартной модели, устанавливающей методики и процедуры оценки и развития процессов разработки ПО в контексте деятельности подразделений фирм-производителей ПО [1].

В 1995 г. под руководством Куртиса в SEI разработана People Capability Maturuty Model (People CMM) [2], которая является дополнением модели CMM, обеспечивая те организации, которые адаптируют ее с целью усовершенствования своих технологических процессов, множеством процедур по оценке и развитию всей системы отношений, связанной с "человеческим фактором". ""Краткий обзор этой модели может помочь читателю более наглядно представить тот контекст, в котором следует воспринимать несколько экзотическую по материалу статью "Программисты и профессиональные спортсмены".

Пять уровней модели (которые соответствуют одноименным уровням SEI CMM) представляют стадии в эволюционном переходе от низшего уровня в работе с персоналом к высшему. Каждый уровень характеризуется множеством тех ключевых аспектов работы с персоналом (key practice areas), которые реализуются с помощью набора практических процедур, необходимых для развития разных сторон деятельности сотрудников.

Первый уровень ("Initial") является начальным и характеризуется пассивностью менеджмента и наличием только стихийных и несогласованных процедур по работе с персоналом. На уровне 2 ("Repeatable") уже просматривается более-менее согласованная политика управления сотрудниками, однако она ограничивается рамками локальных структурных подразделений и стандартными процедурами по созданию рабочей среды и облегчения коммуникаций между сотрудниками, элементарным тренингом и материальным стимулированием. На третьем ("Defined") уровне определяется множество организационных процедур, позволяющих связать знания и навыки персонала с той спецификой разрабатываемого ПО, которая свойственна конкретным проектам данной организации ("competency-based workforce practices"). Уровень 4 ("Managed") характеризуется вводом в действие системы количественных измерений эффективности работы сотрудников и предполагает адаптацию процедур, позволяющих на основе объективной информации целенаправленно выстраивать настроенные на работу над конкретным проектом команды. Наконец, высший - пятый уровень ("Optimizing") имеет в виду наличие в организации такой всеобъемлющей системы работы с персоналом, которая сфокусирована на непрерывном совершенствовании специфической компетентности отдельных индивидов, больших и малых структурных подразделений и всей организации, что позволяет в оптимальном режиме перестраивать работу на создание инновационных продуктов.

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

SEI инициировал несколько пилотных проектов по использованию People CMM. Помимо приложения предоставляемых этой моделью процедур к собственному персоналу SEI, проект запущен в таких организациях, как Citicorp, GDE Systems, Boeing и US Army Software Design Center [3].

Литература

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