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

הקו, ולמה שם

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

המדידה שקודמת לגיוס

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

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

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

מה חייב להיות מוכן ביום הראשון

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

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

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

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

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

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

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

סקירת קוד כגבול, ולא כפקק

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

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

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

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

איך מודדים שזה עבד

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

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

איך אני עובד על זה

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

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