Дневник достижений#

Документ описывает методологию ведения дневника достижений — основного инструмента для сбора доказательств компетенций.

Зачем нужен дневник#

Зачем: Сбор доказательств компетенций для повышения грейда

Кто ведет: Совместно сотрудник + менеджер (collaborative approach)

Формат: Документ (Google Doc, Notion, Confluence), структурированный по критериям

Модель совместного ведения#

Почему не “сотрудник сам”#

  • ❌ Дискомфорт саморекламы (особенно в русской культуре)
  • ❌ Impostor syndrome: “Это не достижение, любой так мог бы”
  • ❌ Неравенство: экстраверты лучше презентуют себя → несправедливое преимущество
  • ❌ Менеджер не видит полной картины развития

Как работает совместная модель#

Сотрудник фиксирует “что сделал” (факты, без оценок):

  • Завершил проект X
  • Помог коллеге Y решить проблему Z
  • Написал документацию для модуля W
  • Провел презентацию / code review / инициативу

На 1-на-1 вместе с менеджером:

  • 📊 Определяют влияние (какие метрики улучшились, кому помогло)
  • 🎯 Связывают с критериями грейда (какие компетенции демонстрирует)
  • 📝 Формулируют доказательства (ссылки, feedback, данные)
  • ⚖️ Оценивают значимость для следующего грейда

Пример трансформации#

Сотрудник записал:
"Сделал рефакторинг модуля Отопление в сентябре-ноябре"

↓ На 1-на-1 менеджер помогает раскрыть:

"Рефакторинг legacy модуля Отопление
- Контекст: 5-летний код, сложный, без тестов, фичи добавлять долго
- Действия: Разбил на 8 этапов, покрыл тестами, выделил компоненты
- Результат:
  • Время разработки фичи: 2 недели → 3 дня (-78%)
  • Coverage: 70% → 85%
  • Баги в production: -40% за 3 месяца
  • Код используется как best practice
- Демонстрирует:
  • Технические навыки (работа с legacy, рефакторинг)
  • Влияние (улучшил velocity команды, качество кода)"

Роль менеджера#

  • Видит big picture: как работа вписывается в цели команды/продукта
  • Знает что важно для следующего грейда: подсказывает на чем акцентировать
  • Замечает “невидимую” работу: помощь коллегам, которую сотрудник не записал
  • Помогает сформулировать: переводит “сделал X” в “достиг Y, улучшил Z”
  • Добавляет контекст: сложность задачи, impact на бизнес

Что фиксировать#

Для каждого достижения записывайте:

1. Технические навыки#

  • Какие технологии / инструменты / подходы освоили
  • Сложные технические проблемы, которые решили
  • Code review: примеры качественного кода, архитектурных решений
  • Примеры: “Спроектировал и реализовал систему кэширования, сократил время отклика API на 60%”

2. Автономность и Ownership#

  • Проекты, которые вели самостоятельно (от дизайна до релиза)
  • Инициативы, которые предложили и реализовали
  • Примеры принятия решений при неопределенности
  • Примеры: “Самостоятельно спроектировал архитектуру модуля ‘Водоснабжение’, провел через ревью, реализовал за 2 месяца”

3. Влияние и лидерство#

  • Менторинг: кому помогали, какие результаты
  • Влияние на команду: процессы, которые улучшили, инициативы
  • Документация, которую создали и которую используют другие
  • Помощь коллегам: критические ситуации, code review, консультации
  • Примеры: “Провел 15 сессий code review для Junior разработчика, через 3 месяца он начал работать самостоятельно”

4. Бизнес-влияние#

  • Метрики: производительность, качество, экономия времени/ресурсов
  • Влияние на пользователей: feedback, adoption, удовлетворенность
  • Вклад в достижение целей команды/продукта
  • Примеры: “Оптимизация расчета сетей сократила время на 40%, что критично для крупных проектов (>1000 элементов)”

Структура записи (шаблон)#

### [Название достижения]
**Дата**: [месяц-год]
**Критерий**: [Технические навыки / Автономность / Влияние / Бизнес]

**Контекст**: Какая была проблема/задача/ситуация

**Действия**: Что конкретно сделали (ваша роль)

**Результат**: Что получилось (с метриками если возможно)

