เจ้านายของฉันตัดสินใจเพิ่มฟิลด์“ บุคคลที่จะตำหนิ” ในรายงานข้อผิดพลาดทุกครั้ง ฉันจะโน้มน้าวเขาได้อย่างไรว่าเป็นความคิดที่ไม่ดี

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

อะไรคือข้อโต้แย้งที่แข็งแกร่งอื่น ๆ เกี่ยวกับการฝึกฝนนี้ที่ฉันสามารถใช้ได้ มีการเขียนในหัวข้อนี้ที่ฉันสามารถแบ่งปันกับทีมและเจ้านายได้หรือไม่?

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

ค้นหาเว็บสำหรับสิ่งที่ต้องการซอฟต์แวร์การวิเคราะห์ข้อผิดพลาดสาเหตุที่มีความอุดมสมบูรณ์ของทรัพยากรที่จะแสดงให้เห็นถึงเหตุผลนี้^{1 , 2 , 3 , 4 ,} ...

... สาเหตุที่เป็นข้อบกพร่องไม่ใช่นักพัฒนารายเดียว (ซึ่งเป็นประเด็นหลักของฟิลด์นี้) ...

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

บอกเจ้านายของคุณเมื่อมีการเป็นนักพัฒนาที่เดียวที่จะตำหนิสาเหตุฟิลด์แน่นอนจะครอบคลุม ( "ความผิดพลาดการเข้ารหัสทำโดยบ๊อบในกระทำ 1234 พลาดโดยจิมในการตรวจสอบ 567" ) จุดประสงค์ในการใช้สาเหตุของคำศัพท์คือครอบคลุมกรณีดังกล่าวพร้อมกับกรณีที่ออกนอกขอบเขตของทีม dev

^{ตัวอย่างเช่นหากข้อผิดพลาดเกิดจากฮาร์ดแวร์ที่ผิดพลาด (เมื่อบุคคลนั้นตำหนิว่าเป็นคนนอกทีมที่ซื้อและทดสอบ) ฟิลด์สาเหตุของปัญหาจะช่วยให้ครอบคลุมได้ในขณะที่ "นักพัฒนาเดียวจะตำหนิ" ก็จะแตกติดตามปัญหาการไหล}

^{เช่นเดียวกับข้อผิดพลาดอื่น ๆ ที่เกิดจากบุคคลนอกทีม dev - ข้อผิดพลาดของผู้ทดสอบการเปลี่ยนแปลงข้อกำหนดและการตัดสินใจด้านการจัดการ สมมติว่าหากผู้บริหารตัดสินใจที่จะข้ามการลงทุนในฮาร์ดแวร์การกู้คืนความเสียหาย "การตำหนิผู้พัฒนารายเดียว" สำหรับไฟฟ้าดับในดาต้าเซ็นเตอร์จะไม่สมเหตุสมผล}

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

อาร์กิวเมนต์หลักที่ฉันจะใช้กับมันคือถามว่าปัญหาที่เขาพยายามแก้ไข มีวิธีแก้ปัญหาเดียวกันที่ดีกว่า

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

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

จากนั้นคุณจะเห็นได้อย่างชัดเจนว่าคน ๆ หนึ่งนั้นผิดปกติหรือไม่และอาจเป็นปัญหาที่แตกต่างออกไป

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

มีปัญหาอย่างน้อยสามข้อในฟิลด์ดังกล่าว

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

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

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

อีกซอฟต์แวร์หนึ่งล้มเหลวในการวัด

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

ไม่ถูกต้อง:

บ๊อบลืมตรวจสอบอินพุตและโปรแกรมหยุดการหารด้วยศูนย์

ขวา:

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

เปลี่ยน "บุคคลที่จะกล่าวโทษ" เป็น "บุคคลที่น่ายกย่อง"

บุคคลหลักในการแก้ไขข้อบกพร่องจะได้รับชื่อของพวกเขา

คำตอบง่ายๆ

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

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

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

หากคุณพร้อมสำหรับการไม่เชื่อฟังเล็กน้อยให้ทีมงานยอมรับที่จะนำรายชื่อผู้พัฒนาทั้งหมดในฟิลด์นั้นสำหรับแต่ละข้อบกพร่อง ถ้ามันไม่พอดีเขียน "I'm Spartacus!" แทน. ประเด็นก็คือคุณต้องรับผิดชอบต่อข้อบกพร่องทั้งหมดและคุณไม่มีความสุขที่ต้องชี้ให้เห็นบุคคลที่สร้างข้อผิดพลาดอย่างใดอย่างหนึ่ง

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

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

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

