company_banner

Blameless environment: никто не должен писать качественный код

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

    Работали ли вы когда-нибудь на плохой работе?

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



    Когда я говорю, все плохо, я имею в виду, что у нас был:

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

    Да, это была аутсорс-разработка, но не это делало её плохой. Люди сделали ее такой.

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



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

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

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

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

    Проблема была только одна — это была моя компания.



    Я тот человек, который начал эту революцию.

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

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

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



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

    Создать порядок из хаоса — это акт творения, который дается тяжело.

    Нужно начать с самого-самого начала, чтобы понять, когда все полетело в хаос. Нужно определить новый порядок и объяснить себе, что нужно делать. Это красивые слова: «Давайте все делать хорошо!». Но ты приходишь на работу и на самом деле не понимаешь, за что браться, чтобы все изменить, нет никаких идей.

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

    Постановка задачи


    Тогда я задумался — а в чем же самая большая проблема? Где самая больная точка, которая не дает жить и работать? Я понял, что это постановка задачи. Для меня постановка задачи всегда была достаточно необязательным делом.

    Думаю, многие из вас видели задачку из одного заголовка «Поправить баг на проде». У нас было много таких, я их писал одной строкой, а потом люди делали что-то не то и пытались исправить не так. Я думал: «Почему же они не думают своей головой? Что вы вообще делаете? Нужно поправить простой баг, а не делать всю эту ерунду».

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



    Задачи должны быть короткие. Не в плане описания, как «поправить баг на проде», но короткие по своей сути. Короткие, маленькие задачи удобно делать. Они понятны любому: новичку, среднему, опытному разработчику. Каждый может понять такую задачу и сделать, например, за половину рабочего дня. Можно начать с этого.

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

    Про упорядоченность задач говорят очень мало: заносят их в Jira или Trello, а потом берут оттуда. Но немногие задумываются, а в каком порядке, почему и зачем порядок именно такой.

    Все задачи должны быть индивидуальными. Что это значит? Задачи — это сущности, которые существуют в рамках проекта и всегда кому-то принадлежат. Иногда прямо в описании задачи можно встретить: «Сергей, Маша, пожалуйста, поправьте это. Вы знаете, как это сделать». Так делать нельзя, нужно дать весь контекст, чтобы эта задача стала индивидуальной внутри себя, чтобы любой человек, который ее прочитал, мог ее выполнить. Чтобы не было никаких разрозненных знаний, разбросанных по проекту, и не было никаких скрытых смыслов в рамках этой задачи.

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

    Просто поменяв способ общения, я добился того, что те самые люди, которые до этого делали ерунду, стали делать то, что я хочу — это ли не магия? Это ли не доказательство того, что очень многое легко изменить. И я начал углубляться в этот вопрос дальше.

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

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



    Это задача не новая. В целом такой подход называется Domain-Driven Design и успешно применяется на протяжении многих лет. Я решил взять лучшее — способ общения, инструментарий, технологии, и постараться сделать так, что разработчики стали понимать, что нужно сделать, чтобы удовлетворить желания клиента.

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

    Требования. С них все начинается, заказчик изъявляет свою волю нам, разработчикам, в виде требований. Клиент условно говорит: «Требую, чтобы страница логина работала». Начинается их осознание, расписывание в виде таблиц, списков, графиков и т.д. Требования остаются с тобой как самая главная часть твоего проекта. Это то, что ты делаешь на самом высоком уровне.

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

    Документация и требования — это близнецы-братья, это двуединство. Требования — это ЧТО нужно сделать, а документация — КАК это делать.

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

    Тесты. Следующий логичный шаг — проверить, что это работает. Мы стали тестировать наши требования, чтобы убедиться, что делаем действительно что нужно.

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

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

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

    Как только мы объединили (Код един!) разработчиков и заказчика при помощи таких хитроумных переплетений разных сущностей, мы добились очень важного: наши разработчики наконец-то стали делать то, что нужно бизнесу. Они перестали внедрять что-то просто так, потому что видели требования и понимали их, понимали, что нужно сделать.

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

    Общение


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

    Мы все общаемся с коллегами на нерабочие темы (обсуждаем сериалы и пр.), потому что мы — люди. Этот недостаток, к счастью, исправим. Для того чтобы понять, насколько на самом деле общение губительно для нас, можно посмотреть на разные примеры.

    Прежде всего, люди отвлекают друг друга и вырывают из состояния потока. Человек просто подошел и что-то рассказал — что мне теперь с этим делать? Зачем он мне это сказал, что хотел этим донести?

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

    Митинги крадут огромное количество времени и не приносят пользы.

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

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

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

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



    Чтобы структурировать общение, достаточно сделать два шага:

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

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

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

    Мы общаемся только на рабочие темы. Если кто-то хочет обсудить «Игру престолов» — извини, мы работаем, а «Игру престолов» обсуждай со своими друзьями. Если хочешь обсудить новую технологию, создай тикет, давай ее обсудим: возможно, она принесет пользу проекту. Но «Игра престолов» точно не принесет пользы проекту.

    Структурированное общение делает разных людей одинаковыми. У GitLab даже аватарки все примерно одинаковые — у одного буква K, у другого C, и я не знаю, кто эти люди. Мне все равно, какие они, главное — они общаются в рамках структуры.

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

    Код


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

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

    Но раз так, с этим можно что-то делать и научиться работать именно в этих условиях.



    Для того, чтобы с этим работать, нужна строгость — CI и тесты, которые будут максимально строги к тому, что ты делаешь. Это должен быть Страшный Суд — инструмент, который ответит на вопрос, хороший код или плохой. Только взглянув на него, всевидящее око CI скажет, попадет ли твоя работа в master или так и останется где-то на stage.

    Такой CI, естественно, должен быть неотвратим. Как только кто-то получает исключительное право коммитить в master, все попытки построить процессы разваливаются, потому что этот кто-то начинает делать всякую ерунду.

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

    Как только фундамент готов, можно двигаться дальше.

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

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

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

    Blameless environment


    Я назвал этот подход Blameless environment — это значит, что я никогда ни в чем не виню людей. Если баг попал в ваш проект, это проблема проекта. Этот баг должен быть поправлен так, чтобы он больше никогда не случился. Если это баг в коде, нужно написать регрессионный тест. Если это баг в инфраструктуре проекта, нужно написать инструмент, который этот баг предотвратит.



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

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

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

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

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

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

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

    Каждый следующий шаг имеет смысл только тогда, когда есть фундамент предыдущего.

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



    Давайте поговорим о дарах — какие дары есть в разработке.

    Самый главный дар — это наши баги. В каждом продукте есть баги. Многие люди хватаются за голову: «У нас баги на проекте, представляете?!» Но все же с ними живут, просто есть критичные баги, а есть не очень.

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

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

    Скрытый баг — это плохо, найденный баг — это хорошо.

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

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

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

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

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

    Эту систему можно исправить, и сделать это несложно. Вы можете взять все те инструменты, которыми пользуемся мы, поставить их себе и работать. Они все в open source, поэтому вы легко можете начать делать так же.

    Имплементация


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

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

    Нет общения. У нас некому сказать, что ты сегодня не собираешься работать или собираешься работать. Фактически нам все равно: собираешься работать — хорошо, не собираешься — тоже ладно. Даже системы информирования об этом нет.

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

    Боты управляют людьми. Но для того, чтобы все это функционировало, не должно быть главного человека — того, кто бы всеми руководил. Если есть кто-то самый главный, то получится не свобода, а ерунда. Поэтому нам нужен бот, чтобы править всеми. Он тоже выложен в open source.

    Всё код. Когда работаешь с разработчиками, пишешь требования как код, документацию как код, всё как код, понимаешь, что всё код. Так можно сделать очень и очень многое, потому что код можно линтить, тестировать, отслеживать его изменения во времени и т.д. Код един!

    Оплата за результат. Это самая холиварная часть: мы не платим зарплаты. Кто-то пошутил, что мы не платим разработчикам в принципе. Действительно есть люди, которые с нами работали и ничего не заработали, потому что ничего не сделали. Мы платим только за результат. Так как задачки маленькие, понятные, мы можем каждой задачке определить цену. Человек выполняет задачу и получает за это деньги.

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

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

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

    С приходом Agile многие команды осознали, что за качество отвечают не только тестировщики. Чтобы рассмотреть все аспекты разработки качественных продуктов мы запустили QualityConf, в этом году в рамках РИТ++, а в следующем — вынесем в отдельное мероприятие. Видео прошедших выступлений смотрите здесь, а чтобы не пропустить информацию о конференциях, подпишитесь на рассылку.

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

    Кого винить, если в компании плохие процессы и некачественный код?

    Конференции Олега Бунина (Онтико)
    735,04
    Конференции Олега Бунина
    Поделиться публикацией

    Комментарии 51

      +5
      Прочитал статью, озвученные проблемы имеют место, но решение как по мне очень спорное.

      При таком подходе возникают следующие вопросы — кто оценивает время выполнения задачи (ну или её цену). Что делать, если сложность задачи недооценили, как оценивать задачи на проектирование или на исследование проблемы. Как ставится задача когда есть проблема (бага) но она плавающая/сложно воспроизводится/непонятно откуда «ноги растут». Кто-то же должен локализовать проблему и разобраться, при этом время оценить в принципе нельзя, только по факту. Что делать если никто не берёт какую-то задачу потому что не хотят?

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

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

      Я могу быть не прав, тогда поправьте меня)
        +3
        >В общем такое ощущение, что данный подход работает только при аутсорсе, при этом компания представляет собой всего-лишь ещё одну биржу, и смысл работы в ней непонятен.

        Очень хорошо сформулировано. Да, компания которую наверное лучше обходить стороной )
          0
          «А судьи кто?»
            0
            *upd. простите ответил сразу не на тот комменатрий

            судьи — опытные разработики которые будут голосовать ногами
              +2
              Я работал фрилансером, с почасовой и оплатой за проект. Так вот с оплатой за проект было трудно и невыгодно, т.к. всегда возникают задачи, которые ты не ожидал. Договорились что за 6 месяцев поставлю систему, в итоге работал 12, реально последние 2 месяца работал себе в убыток, лишь бы закончить проект.
                0
                мне кажется что многим инженерам будет претить торговаться за каждую задачу, ощущение как на рынке в Индии. Поэтому на fix price наверное можно соглашаться только от безысходности, и всегда радуешься когда вырастаешь из этих штанишек.
                Только хорошая почасавая оплата, желательно с людьми которые говорят на английском без сильно выраженного русского акцента.
          +9
          >Мы общаемся только на рабочие темы. Если кто-то хочет обсудить «Игру престолов» — извини, мы работаем, а «Игру престолов» обсуждай со своими друзьями. Если хочешь обсудить новую технологию, создай тикет, давай ее обсудим: возможно, она принесет пользу проекту. Но «Игра престолов» точно не принесет пользы проекту.
          >Оплата за результат. Это самая холиварная часть: мы не платим зарплаты. Кто-то пошутил, что мы не платим разработчикам в принципе.

          жесть
            0
            Игра престолов или оплата за результат?
              0
              и то и то.
              В книге «Remote. Офис не обязателен» авторы наоборот говорили о необходимости неформального общения, мол этот «water cooler» где обмениваться анекдотами и фильмами, тут же тезис о том что все должно быть жёстко про бизнес не совсем раскрыт, мне кажется это не будет работать в долгосрочной перспективе.
              Тоже самое с оплатой за результат, люди уйдут как только смогут найти что-то получше.
              +2
              Оплата за результат у меня всегда асоциируется с сетевым маркеттингом аля орифлейм.
              +2

              не хватает примера задачи с оценкой

                +1
                Спасибо за полезную статью. Хотя многое в ней завязано на удаленную работу, как я понял, какие-то процессы можно применить и к работе в офисе — грамотная постановка задач, кодревью, линтеры. Насчет общения на нерабочие темы — для этого есть короткие перерывы на кухне, к примеру. Там никто никого не вырывает из потока. Насчет митингов — согласен целиком и полностью. Поэтому, если и проводить их, то а) быть подготовленным б) делать их короткими и по выделенной тематике с) в соответствии с предыдущим пунктом, звать только необходимых людей. Как-то так.
                  +10
                  Мммм, механистический подход к труду, прямо как сто лет назад.
                  Работать точно будет, даже достаточно эффективно. Одна беда, люди, которые могут найти более человечное место, уйдут очень быстро. Останутся либо те, кто не сможет найти, либо те немногие, кому действительно совсем не нужно общение на работе.
                  Для простых задач не критично, конечно, но что-то действительно интересное в такой обстановке, мне кажется, не создать. Просто слишком жесть. Вот избавиться бы от абсолютизма, сделать поправку на то что люди не машины, и как все лучше было бы.
                    0
                    В скором будущем так и будет, но вместо людей будут роботы. Вполне возможно типовые задачи систематизировать и создать таких роботов.
                      +3
                      Гм, с другой стороны… работа без приседаний, где я честно продаю свое время за деньги, а не притворяюсь, что мне нравится лайкать уродливые фотки новорожденных в #general.
                      +5
                      А «цену» тикета кто определяет? Разработчик может отказаться от задачи, если не согласен с её ценой?

                      Может быть, я морально не готов к этой прорывной идее или неправильно понял посыл статьи — но это все звучит как описание очередной галеры с небезызвестного сайта на домене .it — и менеджер-евангелист, который, разумеется, может писать код сутки напролёт, и невероятный контроль на рабочем месте (про игру престолов нельзя говорить, линтер пишет код за тебя, потому что менеджер для себя решил что никто не умеет писать код [как ему нравится]), неопределенная зарплата по тайным kpi.
                        +1
                        Мы понимаем, что разработчики могут исчезнуть, не хотеть работать и не работать, у них может быть плохое настроение, им нужна полная свобода.

                        Я не очень понял, как обрабатывается случай, когда человек подписался на выполнение задачи и потом исчез. У задачи же есть определенный срок — договоренность с заказчиком, что задача будет выполнена к определенному времени. И что делать с такой «подвисшей» на конкретном сотруднике задачей?
                          +4
                          Шикарно, почти идеально, с оплатой только не очень понятно, как например оценивается сделал ревью человек или нет?
                            +2
                            Фактически нам все равно: собираешься работать — хорошо, не собираешься — тоже ладно.

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

                              А это точно не статья Егора Бугаенко? Как-то очень много общих тезисов.

                                +1
                                Да! Звучит прям как франшиза одиозной потагонки от Егора
                                +1
                                Если у вас все(ну или большая часть) народа это фрилансеры на удалёнке, то это может быть и имеет смысл так работать. Но для более-менее нормальной фирмы это какая-то адская жесть. Я бы так точно работать не cтал и не факт что вообще бы смог.

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

                                  По тексту — есть хорошие идеи, и в идеально настроенном подобном окружении наверное хорошо работать. Но вот только смущают несколько моментов.
                                  • Кто ставит задачи, как это оплачивается (это ведь тоже работа, очень важная и не простая).
                                  • Что делать если задача оценена неверно? Очень часто случается так, что какая-то простая на первый взгляд задача выливается в лютый адище для разработчика. А ее уже оценили в какие-то копейки, и исполнитель приступив к работе внезапно понимает что все эти потраченное на работу время и силы будут очень дешево оценены.
                                  • Как быть с людьми, которые взялись за сложную и блокирующую множество других задачу, и задинамивших всю работу. Сначала просто отделывающихся фиктивными рапортами о работе, а потом и вовсе исчезнувших с радаров?
                                  • И, еще раз — какой алгоритм оценки задач? При постоянной з/п этот вопрос не сильно критичный, ну ошиблись там, задача оказалась сложнее чем ее первоначально оценили, провозился с ней человек вместо запланированного дня, целую неделю. (Примем за данность то что человек добросовестный и специально резину не тянет, задача действительно оказалась непростой). На окладе ничего страшного не случилось, разработчик получит свою з/п и не будет сильно переживать, а как быть при такой сдельной работе?
                                    По идее должны быть какие-то механизмы переоценки задач постфактум, иначе все разработчики начнут ради снижения риска брать исключительно тривиальные задачи, а все важные но более сложные навечно зависнут в беклоге
                                    0
                                    А меня люто бесит сочетание этого проклятого новомодного опенспейса и общительных коллег, которые перекрикиваются из одного угла опенспеса в другой, или как раз в том момент когда тебе надо сосредоточится начинают шумно обсуждать очередную игру престолов.

                                    Хм, а кто сказал что надо обязательно из одной крайности бросаться в другую? У нас например комната на 6 человек и пообщаться на нерабочие темы мы обычно выходим на кухню :)
                                      0
                                      Увы, это не такая уж крайность. Все последние места в которых работал были с опенспейсом и коллегами которые никуда не выходили пообщаться. (Да если прямо попросишь не шуметь, какое-то время это работает, но недолго, а постоянно ругаться тоже не вариант, по множеству причин)
                                        0
                                        Я один раз в своей жизни работал в опенспэйс и мне пришлось купить себе хорошие наушники с активным шумоподавлением. И сидеть в них всё время, даже если я не слушал музыку.
                                        К счастью страдал не только я и в какой-то момент начальство восприняло жалобы всерьёз. И опенспэйс разбили на комнаты.

                                        Так что либо давить на начальство, либо менять работу, либо покупать наушники :)
                                          +2
                                          Наушники, увы, не отключают шум визуальный. Ходящих туда-сюда, переключающих лампы, иногда вид из соседнего монитора(зависит от того как столы расставят) поверх твоего монитора бывает.
                                          Шоры для программистов ещё не встречал в продаже… и, пожалуй, не хочу встретить.
                                            0
                                            Да и наушники… Шумодав эффективен не на 100%, а заглушать все музыкой — лично я от этого тоже устаю, я бы предпочел просто тихое помещение.
                                      +1
                                      Не исключаю, что все держится на гениальных пмах, которые продают заказчику задачу за миллион, а потом делят на пять разработчиков по рублю каждому.
                                    +2
                                    Мы платим только за результат. Так как задачки маленькие, понятные, мы можем каждой задачке определить цену.
                                    Должна начаться борьба за «вкусные» задачки. И оптимизаторы прибыли. Будет очень весело через некоторое время.

                                    Плюс люди назначающие цену почувствуют вкус жизни и тоже порадуются.

                                    Ну и концепция «blameless environment» с душком, так и видится как руководство топят за blameless, а по закону единства и борьбы противоположностей, на самом деле у них там blameful
                                      0
                                      > Мы научились записывать требования в специальном формате и формировать документацию.

                                      Сколько лет формам IDEF? Сколько лет ARIS? Сколько лет UML? И вот ещё кто-то сделал для себя открытие — требования можно формализовать! Давайте придумаем, как это делать!
                                        +1
                                        Чтобы структурировать общение, достаточно сделать два шага:

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



                                        Это гениально! :)
                                          +1
                                          Вимо речь про канал связи, а не про канал в телеграме
                                            +2
                                            Постулат получился настолько с одной стороны простым, а с другой — многослойным, что совершенно неважно о каком именно канале идёт речь! Потому и гениально.
                                          +1
                                          Это у них, что, франшиза Yegor 256?
                                            0

                                            У меня похожий жизненный опыт, поэтому я согласен с автором на 95%.

                                              0
                                              А бы в постановку задачи добавил еще один пункт из своей практики: задача должна быть проверяема. У меня был интересный опыт, нужно было расширить фреймворк, одной удобной фичей. Я написал фича-реквест, и приложил к нему тест которому должна была бы удовлетворять реализация. Но это не обязательно должны быть формальные критерии, это могут быть критерии описаные словесно. Список критериев. Тогда вероятность, что сделают не то и не так снижается значительно и задача выполняется быстрее.
                                                +3
                                                По своему опыту удаленной работы могу сказать так: работал и в таких вот «эффективных» условиях и в нормальных. В «эффективных» не выдерживал больше 2-3 месяцев, особенно где scrum. Просто прорву времени отнимает на то чтобы послушать как никто ничего не успевает и что надо сделать чтобы все всё успевали. И это изо дня в день месяцами. В нормальных адекватных компаниях наоборот, никто тебя не контролит, все довольны, проект живой, развивается и работать всегда интересно. Не чувствуешь никакого давления и негатива. Так вот, к чему это я: в 100% случаях где такие «галеры» — проекты стагнируют и деградируют (с точки зрения человеческого фактора. бизнес как ни странно прибыль приносит всё равно), люди уходят. А в нормальных человеческих условиях проекты растут, релизятся новые классные штуки, и в целом люди довольные, ценят то что делают. Причем это актуально как для РФ так и других стран. У меня проекты и в США и в РФ, ничего не отличается.
                                                  0

                                                  Ни разу не встречал проектов с "нормальными" условиями.

                                                    0
                                                    Ни разу не встречался с ненормальными, за 30 лет и десятки проектов. Один раз было близко к «ненормальному», причина была некомпетентный-самодур руководитель, но я там был консалтером на пару недель, так что не понял, это реальность или ширма, для внешних работников.

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

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

                                                        Или вы хотите сказать что перфекционист всегда намереет себе 100%? Сомневаюсь, скорее наоборот.

                                                        Ну и когда идёт разговор в целом, а не о конкретных случаях, то отклонениями от нормы (перфекционистами, ж0п0лизами и т.п.) можно пренебречь.
                                                          0

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

                                                  0
                                                  Не совсем в тему. Но периодически одна мысль приходит по поводу «хорошего кода». А всегда ли он в принципе возможен? Как-то стараешься, ищешь, придумываешь, в общем идёшь к невидимой цели, тратишь силы. А она вообще существует, эта цель? В простых случаях существует. В сложных — возможно в принципе невозможно сделать идеальный код? Может быть, в большей или меньшей степени, сложный код всегда будет нагромождением странных конструкций?
                                                  Теоретической базы под это наверное нет.
                                                  Но взять, для примера, математику. В простых случаях всё просто и красиво 2+2=4. А чем дальше в лес… Тем всё малопонятнее и малопонятнее.
                                                    +2
                                                    Тут как в школе, ты может задачу и решил, однако у тебя, мол, поля в тетради не расчерчены, слово «ответ» не выделено, и промежуточные шаги не обозначены, поэтому четыре с минусом. А так ты можешь быть хоть Альбертом Германовичем Эйнштейном, всем пофиг.

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

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

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

                                                    Идеального кода, конечно, не существует, и не может существовать, потому что код всего лишь средство выражения мысли. Все что я сказал можно написать совсем другими словами, и кто-то скажет что стилистика стала лучше. Кто-то посчитает что это вообще не относится к делу, и поставит минус. Люди оценивают нашу работу. Нужно делать так, чтобы большинству она нравилась. Так что не надо париться, но нельзя не париться вообще.
                                                      0

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

                                                        0
                                                        Писать понятный код не легко, но в этом нет ничего невозможного. Просто само превращение некоего кода в понятный требует вполне ощутимых трудозатрат, и многие пытаются сэкономить эту работу. Потому что часта сама задача непонятна, и не известно, решит ли только что написанный код «что-то»
                                                      +1
                                                      Ещё с линтером момент — они тупые обычно и при закручивании гайк придётся не работу делать, а линтер удовлетворять, поэтому было бы интересно услышать тех кто работал в этой системе по этому и другим вопросам.
                                                        0
                                                        Боюсь, что это всё про начало эксперимента (который провалится), а не про опыт успешной компании, которая прожила хотя бы лет 5.
                                                          +1
                                                          Сюда бы самого Никиту в комментарии =)
                                                            0
                                                            Оплата за результат. Это самая холиварная часть: мы не платим зарплаты. Кто-то пошутил, что мы не платим разработчикам в принципе...
                                                            — для галер и аутстаффа подход, может быть, и оправдан, но со стороны разработчика возникает острое чувство социальной незащищенности. Вот сломал коллега руку — все, будет кушать воду из-под крана?

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

                                                            Самое читаемое