Привет! Меня зовут Дмитрий. Я являюсь руководителем группы в IT‑компании. Если перевести на более доступный язык, то получится так: Team Lead Integration. Компания не самая крупная, но очень международная.

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

Статья полезна тем, кто работает на стыке тесного взаимодействия того, что часто называют бизнесом, и технических или около‑технических команд, для сотрудников разных уровней (от условных джунов до руководителей отделов (Head of sales и прочее)). Также может быть полезна и интересна тем, кто ощущает лёгкий ветерок хаоса в рабочих процессах. Тут нет глубокой аналитики, цифр на основе графиков, графиков на основе исследований учёных британского университета. Только здравый смысл, мои размышления на основе собственного опыта и некоторые рекомендации, что же с этим делать.

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

Начало

После того, как у вас сформировалось общественное мнение pro процессы, сразу же оговорюсь, что разговор будет про операционный уровень, не стратегический. И в первую очередь про отношение к формализации рабочих процессов. Про организацию, отладку, формализацию самих процессов расскажу как‑нибудь в другой раз. И статей, постов, материалов на эту тему вы, наверняка, читали‑смотрели множество: от скрам‑мастеров (они, кстати, куда‑то все как будто пропали. Заметили?), от аджайл‑коучей (про этих ребят тоже в последнее время не многое слышно), от умных людей (эти вообще редкость во все времена), от неумных людей (сами всё знаете), теоретиков и практиков. А я в этом списке — просто неравнодушный. И неравнодушие заключается в том, что в определённой степени я являюсь последователем и латентным амбассадором рабочих процессов среди коллег, которые работают со мной. Я таких называю душными, но уверен, что про меня так не думают, потому что тут другое. Вы закономерно и правильно считаете, что существует и диаметрально противоположное мнение и отношение к рабочим процессам, на разных языках и в разных частях необъятного мира, звучащее примерно буквально дословно так: «Дмитрий, давай зарабатывать деньги, а не тратить время на заполнение ваших задач».

Let's do business, как говорится. т. е. с одной стороны есть бизнес, который продаёт. С другой — IT‑команда, которая так или иначе создаёт сам объект продаж, условия для осуществления продаж и оказывает дальнейший сервис по поддержке и техническому сопровождению продукта. В какой‑то момент команды пересекаются для обмена запросами и результатами: бизнес озвучивает свои потребности и айтишники их реализуют, а также происходит корректировка уже имеющихся результатов. Оформляются эти пересечения, как правило, различного рода задачами в таск‑трекерах или CRM и могут быть организованы абсолютно по‑разному. Всё это можно обобщить термином «процессы». И у команд в рамках одной компании могут быть разные требования к тому, как они должны работать. Попробуйте просто по звонку в HR уйти в отпуск. Или в бухгалтерии запросить компенсацию командировочных расходов через ТГ. Или получить на складе условные бахилы посредством личного посещения. т. е. для достижения нужного результата нужно инициировать определённый процесс (задача, тикет, заявка) в условном таск‑трекере, который имеет формализованный вид. Моя команда — не исключение. Мы занимаемся обеспечением качества QA, а также — Integration (чтобы это ни значило сейчас). Для каждого вида наших работ есть определённые процессы, под которые создаются задачи в таск‑трекере. Итак, с одной стороны есть команды, с другой — потребности, с третьей — рабочие процессы, которые отражают прогресс достижения поставленных целей. Казалось бы: всё логично и просто. Так есть ли тут проблематика?

Проблематика

