Условия работы с рутиком

Где посмотреть, чем занимаюсь

• Telegram — t.me/ROOTWIN_PROJECT — новостной канал головного проекта ROOTWIN PROJECT, апдейты и релизы
  Сайт - https://rootwin.vercel.app/software
• Reddit — reddit.com/user/rwm0 — активность и посты по разработке в тематических сообществах
• X — x.com/rootwin_project — короткие апдейты и активность по проекту

❗ВНИМАНИЕ ❗
Я никогда не изучал доктрину СКАМА и не брал фокус на СКАМ и нигде не засветился в СКАМ-историях. Работаю в открытую — на репутацию ROOTWIN PROJECT, а не на разовый профит с одной сделки. Долгосрочное доверие сообщества стоит дороже, чем любой краткосрочный выигрыш от нечестной работы.

Здесь — как я работаю с заказчиками. Прочитайте перед стартом проекта, это экономит время нам обоим.

1.1. Работа начинается только после письменного согласования технического задания и получения предоплаты (п.2).

1.2. ТЗ обязательно содержит:

• перечень задач (что входит);
• перечень того, что не входит (п.1.9);
• формат результата;
• критерии приёмки;
• срок на разработку (число дней);
• срок на приёмку (число дней);
• количество бесплатных правок (п.4);
• стоимость и график оплаты;
• список материалов, исходников и доступов, которые заказчик должен передать (п.3.7);
• одного уполномоченного представителя заказчика (п.1.8).

1.3. Если какого-то пункта из списка в ТЗ нет, ТЗ считается неполным. Недостающие значения берутся по умолчанию из этих условий (срок на приёмку — 3 рабочих дня, бесплатных правок — 2 раунда), и заказчик подтверждает их вместе с ТЗ. Без стоимости, объёма и списка исходников ТЗ не согласовывается.

1.4. Если вы не можете составить ТЗ сами, составлю я. Вам нужно прочитать его и подтвердить письменно: «да, всё верно, приступайте».

1.5. Всё, что не зафиксировано в ТЗ, в объём работы не входит.

1.6. Стоимость относится к согласованному ТЗ, а не к разговору до него. Сумма, названная в переписке («за X всё сделаешь?», «45$ в целом за всё»), действует только на то, что записано в ТЗ. Всё, что клиент просил в разговоре, но что не вошло в ТЗ, в эту цену не входит.

1.7. ТЗ считается согласованным только когда уполномоченный представитель заказчика написал «да, всё верно, приступайте» (или эквивалент) под финальной версией ТЗ, одним сообщением, без «но», «ещё» и «пока подумаю». Если после ТЗ заказчик продолжает дописывать или менять условия, ТЗ не согласовано, срок не идёт, и я имею право выдать новую версию ТЗ с пересчитанными ценой и сроком.

1.8. Один уполномоченный представитель. В ТЗ указывается один человек со стороны заказчика, который согласует ТЗ, принимает этапы и подтверждает правки. Сообщения остальных участников (партнёров, знакомых, разработчиков) согласованием не считаются, пока их не продублировал уполномоченный.

1.9. Что не входит — перечисляется в ТЗ явно, например:

• развёртывание на сервере, настройка домена, выдача и настройка ключей;
• добавление новых игр, режимов и механик;
• дизайн с нуля, переработка макетов, анимации, 3D;
• интеграции с недокументированными API и реверс-инжиниринг;
• поддержка после сдачи.

Всё, чего нет в списке включённого, в объём не входит. Всё, что заказчик просит устно («ещё вот это»), — допсоглашение (п.4.3).

2. Предоплата

2.1. Предоплата обязательна: от 30 до 100% в зависимости от объёма и срока.

2.2. Короткие задачи (1–3 дня) — 100% вперёд.

2.3. Проекты с этапами оплачиваются по этапам:

• не сдан этап — следующий не начинается;
• не оплачен этап — работа приостанавливается, это не срыв сроков с моей стороны.

2.4. Без предоплаты я не беру обязательств по срокам и не начинаю работу.

2.5. Изменение цены после согласования ТЗ возможно только через допсоглашение (п.4.3), в письменной форме.

3. Сроки и задержки

3.1. Срок проекта состоит из двух отдельных частей:

• срок на разработку — время, за которое я делаю и сдаю этап;
• срок на приёмку — время, за которое вы проверяете сданный этап и присылаете замечания.

3.2. Эти два срока не складываются в один и не вычитаются друг из друга. Срок на приёмку всегда идёт после сдачи и сверху срока на разработку.

3.3. Если в ТЗ указан один общий срок без разбивки, он всегда считается сроком на разработку. Срок на приёмку (3 рабочих дня по умолчанию) добавляется к нему сверху.

Пример: в ТЗ «7 дней». Это 7 дней на разработку. После сдачи ещё 3 рабочих дня на приёмку. Общее окно — 7 + 3.

3.4. Срок на приёмку всегда отсчитывается от даты фактической сдачи этапа, а не от окончания срока на разработку.

3.5. Досрочная сдача не даёт заказчику дополнительного времени. Срок на приёмку равен ровно тому, что указано в ТЗ (или 3 рабочим дням), и отсчитывается от дня сдачи. Оставшееся время разработки заказчику не переходит.

Пример: срок на разработку 7 дней, сдал на 4-й день. Приёмка — 3 рабочих дня с 4-го. Остаток разработки (3 дня) на приёмку не добавляется.

