การจัดการความขัดแย้งในทีม – ความสมดุลหรือความจำเป็นที่สำคัญ?

คำบรรยาย:
กาลครั้งหนึ่งเม่นและหมีน้อยพบกันในป่า
- สวัสดีเม่น!
- สวัสดีหมีน้อย!
ทีละคำ ตลกต่อตลก เม่นโดนหมีน้อยตบหน้า...

ด้านล่างนี้คือการสนทนาจากหัวหน้าทีมของเรา รวมถึงผู้อำนวยการฝ่ายพัฒนาผลิตภัณฑ์ RAS Igor Marnat เกี่ยวกับข้อขัดแย้งในการทำงานและวิธีการที่เป็นไปได้ในการจัดการข้อขัดแย้งเหล่านี้

ความขัดแย้งส่วนใหญ่ที่เราพบในที่ทำงานเกิดขึ้นจากสถานการณ์ที่คล้ายคลึงกับที่อธิบายไว้ในบทข้างต้น มีผู้เข้าร่วมหลายคนที่มีนิสัยค่อนข้างดีต่อกันในตอนแรก พวกเขากำลังพยายามแก้ไขปัญหาบางอย่าง แต่ในที่สุดปัญหาก็ยังไม่ได้รับการแก้ไข และด้วยเหตุผลบางประการความสัมพันธ์ระหว่างผู้เข้าร่วมในการอภิปรายจึงเสียหาย

ชีวิตมีความหลากหลาย และความแปรผันเกิดขึ้นในสถานการณ์ที่อธิบายไว้ข้างต้น บางครั้งความสัมพันธ์ระหว่างผู้เข้าร่วมอาจไม่ดีนักในช่วงแรก บางครั้งไม่มีแม้แต่ปัญหาที่ต้องได้รับการแก้ไขโดยตรง (เช่น ใน epigraph) บางครั้งหลังจากการอภิปราย ความสัมพันธ์ยังคงเหมือนเดิมก่อนที่จะเริ่มต้น แต่ ในที่สุดปัญหาก็ไม่ได้รับการแก้ไข

อะไรเป็นเรื่องปกติในทุกสถานการณ์ที่สามารถนิยามได้ว่าเป็นสถานการณ์ความขัดแย้งในการทำงาน?



ประการแรกมีสองด้านหรือมากกว่านั้น ฝ่ายเหล่านี้สามารถครอบครองตำแหน่งที่แตกต่างกันในองค์กร อยู่ในความสัมพันธ์ที่เท่าเทียมกัน (เพื่อนร่วมงานในทีม) หรือในระดับที่แตกต่างกันของลำดับชั้น (เจ้านาย - ผู้ใต้บังคับบัญชา) เป็นรายบุคคล (พนักงาน) หรือกลุ่ม (ในกรณีที่เกิดความขัดแย้งระหว่าง พนักงานและทีมงานหรือสองทีม) เป็นต้น โอกาสที่จะเกิดความขัดแย้งและความสะดวกในการแก้ไขนั้นได้รับอิทธิพลอย่างมากจากระดับความไว้วางใจระหว่างผู้เข้าร่วม ยิ่งทั้งสองฝ่ายรู้จักกันดี ระดับความไว้วางใจก็จะยิ่งสูงขึ้น โอกาสที่จะตกลงกันก็จะยิ่งมากขึ้นเท่านั้น ตัวอย่างเช่น สมาชิกในทีมที่กระจายตัวกันซึ่งไม่เคยมีปฏิสัมพันธ์แบบเห็นหน้ากันมักจะประสบกับความขัดแย้งในเรื่องงานธรรมดาๆ มากกว่าคนที่มีปฏิสัมพันธ์แบบเห็นหน้ากันอย่างน้อยสองสามครั้ง ดังนั้น เมื่อทำงานเป็นทีมแบบกระจาย สิ่งที่สำคัญมากคือต้องแน่ใจว่าสมาชิกในทีมทั้งหมดพบปะกันเป็นระยะๆ

ประการที่สอง ในสถานการณ์ความขัดแย้งในที่ทำงาน คู่สัญญาทั้งสองฝ่ายอยู่ในสถานการณ์ของการแก้ไขปัญหาบางอย่างที่สำคัญสำหรับฝ่ายใดฝ่ายหนึ่ง สำหรับทั้งสองฝ่าย หรือสำหรับองค์กรโดยรวม ในเวลาเดียวกัน เนื่องจากสถานการณ์เฉพาะ ทั้งสองฝ่ายมักจะมีเวลาเพียงพอและมีวิธีต่างๆ ในการแก้ไขปัญหา (เป็นทางการ ไม่เป็นทางการ การประชุม จดหมาย การตัดสินใจของฝ่ายบริหาร การมีเป้าหมายและแผนงานของทีม การ ข้อเท็จจริงของลำดับชั้น ฯลฯ) ซึ่งแตกต่างจากสถานการณ์ในการแก้ไขปัญหาเรื่องงาน (หรืองานที่ไม่ใช่งาน) ในองค์กร เช่น การแก้ปัญหาสำคัญ “เอ๊ะ ไอ้หนู คุณมาจากสาขาไหน!” บนท้องถนนหรือความขัดแย้งจาก epigraph ในกรณีของการแก้ไขปัญหาการทำงาน คุณภาพของกระบวนการทำงานและวัฒนธรรมในการแก้ไขปัญหาในทีมมีความสำคัญ

ประการที่สาม ปัจจัยกำหนดความขัดแย้ง (จากมุมมองของการสนทนาของเรา) คือความจริงที่ว่าทุกฝ่ายในกระบวนการไม่สามารถหาแนวทางแก้ไขปัญหาที่เหมาะสมกับทุกฝ่ายได้อย่างอิสระ สถานการณ์ดังกล่าวจำเป็นต้องได้รับการแทรกแซงจากบุคคลที่สาม ซึ่งเป็นผู้ตัดสินจากภายนอก ประเด็นนี้อาจดูขัดแย้งกัน แต่โดยพื้นฐานแล้ว หากสถานการณ์ความขัดแย้งได้รับการแก้ไขได้สำเร็จโดยปราศจากการแทรกแซงของผู้ตัดสินจากภายนอก ปัญหาก็ได้รับการแก้ไขอย่างประสบความสำเร็จและความสัมพันธ์ของทั้งสองฝ่ายก็ไม่เสื่อมลง นี่คือสถานการณ์ที่เราควรต่อสู้ . เรามักจะไม่รู้ด้วยซ้ำเกี่ยวกับความขัดแย้งดังกล่าว หรือเราจะรู้โดยบังเอิญหลังจากได้รับการแก้ไขแล้ว ยิ่งทีมสามารถแก้ไขได้ด้วยตัวเองมากเท่าไรก็ยิ่งมีประสิทธิภาพมากขึ้นเท่านั้น

คุณลักษณะที่เป็นลักษณะเฉพาะอีกประการหนึ่งของความขัดแย้งที่ควรค่าแก่การสัมผัสคือระดับความรุนแรงทางอารมณ์ในระหว่างการตัดสินใจ ความขัดแย้งไม่จำเป็นต้องเกี่ยวข้องกับระดับอารมณ์ที่สูงเสมอไป ผู้เข้าร่วมไม่จำเป็นต้องตะโกนและโบกแขนเพื่อให้สถานการณ์เกิดความขัดแย้ง ปัญหาไม่ได้รับการแก้ไข มีความตึงเครียดทางอารมณ์อยู่ (บางทีอาจไม่แสดงออกภายนอกอย่างชัดเจน) ซึ่งหมายความว่าเรากำลังเผชิญกับสถานการณ์แห่งความขัดแย้ง

