Πρότυπο Εγγράφου Απαιτήσεων Προϊόντος (PRD) (+ Ένα Πλήρες Παράδειγμα Εργασίας για Αντιγραφή)

Πρότυπο Εγγράφου Απαιτήσεων Προϊόντος (PRD) (+ Ένα Πλήρες Παράδειγμα Εργασίας για Αντιγραφή)

Τελευταία ενημέρωση: 28 Ιουλίου 2026.

Οι περισσότερες σελίδες με πρότυπο εγγράφου απαιτήσεων προϊόντος σού δίνουν μια άδεια φόρμα. Το πρότυπο της Atlassian είναι τέσσερις ενότητες οδηγιών γύρω από έναν κενό πίνακα μετρικών επιτυχίας. Το πρότυπο του Product School έχει «(with Example)» στον τίτλο του και δεν περιέχει κανένα παράδειγμα. Το παρακάτω block markdown με 12 ενότητες είναι ολόκληρο το πρότυπο, ελεύθερο πρόσβασης, έτοιμο για αντιγραφή. Στην Ενότητα 4 συμπληρώνουμε και τις 12 αυτές ενότητες για μια πλήρη υλοποίηση: ένα invoice portal πελάτη που διαβάζει PDF με ένα LLM και στέλνει τις αμφίβολες περιπτώσεις σε άνθρωπο. Αντέγραψε την άδεια. Διάβασε τη συμπληρωμένη. Γράψε τη δική σου.

Βασικά Συμπεράσματα

• Ένα PRD απαντά στο τι θα χτιστεί και γιατί· το technical design doc απαντά στο πώς.
• Οι 12 ενότητες ταιριάζουν σε κάθε μέγεθος έργου. Ένα έγγραφο μιας σελίδας είναι το ίδιο πρότυπο με λιγότερες γραμμές.
• Οι μη-στόχοι πρέπει να γράφονται. Ένας AI coding agent δεν μπορεί να συναγάγει το πεδίο εφαρμογής από την παράλειψη.
• Τα κριτήρια αποδοχής πρέπει να είναι ελέγξιμα από μηχανή: «p95 κάτω από 400ms», ποτέ «γρήγορο».

Ποιο Σχήμα PRD Πρέπει να Χρησιμοποιήσεις;

Διάλεξε το σχήμα ανάλογα με το ποιος διαβάζει το έγγραφο, όχι με το πόσο μεγάλο φαίνεται το προϊόν. Μια μεμονωμένη λειτουργία που πάει στους δικούς σου μηχανικούς χρειάζεται ένα έγγραφο μιας σελίδας. Μια υλοποίηση που παραδίδεται σε εξωτερική ομάδα χρειάζεται το πλήρες PRD 12 ενοτήτων, γιατί τα κριτήρια αποδοχής λειτουργούν και ως πύλες έγκρισης. Ένα spec που πάει σε έναν AI coding agent χρειάζεται τις ίδιες δώδεκα ενότητες χωρισμένες σε φάσεις.

Το πρότυπο εγγράφου απαιτήσεων προϊόντος μιας σελίδας που όλοι ζητάνε δεν είναι ξεχωριστό artifact. Το ευρέως αντιγραμμένο έγγραφο μιας σελίδας του Lenny Rachitsky, δημοσιευμένο με πραγματικά παραδείγματα στο newsletter του, είναι ο ίδιος σκελετός χωρίς την τυπολατρία. Ένα έγγραφο μιας σελίδας δεν είναι διαφορετικό έγγραφο. Είναι οι ίδιες δώδεκα ενότητες με τις κενές γραμμές διαγραμμένες.

Οι agile ομάδες κάνουν συχνά αυτή την ερώτηση κι αυτές, συνήθως διατυπωμένη ως το αν ένα PRD αντέχει μόλις υπάρξει backlog. Αντέχει, ως έγγραφο μιας σελίδας: το PRD κρατά το γιατί και τα όρια, τα tickets κρατούν τη δουλειά.

Το Πρότυπο PRD (Markdown για Αντιγραφή-Επικόλληση)

Ορίστε ολόκληρο το πράγμα σε markdown, ελεύθερο πρόσβασης, χωρίς email wall. Επικόλλησέ το σε Notion, Confluence, Google Docs, Linear, Word, ή κάνε το commit στο GitHub ως PRD.md και άσε το να κάνει version δίπλα στον κώδικα. Ο κόσμος ζητά αυτό το πρότυπο σε εννιά διαφορετικές μορφές· το markdown είναι αυτό που επιβιώνει σε επικόλληση σε όλες, και είναι το μόνο που ένας AI coding agent διαβάζει καθαρά.

# PRD: [Όνομα προϊόντος ή λειτουργίας]

## 1. Κεφαλίδα
- Υπεύθυνος (προϊόν):
- Επικεφαλής μηχανικός:
- Επικεφαλής σχεδίασης:
- Κατάσταση: Πρόχειρο | Υπό αξιολόγηση | Εγκεκριμένο | Σε παραγωγή
- Τελευταία ενημέρωση:
- Ιστορικό αλλαγών: ημερομηνία / συγγραφέας / τι άλλαξε

## 2. Δήλωση προβλήματος
Μία παράγραφος. Ποιος υποφέρει, πόσο συχνά, τι κοστίζει σήμερα. Καμία γλώσσα λύσης.

## 3. Στόχοι & μετρικές επιτυχίας
| Στόχος | Μετρική | Βάση αναφοράς | Στόχος | Μετράται από | Ημερομηνία |
|---|---|---|---|---|---|

