ಮಾರ್ಗದರ್ಶಿಗಳು

AI ಬಳಸಿ ಉತ್ಪನ್ನ ಅವಶ್ಯಕತೆಗಳ ಡಾಕ್ಯುಮೆಂಟ್ ಬರೆಯುವುದು ಹೇಗೆ (ಉಚಿತ ಟೆಂಪ್ಲೇಟ್)

ಉತ್ಪನ್ನ ಅವಶ್ಯಕತೆಗಳ ಡಾಕ್ಯುಮೆಂಟ್ (PRD) ಎಂದರೆ ನೀವು ಏನನ್ನು ನಿರ್ಮಿಸುತ್ತಿದ್ದೀರಿ, ಅದು ಯಾರಿಗಾಗಿ, ಅದು ಏನು ಮಾಡಬೇಕು ಮತ್ತು ಅದು ಸರಿಯಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತಿದೆ ಎಂದು ಹೇಗೆ ತಿಳಿಯುವಿರಿ ಎಂಬುದರ ಸಣ್ಣ, ಸರಳ ಭಾಷೆಯ ವಿವರಣೆ. AI ಬಳಸಿ ಇದನ್ನು ಬರೆಯುವುದು ಬಹಳ ವೇಗವಾಗುತ್ತದೆ: ಕಚ್ಚಾ ಟಿಪ್ಪಣಿಗಳನ್ನು ಕೊಟ್ಟರೆ ಅದು ರಚನಾತ್ಮಕ ವಿಭಾಗಗಳು, ಬಳಕೆದಾರ ಕಥೆಗಳು ಮತ್ತು ಅಂಚಿನ ಪ್ರಕರಣಗಳನ್ನು ರಚಿಸುತ್ತದೆ. AI ಮಾಡಲಾಗದ ನಿರ್ಧಾರಗಳನ್ನು ನೀವೇ ಒದಗಿಸಬೇಕು, ಅಂದರೆ ಗುರಿ, ವ್ಯಾಪ್ತಿ ಮತ್ತು ಏನನ್ನು ಬಿಡಬೇಕು ಎಂಬುದನ್ನು. ಅದು ಸೇರಿಸುವುದನ್ನೂ ನೀವು ಪರಿಶೀಲಿಸಬೇಕು.

ಈ ಮಾರ್ಗದರ್ಶಿ PRD ಯಲ್ಲಿ ಏನಿರಬೇಕು, ಯಾವುದೇ AI ಸಹಾಯಕದೊಂದಿಗೆ ಹಂತ ಹಂತವಾಗಿ ಒಂದನ್ನು ಕರಡು ಮಾಡುವ ವಿಧಾನ, ಪ್ರತಿ ವಿಭಾಗಕ್ಕೆ ಪ್ರಾಂಪ್ಟ್‌ಗಳು, ಮತ್ತು ನಕಲಿಸಿ ಭರ್ತಿ ಮಾಡಬಹುದಾದ ಟೆಂಪ್ಲೇಟ್ ಅನ್ನು ವಿವರಿಸುತ್ತದೆ.

PRD ಯ ಉದ್ದೇಶ (ಮತ್ತು ಅದು ಅಲ್ಲದ್ದು)

PRD ನಾಲ್ಕು ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತದೆ:

  1. ಇದನ್ನು ನಾವು ಏಕೆ ನಿರ್ಮಿಸುತ್ತಿದ್ದೇವೆ? ಯಾವ ಸಮಸ್ಯೆ, ಯಾರಿಗಾಗಿ?
  2. ಮೊದಲ ಆವೃತ್ತಿಯಲ್ಲಿ ಅದು ಏನು ಮಾಡಬೇಕು?
  3. ಅದು ಇನ್ನೂ ಏನನ್ನು ಮಾಡುವುದಿಲ್ಲ?
  4. ಅದು ಕೆಲಸ ಮಾಡಿದೆ ಎಂದು ಹೇಗೆ ತಿಳಿಯುತ್ತೇವೆ?

ಇದು ತಾಂತ್ರಿಕ ವಿನ್ಯಾಸವಲ್ಲ. ಯಾವ ಡೇಟಾಬೇಸ್ ಅಥವಾ ಫ್ರೇಮ್‌ವರ್ಕ್ ಬಳಸಬೇಕು ಎಂದು ಅದು ಹೇಳುವುದಿಲ್ಲ. ಅದಕ್ಕೆ ಬೇರೆ ತಾಂತ್ರಿಕ ವಿವರಣೆ ಬೇಕಾದರೆ ಅದು ಪ್ರತ್ಯೇಕವಾಗಿರಬೇಕು. ಇದು ಮಾರುಕಟ್ಟೆ ಬ್ರೀಫ್ ಅಥವಾ ವ್ಯವಹಾರ ಯೋಜನೆಯೂ ಅಲ್ಲ. PRD ಅನ್ನು ಉತ್ಪನ್ನದ ವರ್ತನೆಗೆ ಸೀಮಿತವಾಗಿಟ್ಟರೆ ಅದನ್ನು ಓದುವ ಎಲ್ಲರಿಗೂ ಉಪಯುಕ್ತವಾಗುತ್ತದೆ: ವಿನ್ಯಾಸಕರು, ಡೆವಲಪರ್, ಒಪ್ಪಿಗೆ ನೀಡುವ ಪಾಲುದಾರರು, ಅಥವಾ ಅದನ್ನು ಕೋಡ್ ಆಗಿ ಪರಿವರ್ತಿಸುವ AI ಆಪ್ ಬಿಲ್ಡರ್.