จำเป็นหรือไม่ที่จะต้องเข้าไปแทรกแซงในสถานการณ์ความขัดแย้งเลย หรือจะดีกว่าถ้าปล่อยให้การแก้ปัญหาดำเนินไปและรอให้ปัญหาคลี่คลายเอง? จำเป็นต้อง. การแก้ไขข้อขัดแย้งโดยสมบูรณ์อาจไม่ได้อยู่ในอำนาจหรือความสามารถของคุณเสมอไป แต่ในสถานการณ์ใดก็ตาม ในความขัดแย้งทุกขนาด คุณสามารถเข้ารับตำแหน่งที่เป็นผู้ใหญ่ได้ และด้วยเหตุนี้จึงนำคนมาอยู่รอบตัวคุณอีกหลายคน เพื่อบรรเทาผลกระทบด้านลบของ ขัดแย้งและมีส่วนร่วมในการแก้ไขปัญหา

ก่อนที่จะดูตัวอย่างบางส่วนของสถานการณ์ความขัดแย้ง เรามาดูประเด็นสำคัญบางประการที่เกี่ยวข้องกับความขัดแย้งทั้งหมดก่อน

เมื่อแก้ไขข้อขัดแย้ง สิ่งสำคัญคือต้องอยู่เหนือการต่อสู้ และไม่ใช่อยู่ข้างใน (ซึ่งเรียกอีกอย่างว่า "การเข้ารับตำแหน่งเมตาดาต้า") นั่นคือต้องไม่เป็นส่วนหนึ่งของฝ่ายใดฝ่ายหนึ่งในกระบวนการแก้ไข มิฉะนั้น การมีอนุญาโตตุลาการภายนอกช่วยตัดสินจะยิ่งทำให้ตำแหน่งของฝ่ายใดฝ่ายหนึ่งแข็งแกร่งขึ้นจนสร้างความเสียหายให้กับอีกฝ่ายเท่านั้น เมื่อตัดสินใจเป็นสิ่งสำคัญที่ทุกฝ่ายจะยอมรับทางศีลธรรมตามที่พวกเขาพูดว่า "ซื้อ" ดังนั้นแม้ว่าทั้งสองฝ่ายจะไม่พอใจกับการตัดสินใจดังกล่าว แต่อย่างน้อยพวกเขาก็ตกลงที่จะปฏิบัติตามอย่างจริงใจ อย่างที่พวกเขาพูดเพื่อให้สามารถไม่เห็นด้วยและกระทำได้ มิฉะนั้นความขัดแย้งจะเปลี่ยนรูปลักษณ์ไป ไฟที่คุกรุ่นจะยังคงอยู่ใต้พรุพรุและเมื่อถึงจุดหนึ่งก็จะลุกเป็นไฟอีกครั้งอย่างหลีกเลี่ยงไม่ได้

ประเด็นที่สองซึ่งบางส่วนเกี่ยวข้องกับประเด็นแรกคือ หากคุณได้ตัดสินใจที่จะมีส่วนร่วมในการแก้ไขข้อขัดแย้งแล้ว ให้ดำเนินการอย่างจริงจังที่สุดเท่าที่จะเป็นไปได้จากมุมมองของการสื่อสารและศึกษาบริบท พูดคุยเป็นการส่วนตัวกับแต่ละฝ่าย แยกกันสำหรับผู้เริ่มต้น อย่าชำระจดหมาย กรณีเป็นทีมกระจายอย่างน้อยก็พูดคุยผ่านวิดีโอลิงค์ อย่าพอใจกับคำบอกเล่าและคำบอกเล่าของผู้เห็นเหตุการณ์ เข้าใจเรื่องราว ว่าแต่ละฝ่ายต้องการอะไร เหตุใดจึงต้องการ คาดหวังอะไร เคยพยายามแก้ไขปัญหานี้มาก่อนหรือไม่ จะเกิดอะไรขึ้นหากไม่ได้รับการแก้ไข เห็นแนวทางแก้ไขอย่างไร พวกเขาจินตนาการถึงจุดยืนของ คสช. อย่างไร อีกฝ่ายคิดอย่างไร ถูกหรือผิด ฯลฯ ใส่บริบทที่เป็นไปได้ทั้งหมดลงในหัวของคุณด้วยใจที่เปิดกว้าง โดยถือว่าทุกคนพูดถูก คุณไม่ได้อยู่ในความขัดแย้ง คุณอยู่นอกความขัดแย้ง ในอภิปราย หากบริบทมีเฉพาะในกระทู้ของโพสต์ อย่างน้อยก็อ่านเนื้อหาทั้งหมด รวมถึงกระทู้และเอกสารที่เกี่ยวข้องด้วย หลังจากที่คุณอ่านแล้วยังคงพูดด้วยเสียงของคุณ คุณเกือบจะรับประกันว่าจะได้ยินบางสิ่งที่สำคัญซึ่งไม่ได้อยู่ในจดหมาย

