Дзен в деле автоматизации процессов

Эта статья была написана для корпоративного блога нашей компании, который планировалось запустить, но по определённым причинам этого так и не произошло. После некоторых размышлений я решил опубликовать текст лично от своего имени (а чего добру зря пропадать), поэтому из статьи изъяты любые упоминания названия нашего продукта и личные имена.

Сразу извиняемся за претенциозное название статьи, которое вдохновлено очерком знаменитого писателя Рэя Брэдбери «Дзен в искусстве написания книг». В первом абзаце своего труда писатель извиняется за вычурный заголовок, который, разумеется, сделан для привлечения внимания. Он честно признаётся, что позаимствовал его из недавно прочитанной книги «Дзен в искусстве стрельбы из лука». Но тут же Брэдбери заявляет, что модное словечко в заголовке не является исключительно рекламным трюком: «Потому что в конце, вы, может быть, поймёте, что я говорю вполне серьёзно». Мы тоже просим воспринимать название статьи не слишком серьёзно, но с учётом того, что в каждой шутке есть доля правды.

Конечно, наша небольшая команда — это не сборище просветлённых бритоголовых монахов. В религиозные предпочтения друг друга мы не лезем, как в любом адекватном коллективе. Так почему же мы используем именно слово «дзен» в отношении долгого процесса того, как мы совместными усилиями автоматизировали в посильной мере нашу работу? Потому что всё происходило в духе этого учения, известного своим принципом «здесь и сейчас»: не было никакого строго определённого плана, намеченных дедлайнов, сотен страниц технического задания, утомительных многочасовых совещаний — вообще, какой-либо формализованной системы, сопровождавшей нас на этом пути. Всё происходило само собой, вытекало из насущных потребностей и вызовов, которые в те или иные моменты нам предъявляла жизнь.

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

Итак, начнём с самого начала.

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

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

Этот начальный период работы команды был очень спокойным, предсказуемым, формализованным. И скучным. Над всеми процессами витал бюрократический дух, свойственный большим организациям (в первую очередь, госучреждениям), где каждый человек — это лишь винтик огромного механизма. Внешне казалось, что всех всё устраивает, и никаких позывов к тому, чтобы перекроить устоявшиеся формы работы, не было.

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

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

К счастью, оказалось, что у программистов ИТ-отдела имеется выраженная аллергия к использованию Google-таблиц где бы то ни было, и они хорошо поняли суть жалоб маркетологов. Было принято решение сделать небольшую подсистему, которая автоматизировала бы сопоставление лидов со звонками и облегчила работу отдела маркетинга.

Хотя специалиста по таким методам работы, как Agile и Scrum, у нас в команде не было (да и сейчас нет, поэтому мы допускаем, что всё, что мы тут рассказываем, может показаться посвящённым «изобретением велосипедов»), зато имелось принципиальное понимание преимуществ итеративной разработки продуктов. На совещании остановили выбор на схеме «одна итерация в неделю»: каждую среду маркетологи, разработчики и руководитель собирались в переговорке, смотрели результаты работы за неделю, высказывали замечания, поправки и пожелания, формулировались и ставились задачи на следующую неделю. Результаты совещания фиксировались в таск-менеджере. Короткая длина «спринта» (неделя) была оправдана тем, что и задача, в общем-то, была некрупной.

Минуло 4-5 итераций, и на свет появился вполне рабочий продукт, удовлетворяющий требованиям маркетологов. Программа, используя возможности API внешних сервисов — источников лидов (колл-трекинг, обратные звонки, генераторы лендингов и т. д.), ежедневно собирала все поступающие лиды. Точно так же по Google API из онлайн-таблиц «вытаскивались» данные обзвона клиентов. Вся информация сводилась в единую базу, попутно удалялись некорректные и дублирующие данные и проводился их предварительный анализ. Маркетологи были довольны возможностью сэкономить время. Чуть позже у них появилась идея импортировать в базу ещё и данные по рекламным кампаниям, чтобы также автоматически сопрягать эти данные с лидами и звонками. Ещё 3-4 итерации, и задача была решена: подсистема теперь могла сопоставлять финансовую информацию, связанную с рекламными кампаниями, с операционной деятельностью и на основе этого генерировать различные нужные отчёты — например, вычислять стоимость лидов из разных маркетинговых каналов и проводить их сравнение между собой.

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

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

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

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

