AI மூலம் Product Requirements Doc எழுதுவது எப்படி (இலவச டெம்ப்ளேட்)

Product requirements document (PRD) என்பது நீங்கள் எதை உருவாக்குகிறீர்கள், அது யாருக்காக, அது என்ன செய்ய வேண்டும், அது வேலை செய்கிறது என்பதை எப்படி அறிவீர்கள் என்பதை எளிய மொழியில் விவரிக்கும் சுருக்கமான ஆவணம். AI இதை எழுதுவதை மிக வேகமாக்குகிறது: உங்கள் தோராய குறிப்புகளைக் கொடுத்தால், அது அவற்றை கட்டமைக்கப்பட்ட பகுதிகள், user stories மற்றும் எல்லை நிலை சூழ்நிலைகளாக மாற்றும். AI எடுக்க முடியாத முடிவுகளை - இலக்கு, எல்லை, எதை விட்டுவிடுவது - நீங்கள்தான் வழங்க வேண்டும், AI சேர்ப்பதையும் நீங்கள்தான் சரிபார்க்க வேண்டும்.

இந்த வழிகாட்டி PRD-யில் என்ன இருக்க வேண்டும், எந்த AI உதவியாளருடனும் அதை எப்படி படிப்படியாக வரைவது, ஒவ்வொரு பகுதிக்கும் prompts, நீங்கள் நகலெடுத்து நிரப்பக்கூடிய ஒரு டெம்ப்ளேட் ஆகியவற்றை விளக்குகிறது.

PRD எதற்காக (எதற்காக இல்லை)

PRD நான்கு கேள்விகளுக்குப் பதில் சொல்கிறது:

1. ஏன் இதை உருவாக்குகிறோம்? என்ன பிரச்சினை, யாருக்கு?
2. முதல் பதிப்பில் என்ன செய்ய வேண்டும்?
3. இன்னும் எதைச் செய்யாது?
4. அது வேலை செய்ததை எப்படி அறிவோம்?

இது ஒரு தொழில்நுட்ப வடிவமைப்பு அல்ல. எந்த database அல்லது framework பயன்படுத்த வேண்டும் என்று அது சொல்லாது - அது தேவைப்பட்டால் தனியான தொழில்நுட்ப specification-இல் இருக்க வேண்டும். இது marketing brief அல்லது business plan-உம் அல்ல. PRD-யை product-இன் நடத்தையில் மட்டும் வைத்திருப்பதுதான் அதை எல்லோருக்கும் பயனுள்ளதாக்குகிறது: designer, developer, ஒப்புதல் அளிக்கும் stakeholder, அல்லது அதை குறியீடாக மாற்றும் AI app builder - அனைவருக்கும்.

யாருக்கு இது தேவை

• தனி நிறுவனர்கள் scope creep தொடங்குவதற்கு முன்பே நிறுத்த விரும்புபவர்கள்.
• சிறிய குழுக்கள் "நாம் என்ன ஒப்புக்கொண்டோம்" என்பது ஒரே இடத்தில் இருக்க வேண்டும் என்று விரும்புபவர்கள்.
• ஒரு freelancer அல்லது agency-ஐ வேலைக்கு அமர்த்துபவர்கள், ஏனெனில் தெளிவான PRD தெளிவான மதிப்பீடுகளைத் தரும். டெவலப்பரை வேலைக்கு அமர்த்துவது அல்லது AI மூலம் உருவாக்குவது பார்க்கவும்.
• AI மூலம் உருவாக்குபவர்கள், ஏனெனில் PRD-யின் user stories மற்றும் data பட்டியல் கட்டமைக்கப்படாத விருப்பப் பட்டியலை விட சிறந்த prompts ஆகும்.

AI எதில் சிறந்தது - எதில் இல்லை