จุดสำคัญประการที่สามคือแนวทางการสื่อสารทั่วไป สิ่งเหล่านี้เป็นสิ่งธรรมดา ไม่มีอะไรเป็นจักรวาล แต่มีความสำคัญมาก เราไม่พยายามประหยัดเวลา เราพูดคุยกับผู้เข้าร่วมทั้งหมด เราไม่วิพากษ์วิจารณ์บุคคลนั้น แต่เราคำนึงถึงผลที่ตามมาของการกระทำของเขา (ไม่ใช่ "คุณหยาบคาย" แต่ "บางทีพวกเขาอาจจะขุ่นเคืองด้วย สิ่งนี้”) เราให้โอกาสในการรักษาหน้า เราพูดคุยกันต่อหน้า ไม่ใช่อยู่หน้าแถว

ความขัดแย้งมักเกิดจากสาเหตุใดสาเหตุหนึ่งจากสองสาเหตุ ประเด็นแรกเกี่ยวข้องกับว่าบุคคลในช่วงเวลาที่เกิดความขัดแย้งอยู่ในตำแหน่งผู้ใหญ่หรือในตำแหน่งเด็ก (อ่านรายละเอียดเพิ่มเติมด้านล่าง) นี่เป็นเพราะวุฒิภาวะทางอารมณ์ความสามารถในการจัดการอารมณ์ (ซึ่งไม่ได้เกี่ยวข้องกับอายุของเขาเสมอไป) สาเหตุทั่วไปประการที่สองคือความไม่สมบูรณ์ของกระบวนการทำงาน ซึ่งทำให้เกิดสถานการณ์ในพื้นที่สีเทาซึ่งความรับผิดชอบจะกระจายออกไประหว่างผู้เข้าร่วม ความคาดหวังของทั้งสองฝ่ายไม่โปร่งใสต่อกันและกัน และบทบาทในกระบวนการไม่ชัดเจน

ดังนั้น ในการแก้ไขข้อขัดแย้ง (เช่นเดียวกับปัญหาอื่นๆ) ผู้จัดการจะต้องคำนึงถึงมุมมองสามประการ: ระยะสั้น - เพื่อแก้ไขปัญหา/ข้อขัดแย้งที่นี่และเดี๋ยวนี้ ระยะกลาง - เพื่อลดโอกาสที่จะเกิดความขัดแย้งอื่น ด้วยเหตุผลเดียวกันและระยะยาว - เพื่อปลูกฝังวัฒนธรรมผู้ใหญ่ในคนในทีม

เราแต่ละคนมีความเป็นเด็กในตัว อายุประมาณสามหรือสี่ขวบ เขานอนหลับเกือบตลอดเวลาในที่ทำงาน แต่บางครั้งก็ตื่นขึ้นมาและควบคุมได้ เด็กมีลำดับความสำคัญของตัวเอง สิ่งสำคัญสำหรับเขาคือการยืนยันว่านี่คือกระบะทรายของเขา แม่ของเขารักเขามากกว่า เครื่องจักรของเขาดีที่สุด (การออกแบบดีที่สุด เขาตั้งโปรแกรมได้ดีที่สุด ...) ในสถานการณ์ความขัดแย้ง เด็กสามารถกดของเล่น กระทืบเท้า และหักไม้พายได้ แต่เขาไม่สามารถแก้ปัญหาสำหรับผู้ใหญ่ได้ (สถาปัตยกรรมโซลูชัน วิธีการทดสอบอัตโนมัติ วันที่วางจำหน่าย ฯลฯ) เขาไม่ได้คิดถึงผลประโยชน์ เพื่อทีม. เด็กที่อยู่ในความขัดแย้งสามารถได้รับการส่งเสริม ปลอบใจ และส่งเข้านอนโดยขอให้เขาโทรหาผู้ใหญ่ ก่อนที่จะเริ่มการสนทนาในสถานการณ์ความขัดแย้ง ตรวจสอบให้แน่ใจว่าคุณกำลังพูดคุยกับผู้ใหญ่ ไม่ใช่เด็ก และคุณเองก็อยู่ในสถานะที่เป็นผู้ใหญ่ หากเป้าหมายที่ซื่อสัตย์ของคุณในขณะนี้คือการแก้ไขปัญหาร้ายแรง แสดงว่าคุณอยู่ในสถานะที่เป็นผู้ใหญ่ หากเป้าหมายของคุณคือการกระทืบเท้าและสะบักไหล่หัก นี่เป็นท่าแบบเด็กๆ ส่งความเป็นเด็กในตัวคุณเข้านอนแล้วโทรหาผู้ใหญ่ หรือกำหนดเวลาการสนทนาใหม่ บุคคลทำการตัดสินใจโดยใช้อารมณ์แล้วมองหาเหตุผลที่สมเหตุสมผล การตัดสินใจโดยเด็กตามลำดับความสำคัญของเด็กจะไม่เหมาะสมที่สุด

นอกจากพฤติกรรมในช่วงเวลาที่เกิดความขัดแย้งแล้ว ตำแหน่งของเด็กหรือผู้ใหญ่ยังมีลักษณะเฉพาะด้วยระดับความรับผิดชอบที่บุคคลพร้อมที่จะรับไว้เอง ในการแสดงออกที่รุนแรงตำแหน่งเด็ก ๆ ของโปรแกรมเมอร์ที่ฉันพบมากกว่าหนึ่งครั้งมีลักษณะดังนี้: ฉันเขียนโค้ดส่งไปตรวจสอบ - งานของฉันเสร็จแล้ว ผู้ตรวจสอบควรตรวจสอบและอนุมัติ QA ควรตรวจสอบ หากมีปัญหาจะแจ้งให้ทราบ น่าแปลกที่บางครั้งแม้แต่คนที่ค่อนข้างเป็นผู้ใหญ่และมีประสบการณ์ก็มีพฤติกรรมแบบนี้เช่นกัน อีกด้านหนึ่งของมาตราส่วนคือ บุคคลถือว่าตัวเองมีหน้าที่รับผิดชอบในการตรวจสอบให้แน่ใจว่าโค้ดของเขาใช้งานได้ ได้รับการทดสอบ ได้รับการตรวจสอบเป็นการส่วนตัว และผ่านการตรวจสอบได้สำเร็จ (หากจำเป็น ไม่มีปัญหาในการส่ง Ping ไปยังผู้ตรวจสอบ อภิปรายประเด็นต่างๆ ด้วยเสียง ฯลฯ) และถูกระงับ QA จะให้ความช่วยเหลือหากจำเป็น จะมีการอธิบายสถานการณ์การทดสอบ ฯลฯ ในกรณีปกติ โปรแกรมเมอร์จะเริ่มต้นเข้าใกล้จุดสิ้นสุดของผู้ใหญ่มากขึ้น หรือย้ายไปที่นั่นเมื่อเขาได้รับประสบการณ์ (โดยต้องมีการปลูกฝังวัฒนธรรมที่เหมาะสมภายในทีม) ในกรณีที่ร้ายแรงเขายังคงทำงานต่อไปโดยมักจะรับตำแหน่งเด็ก ๆ จากนั้นเขาและทีมก็มีปัญหาและข้อขัดแย้งเป็นระยะ

การส่งเสริมวัฒนธรรมที่เหมาะสมและเป็นผู้ใหญ่ในทีมถือเป็นงานที่สำคัญสำหรับผู้จัดการทุกคน ใช้เวลานานและความพยายามทุกวัน แต่ผลลัพธ์ก็คุ้มค่า มีสองวิธีในการโน้มน้าววัฒนธรรมของทีม - นำด้วยการเป็นตัวอย่าง (ซึ่งจะตามมาอย่างแน่นอน ทีมจะมองไปที่ผู้นำเสมอ) และการพูดคุยและให้รางวัลกับพฤติกรรมที่ถูกต้อง ไม่มีอะไรที่ลึกซึ้งหรือเป็นทางการมากนักในที่นี้ เพียงแค่เมื่อพูดถึงปัญหา สังเกตว่ามีบางอย่างที่สามารถทำได้ที่นี่ เน้นว่าคุณสังเกตเห็นเมื่อมีการตัดสินใจอย่างถูกต้อง การยกย่อง ข้อสังเกตระหว่างการตรวจสอบการเปิดตัว ฯลฯ

ลองพิจารณาสถานการณ์ความขัดแย้งทั่วไปหลายประการ ตั้งแต่แบบง่ายไปจนถึงซับซ้อน:

ความขัดแย้งที่ไม่เกี่ยวข้องกับปัญหาการทำงาน

บ่อยครั้งมีความขัดแย้งในที่ทำงานที่ไม่เกี่ยวข้องกับปัญหาในการทำงาน การเกิดขึ้นและความง่ายในการแก้ปัญหามักจะเกี่ยวข้องโดยตรงกับระดับความฉลาดทางอารมณ์ของผู้เข้าร่วม ระดับวุฒิภาวะของพวกเขา และไม่เกี่ยวข้องกับความสมบูรณ์แบบหรือความไม่สมบูรณ์ของกระบวนการทำงาน

ตัวอย่างทั่วไป: บางคนไม่ได้ใช้เครื่องซักผ้าหรืออาบน้ำบ่อยเพียงพอ ซึ่งคนอื่นไม่ชอบ บางคนอับชื้น ในขณะที่บางคนได้รับลมหากเปิดหน้าต่าง บางคนส่งเสียงดังเกินไป และคนอื่นๆ ต้องการความเงียบในการทำงาน และ เร็วๆ นี้. เป็นการดีกว่าที่จะไม่ชะลอการแก้ไขข้อขัดแย้งประเภทนี้และอย่าปล่อยให้ความขัดแย้งเหล่านี้ดำเนินไป พวกเขาจะไม่แก้ไขด้วยตัวเองและจะทำให้คุณเสียสมาธิจากการทำงานทุกวัน และทำให้บรรยากาศในทีมเป็นพิษ โชคดีที่การแก้ปัญหามักไม่ใช่ปัญหาใหญ่ เพียงแค่พูดคุยอย่างสงบ (ตัวต่อตัว) กับเพื่อนร่วมงานที่ละเลยสุขอนามัย จัดที่นั่งที่สะดวกสบายสำหรับผู้ที่ชื่นชอบความเงียบ/ความเย็น ซื้อหูฟังดูดซับเสียง หรือติดตั้งฉากกั้น ฯลฯ

อีกตัวอย่างหนึ่งที่ฉันพบหลายครั้งระหว่างทำงานคือความไม่ลงรอยกันทางจิตวิทยาของสมาชิกในทีม ด้วยเหตุผลบางประการ ผู้คนไม่สามารถทำงานร่วมกันได้ ทุกปฏิสัมพันธ์จบลงด้วยเรื่องอื้อฉาว บางครั้งอาจเป็นเพราะความจริงที่ว่าผู้คนมีความคิดเห็นเชิงขั้วเกี่ยวกับปัญหาเร่งด่วนบางอย่าง (โดยปกติจะเป็นเรื่องการเมือง) และไม่รู้ว่าจะปล่อยให้พวกเขาอยู่นอกที่ทำงานได้อย่างไร การโน้มน้าวให้พวกเขาอดทนต่อกันหรือเปลี่ยนพฤติกรรมถือเป็นงานที่ค่อนข้างไร้ประโยชน์ ข้อยกเว้นเดียวที่ฉันพบคือเพื่อนร่วมงานรุ่นเยาว์ที่มีการรับรู้แบบเปิด พฤติกรรมของพวกเขายังคงสามารถค่อยๆ เปลี่ยนแปลงได้ผ่านการสนทนาเป็นระยะ โดยปกติแล้วปัญหาจะได้รับการแก้ไขได้สำเร็จโดยการแบ่งพวกเขาออกเป็นทีมต่างๆ หรืออย่างน้อยก็เปิดโอกาสให้มีการทับซ้อนกันในที่ทำงานน้อยมาก

ในสถานการณ์ข้างต้นทั้งหมด คุ้มค่าที่จะพูดคุยกับผู้เข้าร่วมทุกคนเป็นการส่วนตัว หารือเกี่ยวกับสถานการณ์ ถามว่าพวกเขาเห็นปัญหาในกรณีนี้เลยหรือไม่ ถามว่าในความเห็นของพวกเขาคืออะไร วิธีแก้ไข และรับประกันการมีส่วนร่วมในการดำเนินการนี้ การตัดสินใจ.

จากมุมมองของการเพิ่มประสิทธิภาพกระบวนการทำงาน (มุมมองระยะกลางที่ผมกล่าวถึง) ยังทำอะไรไม่ได้มากนัก จุดเดียวในการเพิ่มประสิทธิภาพคือคำนึงถึงปัจจัยความเข้ากันได้เมื่อสร้างทีมและไม่ใส่คน กันล่วงหน้าใครจะขัดแย้งกัน

จากมุมมองของวัฒนธรรมทีม สถานการณ์ดังกล่าวเกิดขึ้นน้อยมากในทีมที่มีวัฒนธรรมที่เป็นผู้ใหญ่ โดยที่ผู้คนให้ความเคารพในทีมและเพื่อนร่วมงาน และรู้วิธีแก้ไขปัญหาอย่างเป็นอิสระ นอกจากนี้ ข้อขัดแย้งดังกล่าวได้รับการแก้ไขได้ง่ายขึ้นมาก (มักจะโดยอัตโนมัติ) ในทีมที่มีความไว้วางใจในระดับสูง ผู้คนทำงานร่วมกันมาเป็นเวลานาน และ/หรือสื่อสารบ่อยครั้งนอกเวลางาน

ความขัดแย้งที่เกี่ยวข้องกับปัญหาการทำงาน:

ความขัดแย้งดังกล่าวมักเกิดจากทั้งสองสาเหตุพร้อมกัน ทั้งทางอารมณ์ (ความจริงที่ว่าผู้เข้าร่วมคนใดคนหนึ่งไม่ได้อยู่ในตำแหน่งผู้ใหญ่) และความไม่สมบูรณ์ของกระบวนการทำงานนั่นเอง บางทีความขัดแย้งประเภทที่พบบ่อยที่สุดที่ฉันพบอาจเป็นความขัดแย้งระหว่างการตรวจสอบโค้ดหรือการอภิปรายด้านสถาปัตยกรรมระหว่างนักพัฒนา

ฉันจะเน้นสองกรณีทั่วไปที่นี่:

1) ในกรณีแรก นักพัฒนาไม่สามารถรับการตรวจสอบโค้ดจากเพื่อนร่วมงานได้ โปรแกรมแก้ไขถูกส่งไปเพื่อตรวจสอบและไม่มีอะไรเกิดขึ้น เมื่อมองแวบแรกไม่มีความขัดแย้งที่ชัดเจนระหว่างทั้งสองฝ่าย แต่เมื่อลองคิดดูก็ถือว่าค่อนข้างขัดแย้งกัน ปัญหางานไม่ได้รับการแก้ไข ฝ่ายใดฝ่ายหนึ่ง (รอการตรวจสอบ) รู้สึกไม่สบายอย่างเห็นได้ชัด ประเภทย่อยที่รุนแรงของกรณีนี้คือการพัฒนาในชุมชนหรือในทีมที่แตกต่างกัน ในขณะที่ผู้ตรวจสอบอาจไม่สนใจรหัสนี้โดยเฉพาะ เนื่องจากการโหลดหรือสถานการณ์อื่น ๆ อาจไม่ใส่ใจกับคำขอตรวจสอบเลย และผู้ตัดสินภายนอก (ผู้จัดการร่วมกันทั้งสองฝ่าย) ) อาจจะไม่มีอยู่เลยก็ได้