ಯಾರಿಗೆ ಇದು ಬೇಕು

  • ಏಕಾಂಗಿ ಸ್ಥಾಪಕರು ವ್ಯಾಪ್ತಿ ವಿಸ್ತರಣೆ (scope creep) ಆರಂಭದಲ್ಲೇ ತಡೆಯಲು ಬಯಸಿದರೆ.
  • ಸಣ್ಣ ತಂಡಗಳು "ನಾವು ಒಪ್ಪಿಕೊಂಡಿದ್ದು ಏನು" ಎಂಬುದು ಇರುವ ಒಂದೇ ಸ್ಥಳ ಬೇಕಾದರೆ.
  • ಫ್ರೀಲಾನ್ಸರ್ ಅಥವಾ ಏಜೆನ್ಸಿಯನ್ನು ನೇಮಿಸಿಕೊಳ್ಳುವವರು, ಏಕೆಂದರೆ ಸ್ಪಷ್ಟ PRD ಇದ್ದರೆ ಕೊಟೇಶನ್‌ಗಳೂ ಸ್ಪಷ್ಟವಾಗಿರುತ್ತವೆ. ಡೆವಲಪರ್ ನೇಮಿಸುವುದು ಅಥವಾ AI ಯೊಂದಿಗೆ ನಿರ್ಮಿಸುವುದು ನೋಡಿ.
  • AI ಯೊಂದಿಗೆ ನಿರ್ಮಿಸುವವರು, ಏಕೆಂದರೆ PRD ಯ ಬಳಕೆದಾರ ಕಥೆಗಳು ಮತ್ತು ಡೇಟಾ ಪಟ್ಟಿ ರಚನೆಯಿಲ್ಲದ ಆಸೆಪಟ್ಟಿಗಿಂತ ಉತ್ತಮ ಪ್ರಾಂಪ್ಟ್‌ಗಳನ್ನು ಮಾಡುತ್ತವೆ.

AI ಗೆ ಏನು ಚೆನ್ನಾಗಿ ಬರುತ್ತದೆ, ಮತ್ತು ಏನು ಬರುವುದಿಲ್ಲ

ಕಾರ್ಯAI ಚೆನ್ನಾಗಿ ಮಾಡುತ್ತದೆಇನ್ನೂ ನೀವೇ ಹೊಣೆ
ಅಸ್ತವ್ಯಸ್ತ ಟಿಪ್ಪಣಿಗಳನ್ನು ವಿಭಾಗಗಳಾಗಿ ಬದಲಾಯಿಸುವುದುಹೌದುಏನನ್ನೂ ಕಲ್ಪಿಸಿಲ್ಲ ಎಂದು ಪರಿಶೀಲಿಸುವುದು
ಬಳಕೆದಾರ ಕಥೆಗಳನ್ನು ಸ್ಥಿರ ಸ್ವರೂಪದಲ್ಲಿ ಬರೆಯುವುದುಹೌದುಯಾವ ಕಥೆಗಳು ಮೊದಲ ಆವೃತ್ತಿಯಲ್ಲಿವೆ ಎಂದು ನಿರ್ಧರಿಸುವುದು
ಅಂಚಿನ ಪ್ರಕರಣಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುವುದು (ಖಾಲಿ ಸ್ಥಿತಿ, ದೋಷಗಳು, ಅನುಮತಿಗಳು)ಹೌದು, ಕೆಲವೊಮ್ಮೆ ದಣಿದ ಮನುಷ್ಯನಿಗಿಂತ ಉತ್ತಮಯಾವುದು ಮುಖ್ಯ ಎಂದು ನಿರ್ಧರಿಸುವುದು
ಯಶಸ್ಸಿನ ಮಾಪನಗಳನ್ನು ಸೂಚಿಸುವುದುಸಮಂಜಸ ಆಯ್ಕೆಗಳನ್ನು ನೀಡುತ್ತದೆನಿಜವಾಗಿ ಅಳೆಯಬಹುದಾದವುಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದು
ನಿಮ್ಮ ಬಳಕೆದಾರರು, ಮಾರುಕಟ್ಟೆ ಅಥವಾ ಬಜೆಟ್ ತಿಳಿಯುವುದುಇಲ್ಲಎಲ್ಲವೂ
ಏನನ್ನು ಬಿಡಬೇಕು ಎಂದು ನಿರ್ಧರಿಸುವುದುಇಲ್ಲ, ಅದು ಸೇರಿಸುತ್ತದೆ, ಕಡಿತ ಮಾಡುವುದಿಲ್ಲಎಲ್ಲವೂ

ಸಾಮಾನ್ಯ ತಪ್ಪು ಎಂದರೆ ಮೇಲಿನ ಕೋಷ್ಟಕದ ಕೊನೆಯ ಸಾಲನ್ನು ತಲೆಕೆಳಗು ಮಾಡಿದಂತೆ: AI ಆತ್ಮವಿಶ್ವಾಸದಿಂದ ನಿಮ್ಮ ಬಳಕೆದಾರರ ಬಗ್ಗೆ ಸಂಭಾವ್ಯ ಊಹೆಗಳಿಂದ ಖಾಲಿ ಜಾಗಗಳನ್ನು ತುಂಬುತ್ತದೆ. ಬಳಕೆದಾರರು, ಮಾರುಕಟ್ಟೆ ಗಾತ್ರ ಅಥವಾ ವರ್ತನೆಯ ಬಗ್ಗೆ ಅದು ಬರೆದ ಯಾವುದನ್ನೂ ಸತ್ಯವೆಂದು ಪರಿಗಣಿಸದೆ ಪರಿಶೀಲಿಸಬೇಕಾದ ಪ್ರಶ್ನೆಯಂತೆ ನೋಡಿ.

ಹಂತ 1: ನಿಮಗೆ ತಿಳಿದಿರುವುದನ್ನು ಇಳಿಸಿ

ಯಾವುದೇ ಪ್ರಾಂಪ್ಟ್ ಮಾಡುವ ಮೊದಲು ಕಚ್ಚಾ ಟಿಪ್ಪಣಿಗಳನ್ನು ಬರೆಯಿರಿ. ಬುಲೆಟ್ ಪಾಯಿಂಟ್‌ಗಳು ಸಾಕು. ಇವುಗಳನ್ನು ಒಳಗೊಳ್ಳಿ:

  • ಸಮಸ್ಯೆ, ಒಂದು ಅಥವಾ ಎರಡು ವಾಕ್ಯಗಳಲ್ಲಿ, ಬಳಕೆದಾರರ ದೃಷ್ಟಿಯಿಂದ.
  • ಅದನ್ನು ಯಾರು ಎದುರಿಸುತ್ತಾರೆ. ನಿರ್ದಿಷ್ಟವಾಗಿರಿ: "10–40 ಗ್ರಾಹಕರಿರುವ ಫ್ರೀಲಾನ್ಸ್ ಬುಕ್‌ಕೀಪರ್‌ಗಳು", "ಸಣ್ಣ ವ್ಯಾಪಾರಗಳು" ಅಲ್ಲ.
  • ಇಂದು ಬದಲಾಗಿ ಅವರು ಏನು ಮಾಡುತ್ತಾರೆ (ಸ್ಪ್ರೆಡ್‌ಶೀಟ್, ಇಮೇಲ್, ಇಷ್ಟವಾಗದ ಉಪಕರಣ).
  • ಮೊದಲ ಆವೃತ್ತಿಯನ್ನು ಯಶಸ್ವಿಯಾಗಿಸುವ ಒಂದೇ ಫಲಿತಾಂಶ.
  • ನೀವು ಖಂಡಿತವಾಗಿ ಮಾಡದ ವಿಷಯಗಳು.
  • ಕಠಿಣ ಮಿತಿಗಳು: ಗಡುವು, ಬಜೆಟ್, ಫೋನ್‌ಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡಬೇಕೇ, ನೀವು ಈಗಾಗಲೇ ಬಳಸುವ ಉಪಕರಣದೊಂದಿಗೆ ಸಂಯೋಜನೆಯಾಗಬೇಕೇ.

