วิธีจัดการและประเมินความต้องการที่ไม่มีโครงสร้างที่ได้รับจากลูกค้า


21

หลายครั้งในระหว่างขั้นตอนการเสนอราคาของโครงการฉันได้รับข้อกำหนดของระบบซอฟต์แวร์จากผู้มีโอกาสเป็นลูกค้าของเราในรูปแบบที่ไม่มีโครงสร้างมากจากแหล่งต่าง ๆ [อีเมล, เอกสารคำ, excel] โดยปกติจะเป็นกลุ่มของ "การพัฒนาผลิตภัณฑ์" จากฝ่ายลูกค้าที่มาพร้อมกับ "โซลูชันที่เสนอ" เหล่านี้เพื่อแก้ไขปัญหาทางธุรกิจที่พวกเขามี ในขณะที่พวกเขาเป็นผู้เชี่ยวชาญในโดเมนธุรกิจหลายครั้งที่พวกเขาไม่มีทางแก้ไข

ผลลัพธ์นี้ใน

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

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

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

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


1
มีใครในทีมของคุณที่ทำงานกับ "การพัฒนาผลิตภัณฑ์" เพื่อทำการวิเคราะห์ความต้องการ (เช่นนักวิเคราะห์ธุรกิจ) หรือไม่
Deco

ใช่ฉันทำอย่างนั้นในทุกกรณีที่เราไม่มีงบประมาณใน BA
user20358

คำตอบ:


17

ความต้องการจะเติบโตและเปลี่ยนแปลง ฉันไม่คิดว่าจะมีใครโต้แย้งได้

วิธีการเก็บรวบรวมและประมวลผลการร้องขอเข้ามา

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

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

วิธีการติดตามและจัดระเบียบข้อกำหนด

ในระยะสั้นไปเทคโนโลยีต่ำ

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

ในระยะยาวให้ใช้เครื่องมือซอฟต์แวร์ที่สามารถค้นหาได้จัดเรียงและเชื่อมโยงได้

สำหรับความพยายามในระยะยาวซอฟต์แวร์บางประเภทจะมีค่า มีเครื่องมือการจัดการความต้องการพิเศษ: ประตู, Clearcase / Clearquest และอื่น ๆ อีกมากมาย เครื่องมือพิเศษเหล่านั้นยอดเยี่ยมในสิ่งที่พวกเขาทำ แต่มักจะเกินกำลัง บางครั้งแม้แต่สเปรดชีตเก่าธรรมดาก็เพียงพอแล้ว ฉันเองพบว่าระบบการติดตามปัญหาทั่วไปมีประโยชน์พอสมควรในการทำสิ่งนี้และตอนนี้ฉันก็ชื่นชอบคือ redmine แต่คนอื่น ๆ ก็มั่นใจเช่นกัน

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

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

ประกาศผลรางวัลสัญญา / ประกาศความต้องการแจ้งกำหนดการพัฒนาโครงการ

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

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

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

แสดงตัวเลือกว่า 'เกิดอะไรขึ้น' และให้ทางเลือกและการตัดสินใจแก่ลูกค้า

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

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

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

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


4

ฉันจะมองว่านี่เป็นกระบวนการที่วนซ้ำ ขั้นตอนที่ 1 คือการรวบรวมความต้องการ ขั้นตอนที่ 2 คือการจัดเรียงพวกเขา ขั้นตอนที่ 3 คือการจัดลำดับความสำคัญ ขั้นตอนที่ 4 คือการแบ่งแต่ละครั้งลงในบิตขนาดเล็กพอที่จะประเมินความพยายาม ขั้นตอนที่ 5 คือการรวมบิตเหล่านี้เข้าด้วยกันเป็นถังความพยายามระดับโลก (สมมติว่า 84 คนต่อวัน) ขั้นตอนที่ 6 คือการแมปความพยายามกับทรัพยากร (84 person-days / 2 devs = 42 วัน)

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

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

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

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

ดั๊ก

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.