Как честно описывать свой вклад в проекты: фреймворк для резюме, портфолио и собеседований

Главная ошибка при описании опыта — не в том, что люди врут, а в том, что они смешивают «что сделал проект» с «что сделал я». Рекрутеры и технические лиды за секунды видят разницу между «мы запустили платформу за 3 месяца» и «я спроектировал API, который выдержал пиковую нагрузку в 10к RPS». Вторая фраза получает приглашение на собеседование. Первая — уточняющий вопрос, на который многие не знают ответа.

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

Почему преувеличение работает против тебя

Есть три уровня проверки твоего вклада:

• Скрининг резюме (10–30 секунд): ищут конкретные глаголы действия и метрики. «Участвовал в разработке» — шум. «Рефакторил модуль платежей, сократил latency p99 с 800 до 120 мс» — сигнал.
• Техническое собеседование (30–60 минут): просят пройтись по архитектуре, объяснить альтернативы, назвать сложности. Если в резюме «проектировал систему», а на собеседовании не можешь нарисовать схему и обосновать выбор БД — доверие рушится.
• Reference check / онбординг (первые недели): ожидания от описания встречаются с реальностью. Разрыв ведёт к провалу испытательного срока или потере репутации.

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

Базовый принцип: разделяй роль и результат

Любой проект имеет результат (outcome) — то, что получилось в итоге. И имеет вклады (contributions) — действия конкретных людей. Твоя задача — описать свой вклад так, чтобы читатель мог восстановить причинно-следственную цепочку: твоё действие → изменение в системе/процессе → измеримый эффект.

Шаблон проверки: если убрать твое имя из описания, останется ли понятным, что именно ты сделал? Если остаётся только «проект успешно запущен» — описание бесполезно.

Фреймворки структурирования: STAR, CAR, PAR

Все популярные фреймворки (STAR — Situation, Task, Action, Result; CAR — Challenge, Action, Result; PAR — Problem, Action, Result) решают одну задачу: заставить тебя писать действие и результат, а не контекст.

Как применять STAR без воды

Компонент	Вопрос для самопроверки	Плохой пример	Хороший пример
Situation / Context	Какое ограничение или контекст важен для понимания сложности?	В нашей компании было много проектов	Легаси-монолит на PHP 5.6, 0 тестов, деплой раз в месяц
Task / Challenge	Какую задачу решали ты лично, а не команда?	Нужно было переписать всё	Выделить сервис авторизации в отдельный микросервис за 6 недель
Action	Какие конкретные шаги сделал ты? Глаголы: спроектировал, написал, внёс, настроил, привёл, договорился.	Работал над микросервисом	Спроектировал контракт API (OpenAPI 3.0), написал реализацию на Go, настроил CI/CD в GitLab, ввёл контрактные тесты, провел код-ревью 12 PR коллег
Result	Что изменилось измеримо? Метрика + база сравнения + горизонт.	Сервис запустили	Деплой стал ежедневным, p99 latency авторизации упал с 450 до 40 мс, инцидентов по auth за квартал — 0 против 12 до миграции

Правило: 60–70% объёма описания — Action, 20–30% — Result, 10% — Context. Контекст нужен только чтобы показать сложность (нагрузка, легаси, дедлайн, неопределённость).

Глаголы, которые работают, и глаголы-маски

Выбор глагола сразу сигнализирует о уровне ответственности. Сравни пары:

• Участвовал / Помогал / Поддерживал — пассивная роль, неясно, что именно сделал ты.
• Разработал / Реализовал / Спроектировал / Ввёл / Оптимизировал / Автоматизировал / Привёл к / Договорился / Настроил / Написал / Рефакторил / Покрыл тестами — активная роль, понятный артефакт.

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

Если был индивидуальным контрибьютором в команде: взял в работу тикеты по X, реализовал Y, покритил Z, предложил улучшение W, которое команда приняла.

Работа с командными достижениями: «Мы» vs «Я»

Скрывать командную работу нельзя — это подозрительно. Но писать только «мы» — бесполезно. Используй конструкцию: «Команда достигла X, мой вклад — Y».

Примеры перевода «мы» в «я»:

• Мы внедрили CI/CD → Я написал пайплайн для 5 сервисов (GitLab CI), ввёл стадию contract tests, сократил время деплоя с 40 до 12 минут.
• Мы перешли на микросервисы → Я выделил 3 bounded context, спроектировал асинхронное взаимодействие через Kafka, написал общую библиотеку идемпотентности.
• Мы улучшили качество кода → Я ввёл обязательный SonarQube gate (coverage >80%, 0 critical smells), настроил pre-commit хуки, провел воркшоп по чистому коду для 8 разработчиков.

Если ты не помнишь деталей — не пиши. Лучше одно конкретное действие, чем три размытых «участвовал».

Цифры: как количественно описать вклад без выдумки

Цифры доверяют больше слов, но только если они верифицируемы тобой же через полгода. Не придумывай. Используй то, что есть в системах мониторинга, CI/CD, тикет-системах, гите, бизнес-отчётах.

Что считать (и где брать данные)