Мы, моя команда, много коммуницируем как с внутренними клиентами, так и внешними. С первыми и возникают «некоторые» противоречия. Потому что большая или даже основная часть рабочих взаимоотношений происходит именно с ними. Они продают высокотехнологичный продукт, который мы настраиваем и поддерживаем техническую составляющую в дальнейшем. И зачастую в представлении бизнеса взаимодействие должно выглядеть так: «Ребята, ловите контакты, это наш новый клиент. Займитесь‑разберитесь там с ним. Ну, вы же сами знаете, что делать. Всё, больше нет времени, я полетел дальше. Обнимаю крепко». Или так: «Ребята, у этого клиента какая‑то проблема возникла. Вот контакты. Созвонитесь там с ним»... Что‑что ещё раз? Погоди. Я не такой шустрый, поэтому пускай‑ка твой пегас‑икар пока подождёт. «Друг, инициируй процесс в цэрээмке, заполняй необходимые данные и вот это всё, и мы с нескрываемой радостью приступим к работе». И вот тут начинается про бизнес: «не мешай», » не отвлекай», «наше дорогое время» и т. п. Не всегда получается, но я стараюсь относиться к таким ситуациям как к обычной рабочей рутине (и вам, кстати, рекомендую. Вряд ли прям так сразу получится не принимать близко к сердцу чьи‑то попытки облегчить себе жизнь мягко говоря не за счёт себя). Ещё и внутри своей команды мониторить соблюдение договорённостей. И не потому что команда плохая, и не потому что саботаж, а просто банально потому что мы — люди. Тут старший по должности (хоть и старший в другом месте) решил, что может накинуть директив; там — в «личке» попросили и неудобно же коллеге отказывать, и чтобы отношение/впечатление хорошее сохранить/создать. Конечно, кто‑то может подумать, что я утрирую и гиперболизирую и что проблема надуманная. И это не является стопроцентной неправдой. Но попытки работать «с коленки» предпринимаются на регулярной основе.

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

Определение:
Давайте начнём разбираться с самого начала. Что же в целом такое процесс? Своими словами я бы описал так: это согласованный и утвержденный сторонами алгоритм действий. Это база. («Это база», если вы понимаете, о чём я). Чтобы объект из состояния А осуществил переход в состояние Б, нужно инициировать соответствующий процесс — формализованный алгоритм (так, к слову: и без формализации будет работать. С эффективностью только будут вопросы). Если вы хотите заказать еду (состояние А), то вам нужно: открыть приложение на вашем мобильном устройстве, найти нужное заведение общепита, выбрать продукты, указать способ доставки, адрес, ввести платёжные данные, подтвердить заказ, и на всякий случай быть на связи — мало ли что. Это вот процесс (заказа еды). Завершится процесс состоянием Б: успешной доставкой еды либо успешной отменой вашего заказа по какой‑то причине (в том числе, это может быть и ваша инициатива. Даже если курьер уже в пути.). Перед нами алгоритм действий, утвержденный и согласованный. Здесь можно было бы, конечно, подискутировать на тему согласованности и утверждения такого процесса — нас ведь не спрашивали нашего мнения. Но не буду: мир не справедлив, а демократия — самообман. Это такой один из самых простых примеров процесса, с которым знакомы многие. Другой похожий пример — аренда самоката, где тоже прописаны шаги, которые необходимо пройти прежде, чем вы встанете на тропу ненависти к себе со стороны прохожих. С рабочими процессами также: инициализация, какие‑то действия, изменение состояния. У нас это реализовано через постановку различного типа задач в таск‑трекере: менеджер выбирает нужный тип работы, заполняет необходимые данные, подтверждает кнопкой «Поставить» и остается на связи. Это так задумано. Но часто работает не так, как задумано. А задумано так: выбирается именно нужный тип работы, а не просто то, что попалось под руку; добавляются необходимые для работы данные: описывается проблема, прикладываются скрины, проверяется и актуализируется при необходимости контактная информация; в некоторых случаях — описание того, чтобы было сделано для предотвращения возникновения инцидента и/или подтверждение проблемы; отслеживается статус (состояние) задачи. А часто происходит так: «Ну, вы же требуете задачу. Вот вам задача». Качество на высоте, исполнение на высоте, контроль — отсутствует. И в этом ощущается некоторая доля легкомысленности (несерьёзности, на самом деле). «Нормально делай — нормально будет», — как говорит классик. И в качественном профессиональном подходе к формализации процессов скрывается много преимуществ. Давайте их и рассмотрим.

