Dokumentacja produktowa, która trzyma powody obok wymagań.
Specyfikacja rzadko wyjaśnia całą decyzję. W Nodary specyfikacja funkcji stoi obok badań, projektu technicznego i decyzji, które ją ukształtowały, każde z osobą odpowiedzialną i statusem. Agenci kodujący Twoich programistów czytają to wszystko przez MCP i wiedzą, które strony są aktualne.
Problem słowami Twojego zespołu
Zespoły produktowe i inżynierskie piszą dużo, a potem tracą rachubę, która strona obowiązuje. Specyfikacja mówi jedno, zgłoszenie drugie, a decyzja, która zmieniła oba, zapadła na rozmowie, której nikt nie spisał. Gdy programistka, albo agent kodujący, przejmuje pracę, wymagania przychodzą bez powodów, a te same pytania wracają na przeglądzie.
- Czy ta specyfikacja jest zatwierdzona, czy to wciąż szkic?
- Dlaczego usunęliśmy to wymaganie?
- Agent zbudował to według starej wersji dokumentu.
Tydzień z Nodary
Jak może wyglądać tydzień, gdy praca żyje w Nodary. Każdy dzień korzysta z czegoś, co produkt robi już dziś.
- Poniedziałek
Napisz specyfikację z szablonu
Zacznij specyfikację funkcji od szablonu Specyfikacja produktu (PRD): problem i kogo dotyczy, cele i nie-cele, wymagania jako lista do odhaczania, wskaźniki sukcesu z punktem wyjścia i celem. Połącz ją przez [[Tytuł]] z badaniami i projektem technicznym, żeby każda z tych stron wymieniała specyfikację, która do niej prowadzi.
Szablony wymagań produktowych - Wtorek
Umieść przepływ i liczby w specyfikacji
Narysuj diagram Mermaid, przepływu, sekwencji albo stanów, w samej specyfikacji, tam gdzie toczy się dyskusja; zepsuty diagram jest wyjaśniany prostymi słowami. Dodaj arkusz z szacunkami lub modelem cenowym, z założeniami obok i około 60 funkcjami, i skomentuj pojedynczą komórkę, gdy liczba wygląda źle.
Arkusze, właściwości i widoki na żywo w dokumentach - Środa
Śledź każdą specyfikację po statusie
Nadaj każdemu dokumentowi status (szkic, w recenzji, zatwierdzone, opublikowane, gotowe lub zablokowane), osobę odpowiedzialną i termin. Widok na żywo zbiera dokumenty wydania w tablicę, tabelę lub oś czasu, a widok postępu rysuje burn-up, który mówi, czy kamień milowy zmieści się w docelowej dacie.
Planuj wydania na dokumentach
- Czwartek
Zrecenzuj specyfikację, zapisz decyzję
Poproś właściciela lub administratora przestrzeni albo administratora projektu o recenzję specyfikacji; zatwierdza ją albo odsyła z notatką, z podpisem: kto i kiedy, a decyzja może trafić na kanał Slacka lub Discorda. Zapisz uzasadnienie w Decyzji architektonicznej (ADR), oznacz ją jako kanon, a wersję, którą zastępuje, jako zastąpioną, żeby nikt nie budował na niewłaściwej stronie.
Recenzje i zatwierdzenia - Piątek
Przekaż pracę programistom i ich agentom
Programiści łączą Claude Code, Cursor lub VS Code z przestrzenią przez MCP, przez OAuth albo kluczem ograniczonym do jednego projektu. Agent czyta specyfikację, połączony projekt techniczny i decyzje, i wie, które strony są kanonem, zanim się na nich oprze. Gdy dwa dokumenty sobie przeczą, Nodary pokazuje oba fragmenty obok siebie.
Połącz Cursor z dokumentacją produktu
Szablon na start
Specyfikacja produktu (PRD)
Zaczynaj każdą funkcję od Specyfikacji produktu (PRD), jednego z 30 wbudowanych szablonów, w 12 językach. Dołącz Projekt techniczny i Decyzję architektoniczną (ADR), gdy praca tego wymaga, i zapisz specyfikację swojego zespołu jako szablon, gdy już się sprawdzi.
- Cele i nie-cele, żeby zakres omawiać tylko raz
- Wymagania jako pola odhaczane przy wydaniu
- Wskaźniki sukcesu z punktem wyjścia i celem
Przygotuj decyzję produktową
Porównaj opcje, mając na widoku dowody i kompromisy.
Porównaj opcje opisane w wybranych źródłach z celem produktu, potrzebami użytkowników i ograniczeniami dostawy. Wskaż założenia, kompromisy i dowody, których wciąż brakuje.
Misja dla studia kontekstu, gotowa do dostosowania: nie zawiera dokumentów projektu, tylko zadanie i źródła do zebrania.
Źródła do zebrania- Opis problemu i opinie użytkowników
- Opcje i specyfikacje produktu
- Ograniczenia dostawy i wcześniejsze decyzje
Oczekiwany wynik Tabela porównawcza, warunkowa rekomendacja poparta źródłami oraz pytania do rozstrzygnięcia przed decyzją. Nie przedstawiaj rekomendacji jako zatwierdzonej decyzji.
Trzy prośby do Twojego agenta AI
To samo połączenie MCP służy menedżerce produktu w ChatGPT i programiście w Cursorze. Agenci czytają i zapisują dokumenty blok po bloku w granicach roli danej osoby, a ponowna próba z tym samym kluczem nigdy nie zapisuje dwa razy.
Podłącz agentaPytaszPrzeczytaj specyfikację przebudowy płatności i powiązane decyzje, a potem wypisz wymagania bez kryteriów akceptacji.
search_documentsget_documentget_star
PytaszPorównaj obecną specyfikację eksportu z wersją zatwierdzoną w zeszłym tygodniu i podsumuj zmiany.
list_versionsdiff_versions
PytaszUtwórz z szablonu Projekt techniczny dla funkcji eksportu i połącz go ze specyfikacją.
create_from_templatelink_stars
Czego Nodary nie robi
- Brak synchronizacji z Jira, Linear czy GitHub: zgłoszenia i pull requesty zostają w swoich narzędziach, podlinkowane ze specyfikacji.
- Nodary nie czyta Twojego repozytorium kodu: agent kodujący czyta kod po swojej stronie, a dokumenty przez Nodary.
- Brak śledzenia czasu i planowania Gantta: przesunięcie dokumentu na osi czasu nigdy nie przesuwa tych, które od niego zależą.
- Brak logowania jednokrotnego (SSO) i hostingu u siebie: Nodary działa na AWS w Stanach Zjednoczonych.
Właściwy plan
Pro
15 € za stanowisko miesięcznie, rozliczane miesięcznie
Dla samodzielnego twórcy lub małego zespołu gotowego do premiery.
Pro pasuje do większości zespołów produktowych: nieograniczona liczba dokumentów, kilka projektów oraz MCP i Studio AI dla każdego członka. Przejdź na Studio, gdy potrzebujesz więcej członków albo projektów zastrzeżonych dla dodanych do nich osób.
- Członkowie: do 5
- Projekty: do 10, dokumenty: bez limitu
- 5 GB na pliki
- Studio AI: 800 ☄ na stanowisko co miesiąc, we wspólnej puli zespołu
Pytania
Czy Nodary może zastąpić naszą wiki ze specyfikacjami produktu?
Tak, w zespołach, które chcą mieć specyfikacje, decyzje i plany w jednej połączonej przestrzeni z historią. Na start zaimportuj Markdown, Word, HTML lub eksport z Notion. To nie jest system zgłoszeń: trzymaj zgłoszenia sprintu w ich narzędziu i linkuj je ze specyfikacji.
Czy Nodary integruje się z Jira, Linear lub GitHubem?
Dziś nie. Wklejaj linki do zgłoszeń i pull requestów w dowolnym dokumencie. Agent z dostępem do obu narzędzi, na przykład Claude Code z otwartym repozytorium, czyta kod po jednej stronie, a dokumentację przez Nodary po drugiej.
Jak agenci kodujący czytają nasze specyfikacje?
Przez serwer MCP Nodary. Claude Code, Cursor, VS Code i inne klienty MCP logują się przez OAuth lub kluczem API, który można ograniczyć do jednego projektu, i czytają lub zapisują dokumenty w granicach roli danej osoby. Każdy zapis agenta zachowuje poprzednią wersję.
Czy możemy prowadzić rejestr decyzji architektonicznych?
Tak. Zaczynaj każdą od szablonu Decyzja architektoniczna (ADR): status, data, decydenci, kontekst, decyzja, rozważane opcje, konsekwencje. Oznacz przyjętą jako kanon, a starą jako zastąpioną przez nową. Agenci znają status dokumentu, zanim go przeczytają.
Czy osoby spoza zespołu mogą przeczytać specyfikację?
Tak, przez link udostępniania tylko do odczytu do jednego dokumentu, dokumentu z wszystkim pod nim lub całej przestrzeni, na wybraną liczbę dni albo bez końca, odwoływalny w każdej chwili. Żeby komentować, osoba dołącza do przestrzeni jako członek.
Daj swojej następnej specyfikacji jej powody.
Zacznij za darmo z jednym projektem albo otwórz przykładowy projekt w demo z tablicą statusów i tabelą spóźnionych dokumentów: bez konta.
Za darmo dla dwóch członków i dziesięciu dokumentów. Bez karty.