Скоро наш журнал обновит свой дизайн
Close
Будь в курсе
Подпишитесь на рассылку, чтобы не пропускать новые выпуски журнала
лекция
Управление и результаты
Что значит «сделать»
Как в фильме «Пятый элемент», значение имеет только жизнь, так и при решении задачи, значение имеет только результат. Это — бинарная система: либо результат есть, либо нет. Нет градаций, полурезультата не бывает.

Артемий Лебедев пишет о результате: «Если в студии дизайнер не спал неделю, редкие седые волосы падают с его немытой головы, щёки впали, глаза красные, но при этом страница хуёво свёрстана, то меня волнует только то, что страница хуёво свёрстана».

У Ильи Бирмана есть мысль: «Наличие причины не опровергает следствие».

Что бы там ни происходило, как бы кто ни проспал, не успел, не понял, ни постеснялся позвонить, важно, что сегодня в 10 часов мы собрались. Либо что‑то есть, либо чего‑то нет.

Мне нравится метафора преподавателя и студента. Представьте, студенту надо сдать курсовую или диплом, а научный руководитель у него ужасно противный, ленивый, всё ему пофиг и осточертело в этом институте. А студенту надо сдать ему работу. И студент бегает за преподавателем, пытается его выловить, а преподаватель всё время пытается съехать, либо вообще потеряться. И даже если студент поймает преподавателя, он даёт ему плохие комментарии, старается избавиться от студента побыстрее.

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

Значение имеет только результат. Да, преподаватель плохой, да, он виноват, но в армии — студент.

Что вы по этому поводу думаете, что вам кажется неправильным? Какие есть вопросы?

— Основной принцип — «„делать" не значит „сделать"» — я читал несколько раз, он мне очень нравился, и я думал, что буду так жить и будет красота. Всем, с кем я работал, тоже про это рассказывал. В реальности переключения не произошло. Я прочитал, мне очень понравилось, но применить в жизни не получилось.

Н. Т. — А почему? Я ещё не встречал ни одного человека, который бы сказал, что он не понял, что значит «сделать».

— Все всё прекрасно понимают.

Н. Т. — При этом также я не встречал ни одного, который с первого раза сделал бы. Потом, в итоге, начинается: «Блин, это вообще не я делал, это вообще бэкэнд».

— У меня сработали какие‑то внутренние модели поведения, что ночью звонить, туда‑сюда...

Н. Т. — Я хотел бы, чтобы у вас осталось в голове следующее. У вас должен быть «водораздел»: можно испытывать все эти эмоции (иногда действительно звонить людям плохо), но вы должны всегда понимать, в каком вы состоянии: «сделал» или «не сделал». Что вы делаете, это уже другое дело. Звоните, пишете, может быть, вы приехали назад в бюро, это уже какие‑то решения. Но важно понимать состояние, в каком вы находитесь. [После этого] дальше в голове всё устаканивается.

...

Н. Т. — А задачу кто решает?

— Задачу решает исполнитель, но формулирует задачу и отвечает за результат менеджер.

Н. Т. — Делает исполнитель, а отвечает менеджер?

— В начале курса была хорошая тема про то, что менеджер отвечает за продукт. По каким причинам у него этот продукт не получился, чей это факап, это абсолютно внутренняя история с исполнителем.

Н. Т. — То есть существует большой продукт и менеджер передаёт небольшой кусочек.

— Нет, менеджер отвечает за всё.

Н. Т. — Менеджер передаёт кусочек исполнителю?

— И если кусочек не получается, и из‑за него весь продукт плохой, то это не вопрос к исполнителю. Если менеджер берёт исполнителя за руку и ведет к директору, говорит: «Вот такой исполнитель мне попался». Ситуация вчерашнего ролика, когда все сидят на общем совещании с клиентом и пинают бедного дизайнера, когда это абсолютно внутренний процесс.

Н. Т. — Давайте разберёмся. Есть большой продукт. Это может быть, что угодно. Сайт, не сайт. Есть заказчик, которому надо всё. Для этого он выдал задание менеджеру: «Сделай мне сайт». Менеджер сам не делает. У него есть много исполнителей. Одному он дал верстать, другому дизайнить… У кого какие здесь обязательства? Менеджер заказчику должен отдать весь продукт. В чём идиотизм ситуации, которую вы описали? Если менеджер дал исполнителю кусочек, но за кусочек отвечает менеджер, то заказчик, давая менеджеру весь проект, отвечает за весь проект? Так получается?

— Нет. Менеджер отвечает полностью перед заказчиком.

— То есть менеджер перед заказчиком отвечает полностью, а исполнитель перед менеджером отвечает не полностью?

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

Здесь надо очень чётко разделять. Исполнителя не должно волновать, что менеджер отвечает за весь продукт, потому что ему дали задание, кусочек, который он должен сделать. Отсюда берутся все проблемы. Ситуация детского сада: исполнитель зафейлил, но отвечает менеджер, который начинает пытаться выгребать сам. Он должен построить равные отношения между собой и исполнителем и между собой и заказчиком. Если исполнитель не сделал, это его проблемы. Он не сделал именно свой участок, его никто не просил делать весь проект. Но то, о чем его просили, он должен сделать. На этом уровне менеджер — заказчик для исполнителя. Отношения все те же самые. Если исполнитель не сделал, то ситуация такая же, как если менеджер не сдал.

— Поэтому я подчеркнул, что если рассматривать ситуацию с точки зрения клиента, а не исполнителя в данной ситуации, то это так.

Н. Т. — Не важно. В данной ситуации менеджер — заказчик. Если он плохо описал задачу исполнителю, то это проблема исполнителя. Клиент же может плохо описать задачу? Тогда менеджер сам дурак. Здесь то же самое. Ситуация просто переносится. На участке клиент‑менеджер, исполнитель — менеджер, на участке менеджер‑исполнитель, исполнитель — исполнитель. Если менеджер фигово объяснил задачу исполнителю, то это проблема исполнителя. Он должен уточнить. Эта схема должна работать симметрично. Вот, в чём история. Исполнитель делает и должен сделать.

— Имеется в виду, что не надо расхолаживать исполнителя? В контексте того, что если они не поняли задачу или её хреново объяснили, а они не спросили, значит виноваты они?

