Работая продолжительное время инженером-программистом, я собирал помимо опыта и знаний ещё недовольство и замечания к рабочему процессу и начальству в частности. Каждый раз, когда я сталкивался с проблемой, я думал над тем, как мог бы я её решить и что я могу сделать в этой ситуации. Что-то удавалось сделать, а что-то разбивалось об процесс и руководящий аппарат. И каждый раз проблема и её решения откладывались мной, с осознанием того, что если бы у меня были нужные рычаги, уж тогда-то я смог бы изменить и сделать так, как правильно. Я даже сформировал ментальную систему, которую, впрочем, поленился формализовать на бумаге. Царящая вокруг меня несправедливость была для меня хоть и сокрытым, но комком в горле, превращающимся в камень на душе. Я ожидал шанса и возможности всё накопленное реализовать и поправить, и однажды возможность подвернулась.
Будьте осторожны в своих желаниях — они сбываются!
Так и случилось, что мне предложили нежданно-негаданно руководящую должность, оценившую мои таланты и навыки и позволяющую реализовать свои амбиции. Беседа с менеджером закончилась в лучших традициях “Ты теперь начальник — управляй”. И теперь мне предстояло воплощать в себе лучезарный и кристально-чистый светоч справедливости и делать людей счастливыми, нести слово и байт людям. Однако, почти сразу же оказалось, что это несколько сложнее, чем мне казалось ранее, что угол зрения на проблемы снизу и сверху несколько различается, и родной код оказался приветливее громадины проблем и забот. Поэтому сейчас я решил наконец-то оформить свои догмы на бумаге от лица исполнителя и с призмы начальника. Вряд ли я скажу что-то новое, кроме того, что уже до меня написано в хороших книгах, за исключением примеров из практики и шуток с прибаутками, поэтому либо пролистывайте сразу, либо добро пожаловать под кат.
Во-первых, начну с того, чтобы что-то делать и чего-то добиться надо знать, хотеть и делать. Недостаточно кивнуть на удачу или принцип Питера: “В иерархической системе любой работник поднимается до уровня своей некомпетентности”. Хотя и такое случается чаще, чем хотелось бы природной программистской справедливости. Надо знать больше, чем того требует принцип, чем даёт обладание бумажкой диплома, чем видимое с вашей точки зрения участие в рабочем процессе. Будучи рядовым сотрудником я интересовался, как делают ЭТО системные архитекторы и менеджеры проектов, как всё связано и как работает, и зачем, чёрт подери, я пишу код. Нет, я конечно абстрактно понимал, что мой софт запишут в память контроллера, а за контроллер заказчик отдаст деньги. Но помимо моего кода было ещё было много всего остального, зачастую, как мне казалось, ненужного (а иногда так оно и было), и мне жизненно важно было понять суть и цель той миссии, справедливости, что я несу сам во имя Луны.
У программистов, разработчиков обострённое чувство справедливости. Если его нет, то этот специалист — плохой. Не имейте с ним дело и не надейтесь на него. Хорошие программисты не идут на компромиссы до той поры, пока не посчитают решение справедливым. Поэтому одна из наиважнейших мотиваций — это святая цель, управление целью. Хорошим примером, могут служить примеры Apple с его пацифизмом или Google с его свободой для сотрудников. Хорошими примером является так же выступление против “зла” в лице других компаний. Имея цель, как в рабочем процессе, так и на уровне компании легче определить возможности и ресурсы, которые исполнитель будет использовать для своих действий, он будет в конечном итоге понимать, зачем и для чего он работает, и что его отловленный баг не будет больше летать в воздухе, где-то усевшись в контроллере управления самолётом, с сотней ничего об этом не подозревающих людей, потому что его компания, допустим, высшей целью поставила жизни людей. Разработчик, имея свои идеалы и мерила справедливости никогда не пойдёт в компанию, которая убивает морских котиков или распиливает бюджет на латание ям, если это будет противоречить его идеалам. Для него будет критичен стиль кода (нет, только не индийский код!), количество печенья (не допустите, чтобы кому-то не досталось!), вид из окна (у начальника на реку, а у программистов на кирпичную стену) и шум в офисе (менеджеры всегда болтают вместо работы). С точки зрения других участников процесса разработчик может быть и не всегда прав, но у него есть свои святые цели, догмы, нарушение которых куда страшнее, чем, например, оплата труда.
Это очень важный момент, оплата труда разработчика должна быть такой, чтобы он не думал о своих заботах и не искал урывками как бы заработать деньги. И его успехи не нуждаются в подтверждениях в виде премий. Он работает на цель, за свою справедливость, но не за поощрение. Вскормив разработчика с руки вы рискуете просто разрушить отличного специалиста, который мог бы гореть на своём месте куда дольше, озаряя своими идеями весь рабочий процесс. Однако если разработчик ставит во главе угла деньги, и регулярно ходит просить у босса премий — это признак проблемы. С человеком или процессом. Была допущена ошибка, от которой нет обратного хода, но, с точки зрения процесса и управления есть возможность на других сотрудниках избежать подобной проблемы в будущем.
Не всегда мне платили столько, сколько я бы хотел и сколько мне было нужно, и иногда я параллельно лазил по фриланс-сайтам, но на работе я брал инициативу на себя, выполняя свою работу раньше сроков, помогая замешкавшимся сотрудникам, в-общем, я работал усердно, хоть и с косяками, но я старался работать, не за премии, а за успех: “Мы в одной упряжке”. По отношению к себе я был честен, но вот чувство внутренней справедливости взыграло: я работаю на результат, а коллега за часы. Я мог бы работать по 2а часа в день за место 8и с тем же выхлопом, мне не надо было бы стоять лишние часы в пробках. Мне могли бы платить не премии (если такое было предусмотрено), а из результата, из бюджета того сотрудника-лентяя. Можно было бы восстановить справедливость по-разному. Но никто этого не делал. Это была ошибка управления, вылившаяся в падение мотивации и просиживанию часов на стуле. Никогда, ни при каких обстоятельствах не давайте повод разработчикам делать чужую работу даже по их инициативе. Изменяйте планы, выгоняйте нерадивых, давайте сложные задачи инициативным, но не допускайте возможности почувствовать разработчику несправедливое разделение труда. Со стороны разработчика стоит не увлекаться через меру своей работой, а стоит планировать своё время и пускать свои ресурсы в иное русло: обучаться, общаться, улучшать процесс.
Возможно, с точки зрения читателя, в можете сказать, что сам виноват, что же я сам этого не сделал? Что же я пахал на “того парня”? Если многие могут читать башорг на рабочем месте и сохранять видимость работы, то мне, листающему мануалы и пишущему код Qt (допустим) за место ассемблера это сделать было тяжело, опять-таки в силу обострённого чувства справедливости — обманывать начальство? Да и заниматься чем-то другим на работе не приветствуется нигде, а уж тем более иметь side-проекты. Это ещё одна из ошибок руководства — не обучать сотрудников. Вторым важным качеством разработчика является обучаемость. Мы, люди связанные с IT, находимся в перманентном состоянии изучения и совершенствования. Нам мало оттачивать навыки, и интересно написать hello world на brainfuck’e, тетрис на Haskel и много чего такого, что от нас не просят. Нам интересно изучать новое. И когда я спрашивал руководство “А бывают ли у вас тренинги, семинары?” — мне отвечали отрицательно. Они не всегда могут быть связаны с работой, что могло бы приносить риски и потери ресурсов со стороны работодателя, но положительным было бы расширение моей сферы знаний и влияния, обмен опытом с другими программистами, знание новинок в моё сфере. И нечего удивляться, что частой забавой для нас было написание нечитаемого кода, либо красивого, либо сверхбыстрого и низкоуровнего, где происходила битва за каждый не байт, а бит и за каждый такт. Что, в конечном итоге, хотя и не противоречило внутренним стандартам, но вызывало недовольство руководства: код становился человеко-зависимым. Нужда в нас восполняла несправедливость.
Это в Google сотрудник имеет право 20% своего времени заниматься своими проектами, при возможности их внедрить в будущем, т.е. проявить инициативу. На практике это почти всегда не так. Более того, рутина обычно преобладает перед интересными задачами, и отсутствие сайд-проектов губительно так же для атмосферы и мотивации разработчиков. Тем не менее, убить мотивацию разработчика очень сложно, и его идеи и движения рано или поздно доходят до руководства. Не все из них полезны, конечно, но ни одна из них, как правило, не бывает вредна (если, конечно, специалист не обрушил целый build последним commit’ом с сумасбродной и неодобренной фичей). Тем не менее, жестоким ударом по нему будет выкидывание результатов в мусор. Например такое, какое уж никаким образом не должно касаться всей архитектуры и последующих итерацийтестирования. Как пример, могу привести чисто эстетическое вылизывание кода, табуляций, опечаток в комментариях (помимо новой написанной функции), или дополнение unit-test’ов до MCDC. Совершенно очевидно, что функционально такие изменения не изменят ничего, просто приведут к тому, что в обновление вместо одного участка кода попадут другие, и в целом изменения будут больше ожидаемых. Проблема: результат инициативы будет выброшен в мусор. При том, что это не является нарушением или косяком в рабочем процессе. Или обратная сторона — нововведение (фича, рабочий процесс, тулза) будет принята не под автором идеи, а под именем другого сотрудника или промежуточного начальника. С одной стороны, это может быть расценено как вопиющее воровство, а с другой как сигнал к недоверию к сотруднику, что куда хуже повлияет на его собственную оценку.
Помимо всего прочего, важным является так же протекция и сплочённость команды разработчиков. Протекция значит следующий факт, что всё сыплющееся на разработчика сверху — бухгалтерская отчётность, митинги, спринты SCRUM (если процесс не налажен), инвентаризация, техническая оснащенность, возможность участвовать в жизни компании, должно фильтроваться буфером в лице руководителей и менеджмента. У разработчиков особая парадигма жизни, особая экосистема, в которую запускать что-то непонятное очень рисковано. Их, держащих в голове огромную модель, взаимосвязи проекта и кода нельзя отвлекать по “пустякам”, иначе всё начинает рушиться, как карточный домик, а надежда возобновить рабочий процесс становится шалтаем-болтаем, которого, в последствие, надо будет собирать всем персоналом всей компании. Но наряду с этим важно отметить, что участие в жизни компании — это не просто способ увидеть светлую цель, но и почувствовать свою важность. Самой часто распространённой проблемой является посыл “вы денег не зарабатываете”. Люди IT тратят деньги, при этом ничего не производя. А отдел продаж зарабатывает. Продаёт. Поддержка работает с клиентами. Это высказывание — маячок огромной системной проблемы, когда даже в распределённом концерне роль IT-персонала является “убыточной”, хотя, как правило, автоматизация и проекты одной команды разработчиков могут приносить тысячи и миллионы единиц товара на продажу. Особенно плохо дело обстоит с отделами инфраструктуры IT, особенно если они работают хорошо (а не постоянно перетягивают кабели) и с тестированием (код написан!). Такое отношение хотя и порождает защитную реакцию “тупые продажные женщины”, но самое главное, ведёт зачастую к пренебрежению винтиком-разработчиком, на котором держится весь концерн (и конечная прибыль в итоге): в бытовом плане — в стульях второго сорта, в возможности сэкономить (они не жалуются, кому? с людьми же не работают), обрезать бюджет на печенье или мобильную связь, оставив в чёрном лесу на съедение волкам, если несчастному программисту посчастливилось ехать в командировку на объект через тёмные леса.
Разработчики очень терпеливые люди, потому что обычно знают, что во-первых, на дураков не обижаются, а во-вторых, на обиженных воду возят. Но если изначально сотрудник пришёл в компанию, где были бесплатные печеньки, а вид из окна был на подлесок, а по прошествии времени его этого лишили — ждите беды. Убеждение, что в финансовом отделе и кипяток платный вряд ли сработает. Было лучше — стало хуже, да к тому же теперь вид из окна на кладбище домашних животных. Это вызвано тем, что разработчик — существо прогрессивное, и если он видит регресс, с которым не может совладать, от которого нет защиты — это так же его демотивирует.
Сплочённость команды — очень важная вещь, и её как-то облечить в форму управления очень сложно. Сплочённость — это способность команды идти в одной упряжке и взаимодополнять друг друга, иметь общие интересы, не выделяя “худших и лучших”. Я уже сказал выше, что цели и задания не должны пересекаться, не должна появляться конкуренция и соперничество между людьми. Рейтинги, поощрения, морковки и печеньки, особенно печеньки для избранных — это тёмная сторона зла. И не меньшее зло — сам коллектив. Разработчик приходит к себе на работу с желанием быть понятым и принятым. И важным является точки соприкосновения. Зачастую точки соприкосновения образуют подгруппы, группы по интересам. В любом обществе это нормально, но неприемлемо в рабочем процессе. Что же я хуже, в самом деле, что я не вхожу в эту группу любителей покерфейсов? Проблема, когда стержень группы просто расходится со стержнем человека. Например каждодневное обсуждение новостных порталов или нелюбимого вида спорта будет вызывать недовольство. Просто потому что человек не читает желтые новости и не смотрит увлекательное пинание ядер левым мизинцем. Далее объединение в такие сообщества попросту вызовет междоусобные сборы и протекцию, продвижение одних над другими. В обычном обществе — это проблемы общения, но в техническом обществе, в среде IT, как плохо владеющими коммуникационными навыками, такая проблема может носить терминальный характер. Более того, это повод задуматься, если один из сотрудников изучает мануалы, читает тематические ресурсы, и подходя к коллегам с желанием поделиться “я тут такой фреймворк нашёл” слышит в ответ “что ерунда, нам это не интересно”. Это повод задуматься разработчику — а туда ли он вообще пришёл? И повод задуматься руководству о сотрудниках: а тем ли они заняты и нужные ли это люди? Умение решать проблемы и задачи без интереса в профессиональном плане — признак гниения процесса и команды. Поэтому заинтересованность — третье важное качество разработчика.
Все эти проблемы выливаются в чувство несправедливости и неправильности. Процесса, людей, всего, что окружает человека. И именно с этими факторами мне, как руководителю предстояло бороться и не повторять прежних ошибок.
Для этого можно составить итоговый список по всему, что я перечислил выше:
- быть рассудительным и видеть точку зрения разработчика;
- быть открытым для обратной связи;
- иметь авторитет человека, знающего тематику;
- развивать людей без боязни, что они уйдут;
- доверять и делегировать управление;
- не давать обещаний, которые нельзя выполнить;
- управлять командой и подбором людей;
- выработать цель и ценности;
- иметь открытый и ясный процесс;
- защищать интересы команды в первую очередь.
По поводу последнего могу отметить, что для руководства это одно из ключевых моментов. Команда — это опора руководителя, и чем крепче команда, чем довольнее разработчик, тем больше у него возможностей выполнить проект в срок, сдать заказчику и сделать его идеальным.
Об остальных проблемах, опыте и деталях мы поговорим в следующий раз.
Автор: wwakabobik
