Что важно при выборе проекта?

Что важно при выборе проекта? Мой критерий за 10+ лет

Краткий ответ

Выбирай проект на основе 5 критериев: Team, Budget, Timeline, Problem, Growth.

Мои критерии выбора

1. TEAM (самый важный, 40% решения)

Хороший team:
  ✓ Компетентный CTO/tech lead (понимает что делает)
  ✓ Product Manager (знает бизнес)
  ✓ Разработчики (senior, не junior)
  ✓ Open к feedback, collaborative
  ✓ Честные люди (не обещают невозможное)

Плохой team:
  ✗ Нет clear leadership
  ✗ Разработчики resistive к requirements
  ✗ Политика вместо work
  ✗ Люди приходят и уходят часто
  ✗ Нет процессов

Мой опыт:
  Я видел плохой проект с good team → успешен
  Я видел good проект с плохой team → провал
  
  Lesson: Team важнее чем project.

2. BUDGET (30% решения)

Хороший бюджет:
  ✓ Реалистичен для scope'а
  ✓ Есть buffer (20% contingency)
  ✓ Approved и committed (не может быть cut в середине)
  ✓ Включает everything (not just development)
  ✓ Контролируется с discipline

Плохой бюджет:
  ✗ Недооценён на 50% (красный флаг!)
  ✗ Нет buffer'а
  ✗ Subject to cuts (политика)
  ✗ Только dev, забыли про QA/ops
  ✗ Перезахозят каждый месяц

Красные флаги:
  "Мы потратили только 30% бюджета, но уже в середине timeline"
  → Scope может быть недооценён, в конце будут проблемы
  
  "Раньше такой проект стоил $100k, этот должен стоить $50k"
  → Нереалистично. Вопрос: что cut'ят?

3. TIMELINE (20% решения)

Хороший timeline:
  ✓ Реалистичен (не 2x быстрее чем прошлый похожий проект)
  ✓ Есть slack (буфер для неизвестного)
  ✓ Фазы clearly defined
  ✓ MVP early (не всё в конце)
  ✓ Гибкий (можно adjust)

Плохой timeline:
  ✗ Нереалистично tight ("6 месяцев это 2 месяца работы")
  ✗ Нет contingency
  ✗ All-or-nothing (launch всё сразу или ничего)
  ✗ Fixed (нельзя adjust)
  ✗ Pushed by business, не скорректирован с team'ом

Мой анализ:
  Я оцениваю: сколько времени РЕАЛЬНО потребуется
  Потом складываю 30% buffer'а
  Если timeline < моя оценка → красный флаг
  
  Я говорю: "Реально потребуется 9 месяцев, буффер 3 месяца = 12 месяцев.
             Если нужно 6 месяцев — cut scope or add people (не удалось доказано)."

4. PROBLEM (15% решения)

Хороший problem:
  ✓ Реальная боль users (не вымышленная)
  ✓ Clear value proposition (почему важно)
  ✓ Большой market (тысячи+ users)
  ✓ Ясное решение (знаем что делать)
  ✓ Выигрыш для бизнеса явный (revenue, cost savings)

Плохой problem:
  ✗ Непонятный (no clear value)
  ✗ Vague requirements ("make it better")
  ✗ Малый market (очень узкая задача)
  ✗ Не вполне сформулирован
  ✗ Выгода неясна

Примеры хороших problems:
  "Наши salespeople тратят 50% времени на data entry в CRM. Это стоит нам $2M/год."
  → Ясный problem, ясный value
  
  "Пользователи не могут найти нужное в каталоге, теряем 30% orders."
  → Ясный problem, ясный impact

Примеры плохих problems:
  "Хотим красивее интерфейс."
  → Неясно что означает "красивее", какой ROI?
  
  "Technology is outdated, нужно переписать всё на новый фреймворк."
  → Технический problem, не business problem. Нет ROI.

5. GROWTH (5% решения)

Хороший growth:
  ✓ Проект может расширяться (скалируемость)
  ✓ Future opportunities (V2, V3)
  ✓ Careerwise (чему можно выучиться)
  ✓ Industry нужно (не нишевое)
  ✓ Company растёт (не dying startup)

Плохой growth:
  ✗ Dead-end проект (одноразовый)
  ✗ Никакого будущего
  ✗ Industry declining (печать, например)
  ✗ Company struggling

Примеры:
  Good: "Это core product, компания растёт 100%/год, в ближайшем году нужны 10 больше
          features. Карьера стабильна и растёт."
  
  Bad: "Это legacy system, 3 года никто не трогает. Может быть deprecated в 2 года.
         Карьера стагнирует."

Матрица выбора (как я решаю)

         Team  Budget  Timeline  Problem  Growth  TOTAL
Project A: 5/5   4/5    4/5      5/5      3/5   = 21/25 ✓ YES
Project B: 2/5   3/5    2/5      3/5      4/5   = 14/25 ✗ NO
Project C: 4/5   2/5    5/5      4/5      5/5   = 20/25 ~ MAYBE

Rules:
- Team < 3/5 → автоматически NO (риск слишком высокий)
- Budget < 2/5 → автоматически NO (проект will fail)
- Total > 20/25 → YES
- Total < 15/25 → NO
- 15-20 → зависит от остальных факторов

Case 1: Выбор между двумя проектами (реальный)

Project A: Big Marketplace (Series B startup)

Team: 5/5
  - CTO is genius, ex-Google
  - Product Manager is sharp
  - Team 15 people, all senior
  - Culture: collaborative, fast-moving