Н. Т. — «Расхолаживать» — это файнтюнинг команды. Я говорю о понимании. Тот, кто делает, тот и отвечает за результат. Если тебе дали [задание], ты отвечаешь за результат. Если тебе дали плохое задание, это будут твои проблемы. Либо это задание не бери сразу, либо, если ты понял после того, как тебе его дали, что с ним есть проблема, сразу звони, либо отменяй, либо узнавай, либо получай данные сам. Выкручивайся сам, как хочешь. Важно только то, чтобы в результате ты сделал то, что от тебя ждут. Либо ты делаешь то, что ждут, либо ты меняешь эти ожидания. Точно так же и здесь. Заказчик попросил сайт, менеджер, допустим, не знал, что ему придётся делать фотографии и фотосессию. И пусть он делает, что хочет: проводит фотосессию за свои деньги, передоговаривается, изменяет ожидания, делает [иллюстрации] из пластилина, но [продукт должен быть сделан]. Это главная проблема. Почему‑то в отношениях клиента и менеджера все всё понимают. Если это две компании, то, не дай бог, суд и всё такое. А если это менеджер и исполнитель, то внутри компании начинается детский сад: «А это мне плохо задание дали». Кого это волнует? Ты взял задание? Взял. Дедлайн был? Был. Если ты чего‑то не понял, то почему не уточнил?

— Можно я добавлю кое‑что. В агентстве была такая система, когда был введён общий лист истории факапов. Идут проекты, по понедельникам планёрки, на которых закрываются задачи прошлых недель, ставится список на следующую. И независимо от обстоятельств, которые случились, каждая задача из предыдущего списка оценивается по системе «либо сделана, либо не сделана». Всё, что не сделано, попадает в общий лист. Без обстоятельств, без всего. Эту систему, к сожалению, пока отменили. Она показалась излишне жестокой. Но те люди, которые в ней пожили хотя бы полгодика…

Н. Т. — Я не понял. Если не сделано, то это добавляется в список. А что дальше?

— За это нет штрафов. Просто все осознают факт. Была задача, задача не сделана. Пожив полгодика в такой системе, у человека полностью меняется сознание. Не на уровне «я понимаю, о чём речь», а на уровне внутреннего ощущения.

Н. Т. — Понятно.

— Это был список несделанных задач?

— Да.

Н. Т. — Другой хороший пример, чтобы понять и визуализировать в голове: любые виды транспорта. Например, поезд. Допустим, ты хочешь куда‑то уехать. Ты зашёл и прочитал расписание, что в час отправляется поезд. Дальше здесь бинарная система: либо ты сел в поезд и поехал, либо поезд ушёл. Но случиться может всё, что угодно. На сайте могли опубликовать неправильное расписание (это как раз плохая задача — менеджер плохо поставил). Что бы там ни случилось, в какой‑то момент ты придёшь на вокзал, а поезда нет. Не поедешь ты, а тот, кто сделал плохое расписание, вообще об этом не узнает.

Давайте пойдем дальше. Мы договорились, что «сделать» значит «получить результат». А что такое результат? Люди иногда говорят: «Делай, что хочешь, но чтобы к вечеру было!». Это значит, что если есть задание, у него есть какой‑то путь выполнения и финальная точка. Когда люди говорят «делай, что хочешь», они имеют в виду, что [на отрезке пути к этой точке], ты можешь делать, что хочешь, но в конечной точке должен быть результат. Средняя часть пути их не волнует. Потому что эта часть находится в мире исполнителя, он здесь живёт, он знает, как сделать дизайн, как открыть Фотошоп, а в мире клиента только финальная точка.

Процесс — в мире исполнителя, а в мире клиента — только результат. Поэтому можно сказать, что «сделать» значит получить результат в мире клиента. Не просто какой‑то результат, а тот, который важен для клиента. Не как многие приходят и говорят, что сделали дизайн и получают кучу замечаний. Дело в том, что [исполнитель] не сделал. Он в своем мире считает, что сделал, а в мире арт‑директора — вообще не сделал. Ещё надо 40 итераций.

Границы — это всё равно, что я решил, что поздно звонить. Ты не знаешь, поздно ли звонить, не поздно, можно, нельзя, а уже ты установил границу себе. Границ не существует, пока ты их не потрогал.

Другой взгляд. История хорошая. Так и делают хорошие разработчики и вообще любые исполнители. Они думают глобально, а действуют локально. Они могут идти дальше. Допустим, ты пришел в магазин купить себе беговые кроссовки, потому что ты хочешь заниматься бегом. А тебе продавец в магазине после 10 минут копания на складе выносит очень дорогие лакированные туфли и говорит: «У меня для вас есть отличное предложение. Эти туфли стоили пятьсот тысяч, я вам продам их за пять. Это специальное предложение для вас».

Продавец считает, что он делает лучше, но его решение может тебе не подойти. Оно может быть лучше в общем, но оно может не подходить. Так же и с программистом. Он может что‑то придумать, но оно будет не в мире клиента. Это хорошо, что он так делает, расширяет зону ответственности, но он должен сверяться, нормально это или нет. Это то, что нужно или нет? Он должен сам убедиться в том, что его новое предложение соотносится с тем, что нужно клиенту, заказчику. Границ нет.

Пример из лекции Артёма Поликарпова из нашей практики. Когда мы делали один сайт, там была переключалка оплаты, и два вида товара (красный товар и синий), «оплатить таким‑то способом» и иконки. Мы сделали синие иконки, потому что я думал, что они будут везде. Потом до меня дошло, что было бы хорошо, если у нас есть два товара, покрасить этот в синий, а тот — в красный, чтобы было одинаково. И я пишу арт‑директору в «Тутти» (бюрошный Бейскемп): «Артём, вот идея. Давай сделаем тут красные иконки». На что через несколько часов мне отвечает Артём Поликарпов, верстальщик: «Спасибо, воплотил».

Он точно попал в то, что было нужно. Всё сам сделал и нарисовал в Фотошопе. Конечно, это замечательно. Он понял, что надо, сделал. Но он мог и не попасть. Может быть, я имел в виду что‑то другое. Здесь важно понимать, что он мог выкинуть свое время и сделать вообще что‑то не то. Я понятно ответил?

