"אוניברסלי" בצוות הפיתוח: תועלת או נזק?

שלום לכולם! שמי לודמילה מקרובה, אני מנהלת פיתוח ב-UBRD ושליש מהצוות שלי הם "גנרליסטים".

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

מי הוא, מבשר הציפיות שלנו?

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

האינטראקציה של הצוות ותוצאת עבודתו תלויה בתכונות המקצועיות והאישיות של המשתתפים.

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

יש הרבה מאמרים על כל מיני סוגי אישיות בתעשיית ה-IT. בהתבסס על הניסיון שלי, הייתי מחלק את כללי ה-IT לארבע קטגוריות:

1. "אוניברסלי - כל יכול"

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

במה הם חזקים:

• מסוגלים לפתור בעיות מורכבות;
• לצלול עמוק לתוך הבעיה, "לחפור" ולהשיג תוצאות;
• בעל מוח סקרן.

אך

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

2. "אוניברסלי - אני אמצא את זה ואעשה את זה"

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

במה הם חזקים:

• עצמאי;
• עמיד בפני מתח;
• מוכשר בנושאים רבים;
• מלומד - תמיד יש על מה לדבר איתם.

אך

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

3. "אוניברסלי - בסדר, תן לי לעשות את זה, כי אין אף אחד אחר"

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

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

במה הם חזקים:

• אחראי;
• ממוקד תוצאות;
• לְהַרְגִיעַ;
• נשלט לחלוטין.

אך

• להראות תוצאות ממוצעות עקב רמה נמוכה של כישורים;
• לא יכול לפתור בעיות מורכבות ומופשטות.

4. "כל-עגול הוא אמן במלאכתו"

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

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

במה הם חזקים:

• להראות איכות גבוהה של עבודה;
• מסוגל לפתור כל בעיה;
• יעיל מאוד.

אך

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

מה יש לנו בפועל?

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

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

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

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

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

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

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

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

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

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

איך אנחנו מתמודדים עם בעיות?

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

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

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

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

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

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

מה קרה בסוף?

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

ממצאים

לעובדים כלליים יש את היתרונות והחסרונות שלהם.

יתרונות:

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

חסרונות:

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

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

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

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

אני מאחל לכולם צוות מארגן עצמי של "מאסטרים אוניברסליים של האומנות שלהם"!

מקור: www.habr.com