Тут мы хотим отметить ещё одну достаточно интересную «мелочь», которая при ближайшем рассмотрении оборачивается вовсе и не мелочью. Дело в том, что примерно тогда же произошла смена корпоративного мессенджера с Pidgin на Slack. Знаем, что у протокола XMPP всё ещё остаётся много сторонников, которые доказывают его превосходство перед прочими проприетарными стандартами и продуктами, но в случае нашей команды отказ от него в пользу более удобного, функционального и — не побоимся этого слова — «классного» Slack оказал очень позитивное влияние. Конечно, и у Slack есть свои недостатки, но в целом он сразу пришёлся по нраву большинству членов команды и способствовал естественному перетеканию туда наиболее неформальной части рабочего процесса. Slack практически заместил собой для нас не только Pidgin, но и в известной мере таск-менеджер. Особенно востребованной оказалась лёгкость и простота создания рабочих групп по отдельным темам и вопросам в виде каналов, куда можно включить только причастных к вопросу людей — вплоть до обсуждения того, какой подарок организовать коллеге на день рождения тайком от него самого.

Количество, как известно, рано или поздно переходит в качество. Возросшая интенсивность общения внутри команды в какой-то момент привела ко всеобщему пониманию того, что для более эффективной работы всех отделов требуется целостная CRM-система, которая, с одной стороны, автоматизировала бы наиболее скучные, рутинные части работы людей, а с другой — позволила бы прозрачно связать изолированные друг от друга части бизнес-процессов в одно целое и повысить степень контроля над ними. Опыт работы над подсистемой для маркетологов дал понять, что при достаточных (и не слишком фантастических) усилиях это вполне реализуемая идея. Конечно, можно было бы пойти по наиболее очевидному пути — купить и внедрить какое-либо готовое решение. Но по определённым причинам такой вариант не рассматривался — в первую очередь, из-за осознания того, что найти по приемлемой для нас цене гибко настраиваемую CRM-систему, которая покрыла бы все наши (местами довольно специфические) требования к ней, будет сложно. Решено было создать собственную самописную CRM-систему (если кому-то интересны чисто технические особенности, то в этом отношении ничего необычного: связка LNMP — Linux + Nginx + MySQL + PHP, фреймворк Laravel 5, среди рабочих инструментов Git, Docker, Gulp и т. д.).

Работу начали с самой острой необходимости — автоматизации процесса работы телемаркетологов. Им давно уже смертельно надоела бесконечная круговерть процесса копирования-вставки телефонного номера из Google-таблиц в поле ввода клиента SIP-телефонии. А ведь ещё и нужно было вручную вносить в ту же таблицу пометки о результате разговора... Очевидно, эту часть работы можно было легко подвергнуть хотя бы частичной автоматизации, облегчая жизнь сотрудникам и получая значительный выигрыш в эффективности их работы. Бонусом шло исключение различных человеческих ошибок.

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

Замысел сработал. То, что первая вариация системы не выглядела слишком сложной и «навороченной» в глазах телемаркетологов — а им предстояло с ней активно работать каждый день, — её внешняя и функциональная схожесть с привычным интерфейсом Google-таблиц (с тем различием, что наша система изначально создавалась так, чтобы стать для них более удобной и снять большую часть рутинных действий), минимизировало трудности переходного периода. Заявления в духе «Дуров, верни стену!», если и звучали, то только в первые часы из-за естественного смущения перед новизной. Когда же сотрудники опробовали новую схему работы на деле, то для них стали очевидны её преимущества.

Конечно, мы не могли учесть всего. Оказалось, что система в своём первозданном виде игнорировала некоторые неочевидные особенности работы телемаркетологов. Пошла первая обратная связь, фиксируемая и поощряемая нами. Мы вернулись к знакомой итеративной схеме работы, раз в неделю (а иногда, в зависимости от условий, и чаще) выпуская новые версии системы с учётом поступающих замечаний. А таковых было действительно много. Не всё мы реализовали, но большинство предложений того периода в итоге успешно вошли в тот или иной релиз и стали весомым вкладом в то, какой конечный вид приняла система.

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

Одно из направлений развития было самоочевидным: раз уж мы отказались от Google-таблиц, с которыми взаимодействовала ранее разработанная подсистема для маркетологов, необходимо переориентировать последнюю так, чтобы она работала со вновь созданной CRM-системой, а ещё лучше — полностью интегрировать оба проекта. Работа началась практически сразу после окончания разработки первой версии, и вскоре обе системы слились в одну, взаимодополняя друг друга. По факту, первый прототип стал опорой для операционного модуля СRM-системы, а старая добрая подсистема для маркетологов — для аналитического.

