Posts tagged ‘פשטות’

כלים אג’ילים – יש דבר כזה?

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

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

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

נסקור את הסיבות לשימוש ב”כלים אג’ילים” שאני נתקל בהן:

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

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

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

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

עקרון חשוב ומנחה במניפסט האג’ילי (עקרון 5) הוא:

Build projects around motivated individuals, give the environment and the tools they need, and trust them to get the job done.

עקרון נוסף חשוב (עקרון 11) הוא:

The best architectures, requirements and design emerge from self-organizing teams

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

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

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

לסיום אני רוצה לצטט משפט מתוך ספר של בס וודה וקרייג לרמן:
If you automate a mess, you will get an automated mess.

ספרינט בקלוג – Smells

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

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

בפוסט הזה אני הולך לדבר על ריחות של ספרינט בקלוג – Sprint backlog smells .

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

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

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

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

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

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

צבעוני מידי – בהפוך לקודם גם לא כדאי שהוא יהיה צבעוני מידי, למה אני מתכוון? ראיתי כבר בקלוגים שלכל סוג משימה (בדיקות, תיעוד, קידוד, DB וכדו’) יש צבע פתק מיוחד, זה יכול להצביע על בעיה פוטנציאלית בצורת העבודה של הצוות, ואף עלול להצביע על ריכוזיות בתוך הצוות, כאשר כל חבר צוות “יודע” איזה צבע מעניין אותו.
בנוסף, זה עלול להעיד על Mini-Waterfall בתוך הספרינט.

פתקים “ברוורס” – אם רואים לעיתים קרובות מידי פתקים עושים “פניית פרסה” וחוזרים מעמודת “Done” לעמודת “In work”, זה עלול להעיד אולי על בעיתיות בהשלמת המשימות, ואולי על בעיה בהגדרת המשימות עצמן.

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

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

חבל על הזמן…

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

יום שני 11:00 – ישיבת הנהלה הכירה:
המנכ”ל גדי מברך את כולם ביום טוב וסוקר את הפעילויות הצפויות לחברה בעתיד הקרוב, לקוחות פוטנציאלים ועוד מספר עניינים אדמיניסטרטיביים, גדי מזכיר לכולם שהחברה החליטה לעבור לגישות אג’יליות ורזות יותר, “השינויים שאנחנו עושים הם חשובים, הם נוגעים לחלקכם, ויש להקדיש זמן ליועץ שהבאנו ולהתייחס בכובד ראש לדברים” הוא אומר, “מסכנים הפיתוח“ אומרת דליה סמנכלית השיווק, גדי מחייך.
אחד כך עובר גדי לסבב הרגיל של דיווחי סטטוס:
image– שירה, סמנכ”לית פיתוח, מסתכלת על גדי ומספרת על מצב הפרויקטים, הבעיות, ואף מציינת שכבר שני צוותים עברו לפיתוח “בשיטת סקראם” שזה הטרנד החם כרגע בעולם תהליכי פיתוח התוכנה האג’ילים, “יופי, איך הולך?” שאל גדי, “אנחנו מנסים את זה, גם דיברנו עם היועץ שיעזור לנו, אני מאמינה שזה יכול לקצר משמעותית זמני פיתוח ולהגביר את האיכות”, מעולה! אומר גדי תעדכני אותי כשיהיו מסקנות.
– אחרי שירה דיבר יניב, סמנכ”ל HR, הוא סיפר לכולם שעקב חוסר תקציב אין יום כיף השנה, וגם כנראה לא יהיו בונוסים. בנוסף הוא הזכיר שיש למלא את הערכות העובדים עד סוף השבוע ולקבוע יעדים אישיים חדשים לשנה הבאה, “ולא לשכוח לנרמל את התוצאות ברמת הצוות, והמחלקה”, כולם מהנהנים.
– לבסוף מדבר אורן, סמנכ”ל תפעול, הוא טוען שהוא גילה לאחרונה שלקוחות יוצרים קשר עם אנשי פיתוח ולהיפך “זו תופעה חמורה ואנחנו חייבים לנתק את הקשר הזה”, כולם מהנהנים בהסכמה.
– דליה סמנכ”לית שיווק, מעלה בתורה את הבעיה שאנו לא עומדים בזמנים שהבטחנו ללקוח, ומעבר לכך יש לנו בעיה קשה עם לקוח X, יש כרגע מספר בעיות קריטיות וחייבים לפתור לו את הבעיות, ומהר. גדי (המנכ”ל) מסתכל על שירה, שירה אומרת שהם עושים את המקסימום והמפתחים כבר באו 3 סופי שבוע אחרונים בכדי לנסות להדביק את הפער, “והשבוע עוד מפתח עוזב, באמת שאנחנו עושים את המקסימום.”, “את צריכה לשמור על האנשי שלך יותר טוב” אומר גדי בחצי חיוך חצי רצינות. “אני מאמינה שעד סוף הגירסה נצליח להשלים את הפער” אומרת שירה. השיחה ממשיכה עוד קצת ואז תם הזמן לישיבה.
– “טוב, שבוע טוב לכולם” אומר גדי. שבוע טוב, הם עונים לו.

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

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

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

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

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

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