สิ่งที่เธอทำคือแทนที่จะเพิ่มฟิลด์ 'บุคคลที่จะตำหนิ' ลงในเอกสารของเราเธอให้ชุดสติ๊กเกอร์สีแก่นักออกแบบแต่ละคน นักออกแบบแต่ละคนมีสติกเกอร์สีที่แตกต่างกันและได้รับคำสั่งว่าสำหรับการออกแบบใด ๆ ที่ทำงานบนหรือแม้แต่การสัมผัสสติกเกอร์จะต้องเพิ่มลงในเอกสารของการออกแบบนั้น

เป้าหมายที่ระบุไว้ของเจ้านายสำหรับ "ความคิดริเริ่มสติ๊กเกอร์" คือการสร้างแหล่งที่มาของข้อผิดพลาดของแผนกของเรา (ความผิดพลาดในงานเอกสาร, การทำผิดพลาด, คัดลอกไม่ดี, เป็นหลักเทียบเท่ากับการพิมพ์ข้อบกพร่อง)

สิ่งที่เราทำคือให้นักออกแบบคนอื่น ๆ หนึ่งในสี่ของสติกเกอร์ของเราเพื่อให้เรามีสีทั้งหมดและแทนที่จะใส่เพียงแค่สีของเราในแต่ละแบบเราใส่สีของนักออกแบบทั้งสี่

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

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

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

อธิบายว่าระบบนี้จะทำให้ดูเหมือนว่าคนที่เขียนรหัสมากที่สุดคือโปรแกรมเมอร์ที่แย่ที่สุดและคนที่เขียนรหัสน้อยที่สุดคือโปรแกรมเมอร์ที่ดีที่สุด

ฟังดูเหมือนเป็นอย่างมากเมื่อ Scott Adams ชี้ให้เห็นถึงภูมิปัญญาที่ล้มเหลวของ Bug Bounty เมื่อเจ้านายของ Pointy Haired ใน Dilbert เก่งประกาศว่าเขากำลังจะไปและ 'เขียนเขามินิแวนใหม่ "

การ์ตูน Dilbert สำหรับ 11/13/1995 จากหนังสือการ์ตูน Dilbert ฉบับทางการ

ฉันจำได้ว่าครั้งหนึ่งเมื่อ Snow Skiing ที่ใครบางคนชี้ให้เห็นว่า "ไม่ล้ม" ไม่ใช่สัญญาณของนักเล่นสกีที่ดี แต่บ่อยครั้งที่สัญญาณของคนที่ไม่ได้ลองอะไรเลย

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

ดูเหมือนว่าเจ้านายของคุณอาจจะผิดหวังกับจำนวนข้อบกพร่อง คนในกลุ่มของคุณหลงใหลเกี่ยวกับคุณภาพหรือไม่ การสร้างฟิลด์ 'what' สำหรับสาเหตุแทนที่จะเป็นฟิลด์ 'who' อาจมีประสิทธิผลมากกว่า ตัวอย่าง: การเปลี่ยนแปลงข้อกำหนด, ข้อบกพร่องในการออกแบบ, ข้อบกพร่องในการใช้งาน, ฯลฯ แม้สิ่งนี้จะล้มเหลวเว้นแต่จะมีการรวมกลุ่มเพื่อปรับปรุงคุณภาพของผลิตภัณฑ์

บางทีคุณควรมองว่า "ใครอยู่ในตำแหน่งที่ดีที่สุดในการแก้ไขข้อบกพร่อง" ส่วนหนึ่งของฉันก็รู้สึกคุณหักมันคุณแก้ไขมัน ควรมีความรับผิดชอบ

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

ในบางจุดผู้จัดการควรรู้ว่าใครทำหน้าที่ของตนและใครไม่ดีใครทำดีกว่าเพราะคนอื่นในทีมทำ

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

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

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

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

นี่คือการสั่งซื้อสูง นอกจากปัญหาเรื่องการรักษาใบหน้าหลังจากเปลี่ยนใจแล้วยังมีปัญหาพื้นฐานที่ผู้คนคิดเกี่ยวกับการแก้ปัญหาในแง่ของโทษส่วนบุคคลมักจะตั้งอยู่ในความคิดนั้น

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

ผิดปกติเนื่องจากปัญหาที่นี่เป็นเรื่องของคนมากกว่ารายงานข้อผิดพลาดมันอาจเป็นของ Workplace มากกว่าโปรแกรมเมอร์ แต่ความสำเร็จของโครงการซอฟแวร์มักจะสามารถติดตามการปฏิสัมพันธ์ทางสังคมของมนุษย์ได้ค่อนข้างมากดังนั้นคำตอบที่แท้จริงนั้นมักจะเกี่ยวกับสิ่งที่เหนือกว่าซอฟต์แวร์

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

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

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

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

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

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

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

