Расскажи про свой опыт наставничества

Question

claude-haiku-4.5 · Accepted Answer

## Опыт наставничества: от новичка к система-аналитику

### Контекст: развитие junior аналитика

В моей карьере мне доводилось наставлять молодых аналитиков. Расскажу про конкретный случай: как я помог превратить junior разработчика в полноценного System Analyst за год.

### История: Саша — junior бэкенд разработчик

**Начальный уровень:**
- 2 года опыта в Python/Django
- Хорошее понимание кода
- Но НЕ понимает системную архитектуру
- Не может писать требования
- Не видит больших картин

**Проблема, которую я заметил:**

Саша получил задачу: "Добавить фильтрацию в API"

Он сделал:
```python
@app.route('/users')
def get_users():
    name = request.args.get('name')
    email = request.args.get('email')
    age = request.args.get('age')
    # ... 20 фильтров
    return users.filter(...)
```

**Проблемы:**
1. Не спросил, сколько пользователей будет?
   - БД медленная с 20 фильтрами на миллионе записей
2. Не спросил про использование
   - Frontend пошлёт 10 фильтров, но возьмёт только имя и email
   - Остальное вычисляется зря
3. Не подумал про масштабируемость
   - Если добавится ещё 20 фильтров, код станет unmaintainable
4. Не документировал
   - Никто не знает, какие фильтры поддерживаются

Это был момент, когда я понял: Саша знает код, но не знает как быть аналитиком.

### Мой план наставничества

#### Этап 1: Обучение основам (месяц 1)

**Что я делал:**

1. **Дал ему прочитать книги:**
   - "Проектирование API" — Arnaud Lauret
   - "Building Microservices" — Sam Newman
   - "Domain-Driven Design" — Eric Evans
   - Не весь текст, а конкретные главы

2. **Обсуждали на примерах:**
   
   Я спросил Сашу:
   ```
   "Когда ты пишешь GET /users, что ты думаешь?"
   
   Саша ответил:
   "Достану всех пользователей из БД"
   
   Я спросил:
   "Правильно. А если их 10 миллионов? Вернёшь все 10 млн?"
   
   Саша: "Ой, нет! Это упадёт!"
   
   Я: "Ровно. Значит нам нужны pagination, limits, filters. 
       И всё это нужно документировать. Вот почему это важно."
   ```

3. **Практическое упражнение:**
   
   Я дал ему реальную задачу:
   ```
   "Напиши требования для API экспорта отчётов
   (не код, просто требования)"
   ```
   
   Саша написал:
   ```
   POST /exports
   Body: { report_type: 'pdf' }
   ```
   
   Я попросил расширить требования:
   ```
   Вопросы для тебя:
   1. Сколько времени экспорт будет обрабатываться?
   2. Что если экспорт большой (1GB)?
   3. Как пользователь узнает, готов ли экспорт?
   4. Куда сохранять экспорт?
   5. Сколько экспортов может быть одновременно?
   6. Что если пользователь отменит экспорт?
   ```

#### Этап 2: Раскопать нефункциональные требования (месяц 2-3)

**Я показал ему матрицу вопросов:**

```
Для каждого компонента спрашиваем:

⚡ Performance (производительность)
  - Сколько времени это должно занимать?
  - Сколько одновременных операций?
  - Какой объём данных?

🔒 Security (безопасность)
  - Кто имеет доступ?
  - Как защищены данные?
  - Нужна ли аутентификация?

📈 Scalability (масштабируемость)
  - Может ли это вырасти в 10x?
  - Как архитектура изменится?
  - Где bottleneck?

🛡️ Reliability (надёжность)
  - Что если сломается?
  - Как восстановиться?
  - Гарантирует ли 100%?

🎯 Usability (удобство)
  - Понятна ли ошибка пользователю?
  - Как он узнает о прогрессе?
  - Удобен ли интерфейс?
```

**Практика: его первое полное требование**

Дал ему задачу: "Напиши требования для истории платежей"

После применения матрицы вопросов, он написал:

```
API: GET /payments?limit=20&offset=0

Функциональные требования:
- Возвращает список платежей пользователя
- Поддерживает pagination (limit, offset)
- Фильтрует по дате и статусу

Нефункциональные требования:

Производительность:
- P95 response time: < 200ms
- Система должна выдержать 1000 запросов/сек

Безопасность:
- Пользователь видит только СВОИ платежи
- Используется JWT token для аутентификации
- Данные карты НЕ возвращаются в API

Масштабируемость:
- При 10x росте пользователей, время ответа не должно расти
- Используем индексы в БД по дате и user_id
- Кешируем в Redis последние 1000 платежей

Надёжность:
- Если Redis отвалится, система работает из БД
- Если история потеряется, можно восстановить из payment logs
- 99.9% availability

Удобство:
- Отобра clear error message если платёж не найден
- Показываем статус платежа (completed, pending, failed)
```

Это был прорыв! Саша начал думать как аналитик.

#### Этап 3: Встречи с заинтересованными сторонами (месяц 4-5)

**Что я делал:**

1. **Научил брать интервью:**
   
   Дал ему план интервью с бизнесом:
   ```
   1. Открыть встречу вопросом:
      "Какую проблему мы решаем этой фичей?"
   
   2. Слушать основную проблему
   
   3. Уточняющие вопросы:
      - "Сколько пользователей это затронет?"
      - "Как часто это случается?"
      - "Что произойдёт, если мы ничего не сделаем?"
      - "Какой бюджет у нас на это?"
      - "Какой deadline?"
   
   4. Закончить:
      "Дайте мне неделю, я подготовлю требования"
   ```

2. **Первое интервью Саши:**
   
   Product Manager сказал:
   ```
   "Хочу фичу для экспорта отчётов в Excel"
   ```
   
   Саша спросил вопросы:
   ```
   - Какие отчёты? (Продажи, прибыль, аналитика)
   - Кто их экспортирует? (CFO, accountants) — ВАЖНО!
   - Как часто? (Каждый день)
   - Сложные это отчёты или простые? (Очень сложные, 50 000 строк)
   - Когда нужно? (За месяц)
   ```
   
   Из интервью Саша понял:
   - Это не на месяц, это на 2-3 месяца (50k строк = сложность)
   - Нужны оптимизации (async processing, background jobs)
   - Нужен мониторинг (CFO не может ждать, нужно видеть прогресс)

#### Этап 4: Написание документации (месяц 6)

**Я учил его писать Requirements Document:**

```
Таблица оглавления:
1. Обзор проекта
2. Заинтересованные стороны
3. Функциональные требования
4. Нефункциональные требования
5. Constraints
6. Assumptions
7. Risks
8. Success Criteria
9. Dependencies
```

**Первый документ Саши:**

Получился хороший, но было много проблем:
- Описания были неясные
- Не было примеров
- Не были проверены с бизнесом

Я попросил переделать, дав feedback:
```
"Прочитай это описание, ты как разработчик сможешь это реализовать?"

Саша: "Нет, не понял что именно нужно делать"

Я: "Ровно. Значит описание неправильное. 
    Добавь примеры, диаграммы, тест-кейсы."
```

После 3-4 итераций документ стал хороший.

#### Этап 5: Code Review требований (месяц 7-8)

**Я научил его:**

1. **Проверять требования like code review:**
   ```
   ✓ Есть ли все MUST иметь?
   ✓ Есть ли примеры для каждого случая?
   ✓ Есть ли error cases?
   ✓ Есть ли performance требования?
   ✓ Есть ли security требования?
   ✓ Может ли разработчик это понять и реализовать?
   ✓ Могут ли тестировщики это проверить?
   ```

2. **Проверять на противоречия:**
   ```
   Саша написал:
   - "API должен вернуть результат за < 100ms"
   - "Система должна обработать 100,000 элементов"
   
   Я спросил:
   "Это физически невозможно. Выбери одно."
   
   После обсуждения выяснилось:
   - На самом деле, нужно < 1 сек
   - Но с pagination: limit 20 элементов
   ```

#### Этап 6: Самостоятельные проекты (месяц 9-12)

**После года обучения я дал ему полный проект:**

```
Проект: Система аналитики для маркетинга

Требуемое:
1. Полное требование (Requirements Document)
2. Диаграммы (Use Cases, System Architecture)
3. Презентация для бизнеса
4. Technical specification для разработки
5. Test plan для QA
6. Presentation результатов
```

Саша справился!

### Ключевые уроки, которые я передал

#### #1: Никогда не верь первому предложению

