Способы прерывания контакта в разработке

Когда не получается решить проблему, мы обычно стараемся еще сильнее. Но вместо этого полезно посмотреть в обратную сторону: попробовать разобраться, что и как именно у нас не получается. В какой момент мы застреваем? Что делаем вместо необходимых действий? Чего не замечаем или избегаем?

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

1. Слияние

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

Команда настолько привыкла к условиям работы, что перестала отделять свои потребности от требований привычной среды.

2. Интроекция

В проекте всегда действовало негласное правило: “не плодить сущности и абстракции”. Несколько лет назад его установил руководитель с большим опытом быстрого прототипирования.

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

Команда продолжает руководствоваться усвоенным правилом, не проверяя его применимость к нынешней ситуации.

3. Проекция

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

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

Человек приписывает окружающим собственные опасения и ограничения, принимая их за объективные свойства среды.

4. Дефлексия

Разработчик несколько недель проектирует новую подсистему. Основной функционал уже готов, пора интегрировать решение и проверить, как работает все вместе, но он продолжает полировать детали реализации. Вроде каждое изменение имеет смысл, но все это только откладывает момент встречи с главной неопределенностью: насколько удачным оказалось решение в целом.

Человек сохраняет активность, но направляет ее в сторону от наиболее значимого и напряженного контакта.

5. Ретрофлексия

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

Энергия, предназначенная для взаимодействия со средой, разворачивается на себя.

6. Обесценивание

Команда потратила несколько месяцев на рефакторинг большого модуля. Полностью завершить работу не удалось: выяснилось, что потребуется намного больше ресурсов, чем предполагалось.

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

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