Дмитрий Гончаренко: Что мне нравится в интеграторах ПланФикса, так это то, что они разные. По возрасту, географии и интересам. По методологическому инструментарию и подходам к настройке ПланФикса. А еще — по темпераменту и стилю общения, что хорошо иллюстрирует сегодняшняя публикация в рубрике “Рассказ от первого лица”. Признаюсь, я долго чесал в затылке и думал, допустимо ли в корпоративном блоге использование некоторых из встречающихся в ней выражений, но в итоге решил, что из песни слов не выкинешь. Поэтому лексика и стилистика рассказа Сергея Улаева, руководителя компании AffContext, опубликованы без изменений 🙂

Сергей Улаев: Эта история должна начинаться вот с такой картинки:

Она поистине отражает всю ту боль, что была у клиента, когда он обратился к нам. Причем на момент обращения клиент сам смог уже настроить себе ПланФикс, чтобы работало «как-то», и даже на довольно хорошем техническом уровне. Но масштабируемостью и удобством работы там и не пахло. Похоже, поэтому и хотелось создавать задачи с такими названиями.

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

Этот проект – совсем нетиповой для нас, т.к. мы больше специализируемся на производственной тематике, но это лишь в очередной раз показывает, что с нужными знаниями ПланФикс может стать «конфеткой» для любого бизнеса. А здесь примечателен тот факт, что ПланФикс – лишь одна из систем, которая обрабатывает информацию. Это случай, когда связка нескольких систем делает все бизнес-процессы компании более удобными и прозрачными для работы. И ПланФикс в этой связке занимает центральное положение.

Сразу хочется отметить отличное участие в проекте другого официального партнёра и интегратора ПланФикса – Андрея Лежнина. При взаимодействии с нами он придумывал очень лаконичные решения по ходу реализации проекта. И мы никак не скрываем факт того, что сотрудничаем с другими интеграторами, т.к. мы за результат. Клиент доверяет нам – и это самое главное. А уж какими силами мы всё сделаем и кого будем привлекать – уже наша забота. И мы лишь рады, когда попадается такой проект, где можно задействовать кого-то ещё. Это же совсем другой опыт, масштаб и конечный результат для нас всех. В общем, Андрею спасибо.

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

С одной стороны это позволяет показывать результат очень быстро, т.к. не надо прописывать ТЗ, которое на момент утверждения уже неактуально. С другой – эмоциональный стресс от непонимания того, что надо делать. Поэтому с клиентом сразу была утверждена большая почасовая работа на пару месяцев вперёд, чтобы мы не ТЗ писали, а работу работали. И все остались этим довольны.

Всё же если попытаться выделить самые основные блоки работ, что были проделаны, то это:

• Внедрение планировщика дел для руководителя и коллектива
• Прибраться в системе и поудалять ненужный треш
• Сделать интеграцию с другими сервисами по обмену информацией
• Унифицировать настройки системы так, чтобы можно было подключать новые проекты (проекты клиента, которые он продюссирует) без создания копий процессов и сценариев.

Пожалуй, на эти 4 раздела всю статью и разобьём. И сделаем это, как делают все супермаркеты – хлеб размещают в самом конце, чтобы люди прошли весь магазин 🙂 Вот и мы самый смак оставим напоследок, чтобы дочитали. Но будет интересно – это точно.

1. Внедрение планировщика дел для руководителя и коллектива

Сделать планировщик личных дел – та ещё задача. Я сам не пришёл к своей идеальной модели и переделывал её уже раз 5 для себя, а когда такое хочет клиент – тут вообще проще повеситься. Особенно если это сопровождается фразами «Я тут у одних ребят скрам модель подсмотрел. Давай так же сделаем».

С горем пополам мы отказались от идеи скрам модели и решили начать с малого – просто завести в систему список актуальных задач, без приоритетов, без сроков. Просто список – но всегда актуальный! А потом уже со временем на это будут навешиваться приоритеты и прочие плюшки. Только так можно понять, что сам человек понимает под задачей. Будет ли действие «позвонить Коле» для него задачей или нет.

После разговора клиент сделал нам список своих текущих задач:

И это лишь задачи руководителя. А есть ещё пачки поручений рядовым сотрудникам (по большей части одной помощнице, но суть не меняется). И проблема №1, которую вам надо знать, какой бы вы органайзер задач ни делали – это что полный список задач не существовал нигде.

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

Поэтому первое, что нужно сделать – это ввести дисциплину фиксации просто задачи. Хотя бы просто факта её существования с понятным названием. Потому что нужно знать, что задача существует. Неважно с каким приоритетом, датами и всем прочим. Существует – и уже хорошо!
Ибо то, что «на словах» – не существует.

В итоге начали с супер-простого планировщика, где можно фиксировать задачи. На минимальной категоризации (манимейкинг / система) клиент настоял, поэтому сделали:

Тут влезло не всё в ширину, но да и не надо. Главное, что на этой картинке есть календарь – это первое, что почему-то люди хотят видеть в своем органайзере задач. А потом оказывается, что с датами-то никто не привык работать. Ну вот не привыкли. В жизни ещё не встретили ни одного руководителя, который бы в планировщике дел задачи делал по датам и как-то на это ориентировался. Всегда даты заменяются приоритетами в стиле «срочно и 5-ая точка уже горит», «почти срочно» и «прочая хрень».

Поэтому не прошло и несколько дней, как календарь был успешно удалён и больше его никто не видел. Вместо него сделали столбец с критерием «ближайший приоритет». Так себе решение, но это был плавный уход от сроков вообще:

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

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

— Ты прямо как сенсей говоришь 🙂 Ну ок, верю

В конце концов личный планировщик руководителя сильно преобразился, ушла какая-либо категоризация задач (что и ожидалось), всё свелось к удобным фильтрам по задачам. Приведу скриншот, описывать его не буду, названия столбиков можете разглядеть на увеличенной по клику картинке. Ибо не всем это может быть интересно:

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

Он прост, очень прост. Но вы бы знали, с каким «боем» в коллективе принимается даже такая простота. Но истину мы отвоевали – все работают теперь в нём.

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

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

Мы порадовались…и пошли запивать эту «радость» безалкогольным пивом с сыром-косичкой. Потому что мы этот отчет сделали за пару часов и не придавали ему значение. Зато чего сделали по технической начинке за месяц!! А лучшей работой…оказался…просто отчет. Состояние было примерно таким:

Но так бывает, лишь бы клиент был доволен работой. Мы-то для себя понимали, что «технический фарш» просто не виден клиенту, но он тоже очень крутой.

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

2. Прибраться в системе и поудалять ненужный треш

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

То, что часть задач тут выполнена, не означает, что со всем этим вообще работали. Нет. Не работали. Про задачи забывали (а может и забИвали на них) или закрывали без особого смысла.

И это я молчу про количество ненужных проектов в системе. Но в итоге всё стало красиво и лаконично, а-ля вот такие фильтры задач в списке слева:

Или же в выпадающем меню вверху:

Где внутри каждого меню целый ворох нужных для человека задач:

Понимаю, звучит красиво, а что именно было сделано? Тут больше была работа по дисциплине и введению правила «делайте как можно меньше подзадач. В идеале – без них. Потому что дисциплины работы по задачам сейчас нет вообще никакой. И любая подзадача ломает мозг как постановщику, так и исполнителю». Так же был сделан такой интерфейс, чтобы можно было быстро создавать задачу в нужном проекте (коих мы урезали на порядок), а не где удобнее и быстрее, лишь бы создать.

В какой-то момент по этой работе мы добираемся до того, чтобы почистить в системе все ненужные сущности. И делаем «слепок» всего того, что было. А было такое:

Да, вам не показалось, там было к тому моменту 164 кастомных поля и 633 сценария задач. Треш ещё тот.

К слову, именно на этом проекте мы узнали, что можно достигнуть некоего технического лимита по удаляемым объектам. У нас просто в какой-то момент перестали создаваться новые сущности, не по лимитам системы, а просто перестали. Аж пришлось привлекать техподдержку ПланФикса для глубокой очистки ненужных данных этого аккаунта, т.к. для них это тоже был первый такой случай. Не каждый день они встречают проекты с таким набором всего подряд по настройкам (это были безуспешные попытки клиента настроить всё самому). Техподдержка отработала, как обычно, оперативно. 1-2 дня и проблема была решена.