แนวทางการแก้ปัญหาที่ช่วยในสถานการณ์ดังกล่าวมีความเกี่ยวข้องอย่างแม่นยำกับมุมมองระยะยาว ซึ่งเป็นวัฒนธรรมของผู้ใหญ่ ประการแรก กิจกรรมอัจฉริยะใช้งานได้ คุณไม่ควรคาดหวังว่าโค้ดที่แขวนอยู่บนรีวิวจะดึงดูดความสนใจของผู้รีวิวเอง เราต้องช่วยให้ผู้ตรวจสอบสังเกตเห็นเขา Pingani สองสามคน ถามคำถามเกี่ยวกับ syncape เข้าร่วมการสนทนา แน่นอนว่าการเรียกร้องมีแนวโน้มที่จะเป็นอันตรายมากกว่าความช่วยเหลือ คุณต้องใช้สามัญสำนึก ประการที่สอง การเตรียมการทำงานได้ดี หากทีมเข้าใจถึงสิ่งที่เกิดขึ้นและทำไม เหตุใดจึงต้องใช้โค้ดนี้ การออกแบบได้มีการพูดคุยและตกลงล่วงหน้ากับทุกคนแล้ว ผู้คนก็มีแนวโน้มที่จะให้ความสนใจกับโค้ดดังกล่าวและยอมรับมันในการทำงาน ประการที่สาม อำนาจทำงาน อยากถูกรีวิวก็รีวิวตัวเองเยอะๆ ทำการรีวิวคุณภาพสูง พร้อมการตรวจสอบจริง การทดสอบจริง และความคิดเห็นที่เป็นประโยชน์ หากชื่อเล่นของคุณเป็นที่รู้จักในทีม มีโอกาสมากขึ้นที่รหัสของคุณจะถูกสังเกตเห็น

