Справедливые ожидания вашего технического директора

в 20:32, , рубрики: ожидания, переводы, Программирование, Роберт Мартин, техдиректор, управление проектами
Я – ваш новый технический директор.

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

Профессионалы ли мы?

Это главный вопрос. Я расскажу, чего я от вас жду, и это определит ответ на вопрос, профессионалы ли мы.

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

Оглядитесь в этой комнате и посчитайте количество софта который тут работает. Можно даже не считать смартфоны и ноутбуки. Выйдем из комнаты и посчитаем софт, который затрагивает вашу жизнь в то время как вы перемещаетесь с одного квадратного метра на другой, заходите в лифт, проходите через автоматические двери… всё это управляется софтом.
Отопление и охлаждение воздуха, качество усиления голоса через микрофон и его запись — всё управляется софтом.
Вы выходите на дорогу и в каждой машине есть несколько процессоров, каждый из которых выполняет код. Вы окружены морем кода.
Так вот мой вопрос: сколько раз на дню вы вверяете свою жизнь if-у, который написал 22х летний кодер в 3 утра?
Ответ на него — слишком много. На определенном этапе случится событие (может даже уже случилось, но надеюсь что нет). Событие, которое будет очень серьезным. Какой-нибудь кодер сделает глупость и десятки тысяч людей погибнут, и все политики мира вскинутся в праведном негодовании и покажут пальцами на нас, и лучше бы нам иметь на это ответ.
Потому что если мы его не дадим — они дадут его за нас, и этот ответ будет — контролировать нас. Мы все станем государственными служащими, и это не может быть хорошим поворотом для индустрии, всем резко сделаться госслужащими.

Я ожидаю

Первое и главное, впереди всего остального — я ожидаю что мы не будем выкатывать говно.
Почему нужно это сказать? Потому что мы выкатывали говно.
И суть профессиональной разработки ПО в том, чтобы это закончилось сегодня. Мы положим этому конец прямо здесь сейчас, и больше никогда не будем выкатывать плохой код, нет.
Почему? Потому что у нас есть ответственность. Люди, которые наняли нас — не могут читать наш код. Они не знают, чем мы там занимаемся они не могут посмотреть на то что мы пишем и измерить, хороший ли он или нет.
Всё что они могут нам сказать — «Нам надо это к четвергу».
А мы — единственные кто знает что в действительности мы выкатываем. Это нам, а не кому-то другому необходимо гордиться тем, что мы делаем.
Кто проводит 8 часов в день на работе, а потом идёт домой и ему необходимо принять душ, потому что он весь день разгребал конюшню?
Я заявляю вам, что это непрофессиональное поведение. Я заявляю что всем нам необходимо иметь возможность каждый вечер говорить себе «Видит бог, я сегодня отлично поработал. Я следовал дисциплинам, я писал хороший код и бизнес будет на нём хорошо работать». Мы все должны идти домой с гордостью за плоды своего труда.

Я жду что мы Всегда будем готовы.

Я имею в виду, что когда бизнес хочет деплоить — мы будем готовы. Без задержек. Не бывает причин, по которым нужно было бы ждать месяц или два. Нет причин ждать пока QA закончит или пока код «устаканится». Если у вас есть «период выжидания», то… степень непрофессионализма… это вам не желе!
Код не должен стабилизироваться, он должен просто быть стабильным.
Я жду что вы будете всегда готовы, готовы задеплоить. Ну хорошо, может быть я дам вам неделю. Скажем, я говорю «Деплоим!», а вы говорите «Окей, к пятнице всё будет». Я не желаю слышать «месяц» или «полгода». Я хочу чтобы вы были готовы.

Стабильная производительность

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

Я хочу дешевую адаптивность.

И под этим я подразумеваю банальную ситуацию: когда бизнес хочет внести изменения вы говорите «Конечно! Нет проблем, мы внесем их и нет, это не будет стоить вам почки»
Почему? Вот эта штука, которую мы делаем, они называется «Software». Первое слово Soft — предполагается что она будет мягкой. И почему мы называем код — Software?
Предполагается что он будет легко меняться. И в вашей ответственности держать его в таком состоянии. Я не хочу чтобы мне говорили, что наш продукт не принимает мои новые требования.
Что не так с архитектурой если они не принимает мои требования?
Что не так с командой, которая не может обеспечить дешевую адаптивность?
Почему изменения должны так дорого стоить? Что-то не так, если они настолько дороги.
Я ожидаю от вас постоянного улучшения. Улучшения кода, процессов, производительности.
Если вы видите грязный код — я хочу чтобы вы его почистили, а не боялись его.
Если вы видите плохой процесс — его надо исправить.
Я ожидаю постоянного улучшения, а не какого-то закостенелого поведения, которое ничего не улучшает.
Улучшайте! Постоянно.

Безбоязненная Компетенция