**Доказательства**: Ссылки на PR, документы, feedback от коллег/пользователей

Пример записи#

### Рефакторинг legacy модуля Вентиляция
**Дата**: Сентябрь-Ноябрь 2030
**Критерий**: Технические навыки, Влияние

**Контекст**: Модуль Вентиляция был написан 5 лет назад,
код сложный для понимания, много дублирования, тесты отсутствуют.
Новые фичи добавлять очень долго.

**Действия**:
- Проанализировал архитектуру, выявил проблемные места
- Разбил рефакторинг на 8 этапов для минимизации рисков
- Покрыл тестами критичные части (coverage 70% → 85%)
- Выделил 3 переиспользуемых компонента
- Провел knowledge sharing сессию для команды

**Результат**:
- Время на добавление новой фичи: 2 недели → 3 дня
- Code review approval time: 2 дня → 4 часа (код стал понятнее)
- Баги в production: -40% (за следующие 3 месяца)
- Код теперь используется как best practice

**Доказательства**:
- PR: [ссылка на основной PR и 8 последующих]
- Feedback от коллег: [цитаты из code review]
- Metrics: [скриншот графика bugs, времени разработки]

Как часто пополнять#

  • Регулярно: После завершения значимой задачи/проекта (не реже 1 раза в месяц)
  • В процессе работы: Фиксируйте сразу (не откладывайте, забудете детали)
  • Перед 1-на-1: Просмотрите дневник, обсудите с менеджером что добавить

Процесс на регулярных 1-на-1#

Каждую встречу (15-20 минут на дневник):

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

Пример диалога на 1-на-1#

Сотрудник: "Я помогал Марии с багом в модуле Отопление,
            потратил примерно 3 часа"

Менеджер: "Отличный пример менторинга! Давай зафиксируем.
          Что конкретно было? Какой результат?"

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

Менеджер: "Хорошо. А она теперь может сама такие баги находить?"

Сотрудник: "Да, на следующий день уже сама нашла похожую проблему"

Менеджер: "Отлично! Значит это демонстрирует 'Влияние и лидерство'
          для Middle II - ты не просто решил проблему, а научил человека.
          Записываем:

          'Менторинг Junior разработчика: помог найти баг в расчетах,
          показал методологию отладки через тесты.
          Результат: через 1 день самостоятельно нашла аналогичную проблему.
          Демонстрирует: Влияние (менторинг), Технические навыки (debugging)'"

Помощь менеджера (роль curator)#

Менеджер помогает:

  • Определить что фиксировать: Что важно для следующего грейда
  • Сформулировать влияние: Переводит “сделал X” в “улучшил Y на Z%”
  • Найти метрики: Подсказывает где взять данные (dashboard, analytics)
  • Заметить “невидимое”: Напоминает про помощь коллегам, ревью, которые сотрудник забыл упомянуть
  • Понять пробелы: Какие компетенции есть, каких не хватает для повышения
  • Добавить контекст: Насколько сложна была задача, почему это важно для бизнеса

Признание от коллег#

Дополнительный механизм для фиксации “невидимой” работы:

Вариант 1: Менеджер собирает feedback от коллег#

  • На регулярных 1-на-1 менеджер спрашивает: “Кто из коллег тебе помогал на этой неделе?”
  • Менеджер фиксирует в дневниках обоих (помогающего и получающего помощь)
  • Естественный процесс без публичности

Вариант 2: Квартальный опрос коллег#

  • Раз в квартал менеджер спрашивает команду (анонимно или лично):
    • “С кем из коллег тебе было особенно хорошо работать? Почему?”
    • “Кто помог тебе в работе? Конкретные примеры?”
  • Менеджер добавляет в дневники как “отзыв от коллег”

Что это дает#

  • ✅ Фиксируется помощь команде (code review, консультации, поддержка)
  • ✅ Интроверты получают признание (даже если сами не озвучивают)
  • ✅ Без публичной саморекламы (естественный процесс)
  • ✅ Укрепляет командный дух

Пример записи с отзывом коллеги#

### Помощь с критичным багом у клиента
**Дата**: Январь 2025
**Критерий**: Влияние, Технические навыки

**Контекст**: В пятницу обратился клиент: проект на 500+ элементов не открывается после обновления до новой версии. Срочно нужно исправить до понедельника — у них сдача проекта.

