Subject Matter Expert. Чёрная Метка Для Разработчика

Это не совсем привычная для меня статья, но я давно хотел поделиться одним своим наблюдением. В ней не будет никаких вещей, связанных непосредственно с разработкой на Java или Kotlin, не будет кода. Я просто решил поделиться опытом. Я надеюсь, читать эту статью Вы будете вечером, в спокойный, выходной день.

Ну что же, поехали.

Меня зовут Михаил Поливаха, и я предполагаю, что Spring АйО читают в основном Java или Kotlin разработчики. В том или ином виде, Java / Kotlin разработчики часто пишут какие-то Enterprise решения. Одной из отличительных особенностей Enterprise является сложная доменная область. Если Вы хотя бы какое-то время писали Enterprise бекенд, то я думаю, для Вас это не новость.

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

• Структуру торгов на бирже

• Типы рынков и их взаимодействие

• Как происходит взаимодействие брокера с биржей

И так далее. Ещё раз, это абсолютно естественно. В той или иной степени это знание приобретается. И это, казалось бы, хорошо и помогает решать проблемы. Но не совсем. У этого есть крайне тёмная сторона. Даже больше — это знание может оказаться фатальным как для программиста, так и для проекта.

Разработка, или Туда и Обратно. Начало

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

Вроде бы всё нормально. Релизы есть. Да не без багов, но всё же. Фичи как-то плюс-минус делаются. Да, пускай сроки иногда срываются, но тем не менее. Прогресс идёт. Самый типичный проект.

И наш Ваня самый обычный программист. В том плане, что он воспринимает работу как некий производственный процесс, как ремесло. Он не сильно интересуется новинками в мире Spring Framework, ему не сильно интересно, как там работает Postgres или JVM. За рамки Java он обычно не выходит. Его компетенций хватает, чтобы писать софт, который ± работает и может удовлетворить требования бизнеса (как им кажется).

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

Наблюдение Первое

Первое, очень важное наблюдение, которое мы можем сделать: Ваня с подобным обыденным отношением к работе (ещё раз, вполне типичным и часто встречаемым) будет принимать решения далеко не самые эффективные. На то есть 2 причины:

1. У него не хватает знаний. Он не знает альтернатив. Он не знает, что Spring Framework уже давно так умеет. Или что вызывать сторонний сервис под открытой транзакцией к БД — это плохо. Он не знает, что его система в проде теряет сообщения и т.д.

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

Это важное наблюдение. Оно нам потом понадобится.

Нежданные Гости. Время Перемен

Проходит время. И с течением времени неизбежно происходит некая текучка кадров. Кто-то уходит, кто-то приходит. И за пару лет из 3 разработчиков (2 + Ваня) бекенда, кто изначально писал проект, остался лишь Ваня. Остальные либо ушли на другие проекты, либо вовсе покинули компанию.

Менеджер проекта, Антон, конечно понимает, что раньше было 3 программиста, сейчас 1. Работа будет выполняться медленнее. Нужда в программистах осталась, поэтому на проект идёт найм двух разработчиков на бекенд. Их находят и нанимают.

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

Наблюдение Второе

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

И теперь начинается самое интересное.

Баранье Жаркое. Раскручиваем Маховик.

Наш менеджер, Антон, конечно всё понимает. Он понимает, что новым разработчикам нужно время, чтобы “въехать” в проект. Ну, очевидно же. Более того, мы даже знаем золотое правило из The Mythical Man Month:

Adding manpower to a late software project makes it later

Пока программисты “въезжают”, толку от них не так много. Но задачи-то надо делать. Сверху же уже топчат ногами — сроки можем сорвать! Антон понимает, что единственный шанс успеть в сроки — это давать срочные задачи Ване.

Но мы-то с Вами понимаем, что срочные задачи есть всегда, и их много. Всегда что-то ломается на продакшене, какие-то срочные изменения запрашивает Информационная Безопасность и т.д. Отдавать какие-то срочные баги новопришедшим программистам — это же самоубийство! Пока они разберутся в том, что происходит, пока поймут контекст проблемы, пока…

И Ваня, будучи по сути единственным человеком, который знает, как работает система, становится самым настоящим “заложником” ситуации. Происходит примерно следующее:

• Любая срочная задача: Ваня!

• Любой вопрос по функционалу: Ваня!

• Как реализовывать эту фичу так, чтобы ничего не сломать? Ваня!

Результат: Наш герой постоянно занят. Его отвлекать сильно нельзя, ведь только он может решить проблему, и решить её в срок. Ваня становится довольно сильно перегружен — он нужен буквально везде.

Наблюдение Третье

Ситуация выше очень быстро превращается в порочный круг, так как:

1. У Вани мало времени на то, чтобы писать стабильные и расширяемые и производительные решения (кроме того, добавьте к этому тот факт, что Ваня ещё и не сильно хотел бы этим заниматься — он обычный ремесленник).

