20 июня 2012 в 14:32

Кормление и уход за разработчиками (или почему мы такие ворчуны) перевод

Прим. переводчика — В оригинале использовался всем знакомый термин «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 говорит, что на эту задачу хватит пары дней.

Да, потому что N уже досконально знает ее проблемную область. Я не знаю, мне нужно время на ее изучение.

Что мы можем сделать, чтобы ускорить процесс? Выделить еще разработчиков?

Увеличение числа разработчиков, занятых проблемой, как правило ее только усугубляет. Единственный способ сделать что-то быстрее — начать с более мелких проблем.

Но худшее, что можно сделать — это сказать разработчикам, что вы когда-то тоже программировали. Обратите внимание, это совсем не то же самое, что быть в прошлом профессиональным разработчиком. Разработчик, ставший менеджером, как правило сохраняет какие-то навыки в течение конечного периода (как правило это пять лет, дальше технологии уже полностью меняются). Но тем, кто никогда не занимался профессиональной разработкой ПО, лучше держать свое хобби при себе, чем использовать его как доказательство своей правоты.

(Если по справедливости, то дизайнеры тоже страдают от такого невежества. Все считают себя специалистами по дизайну, потому что всем нравятся красивые штуки. Но это не делает вас профессиональным дизайнером.)

Больше нянек

Разработчики постоянно сталкиваются с проблемой «семи нянек в команде». Так как мы постоянно занижаем реальные сроки выполнения задач, большая часть ПО выходит с опозданием. Независимо от того, идет ли речь о крупных компаниях или мелких компаниях, никому неизвестных стартапах или уважаемых продуктах, все они выходят с опозданием. Постоянные опоздания огорчают менеджеров, которые как правило решают, что вся проблема в нехватке разработчиков. «Так давайте выделим еще людей», говорят они — «это решит все наши проблемы».

Иногда, бесспорно, увеличение числа разработчиков может решить проблему. В большинстве случаев их выделение только приводит к дополнительным трудностям. Заставить творческих людей работать в команде и так не просто, а чем больше их в команде, тем сложнее это сделать. Разработчикам не разрешают просто так сидеть без дела — как только менеджеры решают, что им нечем заняться, они тут же придумывают им работу.

Подобное случилось и со мной в совершенно абсурдном виде. Мы разрабатывали новый, с нуля созданный дизайн главной страницы Yahoo одной маленькой командой. Это был идеальный проект, мы небольшой группой проектировали базовую архитектуру страницы, и никто нам не мешал. Мы закончили проектирование, и готовы были приступить к разработке прототипа, как нам выделили восемь новых разработчиков. Более того, нам дали указания, чтобы эти разработчики тут же приступили к программированию новой страницы. Что было той еще задачей, ведь архитектуры в конечном виде еще не существовало! Но разработчиков нельзя оставлять без дела, их назначили на проект, значит им нужно дать задачу. Классическая проблема о курице и яйце.

В идеальной ситуации мы бы вначале закончили прототип архитектуры, и уже потом бы получили дополнительных разработчиков для ее внедрения. На деле же мы застряли. В итоге я решил использовать уже готовую архитектуру из другого проекта, написав для нее простенький интерфейс, через который можно было обращаться к ней как к новой. Разработчики смогли приступить к своей работе, а мы смогли продолжить разработку архитектуры. Это было ужасным решением ужасной проблемы, которое в итоге перестало работать, когда разработчики добрались до той части интерфейса, которая еще не была реализована. В итоге мне пришлось сказать нашему менеджеру, что если нам не дадут время закончить новую архитектуру, то наш аккуратный карточный домик быстро разлетится на части.

Слишком большое количество разработчиков в команде может сильно усложнить проект. Конечно, они могут работать над независимыми друг от друга задачами, но, как правило, количество таких задач в любом проекте не так велико. Чем больше в проекте занято разработчиков, тем больше времени тратится не на разработку, а на планирование и организацию командной работы. Если вернуться к метафоре строительства дома, то нельзя строить второй этаж до того, как построишь первый. Большинство задач по разработке ПО выполняются строго по очереди, поэтому выделение дополнительного числа разработчиков никак не ускорит процесс разработки. Как говорил один из моих бывших коллег, сколько бы женщин у вас не было, ребенка родить раньше девяти месяцев не получится (на самом деле известная цитата из книги Фреда Брукса «Мифический человеко-месяц»).

Ворчание по-крупному

Итак, каждый день нам приходится сталкиваться с недостатком информации, меняющимися требованиями, недостаточным пониманием проблемной области и угадывающими наши мысли коллегами. Как творческие люди, мы миримся со всем этим только потому, что результат нашей работы будут использовать живые люди. Вот главный мотиватор разработчиков — мысль о том, что жизнь людей, которых мы даже не знаем, поменяется благодаря нашим стараниям, независимо от того, работаем ли мы над сайтом с миллионом посещений в день или системой продаж для сети ресторанов.

Повторяю еще раз — разработчики «выгорают» не потому, что работа тяжелая, а потому, что указания постоянно меняются, а дата релиза задерживается.

Когда релиз задерживается потому, что кто-то снова поменял свое решение, мы превращаемся в жутких ворчунов. Безумных ворчунов. Нашей мечте, довести результат своих усилий до конечного пользователя, снова помешали осуществиться — нет хуже демотиватора. Что удивительно, разработчики редко бывают перфекционистами. Мы согласны с тем, что лучшее враг хорошего, и готовы выкладывать нашу работу постепенно, чтобы потом объединить ее в одно большое целое. Почему? Потому что только так можно вовремя выложить нашу работу людям.

