การกำหนดราคาสำหรับรหัสแหล่งที่มาและผลิตภัณฑ์ซอฟต์แวร์เชิงปริมาณ


9

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

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

ข้อมูลเพิ่มเติม:แอปพลิเคชันต้องทำงานทุกที่ในระบบปฏิบัติการใด ๆ รวมถึงแท็บเล็ต (iPad, แท็บ Galaxy, ฯลฯ ), สมาร์ทโฟน (iPhone, โทรศัพท์ Android, ฯลฯ ) และบนเว็บ (ตอนนี้คิดเท่าใดรหัสนี้จะเป็น)


2
เมื่อใครบางคนจะพบว่าปริมาณของราคาผลิตภัณฑ์ซอฟต์แวร์อย่างน่าอัศจรรย์โดยอิงจากการเปลี่ยนแปลงอยู่ตลอดเวลาความต้องการของผู้ใช้ที่ไม่ชัดเจนและไม่สมบูรณ์บ่อยครั้งที่โลกจะดีขึ้น แต่ยังคง +1 กับคำถาม
Arseni Mourzenko

วิธีการที่เชื่อถือได้เพียงอย่างเดียวของซอฟต์แวร์ราคา: (1) เขียนและทดสอบโปรแกรม; (2) วัดความพยายามของคุณ (3) ขายซอฟต์แวร์ตามความพยายามที่คุณมี
Doc Brown

คุณควรตรวจสอบAppcelerator , AirและHaxe (ซึ่งสามารถกำหนดเป้าหมายทั้งสองหรือใช้NME )
back2dos

นี่ไม่ใช่เฉพาะการเขียนโปรแกรมหรือซอฟต์แวร์มันเป็นคำถามทั่วไปเกี่ยวกับการกำหนดราคาที่ปลอมแปลงเป็นคำถามที่เกี่ยวข้องกับการเขียนโปรแกรม

I am about to undertake a project. This requires me to write code.... โปรแกรมเมอร์ + โครงการ = รหัส (ปกติ) ทำไมรัฐชัดเจน?
แบบไดนามิก

คำตอบ:


12

คุณไม่สามารถรู้ราคาที่แน่นอนหรือเกือบจะแน่นอนเพราะมันขึ้นอยู่กับหลายปัจจัย ตัวอย่าง:

กรณีศึกษา

คุณได้รับคำขอสำหรับเว็บไซต์ขนาดเล็กตาม WordPress สิ่งเดียวที่คุณต้องทำ: ทำงานร่วมกับนักออกแบบของคุณเพื่อสร้างกราฟิกที่น่าสนใจจากนั้นสร้างเว็บไซต์เอง (ไม่มีเทคนิคขั้นสูงเพียงแค่ชุดปลั๊กอินที่จะเพิ่มใน WordPress) จากนั้นปรับใช้ งานเป็นเรื่องง่ายมากคุณเสนอราคา $ 600

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

แต่น่าเสียดายที่นักออกแบบถูกรถบัสชนและสิ่งเดียวที่คุณได้รับคือ JPEG ที่เขาส่งให้คุณ แต่ไม่ใช่ PSD ดั้งเดิมดังนั้นคุณต้องเริ่มต้นด้วยนักออกแบบใหม่ ในที่สุดคุณได้กราฟิกและเริ่มงานของคุณ

ประหลาดใจ: คุณค้นพบว่าปลั๊กอิน A เข้ากันไม่ได้กับปลั๊กอิน B ว่าปลั๊กอิน C ไม่ทำงานตามที่คาดไว้และปลั๊กอิน D ไม่สามารถติดตั้งบน WordPress รุ่นใหม่ล่าสุดในขณะที่ปลั๊กอิน A สามารถติดตั้งได้เท่านั้น ในรุ่นใหม่ล่าสุดนี้ ตอนนี้คุณต้องเขียนโค้ด PHP ด้วยมือมากมายและเนื่องจากคุณเป็นนักพัฒนา Python และไม่เคยเขียนโค้ดบรรทัดเดียวใน PHP จึงไม่ใช่งานที่ง่ายที่สุด

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

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

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