## 4. Μη-στόχοι
Διατυπωμένοι θετικά: «Αυτή η φάση δεν περιλαμβάνει X.»

## 5. Χρήστες & προφίλ
Ποιος το χρησιμοποιεί, τι ήδη γνωρίζει, ποια συσκευή, πόσο συχνά.

## 6. Ιστορίες χρηστών & κριτήρια αποδοχής
Ως [προφίλ χρήστη], θέλω [ενέργεια], ώστε να [αποτέλεσμα].
- Given [πλαίσιο], when [συμβάν], then [παρατηρήσιμο αποτέλεσμα].

## 7. Λειτουργικές απαιτήσεις
Αριθμημένες. Μία απαίτηση ανά γραμμή. Ελέγξιμη. Καμία πρόταση που περιέχει «και».

## 8. Μη λειτουργικές απαιτήσεις
Απόδοση / ασφάλεια & πολυμισθωτικότητα / τοποθεσία & διατήρηση δεδομένων / προσβασιμότητα / διαθεσιμότητα.

## 9. Εξαρτήσεις & ενσωματώσεις
Εξωτερικά συστήματα, API, διαπιστευτήρια, ποιος έχει την πρόσβαση, χρόνος υλοποίησης.

## 10. Ορόσημα & φάσεις
| Φάση | Πεδίο εφαρμογής | Κριτήρια εξόδου | Στόχος ημερομηνίας |
|---|---|---|---|

## 11. Ανοιχτά ερωτήματα & κίνδυνοι
| Ερώτημα ή κίνδυνος | Υπεύθυνος | Χρειάζεται έως | Επίπτωση αν δεν απαντηθεί |
|---|---|---|---|

## 12. Παράρτημα & σύνδεσμοι
Σχέδια, έρευνα, σημειώσεις ανταγωνιστών, προηγούμενα tickets, συμβάσεις.

Οι δώδεκα ενότητες, με τη σειρά: κεφαλίδα, δήλωση προβλήματος, στόχοι και μετρικές επιτυχίας, μη-στόχοι, χρήστες και προφίλ, ιστορίες χρηστών με κριτήρια αποδοχής, λειτουργικές απαιτήσεις, μη λειτουργικές απαιτήσεις, εξαρτήσεις και ενσωματώσεις, ορόσημα και φάσεις, ανοιχτά ερωτήματα και κίνδυνοι, παράρτημα.

Τι Πρέπει να Περιλαμβάνει ένα PRD; Οι 12 Ενότητες, και η Αδύναμη Εκδοχή της Καθεμιάς

Ένα έγγραφο απαιτήσεων προϊόντος πρέπει να περιλαμβάνει δήλωση προβλήματος, μετρήσιμους στόχους, ρητούς μη-στόχους, προφίλ χρηστών, ιστορίες χρηστών με κριτήρια αποδοχής, λειτουργικές και μη λειτουργικές απαιτήσεις, εξαρτήσεις, ορόσημα, ανοιχτά ερωτήματα με υπευθύνους, και ιστορικό αλλαγών. Οτιδήποτε άλλο είναι παράρτημα. Το τεστ για κάθε γραμμή είναι αυτό που το ISO/IEC/IEEE 29148:2018 εφαρμόζει γενικά στις απαιτήσεις: επαληθεύσιμη, μονοσήμαντη, μοναδική.

Τα περισσότερα PRD αποτυγχάνουν σε αυτό το τεστ στα ίδια τρία σημεία.

Δύο ενότητες αξίζουν περισσότερη προσοχή από αυτή που συνήθως παίρνουν.

Οι μη λειτουργικές απαιτήσεις είναι εκεί όπου το πεδίο εφαρμογής διπλασιάζεται σιωπηλά. Απόδοση, πολυμισθωτικότητα, τοποθεσία δεδομένων, διατήρηση, προσβασιμότητα, διαθεσιμότητα: καθεμιά από αυτές είναι μια απόφαση μηχανικής με κόστος, και καμία τους δεν εμφανίζεται σε μια ιστορία χρήστη. Βάλτε τη γραμμή ασφαλείας εδώ αντί σε ένα ασαφές χειρονομιακό σχόλιο, και γράψτε τη με τον τρόπο που θα θέλατε να ελεγχθεί, χρησιμοποιώντας κάτι σαν τη λίστα ελέγχου ασφαλείας πριν την εκκίνηση μας ως πηγή. Αν η υλοποίηση έχει στοιχείο AI, οι απαιτήσεις ετοιμότητας παραγωγής ανήκουν κι αυτές εδώ, όχι σε μια μετέπειτα φάση «σκλήρυνσης» που ποτέ δεν προγραμματίζεται: η λίστα ελέγχου PoC-σε-παραγωγή μας είναι η εκδοχή που χρησιμοποιούμε.

Τα ανοιχτά ερωτήματα χρειάζονται τρεις στήλες, όχι μία. Ερώτημα, υπεύθυνος, ημερομηνία που χρειάζεται. Ένα ερώτημα χωρίς υπεύθυνο είναι μια απόφαση που κανείς δεν παίρνει, και θα εμφανιστεί ως αίτημα αλλαγής στην έκτη εβδομάδα. Αξίζει να ειπωθεί: ένα PRD είναι αυτό που γράφετε αφού έχετε αποφασίσει να φτιάξετε αντί να αγοράσετε. Αν η δήλωση προβλήματος ακόμα διαβάζεται σαν λίστα αγορών με λειτουργίες, η απόφαση build-versus-buy δεν έχει πραγματικά συμβεί ακόμα.

