Когда люди выполняют физическую работу, легко оценить, насколько усердно они работают. Вы можете видеть, как они двигаются и потеют. Видны и результаты их работы: кирпичная стена растёт, яма в земле становится всё больше.
Ценить и вознаграждать упорный труд — это фундаментальный человеческий инстинкт, одна из причин, по которой мы так любим силовые виды спорта.
Но когда дело доходит до управления творческими или техническими сотрудниками, это инстинктивное восприятие тяжелого физического труда становится проблемой.
Эффективные работники умственного труда часто не похожи на людей, которые много работают. В 2004 году я работал младшим разработчиком в большой команде по выставлению счетов и предоставлению услуг в компании кабельного телевидения.
Как и все большие системы, эта состояла из нескольких относительно независимых компонентов, над которыми работали отдельные лица или небольшие группы.
Системы цифрового и аналогового телевидения были практически полностью отделены друг от друга, и с каждой из них работала своя команда.
Команда аналогового телевидения развернула свою систему на ранней версии Microsoft BizTalk. Четверо наших ребят и команда Microsoft разработали систему и запустили ее.
Казалось, все они усердно работали.
Они часто оставались на работе по ночам и в выходные дни.
Они прекращали свои дела, чтобы решить проблемы на работе, часто толпились за одним столом, высказывая предположения о том, что может быть не так и как это исправить.
Они постоянно чем-то занимались, и с одного взгляда на них было видно, что это сплоченная команда, которая много работает. Команда цифрового телевидения была совсем другой.
Код в основном писал один парень, назовем его Дэйв.
Я был младшим разработчиком в команде.
Сначала мне было трудно понять код. В самых важных местах не было длительных процедур; вместо этого использовалось множество небольших классов и методов размером в несколько строк.
Некоторые из моих коллег жаловались, что Дэйв все слишком запутывает. Но он взял меня под свое крыло и предложил прочитать несколько книг по объектно-ориентированному программированию.
Он научил меня шаблонам проектирования, принципам SOLID и модульному тестированию.
Вскоре я начал разбираться в коде, и чем больше я над ним работал, тем больше мне нравился его элегантный дизайн.
Он функционировал корректно и просто выполнял свою работу.
Внесение изменений в код также было относительно простым, поэтому добавление новых функций прошло довольно безболезненно.
Использование модульных тестов означало, что лишь немногие ошибки попадали в производство.
В конце концов, не похоже, что мы усердно работали.
Я приходил домой в 5:30, я никогда не работал по выходным, мы не толпились часами за столами друг друга, размышляя о том, что пошло не так с неисправными системами.
Люди, должно быть, думали, что наша работа намного проще, чем у команды аналогового телевидения.
По правде говоря, требования к нам были очень похожими, просто у нас было лучше написанное и реализованное программное обеспечение и лучшая инфраструктура поддержки, особенно модульных тестов.
Начальство заявило, что хочет повысить зарплату в зависимости от результатов работы.
Когда подошла моя очередь поговорить с боссом, он объяснил, что было бы справедливо, чтобы люди, которые очень много работали, получали повышение, и наша команда, похоже, не особо заботилась о компании, особенно по сравнению с героями.
которые пожертвовали своими вечерами и выходными.
История кабельной компании представляет собой особый случай, поскольку она позволила нам собственными глазами сравнить последствия хорошего и плохого программного обеспечения и поведения команды.
В большинстве компаний вы не сможете найти такого сравнения.
Если кто-то много работает, работает допоздна и по выходным и постоянно терпит неудачу, трудно сказать, действительно ли он выполняет очень сложную работу тщательно или просто делает много ошибок.
Если вы не сможете нанять две или более конкурирующие команды для решения одной и той же проблемы (кто бы это сделал?), вы не будете знать наверняка.
И наоборот, как насчет парня, который сидит в углу, работает с 9 до 5 и, кажется, проводит много времени в Интернете? Есть ли у него большой опыт написания стабильного и надежного кода или его работа просто проще, чем у других? Если посмотреть со стороны, первый работает очень усердно, а второй нет. Трудолюбие – это хорошо, лень – это плохо, верно? Я бы сказал, что упорный труд часто указывает на ошибки.
Трудно разрабатывать хорошее программное обеспечение, если вы находитесь под давлением и вас постоянно прерывают. Работать сверхурочно в большинстве случаев не так уж и здорово.
Иногда лучший способ решить сложную проблему — перестать думать о ней, пойти на прогулку или даже вздремнуть, чтобы позволить вашему подсознанию разобраться во всем.
Одна из моих любимых книг — Извинения математика Г.
Х.
Харди (G.H.Hardy), один из ведущих британских математиков 20 века.
В нем он описывает свой распорядок дня: четыре часа работы утром, просмотр крикета днем.
Он говорит, что заниматься тяжелой умственной работой более четырех часов в день бессмысленно и непродуктивно.
Я бы посоветовал менеджерам судить о людях по их результатам, по тому, как работает программное обеспечение, а не по тому, насколько усердно они работают. Как ни странно, иногда лучше не сидеть с разработчиками, потому что тогда вы сможете получить более полное представление о своих продуктах, которое не будет зависеть от обычных/интуитивных показателей.
Удаленная работа особенно выгодна; вы можете оценивать своих сотрудников по объему выполненной ими работы, избавляя вас от необходимости лениво наблюдать, как они сидят за своими столами по 8 часов в день, ковыряясь в интегрированных средах разработки или «услужливо» слоняясь вокруг, предлагая «полезные» идеи .
Теги: #программирование #эффективность #история #история #программирование #Управление проектами
-
Люблю Во Мне Программиста
19 Oct, 24 -
Коды Исправлений «На Пальцах»
19 Oct, 24 -
Csspedys — Велосипеды От Css
19 Oct, 24
