Проект, который не вошёл в портфолио. Как я бросил
клиента по SMS

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

Знакомство с проектом

В 2018 году к нам обратилась финансовая компания. Такой себе локальный «Уолл-стрит», где сидят белые воротнички и предлагают клиентам акции, ПИФы, финансовое управление активами и инвестициями. Руководство хотело создать динамичные онлайн-доски почета и позора с привязкой к сложным финансовым расчетам. Цель — в режиме реального времени наблюдать за ходом продаж и рейтингом сотрудников.

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

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

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

Второй этап заключался в предварительном переходе к хранилищу данных и интеграции с 1С, SAP, таблицами в Excel.

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

Первый этап. Организационные факапы

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

Мой аналитик копался в цифрах. Дизайнер рисовал красивый, но бессмысленный макет. Не было логической связи между визуалом и Экселем.

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

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

Руководство компании спорило между собой, присылало нам по 100500 переделок. Ситуация напоминала кадры из фильма «99 франков», когда вице-президенты огромной рекламной компании не могли утвердить оттенок травы.

Часто мы слишком долго ждали, пока рабочая группа клиента соберётся для совместных совещаний. Встречи проходили бурно. Моему бизнес-аналитику, действительно грамотной девушке, было сложно строить диалог с толпой продажников, которые привыкли кричать, спорить и действовать на эмоциях.

В итоге получился макет с цветными индикаторами выполнения плана. На нём же — довольные и недовольные человечки, стрелочки, медальки за первые места и красные карточки за убыточные сделки. Образец «Как не надо делать, или Топ-10 ошибок дизайнера».

Рассмотрим эту линию дальше и перейдем на дашборд, рассказывающий историю российского животноводства. На левой части листа расположены графики, которые показывают объемы потребления и производства мяса. Автор даёт информацию, начиная с 1990 года и заканчивая прогнозом на 2030 год.

На ленточной диаграмме видим динамику потребления птицы, говядины и свинины в России и мире. До 2000 года население России отдавало предпочтение говядине, а потом на первое место переместилось мясо птицы. Доля его потребления будет расти и к 2030 году составит 5,5 млн тонн.

В мире ситуация отличается. До 2010 года на первом месте было потребление свинины, после — мяса птицы. Объемы говядины на фоне птицы и свинины понемногу сокращаются. Связано это с тем, что с каждым годом производственные циклы по свинине и птице дешевеют, а выращивание говядины остается более дорогостоящим процессом.
В нашем портфолио — минималистичные и функциональные дашборды. Этот макет оказался полной противоположностью предыдущих работ.
Итак, мы уложились в срок и прошли первый этап. Всё нарисовали, согласовали, собрали на разовых выгрузках дашборды в Power BI, чтобы можно было прокликать и прощупать.

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

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

Второй этап. Хранилище данных и проклятые OLAP-кубы

До этого момента общались с бизнес-заказчиками: финансовыми отделами и продажниками. Они у нас принимали работу. На этапе разработки уже предметно перешли к согласованию архитектуры с ИТ-директором и его командой.

DAX против MDX

Состоялся такой диалог:

— Ребята, нам нужен системный подход, а не ваши красивые картинки в дашборде. У нас, на минуточку, шина данных, и расчетные показатели должны быть доступны для интеграции с другими сервисами!

— Да пожалуйста, мы как раз всю агрегацию делаем в хранилище на MS SQL, не замыкая все расчеты на Power BI.

— Это хорошо, только сделайте нам еще OLAP-куб.

— Так у вас же SQL Server Enterprise последней версии, там есть табулярная In-Memory модель данных. Это то же самое, что куб, только делается быстрее, то есть будет для вас дешевле.

— Вы не поняли, нам нужен старый добрый OLAP-куб, на MDX.

— Давайте не будем. Это уже отмирающие технологии из нулевых, с 2012 года существует DAX (напомню, диалог происходил в 2018 году).

— Нет, это неполноценная технология, нам нужны настоящие кубы!

Понимая, что диалог зашел в тупик, я назначил отдельную техническую встречу, чтобы взвешенно решить вопрос архитектуры. На ней команда ИТ-директора начала задавать нам каверзные вопросы в духе:

— Скажите, как в вашей мемори-модели вы будете считать вот эту средневзвешенную с динамическими коэффициентами?

И так далее. Действительно, все это можно было сделать только на MDX. Только вот в нашем проекте это было и не нужно. Но нас тыкали носом в неполноценность и ограниченность архитектуры. И намекали, что будут «вынуждены заявить о технической некомпетентности подрядчика».
Я не отстоял мнение своей команды, а прогнулся под заказчика. Повёлся на манипуляцию не получить оплату и потерять клиента. Согласился на работу с морально устаревшей технологией, которая несла в себе много рисков.

История с исходными данными и моими истериками

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

Работа затягивалась. Мы писали техзадание и отправляли разработчику. Получали ответ, проверяли, находили несоответствия с ТЗ и просили переделать.

Разработчик доказывал, что его таблицы должны состоять именно из таких столбцов, а мы требовали смотреть внимательно и давать нам информацию четко по ТЗ. Он нехотя переделывал. Высокомерно обращался, считая нас дураками.

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

— Ты читал техзадание?!

— Ну естественно…

— Сейчас открывай седьмую страницу и читай вслух перечень полей! (Он читает).