Нет, мы понимаем, что задержки — это неотъемлемая часть процесса разработки ПО. Разработчики готовы работать за десятерых, только бы успеть к установленным ими срокам. Мы готовы работать по двенадцать часов в сутки, пусть это только приведет к нормальному результату.

Сказать спасибо? Еще чего

Работая разработчиками, мы привыкаем к режиму работы, кардинально отличающемуся от режимов других сотрудников. Когда на сервере или в сборке что-нибудь ломается, среди ночи будят не дизайнера с менеджером, а разработчика (хотя я знаком с менеджерами, которые требуют, чтобы их тоже будили). Как-то раз мне позвонили прямо тогда, когда я собирался уйти с девушкой на свидание. Моя пара сидела и терпеливо ждала меня целый час, пока я безуспешно пытался исправить проблему. В итоге она ушла (я не могу ее винить), оставив меня страдать наедине с работой и коллегами в IRC-клиенте.

При этом мало кто из разработчиков сильно жалуется на длинный рабочий день или на то, что его разбудили ночью из-за очередного бага. Наш проект для нас как ребенок, и мы готовы заботиться и ухаживать за ним. Если в два часа ночи его нужно покормить, нет проблем. Если на выходных ему нужно уделить время, мы всегда найдем его, при этом улыбаясь, глядя на то, как наше творение растет.

Разработчики особенно рады, когда им дают возможность самим завершить задачу. Ничто не может для них сравниться с удовольствием от отправки письма о том, что задача выполнена и готова пройти ревью. Но их радость тут же улетучивается, когда спустя 10 минут после коммита на их свежесозданное детище начинают записывать баги.

Представьте себя на их месте. Вы потратили целый день (или неделю (или месяц)) на выполнение задачи и справились с ней. Вас переполняет чувство гордости от выполненной работы, которая возможно потребовала от вас знаний, которыми вы раньше не обладали. Все, чего вы хотите — это откинуться на спинку кресла и полюбоваться своими достижениями. Еще лучше, если кто-нибудь похвалит вас за выполненную работу. И что вы получаете? Сообщения о багах. Это не работает, то не так работает, и т.п. Приходится в расстроенных чувствах приступать к работе над ошибками.

Почему мы говорим «нет».

Подводя общий итог всему вышесказанному, давайте выделим основные причины, по которым разработчики говорят «нет» (или просто ворчат):
  • Новое требование появилось под самый конец разработки, и времени на его реализацию совсем нет;
  • Новое требование противоречит тем предположениям, которые мы сделали ранее, чтобы не тормозить проект;
  • Новое требование полностью противоречит предыдущим;
  • Новое требование другим способом увеличивает количество работы, которую нужно выполнить, уложившись в сроки;
  • Мы так сильно устали, что любое новое требование кажется нам невероятно сложным в реализации, и мы категорически не хотим его выполнять.

Имейте в виду, что каждая из этих проблем, за исключением первой, связаны с условиями работы в сжатые сроки. Мы хотим завершить к дедлайну все задачи — а как это сделать, когда они постоянно меняются во время нашей работы? Когда такое происходит, нашему недовольству (и ворчанию) нет предела, а «нет» вылетает еще до того, как вы успеваете закончить предложение.

Кормление и уход

Так как же менеджерам справиться с этой ворчливостью на практике? Давайте еще раз вспомним, что движет разработчиками:
  • Желание творить;
  • Желание решать задачи;
  • Желание увидеть результат нашей работы в деле.

А теперь подумайте, чего в этом списке нет. Денег. Увеличение денежного вознаграждения редко удовлетворяет разработчиков. Звучит как пошлый штамп, но для разработчиков правда дело не в деньгах. Деньги дают им возможность жить в свое удовольствие, но в душе их в первую очередь интересует сам процесс разработки. И чаще всего главное, что им нужно — это возможность заниматься им в нормальных рабочих условиях.

Так как же создать нормальные рабочие условия для разработчиков?

Работайте вместе с ними

Разработчики такие же творческие люди, как и менеджеры продуктов с дизайнерами, поэтому нужно позаботиться о том, чтобы включить их в творческий процесс. Разработчикам нет равных во время мозговых штурмов и совещаний по обсуждению требований. Дайте разработчикам возможность встретиться с проектной командой и поработать напрямую с ними (но не обязательно всем сразу). Иными словами, включите разработчиков в творческий процесс как можно раньше. Никто не любит, когда в него без объяснений швыряют документами со спецификациями.

Разработчики до предела логичны, поэтому их присутствие на ранних совещаниях поможет им понять, на чем основываются требования, и решить многие проблемы еще до их появления. Когда к разработчикам относятся, как к строителям, они постоянно задают вопросы, и это замедляет процесс разработки. Когда к разработчикам относятся, как к коллегам по творческому цеху, у них появляется меньше вопросов, и разработка движется быстрее.

Также важно то, что разработчики очень часто лучше знают, что можно сделать, а что нельзя. Например, фронтенд разработчики узнают о том, что можно реализовать в браузере задолго до остальных. Поделившись этими знаниями с остальными, мы можем спровоцировать рождение новых идей о том, как улучшить продукт, исходя из наших возможностей. Представьте, что вы придумываете сайт для выкладывания фотографий и не знаете, что их можно кидать прямо с рабочего стола в браузер? Как бы это повлияло на его дизайн?

