Почему такие споры затягиваются
Потому что часто правильного ответа нет. Оба варианта рабочие, у каждого свои плюсы, и спор превращается в обмен предпочтениями, замаскированными под аргументы.
Второе: технические споры приятны. Обсуждать выбор библиотеки интереснее, чем писать код. Команда может неделю выбирать инструмент для проекта на три недели.
Первый вопрос: насколько это важно
Разделите решения на два вида.
Обратимые. Переделать потом — от часа до дня. Название переменной, библиотека для работы с датами, оформление интерфейса.
Правило: не спорьте о них дольше пятнадцати минут. Возьмите любой вариант и идите дальше. Обсуждение дороже переделки.
Труднообратимые. Переделать — недели. Выбор хранилища, структура данных, способ разграничения прав, основная технология.
Здесь стоит потратить время: полчаса-час на разбор, а иногда полдня на пробу.
Ошибка новичков — путать одно с другим. Час спора о названии и пять минут о структуре базы.
Как вести обсуждение по существу
Начните с задачи, а не с решения. Не «давайте возьмём вот это», а «нам нужен быстрый поиск по тексту и понятная работа со связями». Половина споров растворяется на этом шаге: выясняется, что стороны решают разные задачи.
Назовите ограничения. Сколько времени, кто умеет, что уже используется. Прекрасная технология, которую в команде никто не знает, — плохой выбор для проекта на месяц.
По каждому варианту скажите цену. Не только плюсы. «Это быстрее, но придётся разбираться неделю» — честный аргумент.
Проверьте на кошках. Когда спор упирается, часто быстрее потратить два часа на пробный кусок, чем два дня на обсуждение.
Аргументы, которые ничего не значат
«Так все делают». Кто именно и в каких условиях? У крупных компаний другие задачи.
«Это современнее». Возраст технологии не аргумент ни в какую сторону.
«Мне не нравится». Может быть правдой, но должно превратиться в довод: что конкретно неудобно.
«А вдруг вырастем». Самая дорогая ловушка. Строить под миллион пользователей то, чем воспользуются сто человек, — верный способ не доделать вовсе.
Записывайте
После решения — короткая запись: что решили, какая была задача, что рассматривали, почему выбрали это, чем платим.
Десять строк. Даёт три вещи:
- Не спорите дважды. Через месяц кто-нибудь обязательно спросит «а почему не то?».
- Новый участник понимает контекст. Иначе он видит странное решение и не знает причины.
- Видно, когда решение устарело. Условия изменились — причины больше не действуют, можно менять осознанно.
Кто решает, если не сошлись
Договоритесь заранее. Рабочие варианты: решает тот, кто отвечает за эту часть; решает тот, кому это потом чинить; берём то, что знает большинство.
Любое правило лучше, чем его отсутствие. Без правила спор идёт до тех пор, пока кто-нибудь не устанет, — и это худший способ принимать решения.
Хватит читать — пора делать
На CohortX можно найти команду под пет-проект и получить тот самый опыт, о котором спрашивают на собеседовании.
Похожие статьи
- Agreeing on technical decisionsWhy technology arguments drag on, how to tell an important decision from an unimportant one, and what to record so you don't argue twice.
- Handing a project over to someone elseWhat to prepare, what to say out loud, what the code won't tell them, and how to know the handover actually happened.
- Как передать проект другому человекуЧто подготовить, о чём рассказать голосом, чего не расскажет код и как понять, что передача состоялась.