การอ่านที่แนะนำในส่วนของเจ้านายของคุณ: 7 นิสัยของคนที่มีประสิทธิภาพสูง

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

การอ่านและ / หรือการวิจัยที่แนะนำในส่วนของคุณ:

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

ตอนนี้ดูเหมือนว่าเขาไม่ได้เตรียมที่จะแก้ไขอะไรเลยเพราะเขาไม่มีความเข้าใจในสิ่งที่แตกสลายหากมีสิ่งใดเสียหาย - นอกเหนือจากความคิด "ฉันเป็นเจ้านาย" ของเขา

โชคดี! ฉันหวังว่าคุณจะได้รับผ่านสิ่งนี้ในลักษณะที่เป็นที่ยอมรับสำหรับทุกคนโดยเฉพาะในเวลานี้

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

สำหรับความรับผิดชอบฉันไม่ต้องการperson to blameฟิลด์ฉันต้องการPerson who knows the codeฟิลด์หรือperson who can fixฟิลด์เพื่อที่ฉันจะได้รู้ว่าจะส่งตั๋วสนับสนุนที่ไหน

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

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

หากเจ้านายของฉันทำสิ่งต่อไปนี้จะเกิดขึ้นตามลำดับนี้:

1) ฉันจะเริ่มหางานใหม่ทันที

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

ตามหมายเหตุด้านข้าง: ผู้จัดการฝ่ายพัฒนาที่ดีทุกคนตระหนักถึงสิ่งที่ฉันเขียนไว้ด้านบน และกลยุทธ์ Agile นั้นมีจุดมุ่งหมายเพื่อชี้ให้เห็นถึงหัวหน้าหรือผู้สนับสนุนของเขา / เธอทำไม dev จึงชะลอตัวลง: ดูสิเราใช้เวลา 50% ของการแก้ไขข้อบกพร่อง ให้ดูกลยุทธ์เพื่อลดพวกเขาเพื่อให้เราสามารถใช้ 40% ของเวลาในการแก้ไขข้อบกพร่องแล้วกลับมาทบทวนปัญหานี้เพื่อให้ได้ 30% เป็นต้น

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

ดูเหมือนว่าเจ้านายของคุณจะไม่เข้าใจซอฟต์แวร์อย่างลึกซึ้งและบางทีเขาก็ไม่ได้ตั้งใจเช่นกัน ดังนั้นเขาจึงมีภาษาที่แตกต่างวัฒนธรรมที่แตกต่าง

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

เนื่องจากเขาไม่รู้จักภาษาของเราและเขาเป็นเจ้านายขั้นตอนแรกที่นี่จะพยายามพูดคุยกับเขาในภาษาของเขา ฉันหมายถึงภาษาอะไร ลองคิดกัน:

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

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

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

ทำให้การเคลื่อนไหวของคุณพูดคุยในภาษาของเขา ข้อบกพร่องนั้นยอดเยี่ยมสำหรับ บริษัท ซอฟต์แวร์ไม่ใช่ปัญหา พวกเขาทำให้เรามีชีวิต

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

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

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

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

ฉันเรียงกลับมาในวันนี้นี่คือสิ่งที่ฉันทำ

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

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

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

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

ผลที่ได้คือผู้พัฒนาจะเป็นเจ้าของมากขึ้นรู้สึกมั่นใจมากขึ้นและจะมีข้อผิดพลาดน้อยลงในรหัสการผลิต

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

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

เพื่อให้เครดิตแก่เจ้านายแนวคิดของ "การมอบหมายโทษ" ได้ถูกอบเข้าสู่เครื่องมืออย่างSVNแล้วและการใช้ข้อมูลที่เหมาะสมสามารถเป็นประโยชน์สำหรับนักพัฒนาในการ "ค้นหาว่าใครจะคุยด้วย" ในขณะที่ทำการดีบักเช่น: http: / /www.codinghorror.com/blog/2007/11/who-wrote-this-crap.html

