1. Закон «Первого демо»
Никогда не показывай заказчику готовый функционал спустя месяц разработки. Показывай «скелет» через неделю. Риск: Заказчик может только на живом примере понять, что он имел в виду в ТЗ совсем другое. Лучше переделать 5% работы сейчас, чем 80% в конце.
2. Принцип «Отраженного понимания»
После каждой встречи пиши короткое follow-up письмо: «Мы обсудили это, я понял задачу так-то, фиксируем это как план». Если заказчик не возразил в почте — у тебя есть юридический и моральный щит на случай «я этого не говорил».
3. Эмпирический закон 90/10
Первые 90% проекта занимают 90% времени. Остальные 10% (доводка, баги, «покрасить кнопку») занимают еще 90% времени. Совет: Закладывай на стабилизацию и передачу проекта минимум 30% общего бюджета времени, даже если кажется, что «там всё просто».
4. Управляй не задачами, а ожиданиями
Провал проекта — это не когда код плохой, а когда разрыв между тем, что заказчик представлял, и тем, что он получил, слишком велик. Постоянно «калибруй» его ожидания. Если видишь, что фича будет выглядеть иначе, чем в его мечтах — скажи об этом сразу.
5. Борись с «Scope Creep» (Раздувание рамок)
Заказчик часто просит «маленькую правочку», которая не в ТЗ. Помни: каждая «бесплатная» правка — это шаг к срыву сроков основного ТЗ. Используй фразу: «Отличная идея, давайте внесем её во вторую фазу или оформим доп-соглашением, чтобы не сдвигать текущий релиз».
6. Ищи «Скрытого ЛПР»
Часто ТЗ обсуждает один человек, а принимать работу будет его начальник, который документ и в глаза не видел. Найди этого «серого кардинала» как можно раньше и узнай его истинные критерии успеха.
7. Правило «Плохих новостей»
Плохие новости (задержка, баг, уход ключевого разраба) нужно сообщать немедленно. Но по формуле: Проблема + Причина + 3 варианта решения. Заказчик оценит контроль над ситуацией больше, чем ложное спокойствие.
8. Документируй «Почему», а не «Что»
В коде или в документации фиксируй, почему было принято именно такое техническое решение. Через полгода, когда заказчик спросит: «Зачем мы сделали этот костыль?», ты сможешь аргументированно ответить, ссылаясь на ограничения того момента.
9. Сопротивляйся «Золотому унитазу»
Иногда разработчики хотят сделать «идеально архитектурно», тратя на это недели. Твоя задача — бить по рукам за избыточное качество (over-engineering), если оно не приближает к сдаче по ТЗ. Сначала — working software, потом — рефакторинг.
10. Помни про Бритву Хэнлона
Не приписывай злому умыслу заказчика то, что можно объяснить простотой или отсутствием опыта. Если он задает «глупые» вопросы или саботирует тесты, скорее всего, он просто боится ответственности. Стань для него проводником, а не оппонентом.