Бюрократия

Начну с вопросов (самому себе, разумеется): для чего же нужны процессы (подчеркиваю, что в данном контексте под процессом я имею ввиду его формализованную сторону — то есть для чего нужно ставить вот эти все задачи, писать там комментарии, отвечать на встречные вопросы и т. п.)? И возможно ли осуществлять рабочую деятельность без такого подхода с детальными описаниями алгоритма действий (без формализованных процессов)? Очевидно, что ответ на второй вопрос будет таким: конечно же, да. Формализация — это же, по сути, бюрократия, так ведь? (Вот это поворот!) А мы с вами (особенно, те, кто по‑старше) уж точно имеем чёткое отношение к данному явлению. Но не всё так однозначно. Да, это сложные речевые обороты, важность каждой запятой и словесная казуистика, работа ради работы. Хуже может быть только то, если вы сами всё это создаёте — придумываете и описываете правила игры. Давайте же поищем хоть что‑то положительное. Итак, возвращаемся: для чего же нужны процессы? Если кто‑то постарался и сделал многое правильно, то вот эта самая бюрократия позволит в какой‑то момент, вдохнув полной грудью, заявить: «Мяч на вашей стороне». Но это даже не совсем точно. Вы‑то в одной команде, поэтому мяч отдаёте не на другую сторону, а просто пасуете, получается. Цель одна, поле одно. Мяч тоже один на всех. И каждый отвечает за свой участок поля. Вот именно это и осуществляет бюрократия внутри ваших процессов — разграничивает ответственность. Поэтому отказ следования процессам — это попытка переложить ответственность (а мы не такие). Снять ответственность с себя. Размыть ее. И когда дойдёт до выяснения кто провалил какие‑то сроки, не ответил что‑то клиенту, не запросил что‑то у аналитиков, то коллеги с не сильно тяжёлым сердцем будут топить вас, и топить за свою идею, что «мы‑то, вообще‑то, занимаемся тут зарабатыванием денег так‑то, а вот это всё — вы же технари, мы думали, что вы сами там как‑то между собой разберётесь. А мы хлебушек».

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

История

Бюрократическую составляющую процессов я бы обозначил как ключевую (в моём мировоззрении) функцию процессов. Хотя её даже можно определить не как ключевую, а больше как всеобъемлющую, общую. Тем не менее, другая, не менее ключевая (но уже больше частная), может поместиться в ёмкую цитату‑тезис: «Народ, не знающий своего прошлого, не имеет будущего». Цитата сами знаете кого (если нет, то сами знаете, что делать в таком случае). В общем, я говорю про сохранение истории. Например, в нашем случае это вообще своеобразная летопись: когда проводились какие‑то работы, какие услуги оказывались, кто принимал участие, где взаимодействовали с другими задачами, департаментами, бизнес‑юнитами и т. д. Всё это в рамках одного клиента, например. Если ассоциация возникла про досье, то это не то, что вы подумали. Так вот вся эта информация хранится в таск‑трекере в форме задач. Электронный журнал‑дневник. Во многих случаях история помогает оперативнее решать возникающие технические проблемы, потому что можно отследить случались ли аналогичные инциденты ранее, сколько их было, когда, какую документацию отправляли и т. д. Любой таск‑трекер отлично справляется с этой работой: дедлайны, переписки, прикреплённые документы, сриншоты, текущие статусы, чек‑листы. Всё это хранится и готово быть представленным в любой момент.

Отчёты

А теперь представьте, что бюрократия и история могут сделать, если их объединить: они позволят собирать метрики. Те самые метрики, на основании которых можно строить отчётность, чёткую и прозрачную. Да, это больно в начале — знаю по себе и ещё больше не по себе. Но спокойствие в дальнейшем. Как с уплаченными налогами. Кручу‑верчу, но цифры‑то есть! Больше про эту часть говорить не вижу смысла: задачи разные, цели разные, метрики могут быть разные. Самое главное, что есть на основании чего их собирать. А как ими манипулировать — каждый сам разберётся.

