Первые 90 дней

Updated Jul 2026

Почему первые 90 дней определяют следующие 3 года

Первые 90 дней на новой QA-позиции имеют непропорционально большое значение. В это окно вы устанавливаете свою репутацию, строите или разрушаете доверие, демонстрируете свою ценность и задаёте траекторию на весь срок работы. Люди формируют мнение о новых сотрудниках в первый месяц, и эти мнения становится крайне трудно изменить.

Большинство QA-инженеров начинают новую роль и немедленно пытаются исправить всё, что видят неправильным. Это самый быстрый путь к провалу. Прежде чем вы сможете что-то изменить, вам нужно понять систему -- продукт, людей, процессы и историю. QA-инженеры, которые оказывают наибольшее долгосрочное влияние, -- те, кто проводят первые 90 дней, слушая, обучаясь и выстраивая отношения, прежде чем начать предлагать изменения.

Этот файл даёт вам структурированный план для каждой фазы: первые 30 дней (учитесь), первые 60 дней (вносите вклад) и первые 90 дней (руководите).

Первые 30 дней: изучите всё

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

Неделя 1: ориентация и отношения

День 1-2: настройка окружения

• Запустите ваше рабочее окружение (все репозитории, тестовые фреймворки, доступ к CI)
• Запросите доступ ко всем инструментам: Jira, система управления тестами, CI/CD, дашборды мониторинга, каналы Slack
• Запустите существующий набор тестов локально. Проходит ли он? Сколько времени занимает? Как выглядит вывод?

День 3-5: встречи с людьми

• Назначьте 30-минутные 1:1 с каждым, с кем вы будете работать напрямую: члены QA-команды, разработчики в вашем скводе, product owner, инженерный менеджер и DevOps/SRE
• Ваша повестка для каждого 1:1: кратко представьтесь, спросите об их роли и текущих задачах, спросите, что бы они хотели, чтобы QA делало по-другому, и спросите, какой самый большой риск для качества прямо сейчас

Недели 2-4: глубокое изучение

Знание продукта:

• Используйте продукт как реальный пользователь. Пройдите все основные потоки. Записывайте, что вас смущает -- ваш свежий взгляд ценен.
• Прочитайте документацию продукта, базу знаний и клиентские справочные статьи.
• Изучите продакшен-инциденты за последние 30 дней. Что сломалось? Почему? Каково было влияние на клиентов?
• Изучите баг-репорты за последние 30 дней. Какие паттерны вы видите?

Ландшафт тестирования:

• Составьте карту существующего тестового покрытия: что автоматизировано, что ручное, что не тестируется вообще
• Поймите тестовую архитектуру: фреймворки, паттерны, управление данными, конфигурация окружений
• Прочитайте существующий документ стратегии тестирования (если он существует)
• Запустите полный набор тестов в CI и локально. Отметьте нестабильные тесты, медленные тесты и падающие тесты.
• Поймите процесс релиза от коммита кода до развёртывания в продакшен

Люди и процессы:

• Посетите все командные церемонии (стендап, планирование, ревью, ретроспектива) и наблюдайте, прежде чем участвовать
• Изучите коммуникационные паттерны команды: кто с кем общается, кто имеет влияние, у кого есть институциональные знания
• Определите неформальных лидеров -- людей, чьё мнение имеет вес независимо от должности

Вопросы, которые стоит задать на первой неделе

Они организованы по аудитории. Вам не нужно задавать все -- выберите наиболее релевантные для вашей роли и уровня.

Вопросы для вашего QA-менеджера

1. «Как выглядит успех для меня на 30, 60 и 90 днях?»
2. «Какая самая большая проблема качества, с которой команда сталкивается прямо сейчас?»
3. «Как здесь измеряется эффективность QA?»
4. «Какие QA-инициативы сейчас в работе или запланированы?»
5. «Что команда пробовала раньше, но не сработало?»
6. «Как структурирована QA-команда относительно команд разработки?»
7. «Какова ситуация с бюджетом на инструменты, обучение и конференции?»
8. «С какими ключевыми стейкхолдерами мне стоит выстроить отношения?»

Вопросы для членов QA-команды

9. «Что самое болезненное в вашей ежедневной работе?»
10. «Какие области продукта страшнее всего тестировать? Почему?»
11. «Что бы вы хотели видеть автоматизированным, но этого нет?»
12. «Откуда берутся нестабильные тесты и как с ними справляются?»
13. «Какова ситуация с тестовыми данными -- легко или болезненно?»
14. «Как вы справляетесь с тестированием, когда требования неясны?»
15. «Каков опыт онбординга -- что бы вы хотели, чтобы вам сказали в первый день?»

Вопросы для разработчиков

