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

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


“Who Cares About Quality? (in Russian)”

Ответы на вопросы к докладу “Who Cares About Quality? (in Russian)".

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

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

Большинство ошибок приходятся на этап кодирования, и эти ошибки часто “отсекаются” линтером. Архитектурные ошибки линтером не отсекутся, конечно, но таких ошибок довольно мало на проекте, чем банальных дефектов типа неработающих кнопок.

Q: Ротация - довольно дорогая штука для проекта, ведь новичок должен вникнуть в проект, используемые технологии и написанный до него код. Иначе говоря, ротация замедляется архитектурной синхронизацией новичка. Что ты на это скажешь?

Текучка (ротация) действительно “утяжеляет” проект, но если в нем качество на высоком уровне и присутствует документация, то ротация проходит настолько безболезненно, насколько это возможно.

Если проект ценит людей больше, чем код, то это - плохой проект.

Разработчики должны быть на службе у кода. Мы - заменяемые ресурсы: пришли - сделали код лучше - ушли. Проект продолжает жить.

Чем легче вас уволить, тем лучше вы профессионал.

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

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

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

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

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

Серьезного технического специалиста можно замотивировать только проблемами.

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

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

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

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

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

Если же мотивацию строить на проведенном времени в офисе, то люди будут просто жать кнопку “Approve” раз в час, чтобы сымитировать активную деятельность, и чай пить параллельно.

Ответы на вопросы после выступления в офисе EPAM в Питере

Видео: youtube

Q: Есть разные роли в проектах. Простых исполнителей, от работы которых не зависят другие (в большей степени). Они могут работать удаленно откуда угодно: дача, дом, Бали, Тайланд и тд. А что насчет ключевых позиций на проекте типа архитектора или девопсера, который должен настроить архитектуру? Будут ли они на фрилансе?

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

Инженер - это тот, кто умеет излагать свои мысли ясно на бумаге, а не “на пальцах” как обезьяна.

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

Q: Если есть стартап, которому нужно быстро запуститься, и ему нет времени формализовать свои требования. Что делать им?

Мы не работаем в Zerocracy с избыточными требованиями, требования формализованы ровно настолько, насколько это необходимо. Главное, чтобы исполнители понимали, что им нужно делать. Объяснить можно словами, а можно текстом, и текстом предпочтительнее. Как минимум потому что повторять второй раз не придется.

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

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

Q: Что насчет командной работы, синергии, командного духа?

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

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

Q: Как вы оцениваете качество кода?

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

В стандартной команде же разработчик неделю работает, вываливает пулл-реквест на 7к строк, и кто будет его смотреть? “Давайте мерджить уже, пятница, сейчас пиццу привезут… Разберемся в понедельник.”

Q: Как передаются знания в проекте?

Знания в стандартной команде витают в воздухе в головах участников проекта, именно поэтому новичку нужно время на раскачку. В опенсорсе и в Zerocracy же не так. Вот тебе тикет на полчаса, ждем пулл-реквест.Новичок открывает код и ищет причину проблемы. Если новичок не может разобраться в коде, то это - дефект проекта - документация “бедная” или отсутствует. Не вини себя, не учись, не пытайся понять, а пиши сразу багрепорт. Ее подтянут, разберутся, починят или объяснят, и тогда ты получишь деньги не за тикет, а за этот багрепорт. Когда по багрепорту отработают, ты снова возьмешь свой первый тикет и попробуешь разобраться. И таких кругов может быть несколько. Так проект и улучшается.

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

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

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

Q: Кто будет отвечать?

А что значит “отвечать”? Возьмите любой договор о разработке продукта, и там ни слова о том, кто будет отвечать. В договорах обычно прописывают, что заказчик покупает 50 человек в свои ресурсы, и аутсорсер лишь отвечает за то, что эти 50 человек приходят в офис и у них есть все необходимое для выполнения своей работы. Ни один аутсорсер не соглашается на договор по принципу Fixed Price, ему это не выгодно. В основном это аренда людей, slave-trade.

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

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

Q: Кому ваш подход подходит?

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

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