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

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

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

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

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

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

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

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

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

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

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

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

Итак, мы уложились в срок и прошли первый этап. Всё нарисовали, согласовали, собрали на разовых выгрузках дашборды в Power BI, чтобы можно было прокликать и прощупать.

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

Ничто не предвещало беды: все утверждено, работа движется. Но я не обратил внимание на отношения между моей командой и рабочей группой заказчика.

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

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

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

— Да пожалуйста, мы как раз всю агрегацию делаем в хранилище на 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 закончил работу над проектом. Но сегодня в половине случаев я бы поступил точно так же.

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