Когда люди выполняют физическую работу, легко оценить, насколько тяжело они трудятся. Видно, как они двигаются, потеют. Видны и результаты их работы: кирпичная стена растет, дыра в земле становится все больше. Одобрять и награждать за тяжелую работу — это фундаментальный человеческий инстинкт, одна из причин, по которой нам так нравятся силовые виды спорта. Но когда дело доходит до управления творческими или техническими сотрудниками, это инстинктивное восприятие тяжелой физической работы становится проблемой. Эффективные работники умственного труда часто не похожи на людей, которые тяжело работают.
В 2004 году я работал младшим разработчиком в большой команде отдела по биллингу и предоставлению услуг в компании кабельного телевидения. Как и все большие системы, эта состояла из нескольких относительно самостоятельных компонентов, над которыми работали отдельные сотрудники или небольшие группы. Системы цифрового и аналогового ТВ были почти полностью отделены друг от друга, с каждой из них работала своя команда.
Команда аналогового ТВ развертывала свою систему на ранней версии Microsoft BizTalk. Четверо наших ребят и команда из Microsoft развивали систему и запускали ее. Казалось, что все они усиленно работают. Они часто оставались на рабочем месте ночью и по выходным. Они бросали свои дела, чтобы помочь с проблемами на работе, часто толпились вокруг одного стола, выдвигая предложения о том, что может быть не так, и как это исправить. Они постоянно что-то делали, и с одного взгляда на них было понятно, что перед нами сплоченная команда, которая усердно трудится.
Команда цифрового ТВ очень отличалась. Код был в основном написан одним парнем, назовем его Дэйв. Я был младшим разработчиком по ТО в команде. Сначала я с трудом понимал код. В самых важных местах не было длительных процедур, вместо них использовалось много мелких классов и методов величиной в несколько строк. Некоторые из моих коллег жаловались, что Дэйв все слишком запутал. Но он взял меня под свое крыло и предложил прочитать несколько книг по объектно-ориентированному программированию. Он рассказал мне о шаблонах проектирования, принципах SOLID и модульном тестировании. Вскоре я начал вникать в код, и чем больше я работал над ним, тем сильнее мне нравился его элегантный дизайн. Он функционировал правильно и просто делал свою работу. Вносить изменения в код тоже было относительно легко, так что новые функции подключались довольно безболезненно. Использование юнит-тестов означало, что немногие баги доходили до продакшена…
В итоге со стороны было не слишком похоже, что мы усердно трудимся. Я шел домой в 5:30, никогда не работал в выходные дни, мы не толпились часами вокруг столов друг друга, высказывая догадки о том, что пошло не так с упавшими системами. Людям, должно быть, казалось, что наша работа гораздо проще, чем работа команды аналогового ТВ. По правде говоря, требования к нам были очень похожи, у нас просто было лучше написанное и внедренное программное обеспечение и более качественная инфраструктура поддержки, особенно модульные тесты.
Начальство объявило, что хочет повысить заработную плату, основываясь на показателях работы. Когда пришла моя очередь говорить с боссом, он объяснил, что справедливо будет, если прибавку получат те люди, которые работают очень тяжело, а наша команда, кажется, не так уж сильно переживает за компанию, особенно в сравнении с героями, которые жертвовали своими вечерами и выходными.
История с кабельной компанией – особый случай, ведь там можно было своими глазами сравнить последствия хорошего и плохого программного обеспечения и поведения команды. В большинстве компаний не получится найти такого сравнения. Если какой-то человек усердно трудится, работает допоздна и в выходные, постоянно не успевает, сложно сказать, действительно ли он тщательно выполняет очень сложную работу или просто много ошибается. Если вы не можете нанять две или более команд-конкурентов для решения одно и той же задачи (а кто так сделает?), то не сможете узнать наверняка. И наоборот, как насчет парня, который сидит в углу, работает с 9 до 5, и, кажется, много времени сидит в Интернете? У него большой опыт в написании стабильного надежного кода или просто его работа легче, чем у остальных? Если взглянуть со стороны, первый работает очень тяжело, а второй нет. Тяжелая работа это хорошо, лень это плохо, ведь так?
Я бы сказал, что тяжелая работа часто указывает на ошибки. Трудно заниматься разработкой хорошего программного обеспечения, если на вас давят и постоянно мешают. Работа сверхурочно чаще всего не так уж и хороша. Иногда для решения сложной проблемы лучше всего перестать думать о ней, пойти на прогулку или даже хорошенько поспать, чтобы дать вашему подсознанию во всем разобраться. Одна из моих любимых книг – это A Mathematician’s Apology Г.Х. Харди (G. H. Hardy), одного из ведущих британских математиков 20-го века. В ней он описывает свою повседневную рутину: четыре часа работы утром, просмотр крикета во второй половине дня. Он говорит, что выполнять тяжелую умственную работу дольше четырех часов в день бессмысленно и непродуктивно.
Менеджерам я бы посоветовал судить о людях по результатам, по рабочему программному обеспечению, а не тому, насколько усердно они работают. Вопреки интуиции, иногда лучше не сидеть вместе с разработчиками, ведь тогда можно получить более полное представление о своей продукции, которое не будет зависеть от обычных/интуитивных показателей. Удаленная работа особенно выгодна; вы можете оценивать своих сотрудников по количеству выполненной работы, избавившись от необходимости лениво смотреть на то, как они сидят за столами по 8 часов в день, копошась в интегрированных средах разработки, или «услужливо» толпятся рядом, предлагая «полезные» идеи.
Источник http://habrahabr.ru/post/206540/
RSS & RSS to Email