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

Original author: Robert Martin
  • Translation
Я – ваш новый технический директор.

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

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

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

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

Оглядитесь в этой комнате и посчитайте количество софта который тут работает. Можно даже не считать смартфоны и ноутбуки. Выйдем из комнаты и посчитаем софт, который затрагивает вашу жизнь в то время как вы перемещаетесь с одного квадратного метра на другой, заходите в лифт, проходите через автоматические двери… всё это управляется софтом.
Отопление и охлаждение воздуха, качество усиления голоса через микрофон и его запись — всё управляется софтом.
Вы выходите на дорогу и в каждой машине есть несколько процессоров, каждый из которых выполняет код. Вы окружены морем кода.
Так вот мой вопрос: сколько раз на дню вы вверяете свою жизнь 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? Никак. Придерживайся его сам.
Как заставить их вести себя как подобает профессионалам. Никак, сам веди себя как профи.
Это личное решение. Делай так сам, и другие могут сказать «Хм, вот у него хорошие мысли в голове. Может и мне стоит делать как он». А могут и не сказать, это их личное дело.
Но решение за тобой.

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

Comments 113

    +27
    Лифт есть мощное средство передвижения, это первое. А также средство транспорта. Лифт должен быть как самосвал: приехал, вывалил и обратно. Это во-первых. Администрации давно известно, что многие товарищи ученые, в том числе отдельные академики, лифтом эксплуатировать не умеют. С этим мы боремся, это мы прекращаем. Экзамен на право вождения лифта, невзирая на прошлые заслуги… учреждение звания отличного лифтовода… и так далее. Это во-вторых. Но монтеры со своей стороны должны обеспечить бесперебойность. Нечего, понимаете, ссылаться на объективные обстоятельства. У нас лозунг: лифт для всех. Не взирая на лица. Лифт должен выдерживать прямое попадание в кабину самого необученного академика...
      +5
      Железный конь идет на смену крестьянской телеге. Наладим серийное производство советских автомашин. Ударим автопробегом по бездорожью и разгильдяйству. Я кончаю, товарищи. Предварительно закусив, мы продолжим наш далекий путь!
      +7
      Усложним задачу, представим что ваша деятельность не финансируется или финансируется недостаточно, а вокруг кадровый вакуум, после чего я с радостью померяюсь яйцами с автором статьи. «По возможности избегайте проектов с хромой бизнес-частью» слишком красивый совет.

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

      Вопрос к переводчику, зачем вместо слова «оценки» было использовано «истимейты», в словаре не нашлось перевода?
        0
        Изначально показалось слишком громоздкая конструкция для подзаголовка… но калька смотрится действительно коряво, исправил.
        +4
        Спасибо за перевод.

        Это сжатый пересказ его же книги The Clean Coder.
        www.amazon.com/Clean-Coder-Conduct-Professional-Programmers/dp/0137081073

        Достойная книга. Надеюсь, что будет всё больше людей, которые её прочитают и осознают.
          +1
          Если вы о том, что она изменит мир — то, сомневаюсь. К сожалению, и книга, и статья говорит о частном случае, предлагая бороться с посредственностью (в работе, в учебе, в жизни — в данном случае, в области разработки ПО). Но не освещает корневые проблемы, и не предлагает методов их решения.

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

          Да, посредственность, и наплевательское отношение к работе — в любой области — это ужасно. И в масштабе страны может привести к инфраструктурным катастрофам. Но одними стимулирующими речами вроде данной статьи их не устранить.
          Мы принадлежим к поколению, которому выпало переживать и бояться не фантомов и эгоистических мелочей вроде воспетого ранним Маяковским гвоздя в сапоге, а действительно колоссальных катаклизмов, которые изменят облик не только наших стран и народов, но и всего человечества.
            +2
            Прежде чем изменить мир — постарайтесь изменить себя. Я тоже верил, что «щас заговнокодим» — лучший подход, если нет времени/денег. Как оказалось — если сразу писать хорошо — то работа идёт быстрее. Если «драйвиться» тестами — то не делаешь кучи лишнего (и не забываешь о действительно нужном) — и как результат работа идёт быстрее.

            Да, эта книга не именит мир. Да, она не сделает толпы джунов профессионалами. Но если следовать изложенным там советам — вашей компании будет чуть лучше житься
          +4
          >Представьте что мы все временно перенеслись в параллельную вселенную
          >Так вот мой вопрос: сколько раз на дню вы вверяете свою жизнь if-у, который написал 22х летний кодер в 3 утра?
          Попробую угадать, как человек живущий в этой вселенной и за МКАДом: ноль?
            +3
            В Вашем замкадье тундра?
              +2
              Как человек же живущий за МКАДом задам встречный вопрос: а что, энергия к нам просто так подвозится? Газ, опять же. Не говоря уж про светофоры, школы и больницы… Можно ещё вспомнить ракеты, что нацелены на весь земной шар. Спутники. Да, это жизненно важные области, и писал их не 22х летний кодер в 3 утра, а 27 летний в 2. Сильно легче? Даже в одной из вымирающих деревень, в которой я был (ни школы, ни дорог, ни магазина, никакой инфраструктуры почти) электричество подведено. Спутниковые тарелки стоят. Уверен, что и интернет там есть (раньше-то деревня жила, следовательно «лапша» должны остаться). Так что я думаю даже самые коренные жители Африки так или иначе зависят от if'ов. Вопрос в плотности.
                0
                Софт с высокими требованиями к надежности пишется с бОльшим число тестов и требований, чем сайты и софт для телефонов. Я как минимум надеюсь на это…
            +9
            Я думаю что это весьма идеалистическая точка зрения, не имеющая возможности существовать в реальности. Достаточно вспмомнить о дилеме выбора Быстро — Качественно — Дешево и то, что только у двух кругов могут быть пересечения. Либо дорогая команда супер-профи ( что почти не встречается в коммерческой разработке ПО ), либо страдает качество или сроки. И обычно страдает качество, потому что продукт без применения в бизнесе не имеет смысла если он вышел позже конкурентов. Здравых мыслей у него много конечно, но в реальности все вместе маловероятно (
              0
              Для угоды всем, мы часто используем некое подобие MVP — если планируем запустить N фитч, но не успеваем, то выкатываем, скажем, N-2, но вполне стабильных, остеивая малоприоритетные. Бизнес не очень страдает (результат все-таки есть) и пользователи рады, потому-что не были в курсе планов.
                0
                В некоторых проектах такой подход не подойдет, увы. Например в программировании каких-нибудь железяк, которые потом нереально перепрошить. Или в гос.заказах, в которых перед началом разработки утверждается список фич, и выкинуть нечто просто нереально — без единой закрытой фичи денег за проект не получишь ни копейки.
                0
                Любая из данных оценок носит субъективный характер.
                У меня есть некий проект, я, как заказчик оценил его бюджет в 100.000 $, качество для меня — чтобы система работала и выполняла свои фунции с заранее обговоренной степенью отказа от обслуживания (допустим 99.9%). Сроки я поставил в 2 месяца. Прихожу к одному разработчику и прошу его предложить срок объявляя только первые два параметра (бюджет и качество), он заявляет, что он с командой из 2 человек завершит этот проект за год. Второй разработчик примерно такой же квалификации заявляет, он не сможет обеспечить подобное качество никогда, третий объявляет что его сроки — 2 месяца. Чудо? Мы получили бюджет-качество-сроки именно те, которые хотели?
                Для понимания — пример взял из личной жизни, старт пилота 01.06.
                  0
                  Вы получили бюджет-качество-сроки лишь в том случае, если всё будет именно так, как вам сказали изначально. А не то, что сначала вам называют, скажем, сроки в два месяца, а через месяц говорят «ой, вы знаете, я тут недооценил сложность проекта, мне нужно ещё полгода и лимон баксов».
                  Исполнитель — заинтересованная сторона, его оценки по срокам и бюджетам часто бывают излишне оптимистичны — ведь ему нужно получить этот проект. Поэтому единственный расклад, при котором данные вам обещания реально чего-то стоят — когда они зафиксированы на бумаге вместе с санкциями за их нарушение. Соответственно, для этого исполнитель должен быть кем-то, с кого при случае можно будет эту компенсацию взыскать. Команда же из трёх человек может потенциально просто слиться — и дальше всё будет зависеть от вашего умения договариваться с нашими судами.
                +1
                Возможно, я чего-то не понял, но… На мой взгляд, подобный манифест должен быть прозрачным для команды (я имею, что команду нужно подталкивать и наставлять к тому, чтобы каждый её участник самостоятельно пришел к выводам, написанным выше, вместо декларирования этих выводов перед лицом команды в формате ожиданий), иначе это походит на слова человека, функция которого сводиться лишь к объявлению планки качества и применению дисциплинарных мер за её превышение, что уже дает подрыв авторитета и есть шагом к Fear-driven Development.
                  0
                  Я знаю, с оценки по времени всегда проблемы. Это такие штуки которые кладут на вас ответственность.

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

                  Когда на вас начнут давить вопросами в стиле «А можно как-нибудь быстрее?» я ожидаю услышать «Нет».
                  Во-первых, не следует допускать разработчиков к общению с другими отделами в формате планирования без личного участия. Подобные вопросы должны быть адресованы руководителю. Во-вторых, практически всегда «можно быстрее», доходчиво объяснив менеджерам — или работа занимает столько времени, сколько было озвученно, или упрощается исходная задача — при наличии ряда свойств проекта (проект уже в возрасте, основа дохода — реклама, и т.п.), этот выход часто является единственным способом заработать деньги. Доводилось сталкиваться с несколькими руководителями, которые не предлагали варианты, услышав подобные требования по ускорению. Закономерно — их всех уволили или сняли с должности по одной и той же причине — рецедив срыва сроков по крупным заказам.
                    0
                    проблемы с оценкой времени — это всегда вина руководителя

                    Здесь имеется в виду впринципе оценка, и то что разработчики иногда боятся её давать, потому что потом придётся к ней успевать, а это накладывает ответственность и стресс.

                    Умножать сроки на три, понятно, задача менеджмента и правильности сроков от разработчиков никто не требует. Просто чтобы хоть какие-то цифры были
                  +1
                  Так будет через 30 лет. Пока что спрос гораздо выше предложения, а технологии меняются слишком быстро, чтобы ответственность стала критерием №1 при наборе программистов.
                    +4
                    Боюсь, так не будет еще очень долго. Мой любимый пример: строительство (домов, дорог и т.п.) — там за тыщи лет мало что изменилось.
                      0
                      Когда на вашей памяти в вашем городе падал новострой?
                        0
                        Думаю, ежедневно где-то падает новострой. У кого кубики рассыпаются, у кого дачный сортир падает, у кого еще что.
                        А вы чего спросить-то хотели?
                          0
                          Я к тому, что сравнение строительства домов с разработкой софта в вопросах качества и уровня ответственности пока что не в пользу софта. Новострой в Шанхае таки да, упал, но % падающих новостроев намного меньше % падающего софта.
                            +1
                            Скажем так, стоимость разработки средней софтины тоже радикально меньше стоимости «разработки» многоэтажки. Так что получаем то, за что готовы платить.
                              –1
                              А стоимость человекочаса больше в софте. Но деньги тут не решающий фактор.
                          0
                          Я тоже не совсем понял, к чему вы это спросили, но на всякий случай поделюсь показательным примером: в 2009-м году в Шанхае рухнула новостройка.
                            0
                            Таки меньше года назад в Караганде рухнула новостойка, а заодно снесли весь жилой комплекс, потому что другие дома оказались тоже не ахти, в родном Петропавловске сносят еще не сданную 9-этажку. Так что падают, еще как.
                            +2
                            Может ради интереса стоит сходить на строй площадку? У меня вон под окном несколько — чтот я сомневаюсь, что тысячи лет назад использовали подобные технологии. И да, недавно я переехал из хрущевки в новострой — знаете, за 50-60 лет изменилось ОЧЕНЬ многое.

                            Если разговор об ответственности — посмотрите, за что могут посадить строителей, и за что могут посадить программиста. Думаю вопрос отпадёт сразу.

                            P.S. В российской империи, инженер, проектировавший мост, перед первым пуском поезда должен был стоять под мостом. Вы когда-нибудь видели подобный уровень ответственности в программировании?
                          +8
                          Традиционный вопрос. Вы хотите купить себе мега-супер смартфон.

                          Варианты:

                          1. Безопасный, быстрый, с приложениями, которые никогда не сбоят. Срок появления — 2049 год
                          2. Большей частью безопасный, местами подтормаживающий, приложения изредка падают. Срок появления — 2022 год.
                          3. Кое-как безопасный, весьма задумвчивый иногда, приложения падают иногда. Срок появления — завтра.
                          4. Дырявое ведро, с которым опасно появляться в интернете, всегда тормозит, приложения падают раз пол-часа, а раз в день он виснет наглухо и его нужно перезагружать. Ещё он путает номера в телефонной книге и может пропускать звонки. Срок появления — уже доступен.

                          А дальше вы понимаете, что победителем в этом конкурсе будет №3. Хотя №4 тоже хапнет кусок рынка, но быстро сдуется (на следующий день). Номер два будет иметь своих фанатов, но не получит большой доли рынка. Номер один будет снят с произодства в 2048 году.

                            +4
                            Придумайте другую аллегорию, т.к. первый №2 вышел еще в 2007 году и доля рынка у него огромна.
                              0
                              Под 3й (или даже 2й) пункт сейчас можно записать наверное все популярные мобильные ОС, будь то Android или iOS, а уровень задумчивости будет сильно зависеть от железа :)
                              +19
                              Товарищ неадекватен в своих экстремальных суждениях и несдерживаемой агрессии, такого CTO я бы точно не хотел.
                                +1
                                Сначала я подумал также.
                                А потом подумал ещё раз и решил, что его теории — это не то, что есть или должно быть. Достигнуть такого невозможно (imho), но как цель, к которой нужно стремиться — это здорово.
                                  0
                                  Если к этому не стремиться, то хотя бы приемлимо — никогда и не будет
                                    +6
                                    Можно стремиться и при этом не быть мудаком.
                                  +8
                                  Ваш босс приходит и говорит «Мне это надо к четвергу. Делай что хочешь, но мне это нужно к четвергу».
                                  Знаете что надо делать в такой ситуации? Надо сесть и написать самый лучший код который можете.


                                  И если вы верите что написание хорошего кода поможет вам разрабатывать быстрее — в аврале вы будете писать его ещё лучше. Если вы верите что тесты ускоряют разработку — в аврал вы будете писать их ещё больше.


                                  Это он серьезно?
                                    +19
                                    И при этом «Говорите нет» и «Если вы называете дату — вы врёте, вы не можете успеть к этой дате, она слишком точна. Я хочу услышать диапазон. ».

                                    Т.е., если начальник выдаёт срок — вы обязаны к нему успеть.
                                    Если вы выдаете срок — вы лжете.
                                    Вы обязаны уметь говорить нет.
                                    И параллельно всегда успевать к названной другими дате «без отговорок».

                                    Прям какой то набор лозунгов. Пятилетку в три года…

                                    Или не лозунгов даже. А скорее «светлое будущее, к которому мы обязаны стремиться», но которое на 100% не достижимо.
                                      –2
                                      Вы как-то умудрились смешать не очень связанные вещи.

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

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

                                      Про дату сюда же. Вы не можете гарантировать то, чего не знаете. Например, «с 80-процентной вероятностью я сделаю это за 5 дней». Тут можно либо сказать «сделаю за 5 дней», либо (если начальник адекватен — автор себя представляет именно таким) сказать «сделаю за 4—6 дней», либо (если не очень) сказать «сделаю за 6 дней» и настаивать на этом сроке.
                                        +2
                                        Разве первый пункт об этом? Вам дали ограниченный срок. Вы не должны говорить, что не успеете за этот срок покрыть тестами код или там ещё что-то, нет, вы обязаны в этот срок успеть, причем с идеальным качеством, никаких костылей. Не должны спорить. Но одновременно, если таки вам дали возможность влиять на срок — сообщать о том, что этот нереально. Как это? Как мне узнать, угадать, что от меня сейчас требуется? А вот у автора я должен одновременно не спорить о сроках и уметь говорить «нет».
                                          –4
                                          Про «не должны говорить» вы же сами придумали. Вот приходит к вам шеф и сообщает, что к нам завалились злые люди, и если мы не запилим фичу к понедельнику, нас каждый день будут штрафовать на миллион. В этот момент ему глубоко плевать на все ваши «нет, успеть невозможно», и он даже готов оплачивать все переработки в десятикратном размере. Вы можете ему сказать, что шансов нет, он будет про это знать. Но после вы всё равно сядете и постараетесь успеть к понедельнику.

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

                                          PS: Не утверждаю, что автор прав. Я лишь к тому, что тут нет логических противоречий.
                                            0
                                            Ускорение всегда достигается за счет чего-то другого. Обычно это качество кода. А в вашем случае что?
                                              0
                                              Концентрация усилий именно на «злом» проекте (в ущерб другим), переработка, стимуляторы, отказ от перекуров и/или кофе-бриков и т. п. Вообще в стрессовом состоянии организм вообще, и мозг в частности способен на большее, чем в обычном, но долго такого режима не выдержит. Ну и стресс стрессу рознь, конечно.
                                            +1
                                            Когда спрашивают — нужно говорить «нет», а когда ставят перед фактом «нужно вчера» — нужно просто брать и делать, но так жк качественно как обычно.
                                        +3
                                        Вот мне тоже интересно насчет тестов. Разве тесты просто «ускоряют разработку», а не «ускоряют разработку послезавтра»?
                                        –2
                                        В целом интересно, но перевод получился уж слишком академичный. Явно слова подобраны качественно но по смыслу построения фраз получается «моя идти бить восьмилапых». Текст очень напомнил результат работы гугл-транслейта.
                                        Пара примеров из статьи:
                                        Это такие штуки которые кладут на вас ответственность.
                                        Я жду что ничего не будет хрупким. Я устал слушать о таких частях системы.

                                        С таким переводом смысл остался за кадром, проще прочесть в оригинале чем ломать голову.
                                          0
                                          Есть одна область программирования, которую прекрасный Uncle Bob успешно игнорирует — прототипирование. Там нужны именно ручные тесты, качество и производительность кода не имеет особого значения, тогда как сроки крайне важны. Это может быть стартап, выпускающий новый продукт, или эксперименты у крупного веб-продукта на небольшой аудитории.

                                          Отказ от прототипирования — заведомо показатель некомпетентного технического руководителя. Другой вопрос, что в случае успеха прототип должен быть допилен до адекватного состояния, что, к сожалению, делается далеко не всегда, и это уже прямая вина технического руководства.
                                            +13
                                            Технический директор должен не «ожидать» а выстраивать процесс так, чтобы он работал в соответствии с требованиями.

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

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

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

                                              Именно в ответ на таких «менеджеров» и «руководителей» появляются движения типа такого:
                                              programming-motherfucker.com
                                                0
                                                Полностью с Вами согласен. Собственно это я и имел в виду, «определиться с требованиями, следить за их исполнением и корректировать, где это требуется» это и есть создать технологический процесс производства сотфа.
                                                  0
                                                  Требования — в посте. Вы предложили методы решения соответствующих требований. Создавать технологических процесс действительно необходимо, просто хоть сколько-то квалифицированные программисты и их непосредственных технический менеджмент и сами хорошо понимают, как _лучше_ в конкретном случае решать соответствующие требования, и почему эти общие требования важны и удобны. Именно поэтому тех.диру может быть достаточно просто сформулировать требования и вместе с техническим персоналом выбрать оптимальное решение, которое внедрять уже совместными усилиями, а не личной волей тех.дира, который лучше подчинённых знает, как они должны работать.

                                                  Извините, просто наелся такого неквалифицированного менеджмента с завышенным самомнением и непониманием принципов совместной работы.
                                            • UFO just landed and posted this here
                                                +6
                                                Хотеть не вредно…
                                                  +15
                                                  Требования хорошие и даже правильные.

                                                  А я хочу квартиру.
                                                  За три рубля возле кремля.
                                                    +6
                                                    Напоминает напутствие молодому строителю коммунизма. Такое впечатления что вот сидят все и думают: «Так, мне сегодня работать хорошо или плохо? А, что Вы говорите, надо хорошо? Ох, ну спасибо, помогли определиться. Так и сделаю, пожалуй!».
                                                      +2
                                                      Вижу в комментариях много негатива в адрес сути статьи… Странно. На самом деле, статья во многом отражает и мою точку зрения. Многие из фраз я чуть ли не дословно использовал в недавних спорах с коллегами. Очень многие из этих мыслей уже давно крутятся в моей голове.

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

                                                      Программистам давно пора оглянуться вокруг. Посмотреть на результаты работы инженеров, архитекторов, врачей. Вам приятно было бы ездить на машине, которая потребляет двести литров бензина на 100км и у которой иногда отваливаются колёса? А жить в здании, которое рушится каждый месяц? А может, после операции по удалению аппендицита недосчитаться руки? Так почему ничто меня нынче так не удивляет, как корректно работающая программа? Нам всем пора стать более ответственными за результат своего труда.
                                                      Можно возразить, что не важно, как написана программа, пока она работает. А вам хотелось бы видеть под капотом вашего автомобиля груду кривого хлама, непонятно как работающего (для многих, возмножно, оно так и выглядит, но на самом деле это не так)?
                                                        +9
                                                        Погодите. Вы хотите сказать, что ни единого проекта не делается по принципу «так ребята, сколько вам нужно времени? С учетом того, что релиз должен быть 13 сентября, и ни секундой позже, иначе мы опоздаем. Нет, новых людей мы нанимать не будем, или будем, но в середине проекта, когда сам их ввод затормозит процесс».

                                                        Дома по такому принципу не строятся. И не лечат по такому принципу. И автомобили не выходят на рынок. А вот софт пишется, причем не редко, мягко говоря. Кто то себе может позволить тратить именно столько времени, сколько нужно (Blizzard например Warcraft 3 делала реально годами, да не только она и не только их. Но и у них бывают косяки.).

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

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

                                                        Короче, все советы в полном объёме удастся наверняка выполнять, но не в любой ситуации. А автор, как лично мне кажется, отталкивает подходом «лучше не выходит на рынок вообще, чем выходить с посредственным продуктом» — по крайней мере, для меня его лозунги выглядят именно так.
                                                          0
                                                          что ни единого проекта не делается по принципу
                                                          Делается, разумеется. Но далеко не всегда. Но не всегда. Просто глупо самому назначать сроки, а потом самому жаловаться, что тебе не хватило времени сделать нормально.

                                                          Как инженер и просто образованный человек я понимаю, что абсолютных истин не бывает. Но это то, к чему мы должны стремиться.
                                                          Да, автор не упомянул о прототипах. К счастью, прототипы люди пишут на выброс: они либо заменяются качественным кодом, либо просто выбрасываются, т.к. фокус не удался.
                                                            –1
                                                            Дома по такому принципу не строятся. И не лечат по такому принципу. И автомобили не выходят на рынок. А вот софт пишется, причем не редко, мягко говоря. Кто то себе может позволить тратить именно столько времени, сколько нужно…
                                                            Далее, к домам не бывает требований «а давайте перестроим дом в речной параходик». А к софту бывает.

                                                            Это неверные представления о порядке вещей, которые как раз и поддерживаются рассказами о «22-летних кодерах, пишущих в 3 часа ночи».

                                                            Пока архитектор проектирует, заказчик может менять свои представления о том, чего он хочет, и вбрасывать все новые и новые задачи. Готовые дома иногда перестраиваются, и даже дворцовые комплексы эта чаша не минует. То же самое — с любыми техническоми разработками. Не надо только путать процессы инженерного проектирование и конвейерной сборки.
                                                            Софтостроение «к нормальному, инженерному подходу в разработке» пришло уже давно. 22-летние кодеры писали по ночам 15-20 лет назад, а сейчас им по 40 и более, большой багаж опыта за плечами и за важные вещи отвечают именно они, а не вчерашние студенты.
                                                            И никто серьезные проекты за пару месяцев не делает, потому что серьезные проекты не финансируются без серьезного планирования.

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

                                                              +1
                                                              Насчет «релиза к 13 сентября»… Не надо только думать, что это — норма, и что весь мир так работает.


                                                              Вы не поверите, но наличие четкой даты релиза, определяемой бизнес-требованиями, на которую никто из «технических людей» повлиять не может — это именно норма и весь мир так работает.
                                                                0
                                                                Да, конечно.
                                                                Я имел в виду, что на серьезных проектах не бывает такого, чтоб заказчик ворвался и потребовал сделать что-то в нереальные сроки, потому что ему вдруг приспичило.
                                                          • UFO just landed and posted this here
                                                              +3
                                                              Вы видели аналитиков, из-за нерадивой работы которых падают системы? А может, дизайнеров, из-за которых некорректно обрабатываются финансовые транзакции? Или, быть может, технические писатели мешают расширяемости вашей системы?

                                                              На моей практике 99% ошибок допускают именно те люди, которые занимаются реализацией логики системы. Думаю, эта работа одна из самых сложных и ответственных, и именно на таких людей ориентирована эта статья. А архитекторы, к счастью, обычно опытные люди, вышедшие из рядовых программистов, их ошибки редки, обходятся довольно дорого, и выявляются обычно ещё на этапе реализации. По поводу команды сборки… Я довольно редко встречаю людей, которые занимаются только этим. Обычно за сборки отвечают несколько разработчиков по совместительству. В особо крупных проектах, в которых я работал, за это отвечал один человек на продукт, работающий на полную ставку. С его стороны осечек не было практически никогда.

                                                              Да, слово «программист» мне тоже не очень нравится, а уж слово «кодер» вызывает у меня изжогу. Я предпочитаю «software engineer» или просто «инженер».
                                                              • UFO just landed and posted this here
                                                                • UFO just landed and posted this here
                                                                    0
                                                                    Я слышал об этом и даже хотел включить в первый абзац предыдущего комментария после «финансовых транзакций». Я так понимаю, выделенные вами словосочетания как раз и выявляют вину именно разработчиков, ведь это они отвечают за дизайн и используемые практики разработки.
                                                                    • UFO just landed and posted this here
                                                                        0
                                                                        У меня всё прекрасно с терминологией. В реальной жизни любой человек, отвечающий за разработку программного обеспечения, совмещает в себе несколько ролей. Более того, конкретный круг обязанностей каждой роли сильно варьируется от компании к компании, да даже в рамках одной компании. Да и понятие «архитектура», к примеру, такое же «конкретное», как и «энергия» в физике. Все знают, что она есть, но никто не знает, что это такое. Каждый представляет её себе по-своему.

                                                                        За «software design» и «development practices» в моём понимании должны отвечать те, кого вы называете «кодерами». Повторюсь, меня от этого слова коробит, я сразу представляю себе улюбащихся индусов с группового фото разработчиков IE6, не в обиду жителям Индии будет сказано.

                                                                        Мне лично сложно как-то вписать себя в вашу красивую систему понятий. Я занимаюсь архитектурой (а именно выделением модулей и связей между ними, описание контрактов компонент), активным написанием кода и частенько ковыряюсь в проектной системе сборки просто потому, что вижу в ней серьёзные изъяны, а отдельного билд-инженера у нас нет (хотя компания довольно большая). В один день я могу писать High-Level Design спецификацию, потом писать низкоуровневый код на с++, править скрипты CMake и конфигурацию CI-сервера, потом сваять пару скриптов для автоматизации на python. Кто я в вашей классификации?

                                                                        С аналитиками, дизайнерами и тестерами всё немного прозрачней, но они то в примере с Therac-25 точно невиновны.
                                                                        • UFO just landed and posted this here
                                                                            +1
                                                                            Отчего же, мои обязанности прописаны в договоре. Но что мне остаётся делать? Если я написал библиотеку, а билд-инженера нет, мне нужно ждать, пока компания его наймёт, чтобы включить модуль в сборку? Или мне нужно мириться с отсутствием CI-сервера потому, что его настройка, занимающая в сумме 2 несчастных часа, не входит в мои прямые обязанности? Мне нужно перестать писать тесты потому, что я не тестер и мне не платят за нахождение багов? Мне нужно повторять раз за разом рутинные действия, т.к. я не в должности автоматизатора и писать скрипты — не моя работа?
                                                                            • UFO just landed and posted this here
                                                                                +2
                                                                                у вас в компании что-то не так с организацией труда

                                                                                Абсолютно верно. Людям прекрасно живётся без модульной архитектуры, тестов и CI. Они бояться трогать код и частенько подпирают его костылями.
                                                                                И что я дожлен сделать по этому поводу? Уволиться? Смириться? Или всё же примером показать преимущества лучших практик, упростить их использование настолько, чтобы они стали неотъемлимой частью общего цикла разработки?

                                                                                Более того, очень мало компаний, в которых с организацией труда всё идеально (Google?). Я уже работал в очень крупном проекте, в котором роли каждого человека были расписаны досконально. Повлиять на работу такой «системы» очень сложно. Что дали, тем и пользуйся. И да, я не вернусь туда ни за какие деньги.
                                                                          • UFO just landed and posted this here
                                                                              +1
                                                                              За «software design» и «development practices» в моём понимании должны отвечать те, кого вы называете «кодерами».
                                                                              Если даже за development practices, по-вашему, должны отвечать кодеры, то за что в таком случае должен отвечать CTO?

                                                                              Да и насчёт ответственности кодеров за software design — тоже очень спорное утверждение. Как минимум потому, что кодеров в крупном проекте бывает много, и у каждого есть свой предыдущий опыт работы и, соответственно, свой собственный взгляд на то, как ту или иную вещь делать. Дать им возможность каждому решать за себя, в каком стиле писать вверенный им кусок проекта? Получится хаос. Заставить их сесть и коллегиально вырабатывать единую архитектуру и стиль? Убьют кучу времени, прежде чем договорятся, и всё равно нет гарантии, что выбранное решение взлетит.

                                                                              Именно поэтому в крупных проектах есть разделение ролей. Есть архитекторы, которые на основе своего опыта и компетенции выбирают некое генеральное направление развития проекта, и есть рядовые разработчики, которые в этом направлении проект тянут. Нет, конечно, можно потенциально нанять людей с квалификацией архитектора на позицию рядовых разработчиков, но такие люди знают себе цену, и она высока. Так что целая команда из таких спецов сожрёт бюджет проекта с меньшей отдачей, чем команда более «приземлённых» специалистов во главе с одним архитектором.
                                                                                0
                                                                                Не знаю, сколько времени должно быть у CTO, чтобы проверять соблюдение всех development practices. И, возможно, мы слегка по-разному трактуем словосочетание «software design».
                                                                                Реальный пример: для нашей задачи нам нужен быстрый поиск, мы решаем использовать для этой цели Elastic. Подходяещго клиента для наших нужд нет. Мы говорим «кодерам»: вам нужно написать модуль с интерфейсом I.

                                                                                Вот выделить внутренние классы для решения этой задачи — это software design или уже архитектура и «генеральное направление развития проекта»? С моей точки зрения решение «мы решаем использовать для этой цели Elastic,… нужно написать модуль с интерфейсом I» — это работа CTO и генеральное направление. А проектирование реализации модуля, его скурпулёзная и надёжная реализация — тот самый «software design». Конечно, отлично, если CTO сможет проконтролировать каждый шаг и найдёт ошибки дизайна, переполнения счётчиков и ситуации гонки в результате code-review. Но я так понимаю, посыл статьи (и моя точка зрения) — «кодер» должен быть сознателен и ответственнен за свою работу, он должен принимать больше ответственности, заботиться о сроках, тестах и интеграции самостоятельно, а не просто слепо выполнять волю начальства по инерции.
                                                                                  +3
                                                                                  Для меня «development practices» — это что-то вроде «с сегодняшнего дня мы работаем по методологии scrum» или «каждая фича делается в отдельном бранче» или «весь UX должен автоматизированно теститься через Selenium». Некие базовые моменты. При этом, естественно, просто лозунгом отделываться нельзя — нужно при необходимости создавать инструкции, как достигать поставленных целей — или нанимать тех, кто будет составлять такие инструкции.
                                                                                  И это действительно работа СТО. Его за тем в команду и приглашают, чтобы он создал «правила игры» для этой команды.

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

                                                                                  Организация сode-review и прочих производственных вещей — это задача team lead'а. Он отвечает за процесс внедрения development practices в рабочий процесс и в соответствие результата работы команды заявленному software design'у. Иногда явно выделенного тимлида не существует, и менеджеры полагаются просто на сознательность разработчиков. Но в конечном итоге всё равно находится кто-то, кто сечёт в проекте лучше всего, у кого менеджеры интересуются текущим положением вещей в проекте, перспективами поспеть к очередному milestone'у и т.д. Наконец, всегда есть кто-то, кто помогает новичкам влиться в проект, вводит их в курс дела, как принято работать конкретно в этой конторе, кто проводит технические собеседования наконец.

                                                                                  Также существует отдельная задача — разложить вытекающий из software design'а фронт работ на отдельные задачи, сгруппировать эти задачи по этапам и согласовать на них сроки. Это обычно работа менеджера проекта, хотя не без технических консультаций со стороны тимлида.

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

                                                                                  При этом заботиться о сроках — это задача кодера лишь в том случае, когда он влияет на этих сроков назначение. Потому как бывают ситуации, когда команде даётся просто набор задач и ставится условие: закрыть эти задачи к такому-то числу. Тут уж всё зависит от того, является ли названный срок реалистичным. Если менеджер накосячил и назначил нереальные сроки — это уже его проблемы, и рядовые программисты не обязаны рвать задницу, чтобы эту проблему решить.
                                                                                    0
                                                                                    СТО раз. Архитектор два. Team-lead три. «Учитель» четыре. Тех. Пис. пять. Менеджер проекта шесть. Плюс штат кодеров и, пожалуй, один-два тестера (которые вдобавок тестят не только систему, но и юзабилити). Много для проекта? Почти всегда (посчитаем зарплату всех этих кадров).
                                                                                    Объединим СТО и Архитектора, Team-lead'а и Менеджера, ТехПиса и «Учителя». Функции тестера можно умеючи на кого-нибудь перекинуть. Много для проекта (снова считаем зарплату)? Много.
                                                                                    Объединим… СТО-Архитектор-ТехПис («ну ты же разбираешься!»), Менеджер-Team-lead-«Учитель». Стоп. Два управляющих? Я что, сам себе не начальник? Сократить…
                                                                                    Беда лишь в том, что такими сокращениями и объединениями вопрос выгоды является крайне спорным. Точнее, беда не в этом. Беда в том, что начальство не понимает, как мы работаем и почему надо обеспечить все условия для качественного выполнения задачи с первого раза. Но это уже беда компании, что их Аналитик (если он есть вообще) не просчитывает «долгие деньги» от такой «экономии». А отсутствие должного планирования вообще бич для многих компаний…
                                                                                    И вот в этих условиях всю ответственность за косяки начальства на себя придётся брать рядовым кодерам (хотя и кодерами их уже не назовёшь). «Менеджеры» же предпочитают старую схему: один начальник, много подчинённых. Один технический директор — много «кодеров». Ладно если ещё технический директор сам из этой среды, понимает что и как. По этому поводу много возмущались тут же, на Хабре.
                                                                                    Теперь ответ на вопрос «что делать». Выполнить на досуге работу аналитика и придти с ней к начальству. То есть, работая на скорость, а не на качество, мы ежемесячно теряем n человекочасов, что даёт потерю в n денег. Более того, значительное время приходится уделять не своим обязанностям, в то время как разделение труда себя успешно зарекомендовало ещё несколько сотен лет назад. Наняв <таких-то> людей, мы сможем сократить временные, а, следовательно, и финансовые издержки на полпорядка. Что означает выход на окупаемость в первом же месяце их работать. Далее, есть проблема с материальным обеспечением (ну мало ли, столы неправильно стоят, кофе и печенек хватает только до обеда...), что тоже ведёт к прямым потерям. Таким образом, при текущей организации труда мы теряем <много> денег. Вот вам листок с расчётами, вот рекомендации. Работу стороннего аудитора и аналитика я выполнил бесплатно. Иногда срабатывает, если начальство разбирается в бизнесе, а не «поставлено» кем-то.
                                                                  +3
                                                                  Статья то немного не о том…

                                                                  Трудно увидеть в себе недостатки. Трудно принимать ответственность. Трудно улучшать свою работу, затачивать самодисциплину. Этому надо учиться, и это только от самого человека зависит, начальники тут бессильны. Максимум что начальник может — попытаться нанять программистов в шаолиньском монастыре :)

                                                                  ЗЫ, это я тоже про критику статьи
                                                                    0
                                                                    «которым плевать на даты» — наверное, имелись в виду все-таки свидания (которые тоже dates).
                                                                      0
                                                                      Да, в оригинале «twinkie-eating people, who pay no attention to dates» — пожиратели пирожных, которым плевать на свидания.
                                                                      +4
                                                                      Мне в целом понравилось. Но есть, на мой взгляд, нюансы:

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


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

                                                                      Когда бизнес хочет внести изменения вы говорите «Конечно! Нет проблем, мы внесем их и нет, вам не придётся отдавать почку чтобы это себе позволить»


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

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


                                                                      У автора оригинального поста уже кто-нибудь спросил — эти 20 часов в неделю предоставляет работодатель как оплаченное время, или ребята наивно полагают, что за те деньги, что они готовы платить, у них будут работать спецы, которые в неделю сначала 40 часов работать на них, потом каким-то волшебным образом восстанавливают ману и еще 20 часов изучают новые технологии? Так крайне мало кто может, нанимать таких ребят трудно и плохо масштабируемо. А бизнем не очень любит азартные игры на тему «а что с нами будет, если уволятся адепты Вася с Петей? Найм специалистов с такими умениями за такие деньги — везение и лотерея чистой воды. А если за три месяца не наймем?»
                                                                        0
                                                                        Все вроде бы хорошо, но есть несколько нюансов.
                                                                        1).Менеджерам хотелку бы поуменьшить нужно. Иногда случается такое что наваливают работу на 2-х — 3-ех человек которой должны заниматься 10-15. А потом «я хочу, я хочу» и т.п.
                                                                        2). К классике жанра относится — заплатить 3 копейки и хотеть получить качественное ПО.
                                                                        3). Особенно в больших организациях такое бывает, что один менеджер что бы прогнуться под другим менеджером подписывается под что-то. А потом — вы девелоперы вы и делайте. (Хоть как-то не сделайте, неважно что будет ломаться — потом пофиксите и т.п. а не сделаешь — уволю к чертям собачьим).
                                                                          +1
                                                                          1) Получившийся в итоге факап это проблема менеджера, а не разработчика
                                                                          2) Странная позиция. Напоминает учителей и врачей которые плохо учат и лечат, мотивируя это тем, что им мало платят.
                                                                          Если мало денег — попроси больше. Кадровый дефицит у нас это легко позволяет.
                                                                          Делать не так профессионально как ты можешь потому что тебе мало платят — это неуважение к себе и своей профессии.

                                                                          3) Опять же, разработчикам увольнением никто и никогда не грозит в силу жестокого кадрового дефицита нашей индустрии.
                                                                          Не нравится менеджмент — идёшь в другую контору.
                                                                            0
                                                                            по пункту 2). — нанять неквалифицированных=студентов-студентов, а потом удивляться
                                                                            по пункту 3). менеджеры бывают разные
                                                                          +3
                                                                          Ну, клёво, товарищ перечислил, что ему нужно. Но задача техдира не что, а как, и вот про это почти ничего.

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

                                                                          Уж не знаю почему, но вот вспомнилось, когда читал текст.
                                                                            0
                                                                            задача техдира не что, а как, и вот про это почти ничего

                                                                            Ну так статья называется «ожидания» а не «задачи» техдиректора
                                                                            +12
                                                                            Справедливые ожидания вашего программиста. Чего я ожидаю от руководства.

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

                                                                            2) Выполнение обещаний. Ждете проекты в срок? А как насчет сервера, который мы ждем уже год? Как насчет вопроса, который я задал месяц назад и на который до сих пор нет ответа, не смотря на еженедельное напоминание?

                                                                            3) Занимайтесь своим делом. Это лично мое дело, когда приходить в офис и приходить ли вовсе. Если я согласился на какие-то митинги или на конференции, я буду в срок, но порой мне бывает нужно остаться дома и закончить то, что я кодил вчера до 2х утра.

                                                                            4) Признавайте ошибки. Будьте конкретными. Не «произошли накладки в процессе коммуникации с клиентом», а «менеджер Василий был с бодуна и подписал все, не читая, и теперь вы должны за 1 месяц написать систему управления космическим кораблем»

                                                                            5) Уважайте мое профессиональное мнение. Если я говорю, что что-то надо делать так, то не нужно командным путем заставлять меня делать иначе.

                                                                            Спасибо за внимание.
                                                                              +4
                                                                              Всецело поддерживаю.

                                                                              На самом деле, к этому списку ответных требований каждый разработчик может добавить какие-то свои личные «справедливые ожидания».
                                                                              Например, меня лично угнетает сама концепция однобокости взаимоотношений работодателя и работника. То есть, если работодатель хочет, чтобы ты любил свой проект как родную маму и вкалывал как лошадь на его благо, а в свободное время читал книжки для повышения своей квалификации — это справедливое ожидание. А если ты так и не дождался негласного ежегодного пересмотра зарплаты и вынужден клянчить прибавку у своего менеджера — то это уже «сложный вопрос» и тебе «нужно доказать обоснованность» своих требований.
                                                                              Или, например, когда ты думаешь, остаться ли тебе на текущем месте работы или перейти в другую контору на интересный тебе проект — в личном общении менеджер вешает тебе лапшу на уши, мол, у заказчика на наш проект огромные планы, тут на годы вперёд открытый фронт работ и серьёзный бюджет, а через несколько месяцев проект запиливают, а команду распихивают по другим отделам, заставляя заниматься по сути совершенно другими задачами. Например, меня как backend разработчика на С++ под винду переводили в команду к мобильным разработчикам — клепать UI на Objective-C. Хотя даже в процессе перевода обещали позицию, где можно будет подучиться и попрактиковаться с Java. При этом работодатель искренне считает, что сделал тебе одолжение — не уволил, а взял на позицию, где тебе придётся сначала учиться, а потому первую пару месяцев от тебя, так и быть, не ждут полноценной отдачи.

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

                                                                              Только, как это часто бывает, компании сначала публикуют вакансии с нереальной зарплатой и нереальными требованиями, но оставляют ремарку типа «если вы чего-то из вышеперечисленного не знаете — всё равно пишите». Потом на собеседовании ищут слабые места соискателей, чтобы сбить цену и потом при приглашении на работу иметь позицию типа «ты не наш идеал, и приглашая тебя, мы делаем тебе одолжение».
                                                                              А потом у начальства резко образуется амнезия, и они требуют чтобы ты впахивал по полной программе, а если вдруг чего-то не знаешь — ликвидировал эти пробелы своими силами. Если не смог этого сделать — увольняют после испытательного срока. Если смог — здорово, молодец, работай дальше. Но та нереальная зарплата из изначального объявления о вакансии тебе всё равно не светит.
                                                                              0
                                                                              Касательно «я попробую». Если назван не конкретный срок, а что-то вроде «это займет дня/недели/месяца 4, если повезет, то 3, в худшем случае 5), то можно сказать „да, я попробую уложиться в 3“ лищней отвественности не добавляет. Но заказчик (пускай внутренний) должен понимать, что это аналогично „да, я попробую бросить кубик и выбить 5 или 6“. Пока я будут работать, он пускай молится, чтобы мне повезло и никаких подводных камней не встретилось — может поможет :)
                                                                                0
                                                                                Обычно происходит все с точностью наоборот. Ты говоришь «Я попробую», а вопрошающий слышит «Да, я сделаю это»… Так что с этой частью статьи я по сути согласен — если не уверен, лучше скажи «Нет».
                                                                                +5
                                                                                Пост действительно выглядит как будто спустившийся с заокеанских небес новый начальник, полностью оторванный от реальности, пытается мотивировать бессловесное стадо разработчиков, но в принципе это объяснимо. Этот самый «дядя Боб», автор текста, с 1990 года занимается не программированием, а «консультированием», а также книжки пишет. Поняно, что он больше живет в мире теории и блестящей самопрезентации.

                                                                                Но я подумал: может в его книжках и правда есть секреты, благодаря которым написание тестов ускоряет разработку, а растерянные QA ничего не находят. Пролистал оглавление. К сожалению там набор банальностей: пишите осмысленные комментарии, делайте функции короткими, обрабатывайте ошибки правильно. Мдааа… Ну, надеюсь понятно, что даже самое скрупулезное следование этим советам не приведет к тому, что QA останутся без работы. У нас в деревне таких дядь Бобов булшиттерами кличут.
                                                                                  0
                                                                                  Думается мне, что если всего лишь переименовать статью в «К чему надо стремиться в своей работе, чтобы стать высокооплачиваемым незаменимым профессионалом», то комментарии стали бы совершенно другими.
                                                                                    +1
                                                                                    Если переименовать статью в «К чему надо стремиться в своей работе, чтобы стать высокооплачиваемым незаменимым профессионалом» — то она станет 100% фарсом и ложью. Один только пункт «Мы поддерживаем друг друга» чего стоит! К этому должно и будет стремиться руководство — а нормальный, вменяемый специалист этого всегда будет избегать. Потому что пока я в компании уникален, как специалист и профессионал — мне достаётся куча плюшек, уступки, меня «целуют в зад». Но научив своего соседа своим уникальным, придуманным и опробованным мною, приемам — я сразу теряю эту уникальность. А вместе с ней теряю и те самые плюшки. Ну и зачем оно мне надо? И такое мнение есть по большинству пунктов. Сама по себе идея статьи верная — но вот изложение этой идеи рассчитано только на «верхушку» фирмы, на руководство.
                                                                                    • UFO just landed and posted this here
                                                                                        –1
                                                                                        Меня не могут вызвать в выходные или из отпуска — это одна из положенных плюшек… :) А если меня трамвай переедет — то компании придется искать специалиста с таким же или более высоким уровнем компетенции. И этому я не буду мешать ни после того, как меня переедет трамвай — ни до этого. Но сам себе конкуренцию готовить я не обязан.
                                                                                        • UFO just landed and posted this here
                                                                                            0
                                                                                            Для того, чтобы очень попросить — надо очень сильно мотивировать, Теми самыми же плюшками. Если за выходной я заработаю так же, как за рабочую неделю — то да, я буду считать это достаточной мотивацией для смены своего рабочего графика.
                                                                                            • UFO just landed and posted this here
                                                                                                0
                                                                                                На последнем месте работы стаж 2 года. И надо сказать, что это место работы я не искал — меня на него «переманили». То есть я пришел на рабочее место уже изначально на привилегированных условиях. И условия эти мне достались именно из-за уникальности, как специалиста. :) То же самое было на предыдущем месте работы. И на предшествующем предыдущему. Так что я могу вполне уверенно сказать, что уникальность больше несет плюсов, чем минусов.
                                                                                                • UFO just landed and posted this here
                                                                                                    0
                                                                                                    Это умение раскачивается параллельно с основными рабочими навыками… :) Ведь без отстаивания своих интересов придется следовать вот такому «мануалу начинающего технического директора», что очень быстро сведет на нет всякую мотивацию для самообразования.
                                                                                    +1
                                                                                    Мне кажется, суть в том что «Мы поддерживаем друг друга» в 99% случаев — это наглая ложь. В редких случаях когда ваш начальник не потакает клиенту и не даёт ему растечься фичекрипом по дереву, когда он действительно поддерживает вас и осознаёт когда сроки на имплементацию действительно разумные, тогда я как программер к нему бы ушёл с любой работы даже на меньшую зарплату. И работал бы согласно ожиданиям. Но ведь это же не так.

                                                                                    В реальности мы имеем индивида который в лучшем случае держит вас в известности относительно желаний клиента. И нас как программистов ставят в позицию, когда на «А это сможешь к Пятнице?» мы отвечаем «Смогу, но появится куча левых тесткейсов, а о scalability можно и не думать.» И начальник перестал слушать нас на «Смогу». Позже выясняется что юзеров не десять, а тысяча, и нужно не к пятнице, а прямо сейчас. И мы переводим стрелки на QA потому что кучу левых тесткейсов «Прям щас!» мы делать не имеем ни малейшего желания, нам ещё ядро функционала переписывать до трёх утра потому что костыль на тысяче юзеров сдохнет. И мы всё равно остаёмся крайние, потому что яиц своих у начальника нет чтобы ответственность на себя взять.

                                                                                    Вот эту уёбищность мы терпим, терпим, а потом уходим. Проблема в том что даже уйдя мы уже привыкли писать гуано-подобный код. Надо переучиваться и т.д.
                                                                                      0
                                                                                      да нет же! «Мы поддерживаем друг друга» тут не включает в себя начальство. «Мы поддерживаем друг друга» означает только, что «кого угодно можно уволить и проект от этого не пострадает»
                                                                                        0
                                                                                        Мой теперешний манагер меня (и вообще всех своих подчинённых) поддерживает и именно поэтому я на него работаю задёшево. Правда его все его «коллеги» выжить пытаются из компании.
                                                                                      +3
                                                                                      хехе… директор??? гыгы… да иди ты в жопу директор =)
                                                                                      (с) Мосяня =)
                                                                                        +1
                                                                                        Слушайте, а ему уже написали в ответ статью про то, что программисты ожидают от нормального директора? А то фигня какая-то получается: мы и то должны, и это: в долгах, как в шелках, а он лишь будет говорить нам «хочу к четвергу то-то».
                                                                                          +2
                                                                                          Вы выходите на дорогу и в каждой машине есть несколько процессоров, каждый из которых выполняет код.


                                                                                          Два в карбюраторе и по одному на каждый дворник
                                                                                            –1
                                                                                            Агрессивное обучение — это как? В процессе рычать и кусаться? Или сразу уже выбегать с книжкой и топором на улицу?
                                                                                              +1
                                                                                              Ну за всё хорошее, против всего плохого! Осталось всего лишь найти идеальных людей
                                                                                                +3
                                                                                                >Я расскажу, чего я от вас жду, и это определит ответ на вопрос, профессионалы ли мы.

                                                                                                Когда вопрос ставится таким образом, мне сразу же вспоминается это отличное видео:

                                                                                                  0
                                                                                                  Если честно, я сам не вполне доволен этой формулировкой в оригинале, но перевести надо было, а придумывать предложение заново как-то неправильно несколько

                                                                                                Only users with full accounts can post comments. Log in, please.