Estimation, Stakeholder Management, Career

Зачем знать на Middle 3: на этом уровне умение “правильно оценивать сроки”, “коммуницировать с PM/менеджером”, “грамотно драфтить документацию” и “управлять карьерой” — критерии для повышения. Senior+ инженер не просто кодит, а помогает бизнесу понять, что и когда возможно. И умеет договариваться о компенсации.

Содержание

1. Концепция
2. Глубже: estimation techniques, stakeholder map, career ladder
3. Gotchas / Best practices
4. Real cases
5. Вопросы (20, в т.ч. behavioral)
6. Practice
7. Источники

---

1. Концепция

Почему оценка трудна

• Unknown unknowns: то, чего мы не знаем, что не знаем.
• Planning fallacy (Канеман): люди систематически недооценивают.
• Anchoring: первая названная цифра «якорит» всех.
• Optimism bias: «всё пройдёт гладко».
• Hofstadter’s Law: «Всегда занимает больше, даже если учесть Hofstadter’s Law».

Что значит “грамотная оценка”

• Оценка — диапазон, не точка.
• Оценка = опытом подкреплённое прогнозирование.
• Включает риск-факторы.
• Может пересматриваться по мере появления информации.

Stakeholder management

Stakeholder — любой, кого касается твой проект:

• Executive sponsor — выделяет ресурсы.
• Product Manager — приоритизирует.
• Designers — UX/UI.
• Ops/SRE — поддерживают prod.
• QA — валидация.
• Other engineering teams — зависимости/потребители.
• Customer success / support — клиенты.
• End user.

Career path

Middle 3 → Senior → Staff → Principal:

• Каждый уровень = расширение scope of impact.
• Не “больше кода”, а больше leverage (через mentoring, дизайны, кросс-командные решения).

---

2. Глубже

2.1 Estimation techniques

Story points (relative):

• Шкала Fibonacci: 1, 2, 3, 5, 8, 13, 21.
• Не привязано к часам — measure relative complexity.
• Стабилизируется velocity (sp/sprint).

T-shirt sizes:

• XS, S, M, L, XL.
• Для high-level планирования (квартал, год).

Hours/days:

• Дают illusion of precision, но часто ошибочны.
• ОК для маленьких задач (<2 дней).

Planning poker:

• Команда видит оценку каждого одновременно.
• Discuss diffs, re-vote.
• Уменьшает anchoring.

Wideband Delphi:

• Анонимные оценки в несколько раундов.
• Хорошо при политических темах.

Reference tasks:

• Список 5-10 типовых задач с известной оценкой (“залить cron job — 2 SP”).
• Сравнение новой задачи с ref.

PERT (Programme Evaluation and Review Technique):

• 3-point estimation: optimistic (O), most likely (M), pessimistic (P).
• Estimate = (O + 4M + P) / 6.
• Variance = (P - O)² / 36.

Пример: O=2, M=5, P=14.

• E = (2 + 20 + 14)/6 = 6 дней.
• σ = (14-2)/6 = 2 дня.

Cone of uncertainty (Steve McConnell):

• В начале проекта погрешность ±400%.
• К design phase — ±50%.
• К coding — ±20%.

2.2 Buffer и risk

• Linear buffer: добавить 30% к total.
• Conditional buffer: на каждый risk — резерв в человеко-днях.

Estimate baseline:        20 d
+ Integration unknown:    +3 d (50% probability * 6 d)
+ Vendor API delay:       +2 d
+ Personal time off:      +1 d (planned)
+ Code review/iteration: +2 d
= Total commitment:       28 d

Critical path — последовательность задач, определяющая срок. Любая задержка в critical path → задержка проекта.

2.3 Коммуникация оценки

• Range, not point: “2-4 недели”, не “3 недели”.
• Confidence level: “80% уверен, что справимся к Q3”.
• Assumptions explicit: “Если DB shard готов, и vendor X отвечает за 1 неделю”.

