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

הקו, ולמה שם

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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