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

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

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

1. עבודה על בעיות חדשות בלי מספיק ידע על הבעיה או על הכלים. אלה מתכנתי ה PHP שעכשיו צריכים לכתוב אפליקציית Front End בריאקט. כשהכל חדש ההתקדמות איטית יותר והרבה פעמים בכיוון הלא נכון.

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

3. עבודה על פיצ'רים גדולים מדי עבור המוצר במצבו הנוכחי (וכן ברור לי שמנהלי המוצר שמאפיינים את הפיצ'רים לא מרגישים שאלה פיצ'רים גדולים מדי).

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

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