כשה-AI כותב את הקוד, מי מחזיק את הצוות?
הכלים משתנים, הציפיות עולות, וראשי הצוותים נשארים באמצע. דווקא עכשיו, היחסים בין אנשים נעשים חלק חשוב יותר מהעבודה.
יש רגע שבו כולם מסתכלים על ראש הצוות ומחכים לתשובה. ההנהלה רוצה לדעת מתי המוצר יעלה לאוויר. המפתחים רוצים להבין מה מצופה מהם עכשיו. הלקוח שמע שעם AI אפשר לפתח הרבה יותר מהר, ומנסה להבין למה הפרויקט עדיין לא הסתיים.
וראש הצוות? גם הוא מנסה להבין את המציאות החדשה.
הרבה נכתב על השינוי בעבודה של מפתחים: יצירת קוד, סוכנים, בדיקות, כלים שמתחלפים בקצב שקשה לעקוב אחריו. פחות מדברים על מי שצריך לחבר את כל זה לצוות שעובד יחד, למוצר שאפשר לסמוך עליו ולהבטחות שאפשר לקיים.
הלחץ הזה מתבטא בדילמות יומיומיות של ראשי צוותים. מאחורי הדילמות הטכנולוגיות עוברת שאלה אנושית: על מה נשענים כשהניסיון הקודם כבר לא מספק את כל התשובות?
המחשבה שמלווה את הטקסט הזה פשוטה: ככל שיותר משימות נעשות אוטומטיות, כך יש יותר סיבה להשקיע במה שמאפשר לאנשים לעבוד יחד. לא כי הטכנולוגיה מפסיקה להיות חשובה, אלא כי היא אינה פותרת בעצמה פחד, חוסר אמון או ציפיות סותרות.
בתוך הצוות: הכלים משתנים, האנשים לא מתחלפים בלחיצת כפתור
1. איך מעריכים זמן כשהדרך משתנה בכל פעם?
בעבר היה לראש הצוות בסיס מוכר להערכת משימה. מכירים את המפתח, מבינים את המורכבות, מסתכלים על משימות קודמות ומשאירים מרווח לבעיות. זה לא היה מדע מדויק, אבל היה על מה להישען.
עכשיו AI יכול לייצר פתרון ראשוני במהירות מפתיעה, ובמשימה הבאה לדרוש סבבים ארוכים של תיקונים. המודל משתנה, ההקשר משתנה, וגם הדרך שבה כל מפתח עובד איתו משתנה. קשה יותר לדעת מראש כמה זמן יידרש כדי לעבור ממשהו שנראה עובד לפתרון שבאמת מוכן לשימוש.
יש הבדל בין הזמן שלקח לייצר קוד לבין הזמן שצריך כדי להבין אותו, לבדוק אותו ולקחת עליו אחריות. את ההבדל הזה מישהו צריך להסביר.
2. את מי מגייסים, ואיך יודעים מה הוא באמת יודע?
ראיונות פיתוח נשענו במשך שנים על כתיבת קוד, פתרון בעיות והיכרות עם כלים וספריות. אלה עדיין יכולים ללמד משהו, אבל התמונה מסתבכת כשמועמד רגיל לעבוד עם AI כחלק בלתי נפרד מהתהליך.
ביצוע חלש בכתיבה ידנית לא בהכרח אומר שהמועמד לא יכול לפתח היטב בעזרת הכלים שלו. מצד שני, פלט מרשים של מודל לא מוכיח שהוא יודע לזהות טעות, להסביר החלטה או להתמודד עם תקלה.
גם האמירה שצריך לבדוק רק חשיבה ארכיטקטונית אינה פותרת הכול. עדיין צריך אנשים שמבינים פרטים, ביצועים ומגבלות. השאלה הקשה היא איך להבחין בין מי שמקבל תשובות טובות לבין מי שמבין מתי התשובות אינן טובות מספיק.
3. יותר קוד, אבל מי מבין את המערכת?
אפשר לבקש מסוכן אחד לבדוק את העבודה של אחר. אפשר לייצר עוד בדיקות. אלה כלים שימושיים, אבל הם אינם תשובה מלאה לשאלה מי מבין את המערכת ומי מסוגל להסביר למה היא אמורה לעבוד.
כאן מצטבר חוב שקל לפספס: פער בין מה שהמערכת עושה לבין מה שהצוות מבין עליה. כל עוד הכול עובד, אפשר לדחות את השאלות. כשמשהו נשבר, הלקוח צריך פתרון, לא הסבר שהמודל כתב את הקוד.
גם לפני AI היה קוד בעייתי. ההבדל האפשרי הוא בקצב שבו אפשר להוסיף רכיבים שההבנה שלהם עדיין לא הספיקה להיבנות.
4. לכל אחד יש כלי משלו, ולכל כלי יש מישהו שמאמין בו
מפתח מזהה צורך ובונה כלי פנימי. מפתחת אחרת בונה פתרון אחר לאותה בעיה. שניהם השקיעו, שניהם רוצים לעזור, ולכל אחד יש סיבות טובות להעדיף את מה שיצר.
כשקל יותר לבנות, לא בהכרח קל יותר להגיע להסכמה. ראש הצוות צריך לבחור מה ישרת את כולם לאורך זמן: מי יתחזק, מה יקרה כשאותו אדם יעזוב, ואיך הכלי ישתלב בשאר המערכת.
זו החלטה טכנולוגית שיש בה גם יחסים. אפשר לקבל החלטה ניהולית נכונה ולדחות פתרון, ובדרך לפגוע במוטיבציה של מי שניסה לתרום. צריך לדעת לעשות את שני הדברים: להחליט ולהישאר בקשר.
5. הציפייה השתנתה. האדם שמולנו נשאר אותו אדם
יש פיתוי לדמיין עובד חדש שמסוגל לעשות הכול: לדבר עם העסק, לאפיין, לתכנן, לפתח, לבדוק ולדאוג לתוצאה. אם ה-AI עוזר בכל שלב, למה שלא ירכז את הכול אדם אחד?
אבל בצוותים עובדים אנשים שונים. יש מי שמצטיינים דווקא בהתעמקות, מי שזקוקים לרצף ולשקט, ומי שחושבים היטב על בעיה לפני שהם מדברים עליה. אלה לא תכונות שנעלמות כשנכנס כלי חדש.
אפשר ללמוד ולהתפתח. קשה יותר להפוך ביום אחד לאדם שהמצגת הארגונית מדמיינת. בין הציפייה הזו לבין האנשים הקיימים עומד ראש הצוות.
6. איך בונים מעורבות כשאנשים לא בטוחים בעתיד שלהם?
קשה לבקש ממישהו להשקיע את כל הלב בעבודה כשהוא תוהה אם התפקיד שלו יהיה קיים בעוד שנה. גם בלי לדעת מה יקרה בפועל, חוסר הוודאות יכול להשפיע על תחושת השייכות ועל הרצון להתאמץ.
לראש הצוות אין תמיד תשובה מרגיעה. הוא לא יודע בדיוק איך ייראה השוק או מה תחליט ההנהלה. הבטחה שהכול יישאר כפי שהיה עלולה להישמע חלולה.
ולפעמים זה החלק הקשה ביותר: להמשיך לעבוד יחד כשגם מי שאמור להוביל אינו מחזיק מפה מלאה. שיחה כנה אינה מעלימה את אי הוודאות, אבל היא מאפשרת לאדם שמולנו להרגיש שלא מתעלמים ממנה.
מול ההנהלה והלקוח: הקוד האיץ, הציפיות האיצו איתו
7. אם פיצ'ר נבנה מהר, למה שיפור המערכת עדיין לוקח זמן?
קל לראות פיצ'ר חדש. קשה יותר לראות את העבודה שמאפשרת להמשיך לפתח גם בחודש הבא: להבין תלות, לפשט מבנה, לשנות תכנון ולהקטין סיכון.
אם יצירת הפיצ'רים מתקצרת, הזמן שמוקדש לריפקטורינג נראה פתאום גדול יותר ביחס אליה. ההנהלה יכולה לשאול למה משימה אחת מסתיימת מהר, והשנייה עדיין דורשת דיון ועבודה יסודית.
זה לא אומר שריפקטורינג אינו יכול להיעזר ב-AI. זה אומר שהצורך להבין מה נכון לשנות ומה עלול להישבר לא נעלם. להסביר את ההבדל דורש אמון ושפה משותפת, לא רק הערכת שעות.
8. מה קורה כשהכלי שעליו התרגלנו להישען אינו זמין?
אפשר לדמיין תרחיש שבו הגישה למודלים נפסקת. אין צורך להתייחס לתרחיש הזה כנבואה כדי לזהות את השאלה הניהולית שבתוכו: עד כמה הצוות תלוי בספק חיצוני, ועד כמה הוא מסוגל להמשיך להבין ולתחזק את המוצר בלעדיו?
תקלה, שינוי בתנאי השירות או מגבלת גישה יכולים לשנות את אופן העבודה. אם המערכת כבר נשענת על יכולות שהצוות כמעט אינו מתרגל בעצמו, החזרה לאחור אינה בהכרח פשוטה.
האחריות להסביר את התלות הזו ולהיערך אליה נשארת בארגון. היא אינה עוברת לספק המודל יחד עם המנוי.
9. לכתוב מהר יותר זה לא בהכרח לספק ערך מהר יותר
נניח שהצוות הצליח לקצר מאוד את כתיבת הקוד. האם המוצר יגיע ללקוח באותו יחס של קיצור זמן? רק אם שאר התהליך מאפשר זאת.
אם ההחלטות מתעכבות, הדרישות משתנות, המכירות מבטיחות משהו אחר והאינטגרציה תלויה בצוות עמוס, צוואר הבקבוק פשוט עובר למקום אחר. יותר קוד יכול גם לייצר יותר עבודה בבדיקה, בתיאום ובתמיכה.
כשהציפייה הייתה לזינוק מיידי בכל העסק, ראש הצוות עלול למצוא את עצמו מסביר למה זה לא קרה. גם כאן, היכולת לדבר עם אנשים על מגבלות, תלות וציפיות היא חלק מהעבודה המקצועית.
יש אצלכם תהליך שחוזר על עצמו ונעשה ביד?
בשיחה של 30 דקות נבדוק יחד אם אפשר להעביר אותו לאוטומציה או ל-AI, ואיך ייראה השלב הראשון. ללא עלות וללא התחייבות.
ומה עם ראשי הצוותים עצמם?
10. אם כולם עובדים עם סוכנים, בשביל מה צריך ראש צוות?
זו שאלה שמפתה לשאול כשמסתכלים על הארגון כעל רשימה של משימות. אם כל מפתח יכול לעשות יותר, אולי אפשר לוותר על חלק משכבות הניהול.
בחלק מהארגונים אכן יש מקום לבחון מבנים ותפקידים מחדש. אבל תיאום, הכרעה במחלוקות, פיתוח אנשים ונשיאה באחריות אינם נעלמים רק משום שהקוד נכתב אחרת.
אפשר לשנות את הגדרת התפקיד. מסוכן יותר להניח שהעבודה האנושית שבתוכו הסתיימה, ולגלות מאוחר יותר שאיש אינו מחזיק בה.
11. גם הדרך חזרה לפיתוח כבר אינה אותה דרך
לראש צוות שהתעייף מניהול הייתה פעם אפשרות מוכרת: לחזור לתפקיד פיתוח בכיר. לא תמיד בקלות, אבל בתוך עולם מקצועי שהכיר.
היום, מי שהיה רחוק מעבודת הפיתוח השוטפת עשוי לגלות שהכלים והרגלי העבודה השתנו. הניסיון לא נמחק, אבל הוא אינו פוטר מהיכרות מעשית עם הדרך שבה עובדים כעת.
כשהתפקיד הנוכחי מעורר שאלות וגם מסלול החזרה פחות ברור, תחושת חוסר היציבות נעשית אישית מאוד.
12. אנשים שואלים לאן הולכים. לא תמיד יש תשובה
אחד התפקידים של ראש צוות הוא לחבר בין הכיוון של הארגון לבין העבודה היומיומית. לעזור לאנשים להבין לא רק מה לעשות, אלא גם למה.
אבל מה קורה כשההנהלה עצמה עדיין מנסה להבין את הכיוון? קל להעביר מטה את הציפייה ליוזמה ולחשיבה עסקית. קשה יותר לתת תשובה לעובד ששואל בשיחת אחד על אחד מה כדאי לו ללמוד ואיפה הוא עומד.
לא כל ראש צוות יכול או צריך לפתור בעצמו את האסטרטגיה של החברה. ובכל זאת, הוא זה שיושב מול האדם שמבקש בהירות. זה מקום שדורש הרבה יותר מהיכרות עם הכלים האחרונים.
13. צוואר הבקבוק כבר היה עמוס. עכשיו נוסף אליו עוד לחץ
בהרבה צוותים, שאלות והחלטות מגיעות בסוף לאותו אדם. הוא מכיר את הלקוח, זוכר למה התקבלה החלטה מסוימת, יודע למי קשה ומי מחכה לתשובה.
עכשיו מתווספים גם בחירת כלי AI, בדיקת התוצרים שלהם, הגדרת דרכי עבודה חדשות ותיווך הציפיות. אם האחריות נשארת מרוכזת והקצב עולה, גם העומס עלול לעלות.
אי אפשר לצפות מראש הצוות להחזיק את כולם בלי לשאול מי מחזיק אותו, מה אפשר לחלק אחרת, ועל אילו החלטות הוא באמת אמור להיות אחראי.
העוגן שנשאר: היחסים בין אנשים
כשכלים ותפקידים משתנים, אנשים עדיין צריכים לעבוד יחד. הם צריכים להבין מה מצופה מהם, למי אפשר לפנות, ואיך מדברים על טעות בלי להפוך אותה מיד לאיום אישי.
אפשר להיעזר ב-AI כדי לנסח שיחה קשה. את ההקשבה לאדם שמולנו, את האחריות להחלטה ואת האמון שנבנה לאורך זמן עדיין צריך לקיים בתוך היחסים עצמם.
ככל שיותר משימות עוברות לאוטומציה, כך חשוב יותר לטפח את היחסים שמאפשרים לצוות לעבוד יחד.
זו לא סיבה לוותר על הבנה טכנולוגית. ראש צוות צריך לדעת על מה הוא אחראי ולשאול שאלות קשות על איכות ועל סיכון. אבל ההבנה הזו מקבלת ערך בתוך עבודה משותפת עם אנשים.
הכלים ימשיכו להשתנות. גם גבולות התפקידים ישתנו. ההשקעה ביכולת להקשיב, להציב גבולות, להסביר ולבנות אמון היא דרך ממשית להתכונן לעתיד שאי אפשר לתכנן עד הסוף.
כי גם כשהקוד נוצר אחרת, עדיין יש אנשים שצריכים לבחור לבנות משהו יחד.
מאמרים נוספים שיעניינו אתכם
