ИСКУССТВО СПАРИВАТЬСЯ С КОЛЛЕГАМИ

В конце 2022 года мы начали экспериментировать с парным программированием.

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

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

Пришлось пересмотреть подход.

Теперь мы используем парную работу только для сложных задач. Если нужно разобраться в чём-то нестандартном или глубоком, подключаются два человека. Парное программирование стало инструментом для особых случаев.

А потом пришла мысль: а что, если парное программирование — это только часть чего-то большего? Универсальный метод, который подходит для любых сложных задач: инженерных, бизнес или творческих. Для многих это, может быть, давно очевидно. Для меня — открытие. Если убрать специфический контекст, останется простая, но мощная идея…

Парная работа

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

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

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

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

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

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

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

Инструкция по спариванию

1. Начни с себя, начни с малого

Не пытайтесь сразу внедрить парную работу во всей команде. Это создаст излишнее сопротивление и усложнит процесс.

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

Так всё и закрутилось: задача была решена быстрее и с меньшими правками. Дзимке понравилось, и он с удовольствием согласился попробовать этот подход с другими ребятами.

2. Установи правила

Чтобы практика устаканилась, ей нужны регламенты, ориентиры и лучшие практики. Я решил, что нам нужен некий "Обязательный процесс разработки". Его идея была простой: дать новичкам чёткие шаги, чтобы они быстрее влились в работу. Конечно, он был "навязан" мной, а не выработан коллективно.

На бумаге процесс выглядел безупречно: всё продумано, всё учтено. Вот как он выглядел:

Обязательный процесс разработки

Взять задачу.
Найти пару.
Позвонить заказчику и описать разговор в тикете.
1. Выяснить, в чём проблема и зачем её решать. И можно ли её не решать с помощью IT.
2. Выяснить цель: чего мы хотим достигнуть, почему достижение этой цели сделает кого-то счастливым и спокойным.
3. Выяснить, как заказчик поймёт, что мы его не обманули, сказав, что уже всё сделали: как тот будет проверять, что всё получилось.
4. Узнать список экспертов и заинтересованных лиц, которые дали бы больше информации. Больше всего нас интересуют люди, которые могут сказать, что наше решение может что-то сломать или нарушить закон.
5. Либо сразу, либо предварительно посовещавшись, предложить решение. Решение должно быть самым убогим, еле работающим, но с помощью которого решается задача и при этом не нарушается закон. То есть все свистелки и перделки мы отказываемся делать в первой итерации задачи. Надо максимально до*бывать заказчика вопросом «А на*уя?».
Позвонить экспертам и заинтересованным лицам. Экспертами по общим вопросам будут: CEO, COO, тимлид, директор по рискам.
Если в ходе обсуждения кому-то было непонятно или неизвестно хоть что-то о нашем продукте, коде, бизнесе — тот пишет заметку в документацию. Чем короче, тем лучше.
Написать тексты тест-кейсов прямо в комменты в жиру. Буквально:

Я как админ с такими-то правами захожу в админку в раздел такой-то.

Нажимаю (пока ещё не существующую) кнопку, на которой написано «Скачать отчёт».

Обновляется страница и появляется надпись «Отчёт успешно запланирован».

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

Автоматизировать сценарии через приёмочные тесты. То есть вы пишете тест на несуществующую функциональность.
Обсудить с парой архитектуру: какие вы создадите и заиспользуете компоненты, какой интерфейс у них будет. Придумать названия классов и методов. Нарисовать схему в миро — криво, косо, хоть как-нибудь сбоку.
Обсудить, как реализованная функциональность будет отключаться. То есть продумать фича-флаги, чтобы можно было подливать в прод незаконченный код и не париться, что он начнёт работать и всё сломает. Отписаться о стратегии запуска в тикете.
Писать код можно вместе, а можно по отдельности — как хотите. Распределить работу проще всего по модульно и по классово.
Писать очень короткими коммитами. Пушить сразу в мастер.
Юнит-тесты можно писать, можно не писать. Если у вас есть нормальный приёмочный тест, этого будет достаточно.
Как только что-то хоть сколько-нибудь готово на проде — криво, косо, с постоянным присутствием разработчиков, чтобы что-то подтюнивать — звоним напрямую заказчику и показываем. Нужно как можно быстрее понять, не х*рню ли мы делаем. Помпезных демо не надо, просто тихо и по-быстрому получаем обратную связь.
Когда решение стало похоже на конечное, порефакторить код. Акцент сделать не на красоту содержимого методов, а на модульность и возможность описать текстом, что делает каждый из элементов. Тут важно, чтобы мы потом, по верхам взглянув на структуру компонентов и их интерфейсы, могли вспомнить, что там происходит.

Конечно, процесс не стал "обязательным". Правила, спущенные "сверху", редко приживаются.

Я не настаивал на их соблюдении. Все знали, что они существуют. Я знал, что их не соблюдают. Все знали, что я знаю. И меня это устраивало. Даже немного радовало: команда умела игнорировать идиотские навязанные правила.

3. Возненавидь и отряхни от чепухи

Любая практика — это костыль. Мы решаем одну проблему, но порождаем кучу побочных эффектов, которые иногда оказываются хуже, чем сама проблема.

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

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

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

Заключение

Парная работа — это не только для программистов. Это способ решать задачи вместе, когда один человек может не заметить что-то важное, а другой это увидит.

Она полезна там, где нужно искать нестандартные решения или разбираться с чем-то сложным. Инженерные проекты, креативные задачи, даже обсуждение стратегии — парная работа помогает.

Попробуйте её в своём деле. Возможно, она станет удобным инструментом, который упростит сложное и сделает работу интереснее.