02 - Ideazione e Requisiti con GitHub Copilot

Dall'Idea all'MVP con Copilot

Prima di scrivere una singola riga di codice, è fondamentale definire chiaramente cosa vuoi costruire e perché. GitHub Copilot può aiutarti in questa fase critica, trasformando idee vaghe in requisiti concreti e actionable. In questo articolo esploreremo un framework completo per passare dall'idea iniziale a un MVP ben definito.

Panoramica della Serie

Questo è il secondo articolo della serie "GitHub Copilot: AI-Driven Personal Project". Ecco dove ci troviamo nel percorso completo:

Il Framework della Ideazione

La fase di ideazione non è solo "avere un'idea". È un processo strutturato che include:

Fase 1: Definizione dell'Idea

Inizia con un prompt che aiuti Copilot a comprendere e raffinare la tua idea. Non partire mai da un'idea vaga. Usa il framework IDEA-PROBLEM-TARGET.

I have an idea for a personal project and need help refining it.

## IDEA
[Descrizione dell'idea in 2-3 frasi]

## PROBLEM
- What problem does it solve?
- Who experiences this problem?
- How severe is this problem (1-10)?
- How are people solving it today?

## TARGET USERS
- Primary audience: [Chi sono]
- Secondary audience: [Chi altro potrebbe usarlo]
- Market size estimate: [Quanti potenziali utenti]

## MY BACKGROUND
- Technical skills: [Lista skills]
- Available time: [Ore per settimana]
- Budget: [Se c'è]

Help me:
1. Validate if this idea is feasible as a solo project
2. Identify the core value proposition (ONE sentence)
3. Suggest what makes this different from existing solutions
4. List potential challenges and risks
5. Estimate complexity (1-10) and time to MVP

Be honest and critical. Challenge my assumptions.

Esempio Pratico: TaskFlow

Vediamo come applicare questo framework a un progetto reale:

## IDEA
TaskFlow: Un'app per freelancer che unifica time tracking,
gestione task e generazione fatture in un'unica dashboard.

## PROBLEM
- Problem: I freelancer usano 5+ tool separati (Toggl, Trello,
  Invoice Ninja) che non comunicano tra loro
- Severity: 7/10 - Causa perdita di tempo e denaro
- Current solutions: Spreadsheet manuali, tool multipli

## TARGET USERS
- Primary: Freelancer developer/designer (1-5 anni esperienza)
- Secondary: Piccole agenzie (2-5 persone)
- Market: ~50M freelancer globalmente

## MY BACKGROUND
- Skills: TypeScript, React, Node.js, PostgreSQL
- Time: 10-15 ore/settimana
- Budget: €0 (solo servizi free tier)

Fase 2: Analisi della Concorrenza

Prima di costruire, conosci il mercato. Copilot può aiutarti ad analizzare la concorrenza.

Help me analyze competitors for my project:

PROJECT: [Nome e descrizione breve]
CATEGORY: [Categoria prodotto]

Research and compare:
1. Direct competitors (same problem, same solution)
2. Indirect competitors (same problem, different solution)
3. Potential competitors (could pivot into this space)

For each competitor, identify:
- Name and website
- Target audience
- Key features
- Pricing model
- Strengths (what they do well)
- Weaknesses (gaps I could exploit)
- User reviews/complaints (if known)

Create a comparison table and identify my potential
differentiation opportunities.

Matrice di Comparazione

Fase 3: Feature Prioritization (MoSCoW)

Un errore fatale è voler implementare tutto subito. Usa il metodo MoSCoW per distinguere feature essenziali da nice-to-have.

For my project [NOME], help me prioritize features using MoSCoW method.

CORE IDEA: [Descrizione]
TARGET USER: [Persona principale]
TIME CONSTRAINT: [Tempo disponibile per MVP]

Categorize these potential features into:

## MUST HAVE (MVP - Without these, product is useless)
- Essential for core value proposition
- Users cannot achieve their goal without these

## SHOULD HAVE (Important, but can launch without)
- Significantly improve UX
- High user demand expected

## COULD HAVE (Nice to have, future versions)
- Would delight users
- Not critical for launch

## WON'T HAVE (Out of scope - at least for now)
- Too complex for solo developer
- Low priority, can always add later

For each feature, estimate:
- Development effort (hours)
- Technical complexity (1-5)
- User value (1-5)
- Dependencies (other features needed first)

Esempio di Prioritizzazione TaskFlow

Fase 4: User Personas

Definire chi userà il tuo prodotto aiuta a prendere decisioni di design migliori. Le personas non sono demografiche generiche, ma archetipi con obiettivi specifici.

Create 2-3 detailed user personas for my project:

PROJECT: [Nome e descrizione]
TARGET MARKET: [Mercato di riferimento]
CORE PROBLEM: [Problema principale che risolve]

For each persona include:

## Demographics
- Name, age, location
- Job title and experience level
- Tech savviness (1-10)

## Goals & Motivations
- Primary goal (what they want to achieve)
- Secondary goals
- What success looks like for them

## Pain Points
- Current frustrations
- What they've tried before
- Why existing solutions don't work

## Day in the Life
- Typical workday scenario
- When/where they would use the product
- Frequency of use

## Product Interaction
- Key features they would use most
- Features they would ignore
- Potential objections to using the product

Keep personas realistic, specific, and actionable.
Avoid stereotypes and generic descriptions.

Esempio Persona: Marco il Freelancer

Esempio Persona: Sarà la Designer

Fase 5: Use Cases Dettagliati

Gli use case descrivono come gli utenti interagiranno con il sistema. Sono fondamentali per definire requisiti funzionali precisi.

Write detailed use cases for my MVP:

PROJECT: [Nome]
CORE FEATURES: [Lista feature MVP]
PRIMARY PERSONA: [Nome persona]

For each use case include:

## Use Case: [Title]

**ID:** UC-001
**Actor:** [Who performs the action]
**Priority:** Must/Should/Could

### Preconditions
- What must be true before this use case starts

### Trigger
- What initiates this use case

### Main Flow (Happy Path)
1. Step 1
2. Step 2
3. ...

### Alternative Flows
- 2a. If [condition], then [action]
- 3a. If [condition], then [action]

### Exception Flows
- E1. If [error], then [error handling]

### Postconditions
- What is true after this use case completes

### Business Rules
- BR1: [Rule]
- BR2: [Rule]

### UI Mockup Notes
- Key UI elements needed

Focus on MVP use cases first, then secondary ones.

Esempio Use Case: Avvio Timer

## Use Case: Start Time Tracking

**ID:** UC-003
**Actor:** Authenticated User (Marco/Sarà)
**Priority:** MUST HAVE

### Preconditions
- User is logged in
- User has at least one task created
- No timer is currently running

### Trigger
- User clicks "Start Timer" button on a task

### Main Flow
1. User views task list on dashboard
2. User locates the task to track
3. User clicks "▶️ Start" button on task row
4. System validates no other timer is running
5. System creates new time entry with:
   - Start time = now
   - Task ID = selected task
   - User ID = current user
6. System updates UI:
   - Task row shows running timer (00:00:00)
   - Header shows global timer indicator
   - "Start" button changes to "Stop"
7. Timer increments every second in UI

### Alternative Flows
- 4a. Another timer is running:
  - System shows confirmation: "Stop current timer and start new?"
  - If confirmed: Stop current, start new
  - If cancelled: No action

- 3a. User uses keyboard shortcut (Ctrl+Enter):
  - Same flow from step 4

### Exception Flows
- E1. Network error during save:
  - System saves entry locally
  - Shows "Offline mode" indicator
  - Syncs when connection restored

### Postconditions
- New time entry exists in database with status "running"
- UI shows active timer for the task
- Previous timer (if any) is stopped and saved

### Business Rules
- BR1: Only one timer can run at a time per user
- BR2: Timer cannot run for more than 12 hours (auto-stop)
- BR3: Minimum time entry is 1 minute (rounds up)

### UI Mockup Notes
- Timer button prominent, easy to tap on mobile
- Visual feedback immediate (optimistic update)
- Timer visible without scrolling

Fase 6: Documentazione dei Requisiti

Usa Copilot per generare documentazione strutturata dei requisiti. Un buon documento requisiti è la base per tutto lo sviluppo successivo.

Create a Product Requirements Document (PRD) for my MVP:

PROJECT: [Nome]
VISION: [One sentence vision]
PERSONAS: [List personas]
FEATURES: [MVP features]

Include these sections:

## 1. Executive Summary
- Problem statement
- Solution overview
- Success metrics

## 2. Functional Requirements
For each feature:
- FR-001: [Description]
- Acceptance criteria
- Priority (Must/Should/Could)

## 3. Non-Functional Requirements
- Performance (response times, load)
- Security (auth, data protection)
- Scalability (expected growth)
- Accessibility (WCAG level)
- Browser/device support

## 4. Technical Constraints
- Tech stack decisions
- Third-party services
- Infrastructure limits

## 5. Assumptions & Dependencies
- What we assume to be true
- External dependencies

## 6. Out of Scope
- Explicitly what we're NOT building

## 7. Success Metrics
- How we measure if MVP is successful
- KPIs to track

Format as a structured markdown document
ready for team/stakeholder review.

Template PRD Semplificato

# TaskFlow MVP - Product Requirements Document

## 1. Executive Summary

**Problem:** I freelancer perdono 2+ ore/mese gestendo tempo,
task e fatture su tool separati.

**Solution:** Dashboard unificata che collega time tracking
ai task e genera report pronti per la fatturazione.

**Success Metrics:**
- 100 utenti registrati entro 3 mesi
- 50% retention rate a 30 giorni
- NPS > 30

---

## 2. Functional Requirements

### Authentication
| ID | Requirement | Priority | Acceptance Criteria |
|----|-------------|----------|---------------------|
| FR-001 | User registration | Must | Email/password, email verification |
| FR-002 | User login | Must | JWT token, 7-day expiry |
| FR-003 | Password reset | Must | Email link, 1-hour expiry |

### Task Management
| ID | Requirement | Priority | Acceptance Criteria |
|----|-------------|----------|---------------------|
| FR-010 | Create task | Must | Title required, description optional |
| FR-011 | Edit task | Must | All fields editable |
| FR-012 | Delete task | Must | Soft delete, recoverable 30 days |
| FR-013 | Task status | Must | Todo, In Progress, Done |

### Time Tracking
| ID | Requirement | Priority | Acceptance Criteria |
|----|-------------|----------|---------------------|
| FR-020 | Start timer | Must | One-click, linked to task |
| FR-021 | Stop timer | Must | Auto-saves time entry |
| FR-022 | Manual entry | Should | Add past time entries |
| FR-023 | Edit entry | Should | Modify start/end times |

---

## 3. Non-Functional Requirements

| Category | Requirement |
|----------|-------------|
| Performance | Page load < 2s, API response < 500ms |
| Security | HTTPS, password hashing, JWT |
| Scalability | Support 1000 concurrent users |
| Accessibility | WCAG 2.1 AA |
| Browser | Chrome, Firefox, Safari (last 2 versions) |

---

## 4. Out of Scope (MVP)

❌ Team collaboration
❌ Invoice generation (PDF)
❌ Payment processing
❌ Mobile native app
❌ Integrations with other tools

Fase 7: Validazione dell'Idea

Prima di sviluppare, valida che l'idea abbia senso. Non innamorarti della soluzione prima di aver validato il problema.

Tecniche di Validazione Rapida

Output Finale della Fase

Alla fine di questa fase dovresti avere tutti i documenti necessari per iniziare lo sviluppo con chiarezza.

Errori Comuni da Evitare

Conclusione

La fase di ideazione e requisiti è cruciale per il successo del progetto. Investire 2-4 settimane qui risparmia mesi di refactoring dopo. Copilot può accelerare enormemente questo processo aiutandoti a strutturare il pensiero, generare documenti e sfidare le tue assunzioni. Ma le decisioni finali sono sempre tue.