**Действия**: Остался после работы, проанализировал логи, нашёл проблему в миграции данных. Подготовил патч и инструкцию по восстановлению.

**Результат**: Клиент восстановил проект в субботу утром, успел к сдаче.

**Отзыв коллеги** (Мария, поддержка): "Алексей оперативно подключился к решению проблемы, хотя это была не его зона ответственности. Благодаря его помощи удержали клиента"

Культурные особенности и психология дневника#

Проблема: Дискомфорт саморекламы#

В русской/славянской культуре:

  • 🚫 “Хвастаться” = неприлично
  • 🚫 “Я сам себя хвалю” = неловко и странно
  • 🚫 Скромность ценится выше самопрезентации
  • 🚫 Боязнь показаться самоуверенным перед коллегами

Психологический барьер:

“Если я напишу ‘Я сделал отличную работу’, коллеги подумают что я зазнайка. Лучше промолчу, менеджер и так знает что я делаю.”

Результат: Интроверты и скромные люди недо-документированы → несправедливо проигрывают при повышении

Решение: Переосмысление дневника#

Дневник ≠ самореклама, дневник = документация

Вы не хвастаетесь, вы фиксируете факты:

  • ❌ Не надо: “Я сделал гениальный рефакторинг!”
  • ✅ Надо: “Рефакторинг модуля Х. Результат: время разработки -78%”

Аналогия: Ведете дневник как лабораторный журнал:

  • Ученый фиксирует эксперименты и результаты
  • Это не хвастовство, это научная практика
  • Дневник достижений = журнал вашего профессионального роста

Совместная модель снимает дискомфорт:

  • Вы говорите что сделали (факт)
  • Менеджер помогает сформулировать влияние (оценка)
  • Результат: объективная документация без “самовосхваления”

Проблема: Синдром самозванца#

Что происходит:

  • “Это не достижение, любой так мог бы”
  • “Задача была несложная, не стоит записывать”
  • “Другие делают круче, мне стыдно записывать такое”

Особенно у:

  • Junior/Middle разработчиков
  • Людей с высокими стандартами к себе
  • Тех кто пришел из топовых компаний/вузов

Результат: Недо-фиксация достижений → менеджер не видит полной картины → повышение откладывается

Решение: Менеджер помогает калибровать#

Роль менеджера — показать значимость:

Сотрудник: "Я просто починил баг в расчетах, ничего особенного"

Менеджер: "Стоп. Этот баг блокировал клиента 2 недели,
          3 Senior разработчика не могли найти. Ты нашел за 1 день.
          Это демонстрирует сильные навыки debugging и persistence.
          Записываем как достижение"

Практика: Спросите менеджера

  • “Стоит ли это записать в дневник?”
  • Менеджер знает контекст, сравнивает с ожиданиями грейда
  • Его задача — помочь увидеть значимость вашей работы

Проблема: Неравенство интровертов и экстравертов#

Неравенство навыков самопрезентации:

Экстраверт:

  • Легко рассказывает о достижениях на 1-на-1
  • Пишет подробные записи с эмоциями
  • Активно делится success stories в команде
  • → Дневник богатый и детальный

Интроверт:

  • Стесняется говорить о своих успехах
  • Пишет сухо: “Сделал X, Y, Z”
  • Не афиширует достижения
  • → Дневник скудный, хотя работа отличная

Несправедливость: Продвижение зависит не от качества работы, а от коммуникативных навыков

Решение: Менеджер — уравнитель#

Менеджер выравнивает:

  1. Задает вопросы интровертам:

    • “Расскажи подробнее про проект X”
    • “Какие были сложности?”
    • “Кому это помогло?”

  2. Помогает сформулировать:

    • Интроверт говорит факты → менеджер превращает в story
    • Добавляет контекст который интроверт опустил

  3. Замечает “невидимое”:

    • Помощь коллегам, которую интроверт не упомянул
    • Code review, который “и так понятно что делал”

Результат: Все сотрудники документированы справедливо, независимо от навыков самопрезентации

Проблема: Выбор только “заметных” задач#

