Качество социальных отношений в ИТ-команде
Все мы стараемся сделать качественный сервис и хотим гордиться своим проектом. И для этого прибегаем к техническим решениям: автотестам на разных уровнях, оценке покрытия, сбору и анализу метрик. Это отличные активности, которые помогают проекту стать лучше.
Но помимо hard-инструментов есть и soft-составляющая. Она не столь очевидна, но тоже помогает повысить качество сервиса. Меня зовут Николай Котов, я старший QA-инженер в Тинькофф и сегодня расскажу, как социальные связи влияют на качество проекта, и поделюсь советами по укреплению этих связей.
Забота об атмосфере в команде в большей степени лежит на тимлиде или продакт-менеджере, но работать над ее улучшением могут все. Если вам интересна эта тема, предлагаю вместе в ней разобраться.
Дисклеймер
Это не технический текст, он про софт-скиллы.
Что такое социальные отношения и какими они бывают
Социальные отношения — это взаимосвязи, которые возникают между людьми в ходе социального или профессионального взаимодействия. Существует несколько классов общественных отношений: национальные, межличностные и другие. В этой статье важен класс групповых отношений, то есть отношений между группами сотрудников.
Делить команду на группы можно по разным признакам. Например, профессиональные группы: разработчики, QA-инженеры, DevOps и другие. Или по классам выполняемых задач: фичи, баги, помощь пользователям, технические задачи.
Если говорить о верхнеуровневом разделении по признаку рабочей стороны, на мой взгляд, можно выделить три основные группы:
Заказчик или бизнес-сторона.
ИТ-команда.
Конечный пользователь.
Треугольник «заказчик — команда — пользователь» — основополагающий для многих проектов (не путать с драматическим треугольником Карпмана).
С точки зрения ИТ-команды в этой пирамиде можно выделить очевидные связи:
Команда — заказчик.
Команда — конечный пользователь.
И более низкоуровневые:
Внутрикомандные отношения.
Нарушение любой из этих связей приводит к ухудшению качества продукта. Мы разберем, как это происходит и что можно сделать, чтобы эти связи укрепить.
В компаниях социальные взаимосвязи определяют скорость и качество передачи информации, влияют на скорость принятия решений и их качество. Они словно нервные волокна организма, передающие сигналы от органов к мозгу (здесь можно вспомнить концепцию «Мир тесен» или теорию сильных и слабых связей Грановеттера). ИТ-компании — не исключение.
Отличие в том, что в ИТ-команде может не быть четкой вертикальной структуры и решения, которые принимаются на уровне команды, могут не требовать дополнительного согласования с руководством.
Если вы хотите повысить качество продукта через социальные отношения, начать стоит с выявления имеющихся проблем. Вот что поможет это сделать.
Анализ различных метрик:
— Lead Time;
— Jira Control Chart;
— количество ошибок на продовом и тестовом контурах;
— время нахождения задач в буферных статусах. Если там зависают задачи, убедитесь, что не нарушены связи между профессиональными группами, отвечающими за разные этапы.
Анализ метрик помогает отбросить эмоции и подсвечивает узкие места в процессах.
Ретроспектива — встреча для анализа проделанной работы. Хорошо, если на таких встречах команда открыто говорит о проблемах в социальных связях. Например, «бизнес-линия не участвует в развитии проекта», «ИТ-команда не понимает стратегии развития проекта и конечную цель» — это проблемы в социальной связи «команда — заказчик». А «никто из команды не знает, какие тест-кейсы пройдены по задаче Х и что проверяли» — нарушение социальной связи между двумя профессиональными группами внутри команды. Фиксируйте такие проблемы и берите в работу.
Следите за тем, как участники команды принимают совместные решения. Если по некоторым вопросам возникают споры со взаимными обвинениями, которые переходят в личные конфликты, это повод задуматься.
Не все ретроспективы бывают эффективными. Иногда несколько человек рассказывают о проблемах и болях, а остальные молчат и занимаются своими делами. Чтобы вовлечь команду в процесс, попробуйте ретро в игровой форме с помощью доски Miro или Notion.
Встречи one-to-one, на которых можно поговорить обо всем, что важно для конкретного сотрудника. Например, дать обратную связь, обсудить изменения в компании, команде или процессах.
Личные встречи помогают выстраивать доверительные отношения. Не стесняйтесь напрямую спрашивать, как сотрудник оценивает отношения в команде и с какими проблемами сталкивается.
Анонимные опросы для сбора обратной связи. Некоторым людям сложно открыто говорить о проблемах, и этот способ помогает узнать, что они думают. Сделайте опрос в свободном формате. Спросите, есть ли проблемы в личных взаимоотношениях или между профессиональными группами. Например, «Как ты считаешь, достаточно ли бизнес-сторона участвует в жизни проекта?» или «Обмениваетесь ли вы best practices в команде?».
Не забывайте о возможных рисках. Коллеги могут заполнить опрос спустя рукава, не придав ему значения или попросту забыв про него. В таком случае не забудьте напомнить им о важности опроса.
Используйте эти способы по одному или комбинируйте. Ретроспектива и встречи one-to-one дают быстрый результат, но если сотрудники стесняются или не хотят говорить (например, команда сформирована недавно), есть риск пропустить некоторые проблемы. На анализ метрик или анонимный опрос может уйти больше времени, но они помогут выявить скрытые социальные проблемы, о которых не хочется говорить вслух.
В январе 2022 года я проводил встречи one-to-one в своей команде и спрашивал о проблемах, которые могли заметить сотрудники. Несколько разработчиков пожаловались, что молодые коллеги на дейли-встречах не озвучивают свои технические проблемы и трудности, а приходят в личные чаты. Анонимный опрос показал, что четверо разработчиков стесняются говорить о сложностях на всю команду. Они предпочитают выдергивать конкретного коллегу из потока задач, увеличивая время решения проблемы.
Пример анонимного опроса
Мы провели небольшую презентацию и рассказали, зачем нужны дейли-встречи и почему лучше рассказывать о сложностях именно там. В течение недели проблема исчезла — теперь никто не стесняется обсуждать проблемы с коллегами.
Комбинируйте активности по поиску проблем и выявите наиболее приоритетные: те, о которых чаще и громче говорят, те, которые увеличивают время доставки задач на прод. Приоритезируйте сложности и занимайтесь ими в порядке очереди.
Команда — вершина треугольника
Представьте, что на проекте есть два QA-инженера, которые не нашли общий язык. Они не устраивают разборок, но и не общаются друг с другом. Нарушение этой социальной связи приведет к проектным потерям из-за того, что сотрудники не обмениваются опытом о возможных узких местах, не рассказывают о классных best practices, не работают сообща над сложными задачами.
Такие проблемы возникают не только на личном уровне, но и между профессиональными группами. Например, на текущем проекте у нас была проблема с этапом Design Review, на котором сотрудник отдела дизайна проверяет, как реализовали UI по конкретной задаче. Задачи могли зависнуть в статусе Design Review на несколько дней, потому что дизайнер работал с несколькими проектами и мог не увидеть нашу задачу или забыть о ней. Проблема решилась элементарным образом: мы настроили бота, который присылает напоминания о Design Review ответственному дизайнеру. Если задача не прошла за шесть часов, бот дублирует сообщение. В итоге медиана времени нахождения задачи в статусе Design Review сократилась с 8—16 до 4—6 часов.
Поговорим о способах, которые помогут укрепить внутрикомандные связи.
Знакомство с продуктом. Наладить общение внутри команды не всегда просто. Начните со знакомства команды с продуктом, даже если работа над проектом продолжается несколько лет. Для этого соберите встречу, на которой ответьте на вопросы (те, кто знаком с STATIK, узнают их):
1. Что за систему мы делаем?
2. Кто наш заказчик и чего он ожидает от системы?
3. Кто наш конечный потребитель?
4. Какие задачи наших клиентов решает система?
5. Для чего клиенты решают свои задачи?
Важно убедиться, что каждый член команды, включая заказчика, правильно отвечает на эти вопросы и понимает предназначение системы. Понимание того, зачем и кому нужно качество проекта, повышает мотивацию обеспечивать это качество.
Регулярные активности. Не забывайте о стандартных внутрикомандных активностях:
Ежедневные короткие встречи (дейлики). Сейчас их часто проводят онлайн. Есть отличная статья о том, нужно ли включать камеру на онлайн-встречах.
Регулярные ретроспективы. Готовьтесь к таким встречам заранее и подводите итоги предыдущего периода. Подсвечивайте не только проблемы, но и положительные результаты. В нашей компании есть команда фасилитаторов, которая помогает организовать и провести эффективную ретровстречу.
Регулярные встречи обмена техническим опытом и best practices. Формат может быть каким угодно. У нас это митапы, ИТ-завтраки, встречи со свободным обсуждением конкретных практик и инструментов. Раз в неделю мы с командой проводим встречу, на которой любой участник может презентовать новые технические приемы, решения и инструменты.
Используйте Канбан-методы для активации общения. Эти методы хороши тем, что их можно применять к любой методологии разработки, будь у вас Scrum или WaterFall.
Например, задачи не двигают обратно по флоу не только для того, чтобы они не обесценивались на доске, но и для активации взаимодействия между тестированием и разработкой.
Встречи для неформального общения. Обычно это онлайн- или офлайн-тимбилдинги. Прежде чем предлагать такую встречу, выясните потребности сотрудников. Тимбилдинг, в который команда не вовлечена, не будет полезен.
Мы в дополнение к этому используем random-coffee-встречи. Это регулярные парные встречи с общением на нерабочие темы. Пары формируются случайным образом.
Визуализируйте внутрикомандные мемы и приколы. Со временем в команде появляются крылатые высказывания и мемы, которые понятны только вашей компании. Можно сделать из них стикеры в мессенджере, создать сайт или доску и использовать в повседневной работе.
Сильного влияния на социальные связи эта практика не окажет. На мой взгляд, она повышает личную лояльность сотрудника к команде. Когда коллега использует уникальный стикер, он вспоминает смешной случай, который стал поводом для его создания, и испытывает положительные эмоции. Со временем воспоминания пропадут, но связь «уникальный стикер — хорошие эмоции» останется.
Например, мы создали сайт с нашими крылатыми выражениями, которые поднимают настроение.
Активности по развитию коммуникаций нужно проводить регулярно и в течение всей жизни проекта. Было у вас такое, что вы перестали общаться с другом не из-за ссоры, а потому, что не поддерживали связь? Так же работают и рабочие взаимоотношения. Социальные взаимосвязи ослабевают, если ими не пользоваться.
Право голоса. Найти проблему в социальных связях или процессах и рассказать о ней — только полдела. Иногда бывает сложнее убедить коллег в том, что это действительно проблема и ее нужно решать. Сделать это будет проще, если у вас есть профессиональный авторитет и право голоса.
Чтобы вас слушали и слышали, нужно обладать авторитетом как среди разработчиков, так и среди заказчиков. Хорошо, если вы давно в команде и ваш голос имеет вес, но что делать тем, кто недавно в профессии или компании? Вот несколько приемов, которые помогут в этом вопросе:
Участвуйте в активностях разработки. Даже если вы пока ничего не понимаете и молчите, не пропускайте технические встречи и созвоны. Старайтесь вникнуть в суть вопроса, записывайте непонятные слова и не стесняйтесь задавать вопросы.
Это как с изучением иностранного языка. Сначала понимаешь лишь общий смысл и некоторые слова, но со временем начинаешь читать и разговаривать на нем. В одном из выпусков нашего подкаста «Доверяй, но проверяй» мы обсуждали, что профессии QA-инженера и разработчика с каждым годом сближаются.
Старайтесь разговаривать с разработчиками на их языке. Изучите основы архитектуры проекта, DevOps-структуру и стек технологий. Представьте, что разработчик просит проверить функционал роутинга, а вы не понимаете, что это и какие проверки нужны. Не стесняйтесь спросить, что значит незнакомое слово.
Будьте профессионалами. Начните с грамотной речи и орфографии. Оформляйте баги полнотело и понятно. Создайте регламент заведения дефектов на проекте и строго его придерживайтесь: это покажет вашу педантичность и профессионализм. Карточка с багом в Jira — это ваша визитная карточка.
Рассказывайте команде о своих активностях по улучшению качества проекта. Это сделает ваши действия более прозрачными и понятными для разработчиков и покажет, что они приносят пользу проекту.
Развивайте софт-скиллы, учитесь говорить лаконично и грамотно. Здесь могу дать рекомендацию, которая помогла мне: старайтесь как можно чаще выступать публично. Это могут быть выступления перед командой, компанией, на внешних мероприятиях, даже тост на семейном празднике. У нас в компании есть площадки для внутренних докладов, и это отличная практика для выступлений.
Не забывайте также работать над улучшением личных отношений:
Спрашивайте «Как дела?» и запоминайте ответ. При следующем разговоре упомяните событие из жизни сотрудника.
Этот прием полезен также и тимлидам. Он покажет сотруднику, что вам не все равно и вы вовлечены в его жизнь и дела, что повысит личную лояльность сотрудника к вам. Если сотрудник не хочет рассказывать о себе, не стоит этого требовать: не всем нравится делиться личной жизнью с коллегами.
Относитесь с уважением к работе, проделанной другими людьми, даже если в ней были ошибки. В моей работе был случай, когда на проекте скопился большой бэклог ошибок. Пришел новый тимлид и решил этот бэклог полностью потрешить, чтобы начать работу с чистого листа. Это решение задело меня, ведь я потратил много времени на поиск этих ошибок и их оформление. Первое впечатление о новом тимлиде было испорчено, и через три недели я уволился из этой компании.
В такой ситуации было бы лучше предложить приоритизировать ошибки, провести груминг, а в дальнейшем рассказать о практике Zero Bug Policy.
Участвуйте в тимбилдингах и вечерних посиделках.
Авторитет зарабатывается постепенно. Пройдет несколько месяцев упорного труда, прежде чем ваш голос станет значимым. Если вы пришли в новый проект, важно отнестись с уважением к тому, что уже сделано коллегами. Никогда не говорите фраз в духе: «О, как у вас все плохо, срочно переписываем». Не забывайте, что люди потратили на реализацию силы и время.
«Команда — заказчик»
Внутренние технические проблемы команды подсветить проще, потому что разработчики сталкиваются с ними напрямую. Сложнее убедить команду в наличии внешних проблем. Они могут быть не очевидными, но сказываться на количестве ошибок, пропускаемых на прод, и на времени доставки задач.
Отношения между заказчиком и исполнителем важны, но этой стороне создания проекта мало кто уделяет должное внимание, забывая одну из Канбан-ценностей — сотрудничество.
В начале карьеры я работал в банковском аутсорс-проекте. С заказчиком мы общались только во время написания спецификации и приемочных испытаний. Написать полную спецификацию с первого раза сложно, и в ходе решения задачи часто возникала потребность что-то уточнить. Но команда чаще не обращалась к заказчику, а принимала решения сама, потому что:
Рабочего мессенджера не было, и общение велось либо лично, либо через рабочую почту. Ответа на самый простой вопрос можно было ждать целый день.
В этом банке общались на «вы», что также создавало дополнительный психологический барьер.
Команда не понимала банковских терминов. Никто не хотел показаться глупым, уточняя, что означают незнакомые слова.
Все это привело к тому, что разработчики принимали решения, опираясь на свои представления о продукте, а не на нужды заказчика. Срок реализации задачи был две-три недели, а срок приемки иногда доходил до двух месяцев. Представляете, насколько непродуктивно тратилось время только потому, что разработчики не хотели лишний раз контактировать с сотрудниками этого банка?
В Тинькофф таких барьеров нет, и это дает результат. Например, в непростом марте 2022 года медиана Lead Time нашей команды выросла с 4 до 8,12 дней.
В марте бизнес-аналитики команды активизировались по максимуму. Они провели презентацию новых целей и задач для проекта, обозначили четкую целевую аудиторию и скорректированный вектор развития. В меняющихся условиях бизнес-линия дала то, что было важно всей ИТ-команде, — конкретные цели и план их достижения. Одной презентацией дело не ограничилось: бизнес-аналитики терпеливо отвечали на одни и те же вопросы, старались восстановить профессионально-спокойную атмосферу в команде. Не вводя никаких технических решений, а укрепив социальную связь между ИТ-командой и бизнес-линией, нам удалось снизить медиану Lead Time до 6,84 в апреле и до 6,7 в мае.
Цели заказчика для команды. Первый шаг на пути укрепления социальной связи «команда — заказчик» мы уже разобрали: поймите, кто ваш заказчик и какие у него цели. Цели могут быть разными: увеличение прибыли, расширение клиентской базы, ускорение и упрощение внутренних процессов и так далее. Помогите заказчику понять, что он хочет получить в конечном счете и на промежуточных стадиях.
Для отслеживания задач отлично подходит OKR. OKR — ключевые цели, которые ставятся на определенный промежуток времени — квартал, полгода или год. У каждой цели должны быть измеримые параметры, по которым будут подводиться итоги. Цель считается достигнутой, если выполнено 70—75% от задуманного. Про OKR написано немало книг и статей, поэтому здесь я озвучу только две особенности, на которые стоит обратить внимание:
Ставьте OKR не только команде, но и заказчику. Это поможет вовремя проводить маркетинговые исследования, отвечать на вопросы по текущим задачам в установленные сроки, собирать обратную связь от сотрудников. Объясните заказчику, что он такой же участник процесса создания сервиса, как и ИТ-команда. Приведите примеры, как те или иные исследования повлияли на прибыль и развитие в других проектах, а быстрая обратная связь сократила время реализации или доработки функционала.
Визуализируйте OKR. Визуализация — еще одна из Канбан-ценностей. Она помогает быстро вникнуть в смысл конкретных данных. Человеческий мозг воспринимает рисунки и графики гораздо легче, чем текст. Не зря люди научились рисовать раньше, чем писать и читать.
Убедитесь, что цели заказчика понятны и ясны всем участникам команды. Это поможет лучше понять его действия и выбор среди вариантов реализации. Вы сможете предлагать более точечные варианты решения задач и смотреть на продукт с точки зрения заказчика.
Активности команды для заказчика. Важно, чтобы и заказчик смотрел на проект с точки зрения команды. Объясните ему, почему это выгодно. Например, он будет лучше понимать оценку сроков и сможет разобраться, где сроки затягивались по объективным причинам, а где — по вине команды.
В команде заказчика бывают разные уровни технических знаний. Важно помочь коллегам разобраться. Для этого:
Визуализируйте архитектуру проекта. Опишите используемые фреймворки, инструменты, DevOps-архитектуру. Постарайтесь описать сложные вещи простыми словами и блок-схемами.
Визуализируйте процесс релиза. Опишите активности до релиза, во время релиза и после него. Покажите, как именно обеспечивается качество релиза.
Визуализируйте WorkFlow в Jira или в другом таск-менеджере. Покажите, какие этапы проходит задача, чтобы попасть на прод.
Важно установить точку принятия ответственности команды и озвучить ее заказчику. Это статус задачи, на котором команда берет ответственность на себя, начало отсчета срока готовности задачи.
Продолжайте укреплять коммуникации между командой и заказчиком с помощью регулярных встреч:
Рабочие встречи в течение жизненного цикла итерации разработки. Планирование, подведение итогов, синхронизация в ходе работы над спринтом.
Общие ретроспективы с заказчиком. Сфокусируйтесь на вопросах:
— поставки и планирования задач;
— полноты спецификации нового функционала;
— скорости ответов на вопросы в ходе реализации со стороны заказчика и ИТ-команды;
— полноты критериев приемки функционала.
Презентация командных метрик. Показывайте заказчику, как улучшились показатели: Lead Time, Cycle Time, количество багов на проде.
Презентации со стороны заказчика. Маркетинговые исследования, проверка гипотез и влияние реализованных задач на достижение поставленных целей.
Неформальные встречи ИТ-команды и команды заказчика.
Дружить с заказчиком бывает непросто. Но не забывайте, что увеличение его прибыли влияет на доход команды.
«Команда — пользователь»
Для команды пользователь может быть существом мифическим и далеким. Мы знаем, что он существует, и иногда решаем его проблемы, о которых узнаем от службы поддержки, но в реальной жизни пользователя не встречали. Этот подход в корне неверный, ведь мы делаем проект для конечного потребителя. Именно пользователь делает нашу систему популярной, и благодаря ему у нас есть работа.
Важно показывать команде продукт с точки зрения конечного пользователя. Это поможет сотрудникам выбирать варианты реализации задач, которые будут точнее соответствовать ожиданиям пользователя, и быстрее вникать в пользовательские ошибки, что сократит время ответа на запрос пользователя.
Дело не только в скорости ответа, но и в мотивации. Работа с проблемами пользователя может вызывать демотивацию ИТ-сотрудника. Часто сложно понять, что не устраивает пользователя, потому что он не знает всех тонкостей работы системы и разговаривает с разработкой на разных языках. К тому же это может оказаться и не проблемой вовсе, а незнанием функционала. Получается, сотрудник потерял время на работу, которую могла сделать первая линия поддержки.
Такие моменты могут ухудшить отношение команды к пользователю. Может случиться так, что один из резких ответов ИТ-специалистов дойдет до конечного пользователя и приведет к репутационным потерям.
Чтобы помочь команде понять потребности пользователя и вызвать чувство сопереживания, используйте несколько активностей:
Рассказывайте реальные кейсы пользователей, которым ваша система помогла или помешала достичь результата. Кейсы должны быть как положительные, так и отрицательные. Например, в нашей команде есть регулярная рубрика, в рамках которой нам озвучивают самые яркие комментарии пользователей. Это повышает чувство значимости продукта. Всем приятно чувствовать себя нужным и осознавать, что сервис помогает реальным людям.
Мотивируйте команду использовать свой продукт (Eating your own dog food). Проводите конкурсы на лучший сценарий использования сервиса. Например, мы провели конкурс на лучший сайт, в ходе которого команда подсветила более 50 решений, которые использовать было неудобно. Конечно, мы взяли в работу не все, но около 10 пользовательских проблем решили именно этим способом.
3. Вовлекайте команду в активности связи «заказчик — пользователь». Расскажите, как прошло А/Б-тестирование или как работает воронка привлечения.
4. Не забывайте сами проводить исследовательское тестирование и делитесь результатами с командой. Этот вид тестирования помогает изучить самые разные флоу использования сервиса.
Заключение
Как бы мы ни стремились быть профессионалами, личные отношения между сотрудниками влияют на рабочие отношения. А настроение и состояние личных дел влияют на нашу производительность и качество работы. Скажу очевидную вещь: работать в команде, где с социальными отношениями все хорошо, приятнее, чем там, где царят скрытые или открытые конфликты.
Время ИТ-индивидуалистов безвозвратно ушло. В большом проекте, разбитом на микросервисы, сама архитектура подразумевает большое количество интеграций между сервисами и командами.
Помогите команде укрепить социальные связи и взглянуть на проект с разных точек зрения. Не забывайте, что вы делаете проект для достижения конкретных целей. Нарушение в социальном взаимодействии бывает неочевидным. Часто на такие проблемы не обращают внимание или замалчивают их. Между тем они стабильно увеличивают время доставки задач на прод и играют против команды quality assurance.