จากมุมมองของเวิร์กโฟลว์ การปรับปรุงที่เป็นไปได้ที่นี่คือการจัดลำดับความสำคัญที่ถูกต้องเพื่อช่วยให้นักพัฒนาบรรลุเป้าหมายของเขาและทีม (ตรวจสอบผู้อื่น เขียนจดหมายถึงชุมชน แนบโค้ดพร้อมคำอธิบายสถาปัตยกรรม เอกสาร การทดสอบ เข้าร่วมในการสนทนากับ ชุมชน ฯลฯ) ป้องกันไม่ให้แพตช์ค้างอยู่ในคิวนานเกินไป เป็นต้น

2) กรณีทั่วไปประการที่สองของความขัดแย้งในระหว่างการตรวจสอบโค้ดหรือการออกแบบคือมุมมองที่แตกต่างกันเกี่ยวกับปัญหาทางเทคนิค รูปแบบการเขียนโค้ด และการเลือกเครื่องมือ สิ่งสำคัญอย่างยิ่งในกรณีนี้คือระดับความไว้วางใจระหว่างผู้เข้าร่วม การอยู่ในทีมเดียวกัน และประสบการณ์ในการทำงานร่วมกัน ทางตันเกิดขึ้นเมื่อผู้เข้าร่วมคนใดคนหนึ่งมีท่าทีเหมือนเด็กและไม่พยายามได้ยินสิ่งที่คู่สนทนาต้องการสื่อถึงเขา บ่อยครั้ง ทั้งแนวทางที่เสนอโดยอีกฝ่ายและแนวทางที่เสนอในตอนแรกอาจใช้ได้ผลดี และไม่สำคัญในหลักการว่าจะเลือกวิธีใด

วันหนึ่ง โปรแกรมเมอร์จากทีมของฉัน (ขอเรียกเขาว่า Pasha ดีกว่า) ได้เตรียมแพตช์ที่มีการเปลี่ยนแปลงระบบการปรับใช้แพ็คเกจ ซึ่งได้รับการพัฒนาและสนับสนุนโดยเพื่อนร่วมงานจากแผนกใกล้เคียง หนึ่งในนั้น (อิกอร์) มีความคิดเห็นที่ชัดเจนเกี่ยวกับวิธีกำหนดค่าบริการ Linux เมื่อปรับใช้แพ็คเกจ ความคิดเห็นนี้แตกต่างจากแนวทางที่เสนอในแพตช์ และพวกเขาไม่เห็นด้วย ตามปกติกำหนดเวลากำลังจะหมดลงและจำเป็นต้องตัดสินใจบางอย่างจึงจำเป็นที่หนึ่งในนั้นจะต้องเข้ารับตำแหน่งผู้ใหญ่ มหาอำมาตย์ตระหนักว่าทั้งสองแนวทางมีสิทธิที่จะมีชีวิต แต่เขาต้องการให้ทางเลือกของเขาผ่านเพราะว่า ไม่มีตัวเลือกใดตัวเลือกหนึ่งหรือตัวเลือกที่สองไม่มีข้อได้เปรียบทางเทคนิคที่ชัดเจน

การสนทนาของเรามีลักษณะเช่นนี้ (แน่นอนว่าการสนทนากินเวลาครึ่งชั่วโมงตามแผนผังมาก):

- มหาอำมาตย์ เรามีฟีเจอร์หยุดให้บริการในอีกไม่กี่วัน สิ่งสำคัญคือเราต้องรวบรวมทุกอย่างเข้าด้วยกันและเริ่มการทดสอบโดยเร็วที่สุด เราจะผ่านอิกอร์ได้อย่างไร?
— เขาต้องการตั้งค่าบริการที่แตกต่างออกไป เขาติดความคิดเห็นไว้ตรงนั้นให้ฉัน...
- และมีอะไรเปลี่ยนแปลงครั้งใหญ่ยุ่งยากมากมาย?
- ไม่ มีงานสองสามชั่วโมง แต่สุดท้ายก็ไม่ต่างกัน มันจะได้ผลทั้งสองทาง ทำไมจึงจำเป็น? ฉันทำบางอย่างที่ได้ผล ยอมรับมันเถอะ
- ฟังนะ คุณคุยเรื่องทั้งหมดนี้มานานเท่าไหร่แล้ว?
- ใช่ เรากำหนดเวลามาได้หนึ่งสัปดาห์ครึ่งแล้ว
- อืม... เราจะแก้ปัญหาภายในสองสามชั่วโมงที่กินเวลาไปแล้วหนึ่งสัปดาห์ครึ่งแต่ไม่ทำได้ไหม?
- ก็ใช่ แต่ฉันไม่อยากให้อิกอร์คิดว่าฉันยอมจำนน...
- ฟังนะ อะไรสำคัญกว่าสำหรับคุณในการออกแถลงการณ์พร้อมกับการตัดสินใจของคุณภายในหรือฆ่าอิกอร์? เราสามารถบล็อกมันได้ อย่างไรก็ตาม ก็ยังมีโอกาสดีที่จะปล่อยผ่านได้
- เอาล่ะ... คงจะเจ๋งถ้าได้เช็ดจมูกของอิกอร์ แต่โอเค ฉันเห็นด้วย การปล่อยตัวสำคัญกว่า
- สิ่งที่อิกอร์คิดเป็นสิ่งสำคัญสำหรับคุณจริง ๆ หรือไม่? พูดตามตรง เขาไม่ได้สนใจเลย เขาแค่ต้องการแนวทางที่เป็นหนึ่งเดียวกันในสถานที่ต่าง ๆ ของสิ่งที่เขารับผิดชอบ
- เอาล่ะ ให้ฉันทำตามที่เขาถามในความคิดเห็นแล้วมาเริ่มทดสอบกันดีกว่า
- ขอบคุณมหาอำมาตย์! ฉันมั่นใจว่าคุณสองคนจะเป็นผู้ใหญ่มากขึ้นแม้ว่า Igorek จะแก่กว่าคุณก็ตาม :)

ปัญหาได้รับการแก้ไขแล้ว ปล่อยตัวตรงเวลา มหาอำมาตย์ไม่ได้รู้สึกไม่พอใจมากนักเพราะว่า เขาเองก็เสนอวิธีแก้ปัญหาและนำไปปฏิบัติ โดยทั่วไปอิกอร์พอใจเพราะ... ความเห็นของเขาถูกนำมาพิจารณาและปฏิบัติตามที่เขาแนะนำ

