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


695

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

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


79
เฮ้พวกฉัน "เจ้านาย" ที่แนะนำฟิลด์ WTF นี่คือเหตุผลที่ฉันเพิ่มฟิลด์ "Peson to Blame" ในระบบติดตามบั๊กของเรา: news.ycombinator.com/item?id=4179298
Jason

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

31
@ สันแทนการประดิษฐ์เขต Jira, พิจารณาจ้างหลังหนึ่งหรือสองทดสอบ BTW ในกรณีที่มีสาเหตุสาขาของคุณ (ไม่ว่าคุณชื่อมัน) มีลักษณะสำคัญต่ำกับผมเพราะคุณ groked แล้วการเชื่อมต่อระหว่างการขาดของการทดสอบและการเพิ่มขึ้นของข้อบกพร่องการผลิต
ริ้น

68
@ Jason ข้อผิดพลาดอยู่ในรหัสไม่ใช่ในนักพัฒนา คุณต้องเป็นหนึ่งในคนเหล่านั้นที่คิดว่าบทวิจารณ์โค้ดนั้นมีไว้สำหรับตรวจสอบนักพัฒนาไม่ใช่รหัส
Danny Varod

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

คำตอบ:


676

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

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


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

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

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

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

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


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

326
+1 สำหรับการเปลี่ยนเส้นทางความคิดของเจ้านายเป็นสิ่งที่มีประสิทธิผลมากขึ้น (เสมอง่ายที่จะชนะการสู้รบที่เดียว)
benzado

16
"สาเหตุหลัก" ยังครอบคลุมถึง (หวังว่าส่วนใหญ่!) ของกรณีที่ไม่มีบุคคลเดียวที่จะตำหนิสิ่งต่าง ๆ เช่น "ความล้มเหลวของซอฟต์แวร์ของผู้จัดจำหน่าย", "ข้อผิดพลาดเอกสาร API", "ปริมาณที่สูงกว่าที่คาดหวัง"
James Anderson

29
ยิ่งใหญ่ แม้แต่ตัวอย่างของคุณสำหรับผู้รับผิดชอบเพียงคนเดียวก็มีคนสองคนแสดงให้เห็นถึงความโง่เขลาของการฝึก
Urs Reupke

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

272

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


300
เจ้านายจะมีความสุข! จะมีรายงานข้อบกพร่องน้อยลงดังนั้นคุณภาพจะต้องสูงขึ้น
nicodemus13

5
หัวหน้าอาจจะเกี่ยวกับการจ่ายเงินที่เกี่ยวข้องกับการปฏิบัติงานและตัวบ่งชี้ประสิทธิภาพหลักหนึ่งตัวคือจำนวนข้อบกพร่องที่รายงาน หวังว่าเขา / เธอจะแบ่งปันโบนัสของเขาให้กับทีมพัฒนาปลายปีนี้
Matt Wilko

54
จากประสบการณ์นี้ไม่ได้เป็นผลลัพธ์ที่ "น่าจะเป็น" แน่นอนว่ามันจะเกิดขึ้นอย่างแน่นอน 100% เพราะนักพัฒนาเป็นคนฉลาด สิ่งที่คุณจะเห็นก็คือเวลาเพิ่มขึ้นอย่างมากที่ใช้โต้เถียงอย่างรุนแรงกับผู้ทดสอบว่า "บั๊ก" ของพวกเขาไม่ใช่บั๊ก
Joris Timmermans

บุคคลที่รายงานข้อผิดพลาดจะไม่เป็นคนที่root causeฉันหมายถึงคิดว่าจะพยายามหาข้อผิดพลาดในรหัสของคุณหลังจาก 36 ชั่วโมงในการเขียนรหัสในสัปดาห์นี้?
มาลาคี

141

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

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

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

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

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


5
กระบวนการที่ดีจริงๆหลีกเลี่ยงนักวิเคราะห์และโปรแกรมเมอร์ที่จะเป็นคนสองคนที่แตกต่างกัน - ประสบการณ์ของฉันกับนักวิเคราะห์ที่ไม่สามารถเขียนโปรแกรมและโปรแกรมเมอร์ที่ไม่สามารถวิเคราะห์ได้นั้นแย่มาก อย่างไรก็ตาม +1 สำหรับคำตอบของคุณ
Doc Brown

@DocBrown ประสบการณ์ของฉันกับนักวิเคราะห์และโปรแกรมเมอร์ที่จะเป็นคนสองคนที่แตกต่างกันได้ค่อนข้างดีจนถึงขณะนี้ แต่ในกรณีของฉันมันเป็นมากกว่านักวิเคราะห์ที่สามารถเข้าใจตรรกะของโปรแกรมและโปรแกรมเมอร์ที่สามารถมีส่วนร่วมในการวิเคราะห์ :)
ริ้น

@gnat: การที่ IMHO มีนักวิเคราะห์ที่มีโปรแกรมเมอร์คนหนึ่งในทีมของคุณสามารถปรับปรุงความเร็วและคุณภาพการพัฒนาของคุณได้ตามลำดับความสำคัญ
Doc Brown

3
หนังสือเล่มนี้จะช่วยให้คุณค้นหาคำศัพท์ที่จะช่วยให้คุณเข้าใจได้amazon.com/The-Power-Positive-No-Relationship/dp/0553384260/…
zundarz

2
ลิงก์สำหรับ "เสนอได้อย่างอิสระ" นั้นยากจน
Tom Fobear

