Хороший, плохой и сложный

- привет, сможешь сделать эту задачу до завтра ? - спрашивает Руководитель Проекта.

- ох, блин, там достаточно сложное изменение. До завтра не успею , там надо неделю разбираться. - озадаченно ответил Тимлид.

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

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

- у тебя сегодня уставший вид и твоя производительность за последнюю неделю изменилась. Давай обсудим это ? - спрашивает Тимлид.

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

Сложно, хорошо, плохо, оптимально, легко, быстро, медленно, важно, не важно, … Этот ряд продолжается до бесконечности. Речь о субъективных оценках.

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

Львиная доля конфликтов на ранней стадии формирования команды или добавления новенького в команду приходится на субъективные оценки (фаза шторминга из модели командной динамики Брюса Такмана). Одни и те же слова «хорошо», «плохо», «оптимально» и т.д. для людей, по-умолчанию, значат разное (Выготский «Мышление и Речь»).

Тимлиду стоит синхронизировать контексты участников команды. Синхронизация контекстов - это выравнивание понимания участников команды по субъективным оценкам, таким как успех, хорошо, плохо, успеваем или не успеваем , легко, сложно, быстро, просто и т.д.

Синхронизация контекстов - это рутинная работа, она происходит постоянно и регулярно и заканчивать её нельзя никогда. Эффект от синхронизации контекстов заметно виден, исходя из личного опыта, где-то через 4-6 месяцев.

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

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

«Этот код плохой», «это архитектура хорошая» , «у нас плохие процессы» и т.д. Ответом на это может быть : «нет, этот код хороший», «эта архитектура плохая» и «у нас хорошие процессы». Обмен субъективными оценками, если позволить, будет происходить неприлично длительное время.

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

Тогда, «хорошо» - это когда команда приближается к цели, а «плохо» - когда команда уходит от цели.

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

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

«Сложно» появляется в разных контекстах:

Для «сложно» можно определить свою меру, которая будет решать ваши задачи в команде, например:

При использование слова «сложно» попросите выразить его в чём-то измеримом. Действуйте проактивно и сформируйте, что такое «сложно», внутри команды сами.