Anti-pattern: “коммитнуться, чтобы PM отстал”. Это даст текущий мир, но репутацию убьёт.

2.4 Stakeholder map (RACI)

Для крупного проекта — матрица RACI:

Task	Engineer	TL	PM	EM	Designer
Spec review	R	A	C	I	C
Code	R	A	I	I	—
QA	C	A	R	I	—
Launch	R	A	R	I	C

• R (Responsible) — делает.
• A (Accountable) — отвечает за результат (один на task).
• C (Consulted) — даёт input.
• I (Informed) — в курсе.

2.5 Status updates / communication cadence

Weekly tech update:

• Что сделано (concrete artifacts).
• Что в работе.
• Что заблокировано (с owner).
• Risks/decisions нужны.

Длина: ≤15 строк. Markdown в Slack/email.

Quarterly business review:

• Цели Q.
• Достижения с метриками.
• Сдвиги и причины.
• Outlook next Q.

2.6 Escalation paths

Escalate когда:

• Блокируешься > 2 рабочих дней.
• Cross-team conflict не решается.
• Risk to milestone.
• Несоответствие приоритетов между PM и tech.

Как escalate:

• Письменно (email / DM, не в open Slack).
• Сначала к direct manager.
• Если manager сам — к skip level.
• Без emotion, факты + impact.

2.7 Управление вверх (managing up)

• No surprises — менеджер узнаёт о проблемах ОТ ТЕБЯ, не от других.
• Pre-mortem: за день до меетинга — отправь key points.
• Brag doc: 1 раз в неделю — короткая запись о достижениях. Поможет на review.

2.8 Saying “no” gracefully

Шаблон:

1. Acknowledge: “Понимаю, это важно для X.”
2. Trade-off: “Чтобы взять это, придётся отложить Y или ускорить Z с риском качества.”
3. Alternative: “Можем сделать lite-version за 2 спринта вместо полной за 4.”
4. Decision owner: “Окей сделать выбор Y vs X?“

2.9 Документация и runbooks

Code docs (godoc):

• Каждый exported идентификатор.
• Examples в Example_<Name>.

Architecture docs:

• C4 model (Context, Container, Component, Code).
• ADR (Architecture Decision Record) — короткие записи “почему так”:

# ADR-007: Use PostgreSQL for billing events

Status: Accepted
Date: 2026-03-15
Context: ...
Decision: ...
Consequences: ...

Runbooks:

• Step-by-step для on-call.
• Каждый alert → есть runbook.
• Tested (chaos drill).

Onboarding guide:

• Setup, glossary, key links.

2.10 Career path Middle 3 → Senior → Staff

Middle 3 (или Senior I в некоторых ladder):

• Глубокая экспертиза в одной области.
• Tech lead small team (3-5 человек).
• Mentor 1-2 juniors.
• Owner of subsystem.

Senior (Senior II / SSE):

• Cross-team impact.
• Архитектурные решения (~3-6 months ahead).
• Mentor middles.
• Reliable estimation.
• Major project ownership.

Staff:

• Org-wide impact.
• Tech strategy (12+ months).
• Mentor seniors.
• Ambiguous/political problems.
• Tech evangelist.

Principal / Distinguished:

• Industry-level expertise.
• Multi-year strategy.
• “Last resort” technical authority.

2.11 Skills для роста

• Technical depth: deep specialization.
• Technical breadth: знание соседних систем.
• Communication: writing, presenting.
• Influence: ведение people без формальной власти.
• Strategic thinking: 6-18 months ahead.
• Mentoring: cascade impact.

Внешняя видимость:

• Conference talks (KubeCon, Gophercon).
• Tech blog (личный или company).
• Open source contributions.
• Industry working groups.

Books canonical:

• “Staff Engineer” — Will Larson.
• “The Staff Engineer’s Path” — Tanya Reilly.
• “The Pragmatic Programmer” — Hunt, Thomas.
• “The Manager’s Path” — Camille Fournier.
• “An Elegant Puzzle” — Will Larson.
• “Designing Data-Intensive Applications” — Kleppmann.

2.12 Performance review

Подготовка:

• Brag doc за весь cycle (6-12 месяцев).
• Quantify impact (метрики: latency saved, $$ saved, выручка, time saved).
• Peer feedback запрос (3-5 человек).
• Self-assessment честный, не “soft sell” и не “ego boost”.

Self-assessment template:

## Impact
- Delivered feature X → 20% conversion lift.
- Reduced p99 latency from 800ms to 200ms.
- Migrated billing to event-driven (eliminated 5 nightly batch jobs).

## Leadership / mentoring
- Mentored 2 junior engineers (both promoted).
- Authored 4 design docs (all approved).

## Growth areas
- Want to take more cross-team architectural decisions.
- Plan to deliver one KubeCon talk in 2026.

2.13 Negotiation: компенсация

• Знай рынок: levels.fyi, Glassdoor, Otta, Layoffs.fyi.
• Total comp = base + bonus + equity (stock vest).
• Не принимай первое предложение — почти всегда есть room.
• Justify number = market data + your specific impact.
• Multiple offers — главный leverage.
• Sign-on bonus — single hit, легче дать рекрутеру, чем base.

Phrases:

• “Based on my research and current offers, I’d expect compensation in range X-Y.”
• “What flexibility is there on base / equity / sign-on?”
• “Can we revisit base in 6 months if I exceed expectations?”

⚠️ В России / СНГ — equity редкость, фокус на base. В US/EU — equity критична.

⚠️ Внутреннее повышение — обычно меньший рост, чем смена компании. Балансируй loyalty vs market.

---

3. Gotchas / Best practices

⚠️ “Я этим займусь в свободное время” — нет такого. Если не запланировано — не сделается.

⚠️ Estimation в часах для feature >3 дней — гарантированный провал.

⚠️ “Точный план на 6 месяцев” — невозможен. Только roadmap + iteration.

⚠️ Status update в эмоциональном тоне (“это полный провал!”) — теряешь credibility.

⚠️ No-no для escalation: жалоба без alternative.

⚠️ “Я не знаю” в design review — нормально, лучше чем blefar. Follow up.

⚠️ Brag doc только перед review — поздно, многое забыто. Делай еженедельно.

⚠️ Compensation discussion в Slack — переводи на 1:1, голос/видео.

⚠️ “Конкурент предлагает X” без offer letter — не врать.

⚠️ Negotiation после signing — late. Договаривайся до.

⚠️ Title vs comp: иногда дают title без денег. Не зацикливайся на title.

Best practices

• Brag doc weekly (5 min).
• 1:1 с manager weekly — твой инструмент, не его.
• Mentor outside your team — расширяет network.
• Job хобби: open source / blog.
• Knowledge tax — выделяй 10% на learning.
• Conference 1/year — расширяет horizon.
• Reading list — 1 серьёзная книга/квартал.

---

4. Real cases

4.1 Estimation: 6-month roadmap

Команда дала PM “точный план на 6 месяцев” — 30 features. Через 2 месяца:

• 5 features заняли всё время (была недооценка legacy).
• 25 не сделаны.

PM в ярости. После: перешли на quarterly OKRs + 2-week sprints.

4.2 Stakeholder management: cross-team conflict

Team A зависит от Team B. B не приоритизирует. Engineer из A escalate через TL → EM:

• Не “B не хочет работать”.
• “Project X на критическом пути, зависит от API в B. Без него slip 2 weeks. Можем выделить engineer из A для парного дизайна?”

Решение: B даёт design review, A пишет implementation. Win-win.

4.3 Career growth: switch to Staff

Senior 5 лет в одной компании, забуксовал. Поговорил с менеджером:

• “Что нужно для Staff?”
• “Cross-org impact, tech strategy.”

План:

• Возглавил migration инициативу (3 команды).
• Написал tech vision на год.
• 2 design reviews для соседних команд.
• KubeCon talk.

Через год — promoted.

4.4 Negotiation: первый offer

Outsourcing→ FAANG. Recruiter: “X базы”. Engineer: “благодарю, дайте 2 дня”. Исследовал levels.fyi — X на 25% ниже рынка для уровня. Ответил: “Текущий offer от Y компании на 30% больше base. Можем закрыть gap?” Финал: +30% base + sign-on.

Урок: никогда не торопись с ответом, всегда есть room.

4.5 Failed estimation постмортем

Команда оценила миграцию в Kubernetes в 2 месяца. Заняло 8. Постмортем:

• Не учли legacy stateful services (отдельная schema).
• Не учли security audit (3 weeks lock).
• Optimism bias: предполагали “сделаем все за неделю”.

Action: с этого момента — 1.5x buffer + risk register в каждом плане.

---

5. Вопросы (20)

Estimation

1. Чем story points отличаются от часов?
2. Что такое cone of uncertainty?
3. Как формула PERT для оценки?
4. Почему planning poker уменьшает bias?
5. Когда использовать T-shirt size vs SP?

Stakeholder

6. Что значит RACI? Кто такой Accountable?
7. Как escalate cross-team конфликт?
8. Что такое “managing up”?

Career / behavioral

9. Расскажи, как ты ошибся с estimation и что вынес.
10. Опиши ситуацию, когда сказал “нет” PM. Как это прошло?
11. Как готовишь performance review?
12. Какое самое сильное достижение в текущей роли? Метрики?
13. Расскажи о project, который ты убил (kill). Как пришёл к решению?
14. Как доносил архитектурное решение non-tech stakeholders?
15. Какой book / talk изменил твой подход к engineering?
16. Опиши план для перехода Senior → Staff.
17. Как ты обрабатываешь negative feedback?
18. Что делаешь, когда менеджер не согласен с тех. решением?
19. Расскажи о compensation negotiation — что сработало?
20. Когда последний раз отказывался от promotion и почему?

---

6. Practice

1. Возьми текущий feature; оцени по PERT (O, M, P, σ).
2. Напиши brag doc за последние 3 месяца.
3. Сделай RACI для своего проекта.
4. Подготовь 5-минутный stakeholder update (письменно).
5. Напиши career growth plan на 12 месяцев с 3 SMART целями.
6. Заполни levels.fyi data — где ты по рынку?
7. Подготовь “saying no” скрипт для типичного PM запроса.
8. Сделай ADR для последнего важного тех. решения.
9. Сделай pre-mortem на проект: “что может пойти не так и как мы узнаем”.
10. Найди conference, на которую подашься в этом году.

---

7. Источники

1. “The Mythical Man-Month” — Fred Brooks
2. “Software Estimation: Demystifying the Black Art” — Steve McConnell
3. “Staff Engineer” — Will Larson
4. “The Staff Engineer’s Path” — Tanya Reilly
5. “The Manager’s Path” — Camille Fournier
6. “The Pragmatic Programmer” 20th anniv — Hunt, Thomas
7. “Thinking, Fast and Slow” — Daniel Kahneman
8. levels.fyi — comp data
9. Otta / Welcome to the Jungle — job listings
10. “Working Backwards” — Bryar, Carr (Amazon)
11. “Crucial Conversations” — Patterson et al.
12. “Never Split the Difference” — Chris Voss (negotiation)
13. Will Larson blog (Lethain.com)
14. Charity Majors blog
15. Camille Fournier blog (skamille)
16. RACI matrix in PMI BoK
17. PERT in DoD project management
18. C4 model (Simon Brown)
19. ADR templates: https://adr.github.io
20. “Resilient Management” — Lara Hogan