Из нерешенных проблем по сущностям системы в итоге осталась лишь одна – быстро забивается файловое хранилище. Потому что сделана интеграция с VK (общение с клиентами идет только через этот канал) и при создании задачи сейчас внутрь попадают абсолютно все файлы, отправленные когда-либо клиенту в VK. В одной новой задаче там может быть файлов метров на 50. А для данного проекта это вообще не нужно. Сделал рассылку по клиентской базе, кто-то отреагировал, создались задачи – и хранилище забито на пару гигов 🙁

Ребята из ПланФикса уже в курсе этой проблемы и пообещали придумать решение. Уверен – придумают. Пока что очистку приходится делать вручную через опцию «удалить все файлы, прикрепленные до даты …»

3. Сделать интеграцию с другими сервисами по обмену информацией

Вооо, мы подошли к самому интересному. Как я уже говорил, на этом проекте ПланФикс выступал в роли базы данных, куда со всех прочих систем попадала информация. В двустороннем порядке – т.е. ПланФикс тоже отдавал в эти системы информацию. Весь обмен происходил через POST-запросы.

Когда мы пришли на проект, архитектура взаимодействия систем была такой:

И это мы сами её сделали, т.к. нас «завели» в проект и сказали «ну, давайте быстро пробежимся по этажам, я вам всё покажу. А дальше вы уже сами». И потом сидишь, «склеиваешь» всё увиденное в одну схему.

Следующая схема уже содержит блок «Microsoft Flow» (наш любимчик), который впоследствии должен стать той «стеной», которая принимает все запросы от систем, анализирует их и если всё хорошо, отправляет в ПланФикс. И наоборот – ПланФикс сначала все запросы шлёт сначала во Flow и уже затем они идут дальше.

Зачем отправлять все запросы через Flow?
Вообще, это даёт следующие преимущества (о каждом ниже будет описание):

• Можно сделать логирование ошибок
• Можно видеть внутрянку всех запросов и их внутреннюю обработку по шага
• Можно параллельно обрабатывать все входящие запросы от разных систем

MSFlow – это некий аналог внешнего сервера, который может поднять вам ваш разработчик. Тоже напишет свой код, тоже будет работать. Только прозрачности работы этого «черного ящика» (внешнего сервера) – почти ноль (если вы не сисадмин в колючем свитере). А у нас была задача сделать прозрачный обмен информацией меж систем, чтобы если где-то что-то отвалилось, это можно было найти самому руководителю.

Давайте ниже кратко пробегусь по описанным выше преимуществам:

MSFlow – Логирование ошибок

На картинке выше под блоком «MsFlow» можно увидеть красную надпись у стрелки – «Коды 01, 02». Т.к. мы знаем, как должны выглядеть корректные данные на входе, то при получении некорректных данных от систем мы сообщаем об этом в специальную (никогда не удаляемую) задачу в ПланФиксе. Выглядит там это так:

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

MSFlow – можно видеть внутрянку всех запросов

Да тут даже писать не надо, всё покажут скриншоты. Нужно лишь в интерфейсе системы найти нужный вам поток, например, этот:

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

Далее нужно снова кликнуть на нужную отработку:

Вуаля – и вы видите все шаги потока:

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

Ну всё, хватит картинок про MSFow в блоге ПланФикса. Но остался ещё один текстовый момент.

MSFlow – Параллельная отработка всех запросов

Уж не знаю, может это и не такой крутой плюс, но это же продукт от Microsoft – мы можем слать во Flow сотни (а может и тысячи) запросов и все они будут отработаны параллельно. Проблем с задержек выполнения у нас не было. Были проблемы с временем отработки потока (неоптимизированный изначально код), были проблемы с отправкой запросов из ПланФикса (слишком много слали), но с очерёдностью выполнения внутри MSFlow – никогда.