Н. Т. — Если исполнитель к дедлайну не сделал задачу, а ведущий проекта говорит, что виноват не исполнитель, а вся команда. В этом есть доля правды или это сентиментальность?

Н. Т. — Макс (в скайпе) написал, что результат — это то, что от тебя ожидает заказчик.

— Можно еще вопрос по результату? По мотивам наших вчерашних разговоров, насколько я понял, результат — это не всегда то, что ожидает заказчик, это то, с чем он согласился: у нас есть «Б», «Б‑штрих» и т. д.

Н. Т. — В этом смысле, конечно. Но только когда происходит история про Б‑штрих, в какой‑то момент ожидания меняются. Хотели сделать 10 страниц, не успели, пошли к клиенту, договорились на 5 страниц. «Б» изменилась так, что клиент с этим согласен: «Да, хорошо. Я согласен». Тогда мы сделали 5 страниц. Здесь нет разницы, просто изменились ожидания.

[Сергей по Скайпу]

— В общем, пример из реальной жизни. Я запускал проект, не запустил его вовремя, накосячил, и на разборе полётов с менеджером я говорю, что это мой косяк, я не сделал то‑то и то‑то. А менеджер говорит: «Нет, виноват не ты, Сергей. Виновата вся команда». И теперь, когда я стал старшим джедаем, а младший джедай чего‑то не делает, я говорю, что это косяк младшего джедая. История повторяется и менеджер говорит: «Виноват не младший джедай, виновата вся команда». Я считаю, что это не так. А вот есть ли в этом доля правды?

— В поиске виноватых? Правильно ли были найдены виноватые?

— Правильно ли в срыве дедлайна исполнителем винить всю команду.

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

— Несмотря на тот посыл, что когда менеджер плохо поставил задачу исполнителю, это проблема исполнителя, он должен контролировать ход работы и такой принцип контроль не снижает?

Н. Т. — Ещё раз: если менеджер плохо объяснил задачу исполнителю, а исполнитель её уже взял и высказал какие‑то обещания, то это полностью проблема исполнителя. Он должен сделать задачу либо изменить ожидания. При этом, может быть плохой менеджер. Он всё время даёт плохие задания. Это не значит, что исполнитель теперь должен переключиться в режим «мне плохо дают задания, а я теперь им всё буду сливать». Он должен думать, что с этим делать. Например, прийти к руководству и сказать, что у него плохой менеджер, поговорить с самим менеджером. Сказать: «Ты всё время даёшь плохие задания. Мне очень трудно их выполнять».

— Получается, что менеджер вовремя не проконтролировал, вовремя не пнул и пропарил, что исполнитель не сделал задачу.

Н. Т. — Перенесём на наш пример с письмом. Я вас, всех участников, не пнул, и вы не сделали иконку. И что? Кто не сделал иконку?

— Не сделали‑то мы, а плохо — заказчику.

Н. Т. — Это уже следующий слой. Естественно и понятно, что если менеджер будет отвечать за всё, то если он в итоге сайт не сделает, то он не сделает свою задачу. Но на уровне отношения между менеджером и исполнителем плохая работа менеджера никого не волнует. «Мне плохо дали задачу» — не отмазка. Если задача плохая, то зачем ты её взял. Если ты заметил это позже, то почему ты ничего не сделал, чтобы получить данные или передоговориться.

— Можно короткую ремарочку? Хотелось бы по‑прежнему видеть задачу из глаз менеджера несмотря на зеркальность этой ситуации не с точки зрения исполнителя. Но чтобы сделать некоторые выводы, в том числе, и с моей работой с исполнителем в реальной жизни, хотелось бы понимать задачу с точки зрения менеджера исполнителя. Его внутренний мир и его обязательства передо мной меня интересуют только в контексте того, как выстраивать отношения с этим исполнителем, но я по‑прежнему остаюсь менеджером, а не исполнителем. То есть ситуация для меня не меняется. Симметрично…

Н. Т. — Смотрите, когда менеджер даёт задание, говорит «Вася, копай яму!», он в этот момент сам исполняет свои обязанности перед вышестоящим клиентом. Если он даст плохое задание, то он зафейлит свою работу перед клиентом. Но перед исполнителем, который пойдет с лопатой копать, он ни в чем не виноват. Для него он клиент: как смог, так и сказал.

— В этом плане меня не контекст интересует или какие‑то рефлексии на тему, кто прав или виноват. Это не важно в контексте продукта. Мне интересно, какую нужно создать атмосферу или воспитать идеологию у исполнителей, когда будет значить, что если они не переспросили, то зафейлили продукт. Это поинт. Поинт — это конкретная методическая штука для менеджера. Рефлексии исполнителя и менеджера по отношению к исполнителю не важны в контексте того, что проект зафейлен. Как работать с исполнителем и выстраивать с ними работу таким образом, чтобы эта ситуация была эффективнее? Как самому ставить задачи либо создавать культуру того, что исполнитель сам виноват перед менеджером, если не уточняет, не участвует в общем результате? Что тут делать менеджеру?

Н. Т. — Хочу уточнить вопросы. Как вести себя менеджеру с исполнителем — чтобы что?

— Чтобы максимизировать его ответственность и чтобы это давало конкретные результаты. То, что исполнитель виноват, ок. Он придет ко мне и скажет: «Я виноват». Хорошо. Если это поможет в будущем, это эффективно, но если он придёт и скажет, то это никак не поможет завтра сдать результат.

Н. Т. — Почему же не поможет?

— Он так будет делать постоянно.

Н. Т. — Приходить и говорить, что он зафейлил?

— Суть в том, что какая система должна быть?

