RWB Тех

⭐️⭐️ Коллеги, а есть документация по проекту?

Люсьена Мирославская, технический писатель Wildberries & Russ, рассказывает, как начать писать документацию, если в команде нет техписателя и ресурсов на полноценный отдел:

➡️ С чего начать, если вы не знаете, что именно описывать;
➡️ Как определить цель статьи и не превратить её в «всё обо всём»;
➡️ Почему структура — это 50% успеха;
➡️ Как писать понятно, без литературных изысков и двусмысленностей;
➡️ Какие ошибки чаще всего делают разработчики и менеджеры;
➡️ И как не утонуть в объёме и деталях.

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

➡️ Читать на Хабре

👀 Отдыхаем и смотрим картинки

Ждём ваши любимые мемы за неделю в комментариях!

⏩️⏩️ Продолжаем

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

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

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

Что же за пример? Правильно — клиентское мобильное приложение Wildberries!

Как определяете баланс между скоростью выпуска продукта и качеством тестирования (скажи своё непопулярное мнение и беги)?

Влётные задачи. Реактивный бизнес. TTM нам не помеха. Как выжить тестировщикам?

Мы начали регресс одного из самых популярных приложений в стране, а нам постоянно говорят: «Вот, держите, очень надо в этот же релиз! Бизнес не может ждать!» Отставим панику и оценим влияние изменений. Фиче-флаги проверены? Сможем откатить в случае чего? Оценили влияние на другие стримы? Если всё да — перепроверим то, что затронуто, и можем двигаться дальше.

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

🟣 Видим, вам понравилась рубрика интервью с коллегами, поэтому продолжаем!

Сегодня на связи Роман Лукманов, Head of QA клиентского приложения WB. Поговорим о карьере, важных навыках и подходах к релизам.

Твои первые шаги в профессии? Что было самым сложным?

Собеседование. Онбординг. Документация.
Три вехи погружения нового человека в команду. Тогда было одновременно проще и сложнее.

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

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

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

Что изменилось в роли лидера тестирования?

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

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

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

Важно ли непрерывное обучение в тестировании?

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

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

⭐️⭐️ 1000 в 1: единая платформа для событий Databus

Виктор Такташов, Golang-разработчик команды Trust & Safety в Wildberries & Russ, рассказал, как мы собрали десятки Kafka-кластеров в единую событийную платформу — Databus:

➡️ Почему разрозненные Kafka-кластеры тормозят развитие компании;
➡️ Как обеспечить неизменяемость контрактов и перестать ломать интеграции;
➡️ Зачем между сервисами и брокером стоят прокси и что это даёт в масштабировании;
➡️ Как DCP и SDK снимают с команд инфраструктурную боль (например, retry, offset management, TLS, метрики из коробки и тд).

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

➡️ Читать на Хабре

⭐️ У всех есть рабочие идеи. Хорошие, интересные, полезные. Но большинство из них так и остаются идеями. Почему?

Потому что между «у меня есть классная мысль» и «давайте это делать» лежит пропасть, которую нужно правильно преодолеть. Разбираемся, как это сделать в карточках.