คุณจัดการกับต้นทุนของการเปลี่ยนแปลงที่รวดเร็วเกินไปได้อย่างไร

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

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

มีการเรียงลำดับของบทบาทผลิตภัณฑ์ - เจ้าของ - ผู้จัดการ, การศึกษาในเชิงลึก, คำอุปมา, หรือคำพูดที่สามารถช่วยฉันลดจำนวนของความพยายามที่สูญเปล่าหรืออย่างน้อยอธิบายค่าใช้จ่ายของพฤติกรรมที่วุ่นวายนี้?

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

นี่คือวิธีที่ฉันจัดการกับปัญหาที่คล้ายกัน .. ย้อนกลับไปในวันที่เรามีความคล่องตัวมาก่อนเปรียว

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

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

ฉันปิดประตูไปยังสำนักงาน SD ล็อคและหยิบโทรศัพท์ออกจากตะขอ อีเมลถูกข้ามไปจนถึงเวลา 10:00 น., 12:00 น. และ 14:00 น. แม้จะมีคนคิดและรู้สึกว่าโลกยังคงรอบดวงอาทิตย์เราทำงานของเราเสร็จแล้วและ "ลูกค้า" ได้รับซอฟต์แวร์ที่ส่งมอบให้กับพวกเขาเร็วกว่าและดีกว่าทุกครั้งในอดีต

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

SOP ขั้นตอนการปฏิบัติงานมาตรฐาน (หรืออย่างน้อยโปรโตคอลที่ลงชื่อโดยทีมการจัดการของคุณ) แผนกของคุณต้องการที่จะพัฒนาหรือทำงานกับทีมผู้บริหารของคุณในการพัฒนา คนที่คุณต้องการคุยด้วยอยู่เหนือผู้จัดการผลิตภัณฑ์ / ผู้จัดการบัญชี

ตัวอย่างบางส่วนของสิ่งที่ SOP ของคุณควรกำหนด

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

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

ผลลัพธ์ที่ได้คือไม่พอใจคุณและนั่นไม่ได้อยู่ในความสนใจที่ดีที่สุดของ บริษัท คุณ

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

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

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

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

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

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

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

ดูเหมือนว่ายังไม่มีใครพูดถึงSprintและเรื่องราวของผู้ใช้ideally should be locked till the next sprint(การวิ่งทั่วไปใช้เวลา 2-4 สัปดาห์) โดยการล็อค - ฉันหมายถึงไม่ควรเพิ่มงานเพิ่มเติมลงใน Sprint ที่เริ่มทำงานแล้ว

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

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

Scrum มีบทบาท Scrum Master ซึ่งจะเป็นบุคคลที่ควรแก้ไขปัญหาที่คุณกล่าวถึง

หากมีใครบางคนเช่นหัวหน้าทีมผู้จัดการโครงการหัวหน้าทะเลาะวิวาท ฯลฯ ที่รับผิดชอบฉันจะพูดคุยกับบุคคลนั้น

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

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

ประกาศเปรียวบอกว่าหนึ่งในหลักการพื้นฐานที่สุดคือ:

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

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

อีกครั้งในขณะที่ขั้นตอนการทำงานของยอดขายของผลิตภัณฑ์อาจเปลี่ยนแปลงในแต่ละสัปดาห์ฉันคิดว่าผลิตภัณฑ์โดยรวมจะไม่เปลี่ยนแปลงในแต่ละสัปดาห์ ฉันไม่สามารถจินตนาการถึง Microsoft ที่ให้ Office แก่เราในวันนี้ แต่พรุ่งนี้จะให้บริการ Offooose แก่เราและอีกหนึ่งสัปดาห์ต่อมา Offasooooooooooooos

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

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