ทำไมมันเกิดขึ้น

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

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

หนึ่งสามารถแก้ปัญหาเหล่านั้นด้วยวิธีการเฉพาะ:

  • ความต้องการในการใช้งานและไม่ใช่หน้าที่ชัดเจนและแม่นยำ
  • การจัดการสถานการณ์ Hit-by-a-bus (เช่นนักออกแบบต้องแชร์เอกสารทุกฉบับกับคุณเพื่อให้เขาตายได้ทุกเมื่อโดยไม่กระทบต่อโครงการ)
  • ความรู้ก่อนหน้าของเครื่องมือและภาษาที่คุณต้องใช้ (ซึ่งต้องใช้งานมาก )
  • การจัดเตรียมการทดสอบอย่างเข้มข้น ฯลฯ

ปัญหาเดียวคือด้วยวิธีนี้คุณต้องบอกลูกค้าของคุณว่าเขาจะจ่ายเงินอย่างน้อย $ 5,000 ในตอนแรกเนื่องจากเป็นราคาข้อกำหนดข้อกำหนดการออกแบบการทดสอบและอื่น ๆ โอกาสสำหรับลูกค้ารายนี้ที่จะยอมรับ คำพูดของคุณต่ำมาก

ดังนั้นไม่มีอะไรทำ?

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

คุณมีสองวิธีในการทำเช่นนี้:

1. วิธี Watefally

หากคุณทำงานในโครงการที่เหมาะสมกับ Waterfall / V-Model สิ่งนี้อาจใช้ได้:

  1. ทำรายการข้อกำหนดด้านการใช้งานและไม่ใช้งานของโครงการ รับเอกสารที่ลงชื่อโดยลูกค้าเช่นเดียวกับที่เขาเซ็นสัญญา

  2. เมื่อคุณได้รับเอกสารนี้คุณมี:

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

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

  3. ไปกับทีมของคุณทีละขั้นตอนวิเคราะห์ความต้องการแต่ละอย่างและประเมินผล:

    • ราคาเฉลี่ยของส่วนนี้ของโครงการ

    • ราคาสูงสุดโดยไม่คำนึงถึงความเสี่ยง

    • ดัชนีความเสี่ยง

    ทั้งสามจะถูกนำเข้าบัญชีเพื่อกำหนดราคาที่คุณจะให้กับลูกค้า

  4. สินทรัพย์ความเสี่ยงที่ไม่ได้ขึ้นอยู่กับข้อกำหนดเฉพาะ แต่ขึ้นอยู่กับความเข้ากันได้ระหว่างข้อกำหนดหรือระบบโดยทั่วไป

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

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

2. วิธีเปรียว

หากคุณทำงานในโครงการที่เหมาะสมกับ Scrum หรือโมเดลที่คล่องตัวอื่น ๆ :

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

ในทั้งสองกรณีคุณควรมีความเชื่อมั่นอย่างแรงกล้าระหว่างคุณและลูกค้าหรือมีพนักงานขายที่ยอดเยี่ยม มิฉะนั้น,

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

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

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

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


3

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

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

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

การรับเงินตามบรรทัดของรหัส (LOC) เป็นสิ่งที่โง่ เพราะ LOC ไม่ได้มีความหมายอะไรเลย! ฉลาดเขียนรหัสที่ดีและคิดค่าบริการตามคุณสมบัติ!

โชคดี,


1
+1 สำหรับการชี้ให้เห็น LOC คือการวัดที่ไม่ถูกต้อง และเหตุการณ์สำคัญเป็นวิธีที่ชาญฉลาดในการรับเงิน
jqa

0

อย่ายอมรับราคาคงที่สำหรับภาระผูกพันที่สิ้นสุดลงแล้ว คุณจะเมาทุกครั้งถ้าทำ


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