סליחה, אבל למה תמיד כשמדברים על הנושא הכאוב הזה, הדיון מגיע לכלים ולא למהות?

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

נראה טריוויאלי?

אולי, אבל מעולם לא נתקלתי שמנהל המוצר, צוות ניהול המוצר, או מי שזה לא יהיה שאחראי על הנושא הזה, ניסחו דרישות בצורה כזו. בדרך כלל זה מנוסח, אם בכלל, בצורה מעורפלת, מלאת buzz-words, וקשה לעיקוב, וברוב המקרים זה בא לכסות על חוסר התחייבות מנהלית על מה בעצם הולכים לפתח, והנטייה לרוץ קדימה ו-"יהיה בסדר".

כמה מקרים שמעתם: המוצר שלנו עושה ככה ועושה ככה, ויכול לעשות גם ככה, ואם רוצים ממש, אז נקנפג אותו שיידע לעשות גם ככה.... ??

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

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

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

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

ברור שאף כלי אינו תחליף לשיקול דעת מקצועי בהגדרת הדרישות. הכלי יכול רק לעזור לאנשי המקצוע.

יש גם פרוייקטים שבהם מסמכי הדרישות הם חלק מה- deliverables (למשל פרוייקטים רפואיים שצריכים לעבור FDA).

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

צטט: ziverez 2010-03-08 21:34:58

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

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

ברור שאף כלי אינו תחליף לשיקול דעת מקצועי בהגדרת הדרישות. הכלי יכול רק לעזור לאנשי המקצוע.

יש גם פרוייקטים שבהם מסמכי הדרישות הם חלק מה- deliverables (למשל פרוייקטים רפואיים שצריכים לעבור FDA).

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

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

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

לא פוסל את הכלים, אבל גם יודע טוב מאד שלא הם קובעים את האיכות, זה הכל.

לא פוסל את הכלים, אבל גם יודע טוב מאד שלא הם קובעים את האיכות, זה הכל.

צודק ב- 100% : האנשים קובעים את המהות, לא הכלים.

כלים מתאימים יכולים רק לסייע, והחכמה תמיד היא להבחין בין מטרה לאמצעי.

אני לא יודע אם פתקים על המקרר הוא הפתרון המובחר. אבל אני מאוד מסכים שהאנשים והתרבות חשובים הרבה יותר מהכלי.

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

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