Привет, Хабр! Меня зовут Кристина. Я работаю в Яндекс Практикуме ревьюером на курсе «Инженер по тестированию», ментором тестировщиков в Мастерской программирования и руководителем соревновательных видов IT-практики (багатонов, хакатонов и кейс-чемпионатов).

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

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

Зачем проводить ретроспективы с командой? 

Ретроспективы служат важным механизмом для команд, чтобы задуматься о своей недавней работе и выявлять области для улучшения. Создавая безопасное пространство для открытого обсуждения, ретроспективы побуждают членов команды свободно делиться своими мыслями, проблемами и идеями. Это способствует культуре прозрачности, доверия и сотрудничества в команде. Кроме того, ретроспективы помогают в следующих направлениях:

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

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

3. Решение проблем: выявление проблем и препятствий своевременно не позволяет им расти и сорвать проект.

Инструменты для ретро

Подготовка и проведение эффективных ретроспектив требует некоторых важных инструментов и методов:

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

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

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

Тут я расскажу о нём в общих чертах.

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

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

Мы в Ak Bars Digital тоже используем много собственных наработок, методологий и шаблонов, чтобы делать все быстро и качественно. В этой статье поделюсь прикладным шаблоном, который создали опытным путем для удобной работы с пользовательскими историями.

Я Саша Хрущев, технический директор IT-компании WINFOX. Рассказываю о своем опыте освоения скриптинга в YouTrack и о том, как при помощи этого можно делать крутые отчеты.

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

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

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

Меня зовут Денис Соловьев, и так получилось, что я работал и продолжаю работать как раз на таких внутренних ИТ-продуктах. Я хочу сравнить, какие из инструментов и подходов работают для них.

Всем привет! Меня зовут Валентина Ляликова. Я ведущий бизнес-аналитик в X5 Tech и преподаватель направления «Пользовательские истории и критерии приёмки» в Школе бизнес-анализа X5 Tech. 

Большой опыт работы на разнообразных проектах помог сформировать мне список правил, которых я придерживаюсь каждый день при написании User Story и Acceptance Criteria (US+AC). В этой статье хочу поделиться ими с вами и показать на примерах ошибочных вариантов написания документа US+AC, почему так важно применять эти правила в работе.

Меня зовут Наталья Кобякова, я Product owner и техлид клана аналитиков в Ak Bars Digital. В этой статье я расскажу, почему для проектирования функциональности наших продуктов вместо стандартных ТЗ мы используем методологию User Story Mapping и как это помогает нам вести разработку быстро и качественно.

Однажды к нам пришла задача: заказчик хотел получить мобильное приложение, сайт, ERP-систему и CMS. И всё это — за полгода. Мы поняли, что реализовать проект можно, если подключить к нему не одного аналитика, а команду.

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

Рассказываем, как мы вышли из этой ситуации и выстроили работу команды.

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

Как вы уже поняли из названия - это вторая часть, описываемой системы. В первой части я подробно рассмотрел работу с инбоксом, вторая часть будет посвящена непосредственно "Управлению проектами". Обе части полностью независимы и могут читаться по отдельности, но я всё равно рекомендую с ней ознакомиться (ссылка на первую часть о инбоксе) и настроить один их способов наполнения инбокса.

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

Далеко не все пользуются тёмной темой, но однажды ослепнув от яркого монитора и обзаведясь очками, невольно переходишь на тёмную сторону. Так как же грамотно подойти к её созданию? Меня зовут Мария, я QA-инженер в ISPmanager и сегодня расскажу, как спроектировать и протестировать тёмную тему с учётом человеческой физиологии.

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

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

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

В этой статье я расскажу:

🍒 Из кого состоит продуктовая команда в компаниях в США.
🍒 О коллаборации продуктовой команды между собой и другими.
🍒 И про ротацию продуктовой команды.

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

Почему команда косячит и что-то идет не так? Мы задались этим вопросом и ретроспективно посмотрели на последний год работы. В этой статье я, Артем Салеев, руководитель backend-направления, расскажу о 3 основных проблемах в работе команды и поделюсь, как на опыте компании мы с ними разобрались.

Статья написана на основе моего выступления на конференции Merge 2022.

Меня зовут Михаил Правдин, я руковожу отделом исследований в Авито. Моя команда изучает пользовательский опыт, чтобы клиенты получали от продуктов только приятные впечатления. В этой статье расскажу, почему результаты UX-исследований не всегда идут в работу. Материал будет полезен всем, кто проводит исследования и работает с пользовательским опытом: дизайнерам, исследователям, продакт-менеджерам и аналитикам.

Этот туториал поможет разобраться в этапах проектирования продукта.
Обзор доступных инструментов для исследований в небольших студиях или для фриланс-специалистов.

Как найти пользователей для тестирования? Как создать профиль пользователя?
Какими способами тестировать гипотезы и важно ли это вообще

Что делать, если вы маленькая команда из 2-3 человек, которая делает интересное решение в корпоративном секторе, но у вас проблемы со сроками, качеством продукта, а на ручное тестирование совсем нет времени?

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

В статье я постарался проанализировать проблему, описать решение, которое они пробовали, и рассказать о решении, которое им помогло.