Το Παράδειγμα Εργασίας: Ένα PRD Invoice Portal, Συμπληρωμένο

Ορίστε ένα πλήρες παράδειγμα εργασίας, με και τις 12 ενότητες συμπληρωμένες. Η υλοποίηση: ένα invoice portal πελάτη για έναν μεσαίου μεγέθους πάροχο logistics. Οι πελάτες ανεβάζουν PDF τιμολόγια, ένα LLM εξάγει τις γραμμές, το σύστημα επισημαίνει ασυμφωνίες με την εγγραφή παραγγελίας, και ό,τι δεν είναι σίγουρο πηγαίνει σε ουρά ανθρώπινης αξιολόγησης. Stack: Next.js, Supabase/Postgres, ένα βήμα εξαγωγής LLM. Αντιγράψτε το, τυπώστε το, εξάγετέ το σε PDF, ό,τι χρειάζεστε.

# PRD: Invoice Portal Πελάτη, Φάση 1

## 1. Κεφαλίδα
- Υπεύθυνος (προϊόν): Διευθυντής Λειτουργιών, πλευρά πελάτη
- Επικεφαλής μηχανικός: Delivery lead, Techsy
- Επικεφαλής σχεδίασης: Product designer, Techsy
- Κατάσταση: Εγκεκριμένο για υλοποίηση
- Τελευταία ενημέρωση: 2026-07-28
- Ιστορικό αλλαγών:
  - 2026-07-14 / προϊόν / πρώτο προσχέδιο
  - 2026-07-21 / μηχανική / προστέθηκε κανόνας κατωφλίου εμπιστοσύνης στο 6.2
  - 2026-07-28 / προϊόν / το ERP write-back μετακινήθηκε στους μη-στόχους

## 2. Δήλωση προβλήματος
Το προσωπικό λειτουργιών λαμβάνει τιμολόγια πελατών ως PDF μέσω email και τα
καταχωρεί χειροκίνητα στο σύστημα παραγγελιών. Ο όγκος ξεπερνά τα 300 τιμολόγια
την εβδομάδα, ο μέσος χρόνος επεξεργασίας είναι περίπου 6 λεπτά το καθένα, και
περίπου το 4% φέρει σφάλμα καταχώρισης που εντοπίζεται μόνο κατά την τελική
συμφωνία μήνα. Κάθε διόρθωση κοστίζει ένα δεύτερο πέρασμα και ένα τηλεφώνημα.

## 3. Στόχοι & μετρικές επιτυχίας
| Στόχος | Μετρική | Βάση αναφοράς | Στόχος | Μετράται από | Ημερομηνία |
|---|---|---|---|---|---|
| Μείωση χειροκίνητης επεξεργασίας | Μέσος χρόνος επεξεργασίας | 6 λεπτά | κάτω από 90 δευτ. | Ops dashboard, εβδομαδιαία διάμεσος | 2026-11-01 |
| Μείωση σφαλμάτων καταχώρισης | Τιμολόγια που διορθώνονται στη συμφωνία | 4% | κάτω από 1% | Μηνιαία αναφορά οικονομικών | 2026-12-01 |
| Περιορισμός φόρτου αξιολόγησης | Ποσοστό που στέλνεται σε ανθρώπινη αξιολόγηση | n/a | κάτω από 25% | Μετρικές ουράς portal | 2026-11-01 |

## 4. Μη-στόχοι
Αυτή η φάση δεν υποστηρίζει τιμολόγια πολλαπλών νομισμάτων, ERP write-back,
πιστωτικά σημειώματα self-service για τον πελάτη, ή εφαρμογή για κινητά. Η
εξαγωγή δεδομένων καλύπτει μόνο PDF. Φωτογραφίες έντυπων τιμολογίων και
σαρώσεις κάτω από 200 DPI απορρίπτονται κατά το ανέβασμα, με μήνυμα που
εξηγεί τον λόγο.

## 5. Χρήστες & προφίλ
- Υπάλληλος λειτουργιών (κύριο προφίλ, 6 άτομα): δουλεύει στην ουρά εξαιρέσεων
  όλη μέρα, βαθιά γνώση του domain, μόνο desktop.
- Επαφή λογιστηρίου πελάτη (εξωτερικό, ~140 λογαριασμοί): ανεβάζει τιμολόγια,
  χαμηλή ανοχή σε τριβή κατά τη ρύθμιση λογαριασμού.
- Οικονομικός διευθυντής (δευτερεύον προφίλ): αντλεί τη μηνιαία αναφορά,
  χρειάζεται ίχνος ελέγχου ανά τιμολόγιο.

## 6. Ιστορίες χρηστών & κριτήρια αποδοχής
6.1 Ως επαφή λογιστηρίου πελάτη, θέλω να ανεβάσω ένα PDF τιμολογίου, ώστε να
μη χρειάζεται να το στείλω με email και να περιμένω.
- Given ένα PDF κάτω από 20 MB στα 200 DPI ή καλύτερα, when το ανεβάζω, then
  το portal επιστρέφει έναν αριθμό αναφοράς μέσα σε 5 δευτερόλεπτα και
  εμφανίζει «Επεξεργασία».

6.2 Ως υπάλληλος λειτουργιών, θέλω οι εξαγωγές χαμηλής εμπιστοσύνης να
συγκρατούνται, ώστε τίποτα λάθος να μην εγκρίνεται αυτόματα.
- Given ένα αναλυμένο τιμολόγιο, when η εμπιστοσύνη εξαγωγής για οποιαδήποτε
  γραμμή είναι κάτω από 0.85, then το τιμολόγιο πηγαίνει στην ουρά αξιολόγησης
  και δεν εγκρίνεται ποτέ αυτόματα.