Итак, дайте возможность разработчикам участвовать в творческом процессе с самого начала проекта. Выслушайте их мнение о проекте и о том, что технически возможно реализовать. Чем меньше нам кажется, что нам говорят, что делать, тем больше мы прислушиваемся к чужому мнению и лучше выполняем свою работу. Единственный способ этого добиться — дать нам поучаствовать в творческой работе над проектом.

Создайте творческую атмосферу

Давайте еще подумаем о разработчиках как о творцах. Попробуйте дать нам все возможности для того, чтобы мы проявили свои творческие способности. Хакдей и хакотоны популярны не случайно — они популярны потому, что позволяют разработчикам творческим путем возродить свою любовь к коду и разработке. На хакотонах разработчики полностью отдаются творчеству, свободные от ограничений своей обычной работы.

Одного хакодея раз в квартал уже хватит, чтобы доставить разработчикам радость. Хотите большего? Устройте тематический хакодей. Выдавайте призы самым творческим и практичным решениям и т.п. Главная задача — дать разработчикам творить, чтобы те, вернувшись к обычной работе, чувствовали в себе силы и дальше разрабатывать и улучшать ваши проекты.

Имейте в виду, что это касается не только разработчиков. Все время от времени хотят заниматься творческой работой. Но по моему опыту, у менеджеров продуктов и дизайнеров для этого куда больше возможностей. Для менеджеров и дизайнеров регулярно устраиваются всевозможные тренинги и конференции, о разработчиках же часто забывают.

Кстати, хакотоны — не единственный способ создать творческую атмосферу, но как первый шаг он проще всего. Также можно пробудить творческую жилку у разработчиков, отправляя их на конференции, разрешая им покупать книги за счет компании, позволяя им делиться идеями о проектах, над которыми они работают. Все знают, например, что Google дает разработчикам 20% рабочего времени на разработку их собственных проектов. Все это может привести к началу долгой и продолжительной дружбы с вашими разработчиками.

Поощряйте отдых

Учитывая количество часов умственных усилий, которые мы регулярно тратим во время работы, становится понятно, что разработчикам нужно не забывать делать перерыв. К сожалению, мы редко достигаем особых успехов в планировании своего времени. Бывает, мы настолько погружаемся в работу, что забываем об отпуске. За первые пять лет своей карьеры, я взял в общей совокупности, кажется, семь дней отпуска. Не знаю почему, но мы плохо умеем снимать свой стресс — и в этом большая проблема.

Выгорание разработчиков уникально в том смысле, что мы привыкли работать в таком состоянии. Но стоит выгоранию достигнуть своего пика, и мы увольняемся и уходим искать другую работу. Более того, почти никто из разработчиков никогда не скажет вам, что у них нет сил терпеть; у них слишком большая гордость для этого. В моей прошлой команде я говорил всем разработчикам, чтобы они тут же шли ко мне, как только почувствуют, что их все достало. Я не хотел, чтобы они терпели до тех пор, пока единственным выходом для них станет увольнение. Мне было нужно, чтобы они не увольнялись и наслаждались работой, и единственный способ добиться этого — понять, когда они начнут выгорать.

Поощряйте разработчиков брать отпуска. Ваша компания предоставляет определенное время под отпуск — так проследите за тем, чтобы разработчики его брали, как минимум один раз в 4-5 месяцев. Лучше всего, если этим займутся менеджеры, которые следят за графиком проекта.

Регулярный отдых во время отпуска дает разработчикам возможность восстановить свои творческие силы, избавляя их от постоянно нависающих дедлайнов. Да, во время отпуска мы наверняка тоже займемся разработкой, но заниматься мы будем исключительно нашими проектами, а не рабочими. Такая работа поможет нам набраться энергии и подготовит к новым битвам.

Пусть разрабатывают

Как бы иронично это не звучало, но многие компании нанимают разработчиков, а потом не дают им заниматься разработкой. Вместо этого их дни заполняют бесполезными совещаниями, подрывающими производительность. Вообще разработчики наиболее эффективны тогда, когда могут просидеть над кодом как минимум четыре часа не отвлекаясь.

Войти в хороший «поток» во время программирования всегда сложно, когда знаешь, что тебе через пару часов нужно быть на совещании. Для процесса разработки нет ничего более непродуктивного, чем процесс, во время которого ты вначале пишешь код час, потом прерываешься на час, потом снова пишешь код час, прерываешься еще на час и т.д. Мозгу разработчика нужно некоторое время, чтобы переключиться в «правильное» состояние для программирования.

Постарайтесь убедиться, что у разработчиков есть как минимум четыре часа в день на беспрерывное программирование. Только так можно ускорить разработку. Вполне логично: если люди работают по восемь часов в день, то хотя бы половину этого времени они должны тратить на свои основные задачи. Я, например, выяснил, что для меня самый продуктивный период — это время между одним и пятью часами дня. Если бы я мог работать в это время каждый день, я бы с легкостью справлялся со всеми моими задачами. В дни, когда это время прерывается совещаниями, я понимаю, что много сделать мне сегодня не получится.

