หยุดการอภิปรายทางเทคนิคที่ไม่มีที่สิ้นสุดและตัดสินใจ

ฉันมักจะเจอคนที่ชอบที่จะตบมือสำหรับทุกวัยมากกว่า "สิ่งทางเทคนิค" ที่เล็กที่สุด

อย่าเข้าใจฉันผิดฉันเป็นโปรแกรมเมอร์ที่เกินบรรยายผู้ที่รักในสิ่งที่ฉันทำ แต่คุณรู้จักประเภทของการสนทนา

• Mac ดีกว่า Windows มาก
• อย่าใช้สำหรับแต่ละวงใช้ห่วงขณะ
• อย่าซื้อพีซีที่ใช้ Intel ใช้โปรเซสเซอร์ AMD
• เราควรใช้คอนเทนเนอร์ IoC หนึ่งอันเหนือภาชนะอื่น

"สิ่งต่าง ๆ " ทั้งหมดเหล่านี้มีข้อดีและข้อเสียที่ถูกต้องสำหรับทั้งสองฝ่ายและคุณจะไม่ได้รับคำตอบ "ถูกต้อง" และบุคคลนั้นจะไม่ยอมรับจุดนั้น (แน่นอนว่าจะมีบางที่ที่มีคำตอบอาจ :)

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

ปัญหา 1. บางคนไม่ชอบที่จะสูญเสีย หากพวกเขาไม่ได้โทรนัดพวกเขาจะถกเถียงกันจนกว่าพวกเขาจะโทรนัดด้วยการขัดสี

ปัญหาที่ 2 ไม่มีอะไรที่จะเป็นจริงได้

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

จะทำอย่างไร?

1. ตระหนักดีว่าไม่มีอะไรที่เป็นเดิมพัน

2. ตระหนักว่าในอีก 2 หรือ 3 ปีเรื่องทั้งหมดจะเปิดขึ้นอีกครั้งเพราะมีอะไรบางอย่างนอกองค์กรเปลี่ยนไป

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

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

สองสิ่งที่ต้องพิจารณา:

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

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

สิ่งเหล่านี้เป็นเรื่องจริงที่จะหลีกเลี่ยงปัญหาทั้งสองของ S.Lott - ที่บางคนไม่ชอบที่จะสูญเสีย คำตอบของฉันคือการเดิมพันดังนั้นจึงไม่มีการโต้วาทีเพื่อประโยชน์ของการโต้วาที

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

กฎนั้นง่าย เมื่อคุณไม่รู้ว่าจะเลือกอะไร - คิดว่าอะไรดีกว่าสำหรับ บริษัท

ใช่ตัวเลือก Intel v AMD ไม่ใช่เรื่องง่าย แต่ บริษัท ไหนดีกว่ากัน? ตัวอย่างเช่นหากมีบุคคลที่รับผิดชอบการสั่งซื้อสิ่งต่าง ๆ และจะต้องใช้เวลานานในการสั่งซื้อพีซีที่ใช้โปรเซสเซอร์ AMD แต่สามารถสั่งซื้อได้ในเวลาไม่กี่นาทีและคุณไม่สนใจว่าจะเป็นเช่นไร - เพียงแค่สั่งซื้อจาก Intel เพราะมันจะดีกว่าสำหรับ บริษัท

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

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

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

การกำหนดมาตรฐานเป็นวิธีการหนึ่ง

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

"เฮ้พีซีเหล่านั้นไร้ประโยชน์ในที่สุดมาลอง Macs!"

หรือ

"ฉันบอกคุณแล้ว! ฤดูใบไม้ผลิดีกว่า EJB มาก"

และอื่น ๆ

การมีมาตรฐานหมายความว่ารหัสนั้นง่ายต่อการทำงานกับทีมซึ่งจะนำไปสู่สภาพแวดล้อมที่มีประสิทธิผล

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

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

ฉันยอมรับว่านี่เป็นการสนทนาที่ยั่งยืนมากกว่าการตัดผ่าน อย่างไรก็ตามการอภิปรายไม่สิ้นสุดและเป็นบวกบางคนหลังจาก "ประชุม" ดังกล่าวมีแนวโน้มที่จะหลีกเลี่ยงการอภิปรายเทคโนโลยีเล็กน้อยซึ่งทำให้สิ่งต่าง ๆ สะดวกสบายมากขึ้นสำหรับทั้งทีม

