Posts tagged ‘ארגון’

צוותי פיצ’ר – Feature teams

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

component_teamרוב הארגונים שאני פוגש עדיין עובדים במבנה צוותים שמבוסס על מודול או קומפוננט. המונח המקצועי הוא Component team.
כלומר, במצב שבו יש מספר קומפוננטות במערכת, למשל: GUI, BL, SERVER, INFRA אז כל צוות הוא מומחה בקומפוננט מסוים. קלאסי.

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

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

נתחיל מדף חלק – יום 0 של הפרויקט.
יש לנו רשימת פיצ’רים לגירסה הקרובה, חמישה במספר. הפיצ’רים הללו לא דורשים רמת מאמץ זהה מכל הצוותים, יש פיצ’רים שדורשים יותר עבודה ב-Gui ויש כאלה שיותר עבודה ב- Server וכו’. הנה דוגמא: הטבלה מציגה עבור כל פיצ’ר את התפלגות המאמץ באחוזים לפי מודול.

מספר פיצ’ר A B C D
1 20 30 50 0
2 40 20 0 40
3 0 80 20 0
4 50 0 50 0
5 20 0 70 10

component_team_pie ובואו נניח לשם הפשטות שכל אחד מהפיצ’רים דורש את אותה כמות מאמץ כוללת. למשל כל פיצ’ר ברשימה הוא חודש.
יוצא שאין איזון בין הצוותים בכמות המאמץ הנדרשת לגירסא. מה זה אומר?
שיהיו צוותים מאוד עמוסים ויהיו צוותים מאוד פנויים. שיהיו צוותים שיהפכו לצוואר בקבוק, ויהיו צוותים שיהפכו למטרד.
מה עושים אירגונים במצב הזה? בד”כ או שהם משנים את מבנה הצוותים (שוב…) או שהם ממציאים עבודה לצוותים המובטלים כגון משימות שכתוב מחדש של הבאגים או אולי לסייד את הקירות :) או שהם פשוט משנים את כמות כח האדם, או במילים אחרות: מפטרים ומגייסים.

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

מה האפשרות שרוב הארגונים לא שוקלים (אולי כי הם לא מכירים אותה) לשנות את המבנה של הצוותים כך שלא יהיה מאורגן לפי מודולים אלא לפי איזורים פונקציונאליים, או כפי שקוראים למבנה הזה בשפה המקצועית: צוותי פיצ’ר -  Feature teams.

צוותי פיצ’ר הם צוותים שלא מסודרים לפי התמחות של מודול אלא לפי התמחות של איזור פונקציונאלי, לדוגמא: צוות Security, צוות דוחות, צוות ניהול פריטים וצוות אדמיניסטרציה,כשכל צוות בעצם מפתח התמחות באיזור פונקציונאלי מסוים ולא באיזור טכני מסוים, רגע…בעצם  אני מניח שלמרות שהצוות של הדוחות למשל “נוגע” בכל המודולים, ברוב הפעמים הוא נוגע באותם איזורים בקוד, כלומר בכל זאת ישנה התמקדות טכנית מסוימת.

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

באופן אישי אני לא מצליח להבין ארגונים שלא רוצים לעבוד למבנה כזה, אבל, זה לא הדבר היחיד שאני לא מבין… :)

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

לשבור את הקיר

clip_image002[4]

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

אז בואו נתן דוגמאות לכמה קירות כאלה באירגונים חלקם פיזיים וחלקם וירטואלים:

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

הקיר שמעליו זורקים את המסמכים מגורם אחד לשני:
זהו קיר וירטואלי בעיקר והוא נוצר בד”כ clip_image004[4]בעקבות מבנה ארגוני והגדרות תפקידים, קיר זה מייצר בעיה דומה לבעיית הקיר הפיזי ו”תורם” לאי הבנות. בנוסף הקיר הזה מאופיין בעוד משהו: התנערות מאחריות – כשאני מקבל מסמך ומממש אותו למיטב הבנתי, אז לכל בעיה שנוצרה אני תמיד יכול להאשים את המסמך או את מי שכתב אותו, כאשר כותב המסמך ואני עובדים יחד, אזיי שנינו אחראים באותה המידה ומחויבים להצלחת המשימה כולה ולא רק “לחלק שלי במשימה”. דוגמאות קלאסיות הן מסמכי בדיקות, מסמכי ארכיטקטורה וכו’.
איך לשבור? להכניס את הבודקים, הארכיטקטים, מהנדסי המערכת וכו’ לתוך הצוותים.

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

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