ಸಮಸ್ಯೆ ಇರುವ ಯಾರ ಜೊತೆಗೂ ನೀವು ಮಾತನಾಡಿಲ್ಲದಿದ್ದರೆ, ಮೊದಲು ಅದನ್ನು ಮಾಡಿ. ಆಪ್ ಐಡಿಯಾವನ್ನು ಹೇಗೆ ಪರಿಶೀಲಿಸುವುದು ಇದಕ್ಕೆ ಪ್ರಾಯೋಗಿಕ ದಾರಿ ತೋರಿಸುತ್ತದೆ. ಊಹೆಗಳ ಮೇಲೆ ನಿರ್ಮಿಸಲಾದ PRD ಚೆನ್ನಾಗಿ ರೂಪಿಸಲಾದ ಊಹೆಯಷ್ಟೇ.

ಹಂತ 2: AI ಗೆ ಮೊದಲ ಕರಡು ಕೇಳಿ

ನಿಮ್ಮ ಟಿಪ್ಪಣಿಗಳನ್ನು ಅಂಟಿಸಿ ಸ್ಥಿರ ರಚನೆಯಲ್ಲಿ ಕರಡು ಕೇಳಿ. ಚೆನ್ನಾಗಿ ಕೆಲಸ ಮಾಡುವ ಪ್ರಾಂಪ್ಟ್:

ಇಲ್ಲಿ ಒಂದು ಉತ್ಪನ್ನದ ಬಗ್ಗೆ ನನ್ನ ಟಿಪ್ಪಣಿಗಳಿವೆ. ಇವುಗಳನ್ನು ಉತ್ಪನ್ನ ಅವಶ್ಯಕತೆಗಳ ಡಾಕ್ಯುಮೆಂಟ್ ಆಗಿ ಈ ನಿಖರವಾದ ವಿಭಾಗಗಳೊಂದಿಗೆ ಪರಿವರ್ತಿಸಿ: ಸಾರಾಂಶ, ಸಮಸ್ಯೆ, ಬಳಕೆದಾರರು, ಗುರಿಗಳು ಮತ್ತು ಯಶಸ್ಸಿನ ಮಾಪನಗಳು, ವ್ಯಾಪ್ತಿ (ಒಳಗೆ / ಹೊರಗೆ), ಸ್ವೀಕಾರ ಮಾನದಂಡಗಳೊಂದಿಗೆ ಬಳಕೆದಾರ ಕಥೆಗಳು, ಡೇಟಾ, ಅನುಮತಿಗಳು, ಅಂಚಿನ ಪ್ರಕರಣಗಳು, ತೆರೆದ ಪ್ರಶ್ನೆಗಳು. ಎರಡು ಪುಟಗಳಿಗಿಂತ ಕಡಿಮೆ ಇರಲಿ. ಬಳಕೆದಾರರು ಅಥವಾ ಮಾರುಕಟ್ಟೆಯ ಬಗ್ಗೆ ಸತ್ಯಗಳನ್ನು ಕಲ್ಪಿಸಬೇಡಿ. ನನ್ನ ಟಿಪ್ಪಣಿಗಳು ಏನನ್ನೂ ಹೇಳದ ಭಾಗಗಳನ್ನು ತೆರೆದ ಪ್ರಶ್ನೆಗಳ ಅಡಿಯಲ್ಲಿ ಪ್ರಶ್ನೆಯಾಗಿ ಬರೆಯಿರಿ.

ಕೊನೆಯ ಸೂಚನೆ ಮುಖ್ಯ. ಗೊತ್ತಿಲ್ಲದ ವಿಷಯಗಳನ್ನು ಭರ್ತಿ ಮಾಡುವ ಬದಲು "ತೆರೆದ ಪ್ರಶ್ನೆಗಳು" ಗೆ ಹಾಕಲು AI ಗೆ ಹೇಳುವುದರಿಂದ ಹೆಚ್ಚು ಪ್ರಾಮಾಣಿಕ ಕರಡು ಸಿಗುತ್ತದೆ.

ಹಂತ 3: ಪ್ರತಿ ವಿಭಾಗವನ್ನು ಬಿಗಿಗೊಳಿಸಿ

ಕರಡನ್ನು ವಿಭಾಗವಾರು ಪರಿಶೀಲಿಸಿ. ಈ ಅನುಸರಣಾ ಪ್ರಾಂಪ್ಟ್‌ಗಳು ಸಹಾಯ ಮಾಡುತ್ತವೆ:

ಸಮಸ್ಯೆ ಮತ್ತು ಬಳಕೆದಾರರು

ಸಮಸ್ಯೆಯ ಹೇಳಿಕೆಯನ್ನು ಬಳಕೆದಾರರ ದೃಷ್ಟಿಯಿಂದ ಒಂದು ಅಥವಾ ಎರಡು ವಾಕ್ಯಗಳಲ್ಲಿ ಮರುಬರೆಯಿರಿ. ಪರಿಹಾರದ ಪದಗಳು ಬೇಡ.

ಸಮಸ್ಯೆಯ ಹೇಳಿಕೆಯಲ್ಲಿ ನಿಮ್ಮ ಉತ್ಪನ್ನದ ಹೆಸರಿದ್ದರೆ, ಅದು ಸಮಸ್ಯೆಯನ್ನಲ್ಲ, ಪರಿಹಾರವನ್ನು ವಿವರಿಸುತ್ತಿದೆ.