ความขัดแย้งเดียวกันโดยพื้นฐานอีกประเภทหนึ่งคือตัวเลือกระหว่างโซลูชัน/ไลบรารี/แนวทางทางเทคนิคในโครงการ โดยเฉพาะอย่างยิ่งในทีมที่กระจายตัว ในโปรเจ็กต์หนึ่งซึ่งอยู่ในตำแหน่งที่ใช้ C/C++ ปรากฏว่าการจัดการทางเทคนิคของโปรเจ็กต์ขัดแย้งกับการใช้ STL (ไลบรารีเทมเพลตมาตรฐาน) อย่างเด็ดขาด นี่คือไลบรารีภาษามาตรฐานที่ช่วยให้การพัฒนาง่ายขึ้น และทีมงานของเราคุ้นเคยกับมันมาก ปรากฎว่าโปรเจ็กต์นี้ใกล้กับ C มากกว่า C++ ซึ่งไม่ได้สร้างแรงบันดาลใจให้กับทีมมากนักเพราะว่า ฝ่ายบริหารพยายามอย่างดีที่สุดและได้รับการคัดเลือกผู้เล่นที่ยอดเยี่ยมจริงๆ ในเวลาเดียวกัน ทีมงานชาวอเมริกันทั้งวิศวกรและผู้จัดการทำงานในบริษัทมาเป็นเวลานาน คุ้นเคยกับสถานการณ์ปัจจุบัน และพอใจกับทุกสิ่ง ทีมจากรัสเซียถูกรวมตัวกันเมื่อไม่นานมานี้ ภายในไม่กี่สัปดาห์ (รวมถึงฉันด้วย) ส่วนหนึ่งของทีมรัสเซียไม่ต้องการละทิ้งแนวทางการพัฒนาตามปกติอย่างเด็ดขาด

การสนทนาที่เป็นลายลักษณ์อักษรอย่างไม่มีที่สิ้นสุดเริ่มต้นขึ้นระหว่างสองทวีป จดหมายบนหน้าจอสามหรือสี่จอบินไปมาทั้งในรูปแบบการส่งจดหมายเป็นกลุ่มและส่วนตัว ตั้งแต่โปรแกรมเมอร์ไปจนถึงโปรแกรมเมอร์และผู้จัดการ ตามปกติแล้วไม่มีใครอ่านจดหมายที่มีความยาวขนาดนี้ ยกเว้นผู้เขียนและผู้สนับสนุนที่กระตือรือร้นของพวกเขา การสนทนาดังเอี๊ยดด้วยความตึงเครียดส่งผ่านความคิดหลายหน้าจอไปในทิศทางต่าง ๆ เกี่ยวกับข้อได้เปรียบทางเทคนิคของ STL การทดสอบนั้นดีแค่ไหนปลอดภัยแค่ไหนและโดยทั่วไปแล้วชีวิตที่ยอดเยี่ยมนั้นเป็นอย่างไรและมันแย่แค่ไหนหากไม่มีมัน .

ทั้งหมดนี้กินเวลาค่อนข้างนาน จนกระทั่งในที่สุดฉันก็รู้ว่าเรากำลังพูดคุยกันในด้านเทคนิคของปัญหานี้ แต่จริงๆ แล้วปัญหาไม่ใช่เรื่องทางเทคนิค ปัญหาไม่ใช่ข้อดีหรือข้อเสียของ STL หรือความยากในการทำงานโดยปราศจากมัน ปัญหาค่อนข้างเป็นองค์กร เราแค่ต้องเข้าใจว่าบริษัทที่เราทำงานด้วยทำงานอย่างไร พวกเราไม่มีใครมีประสบการณ์ทำงานในบริษัทดังกล่าวมาก่อน ประเด็นก็คือหลังจากที่โค้ดได้รับการพัฒนาและเผยแพร่สู่การใช้งานจริง การสนับสนุนได้รับการจัดการโดยผู้คนที่แตกต่างอย่างสิ้นเชิงจากทีมอื่น ๆ จากประเทศอื่น ๆ ทีมวิศวกรขนาดใหญ่ที่ประกอบด้วยวิศวกรหลายหมื่นคน (โดยรวม) สามารถซื้อเครื่องมือทางเทคนิคขั้นต่ำขั้นพื้นฐานได้เท่านั้น หรือพูดง่ายๆ ก็คือขั้นต่ำสุดนั่นเอง สิ่งใดก็ตามที่เกินกว่ามาตรฐานทางวิศวกรรมที่กำหนดขึ้นในบริษัททางกายภาพจะไม่สามารถรองรับได้ในอนาคต ระดับของทีมจะถูกกำหนดโดยระดับของสมาชิกที่อ่อนแอที่สุด หลังจากที่เราเข้าใจแล้ว แรงจูงใจที่แท้จริง การกระทำของทีมงานชาวอเมริกัน ปัญหานี้ถูกลบออกจากวาระการประชุม และเราได้ร่วมกันพัฒนาและเผยแพร่ผลิตภัณฑ์ได้สำเร็จโดยใช้มาตรฐานที่บริษัทนำมาใช้ จดหมายและการแชทในกรณีนี้ทำงานได้ไม่ดีนัก ต้องใช้การเดินทางหลายครั้งและการสื่อสารส่วนตัวมากมายกว่าจะได้ตัวส่วนร่วม

จากมุมมองของเวิร์กโฟลว์ ในกรณีนี้ การมีคำอธิบายของเครื่องมือที่ใช้ ข้อกำหนดสำหรับเครื่องมือ ข้อจำกัดในการเพิ่มเครื่องมือใหม่ และเหตุผลสำหรับข้อจำกัดดังกล่าวจะช่วยได้มาก เอกสารดังกล่าวโดยคร่าวๆ สอดคล้องกับที่อธิบายไว้ในย่อหน้ากลยุทธ์การใช้ซ้ำและสภาพแวดล้อมการพัฒนาของ "คู่มือผู้จัดการเพื่อการพัฒนาซอฟต์แวร์" ซึ่งพัฒนาขึ้นใน นาซา. แม้จะอายุมาก แต่ก็อธิบายกิจกรรมหลักและขั้นตอนการวางแผนการพัฒนาซอฟต์แวร์ประเภทนี้ได้อย่างสมบูรณ์แบบ การมีเอกสารลักษณะนี้ทำให้เป็นเรื่องง่ายมากในการหารือว่าส่วนประกอบและวิธีการใดบ้างที่สามารถใช้ในผลิตภัณฑ์ได้ และเพราะเหตุใด

จากมุมมองทางวัฒนธรรม เห็นได้ชัดว่ามีตำแหน่งที่เป็นผู้ใหญ่มากขึ้น ซึ่งทั้งสองฝ่ายพยายามที่จะได้ยินและเข้าใจแรงจูงใจที่แท้จริงของการกระทำของเพื่อนร่วมงาน และดำเนินการตามลำดับความสำคัญของโครงการและทีม ไม่ใช่อัตตาส่วนบุคคล ความขัดแย้งก็จะคลี่คลายได้ง่ายขึ้นและเร็วขึ้น

ในข้อขัดแย้งอื่นเกี่ยวกับการเลือกวิธีแก้ปัญหาทางเทคนิค ฉันต้องใช้เวลาพอสมควรในการทำความเข้าใจแรงจูงใจของฝ่ายใดฝ่ายหนึ่ง (ซึ่งเป็นกรณีที่ไม่ปกติมาก) แต่หลังจากแรงจูงใจชัดเจนแล้ว วิธีแก้ปัญหาก็ชัดเจน

