Эта статья - конспект видео-доклада Егора Бугаенко. Доклад доступен на youtube по ссылке.


В чем проблема

Если у вас очень “умная” команда, то у вас проблемы.

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

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

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

1. Subject Method Experts (SME)

SME - это “эксперты в определенной области”, в определенных модулях системы. Люди начинают хорошо понимать, как работает та или иная часть проекта системы. Это происходит органически, произвольно, никто не делает это специально. Эти люди стремятся подольше остаться в этой позиции, они неохотно делятся своими знаниями, ибо так они становятся нужнее своей компании. И чем дольше они обмениваются знаниями вербально, чем дольше они находятся в позиции архитектора / главного разработчика / ответственного за отдельный модуль проекта, тем больше они стараются защитить себя от внешних “угроз” - передачи информации кому-то другому.

2. Неуправляемая команда

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

3. Отсутствие документации

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

4. Неподдерживаемый код

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

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

Программисты пишут для себя, а не для кого-то другого.

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

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

5. Потеря времени и денег

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

А как может быть иначе?

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

Ситуации, когда команда год работает над проектом и в ее тикет-системе зарегистрировано только 70 багов (что Егор считает почти нереально низким числом за год), происходят часто, если репозиторий и/или тикет-трекинг система не является центров всех коммуникаций. “Вот такая мы классная команда”, - говорят они. А знания остались у них в головах, как и остальные 700 или 7000 багов, которые не были зарегистрированы. Эти баги были решены на митингах, которые уже никак не поднять в будущем и не пересмотреть. Новички в проекте вынуждены будут подходить и спрашивать “старожил” проекта о том или ином архитектурном решении, и в итоге у нас зависимость от конкретных людей - экспертов. А эксперт не захочет делиться знаниями и даст их порционно, и каждую порцию еще и проси у него.

Репозиторий с кодом и тикет-система должны идти вместе. GitHub в этом плане хорошо спроектирован, другие системы не так прокачены. Тут тебе и тикет/баг, тут же по нему обсуждение, тут же команда приняла решение по проблеме и тут же приаттачен pull-request с решением проблемы.

Мы все видим единым таймлайном: кто начал, кто закодил, кто замерджил, кто задеплоил и чем все это кончилось.

Какие мы получаем преимущества

1. Повышается информационный фон (documented info flow)

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

2. Документированный код (documented code)

Мы “заставляем” участников команды документировать код через код-ревью или иными способами.

3. (maintanable code)

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

4. (code is a king)

Код становится центром проекта и коммуникаций. Как добиться этого? Запретить митинги в любых их проявлениях.

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

Вопросы из зала

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

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

плохие программисты не могут отказаться от митингов, потому что они не умеют писать граммотно тикеты и issue в GitHub, им проще все сказать словами, им важны эмоции.

В итоге мы отказались от таких “плохих” программистов.

Как долго заняла трансформация - полный отказ от митингов?

Пару лет. Сначала мы отказывались от некоторых митингов и постепенно сокращали их число, пока не осталось ни одного. Митинги только вредят. Есть GitHub и есть митинг; на митинге мы что-то обсудили, а в GitHub не написали, и в итоге информация потерялась.

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

А что стало с атмосферой в команде?

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

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

Что делать, если люди начинают игнорировать обсуждеия в GitHub? Ну есть и есть там обсуждение, меня оно вроде как не касается.

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

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

В первую очередь ему нужно ответить, ведь он получит за это деньги.

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

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

Как не допустить хаос неконтролируемых изменений в коде?

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

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

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

Вторая проблема - проблема избытка тикетов - это тоже беда именно джуниоров, а не системы. Если человек не умеет четко поставить вопрос или описать проблему в одном тикете, значит проблема в этом неумении, а не в системе. Джуны действительно начинают спамят тикетами, задают в них вопросы типа “помогите разобраться, вот мои B вопросов”. Иначе говоря, люди переносят идею митинга в обсуждение на GitHub.

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

Во вторых, некоторые джуны создают тикеты с текстом “help me, I don’t understand” и ждет, что придет эксперт и объяснит ему. Как будто задал вопрос по телефону кому-то.

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

получить ответ можно только лишь задав правильно и лаконично вопрос.