בהתחלה היו I‑specialists
בתחילת עולם ה‑IT הכשירו אנשי מקצוע לפי מסלול אחד (למשל C++ או DCOM). אלה היו I‑shape – מומחים צרי התמחות.
הם מקצוענים, אבל כדי לבנות מוצר עם צוות מלא ב‑I צריך המון אנשים – לכל פעולה מומחה. זו בעיה ראשונה.
בעיה שנייה: תקשורת. מומחים צרים לא תמיד מבינים זה את זה, וכל אחד שקוע בתחום שלו. ככל שהצוות גדל כך הוא נעשה פחות זריז. לחבר מפתחים, אנליסטים, אנשי DB ובודקים היה קשה.
ה‑IT התפתח והגיע הזמן לפתור זאת – וכך נולדו ה‑T‑shaped.
המונח T‑shaped נטבע ב‑1991 בידי David Guest בכתבה "The hunt is on for the Renaissance Man of computing".
Guest חזה שאנשי T יהיו מנהיגי העתיד שייקחו צוותים ופרויקטים קדימה.
הפופולריות הגיעה בזכות Tim Brown (IDEO) ואף Valve בספר "HANDBOOK FOR NEW EMPLOYEES".
בבסיס המתודולוגיות האג'יליות עומדים אותם "יוניברסלים" משנות ה‑90.
מי הם אנשי T?
לפי Guest הכישורים נפרסים על שני וקטורים: אנכי (עומק) ואופקי (רוחב). הקו האופקי אינו אחיד – חלק מהנושאים מוכרים יותר וחלק פחות.
למה הם חשובים לצוותים ולחברות?
בשוק שמתפתח כל הזמן, חשוב גם עומק וגם כישורים חוצי תחומים. אנשי T מקטינים צוותים, מגבירים גמישות ומהירות תגובה. כך מתייעלת הבנייה, גדלה המהירות, והתקשורת בתוך הצוות קלה יותר.
במציאות, צוותים זריזים הם קרוס‑פונקציונליים.
מה זה אומר?
צוות קרוס‑פונקציונלי הוא קבוצת מומחים עם כל הכישורים לבנות, לתחזק ולפתח מוצר בלי להזדקק לצוותים אחרים.
למה צוותים כאלה חשובים?
-
גמישות
-
מהירות פיתוח גבוהה
-
עצמאות
-
פרודוקטיביות גבוהה
טעות נפוצה: צוות קרוס‑פונקציונלי מורכב רק מאנשי T. לא נכון – הוא יכול לשלב T ו‑I.
בפועל צוותים רבים מורכבים בעיקר מ‑I.
ראשית, לגדל או למצוא איש T לוקח זמן רב (שנים). שנית, לפעמים זה פשוט לא נדרש.
דוגמה: בונים לנדינג פשוט ב‑Tilda – יידרש מעצב, מפרט וייתכן בודק; אין צורך בבקאנד.
עבדתי בכמה צוותים קרוס‑פונקציונליים בפרויקטים עתירי עומס. כל צוות הוא יחידה עצמאית.
בצוות אחד היו מפתחי פולסטאק (מכירים גם פרונט וגם בק), אנליסטים, בודקים ידניים ואוטומטיים ומנהל צוות.
מפתחים החליפו זה את זה בחופשה/מחלה, והפיתוח לא נעצר. כך גם אנליסטים ובודקים.
צוות קטן ובטוח ניהל כמה פרויקטים של אותה פלטפורמה בהצלחה רבה יותר מצוותים גדולים, בזכות אנשי T טובים.
לא היו בעיות תקשורת – מפתחים, אנליסטים ובודקים דיברו באותה שפה. הבודקים יכלו לקרוא קוד ולהבין אילו טסטים להוסיף ללא עזרת המפתחים.
על החסרונות
אנשי T מבוקשים, אבל יש גם צדדים פחות זוהרים.
שחיקה: צריך לרדוף אחרי ההתפתחות גם במומחיות וגם בתחומים סמוכים.
"הגנה" פסיכולוגית: חשש שידע נוסף יביא עוד עבודה, במיוחד אם הנהלה מנצלת זאת.
ספקות: "האם אפשר להיות מומחה בשני תחומים?" – חשוב לעודד כדי לגדל איש T.
צוותים קרוס‑פונקציונליים אינם מורכבים רק מאנשי T – לרוב הם "מערבבים" מומחי T עם I.
צוותים כאלה גמישים יותר ומסוגלים לספק יותר תוצאות בזמן קצר.