נ.ב.
אחרי שקראתי את הפוסט הבנתי שעקב ריבוי הדמויות והמידע (יחסית לרמת הפירוט) אפשר לפרש את הישיבה בכל מיני צורות וצבעים, כוונתי היתה הפשט, בבקשה אל תניחו הנחות אלא התבססו על העובדות.
ואולי אכתוב עוד אחד כזה על ישיבת R&D…. אולי.

לשבור את הקיר

clip_image002[4]

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

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

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

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

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

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

מכתב פתוח לדוד בוב

בוב היקר,

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

אתייחס כעת לעל אחת מהנקודות שהעלית:

1. חוסר בטכניקות טכניות – אתה צודק, וזה ידוע לרוב שסקראם, בניגוד למשל ל-XP אינו מציין באיזה טכניקות או שיטות יש להשתמש כשמפתחים תוכנה, ולטעמי לא סתם: לו היה סקראם מגדיר באיזה שיטות לעבוד כשמפתחים תוכנה הרי היה גורלו להפוך לא רלוונטי כעבור פרק זמן מסויים, וכידוע לנו, תחום התוכנה הוא דינאמי ומשתנה. כאשר צוותים היום בוחרים לעבוד בסקראם הם בד”כ משתמשים בשיטות כגון CI, Pair programming, TDD וכו’ מכיוון שאלה דברים שנכון להיום אנו יודעים שהם עובדים, אבל מה יהיה עוד 10 שנים, האם עדיין אותן שיטות יהיו רלוונטיות ? אז ממש כמו ה-Agile Manifesto שאתה מהיוזמים שלו, לא צוינו פרטים טכניים בכדי לשמר אותו לאורך זמן, כך גם סקראם, ואני רואה בכך יתרון.

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

3. מסכים בהחלט – לא מומלץ ואף גורם נזק בד”כ כשהסקראם מסטר הוא גם מנהל פרויקט. אבל זה לא חסרון של סקראם.

4. מסכים! מסכים! מסכים! אבל גם זה לא חסרון של סקראם אלא של הארגון שמפיץ אותו, היה נפלא לו היינו נפתרים מה-“Certified” לאלתר.

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

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

7. זו הנקודה היחידה שאני נוטה להסכים איתך, יש מקום (אם כי לא חובה) לציין כי Continuous integration צריך להיות חלק מהשיטה.

8. צוותים מרובים או “סקראם בגדול” היא באמת שאלה פתוחה ואני לא חושב שמישהו עדיין מצא אחת גלובאלית להתמודד עם השאלה, לטעמי האישי הרעיונות של Bas Vodde ו-Craig Larman הם טובים, אך גם הם לא מתאימים לכל מקום כמו כפפה ליד, הנושא של פיתוח בסדר גודל גדול הוא נושא כנראה סבוך מידי ואין פתרון אחד (ממש כמו התפיסה האג’ילית – One size does not fit all)

זוהי תשובתי מלאת ההערכה אלייך דוד בוב (Robert C Martin).

אלעד.

איך לעודד ביצוע משימות “לא נעימות” ?

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


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

ישיבות או לא להיות

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

clip_image002באופן קלאסי ישיבה מתחלקת לשלושה חלקים:

– הכנת השטח.
– איסוף נתונים
– עיבוד הנתונים.

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

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

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

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

י יש ישי ישיב ישיבו ישיבות

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

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

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

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

פיתוח תוכנה רזה – Lean software development.