6.3 Ως υπάλληλος λειτουργιών, θέλω να βλέπω την ασυμφωνία σε ένα σημείο, ώστε
να μπορώ να τη λύσω χωρίς να ανοίξω το σύστημα παραγγελιών.
- Given ένα τιμολόγιο αντιστοιχισμένο σε παραγγελία, when οποιαδήποτε ποσότητα
  γραμμής ή τιμή μονάδας διαφέρει από την εγγραφή παραγγελίας, then το portal
  δείχνει και τις δύο τιμές δίπλα-δίπλα και επισημαίνει τη διαφορά.

6.4 Ως οικονομικός διευθυντής, θέλω να φιλτράρω τιμολόγια, ώστε να μπορώ να
κλείσω τον μήνα.
- Given τη λίστα τιμολογίων, when φιλτράρω κατά προμηθευτή, εύρος ημερομηνιών
  και κατάσταση, then τα αποτελέσματα επιστρέφουν σε κάτω από 400ms στο p95
  και η κενή κατάσταση προσφέρει «Καθαρισμός φίλτρων».

## 7. Λειτουργικές απαιτήσεις
1. Το ανέβασμα δέχεται μόνο PDF, μέγιστο 20 MB, ένα αρχείο ανά υποβολή.
2. Η εξαγωγή επιστρέφει προμηθευτή, αριθμό τιμολογίου, ημερομηνία, νόμισμα,
   και γραμμές με ποσότητα, τιμή μονάδας και σύνολο.
3. Κάθε γραμμή φέρει βαθμολογία εμπιστοσύνης μεταξύ 0 και 1.
4. Η αντιστοίχιση συγκρίνει το εξαγόμενο τιμολόγιο με την ανοιχτή παραγγελία
   βάσει αριθμού PO.
5. Οι εξαιρέσεις μπαίνουν σε ουρά με σειρά παλαιότερο-πρώτα, ανατεθειμένη σε
   έναν υπάλληλο.
6. Κάθε αλλαγή κατάστασης γράφει μία εγγραφή ελέγχου με τον εκτελεστή (actor),
   τη χρονική σφραγίδα (timestamp) και την προηγούμενη τιμή.
7. Τα εγκεκριμένα τιμολόγια εξάγονται ως CSV batch για το οικονομικό σύστημα.

## 8. Μη λειτουργικές απαιτήσεις
- Απόδοση: λίστα τιμολογίων p95 κάτω από 400ms. Η εξαγωγή ολοκληρώνεται μέσα
  σε 90 δευτερόλεπτα από το ανέβασμα, στο p95.
- Ασφάλεια & πολυμισθωτικότητα: απομόνωση ανά ενοικιαστή επιβεβλημένη στο
  επίπεδο γραμμής της βάσης δεδομένων. Ένας πελάτης δεν μπορεί ποτέ να
  διαβάσει το τιμολόγιο άλλου πελάτη. Επαληθεύεται από αυτοματοποιημένο test
  σε κάθε release.
- Τοποθεσία & διατήρηση δεδομένων: τα έγγραφα αποθηκεύονται στην ΕΕ. Τα
  πρωτότυπα διατηρούνται 7 χρόνια, τα payloads εξαγωγής 90 ημέρες.
- Προσβασιμότητα: η ουρά λειτουργεί πλήρως με πληκτρολόγιο, αντίθεση WCAG 2.2
  AA.
- Διαθεσιμότητα: 99.5% μηνιαίως, υποστήριξη κατά τις εργάσιμες ώρες.

## 9. Εξαρτήσεις & ενσωματώσεις
- Εγγραφές παραγγελιών: read-only replica Postgres. Την πρόσβαση την έχει η IT
  του πελάτη, τα διαπιστευτήρια χρειάζονται έως 2026-08-15.
- Πάροχος εξαγωγής LLM: σύμβαση και συμφωνία επεξεργασίας δεδομένων
  υπογεγραμμένη πριν ξεκινήσει η υλοποίηση.
- Ειδοποιήσεις email: υπάρχων πάροχος transactional email, το domain
  αποστολέα επαληθευμένο από τον πελάτη.

## 10. Ορόσημα & φάσεις
| Φάση | Πεδίο εφαρμογής | Κριτήρια εξόδου | Στόχος ημερομηνίας |
|---|---|---|---|
| P1 | Ανέβασμα, εξαγωγή, δρομολόγηση εμπιστοσύνης | 50 πραγματικά τιμολόγια από άκρο σε άκρο, κάτω από 25% σε ουρά | 2026-09-19 |
| P2 | Αντιστοίχιση παραγγελιών και προβολή ασυμφωνίας | Σωστή επισήμανση ασυμφωνίας σε 20 δοκιμαστικές περιπτώσεις | 2026-10-10 |
| P3 | Ίχνος ελέγχου, εξαγωγή CSV, αναφορές | Το οικονομικό κλείνει έναν μήνα μέσα στο portal | 2026-11-01 |