ในขณะที่ฉันเห็นด้วยกับการตอบสนองของริ้นข้างต้นว่าฟิลด์สาเหตุรากเป็นสิ่งที่ดีนี่ไม่ใช่ข้อมูลเดียวกันและ "denormalizing" ฟิลด์บางครั้งเพื่อกำหนดชื่อนักพัฒนาก่อนหน้านี้สำหรับแหล่งที่ได้รับผลกระทบและบางครั้งมี คำอธิบายทางเทคนิค (เช่น "ไม่ได้ปรับขนาดได้ 10,000 ผู้ใช้") จะทำให้น้ำขุ่น ฉันอยากสนับสนุนให้รูทสาเหตุฟิลด์คำอธิบายทางเทคนิคอย่างชัดเจน (เช่นแม้เมื่อมีข้อผิดพลาดโปรแกรมเมอร์ชัดเจนให้จับรายละเอียดเช่น "IndexOutOfRange Exception เมื่อ fooData = 999") สิ่งนี้อาจให้ข้อเสนอแนะที่เป็นประโยชน์เมื่อตรวจสอบโดยรวมและอนุญาตให้ดำเนินการแก้ไขบางอย่าง เพื่อแก้ไขปัญหาทั้งหมดของคลาสที่มีการเปลี่ยนแปลงทางสถาปัตยกรรมหรือเฟรมเวิร์ก (เช่นการปรับปรุงคลาสคอนเทนเนอร์แบบกำหนดเองการส่งข้อยกเว้นระดับบนสุด)

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

ปัญหาของการเพิ่มสิ่งนี้เป็นเขตข้อมูลบั๊ก / การวัดที่มีศักยภาพนั้นง่ายต่อการเริ่มต้นการแจกแจง:

1. บั๊กนั้นยากที่จะแก้ไขและสถิติที่ง่ายของการนับบั๊ก / นักพัฒนาจะไม่สะท้อนสิ่งนี้
2. นักพัฒนามีความสามารถในการเปลี่ยนแปลงสูง "" "" "" "" "
3. ระบบซอฟต์แวร์จำนวนมากมีส่วนประกอบที่จำเป็นต้องทำการปรับโครงสร้างใหม่อย่างไรก็ตามการปรับโครงสร้างส่วนประกอบดั้งเดิม (โดยเฉพาะอย่างยิ่งถ้าฐานเดิมไม่มีหน่วยทดสอบหน่วย / ไม่ จำกัด ) จะเริ่มมีข้อบกพร่อง นักพัฒนามีแนวโน้มที่จะถูกกีดกันจากกิจกรรม "ดี" นี้หากมีความอัปยศ / ความกลัวที่เกี่ยวข้องกับการสร้างข้อบกพร่องใหม่ (แม้ว่าสิ่งเหล่านี้จะแก้ไขได้เล็กน้อยและผลลัพธ์สุดท้ายคือการปรับปรุงที่สำคัญในระบบ)
4. ผู้ทดสอบอาจยื่นจำนวนบั๊กที่ผันแปรสูงซึ่งเกี่ยวข้องกับปัญหาเดียวกันส่งผลให้มีการนับ / นักพัฒนาบั๊กที่มีความเบ้สูงเว้นแต่จะทำการวิเคราะห์รายละเอียดเพิ่มเติม

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

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

แค่ปล่อยมันไป. เจ้านายของคุณจะค้นพบด้วยตัวเองว่าเป็นสาเหตุของปัญหาหากเป็นเช่นนั้น

ให้ทื่อคุณมีความเห็นและเขาก็เช่นกัน เขาเป็นผู้จัดการของคุณและความเห็นของเขาเป็นคนที่ชนะ

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

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

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

เคารพสำนักงานแม้ว่าคุณจะไม่เคารพการตัดสินใจ

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

บอกหัวหน้าของคุณว่าการพัฒนาทีมต้องการทักษะทางสังคม เขาอาจพยักหน้า

แต่ปัญหาคือว่านี่คือสิ่งที่นักพัฒนาไม่ดีอย่างยิ่งกับ การเพิ่มเครื่องมือที่แนะนำการตำหนินั้นมีความสำคัญมากกว่าการวิเคราะห์ปัญหาที่เหมาะสมคือการต่อต้าน

แต่คุณต้องการสิ่งจูงใจเพื่อพัฒนาทักษะทางสังคมและโครงสร้างพื้นฐานการสื่อสารที่คุณควรสนับสนุน ตัวอย่างเช่นเหรียญมันบวก: ตั้งชื่อคนที่รับผิดชอบตั๋วที่ดูแลมัน

เริ่มจากบทวิจารณ์โค้ดเพื่อให้คุณสามารถเรียนรู้จากกันและกัน ที่อะไหล่โทษในภายหลัง

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

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

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

เจ้านายของฉันตัดสินใจว่าการเพิ่มฟิลด์ "บุคคลที่จะตำหนิ" ในเทมเพลตการติดตามข้อผิดพลาดของเราจะเพิ่มความรับผิดชอบ

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

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

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

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

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

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

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

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