ಗುರಿಗಳು ಮತ್ತು ಯಶಸ್ಸಿನ ಮಾಪನಗಳು

ಮೊದಲ ಆವೃತ್ತಿಗೆ ಮೂರು ಯಶಸ್ಸಿನ ಮಾಪನಗಳನ್ನು ಸೂಚಿಸಿ, ಸಣ್ಣ ಸಂಖ್ಯೆಯ ಬಳಕೆದಾರರೊಂದಿಗೆ ಮೊದಲ ತಿಂಗಳಲ್ಲಿ ನಾನು ಅಳೆಯಬಹುದಾದವು. ಪ್ರತಿಯೊಂದಕ್ಕೂ ನಾನು ಅದನ್ನು ಹೇಗೆ ಅಳೆಯುತ್ತೇನೆ ಎಂದು ಹೇಳಿ.

ಒಂದು ಅಥವಾ ಎರಡನ್ನು ಆರಿಸಿ. "ಇಪ್ಪತ್ತು ಬುಕ್‌ಕೀಪರ್‌ಗಳು ಒಂದು ತಿಂಗಳು ವಾರಕ್ಕೊಮ್ಮೆ ಬಳಸುತ್ತಾರೆ" ಅಳೆಯಬಹುದು. "ಉತ್ಪಾದಕತೆ ಸುಧಾರಿಸಿ" ಅಳೆಯಲಾಗುವುದಿಲ್ಲ.

ವ್ಯಾಪ್ತಿ

ಮಹತ್ವದ ಹರಿವಿಗೆ ಧಕ್ಕೆಯಾಗದೆ ನಂತರದ ಆವೃತ್ತಿಗೆ ಮುಂದೂಡಬಹುದಾದ ಈ PRD ಯಲ್ಲಿರುವ ಎಲ್ಲವನ್ನೂ ಪಟ್ಟಿ ಮಾಡಿ.

AI ಉಪಕರಣಗಳು ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಸೇರಿಸಲು ಒಲವು ತೋರುತ್ತವೆ. ಈ ಪ್ರಾಂಪ್ಟ್ ಅವುಗಳನ್ನು ವಿರುದ್ಧ ದಿಕ್ಕಿಗೆ ತಳ್ಳುತ್ತದೆ. ನಿರ್ದಯವಾಗಿರಿ: ಹೆಚ್ಚಿನ ಮೊದಲ ಆವೃತ್ತಿಯ PRD ಗಳು ತುಂಬಾ ದೊಡ್ಡವಾಗಿರುತ್ತವೆ. MVP ಎಂದರೇನು ಸಣ್ಣ ಮೊದಲ ಆವೃತ್ತಿಗಳು ನಿಮಗೆ ಹೆಚ್ಚು ಕಲಿಸುವುದು ಏಕೆ ಎಂದು ವಿವರಿಸುತ್ತದೆ.

ಬಳಕೆದಾರ ಕಥೆಗಳು ಮತ್ತು ಸ್ವೀಕಾರ ಮಾನದಂಡಗಳು

ಪ್ರತಿ ಅವಶ್ಯಕತೆಯನ್ನು ಬಳಕೆದಾರ ಕಥೆಯಾಗಿ ("[ಬಳಕೆದಾರ]ನಾಗಿ, ನಾನು [ಕ್ರಿಯೆ] ಬಯಸುತ್ತೇನೆ, ಇದರಿಂದ [ಫಲಿತಾಂಶ]") ಬರೆಯಿರಿ, ಪ್ರತಿಯೊಂದಕ್ಕೂ Given / When / Then ರೂಪದಲ್ಲಿ ಎರಡರಿಂದ ನಾಲ್ಕು ಸ್ವೀಕಾರ ಮಾನದಂಡಗಳೊಂದಿಗೆ.

ಸ್ವೀಕಾರ ಮಾನದಂಡಗಳು ನಂತರ ನೀವು ಪರೀಕ್ಷಿಸುವ ಪರಿಶೀಲನಾ ಪಟ್ಟಿ. "ಬುಕ್ ಮಾಡಿದ ಸ್ಲಾಟ್ ಇದ್ದರೆ, ಇನ್ನೊಬ್ಬ ಗ್ರಾಹಕ ಕ್ಯಾಲೆಂಡರ್ ನೋಡಿದಾಗ, ಆ ಸ್ಲಾಟ್ ತೋರಿಸಬಾರದು" ಪರೀಕ್ಷಿಸಬಹುದು. "ಬುಕಿಂಗ್ ಚೆನ್ನಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ" ಪರೀಕ್ಷಿಸಲಾಗುವುದಿಲ್ಲ.

ಅಂಚಿನ ಪ್ರಕರಣಗಳು ಮತ್ತು ಅನುಮತಿಗಳು

ಪ್ರತಿ ಬಳಕೆದಾರ ಕಥೆಗೆ, ಡೇಟಾ ಖಾಲಿಯಾಗಿದ್ದರೆ, ಇನ್‌ಪುಟ್ ತಪ್ಪಾಗಿದ್ದರೆ, ನೆಟ್‌ವರ್ಕ್ ವಿನಂತಿ ನಿಧಾನವಾದರೆ ಅಥವಾ ವಿಫಲವಾದರೆ, ಮತ್ತು ಪ್ರವೇಶ ಇರಬಾರದ ಬಳಕೆದಾರ ಬಂದರೆ ಏನಾಗುತ್ತದೆ ಎಂದು ಪಟ್ಟಿ ಮಾಡಿ.

ಜನರು ಮರೆಯುವ ಖಾಲಿ ಸ್ಥಿತಿಗಳು ಮತ್ತು ಅನುಮತಿಯ ಅಂತರಗಳನ್ನು ಗುರುತಿಸುವುದರಲ್ಲಿ AI ವೇಗವಾಗಿದೆ. ಇಲ್ಲಿ ಅದು ತನ್ನ ಬೆಲೆಗೆ ತಕ್ಕಷ್ಟು ಕೆಲಸ ಮಾಡುತ್ತದೆ.

ಹಂತ 4: ಸಂಶಯದ ಕಣ್ಣಿನಿಂದ ಪರಿಶೀಲಿಸಿ