Что происходит:

  • 🔴 Все хотят новые фичи (попадут в дневник, видно результат)
  • 🔴 Никто не хочет: багфиксы, tech debt, поддержку, дежурства
  • 🔴 Конкуренция за “престижные” проекты → конфликты
  • 🔴 Игнорируют помощь команде (не так заметно для promotion)

Пример:

“Я возьму разработку нового модуля Канализация (круто для дневника), а поддержку старого модуля пусть кто-то другой делает”

Вред для команды:

  • Критичная работа не делается (все хотят “блестящие” задачи)
  • Младшие застревают на “грязной” работе (senior’ы берут интересное)
  • Разрушается коллаборация (конкуренция вместо teamwork)

Решение: Сбалансированная оценка#

1. Менеджер распределяет задачи (не всегда свободный выбор)

  • Каждый делает свою долю “невидимой” работы: поддержка, дежурства, багфиксы
  • Престижные проекты распределяются справедливо (rotation)

2. В дневнике фиксируется ВСЯ значимая работа:

✅ Фичи (да, заметно, но не единственное) ✅ Багфиксы (особенно сложные/критичные) — демонстрирует debugging, resilience ✅ Tech debt (рефакторинг, тесты, документация) — демонстрирует качество, long-term thinking ✅ Production support (инциденты, hotfixes) — демонстрирует ownership, reliability ✅ Помощь команде (code review, менторинг, консультации) — демонстрирует лидерство ✅ Process improvements (CI/CD, tooling, автоматизация) — демонстрирует инициативу

3. Для promotion нужен БАЛАНС (не только “блестящие” проекты):

Пример требований для Senior:

  • ✅ Доставил 2-3 значимых фичи/проекта
  • ✅ И регулярно делал quality work (рефакторинг, тесты, документация)
  • ✅ И помогал команде (менторинг, code review)
  • ✅ И поддерживал production (инциденты, багфиксы)

Если только фичи без команды:

“Технически сильный, но не демонстрирует лидерство и влияние на команду. Не готов к Senior (где важен teamwork и менторинг)”

4. Peer recognition фиксирует “невидимую” работу:

  • Коллеги благодарят за помощь → попадает в дневник
  • Code review, консультации, поддержка — все видимо через благодарности

5. Менеджер следит за балансом workload:

  • Если кто-то берет только “престижное” → разговор о team contribution
  • Если кто-то застрял на “грязной” работе → даются развивающие задачи

Практики борьбы с дискомфортом#

Для сотрудника#

✅ Переосмыслите: Дневник = documentation, не хвастовство

  • Вы фиксируете факты для объективной оценки
  • Это профессиональная практика (как у ученых, врачей)

✅ Пишите факты, не оценки:

  • ❌ “Я сделал великолепную работу”
  • ✅ “Оптимизировал запрос. Время выполнения: 30 сек → 2 сек”

✅ Используйте формулу “Контекст → Действия → Результат”:

  • Это структура, не самовосхваление
  • Менеджер помогает заполнить пробелы

✅ Просите помощь менеджера:

  • “Стоит ли это записать?”
  • “Как лучше сформулировать?”
  • Менеджер калибрует значимость

✅ Помните: недо-документация вредит вам

  • Менеджер не знает всё что вы делаете
  • Без доказательств = нет повышения (даже если заслужили)

Для менеджера#

✅ Создайте безопасную атмосферу:

  • “Дневник — это не хвастовство, это наш рабочий инструмент”
  • “Я помогу сформулировать, не стесняйтесь”

✅ Активно помогайте интровертам:

  • Задавайте вопросы, вытягивайте детали
  • Сами предлагайте что записать (“А давай зафиксируем…”)

✅ Показывайте ценность “невидимой” работы:

  • “Твоя помощь Марии — это отличный пример менторинга для Senior грейда”
  • “Багфикс который ты сделал — демонстрирует сильный debugging”

✅ Калибруйте восприятие:

  • Если сотрудник недооценивает работу → объясните почему это значимо
  • Если переоценивает → мягко покажите реальный уровень

✅ Следите за балансом задач:

  • Все делают свою долю “невидимой” работы
  • Престижные проекты распределяются справедливо

✅ Регулярно напоминайте:

  • “Что мы добавим в дневник сегодня?”
  • Не ждите пока сотрудник сам вспомнит

Связанные документы#