Vai al contenuto
Nodary

Documentazione di prodotto che tiene le ragioni accanto ai requisiti.

Una specifica raramente spiega tutta la decisione. In Nodary la specifica di una funzionalità sta accanto alla sua ricerca, al progetto tecnico e alle decisioni che l’hanno plasmata, ciascuno con un responsabile e uno stato. Gli agenti di codice dei tuoi sviluppatori leggono tutto via MCP e sanno quali pagine sono aggiornate.

Aggiornato il Leggi in Markdown

Una board in tempo reale in Nodary che raggruppa i documenti di una milestone per stato, bozza, in revisione, completato e bloccato, ogni scheda con responsabile e scadenza.
Le schermate mostrano Saltmarrow, un progetto di esempio inventato per la demo.

Il problema, con le parole del tuo team

I team di prodotto e sviluppo scrivono molto, poi perdono il filo di quale pagina vale. La specifica dice una cosa, il ticket un’altra, e la decisione che le ha cambiate entrambe è stata presa in una call che nessuno ha riassunto. Quando uno sviluppatore, o un agente di codice, riprende il lavoro, i requisiti arrivano senza le loro ragioni e le stesse domande tornano in revisione.

  • Questa specifica è approvata o ancora in bozza?
  • Perché abbiamo tolto quel requisito?
  • L’agente l’ha costruito sulla vecchia versione del documento.

Una settimana con Nodary

Come può andare una settimana quando il lavoro vive in Nodary. Ogni giorno usa qualcosa che il prodotto fa già oggi.

  1. Lunedì

    Scrivi la specifica da un modello

    Comincia la specifica della funzionalità con il modello Specifica di prodotto (PRD): il problema e chi lo vive, obiettivi e non obiettivi, requisiti come lista di caselle, metriche di successo con valore di partenza e obiettivo. Collegala alla ricerca e al progetto tecnico con [[Titolo]], così ognuna di quelle pagine elenca la specifica che punta a lei.

    Modelli di requisiti di prodotto
  2. Martedì

    Metti il flusso e i numeri nella specifica

    Disegna un diagramma Mermaid di flusso, di sequenza o di stati dentro la specifica, dove avviene la discussione; un diagramma rotto viene spiegato in parole semplici. Aggiungi un foglio per le stime o un modello di prezzo con le ipotesi accanto, calcolato con circa 60 funzioni, e commenta una singola cella quando un numero non torna.

    Fogli, proprietà e viste in tempo reale nei documenti
  3. Mercoledì

    Segui ogni specifica per stato

    Dai a ogni documento uno stato (bozza, in revisione, approvato, pubblicato, completato o bloccato), un responsabile e una scadenza. Una vista in tempo reale raccoglie i documenti del rilascio in una board, una tabella o una timeline, e la vista di avanzamento traccia un burn-up che dice se la milestone arriva alla data prevista.

    Pianificare i rilasci sui documenti
    Una vista di avanzamento in tempo reale di una milestone in Nodary: il lavoro finito rispetto al perimetro, il burn-up verso la data obiettivo e ciò che resta, prima i documenti in ritardo, con chi li ha.
  4. Giovedì

    Revisiona la specifica, registra la decisione

    Chiedi a un proprietario o amministratore dello spazio, o a un amministratore del progetto, di revisionare la specifica; la approva o la rimanda con una nota, firmata con chi e quando, e la decisione può essere pubblicata in un canale Slack o Discord. Scrivi il perché in una Decisione architetturale (ADR), segnala come canone e segna come sostituita la versione che rimpiazza, così nessuno costruisce sulla pagina sbagliata.

    Revisioni e approvazioni
  5. Venerdì

    Passa il lavoro agli sviluppatori e ai loro agenti

    Gli sviluppatori collegano Claude Code, Cursor o VS Code allo spazio via MCP, con OAuth o con una chiave limitata a un progetto. L’agente legge la specifica, il progetto tecnico collegato e le decisioni, e sa quali pagine sono canone prima di fidarsene. Quando due documenti si contraddicono, Nodary mostra i due passaggi affiancati.

    Collegare Cursor alla documentazione di prodotto
    La sezione Chiavi API e MCP di un profilo Nodary: l’indirizzo MCP da incollare in un client MCP e una chiave agente per lo spazio.

Un modello per cominciare

Modello integrato

Specifica di prodotto (PRD)

Comincia ogni funzionalità con la Specifica di prodotto (PRD), uno dei 30 modelli integrati, in 12 lingue. Affiancale il Progetto tecnico e la Decisione architetturale (ADR) quando il lavoro lo richiede, e salva la specifica del tuo team come modello appena funziona.

  • Obiettivi e non obiettivi, per discutere il perimetro una volta sola
  • Requisiti come caselle spuntate al rilascio
  • Metriche di successo con valore di partenza e obiettivo
Specifica di prodotto (PRD): il modello gratuito
E una missione di contesto

