“Смотреть за тьму”: Как наладить взаимодействие заказчика и исполнителя, чтобы спокойно и продуктивно работать

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

Советы стороне разработчика

Большое объяснение на этапе пресейла

Клиент почти никогда не понимает всего объема работы, который нужно сделать, чтобы получить результат.

Поэтому на этапе переговоров, до того, как вы дадите оценку проекту, посвятите один интрозвонок тому, чтобы полностью, шаг за шагом, рассказать клиенту, что вы будете делать. Мы в Enkonix всегда объясняем, как создается дизайн, как проходит разработка, какие технологии мы будем применять, какие есть нюансы, требующие внимания, — и все это не пресейле. Только потом озвучиваем, сколько это все стоит. Тогда это не просто большая сумма, а стоимость конкретного объема работ.

Подписывайтесь на Youtube-канал delo.ua

Много маленьких хороших новостей

Практикуйте постоянное снабжение клиента хорошими новостями — подойдет даже суперкороткий чекин на 5 минут. Это лучше, чем долгий период молчания, а потом одна большая новость.

Когда вы даете информацию по чуть-чуть, это порождает ощущение работы и прогресса. К примеру, на стадиях бизнес-анализа и дизайна этому правилу следовать просто: новая кнопка, новая страница.

С точки зрения заказчика это показатель хорошего темпа, а с точки зрения исполнителя — отличное вовлечение клиента и дополнительный шаг к прозрачности и отчетности.

Стандартно чекапы у нас каждую неделю, для меня это самый удобный вариант: за это время и будет что обсудить, и не пропадаешь слишком надолго. Мне кажется, многие менеджеры мыслят недельными циклами.

Миксуйте техническую и “гуманитарную” информацию

Приписываемый Эйнштейну афоризм “упрощайте, насколько возможно, но не больше” хорошо работает для построения нормальных отношений между заказчиком и исполнителем в IT. Ваша целевая аудитория почти всегда гораздо проще, чем вы думаете. Их понимание, как устроена техническая часть проекта, минимально.

Но выкатить клиенту информацию, как для 5-летних детей, тоже не вариант.

Мой совет такой: сбалансируйте техническую и не техническую части в подаче информации о проекте. Пусть в ней будут и технические термины/технологии, и человеческое объяснение, как это работает.

Оставляйте себе гибкий дедлайн

Если вы будете делать все вышеперечисленное, то стресс от дедлайна не должен вас настигнуть. Всегда есть ситуации, когда требуется больше времени, чем ожидалось. Если это произошло, будьте прозрачны: объясните клиенту, с какими трудностями вы столкнулись. Скажите, что из-за этого придется поработать над задачей немного дольше и что это нормально: неожиданные сложности — часть жизни разработчиков. Такая коммуникация, по моему опыту, — это способ спокойно довести проект до результата.

Повторяйте

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

Советы стороне клиента

Большое объяснение на этапе пресейла

Любой внешний подрядчик почти никогда не понимает всех нюансов и ограничений вашего проекта. У нас в RYAH, как в компании, работающей с медицинским каннабисом, есть масса ограничений: что мы можем говорить, чего не можем. Разъяснить все это нужно на этапе переговоров. Это поможет подрядчику не только установить адекватный гонорар, но и существенно сэкономить время и усилия. А иногда просто вовремя сойти с дистанции и не браться за неподъемный для себя проект. 

Работы всегда больше, чем кажется клиенту

Если вы на стороне заказчика, помните: вы не ощущаете количества работы, которая выполняется. Даже если раньше вы сами были подрядчиком на этой же позиции или делаете частые синкапы. Вы не знаете, сколько усилий вложили люди и сколько мелочей учли! Качественно выполненная работа требует времени, и ответственный подрядчик будет закладывать в работу риски и правки. По моему опыту, стоит опасаться как раз таки слишком оптимистичных прогнозов по таймлайну и стоимости. 

Не упирайтесь в дедлайны

Придраться к формальным признакам всегда проще, и четкий дедлайн — один из них. Требования заказчика сдавать к определенному времени, “не позже трех часов” (хотя чаще всего никакой поезд в три часа не отходит), — это всегда стресс. Но даже если человек раньше страдал от прессинга дедлайнов, то, перейдя на сторону клиента, волшебный образом начисто забывает об этом и начинает требовать сдать в три часа.

Рекомендую “попуститься”

В моей практике был кейс, когда потенциальный клиент на этапе предпродажных переговоров заявил, что если мы не сдадим к определенному сроку, он нас оштрафует. Мы отказались от сотрудничества. Тогда клиент сказал: "А вы накиньте неделю. Но если не уложитесь в этот срок, заплатите штраф". Мы опять говорим “нет”. И тут он предлагает: "А вы скажите, что это у вас занимает столько-то времени, хотя в реальности вполовину меньше. Тогда вы точно успеете, а если нет, то будет штраф". То есть человек ставит жесткие условия и тут же показывает, как их обойти. Мы тогда решили, что ничего хорошего из этого не выйдет, и финально отказались.

Я за коммуникацию и прозрачность. И как заказчик, и как подрядчик стараюсь редко ставить строгие дедлайны и вести диалог, что получается, что не получается, и когда будет результат.

Больше общайтесь

Если вам как клиенту кажется, что с той стороны лентяи, больше общайтесь с вашим подрядчиком, будь то маркетинговое агентство, команда разработки или одинокий дизайнер на фрилансе. Спросите их, как идут дела, какие возникают трудности, больше разберитесь в процессе.

Конечно, если ты параноик, то это еще не значит, что тебя никто не преследует. Действительно, есть ситуации, когда ваш подрядчик ничего не делает. Для таких случаев существуют условия контракта, и, например, такая модель отношений (мы практикуем ее в Enkonix) — у нас нет предоплаты, заказчик оплачивает только уже созданный код или продукт. Мы называем это “контракт на доверии”.

Не ищите виноватых

Есть такой анекдот. Летящий на воздушном шаре понимает, что потерялся. Он снижает высоту, замечает внизу человека и кричит ему:

- Скажите, пожалуйста, где я?

Человек снизу кричит в ответ:

- Вы на воздушном шаре, в 10 метрах над землей.

- Вы, наверное, разработчик? — спрашивает воздухоплаватель.

- Как вы догадались?

- Вы дали мне технически корректный, но бесполезный ответ.

Человек снизу спрашивает:

- А вы, должно быть, заказчик?

- Как вы узнали?

- Ну, вы не знаете, где вы, но ждете от меня, что я помогу. Сейчас вы в той же позиции, что и до нашей встречи, но теперь я чувствую себя виноватым.