Для нас в команде Culture fit был очень важен. Это была продуктовая компания (не проект), поэтому это был забег на длинную дистанцию и нам важно было, с кем работать рука об руку ежедневно. Доверие, открытость, взаимопомощь, партнерство — все это было нашими ценностями. И мы искали таких же открытых приятных коллег в команду. Со временем даже выработали для себя ряд открытых вопросов, которые хорошо выявляли нужные качества людей. И Патрик Ленсиони посредством своей книги мне тоже в этом помогал. У нас в команде была почти семейная атмосфера. Мы вместе ходили всегда на обеды, были свои традиции (по понедельникам в корейский ресторан, по пятницам в грузинский на хинкали). А в работе не боялись просить о помощи и с удовольствием помогали друг другу. Перфоманс был разным на разных этапах, были и просадки, когда команда переживала M&A (слияние/покупку), это было дважды в течение двух лет). Команда сработалась и мы проработали вместе 2.5 — 3 года и расходиться не собирались, пока наш продукт в итоге не купила Adobe, которая не работает с Украиной в принципе. Поэтому сейчас команда в разные компании разбежалась, но мы все еще встречаемся на дружные посиделки. Это моя первая команда, и в ее развитие я вложила душу, что окупилось замечательным результатом.

Класс, спасибо, что поделились своей историей! Продолжайте в том же духе. Желаю успехов на вашем пути!

Мне помог мой предыдущий опыт написания тест кейсов на английском на позиции QA. Там я разбивала функционал на части и для каждой части писала ряд тест кейсов. Тест кейс имеет свою стандартную структуру, это помогало упорядочивать и структурировать информацию, и английский с его пассивным залогом тоже быстрее усваивался.
1. Важно, чтобы задача не была написана сплошным текстом, это сложнее читается.
2. Каждый пункт должен быть логически завершенным. Если нужно, добавляйте подпункты для детализации и выделения важных данных
3. Каждый пункт должен быть максимально лаконичным, чтобы не было воды и ненужных деталей (об этом можно и нужно уточнять у команды при обсуждении задачи, достаточно ли им информации, к примеру, многое уже показано на дизайне и не нужно указывать размеры элементов, достаточно дать ссылку на дизайн)
3. Избегайте двусмысленностей, называйте всё своими именами, точные названия страниц и элементов, особенно уточняйте в задаче, если у вас, к примеру, одинаково в продукте называются страница и пункт меню или какой-то инпут.
4. Если вы описываете сложную цепочку действий или логику для разных ролей пользователей (у нас такое есть), старайтесь использовать визуализацию (к примеру, диаграммы, mind maps)
5. Постарайтесь продумать и описать максимальное количество вариантов поведения функционала, которое важно знать разработчикам для реализации. Все 100% вариантов вряд ли получится предусмотреть в сложном продукте, но у вас уже будет отличная база для обсуждения на встрече с командой.
6. Всегда уточняйте у команды на встрече, что еще важно добавить в задачу. Разработчики и QA со своей стороны могут дополнить задачу важными деталями.

Касательно примеров, вот одна из наших реализованных задач:

Название задачи: Objective deactivation via the Objective Details darwer

As a user I want to be able to easily deactivate unnecessary objectives so that they wouldn’t be calculated in progress statistic.

Design (ссылка на дизайн)

Acceptance Criteria:

1. Add «Deactivate» button to the drawer
2. What objective can be deactivated (show «Deactivate» button if):
— Status — Active
— Time Frame — current and future
3. Who can deactivate (show «Deactivate» button to):
— Admin user — in any objective
— Non-admin user — if this objective is in scope of his editing permissions (doc with permissions — здесь ссылка на документ)
4. After clicking the «Deactivate» button:
— show a spinner while information is saving
— show success toaster after deactivation «The objective was successfully deactivated»
— status on the preview should be changed to Inactive
— «Deactivate» button should be changed to «Activate»
5. Don’t reduce progress to 0% if there was some value before, just make the progress bar gray instead of green/yellow/red (design)
— do the same progress bar in the Explorer table

Ваши задачи могут быть оформлены иначе, так как контекст будет отличаться. Самое важное — убедиться, чтобы ваша задача была понята командой правильно, а удобная подача информации этому поможет.
Хорошая статья с примерами agileforgrowth.com/...​tance-criteria-checklist
Желаю вам успехов! :)

Спасибо)

Благодарю) и за откровенность тоже))

Спасибо, рада, что статья пришлась вам по душе) верю, что у вас всё получится!

Тоді в моєму випадку все співпало)

Справа не в технічній слабкості проекту і не в зарплатні, адже у нас всі хлопці в команді достатньо досвідчені, і ЗП у багатьох середні або вищі за середні на ринку. Проте це стартап і на етапі змін (формування нової команди, нових процесів та пошук нового СТО протягом трьох місяців) у нас виникали труднощі. І саме труднощі стали плодотворною почвою для зростання (як кар’єрного, так і в зарплатні).