На этом можно закончить оду в честь этого сервиса и дальше продолжить писать про прекрасы ПланФикса 🙂

Чтобы у вас не было ощущения, что всё внутри проекта было гладко и красиво, приведу картинку внутренних сценариев одного из сервисов, с которым мы «цеплялись» – GetCourse. Мы с этим сценарием не пересекались, т.к. он был внутренний (не слал ничего наружу), но при его виде я почувствовал шевеления волос на голове:

Ужаснулись? Вот и мы порадовались тому, что тут ничего наружу не отдаётся, иначе «черт ногу сломит» как потом искать ошибку, если вдруг пришли некорректные данные.

К чему тогда картинка?
К тому, что ПланФикс был выбран как система сбора данных для достаточно серьёзного проекта. Примерно такие схемы были и других сервисах, где была реализована довольно сложная логика коммуникации с клиентом. Это доверие клиента к системе. И оно было оправданным. Вдруг вы сейчас читаете и думаете, что ПланФикс – это простой органайзер задач. Да хренос два, вон какие серьёзные ребята выбирают этот продукт и остаются потом довольны.

В завершение этого пункта покажу финальную версию схему. Текста убрали (т.к. уже некуда было, но они есть у нас сбоку, как легенда). Прямо микросхема какая-то 🙂 :

Унифицировать настройки системы

А вот это самая сложная задача была. Надеюсь, команда ПланФикса не добавит нас в список «интеграторы, уменьшающие доход системы», потому что мы придумали решение, которое позволило не переходить на следующий тариф и сделать систему для клиента очень масштабируемой и управляемой. Хотя если вы читаете этот текст – то всё хорошо 🙂

Постараюсь объяснить «на пальцах» суть. Вот видите эту пачку сценариев?

Они все делают одно и то же – меняют статус в зависимости от приходящего извне значения. Увы, в ПланФиксе нельзя делать условие «Если-То» в сценарии, поэтому приходится вот так извращаться. Но это дико неудобно. Поэтому задача № 1 была такая – превратить эти все сценарии в один, реализовав логику «Если-То» снаружи (через MSFlow).

Но это одна беда. А другая – это то, что на каждый проект был свой процесс со своими сценариями. И сценарии были абсолютно похожи, лишь подставлялись разные значения в нужные поля (исполнителей и пр). И если с 2-3мя проектами это можно было терпеть (и каждое изменение в логике обработки дублировать во все процессы и сценарии), то на 10 проектах это станет очень большой проблемой. Фактор человеческой ошибки будет стоять на первом месте и в какой-нибудь момент всё сломается и будет потеряно много клиентских денег. Поэтому надо было сделать так, чтобы всееееее проекты работали по одному процессу, но так как надо (с подставлением нужных значений в нужные поля). Тогда при изменении общей логики работы это надо будет поменять лишь в одном месте и сразу применится ко всем проектам. А ещё это очень удобно – чем меньше настроек внутри ПланФикса, тем проще этим управлять.

Я не буду технически здесь описывать, как мы это сделали (можете задать вопрос комментарием и я это опишу там, чтобы не дать сейчас читателю заскучать). Скажу лишь, что результат был достигнут. Конечно же, через MsFlow. Мы утащили обработку логики всех действий наружу во Flow, чтобы он уже потом приходил в ПланФикс и делал нужные действия. В итоге мы добились нужного – все проекты теперь работают по одному процессу. И вносить какие-либо изменения стало проще. С другой стороны – это надо делать теперь осторожнее, т.к. сразу затрагивает все проекты, но теперь системе без разницы – подключен 1 проект или 50.

Хотя…разница есть лишь в количестве запросов, которые ПланФикс по такой модели отправляет наружу. Но и тут команда системы показала свою клиентоориентированность. Потому что в какой-то день мы сгенерировали 6 000 запросов из ПланФикса наружу и попали в ситуацию, что наши запросы «встали» в очередь и могли ждать своего выполнения более 24 часов!!

Просто почитайте эту грустную переписку с ТП системы:

