Есть фраза, после которой я уже примерно понимаю, куда пойдёт разговор: «Нам нужно супер лакшери, бизнес плюс, чтобы все конкуренты обзавидовались, бюджет вообще не проблема, можем аж пять тысяч заплатить». Раньше такие формулировки могли меня раздражать, сейчас скорее заставляют внимательнее задавать вопросы. Потому что проблема обычно не в самом клиенте, а в том, что наши представления о задаче вообще могут находиться в разных вселенных.
«Небольшая правка» и другие ловушки
Есть и другая классика — «глянь сайт, у нас там что-то немного подвисает». Однажды такой сайт на Битриксе оказался взломанным, а невинное «глянь» превратилось примерно в два дня ручной чистки, обновлений и поиска последствий взлома. Поэтому слово «небольшая» я теперь стараюсь воспринимать исключительно после того, как сам посмотрел задачу.
С дополнительными хотелками похожая история происходит практически постоянно. Если клиент просит немного передвинуть кнопку, добавить простую форму или сделать небольшой калculator, мне обычно проще спокойно это сделать внутри первоначальной стоимости. Но если посреди разработки интернет-магазина внезапно появляется полноценный раздел избранного, это уже отдельная работа с отдельной стоимостью.
Кстати, про ожидания «вау-дизайна за копейки» — отдельная история. Красивый сайт и рабочий сайт — не одно и то же, и это лучше прояснить до старта, а не после.
Конфликты, которые разработчики создают сами
Со временем я вообще понял довольно неприятную вещь — часть конфликтов с клиентами разработчики создают себе сами. Плохо зафиксировал требования, не уточнил границы проекта, не записал договорённость, а через месяц каждый совершенно искренне помнит разговор по-своему. У меня такие ситуации тоже были, и именно поэтому сейчас я намного внимательнее отношусь ко всему, что происходит до начала разработки.
Как я начинаю проект сейчас
Обычно всё начинается с подробного брифа, а созвонам я сейчас предпочитаю переписку. Можно писать текстом, можно отправлять голосовые сообщения, потому что их потом всё равно получится распознать и сохранить. Мне важно иметь возможность через несколько недель открыть историю и точно посмотреть, что клиент просил, а что мы действительно согласовали.
После этого я собираю всю информацию и дополнительно прогоняю её через ИИ. Он помогает структурировать требования, найти информацию о компании в открытых источниках и иногда подсвечивает вопросы, которые мы сами не обсудили. Потом всё ещё раз согласовывается с клиентом, считается стоимость, вносится предоплата, и только после этого начинается сама работа.
Материалы, предоплата и сроки
Отдельная боль практически любого разработчика — материалы от клиента. Сайт уже пора собирать, сроки идут, а тексты, фотографии, цены или документы где-то путешествуют между сотрудниками компании. Поэтому сейчас я работаю только с предоплатой, а в договоре отдельно прописываю возможность сдвигать сроки, если необходимые материалы задерживаются со стороны заказчика.
Формально там даже предусмотрено начисление 0,1 процента за каждый день такой задержки, хотя применять этот пункт мне пока ни разу не хотелось. Он скорее нужен для понимания простой вещи — срок разработки зависит не только от разработчика. На практике я обычно просто напоминаю, жду материалы и корректирую сроки проекта.
Почему не «стартанём, а по ходу разберёмся»
И ещё я почти никогда не люблю начинать работу в формате «давайте стартанём, а по ходу разберёмся». Не потому, что мне хочется развести бюрократию на сорок страниц, а потому что без понимания объёма я могу назвать только очень примерную стоимость. Причём эта оценка может оказаться как ниже реальной, так и выше, а переплачивать за мою перестраховку клиенту тоже никакого смысла нет.
Исключение — проекты вроде Дельников, где сам продукт ещё не существовал и ТЗ рождалось вместе с разработкой. Но там была совсем другая логика: свой продукт, а не заказной проект с фиксированным бюджетом и сроками.
Главный вывод
Наверное, главный вывод за годы работы оказался довольно простым — нормальный процесс нужен не для того, чтобы усложнить жизнь клиенту. Бриф, переписка, ТЗ, предоплата и фиксация дополнительных работ нужны затем, чтобы через месяц никто не доказывал друг другу, кто что когда говорил. Чем лучше мы договорились в начале, тем меньше неприятных сюрпризов потом получают обе стороны.
Про то, как это выглядит в повседневной работе — блокнот, сообщения, переключение между проектами — писал отдельно. Если хотите обсудить проект с нормальным стартом — напишите, разберём задачу до начала разработки.