```
Постоянно спрашиваю "Почему?"

Проект менеджер: "Нам нужна фича X"
Я: "Почему?"
ПМ: "Потому что это нужно клиентам"
Я: "А сколько клиентов?"
ПМ: "Ну, двое-трое просили"
Я: "Может быть, это не priority?"

Всегда копай глубже.
```

#### #2: Сложность часто скрыта

```
Петя говорит: "Просто добавь фильтр"

После анализа выясняется:
- Нужно 5 новых таблиц БД
- Нужны индексы (production performance issue)
- Нужно обновить frontend
- Нужны миграции (downtime?)
- Нужны тесты

Это не "просто".
```

#### #3: Нефункциональные требования часто забывают

```
Типичная ошибка новичка:
- Фокусируется только на функциональности
- "Может делать X, Y, Z"

Что забывает:
- Насколько это быстро?
- Насколько это безопасно?
- Что если это сломается?

Отличный аналитик спрашивает про NFR с самого начала.
```

#### #4: Пишите для людей, не для компьютеров

```
Плохо:
"Использовать RESTful API с JSON payload для синхронизации состояния"

Хорошо:
"API отправляет список заказов в формате JSON. Включает ID, сумму и статус.
 Пример ответа: {orders: [{id: 123, amount: 500, status: 'completed'}]}"

Хороший документ должны понимать:
- Разработчики
- QA
- Бизнес-пользователи
- Будущие аналитики
```

### Результаты наставничества (через год)

**Саша сейчас:**
- Может писать полные требования
- Проводит интервью с заинтересованными сторонами
- Выявляет скрытые нефункциональные требования
- Создаёт системные диаграммы
- Консультирует новичков

**Его карьерный путь:**
- Начинал как junior разработчик
- Через год стал System Analyst
- Сейчас является Senior Analyst (через 2 года)

### Что я применял в наставничестве

**Метод Сократа**
```
Я не говорил ему ответ.
Я задавал вопросы, пока он сам не понимал.

Вместо: "Это требование неправильное потому что X"
Я спрашивал: "А что произойдёт если X случится?"

Это помогло ему развить critical thinking.
```

**Постепенное усложнение**
```
Неделя 1: Простая фильтрация
Неделя 2: С performance требованиями
Неделя 3: Со scalability
Неделя 4: Со всеми аспектами
```

**Регулярный feedback**
```
Каждую неделю:
- 1-1 встреча (30 минут)
- Обсуждаем его работу
- Даю feedback
- Дам задачу на неделю
```

**Реальные проекты, не упражнения**
```
Вместо:
"Напиши требование для вымышленного проекта"

Я давал:
"Напиши требование для нашего реального проекта
(и оно будет использовано в production)"

Это мотивирует и учит ответственности.
```

### Советы при наставничестве

1. **Будьте терпеливы**
   - Новичок будет делать ошибки
   - Это нормально
   - Помогите учиться на ошибках

2. **Показывайте примеры**
   - "Вот как это делается хорошо"
   - "А вот плохой пример"
   - Сравнения помогают

3. **Давайте ответственность**
   - Постепенно увеличивайте сложность
   - Новичок должен чувствовать себя capable
   - Но не overwhelmed

4. **Документируйте процесс**
   - Создайте checklists
   - Шаблоны требований
   - Это поможет следующему новичку

5. **Будьте доступны**
   - Новичок должен знать, что может спросить
   - Но не спрашивать на каждом шаге
   - Это баланс

Расскажи про свой опыт наставничества

Комментарии (1)

Опыт наставничества: от новичка к система-аналитику

Контекст: развитие junior аналитика

История: Саша — junior бэкенд разработчик

Мой план наставничества

Этап 1: Обучение основам (месяц 1)

Этап 2: Раскопать нефункциональные требования (месяц 2-3)

Этап 3: Встречи с заинтересованными сторонами (месяц 4-5)

Этап 4: Написание документации (месяц 6)

Этап 5: Code Review требований (месяц 7-8)

Этап 6: Самостоятельные проекты (месяц 9-12)

Ключевые уроки, которые я передал

#1: Никогда не верь первому предложению

#2: Сложность часто скрыта

#3: Нефункциональные требования часто забывают

#4: Пишите для людей, не для компьютеров

Результаты наставничества (через год)

Что я применял в наставничестве

Советы при наставничестве