«Сделать по ТЗ» vs «Решить задачу»: почему это разные вещи
Я руковожу дата-консалтингом, который строит системы сквозной аналитики для диджитал-компаний. После 40+ выполненных проектов я понял, что самое сложное и самое важное — это не разработать техническое решение, а найти подход к заказчику. Рассказываю на примере, как это сделать и не фрустрироваться из-за правок, когда не получилось с первого раза.
Вы бывали в такой ситуации, когда в парикмахерской мастер спрашивает:
— Ну, как вам?
Вы отвечаете:
— Да, здорово, то, что надо, — а в это время гадаете, как вам теперь жить пока это не отрастет обратно. Ходить все время в шапке или стать отшельником и уйти жить в лес?
Такое бывает в любом деле, которое связано с работой с клиентами: вроде бы сделали, что просили, но получилось не то.
А все потому, что «сделать то, что просили» и «сделать хорошо» — это не всегда одно и то же.
Задача исполнителя — найти баланс между пожеланиями заказчика и своим экспертным пониманием, как сделать лучше. В моей практике был случай, который помог мне в этом убедиться.
Заказчик пришел с очень конкретным ТЗ. Мы с командой выполнили все, что он просил, но результат получился не таким классным, как хотелось бы и нам, и ему. Это подтолкнуло к тому, чтобы глубже погрузиться в проект и вместе с заказчиком найти лучшее решение.
Суть задачи: дашборд для отслеживания времени ответа на заявку лида
- Заказчик: онлайн-школа Refocus. Много курсов, несколько отделов продаж и огромный поток заявок.
- Задача: мониторить SLA (контроль качества сервиса) и, в частности, скорость ответа продажников на заявку. Чем быстрее, тем охотнее лид конвертится в клиента. Целевое время — 15 минут.
- Решение: сверстать дашборд с заявками по дням, источниками лидов, скоростью ответа и продолжительностью звонка.
По такому дашборду можно увидеть, откуда пришел лид и как быстро на его заявку отреагировали сейлзы.
Респект заказчику за подробное ТЗ. Он не только описал, зачем ему дашборд, но и какие показатели и в каком виде надо на нем отобразить. Например, у него было требование скорость ответа показать именно ✨на логарифмической шкале✨
Спойлер: с этой шкалой мы еще намучаемся.
По ТЗ сразу видно, что заказчик серьезно подошел к вопросу и подумал над задачей. Те, кто работает с клиентами, знают, как это греет душу.
Этому заказчику мы выстроили масштабную систему аналитики — одних дашбордов в ней было больше 40. Подробно (и абсолютно бесплатно) я рассказываю об этом на онлайн-экскурсии: показываю дашборды и рассказываю про работу.
→ Запись по ссылке
Итерация первая: ничего не понятно и не очень интересно
Что мы видим на этом дашборде? Идем сверху вниз.
- Инструкция, как с ним работать.
- Логарифмическая шкала заявок по дням. По шкале Y — скорость ответа, по шкале X — время. Черные линии — медианное время ответа.
- Два столбчатых графика со медианной скоростью ответа на заявку в день и средней продолжительностью звонка.
- Справа фильтры — можно выставить временной период и посмотреть, откуда пришел лид, какой курс его заинтересовал, кто из сейлзов с ним общался.
Оценка результата: 3/5. Дашборд выполняет свою задачу, но можно и лучше.
Кстати, а как вам этот дашборд? Пишите в комментариях, что думаете о каждой из версий! Да, их будет несколько.
Что с ним не так?
- Логарифмическая шкала была требованием одного из представителей заказчика, но оказалось удобной не для всех пользователей. Скажите честно, как часто вы имеете дело с логарифмической шкалой?
- Три графика не были синхронизированы по шкале Y. В итоге сравнивать по ним данные было неудобно.
- Неудобные фильтры — чтобы сравнить данные по лидам из разных источников, нужно было переключаться между фильтрами и делать скриншоты. Ну, или запоминать значения для каждого источника.
Все это неприятно, но не смертельно и неизбежно. Как бы хорошо ни было продумано ТЗ и как бы тщательно мы ни подошли к разработке, с первой попытки сделать идеальный дашборд получается не всегда.
Но получается — не зря же мы так долго этим этим занимаемся. На экскурсии рассказываю, как мы это делаем, и прохожусь по всем этапам работы — от первого брифа до верстки дашборда. За 1 час узнаете все о том, как создаются системы аналитики.
Записаться все еще можно по ссылке.
Итерация вторая: хотели как лучше, получилось как всегда
Тут мы освежили дизайн и предложили несколько улучшений.
- Слева список сейлзов с медианной скоростью ответа и средним временем звонка. Он работает, как фильтр — если хочется узнать подробности про конкретного менеджера, надо нажать на его имя, и его данные отобразятся на графиках справа.
- В центре шкала, которая теперь переключается между двумя режимами: логарифмическим и линейным.
- Столбчатый график с медианным временем ответа заменили на более удобный и наглядный линейный.
- График со средней продолжительностью разговора убрали, чтобы не перегружать дашборд. Теперь этот показатель можно было отслеживать по каждому сейлзу отдельно с помощью фильтров слева.
- Справа фильтры по курсу, источнику и категории лида. К ним прикрутили столбики с медианным SLA, чтобы сразу можно было оценить скорость ответа по разным признака без переключения между фильтрами.
Стало не только красивее, но и намного удобнее. Да? А вот и нет.
Оценка результата: 3-/5. Учли старые ошибки, но добавили новые.
- График со средней продолжительностью звонка по всему департаменту продаж надо было вернуть — фильтр слева не смог его заменить.
- На главном графике со шкалой по всем лидам потеряли отсечки с медианным временем ответа за день.
- Также этот график очень долго загружался из-за того, что открывался без фильтров и вываливал на пользователя все данные по всем лидам сразу.
Итерация третья: вот теперь норм
Вот он — идеальный дашборд, где все на своем месте.
- Все фильтры и колонки подписаны. Для шкалы в центре сохранили возможность переключаться между линейным и логарифмическим режимами.
- Все графики на месте, и оси синхронизированы друг с другом.
- Центральный график отображается после выбора отдела или менеджера, чтобы ускорить загрузку.
И сверху все отполировали дизайном по брендбуку.
Оценка результата: 10/5. Все довольны, все смеются.
Что мы поняли?
Когда вы все сделали по ТЗ и все равно прилетели правки, легко начать кого-нибудь обвинять: заказчика за «неточное» задание или своих коллег за «плохую» работу. Но это нерационально.
Продуктивный подход — разобраться в запросе заказчика и понять, какой результат ему нужен. Это поможет найти решение проблемы.
Довольно часто, каких-то требований нет в ТЗ, потому что заказчик просто не знал, что так можно. И это особенно актуально для сложных технических сфер вроде аналитики — Refocus сначала не попросил прикрутить графики к фильтрам, потому что не знал, что в Tableau можно это сделать. Ну а мы с этим Tableau много лет работаем и знаем кучу фишек, которые можем предложить.
В общем, конечно, нужно стремиться к идеалу, но стоит ждать, что его удастся достичь с первого раза — и это нужно понимать и заказчикам, и подрядчикам. Почти всегда будут правки и доработки, мелкие и не очень, и это нормально. Это возможность сделать продукт лучше и полезнее.
В последний раз напомню про еще одну возможность — бесплатно, в онлайн-формате и в любое удобное время узнать, какую пользу вам принесет система аналитики. Это круче, чем простая консультация, потому что вы не просто узнаете про цены и сроки, а видите своими глазами реальный результат работы.
Оставляйте заявку по ссылке.
Итоговый реально хорош. Он уже в бою у клиента?
Спасибо! Да, это была итоговая, рабочая версия, которую использовал клиент
как всегда подробно, спасибо, читаю с удовольствием
Спасибо большое!
хочу добавить, что с первого раза сдаться точно не получится в случае разработки или дизайна, да и много в чем еще
Не сказал бы, что точно не получится — зависит от кучи факторов: от ТЗ, от заказчика, от исполнителя. Но соглашусь, что чем сложнее проект, тем выше вероятность, что даже с самым лучшим ТЗ и самым лучшим исполнителем придется пройти несколько раундов правок, чтобы прийти к нужному результату.
Заказчик пришел с очень конкретным ТЗ. Мы с командой выполнили все, что он просил, но результат получился не таким классным, как хотелось бы и нам, и ему
это хорошо, что все всё поняли и решили двигаться дальше, сделал выводы, а то заказчик мог и на дыбы встать и сделать вас виноватыми.