รายงานรายวันสามารถลดประสิทธิภาพของนักพัฒนาได้หรือไม่ [ปิด]

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

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

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

1. ไม่จำเป็นต้องทำตามรูปแบบเฉพาะ ยอมรับทุกรูปแบบและทุกรูปแบบ
2. แม้ว่างานจะไม่เสร็จ แต่เราต้องการฟังความคืบหน้า
3. ไม่จำเป็นต้องพูดถึงเวลาที่ใช้ในแต่ละภารกิจ
4. ควรกล่าวถึงข้อกำหนดในการพัฒนาอุปสรรคและการประสานงาน
5. ไม่จำเป็นต้องหมกมุ่นอยู่กับรายงานประจำวัน มันไม่ได้เข้มงวดอย่างนั้น

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

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

ช่างเป็นความคิดที่แย่ขนาดไหน

คุณคิดว่าสิ่งนี้สามารถลดความสามารถในการผลิตได้หรือไม่?

ใช่.

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

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

รายงานรายวันจะไม่ได้รับการอ่าน พวกเขาพัฒนาไปสู่สัญญาณรบกวนในกล่องอย่างรวดเร็ว

"ไม่จำเป็นต้องหมกมุ่นอยู่กับรายงานประจำวัน" ในกรณีนี้ทำไมพวกเขา?

คุณมีข้อเสนอแนะใด ๆ สำหรับเราเพื่อให้แน่ใจว่าเราไม่ได้เป็นจุลภาคหรือไม่?

ใช่. ยืนขึ้นทุกวัน ใช้เวลาสองสามนาทีและเสร็จแล้ว

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

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

ต้องบอกว่า ...

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

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

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

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

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

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

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

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

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

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

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

ดังนั้น: ในบางกรณีรายงานรายวันทำให้ประสิทธิภาพการทำงานลดลง โดยเฉลี่ยแล้วฉันไม่มีความรู้สึกว่าพวกเขาทำให้งานของเรามีประสิทธิภาพมากขึ้น

UPDATE

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

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

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

เราไม่ต้องการที่จะสูญเสียส่วนที่ดีของการต่อสู้ทุกวันเช่นได้รับโอกาสในการประสานงานนักพัฒนาทุกวัน

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

หรือดูความคืบหน้าการทำงานเช่นตัวบ่งชี้ประสิทธิภาพหลักเพื่อดำเนินการก่อน

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

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

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

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

เป็นความคิดที่ดีในการปรับแต่งวิธีการ Agile ของคุณเพื่อให้เหมาะกับคุณ - ดังนั้นขอชื่นชมในสิ่งนั้น

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

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

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

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

คุณไม่สามารถดึงข้อมูลนี้จากเครื่องมืออื่น ๆ ของคุณ?

• คุณกำลังทำอะไรอยู่ ตั๋วที่ฉันได้รับมอบหมาย
• ความคืบหน้าของคุณคืออะไร สำหรับตั๋วที่ฉันมีระยะเวลานานกว่า 1 วันโปรดดูความคิดเห็นในตั๋วหรือส่งข้อความถึงสาขา ตั๋วฉันสั้นกว่า: อาจจะเสร็จในวันพรุ่งนี้ (คุณไม่ต้องซื้อตั๋วขนาดใหญ่ 5+ วันใช่มั้ย)
• ความคืบหน้าทั่วไปคืออะไร? ดู open / closed-tickets-ratio
• สิ่งที่จะต้องจัดระเบียบ? ตั๋วที่คุณได้รับมอบหมายกลับมาพร้อมกับข้อเสนอแนะสถานะและทุกอย่างที่กล่าวถึงใน IRC ของทีมของคุณห้องกองไฟไม่ว่าอะไรก็ตาม

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