ಇಡೀ ಡಾಕ್ಯುಮೆಂಟ್ ಅನ್ನು ಇನ್ನೊಮ್ಮೆ ಓದಿ ಮತ್ತು ಪರಿಶೀಲಿಸಿ:

  • ಬಳಕೆದಾರರ ಬಗ್ಗೆ ಪ್ರತಿಯೊಂದು ಹೇಳಿಕೆ ನಿಮ್ಮಿಂದ ಅಥವಾ ಸಂಶೋಧನೆಯಿಂದ ಬಂದದ್ದು, AI ನಿಂದಲ್ಲ.
  • "ವ್ಯಾಪ್ತಿಯಿಂದ ಹೊರಗೆ" ವಿಭಾಗವು "ಒಳಗೆ" ವಿಭಾಗದಷ್ಟೇ ಉದ್ದವಾಗಿದೆ ಅಥವಾ ಹೆಚ್ಚು.
  • ಪ್ರತಿ ಬಳಕೆದಾರ ಕಥೆಗೆ ನಿಮ್ಮನ್ನು ಕೇಳದೆ ಯಾರಾದರೂ ಪರೀಕ್ಷಿಸಬಲ್ಲ ಸ್ವೀಕಾರ ಮಾನದಂಡಗಳಿವೆ.
  • ಡೇಟಾ ವಿಭಾಗವು ಆಪ್ ಇಡುವ ಪ್ರತಿಯೊಂದು ಬಗೆಯ ದಾಖಲೆಯನ್ನೂ ಮತ್ತು ಅದನ್ನು ಯಾರು ನೋಡಬಹುದು ಎಂಬುದನ್ನೂ ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ.
  • ತೆರೆದ ಪ್ರಶ್ನೆಗಳಿಗೆ ಒಬ್ಬ ಜವಾಬ್ದಾರ ವ್ಯಕ್ತಿ ಮತ್ತು ದಿನಾಂಕವಿದೆ.
  • ನಿಜವಾದ ಮಿತಿಯಲ್ಲದ ಯಾವುದೇ ತಾಂತ್ರಿಕ ವಿಷಯ ಒಳಗೆ ನುಸುಳಿಲ್ಲ. ("ಆಫ್‌ಲೈನ್ ಕೆಲಸ ಮಾಡಬೇಕು" ಒಂದು ಅವಶ್ಯಕತೆ; "Redis ಬಳಸಿ" ಅಲ್ಲ.)

ನಂತರ ಉತ್ಪನ್ನವನ್ನು ಬಳಸುವ ಅಥವಾ ನಿರ್ಮಿಸುವ ಒಬ್ಬ ವ್ಯಕ್ತಿಗೆ ಅದನ್ನು ತೋರಿಸಿ, ಏನು ಅಸ್ಪಷ್ಟವಾಗಿದೆ ಎಂದು ಕೇಳಿ. ಅವರ ಪ್ರಶ್ನೆಗಳೇ ಇರುವ ಅಂತರಗಳು.

ಭರ್ತಿ ಮಾಡುವ PRD ಟೆಂಪ್ಲೇಟ್

ಇದನ್ನು ಡಾಕ್ಯುಮೆಂಟ್‌ಗೆ ನಕಲಿಸಿ ಆವರಣದಲ್ಲಿರುವ ಭಾಗಗಳನ್ನು ಬದಲಾಯಿಸಿ. ನಿಜವಾಗಿ ಅನ್ವಯಿಸದ ವಿಭಾಗಗಳನ್ನು ಅಳಿಸಿ.

ಉತ್ಪನ್ನದ ಹೆಸರು: [ಹೆಸರು] ಮಾಲೀಕರು: [ನಿರ್ಧಾರಗಳಿಗೆ ಹೊಣೆಯಾದ ವ್ಯಕ್ತಿ] ಸ್ಥಿತಿ: [ಕರಡು / ಪರಿಶೀಲನೆಯಲ್ಲಿ / ಒಪ್ಪಿಗೆಯಾಗಿದೆ] — ಕೊನೆಯ ನವೀಕರಣ: [ದಿನಾಂಕ]

1. ಸಾರಾಂಶ

[ಎರಡು ಅಥವಾ ಮೂರು ವಾಕ್ಯಗಳು: ಇದು ಏನು, ಯಾರಿಗಾಗಿ, ಮತ್ತು ಮುಖ್ಯ ಫಲಿತಾಂಶ.]

2. ಸಮಸ್ಯೆ

[ಬಳಕೆದಾರರ ದೃಷ್ಟಿಯಿಂದ ಸಮಸ್ಯೆ. ಅವರು ಇಂದು ಏನು ಮಾಡುತ್ತಾರೆ ಮತ್ತು ಅದು ಏಕೆ ನೋವುಂಟು ಮಾಡುತ್ತದೆ.]

3. ಬಳಕೆದಾರರು

ಬಳಕೆದಾರ ಪ್ರಕಾರಅವರಿಗೆ ಏನು ಬೇಕುಎಷ್ಟು ಬಾರಿ ಬಳಸುತ್ತಾರೆ
[ಉದಾ. ಮಾಲೀಕ][ಅಗತ್ಯ][ದೈನಂದಿನ / ವಾರಕ್ಕೊಮ್ಮೆ]
[ಉದಾ. ಗ್ರಾಹಕ][ಅಗತ್ಯ][ಅಪರೂಪಕ್ಕೆ]

4. ಗುರಿಗಳು ಮತ್ತು ಯಶಸ್ಸಿನ ಮಾಪನಗಳು

  • ಗುರಿ: [ಮೊದಲ ಆವೃತ್ತಿ ಸಾಧಿಸಬೇಕಾದ ಫಲಿತಾಂಶ]
  • ಮಾಪನ: [ಅದನ್ನು ಹೇಗೆ ಅಳೆಯುತ್ತೀರಿ, ಮತ್ತು ಗುರಿ ಮೌಲ್ಯ]
  • ಗುರಿಯಲ್ಲದ್ದು: [ಜನರು ಊಹಿಸಬಹುದಾದ, ಆದರೆ ಈ ಆವೃತ್ತಿ ಮಾಡಲು ಪ್ರಯತ್ನಿಸದ ವಿಷಯ]

5. ವ್ಯಾಪ್ತಿ