3.6. Дата сдачи — дата и время моего сообщения, в котором я отправил результат или доступ к нему в переписку по проекту. Это точка отсчёта срока на приёмку. В сообщении о сдаче я указываю конкретную дату окончания приёмки.

3.7. Срок на разработку начинается только когда выполнены все три условия:

• ТЗ согласовано (п.1.7);
• предоплата получена (п.2);
• переданы все исходники, доступы и материалы из списка в ТЗ (п.1.2).

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

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

3.9. Если вы не выходите на связь 5–7 рабочих дней без объяснений, проект переходит в статус «заморожен». Возобновление — по новому согласованию сроков, возможен пересчёт стоимости.

4. Правки

4.1. Количество бесплатных правок фиксируется в ТЗ. Если не указано — 2 раунда. Раунд — это один список замечаний, отправленный одним сообщением. Дописывание замечаний по одному считается одним раундом до тех пор, пока я не ответил, и следующим раундом после моего ответа.

4.2. Бесплатны правки, которые одновременно:

• относятся к тому, что описано в исходном ТЗ;
• поданы в срок на приёмку (п.3);
• касаются того, что не работает или не соответствует ТЗ.

4.3. Допсоглашение. Любая просьба, которой нет в ТЗ, — новая функция, игра, режим, экран, изменение уже согласованного, «а можно ещё», «добавь», «замени», «переделай» — считается запросом на допсоглашение:

• я даю отдельную оценку по цене и сроку;
• работа начинается только после вашего письменного подтверждения;
• срок допсоглашения — отдельный, и может сдвинуть общий срок проекта.

4.4. Моё «ок», «посмотрю», «могу», «думаю да», «адаптирую» на просьбу вне ТЗ не считается согласием выполнить её бесплатно и не включает её в объём. Согласием является только моё сообщение с ценой и сроком плюс ваше письменное «да».

4.5. Любое замечание, поданное после окончания срока на приёмку, считается новой задачей и идёт по п.4.3.

4.6. Изменение ранее согласованных решений задним числом («уберите X» во время разработки, а после сдачи претензия, что X нет) не является багом и бесплатно не исправляется.

4.7. Если заказчик меняет объём во время разработки (добавляет, убирает, заменяет), срок и цена пересчитываются. Работа над изменённой частью начинается после письменного согласования.

5. Ответственность за третьих лиц

5.1. Я не отвечаю за задержки по вине третьих лиц с вашей стороны: других подрядчиков, переводчиков, дизайнеров, внутренних согласований, сторонних сервисов и API, если они не под моим управлением.

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

5.3. Интеграции со сторонними системами (плагины, API, чужой код, чужие ассеты) тестируются в рамках ТЗ.

5.4. Баги, унаследованные от сторонних компонентов, не на мне. Могу локализовать и описать их за отдельную оплату, если это не входило в исходную оценку.

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

5.6. Развёртывание и инфраструктура. Сервер, домен, ключи и доступы предоставляет заказчик. Настройка и развёртывание не входят в стоимость, если это прямо не записано в ТЗ.

6. Фиксация договорённостей

6.1. Этап считается принятым в момент, который наступит первым из двух:

• а) уполномоченный представитель письменно подтвердил: «работа принята, претензий нет»;
• б) срок на приёмку истёк, а замечаний по существу не поступило.

6.2. Письменное подтверждение не обязательно. Его отсутствие не делает этап «открытым» и не отменяет п.6.1(б). Молчание после истечения срока — это приёмка.

6.3. «Замечание по существу» — конкретное описание того, что не работает или не соответствует ТЗ. Сообщения вида «посмотрим», «пока не проверили», «позже отпишем» замечанием не являются и срок приёмки не продлевают.

6.4. Срок на приёмку можно продлить только письменным согласием обеих сторон до его окончания. Иначе он не продлевается.

6.5. Все ключевые решения (принятие ТЗ, согласование правок, допсоглашения, продление сроков) фиксируются письменно в переписке или отдельным документом.

6.6. Устные договорённости (созвон, голосовые) не считаются согласованием, пока не продублированы текстом.

6.7. Любое сообщение после наступления приёмки (п.6.1) — заявка на новую задачу по п.4.3, а не замечание по этапу.

7. Тестирование и приёмка

7.1. Я провожу базовое самотестирование: проверяю, что заявленный в ТЗ функционал работает как задумано.

7.2. Полноценное приёмочное тестирование — на вашей стороне: реальные данные и сценарии, бизнес-логика, edge-кейсы под ваши задачи. Проводить его нужно в срок на приёмку (п.3).

7.3. Как и когда этап считается принятым, определяется только п.6. Этот пункт правил приёмки не содержит и не меняет.

7.4. Баги, не найденные в срок на приёмку из-за того, что тестирование не проводилось или проводилось не полностью, — не «баг со старта». Разбираются как новая задача по п.4.3.

8. Права на результат

8.1. Права на результат (код, материалы) передаются только после полной оплаты.

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

9. Отказ от проекта

9.1. Вы можете отказаться от проекта в любой момент. Предоплата за уже выполненный объём не возвращается.

9.2. Я могу отказаться от проекта при систематическом нарушении условий по оплате и срокам (просрочка оплаты, долгое молчание) или если заказчик после согласования ТЗ систематически меняет объём без допсоглашения. В этом случае возвращаю неотработанную часть предоплаты за вычетом фактически выполненного объёма.