Егор много выступает, и практически после каждого доклада ему задают вопросы. Ответы на вопросы Егора очень ценны, на мой взгляд, сами по себе, даже в отрыве от основного доклада. Эта статья - набор тех ответов, которые мне больше всего понравились. Ответы на доклады, которые я уже законспектировал, я выкладывать здесь не буду, дабы не повторять материал.
Вопросы и ответы даны в моем пересказе, и на полную точность передачи не претендую. Статья будет постоянно дополняться по мере публикаций выступлений Егора.
Q: Мне показалось, что в докладе говорится о низкоуровневом качестве. А что насчет качества выбранной архитектуры?
Неверно выбранная архитектура - это действительно баг, который может обойтись дороже, чем любой другой на проекте. Но по опыту Егора, архитектурные решения принимаются довольно редко, а кода пишется много. Все архитектурные решения принимаются в начале проекта при запуске: выбор фреймворка, базы данных и другие инфраструктурые вопросы. Дальше программисты пишут обычный код на основе тикетов, которые разбиты на микро-задачи по полчаса-час работы. Какие-то архитектурные решения в таких тикетах будут приниматься довольно редко.Большинство ошибок приходятся на этап кодирования, и эти ошибки часто “отсекаются” линтером. Архитектурные ошибки линтером не отсекутся, конечно, но таких ошибок довольно мало на проекте, чем банальных дефектов типа неработающих кнопок.
Q: Ротация - довольно дорогая штука для проекта, ведь новичок должен вникнуть в проект, используемые технологии и написанный до него код. Иначе говоря, ротация замедляется архитектурной синхронизацией новичка. Что ты на это скажешь?
Текучка (ротация) действительно “утяжеляет” проект, но если в нем качество на высоком уровне и присутствует документация, то ротация проходит настолько безболезненно, насколько это возможно.Если проект ценит людей больше, чем код, то это - плохой проект.Разработчики должны быть на службе у кода. Мы - заменяемые ресурсы: пришли - сделали код лучше - ушли. Проект продолжает жить.Чем легче вас уволить, тем лучше вы профессионал.Чем более вы заменяемы, тем выше качество продукта, который вы пишете. Если вам легко заменить и перекинуть на другой проект, значит вы правильно настроили процессы вокруг себя, минимизировав свое участие и перенеся все свои знания в репозиторий проекта.Если же вы незаменимы, если только вы знаете, как работает тот или иной модуль в вашем проекте, значит у вас низкий профессиональный уровень.Ротация - это хорошо. Ротируя людей, мы тестируем нашу систему. Если мы увидели, что после замены какого-то человека система встает, то значит мы выявили проблему. И решив эту проблему, проект станет стабильным.
Q: Мотивация деньгами - не самая лучшая мотивация, есть множество других аспектов. Например, желание разработчиков использовать новые подходы, фреймворки. которое не будет пропущено пайплайном. Что насчет мотивации, которую не всегда деньгами купишь?
Егор согласен, что деньгами не создашь интерес к работе. Деньгами можно создать интерес только у тех, кому нечего есть. Егор считает, что хорошо мотивирует высоко поставленная планка качества в его проектах и решение сложных проблем.Серьезного технического специалиста можно замотивировать только проблемами.Чем серьезнее проблема поставлена перед программистом, чем больше усилий ему нужно приложить для решения этой проблемы (в том числе и пайплайн проекта), чем больше менеджмент уделяет внимание дисциплине и организации работы, тем больше программисту нравится работать. Полная свобода на проекте чаще всего демотивирует. Чем больше внимания обращают на результат работы программиста, тем больше мотивации.Проект создает программисту комфортную среду. Можно привести аналогию: ехать гораздо комфортнее по автобану с организованным движением, светофорами и инфраструктурой. Иногда хочется и по бездорожью проехаться, когда ничего не известно и риск высок, однако это желание приходит не так часто. Второй вариант - это больше креатива, однако и риски больше. Первый вариант может показаться скучным относительно второго, однако, по опыту Егора, мотивирует все же ощущение, что менеджменту “не все равно” на проект, на его качество и на результат работы отдельно взятого программиста. У сеньоров возникает интерес поработать в таких условиях, а джуны действительно быстро отсекаются.Профессионал не хочет отвечать за чужие ошибки, он не хочет, чтобы ему кто-то мешал работать. Он хочет, чтобы ему дали понятный скоуп работы, понятные правила, понятный тикет. В процессе работы над тикетом профессионал не только узнает что-то новое, но и видит, что результат его работы сразу вливается в общую кодовую базу. Это и мотивирует специалистов, считает Егор.
Q: Егор, ты говоришь, что распределенная команда - это лучше, чем команда в одной комнате. Но если каждый участники сидит в своей локации и пишет код в своем модуле, то зачем ему проводить код-ревью другому программисту и тратить свое время?
Действительно, если мне никогда больше не работать с тем кодом, которому я провожу код-ревью, то мне и мотивации нет делать это код-ревью качественно. Нужно мотивировать людей. Егор делится опытом, что оджнажды они платили за количество комментариев в код-ревью, чем больше комментариев, тем больше денег ревьюер получал. Это работало не так плохо. Конечно, были элементы обмана, однако и автор кода - тоже человек, который увидит придирки ради придирок и напишет репорт архитектору. Система была работоспособна. Также учитывался и средний показатель ревьюера: ревьюеры, после ревью которых остается больше комментариев, оплачивались дороже. Что-то подобное можно придумать и в ваших проектах, говорит Егор.Если же мотивацию строить на проведенном времени в офисе, то люди будут просто жать кнопку “Approve” раз в час, чтобы сымитировать активную деятельность, и чай пить параллельно.
Видео: youtube
Q: Есть разные роли в проектах. Простых исполнителей, от работы которых не зависят другие (в большей степени). Они могут работать удаленно откуда угодно: дача, дом, Бали, Тайланд и тд. А что насчет ключевых позиций на проекте типа архитектора или девопсера, который должен настроить архитектуру? Будут ли они на фрилансе?
Да, они будут. Тенденция к этому и ведет. Как они смогут работать удаленно и коммуницировать - это вопрос нашей с вами квалификации. Пока что нам кажется, что без митингов ничего не решить, однако научиться - это дело времени. Митинги нас развратили.Инженер - это тот, кто умеет излагать свои мысли ясно на бумаге, а не “на пальцах” как обезьяна.На бумаге - это не только документация, но и различные диаграммы. Проще собраться на митинге и объяснить, конечно. Однако письменная коммуникация лучше. Есть какая-то мысль или идея - напиши простым английским/русским языком. Если в ней есть смысл, то проект ответит тебе.
Q: Если есть стартап, которому нужно быстро запуститься, и ему нет времени формализовать свои требования. Что делать им?
Мы не работаем в Zerocracy с избыточными требованиями, требования формализованы ровно настолько, насколько это необходимо. Главное, чтобы исполнители понимали, что им нужно делать. Объяснить можно словами, а можно текстом, и текстом предпочтительнее. Как минимум потому что повторять второй раз не придется.Вторая причина, зачем писать тикеты, а не объяснять их словами, заключается в том, что когда наступят времена фрилансеров, каждому новому человеку на проекте (а это случаться будет часто) не нужно будет объяснять те или иные архитектурные решения. Новичок на проекте просто прочтет об этом из обсуждений.Это уже происходит в опенсорсе. Когда вы хотите контрибьютить в какой-нибудь проект, специально для вас не создают митинг, где вам объясняют суть проекта. Вот код, вот репозиторий, вот правила - бери и делай тикеты.
Q: Что насчет командной работы, синергии, командного духа?