Эта статья - конспект видео-доклада Егора Бугаенко. Доклад доступен на youtube по ссылке.
Если у вас очень “умная” команда, то у вас проблемы.
Здесь Егор имеет в виду не интеллект, а количество знаний, которые в голове у членов команды, хотя этому место в документации или коде. Если в команде есть люди, которые обладают большим количеством знаний о продукте, который вы пишете, то у вас как у менеджера проблемы. Такие “эксперты” могут завалить проект.
Стандартным видом коммуникации в этом случае являются митинги. Чаще всего структура коммуникаций складывается такая: в центре коммуникаций некий архитектор, который понимает проект, его историю, как он собирается и тд, а вокруго него остальные члены команды.
Важным аспектом проекта является вопрос, как эта группа людей решает ахитектурные вопросы. Чаще всего архитектор принимает решение и вербально передает его команде. Команда что-то кодирует, и в результате проект обрастает новым кодом. Получается, что репозиторий проекта - это результат какой-то устной коммуникации. И тут есть несколько проблем.
SME - это “эксперты в определенной области”, в определенных модулях системы. Люди начинают хорошо понимать, как работает та или иная часть проекта системы. Это происходит органически, произвольно, никто не делает это специально. Эти люди стремятся подольше остаться в этой позиции, они неохотно делятся своими знаниями, ибо так они становятся нужнее своей компании. И чем дольше они обмениваются знаниями вербально, чем дольше они находятся в позиции архитектора / главного разработчика / ответственного за отдельный модуль проекта, тем больше они стараются защитить себя от внешних “угроз” - передачи информации кому-то другому.
Такой подход еще и выгоден плохому менеджеру, потому что такими “экспертами” не надо особо управлять, ведь они сами становятся самоуправляемы. Менеджеры считают, что это очень хорошо: “у меня такая классная команда, они сами все делают”, “у меня Петя классный программист, на нем все держится”. Вот эта фраза “на нем все держится” говорит о том, что перед нами Петя эксперт, который закрепился глубоко в проекте.
Такие эксперты и документацию не пишут, ведь нет смысла подответственные им модули документировать - они и так знают, как они работают. Только силовые методы заставят экспертов писать документацию, и то эта документация вряд ли будет информативной.
Еще одна проблема, вытекающая из этой ситуации - неподдерживаемый код. Поддерживаемость кода можно измерить следующим способом: сможет ли баг в системе решить новичок в команде за 30-60 минут без помощи товарищей по команде. Если нет, то ваш код можно смело назвать неподдерживаемым. Особо запущенный случай - когда новичок говорит, что “все нужно переписать”.
В такой ситуации виноват не предыдущий программист, а менеджер, который это позволил. Программисты не виноваты, ведь все программисты такие, считает Егор.
Программисты пишут для себя, а не для кого-то другого.
“Я хочу писать так, чтобы было понятно только мне и я один смог бы разобраться в этом коде”, - так думают многие программисты. Такова природа человека. Поэтому вина за сложившуюся ситуацию перекладывается на менеджера, потому что он должен был не допустить такой ситуации. Таким образом,
плохой менеджер делает продукт, который работает только у отдельно взятых людей в его команде.