Дополнительно

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

Инструменты, которые подойдут для целей налаживания процессов: практически любой таск‑трекер (Trello, Asana, даже у Яндекса что‑то есть (возможно, с доступом только по подписке)). Форма ведения: тоже любая под ваши потребности и в зависимости от выбранного инструмента: задачи, карточки, доски. Концепция организации процессов: тут может показаться немного сложнее (только если начать изучать все современные подходы и философии: скрам, аджайл и т. п.), для не слишком же сложных процессов можно обойти мимо и при необходимости прорабатывать, когда приходит понимание, что имеющиеся процессы не покрывают разнообразие целей и задач. У нас, например, используются YouTrack и кастомизированный Битрикс, в основе всех процессов — принципы Канбана, которые адаптированы под решение наших задач.

Что ещё?

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

Итог

Подводя итог, могу утверждать: сами по себе выстроенные процессы и следование им могут стать мощным незримым инструментом вашей работы. Принимайте их как часть рабочих обязанностей. Относитесь к ним с любовью. Отстаивайте их. Будьте профессионалами. И очень‑очень‑очень важный момент: не станьте их заложником. Процессы не должны быть ради процессов и не должны быть самоцелью. Отслеживайте, мониторьте, анализируйте и будьте гибкими. Будьте готовы как к революционным сдвигам, так и плавным трансформациям. Их призвание — устранить хаос. Обсуждайте с коллегами как внутри своих команд, так и со смежными группами, отделами, командами, ведь все преимущества настроенных рабочих процессов будут работать на обе стороны. Если у вас есть выстроенные процессы, то вы и так знаете и понимаете их пользу (наверняка).

Если же вы испытываете сомнения (под давлением извне) о необходимости сведения любых ваших процессов к минимуму, то дерзайте (на самом деле нет): объясняйте коллегам необходимость (на уровне must‑have) использования таск‑трекеров, необходимость разработки, внедрения, контроля и использования описанных алгоритмов‑протоколов действий. По сводкам учёных британского университета (что подтверждено эмперически), внедрение процессов повысит продуктивность и эффективность команды, а также улучшит микроклимат. Догма должна быть одна: процессы должны быть. А сами их правила — могут (почти 100% должны) быть гибким. В общем, такое моё мнение про процессы, про профессиональные процессы — не может быть никакого противопоставления: процессы или бизнес. Выстроенные процессы помогают достигать бизнес‑целей.

Бонус

Послесловие (но не послевкусие). Для ярых приверженцев антипроцессов могу порекомендовать одно место. Замечательное просто. Правда, я там не был. Но знаю наверняка, о чём говорю. Если вам никаким образом не подходит формализация процессов в работе, то направляйтесь в Индию. Да, именно. И даже если устраиваясь на работу вы увидите/услышите/узнаете что‑то про процессы, то не пугайтесь — это чужаки занесли этот вирус и он скоро пройдёт. Даже если внедряются процессы, то срок их жизни составляет примерно пару недель. Далее следует ремиссия (очищение). У меня в команде почти 3 года работал инженер в нашем офисе в пригороде Нью‑Дели (компания же международная), который покинул компанию около года назад. За это время уже второй раз оказывается в поиске работы. Причины обоих раз объясняет хаосом, творящимся на работе. И тем, что попытки настроить любые более‑менее адекватные процессы проваливаются. И я понимаю, о чём он говорит, потому что по своему опыту я хорошо представляю, какое количество сил требуется, чтобы во‑первых, что‑то настроить, а во‑вторых, сколько усидчивости, чтобы поддерживать достигнутые договорённости. И этот сотрудник уже дважды намекал, что не против бы вернуться.

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

Ваши успешные кейсы работы без процессов и неуспехи работы внутри процессов оставляйте в комментариях.