ಮೊದಲ ಆವೃತ್ತಿಯಲ್ಲಿ:

  • [ವೈಶಿಷ್ಟ್ಯ]
  • [ವೈಶಿಷ್ಟ್ಯ]

ಮೊದಲ ಆವೃತ್ತಿಯಲ್ಲಿ ಇಲ್ಲ:

  • [ವೈಶಿಷ್ಟ್ಯ, ಮತ್ತು ಅದು ಏಕೆ ಕಾಯಬಹುದು]
  • [ವೈಶಿಷ್ಟ್ಯ, ಮತ್ತು ಅದು ಏಕೆ ಕಾಯಬಹುದು]

6. ಬಳಕೆದಾರ ಕಥೆಗಳು

ಕಥೆ 1: [ಬಳಕೆದಾರ]ನಾಗಿ, ನಾನು [ಕ್ರಿಯೆ] ಮಾಡಲು ಬಯಸುತ್ತೇನೆ, ಇದರಿಂದ [ಫಲಿತಾಂಶ].

  • [ಸಂದರ್ಭ] ಇದ್ದಾಗ, [ಕ್ರಿಯೆ] ಮಾಡಿದಾಗ, [ಫಲಿತಾಂಶ] ಆಗಬೇಕು.
  • [ಸಂದರ್ಭ] ಇದ್ದಾಗ, [ಕ್ರಿಯೆ] ಮಾಡಿದಾಗ, [ಫಲಿತಾಂಶ] ಆಗಬೇಕು.

ಕಥೆ 2: [ಬಳಕೆದಾರ]ನಾಗಿ, ನಾನು [ಕ್ರಿಯೆ] ಮಾಡಲು ಬಯಸುತ್ತೇನೆ, ಇದರಿಂದ [ಫಲಿತಾಂಶ].

  • [ಸಂದರ್ಭ] ಇದ್ದಾಗ, [ಕ್ರಿಯೆ] ಮಾಡಿದಾಗ, [ಫಲಿತಾಂಶ] ಆಗಬೇಕು.

7. ಡೇಟಾ

ದಾಖಲೆಮುಖ್ಯ ಕ್ಷೇತ್ರಗಳುಯಾರು ರಚಿಸಬಹುದುಯಾರು ನೋಡಬಹುದು
[ಉದಾ. ಬುಕಿಂಗ್][ದಿನಾಂಕ, ಸಮಯ, ಗ್ರಾಹಕ, ಸೇವೆ][ಗ್ರಾಹಕ][ಮಾಲೀಕ, ಆ ಗ್ರಾಹಕ]

8. ಅನುಮತಿಗಳು

[ಯಾರು ಲಾಗಿನ್ ಆಗಬಹುದು, ಯಾವ ಪಾತ್ರಗಳಿವೆ, ಮತ್ತು ಪ್ರತಿ ಪಾತ್ರ ಏನನ್ನು ನೋಡಬಹುದು ಮತ್ತು ಬದಲಾಯಿಸಬಹುದು.]

9. ಅಂಚಿನ ಪ್ರಕರಣಗಳು

  • [ಖಾಲಿ ಸ್ಥಿತಿ: ಇನ್ನೂ ಡೇಟಾ ಇಲ್ಲದಾಗ ಏನು ತೋರಿಸುತ್ತದೆ]
  • [ತಪ್ಪು ಇನ್‌ಪುಟ್: ತಪ್ಪು ಇಮೇಲ್ ಅಥವಾ ಕಾಣೆಯಾದ ಕ್ಷೇತ್ರದೊಂದಿಗೆ ಏನಾಗುತ್ತದೆ]
  • [ಪ್ರವೇಶ: ಇರಬಾರದ ಪುಟವನ್ನು ಯಾರಾದರೂ ತೆರೆದರೆ ಏನಾಗುತ್ತದೆ]

10. ಸಂಯೋಜನೆಗಳು ಮತ್ತು ಮಿತಿಗಳು

[ಪಾವತಿಗಳು, ಇಮೇಲ್, ಇರುವ ಉಪಕರಣಗಳು, ಗಡುವುಗಳು, ಬಜೆಟ್, ಕೆಲಸ ಮಾಡಬೇಕಾದ ಸಾಧನಗಳು.]

11. ತೆರೆದ ಪ್ರಶ್ನೆಗಳು

ಪ್ರಶ್ನೆಹೊಣೆನಿರ್ಧರಿಸಬೇಕಾದ ದಿನಾಂಕ
[ಪ್ರಶ್ನೆ][ಹೆಸರು][ದಿನಾಂಕ]

PRD ಯಿಂದ ಪ್ರಾಂಪ್ಟ್‌ಗಳವರೆಗೆ

ಒಂದು ಉತ್ತಮ PRD ಬಹುತೇಕ ನೇರವಾಗಿ AI ಆಪ್ ಬಿಲ್ಡರ್‌ಗೆ ಪ್ರಾಂಪ್ಟ್‌ಗಳಾಗಿ ಬದಲಾಗುತ್ತದೆ:

  • ಸಾರಾಂಶ, ಬಳಕೆದಾರರು ಮತ್ತು ಡೇಟಾ ಕೋಷ್ಟಕ ನಿಮ್ಮ ಮೊದಲ ಪ್ರಾಂಪ್ಟ್ ಆಗುತ್ತದೆ.
  • ಪ್ರತಿ ಬಳಕೆದಾರ ಕಥೆ ಒಂದು ಅನುಸರಣಾ ಪ್ರಾಂಪ್ಟ್ ಆಗುತ್ತದೆ.
  • ಪ್ರತಿ ಸ್ವೀಕಾರ ಮಾನದಂಡ ನೀವು ಪ್ರಿವ್ಯೂನಲ್ಲಿ ಪರೀಕ್ಷಿಸುವ ವಿಷಯವಾಗುತ್ತದೆ.
  • "ಮೊದಲ ಆವೃತ್ತಿಯಲ್ಲಿ ಇಲ್ಲ" ಪಟ್ಟಿ ನೀವು ಇನ್ನೂ ಕೇಳಲು ನಿರಾಕರಿಸುವ ವಿಷಯಗಳು.