• Производительность: latency (p50, p95, p99), throughput (RPS), время билда/деплоя, время запуска тестов — Grafana, Datadog, CI логи.
• Надёжность: количество инцидентов, MTTR, availability (SLA/SLO), error rate — инцидент-менеджмент (PagerDuty, Opsgenie), логи.
• Качество кода: coverage, количество багов в проде за период, code churn, технический долг (SonarQube) — CI артефакты, баг-трекер.
• Бизнес-метрики: конверсия, выручка, retention, стоимость инфраструктуры — аналитика (Amplitude, Mixpanel, внутренние дашборды), фин-отчёты.
• Процессные: lead time, cycle time, deployment frequency, change failure rate — Jira/GitLab метрики, DORA metrics.
• Объём работы: строк кода (осторожно, только как контекст), количество PR, ревью, закрытых тикетов, мигрированных таблиц/эндпоинтов — Git/GitLab/GitHub статистика.

Правила использования цифр

1. Всегда указывай базу сравнения: «ускорил в 2 раза» бесполезно без «было 400 мс, стало 200 мс».
2. Указывай горизонт: «за квартал», «за 6 месяцев после релиза», «в первый месяц».
3. Разделяй корреляцию и причинность: «после моего рефакторинга конверсия выросла на 5%» — слабо. «убрал блокирующий вызов стороннего API на критическом пути, latency чекаута упал с 3с до 400мс, A/B тест показал +3.2% конверсии» — сильно.
4. Не округляй до нелепости: «сэкономил $1M» требует расчёта. «снизил инфраструктурные расходы на 18% ($12к/мес) за счёт правки instance types и включения spot-инстансов» — проверяемо.
5. Если точной цифры нет — дай диапазон или порядок: «обрабатывал ~500 тикетов за год», «поддерживал кластер из 20+ нод». Добавь оговорку: «по данным GitLab за период X–Y».

Типичные паттерны преувеличения и как их исправить

Паттерн	Как выглядит	Что написать вместо этого
Присвоение командного результата	«Я запустил платформу, которая приносит $10M/год»	«В команде из 6 человек я отвечал за billing-модуль: спроектировал схему БД, реализовал интеграцию со Stripe, покрыл 95% тестами. Платформа приносит $10M/год.»
Сокрытие контекста масштаба	«Управлял миграцией БД» (на самом деле — ALTER TABLE на 10к строк в dev)	«Выполнил миграцию схемы пользователей (2.5M записей) с zero-downtime через dual-write стратегию, координировал с 3 командами-зависимостями»
Глаголы-обёртки	«Обеспечил безопасность приложения»	«Ввёл CSP заголовки, настроил WAF правила для OWASP Top 10, провел threat modeling для нового платежного потока, закрыл 12 уязвимостей из SAST отчёта»
Результаты без действий	«Сократил расходы на облако на 30%»	«Проанализировал Cost Explorer, выявил 40% idle-ресурсов, настроил autoscaling policies, перевёл batch-д джобы на spot-инстансы, внедрил еженедельный finops-ревью»
Технологии как достижение	«Использовал Kubernetes, Kafka, Redis, gRPC»	«Развернул k8s-кластер (EKS) под 15 сервисов, настроил HPA/VPA, спроектировал топики Kafka для event sourcing, ввёл distributed tracing (Jaeger)»

Сценарии применения: адаптируй описание под цель

Резюме (CV) — сканируемость за 15 секунд

• Один проект — 3–5 буллетов максимум.
• Первый буллет — самый сильный результат + действие.
• Технологии в скобках или отдельной строкой skills, не в каждом буллете.
• Формат: [Глагол действия] + [Артефакт/Область] + [Метрика/Эффект] + [Контекст сложности].

Пример:

• Спроектировал и реализовал систему асинхронной обработки заказов на Go + Kafka (15к событий/сек, p99 < 200 мс), заменил синхронные вызовы между 4 сервисами — исключил каскадные отказы.
• Ввёл контрактное тестирование (Pact) для 12 микросервисов, устранил класс integration bugs — 0 регрессов в проде за 2 квартала.
• Настроил GitOps (ArgoCD) для 3 окружений, сократил lead time деплоя с 2 дней до 15 минут, делегировал деплой разработчикам.

Портфолио / кейс-стади — глубина для эксперта

Здесь читатель готовится потратить 5–10 минут. Структура:

1. Проблема: что было больно, почему старый подход не масштабировался.
2. Ограничения: дедлайн, бюджет, легаси, команды, компромиссы.
3. Твоё решение: архитектура, ключевые решения, почему выбрал именно так (альтернативы и причины отказа).
4. Реализация: твои личные артефакты — код, конфиги, диаграммы, документы, скрипты.
5. Результаты: метрики до/после, инциденты, обратная связь пользователей/бизнеса.
6. Ретроспектива: что бы сделал иначе, какие технические долги остались, чему научился.

Ретроспектива — сильный сигнал зрелости. Она показывает, что ты рефлексируешь, а не просто выполняешь.

Performance review / самооценка — связь с целями компании

