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