И хотя бы один день в неделю обходитесь совсем без совещаний, включая ежедневные летучки. Пусть у разработчиков будет один день, в который они могут самостоятельно распределить свое время и расправиться со всеми делами. Вы не поверите, сколько всего можно успеть за день, полностью свободный от отвлекающих факторов. В свое время мой менеджер даже требовал, чтобы я работал из дома хотя бы два дня в неделю, потому что в офисе меня постоянно отвлекали. В результате я работал с невероятной скоростью.

Выражайте благодарность

Кое-что можно сделать уже прямо сейчас, добившись при этом значительных результатов. Я уже упоминал выше о том, как бесит, когда ты только закончил задачу, а на нее уже начали выписывать баги. У разработчиков редко выпадает шанс откинуться на спинку стула и полюбоваться выполненной работой, не говоря уж о том, чтобы услышать при этом слова благодарности.

Маленькое письмо со словами благодарности разработчику, только что завершившему задачу, способно добиться невероятных успехов, особенно если задача была сложной. Даже если вы просто скажете: «Слушай, спасибо за работу, я обязательно посмотрю», этого будет достаточно, чтобы снять угрюмое настроение, возникающее при появлении первого потока багов. Разработчикам очень важно, чтобы их работу ценили, ведь большая часть получаемых ими отзывов носят негативный характер — баги, проблемы и т.д. Пара добрых слов, и это все уже не кажется таким страшным.

Совсем здорово будет, если вы назначите что-то вроде награды, которую будут выдавать каждый квартал разработчику, который внес больше всего усилий, внедрил больше всего улучшений и т.п. Награда не должна быть обязательно чем-то дорогим и желанным вроде iPad'а (хотя мы с благодарностью примем и его), это может быть просто маленький подарок и письмо с признанием заслуг всей команде или отделу.

И, пожалуйста, когда благодарите людей за выполненную работу, никогда не забывайте о разработчиках. Я побывал на бесчисленном количестве совещаний по проектам, на которых все восхищались работой менеджеров или дизайнеров, при этом совершенно забывая о разработчиках, чьи пот, кровь и слезы воплотили проект в жизнь. Успех каждого проекта зависит от усилий каждой из трех групп, ни одна группа в одиночку не может его выполнить. Проследите за тем, чтобы ваша компания признавала усилия всей команды, а не какой-то из ее частей.

Заключение

Мы, разработчики, как правило, незаурядные люди. Мы все определенно являемся личностями, и мы правда хотим достичь как можно лучшего результата из возможных. Если вы перестанете относиться к нам как к мальчикам на побегушках и начнете уважать нас как часть творческого процесса, то вы добьетесь отличного результата в короткие сроки. В командах, в которых я работал, всегда были те или иные трения, возникавшие из-за непонимания способа мышления и мотивации разработчиков. Я искренне надеюсь, что эта статья поможет улучшить взаимодействие между разработчиками и их коллегами. Это ведь не так сложно — нам всего-то нужно чувствовать себя частью общего решения, а не обычной рабочей пчелой.
+214
19287
1098
Похожие публикации
Ход абстрактного проекта в вакууме: модель случайным процессом вчера в 21:28
Дайджест интересных материалов из мира веб-разработки и IT за последнюю неделю №126 (15 — 21 сентября 2014) 21 сентября в 21:11
Разработка code-based UE4 проектов под iOS в Windows 26 июня в 18:34
Высшая школа экономики открывает программу «Менеджмент игровых интернет-проектов» 8 мая в 20:38
Как создать концепцию продукта и написать ТЗ на разработку электроники 5 ноября 2013 в 17:32
Иллюзия эффективной разработки: управление 11 сентября 2012 в 22:41
Как дизайнеры и разработчики могут играть слаженно (и продолжать бегать с ножницами) 25 июня 2012 в 15:12
Разработка сайта — от первой встречи с заказчиком до сдачи проекта, или как быть фрилансером и выжить 16 апреля 2012 в 13:03
Твиттер для поддержания пульса проекта 6 марта 2009 в 11:05
Есть у кого опыт аутсорсинга процессов веб-разработки? 8 февраля 2007 в 15:30

Комментарии (76)

+26
glebmachine, #
Это ах*ено!
+9
namespace, #
Это ахуен*о!
+20
sainnr, #
Это охуенно, чего уж там.
+1
namespace, #
Ну, ну. Покультурнее можно.
+19
xldsakamrhahn, #
Использовать звездочки в матерных словах — все равно, что делать минет на площади и прикрывать рот ладошкой (с) bash
+2
lacki, #
Неа. Это хабр :)
0
Dimmerg, #
Судя по всему, у sainnr будет месяц, чтобы понять разницу между матом со звездочками и матом без оных
+12
s0L, #
Блин, я это распечатаю и обклею стены офиса. Статья невероятно классная :) Большой респект автору и переводчику.
+7
Mrrl, #
Отлично! Сейчас отправлю начальнику :D
+8
Melorian, #
Спасибо за перевод! Потрясающий текст! Уже разослал его всем своим менеджерам)
+11
skvot, #
Статья шикарна!
Господи, как же я ненавижу моменты, когда сидишь себе погруженный в работу, а тут тебя просят СРОЧНО поправить форму на сбытовом сайте.
+8
wwakabobik, #
Статья и перевод хороший.
Для меня, правда, ничего новым не оказалось в ней после своего опыта и статей Джоэла, а так же бизнес-моделей Google, но автор всё замечательно и кратко скомпоновал и выжал суть из многих проблем.
0
hDrummer, #
М.б. заголовок поправить —