Например, вы открыли код на экране и ваша первая мысль «О боги!», а ваша вторая мысль: «Нет, я не буду это трогать», потому что вы знаете — если туда залезть то вы обязательно что-то сломаете, а если вы его сломаете то он станет вашим.
Так что вы просто абсолютно некомпетентно и испугано закрываете его. Совершенно непрофессионально и безответственно струсив. Если я чего и ожидаю, так точно не подобного поведения. Я хочу бесстрашной компетенции. Я хочу чтобы вы посмотрели тому коду в глаза и сказали «Я поменяю тебя, черт возьми я тебя почищу».
И вы должны применить любые необходимые инструменты, чтобы не бояться кода.
Я, например, использую тесты. Если вы способны обойтись чем-то ещё — пусть будет так, но вы не должны бояться того, что создали.
Квинтэссенцией безответственности является создание системы, которую вы вдруг боитесь изменить. Она вышла из-под вашего контроля, вы выпустили джина из бутылки, проигнорировав свою обязанность держать его там.

Экстремальное качество

Все эти слова о постоянной чистке важны, потому что я жду Экстремального качества.
Я не хочу слышать всю эту бессмыслицу про компромиссы «Ой, у нас не хватает времени поэтому мы должны делать грязно». Эти слова сами по себе — грязь.
Эта старая мысль о том что «Единственный путь сделать быстро — сделать большой бардак». Кто это вас такому научил? Точно не мама.
Нельзя работать быстро, разводя бардак. Нет, вам кажется что вы работаете быстро потому что это так ощущается, но в действительности это не так, и вы это знаете.
Нельзя развести бардак и потом всё равно продвигаться быстро. Единственный способ работать быстро это держать настолько качественным насколько вы способны.
Кто из вас обычно работает медленнее когда имеет дело с плохим кодом?

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

Мы не будем сваливать на QA

В задачи QA не входит поиск ваших багов. На самом деле, QA не должно находить вообще ничего.
Я жду что вы будете выпускать код без дефектов и когда QA завершит их тесты они принесут отчет, в котором будет сказано «Ничего не найдено».
Они должны вообще удивляться, почему у них есть работа. Они должны быть в страхе, «Мы ничего не находим, что вообще с этими программерами, они не дают нам багов „
Конечно, они будут находить баги время от времени, для этого они там и сидят. И когда они находят — разработчики должны быть в недоумении. “Как это могло туда попасть ?»
QA вам не слуги, чтобы искать баги за вас, они не дебаггер. Ваша ответственность — производить наилучший код который вы только можете и не выпускать его в QA до тех пор, пока он не готов и работает.
Слишком многие из нас приняли на вооружение политику планирования которая звучит как «Я могу успеть к любой дате, до тех пор пока продукт не должен работать»
Могу задеплоить продукт в любой день, только назовите его.
Если же он должен работать, ну это тогда другой вопрос…
Вот что мы делаем с QA. Мы отправляем им продукт, зная, что он не работает и используем их как способ оттянуть сроки.

Автоматизация

Я оджидаю много-много автоматизации. Ваши тесты. Мне не нужны ручные тесты, и я не понимаю почему вообще люди тестируют вручную.
Видите картинку на экране. Это руки QA менеджера в большой компании. Документ, который он держит — это оглавление его плана ручного тестирования. Там 80к ручных тестов и он отправляет их каждые полгода в индию, где армия тестеров их выполняет и это всё стоит мильён баксов… ну или стоило в 2008.
Причина, по которой он на слайде — потому что там сейчас 2008 и идёт кризис. И он протягивает мне этот документ со словами «Мой босс урезал бюджет ручного тестирования вполовину».
Так что он спрашивает меня, какую половину тестов я должен выкинуть?
Я ответил ему «Не важно. Ты никогда не будешь уверен что половина системы вообще работает». Ручное тестирование всегда так заканчивается, как оно и должно.
Потому что когда система становится всё больше и больше, нам требуется больше и больше тестов и это становится всё дороже и в конце концов становится строчкой в бюджете у CFO, а он смотрит на неё и говорит «Эмм… ну это глупо» И он прав, это глупо. Автоматизируйте! Автоматизируйте тесты, пока ещё не слишком поздно.

Никакой хрупкости

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

Мы поддерживаем друг друга

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

Честные истимейты

Я знаю, с истимейтами всегда проблемы. Это такие штуки которые кладут на вас ответственность.
Кто-то может сказать «это неприемлимо, нам нужно быстрее», но разработчикам такого не скажут. От вас требуется честная оценка, но что же это такое?
Дата — это ложь. Если вы называете дату — вы врёте, вы не можете успеть к этой дате, она слишком точна. Я хочу услышать диапазон. Каково распределение вероятностей? Я хочу знать шансы, что всё будет готово к этой или следующей пятнице.
Я ожидаю услышать диапазон, а когда на вас начнут давить вопросами в стиле «А можно как-нибудь быстрее?» я ожидаю услышать «Нет».

Говорите нет