Н. Т. — Честно говоря, я до конца вопрос не очень понял. Система должна просто и эффективно работать, если основана на всех уровнях на принципе «сделать». Объясняется это примерно такими же словами. Вот задача, дедлайн такой‑то (договорились о нём — не обязательно его требовать). Дальше ты говоришь: «Вася, мои ожидания, что к десяти часам это будет сделано. Я ожидаю, что ты всё необходимое сделаешь, чтобы задача была выполнена. А если у тебя возникнут проблемы, я ожидаю, что ты со мной свяжешься и изменишь мои ожидания. Сейчас других ожиданий у меня нет. Я ожидаю, что апельсины будут готовы. Всё, работай». Вот так надо требовать. Если это работает не так, начинается детский сад. Детский сад очень тяжёл физически, потому что ты не можешь доверять [исполнителю]. Вдруг он не делает, вдруг он не работает. Надо ему позвонить: «Ты работаешь? Ты сделал? А сколько ты сделал? Давай посмотрим». Это как раз и вызывает все сложности. Каким образом в бюро удаётся делать много проектов? Например, Артём участвует во многих проектах, в том, что делаем мы (сайтах, кафе, учебных курсах и куче всего). Это настроенная работа. Он знает, что если он сказал мне сделать курс, я здесь буду грызть землю зубами, сам буду настраивать видеотрансляцию, делать всё, что угодно, чтобы курс был сделан. Если у меня не получится что‑то сделать, я ему скажу, что у нас очень серьёзная ситуация («Полстены у Коворкафе отвалилось. Надо срочно искать кирпичи, а я не знаю, где»). И он знает, что он меня может оставить в покое, я сам приду, если что. Если бы было наоборот, и он был как классический менеджер, ему бы каждого приходилось спрашивать, что у тебя, как у тебя. Просто физически одного человека не хватило бы.

— И всё же что делать, если исполнитель не знает, что такое «понимать задачу» и делает фигню?

Н. Т. — Надо учить. Учить, что такое «понимать задачу».

— А не у тебя был пост про ручное управление в экстренной ситуации?

Н. Т. — Возможно, был. Может быть, был у кого‑то ещё. Это же не секрет. Мы сейчас говорим, как этого избежать.

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

Н. Т. — Конечно, не испортит. Во‑первых, если менеджер будет плохо ставить задачу, он не выполнит свою задачу. Он пообещал сделать сайт и всем сказал: «Ну сделай, ну напрограммируй». Потом все ему принесут плохой результат, а тут уже клиент пришёл, говорит: «Давай сайт». А у него его нет. Он быстро сам свою работу сольёт. Во‑вторых, если он испортит все отношения, ему будет очень тяжело. Когда менеджер даёт задание, в его интересах дать его как можно лучше. Если он так не делает, то либо он неопытный, либо у него появились другие мотивы. Хорошие исполнители должны это чувствовать и не брать задачу. Если что, у всех же должно быть право на «нет». К вам приходит сторонняя фирма и говорит: «Мы хотим такой сайт за день из 56 страниц». Вы говорите: «Нет, мы не успеем». Клиент: «Ну, всё, до свидания. Мы ушли». То же самое здесь. Менеджер приходит к исполнителю и говорит запрограммировать за сегодня. У него должно быть право сказать «нет». Здесь он не нарушает обещание и не предаёт принцип. Он просто плохое не берёт.
Из чего состоит задача
Мы разобрались, что «сделать» — это, как минимум, получить результат в мире клиента. Давайте попробуем разобраться, как это сделать. Посмотрим, из чего состоит задача.

То, что мы вчера рассматривали («Из А в Б») — это типичная задача. Мы находимся в точке «А», как‑то хотим прийти в точку «Б». На этом пути могут возникнуть всякие непредсказуемые вещи.

Чтобы нам знать, куда мы направляемся и куда хотим прийти, нужно понимать задачу. Поэтому очень важен принцип «исполнитель понимает задачу».

Этот принцип используется не везде. Например, в армии, наоборот, исполнитель ничего не понимает. У него есть командир, который отдает приказы: «Копать от забора и до заката». Почему это работает в армии? В армии нужно максимально эффективно управлять огромным количеством людей. Там должна быть не важна их квалификация. Каких набрал, таких и послал в бой. Для этого есть сложная иерархия: командиры, сержанты, лейтенанты. Пример армейского управления можно увидеть в фильме «Спасти рядового Райна». Посмотрите, как командир отдаёт приказания. Ему совершенно всё равно, поняли его или нет, он просто говорит, что делать.

Отрывок из фильма «Спасти рядового Райна»

— Четвёртый дивизион, три мили на юг.

— Спасибо.

— Мы с вами поведём взвод в сторону Нувила для выполнения миссии особой чести и важности.

— Ты поведешь взвод?

— Один рядовой из 101‑й потерял сразу трёх братьев и ему выписали обратный билет домой.

— А причём здесь Нувил?

— В этой десантной операции было полно ошибок, он мог оказаться и там.

— Нелегко будет отыскать одного солдата в самом пекле этой проклятой войны.

— Не труднее, чем иголку в стоге сена.

— Как же твой отряд?

— Возьмём лучших, остальные пойдут в роту «Б».

— Боже мой, они забрали твою роту?

— Это не мой отряд, армейский. Так было мне сказано. Мне нужны Райбен, Джексон, Уэйд, Бизли, Капарзо.

— Бизли мертв.

— Ладно, тогда Меллиш. Кто‑нибудь у нас говорит по‑французски?

— Такого не знаю.

— Эй, приятель, дай закурить.

— А ты, Тэлбот?

— Так и быть, докуривай.

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

— Сержант, что делать будем? Уберёмся мы отсюда или нет?

— Ты, Капарзо, отправишься домой, завёрнутый в американский флаг и с куском свинца в заднице.

— Вы любите, когда что‑то в заднице?

— Чтоо?



— Вы знаете рядового Райна?

— Говорите погромче, сэр. У него проблемы со слухом.

— Говорите громче, у меня плохо со слухом. Немецкая граната разорвалась рядом с головой.

— Понял, понял. Вы знаете рядового Райна?

— Кого?

— Рядовой Райн. Джеймс Райн.

— Джимми Райн?

— Джеймс. Джеймс Френсис Райн.

— Нет. Джеймс Френсис Райн.

— Ладно, дайте мне бумагу и карандаш. Быстрее! На чём писать.

— Карандаш.

— Вот маленький, сэр.

— Пишите. Джеймс Френсис Райн. Вопросительный знак. Айова. Вопросительный знак. Прочтите записку. Прочтите!

