Как заполняешь wiki?

Документирование в Wiki: стратегия сохранения знаний

Почему wiki критична для PM

Wiki — это не для галочки. Это инвестиция в будущее: когда ты уйдёшь, когда новый PM заступит, когда инженер забудет почему именно так архитектура. Хорошо заполненная wiki = месяцы экономии на onboarding'е.

1. Структура Wiki

Я организую wiki по уровням абстракции:

📚 Wiki
├── 🏢 Company
│   ├── Mission & Values
│   ├── Org Chart
│   └── Decision Log
├── 📦 Product
│   ├── Vision & Strategy
│   ├── Roadmap
│   ├── Features (по модулям)
│   └── Glossary (единые термины)
├── 🔧 Technical
│   ├── Architecture
│   ├── API Documentation
│   └── Database Schema
├── 📊 Analytics
│   ├── North Star Metrics
│   ├── Dashboard Guide
│   └── Key Reports
├── 💼 Operations
│   ├── Processes
│   ├── Meetings Schedule
│   └── Runbooks (что делать при проблеме X)
└── 📚 Archive
    ├── Old Features
    └── Cancelled Ideas

Главное правило: если информация нужна больше одному человеку → в wiki.

2. Что писать в каждый раздел

2.1 Vision & Strategy

Это самый важный документ. Он должен ответить на вопросы:

• Что мы строим? (описание продукта в 1 параграф)
• Почему? (проблема, которую решаем)
• Для кого? (целевая аудитория)
• Как узнаем, что добились? (ключевые метрики)
• На сколько лет видим будущее? (обычно 3-5 лет)

Пример:

# Product Vision

## Что мы строим
Платформа для управления подписками в мобильных приложениях. 
Система включает аналитику, A/B тестирование, управление ценами и интеграцию 
с платёжными системами.

## Проблема
- Разработчики тратят месяцы на кодирование платежей
- Не знают оптимальную цену подписки
- Теряют 20% пользователей из-за сложности платежа

## Целевая аудитория
Разработчики мобильных приложений (10k+ DAU), которые хотят монетизировать.

## Ключевые метрики (North Star)
- MRR (Monthly Recurring Revenue): растёт на 20% MoM
- Customer Retention: >85% за год
- NPS: >50
- Time to Launch: < 1 дня

## Стратегия на 3 года
- Год 1: базовая функциональность, первые 100 клиентов
- Год 2: расширение интеграций, 1000 клиентов
- Год 3: ML-рекомендации цены, IPO или EXIT

2.2 Roadmap

Рoadmap — это путь от сегодня к видению.

# Product Roadmap 2025

## Q1 2025
- [ ] Поддержка платежей Apple Pay (3 недели)
- [ ] Push-уведомления об истечении подписки (1 неделя)
- [ ] Аналитика чёрна в реальном времени (4 недели)

## Q2 2025
- [ ] A/B тестирование цены (5 недель)
- [ ] Интеграция с Salesforce (3 недели)

## Q3 2025
- [ ] Dunning (автоматический повтор платежей) — BACKLOG
- [ ] ML-рекомендации цены — RESEARCH

## Cancelled
- Мобильное приложение (решили не делать, API достаточно)

2.3 Features Documentation

Для каждой фичи нужен документ:

# Feature: Push Notifications for Subscription Expiry

## Objective
Уменьшить churn на 5% через напоминание пользователям перед истечением 
подписки.

## User Story
Как пользователь приложения X, я хочу получить уведомление за день до 
конца моей подписки, чтобы не потерять доступ к премиум-контенту.

## Success Metrics
- Delivery rate: >95% (push дошла до девайса)
- Open rate: >20% (пользователь открыл уведомление)
- Conversion rate: >10% (пользователь сделал renewal)
- Churn reduction: 3-5% (вспомогательная метрика)

## Technical Details
- API endpoint: POST /v1/subscriptions/{id}/send-expiry-notification
- Timing: T-24 часа от expiry date
- Supported platforms: iOS, Android, Web

## Edge Cases
- Что если пользователь уже возобновил? (не шлём)
- Что если отключил уведомления? (уважаем выбор)
- Что если временная зона пользователя не известна? (отправляем в UTC)

## Status: SHIPPED (Jan 15, 2025)
- Adoption: 65% пользователей включили
- Delivery rate: 97%
- Open rate: 23%
- Churn reduction: +4.2% (ниже ожидания 5%, но в пределах нормы)

2.4 Decision Log

Это журнал важных решений с их обоснованием. Спасает часы объяснений новичкам.

# Decision Log

## Решение #45: Использовать GraphQL вместо REST
Дата: 2024-12-01
Делали: CEO, CTO, PM

### Контекст
Наш REST API медленный. Фронтенд делает 10 запросов вместо 1.