Здесь важно показать вклад в OKR/KPI команды и организации. Структура:

• Цель команды/компании: например, «снизить Time-to-Market для новых фич до 2 недель».
• Твоя инициатива: что предложил/инициировал.
• Твоя доставка: что конкретно сделал.
• Влияние на метрику цели: как твой вклад сдвинул иглу.
• Побочные эффекты: менторство, документация, улучшение процессов, найм, knowledge sharing.

Поведенческие вопросы на собеседовании — рассказ за 2–3 минуты

Используй сжатый STAR. Говори так, будто объясняешь коллеге за кофе:

«Был монолит на PHP, деплой раз в месяц, любой баг — откат всего сайта. Я предложил вынести авторизацию в отдельный сервис. Спроектировал API, написал на Go, настроил CI/CD, ввёл контрактные тесты. Самое сложное было — миграция сессий без даунтайма: сделал dual-write с feature flag, катил 2 недели. Результат: деплой стал ежедневным, инцидентов по auth нет уже полгода, команда релиза сгорела от счастья».

Готовь 5–7 таких историй под основные компетенции: техническое лидерство, решение конфликта, работа с неопределённостью, ошибка и урок, масштабирование, рефакторинг, введение практики.

Чек-лист самопроверки перед отправкой

Прогони каждое описание проекта по этим вопросам. Если на любой пункт «нет» — переработай.

1. Есть ли хотя бы один конкретный глагол действия, обозначающий мой артефакт?
2. Чётко ли разделено: что сделал проект / команда, а что сделал я?
3. Есть ли измеримый результат с базой сравнения и горизонтом?
4. Могу ли я нарисовать архитектуру / привести код / показать конфиг за 2 минуты на собеседовании?
5. Могу ли я назвать 2–3 альтернативы, которые рассматривал, и почему отказался?
6. Могу ли я назвать конкретную сложность/блокер и как её решил?
7. Нет ли глаголов-масок («участвовал», «помогал», «обеспечил») без конкретики рядом?
8. Соответствует ли уровень ответственности в описании моему реальному грейду?
9. Если убрать моё имя — останется ли понятным, что именно я сделал?
10. Готов ли я подтвердить каждую цифру ссылкой на дашборд/тикет/гит?

Работа с неопределённостью: когда цифр нет

Бывает: стартап закрылся, доступы потеряны, метрики не собирались, проект на стадии R&D. Не придумывай. Используй качественные ориентиры:

• Сложность: «мигрировал 15 таблиц с zero-downtime», «интегрировал 3 сторонних API с разными SLA», «поддержал онлайн 50к пользователей на 2-х нодах».
• Качество: «покрыл 90% нового кода тестами», «0 критических багов в проде за 6 месяцев», «провел 40+ код-ревью».
• Скорость/процесс: «сократил время онбординга с 2 недель до 3 дней через документацию и скрипты», «ввёл еженедельный tech radar, команда начала пробовать 2 новые библиотеки в квартал».
• Признание: «решение принято как стандарт для 3-х команд», «доклад на внутренней конференции (50+ слушателей)», «номинирован на internal award».

Добавляй оговорку: «Метрики бизнеса на момент ухода не публиковались, технические метрики подтверждаются логами CI/CD за период X–Y».

Ошибки, которые стоят оффера

• Описывать технологии, а не решения. «Использовал Kubernetes» ничего не говорит. «Развернул EKS кластер для 10 сервисов, настроил IRSA, Network Policies, ExternalDNS, настроил автоскейлинг под нагрузку Black Friday» — говорит.
• Писать про «ответственность за» вместо «сделал». «Отвечал за CI/CD» — слабо. «Настроил пайплайны для 8 репозиториев, ввёл security scanning (Trivy, SAST), сделал deploy preview для каждого PR» — сильно.
• Игнорировать неудачи. Проект провалился / не запустили / откатили. Напиши: «Пilot не прошёл в прод из-за изменений приоритетов бизнеса. Мой код покрыт тестами, документация передана команде, архитектурные решения использованы в следующем проекте». Это показывает профпригодность.
• Один шаблон для всех проектов. Разные проекты — разные акценты. Один — про масштаб, другой — про скорость доставки, третий — про качество/безопасность, четвёртый — про менторство/процессы.

Практический следующий шаг: аудит твоего текущего резюме

1. Открой резюме / профиль LinkedIn / портфолио.
2. Выдели каждый буллет проекта.
3. Примени чек-лист из 10 пунктов выше.
4. Перепиши слабые буллеты по формуле: Глагол + Артефакт + Метрика + Контекст.
5. Подготовь 3–5 рассказов по STAR для устного собеседования.
6. Попроси сильного коллегу/ментаора прочитать и задать уточняющие вопросы: «А что именно ты сделал здесь?», «Откуда эта цифра?», «А какая была альтернатива?».

Честное описание вклада — не скромность, а профессиональная гигиена. Оно экономит время всем: рекрутеру на скрининге, тебе на собеседовании, новому работодателю на онбординге. И именно честные описания приводят к офферам, где твой реальный опыт решает реальные проблемы.