А потом оказалось, что проблема была в другом (похоже, мы случайно под нагрузкой ткнули в слабое место системы), и знаете, что они сделали?? Просто переписали за пару дней код!! И всё заработало без перебоев. Без дополнительных денег, регистраций и смс 🙂

WTF? А так люди могут делать?
Знаете, тут недавно в Москве была первая конференция интеграторов ПланФикса, куда приезжал и сам Дмитрий Гончаренко. Так вот в закулисной беседе я прямо спросил: «Дмитрий, ну мы же явно писали – вы можете придумать новую тарифную сетку для таких клиентов, кто хочет слать так много и часто запросов. А вы взяли и переписали код, теперь всё работает для всех и за те же деньги».

И знаете, что ответил Дмитрий? О, у меня даже фото есть, которое кто-то делал +- в момент этого вопроса…сейчас…найду его….вот..это я и Дмитрий Гончаренко:

Дмитрий, ну это лучшая фото того момента, уж какой ракурс получился 🙂

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

100% за словесность не ручаюсь, Дмитрий может добавить свой комментарий в этом месте статьи. Но суть была такая. И после такого ответа моё уважение ко всей команде сервиса выросло ещё выше. Думал, выше уже некуда. А не – есть куда. И то ли ещё будет. В общем – красавцы!

Пожалуй, это всё по истории. Хоть тут далеко не вся информация, которую можно было бы выложить. Например, в процессе работы было реализовано 2 очень диковинных функционала для работы коллектива. Но давайте я их просто перечислю списком, а в комментарии вы можете уточнить детали реализации по любому из пунктов. Так будет всем удобнее. Итак:

1. Быстрые ответы клиенту (с возможностью отправки сразу нужного файла) – достаточно в списке выбрать нужный вариант названия ответа. Можно и отредактировать шаблонный ответ перед отправкой. Видео-демонстрацию можно посмотреть здесь.
2. Логика определения участия менеджера в продаже. Представьте, что оплата должна идти в учет менеджера, если он сделал 5 касаний с клиентом, провёл сделку минимум через 3 статуса и это всё не может быть быстрее 30 минут. Все условия должны соблюдаться.

И вот тут должен был быть конец статьи, но после её прочтения (утверждения ради) клиент сказал, что можно вставить некоторые его комментарии о проекте. Я не нашёл никакого другого места, как здесь, чтобы уже не ломать общую структуру описанного выше текста. Итак, комментарии клиента, тут кратко:

---

Статья норм. Если интересны комменты по самой статье, с точки зрения сильных сторон я бы сделал акцент на:

1) Кол-во проектов. Мол круто, когда проект один. А если их дохера? Вот с этим пришел клиент, т.к просто зае…ся жить.
2) Самое важное – это инновация в плане CRM для соц. сетей. Что ПланФикс – это крутой инструмент продаж и т.д. Что это инновация, которую сделали ваще с нуля, таких решений нет на рынке.
3) Я бы разделил отдельно задачи по продакшну и по продажам, т.к это 2 разные темы. Но болят они одинаково сильно)
4) Я бы сказал о том, что систему строили с заделом под то, что потом можно масштабировать ( СУ: хотя в статье это написано, но ок, пусть будет напоминанием)
5) Я бы показал кол-во инструкций, которые ты записывал. Портал мб. Их там дохренища))) (СУ: да, инструкции мы писали, но это могу раскрыть в комментариях, если будут на то запросы)

---

Если что-то непонятно – можно продолжить общение в комментариях, а то у вас уже точно кофе кончился или остыл, пока вы это читали.

Теперь точно всё. Спасибо!

Сергей Улаев

---

Дмитрий Гончаренко: И небольшой традиционный постскриптум от меня. Мы с удовольствием опубликуем рассказы о внедрениях ПланФикса и интересных решениях, которые были найдены и реализованы с его помощью. Для того, чтобы попасть в рубрику Рассказ от первого лица, не обязательно быть партнером или профессионально заниматься интеграцией — просто поделитесь своим опытом использования ПланФикса, и вы найдете здесь множество благодарных читателей.

Свои расказы отправляйте в Службу поддержки с темой “Рассказ от первого лица”. Я подключусь и мы все согласуем.