«Уход и кормление разработчиков (или почему мы такие ворчуны) „
или
“Кормление и уход за разработчиками (или почему мы такие ворчуны)»

да и в оригинале «or, why engineers are grumpy» — «почему инженеры (или пусть будет разработчики)...», а не мы.
+2
opportunato, #
Первое замечание в точку, кормления я и не заметил.
Насчет второго — два раза подряд в заголовке употреблять слово «разработчики» некомильфо, а так как автор постоянно в тексте говорит от лица разработчиков «мы», решил такой же вариант использовать и в заголовке.
0
s0rr0w, #
Не нашел ничего нового. Как хорошо осознавать, что я не один такой в этом заброшенном уголке Вселенной… :D
+5
demark, #
Отличная статья, однако часто вижу противоположное мнение (с которым согласен) относительно вот этого пожелания:
Совсем здорово будет, если вы назначите что-то вроде награды, которую будут выдавать каждый квартал разработчику, который внес больше всего усилий, внедрил больше всего улучшений и т.п.

Из хабраперевода статьи Джоеля Спольски Как положить спасибо в карман:
Как только вы начнете отмечать хорошую производительность сотрудников премиями, они немедленно начнут сравнивать себя с коллегами: почему я получил меньше, чем он? И такие вопросы вполне правомерны. Как вы определите, что ценнее в денежном эквиваленте: баг, который Дэвид пофиксал во вторник, или фича, которую Тэд реализовал в среду? Если бы у нас был цех по пошиву мужских трусов, то все было бы гораздо проще: Дэвид сегодня сшил пять трусов, а Тэд — семь; значит, Тэд получит на 40% больше денег.

Мы делаем лучше, больше, быстрее не ради премий, а потому что можем и хотим — это внутренняя мотивация, если оперировать терминами из статей.

Вот благодарить всю команду/отдел после выполнения ключевых этапов — вполне разумная идея.
0
opportunato, #
Да-да-да, меня это тоже сильно напрягло. Но тут уж ничего не поделаешь — из песни слов не выкинешь.
+2
s0rr0w, #
Есть вполне нормальная практика премирования групп разработчиков. Для каждой значимой порции работы выделяется премиальный фонд. При выполнении разработчиками ряда условий, как то сдача проекта в срок, отсутствие критических багов, и так далее, премиальный фонд раздается группе. При невыполнении, фонд урезается каждую неделю или за каждый баг.

Морковка должна быть в поле зрения и осязаема, тогда будет желание ее достать
+1
wwakabobik, #
Не хочу с вами спорить, а наоборот поизучать эту проблему.
Моё личное мнение, как и у Джоэла, состоит в том, что прибегать к средствам материальной стимуляции — последний аргумент. С одной стороны обезоруживающий руководителя (у него не остаётся резерва и других эффективных рычагов воздействия, что сводит к нулю его лидерство), а со второй — портящей систему ценностей и мотивации сотрудника. Что заставляет последнего просто как разработчика перегореть и перейти в лоно потребления в одном сценарии; и уйти из компании, но с достаточным уровнем дохода, позволяющего не думать о деньгах, а сосредоточиться на цели — в другом.
Разработчик — в первую очередь творческая личность с сильнейшим чувством справедливости, которого попросту вгонять в однобокую модель глупо.
В вашем случае — это хороший метод восстановление справедливости, реально работающий. Проблема в том, что создав такую машину руководитель перекладывает на неё и ответственность. А как бы не были бы странны разработчики, с ними можно и говорить, и обучать, и понимать. Не всегда косяк или просмотр так плох, так как самый безолаберный работник может приносить огромную пользу, например, мотивируя других сотрудников, что при механической\материальной модели не видно на уровне начальства, и его результаты будут всего «плохими» и «штрафными» лишь от того, что им не умеют пользоваться из-за непонимания.
+1
s0rr0w, #
Мне кажется, вы немного преувеличиваете связь мателиального вознаграждения и лидерства. Это не пересекающиеся понятия и не зависят друг от друга.

С остальным не спорю, можно любой механизм обратить во зло, если им неумело пользоваться или возводить его до абсолютизма или идиотизма.

0
wwakabobik, #
Я ещё в процессе анализа этой проблемы. Собираю факты и проверяю гипотезы.
Поэтому благодарю за ваше мнение.

Г-н Кови утверждает, что как раз-таки зависят, и что подобное управление не является проявлением лидерства.
+2
s0rr0w, #
Ну, г-н Кови тоже может ошибаться, или его слова были привратно поняты.

Лидер — это не «кормящая рука». Лидер — это тот человек, авторитет которого непререкаем, слова и действия которого всегда несут пользу коллективу, который может повести за собой людей или организовать процесс, который берет на себя отвественность и принимает решения. А раздавать морковки может кто-то другой, и не факт, что это будет другой лидер. Лидер не надзиратель с кнутом, он человек, который побуждает в других желание самостоятельно двигаться вслед за лидером, т.е. не вешает морковку, а подталкивает человека к самостоятельному решению, что за морковкой идти надо.