— Да, конечно, я его его знаю, сэр.

— Где он сейчас?

— Да. Мы оказались в стороне от зоны высадки миль примерно на 20 где‑то возле Бамвиля или как там его. Он и я и двое других парней по дороге к месту сбора наткнулись на полковника, который собирал команду, чтобы идти в Рамеллу.

— Рамеллу?

— Охранять мост.

— Спасибо. Спасибо. Пишите ему. Читайте. Спасибо.

Видите, как это работает? Сам капитан задачу понимает. Ему объяснили, что надо найти рядового и почему это важно. Но сам он действует абсолютно в армейском режиме: «Пишите!» Говорит по буквам. Чем это плохо? Он всё это должен делать сам. Должен отдавать эти приказы, контролировать их исполнение. У нас в работе так не получается. Поэтому, когда в нашей среде люди не понимают, получается как на картинке ниже:
Есть сайт (www.projectcartoon.com), где можно самому набрать каких угодно картинок в любом порядке.

На картинке видно непонимание задачи на всех этапах, что очень похоже на реальный проект. Те, кто описывали ТЗ не поняли, что хотел клиент. Те, кто дизайнили, не поняли ТЗ, другие сверстали не так, как хотели дизайнеры. Потом это хоть как‑то прикрутили и т. д. Получается такая смешная картинка. Фактически, в этой схеме, когда у нас есть клиент, дизайнер и разработчик, клиент приходит в дизайн‑студию и хочет заказать какую‑то работу, а дизайн‑студия отдаёт ему ТЗ или бюро пишет «понимание задачи». Фактически, то же самое должно происходить на всех этапах. Все должны понимать, чего от них хотят, и должны своими словами передавать. Клиент пришёл, мы ему — ТЗ. Не он нам ТЗ, а мы ему. Пришёл дизайнер к разработчикам, разработчики должны всё послушать и сами написать ТЗ. В этом смысле хорошо работают «вопросы Горбунова». Есть такой совет: (http://artgorbunov.ru/bb/soviet/20110422. Пожалуйста, прочтите. Знаете вы или нет, но часть с этими вопросами мы клиентам в таком же виде как они опубликованы на сайте и задаём: http://artgorbunov.ru/bureau/welcome/

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

У нас в Советах был пример (http://bureau.ru/bb/soviet/20140213/). Это реальное понимание задачи, из которого я убрал только вещи про финансы и пр.

Когда клиент приходит в бюро после такого обсуждения, какое вы проводили сейчас (только обычно такой разговор длится часа два с половиной и не всегда заканчивается с первого раза), клиент в ответ получает от ведущего дизайнера такое понимание. Это понимание задачи делается за неделю. И для себя мы тоже используем ФФФ. Если мы не успели, мы флексим и т. д., но дедлайн фиксированный. Здесь сразу, обычно вверху, написано… Здесь сложная история, это писал Илья. Здесь рассказано, что да как. Какие‑то три подхода, три точки зрения на сайт Регуляра.

Задача — поставить на поток заказы на приборы. Здесь сделано не очень привычно для меня, обычно я это выделяю отдельно. Если этого описания нет, то всё, что написано дальше, не нужно. Дальше — это решение. Что надо? Поставить на поток заказы приборов. Самая важная часть.

Эта система масштабируется по‑разному. Если вы даёте просто своему подчинённому или кому‑то задание, он должен точно так же его понять. Вы должны научить его так работать, чтобы он вам говорил: «Я понял, надо сделать вот так. Правильно или нет?» Чтобы он утверждал у вас понимание задачи.

Давайте обсудим, если здесь есть вопросы.

— Что получилось. Клиент плохо прочитал понимание задачи и со всем согласился, а потом в процессе работы, когда уже вник, понял, что всё неправильно. Как помогает такая система?

— Первая помощь здесь в том, что это работает по принципу заряженного ружья. Уже то, что мы показали клиенту наше понимание и потом десять раз спросили его под разными соусами, правильно ли его поняли, уменьшает вероятность такого. Всё равно он хоть что‑то читал. Если бы мы этого не сделали, мы вообще не знали бы, правильно мы его поняли или неправильно, не было бы никаких обсуждений. Если бы показывали, то вероятность была бы ниже. Но избавить от такого, наверное, именно этот подход не может, потому что если клиент, грубо говоря, мог бы и не читать и со всем согласиться, а потом начать предъявлять претензии, это надо решать с помощью переговоров. В проекте большая проблема. Но так как вы уже обсуждали понимание задачи, ты с клиентом можешь обсудить, как же так получилось. Мы думали, что мы правильно поняли, а оказалось, что неправильно. В ответ на этот вопрос ты можешь узнать, что клиент по какой‑то причине читал понимание задачи по диагонали. Например, ему всё равно, лишь бы что‑то было. Ответ понятен, Макс?

— Если я правильно понял, решение на уровне переговоров?

— Да, на уровне переговоров. Чем лучше ты использовал правило «Три плюс» (десять раз переспросил в начале), тем ниже вероятность такой странной истории. Что смешного?

— Нет, это вообще не связано с этим.

— Если смешно про «Три плюс», то это техника переговоров, когда один и тот же вопрос три раза задаётся под разными соусами, потому что человек не сразу может понять что он согласился. Так спросил: «Вы считаете, что это правильно?» Он говорит: «Да». Вы: «Ок, понятно. То есть вы считаете, что вот такие действия приведут к спеху?». И еще раз как‑нибудь переформулировав. Хорошо. Давайте пройдём дальше.
Сдача
Давайте пойдём дальше. Теперь мы знаем, что мы вышли из точки «А» в известном направлении. Мы не просто рисуем иконку или чёрт знает, что. А мы уже знаем, для чего она будет использоваться, каковы критерии оценки и т. д. Допустим, мы пришли, на наш взгляд, в точку «Б». Как понять пришли мы сюда или не попали? Для этого вторая сторона графика — «Сдача».

Работу надо сдать. Дело в том, что только в голове у клиента есть все критерии, которые необходимы для того, чтобы доделать. Мы можем быть как угодно уверенными, что надо именно так, но мы точно не знаем, потому что знания в голове у клиента, кем бы он ни был. Даже если это просто жена, которая попросила нас купить хлеб.

— А если клиент начинает «жопиться»?

Н. Т. — Это как?

— «А вот тут вы не доделали», начинает вставлять палки в колёса, ему всё время что‑то не нравится. Уже всё готово.

Н. Т. — Как готово? Клиент говорит не готово, а вы говорите готово.

— Цвет не тот. Давайте перерисуем. Перерисовали. А давайте подвинем картинку.

Н. Т. — А почему вы решаете тогда, что это готово?

— Начинается хождение по кругу. Давайте вернём то, что было, а картинку обратно, а потом еще одну лабуду сделаем, а потом еще лесять раз её переделаем.

Н. Т. — Всё нормально. Значит, вы ничего не сделали. Помните бинарность отношений? Вот вы ещё в состоянии «не сделали». Клиент говорит, что надо ещё переделывать. Почему он так говорит, другой вопрос. Может быть, правда, вы ошиблись, может быть, ему что‑то в голову взбрело. Соглашаться на такое или нет или какие‑то договоренности были изначально, это другое дело. Но если посмотреть на проблему в рамках темы, то если клиент говорит «не готово», значит, не готово. Представьте, что вы пришли забирать машину из автосервиса, а у неё течёт масло. Вы говорит: «Течёт масло!» Закрутили, потёк «Тосол». Вы говорите: «Тосол потёк!» Устранили утечку, снова побежало масло. Вы не забираете машину, говорите: «Не готово. Не возьму. Давайте доделывайте».

— Это объективная поломка. А когда в дизайне «пиксель не тот»? Он может быть тот, а может быть не тот.

Н. Т. — Вопрос в том, кто решает. По сути, решение принимает клиент.

— Вопрос в том, как работать с клиентом, если он начинает выёбываться?

Н. Т. — Разбираться. Важно понять, почему клиент считает, что пиксель не тот. Он же почему‑то так решает. Вы спрашиваете у него, почему, что не так. Он говорит: «Цвет не тот». А почему не такой? Разбирайтесь в проблеме. Если, допустим, у вас уже кончается время, у вас ограниченный дедлайн и время на разборки кончилось, тогда стоит обсудить с клиентом, что делать: «Пиксель всё ещё не тот? Мы не до сих пор не поняли, что это значит. Давайте подумаем, что с этим делать». По‑другому не может быть. Клиент дал задание, задачу и ждёт, что вы её сделаете. И вы сами, без клиента, её не можете сделать. Вы можете только договориться с ним, что его устроит старый вариант.

По сути, можно сказать, что «сделать» — значит сдать. В прошлый раз было «сделать — это получить результат в мире клиента», а чтобы удостовериться, что он в мире клиента, мы сдаём ему задание. Приходим, показываем и сдаём. И здесь очень важна история про «прогрессивный джипег». Если у вас есть дедлайн и к нему надо что‑то сделать, и вы пришли в этот момент и что‑то показываете в первый раз, априори вы ничего не сдадите, потому что не получили никаких замечаний. Человек, скорее всего, сейчас скажет, что ему что‑то не нравится, а что именно, вы не знаете. Всё, дедлайн пропущен. Теперь вам нужно переделывать или передоговариваться, а времени нет. Поэтому тут работает метод «прогрессивного джипега».

Как у Артемия Лебедева в «Ководстве» (http://www.artlebedev.ru/kovodstvo/sections/167/): есть обычный джипег, который красиво загружает картинку сверху вниз (вверху 30%, внизу — 70%), а есть прогрессивный джипег, когда картинка есть сразу вся целиком, но постепенно уточняется. Вам не нужно ждать до конца, пока загрузка дойдет до края, а показывать картинку сразу целиком в общих очертаниях, чтобы узнать, что вместо синей урны нужна розовая. Дальше, прорабатывая, вы сможете это скорректировать.
На практике это делается так. «Прогрессивный джипег» — это про гусеничку и всё такое. Все дизайнеры, которые приходят в бюро, ошибаются в первый раз. Даётся задание сделать макет за неделю. Если новичок хороший и ответственный, он думает, что в понедельник уже нужно всё принести. Так как я новичок, я буду фигачить все дни, ещё на всякий случай и в выходные попеределываю, чтобы в понедельник принести арт‑директору результат. Арт‑директор говорит, что макет настолько говно, что если только снять первый слой, можно будет смотреть куда‑то дальше. Ещё делать и делать. С фрилансерами похожая история. Почему их многие не любят? Потому что они делают точно так же. Вместо того, чтобы работать на неделе, они пытаются сделать всё в последний день и выдают это за результат. Но в понедельник у них всё равно ничего не будет, потому что замечания учитывать некогда. Правильная история показана внизу. Если у тебя есть задача за неделю сделать десять макетов, значит, в первый день ты должен сделать все десять и показать их. Потом ты получишь какие‑то замечания о том, что ты не туда свернул, два‑три дня ты переделываешь, общаясь с арт‑директором. В конце у тебя остается один день, чтобы идеально всё отполировать, учесть мелочи и детали. В пятницу у тебя всё готово, в выходные ты отдыхаешь.

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

Ребята, кто удалённо участвует, у вас есть вопросы? Не может быть, что нет вопросов.

То есть человек всё выполнил, принес арт‑директору, получил миллион комментариев, с трудом их сделал, и всё равно получил ещё потом столько, что он не успеет. Здесь очень важный момент в том, что арт‑директору плевать на то, что ты не успеешь. Он — клиент, он — заказчик. Он тебе дал задание, и это твои проблемы, что ты не успеваешь. Ты как всегда разбираешься сам, придумываешь что‑то и предлагаешь, либо сообщаешь о проблеме. Соответственно, сообщить о проблеме я ничего не успею, очень плохо, лучше думать. Дизайнер в данном случае должен работать с арт‑директором как с заказчиком, должен придумать какой‑то способ как успеть и предложить его арт‑директору и провести с ним переговоры: «Дорогой арт‑директор, сегодня среда, я получил новую пачку замечаний, которую я не успею сделать. Давай я пока сделаю так, попроще». Так работать вполне нормально. Арт‑директор, как тот менеджер и исполнитель, в этом смысле — менеджер, не обязан следить за тем, что у тебя перегрузка. Он не знает, сколько ты это делал, не знает, что ты ночами не спал. Единственная разница в том, что хороший арт‑директор — очень требовательный клиент. Он замечает много всего. Какой‑то клиент может тебе спустить что‑то с рук, арт‑директор, наоборот, никогда не спустит, ещё и навалит того, что не просили (все соседние задачи). Это правда, так и есть. Макс, что тебе кажется здесь странным?

— Странным — ничего, но нужно научиться технике переговоров.

Н. Т. — Главное — не просто говорить, что не успеешь, а предлагать решения. Обычно, когда есть хорошее простое решение, арт‑директор никогда не против. Обложку курса мы пофлексили. Если бы я стал туда придумывать иллюстрацию, я бы получил туда те самые миллион комментариев. А так обошлось всего лишь двадцатью итерациями о положении шрифта. Макс, я ответил?

Мне кажется, что это должно быть странным для кого‑то. Давайте попробуем [это обсудить]. Кто делает так, кроме тех кто работает в бюро?

— А если нет арт‑директора? Как у фрилансера, например.

Н. Т. — У него есть заказчик.

— В третьем варианте, у дизайнера бюро есть два заказчика: реальный клиент и арт‑директор.

Н. Т. — Здесь нет того реального заказчика. Здесь всё ограничивается уровнем работы с арт‑директором. Потом ведущий дизайнер берет это всё и то же самое делает с клиентом. Здесь можно зачеркнуть «арт‑директор» и написать «клиент», зачеркнуть «дизайнер» и написать «исполнитель». Все исполнители считают, что их работа ограничивается придумыванием решения. Он пришёл и говорит: «Я сделал». Ни фига ты не сделал. Ты должен ещё показать, получить комментарии, исправить большие недочёты, потом ещё докрутить мелочи.

— Если говорить про бюро и третий вариант, где в этой строке клиент? Там еще такая же неделя с клиентом?

— Да, дальше ещё неделя с клиентом.

Н. Т. — Важный вопрос, если говорить про фрилансера, который напрямую общается с клиентом, насколько сырой результат имеет смысл показывать? Это зависит, конечно, от клиента, но это очень тонкая штука.

— Действительно, показывать сырой результат опасно. Если ты работаешь внутри какой‑нибудь дизайн‑фирмы, то можно прийти и показать арт‑директору сырой результат, что тоже очень плохо, у него будет много замечаний. Всегда проще, если ты сам всё придумал, принес готовое решение, даже если он потом всё выкинул. Иногда прокатывает какой‑нибудь сырой вариант, но с клиентом это может не прокатить, потому что он может не понять. Принцип — приносить максимально готовое.

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

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

Н. Т. — А с клиентом в такой ситуации как быть?

— С клиентом опаснее. Нужно думать. Если клиенту показать совсем сырой вариант, он не поймёт и завернёт, у арт‑директора специально настроенный мозг, он может в плохом увидеть хорошее и помочь вытащить.

Н. Т. — Можешь привести примеры реальных жизненных ситуаций, когда тебе приходилось показывать клиенту что‑то сырое и объяснять, что ты показываешь что‑то сырое, чтобы понять…

— Конечно. В понимании задачи всё сырое. Иногда мы вставляли туда схемы.

Когда мы делали дизайн электронных журналов для фирмы Актион, мы им предложили не просто сделать дизайн журнала, а предложили систему перехода всех изданий. Прикол этой задачи в том, что есть 42 журнала, которые обновляются. Если будешь делать каждый дизайн каждого журнала отдельно, потом его будет невозможно обновлять. Поэтому мы придумали, как сделать их универсальными. Они устроены одинаково. Вот дефолтный стиль без ничего, а вот — «Финансовый директор». И так — 42 журнала. Мы нарисовали не всё, но основную часть.
А когда мы с клиентом обсуждали, мы вставили ему такой график понимания задачи. Мы рассказали, как это всё будет: сначала мы сделаем «Главбух», потом на его основе дефолтный серый стиль, потом переведём все остальные журналы. То есть сначала был дефолтный стиль. «Главбух» мы сразу делали «раскрашенным», круче, чем дефолтный. Потом все остальные журналы мы переводим в дефолтный серый стиль, а потом начинаем придавать им стиль. В итоге итерации № 2 не случилось, клиент посмотрел и сказал, что они не хотят все журналы делать серыми, они хотят сразу «раскрашивать», поэтому мы перешли сразу к итерации Х. Сейчас идёт и продолжается итерация N. Вся идея и рисунок — это общий джипег, сделанный за полдня.
Ещё раз. Задача — это весь градиент. Первая часть — не решение, а первая часть, поэтому не стоит удивляться, когда клиенты говорят вам, что всё фигово.

— А если к этому добавляется ещё одно звено, к строке прибавляется неделя или это происходит на заданном промежутке? Есть дизайнер, ведущий дизайнер и арт‑директор. Что меняется?

Н. Т. — Это принцип. Не обязательно бывает так. Части могут быть меньше, могут быть двухнедельными. Если ведущий дизайнер дал дизайнеру задание, дизайнер утверждает у ведущего, ведущий дизайнер утверждает у арт‑директора по этой схеме. Это атомарная задача. Отдельно частей не бывает. Каждая задача такая и дальше не делится, иначе будет недоделанной.

— Я правильно понимаю, что каждый конец маленького этапа — это чекпоинты?

Н. Т. — Гвозди в гусенице? Да, всё правильно.

— Эти точки проговариваются как‑то с исполнителем?

Н. Т. — Проговариваются, да. Более того, «сделать» надо кому?

— Исполнителю.

Н. Т. — Он и просит. Потому что если он не попросит и не договорится (за ним же ходить никто не должен), он просто не сможет всё это сделать. Он должен знать и понимать эту схему. Тут может быть много чекпоинтов, зависит от задачи. Так реально в бюро задача и устроена. Если я работаю с дизайнером, у нас с ним итерации по один‑два дня, там всё то же самое. Он говорит: «Давай, я завтра в четыре часа покажу первую итерацию, а вечером докрутим, потому что завтра показывать арт‑директору». «Давай». А для арт‑директора я исполнитель. Я прихожу и приношу ему то, что мы вместе сделали с дизайнером. Арт‑директор, соответственно, мочит, я всё записываю и мы переделываем. А потом всё это мы вместе несём клиенту. Клиент говорит: «Тут тоже есть такие‑то проблемы».

— Какое имеет значение то, что ты ходишь на согласование к арт‑директору вместе с дизайнером, который рисовал, или без него?

Н. Т. — Я люблю ходить вместе, но этого не требуется, а иногда, может быть, и не нужно. Почему это может быть плохо? Потому что когда ты идешь вдвоём, ответственность ведущего дизайнера перед арт‑директором никак не меняется. Результат арт‑директору сдаёт ведущий дизайнер. Но когда он идёт вдвоём с кем‑то, у него может возникнуть иллюзия того, что тот тоже слышал задание и всё сделает сейчас сам. А если он не сделает, это арт‑директора не будет волновать. Я люблю ходить вместе, потому что так быстрее передаётся информация. Илья Бирман, например, насколько я знаю, не любит ходить толпой.

— Ещё вопрос. Может быть, его раньше надо было задать. У меня была ситуация, когда мы делали галочки. Рисовала галочки девочка‑шрифтовик, потому что в шрифтах она разбиралась гораздо лучше, чем я.

— Миша говорит вот об этом проекте: http://bureau.ru/projects/galochki/

— Частенько я чувствовал себя нелепо, потому что не мог что‑то подсказать шрифтовику, потому что разбирался в них не так хорошо. Как действовать в таких ситуациях?

Н. Т. — А в чём проблема? Ты не мог ей помочь сделать её работу?

— Да.

Н. Т. — Ну ты и не должен ей помогать делать её работу. Иначе тогда ты должен разбираться во всех областях. Ты должен понимать базовые принципы, а если у неё есть вопрос, как для какого‑то шрифта нагнуть кривую, то ты не обязательно должен дать ей ответ. Ты должен дать ей ответ как это сделать, но не на сколько градусов. Ты должен понимать принцип, что этот знак устроен по тем же принципам, что и такая‑то буква: «Иди изучи все буквы, изучи как во всех хороших шрифтах сделаны галочки». То есть у тебя должен быть ответ, но это не значит, что ты должен быть экспертом во всех областях.
Согласование
Это все компоненты. У нас есть знания и умения о том, как понять задачу, чтобы направиться, есть этап согласования, чтобы понять, попали мы в точку «Б» или нет.

У нас есть совет о согласовании (http://bureau.ru/bb/soviet/20130624). Я хочу сейчас очень быстро с Ильёй Синельниковым посмотреть, как это работает. В чём здесь прикол? Когда вы принесли клиенту что‑то сдавать, очень важно все его замечания аккуратно обработать, всё понять и договориться с ним о том, что вы с ними делаете. Это главный источник всех конфликтов с клиентами.

Первое, что нужно сделать, это суперспокойно без всяких предположений обсудить каждое замечание. Даже если человек вам написал, что тут всё говно и он такого не ожидал, и на этом точка, вы к нему приходите и говорите: «Михаил Константинович, что значит то, что вы написали, что вы имели в виду?» Никаких эмоций, ты не волнуешься, не злишься, не считаешь, что он мудак, просто спрашиваешь. Он начинает тебе говорить, пока ты не поймешь (можно извиниться за глупые вопросы, как, например, ребята, как Илья, Миша) до конца его замечания. Как только ты его поймешь, тебе нужно принять решение прямо здесь на встрече и выбрать один из трех вариантов решения проблемы. Других просто не может быть.

Решение проблемы можно перенести на следующую итерацию, либо совсем не делать, снять. Клиент говорил, что работа говно, ты с ним поговорил, объяснил, почему ты так сделал, он сказал: «Ой, ну да. Ладно. Не говно». Снимается.

Либо вы договорились, что действительно здесь ты не очень хорошо сработал и тебе нужно что‑то доделать. Тут же ты должен договориться, как ты это делаешь. Это, минимум, понимание задачи, которое ты обсуждаешь с клиентом.

Либо самый худший вариант, если ты совсем не знаешь, что делать, — взять таймаут. Но так как у тебя при этом согласование заложено в срок, то этот таймаут работает против тебя. Если у тебя есть неделя на согласование, а ты ушёл на четыре дня думать, потом пришёл с каким‑то решением, то времени ещё что‑то переделать нет. Тебе будет очень плохо. Поэтому надо максимально быстро придумать и перезвонить. В итоге все решения сводятся к первым двум. В третьем варианте ты возвращаешься к началу и либо делаешь, либо не делаешь.
«Сделать» не значит сдать
Про «сделать» я немного вам наврал специально. Для базового понимания достаточно знать, что «сделать» это значит сдать. Нужно всех к этому вести и рассказывать про мир клиента. Для начала понимания это хорошо работает. Это чёткий принцип. Но реально «сделать» это не значит сдать. «Сделать» значит «сделать». Это сложно понять, но секрет здесь вот в чём. Клиент не всегда прав. Вы можете прекрасно всё сделать и прекрасно всё сдать, но это будет фигня. Поэтому вы всегда должны понимать, что «сделать» это значит сделать хорошую работу, её продать, донести и т. д. История про «сделать значит сдать» — базовый уровень понимания.

— Сдать можно и что‑то нехорошее?

Н. Т. — Да. Клиент примет — и всё. Так же многие и делают. Тот же интернет‑магазин белья сделали и сдали, а он не работает, потому что, оказывается, был нужен фирстиль. Клиент может давить на вас и говорить: «Да ладно, блин, давай…». Ни фига. Вы должны понимать, что вы действительно сделали и принесли настоящую пользу.

Последнее, что вы должны понимать: «делать» не значит «сделать». Это про бинарное состояние результата. Пока вы в процессе делаете, что хотите, вы делаете, а когда готово — вы сделали.

UPD: Рекомендую посмотреть сериал о докторе Хаусе. Хаус всегда всех посылает на три буквы, нарушает правила, все его ненавидят, но пациента он вылечивает, потому что знает что значит «сделать».