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

אני מאמין בחוק פארטו בריבוע. הרעיון הוא לעשות 20% ועוד 20% מתוך ה 80% שלא עשינו. בחישוב פשוט, אנחנו משקיעים 36% (20 + 20%*80) ומקבלים 96% (80+ 80%*20). זה כבר הישג יפה מאד בהשקעה נמוכה יחסית.

לגישה זו יש יישום בתחומים רבים (בעסקים ובחיים). בניהול פיתוח יש לה לפחות שני יישומים:

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

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

רעיון פשוט, יישום פשוט, תוצאות יפות.

כשמדובר בפיתוח של מוצר העסק קצת יותר מורכב.

ראיתי את זה בהמון פרויקטים שבהם הייתי מעורב. זה מתחיל בהגדרת מוצר ואז משקיעים 20% ומקבלים 80% תשתית. כשיש תשתית אתה עושה 20% ומקבל 80% מהאפליקציה על 80% תשתית.

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

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

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

כמובן שעכשיו הלחץ גדול ואין מצב שתעשה יותר מ 20% הדרושים כדי להשיג 80% ממה שאתה נדרש להשיג...

80% זה לא רע.

צטט: דביר זהר 2008-11-11 19:21:09

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

מהנסיון האישי שלי זה לא עובד.

X מאמץ - 80% תפוקה

2X מאמץ - 90% תפוקה

3X מאמץ - 95% תפוקה.

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

לפחות זה מה שהיה לי בלימודים, ובאיזה פסאודו ניסוי שערכתי בעבודת QA שעשיתי לפני הרבה שנים כששמעתי על העקרון הזה לראשונה ורציתי לבדוק אותו (שם מדדתי את התפוקה במספר use cases מוצלחים ואת המאמץ בזמן).

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

כשמדובר בתשתית אני מנסה להגיע קרוב ל 100% (כדי להמנע מהאפקט הגאמטרי שעליו דיברתי) וזה בדרך כלל דורש הרבה יותר מכפול מ"מינימום המאמץ שנדרש בשביל לקבל תפוקה סבירה".

תנסו לא להסתכל על התשומות. ברור שבשליש מאמץ לא תצליחו להגיע ל 95% מהעבודה. הרעיון הוא להגיע ל 95% מהתפקות החשובות.

תבדקו אם הייתם מגדירים את הבדיקות כך ששליש מתוכן מביא למציאת 95% מהבאגים הבאמת חשובים.

נסו להגדיר את הפיתוח כך שבשליש מאמץ תגיעו ללקוחות שיביאו 95% מההכנסות.

זה הרעיון (הוא מצריך קצת זמן להתרגל אליו).

צטט: דביר זהר 2008-11-12 21:15:39

תנסו לא להסתכל על התשומות. ברור שבשליש מאמץ לא תצליחו להגיע ל 95% מהעבודה. הרעיון הוא להגיע ל 95% מהתפקות החשובות.

תבדקו אם הייתם מגדירים את הבדיקות כך ששליש מתוכן מביא למציאת 95% מהבאגים הבאמת חשובים.

נסו להגדיר את הפיתוח כך שבשליש מאמץ תגיעו ללקוחות שיביאו 95% מההכנסות.

זה הרעיון (הוא מצריך קצת זמן להתרגל אליו).

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

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

שכן יקר,

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

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

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

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

אני תומך בגישתו של דביר ועקרון ה-פרטו בריבוע בתחומי הפיתוח.

אולם, הפרטו נכון לדעתי לכל תחומי חיינו ומהוה למעשה "מסננת"

שמקפת לנו היכן כדאי להתמקד,ממה כדאי להפרד ובכל ניצול נכון

יותר של המשאבים העומדים לרשותנו.

ב-20% מכח היצור/ביצוע, אנו משיגים 80% מהרווח.

                      או

את 20% מהרווח אנו מפיקים ב- 80% מכח הייצור/הביצוע.

סיכום:

כלי פשוט שבעזרתו ניתן לעשות חשבון או מאזן היכן לשפר,

היכן לתגבר וממה אולי כדאי להפרד.

                                                        בברכה,

                                                          משה

                              benjamin.moshe@gmail.com

צטט: דביר זהר 2008-11-25 12:33:21

חוק פארטו בריבוע בניהול הפיתוח

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

אני מאמין בחוק פארטו בריבוע. הרעיון הוא לעשות 20% ועוד 20% מתוך ה 80% שלא עשינו. בחישוב פשוט, אנחנו משקיעים 36% (20 + 20%*80) ומקבלים 96% (80+ 80%*20). זה כבר הישג יפה מאד בהשקעה נמוכה יחסית.

לגישה זו יש יישום בתחומים רבים (בעסקים ובחיים). בניהול פיתוח יש לה לפחות שני יישומים:

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

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

רעיון פשוט, יישום פשוט, תוצאות יפות.

 

הרעיון יפה - למרות זאת לדעתי במקרים מסוימים קשה לישם אותו:

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

דבר נוסף הוא כמו שכתב השכן ממול הוא האפקט הגאמטרי שבו אם יש לנו תשתית שהיא 90% ואימפלמנטציה שהיא 90% בסופו של דבר נקבל 81% - לדעתי ניתן להרחיב את האפקט ולומר שכל בעיה בשלב פיתוח מחלחלת לשלבים שאח"כ כלומר צריך לחשב - איפיון * תיכנון * קידוד כך שהאפקט הגאומטרי יותר משמעותי. נקודה נוספת באפקט הגאמטרי היא שאם יש לנו תהליך שעובר ב5 מודולים שונים וכולם עם 96% צריך לחשב 96% בחזקת 5 כך שלדעתי האפקט הגאומטרי במערכות גדולות משמעותי ביותר.

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

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