Автор: Джуди Мосли (Judy Mosley)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

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

CANDY — это обратная связь, которая всегда:

• Clear — ясная
• Actionable — действенная
• Neutral — нейтральная
• Directional — направляющая
• Yarely — готовая к действию

➿ Сначала давайте определим, что такое цикл обратной связи.

Циклы обратной связи

TechTarget определяет цикл обратной связи как часть системы, в которой определённая часть (или весь объём) выходных данных системы используется в качестве входных данных для будущих операций.

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

• Результаты автоматизированных тестов
• Сессии уточнения требований, в которых участвует команда
• Отчёты о багах
• Запросы на добавление функциональности
• Логи ошибок в продакшене

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

Чтобы создать общую культуру, в которой качество – это ответственность каждого, думаю, не повредит немного радости. А что может быть радостнее конфет?

Акроним CANDY

• Clear:
  • Получаемая обратная связь не вызывает путаницы. Процесс документирован, доступен и, возможно, закреплён в канале Slack. Шаги для воспроизведения помогают определить, где ломается код. Отчёт даёт нам уверенность в том, что релиз можно выпускать, или понимание, что этого делать не стоит. Что бы мы ни использовали и что бы ни говорили, то, что сообщается, ясно и понятно всем.
• Actionable:
  • Член команды, обнаруживший баг, знает, как о нём сообщить. Команда разработчиков знает, как его исправить. Критерии приёмки понятны разработчику, работающему над функциональностью.
• Neutral:
  • В хорошей обратной связи нет обвинений и эго. Если что-то плохо, мы это исправляем. Если что-то хорошо, мы это празднуем. Команда не увязает в поиске виноватых. Ни один человек не несёт единоличной ответственности за успешную функциональность. Мы все вносим свой вклад и уважаем деятельность друг друга.
• Directional:
  • Время, проведённое с членами команды – это ценное время. Когда человек высказывается, он получает необходимую помощь. Нет необходимости в микроменеджменте, потому что все чувствуют себя в безопасности, обсуждая дальнейшие действия.
• Yarely:
  • (Слова на Y — это сложно, ладно??) Но, серьёзно, Yarely — идеальное слово. Его корень «Yare» означает «готовый». Обратная связь подготавливает команду к тому, что делать дальше, а команда достаточно гибка, чтобы изменить направление в соответствии с новой информацией.

У вас уже слюнки текут? ???? У меня тоже! Но для того, чтобы получать великолепную обратную связь, нам нужно учитывать и наш образ мышления – не так просто переварить огромное количество CANDY.

Извлечённые уроки

Вот чему я научилась, когда и предоставляла, и получала эффективную обратную связь:

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

Использование CANDY в SDLC

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

Базовый цикл:

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

Где ещё стоит добавить немного CANDY?

Вы, наверное, уже понимаете, к чему я веду…

А что насчёт деплоя? Ясны ли наши логи ошибок? Есть ли у нас логи ошибок? Что они нам сообщают? У кого есть доступ к этой информации и могут ли эти люди быстро её получить?

А что насчёт проектирования? Обсуждается ли доступность? Знаете ли вы, какие существуют инструменты для проверки доступности? Может ли кто-нибудь высказаться на этапе дизайна и выступить в защиту любого типа пользователя?

А что насчёт отчётов о багах? Ясны ли они? Может ли их писать кто угодно? Есть ли руководство о том, как писать их таким образом, чтобы разработчикам был понятен путь к обнаружению бага? Как сообщают о багах? Есть ли доска с багами, которую регулярно оценивают соответствующие стороны? Кто именно это делает?

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

Проблемы

Итак, что вы можете сделать, когда ваши ресурсы ограничены?

• Начните разговор и будьте готовы сделать первый шаг. Иногда достаточно, чтобы кто-то спросил: «Работает ли этот процесс для нас?» Надеюсь, другие присоединятся к разговору, и после этого будут готовы вывести этот разговор на следующий уровень.
• Ищите небольшие победы. В какой области у вас есть достаточно влияния? Есть ли в программном обеспечении пакет, который необходимо обновить и с которым вы знакомы? Поднимите этот вопрос на инженерной встрече и возьмите на себя ответственность за него. Обсудите объём работ и то, насколько это действие выполнимо. Укажите на преимущества этого изменения и на то, что будет доступно всей команде после этого обновления.
• Создайте spike-задачу. Возможно, вы не уверены, какие преимущества будут получены при переходе на другой инструмент. С согласия вашей команды (если возможно) создайте spike-задачу, в рамках которой вы сможете провести исследование и посмотреть, какие изменения возможны. Обсудите результаты со своей командой и оцените ценность изменения.
• Предлагайте то, что можете, и будьте готовы ко всему. Это сложный момент. Не всем понравятся ваши идеи, и это нормально. Постарайтесь не принимать отказ на свой счёт. Однако если команда отвергает абсолютно каждую идею, подумайте, не является ли источником вашего стресса не столько работа, которую вы выполняете, сколько среда, в которой вы находитесь. Это уже сам по себе цикл обратной связи. Принимайте решения соответственно.

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

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

Заключение

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

У вас на этой неделе было немного CANDY?

Обсудить в форуме