79

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

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

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

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

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


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

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

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

68

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

ไม่ถูกต้อง:

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

ขวา:

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


6
ยิ่งไปกว่านั้น: แนวทางการเข้ารหัส / มาตรฐานและรายการตรวจสอบการตรวจสอบโค้ดได้รับการอัปเดตเพื่อหลีกเลี่ยงเหตุการณ์นี้อีกครั้ง
Oddthinking

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

3
@Adam: คำตอบของฉันไม่ได้ตอบคำถามของคุณโดยตรงว่า "มีอะไรผิดปกติกับการตำหนิใครสักคน ... ?"
วินไคลน์

54

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

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


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

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

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

49

คำตอบง่ายๆ

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

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

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


8
+1, วัฒนธรรมแห่งการตำหนิมักจะนำไปสู่วัฒนธรรมการเก็บเงียบเกี่ยวกับข้อบกพร่องและหวังว่าจะไม่มีใครสังเกตเห็น
Carson63000

45

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

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

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


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

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

3
นอกจากนี้ทีมยังคงประสบอยู่ ทั้งหมดเพื่อพิสูจน์ว่าเจ้านายนั้นผิด
Oleg V. Volkov

29
ฉันมักจะใส่ชื่อผู้จัดการที่นั่น "ในองค์กรใดก็ตามงานจะจมลงสู่ด้านล่างในขณะที่ความรับผิดชอบลอยไปด้านบน"
David Schmitt

3
@ David: ทั้งครีมและฝาลอยไปด้านบน คุณเกี่ยวข้องกับอะไรในองค์กรของคุณ
Donal Fellows

32

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

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

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

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

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

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


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

20

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

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


20

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

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

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

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

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


19

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

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

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


19

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

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

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


18

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

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

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

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

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

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

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


+1 สำหรับการแนะนำการอธิบายเชิงบวกถึงวิธีการจัดการผู้ปฏิบัติงานข้อมูลแทนที่จะโจมตีแนวคิดนี้เพียงอย่างเดียว
Oddthinking

14

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

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

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

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

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

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

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

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

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

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

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


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

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

10

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

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


9

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


2
คุณไม่สามารถ "แก้ไขคน" ...
SandRock

1
เรามีช่อง "บุคคลที่ต้องแก้ไข" ไม่เพียงพอ
MK_Dev

9

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

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

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

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

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


8

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

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

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

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

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

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

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

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

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

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


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

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

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

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

@hasanyasin เกี่ยวกับความดีของ bug - มันยอดเยี่ยมมาก! ฉันเสียใจฉันไม่สามารถใส่ผู้โหวตสองคนได้! ฉันจะใช้มันเองเช่นกัน!
Gangnus

8

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

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

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

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


3
เพื่อทำให้เรื่องแย่ลง devs ก็เป็น QA เช่นกัน ฉันรู้ ...
MK_Dev

ช่างเป็นทัศนคติที่รบกวน
pdr

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

@ Sgoettschkes ในทางทฤษฎีฉันเห็นด้วยกับคุณ 100% ทีมโดยรวมเป็นผู้รับผิดชอบผลิตภัณฑ์ที่ผลิต แต่ถ้าคุณพยายามที่จะแยกแยะบุคคลที่เฉพาะเจาะจงคนที่ตรวจสอบงานเป็นคนที่รับผิดชอบในการปล่อยให้ผ่าน

7

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

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

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


ฉันเห็นด้วยกับข้อความแรกของคุณ 100% นั่นเป็นคำพูดของฉันเมื่อฉันพูดถึงเรื่องนี้
MK_Dev

7

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

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


6

เพื่อให้เครดิตแก่เจ้านายแนวคิดของ "การมอบหมายโทษ" ได้ถูกอบเข้าสู่เครื่องมืออย่าง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, ผลลัพธ์ที่คาดหวังไม่ถูกต้องในการทดสอบและปัญหา "ก่อนหน้านี้ในห่วงโซ่" กับข้อกำหนดที่ไม่ถูกต้อง / ขาดหายไปและควรเห็นได้ชัดเจนว่า เป้าหมายคือเพื่อทำลายขวัญกำลังใจและทำให้เกิดการอพยพเป็นจำนวนมาก)

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


6

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

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

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

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

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

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

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


+1 สำหรับวิธีแก้ปัญหาที่สมเหตุสมผล (แม้ว่าฉันได้เพิ่มคำตอบของฉันเอง) :-)
Homer6

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

5

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

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

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

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


เตือนเขาว่าในกรณีส่วนใหญ่เขาสามารถเป็นคนที่จะตำหนิได้ ความดันเวลาสมาชิกในทีมลำดับความสำคัญของการจัดการเลือก / เครื่องมือได้รับการอนุมัติ ...
BillThor

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

4
-1 developer == no social skillsบอกว่า ทั้งสองไม่เกี่ยวข้องกันอย่างสิ้นเชิง คุณสามารถทำได้ดีที่หนึ่งหรือทั้งสองและไม่ดีที่หนึ่งหรือทั้งสองและไม่มีการเชื่อมต่อ
Daenyth

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

@hakre: ถ้าเป็นกรณีที่เขาทำงานก็เป็นเพราะคนที่เก่งกว่าได้ลาออกจาก บริษัท เนื่องจากการบริหาร
Daenyth

2

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

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


1

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

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

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

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

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

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


-3

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

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

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

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.