เหตุใดจึงยากที่จะให้พนักงานอัปเดตตัวติดตามปัญหา

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

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

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

เหตุผลก็คือพวกเขาไม่คิดว่าทำไมพวกเขาควรอัพเดทตัวติดตามปัญหานอกเหนือจากความจริงที่ว่าคุณพูดเช่นนั้น

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

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

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

นำโดยตัวอย่าง

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

นี่คือสิ่งที่จะทำให้ฉันใช้ตัวติดตามตลอดเวลา:

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

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

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

ก่อนอื่น: คุณหมายถึงอะไรกับ "ผู้คนกำลังอัพเดตความก้าวหน้าของพวกเขา"?

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

จากมุมมองของนักพัฒนามันเป็นส่วนผสมของความคิดและวัฒนธรรม

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

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

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

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

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

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

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

ในการให้สิทธิ์ระบบติดตามบั๊กฉันจะแนะนำสิ่งต่อไปนี้:

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

ในการดำเนินการคุณสามารถใช้สิ่งต่อไปนี้:

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

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

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

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

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

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

ตัวเลือกอื่นคือมีการประชุมสถานะ (หรือระหว่างช่วงเวลารายวัน) ที่มีคนเปิดงานติดตามและอัปเดตตามที่ผู้คนแจ้งสถานะ

สิ่งหนึ่งที่ต้องคำนึงถึงก็คือ GUI เองเป็นอุปสรรค ตัวอย่างเช่นอุปสรรคบางอย่างอาจรวมถึง:

• คลิกมากเกินไป
• เซิร์ฟเวอร์แอปพลิเคชันติดตามฉบับที่ไม่ได้เพิ่มประสิทธิภาพหรือต่ำกว่า
• การใช้งานหรือการเข้าถึงต่ำ

การเปิดเผย API จะทำให้ตัวติดตามปัญหาได้รับการอัปเดตผ่านสคริปต์เช่นเดียวกับสิ่งประดิษฐ์ทางเทคนิค (การครอบคลุมรหัสรายงานการทดสอบหน่วยสถานะการสร้าง ฯลฯ )

อ้างอิง

• Scrumwise - API

• การอ้างอิง JIRA Cloud REST API

• API บริการ REST ของ Alfresco