Потому что из всех задач профессионала — это самая важная. Именно из-за неё вас и наняли, кстати говоря. Говорить «Нет». Вы можете в это не верить, вы можете думать что вас наняли чтобы говорить «Да».
Но кто угодно может сказать «Да». Собаки например, у них это очень хорошо получается. Вас наняли потому что у вас есть такие знания, которых нет у боссов и менеджеров и бизнеса в целом. И эти знания дают вам власть говорить «Нет».
Когда стоит говорить «Нет»? Это самый сложная задача, которая стоит перед вами, профессионалами, и также самая важная.
Вы не должны говорить «Нет» просто по прихоти, «ты мне не нравишься, поэтому нет».
Чего вы действительно не должны никогда делать, так это говорить «Да» в то время как ответ «Нет», потому что это ложь и вы не делаете то, для чего вас наняли.
Конечно отказ провоцирует негатив, этого следует ожидать. Бизнес хочет получить прогресс, это важно для них. Глупо ожидать что они вас поблагодарят за отказ, но отказы также важны как согласие.
Потому что бизнес в конечном итоге оценит ситуацию и скажет «Хм, хорошо что эти ребята сказали Нет. Мы могли бы впустую потратить миллионы долларов, если бы они согласились».
Вы все видели мёртвые проекты, где кто-то сказал «Да», в то время как должен был отказать.
Чего ещё никогда нельзя говорить? Предположим к вам приходят с просьбой «хотя бы попытаться». Правильным ответом будет «нет».
И это не просто так. Если бы вы согласились, то это означало бы что вы держали что-то в резерве. Нечто вроде серебряной пули в кармане. И вы не говорили менеджеру об этом.
Так что получается, что он наконец выдавливает из вас «Я попробую» и он уверен что сейчас вы достанете из кармана эту самую пулю.
Но правда в том, что её у вас нет. Вы не станете делать что-то иначе, не измените свой подход. Ничего не изменится вообще. Вы также будете писать тот же самый код, что и в других случаях, на такой же скорости как и раньше.
Вы не сделаете ничего иначе, просто сказав «Я попробую». Единственное что вы изменили это сказали неправду. Потому что когда вы согласились попробовать — на самом деле вы пытались сказать «Уходи, я устал от тебя и не хочу об этом больше разговаривать».

Постоянное агрессивное обучение

Я ожидаю что каждый из вас будет применять этот подход. Ну, в этой комнате я скорее читаю лекцию профессорам, но тем не менее об этом нужно сказать.
Обязанность разработчика ПО — одна из самых важных — учиться. Мы — индустрия, развивающаяся на огромной скорости. Новые языки каждые пару лет, постоянно новые процессы. Мы движемся в безумном темпе и каждый кто хоть чуть-чуть отстанет — может уже никогда не нагнать.
Языки приходят волнами и искусство профессионального разработчика в том, чтобы оставаться на их гребне.
Может быть в данный момент вы знаете Ruby. Вы бросите это, не пройдёт и 5 лет. Будет что-то другое.
Так что вам надо смотреть вперёд, на следующую волну. Closure или Scala, может быть F#, кто знает. Настанет момент и вам придётся перепрыгнуть на следующую волну и продолжать держаться на ней.
Мы все должны постоянно агрессивно обучаться. Если вы ждете что ваш работодатель будет этим заниматься — вам не повезло. Если вы ждёте что вам будут покупать книги и отправлять вас на конференции — вы уже отстаёте от графика. Вам надо учиться быстро.
Вы приходите к врачу и вы вроде как надеетесь что ваш врач сидит дома вечером и читает много медицинских журналов, а не приходит домой и с большой бутылкой скотча и не выносит себе мозги на следующие 4 или 8 часов. Вы надеетесь что он развивается.
Если на вас подают в суд — вы обращаетесь к адвокату в надежде что он знает все нужные и свежие законы и занимается этим вне рабочего времени.
И к вам это всё тоже относится.
Рассчитывайте тратить дополнительные 20 часов в неделю на вашу карьеру. Это то, чем занимаются профессионалы.
К рабочим это не относится.

Наставничество

Обучайте друг друга. У нас в индустрии ужасная проблема с образованием. Образовательные учреждения ничего не делают чтобы подготовить молодых программистов к тому, с чем им придётся столкнуться когда они начнут работать.
Они учат их языкам, нотации большого-О, алгоритмам. Может быть они там работают над проектами.
Можете себе представить эти проекты?
Молодые ребята, студенты. Как они делают проекты?
В 3 утра после пивной вечеринки, вот как они учатся.
Потом они оказываются в офисе, и с чего бы им менять своё поведение. Всё было отлично в институте.
Никто по этому поводу ничего не делает. Существует необходимость превратить этих ребят в профессионалов и это наша обязанность.
Наша работа посеять семена профессионализма, с тем чтобы индустрия могла пожать их потом.
Те из вас, кто в индустрии более 15 лет должны обучать. Учить молодёжь, что надо делать и как именно. Какие правила существуют, что такое хороший код и плохой.
То же самое с поведением.
Вот этого я ожидаю ото всех.

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

Спасибо за внимание

Автор: synchrone

Источник

Поделиться

* - обязательные к заполнению поля