מעולמו של סמנכ"ל מו"פ – המירוץ האין סופי אחרי הגדרת מוצר, חזון הנדסי, איכות, אנשים, תוצאות, עוד תוצאות (...וקצת אמפטיה בדרך)
פוסטים פופולאריים
-
סף דרישות גבוה (מדי?)
23/5/07 | 3295 צפיות
-
לקפוץ מעל תהום שיווקית ולהישאר בחיים!? (ואיך מו"פ קשור לזה...)
13/8/07 | 4084 צפיות
-
דחיפת איכות במעלה הזרם...
19/4/07 | 4140 צפיות
-
מנהל 2.0
6/6/07 | 2187 צפיות
-
על עתיד תחום פיתוח התוכנה. האם אנחנו על סף שינוי גדול? חלק ראשון
12/7/07 | 4428 צפיות
-
סיפור אישי על יזמות וארגוני פיתוח גדולים
20/9/07 | 5204 צפיות
פוסטים אחרונים
- סיפור אישי על יזמות וארגוני פיתוח גדולים 20/9/07
- לקפוץ מעל תהום שיווקית ולהישאר בחיים!? (ואיך מו"פ קשור לזה...) 13/8/07
- על עתיד תחום פיתוח התוכנה. האם אנחנו על סף שינוי גדול? חלק שני 21/7/07
- על עתיד תחום פיתוח התוכנה. האם אנחנו על סף שינוי גדול? חלק ראשון 12/7/07
- ארץ השמש והאיכות העולה - על דמינג ומשנתו 16/6/07
- מנהל 2.0 6/6/07
סף דרישות גבוה (מדי?)
מישהו סיפר לי שפעם הוא קנה תוכנה מסויימת והסתכל על הצד האחורי של הקופסא. הוא ראה תחת דרישות התוכנה - requires Windows XP or better. אז הוא פשוט הלך והתקין linux......
לא, אני לא מתכוון להכנס לדיונים דתיים בפוסט הזה, אבל אני כן רוצה לשאול - מתי בפעם האחרונה נתקלתם במסמך דרישות מוצר מצויין? כזה שהיה ממצה ופשוט לקריאה? כזה שדיסיפלינות הפיתוח קיבלו אותו כבסיס מוסכם וחד משמעי ליצירת התכנה? והכי חשוב – כזה שנשאר תקף לאורך חיי פיתוח המוצר? ... קשה, אה?
עבור מנהל מוצר (product manager) חווית כתיבת דרישות המוצר עשויה להיות במקרים רבים לא פשוטה. מנהל מוצר מעורב בצורה אינטימית בעשיית החברה – שיווק, פיתוח ופיתוח עסקי. כתיבת הדרישות אמורה לייצר שפה אחידה המגשרת בין כולם ובנוסף היא צריכה להיות חד משמעית על מנת למנוע אינטרפרטציות שיגרמו לאי הבנות שבסופו של דבר יגרמו ליצירת ושיווק המוצר הלא נכון (או תיקונו בשלבים מאוחרים מאד). בנוסף שפה אחידה אמורה לצלוח מכשולים של שפת דיבור ותרבות והעובדה שחברות רבות הן בינלאומיות, מקשה מאד מן הסתם כאן.
בפוסט זה, אנסה לתאר כמה מכשולים טיפוסיים ביצירת מסמכי דרישות ואספק מספר טיפים של איך ניתן להתגבר עליהם.
· איפה נגמרות הדרישות ומתחיל הפיתוח? שאלה קשה ומקור בלתי נדלה לוויכוחים (לעתים רוויי דם) בין אנשי מוצר ואנשי הפיתוח. אנשי המוצר באופן טבעי רוצים להישאר ברמת המוצר ודרישות השוק. אנשי הפיתוח רוצים למנוע כפל משמעויות ולכן רוצים לראות כמה שיותר פרטים במסמכי הדרישות. אנשי ה- QA מתבססים על פי רוב על מסמכי הדרישות כבסיס לבדיקות המוצר ולכן גם הם רוצים לראות מסמכים מפורטים מאד. אז איפה האמת? הדרך הפשוטה להסתכל על זה מנסיוני הוא בגישת ה- "מה" וה- "איך". אנשי מוצר צריכים להתמקד במה המוצר יעשה. אנשי הפיתוח - באיך המוצר יעבוד. דוגמא לדרישת מוצר – "המוצר יתמוך בלקוחות המתחברים גם באמצעות דפדפני ווב וגם באמצעות smart clients המספקים חוויית משתמש עשירה וכן עבודה במצב מקוון ומצב לא מקוון." תרגום המשפט הנ"ל לדרישות הנדסיות יעבור דרך בחינת טכנולוגיות (האם זה אפשרי ואיך), דרישות ארכיטקטורה , וכו' ולבסוף יעובד לסדרת הנחות הנדסיות שיתוארו במסמך התכן ההנדסי. מסמכי תכן יכללו במקרים רבים ציורים של מסכי דמה ופרטים נוספים שיאפשרו דיון יותר מפורט בתרגום דרישות המוצר למימוש הנדסי. דבר נוסף לזכור כאן – כמות אנשי המוצר בארגון טיפוסי היא מועטה מאד יחסית לגודל ארגון הפיתוח. כמו כן על אנשי המוצר בדר"כ מועמסות פונקציות נוספות כגון קדם-מכירה ללקוח ולעתים אף פיתוח עסקי. המטרה היא לייצר מסגרת דרישות טובה במסגרת המגבלות לאנשי הפיתוח שאותה יוכלו לקחת הלאה לדרישות המפורטות יותר ותרגומן לפיתוח. כך שהגבול בין הדיסיפלינות הוא אפור ולדעתי טוב שכך. זה מאפשר דיאלוג ושיתוף של הפיתוח בהבנת צרכי הלקוח ושם על הפיתוח אחריות לתרגום מתוך הבנת המסגרת. זה גם דורש מאיש המוצר להיות מעורב בהתפתחות הדרישות לאורך כל חיי הפיתוח ועזרה בפרשנות מדי פעם. הסכנה היא בנסיון להגדיר בצורה מאד כירורגית את הגבולות דבר המבזבז זמן מיותר לארגון כולו ועלול לגרום ליצירת משקעים מיותרים ברמה האישית מנסיוני.
· דרישות מנוסחות היטב דרישות טובות הן פשוטות להבנה, ספציפיות, מדידות וריאליות. אני ממליץ לקרוא על המושג “smart goals”. אם לא נתקלתם עדיין במונח. לינק אחד לנושא נמצא כאן. בנוסף זכרו שהדרישות יצטרכו להתפרש בצורה קונסיסטנטית בקרב אנשים מדיסיפלינות, גאוגרפיות ותרבויות שונות. לכן ניסוחן חייב להיות קפדני מאד ומדויק
· תיעדוף נכון דרישות מוצר מגיעות מהרבה מקורות כשלכל אחד יש אג'נדה ועדיפויות משלו. לאלו שמתקינים ועובדים עם המוצר יש דרישות מאד שונות מיועצים העוזרים ללקוח בבחירת המוצר, מאנשי מכירות ואנשי פיתוח. זכרו שכל צד נוטה לראות רק את הדרישות והאינטרסים שלו ובאופן טבעי הדרישות שלו מקבלות את המשקל הגבוה ביותר בעיניו. מנהל מוצר טוב ישקלל ויאזן בין כולם. מוצר טוב יכלול בסופו של יום מספר תכונות שיעזרו למכור אותו טוב יותר יחסית למתחרים, מספר תכונות שישפרו את הארכיטקטורה הפנימית ויעזרו לתמיכה או הוצאה מהירה יותר של שינויים עתידיים, מספר תכונות שיעזרו לשותפים עסקיים לפתח פתרונות, מספר תכונות שיעזרו ל-usability של המוצר בקרב משתמשים, וכן הלאה.
· הבנת שוק
נקודה זו מתחברת באופן טבעי וממשיכה את הקודמת. הבנת שוק המטרה למוצר היא חשובה מאד. אם הבנה זו מגיעה מהלקוחות הקיימים בלבד, זה לא בריא. שוב, לקוחות אלו מתקשרים צרכים ספציפיים שנחוצים להם. הם לא מסתכלים בהכרח איך המוצר שלך יגדיל נתח שוק ואף יתפרס לשווקים חדשים. מומלץ מאד לקבל סקר שוק מיועצים אובייקטיבים המבינים היטב את השוק שבו אתה פועל או בו אתה רוצה לפעול. רצוי להתייעץ עם אנשי אנשי חזון שיכולים להסתכל על מגמות וצרכים עתידיים ולא רק על השלמת פערים טקטיים. בסופו של דבר מעבר לסגירת פערים עם מתחרים ולקוחות קיימים, המטרה היא לבנות מוצר תחרותי הנותן יתרון יחסי לחברה לאורך שנים קדימה. · אי וודאות
דרישות מוצר וחוסר וודאות הולכים יד ביד. אי הוודאות מנסיוני קיימת בעיקר באספקטים הבאים: 1. תהליך יצירת הדרישות 2. תגובה לשינויים חיצוניים המכתיבים שינויי דרישות מספר תובנות: יצירת הדרישות נעשית קלה יותר כששאלות המפתח מוצגות ונענות בשלב מוקדם מאד. האם הדרישות באות ממקום עסקי או טכני? אני אישית נתקלתי בהמון בלבול כאן כשהנטייה במיוחד בחברות עם בסיס הנדסי חזק לייצר דרישות הנדסיות קודם למרות שזה מעוות את הראייה העסקית. בעייה נוספת היא שבארגונים מסויימים לא ברור ממש מי מייצר את הדרישות ומי מחליט עליהן. חוסר בהירות זו "מורחת" בד"כ את התהליך לאורך זמן בלי מנהיגות ברורה בדרך. שאלה נוספת היא מתי מתחילים את התהליך ומתי גוף הפיתוח לוקח חלק. האם כל הדרישות צריכות להיות מוגדרות לפני שהפיתוח מתחיל לייצר מסמכי תכן הנדסי?תגובה לשינויים – תהליך פיתוח טוב יודע להתמודד עם שינויי דרישות בצורה מובנה. זה נכון בפרט לכל התהליכים המבוססים על agile (אתם מוזמנים לקרוא את הפוסט שלי בנושא כאן). הרעיון הכללי הוא להסכים בשלב מוקדם על תכולה כללית ובצע אותה ע"י מחזורי פיתוח קצרים מאד כשהדגש הוא להדגים בסוף כל איטרציה "מוצר שלם עובד" שמאפשר קבלת פידבק ושינויים בהתאם. בצורה כזו ניתן לשנות דרישות תוך כדי תנועה בצורה מובנית וכן לייצר מנגנון פידבק קבוע של התפתחות המוצר כנגד הדרישות שלו. · על דמוקרטיה ועריצות
בעוד תהליך איסוף הדרישות מעודד את כולם (עובדים ולקוחות) להשתתף, אין זה אומר שכל רעיון ייושם בסופו של דבר. הבעייה היא שאנשים נוטים להתאהב בדרישות שהם הציעו. בפועל כפי שרובנו יודעים רוב ההחלטות לגבי דרישות המוצר או ה- "רוח" שלהן, יגיעו מאותם "רודנים" בצורת מייסדי החברה, מנהליה, וכו' – אותם אנשים המובילים את חזון החברה ותפיסת השוק שלה. כאן לתפיסתי, מנהל המוצר מכניס את הערך המוסף הגדול ביותר שלו בתהליך. הצלחתו לא נמדדת בכמות הדרישות הפרטיות שלו שנכנסו פנימה, אלא באיכות התהליך ובמנהיגות שלו ביישומו. על מנהל המוצר מוטלת האחריות לוודא שכל מכלול השיקולים מונח על שולחן ההחלטה ושההנהלה עושה החלטות מתוך ראיית שיקולים רחבה (תחרותיות שוק, מענה לדרישות לקוחות, חזון, יכולת תמיכה והרחבה, דרישות שותפים, וכו') ובצורה מובנה. דבר אחרון לזכור, ובזאת אסיים להפעם – אובייקטיביות התהליך היא דבר טוב לשאוף אליו. אבל חשוב מאד להשאר פרגמטיים. בסופו של דבר תהליכים אובייקטיביים כמו איסוף דרישות מונעים ע"י אנשים שמטבעם הם יצורים מאד סובייקטיבים. בסופו של דבר אין תחליף ל- judgment call של אנשים רלוונטיים הרואים את התמונה הרחבה. החכמה היא לברור ולהציג את בליל הדרישות בצורה חכמה שתאפשר החלטות סובייקטיביות ובכך טמונה בעצם כל הצלחת מנהל המוצר. לקריאה נוספת אני ממליץ על הלינק הזה. הוא מכיל מאמרים רבים בנושא זה שעל חלקם פוסט זה מתבסס.
אשמח להמשיך את הדיון בקהילת המו"פ כאן.
|
תגובות אחרונות
-
דניאל דיין d
בתגובה על על עתיד תחום פיתוח התוכנה. האם אנחנו על סף שינוי גדול? חלק ראשון
-
marmor
בתגובה על על עתיד תחום פיתוח התוכנה. האם אנחנו על סף שינוי גדול? חלק שני
-
נטע וינריב
בתגובה על סיפור אישי על יזמות וארגוני פיתוח גדולים
-
אבי אהרן
בתגובה על ארגוני מו"פ קלי תנועה – עונת סדנאות ההרזיה בעיצומה!
-
דקל א
בתגובה על לקפוץ מעל תהום שיווקית ולהישאר בחיים!? (ואיך מו"פ קשור לזה...)
-
yassa
בתגובה על הקדמה (והזמנה)
תגובות (9)
נא להתחבר כדי להגיב
התחברות או הרשמה
/null/text_64k_1#
אני מסכים, החשיפה ללקוחות עוזרת לפיתוח להבין את הצרכים וזה בוודאי דבר טוב. אם זאת נדיר שלקוח אחד ספציפי יספק לך את כל הדרישות. תהליך איפיון הדרישות מורכב מ-1) איסוף נתונים פנימי וחיצוני. נתונים יכולים להיות מה שלקוח X אמר, אבל יכולים להיות גםמאמר באינטרנט, המפרט של המתחרה או הרצאה בכנס. דרך אגב כמה מהפיצ'רים הכי שימושיים מגיעים מהפיתוח וה-test, לכן חשוב לתשאל גם אותם, כפי שציין תובל 2) אנליזה של הנתונים - מה רלוונטי ומה לא, מה חשוב יותר ומה פחות - בד"כ על בסיס מטרות עסקיות 3) סינטזה של הדרישות.
הפיתוח יכולים וצריכים לתרום לתהליך אבל חשוב שמישהו שזה תפקידו יעשה אותו ב-100% משרה.
אם יותר מפתחים יהיו מעורבים בעבודה עם לקוחות, כך יוכלו להבין יותר טוב את צרכיהם ולהיות "בראש של מנהל המוצר", וגם לקבל מוטיבציה נוספת לעבודה.
משום מה, נראה לי שהנטייה של ארגונים היא דווקא להשאיר את הפיתוח רחוק מלקוחות.
פוסט קולע.
למעשה, השירות ללקוח מתחיל כבר בשלב הגדרת המוצר, עוד לפני שהלקוח הפך ללקוח. האיזון בין השקעה בפונקציונליות ופיצ'רים שנראים טוב בפרזנטציה ומוכרים, לבין השקעה בכלים פונקציונליים שהם פחות "פוטוגניים", אך מתגלים כחיוניים ביותר בחיי היומיום של משתמשי המערכת, מהווה דוגמא בולטת להשפעת שלב ההגדרה על רמת שביעות רצון הלקוחות בהמשך.
אריאל - עוד פוסט מצוין. ממצה ומעניין.
בנוגע לציפיות ממנהל המוצר. התפיסה הנאיבית (שעדיין רווחת בארגונים מסוימים) גורסת ש:
1. מנהל המוצר יודע את כל הדרישות במידה גבוהה של וודאות
2. מנהל מוצר טוב ידע לייצר מסמך דרישות מקיף,מפורט וברור בזמן להניע את ה-dev וה-test
3. הדרישות לא יישתנו באופן משמעותי לאחר פירסומן .
כאידיאל זה נחמד, אבל בפועל אנו עובדים בסביבה אמורפית ולא דטרמינסטית שבה הקבוע היחיד הוא השינוי. הדבר נכון במיוחד לדרישות תוכנה ובמיוחד בארגונים קטנים ודינמיים - מה שהיה דרישה בעדיפות עליונה אתמול עלול להפוך ללא רלוונטי מחר כי הלקוח התחלף או כי הגיע מידע חדש או כי משהו השתנהבשוק או כי המנכ"ל/סמנכ"ל-שיווק/דירקטור-מכירות שינה את דעתו, או כי הסטארט-אפ בחר בכיוון חדש. יוצא שה-PM בעצמו נמצא בתהליך מתמיד של איסוף ולימוד הדרישות תוך מחקר ותקשורת עניפה פנימה והחוצה. בכל זמן נתון ה-PM יכול לומר מה לדעתו הדרישות נכון לעכשיו, אבל הוא לא יכול להתחייב שדעתו לא תשתנה בעתיד הקרוב או הרחוק. יוצאים מזה כמה דברים חשובים:
1. הארגון צריך לאמץ את חוסר הוודאות בדרישות כעובדה קיימת ולבנות גמישות לתוך התהליכים (כולל בפיתוח).
2. עדיף לפרמל את הדרישות מאוחר ככל האפשר, אידיאלית סמוך לזמן התכנון והקידוד. הדרישות הטובות ביותר הן אלה שנלמדו על בסיס נסיון אמיתי של פרוטוטייפ או גירסת ביניים.
3. מסמכי דרישות עבי כרס לא עובדים כי: א) לוקח הרבה זמן לכתוב אותם, כלומר כשהם מתפרסמים הם כבר לא רלוונטיים ב) הזמן שה-PM מקדיש לכתיבה ספון בחדרו ונאבק ב-Word הוא זמן מת מבחינת תיקשורת ומחקר - סכנה של איבוד קשר עם המציאות המשתנה תמידית ג) לאחר שה-PM פיתח spec מפואר כזה הוא עלול להקשר אליו ולהתנגד לשינויים ד) בסופו של דבר אף-אחד לא מוכן לקרוא 120 עמודים של spec (תסמונת מבקר המדינה). המפתחים יהנהנו בראשם בהערכה להישג הספרותי המרשים וילכו לפתח מה שנראה להם.
עדיף בעיני להשתמש במסמכים ותהליכים שהם lighweight, ו-just-in-time כדוגמת אלה שמומלצים בשיטות Agile תוך הקפדה על תקשורת אפקטיבית. עדיף להתחיל בקטן (פרוטוטייפ) ולהגדיל על בסיס הנסיון המצטבר במקום לאפיין מראש את הכל.
הערה: כל ארגון תכנה הוא שונה ויכול להיות שלחלק מהארגונים (במיוחד היותר גדולים ופחות דינמיים) הדברים שכתבתי אינם מתאימים.
תובל - בררתי עוד קצת והנה שתי הפניות נוספות לגבי agile בארץ הקודש:
רועי אושרוב כותב בלוג מצויין ובפרט על agile - http://weblogs.asp.net/rosherove/default.aspx
Rothman Consulting Group - מתמחים בנושא ומדי פעם מעבירים סמינר בארץ. שמעתי שהאחרון שהתקיים במרכז לפני מספר חודשים היה ממש מוצלח
מקווה שעזרתי,
תודה.
תובל - אני יודע שמיקרוסופט ישראל ארגנה כנסים בעבר שעסקו ב-agile. המוצר החדש שלהם לפיתוח - Visual Studio Team System - מאפשר עבודה ב-MSF for agile) agile) לכן אני מניח שיש ידע טוב בנושא גם אצל השותפים העסקיים שלהם שעוסקים בהדרכות והטמעות. אני לא מודע לגוף אחד שמוביל את הנושא בארץ היום... למה לא תריץ שאלה בקהילת המו"פ?