Андрей и Тимур: как двум друзьям вести общий проект без ссор

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

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

Эта история типовая для любых дружеских проектов: сайта, бота, маленького SaaS, игры, канала или локального сервиса для своей компании. Друзья часто пропускают скучные договорённости, потому что не хотят выглядеть формалистами. На практике именно короткие правила берегут отношения лучше, чем фраза «мы же свои, разберёмся».

Сначала договориться о цели

Первый вопрос для Андрея и Тимура был не про стек и не про дизайн. Им пришлось честно описать, что они вообще делают. Для Андрея проект был шансом собрать портфолио и проверить продуктовую идею. Для Тимура это был технический полигон: попробовать очередь задач, нормальный мониторинг и аккуратный деплой.

Обе цели нормальные, но они ведут к разным решениям. Если цель — проверить спрос, не надо месяц строить идеальную архитектуру. Если цель — прокачать инженерную часть, странно злиться, что второй человек тратит время на инфраструктуру. Конфликт появляется не потому, что кто-то неправ, а потому что критерий успеха разный.

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

Разделить зоны ответственности

Дружеский проект часто страдает от размытого «мы сделаем». В календаре это обычно значит «никто не сделал». Андрей и Тимур оставили общую ответственность за результат, но разделили конкретные зоны.

• Андрей отвечает за интерфейс, тексты на главной странице и сценарий первого пользователя.
• Тимур отвечает за API, базу данных, деплой и резервные копии.
• Решения по продукту принимаются вместе раз в неделю, а не в случайных сообщениях ночью.
• Если задача пересекает две зоны, у неё всё равно есть один владелец.

Последний пункт оказался самым полезным. У задачи может быть два участника, но не должно быть двух людей, которые «в целом присматривают». Владелец не обязан делать всё руками. Он обязан довести задачу до понятного состояния: сделано, отменено, заблокировано или перенесено.

Письменные правила вместо памяти

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

project: prototype
goal: показать прототип 20 пользователям за 6 недель
weekly_sync: воскресенье, 19:00
decision_rule: если спор дольше 15 минут, выбираем более простой вариант
owners:
  frontend: Андрей
  backend: Тимур
money:
  costs: пополам до отдельной договорённости
  revenue: не обсуждаем до первых платящих пользователей
stop_rule: если 2 недели нет прогресса, пересматриваем проект

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

Деньги обсуждать до денег

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

Андрей и Тимур выбрали простой режим: до первых пользователей расходы пополам, каждая трата выше заранее выбранной суммы согласуется в чате. Доходы не делятся и не обещаются, пока нет реального продукта и юридической формы. Если проект начнёт зарабатывать, они отдельно обсуждают доли, роли и ответственность.

Это звучит сухо, но сухость здесь полезна. Дружба плохо переносит ситуацию, где один человек платит за сервер, второй забывает перевести свою часть, а оба делают вид, что ничего не произошло.

Ритм важнее вдохновения

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

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

Конфликты лучше ловить рано

У Андрея и Тимура был полезный сигнал: если кто-то третий день подряд отвечает односложно, значит, пора не давить задачами, а спросить, что происходит. Часто проблема не в лени. Человек мог устать, потерять интерес, испугаться объёма или не согласиться с направлением, но не найти момент сказать прямо.

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

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

Что у них сработало

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

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

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