Прим. переводчика — В оригинале использовался всем знакомый термин «software engineer». Так как русский его аналог «инженер-программист» используется в повседневной речи редко, пришлось использовать слово «разработчик» как наиболее близкое. Также профессия «short-order cook», с которой автор сравнивает положение многих разработчиков в индустрии, была переведена как «мальчик на побегушках» — мне кажется, что она отлично отражает суть проблемы отношения к разработчикам. Наконец, я старался везде вместо слов «to code» и «programming» использовать «разрабатывать» и «разработка» из-за сложившемся в русском языке негативном смысле слов «кодировать» и «программирование» как примитивных процессов перевода требований в машинные инструкции низкого или высокого уровня.
Автор оригинальной статьи — Nickolas C. Zakas, известный фронтенд разработчик и JavaScript-евангелист в свое время проработавший более пяти лет в Yahoo. Это запись из его блога, в которой он говорит о том, почему с разработчиками так сложно договориться и что с этим делать.
Не так давно Дженна Байлотта написала замечательную статью «Как дизайнерам ужиться с разработчиками», в которой она описывает методы работы в команде, позволяющие дизайнерам и разработчикам добиться лучшей производительности. Я в свое время работал с дизайнерами (а, работая в UI, и с разработчиками) и столкнулся с похожими проблемами, так что мне понятен ее практичный подход. Во время командной работы никогда не помешает уважать труд своих коллег и понимать их способ мышления.
Одна из главных мыслей той статьи заключалась в том, что разработчики говорят «нет» слишком быстро. Эта мысль тут же въелась мне в мозг и долго отказывалась вылезать оттуда. Мне хотелось воскликнуть: «Но подожди, ты же не понимаешь, почему мы говорим „нет“!». Тут же появился миллион других защитных аргументов. На самом деле она, конечно, права — мы правда слишком быстро говорим «нет», причем не только дизайнерам, а вообще всем. Это побудило меня поразмыслить над психологией разработчиков и тем, что составляет нашу истинную суть.
Давайте начистоту, у нас, разработчиков, репутация таких гордых спорщиков с регулярными перепадами настроения. Мы постоянно говорим «нет», уточняем детали до неприличного педантизма и считаем, что можем выполнить работу любого из наших нетехнических коллег намного лучше их самих. И, чего уж там, этот стереотип во многом соответствует истине — именно этим мы и занимаемся день за днем, в перерывах между написанием кода и чтением Твиттера с Hacker News.
(Примечание: Кто-то из вас скажет, что не все разработчики такие, и будет прав. Есть маленький процент разработчиков, которых нельзя причислить к вышеуказанной категории. Не торопитесь пока листать вниз и писать в комментариях о том, что автор идиот, читайте дальше.)
Репутацию никто просто так не выдает, ее зарабатывают. Что удивляет меня в этой репутации, так это то, что я лично знаю кучу разработчиков, и, как правило, это доброжелательные, приятные (если с ними не упрямиться) и просто веселые парни. С ними можно отлично провести время после работы или на выходных. Так почему же на работе они становятся совсем другими людьми?
У меня есть теория. Она заключается в том, что разработчики видят себя совсем не так, как их коллеги. Я пришел к этому выводу за десять с лишним лет работы в крупных и мелких компаниях, занимающихся разработкой ПО. Сотрудники таких компаний (менеджеры продуктов, дизайнеры, прочие менеджеры) обычно смотрят на разработчиков как на простых строителей. Менеджер продукта должен придумать оригинальную идею, дизайнер должен выразить ее в красивой форме, а разработчик должен только воплотить эти идеи в жизнь. По сути на инженеров смотрят как на мальчиков на побегушках, делающих точно то и только то, что им сказали.
Об этом меня предупреждал еще мой первый менеджер. Когда первая компания, в которой я работал, развалилась, у нас состоялся весьма откровенный разговор о моей будущей карьере. Хотя мы не всегда ладили, он дал тогда мне великолепный совет (далее неточная цитата):
Он был совершенно прав. Существует множество компаний, которым нужны мальчики на побегушках, им нужны строители, которые будут писать код по четко заданному шаблону без права сделать шаг в сторону. Я бы даже сказал, что таковы большинство компаний, как крупных, так и мелких. Я давно сбился со счета, сколько основателей стартапов предлагали мне долю в компании в обмен на воплощение в жизнь их авторского видения. Все они исходят из того, что идеи у них уже есть, им нужен только тот, кто воплотит их в жизнь.
И вот тут зарыт главный корень проблемы — разработчики на самом деле не послушные строители. Разработчики — творцы. Вы сами в каком-то смысле занимаетесь сборкостроительством всякий раз, когда собираете мебель из Икеи. У вас на руках все инструкции, и, если следовать им шаг за шагом, вы соберете тот до смешного маленький столик, который вы так хотели. Творчество — это совсем другая работа, это создание чего-то без конкретных направлений или инструкций. Вы начинаете с чистого холста, а заканчиваете произведением искусства. Разработчики так любят программирование не потому, что они хотят исполнять чьи-то инструкции, а потому, что поняли, что могут при помощи него делать разные интересные штуки. Мы все влюбились в процесс разработки, потому что когда-то написали скромное, но полезное приложение, и нас зацепило.
В триумвирате разработки ПО, состоящем из менеджеров продуктов, дизайнеров и разработчиков, только от разработчиков требуют отключить свою творческую жилку и заняться обычным производством. Но разработчики вовсе не тупые, они прекрасно чувствуют такое отношение, и в них начинает проявляться недовольство. Разработчики хотят быть частью общего творческого процесса, а их этого лишают. И вот уже совершенно нормальный разработчик превращается в хронического ворчуна.
Менеджеры продуктов, как правило, незаурядные люди. Их идеи и способность чувствовать тенденции рынка впечатляют. Но у них также есть свойство считать свои идеи совершенно лишенными просчетов, в то время как на самом деле в них есть дыры, через которые может проехать целый поезд. Я говорю это с большой нежностью, некоторые менеджеры продуктов мои хорошие друзья, и, конечно же, я не раз говорил им об этом в лицо. Я ни в коем случае их не критикую, это просто их суть. Они занимаются творческой работой, и редкая идея рождается идеальной. И вот от этого-то как раз разработчики и становятся ворчунами.
Как разработчики, так и менеджеры продуктов часто неверно считают, что требования или спецификация продукта аналогичны готовым частям мебели из Икеи. На самом деле эти документы редко содержат достаточно информации, чтобы по ним можно было собрать полноценный продукт. Как правило, это просто отправная точка — и это предоставляет разработчику уникальную проблему для решения.
Для того, чтобы понять эту проблему получше, давайте рассмотрим задачу строительства дома. Допустим, кто-то решил построить дом на определенном участке земли. У дома должно быть два этажа и гараж. У нас даже есть грубая схема передней части дома, начерченная на салфетке. И вот клиент подходит к вам со всей этой информацией и салфеткой и спрашивает: «Тебе же этого хватит, чтобы приступить к строительству, да?» И как вам, хватит?
Если рассуждать логически, то приступать к строительству никак нельзя. Вы не знаете метраж, у вас нет плана этажей, вы даже не представляете, какие требования город предъявляет к строительству новых домов. У вас не хватает информации даже для того, чтобы начать копать землю под фундамент. Единственное логическое решение — сказать клиенту, что он псих и должен вначале точно решить, что именно ему нужно. А теперь представьте, что вы не можете этого сделать, потому что кто-то поставил дедлайн, и вам кровь из носа нужно к нему успеть.
— Ну… — говорит вам клиент, — давай ты пока начнешь строить; а я буду по мере возможности сообщать тебе новую информацию. Так мы не будем тратить время впустую.
Вы точно знаете, что информации для того, чтобы строить, не хватает, а дальнейшие расспросы клиента ничего пока не дадут. Но дедлайн никто отменять не собирается и вы никак не можете себе позволить просиживать штаны в надежде на то, что клиент расщедрится на детали. И что вам остается? Делать предположения и допущения.
Старая поговорка гласит: «when you assume, you make an ass of u and me» (когда делаешь предположения, выставляешь идиотами нас обоих), и это чистая правда. Предположения опасны и очень часто лживы. И все же без предположений запустить проект не получится. Итак, что вы делаете. Вы начинаете с допущения, в истинности которого вы точно уверены — о том, что у дома будет два этажа и гараж. Тут же вопрос — гараж надо делать пристройкой или отдельно? И какого размера нужно его делать? Не будем усложнять, допустим, что гараж должен быть построен отдельно и рассчитан на одну машину. Теперь можно работать над гаражом как над отдельным зданием, а потом, когда станут известны подробности о доме, его можно будет строить рядом с гаражом.
Спустя неделю работы над гаражом, клиент сообщает вам новые подробности. Оказывается, у дома должно быть три этажа (уф, хорошо, что мы еще не начали строить дом) и восемь ванных. Информации по гаражу пока нет, но дом должен быть покрашен в синий цвет. Вы делаете вывод, что гараж тоже должен быть синим, и приступаете к его покраске.
Спустя еще несколько дней гараж почти закончен. Вы довольны качеством результата, ведь у вас было так мало информации! Вы уже готовы приступить к строительство дома, когда клиент сообщает новые подробности — гараж должен быть рассчитан на две машины и пристроен к дому. У вас трагедия — вы сделали такой крутой гараж, а теперь его придется снести, чтобы построить «нужный». Хуже того, теперь у вас остается меньше времени, чтобы закончить весь проект — и вот вы уже начинаете ворчать.
Если эта аналогия кажется вам безумной, вы явно никогда не работали разработчиком. Мы наблюдаем такое каждый первый день. Мы пытаемся держать проекты на плаву, используя все наши творческие силы, а в итоге получается, что мы не смогли прочитать чужие мысли и неверно угадали, что именно мы строим. Но, если бы мы этого не делали, мы бы просто ждали, тратя время впустую — а, как известно, у каскадной модели разработки не так много поклонников.
Почти в каждой индустрии, где нужно что-то строить, ожидается, что все требования и пожелания будут определены и утверждены до начала строительства. Но не в разработке ПО. При разработке ПО вечно «не хватает времени», чтобы собрать все требования заранее. Нам изо дня в день твердят о том, что нужно двигаться вперед — вот и приходится разработчикам, чтобы двигать проект, учиться заполнять дыры, оставленные менеджерами продуктов. Не стоит забывать и о том, что менеджеры продуктов славятся своей любовью постоянно менять свое мнение, от чего предположения разработчиков зачастую становятся неверными на полпути.
И кто-то еще удивляется, что разработчики так быстро «выгорают» и меняют работу?
Главный враг любого творца — это смена контекста. Как только вы вошли в глубокий творческий режим, так называемый «поток», любое внешнее вмешательство тут же рушит весь процесс. Да, написание кода — тоже творческий процесс, одновременно творческий и логический. Мы не просто пишем код, мы его создаем.
Среди людей, занимающихся управлением времени разработчика, бытует мнение, что переключаться с одного задания на другое для них — плевое дело. Они утверждают, что рабочее время — оно и в Африке рабочее время. Вы просто тратите достаточное его количество на нужную задачу, и, вуаля — вот и результат. Конечно же это не так. Если вы сидите уже второй день над одной задачей, а вас перевели на другую, то вы потом уже не сможете просто так вернуться к тому месту, где закончили. Вам придется потратить определенное время, чтобы включиться в контекст, такова цена за его смену. Даже если другое задание займет всего пару минут, это уже нарушит «поток» и снизит производительность разработчика.
Это одна из главных проблем, от которых ворчат разработчики — постоянная смена приоритетов. Сегодня у нас один главный приоритет, завтра другой — это приводит к неизбежной смене контекста. Творческие люди не любят, когда их отрывают на середине дела, именно поэтому многие разработчики готовы с удовольствием писать до самого утра, только чтобы завершить свою работу. Смена контекста делает их менее производительными.
Но по-настоящему важные приоритеты никогда не меняются, они постоянны. Частота же, с которой люди вокруг нас меняют свое мнение, ужасно бесит разработчиков. Вообще мы постоянно находимся в состоянии боевой готовности и только ждем, когда нам укажут на противника. Но если сегодня вы требуете от нас построить дом, а завтра — переделать его в автомобиль, не удивляйтесь, если почувствуете растущее недовольство в строю.
Разработчиков постоянно ставят в трудное положение, но при этом мы не являемся жертвами, хоть самые истеричные из нас и норовят выставить себя оными. Часть нашей ворчливости идет изнутри, это связано с причиной, зашитой глубоко внутри большинства разработчиков. У нас есть ужасный изъян, и заключается он в том, что мы переоцениваем свои знания и возможности.
Этот изъян проявляется по-разному, но чаще всего при оценке времени на задачу. Почти все из моих знакомых разработчиков хронически недооценивают время, которое им нужно потратить на ту или иную задачу. Только самые лучшие из нас способны поставить себе срок и уложиться в него. Большинство обычно ошибаются раза в два, а то и больше. Это происходит из-за того, что, как и любые другие творческие люди, разработчики часто не могут заранее предвидеть все проблемы, с которыми им придется столкнуться.
Даже несмотря на то, что многие разработчики жалуются, что менеджеры продуктов меняют свое мнение, почти никто из них не берет это в расчет во время оценки времени на задачу. Никто не учитывает время на совещания, уточнение требований и возможные изменения. Баги? Да в нашем идеальном коде их и быть не может, тут и беспокоиться не нужно (а если вдруг что, то тестеры же все отыщут, да?). Важные для проекта люди уйдут в отпуск или заболеют? Ничего страшного, кто-нибудь обязательно их заменит.
Все это прямой дорогой ведет к срыву сроков, но ничто так сильно не задерживает проект, как то, что разработчики не учитывают время на изучение проблемной области. Это напрямую связано с нашим главным недостатком. Мы думаем, что уже знаем все, что нам нужно для выполнения задачи, хотя нам часто приходится работать с технологиями, которые мы видим в первый раз в своей жизни. Сроки, которые мы определяем, подразумевают идеальные знания, с которыми мы можем писать ПО как будто бы по икеевской инструкции. На деле же многие задачи требуют от нас детального изучения их подноготной.
Разработчики, закончившие вуз по специальности, получают после его окончания ложное чувство безопасности. Они мнят себя знатоками ПО и всего процесса разработки, когда на самом деле их знания чуть выше нулевых. Когда я вышел на первую работу, я был таким же гордым выпускником, указывающим всем на их ошибки. Только спустя годы я понял, что на самом деле ничего не знал.
Компьютерные вузы не готовят вас к испытаниям, которые ждут вас в индустрии. Они в первую очередь дают вам концептуальные знания по большому спектру тем, чтобы вы потом не опозорились, столкнувшись с ними во время настоящей работы. Вас учат переменным, функциям и объектам, так как именно с ними вы будете работать большую часть своего времени. Вас учат базам данных и запросам к ним (хотя нормальные формы окажутся бесполезными на практике). Вы тратите ненормально большую часть времени на изучение алгоритмов сортировки и структур данных, которые во время профессиональной разработки будут скрыты от вас под слоем абстракций. Короче, компьютерные вузы рассматривают решение проблем, которые вам на практике никогда не придется решать. Если мне нужно что-нибудь отсортировать, я просто вызову метод sort(). Если мне нужна очередь или связанный список, я использую нативную реализацию языка, на котором я пишу. Все эти проблемы уже решены за меня.
Выпускаясь из университетов, мы считаем, что умеем делать все на свете, хотя на самом деле мы умеем делать только то, что уже было сделано до нас, да и то лишь крошечную его часть. Но при этом мы ведем себя как напыщенные всезнайки и, считая наши знания идеальными, определяем слишком короткие сроки разработки, не думая о том, что нам придется изучать что-то новое.
Частично эта проблема возникает из-за нашего такого хрупкого самолюбия. Мы боимся, что если мы установим слишком длинные сроки, то люди поставят под сомнение нашу компетентность. Нам говорят, что «хорошие разработчики» должны работать быстро, и мы с этим поневоле соглашаемся. Меня всегда поражали ситуации, в которых разработчики вначале определяют срок проекта, а потом кто-нибудь из их руководителей начинает жаловаться, что это слишком много. Во-первых, как я уже заметил, срок и так скорее всего слишком маленький. Во-вторых, разработчик должен лучше менеджера знать, сколько времени потребуется на разработку, не так ли? И это приводит к еще одной проблеме.
Мало какая фраза может так сильно вывести разработчика из себя, как «Раньше я тоже программировал». Кто бы ее не сказал, менеджер продукта, дизайнер или кто-то из руководства, использование ее как доказательства своей правоты приводит только к презрению со стороны разработчика. Если бы я спросил у Леброна Джеймса (известный баскетболист), сколько времени он тренируется перед игрой, то он бы очень удивился, начни я давать ему советы только потому, что я играл в баскетбол в школе. Разработчиков поучают таким образом постоянно.
Вот лишь некоторые примеры невежества, произнесенного менеджерами в моем присутствии:
Технически любая проблема решается «дописыванием пары строк кода». Легче от этого она не становится.
Да, потому что N уже досконально знает ее проблемную область. Я не знаю, мне нужно время на ее изучение.
Увеличение числа разработчиков, занятых проблемой, как правило ее только усугубляет. Единственный способ сделать что-то быстрее — начать с более мелких проблем.
Но худшее, что можно сделать — это сказать разработчикам, что вы когда-то тоже программировали. Обратите внимание, это совсем не то же самое, что быть в прошлом профессиональным разработчиком. Разработчик, ставший менеджером, как правило сохраняет какие-то навыки в течение конечного периода (как правило это пять лет, дальше технологии уже полностью меняются). Но тем, кто никогда не занимался профессиональной разработкой ПО, лучше держать свое хобби при себе, чем использовать его как доказательство своей правоты.
(Если по справедливости, то дизайнеры тоже страдают от такого невежества. Все считают себя специалистами по дизайну, потому что всем нравятся красивые штуки. Но это не делает вас профессиональным дизайнером.)
Разработчики постоянно сталкиваются с проблемой «семи нянек в команде». Так как мы постоянно занижаем реальные сроки выполнения задач, большая часть ПО выходит с опозданием. Независимо от того, идет ли речь о крупных компаниях или мелких компаниях, никому неизвестных стартапах или уважаемых продуктах, все они выходят с опозданием. Постоянные опоздания огорчают менеджеров, которые как правило решают, что вся проблема в нехватке разработчиков. «Так давайте выделим еще людей», говорят они — «это решит все наши проблемы».
Иногда, бесспорно, увеличение числа разработчиков может решить проблему. В большинстве случаев их выделение только приводит к дополнительным трудностям. Заставить творческих людей работать в команде и так не просто, а чем больше их в команде, тем сложнее это сделать. Разработчикам не разрешают просто так сидеть без дела — как только менеджеры решают, что им нечем заняться, они тут же придумывают им работу.
Подобное случилось и со мной в совершенно абсурдном виде. Мы разрабатывали новый, с нуля созданный дизайн главной страницы Yahoo одной маленькой командой. Это был идеальный проект, мы небольшой группой проектировали базовую архитектуру страницы, и никто нам не мешал. Мы закончили проектирование, и готовы были приступить к разработке прототипа, как нам выделили восемь новых разработчиков. Более того, нам дали указания, чтобы эти разработчики тут же приступили к программированию новой страницы. Что было той еще задачей, ведь архитектуры в конечном виде еще не существовало! Но разработчиков нельзя оставлять без дела, их назначили на проект, значит им нужно дать задачу. Классическая проблема о курице и яйце.
В идеальной ситуации мы бы вначале закончили прототип архитектуры, и уже потом бы получили дополнительных разработчиков для ее внедрения. На деле же мы застряли. В итоге я решил использовать уже готовую архитектуру из другого проекта, написав для нее простенький интерфейс, через который можно было обращаться к ней как к новой. Разработчики смогли приступить к своей работе, а мы смогли продолжить разработку архитектуры. Это было ужасным решением ужасной проблемы, которое в итоге перестало работать, когда разработчики добрались до той части интерфейса, которая еще не была реализована. В итоге мне пришлось сказать нашему менеджеру, что если нам не дадут время закончить новую архитектуру, то наш аккуратный карточный домик быстро разлетится на части.
Слишком большое количество разработчиков в команде может сильно усложнить проект. Конечно, они могут работать над независимыми друг от друга задачами, но, как правило, количество таких задач в любом проекте не так велико. Чем больше в проекте занято разработчиков, тем больше времени тратится не на разработку, а на планирование и организацию командной работы. Если вернуться к метафоре строительства дома, то нельзя строить второй этаж до того, как построишь первый. Большинство задач по разработке ПО выполняются строго по очереди, поэтому выделение дополнительного числа разработчиков никак не ускорит процесс разработки. Как говорил один из моих бывших коллег, сколько бы женщин у вас не было, ребенка родить раньше девяти месяцев не получится (на самом деле известная цитата из книги Фреда Брукса «Мифический человеко-месяц»).
Итак, каждый день нам приходится сталкиваться с недостатком информации, меняющимися требованиями, недостаточным пониманием проблемной области и угадывающими наши мысли коллегами. Как творческие люди, мы миримся со всем этим только потому, что результат нашей работы будут использовать живые люди. Вот главный мотиватор разработчиков — мысль о том, что жизнь людей, которых мы даже не знаем, поменяется благодаря нашим стараниям, независимо от того, работаем ли мы над сайтом с миллионом посещений в день или системой продаж для сети ресторанов.
Когда релиз задерживается потому, что кто-то снова поменял свое решение, мы превращаемся в жутких ворчунов. Безумных ворчунов. Нашей мечте, довести результат своих усилий до конечного пользователя, снова помешали осуществиться — нет хуже демотиватора. Что удивительно, разработчики редко бывают перфекционистами. Мы согласны с тем, что лучшее враг хорошего, и готовы выкладывать нашу работу постепенно, чтобы потом объединить ее в одно большое целое. Почему? Потому что только так можно вовремя выложить нашу работу людям.
Нет, мы понимаем, что задержки — это неотъемлемая часть процесса разработки ПО. Разработчики готовы работать за десятерых, только бы успеть к установленным ими срокам. Мы готовы работать по двенадцать часов в сутки, пусть это только приведет к нормальному результату.
Работая разработчиками, мы привыкаем к режиму работы, кардинально отличающемуся от режимов других сотрудников. Когда на сервере или в сборке что-нибудь ломается, среди ночи будят не дизайнера с менеджером, а разработчика (хотя я знаком с менеджерами, которые требуют, чтобы их тоже будили). Как-то раз мне позвонили прямо тогда, когда я собирался уйти с девушкой на свидание. Моя пара сидела и терпеливо ждала меня целый час, пока я безуспешно пытался исправить проблему. В итоге она ушла (я не могу ее винить), оставив меня страдать наедине с работой и коллегами в IRC-клиенте.
При этом мало кто из разработчиков сильно жалуется на длинный рабочий день или на то, что его разбудили ночью из-за очередного бага. Наш проект для нас как ребенок, и мы готовы заботиться и ухаживать за ним. Если в два часа ночи его нужно покормить, нет проблем. Если на выходных ему нужно уделить время, мы всегда найдем его, при этом улыбаясь, глядя на то, как наше творение растет.
Разработчики особенно рады, когда им дают возможность самим завершить задачу. Ничто не может для них сравниться с удовольствием от отправки письма о том, что задача выполнена и готова пройти ревью. Но их радость тут же улетучивается, когда спустя 10 минут после коммита на их свежесозданное детище начинают записывать баги.
Представьте себя на их месте. Вы потратили целый день (или неделю (или месяц)) на выполнение задачи и справились с ней. Вас переполняет чувство гордости от выполненной работы, которая возможно потребовала от вас знаний, которыми вы раньше не обладали. Все, чего вы хотите — это откинуться на спинку кресла и полюбоваться своими достижениями. Еще лучше, если кто-нибудь похвалит вас за выполненную работу. И что вы получаете? Сообщения о багах. Это не работает, то не так работает, и т.п. Приходится в расстроенных чувствах приступать к работе над ошибками.
Подводя общий итог всему вышесказанному, давайте выделим основные причины, по которым разработчики говорят «нет» (или просто ворчат):
Имейте в виду, что каждая из этих проблем, за исключением первой, связаны с условиями работы в сжатые сроки. Мы хотим завершить к дедлайну все задачи — а как это сделать, когда они постоянно меняются во время нашей работы? Когда такое происходит, нашему недовольству (и ворчанию) нет предела, а «нет» вылетает еще до того, как вы успеваете закончить предложение.
Так как же менеджерам справиться с этой ворчливостью на практике? Давайте еще раз вспомним, что движет разработчиками:
А теперь подумайте, чего в этом списке нет. Денег. Увеличение денежного вознаграждения редко удовлетворяет разработчиков. Звучит как пошлый штамп, но для разработчиков правда дело не в деньгах. Деньги дают им возможность жить в свое удовольствие, но в душе их в первую очередь интересует сам процесс разработки. И чаще всего главное, что им нужно — это возможность заниматься им в нормальных рабочих условиях.
Так как же создать нормальные рабочие условия для разработчиков?
Разработчики такие же творческие люди, как и менеджеры продуктов с дизайнерами, поэтому нужно позаботиться о том, чтобы включить их в творческий процесс. Разработчикам нет равных во время мозговых штурмов и совещаний по обсуждению требований. Дайте разработчикам возможность встретиться с проектной командой и поработать напрямую с ними (но не обязательно всем сразу). Иными словами, включите разработчиков в творческий процесс как можно раньше. Никто не любит, когда в него без объяснений швыряют документами со спецификациями.
Разработчики до предела логичны, поэтому их присутствие на ранних совещаниях поможет им понять, на чем основываются требования, и решить многие проблемы еще до их появления. Когда к разработчикам относятся, как к строителям, они постоянно задают вопросы, и это замедляет процесс разработки. Когда к разработчикам относятся, как к коллегам по творческому цеху, у них появляется меньше вопросов, и разработка движется быстрее.
Также важно то, что разработчики очень часто лучше знают, что можно сделать, а что нельзя. Например, фронтенд разработчики узнают о том, что можно реализовать в браузере задолго до остальных. Поделившись этими знаниями с остальными, мы можем спровоцировать рождение новых идей о том, как улучшить продукт, исходя из наших возможностей. Представьте, что вы придумываете сайт для выкладывания фотографий и не знаете, что их можно кидать прямо с рабочего стола в браузер? Как бы это повлияло на его дизайн?
Итак, дайте возможность разработчикам участвовать в творческом процессе с самого начала проекта. Выслушайте их мнение о проекте и о том, что технически возможно реализовать. Чем меньше нам кажется, что нам говорят, что делать, тем больше мы прислушиваемся к чужому мнению и лучше выполняем свою работу. Единственный способ этого добиться — дать нам поучаствовать в творческой работе над проектом.
Давайте еще подумаем о разработчиках как о творцах. Попробуйте дать нам все возможности для того, чтобы мы проявили свои творческие способности. Хакдей и хакотоны популярны не случайно — они популярны потому, что позволяют разработчикам творческим путем возродить свою любовь к коду и разработке. На хакотонах разработчики полностью отдаются творчеству, свободные от ограничений своей обычной работы.
Одного хакодея раз в квартал уже хватит, чтобы доставить разработчикам радость. Хотите большего? Устройте тематический хакодей. Выдавайте призы самым творческим и практичным решениям и т.п. Главная задача — дать разработчикам творить, чтобы те, вернувшись к обычной работе, чувствовали в себе силы и дальше разрабатывать и улучшать ваши проекты.
Имейте в виду, что это касается не только разработчиков. Все время от времени хотят заниматься творческой работой. Но по моему опыту, у менеджеров продуктов и дизайнеров для этого куда больше возможностей. Для менеджеров и дизайнеров регулярно устраиваются всевозможные тренинги и конференции, о разработчиках же часто забывают.
Кстати, хакотоны — не единственный способ создать творческую атмосферу, но как первый шаг он проще всего. Также можно пробудить творческую жилку у разработчиков, отправляя их на конференции, разрешая им покупать книги за счет компании, позволяя им делиться идеями о проектах, над которыми они работают. Все знают, например, что Google дает разработчикам 20% рабочего времени на разработку их собственных проектов. Все это может привести к началу долгой и продолжительной дружбы с вашими разработчиками.
Учитывая количество часов умственных усилий, которые мы регулярно тратим во время работы, становится понятно, что разработчикам нужно не забывать делать перерыв. К сожалению, мы редко достигаем особых успехов в планировании своего времени. Бывает, мы настолько погружаемся в работу, что забываем об отпуске. За первые пять лет своей карьеры, я взял в общей совокупности, кажется, семь дней отпуска. Не знаю почему, но мы плохо умеем снимать свой стресс — и в этом большая проблема.
Выгорание разработчиков уникально в том смысле, что мы привыкли работать в таком состоянии. Но стоит выгоранию достигнуть своего пика, и мы увольняемся и уходим искать другую работу. Более того, почти никто из разработчиков никогда не скажет вам, что у них нет сил терпеть; у них слишком большая гордость для этого. В моей прошлой команде я говорил всем разработчикам, чтобы они тут же шли ко мне, как только почувствуют, что их все достало. Я не хотел, чтобы они терпели до тех пор, пока единственным выходом для них станет увольнение. Мне было нужно, чтобы они не увольнялись и наслаждались работой, и единственный способ добиться этого — понять, когда они начнут выгорать.
Поощряйте разработчиков брать отпуска. Ваша компания предоставляет определенное время под отпуск — так проследите за тем, чтобы разработчики его брали, как минимум один раз в 4-5 месяцев. Лучше всего, если этим займутся менеджеры, которые следят за графиком проекта.
Регулярный отдых во время отпуска дает разработчикам возможность восстановить свои творческие силы, избавляя их от постоянно нависающих дедлайнов. Да, во время отпуска мы наверняка тоже займемся разработкой, но заниматься мы будем исключительно нашими проектами, а не рабочими. Такая работа поможет нам набраться энергии и подготовит к новым битвам.
Как бы иронично это не звучало, но многие компании нанимают разработчиков, а потом не дают им заниматься разработкой. Вместо этого их дни заполняют бесполезными совещаниями, подрывающими производительность. Вообще разработчики наиболее эффективны тогда, когда могут просидеть над кодом как минимум четыре часа не отвлекаясь.
Войти в хороший «поток» во время программирования всегда сложно, когда знаешь, что тебе через пару часов нужно быть на совещании. Для процесса разработки нет ничего более непродуктивного, чем процесс, во время которого ты вначале пишешь код час, потом прерываешься на час, потом снова пишешь код час, прерываешься еще на час и т.д. Мозгу разработчика нужно некоторое время, чтобы переключиться в «правильное» состояние для программирования.
Постарайтесь убедиться, что у разработчиков есть как минимум четыре часа в день на беспрерывное программирование. Только так можно ускорить разработку. Вполне логично: если люди работают по восемь часов в день, то хотя бы половину этого времени они должны тратить на свои основные задачи. Я, например, выяснил, что для меня самый продуктивный период — это время между одним и пятью часами дня. Если бы я мог работать в это время каждый день, я бы с легкостью справлялся со всеми моими задачами. В дни, когда это время прерывается совещаниями, я понимаю, что много сделать мне сегодня не получится.
И хотя бы один день в неделю обходитесь совсем без совещаний, включая ежедневные летучки. Пусть у разработчиков будет один день, в который они могут самостоятельно распределить свое время и расправиться со всеми делами. Вы не поверите, сколько всего можно успеть за день, полностью свободный от отвлекающих факторов. В свое время мой менеджер даже требовал, чтобы я работал из дома хотя бы два дня в неделю, потому что в офисе меня постоянно отвлекали. В результате я работал с невероятной скоростью.
Кое-что можно сделать уже прямо сейчас, добившись при этом значительных результатов. Я уже упоминал выше о том, как бесит, когда ты только закончил задачу, а на нее уже начали выписывать баги. У разработчиков редко выпадает шанс откинуться на спинку стула и полюбоваться выполненной работой, не говоря уж о том, чтобы услышать при этом слова благодарности.
Маленькое письмо со словами благодарности разработчику, только что завершившему задачу, способно добиться невероятных успехов, особенно если задача была сложной. Даже если вы просто скажете: «Слушай, спасибо за работу, я обязательно посмотрю», этого будет достаточно, чтобы снять угрюмое настроение, возникающее при появлении первого потока багов. Разработчикам очень важно, чтобы их работу ценили, ведь большая часть получаемых ими отзывов носят негативный характер — баги, проблемы и т.д. Пара добрых слов, и это все уже не кажется таким страшным.
Совсем здорово будет, если вы назначите что-то вроде награды, которую будут выдавать каждый квартал разработчику, который внес больше всего усилий, внедрил больше всего улучшений и т.п. Награда не должна быть обязательно чем-то дорогим и желанным вроде iPad'а (хотя мы с благодарностью примем и его), это может быть просто маленький подарок и письмо с признанием заслуг всей команде или отделу.
И, пожалуйста, когда благодарите людей за выполненную работу, никогда не забывайте о разработчиках. Я побывал на бесчисленном количестве совещаний по проектам, на которых все восхищались работой менеджеров или дизайнеров, при этом совершенно забывая о разработчиках, чьи пот, кровь и слезы воплотили проект в жизнь. Успех каждого проекта зависит от усилий каждой из трех групп, ни одна группа в одиночку не может его выполнить. Проследите за тем, чтобы ваша компания признавала усилия всей команды, а не какой-то из ее частей.
Мы, разработчики, как правило, незаурядные люди. Мы все определенно являемся личностями, и мы правда хотим достичь как можно лучшего результата из возможных. Если вы перестанете относиться к нам как к мальчикам на побегушках и начнете уважать нас как часть творческого процесса, то вы добьетесь отличного результата в короткие сроки. В командах, в которых я работал, всегда были те или иные трения, возникавшие из-за непонимания способа мышления и мотивации разработчиков. Я искренне надеюсь, что эта статья поможет улучшить взаимодействие между разработчиками и их коллегами. Это ведь не так сложно — нам всего-то нужно чувствовать себя частью общего решения, а не обычной рабочей пчелой.
Автор оригинальной статьи — Nickolas C. Zakas, известный фронтенд разработчик и JavaScript-евангелист в свое время проработавший более пяти лет в Yahoo. Это запись из его блога, в которой он говорит о том, почему с разработчиками так сложно договориться и что с этим делать.
Не так давно Дженна Байлотта написала замечательную статью «Как дизайнерам ужиться с разработчиками», в которой она описывает методы работы в команде, позволяющие дизайнерам и разработчикам добиться лучшей производительности. Я в свое время работал с дизайнерами (а, работая в UI, и с разработчиками) и столкнулся с похожими проблемами, так что мне понятен ее практичный подход. Во время командной работы никогда не помешает уважать труд своих коллег и понимать их способ мышления.
Одна из главных мыслей той статьи заключалась в том, что разработчики говорят «нет» слишком быстро. Эта мысль тут же въелась мне в мозг и долго отказывалась вылезать оттуда. Мне хотелось воскликнуть: «Но подожди, ты же не понимаешь, почему мы говорим „нет“!». Тут же появился миллион других защитных аргументов. На самом деле она, конечно, права — мы правда слишком быстро говорим «нет», причем не только дизайнерам, а вообще всем. Это побудило меня поразмыслить над психологией разработчиков и тем, что составляет нашу истинную суть.
Наша репутация
Давайте начистоту, у нас, разработчиков, репутация таких гордых спорщиков с регулярными перепадами настроения. Мы постоянно говорим «нет», уточняем детали до неприличного педантизма и считаем, что можем выполнить работу любого из наших нетехнических коллег намного лучше их самих. И, чего уж там, этот стереотип во многом соответствует истине — именно этим мы и занимаемся день за днем, в перерывах между написанием кода и чтением Твиттера с Hacker News.
(Примечание: Кто-то из вас скажет, что не все разработчики такие, и будет прав. Есть маленький процент разработчиков, которых нельзя причислить к вышеуказанной категории. Не торопитесь пока листать вниз и писать в комментариях о том, что автор идиот, читайте дальше.)
Репутацию никто просто так не выдает, ее зарабатывают. Что удивляет меня в этой репутации, так это то, что я лично знаю кучу разработчиков, и, как правило, это доброжелательные, приятные (если с ними не упрямиться) и просто веселые парни. С ними можно отлично провести время после работы или на выходных. Так почему же на работе они становятся совсем другими людьми?
Мы творцы, а не строители
У меня есть теория. Она заключается в том, что разработчики видят себя совсем не так, как их коллеги. Я пришел к этому выводу за десять с лишним лет работы в крупных и мелких компаниях, занимающихся разработкой ПО. Сотрудники таких компаний (менеджеры продуктов, дизайнеры, прочие менеджеры) обычно смотрят на разработчиков как на простых строителей. Менеджер продукта должен придумать оригинальную идею, дизайнер должен выразить ее в красивой форме, а разработчик должен только воплотить эти идеи в жизнь. По сути на инженеров смотрят как на мальчиков на побегушках, делающих точно то и только то, что им сказали.
Об этом меня предупреждал еще мой первый менеджер. Когда первая компания, в которой я работал, развалилась, у нас состоялся весьма откровенный разговор о моей будущей карьере. Хотя мы не всегда ладили, он дал тогда мне великолепный совет (далее неточная цитата):
Николас, ты стоишь большего, чем код, который ты пишешь. Где бы ты дальше не работал, никогда не позволяй, чтобы к тебе относились, как к мальчику на побегушках. Не соглашайся на работу, если тебе точно сказали, что нужно сделать и как. Тебе нужно работать там, где ценят не только то, что ты можешь сделать продукт, но и то, как ты можешь его улучшить.
Он был совершенно прав. Существует множество компаний, которым нужны мальчики на побегушках, им нужны строители, которые будут писать код по четко заданному шаблону без права сделать шаг в сторону. Я бы даже сказал, что таковы большинство компаний, как крупных, так и мелких. Я давно сбился со счета, сколько основателей стартапов предлагали мне долю в компании в обмен на воплощение в жизнь их авторского видения. Все они исходят из того, что идеи у них уже есть, им нужен только тот, кто воплотит их в жизнь.
И вот тут зарыт главный корень проблемы — разработчики на самом деле не послушные строители. Разработчики — творцы. Вы сами в каком-то смысле занимаетесь сборкостроительством всякий раз, когда собираете мебель из Икеи. У вас на руках все инструкции, и, если следовать им шаг за шагом, вы соберете тот до смешного маленький столик, который вы так хотели. Творчество — это совсем другая работа, это создание чего-то без конкретных направлений или инструкций. Вы начинаете с чистого холста, а заканчиваете произведением искусства. Разработчики так любят программирование не потому, что они хотят исполнять чьи-то инструкции, а потому, что поняли, что могут при помощи него делать разные интересные штуки. Мы все влюбились в процесс разработки, потому что когда-то написали скромное, но полезное приложение, и нас зацепило.
В триумвирате разработки ПО, состоящем из менеджеров продуктов, дизайнеров и разработчиков, только от разработчиков требуют отключить свою творческую жилку и заняться обычным производством. Но разработчики вовсе не тупые, они прекрасно чувствуют такое отношение, и в них начинает проявляться недовольство. Разработчики хотят быть частью общего творческого процесса, а их этого лишают. И вот уже совершенно нормальный разработчик превращается в хронического ворчуна.
Эй, так в чем проблема?
Менеджеры продуктов, как правило, незаурядные люди. Их идеи и способность чувствовать тенденции рынка впечатляют. Но у них также есть свойство считать свои идеи совершенно лишенными просчетов, в то время как на самом деле в них есть дыры, через которые может проехать целый поезд. Я говорю это с большой нежностью, некоторые менеджеры продуктов мои хорошие друзья, и, конечно же, я не раз говорил им об этом в лицо. Я ни в коем случае их не критикую, это просто их суть. Они занимаются творческой работой, и редкая идея рождается идеальной. И вот от этого-то как раз разработчики и становятся ворчунами.
Как разработчики, так и менеджеры продуктов часто неверно считают, что требования или спецификация продукта аналогичны готовым частям мебели из Икеи. На самом деле эти документы редко содержат достаточно информации, чтобы по ним можно было собрать полноценный продукт. Как правило, это просто отправная точка — и это предоставляет разработчику уникальную проблему для решения.
Для того, чтобы понять эту проблему получше, давайте рассмотрим задачу строительства дома. Допустим, кто-то решил построить дом на определенном участке земли. У дома должно быть два этажа и гараж. У нас даже есть грубая схема передней части дома, начерченная на салфетке. И вот клиент подходит к вам со всей этой информацией и салфеткой и спрашивает: «Тебе же этого хватит, чтобы приступить к строительству, да?» И как вам, хватит?
Если рассуждать логически, то приступать к строительству никак нельзя. Вы не знаете метраж, у вас нет плана этажей, вы даже не представляете, какие требования город предъявляет к строительству новых домов. У вас не хватает информации даже для того, чтобы начать копать землю под фундамент. Единственное логическое решение — сказать клиенту, что он псих и должен вначале точно решить, что именно ему нужно. А теперь представьте, что вы не можете этого сделать, потому что кто-то поставил дедлайн, и вам кровь из носа нужно к нему успеть.
— Ну… — говорит вам клиент, — давай ты пока начнешь строить; а я буду по мере возможности сообщать тебе новую информацию. Так мы не будем тратить время впустую.
Вы точно знаете, что информации для того, чтобы строить, не хватает, а дальнейшие расспросы клиента ничего пока не дадут. Но дедлайн никто отменять не собирается и вы никак не можете себе позволить просиживать штаны в надежде на то, что клиент расщедрится на детали. И что вам остается? Делать предположения и допущения.
Старая поговорка гласит: «when you assume, you make an ass of u and me» (когда делаешь предположения, выставляешь идиотами нас обоих), и это чистая правда. Предположения опасны и очень часто лживы. И все же без предположений запустить проект не получится. Итак, что вы делаете. Вы начинаете с допущения, в истинности которого вы точно уверены — о том, что у дома будет два этажа и гараж. Тут же вопрос — гараж надо делать пристройкой или отдельно? И какого размера нужно его делать? Не будем усложнять, допустим, что гараж должен быть построен отдельно и рассчитан на одну машину. Теперь можно работать над гаражом как над отдельным зданием, а потом, когда станут известны подробности о доме, его можно будет строить рядом с гаражом.
Спустя неделю работы над гаражом, клиент сообщает вам новые подробности. Оказывается, у дома должно быть три этажа (уф, хорошо, что мы еще не начали строить дом) и восемь ванных. Информации по гаражу пока нет, но дом должен быть покрашен в синий цвет. Вы делаете вывод, что гараж тоже должен быть синим, и приступаете к его покраске.
Спустя еще несколько дней гараж почти закончен. Вы довольны качеством результата, ведь у вас было так мало информации! Вы уже готовы приступить к строительство дома, когда клиент сообщает новые подробности — гараж должен быть рассчитан на две машины и пристроен к дому. У вас трагедия — вы сделали такой крутой гараж, а теперь его придется снести, чтобы построить «нужный». Хуже того, теперь у вас остается меньше времени, чтобы закончить весь проект — и вот вы уже начинаете ворчать.
Если эта аналогия кажется вам безумной, вы явно никогда не работали разработчиком. Мы наблюдаем такое каждый первый день. Мы пытаемся держать проекты на плаву, используя все наши творческие силы, а в итоге получается, что мы не смогли прочитать чужие мысли и неверно угадали, что именно мы строим. Но, если бы мы этого не делали, мы бы просто ждали, тратя время впустую — а, как известно, у каскадной модели разработки не так много поклонников.
Почти в каждой индустрии, где нужно что-то строить, ожидается, что все требования и пожелания будут определены и утверждены до начала строительства. Но не в разработке ПО. При разработке ПО вечно «не хватает времени», чтобы собрать все требования заранее. Нам изо дня в день твердят о том, что нужно двигаться вперед — вот и приходится разработчикам, чтобы двигать проект, учиться заполнять дыры, оставленные менеджерами продуктов. Не стоит забывать и о том, что менеджеры продуктов славятся своей любовью постоянно менять свое мнение, от чего предположения разработчиков зачастую становятся неверными на полпути.
И кто-то еще удивляется, что разработчики так быстро «выгорают» и меняют работу?
Главные приоритеты
Главный враг любого творца — это смена контекста. Как только вы вошли в глубокий творческий режим, так называемый «поток», любое внешнее вмешательство тут же рушит весь процесс. Да, написание кода — тоже творческий процесс, одновременно творческий и логический. Мы не просто пишем код, мы его создаем.
Среди людей, занимающихся управлением времени разработчика, бытует мнение, что переключаться с одного задания на другое для них — плевое дело. Они утверждают, что рабочее время — оно и в Африке рабочее время. Вы просто тратите достаточное его количество на нужную задачу, и, вуаля — вот и результат. Конечно же это не так. Если вы сидите уже второй день над одной задачей, а вас перевели на другую, то вы потом уже не сможете просто так вернуться к тому месту, где закончили. Вам придется потратить определенное время, чтобы включиться в контекст, такова цена за его смену. Даже если другое задание займет всего пару минут, это уже нарушит «поток» и снизит производительность разработчика.
Это одна из главных проблем, от которых ворчат разработчики — постоянная смена приоритетов. Сегодня у нас один главный приоритет, завтра другой — это приводит к неизбежной смене контекста. Творческие люди не любят, когда их отрывают на середине дела, именно поэтому многие разработчики готовы с удовольствием писать до самого утра, только чтобы завершить свою работу. Смена контекста делает их менее производительными.
Но по-настоящему важные приоритеты никогда не меняются, они постоянны. Частота же, с которой люди вокруг нас меняют свое мнение, ужасно бесит разработчиков. Вообще мы постоянно находимся в состоянии боевой готовности и только ждем, когда нам укажут на противника. Но если сегодня вы требуете от нас построить дом, а завтра — переделать его в автомобиль, не удивляйтесь, если почувствуете растущее недовольство в строю.
Страшный изъян разработчиков
Разработчиков постоянно ставят в трудное положение, но при этом мы не являемся жертвами, хоть самые истеричные из нас и норовят выставить себя оными. Часть нашей ворчливости идет изнутри, это связано с причиной, зашитой глубоко внутри большинства разработчиков. У нас есть ужасный изъян, и заключается он в том, что мы переоцениваем свои знания и возможности.
Этот изъян проявляется по-разному, но чаще всего при оценке времени на задачу. Почти все из моих знакомых разработчиков хронически недооценивают время, которое им нужно потратить на ту или иную задачу. Только самые лучшие из нас способны поставить себе срок и уложиться в него. Большинство обычно ошибаются раза в два, а то и больше. Это происходит из-за того, что, как и любые другие творческие люди, разработчики часто не могут заранее предвидеть все проблемы, с которыми им придется столкнуться.
Даже несмотря на то, что многие разработчики жалуются, что менеджеры продуктов меняют свое мнение, почти никто из них не берет это в расчет во время оценки времени на задачу. Никто не учитывает время на совещания, уточнение требований и возможные изменения. Баги? Да в нашем идеальном коде их и быть не может, тут и беспокоиться не нужно (а если вдруг что, то тестеры же все отыщут, да?). Важные для проекта люди уйдут в отпуск или заболеют? Ничего страшного, кто-нибудь обязательно их заменит.
Все это прямой дорогой ведет к срыву сроков, но ничто так сильно не задерживает проект, как то, что разработчики не учитывают время на изучение проблемной области. Это напрямую связано с нашим главным недостатком. Мы думаем, что уже знаем все, что нам нужно для выполнения задачи, хотя нам часто приходится работать с технологиями, которые мы видим в первый раз в своей жизни. Сроки, которые мы определяем, подразумевают идеальные знания, с которыми мы можем писать ПО как будто бы по икеевской инструкции. На деле же многие задачи требуют от нас детального изучения их подноготной.
Разработчики, закончившие вуз по специальности, получают после его окончания ложное чувство безопасности. Они мнят себя знатоками ПО и всего процесса разработки, когда на самом деле их знания чуть выше нулевых. Когда я вышел на первую работу, я был таким же гордым выпускником, указывающим всем на их ошибки. Только спустя годы я понял, что на самом деле ничего не знал.
Компьютерные вузы не готовят вас к испытаниям, которые ждут вас в индустрии. Они в первую очередь дают вам концептуальные знания по большому спектру тем, чтобы вы потом не опозорились, столкнувшись с ними во время настоящей работы. Вас учат переменным, функциям и объектам, так как именно с ними вы будете работать большую часть своего времени. Вас учат базам данных и запросам к ним (хотя нормальные формы окажутся бесполезными на практике). Вы тратите ненормально большую часть времени на изучение алгоритмов сортировки и структур данных, которые во время профессиональной разработки будут скрыты от вас под слоем абстракций. Короче, компьютерные вузы рассматривают решение проблем, которые вам на практике никогда не придется решать. Если мне нужно что-нибудь отсортировать, я просто вызову метод sort(). Если мне нужна очередь или связанный список, я использую нативную реализацию языка, на котором я пишу. Все эти проблемы уже решены за меня.
Выпускаясь из университетов, мы считаем, что умеем делать все на свете, хотя на самом деле мы умеем делать только то, что уже было сделано до нас, да и то лишь крошечную его часть. Но при этом мы ведем себя как напыщенные всезнайки и, считая наши знания идеальными, определяем слишком короткие сроки разработки, не думая о том, что нам придется изучать что-то новое.
Частично эта проблема возникает из-за нашего такого хрупкого самолюбия. Мы боимся, что если мы установим слишком длинные сроки, то люди поставят под сомнение нашу компетентность. Нам говорят, что «хорошие разработчики» должны работать быстро, и мы с этим поневоле соглашаемся. Меня всегда поражали ситуации, в которых разработчики вначале определяют срок проекта, а потом кто-нибудь из их руководителей начинает жаловаться, что это слишком много. Во-первых, как я уже заметил, срок и так скорее всего слишком маленький. Во-вторых, разработчик должен лучше менеджера знать, сколько времени потребуется на разработку, не так ли? И это приводит к еще одной проблеме.
Раньше я тоже программировал
Мало какая фраза может так сильно вывести разработчика из себя, как «Раньше я тоже программировал». Кто бы ее не сказал, менеджер продукта, дизайнер или кто-то из руководства, использование ее как доказательства своей правоты приводит только к презрению со стороны разработчика. Если бы я спросил у Леброна Джеймса (известный баскетболист), сколько времени он тренируется перед игрой, то он бы очень удивился, начни я давать ему советы только потому, что я играл в баскетбол в школе. Разработчиков поучают таким образом постоянно.
Вот лишь некоторые примеры невежества, произнесенного менеджерами в моем присутствии:
Я не понимаю, разве это такая большая проблема? Тут всего-то пару строк кода дописать.
Технически любая проблема решается «дописыванием пары строк кода». Легче от этого она не становится.
N говорит, что на эту задачу хватит пары дней.
Да, потому что N уже досконально знает ее проблемную область. Я не знаю, мне нужно время на ее изучение.
Что мы можем сделать, чтобы ускорить процесс? Выделить еще разработчиков?
Увеличение числа разработчиков, занятых проблемой, как правило ее только усугубляет. Единственный способ сделать что-то быстрее — начать с более мелких проблем.
Но худшее, что можно сделать — это сказать разработчикам, что вы когда-то тоже программировали. Обратите внимание, это совсем не то же самое, что быть в прошлом профессиональным разработчиком. Разработчик, ставший менеджером, как правило сохраняет какие-то навыки в течение конечного периода (как правило это пять лет, дальше технологии уже полностью меняются). Но тем, кто никогда не занимался профессиональной разработкой ПО, лучше держать свое хобби при себе, чем использовать его как доказательство своей правоты.
(Если по справедливости, то дизайнеры тоже страдают от такого невежества. Все считают себя специалистами по дизайну, потому что всем нравятся красивые штуки. Но это не делает вас профессиональным дизайнером.)
Больше нянек
Разработчики постоянно сталкиваются с проблемой «семи нянек в команде». Так как мы постоянно занижаем реальные сроки выполнения задач, большая часть ПО выходит с опозданием. Независимо от того, идет ли речь о крупных компаниях или мелких компаниях, никому неизвестных стартапах или уважаемых продуктах, все они выходят с опозданием. Постоянные опоздания огорчают менеджеров, которые как правило решают, что вся проблема в нехватке разработчиков. «Так давайте выделим еще людей», говорят они — «это решит все наши проблемы».
Иногда, бесспорно, увеличение числа разработчиков может решить проблему. В большинстве случаев их выделение только приводит к дополнительным трудностям. Заставить творческих людей работать в команде и так не просто, а чем больше их в команде, тем сложнее это сделать. Разработчикам не разрешают просто так сидеть без дела — как только менеджеры решают, что им нечем заняться, они тут же придумывают им работу.
Подобное случилось и со мной в совершенно абсурдном виде. Мы разрабатывали новый, с нуля созданный дизайн главной страницы Yahoo одной маленькой командой. Это был идеальный проект, мы небольшой группой проектировали базовую архитектуру страницы, и никто нам не мешал. Мы закончили проектирование, и готовы были приступить к разработке прототипа, как нам выделили восемь новых разработчиков. Более того, нам дали указания, чтобы эти разработчики тут же приступили к программированию новой страницы. Что было той еще задачей, ведь архитектуры в конечном виде еще не существовало! Но разработчиков нельзя оставлять без дела, их назначили на проект, значит им нужно дать задачу. Классическая проблема о курице и яйце.
В идеальной ситуации мы бы вначале закончили прототип архитектуры, и уже потом бы получили дополнительных разработчиков для ее внедрения. На деле же мы застряли. В итоге я решил использовать уже готовую архитектуру из другого проекта, написав для нее простенький интерфейс, через который можно было обращаться к ней как к новой. Разработчики смогли приступить к своей работе, а мы смогли продолжить разработку архитектуры. Это было ужасным решением ужасной проблемы, которое в итоге перестало работать, когда разработчики добрались до той части интерфейса, которая еще не была реализована. В итоге мне пришлось сказать нашему менеджеру, что если нам не дадут время закончить новую архитектуру, то наш аккуратный карточный домик быстро разлетится на части.
Слишком большое количество разработчиков в команде может сильно усложнить проект. Конечно, они могут работать над независимыми друг от друга задачами, но, как правило, количество таких задач в любом проекте не так велико. Чем больше в проекте занято разработчиков, тем больше времени тратится не на разработку, а на планирование и организацию командной работы. Если вернуться к метафоре строительства дома, то нельзя строить второй этаж до того, как построишь первый. Большинство задач по разработке ПО выполняются строго по очереди, поэтому выделение дополнительного числа разработчиков никак не ускорит процесс разработки. Как говорил один из моих бывших коллег, сколько бы женщин у вас не было, ребенка родить раньше девяти месяцев не получится (на самом деле известная цитата из книги Фреда Брукса «Мифический человеко-месяц»).
Ворчание по-крупному
Итак, каждый день нам приходится сталкиваться с недостатком информации, меняющимися требованиями, недостаточным пониманием проблемной области и угадывающими наши мысли коллегами. Как творческие люди, мы миримся со всем этим только потому, что результат нашей работы будут использовать живые люди. Вот главный мотиватор разработчиков — мысль о том, что жизнь людей, которых мы даже не знаем, поменяется благодаря нашим стараниям, независимо от того, работаем ли мы над сайтом с миллионом посещений в день или системой продаж для сети ресторанов.
Повторяю еще раз — разработчики «выгорают» не потому, что работа тяжелая, а потому, что указания постоянно меняются, а дата релиза задерживается.
Когда релиз задерживается потому, что кто-то снова поменял свое решение, мы превращаемся в жутких ворчунов. Безумных ворчунов. Нашей мечте, довести результат своих усилий до конечного пользователя, снова помешали осуществиться — нет хуже демотиватора. Что удивительно, разработчики редко бывают перфекционистами. Мы согласны с тем, что лучшее враг хорошего, и готовы выкладывать нашу работу постепенно, чтобы потом объединить ее в одно большое целое. Почему? Потому что только так можно вовремя выложить нашу работу людям.
Нет, мы понимаем, что задержки — это неотъемлемая часть процесса разработки ПО. Разработчики готовы работать за десятерых, только бы успеть к установленным ими срокам. Мы готовы работать по двенадцать часов в сутки, пусть это только приведет к нормальному результату.
Сказать спасибо? Еще чего
Работая разработчиками, мы привыкаем к режиму работы, кардинально отличающемуся от режимов других сотрудников. Когда на сервере или в сборке что-нибудь ломается, среди ночи будят не дизайнера с менеджером, а разработчика (хотя я знаком с менеджерами, которые требуют, чтобы их тоже будили). Как-то раз мне позвонили прямо тогда, когда я собирался уйти с девушкой на свидание. Моя пара сидела и терпеливо ждала меня целый час, пока я безуспешно пытался исправить проблему. В итоге она ушла (я не могу ее винить), оставив меня страдать наедине с работой и коллегами в IRC-клиенте.
При этом мало кто из разработчиков сильно жалуется на длинный рабочий день или на то, что его разбудили ночью из-за очередного бага. Наш проект для нас как ребенок, и мы готовы заботиться и ухаживать за ним. Если в два часа ночи его нужно покормить, нет проблем. Если на выходных ему нужно уделить время, мы всегда найдем его, при этом улыбаясь, глядя на то, как наше творение растет.
Разработчики особенно рады, когда им дают возможность самим завершить задачу. Ничто не может для них сравниться с удовольствием от отправки письма о том, что задача выполнена и готова пройти ревью. Но их радость тут же улетучивается, когда спустя 10 минут после коммита на их свежесозданное детище начинают записывать баги.
Представьте себя на их месте. Вы потратили целый день (или неделю (или месяц)) на выполнение задачи и справились с ней. Вас переполняет чувство гордости от выполненной работы, которая возможно потребовала от вас знаний, которыми вы раньше не обладали. Все, чего вы хотите — это откинуться на спинку кресла и полюбоваться своими достижениями. Еще лучше, если кто-нибудь похвалит вас за выполненную работу. И что вы получаете? Сообщения о багах. Это не работает, то не так работает, и т.п. Приходится в расстроенных чувствах приступать к работе над ошибками.
Почему мы говорим «нет».
Подводя общий итог всему вышесказанному, давайте выделим основные причины, по которым разработчики говорят «нет» (или просто ворчат):
- Новое требование появилось под самый конец разработки, и времени на его реализацию совсем нет;
- Новое требование противоречит тем предположениям, которые мы сделали ранее, чтобы не тормозить проект;
- Новое требование полностью противоречит предыдущим;
- Новое требование другим способом увеличивает количество работы, которую нужно выполнить, уложившись в сроки;
- Мы так сильно устали, что любое новое требование кажется нам невероятно сложным в реализации, и мы категорически не хотим его выполнять.
Имейте в виду, что каждая из этих проблем, за исключением первой, связаны с условиями работы в сжатые сроки. Мы хотим завершить к дедлайну все задачи — а как это сделать, когда они постоянно меняются во время нашей работы? Когда такое происходит, нашему недовольству (и ворчанию) нет предела, а «нет» вылетает еще до того, как вы успеваете закончить предложение.
Кормление и уход
Так как же менеджерам справиться с этой ворчливостью на практике? Давайте еще раз вспомним, что движет разработчиками:
- Желание творить;
- Желание решать задачи;
- Желание увидеть результат нашей работы в деле.
А теперь подумайте, чего в этом списке нет. Денег. Увеличение денежного вознаграждения редко удовлетворяет разработчиков. Звучит как пошлый штамп, но для разработчиков правда дело не в деньгах. Деньги дают им возможность жить в свое удовольствие, но в душе их в первую очередь интересует сам процесс разработки. И чаще всего главное, что им нужно — это возможность заниматься им в нормальных рабочих условиях.
Так как же создать нормальные рабочие условия для разработчиков?
Работайте вместе с ними
Разработчики такие же творческие люди, как и менеджеры продуктов с дизайнерами, поэтому нужно позаботиться о том, чтобы включить их в творческий процесс. Разработчикам нет равных во время мозговых штурмов и совещаний по обсуждению требований. Дайте разработчикам возможность встретиться с проектной командой и поработать напрямую с ними (но не обязательно всем сразу). Иными словами, включите разработчиков в творческий процесс как можно раньше. Никто не любит, когда в него без объяснений швыряют документами со спецификациями.
Разработчики до предела логичны, поэтому их присутствие на ранних совещаниях поможет им понять, на чем основываются требования, и решить многие проблемы еще до их появления. Когда к разработчикам относятся, как к строителям, они постоянно задают вопросы, и это замедляет процесс разработки. Когда к разработчикам относятся, как к коллегам по творческому цеху, у них появляется меньше вопросов, и разработка движется быстрее.
Также важно то, что разработчики очень часто лучше знают, что можно сделать, а что нельзя. Например, фронтенд разработчики узнают о том, что можно реализовать в браузере задолго до остальных. Поделившись этими знаниями с остальными, мы можем спровоцировать рождение новых идей о том, как улучшить продукт, исходя из наших возможностей. Представьте, что вы придумываете сайт для выкладывания фотографий и не знаете, что их можно кидать прямо с рабочего стола в браузер? Как бы это повлияло на его дизайн?
Итак, дайте возможность разработчикам участвовать в творческом процессе с самого начала проекта. Выслушайте их мнение о проекте и о том, что технически возможно реализовать. Чем меньше нам кажется, что нам говорят, что делать, тем больше мы прислушиваемся к чужому мнению и лучше выполняем свою работу. Единственный способ этого добиться — дать нам поучаствовать в творческой работе над проектом.
Создайте творческую атмосферу
Давайте еще подумаем о разработчиках как о творцах. Попробуйте дать нам все возможности для того, чтобы мы проявили свои творческие способности. Хакдей и хакотоны популярны не случайно — они популярны потому, что позволяют разработчикам творческим путем возродить свою любовь к коду и разработке. На хакотонах разработчики полностью отдаются творчеству, свободные от ограничений своей обычной работы.
Одного хакодея раз в квартал уже хватит, чтобы доставить разработчикам радость. Хотите большего? Устройте тематический хакодей. Выдавайте призы самым творческим и практичным решениям и т.п. Главная задача — дать разработчикам творить, чтобы те, вернувшись к обычной работе, чувствовали в себе силы и дальше разрабатывать и улучшать ваши проекты.
Имейте в виду, что это касается не только разработчиков. Все время от времени хотят заниматься творческой работой. Но по моему опыту, у менеджеров продуктов и дизайнеров для этого куда больше возможностей. Для менеджеров и дизайнеров регулярно устраиваются всевозможные тренинги и конференции, о разработчиках же часто забывают.
Кстати, хакотоны — не единственный способ создать творческую атмосферу, но как первый шаг он проще всего. Также можно пробудить творческую жилку у разработчиков, отправляя их на конференции, разрешая им покупать книги за счет компании, позволяя им делиться идеями о проектах, над которыми они работают. Все знают, например, что Google дает разработчикам 20% рабочего времени на разработку их собственных проектов. Все это может привести к началу долгой и продолжительной дружбы с вашими разработчиками.
Поощряйте отдых
Учитывая количество часов умственных усилий, которые мы регулярно тратим во время работы, становится понятно, что разработчикам нужно не забывать делать перерыв. К сожалению, мы редко достигаем особых успехов в планировании своего времени. Бывает, мы настолько погружаемся в работу, что забываем об отпуске. За первые пять лет своей карьеры, я взял в общей совокупности, кажется, семь дней отпуска. Не знаю почему, но мы плохо умеем снимать свой стресс — и в этом большая проблема.
Выгорание разработчиков уникально в том смысле, что мы привыкли работать в таком состоянии. Но стоит выгоранию достигнуть своего пика, и мы увольняемся и уходим искать другую работу. Более того, почти никто из разработчиков никогда не скажет вам, что у них нет сил терпеть; у них слишком большая гордость для этого. В моей прошлой команде я говорил всем разработчикам, чтобы они тут же шли ко мне, как только почувствуют, что их все достало. Я не хотел, чтобы они терпели до тех пор, пока единственным выходом для них станет увольнение. Мне было нужно, чтобы они не увольнялись и наслаждались работой, и единственный способ добиться этого — понять, когда они начнут выгорать.
Поощряйте разработчиков брать отпуска. Ваша компания предоставляет определенное время под отпуск — так проследите за тем, чтобы разработчики его брали, как минимум один раз в 4-5 месяцев. Лучше всего, если этим займутся менеджеры, которые следят за графиком проекта.
Регулярный отдых во время отпуска дает разработчикам возможность восстановить свои творческие силы, избавляя их от постоянно нависающих дедлайнов. Да, во время отпуска мы наверняка тоже займемся разработкой, но заниматься мы будем исключительно нашими проектами, а не рабочими. Такая работа поможет нам набраться энергии и подготовит к новым битвам.
Пусть разрабатывают
Как бы иронично это не звучало, но многие компании нанимают разработчиков, а потом не дают им заниматься разработкой. Вместо этого их дни заполняют бесполезными совещаниями, подрывающими производительность. Вообще разработчики наиболее эффективны тогда, когда могут просидеть над кодом как минимум четыре часа не отвлекаясь.
Войти в хороший «поток» во время программирования всегда сложно, когда знаешь, что тебе через пару часов нужно быть на совещании. Для процесса разработки нет ничего более непродуктивного, чем процесс, во время которого ты вначале пишешь код час, потом прерываешься на час, потом снова пишешь код час, прерываешься еще на час и т.д. Мозгу разработчика нужно некоторое время, чтобы переключиться в «правильное» состояние для программирования.
Постарайтесь убедиться, что у разработчиков есть как минимум четыре часа в день на беспрерывное программирование. Только так можно ускорить разработку. Вполне логично: если люди работают по восемь часов в день, то хотя бы половину этого времени они должны тратить на свои основные задачи. Я, например, выяснил, что для меня самый продуктивный период — это время между одним и пятью часами дня. Если бы я мог работать в это время каждый день, я бы с легкостью справлялся со всеми моими задачами. В дни, когда это время прерывается совещаниями, я понимаю, что много сделать мне сегодня не получится.
И хотя бы один день в неделю обходитесь совсем без совещаний, включая ежедневные летучки. Пусть у разработчиков будет один день, в который они могут самостоятельно распределить свое время и расправиться со всеми делами. Вы не поверите, сколько всего можно успеть за день, полностью свободный от отвлекающих факторов. В свое время мой менеджер даже требовал, чтобы я работал из дома хотя бы два дня в неделю, потому что в офисе меня постоянно отвлекали. В результате я работал с невероятной скоростью.
Выражайте благодарность
Кое-что можно сделать уже прямо сейчас, добившись при этом значительных результатов. Я уже упоминал выше о том, как бесит, когда ты только закончил задачу, а на нее уже начали выписывать баги. У разработчиков редко выпадает шанс откинуться на спинку стула и полюбоваться выполненной работой, не говоря уж о том, чтобы услышать при этом слова благодарности.
Маленькое письмо со словами благодарности разработчику, только что завершившему задачу, способно добиться невероятных успехов, особенно если задача была сложной. Даже если вы просто скажете: «Слушай, спасибо за работу, я обязательно посмотрю», этого будет достаточно, чтобы снять угрюмое настроение, возникающее при появлении первого потока багов. Разработчикам очень важно, чтобы их работу ценили, ведь большая часть получаемых ими отзывов носят негативный характер — баги, проблемы и т.д. Пара добрых слов, и это все уже не кажется таким страшным.
Совсем здорово будет, если вы назначите что-то вроде награды, которую будут выдавать каждый квартал разработчику, который внес больше всего усилий, внедрил больше всего улучшений и т.п. Награда не должна быть обязательно чем-то дорогим и желанным вроде iPad'а (хотя мы с благодарностью примем и его), это может быть просто маленький подарок и письмо с признанием заслуг всей команде или отделу.
И, пожалуйста, когда благодарите людей за выполненную работу, никогда не забывайте о разработчиках. Я побывал на бесчисленном количестве совещаний по проектам, на которых все восхищались работой менеджеров или дизайнеров, при этом совершенно забывая о разработчиках, чьи пот, кровь и слезы воплотили проект в жизнь. Успех каждого проекта зависит от усилий каждой из трех групп, ни одна группа в одиночку не может его выполнить. Проследите за тем, чтобы ваша компания признавала усилия всей команды, а не какой-то из ее частей.
Заключение
Мы, разработчики, как правило, незаурядные люди. Мы все определенно являемся личностями, и мы правда хотим достичь как можно лучшего результата из возможных. Если вы перестанете относиться к нам как к мальчикам на побегушках и начнете уважать нас как часть творческого процесса, то вы добьетесь отличного результата в короткие сроки. В командах, в которых я работал, всегда были те или иные трения, возникавшие из-за непонимания способа мышления и мотивации разработчиков. Я искренне надеюсь, что эта статья поможет улучшить взаимодействие между разработчиками и их коллегами. Это ведь не так сложно — нам всего-то нужно чувствовать себя частью общего решения, а не обычной рабочей пчелой.