ฉันได้อ่านบางแห่งมากกว่าที่คุณไม่ควรเดินทางเกิน 6 คนด้วยกันถ้าคุณต้องเห็นด้วยว่าคุณจะไปที่ไหนและทำอะไรเพราะคุณจะไม่ได้รับฉันทามติ

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

หากการตัดสินใจนั้นไม่ดีในภายหลังคุณอย่างน้อยก็รู้แน่นอนและสามารถเรียนรู้จากมันได้

วิธีหนึ่งคือการลงคะแนนและทำงานได้ดีในทีมขนาดเล็ก

ในขณะที่บุคคลสองคนอาจกำลังสนทนา ย้ายไปยังฟอรัมที่เปิดอยู่ ... อภิปรายเวลา N จำนวนแล้วถือการลงคะแนนโดยยกมือขึ้น

เรียบง่าย แต่เป็นประชาธิปไตยและให้คุณก้าวไปข้างหน้า

คำถามที่คล้ายกันอาจเป็น:

จะหยุดสงครามทางศาสนา / เปลวไฟบนฟอรัมได้อย่างไร

ฉันคิดว่า @ S.Lott ถูกต้องในความคิดเห็นของเขาหากประเด็นเดียวคือ "การอภิปราย" "เดินออกไป" หรือไม่เช่นนั้นอาจเป็นคำตอบเดียว ฉันเคยใช้เทคนิคนั้นในอดีต

หากประเด็นสำคัญคือการแก้ปัญหาให้ชั่งน้ำหนักข้อดี / ข้อเสียสำหรับโดเมนที่มีปัญหาตั้งเวลา จำกัด และ (พยักหน้าให้ Nike) เพียงแค่ทำมัน

นึกคิด - IMO - ผู้นำด้านเทคโนโลยีหรือผู้มีอำนาจกล่าวว่า "โอเคขอบคุณสำหรับคะแนนของคุณเราคือ ... " เสียงของลูกเต๋ากลิ้ง "... ไปตามความคิดของผู้อื่น" และทุกคนไปและนั่งลง

การได้เห็นคะแนนขนาดจิ๋วนั้นเสียเวลาไปกับการประชุมจำนวนมากและฉันไม่ต้องการที่จะได้ยินมันอีกต่อไป : - /

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

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

โดยส่วนตัวฉันไม่ต้องการหรือคาดหวังว่าคนอื่นจะเห็นด้วยกับฉันมันจะดี แต่ไม่สำคัญ และถึงจุดนี้ฉันพูดวอลแตร์

"ฉันไม่เห็นด้วยกับสิ่งที่คุณพูด แต่ฉันจะปกป้องความตายสิทธิ์ที่จะพูด" - นักปรัชญาคริสต์ศตวรรษที่ 5

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

หากการประชุมไม่คุ้มค่าที่จะแต่งตั้งประธานกรรมการ คุณอาจจะมีการแชทที่ watercooler เช่นกัน

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

แก้ไขปัญหาทั่วไปก่อน: เราต้องการเว็บเซิร์ฟเวอร์, เซิร์ฟเวอร์แอพ, ฐานข้อมูล ฯลฯ

สำหรับการอภิปรายเกี่ยวกับฐานข้อมูลหรือเซิร์ฟเวอร์ที่จะใช้ให้เก็บรายการเหล่านั้นไว้สำหรับการประชุมอื่น

ในระหว่างการประชุมครั้งถัดไปอนุญาตให้มีการพูดคุยกับ "รายการสั้น ๆ " ข้อเสนอที่เป็นไปได้เช่น MySQl, MS SQL Server, Postgres เป็นต้น

อนุญาตให้สมาชิกในทีมแสดงความคิดเห็น แต่ขอให้พวกเขาสำรองข้อมูลด้วยข้อเท็จจริง ผลิตภัณฑ์ X sucks! ไม่ตัดมันผลิตภัณฑ์ Y ไม่ได้ปรับขนาด! มันคลุมเครือเกินไป เป็นต้น

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

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

ในฐานะหัวหน้าทีมฉันรู้สึกว่ามันขึ้นอยู่กับว่าการตัดสินใจจะต้องทำที่นี่และตอนนี้

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

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

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

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

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

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

ผู้อำนวยความสะดวกในการประชุมที่ดีสามารถอำนวยความสะดวกในการสนทนาประเภทนี้โดยไม่ต้องออกจากมือ