Дж.Ханк Рейнвотер - Как пасти котов. Наставление для программистов, руководящих другими программистами

Справедливым и бережливым. Хм, это довольно трудно – можно поддаться соблазну разбрасываться деньгами, как будто они растут на деревьях, опрометчиво полагая, что оплата повышает производительность. На самом деле здесь стоит хорошенько подумать, ведь сегодняшняя роскошь есть завтрашняя потребность. Деньги, подобно власти, оказывают на человека самое что ни на есть деструктивное влияние. И не заставляйте меня цитировать еще одно известное высказывание из Нового Завета [13] См. Новый Завет, 1-е послание к Тимофею 6:10 – любовь, деньги и зло он виртуозно сводит в один силлогизм. . Так все-таки, возвращаясь к теме, как соблюсти баланс в вопросах денежных выплат? Представим себе весы правосудия. На одну чашу положим справедливость, на другую – бережливость. Вес чаши справедливости равен опыту и производительности программиста. Вес чаши бережливости состоит из стандартных коммерческих хитростей, таких как соблюдение баланса доходов и расходов и статистика средней заработной платы программиста. Принимая решение о денежных выплатах, имейте в виду эту аллегорию – она очень действенна.

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

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

Ну что, вам интересно? Вы заинтригованы тем, что будет дальше? Думаю, что нет. Скорее всего, вы пребываете в полной уверенности, что дальше я разражусь мириадами советов о том, каких действий лучше избегать, а на каких делать упор, и все эти сведения будут представлены в виде маркированных списков. Действительно, в последующих главах таких списков будет немало, но в данный момент я хочу обратить внимание на то, как важно в вашей новой роли думать. Поэтому с перечислением рекомендуемых и не рекомендуемых приемов руководства пока что повременим. Возможно, необходимость думать – это самая сложная обязанность менеджера. Тем не менее это абсолютно необходимое условие нашего успеха. Как пишет в книге «Dynamics of Software Development» Джим Маккарти (Jim McCarthy):

«Основная задача руководителей процесса разработки программных средств состоит в том, чтобы аккумулировать как можно больше интеллектуальных ресурсов и направить их на создание конечного продукта» [15] Jim McCarthy, Dynamics of Software Development (Redmond, WA: Microsoft Press, 1995), p. 5. .

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

Ну а теперь подумаем о том, как справляться с некоторыми типичными ситуациями.

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