כפי שכבר הזכרתי בעבר אחד המקורות של אג’יל (agile) וסקראם (Scrum) הוא עולם ה-Lean שמגיע בעיקר מיצרניות יפניות (טויוטה בפרט).

ליפנים יש תפיסת עולם מאוד ייחודית (ובעבר גם מהפכנית) בנוגע לתהליכי ייצור ופיתוח, התפיסה הזו הייתה גורם משפיע מאוד, בין השאר הגישה של הזו הייתה השראה למאמר של טקוצ’י וננקה (Hirotaka Takeuchi, Ikujiro Nonaka) שנקרא – The New New Product Development Game, המאמר הזה הוא זה שהתחיל את המהפכה, זה שגרם לשיטת הסקראם להתפתח, ונחשב ע”פ רוב ל”ניצוץ שהדליק את האש”.

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

clip_image002 בשנת 2003 פרסמו מרי וטום פופנדיק את הספרLean Software Development: An Agile Toolkit, הספר למעשה שופך אור על הנושא ומציג באופן פורמאלי אנלוגיה בין עולם הייצור והפיתוח הרזה לבין עולם פיתוח התוכנה, הספר מציע איך לתרגם את הערכים והתפיסות מעולם הפיתוחייצור הרזה לעולם פיתוח התוכנה, ואם יורשה לי, הוא עושה את זה בצורה יוצאת מין הכלל.

עקרונות העבודה בעולם ה-Lean עברו טרנספורמציה קלה לטובת התאמה לפיתוח תוכנה ואסקור אותם כעת:

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

עקרון 2 – לבנות את האיכות מבפנים – Build quality in:
המשמעות של לבנות את האיכות מבפנים היא להחליף תהליכים של איתור בעיות בדיעבד, לתהליכים שמונעים טעויות מראש,כבר כתבתי על כך פוסט ולכן לא ארחיב כעת.

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

עקרון 4 – דחה התחייבויות – Defer commitment:
תחילה הבהרה, משמעות המילה דחה כאן היא לא דחייה לתמיד (reject), אלא דחייה בזמן.
אנשים שמתמודדים עם מצבי חירום כגון טייסים, כבאים רופאים וכו’ כבר מזמן למדו שהחלטות בלתי הפיכות מקבלים ברגע האחרון האפשרי, לא אחרי שמאוחר מידי, אלא ממש לפני. למה ? כי ככל שנדחה את ההחלטה לזמן מאוחר יותר כך יהיה לנו יותר ידע ע”מ להחליט. בפיתוח איטרטיבי זה למעשה מתבצע הלכה למעשה כאשר אנו בכל איטרציה מבצעים את המשימות בעלות הערך הרב ביותר שאנו יודעים עליהן בתחילת האיטרציה, ואת ההחלטה מקבלים ממש בתחילת האיטרציה ולא דקה לפני.

עקרון 5 – ספק תוצאות, ומהר – Deliver fast:
העיקרון הזה טוען שככל שתצליחו לספק מוצר מהר יותר, גם אם הוא חלקי, תוכלו לקבל פידבק אמיתי מהר יותר וע”י כך לבצע את ההתאמות הנכונות למוצר. לפעמים אפילו תופתעו ותבינו שמה שסיפקתם עונה על צרכי השוקלקוח. בנוסף, אם נשאף לספק תוצאות ומהר נייצר יתרון תחרותי. למען הסר ספק – כל האמור לא על חשבון איכותו של המוצר (אם השליח של המכולת היה מגיע תוך 10 דקות אבל עם מוצרים מקולקלים, אז המהירות לא הייתה מהווה יתרון בכל מקרה).

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

עקרון 7 – ייעול של הכלל – Optimize the whole:
אני יודע שהתרגום לא מוצלח (אם יש לכם רעיונות, אני אשמח), אבל המשמעות היא פשוטה: כשמייעלים משהו בארגוןתהליךיחידה וכו’ יש להתבונן על הכל ולא על הפינה שלכם, שמנסים לייעל חלק קטן ממכונה גדולה בד”כ נוצרות בעיות חדשות מהתועלת שקיבלנו בפתרון המקומי. בעיות כאלה מתגלות בצורה של צווארי בקבוק, בעיות ממשקים,

תשטויות

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

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

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

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

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

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

clip_image002

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

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

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