## 11. Ανοιχτά ερωτήματα & κίνδυνοι
| Ερώτημα ή κίνδυνος | Υπεύθυνος | Χρειάζεται έως | Επίπτωση αν δεν απαντηθεί |
|---|---|---|---|
| Ποιος αριθμός PO είναι έγκυρος όταν ένα τιμολόγιο δείχνει δύο; | Διευθυντής λειτουργιών πελάτη | 2026-08-08 | Η λογική αντιστοίχισης μπλοκάρεται |
| Οι 12 μεγαλύτεροι πελάτες στέλνουν σαρωμένα ή native PDF; | Delivery lead | 2026-08-08 | Το κατώφλι εμπιστοσύνης μπορεί να είναι λάθος |
| Έχει επιβεβαιωθεί η διατήρηση 7 ετών με τους νομικούς του πελάτη; | Οικονομικός διευθυντής πελάτη | 2026-08-22 | Αλλάζει ο σχεδιασμός αποθήκευσης και το κόστος |
| Κόστος εξαγωγής ανά τιμολόγιο στα 300/εβδομάδα | Delivery lead | 2026-09-05 | Άγνωστα unit economics |

## 12. Παράρτημα & σύνδεσμοι
Ανωνυμοποιημένο δείγμα τιμολογίων (40 αρχεία), schema πίνακα παραγγελιών,
τρέχουσα μελέτη χρόνου επεξεργασίας, ροές Figma για ανέβασμα και ουρά,
υπογεγραμμένο statement of work.

Τέσσερις επιλογές εκεί μέσα αξίζει να τις αναδείξουμε, γιατί η τεμπέλικη εκδοχή της καθεμιάς κοστίζει πραγματικά χρήματα.

Ενότητα 3, η βάση αναφοράς. Τα «6 λεπτά» δεν είναι διακόσμηση. Χωρίς μια βάση αναφοράς δεν μπορείτε να πείτε αν κάτι δούλεψε, και έξι μήνες αργότερα κάποιος θα το συζητά σε μια συνάντηση χωρίς δεδομένα. Η τεμπέλικη εκδοχή, «βελτίωση αποδοτικότητας», κάνει το έργο αδιάψευστο.

Ενότητα 4, ο μη-στόχος. Το ERP write-back μετακινήθηκε στους μη-στόχους στις 2026-07-28, αφού είχε υποτεθεί σιωπηρά κατά τη διάρκεια μιας κλήσης αξιολόγησης. Το να το γράψεις ως μη-στόχο κόστισε μία γραμμή και γλίτωσε μια διαμάχη για το πεδίο εφαρμογής.

Ενότητα 6.2, το κατώφλι εμπιστοσύνης. Αυτός είναι ο κανόνας που τα δικά μας πρώτα προσχέδια παραλείπουν πιο συχνά. Αν τον παραλείψεις, το σύστημα εγκρίνει αυτόματα τιμολόγια που θα έπρεπε να δει άνθρωπος, κάτι που είναι ακριβώς η αποτυχία που εξαφανίζει την εξοικονόμηση χρόνου που υποσχέθηκες στην ενότητα 3.

Ενότητα 11, οι υπεύθυνοι. Κάθε ανοιχτό ερώτημα έχει ένα όνομα και μια ημερομηνία. Αυτή η στήλη είναι η διαφορά ανάμεσα σε ένα έγγραφο και μια λίστα εκκρεμοτήτων που κανείς δεν κατέχει.

Το PRD σου λέει το τι. Δεν σου λέει πόσο θα διαρκέσει ή πόσο θα κοστίσει, κάτι που είναι ξεχωριστή άσκηση: δες τον καθορισμό του εύρους της υλοποίησης για αυτό το κομμάτι. Και ένας μη-στόχος που δεν έγραψες είναι μια λειτουργία που κάποιος θα χτίσει.

Πώς Γράφεις ένα PRD από το Οποίο ένα AI Coding Agent Μπορεί Πραγματικά να Χτίσει;

Ένα PRD γραμμένο για έναν AI coding agent ανταλλάσσει τη συντομία με τη ρητότητα. Ο agent δεν έχει άτυπο κοινό πλαίσιο, καμία κοινή ιστορία, και κανένα ένστικτο για το τι προφανώς δεν εννοούσες. Τέσσερις κανόνες καλύπτουν το μεγαλύτερο μέρος της διαφοράς, και προκύπτουν από την παρακολούθηση specs που πέτυχαν και απέτυχαν στις δικές μας υλοποιήσεις με agents.

1. Δηλώστε τους μη-στόχους θετικά. Οι άνθρωποι συνάγουν το πεδίο εφαρμογής από την παράλειψη. Οι agents όχι. Το «Μην προσθέσετε αυθεντικοποίηση σε αυτή τη φάση» πρέπει να είναι μια πρόταση μέσα στο έγγραφο, αλλιώς το auth θα χτιστεί, θα δοκιμαστεί, και θα σου παραδοθεί.

2. Μοιράστε τη δουλειά σε φάσεις. Ένα μονολιθικό έγγραφο 40 σελίδων παράγει ένα σίγουρο, απλωμένο, μισοσωστό pull request. Χωρίστε το PRD σε περάσματα που ένας agent ολοκληρώνει σε μία περιορισμένη εκτέλεση, καθένα με τα δικά του κριτήρια εξόδου.

3. Κάντε τα κριτήρια αποδοχής ελέγξιμα από μηχανή. Το «γρήγορο» δεν είναι απαίτηση, είναι διάθεση. Το «p95 κάτω από 400ms στο endpoint της λίστας τιμολογίων» είναι ένα test που ο agent μπορεί να γράψει πριν γράψει τη λειτουργία.