Второй путь — интеграция с телефонией. Это предложение поступило от нашего ведущего телемаркетолога, в обязанности которого входил контроль над работой остальных телемаркетологов и, как следствие — необходимость регулярно прослушивать записи разговоров с клиентами. Раньше это делалось в личном кабинете нашего телефонного оператора, но теперь появилась возможность это дело упростить, встроив доступ к записям разговоров непосредственно в CRM-систему. К счастью, оказалось, что оператор предоставляет широкие возможности интеграции через API, и это было сделано спустя несколько релизов. Тем самым процесс работы ведущего телемаркетолога (да и в целом контроль над повседневной работой отдела телемаркетинга) был значительно оптимизирован. Ну а сегодня и вовсе все действия, связанные с обзвоном клиентов, протекают исключительно внутри CRM-системы.

Третье направление было самым непростым. Как подсказывает сама аббревиатура CRM (Customer Relationship Management — управление взаимоотношениями с покупателями), это в первую очередь система для выстраивания отношений с клиентами. Нам нужно было упорядочить базу наших клиентов, снабдить эту базу всеми необходимыми для работы параметрами, позволять вводить и выводить эти параметры в наиболее удобном для наших сотрудников виде. Тут можно было идти только опытным путём, в тесном контакте с каждым из членов команды, исходя из его реальных потребностей. В первые несколько месяцев постоянно добавлялись какие-то новые поля и характеристики, некоторые потом убирались или видоизменялись, если оказывалось, что это не то, что нужно. Конечно, была куча лишней работы, но в своей сути это всё было необходимо — в результате подобного «научного тыка» на основе эксплуатации на практике система постепенно приобретала выверенный вид, приспособленный для работы людей.

Напоследок хочется отметить ещё одну особенность развития системы. Из всех остальных она была самой необязательной и случайной, но нынче стала важной частью продукта. Всё началось с того, что одному телемаркетологу пришла идея отображать для коллеги — лидера дня по успешным звонкам иконку в виде жёлтой майки лидера. Идея была хорошо принята и быстро воплощена в жизнь. Это был первый росток целой системы достижений-«ачивок», которая постепенно усложнялась и становилась всё более весёлой. За это время каких только форматов ачивок у нас не было — и мемчики из интернета, и смешные фотографии участников команды, и персонажи всеми нами горячо любимого «Рика и Морти»... Сейчас мы решили совместить прикольное с познавательным, и в качестве ачивок используем флаги стран мира с забавными фактами о каждой стране (горячий привет незабвенному шоу «Флаги с Шелдоном Купером», вдохновившему нас на это). Пройдёт время, и мы заменим эту систему ещё на какой-нибудь интересный аналог, предложенный коллегами. Всё это тоже разрабатывалось по наитию, на основе случайных фраз и обсуждений «на кухне». Работа работой, но кто сказал, что в неё нельзя привнести частичку веселья?

В настоящий момент система, конечно, уже мало напоминает те «копии» Google-таблиц, с которых мы начинали. Она обросла функционалом, бесчисленными интеграциями со сторонними сервисами, нужными для работы (начиная с GMail и заканчивая amoCRM), в ней работают десятки человек с чётким разделением прав доступа по ролям. И почти ничего из этого не было запланировано заранее. Да, кое-какие возможности стоило бы вводить заранее, ещё на уровне проектирования — это нам сейчас понятно. Например, логирование действий пользователей в системе (абсолютно ведь необходимая вещь!) было введено, уже когда мы набили себе первые шишки. Система раннего выявления отказа какого-нибудь из многих API, с которыми взаимодействует система, тоже появилась чуть позже, чем следовало бы. Но главное, что все эти проблемы решались немедленно, как только команде становилась ясна необходимость в этом. Из относительно недавних случаев — оперативный переход от использования Google Maps на Яндекс-карты ввиду того, что Гугл в один прекрасный день резко увеличил стоимость использования своего сервиса карт. Мы посидели, посчитали, поняли, что к чему, и через пару дней дело было сделано.

В заключение хочется ещё раз обратить внимание читателя на то, что использование принципа «здесь и сейчас» предполагает некоторую избыточность как по времени выполнения работ по автоматизации процессов, так и в размере прилагаемых усилий. К примеру, код нашего проекта пережил несколько крупных рефакторингов в ходе разработки: многие модули переписывались чуть ли не с нуля, не говоря уже о более мелких переработках существующего кода, которые происходят практически непрерывно. Это неизбежное зло, когда развитие системы идёт небольшими спонтанными приростами, а не по чётко заданной колее, задаваемой заранее разработанным ТЗ. ИТ-отделу, входящему в команду, исповедующему такой принцип, придётся с этим примириться — если, конечно, они не хотят, чтобы код проекта со временем превратился в неудобочитаемую лапшу, навешанную на костыли.

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

Но это уже другая история.