— А теперь читай то, что ты прислал нам. Не сходится? Сколько еще будешь включать дурака? (В этот момент мысленно ломаю стул об его голову).
Согласен, это было грубо, но только после этой сцены он хотя бы стал внимательно читать ТЗ и давать те данные, что написано. Всплеском эмоций я добился прогресса в проекте, но предчувствовал, что такое поведение мне еще аукнется.

Кастомные визуалы

Итак, дизайн-макеты согласовали, Power BI собрали, но я не уследил за дизайнером и вовремя не остановил разгулявшуюся фантазию.

На макете заказчику показали штуки, которые в представленном виде сделать в стандартном Power BI невозможно. Например, прогресс-бар, который меняет заливку в зависимости от процента выполнения плана.
Заказчик оказался склонным к формальности и отказался рассматривать альтернативные варианты. Есть ТЗ — выполняйте. Давайте визуализацию, которую показали на дизайн-макете.

Чтобы в точности повторить макет, пришлось делать кастомные визуалы для Power BI. Нашли подрядчиков и заплатили приличную сумму за создание карточек, а потом долго пытались настроить их работу по-человечески.

Но на этом дело не закончилось. Запросы клиента не соответствовали стандартным возможностям Power BI.

Хитрая настройка доступа и ролей

У нас есть OLAP-куб, куда мы берём пользователей из домена Active Directory Microsoft, чтоб каждый видел только свой уровень. То есть сейл видит себя, начальник отдела — тоже только себя и так далее до генерального директора.

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

Дальше по замыслу клиента на наших дизайн-макетах были такие фишки, когда продажник видит себя и своих конкурентов: 3 выше него по рейтингу и 3 ниже. Для этого тоже пришлось писать кастомную таблицу, которая в обход OLAP-кубов и домена выводила бы историю «конкурентов».

Шрифты

Перфекционизм заказчика добавил боли при настройке шрифтов и единиц измерения, которых нет в Power BI. Ему необходимы были именно свои, а не стандартные.

Новые шрифты не ложились правильно. Отчёты не адаптировались под разные устройства. Пока настраивали на компьютере, изображение на планшете или смартфоне слетало. Надписи съезжали и наползали друг на друга.
Мы продолжали платить подрядчикам. Сразу — за создание дополнений, потом — за их подгонку. По нашим затратам проект на тот момент уже выходил в ноль.
После такого негативного опыта стараемся в проектах обходиться стандартными галереями Power BI. Хотя иногда кастомные доработки проскакивают.

Третий этап. Команда начинает выгорать

Кое-как справились с технической частью и перешли к следующему этапу — ввод системы в эксплуатацию. То есть сначала мы настраиваем процесс, а потом выверяем данные.

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

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

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

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

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

Наш бизнес-аналитик устал от бесконечного проекта и пропускал запросы клиента. Почта оставалась непрочитанной. Я начал разбираться. Оказалось, она уже в депрессивном состоянии и просто игнорирует письма. Отправил её в отпуск, но это не помогло. В итоге она уволилась, оставив кучу незавершенной работы.

В каждый кризисный момент меня поддерживала мысль, что на выходе получится действительно классный проект. Клиент будет использовать его в своей работе, хвастаться партнерам, а наше портфолио пополнится крутым кейсом.
Я поменял аналитика, но так как человек был не знаком со всей кухней проекта, пришлось разруливать, где наш косяк, а где новые работы. Каждый вечер, когда моя семья засыпала, наливал себе виски и садился разбирать почту, сортировал просьбы исправить ошибки и очередные пожелания на доработку.
Спусковым крючком стали сообщения, написанные красными заглавными буквами:«В вашем отчете кривые цифры. РАЗБЕРИТЕСЬ И ИСПРАВЬТЕ!!». Я понял, что так продолжаться не может и принял решение поставить точку в работе над токсичным проектом.

Вечером после порции виски позвонил клиенту. Он не ответил. Я отправил сообщение: «Простите, мы закрываем оплаченный объем работы и прекращаем дальнейшее сотрудничество».

Некрасиво, согласен. Но тогда мне казалось, что так будет правильно.

Список факапов и выводы

Получилось, что факапы были на каждом этапе работы по этому проекту. И все они обогатили меня опытом и выводами.

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

На этапе технической разработки:
- Попытка натянуть Power BI на OLAP-кубы нецелесообразна.
- Кастомные визуалы — это трудозатратно и дорого. А их настройка ещё сложнее, чем разработка.
По части работы с командой:
Я потерял двух сотрудников. Хотя, думаю, они всё равно ушли бы при любом другом сложном проекте.

И о выводах. Первое: каким бы умным ни был аналитик BI, важна стрессоустойчивость. Мягкотелым интровертам не место в команде. Неадекватные, сложные заказчики и рабочая трясина выбивают их из колеи.

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

Признаю, что в некоторых моментах поступал некрасиво. Срывался на крик, грубил заказчику. По sms закончил работу над проектом. Но сегодня в половине случаев я бы поступил точно так же.

Истина «клиент всегда прав» с токсичными заказчиками не работает. Я больше не позволяю садиться на голову и отстаиваю интересы своей команды.
Если вы еще не получаете все новости и полезные материалы Института бизнес-аналитики первыми, то подписаться на рассылку можно внизу этой страницы. Надеюсь, статья была вам полезной и подарила парочку инсайтов.
Читайте также
Подпишись на рассылку и получи в подарок «Каталог лучших отраслевых дашбордов»!
Хочешь получать актуальные статьи о визуализации данных?