மிகவும் பொதுவான தவறு, மேலே உள்ள இரண்டாவது-கடைசி வரிசை தலைகீழாக இருப்பதுதான்: AI இடைவெளிகளை பயனர்கள் பற்றிய நம்பத்தகுந்த யூகங்களால் நம்பிக்கையுடன் நிரப்புகிறது. பயனர்கள், சந்தை அளவு அல்லது நடத்தை பற்றி அது எழுதும் எதையும் உண்மையாக அல்ல, சரிபார்க்க வேண்டிய கேள்வியாகவே கருதுங்கள்.

படி 1: உங்களுக்குத் தெரிந்தவற்றை கொட்டுங்கள்

எதற்கும் prompt கொடுப்பதற்கு முன், தோராய குறிப்புகளை எழுதுங்கள். புள்ளிகள் போதும். இவற்றை உள்ளடக்குங்கள்:

• பிரச்சினை, பயனரின் பார்வையில் ஒன்று அல்லது இரண்டு வாக்கியங்களில்.
• அதனால் பாதிக்கப்படுபவர் யார். தெளிவாக இருங்கள்: "சிறு வணிகங்கள்" அல்ல, "10-40 வாடிக்கையாளர்கள் உள்ள freelance bookkeepers".
• அவர்கள் இப்போது அதற்குப் பதிலாக என்ன செய்கிறார்கள் (ஒரு spreadsheet, email, அவர்களுக்குப் பிடிக்காத ஒரு கருவி).
• முதல் பதிப்பை வெற்றிகரமாக்கும் ஒரே விளைவு.
• நீங்கள் ஏற்கனவே செய்யப்போவதில்லை என்று தெரிந்தவை.
• கடினமான வரம்புகள்: கெடு, பட்ஜெட், மொபைல்களில் வேலை செய்ய வேண்டும், நீங்கள் ஏற்கனவே பயன்படுத்தும் ஒரு கருவியுடன் இணைய வேண்டும்.

இந்தப் பிரச்சினை உள்ள யாரிடமும் நீங்கள் பேசவில்லை என்றால், முதலில் அதைச் செய்யுங்கள். ஒரு app யோசனையை எப்படி சரிபார்ப்பது அதற்கான நடைமுறை வழியைத் தருகிறது. யூகங்களின் மேல் கட்டப்பட்ட PRD என்பது நன்றாக வடிவமைக்கப்பட்ட ஒரு யூகம்.

படி 2: AI-யிடம் முதல் வரைவைக் கேளுங்கள்

உங்கள் குறிப்புகளை ஒட்டி, நிலையான கட்டமைப்பில் ஒரு வரைவைக் கேளுங்கள். நன்றாக வேலை செய்யும் ஒரு prompt:

இது ஒரு product பற்றிய என் குறிப்புகள். இவற்றை சரியாக இந்தப் பகுதிகளுடன் ஒரு product requirements document ஆக மாற்றுங்கள்: Summary, Problem, Users, Goals and success metrics, Scope (in / out), User stories with acceptance criteria, Data, Permissions, Edge cases, Open questions. இரண்டு பக்கங்களுக்குள் வையுங்கள். பயனர்கள் அல்லது சந்தை பற்றிய உண்மைகளை கற்பனை செய்யாதீர்கள் - என் குறிப்புகளில் இல்லாததை Open questions-இல் கேள்வியாக எழுதுங்கள்.

கடைசி அறிவுறுத்தல் முக்கியமானது. தெரியாதவற்றை நிரப்புவதற்குப் பதிலாக "Open questions"-இல் சேர்க்கச் சொல்வது மிகவும் நேர்மையான வரைவைத் தரும்.

படி 3: ஒவ்வொரு பகுதியையும் இறுக்குங்கள்

வரைவை பகுதி பகுதியாகப் பாருங்கள். இந்தப் பின்தொடர் prompts உதவும்:

பிரச்சினையும் பயனர்களும்

பிரச்சினை அறிக்கையை பயனரின் பார்வையில் ஒன்று அல்லது இரண்டு வாக்கியங்களில் மீண்டும் எழுதுங்கள். தீர்வு சொற்கள் வேண்டாம்.