Я сам в свое время изучал проблему стимулирования работников. И пришел к весьма интересным выводам, что материальная сторона на определенном моменте перестает быть важной для работника, на первый план выходят совершенно другие ценности
0
wwakabobik, #
Полностью с Вами согласен.
0
BloodJohn, #
Ключевое здесь — это уметь озвучивать важность работы Дэвида и Тэда.
«Если я уйду — все рухнет»

Как вы будете это озвучивать, айфоном, благодарным поцелуем секретарши, или стулом по правую руку директора во время обеденного перерыва — не так важно.

Главное чтобы все видели и оценили.
+2
Prof, #
Шикарная статья, полностью поддерживаю её автора в его взглядах
+3
GetWindowsDirectory, #
Потрясающая статья!
+5
Alvaro, #
Всё так и есть. И отдельное спасибо за хороший перевод.
+1
adminimus, #
>В оригинале использовался всем знакомый термин «software engineer». Так как в русском языке полноценного эквивалента нет

а чем не устраивает «инженер-программист»?
+5
opportunato, #
В русском языке инженер-программист — это в первую очередь запись в дипломе выпускника технического вуза, квалификация. На работу никто инженеров-программистов не нанимает (нет, есть и такие вакансии, но их меньшинство), нанимают разработчиков.
В английском языке «software engineer» — это именно должность, профессия. Аналог «инженера-программиста» в русском языке — это скорее «Bachelor of Software Engineering».
0
adminimus, #
>На работу никто инженеров-программистов не нанимает

я на такой должности вполне официально работаю. И разработчики у нас в отделе тоже есть.
+1
opportunato, #
Ну я же написал — такие вакансии есть, но их меньшинство.
Суть в том, что четкой терминологии в русском языке для обозначения профессии software engineer не выработалось. Их могут называть разработчиками, программистами и, да, инженерами-программистами. Слово «разработчик» в русском языке как положительное и возвышенное прижилось лучше всего (ну да, по моему субъективному мнению, конечно), поэтому использовать решил именно его.
Если хотите (и нам тут разрешат), можем устроить тут более подробное исследование, мне самому правда интересно, как грамотнее всего это перевести. Можно даже опрос устроить.
0
webkumo, #
Вообще-то в трудовую книжку обычно пишут инженер-программист, поскольку в такому случае не требуется писать определение задач работника — такая должность есть в соответствующем классификаторе.
0
opportunato, #
Вот, хорошо. Вижу, что здесь использован такой же перевод.
Теперь к практике, заходим на hh.ru, используем поиск, получаем следующую статистику:
  • по запросу «инженер-программист» — 185 вакансий
  • по запросу «программист/разработчик» — 6506 вакансий
  • по запросу «software engineer» — 721 вакансия

Получается, что, да, переводить «software engineer» как «инженер-программист» теоретически должно быть верно. Но на практике «инженер-программист» используется в русском языке во много раз реже, чем аналогичное «software engineer» в английском. Приходится использовать нейтральное слово «разработчик», которое более возвышенное, чем «программист», но более естественное, чем «инженер-программист». Конечно, теперь размываются отличия между «developer» и «software engineer», но всем не угодишь. К счастью, в этой статье это совсем не важно.
0
webkumo, #
Извините, похоже вы не правильно меня поняли — я не против того перевода, какой есть. Просто неверно говорить, что на hh.ru вакансия менее востребованная — я сам устроился по подобной вакансии (Java developer), но в трудовой — всё равно инженер-программист.
+1
opportunato, #
Ну да, я как раз имел ввиду, что вроде «инженер-программист» правильно, но используется это преимущественно в официальных документах, на словах все разработчики.
+1
dime, #
А я не согласен. Во всём :)

1. Что касается статьи — использование «инженера-программиста» подчеркнуло бы инженерный характер работы. «Разработчик» тоже не плохо, конечно, и я понимаю ваши аргументы. Но, на мой взгляд, поскольку и в русском и в английском есть все варианты терминов, подозревать автора в том, что он использовал «инженер-», вместо «девелопера» только потому, что «инженер-» у них более распространено (относительно нас), а не потому, что он хотел подчеркнуть именно инженерный характер работы — это как-то неочевидно по отношению к авторской мысли.

2. Плохая статистика «инженера-» не повод не популяризировать этот термин :). И дело не в официальном наименовании — лично меня это меньше всего интересует. Сам до недавнего времени предпочитал именовать себя девелопером/разработчиком (собственно, им и был), а в определённый момент понял, что я всё-таки инженер. И статья, по-моему, именно о тех, кто осознал, что он — инженер.
0
opportunato, #
Когда кто-то не согласен, это здорово, согласие порождает стагнацию. :)

1. Бесспорно, автор использовал слово «software engineer» именно потому, что оно подчеркивает инженерный характер работы, а точнее, указывает на большую ее сложность, о том, что речь идет не обычных «кодерах»-недоучках. Это особенно видно из его следующей записи в блоге (кстати, думаю перевести и ее) «Web developers are software engineers too».
Фишка в том, что в статье на сам инженерный характер работы упора практически не делается, делается упор на представителей этой профессии — а их на русском языке чаще все же называют «разработчиками» — при этом негативного оттенка такое название не несет.

