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