பிரச்சினை அறிக்கை உங்கள் product-ஐக் குறிப்பிட்டால், அது பிரச்சினையை அல்ல, ஒரு தீர்வை விவரிக்கிறது.

இலக்குகளும் வெற்றி அளவீடுகளும்

முதல் பதிப்பிற்கு மூன்று வெற்றி அளவீடுகளைப் பரிந்துரையுங்கள், சிறிய எண்ணிக்கையிலான பயனர்களுடன் முதல் மாதத்தில் நான் அளக்கக்கூடியவை. ஒவ்வொன்றையும் எப்படி அளப்பேன் என்றும் சொல்லுங்கள்.

ஒன்று அல்லது இரண்டைத் தேர்ந்தெடுங்கள். "இருபது bookkeepers ஒரு மாதம் வாரந்தோறும் பயன்படுத்துகிறார்கள்" என்பது அளக்கக்கூடியது. "உற்பத்தித்திறனை மேம்படுத்துதல்" அப்படியில்லை.

Scope

இந்த PRD-யில் உள்ள எதை, முக்கிய flow-வை உடைக்காமல் பிந்தைய பதிப்புக்கு நகர்த்த முடியுமோ, அனைத்தையும் பட்டியலிடுங்கள்.

AI கருவிகள் அம்சங்களைச் சேர்க்க முனைகின்றன. இந்தக் prompt அவற்றை எதிர்த்திசையில் செய்ய வைக்கிறது. கடுமையாக இருங்கள்: பெரும்பாலான முதல் பதிப்பு PRD-கள் மிகப் பெரியவை. MVP என்றால் என்ன சிறிய முதல் பதிப்புகள் ஏன் அதிகம் கற்றுத்தருகின்றன என்று விளக்குகிறது.

User stories மற்றும் acceptance criteria

ஒவ்வொரு requirement-ஐயும் ஒரு user story ஆக எழுதுங்கள் ("[பயனர்] ஆக, நான் [செயல்] செய்ய விரும்புகிறேன், அதனால் [விளைவு]") மற்றும் Given / When / Then வடிவத்தில் இரண்டு முதல் நான்கு acceptance criteria சேருங்கள்.

Acceptance criteria என்பது பின்னர் நீங்கள் சோதிக்கும் சரிபார்ப்புப் பட்டியல். "ஒரு பதிவு செய்யப்பட்ட slot இருக்கும்போது, வேறொரு வாடிக்கையாளர் calendar-ஐப் பார்த்தால், அந்த slot காட்டப்படாது" என்பது சோதிக்கக்கூடியது. "முன்பதிவு நன்றாக வேலை செய்கிறது" சோதிக்கக்கூடியது அல்ல.

எல்லை நிலைகளும் அனுமதிகளும்

ஒவ்வொரு user story-க்கும், காலி data, தவறான உள்ளீடு, மெதுவான அல்லது தோல்வியடைந்த network கோரிக்கை, அணுகல் இருக்கக்கூடாத பயனர் ஆகியவற்றில் என்ன நடக்கும் என்று பட்டியலிடுங்கள்.

இங்குதான் AI தன் பங்கைச் செய்கிறது. மக்கள் மறக்கும் காலி நிலைகளையும் அனுமதி இடைவெளிகளையும் கண்டறிவதில் அது வேகமானது.

படி 4: சந்தேகவாதி போல மதிப்பாயுங்கள்

முழுவதையும் இன்னொரு முறை படித்து இவற்றைச் சரிபாருங்கள்:

