ניהול קונפליקטים בצוות - פעולת איזון או צורך חיוני?

אֶפִּיגְרָף:
פעם, הקיפוד והדוב הקטן נפגשו ביער.
– שלום, קיפוד!
– שלום, דוב קטן!
אז, מילה אחר מילה, בדיחה בדיחה, הקיפוד נפגע בפניו מהדוב הקטן...

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

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

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

מה משותף בכל המצבים שניתן להגדיר כמצב של קונפליקט בעבודה?



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

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

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

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

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

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

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

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

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

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

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

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

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

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

הבה ניקח בחשבון מספר מצבי קונפליקט אופייניים, מפשוט למורכב:

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

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

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

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

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

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

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

קונפליקטים הקשורים לבעיות עבודה:

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

הייתי מדגיש כאן שני מקרים טיפוסיים:

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

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

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

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

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

הדיון שלנו נראה בערך כך (סכמטית מאוד, כמובן, השיחה נמשכה חצי שעה):

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

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

סוג נוסף של אותו קונפליקט בעצם הוא הבחירה בין פתרונות טכניים/ספריות/גישות בפרויקט, במיוחד בצוות מבוזר. באחד הפרויקטים, שהוצב כמשתמש ב-C/C++, התברר שהניהול הטכני של הפרויקט היה נגד שימוש ב-STL (Standard Template Library). זוהי ספריית שפות סטנדרטית שמפשטת את הפיתוח, והצוות שלנו רגיל לזה מאוד. התברר שהפרויקט הרבה יותר קרוב ל-C מאשר ל-C++, מה שלא נתן השראה לצוות, כי ההנהלה ניסתה כמיטב יכולתה וגייסה שחקני פלוס מגניבים באמת. יחד עם זאת, החלק האמריקאי בצוות, מהנדסים ומנהלים כאחד, עבדו בחברה תקופה ארוכה, היו רגילים למצב הקיים ושמחו מהכל. החלק הרוסי של הצוות התכנס די לאחרונה, תוך מספר שבועות (כולל אני). החלק הרוסי של הצוות לא רצה באופן מוחלט לנטוש את הגישה הרגילה לפיתוח.

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

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

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

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

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

המצב הוא כזה: מפתח חדש מופיע בצוות של כ-20 אנשים, בואו נקרא לו סטס. באותו זמן, הכלי הסטנדרטי שלנו לתקשורת כצוות היה Skype. כפי שהתברר מאוחר יותר, סטס היה מעריץ גדול של תקנים פתוחים ותוכנות קוד פתוח, והשתמש רק בכלים ומערכות הפעלה שמקורותיהם היו זמינים לציבור ואשר השתמשו בפרוטוקולים המתוארים בפומבי. סקייפ הוא לא אחד מהכלים האלה. בילינו זמן רב בדיונים על היתרונות והחסרונות של גישה זו, ניסיונות להשיק אנלוגים של סקייפ במערכות הפעלה שונות, ניסיונותיו של סטס לשכנע את הצוות לעבור לסטנדרטים אחרים, לכתוב לו באופן אישי בדואר, להתקשר אליו באופן אישי טלפון, קנה לו מחשב שני במיוחד לסקייפ וכו'. לבסוף, הבנתי שהבעיה הזו, במהותה, אינה טכנית או ארגונית, היא דווקא אידיאולוגית, אפילו, אפשר לומר, דתית (עבור סטס). גם אם בסופו של דבר נחבר את Stas וסקייפ (מה שנמשך מספר חודשים), הבעיה תתעורר שוב בכל מכשיר אחר. לא עמדו לרשותי אמצעים אמיתיים לשנות את תפיסת העולם של סטס, ולא הייתה סיבה לנסות לשנות את תפיסת העולם של צוות שעבד בצורה מושלמת בסביבה הזו. האדם והחברה היו פשוט אורתוגונלים בתפיסת עולמם. במצבים כאלה, פתרון טוב הוא ארגוני. העברנו את סטס לקבוצה אחרת, שם הוא היה יותר אורגני.

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

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

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

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

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

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

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

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

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

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

מקור: www.habr.com