Выйти из роли и подышать

Прохожу курс "Системное саморазвитие". В процессе чтения главы 5 "Роль" запомнилось, что необходимо обсуждать действия человека-в-роли, а не конкретного человека. Думаю, что в рабочих проектах на других участников смотрю с этой позиции. Не "Ты, Шарик, балбес, не мог нормально все требования в задаче сразу описать, чтобы я три раза не переделывала!", а "Т.к. qa-инженер требования перед реализацией задачи не пишет, а описание задачи пишет тимлид, стоило мне, как разработчику включиться и поработать инженером по требованиям - уточнить у тимлида, что же он на самом деле хотел по функционалу".

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

Проблемы бы не было, если бы: 1) я глазами внимательно проверила все этапы сборки проекта в CI 2) если кто-то из коллег, тоже самое сделал на этапе ревью задачи 3) QA на этапе формирования требований уточнил бы может ли сломаться что-то ещё. Но полной картины в голове ни у кого нет, и у всех ролей случился "недосмотр".

Люди плохие? Да нет, хорошие. Я обычно на себя начинаю гнать, на себя-инженера. Исходя из правила: если ты не исправишь, никто не исправит. Если отделить себя от инженера, то получается были произведены не до конца верные действия по роли. Плюс уровень внимания не достаточный при нахождении в роли. Хотя возможно это не внимание. А то, что надо было остановиться и подумать. При помощи мышления в режиме S2, а что же ещё задевают внесенные изменения, что же может сломаться. Может не придумав ничего, можно было дополнительно спросить ещё людей.

Спустя ещё день, прожила фрустрацию. Решила, что люди это конечно прекрасно, но автоматизация решает. Ищу линтер, который сможет за меня (и всех остальных) проверять качество сборки проекта в CI. Проверять на этапе работы над задачей. Fail fast, fail often.


Выводы

  • находясь в роли, не получается адекватно оценивать качество действий по роли. Надо хоть как-то отстраниться от роли, чтобы посмотреть объективно.
  • надо тренировать навык переключения между ролями. Застревание в роли ставит всё на одну карту. Тяжело переносить проигрыш в работе, если ты себя с ней сильно ассоциируешь.
  • ошибаться это нормально, кайф научиться ошибаться раньше.
2 лайка

Наталья, спасибо за пост.

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

Думаю такой опыт дал положительное подкрепление для обучения, и дальше “развидеть” ролевое рассмотрение уже не получится.

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

1 лайк