4. Βάλτε τα μονοπάτια αρχείων και τους περιορισμούς stack μέσα στο έγγραφο, όχι στο chat. Το context του chat εξατμίζεται ανάμεσα σε sessions. Το spec όχι. Γι' αυτό έχει επίσης σημασία το plan mode του Claude Code: διαβάζει τα αρχεία σου και προτείνει ένα σχέδιο χωρίς να επεξεργαστεί τίποτα μέχρι να το εγκρίνεις, και αυτό το βήμα έγκρισης είναι πολύ πιο χρήσιμο όταν το σχέδιο ελέγχεται σε σχέση με ένα γραπτό spec αντί για τη μνήμη σου για το τι ζήτησες.

Ορίστε το invoice portal, χωρισμένο σε μία φάση που ένας agent μπορεί να εκτελέσει σε ένα μόνο πέρασμα.

# Εργασία υλοποίησης: Ανέβασμα και εξαγωγή τιμολογίων (Φάση 1 από 3)

## Περιορισμοί stack (να μην αντικατασταθούν)
Next.js 15 App Router, TypeScript, Supabase Postgres με row-level security,
ανάπτυξη σε Vercel. Καμία νέα εξάρτηση χωρίς να ρωτήσετε πρώτα.

## Αρχεία που μπορείτε να δημιουργήσετε ή να επεξεργαστείτε
- app/(portal)/invoices/upload/page.tsx
- app/api/invoices/route.ts
- lib/extraction/parse-invoice.ts
- supabase/migrations/0007_invoices.sql