• பயனர்கள் பற்றிய ஒவ்வொரு கூற்றும் உங்களிடமிருந்தோ ஆராய்ச்சியிலிருந்தோ வந்தது, AI-யிடமிருந்து அல்ல.
• Scope "out" குறைந்தது Scope "in" அளவுக்கு நீளமாக இருக்கிறது.
• ஒவ்வொரு user story-க்கும் உங்களிடம் கேட்காமலேயே ஒருவர் சோதிக்கக்கூடிய acceptance criteria உள்ளன.
• Data பகுதி செயலி வைத்திருக்கும் ஒவ்வொரு வகைப் பதிவையும், அதை யார் பார்க்க முடியும் என்பதையும் பட்டியலிடுகிறது.
• Open questions-க்கு ஒரு பொறுப்பாளரும் தேதியும் உள்ளன.
• உண்மையான வரம்பாக இல்லாவிட்டால் எந்த தொழில்நுட்பமும் நுழையவில்லை ("offline-இல் வேலை செய்ய வேண்டும்" ஒரு requirement; "Redis பயன்படுத்துங்கள்" அல்ல).

பிறகு இந்த product-ஐப் பயன்படுத்தப்போகும் அல்லது உருவாக்கப்போகும் ஒருவருடன் பகிர்ந்து, என்ன தெளிவாக இல்லை என்று கேளுங்கள். அவர்களின் கேள்விகளே இடைவெளிகள்.

நிரப்ப PRD டெம்ப்ளேட்

இதை ஒரு doc-இல் நகலெடுத்து அடைப்புக்குறிகளை மாற்றுங்கள். உண்மையில் பொருந்தாத பகுதிகளை நீக்குங்கள்.

Product பெயர்: [பெயர்] உரிமையாளர்: [முடிவுகளுக்குப் பொறுப்பானவர்] நிலை: [வரைவு / மதிப்பாய்வில் / ஒப்புக்கொள்ளப்பட்டது] - கடைசியாகப் புதுப்பிக்கப்பட்டது: [தேதி]

1. Summary

[இரண்டு அல்லது மூன்று வாக்கியங்கள்: இது என்ன, யாருக்கு, முக்கிய விளைவு.]

2. Problem

[பயனரின் பார்வையில் பிரச்சினை. அவர்கள் இப்போது என்ன செய்கிறார்கள், அது ஏன் வலிக்கிறது.]

3. Users

4. Goals and success metrics

• இலக்கு: [முதல் பதிப்பு அடைய வேண்டிய விளைவு]
• அளவீடு: [எப்படி அளப்பீர்கள், இலக்கு எண்]
• இலக்கல்லாதது: [மக்கள் இது செய்யும் என்று நினைக்கக்கூடியது, ஆனால் இந்தப் பதிப்பு செய்ய முயற்சிக்காதது]

5. Scope

முதல் பதிப்பில்:

• [அம்சம்]
• [அம்சம்]

முதல் பதிப்பில் இல்லாதது:

• [அம்சம், அது ஏன் பின்னர் வரலாம்]
• [அம்சம், அது ஏன் பின்னர் வரலாம்]

6. User stories

Story 1: [பயனர்] ஆக, நான் [செயல்] செய்ய விரும்புகிறேன், அதனால் [விளைவு].

• [சூழல்] என்றால், [செயல்] நடக்கும்போது, [முடிவு] இருக்கும்.
• [சூழல்] என்றால், [செயல்] நடக்கும்போது, [முடிவு] இருக்கும்.

Story 2: [பயனர்] ஆக, நான் [செயல்] செய்ய விரும்புகிறேன், அதனால் [விளைவு].

• [சூழல்] என்றால், [செயல்] நடக்கும்போது, [முடிவு] இருக்கும்.

7. Data

8. Permissions

[யார் log in செய்யலாம், என்ன roles உள்ளன, ஒவ்வொரு role என்ன பார்க்கலாம், மாற்றலாம்.]

9. Edge cases

• [காலி நிலை: இன்னும் data இல்லாதபோது என்ன காட்டப்படும்]
• [தவறான உள்ளீடு: தவறான email அல்லது விடுபட்ட field இருந்தால் என்ன நடக்கும்]
• [அணுகல்: அணுகக்கூடாத பக்கத்தை ஒருவர் திறந்தால் என்ன நடக்கும்]

10. Integrations and constraints

