От заказчика может прилететь вопрос: “Коллеги, что у нас там по задаче?”
Обычно по такой фразе уже чувствуется, что человек не просто решил уточнить. Он подождал, не увидел движения и пришел сам.
А внутри команды в этот момент может быть полная суета, разбор проблемных блоков и активное стремление успеть к назначенным срокам.
Работа была, но клиент этого не видел. Для него картина другая: задачу обещали, готовой доработки нет, понятного статуса нет, свежего сообщения тоже нет. Значит, команда тормозит.
Когда клиент уже сам пришел с вопросом, объяснять причины задержки уже поздно. То, что вчера можно было спокойно обсудить как риск, сегодня звучит как оправдание. Даже если причина настоящая.
Команда видит процесс. Клиент видит паузу
Команда живет внутри задачи. Там активно может кипеть работа. Иногда почти весь день уходит не на то, чтобы "сделать кнопку", а на то, чтобы понять, почему первый очевидный вариант лучше не делать.
Клиент не сидит внутри рабочих обсуждений. Он видит последнее сообщение, статус задачи, обещанную дату и итог: готово или не готово. Если несколько дней нет обновлений, то вся внутренняя работа для него просто не видна.
Я видел это на проектах несколько раз. Внутри идет активная работа, а у клиента последняя запись по задаче была две недели назад.
И потом уже почти бесполезно рассказывать, сколько всего было сделано внутри. Человек оценивает не количество действий, а то, что изменилось для него с последнего разговора.
Куда реально уходит время
Чаще всего невидимой становится не сама разработка, а все, что идет рядом с ней.
Например, требования. Верхнеуровнево задача понятна. Потом выясняется, что один сценарий описан слишком общо, по другому нет владельца решения, а по третьему разные участники ждут разного поведения. Команда начинает уточнять. С точки зрения клиента, если ему ничего не сказать, это выглядит будто работа идет медленно.
Или согласования. Ответственный человек не ответил сегодня. Завтра попросил показать вариант еще раз. Потом перенес обсуждение. Команда ждет, срок понемногу двигается, но клиент об этом не знает. Через неделю фраза "мы ждали согласование" уже звучит слабовато, потому что блокер всплыл слишком поздно.
Еще один частый случай - меняющиеся вводные. Начали делать одно, потом появилась новая деталь, потом стало понятно, что старое решение уже не подходит. Специалисты переделывают, проверяют. Если это не проговорить вовремя, клиент увидит только итог: обещали раньше, сделали позже.
Отдельная боль - поток обращений. У меня была ситуация, когда команда несколько дней параллельно занималась поддержкой. Обращений было много, часть из них была связана с тем же процессом. Они отвлекали, требовали разборов, где-то помогали лучше понять проблему, но нормально нигде не фиксировались.
Через несколько дней срок по проектной задаче начал уезжать. Команда действительно работала, но показать это было почти нечем. Через неделю сам уже с трудом вспоминаешь, куда ушли конкретные часы. А клиенту объяснить это еще сложнее.
"Разбираемся" почти ничего не объясняет
Когда клиент спрашивает статус, команда может ответить: "в работе", "разбираемся", "есть технические сложности".
Для клиента такие фразы пустые. Особенно если он не технический специалист.
"Есть технические сложности" - какие именно? Как они влияют на срок? Это проблема на час, на день, на неделю? Нужно ли от клиента какое-то решение? Есть ли риск, что объем изменится?
Если этих ответов нет, клиент сам достраивает картину. И редко в пользу команды.
Лучше писать не про занятость, а про движение.
Не так:
В работе.
А так:
Проверили основной сценарий, он подтвердился частично. Сейчас уточняем ограничение по согласованию. Вернусь с обновлением сегодня до 17:00.
Не так:
Есть технические сложности, разбираемся.
А так:
Текущий вариант затрагивает связанный процесс. Проверяем последствия, чтобы не исправить одно и не сломать другое. Если риск подтвердится, предложим более безопасный вариант.
Не так:
Ждем ответа.
А так:
Для продолжения нужно подтвердить основной сценарий. Без этого есть риск сделать не тот вариант. После подтверждения сможем точнее назвать срок.
Это несколько строк, которые показывают, что работа по задаче ведется.
Позднее объяснение почти всегда слабее раннего предупреждения
С рисками по срокам есть простое правило: чем позже о них говоришь, тем хуже это воспринимается.
Команда может видеть проблему заранее, но есть желание дожать. Не тревожить клиента. Не показывать проблему раньше времени. Вдруг успеем.
Иногда успеваем. Но иногда нет, что влечет за собой неприятный разговор.
Клиент спрашивает: "Почему раньше не сказали?". Хотя риск уже был, просто его не вынесли наружу.
Мне кажется, здесь лучше быть чуть раньше, чем чуть позже.
После новых вводных объем изменился. Видим риск по сроку. Можно сохранить текущую дату, если берем только первый сценарий. Если нужен полный вариант, срок придется пересогласовать.
Команда не оправдывается после сорванного срока. Обозначает риски сразу и заранее показывает варианты.
То же самое с блокерами со стороны клиента или других участников. Если задача стоит из-за согласования, лучше написать об этом сразу.
Сейчас задача стоит на подтверждении сценария. Без этого решения есть риск уйти не в тот вариант реализации. После подтверждения вернемся к разработке и обновим срок.
Это намного лучше, чем через несколько дней говорить: "Мы не могли продолжать, потому что нам не ответили".
Если клиент молчит, это не значит, что его все устраивает
Есть ловушка: клиент не спрашивает - значит, все нормально. На практике не всегда.
Он может быть занят. Может ждать обещанную дату. Может считать, что команда сама держит ситуацию под контролем. А потом, когда результата нет, сразу приходит с накопленным раздражением.
И в этот момент выясняется, что у клиента уже есть своя версия происходящего, которая может отличаться от реальной.
Эта версия может быть несправедливой. Но она появляется не на пустом месте. Она появляется там, где не хватило информации.
Для себя я из таких ситуаций вынес простой вывод: если клиент сам пришел за статусом после долгой паузы, значит, где-то раньше мы уже опоздали с коммуникацией.
Клиенту не нужна вся кухня
Здесь легко уйти в другую крайность и начать заваливать клиента подробностями. Это тоже плохо.
Не нужно пересказывать каждую внутреннюю переписку, технические детали и все промежуточные сомнения. Человек хотел понять, что с задачей, а не читать стенограмму рабочего дня.
Хороший статус обычно короткий. В нем есть несколько вещей: что сделали, что выяснили, где зависли, что будет дальше и когда вернетесь с обновлением.
Например:
По задаче: уточнили сценарий с ответственным, нашли расхождение с первоначальными требованиями. Сейчас проверяем влияние на срок. Если риск подтвердится, сегодня предложу два варианта: сохранить дату с меньшим объемом или делать полный вариант с переносом.
Технических подробностей здесь почти нет. Но есть основа. Клиент понимает, что произошло, почему появилась пауза и когда будет следующий шаг.
А если клиент говорит: "Мне нужен только результат"
Такое тоже бывает. Клиент не хочет быть вовлеченным в процесс и прямо говорит: "Не надо меня грузить деталями, просто сделайте".
Не каждый заказчик хочет читать промежуточные статусы и участвовать в рабочих обсуждениях.
Но "не грузите деталями" не равно "молчите до последнего". Если меняется срок, объем или нужен выбор, клиент все равно должен узнать об этом вовремя.
В таком случае я бы оставлял только контрольные сообщения.
Деталями не загружаю. Есть изменение по сроку из-за новых вводных. Сегодня подготовим два варианта: быстрый с меньшим объемом или полный с переносом даты.
Такой формат уважает желание клиента не погружаться. Но при этом не оставляет его в полной тишине.
Что фиксировать, чтобы потом не спорить по памяти
На проектах много важного остается в чатах.
Потом проходит неделя, и начинаются вопросы. Когда появились новые требования? Кто должен был подтвердить сценарий? Почему срок сдвинулся?
Если ничего не зафиксировано, приходится восстанавливать историю по памяти. А память в таких ситуациях плохой помощник. Каждый помнит свой кусок.
Я бы фиксировал минимум:
- текущий статус задачи;
- что изменилось с прошлого обновления;
- следующий шаг;
- зависимость или открытый вопрос;
- риск по сроку;
- дату следующего обновления.
Смысл не в том, чтобы писать больше. Смысл в том, чтобы важная работа не исчезала.
Особенно это касается обращений или дополнительной загрузки, которые прилетают параллельно с проектной задачей. Если они нигде не отражены, они будто не существовали. Хотя время они забирают вполне реальное.
Несколько строк лучше длинной паузы
Иногда достаточно совсем короткого сообщения.
За сегодня закрыли два связанных обращения, которые влияли на этот процесс. По самой доработке возвращаемся к проверке завтра утром. Если увидим сдвиг по сроку, сразу отдельно обозначу.
Это полезно, когда проектная работа пересекается с поддержкой. Статус не оправдывается, но показывает, почему день не был пустым.
Другой пример:
По задаче продвинулись: подтвердили основной сценарий, но нашли зависимость от согласования. Сегодня отправили вопрос ответственному. Если ответа не будет до завтра, предложу временный вариант, чтобы не держать задачу полностью.
Здесь нет отчета на страницу. Но есть понятное движение.
Что руководителю или тимлиду стоит держать в голове
Я бы не строил вокруг этого отдельную тяжелую систему. На практике часто достаточно иногда задавать себе несколько вопросов.
Есть ли по важной задаче свежий понятный статус? Понимает ли клиент следующий шаг? Не появился ли риск срока, о котором еще не сказали? Не стоит ли задача из-за согласования, которое никто не подсветил? Не ушло ли время на обращения, которые нигде не отражены?
Такая проверка помогает поймать проблему раньше, чем клиент сам придет с раздражением.
Потому что вопрос "что у нас там по задаче?" иногда означает не просто интерес к статусу. Иногда это уже сигнал, что клиент слишком долго был без контекста.
Не надо превращать это в отдельную отчетность
Здесь тоже нужна мера. Если после каждого маленького действия писать клиенту отчет, команда начнет обслуживать видимость вместо работы. Клиент быстро перестанет читать такие сообщения.
Мне ближе другой подход: не показывать все подряд, а информировать в ключевых местах.
Появился риск срока - сказать. Нужен выбор клиента - сказать. Требования изменились - показать, как это влияет на работу. Задача стоит из-за согласования - обозначить зависимость. Параллельные обращения забрали время - хотя бы коротко зафиксировать.
Этого обычно достаточно, чтобы клиент видел, что задача жива.
Вывод
Клиенту не нужно видеть всю внутреннюю работу команды. Ему не нужны длинные объяснения, технические подробности без запроса и рассказы о том, как все были заняты.
Но если он не видит никакого движения, он начинает додумывать. И додумывает обычно не в пользу команды.
Поэтому руководителю или тимлиду лучше не ждать момента, когда клиент сам придет с вопросом. Нужно заранее показывать понятное продвижение: что сделали, что выяснили, где возникла сложность, какой следующий шаг и когда будет обновление.
Чем больше клиент находится в рабочем контексте, тем меньше у него поводов собирать свою версию происходящего. И тем меньше сил потом уходит на объяснения, почему команда на самом деле не тормозила.