PRD ಯನ್ನು ಒಮ್ಮೆಲೇ ಅಂಟಿಸಿ ಎಲ್ಲವನ್ನೂ ಕೇಳುವುದಕ್ಕಿಂತ, ಒಂದು ಕಥೆ ಒಂದು ಸಮಯದಲ್ಲಿ ನಿರ್ಮಿಸಿ ಅದರ ಸ್ವೀಕಾರ ಮಾನದಂಡಗಳನ್ನು ಪರಿಶೀಲಿಸಿ ಮುಂದುವರಿಯುವುದು ಬಹಳ ವಿಶ್ವಾಸಾರ್ಹ. AI ಆಪ್ ಬಿಲ್ಡರ್‌ಗಳಿಗೆ ಪ್ರಾಂಪ್ಟ್ ಬರೆಯುವುದು ಹೇಗೆ ಪ್ರಾಂಪ್ಟ್ ಭಾಗವನ್ನು ಇನ್ನಷ್ಟು ವಿವರವಾಗಿ ಹೇಳುತ್ತದೆ.

ಸಾಮಾನ್ಯ ತಪ್ಪುಗಳು

  • ಪರಿಹಾರವನ್ನೇ ಸಮಸ್ಯೆಯಾಗಿ ಬರೆಯುವುದು. "ಬಳಕೆದಾರರಿಗೆ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್ ಬೇಕು" ಒಂದು ಪರಿಹಾರ. "ಮಾಲೀಕರು ಪ್ರತಿ ಇನ್‌ವಾಯ್ಸ್ ತೆರೆಯದೆ ಯಾವುದು ಅವಧಿ ಮೀರಿದೆ ಎಂದು ನೋಡಲಾಗುವುದಿಲ್ಲ" ಒಂದು ಸಮಸ್ಯೆ.
  • "ವ್ಯಾಪ್ತಿಯಿಂದ ಹೊರಗೆ" ವಿಭಾಗವಿಲ್ಲದಿರುವುದು. ಅದಿಲ್ಲದಿದ್ದರೆ ಪ್ರತಿ ಸಂಭಾಷಣೆಯಲ್ಲಿ ವ್ಯಾಪ್ತಿ ಮತ್ತೆ ತೆರೆಯುತ್ತದೆ.
  • AI ಬಳಕೆದಾರರನ್ನು ಕಲ್ಪಿಸಲು ಬಿಡುವುದು. AI ಮಾಡಿದ ಕಾಲ್ಪನಿಕ ವ್ಯಕ್ತಿತ್ವಗಳು ನಿಜವಂತೆ ಅನಿಸುತ್ತವೆ, ಆದರೆ ಅವು ನಿಜವಲ್ಲ.
  • ಅಳೆಯಲಾಗದ ಮಾಪನಗಳು. ಎಣಿಸಲು ಮಾರ್ಗವಿಲ್ಲದಿದ್ದರೆ, ಅದು ಮಾಪನವಲ್ಲ.
  • ಎಂದಿಗೂ ನವೀಕರಿಸದಿರುವುದು. ನೀವು ನಿರ್ಮಿಸುತ್ತಿರುವುದಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗದ PRD ಯಾವುದೂ ಇಲ್ಲದಿರುವುದಕ್ಕಿಂತ ಕೆಟ್ಟದು. "ಕೊನೆಯ ನವೀಕರಣ" ದಿನಾಂಕವನ್ನು ಇಟ್ಟುಕೊಳ್ಳಿ ಮತ್ತು ನಿರ್ಧಾರಗಳು ಬದಲಾದಾಗ ಅದನ್ನು ಬದಲಿಸಿ.

Mythex ಜೊತೆ PRD ಬಳಸುವುದು

ನೀವು Mythex ನಲ್ಲಿ ನಿರ್ಮಿಸುತ್ತಿದ್ದರೆ, ನಿಮ್ಮ PRD ಅನ್ನು ನೇರವಾಗಿ ಚಾಟ್‌ನಲ್ಲಿ ಅಂಟಿಸಬಹುದು. PRD ಗೆ Plan ಮೋಡ್ ಚೆನ್ನಾಗಿ ಹೊಂದುತ್ತದೆ: ಏಜೆಂಟ್ ಅದನ್ನು ಓದುತ್ತದೆ, ಒಂದು ವಿಧಾನ ಮತ್ತು ಹಂತಗಳ ಪರಿಶೀಲನಾ ಪಟ್ಟಿಯನ್ನು ಪ್ಲಾನ್ ಟ್ಯಾಬ್‌ನಲ್ಲಿ ಪ್ರಸ್ತಾಪಿಸುತ್ತದೆ, ಮತ್ತು ನೀವು Build ಒತ್ತುವವರೆಗೆ ಫೈಲ್‌ಗಳನ್ನು ಬದಲಾಯಿಸಲು ಪ್ರಾರಂಭಿಸುವುದಿಲ್ಲ. ಪ್ರೇಕ್ಷಕರು, ಬ್ರ್ಯಾಂಡ್ ಮತ್ತು ನಿಯಮಗಳಂತಹ ಯಾವಾಗಲೂ ಅನ್ವಯವಾಗಬೇಕಾದ ಭಾಗಗಳನ್ನು ಪ್ರಾಜೆಕ್ಟ್ ಜ್ಞಾನವಾಗಿ ಉಳಿಸಬಹುದು, ಆಗ ಪ್ರತಿ ಚಾಟ್‌ನಲ್ಲಿ ಪುನರಾವರ್ತಿಸಬೇಕಾಗಿಲ್ಲ. ಚಾಟ್ ದಸ್ತಾವೇಜು Build, Plan ಮತ್ತು Ask ಮೋಡ್‌ಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ, ಮತ್ತು ಟೆಂಪ್ಲೇಟ್‌ಗಳು ಪೂರ್ಣ ಡಾಕ್ಯುಮೆಂಟ್ ಬರೆಯುವ ಮೊದಲು ಮೊದಲ ಆವೃತ್ತಿ ಹೇಗಿರಬಹುದು ಎಂದು ನೋಡಲು ತ್ವರಿತ ದಾರಿ.

ಪ್ರಶ್ನೆಗಳು

ಉತ್ಪನ್ನ ಅವಶ್ಯಕತೆಗಳ ಡಾಕ್ಯುಮೆಂಟ್ ಎಂದರೇನು?