## Μην αγγίζετε
- lib/auth/*  (το auth έρχεται στη Φάση 2· μην προσθέσετε ροές σύνδεσης τώρα)
- Οτιδήποτε κάτω από app/(marketing)/
- Το υπάρχον schema παραγγελιών. Διαβάστε το. Ποτέ μην το κάνετε migrate.

## Κριτήρια αποδοχής (γράψτε τα πρώτα ως tests)
1. Το POST /api/invoices απορρίπτει μη-PDF με 415 και αρχεία άνω των 20 MB με
   413.
2. Μια γραμμή με confidence < 0.85 ορίζει invoice.status = 'review', ποτέ
   'approved'.
3. Κάθε insert γράφει μια γραμμή ελέγχου με actor_id, action, created_at.
4. Το GET /api/invoices?vendor=&from=&to=&status= επιστρέφει σε κάτω από
   400ms πάνω σε ένα 10,000-row seed.

## Εκτός πεδίου για αυτό το πέρασμα
Αντιστοίχιση παραγγελιών, UI ασυμφωνιών, εξαγωγή CSV, ειδοποιήσεις email.

Τρία πράγματα άλλαξαν σε σχέση με την ανθρώπινη εκδοχή: εμφανίστηκαν μονοπάτια αρχείων, εμφανίστηκε μια λίστα «μην αγγίζετε», και τα κριτήρια αποδοχής έγιναν assertions αντί για προτάσεις. Ποιος agent θα το εμπιστευτείς έχει λιγότερη σημασία απ' όσο νομίζει ο κόσμος, αν και η σύγκριση coding agents αξίζει μια ανάγνωση πριν δεσμευτείς. Κράτα τις απαιτήσεις και τους κανόνες έργου σε ξεχωριστά αρχεία: τα Cursor rules και CLAUDE.md κρατούν συμβάσεις και εργαλεία, το PRD κρατά το τι θα χτιστεί. Αν θέλεις βοήθεια από AI για να παράγεις το πεδίο εφαρμογής εξαρχής αντί απλώς να το καταναλώνεις, αυτή είναι διαφορετική ροή εργασίας. Και για το ίδιο το βήμα εξαγωγής, η επιλογή μοντέλου και ο βρόχος αξιολόγησης είναι δική τους δουλειά ενσωμάτωσης AI.

Τι Αλλάζει Όταν το PRD Πηγαίνει σε μια Εξωτερική Ομάδα

Όταν το PRD πηγαίνει σε ένα agency ή σε έναν contractor, σταματά να είναι ένα έγγραφο ευθυγράμμισης και γίνεται γλώσσα σύμβασης. Η ασάφεια που μια εσωτερική ομάδα λύνει με μια συζήτηση δύο λεπτών γίνεται αίτημα αλλαγής με τιμή. Η έρευνα Pulse of the Profession του PMI βρήκε ότι το 47% των ανεπιτυχών έργων χάνει τους στόχους του εξαιτίας ανακριβούς διαχείρισης απαιτήσεων. Αυτός είναι όλος ο λόγος που υπάρχει αυτό το έγγραφο.

Τρεις ενότητες αποκτούν δυσανάλογη βαρύτητα σε αυτό το πλαίσιο. Τα κριτήρια αποδοχής γίνονται πύλες έγκρισης, οπότε πρέπει να είναι παρατηρήσιμα από κάποιον που δεν είναι μηχανικός. Τα ανοιχτά ερωτήματα χρειάζονται έναν κατονομασμένο υπεύθυνο στην πλευρά του πελάτη, γιατί ο vendor δεν μπορεί να τα απαντήσει και θα χτίσει γύρω από το κενό. Και το ιστορικό αλλαγών σταματά να είναι γραφειοκρατικό: είναι το αρχείο του τι συμφωνήθηκε και πότε, κάτι που είναι το πρώτο πράγμα στο οποίο καταφεύγει κανείς σε μια διαφωνία.

Η γραμμή που έχουμε δει να πηγαίνει στραβά περισσότερες από μία φορά είναι κάποια εκδοχή του «οι χρήστες μπορούν να εξάγουν τα δεδομένα τους». Κανείς δεν γράφει σε ποια μορφή. Η ακριβή εκδοχή αυτού, για εμάς, παραδόθηκε ως εξαγωγή CSV ενώ ο πελάτης εννοούσε ένα μορφοποιημένο πακέτο τιμολογίων σε PDF με το branding του πάνω του, και η επανάληψη έκαψε περίπου μία εβδομάδα μηχανικής που κανείς δεν είχε προϋπολογίσει. Η ειλικρινής ανάγνωση είναι ότι το σφάλμα βρισκόταν στο έγγραφο, όχι στην παράδοση. Ένα κριτήριο αποδοχής θα το είχε πιάσει σε πέντε λεπτά: given ένα αίτημα εξαγωγής, when το αρχείο δημιουργείται, then είναι ένα PDF που ταιριάζει με το δοσμένο layout. Μια γραμμή μη-στόχων θα το είχε πιάσει κι αυτή, από την άλλη πλευρά. Οπότε αυτό είναι πλέον κανόνας στη δική μας διαδικασία ανακάλυψης: κάθε απαίτηση που κρέμεται από ένα ουσιαστικό όπως «εξαγωγή», «αναφορά» ή «ειδοποίηση» παίρνει μορφή, ένα trigger, και ένα παράδειγμα εργασίας πριν υπογραφεί ένα statement of work.

Αυτό είναι, ως επί το πλείστον, το πώς τρέχουμε υλοποιήσεις web εφαρμογών: μετατρέπουμε το ασαφές μισό του spec ενός πελάτη σε ελέγξιμες γραμμές πριν γραφτεί έστω και μία γραμμή κώδικα.

Τι Λέει Στην Πραγματικότητα το r/ProductManagement Για τα Πρότυπα PRD

Αναζήτησε product requirements document template reddit και θα βρεις το ίδιο παράπονο να επαναλαμβάνεται στο r/ProductManagement: πρήξιμο προτύπου (template bloat). PRD που κανείς δεν διαβάζει. Ενότητες συμπληρωμένες επειδή το πρότυπο είχε μια κεφαλίδα, όχι επειδή κάποιος χρειαζόταν το περιεχόμενο. Έγγραφα που μπαγιατεύουν την επόμενη μέρα του kickoff και αντικαθίστανται σιωπηλά από ένα Slack thread. Είναι μια δίκαιη κριτική για τα περισσότερα πρότυπα, συμπεριλαμβανομένων αρκετών από τα πρώτα δέκα αποτελέσματα για αυτό το ερώτημα.

Η δική μας απάντηση: διέγραψε ενότητες αντί να τις γεμίζεις με το τίποτα. Τα προφίλ χρηστών φεύγουν πρώτα όταν οι χρήστες είναι προφανείς. Το παράρτημα φεύγει δεύτερο. Τα ορόσημα μπορούν να ζουν στον tracker αντ' αυτού. Η μόνη που δεν διαγράφουμε ποτέ είναι οι μη-στόχοι, γιατί είναι η μόνη ενότητα που γίνεται μικρότερη όσο περισσότερη δουλειά κάνεις, και η μόνη που αποτρέπει αξιόπιστα τη διαμάχη που αλλιώς θα είχες στην έκτη εβδομάδα.

Σχετικά με τον Συγγραφέα

Mert Batur Gurbuz, Συνιδρυτής, Techsy.io. Διαπιστεύσεις: Συνιδρυτής, Techsy.io, University of Birmingham. LinkedIn

Ο Mert Batur Gurbuz είναι Συνιδρυτής της Techsy.io, όπου η ομάδα παραδίδει AI agents, συστήματα αυτοματισμού, και voice/SDR pipelines για B2B πελάτες. Σπουδάζει στο University of Birmingham και γράφει για το LLM tooling stack που η ομάδα της Techsy χρησιμοποιεί πραγματικά σε παραγωγή.

Συχνές Ερωτήσεις

Τι είναι ένα έγγραφο απαιτήσεων προϊόντος;

Ένα έγγραφο απαιτήσεων προϊόντος (PRD) δηλώνει τι χτίζει μια ομάδα και γιατί: το πρόβλημα, τους στόχους και τις μετρικές τους, τους μη-στόχους, για ποιον προορίζεται, και τις απαιτήσεις που ορίζουν το «έτοιμο». Εξαιρεί σκόπιμα τη λεπτομέρεια υλοποίησης, η οποία ανήκει σε ένα technical design doc που γράφεται μετά από τη μηχανική ομάδα.

Πώς γράφεις ένα έγγραφο απαιτήσεων προϊόντος;

Ξεκίνα με τη δήλωση προβλήματος και αρνήσου να χρησιμοποιήσεις γλώσσα λύσης μέσα σε αυτήν. Πρόσθεσε μετρήσιμους στόχους με βάση αναφοράς και ημερομηνία-στόχο, μετά γράψε τους μη-στόχους. Συμπλήρωσε προφίλ χρηστών, ιστορίες χρηστών με κριτήρια αποδοχής Given/When/Then, λειτουργικές και μη λειτουργικές απαιτήσεις, εξαρτήσεις, ορόσημα, και ανοιχτά ερωτήματα με υπευθύνους.

Τι πρέπει να περιλαμβάνει ένα PRD;

Δώδεκα ενότητες: κεφαλίδα με ιστορικό αλλαγών, δήλωση προβλήματος, στόχοι και μετρικές επιτυχίας, μη-στόχοι, χρήστες και προφίλ, ιστορίες χρηστών με κριτήρια αποδοχής, λειτουργικές απαιτήσεις, μη λειτουργικές απαιτήσεις, εξαρτήσεις και ενσωματώσεις, ορόσημα και φάσεις, ανοιχτά ερωτήματα και κίνδυνοι, και ένα παράρτημα. Οτιδήποτε δεν ταιριάζει σε κάποιο από αυτά μάλλον δεν είναι απαίτηση.

Πόσο μεγάλο πρέπει να είναι ένα PRD;

Μία με δύο σελίδες για μία μεμονωμένη λειτουργία, τρεις με πέντε για μια φάση προϊόντος, πέντε με οκτώ όταν το χτίζει μια εξωτερική ομάδα και τα κριτήρια αποδοχής λειτουργούν ως πύλες έγκρισης. Το μήκος ακολουθεί τον αριθμό των αποφάσεων που καταγράφονται, όχι το μέγεθος του προϊόντος. Οι κενές ενότητες πρέπει να διαγράφονται, όχι να γεμίζονται με φούσκωμα.

Είναι το PRD το ίδιο με το BRD;

Όχι. Ένα business requirements document δηλώνει το εμπορικό αποτέλεσμα που θέλει ο οργανισμός και τους περιορισμούς γύρω από αυτό, συνήθως πριν επιλεγεί μια λύση. Ένα PRD περιγράφει το προϊόν που το παραδίδει: χρήστες, συμπεριφορά, κριτήρια αποδοχής, μη-στόχους. Σε μικρότερες εταιρείες το BRD είναι συχνά απλώς η ενότητα δήλωσης προβλήματος.

Γράφουν ακόμα PRD οι agile ομάδες;

Ναι, συνήθως ως έγγραφο μιας σελίδας. Το backlog κρατά τη δουλειά, αλλά τα tickets είναι απαίσια στο να κρατούν το γιατί, τους μη-στόχους, και τη μετρική επιτυχίας. Οι ομάδες που παραλείπουν εντελώς το PRD τείνουν να το ανακαλύπτουν ξανά ως μια σελίδα Confluence με το όνομα «context» τρία sprint μέσα στο έργο.

Μπορείς να γράψεις ένα PRD σε markdown;

Το markdown είναι η καλύτερη μορφή για αυτό. Επικολλάται καθαρά σε Notion, Confluence, Google Docs και Linear, κάνει version στο Git δίπλα στον κώδικα ως PRD.md, κάνει diff σωστά σε ένα pull request, και είναι η μόνη μορφή που ένας AI coding agent διαβάζει χωρίς να χάνει τη δομή. Το πρότυπο παραπάνω είναι σε markdown ακριβώς για αυτούς τους λόγους.

Πώς γράφεις ένα PRD για έναν AI coding agent;

Να είσαι ρητός εκεί που κανονικά θα ήσουν σύντομος. Δήλωσε τους μη-στόχους θετικά, γιατί ένας agent δεν μπορεί να συναγάγει το πεδίο εφαρμογής από την παράλειψη. Χώρισε το έγγραφο σε φάσεις που ολοκληρώνονται σε ένα πέρασμα. Γράψε τα κριτήρια αποδοχής ως assertions με αριθμούς. Ονόμασε τα αρχεία που ο agent μπορεί να επεξεργαστεί και αυτά που δεν πρέπει να αγγίξει.

Ποια είναι η διαφορά ανάμεσα σε ένα PRD και ένα technical design doc;

Το PRD απαντά στο τι και στο γιατί: πρόβλημα, χρήστες, συμπεριφορά, κριτήρια αποδοχής, μη-στόχοι. Το technical design doc απαντά στο πώς: αρχιτεκτονική, μοντέλο δεδομένων, συμβόλαια API, trade-offs που εξετάστηκαν. Το προϊόν συνήθως κατέχει το πρώτο, η μηχανική το δεύτερο, και το design doc θα έπρεπε να διαβάζεται ως απάντηση στο PRD.

Ποιος κατέχει το PRD, το προϊόν, η μηχανική, ή ο πελάτης;

Το προϊόν κατέχει το έγγραφο και τις αποφάσεις μέσα σε αυτό. Η μηχανική κατέχει το feedback εφικτότητας και τις μη λειτουργικές απαιτήσεις. Σε υλοποιήσεις agency, ο πελάτης κατέχει τη δήλωση προβλήματος, τους στόχους, και κάθε ανοιχτό ερώτημα για τη δική του επιχείρηση. Η κοινή κυριότητα ολόκληρου του εγγράφου συνήθως σημαίνει ότι κανείς δεν το συντηρεί.

Κλείνοντας

Τρία πράγματα να κρατήσεις. Το πρότυπο είναι χρήσιμο μόνο όταν συμπληρωθεί, οπότε αντέγραψε το σχήμα του συμπληρωμένου παραδείγματος αντί για το κενό. Οι μη-στόχοι είναι η ενότητα με την υψηλότερη αξία ανά λέξη στο έγγραφο και η πρώτη που παραλείπει ο κόσμος. Και τα κριτήρια αποδοχής γραμμένα ως ελέγξιμα assertions εξυπηρετούν εξίσου καλά δύο αναγνώστες: έναν μηχανικό που εγκρίνει μια παράδοση, και έναν agent που γράφει το test.

Αν γράφεις ένα PRD για να το παραδώσεις σε μια εξωτερική ομάδα και θέλεις ένα δεύτερο ζευγάρι μάτια πάνω του πριν γίνει σύμβαση, χαιρόμαστε να το διαβάσουμε και να σημειώσουμε τις ασαφείς γραμμές. Είναι το ίδιο πέρασμα που κάνουμε στις δικές μας υλοποιήσεις web εφαρμογών.