Зарисовка 1
- привет, сможешь сделать эту задачу до завтра ? - спрашивает Руководитель Проекта.
- ох, блин, там достаточно сложное изменение. До завтра не успею , там надо неделю разбираться. - озадаченно ответил Тимлид.
Зарисовка 2
- в аргументах против разработанной мной архитектуры, ты, в качестве одного из минусов, написал, что это сложно будет сделать для команды. - сказал Архитектор
- да, и вообще она не такая уж хорошая для этой задачи , тут стоило бы применить более оптимальное решение - ответил Синьор разработчик
Зарисовка 3
- у тебя сегодня уставший вид и твоя производительность за последнюю неделю изменилась. Давай обсудим это ? - спрашивает Тимлид.
- всё очень плохо, мы ничего не успеваем и поэтому у меня стресс - отвечает младший программист.
Сложно, хорошо, плохо, оптимально, легко, быстро, медленно, важно, не важно, … Этот ряд продолжается до бесконечности. Речь о субъективных оценках.
Субъективные оценки используется в каждодневном общении. В сформировавшемся за годы коллективе, субъективные оценки быстро объясняют что и как. За каждой субъективной оценкой стоит опыт, который складывается из культуры, воспитания, обучения и прежних мест работы.
Синхронизация контекстов
Львиная доля конфликтов на ранней стадии формирования команды или добавления новенького в команду приходится на субъективные оценки (фаза шторминга из модели командной динамики Брюса Такмана). Одни и те же слова «хорошо», «плохо», «оптимально» и т.д. для людей, по-умолчанию, значат разное (Выготский «Мышление и Речь»).
Тимлиду стоит синхронизировать контексты участников команды. Синхронизация контекстов - это выравнивание понимания участников команды по субъективным оценкам, таким как успех, хорошо, плохо, успеваем или не успеваем , легко, сложно, быстро, просто и т.д.
Синхронизация контекстов - это рутинная работа, она происходит постоянно и регулярно и заканчивать её нельзя никогда. Эффект от синхронизации контекстов заметно виден, исходя из личного опыта, где-то через 4-6 месяцев.
Cинхронизации контекстов - это объективизация субъективных оценок. Для объективизации подойдут математический формулы, примеры артефактов, список действий, метрики кода, даты, ответственные лица, размер бюджета, человека-часы и т. д., главное что бы субъективная оценка становилась измеримой и понятной для участников команды.
Стоит также помнить, что субъективные оценки встречаются из разных контекстов. Например, «хорошо» в контексте ревью merge request и «хорошо» в контексте технической архитектуры отличаются друг от друга.
Хороший и Плохой
«Этот код плохой», «это архитектура хорошая» , «у нас плохие процессы» и т.д. Ответом на это может быть : «нет, этот код хороший», «эта архитектура плохая» и «у нас хорошие процессы». Обмен субъективными оценками, если позволить, будет происходить неприлично длительное время.
Тимлиду, что бы разрешить данную ситуацию стоит начать с проявления цели. Проявите цель для команды в виде артефактов, например: нагрузку в rps и среднем времени ответа, максимально допустим сложность реализованных алгоритмов (Big O), количество выполненных задач за спринт, доступный бюджет на разработку и т.д.
Тогда, «хорошо» - это когда команда приближается к цели, а «плохо» - когда команда уходит от цели.
«Плохо» когда мы увеличиваем техдолг и отклоняемся от целевой архитектуры , так что не попадаем в целевую дату завершения разработки. «Хорошо» - наши процессы позволяют нам реализовать фичи в обещанное время.
Сложный
Говоря про команду, «сложно» вылезает, например, во время оценки задач. Оценка бывает в майках, попугаях, но она связана со временем. Здесь «сложно» выражается во времени поиска «что надо сделать» и количестве элементов, которые будет задеты изменением.
«Сложно» появляется в разных контекстах:
- сложный код. Для каждого изменения надо 4 часа разбираться, где его сделать.
- сложная архитектура. Каждый раз надо ходить к архитектору, что бы понять в каких приложения надо сделать изменения. Или после каждого изменения надо все приложения деплоить на прод и запускать всю регрессионный тесты.
- сложные процессы. Каждый раз надо выяснять, кто за что отвечает.
Для «сложно» можно определить свою меру, которая будет решать ваши задачи в команде, например:
- вероятность возникновения бага на добавление фичи
- время работы нада задачей
- отношение количества связей между элементами к количеству элементов в системе
При использование слова «сложно» попросите выразить его в чём-то измеримом. Действуйте проактивно и сформируйте, что такое «сложно», внутри команды сами.