האם אי פעם שמתם לב לכך שהדרך שבה אנשים בקבוצה עובדים יחד משפיעה על תוצאות הפרויקט שלהם? ובכן, בעולם של הנדסת תוכנה, יש חוק שמסביר את הקשר הזה - הוא נקרא חוק קונוויי, על שם מתכנת המחשבים מלווין קונוויי. החוק אומר שהדרך שבה מעוצבת מערכת תוכנה משקפת את האופן שבו הארגון שיצר אותה עובד יחד.
איך חוק קונוויי משפיע על פיתוח בטכנולוגית?
חוק קונוויי פשוט קובע שהמבנה של מערכת תוכנה משקף את הדרך שבה אנשים בארגון מתקשרים ומשתפים פעולה. במילים אחרות, אם צוות לא מתקשר טוב או עובד ביחד באופן הדוק, זה יופיע בתוכנה שהם יוצרים.
מצד שני, אם לצוות יש תקשורת ושיתוף פעולה טובים, זה יביא לתוכנה מעוצבת יותר.
בואו נדמיין חברה שבה המחלקות השונות ממעטות לדבר ביניהן. הם עובדים בנפרד, וממעטים לשתף מידע. כשהם מפתחים מערכת תוכנה, סביר להניח שהיא תהיה מפוצלת ולא משולבת היטב. זה יהיה כמו חלקים נפרדים שחוברו יחד בלי הרבה מחשבה. מהצד השני, אם החברה תעודד תקשורת פתוחה ושיתוף פעולה בין מחלקות, מערכת התוכנה שתתקבל תהיה יותר מגובשת ומאורגנת היטב.
לחוק קונוויי יש שיעור חשוב לארגונים העוסקים בפיתוח תוכנה. אם הם רוצים ליצור תוכנה עם עיצוב או מבנה ספציפי, הם צריכים לעצב את המבנה הפנימי ודפוסי התקשורת שלהם בהתאם. לדוגמה, אם חברה רוצה לבנות מערכת תוכנה מודולרית וגמישה, עליה לעודד צוותים לעבוד בשיתוף פעולה הדוק ולשתף מידע בחופשיות על פני מודולים שונים.
איך זה קשור לטכנולוגית?
Agile ו-DevOps הן גישות פופולריות בפיתוח תוכנה שמתואמות ביחס ישר לחוק קונוויי. שיטות אלו מדגישות את החשיבות של תקשורת שוטפת של צוותים מתפקידים שונים לאורך הפיתוח. על ידי קידום שיתוף פעולה בין מפתחים, בודקים וחברי צוות אחרים, Agile ו-DevOps עוזרים ליצור מערכות תוכנה המשולבות היטב ועובדות בצורה חלקה בחטיבה הטכנולוגית של בנק הפועלים.
יתר על כן, ככל שארגונים גדלים ומשתנים, גם דפוסי ומבני התקשורת הפנימיים שלהם מתפתחים. יש לכך השלכות על תחזוקה והתפתחות של מערכות תוכנה. אם מבנה הארגון נעשה מורכב יותר, זה יכול להפוך את תחזוקת התוכנה למאתגרת יותר. על ידי הבנת חוק קונוויי, ארגונים יכולים לצפות ולנהל אתגרים אלו על ידי התאמת המבנה ודפוסי התקשורת שלהם כך שיתאימו לארכיטקטורת התוכנה הרצויה.
הבנק עבר בשנים האחרונות המון שינויים: מודל ההפעלה וצורת העבודה השתנו במעבר ל-Agile ולעבודה בשבטים, הנחלת ארכיטקטורת ה-To Be ועולם ה-Domain Driven Design ותהליכי CI/CD מעולם ה-DevOps. זה יצר צורת תקשורת שונה בין העובדים מזו שהייתה עד כה: למשל, מפתח Backend יכול להשתייך ניהולית ל-CL, לעבוד בצוות שמנהל אותו PO ולהשתייך לגילדת מפתחים או COE שמקדם אותו מקצועית ויוצר אינטראקציה בין שאר המפתחים בתחום שלו. כל אלו באים יחד לידי ביטוי במערכות פיתוח - ובסופו של דבר גם בקוד.
החיבור של שני העולמות, העולם העסקי והטכנולוגי שנוצר בשבטים בבנק יצר ייעול בתהליכים ובא לידי ביטוי בפיתוח פיצ'רים מותאמים יותר ללקוח הקצה. תהליך ניתוח המערכות נהיה יותר מהיר ומוכוון לקוח ממה שהיה לפני כן, מאחר והגורם העסקי נמצא בהישג יד ויכול לכוון בכל רגע נתון.
לעודד תקשורת יעילה
על ידי הבנה כיצד המבנה הארגוני מעצב תוכנה, חברות יכולות לשפר את תהליכי פיתוח התוכנה שלהן ולהשיג הצלחה גדולה יותר!
חוק קונוויי אומר לנו שהדרך שבה אנשים בארגון עובדים יחד משפיעה על התוכנה שהם יוצרים. על ידי זיהוי הקשר הזה, ארגונים יכולים להשתמש בחוק לטובתם. הם יכולים לעודד תקשורת יעילה, שיתוף פעולה ושימוש במתודולוגיות Agile ו-DevOps ליצירת תוכנה מעוצבת יותר.