2013-12-13
Когда люди занимаются физическим трудом, результаты их деятельности легко заметны. Вы видите потные спины и грязь на лицах шахтёров. Вы видите, как вырастает стена или углубляется котлован.
Тяжёлый труд всегда вознаграждается, это одна из основ системы человеческих ценностей. Поэтому мы восхищаемся атлетами, марафонцами, футболистами.
Это инстинктивное восхищение тяжёлой работой становится проблемой, когда мы сталкиваемся с управлением творческим мыслительным процессом, каковым и является работа дизайнера, инженера, архитектора, программиста. Работники интеллектуальной нивы со стороны не выглядят как стахановцы. Взять, к примеру, этого человека:
Моя история
В 2004 г. я был младшим разработчиком в большой команде компании, занимающейся биллинговыми системами и системами тех.поддержки для кабельного телевидения. Любая крупная система состоит из нескольких относительно независимых друг от друга компонентов, каждый из которых контролируется определёнными людьми или группой людей. Например, системами тех.поддержки для цифрового и аналогового телевидения занимаются абсолютно разные отделы.
Отдел аналогового ТВ решил построить свою систему на ранней версии Microsoft Biztalk. Четверо наших ребят работало с командой из Microsoft, разрабатывая и запуская в продакшн сервисы. Все они чертовски много работали. Они оставались на работе ночами и в выходные. Каждый был готов бросить всё и кинуться на помощь ближнему, у которого возникли проблемы при релизе. Деятельность кипела по-настоящему: зайди в этот отдел в любое время, обязательно увидишь ребят, склонившихся над монитором или столпившихся у стола коллеги.
Отдел цифрового ТВ работал совершенно иначе. Код писал волк-одиночка, назовём его, к примеру, Дейвом. Я был младшим программистом. С первых же дней я столкнулся с огромными проблемами в понимании кода, который состоял из множества малых классов и методов. Некоторые мои коллеги жаловались, что Дейв любит всё усложнять. Однако Дейв взял меня под своё крепкое крыло, посоветовал книги про ООП, которые стоит почитать, обучил меня основным паттернам, модульному тестированию. Вскоре я смотрел на код уже осмысленным взглядом, и чем больше я с ним работал, тем больше ценил элегантность кода. Он не выдавал ошибок, он просто работал. Вносить изменения было легко и приятно, а реализация новых функций не вызывала затруднений.
Именно поэтому отдел цифрового ТВ не выглядел постоянно и тяжело работающим. Я приходил домой в 17:30, никогда не работал по выходным, не обсуждал с коллегами часами возможные решения возникшей ошибки. Со стороны, наверное, казалось, что мы вообще ничем не занимаемся в сравнении с отделом аналогового ТВ. На самом деле наши задачи были очень похожи, разница состояла лишь в подходе к инфраструктуре разработки.
Однажды руководство объявило о поднятии заработной платы в зависимости от продуктивности. Мне босс объяснил, что справедливо поднимать зарплаты тем, кто действительно много работает (конечно, отдел аналогового ТВ был приведён в пример), а наш отдел не выглядит очень уж вовлечённым в процесс, и даже ни разу не оставался работать сверхурочно. Угадайте, кому подняли зарплату, а кому нет.
Тяжёлый труд приводит к лучшим результатам?
Эта компания кабельного ТВ была редкой для меня возможностью оценить прямое влияние хорошей и плохой инфраструктуры разработки на поведение команды. Как правило, сложно сказать, каков реальный вклад вот этого чувачка, который вкалывает днями и ночами, постоянно сражаясь с ветряными мельницами: он действительно двигает систему вперёд или просто ошибается на каждом шагу? Если у вас нет возможности посмотреть, как две разные команды работают над одним проектом, вы это никогда не выясните.
А что насчёт вон того гика, который сидит в уголке с 9 до 17, и, кажется, круглый день читает френд-ленту? Он со всем справляется, потому что он настоящий профессионал, или у него просто задачи проще?
Конечно, для стороннего наблюдателя первый экземпляр работает гораздо больше, чем второй. Тяжкий труд — это хорошо, а лень — это плохо.
Что я хочу сказать?
Я хочу сказать, что видимая чрезмерная активность в интеллектуальном труде —зачастую показатель неудачи. В атмосфере постоянного аврала, решения проблем, коллективных обсуждений, громких голосов редко создаётся толковый программный продукт. Совсем не хорошо работать долго. Порой для того, чтобы решить проблему, достаточно на время прерваться, прогуляться, хорошо поспать и дать нашему подсознанию её решить. В своей книге «Апология математика» Годфри Харди, один из лучших британских математиков XX в., описывает свой день: 4 часа продуктивной работы до полудня, а потом сиеста и игра в крикет. Он говорит, что абсолютно бесмыссленно и непродуктивно заниматься ментальной деятельностью более 4 часов в день.
Что я хочу сказать менеджерам и руководителям?
Оценивайте работников по результатам, по работающему продукту, а не по тому, сколько часов они проводят на работе. Попробуйте отпустить свой отдел на удалённую работу на пару недель: вам придётся оценивать их по их результатам, и ваши глаза вас не обманут.
Перевод: Люся Ширшова. По материалам замечательного блога британского разработчика Mike Hadlow с девизом «Жизнь как боль».