สถานการณ์เป็นดังนี้: นักพัฒนารายใหม่ปรากฏตัวในทีมประมาณ 20 คน เรียกเขาว่า Stas กันดีกว่า ในเวลานั้น เครื่องมือมาตรฐานของเราสำหรับการสื่อสารในฐานะทีมคือ Skype ตามที่ปรากฎในภายหลัง Stas เป็นแฟนตัวยงของมาตรฐานโอเพ่นและซอฟต์แวร์โอเพ่นซอร์ส และใช้เครื่องมือและระบบปฏิบัติการที่มีแหล่งที่มาเปิดเผยต่อสาธารณะและใช้โปรโตคอลที่อธิบายต่อสาธารณะเท่านั้น Skype ไม่ใช่หนึ่งในเครื่องมือเหล่านี้ เราใช้เวลามากมายเพื่อหารือเกี่ยวกับข้อดีและข้อเสียของแนวทางนี้ ความพยายามที่จะเปิดตัวอะนาล็อกของ Skype บนระบบปฏิบัติการที่แตกต่างกัน ความพยายามของ Stas เพื่อโน้มน้าวให้ทีมเปลี่ยนไปใช้มาตรฐานอื่น เขียนถึงเขาเป็นการส่วนตัวทางไปรษณีย์ โทรหาเขาเป็นการส่วนตัวที่ โทรศัพท์ ซื้อคอมพิวเตอร์เครื่องที่สองให้เขาโดยเฉพาะสำหรับ Skype เป็นต้น ในที่สุด ฉันก็ตระหนักว่าโดยพื้นฐานแล้วปัญหานี้ไม่ใช่เรื่องทางเทคนิคหรือเชิงองค์กร แต่เป็นเชิงอุดมการณ์ แม้แต่ใครๆ ก็สามารถพูดได้ว่าเป็นเรื่องทางศาสนา (สำหรับ Stas) แม้ว่าในที่สุดเราจะเชื่อมต่อ Stas และ Skype (ซึ่งใช้เวลาหลายเดือน) แต่ปัญหาก็จะเกิดขึ้นอีกครั้งในอุปกรณ์ที่ตามมา ฉันไม่มีทางเปลี่ยนโลกทัศน์ของ Stas ได้อย่างแท้จริง และไม่มีเหตุผลใดที่จะพยายามเปลี่ยนโลกทัศน์ของทีมที่ทำงานอย่างสมบูรณ์แบบในสภาพแวดล้อมเช่นนี้ บุคคลและบริษัทมีทัศนคติแบบตั้งฉากในโลกทัศน์ของพวกเขา ในสถานการณ์เช่นนี้ วิธีแก้ปัญหาที่ดีคือการจัดองค์กร เราย้ายสตาสไปทีมอื่นซึ่งเขามีความเป็นธรรมชาติมากกว่า

ในความคิดของฉันสาเหตุของความขัดแย้งนี้คือความแตกต่างระหว่างวัฒนธรรมส่วนบุคคลของบุคคลใดบุคคลหนึ่ง (ซึ่งมีความคิดเห็นที่รุนแรงซึ่งไม่อนุญาตให้เขาประนีประนอม) และวัฒนธรรมของบริษัท ในกรณีนี้ แน่นอนว่าเป็นความผิดพลาดของผู้จัดการ ในตอนแรกมันเป็นเรื่องผิดที่จะพาเขาไปทำโปรเจ็กต์ประเภทนี้ ในที่สุด Stas ก็ย้ายไปที่โครงการพัฒนาซอฟต์แวร์โอเพ่นซอร์สและทำได้ดีที่นั่น

ตัวอย่างที่ดีของความขัดแย้งที่เกิดจากทั้งทัศนคติแบบเด็กๆ ของนักพัฒนาและข้อบกพร่องของกระบวนการทำงานคือสถานการณ์ที่หากไม่มีคำจำกัดความของคำว่าเสร็จสิ้น นักพัฒนาและทีมงาน QA มีความคาดหวังที่แตกต่างกันเกี่ยวกับความพร้อมของ คุณลักษณะที่ถ่ายโอนไปยัง QA นักพัฒนาเชื่อว่าการเขียนโค้ดและโยนฟีเจอร์นี้ข้ามรั้วไปที่ QA ก็เพียงพอแล้ว - พวกเขาจะจัดการมันที่นั่น เป็นโปรแกรมเมอร์ที่ค่อนข้างเป็นผู้ใหญ่และมีประสบการณ์ แต่นั่นเป็นเกณฑ์ภายในด้านคุณภาพของเขา QA ไม่เห็นด้วยกับสิ่งนี้และต้องการแสดงและอธิบายให้พวกเขาฟังถึงสิ่งที่เขาได้ตรวจสอบด้วยตัวเอง และต้องการสคริปต์ทดสอบให้พวกเขา พวกเขาเคยมีปัญหากับฟังก์ชันการทำงานจากนักพัฒนารายนี้ในอดีต และไม่ต้องการเสียเวลาอีกต่อไป ยังไงก็ตาม พวกเขาพูดถูก - ฟีเจอร์นี้ใช้งานไม่ได้จริง ๆ เขาไม่ได้ตรวจสอบโค้ดก่อนส่งให้ QA

เพื่อแก้ไขสถานการณ์ ฉันขอให้เขาแสดงให้ฉันเห็นว่าทุกอย่างได้ผลจริง ๆ (มันไม่ได้ผลและเขาต้องแก้ไขมัน) เราได้พูดคุยกับทีมงานและด้วยคำจำกัดความของ QA ที่แปลว่าเสร็จสิ้น (พวกเขาไม่ได้ทำในนั้น) การเขียน เนื่องจากเราไม่ต้องการทำให้กระบวนการนี้เป็นระบบราชการมากเกินไป ) ในไม่ช้า เราก็แยกทางกับผู้เชี่ยวชาญรายนี้ (เพื่อการบรรเทาทุกข์ทั่วไป)

จากมุมมองของเวิร์กโฟลว์ การปรับปรุงที่เป็นไปได้ในกรณีนี้คือการมีคำจำกัดความของสิ่งที่ทำเสร็จแล้ว ข้อกำหนดสำหรับการสนับสนุนคุณลักษณะแต่ละหน่วยและการทดสอบบูรณาการ และคำอธิบายของการทดสอบที่ดำเนินการโดยนักพัฒนา ในโปรเจ็กต์หนึ่ง เราวัดระดับการครอบคลุมโค้ดโดยการทดสอบระหว่าง CI และหากระดับความครอบคลุมลดลงหลังจากเพิ่มแพตช์ การทดสอบจะถูกทำเครื่องหมายว่าล้มเหลว กล่าวคือ สามารถเพิ่มรหัสใหม่ได้ก็ต่อเมื่อมีการทดสอบใหม่เท่านั้น

