จะทำอย่างไรกับ“ การพัฒนาที่ล้มเหลว”

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

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

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

สิ่งนี้นำไปสู่คำถามของฉัน: มีใครพบกับสิ่งนี้อีกหรือไม่และหากเป็นเช่นนั้น

แน่นอนว่าเราได้พยายามให้ Camp A และ B ยอมรับก่อน แต่ทุกคนรู้ว่านี่ไม่ใช่กรณี

ขอบคุณ

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

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

Camp A จะบอกว่า Feature X ทำงานอย่างนี้แล้ว Camp B จะล้มเหลวเนื่องจากไม่ทำงานเช่นนั้น

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

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

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

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

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

การจัดการจะขึ้นอยู่กับว่า Camp A และ Camp B เป็นอย่างไร

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

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

ในทุกกรณีความสมบูรณ์แบบคือศัตรูที่ดีพอ

สิ่งที่คุณอธิบายคือการใช้ Agile ที่ผิดปกติ คุณไม่ได้โอบกอดเปลี่ยนคุณเป็นทาสของมัน

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

ฉันขอแนะนำให้คุณจ้างโค้ช Agile และ / หรือส่งทีมของคุณไปฝึกอบรม

ทางออกอีกอย่างคือหยุดทำ Agile

หากพวกเขากำลัง ping-ponging (A บอกว่าทำ x, B ปฏิเสธ, บอกว่า y, จากนั้น A ปฏิเสธและกลับไปที่ x) จากนั้นโอกาสในการขายของคุณ (PO หรืออะไรก็ตามที่คุณมี) จำเป็นต้องเอาชนะพวกเขาเพื่อตัดสินใจ .

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

ปัญหาที่นี่ดูเหมือนจะไม่ "ฉันจะรู้เมื่อฉันเห็นมัน" Wireframes สามารถช่วย (ถึงจุด) กับปัญหาเฉพาะที่

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

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

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

หมายความว่าคุณมีความเสี่ยงที่จะทำให้ลูกค้าไม่สบายใจหรือดูไม่ดีไม่ว่าคุณจะทำอะไรเนื่องจากสิ่งที่คุณทำเพื่อ B อาจทำให้ A ไม่พอใจ (หรือกลับมาอีกครั้ง)

หวังว่าคุณจะสามารถหาแชมป์ที่ลูกค้าที่สามารถดูแลคลุกวงในสำหรับคุณ

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

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

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

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

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

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

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

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

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

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

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

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

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

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