[Payments, email, ஏற்கனவே உள்ள கருவிகள், கெடுக்கள், பட்ஜெட், வேலை செய்ய வேண்டிய சாதனங்கள்.]

11. Open questions

PRD-யிலிருந்து prompts வரை

நல்ல PRD ஒரு AI app builder-க்கான prompts ஆக நேரடியாக மாறும்:

• Summary, users மற்றும் data அட்டவணை உங்கள் முதல் prompt ஆகிறது.
• ஒவ்வொரு user story-யும் ஒரு பின்தொடர் prompt ஆகிறது.
• ஒவ்வொரு acceptance criterion-ம் preview-வில் நீங்கள் சோதிப்பதாக மாறும்.
• "முதல் பதிப்பில் இல்லாதவை" பட்டியல் நீங்கள் இன்னும் கேட்க மறுப்பது.

ஒரு story-ஐ ஒரு நேரத்தில் உருவாக்கி, அடுத்ததுக்குச் செல்வதற்கு முன் அதன் acceptance criteria-வை சரிபார்ப்பது, முழு PRD-யையும் ஒட்டி எல்லாவற்றையும் கேட்பதை விட மிகவும் நம்பகமானது. AI app builders-க்கு prompts எழுதுவது எப்படி prompt பக்கத்தை இன்னும் விரிவாக விளக்குகிறது.

பொதுவான தவறுகள்

• தீர்வை பிரச்சினையாக எழுதுவது. "பயனர்களுக்கு ஒரு dashboard தேவை" ஒரு தீர்வு. "ஒவ்வொன்றையும் திறக்காமல் எந்த invoices தாமதமானவை என்று உரிமையாளர்களால் பார்க்க முடியவில்லை" ஒரு பிரச்சினை.
• "out of scope" பகுதி இல்லாமல் இருப்பது. அது இல்லாவிட்டால், ஒவ்வொரு உரையாடலும் scope-ஐ மீண்டும் திறக்கும்.
• AI பயனர்களைக் கற்பனை செய்ய அனுமதிப்பது. AI உருவாக்கிய personas உண்மையானவை போலத் தோன்றும், ஆனால் இல்லை.
• அளக்க முடியாத அளவீடுகள். அதை எண்ண வழி இல்லையென்றால், அது அளவீடு அல்ல.
• ஒருபோதும் புதுப்பிக்காமல் இருப்பது. நீங்கள் கட்டுவதுடன் பொருந்தாத PRD, இல்லாததை விடவும் மோசம். "கடைசியாகப் புதுப்பிக்கப்பட்டது" தேதியை வைத்திருங்கள், முடிவுகள் மாறும்போது அதை மாற்றுங்கள்.

Mythex-உடன் PRD பயன்படுத்துவது

Mythex-இல் நீங்கள் உருவாக்கினால், உங்கள் PRD-ஐ நேரடியாக chat-இல் ஒட்டலாம். PRD-க்கு Plan பயன்முறையில் தொடங்குவது நல்ல பொருத்தம்: agent அதைப் படித்து, ஒரு அணுகுமுறையையும், நீங்கள் plan tab-இல் மதிப்பாய்வு செய்யக்கூடிய படிப் பட்டியலையும் முன்மொழியும், மேலும் நீங்கள் Build அழுத்தும் வரை கோப்புகளை மாற்றத் தொடங்காது. எப்போதும் பொருந்த வேண்டிய பகுதிகளான பார்வையாளர்கள், brand, விதிகள் ஆகியவற்றை project knowledge ஆகச் சேமிக்கலாம், அதனால் ஒவ்வொரு chat-இலும் திரும்பச் சொல்ல வேண்டியதில்லை. Chat docs Build, Plan மற்றும் Ask பயன்முறைகளை விளக்குகின்றன, மேலும் முழு ஆவணத்தையும் எழுதுவதற்கு முன் முதல் பதிப்பு எப்படி இருக்கக்கூடும் என்று பார்க்க templates ஒரு விரைவான வழி.

கேள்விகள்