איך, בתנאים של ארכיטקטורה מטופשת וחוסר כישורי Scrum, יצרנו צוותים חוצי רכיבים

היי!

שמי אלכסנדר, ואני מוביל פיתוח IT ב-UBRD!

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

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

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

• פחד מאיבוד כוח ו"כותפות";
• פחד להפוך למיותר עבור החברה.

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

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

לפני הקמת צוותי Scrum, עלתה השאלה: "על מה צריך להרכיב את הצוות?" הקונספט שיש מוצר בפחית, כמובן, היה באוויר, אבל ממש מחוץ להישג יד. לאחר מחשבה רבה, החלטנו שצריך לרכז את הצוות סביב כיוון או קטע. לדוגמה, "צוות קרדיטים", המפתחת הלוואות. לאחר שהחלטנו על כך, התחלנו להמציא הרכב יעד של תפקידים ומערכת של כישורים הדרושים לפיתוח יעיל של תחום זה. כמו חברות רבות אחרות, לקחנו בחשבון את כל התפקידים מלבד ה-Scrum Master – באותה תקופה כמעט בלתי אפשרי להסביר ל-CIO מה תפקידו של האדם הנפלא הזה.

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

1. הלוואות
2. כרטיסים
3. פעולות פסיביות

עם סט תפקידים:

1. מנהל פיתוח (טכני)
2. מפתחים
3. אנליסט
4. בּוֹחֵן

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

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

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

מה הלאה?

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

ואז התחיל הכיף. הצוותים החוצים שלנו החלו לפתח את עצמם. למשל, ישנה משימה שעבורה אתה צריך להיות בעל מיומנויות בתחום של מפתחי CRM. הוא בצוות, אבל הוא לבד. יש גם מפתח של אורקל. מה לעשות אם אתה צריך לפתור 2 או 3 משימות ב-CRM? ללמד אחד את השני! החבר'ה החלו להעביר את היכולות שלהם זה לזה, והצוות הרחיב את היכולות שלו, תוך צמצום התלות במומחה אחד חזק (אגב, בכל חברה יש סופרמנים שיודעים הכל ולא מספרים לאף אחד).

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

המטרה הסופית שלנו: להגיב במהירות לשינויים במוצר, להביא במהירות פיצ'רים חדשים לשוק ולשפר את שירותי הבנק!

מקור: www.habr.com