מה רמת הפירוט הנכונה לאפיון? (Spec vs PRD)

Uri Lifshitz

מה רמת הפירוט הנכונה לאפיון? (Spec vs PRD)

השבוע, בזמן שהייתי אצל לקוח, הייתי בדיון מרתק ועתיק ימים על רמת הפירוט שצריכה להיות לאייפון של פיצ'ר. שאלו אותי "כמה עמוק" צריך להיות האפיון וכיאות לאיש מקצוע מומחה בתחום עניתי מייד "שבע", הם שאלו "מה שבע?", ועניתי את התשובה המסורתית "מה כמה?"

והייתי רציני. לא כל הפיצרים נבראו שווים, לא כל מנהלי המוצר זהים ולא כל צוותי הפיתוח זהים. רמת הפירוט של איפיון פיצ'ר צריכה לקחת בחשבון את כל הדברים האלו.בואו נעבור רגע על כמה נקודות חשובות לקביעת רמת הפירוט הנדרשת לאיפיון חדש:

בואו נתחיל מפיצ'רים – לא כל הפיצרים באותה רמת מורכבות. האפיון הכי קצר שכתבתי היה שורה אחת ("תוסיף כפתור signin with google") האפיון הכי ארוך שכתבתי היה עשרות עמודים. עומק האפיון צריך להיות ביחס למורכבות של הפיתוח.

פרונטאנד/בקאנד – אני עושה חלוקה בסיסית בין אפיון שכולל ממשק משתמש וצריך להכיל wireframes, הוראות ניווט, אינטראקציות ועוד לבין אפיון של תהליכי עיבוד שלרוב ידרוש רק טקסט, אלגוריתם, או תרשימי זרימה. לכל אחד מאלו נדרשת רמה נוספת של פירוט כדי למנוע בעיות.

מה? שיהיה לנו כמה סוגים של מסמכי אפיון??
לא. אני מאוד נגד זה. צריכה להיות אחידות כדי למנוע אי הבנות ולהשתפר לאורך זמן. בשביל זה טוב אם יש טמפלייט ברור לאיפיונים והטמפלייט הזה צריך לעבוד בשבילכם. להקל עליכם לעשות את העבודה.

מה התפקיד של הטמפלייט? מבחינת מנהל המוצר: לוודא שלא שוכחים חלקים חשובים ברפיון, לעזור לסדר את כל התהליך האפיון, למנוע דיונים חוזרים ושאלות מיותרות. אחת הדרכים שבהן אני מודד את האיפיונים שלי זה כמה פעמים אנשים צריכים לפנות אלי עם שאלות והבהרות אחרי שהעברתי להם את האפיון.

עבור המפתחת הטמפלייט צריך למקד עבורה את הדברים החשובים ולהקל עליה למצוא את מה שהיא צריכה. לרוב נארוז את כל מה שהמפתחת צריכה לדעת באותו פרק בכדי להקל עליה.

איפה מנהלים את האיפיונים? הם במסמכי Google doc? הם בתוך כלי ניהול כמו ג'ירה? ה-ui נמצא בתוכם? או שיש קישור לכלי העיצוב? הטמפלייט עוזר לנו עם ניהול תהליך הפיתוח.

התנהלות מול צוות הפיתוח: אם צוות הפיתוח נמצא איתכם בקומה והמפתחת מרגישה בנוח לשאול שאלות ויש לנו זמינות לענות – יכול להיות שאפשר לפרט פחות. אם צוות הפיתוח הוא offshore (והאם הוא חלק מהחברה או קבלן חיצוני) צריך להשפיע על רמת הפירוט של האיפיון.

חברת פיתוח שהיא קבלן חיצוני מחוייבת לתת לכם רק את מה שכתוב באיפיון. אם שכחתם לכתוב משהו אז הם ישכחו לפתח אותו כי הם לא מתיימרים להבין את מה שאתם רוצים. הם שכירי חרב.

כל הפוסט הזה הזכיר לי דיון דומה בנושא אחריות שהיה לי לפני כמה חודשים. הגישה שלי נוטה לקחת את כל האחריות עלי ולרשום כל דבר שנדרש. כל בדיקה וכל דרישה. זה אומר שאם אני רושם שדה של גיל, אני ארשום לוודא שהערך הוא מספר חיובי בין 0 לבין 120.

זוגי לדיון אגב טען שהוא לא עושה את זה כדי שהפיתוח לא יתרגל רק ליישם את האפיון מבלי לחשוב.
שתי הגישות לגיטימיות בעיני אבל הערך המוסף האמיתי הוא בכך שאתה מדבר עם צוות הפיתוח ומתאם ציפיות.

אחרון חביב, אחת מהתובנות הכי חשובות שיש: בסוף, הכל זה בני אדם. אם אתם מכירים את המפתחת שהולכת לעבוד על המוצר אז תתחשבו בהעדפות של באפיון.

מה עושה מנהל מוצר?

למה כל כך קשה להבין מה עושים מנהלי מוצר? האמת שזה לא קשה, התשובה היא: ניהול מוצר הוא מקצוע מאתגר בו אתה אחראי ברמה זו

לגלות עוד מהאתר נעים מאוד, בלוג

כדי להמשיך לקרוא ולקבל גישה לארכיון המלא יש להירשם עכשיו.

להמשיך לקרוא

ליצירת קשר

בואו נדבר

סדנת KPIs ומדדי הצלחה

מבוא למדדי הצלחה

מעבר על מהם מטריקות, מהם KPIs, כיצד להגדיר מדדים ויעדים בצורה נכונה, היכרות עם מתודות לעבודה יעילה, ואיך להימנע מטעויות נפוצות.

תמחור

2,500 ש"ח, שעתיים, עד 10 משתתפים

ליצירת קשר

מייל: uri@optareconsulting.com

טלפון:
0523492627