PRD ಎಂದರೆ ಒಂದು ಉತ್ಪನ್ನ ಅಥವಾ ವೈಶಿಷ್ಟ್ಯ ಏನು ಮಾಡಬೇಕು, ಅದು ಯಾರಿಗಾಗಿ ಮತ್ತು ಅದು ಕೆಲಸ ಮಾಡುತ್ತಿದೆ ಎಂದು ಹೇಗೆ ತಿಳಿಯುವುದು ಎಂದು ಹೇಳುವ ಸಣ್ಣ, ಸರಳ ಭಾಷೆಯ ವಿವರಣೆ. ಇದು ಸಮಸ್ಯೆ ಮತ್ತು ನಿರೀಕ್ಷಿತ ವರ್ತನೆಯನ್ನು ವಿವರಿಸುತ್ತದೆ, ಕೋಡ್ ಅನ್ನು ಅಲ್ಲ. ಹಾಗಾಗಿ ವಿನ್ಯಾಸಕರು, ಡೆವಲಪರ್‌ಗಳು ಮತ್ತು AI ಉಪಕರಣಗಳು ಎಲ್ಲರೂ ಇದನ್ನು ಆಧಾರವಾಗಿಟ್ಟುಕೊಂಡು ನಿರ್ಮಿಸಬಹುದು.

AI ನನಗಾಗಿ PRD ಬರೆಯಬಲ್ಲದೇ?

ನಿಮ್ಮ ಟಿಪ್ಪಣಿಗಳನ್ನು ರಚನಾತ್ಮಕ ಕರಡಾಗಿ ಬದಲಾಯಿಸಲು, ಕಾಣೆಯಾದ ವಿಭಾಗಗಳನ್ನು ಗುರುತಿಸಲು ಮತ್ತು ಅಂಚಿನ ಪ್ರಕರಣಗಳನ್ನು ಸೂಚಿಸಲು AI ಉತ್ತಮ. ಆದರೆ ನಿಮ್ಮ ಬಳಕೆದಾರರು, ಮಿತಿಗಳು ಅಥವಾ ಆದ್ಯತೆಗಳು ಅದಕ್ಕೆ ತಿಳಿದಿರುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ ಗುರಿ, ವ್ಯಾಪ್ತಿ ಮತ್ತು ಏನನ್ನು ಬಿಡಬೇಕು ಎಂಬುದನ್ನು ನೀವೇ ನಿರ್ಧರಿಸಬೇಕು ಮತ್ತು AI ಸೇರಿಸುವ ಪ್ರತಿಯೊಂದು ಅವಶ್ಯಕತೆಯನ್ನೂ ಪರಿಶೀಲಿಸಬೇಕು.

PRD ಎಷ್ಟು ಉದ್ದವಿರಬೇಕು?

ಯಾರು, ಏನು, ಏಕೆ ಮತ್ತು ಅದನ್ನು ಹೇಗೆ ಅಳೆಯುತ್ತೀರಿ ಎಂಬುದಕ್ಕೆ ಉತ್ತರಿಸಲು ಸಾಕಾಗುವಷ್ಟು ಚಿಕ್ಕದಾಗಿರಲಿ. ಆಪ್‌ನ ಮೊದಲ ಆವೃತ್ತಿಗೆ ಸಾಮಾನ್ಯವಾಗಿ ಒಂದರಿಂದ ಮೂರು ಪುಟಗಳು ಸಾಕು. ಉದ್ದದ ದಾಖಲೆಗಳನ್ನು ಹೆಚ್ಚಾಗಿ ಯಾರೂ ಓದುವುದಿಲ್ಲ, ಮತ್ತು ಮುಖ್ಯವಾದ ಕೆಲವು ನಿರ್ಧಾರಗಳು ಅವುಗಳಲ್ಲಿ ಮರೆಯಾಗುತ್ತವೆ.

AI ಆಪ್ ಬಿಲ್ಡರ್ ಬಳಸಿ ನಿರ್ಮಿಸುತ್ತಿದ್ದರೆ ನನಗೆ PRD ಬೇಕೇ?

ಔಪಚಾರಿಕ PRD ಅಗತ್ಯವಿಲ್ಲ, ಆದರೆ ಒಂದು ಚಿಕ್ಕ PRD ಇದ್ದರೆ AI ಬಿಲ್ಡರ್‌ಗಳು ಹೆಚ್ಚು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತವೆ. PRD ಯಲ್ಲಿರುವ ಬಳಕೆದಾರ ಕಥೆಗಳು ಮತ್ತು ಡೇಟಾ ಪಟ್ಟಿ ಉತ್ತಮ ಪ್ರಾಂಪ್ಟ್‌ಗಳಾಗಿ ನೇರವಾಗಿ ಬದಲಾಗುತ್ತವೆ, ಮತ್ತು ವ್ಯಾಪ್ತಿ ವಿಭಾಗವು ಎಲ್ಲವನ್ನೂ ಒಮ್ಮೆಲೇ ಕೇಳುವುದನ್ನು ತಡೆಯುತ್ತದೆ.

Mythex · Pricing · AI ನೊಂದಿಗೆ ಏನನ್ನಾದರೂ ನಿರ್ಮಿಸಿ · ವೆಬ್‌ಸೈಟ್ ಮತ್ತು ಆ್ಯಪ್ ಟೆಂಪ್ಲೇಟ್‌ಗಳು · Mythex ಹೋಲಿಕೆ · AI ಆ್ಯಪ್ ನಿರ್ಮಾಣ ಗ್ಲಾಸರಿ · ಉಚಿತ AI ಆ್ಯಪ್ ನಿರ್ಮಾಣ ಉಪಕರಣಗಳು · English

English አማርኛ العربية Български বাংলা Bosanski Català Čeština Dansk Deutsch Ελληνικά Español Español (España) Eesti فارسی Suomi Français Français (Canada) ગુજરાતી हिन्दी Hrvatski Magyar Հայերեն Bahasa Indonesia Íslenska Italiano 日本語 ქართული Қазақ тілі 한국어 Lietuvių Latviešu Македонски മലയാളം Монгол मराठी Bahasa Melayu မြန်မာ Norsk bokmål Nederlands ਪੰਜਾਬੀ Polski Português (Brasil) Português (Portugal) Română Русский Slovenčina Slovenščina Soomaali Shqip Srpski Svenska Kiswahili தமிழ் తెలుగు ไทย Tagalog Türkçe Українська اردو Tiếng Việt 简体中文 繁體中文(香港) 繁體中文(台灣)