16. «Как вы предпочитаете получать баг-репорты?»
17. «На каком этапе вашего процесса разработки вовлечение QA было бы наиболее полезным?»
18. «Каков ваш опыт с набором тестов -- доверяете ли вы ему? Запускаете ли?»
19. «Есть ли области кода, которые вы считаете хрупкими или рискованными?»
20. «Как вы справляетесь с падениями тестов в CI -- исправляете сразу или пропускаете?»
21. «Что облегчило бы вашу жизнь с точки зрения QA?»

Вопросы для product owner

22. «Какие предстоящие функции имеют наибольший риск для качества?»
23. «Как обычно определяются критерии приёмки? Вовлечено ли QA?»
24. «Какой был последний продакшен-инцидент, затронувший клиентов, и как с ним справились?»
25. «Какие области продукта получают больше всего жалоб от клиентов?»
26. «Как вы приоритизируете исправления багов относительно новых функций?»

Вопросы для DevOps/SRE

27. «Каков пайплайн развёртывания, и где в нём тесты?»
28. «Как управляются тестовые окружения? Кто может развернуть новое?»
29. «Какой мониторинг и оповещения существуют для качества в продакшене?»
30. «Каков процесс реагирования на инциденты, и вовлечено ли QA?»
31. «Каковы самые большие инфраструктурные узкие места, влияющие на выполнение тестов?»

Вопросы к себе

32. «Каков разрыв между тем, как тестирование делается здесь, и тем, как я думаю, оно должно делаться?»
33. «Каковы 3 быстрые победы, которые я мог бы одержать в следующие 30 дней?»
34. «Каков самый большой риск для качества продукта, о котором никто не говорит?»
35. «Где я могу принести наибольшую ценность, учитывая мои конкретные навыки и опыт?»

Первые 60 дней: вносите видимый вклад

К 30-му дню вы понимаете ландшафт. Теперь пора начать вносить вклад способами, которые строят авторитет и доверие.

Определите и реализуйте быстрые победы

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

Стратегически выстраивайте отношения

Начните участвовать в церемониях

К 30-45 дню вы должны быть активным участником всех командных церемоний, а не просто наблюдателем.

• Планирование спринта: Задавайте уточняющие вопросы о тестируемости. Оценивайте усилия на тестирование. Определяйте зависимости.
• Ежедневный стендап: Отчитывайтесь о статусе тестирования конкретно, а не общими словами.
• Ревью спринта: Представляйте метрики качества в течение 2-3 минут. Показывайте, что было протестировано и что было найдено.
• Ретроспектива: Приносите одно наблюдение о качестве за спринт, подкреплённое данными.

Это напрямую опирается на практики церемоний спринта, рассмотренные в главе 20.

Первые 90 дней: предлагайте и руководите

К 60-му дню у вас есть авторитет. Люди знают вас, доверяют вам и видели, как вы доставляете результат. Теперь вы можете предлагать более крупные изменения.

Предлагайте улучшения с данными

Не говорите «Я думаю, нам стоит внедрить контрактное тестирование.» Говорите «Я проанализировал наши последние 20 продакшен-инцидентов и обнаружил, что 9 из них (45%) были вызваны несоответствиями API-контрактов между сервисами. Контрактное тестирование нацелено именно на этот тип сбоев. Вот план на 3 спринта для его внедрения, начиная с 3 самых нагруженных API-границ.»

Предложение по улучшению за 90 дней

Напишите короткий документ (1-2 страницы), который охватывает:

1. Текущее состояние: Что вы наблюдали в практике тестирования (сильные стороны и пробелы)
2. Ключевые риски: Топ-3 рисков для качества, которые вы выявили, с данными
3. Предлагаемые улучшения: 3-5 конкретных инициатив, каждая с оценкой усилий, ожидаемым эффектом и зависимостями
4. Порядок приоритетов: Что делать первым и почему
5. Метрики успеха: Как вы будете измерять, сработали ли улучшения

Поделитесь этим сначала с вашим менеджером, получите обратную связь, затем представьте более широкой команде. Этот документ служит нескольким целям: он демонстрирует стратегическое мышление, показывает, что вы слушали и учились, и даёт вашему менеджеру конкретные доказательства вашего влияния для первого performance review.

Пример плана предложения за 90 дней

Current State Assessment:
- Test automation covers 62% of critical paths (gap: checkout flow, admin panel)
- CI pipeline takes 52 minutes (target: <30 minutes)
- 14 flaky tests causing 3-4 false failures per day
- No contract testing between payment service and order service
- Manual regression takes 8 hours per release

Proposed Initiatives (priority order):

1. Fix flaky tests (Sprint 1-2)
   Effort: 3 days
   Impact: Eliminate 3-4 false CI failures per day, restore developer trust in the suite

2. Automate checkout flow (Sprint 2-4)
   Effort: 2 weeks
   Impact: Cover the highest-revenue user path, reduce manual regression by 2 hours

3. Pipeline optimization (Sprint 3-5)
   Effort: 1 week
   Impact: Reduce CI time from 52 to <30 minutes through sharding and caching