2. Как следствие, в коде повышается количество костылей, каких-то решений, которые понятны только Ване. Почему? Да потому, что времени у него нет, а проблемы надо решать быстро. Иногда бывает даже так, что никаких тестов, даже формальных, на эти “костыли” нет.

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

4. И тем самым, спектр задач, которые может решить только Ваня, становится не меньше, а больше! Другие 2 программиста в душе не чаят, как это всё работает. У Вани, из-за повышения спектра задач, которые он может решить, времени на документацию и какие-либо пояснения становится ещё меньше.

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

Из Огня Да в Полымя. Каков Конец Истории?

Я думаю, что кто-то распознал свой проект. Если так — напишите об этом, пожалуйста, в комментарии. Будет интересно почитать.

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

Концовка №1. Ваня Уходит.

По тем или иным причинам, Ваня принимает решение уйти с проекта. Это может быть любая причина:

• Проект его в край задолбал (что несложно представить).

• Ему предложили оффер получше.

• По каким-либо личным обстоятельствам и т.д.

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

И тут возникает проблема.

Ваня, уходя из проекта, как правило, уходит с большим облегчением. Он и так-то не сильно бы хотел перерабатывать и тратить огромное время на разработку продукта, а тут его вынужденно суют как в каждой бочке затычку. И Ваня уже в гробу бы видал этот проект. У него нет энтузиазма рассказывать все ins-and-outs системы. Максимум, что он делает — отвечает на вопросы коллег программистов на встрече.

Но вот беда — наши 2 новоиспечённых программиста на встрече даже не знают, какие вопросы надо задавать. Большая часть проблем, 90% из них, вскроется уже после, уже в бою. После ухода Вани. И подобная “Передача Знаний” на деле почти без исключений обречена на провал. Эта процедура фиктивная, чтобы потом Антон, после ухода Вани, как только начнут срываться сроки и т.д., мог прийти и сказать:

Вам же Ваня всё пояснил! Вы что, не слушали его на встрече?!

И дальше всё зависит от прочности “системы”. Если система прочная, то она переживет уход Вани. Да, команда будет разгребать авгиевы конюшни полгода, а то и год, но проект будет жить. Если же система не такая прочная, или степень зависимости от Вани была близка к 100%, то поддерживать её, конечно, становится почти нереально без него. И менеджмент выше принимает решение:

Переходим на “Целевую Систему”

Переходили когда-нибудь с одной системы на другую, “Целевую”? Если да, то знайте, что, конечно, не всегда, но одна из причин такого перехода — где-то просто внезапно ушёл Ваня. Я думаю, что статью можно было прямо так и назвать — посвящается всем командам, откуда однажды, случайно, совершенно внезапно, ушёл Ваня.

Концовка №2. Весь проект находится “в заложниках”. У Ивана.

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

Каждый раз, когда Ваня уходит в отпуск недельки так на 2, Антон заказывает валидол и бронирует приёмы у психотерапевта, ведь он понимает, что его ждёт. Ситуация страшная: без Вани все боятся принимать какие-либо сложные решения — а вдруг сломаем? Вдруг мы чего-то не знаем? Проект по сути находится в таком “maintenance mode”.

Осознавая степень зависимости, к Ване начинает меняться отношение. Со стороны это выглядит так:

1. Ивану разрешают работать почти откуда угодно.

2. Со временем какой-то ярко выраженный график работы у Вани начинает отсутствовать — это не Ваня работает на проекте, а весь проект подстраивается под Ваню.

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

И далее уже то, насколько далеко будет гнуться эта линия, зависит от ряда обстоятельств, но вектор понятен. Весь проект будет находиться в заложниках либо до ухода Вани (см. Концовка №1), либо до тех пор, пока не придёт “Герой” или команда, которая сможет, со временем, сместить “диктатуру” Ивана.

Post Mortem. Как Этого Можно Было Избежать?

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

Кто же виноват в этом всём?

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

Проблема в том, что условный Антон позволил Ване не как программисту, а “Ване” как феномену случиться. Менеджмент вовремя не распознал, что у них образуется Subject Matter Expert.

В Бочках — на Волю. Как Решать Эту Проблему

Проблему эту должен решать менеджмент и только он. Хотя “менеджмент” — это крайне ответственные позиции, к огромному сожалению, по моим наблюдениям, в современном IT менеджеры проектов — это часто те, кому просто хотелось в IT (деньги, в первую очередь), а технических навыков для написания кода особо не было. Вот они и пошли в управление.

Это безумно, но я думаю, многие со мной согласятся.

Так вот именно менеджменту важно, помимо прочего:

1. Стремиться делать так, чтобы люди были взаимозаменяемыми. Не должно быть такого, что потеря одного элемента в системе становится смертоносным явлением.

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

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

Здесь, конечно, есть вопрос: Так почему же люди этого не делают? Ответов тут много, они тянут уже на другую статью. Я же поступлю, как сделал в своё время Пьер Ферма — оставлю этот вопрос “на полях” статьи, и ответ на него останется Вашим небольшим факультативом.

Всем Удачи!