Preparare una decisione di prodotto

Confrontare le opzioni tenendo presenti evidenze e compromessi.

Confronta le opzioni documentate nelle fonti selezionate con l’obiettivo del prodotto, i bisogni degli utenti e i vincoli di consegna. Individua le ipotesi, i compromessi e le evidenze che ancora mancano.

Una missione per lo studio del contesto, pronta da adattare: non contiene documenti di progetto, solo il compito e le fonti da raccogliere.

Fonti da raccogliere
  • Definizione del problema e feedback degli utenti
  • Opzioni e specifiche di prodotto
  • Vincoli di consegna e decisioni precedenti

Risultato atteso Una tabella di confronto, una raccomandazione condizionata supportata dalle fonti e le domande da chiarire prima di decidere. Non presentare la raccomandazione come una decisione approvata.

Prova questa missione nella demo

Tre richieste per il tuo agente IA

La stessa connessione MCP serve la product manager in ChatGPT e lo sviluppatore in Cursor. Gli agenti leggono e scrivono i documenti blocco per blocco nei limiti del ruolo della persona, e un nuovo tentativo con la stessa chiave non scrive mai due volte.

Collega un agente

Tu chiediLeggi la specifica del nuovo checkout e le decisioni collegate, poi elenca i requisiti che non hanno ancora criteri di accettazione.

Strumenti che chiama
  • search_documents
  • get_document
  • get_star

Tu chiediConfronta la specifica attuale dell’esportazione con la versione approvata la settimana scorsa e riassumi cosa è cambiato.

Strumenti che chiama
  • list_versions
  • diff_versions

Tu chiediCrea dal modello un Progetto tecnico per la funzione di esportazione e collegalo alla specifica.

Strumenti che chiama
  • create_from_template
  • link_stars

Cosa Nodary non fa

  • Nessuna sincronizzazione con Jira, Linear o GitHub: ticket e pull request restano nei loro strumenti, collegati dalla specifica.
  • Nodary non legge il tuo repository di codice: un agente di codice legge il codice dal suo lato e i documenti tramite Nodary.
  • Nessuna rilevazione delle ore né pianificazione Gantt: spostare un documento su una timeline non sposta mai quelli che ne dipendono.
  • Nessun single sign-on (SSO) né installazione in casa: Nodary gira su AWS negli Stati Uniti.

Il piano giusto

Pro

15 € per postazione al mese, fatturazione mensile

Per chi lavora da solo o per un piccolo team pronto al lancio.

Pro è adatto alla maggior parte dei team di prodotto: documenti illimitati, più progetti, e l’MCP e Studio AI per ogni membro. Passa a Studio quando ti servono più membri o progetti riservati alle persone che vi vengono aggiunte.

  • Fino a 5 membri
  • Fino a 10 progetti, documenti illimitati
  • 5 GB di file
  • Studio AI: 800 ☄ per postazione ogni mese, condivise dal team
Confronta tutti i piani

Domande

Nodary può sostituire la nostra wiki per le specifiche di prodotto?

Sì, per i team che vogliono specifiche, decisioni e piani in uno spazio collegato con la loro cronologia. Per cominciare importa Markdown, Word, HTML o un’esportazione di Notion. Non è un sistema di ticket: tieni i ticket dello sprint nel loro strumento e collegali dalla specifica.

Nodary si integra con Jira, Linear o GitHub?

Oggi no. Incolla i link a ticket e pull request in qualsiasi documento. Un agente con accesso a entrambi gli strumenti, come Claude Code con il repository aperto, legge il codice da una parte e la documentazione tramite Nodary dall’altra.

Come leggono le nostre specifiche gli agenti di codice?

Tramite il server MCP di Nodary. Claude Code, Cursor, VS Code e gli altri client MCP si collegano con OAuth o con una chiave API, che può essere limitata a un progetto, e leggono o scrivono documenti nei limiti del ruolo della persona. Ogni scrittura di un agente conserva la versione precedente.

Possiamo tenere un registro delle decisioni architetturali?

Sì. Comincia ciascuna con il modello Decisione architetturale (ADR): stato, data, chi decide, contesto, decisione, alternative, conseguenze. Segna quella accettata come canone e una vecchia come sostituita dalla nuova. Gli agenti conoscono lo stato di un documento prima di leggerlo.

Persone esterne al team possono leggere una specifica?

Sì, con un link di condivisione in sola lettura a un documento, a un documento con tutto ciò che contiene o all’intero spazio, per i giorni che scegli o senza scadenza, revocabile in qualsiasi momento. Per commentare, una persona entra nello spazio come membro.

Dai le sue ragioni alla tua prossima specifica.

Inizia gratis con un progetto, oppure apri il progetto di esempio nella demo per vedere una board per stato e una tabella dei documenti in ritardo: senza account.

Gratis per due membri e dieci documenti. Senza carta.