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


11

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


5
ใช้ทุกสิ่งที่คุณคาดว่าจะอยู่ในเทคโนโลยีที่เป็นที่รู้จักและย้ายทศนิยมหนึ่งตำแหน่ง: P
Rig

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

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

นี่คือสิ่งที่ต้นแบบมีไว้สำหรับ

@ Carson63000 ฉันมีกรวยของความไม่แน่นอนที่เรียบง่ายในการใช้ถ้อยคำนั้น สิ่งสำคัญที่จะนำออกไปจากภาพประกอบนั้นคือการประมาณ 2-12 เดือนไม่ได้หมายความว่ามันจะจบลงที่ 7 เดือนในตอนท้าย แต่การประมาณอาจมาจาก 2-12 ถึง 4-12 ถึง 8-12 ถึง 10-12 ถึง 12 นอกจากนี้โปรดทราบว่ากรวยเดิมมีช่วงของ 16x เมื่อแนวคิดเริ่มต้นเสร็จสิ้น

คำตอบ:


13

สุจริตตามที่ Nassim Nicholas Taleb เขียนไว้ในหนังสือของเขา The Black Swan: 'เราไม่สามารถคาดเดาได้' สาเหตุหลักมาจากสิ่งแปลกปลอม โดยทั่วไปแล้วสิ่งที่ดีที่สุดคือการสื่อสารความจริงข้อนี้ความจริงที่คุณไม่สามารถคาดการณ์ได้แทนที่จะสื่อสารการประมาณ

ตามที่ Taleb เขียน: มันเป็นการดีที่จะถูกต้องในวงกว้าง ดังนั้นให้แน่ใจว่าได้สื่อสารความจริงที่ว่าคุณมีเวลาที่ยากลำบากในการประเมินและใช้สิ่งต่าง ๆ เช่น 'เส้นโค้งการเรียนรู้ในเทคโนโลยีใหม่' เป็นหนึ่งในข้อโต้แย้ง ซึ่งหมายความว่าช่วงประมาณการของคุณจะใหญ่: 'โครงการนี้จะมีราคาระหว่าง 100k ถึง 500k'

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


3
+1: นี่เป็นคำตอบเดียวที่ถูกต้อง สอนให้คุณรู้จักจัดการกับสิ่งแปลกปลอม - ง่ายกว่าการประมาณค่า - นอกจากนี้ควรค้นหางานของ Steve McConnoll ที่ construx.com
mattnz

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

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

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

3

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

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

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

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

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


3

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

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


1

ขึ้นอยู่กับว่าฉันใช้ FPA (การวิเคราะห์จุดของฟังก์ชั่น ) เป็นส่วนใหญ่ แต่เราอยู่ใน "การพัฒนาเว็บ enterprizey" ฉันหมายความว่าคุณรู้ว่า บริษัท เว็บ Forbes 500

มีงานที่สามารถแบ่งออกเป็นสองส่วน: หนึ่งซึ่งเหมาะกับ FPA ดีจริง ๆ : คุณมีอินเทอร์เฟซการป้อนข้อมูลอินเทอร์เฟซการส่งออกแฟ้มภายในแบบลอจิคัล (aka. ตาราง / ชนิดของฐานข้อมูลที่จะส่งออก) .

ในเวอร์ชั่นง่ายงานที่ซับซ้อนเป็นส่วนประกอบที่เขียนไปแล้วมันเป็นเรื่องยากและไม่รู้จักที่จะเชื่อมต่อกับมัน

รุ่นยากคือเมื่อมันต้องถูกเขียนแล้วการประเมินตามนักบิน COCOMO อะไรก็ตาม

อย่างไรก็ตามมีความสำคัญสองประการ:

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

  2. เมื่อฉันมีผู้จัดการที่อ่านนิยายของแบล็กสวอนและคลั่งไคล้มัน เขาบอกเราว่ามันเป็นไปไม่ได้ที่จะประมาณและฉันก็ทำตามปกติของฉันแม่นยำถึง + -10% ประมาณอย่างไม่ลดละ ...


-2

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

ขออภัยที่ไม่ได้ช่วยเลย


-4

ประมาณระยะเวลาที่ต้องใช้ในการทำโครงการที่คล้ายกันโดยใช้เทคโนโลยีที่คุ้นเคย คูณด้วย 4 เพิ่มเวลาการเรียนรู้

หากค่าประมาณสั้นเกินไปคุณจะดูไร้เดียงสาและหยิ่ง หากค่าประมาณนั้นใหญ่เกินไปคุณจะดูโง่เขลาและไร้ความสามารถ เลือกอย่างชาญฉลาด


4
ทำไมต้อง 4 ทำไมไม่ 5 10? 33.3? ... มีวิทยาศาสตร์อยู่เบื้องหลังคำตอบของคุณหรือคุณเพียงแค่เลือกตัวเลขสุ่ม? การรวมไว้ในคำตอบของคุณอาจทำให้มีประโยชน์มากขึ้น
ไบรอัน Oakley

ในโน้ตที่เกี่ยวข้องอย่าอายที่มีจำนวนมาก เพื่อนร่วมงานของฉันเคยประมาณว่าการทำงานซ้ำของโมดูลใน 935 วัน (เก้าสิบห้า) บอสบอกว่าเรามีไม่มากและสั่ง 60 วัน เพื่อนร่วมงานทำในสิ่งที่เป็นไปได้ใน 60 ผลลัพธ์ค่อนข้างลำบาก แต่เขาไม่เคยถูกตำหนิในเรื่องนั้น ต้องยอมรับว่ารุ่น 60 วัน แต่มีปัญหาทำให้เราได้ลูกค้าที่สำคัญมาก - นั่นคือการผลักดันของเจ้านายทำให้ความรู้สึกทางธุรกิจที่ดีงาม BTW ในท้ายที่สุดเรามีการจัดการที่จะได้รับโมดูลที่อยู่ในรูปร่าง แต่ที่เกิดขึ้นหลายปีต่อมาและความพยายามที่จะเอาได้มากขึ้นในสนามเบสบอลที่มี935ประมาณการ
ริ้น
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.