2. Здесь согласен, очень хороший аргумент. Но я на него не решился. :)
В первую очередь потому, что, используя термин «инженер-программист», пришлось бы использовать его во всем тексте целиком — а это смотрелось бы слишком уродливо и неестественно.
0
VolCh, #
Официально есть программисты просто «программисты», а есть «инженеры-программисты», все они входят в составную группу «Специалисты по компьютерам», слышал ещё «инженер по производству программного обеспечения» применительно к выпускникам по специальности «Программная инженерия».
0
jAN, #
Речь скорее о том, что в этом контексте «Так как в русском языке полноценного эквивалента нет» — слишком категоричное утверждение и это режет глаз.
0
opportunato, #
Понял вас, добавил пояснение.
+4
ilichme, #
это великолепная статья! opportunato, спасибо вам за перевод! как жаль, но я не могу плючануть вам карму больше одного раза
0
GrigoryPerepechko, #
Искренне надеюсь что «плючануть» это что-то хорошее по отношению к карме :)
0
ilichme, #
конец рабочего дня дал о себе знать) я ещё вместо «как жаль, но» хотел написать «как жаль, что»
0
ren, #
Небольшое исправление: waterfall model — каскадная модель, а не водопадная.
0
opportunato, #
Спасибо за замечание, так гораздо грамотнее.
–2
Cupper, #
И вот тут зарыт главный корень проблемы — разработчики на самом деле не послушные строители. Разработчики — творцы.

Вам в фирме нужен молодой амбициозный, целеустремленны разработчик С++, с опытом работы в 1.5 года?
Потому что на моей, мне предлагают брать пример с дади Вася на заводе, вместо того что бы пытаться что то улучшить. И что все это выдумка, такая же как снежный человек.
0
Shark, #
Преждевременная оптимизация — это корень всех бед. Наберитесь опыта для начала, посмотрите что/где/зачем, а уж потом улучшайте. В начале карьеры всегда кажется что все вокруг идиоты, а ты видишь очевидный путь решения проблем. Иногда это так, конечно, но чаще всего устоявшееся поведение имеет под собой хорошее основание. Просто не очевидное.
0
Cupper, #
Я согласен с тем, что вы написали. Но… сейчас опять хочется взорваться по поводу своего проекта, но я стараюсь убедить себя в том, что у меня действительно нет опыта и я дурак. В итоге я буду либо прав, либо сильно скромным.
–9
neuymin, #
www.youtube.com/watch?v=fEYceCWI_h0
Нецензурная лексика. Извините.
+2
mapron, #
Зачем извиняться за вставку ссылки, если можно просто не постить?
Не понимаю. Это же не пукнуть нечаянно.
+1
spmbt, #
Да, перевод — действительно, редкого хорошего качества. Спасибо. И автор оригинала — то же самое, редкого качества, книги его популярны, излагать мысли умеет (линк на русские переводы).
+2
RubtsovAV, #
Читал в захлеб! Автору поста громадный респект и низкий поклон! Это нужно читать всем перед тем как постучаться к разработчику.
+2
Gibbzy, #
Отличная статья, спасибо за перевод, вы молодец!
+1
Aemeth, #
Тронуло до глубины души. Автору и переводчику, непомерная благодарность!
+1
DobroeZlo, #
Отличная статья. Завтра утром пошлю оригинал своего продакт менеджеру.
+1
Danvir, #
Замечательная статья! Респект автору и огромнейшее спасибо автору перевода!
+1
dekus, #
Статья прекрасна чуть больше чем полностью.
0
jandosul, #
Отличная статья, спасибо за перевод.
+1
nzeemin, #
Интересные мысли есть, но как же автор любит растечься мыслью по древу… длинно очень в общем.
0
GrigoryPerepechko, #
Компьютерные вузы не готовят вас к испытаниям, которые ждут вас в индустрии. Они в первую очередь дают вам концептуальные знания по большому спектру тем, чтобы потом не опозориться, столкнувшись с ними во время настоящей работы. Вас учат переменным, функциям и объектам, так как именно с ними вы будете работать большую часть своего времени. Вас учат базам данных и запросам к ним (хотя нормальные формы окажутся бесполезными на практике). Вы тратите ненормально большую часть времени на изучение алгоритмов сортировки и структур данных, которые во время профессиональной разработки будут скрыты от вас под слоем абстракций. Короче, компьютерные вузы рассматривают решение проблем, которые вам на практике никогда не придется решать. Если мне нужно что-нибудь отсортировать, я просто вызову метод sort(). Если мне нужна очередь или связанный список, я использую нативную реализацию языка, на котором я пишу. Все эти проблемы уже решены за меня.


Автор так говорит как будто фундаментальные знания бесполезны. Как будто все разработчики вызывают метод sort() и кладут кнопочки на форму.
И да, нормальные формы всё таки лучше применять чем не применять. По крайней мере там где есть ещё буфер по производительности.
0
HammeremmaH, #
Хорошая статья.
По себе скажу:
Не сажусь за решение минимального кванта проблемы, если не уверен, что успею решить его и написать код за неделимый промежуток времени. Всё по той же причине смены контекста. Вместо этого или просто готовлю почву для будущего решения или же решаю другой квант, который вписывается в промежуток времени.
0
citizenblr, #
Спасибо за статью. Думаю не лишним будет почитать как менеджерам, так и разработчикам.
Друзьям скинул :)
0
lany, #
Всё же замечания, что деньги особо не волнуют программистов, по-моему, ближе к западным реалиям. В России зарплаты программистов вполне бывают поводом искать другую работу.
0
KirAmp, #
Скорее у программистов нет тяги к обогащению, главное чтобы хватало для комфортной «западной» жизни. Просто в Российских реалиях, это огромнейшая сумма. :)