อีกตัวอย่างทั่วไปของความขัดแย้งที่เกี่ยวข้องอย่างใกล้ชิดกับการจัดกระบวนการทำงาน เรามีผลิตภัณฑ์ ทีมพัฒนาผลิตภัณฑ์ ทีมสนับสนุน และลูกค้า ลูกค้ามีปัญหาเกี่ยวกับผลิตภัณฑ์และการติดต่อฝ่ายสนับสนุน ฝ่ายสนับสนุนวิเคราะห์ปัญหาและเข้าใจว่าปัญหาอยู่ในผลิตภัณฑ์และถ่ายทอดปัญหาไปยังทีมงานผลิตภัณฑ์ ทีมผลิตภัณฑ์อยู่ในช่วงเวลายุ่ง ใกล้จะเปิดตัวแล้ว ดังนั้นตั๋วที่มีปัญหาจากลูกค้าซึ่งหายไปในบรรดาตั๋วอื่นๆ ของนักพัฒนาที่ได้รับมอบหมายให้ ค้างเป็นเวลาหลายสัปดาห์โดยไม่ได้รับการดูแล ฝ่ายสนับสนุนคิดว่านักพัฒนากำลังแก้ไขปัญหาของลูกค้า ลูกค้ารอและหวังว่าปัญหาจะได้รับการแก้ไข ในความเป็นจริงยังไม่มีอะไรเกิดขึ้น หลังจากผ่านไปไม่กี่สัปดาห์ ในที่สุดลูกค้าก็ตัดสินใจที่จะสนใจในความคืบหน้าและขอการสนับสนุนว่าสิ่งต่างๆ เป็นอย่างไรบ้าง ฝ่ายสนับสนุนขอการพัฒนา นักพัฒนาตัวสั่นเมื่อมองดูรายการตั๋วและพบตั๋วจากลูกค้าที่นั่น เมื่ออ่านตั๋วจากลูกค้า เขาเข้าใจว่ามีข้อมูลไม่เพียงพอที่จะแก้ไขปัญหา และเขาต้องการบันทึกและไฟล์เพิ่มเติม ฝ่ายสนับสนุนขอข้อมูลเพิ่มเติมจากลูกค้า จากนั้นลูกค้าก็ตระหนักว่าไม่มีใครแก้ไขปัญหาของเขาตลอดเวลานี้ แล้วฟ้าร้องจะฟาด...

ในสถานการณ์นี้ วิธีแก้ปัญหาข้อขัดแย้งนั้นค่อนข้างชัดเจนและเป็นเส้นตรง (แก้ไขผลิตภัณฑ์ อัปเดตเอกสารและการทดสอบ เอาใจลูกค้า ออกโปรแกรมแก้ไขด่วน ฯลฯ) สิ่งสำคัญคือต้องวิเคราะห์กระบวนการทำงานและทำความเข้าใจว่าใครเป็นผู้รับผิดชอบในการจัดการปฏิสัมพันธ์ระหว่างทั้งสองทีม และเหตุใดสถานการณ์นี้จึงเป็นไปได้ตั้งแต่แรก ชัดเจนว่าสิ่งใดที่ต้องแก้ไขในกระบวนการนี้ - บางคนต้องติดตามภาพรวมโดยไม่ต้องแจ้งเตือนจากลูกค้าในเชิงรุก ตั๋วจากลูกค้าควรโดดเด่นเหนือตั๋วอื่นๆ จากผู้พัฒนา ฝ่ายสนับสนุนควรดูว่าทีมพัฒนากำลังทำงานกับตั๋วหรือไม่ และหากไม่ จะเริ่มทำงานได้เมื่อใด และคาดว่าจะได้ผลลัพธ์เมื่อใด การสนับสนุนและการพัฒนาควรสื่อสารและหารือเกี่ยวกับสถานะของตั๋วเป็นระยะ การรวบรวมข้อมูลที่จำเป็นสำหรับการแก้ไขจุดบกพร่องควรเป็นไปโดยอัตโนมัติมากที่สุด ฯลฯ

เช่นเดียวกับในสงคราม ศัตรูพยายามโจมตีทางแยกระหว่างสองหน่วย ดังนั้นในการทำงาน จุดที่ละเอียดอ่อนและเปราะบางที่สุดมักจะเป็นปฏิสัมพันธ์ระหว่างทีม หากผู้จัดการฝ่ายสนับสนุนและการพัฒนามีอายุเพียงพอ พวกเขาจะสามารถแก้ไขกระบวนการได้ด้วยตนเอง หากไม่เป็นเช่นนั้น กระบวนการก็จะทำให้เกิดข้อขัดแย้งและปัญหาต่อไปจนกว่าผู้จัดการจะเข้ามาแทรกแซงผู้ที่สามารถแก้ไขสถานการณ์ได้

อีกตัวอย่างทั่วไปที่ฉันได้เห็นซ้ำแล้วซ้ำเล่าในบริษัทต่างๆ คือสถานการณ์ที่ผลิตภัณฑ์เขียนโดยทีมหนึ่ง การทดสอบการรวมอัตโนมัติสำหรับผลิตภัณฑ์เขียนโดยทีมที่สอง และโครงสร้างพื้นฐานที่ใช้งานทั้งหมดนั้นมาพร้อมกับทีมที่สาม ทีม. ปัญหาในการทำการทดสอบเกิดขึ้นตลอดเวลา และสาเหตุของปัญหาอาจเป็นได้ทั้งผลิตภัณฑ์และการทดสอบและโครงสร้างพื้นฐาน มักจะเป็นปัญหาในการตกลงกันว่าใครควรดำเนินการวิเคราะห์เบื้องต้นเกี่ยวกับปัญหา จุดบกพร่องของไฟล์ บันทึกการแยกวิเคราะห์ของผลิตภัณฑ์ การทดสอบและโครงสร้างพื้นฐาน ฯลฯ ความขัดแย้งที่นี่เกิดขึ้นบ่อยมากและในขณะเดียวกันก็มีเรื่องเครื่องแบบด้วย ในกรณีที่มีความรุนแรงทางอารมณ์สูง ผู้เข้าร่วมมักจะตกอยู่ในสถานะเด็ก และการสนทนาเริ่มต้นในซีรีส์: "ทำไมฉันถึงต้องแก้ไขเรื่องนี้" "พวกเขาพังบ่อยขึ้น" เป็นต้น

จากมุมมองของเวิร์กโฟลว์ ขั้นตอนเฉพาะในการแก้ไขปัญหาขึ้นอยู่กับองค์ประกอบของทีม ประเภทของการทดสอบและผลิตภัณฑ์ ฯลฯ ในโปรเจ็กต์หนึ่ง เราได้แนะนำการปฏิบัติหน้าที่เป็นระยะ โดยทีมจะติดตามการทดสอบทีละรายการ สัปดาห์ต่อสัปดาห์ ในทางกลับกัน การวิเคราะห์เบื้องต้นมักจะดำเนินการโดยนักพัฒนาทดสอบ แต่การวิเคราะห์นั้นพื้นฐานมาก และผลิตภัณฑ์ค่อนข้างเสถียร ดังนั้นจึงทำงานได้ดี สิ่งสำคัญคือต้องแน่ใจว่ากระบวนการมีความโปร่งใส ความคาดหวังมีความชัดเจนสำหรับทุกฝ่าย และสถานการณ์ให้ความรู้สึกยุติธรรมสำหรับทุกคน

ความขัดแย้งถือเป็นปัญหาในองค์กรหรือไม่ เป็นสัญญาณที่ไม่ดีที่ความขัดแย้งมักเกิดขึ้นในทีมของคุณ (หรือเป็นระยะๆ) หรือไม่ โดยทั่วไปไม่มี เพราะหากมีการเติบโต การพัฒนา มีพลวัตอะไรสักอย่าง ปัญหาที่ไม่เคยได้รับการแก้ไขมาก่อนก็เกิดขึ้น และเมื่อแก้ไขแล้ว ความขัดแย้งก็อาจเกิดขึ้นได้ นี่เป็นตัวบ่งชี้ว่าบางพื้นที่จำเป็นต้องได้รับการดูแล และยังมีจุดที่ต้องปรับปรุง ไม่ดีเลยหากความขัดแย้งเกิดขึ้นบ่อยมาก แก้ไขได้ยาก หรือใช้เวลานาน นี่อาจเป็นสัญญาณของกระบวนการทำงานที่ไม่มีประสิทธิภาพเพียงพอและความพร้อมของทีมไม่เพียงพอ

ที่มา: will.com