Budget: 2/5
  - $1M allocated
  - But scope is $3M worth of work
  - Budget will likely be cut
  - Contingency: 0%

Timeline: 2/5
  - 12 months for 18-month project
  - No slack
  - All-or-nothing launch

Problem: 5/5
  - Clear: "Sellers can't manage inventory"
  - Impact: losing 40% orders
  - Value: $10M/year potential

Growth: 5/5
  - Company growing 200%/year
  - Will be huge in 2 years
  - Opportunities: endless

TOTAL: 17/25 → MAYBE (borderline)

My decision:
  - Budget is red flag
  - But team is exceptional
  - And problem is huge
  
  Decision: NEGOTIATE
  "I'll do this IF:
   1. Budget increases to $1.5M (realistic)
   2. Timeline extends to 14 months
   3. We focus on MVP first (not everything)"
  
  If they agree: YES
  If they refuse: NO (not worth the risk)

Project B: Internal Tool (Enterprise company)

Team: 3/5
  - CTO is ok but busy with other projects
  - No dedicated product manager
  - Team: mix of junior and senior
  - Culture: hierarchical, slow

Budget: 4/5
  - $500k allocated
  - Scope is $400k worth
  - Realistic estimate
  - 20% contingency included

Timeline: 4/5
  - 12 months for 12-month work
  - Good estimation
  - Some slack
  - Phases defined

Problem: 3/5
  - "Current tool is slow"
  - But users don't complain much
  - Impact: maybe 10% efficiency gain
  - Value: $500k/year (unclear)

Growth: 2/5
  - Internal tool, limited expansion
  - No new market
  - Careerwise: won't learn much new
  - Company stable, not growing

TOTAL: 16/25 → MAYBE (but leaning NO)

My decision:
  - Team is weak (CTO not committed)
  - Growth is minimal
  - Problem is vague
  - Only good thing: budget and timeline are realistic
  
  Decision: NO
  "This is a safe project but boring. Low risk but low reward.
   I'll pass and wait for something more interesting."

I chose Project A (after negotiating budget/timeline)

Case 2: When I said NO (and it was right)

Project: "Revolutionary AI startup"

Team: 2/5
  - CEO: no tech background
  - CTO: fresh from bootcamp
  - No PM
  - Team: 3 people, all junior

Budget: 1/5
  - "We have $200k" (not enough)
  - "We'll raise more" (maybe)
  - No contingency
  - Lots of unknowns

Timeline: 2/5
  - "We need MVP in 3 months"
  - But scope is 6-month work
  - Unrealistic

Problem: 3/5
  - "AI will revolutionize healthcare"
  - Vague
  - No clear users
  - No traction

Growth: 4/5
  - If successful: huge
  - But risk is extreme

TOTAL: 12/25 → NO

My decision: PASS
"Team is too weak. Budget is not enough. Timeline is unrealistic.
This is startup roulette, not viable project."

What happened:
  - 8 months later: startup failed
  - Budget ran out
  - Team quit
  - I was right to say no

My checklists

Before saying YES to project:

☐ Team: Can I trust them? Are they competent?
☐ Budget: Is it realistic? Can it cover contingencies?
☐ Timeline: Is it achievable? With what quality?
☐ Problem: Is it real? Do we know how to solve?
☐ Growth: Is there future in this?

☐ Gut feeling: Do I want to do this?
☐ Red flags: Are there any?
☐ Worst case: Can I live with failure?
☐ Best case: Is success worth my time?

If any "no" → Think carefully before accepting
If multiple "no" → Probably should decline

Red flags that make me say NO immediately:

🚩 Team lead is defensive or not open to feedback
   → Communication will be nightmare
   
🚩 Budget is significantly underestimated
   → Project will be cut mid-way
   
🚩 Timeline is obviously impossible
   → Implies either lying or delusion
   
🚩 Problem is not clearly articulated
   → Scope creep guaranteed
   
🚩 Multiple stakeholders with conflicting goals
   → Political minefield
   
🚩 Key people are unavailable or not committed
   → Will affect quality

My personal rules

1. The 40-40-20 rule

• 40% of success = good team
• 40% of success = realistic planning (budget + timeline)
• 20% of success = good problem definition

If any of these is weak → high risk.

2. The no-red-flag rule I don't accept projects with multiple red flags. One red flag can be managed. Three = too many risks.

3. The gut feeling rule My gut feeling is usually right. If I'm uneasy, there's a reason. I've learned to listen to it.

4. The growth rule I only take projects where I'll learn something. If I can do this project in sleep → it's boring → I'll decline.

I want to grow, not stagnate.

5. The sustainable rule I don't take projects that will burn me out. Even if pay is good, if the project requires 80-hour weeks for months → NO.

Burnout is not worth any amount of money.

Вывод

Выбор проекта = выбор жизни на следующие месяцы.

Лучший критерий:

1. Кому я буду служить? (Team)
2. С каким бюджетом? (Budget)
3. За сколько времени? (Timeline)
4. Какую проблему решаю? (Problem)
5. Куда это приведёт? (Growth)

Если хотя бы одно из этого плохо → рекомендую подумать, стоит ли?

Я видел много проектов. Лучшие были когда:

• Хорошие люди
• Достаточно ресурсов
• Ясная цель
• Интересная задача

Худшие были когда:

• Плохая коммуникация
• Недостаточно денег
• Нереалистичный план
• Никто не понимает зачем

Выбирай мудро. Ты проведёшь много времени на этом проекте.