Как написать пост-мортем проекта и добавить его в портфолио: пошаговое руководство

Вы закончили проект. Сроки сдвинуты, бюджет улетел в трубу, или, наоборот, все прошло идеально, но вы не понимаете, почему. В голове крутится мысль: «Что я сделал не так?» или «Почему это сработало?». Большинство разработчиков и менеджеров просто закрывают тикет и забывают о деталях. Но те, кто хочет расти и показывать свою ценность на рынке труда, превращают этот опыт в документ - пост-мортем. Это не отчет для начальника. Это ваш личный инструмент роста и мощный артефакт для портфолио.

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

Суть пост-мортема: больше чем жалоба

Пост-мортем is a retrospective analysis document that reviews the outcomes of a project to identify lessons learned and areas for improvement. По сути, это автопсихологический разбор полетов. Главная цель - не найти виноватого (это путь к токсичной атмосфере), а найти причины. Если сервер упал, потому что забыли обновить библиотеку, виноват не конкретный человек, а процесс деплоя. Пост-мортем помогает отделить человека от процесса.

Когда вы пишете такой документ, вы демонстрируете системное мышление. Вы показываете, что смотрите на систему целиком: люди, процессы, технологии. Для работодателя это сигнал того, что вы не просто «кодер», который ждет задачи, а специалист, способный улучшать среду вокруг себя.

Структура идеального документа

Не стоит писать простыню текста. Рекрутеры и коллеги ценят структуру. Используйте классическую схему, которая отвечает на три вопроса: Что случилось? Почему? Что делать дальше?

1. Контекст проекта: Краткое описание цели, сроков, команды и ограничений. Без воды. Например: «Разработка мобильного приложения для доставки еды. Срок: 3 месяца. Команда: 2 бэкенда, 1 фронтенд, 1 дизайнер».
2. Фактические результаты: Сравните план с реальностью. Какие KPI достигнуты? Какой бюджет потрачен? Какие сроки соблюдены? Здесь нужны цифры. «Задержка на 2 недели», «Бюджет превышен на 15%».
3. Анализ причин (Root Cause Analysis): Самый важный блок. Используйте метод «5 почему». Если задержка была из-за ожидания дизайна, спросите: почему дизайн опоздал? Потому что клиент менял требования. Почему клиент менял требования? Потому что не был вовлечен на этапе брифа. Вот это и есть корневая причина.
4. Уроки и действия: Конкретные шаги на будущее. Не «будем лучше общаться», а «ввести еженедельные демо-показы клиенту начиная со второй недели разработки».

Как превратить текст в актив портфолио

Просто сохранить файл в Google Docs недостаточно. Чтобы пост-мортем работал на вас, его нужно правильно оформить. Представьте, что вы рассказываете историю. Люди любят истории с поворотом и решением проблемы.

• Визуализация: Добавьте графики скорости команды (velocity chart) или диаграмму Ганта, если речь о сроках. Изображения привлекают взгляд быстрее текста.
• Честность: Укажите свои ошибки. Если вы плохо оценили сложность модуля авторизации, напишите об этом. Покажите, как вы это поняли и как теперь оцениваете такие задачи. Честность вызывает доверие.
• Фокус на решении: Не останавливайтесь на проблеме. Обязательно покажите, что вы сделали, чтобы она не повторилась. Возможно, вы написали скрипт автоматизации тестов или изменили шаблон постановки задач.

Где размещать? На GitHub в отдельном репозитории «Case Studies» или на личном сайте. Если нет сайта, прикрепите PDF к резюме в разделе «Достижения» или «Кейсы». Важно, чтобы документ был доступен по ссылке или во вложении, когда вы отправляете резюме.

Типичные ошибки при написании

Даже опытные специалисты часто допускают просчеты в формате пост-мортема. Вот главные ловушки, которых стоит избегать:

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

Пример структуры кейса

Давайте посмотрим на скелет такого документа. Допустим, вы работали над миграцией базы данных с MySQL на PostgreSQL.

1. Резюме

Миграция выполнена за 4 дня вместо запланированных 7. Простой сервиса составил 2 часа вместо ожидаемых 4. Данные сохранены без потерь.

2. План vs Реальность

План предполагал полную остановку сервиса на ночь. Реальность показала, что можно использовать репликацию и минимизировать даунтайм до 2 часов. Бюджет на облачные ресурсы сэкономлен на 20%.

3. Анализ проблем

Основная проблема: несовместимость синтаксиса запросов. Мы потратили 2 дня на ручную правку SQL-скриптов. Корневая причина: отсутствие этапа предварительного аудита кода перед миграцией.

4. Выводы и действия

• Ввести обязательный этап статического анализа SQL перед крупными миграциями.
• Написать скрипт автоматической конвертации типов данных.
• Обновить документацию по стандартам работы с БД.

Такой формат компактен, логичен и сразу показывает вашу способность анализировать ситуацию.

Как интегрировать в портфолио

Портфолио - это витрина. Пост-мортем здесь играет роль «подкапа», который доказывает вашу компетентность. Не прячьте этот документ в конце списка проектов. Выделите ему отдельную секцию «Кейсы и уроки» или добавьте ссылку в карточке соответствующего проекта.

Если вы фрилансер или работаете на нескольких проектах одновременно, создайте общий хаб знаний. Назовите его «Lessons Learned Hub». Туда можно добавлять короткие заметки (post-mortem notes) по каждому проекту. Это покажет вашу привычку к непрерывному обучению.

Для технических специалистов важно связать урок с технологией. Например, если урок связан с Docker, упомяните, как изменение конфигурации контейнеров повлияло на время сборки. Это поможет SEO-оптимизации вашего профиля, если вы используете LinkedIn или личные блоги.

Частые вопросы