Прозрачность процессов как инструмент эффективного взаимодействия

Всем привет! Меня зовут Анастасия Исаева, я из Газпромбанк.Тех. На текущий момент являюсь одним из HOP QA, но довольно долго была просто тестлидом. Поэтому много мыслей в этой статье использованы ещё с того периода времени.

В этой статье я хочу рассказать, что такое прозрачность процесса. Зачем она нужна команде и как тимлид может объяснить, зачем вводит в процессы атрибуты прозрачности — диаграммы, метрики, инструментарий и прочее.

Что такое прозрачность процесса

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

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

• Постоянный контроль

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

• Бесконечные диаграммы и метрики

Менеджеры вводят новые метрики, но не объясняют зачем. В итоге получаются метрики ради метрик.

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

• Доступ «непосвящённых» к информации

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

В Википедии есть другое определение прозрачности:

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

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

Зачем команде прозрачность

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

1. Управление ожиданиями

Когда процессы не идеальные, люди прибегают со срочными задачами, которые нужно было выполнить ещё вчера. Возникают конфликты и вопросы, почему задачу не сделали раньше.

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

Чтобы уйти от этого бесконечного цикла, мы проработали несколько пунктов.

• Ввели понятные «правила игры»

Все задачи делались строго через Jira. При постановке нужно было понятно описать, что делать, а также указать стенд и дедлайн по задаче. Задачи были типовыми, поэтому мы определили понятные SLA, которые мы были в состоянии выдерживать.

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

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

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

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

Это правило можно применять не только к типовым задачам, но и, например, сделать прописанные критерии definition of ready для включения задач в спринт/релиз. Чтобы они тоже стали «правилом игры», понятным всем. Это также поможет сделать процесс более прозрачным и эффективным.

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

• Известные графики вывода доработок, даты спринтов

По факту этот пункт — продолжение предыдущего, но я выделила его отдельно.

На одной из конференций, где я присутствовала, докладчик спросил зал, у кого есть релиз. Большая часть слушателей подняли руки, потому что не все релизятся on-demand. На вопрос, у кого есть график релизов, руки подняли уже половина людей в зале. Но, когда спикер спросил кто знает, когда у вас следующий релиз, руки подняли буквально пять человек.

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

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

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

• Открытый список проверок

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

• Оповещение о недоступности или ранее выявленных проблемах

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

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

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

Если вы на ранних этапах выявляете проблему или что-то сломалось в моменте — оповестите об этом заинтересованных лиц.

Конечно, это не панацея. Всё равно найдутся люди, которые пропустили объявление и начнут что-то тестировать, когда идёт обновление.

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

2. Снижение доли микроменеджмента

• Наличие дашбордов и тестовых прогонов с актуальными статусами
• Ответственность и контроль каждого участника команды за актуальностью информации

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

Вся команда должна ответственно подходить к актуальным статусам. Если не соблюдать правила, всё пойдёт в мусорку и придётся заново всё выстраивать.

Если есть дашборды, показывающие статус задач, нам не нужно превращать daily в статусные встречи. Это помогает команде. Можно проводить их меньше, чем за 15 минут: уточнять только те проблемы, которые мешают достичь цели. Кому надо, сам посмотрит статус на доске или спросит у коллеги. Главное, чтобы информация была актуальна. Неактуальные задачи лид сразу увидит и снимет, чтобы избавиться от лишней работы.

Доску необязательно размещать в Jira или использовать другие недоступные сегодня инструменты. Можно взять даже простой Excel. Мы работали в Kanban с Excel-файлом со списком бэклог задач в общем доступе. По факту, мы брали задачу, переводили её снизу вверх и меняли статус. Так мы сразу видели, кто что делает, могли сами брать то, что больше интересно. А тимлид видел, что происходит, кто свободен и сможет выполнить срочную задачу, если она, вдруг появилась.

• Декомпозирование задач

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

Если есть большая задача, заказчики не понимают, что под ней происходит. У нас был кейс, когда одному из сотрудников дали задачу протестировать *название проекта*. При этом проект за несколько месяцев значительно вырос. Полностью протестировать проект под одной задачей не представлялось возможным. В итоге сотрудник бегал как белка в колесе, делал все возможные задачи, не понимая, где приоритет. Жары в огонь добавляли разные подзадачки от заказчиков, нигде не отражённые. В итоге все считали, что человек не справляется, при том, что он делал гигантскую работу.

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

• Своевременное заведение дефектов и ответственность за их жизненный цикл

Важно своевременно подсвечивать возникающие проблемы — нет дефекта, нет проблем. Если вы не можете сделать задачу и не обозначаете это — проблема остаётся вашей.

Ещё здесь важна ответственность за жизненный цикл. Бывают кейсы, когда человек заводит дефект и дальше вообще не следит за ним. У меня был случай, когда человек завёл блокирующий дефект в пятницу перед релизом и ушёл с работы, а мы сидели с оставшейся командой и решали, что делать с дефектом.

Наша общая задача — выпустить качественный продукт. Важно доносить это всем в команде.

3. Уменьшение количества «Брентов» в команде и компании

В книжке «Проект Феникс» есть персонаж — Брент. Я его запомнила, потому что он похож на одного из наших разработчиков. Наш Брент — человек-оркестр, всезнающий, умеющий выполнять все процессы. На нём завязано всё, но это создает узкое горлышко. Мы не можем выполнить без него определённую задачу. Если команда большая, таких людей бывает несколько. В офисе к ним выстраивалась живая очередь из тех, кто хотел что-то спросить, на удалёнке у них виртуальная очередь.

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

Чтобы уменьшить количество людей, на которых всё сконцентрировано, нужно:

• Иметь понятную документацию, тест-кейсы, инструкции

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

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

• Проведение Демо по новой функциональности и новым процессам внутри команды и/или смежных команд

Необязательно делать часовые Демо каждую неделю. Достаточно 5-10-минутных Демо раз в месяц на общих инженерных встречах. Цель — показать, что поменялось. Может, изменился процесс или появилась новая функциональность, важная не только вашей команде, но и смежным. Проведение такого Демо расширяет экспертизу. Оно не завязывается на конкретном человеке или команде, а идёт вширь. При большой повторяющейся функциональности, можно сделать обучение для людей. Таким образом мы расширяем узкое горлышко и не упираемся в него.

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

4. Сбор метрик, помогающих улучшить процесс

Не все любят метрики и диаграммы, важно подумать:

• Кому нужны метрики?
• Почему метрики нужны, в том числе команде?

Смотрите на это через призму того, как их применить для своей команды.

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

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

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

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

Заключение

Прозрачность нужна команде, а не только лицам, принимающим решения.

• Через управление ожиданиями команда может снизить избыточную нагрузку.
• При снижении доли микроменеджмента люди могут брать себе более интересные задачи, плюс, просто снизится давление, которое на них оказывается.
• При устранении узких горлышек, расширяется масштаб того, что мы внедряем, а люди могут передавать не интересную для них работу и брать что-то новое.
• Сбор метрик, можно применить везде и посмотреть, оценить проблемы, если они есть. Через метрики можно выявить, что у вас происходит.

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

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