Я вот сейчас работаю за 10к + стипендия 1к. Из них на дорогу уходит только 4 в месяц. На остальные 7к квартиру не снимешь, девушку на прокормишь.
0
citizenblr, #
ИМХО зарплата стоит в топе только до определенного уровня. После того, как тебе хватает на твой образ жизни все больше и больше ценишь и ищешь другие вещи. Так было у меня.
0
Sild, #
Статья определенно порадовала
0
motylkov, #
Статья просто шикарна!
0
porzione, #
О Бруксе (и не только) — первому изданию скоро стукнет 40 лет, но много ли менеджеров прочитав книгу попытались и смогли изменить что-нибудь в своей компании? Судя по моим наблюдениям — исчезающе малый процент. С тех пор вышло немало других книг по теме, родилось немало баззвордов в области управления командами разработки, но старые проблемы — все на месте, кроме единичных компаний, которые как правило изначально создавались айтишниками и обслуживают айтишников. Разработчики прикладного софта все еще где-то в 1975-м году, будто и не было никакого Брукса. Дикая текучка кадров, особенно в российском IT, тому подтверждение.
К сожалению приходится констатировать, что книга в первую очередь нужна самим разработчикам для осознания, что где-то существуют люди, которые понимают их проблемы.
0
Nils22, #
Ээхх, прочитали бы эту статью в одной крупной российской софтверной компании (
Название компании раскрывать не хочется, компания делает проекты для нефтянки и гос. учреждений. Так вот в этой компании менеджеры проектов не являются бывшими разработчиками, не представляют процесс разработки, не знают языков программирования и часто говорят «ну это же просто, ты же сможешь это быстро сделать». Поработал там месяц и уволился.
0
Panacea, #
А про тестировщиков совсем автор забыл, они злые — расстраивают разработчиков… уменьшают их производительность.
+1
vit82, #
Спасибо за перевод. Только исправьте пож. имя баскетболиста.
Вместо «Джеймса Леброна» нужно «Леброн Джеймса». Джеймс — не имя, а фамилия :)
0
LayneBuchyn, #
Спасибо за перевод — у меня вот открытие века, статья прекрасна.
Единственное — почему-то при прочтении строк о новом дизайне страницы Yahoo! я полез на yahoo.com посмотреть, а какой же дизайн там сейчас. И что могу сказать — дизайн до сих пор по-моему редкостное говно, даже удивительно что они ничего не поменяют там.
+1
realno, #
Срок жизни программного обеспечения — 3-5 лет, срок разработки — 1-2 года. Не стоит сравнивать себя со строителями, потому что здания стоят по 100 лет, а срок их строительства сравним с вашим.
При такой скорости разработки всегда будут проблемы. Я вижу пару выходов: 1. Существенно сократить скорость разработки — что, если верить статье не представляется возможным (сроки это не ваша сильная сторона), 2. бить функционал на модули(блоки) и внедрять на базе общей концепции помодульно (но с этим у вас так же огромные проблемы — вы обожаете переписывать чужой код заново и никогда не найдете правил совместной разработки).
В конце хотел бы сообщить, что бизнесу в 95% случаев не важно ваша творческая составляющая, бизнес ждет быстрого копирования вашей предыдущей разработки.
Недавно была статья про спутник «Вояджер-1» которому 34 года и который до сих пор присылает уникальные данные. Это супер успешный проект. Он стал успешным только потому, что его запустили в космос, в котором нет возможности допиливать и оптимизировать. Поэтому 3ий выход: увеличивать срок жизнедеятельности ваших разработок (а вот это уже проблема заказчика)
0
Source, #
Вы забываете что большинство зданий возводятся по типовому проекту. Это ближе к установке CMS в одной из базовых комплектаций, чем к разработке ПО. При строительстве здания по уникальному проекту только разработка арх.проекта и то легко займёт пару лет, не говоря уж про само строительство.
А здания, которые стоят веками, составляют ничтожный процент от общего количества построенного за эти века. К тому же практически все они входят в 3 типа: совсем примитивные, совсем аварийные и памятники-архитектуры. Последние не используются по прямому назначению и для их поддержания в адекватном состоянии выделяются огромные бюджеты.
Однако ПО само по себе не изнашивается в отличии от зданий, т.е. срок жизни программного обеспечения ограничен только сроком жизни типа оборудования, на котором его можно запускать. Разумеется это как минимум десятки лет.
Другой вопрос в моральном устаревании, которое появляется из-за изменений требований к ПО, а отнюдь не из-за внутренних проблем в ПО. Так что пример с ПО для спутников вовсе не единственный, возьмите сотни программ для компьютеров 30 летней давности, они по-прежнему хорошо на них работают.
0
DesTincT, #
Самый верный совет — не бросаться в омут с головой. Сначала на разведку на месяц, а там уж решать — ваше это или не ваше. По поводу социализации могу сказать одно: будьте ДОБРЫМ и ХОРОШИМ. А если смотреть на тайцев как на врагов, то чего еще ожидать в ответ? И да, shit happens.
0
agentx001, #
Мда. Программисты действительно отличаются от простых смертных, причем очень заметно:) Нам в универе препод говорил: «Если хотите стать кодерами — меняйте своё мировоззрение».

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.