עבודה מול בית תוכנה: איך בונים תקשורת שמונעת הפתעות

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

למה צוות טוב מספק תוצאות גרועות

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

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

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

מערך התקשורת שעובד

אחרי יותר מ-200 פרויקטים עם חברות של 20 עובדים ועד חברות של 20,000, למדנו שהכלים עצמם פחות חשובים. מה שחשוב הוא ערוצים ברורים, ולכל ערוץ תפקיד ברור.

תקשורת בכתב (השוטף היומי)

הטעות הכי נפוצה שאנחנו רואים: להשתמש ב-Slack לכל דבר. החלטות קריטיות נקברות בשרשורים. דיווחי באגים נעלמים בהיסטוריה. מי שלא היה מחובר ב-15:00 פשוט לא יראה את ההחלטה שהתקבלה בשרשור ב-15:00.

כלל אצבע: שיחה שנגמרת בהחלטה צריכה להירשם בכלי ניהול הפרויקטים או במייל. ב-Slack מגיעים להחלטה. ב-Jira רושמים אותה.

פגישות

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

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

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

אזורי זמן: האתגר האמיתי

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

הפרש של שעה עד 3 שעות (למשל ישראל ומערב אירופה): כמעט לא מורגש. קבעו פגישות בחלון המשותף, וכל השאר בכתב.

הפרש של 4 עד 7 שעות (למשל ישראל והחוף המזרחי בארה״ב): יהיה לכם חלון משותף של 3 עד 4 שעות. רכזו בו את כל הפגישות, והניחו שכל השאר יקרה בכתב. אחר הצהריים בישראל חופף לבוקר בארה״ב, ובחלון הזה מתקבלות לא פעם ההחלטות הקריטיות.

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

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

מסלול ההסלמה שכולם שוכחים

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

הגדירו אותה לפני שהפרויקט מתחיל:

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

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

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

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

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

חמישה הרגלים שמונעים את רוב הבעיות

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

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

2. בשורות רעות עוברות מהר. הכלל: מדווחים על בעיות לפחות באותה מהירות שמדווחים על הצלחות. אם הצוות מציג פיצ׳ר גמור מיד, גם דדליין שהוחמץ צריך להגיע ללקוח באותה מהירות.

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

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

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

הפכו את הצוות החיצוני לחלק מהצוות שלכם

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

1. תנו גישה לערוצים האמיתיים. צרפו את המפתחים של בית התוכנה לערוצי ה-Slack שבהם הצוות הפנימי מקבל החלטות. ערוץ נפרד "לספקים" אומר שהם ישמעו על שינויים באיחור.

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

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

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

5. שמרו על הרכב יציב. מי שמחליף מפתחים כל כמה חודשים זורק ידע על המוצר. מפתח שעובד על המוצר שלכם 18 חודשים מחזיק הקשר שאין למי שרק הגיע.

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

גבולות תקציב לעבודה ב-Agile

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

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

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

שכבות היקף. בתחילת הפרויקט מסווגים כל פיצ׳ר לאחת משלוש שכבות:

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

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

שאלות נפוצות

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

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

עם אילו כלים Globalbit עובדת? בדרך כלל אנחנו מקימים Jira או Linear לניהול הפרויקט, Slack או Teams לתקשורת השוטפת (אנחנו מצטרפים לסביבה של הלקוח), ו-Figma לעבודה משותפת על העיצוב. אבל אנחנו מתאימים את עצמנו למה שהלקוח כבר עובד איתו. להעביר את הצוות שלכם לכלים שבית התוכנה מעדיף כמעט אף פעם לא עובד. ההפך קל יותר.

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

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

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

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

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