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

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

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

1. יש רק מתכנת אחד שיודע לגעת בחלק מסוים (וקריטי) במערכת.

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

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

2. הניהול מושפע מפוליטיקה וממה צריך לספר לבוסים במקום מה יהיה טוב למוצר.

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

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

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

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

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

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

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

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