การแย่งชิง: มันเป็นการดีสำหรับการออกแบบ / UX ของเรื่องราวของผู้ใช้ที่จะเกิดขึ้นในการวิ่งเช่นเดียวกับการใช้งาน

ขณะนี้ฉันกำลังวิ่ง (สองสัปดาห์) ที่นักออกแบบมอบหมายให้กำหนดข้อกำหนดและ UX ของเรื่องราวผู้ใช้เฉพาะ

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

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

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

ตอนนี้ฉันจะต้องถาม / ทำงานกับนักออกแบบเพื่อให้งานของเขาเสร็จ สิ่งนี้จะทำให้ฉันหมดแรงเมื่อฉันทำภารกิจอื่นทั้งหมดของฉันเสร็จแล้ว

ดังนั้นคำถามของฉันคือ

คุณจะจัดการการพึ่งพาในการวางแผนวิ่งได้อย่างไร

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

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

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

อย่างไรก็ตามคุณไม่ได้ทำอย่างนั้นและตอนนี้คำถามของคุณคือ ...

ฉันจะเข้าใกล้การวิ่งได้อย่างไร

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

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

ก่อนอื่นมีความแตกต่างอย่างมากระหว่างการพึ่งพาระหว่างเรื่องราว / ภารกิจและความไม่แน่นอนในขอบเขต / ความพยายามของเรื่องราว / ภารกิจ

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

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

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

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

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

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

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

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

• เรื่องพร้อม
• เรื่องราวเสร็จสิ้น

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

หากเรื่องราวยังไม่พร้อมอย่าฝังไว้ในการวิ่งของคุณ หากเงื่อนไขการยอมรับไม่เป็นไปตามเงื่อนไขก็จะไม่เสร็จสิ้น

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

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

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

หากคุณต้องโพล่งออกมาในขณะที่การออกแบบคือ 'กระแทก' ระหว่างลูกค้าและ PO กว่า PO ของคุณต้องแจ้งทีมงานเกี่ยวกับคุณสมบัติใหม่ใด ๆ ทันทีที่ปรากฏ: นี่คือความหมายของ 'ความยืดหยุ่น' ในการต่อสู้ - ปรับให้เข้ากับความต่อเนื่อง สถานการณ์. ทีมพัฒนา, Scrum Master และเจ้าของผลิตภัณฑ์จำเป็นต้องสื่อสารอย่างถาวรไม่เช่นนั้นจะไม่มีปฏิกิริยาแบบเรียลไทม์ในการเปลี่ยนแปลง

การฝึกอบรมเพิ่มเติมบางอย่างไม่เป็นอันตราย ... บางทีการทำงานกับนักออกแบบอาจเป็นโอกาสให้คุณได้รับทักษะ UX ใหม่บ้างไหม? ... นั่นคือการสังเกตว่าแก้วเต็มครึ่งแทนที่จะเป็นครึ่งที่ว่างเปล่า :))