23 апреля 2026 г.·4 мин чтения

Как писать техспеку для дашборда

Проверь себя · 1/3разбор после ответа
Вы сравниваете распределение выручки по двум когортам на гистограмме. Что важно сделать, чтобы сравнение было честным?

Зачем это знать

Стейкхолдер говорит «сделай дашборд по продажам». 10 разных способов сделать. Без spec — guaranteed rework.

Spec = документ, где формулируете что, как, почему. Tool #1 для alignment.

Senior-аналитик pisania spec до writing SQL. Junior прыгает в код → wasting time.

Зачем spec

1. Alignment

Stakeholder + analyst на той же странице.

2. Scope control

«Do this, not that» — clear.

3. Documentation

Future analyst (or yourself) — reads spec, understands.

4. Priority

What's critical vs nice-to-have → focus.

5. Estimation

Spec allows estimate time.

Структура spec

1. Executive summary

1-2 sentences: what, why, audience.

2. Users

Кто will use?

  • PM (daily)
  • CEO (weekly)
  • Marketing (for campaigns)

3. Use cases / questions

What questions users want answered?

  • «Сколько revenue за вчера?»
  • «Какой channel performs лучше?»
  • «Где upper-left падение?»

4. Metrics

Each metric:

  • Name
  • Definition (SQL)
  • Aggregation
  • Dimensions

5. Filters

  • Date range
  • Country
  • Segment

6. Layout / wireframe

Sketch или Figma. Где чарт A, B, C.

7. Data sources

Tables, queries.

8. Refresh

Daily / hourly / real-time.

9. Success criteria

«User can answer X question в 30 seconds».

10. Non-functional

  • Performance (< 3 sec load)
  • Access (who sees what)
  • Alerts (optional)

Пример spec

Название: Revenue Dashboard

Executive summary: dashboard для ежедневного monitoring revenue trends, breaking down по channel и region.

Audience:

  • CEO (weekly glance)
  • CMO (daily)
  • Regional managers (daily)

Use cases:

  • Real-time revenue vs target
  • Channel performance comparison
  • Regional hotspots и downturns
  • Trend over time

Metrics:

Metric Definition Source
Total revenue SUM(amount) WHERE status='completed' transactions
AOV Revenue / order count transactions
CR Orders / sessions transactions, sessions
Daily active buyers Unique users who purchased transactions

Filters:

  • Date range (default: last 30 days)
  • Country (multi-select)
  • Channel (organic, paid, referral, direct)

Layout:

Row 1: [Revenue today] [Orders today] [AOV]
Row 2: [Daily revenue line chart last 30d]
Row 3: [Channel bar chart] [Country map]
Row 4: [Top 10 products table]

Data sources:

  • events.transactions
  • events.sessions
  • dim.channels

Refresh: Daily at 3am UTC

Success criteria:

  • CEO can answer «how did we do this week» в 30 seconds
  • CMO can identify struggling channel
  • Regional managers can see их region vs others

Non-functional:

  • Load < 5 seconds
  • Available for [specific Slack groups]
  • Email report daily 8am

Mistakes в spec

1. Vague requirements

«Show me revenue» — which definition? Net / gross? Include taxes?

Specific.

2. No users

«Dashboard для всех». Usually ends serving no one.

3. Feature creep

«Add also...». Scope grows.

Fight. Push к V2.

4. No metrics definitions

«CR» — which? Visit → signup? Signup → purchase? Session → purchase?

Define precisely.

5. Ignoring performance

«Live data» для 100M row table — unfeasible. Feasibility check upfront.

Iterative process

Draft 1

Analyst writes после stakeholder conversation.

Review

Share с stakeholders. Collect feedback.

Refine

Address confusion, alignments.

Sign-off

Formal agreement. «This is what we're building».

Готовься к собесу аналитика как в Duolingo
10 минут в день — SQL, Python, A/B, метрики. 1700+ вопросов в Telegram
Открыть Карьерник в Telegram

Tools

Docs

  • Notion
  • Confluence
  • Google Docs

Wireframes

  • Figma
  • Miro
  • Даже paper sketch

Collaboration

  • Slack threads
  • Comments в docs

Signed spec benefits

Accountability

Stakeholder agreed — hard change mind late.

Pushback

«This not in spec» — fair argument.

Focus

Clear scope — analyst focuses.

Review

After build — compare к spec. Gap?

Для бsagsafd ad-hoc

Не каждый project needs formal spec. 5-min analysis не нужен.

Rule of thumb: > 2 days work → spec.

На собесе

«Как scope dashboard project?»

Walk through:

  • Talk к users
  • Write spec
  • Review и iterate
  • Build

Show discipline.

Metric dictionary

Document каждой metric. Referenced by all specs.

Dashboard inventory

Registry всех dashboards. Owner, purpose, SLA.

Change log

Updates к dashboard — logged.

Связанные темы

FAQ

How long spec?

2-5 pages usually. Short dashboard — 1 page.

Нужен ли для small fixes?

No. Formal spec для new features / dashboards.

Stakeholder resists?

«Help me build right thing. Spec 30 min, saves weeks rework».

Ещё по теме