### Варианты
1. Оптимизировать REST (меньше данных в ответе)
2. Использовать GraphQL (клиент сам выбирает данные)
3. Создать специализированные эндпоинты (решение за решением)

### Выбрали
GraphQL (вариант 2)

### Обоснование
- Гибкость: фронтенд не зависит от бэка
- Performance: 10 запросов → 1 запрос
- Scalability: легко добавлять новые поля
- Trade-off: нужно время на переписывание

### Результат
- Скорость фронтенда улучшилась на 3x
- Онбоардинг новых инженеров теперь медленнее (нужно учить GraphQL)

## Решение #46: ...

3. Как заполнять wiki регулярно

Правило: Документируй СРАЗУ, не потом

Если ты сейчас решил что-то:

• Потратив 2 минуты, напишешь в wiki
• Завтра потратишь 20 минут, объясняя новичку
• На следующей неделе потратишь час на Slack обсуждениях

Правило: 2 минуты сейчас = 1 час потом сэкономлено

Процесс

Каждый день (5 минут):

• Создал новую фичу? → Добавь в Features
• Заметил bug? → Добавь в Known Issues
• Изменил решение? → Update Decision Log

Еженедельно (15 минут):

• Обновить Roadmap (что сделали, что изменилось)
• Обновить North Star metrics
• Ответить на комментарии в wiki

Ежемесячно (1 час):

• Архивировать старые документы
• Переписать неясные части
• Обновить Decision Log с выводами

4. Шаблоны для ускорения

Чем больше шаблонов, тем проще писать.

Шаблон для новой фичи

# Feature: [Feature Name]

## Objective
[Что хотим достичь?]

## Problem
[Какую боль решаем?]

## Solution
[Как решаем?]

## Success Metrics
- Metric 1
- Metric 2
- Metric 3

## Timeline
- Design & Research: [dates]
- Implementation: [dates]
- Testing & QA: [dates]
- Launch: [date]

## Status
- [ ] Backlog
- [ ] In Design
- [ ] In Development
- [ ] Testing
- [ ] Shipped

## Results (if Shipped)
- Metric 1: [actual vs expected]
- Metric 2: [actual vs expected]

Шаблон для Decision

## Decision: [Name]
Дата: YYYY-MM-DD
Делали: [Names]

### Context
[Что произошло?]

### Options
1. [Option A]
2. [Option B]
3. [Option C]

### Decision
[Option X]

### Rationale
- Pro: [Плюс]
- Pro: [Плюс]
- Con: [Минус]

### Follow-up
- Нужно сделать?
- Нужно проверить?

### Result
[Что произошло с этим решением? Хорошо ли сработало?]

5. Что НЕ писать в wiki

❌ Временные задачи (это в Jira/Linear) ❌ Слухи и мнения (только факты) ❌ Дублирование документации код (API docs автогенерируются) ❌ Личные заметки (это в Notion) ❌ Скринкасты без текста (видео устаревает быстро)

6. Инструменты для wiki

Я использовал разные, вот мой рейтинг:

Лучший: Notion

• Красиво выглядит
• Легко структурировать
• Хороший поиск
• Минус: может быть медленным при большом объёме

Хороший: Confluence (Atlassian)

• Интеграция с Jira
• Версионирование
• Минус: менее красивый интерфейс

Простой: GitHub Wiki

• Бесплатный
• Версионирование через Git
• Минус: базовый функционал

7. Как заставить команду писать в wiki

Проблема: даже если ты пишешь, никто больше не пишет.

Решение:

1. Ведомость: делай wiki видимой (ссылка в Slack, в email)
2. Требование: "Если я открыл issue, значит в wiki я должен увидеть контекст"
3. Пример: сам пиши хорошие документы, команда будет копировать
4. Ответственность: DRI (directly responsible individual) за каждый документ
5. Свежесть: помечай дату обновления, помечай как outdated если старо

8. Метрики wiki

Желательно отслеживать:

• Pages created: 10+ в месяц
• Pages updated: 50% документов обновляются каждый месяц
• Search usage: если никто не ищет, значит никто не читает
• Contributor diversity: пишут 5+ человек, не только PM
• Outdated rate: < 5% документов помечены как outdated

Итоговая система

1. Создаю структуру wiki по уровням (Company, Product, Technical, Operations)
2. Заполняю ключевые документы (Vision, Roadmap, Features, Decision Log)
3. Пишу СРАЗУ после события (не потом)
4. Ежедневно (5 минут): малые обновления
5. Еженедельно (15 минут): обновление Roadmap
6. Ежемесячно (1 час): переписание неясного, архивирование
7. Использую шаблоны для ускорения
8. Делаю ответственным за каждый документ (DRI)

Заключение

Wiki — это не скучная документация. Это послание твоему будущему я, новому PM'у и инженерам, которые придут в проект. Тратя 10% времени на wiki сейчас, ты сэкономишь 100% времени потом.