วิธีจัดการกับความต้องการที่เปลี่ยนแปลงบ่อยๆ

ฉันกำลังจัดการกับสถานการณ์เครียด (ในความคิดของฉัน) สวยในที่ทำงานปัจจุบันของฉัน

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

นี่คือลักษณะ 'กระบวนการ':

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

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

ในขณะเดียวกันเราก็ทำงานตามกำหนดเวลาที่แน่นหนาและฉันก็รู้สึกว่าแทนที่จะก้าวไปข้างหน้ากับซอฟต์แวร์ของเรา

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

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

โดยพื้นฐานแล้วบังคับให้เกิดข้อเสนอแนะบางอย่างซึ่งฝ่ายบริหารจะรับรู้ว่าคุณกำลังจะสร้างอะไร เขียนเอกสารข้อกำหนดของคุณเองจนกว่าจะได้รับข้อความ

การ์ดเรื่องราว

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

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

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

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

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

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

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

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

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

ดันกลับ ผู้รับผิดชอบต้องดูว่าคำขอเหล่านี้มีต้นทุนเท่าใด

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

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

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

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

หากมีการเปลี่ยนแปลงเกิดขึ้นในช่วงกลางสัปดาห์พูดคำวิเศษเหล่านี้:

ฉันสามารถทำ [คุณสมบัติใหม่นี้], [การเปลี่ยนแปลงใหม่นี้], [ฯลฯ ] แต่คุณไม่ต้องการทำอะไร

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

หากความต้องการเปลี่ยนแปลงบ่อยกว่านั้นคุณอาจต้องเจรจาให้มีเสถียรภาพมากขึ้นในสภาพแวดล้อมของคุณ

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

1. ความมุ่งมั่นของฝ่ายบริหารที่จะทำให้ผู้ใช้ปลายทางมีความสุขโดยเร็วที่สุดและแสดงความก้าวหน้าอย่างรวดเร็ว

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

3. ขาดกระบวนการที่เป็นทางการสำหรับการตรวจสอบและยืนยันข้อกำหนดตามด้วยการอนุมัติ

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

5. ต้นแบบ จำกัด

6. การสันนิษฐาน / กลัวว่ามันจะต้องทำอย่างรวดเร็วและหากไม่ใช่ฝ่ายไอทีที่จะตำหนิ

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

ฉันคิดว่าคุณควรเข้าหาสิ่งนี้จากสองสามทิศทาง:

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

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

3. พยายามคิดล่วงหน้าสองสามก้าวในขณะที่ออกแบบก่อนการใช้งานแต่ละครั้ง - ออกแบบสถาปัตยกรรมที่มีความยืดหยุ่นซึ่งมีห้องรองรับการเปลี่ยนแปลง

4. พยายามปรับกระบวนการพัฒนาที่คล่องตัวเช่น SCRUM หรือ Kanban สิ่งนี้จะช่วยให้คุณมีชุดเครื่องมือสำหรับการพัฒนาผลิตภัณฑ์ที่มีความต้องการเปลี่ยนแปลง

คุณควรพิจารณาขอให้ผู้ดำเนินการย้ายคำถามนี้ไปที่ PM.stackexchange.com (โดยตั้งค่าสถานะ) แม้ว่าคำถามนี้จะตรงกับที่นี่ แต่จะเหมาะกว่า

(*) ผู้ถือหุ้นสำหรับข้อตกลง: ธุรกิจการตลาดการจัดการโครงการการพัฒนาและควบคุมคุณภาพ