4. Contract testing pilot (Sprint 5-7)
   Effort: 2 weeks
   Impact: Target the #1 production incident category (API mismatches)

5. Deprecate manual smoke tests (Sprint 7-9)
   Effort: 3 weeks
   Impact: Eliminate 8 hours of manual testing per release

Success Metrics:
- Flaky test rate: from 14 to 0
- CI pipeline time: from 52 min to <30 min
- Automation coverage of critical paths: from 62% to 85%
- Manual regression time per release: from 8 hours to 2 hours
- Production incidents from API mismatches: from 9/quarter to <2/quarter

Создание плана обучения

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

Шаблон плана обучения

Типичные ошибки в новых QA-ролях

Подготовка к сильному первому performance review

Ваш первый performance review, вероятно, произойдёт через 3-6 месяцев. Начните готовиться к нему с первого дня.

Что ищут ревьюеры

Ведение документа достижений

Начните приватный документ с первого дня и обновляйте его еженедельно:

Week of [date]:
- Completed: [what you delivered]
- Impact: [measurable result]
- Feedback received: [positive or constructive]
- Skills developed: [what you learned]
- Relationships built: [who you connected with]

Когда придёт время ревью, у вас будет 12+ недель задокументированного влияния вместо попыток вспомнить, что вы делали.

Разговор перед ревью

За две недели до ревью проведите разговор с вашим менеджером:

«Мой ревью будет через две недели. Я отслеживал свои вклады и хочу убедиться, что мы на одной волне в оценке того, как идут дела. Можем ли мы потратить 15 минут на обзор моего прогресса относительно целей, которые мы поставили в начале?»

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

Построение союзников: с кем связаться первым и почему

Карта приоритетов

Week 1:   Your manager          -- alignment on expectations
          Your QA team           -- immediate peers and support network

Week 2:   Your squad's developers -- daily collaborators
          Your product owner      -- defines what you test

Week 3:   DevOps/SRE            -- controls your infrastructure
          Senior engineer         -- technical authority and mentor

Week 4:   QA engineers on other squads -- broader QA community
          Customer support        -- understands user pain points

Month 2:  Engineering leadership  -- visibility and sponsorship
          Design team             -- accessibility and usability perspective

Скрипт построения союзничества

Для каждого 1:1 в первый месяц используйте эту структуру:

1. Вступление (2 мин): Краткий бэкграунд, что вас воодушевляет
2. Их перспектива (15 мин): «Какая самая большая проблема, с которой вы сейчас сталкиваетесь? Как QA вписывается в вашу работу? Что облегчило бы вашу жизнь?»
3. Предложите ценность (5 мин): «Основываясь на том, чем вы поделились, вот одна вещь, с которой я думаю, что могу помочь в ближайшие недели.»
4. Продолжение (в течение 1 недели): Выполните своё предложение или предоставьте обновление

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

Практическое упражнение

1. Составьте расписание первой недели, используя структуру выше: настройка окружения, 1:1 встречи, изучение продукта.
2. Выберите 10 вопросов из списка выше, которые наиболее важны для вашей следующей роли. Расставьте их в порядке приоритета.
3. Определите 3 потенциальные быстрые победы, которые вы могли бы одержать в первые 60 дней на любой новой позиции, основываясь на типичных болевых точках QA.
4. Создайте шаблон плана обучения, адаптированный к конкретной компании или домену, на который вы нацелены.
5. Начните документ достижений прямо сейчас, даже для вашей текущей роли. Выработайте привычку еженедельного документирования.

Тезис для собеседования: «Когда я начинаю новую роль, я следую структурированному 90-дневному подходу. Первые 30 дней я полностью фокусируюсь на обучении -- понимании продукта с пользовательской перспективы, маппинге текущего тестового покрытия и архитектуры, знакомстве с командой и выявлении болевых точек. Я не предлагаю изменений, пока не пойму систему и историю за ней. С 30-го по 60-й день я доставляю быстрые победы, которые строят авторитет -- исправление нестабильных тестов, автоматизация болезненного ручного процесса или улучшение общего инструмента. К 60-му дню я заработал доверие через видимые результаты. Затем в последние 30 дней я пишу предложение по улучшению, подкреплённое данными: текущее состояние, ключевые риски с доказательствами и 3-5 приоритизированных инициатив с оценками усилий и метриками успеха. Я представляю это сначала менеджеру, затем команде. Сочетание продемонстрированной компетенции и стратегического плана улучшений утверждает меня как человека, который слушает перед тем, как действовать, доставляет перед тем, как предлагать, и подкрепляет мнения данными. Каждое предложенное мной улучшение привязано к измеримым результатам качества -- defect escape rates, скорости пайплайна, пробелам покрытия или сокращению ручных усилий -- потому что влияние без измерения невидимо.»