Định lượng giá cho mã nguồn và sản phẩm phần mềm


9

Tôi sắp thực hiện một dự án. Điều này đòi hỏi tôi phải viết mã, và tấn nó. Yêu cầu của khách hàng là giao tất cả mã nguồn vào cuối dự án.

Câu hỏi của tôi là: Làm cách nào để định lượng giá cho mã nguồn và sản phẩm phần mềm? Có bất kỳ số liệu nào theo sau để xác định giá? Làm thế nào tôi có thể định lượng sản phẩm phần mềm?

Thông tin thêm: Ứng dụng phải chạy ở mọi nơi, trong mọi HĐH, bao gồm cả máy tính bảng (iPad, tab Galaxy, v.v.), Điện thoại thông minh (iPhone, điện thoại Android, v.v.) và cả trên web. (Bây giờ, hãy tưởng tượng bao nhiêu mã này sẽ được) .


2
Khi ai đó sẽ tìm thấy cách định lượng một cách kỳ diệu giá của một sản phẩm phần mềm dựa trên các yêu cầu người dùng liên tục thay đổi, không rõ ràng và không đầy đủ, thế giới sẽ trở nên tốt hơn. Nhưng vẫn +1 cho câu hỏi.
Arseni Mourzenko

Phương pháp đáng tin cậy duy nhất của phần mềm định giá: (1) viết và kiểm tra chương trình; (2) đo lường nỗ lực của bạn; (3) bán phần mềm dựa trên nỗ lực bạn thực sự có.
Doc Brown

Bạn nên kiểm tra Appcelerator , AirHaxe (có thể nhắm mục tiêu cả hai hoặc sử dụng NME ).
back2dos

Điều này không cụ thể đối với lập trình hoặc phần mềm, đây là một câu hỏi chung về giá cả được ngụy trang thành một câu hỏi liên quan đến lập trình.

I am about to undertake a project. This requires me to write code.... Lập trình viên + Dự án = Mã (thường). Tại sao nói rõ?
Năng động

Câu trả lời:


12

Bạn không bao giờ có thể biết một mức giá chính xác hoặc gần như chính xác, vì nó phụ thuộc vào nhiều yếu tố. Thí dụ:

Nghiên cứu điển hình

Bạn có một yêu cầu cho một trang web nhỏ dựa trên WordPress. Điều duy nhất bạn phải làm: làm việc với nhà thiết kế của bạn để tạo đồ họa hấp dẫn, sau đó tự tạo trang web (không có gì kỹ thuật cao, chỉ là một bộ plugin để thêm vào WordPress), sau đó triển khai nó. Công việc thực sự dễ dàng, bạn đã trích dẫn nó $ 600.

Nhà thiết kế của bạn đã tạo ra bản nháp đầu tiên. Khách hàng giải thích rằng anh ta thấy nó không hấp dẫn chút nào. Điều tương tự cũng xảy ra với dự thảo thứ hai, thứ ba và thứ tư. Cuối cùng, sau hai tuần làm việc chăm chỉ, cuối cùng nhà thiết kế đã có được bản nháp được khách hàng chấp nhận.

Nhưng thật đáng buồn là nhà thiết kế đã bị xe buýt đâm và điều duy nhất bạn nhận được là JPEG mà anh ta gửi cho bạn, nhưng không phải là PSD gốc, vì vậy bạn phải bắt đầu lại với một nhà thiết kế mới. Cuối cùng, bạn đã có đồ họa và bắt đầu công việc của bạn.

Điều ngạc nhiên: bạn đã phát hiện ra rằng plugin A không tương thích với plugin B, rằng plugin C không hoạt động như mong đợi và plugin D không thể được cài đặt trên phiên bản mới nhất của WordPress, trong khi chỉ có thể cài đặt plugin A trên phiên bản mới nhất này. Bây giờ bạn phải thực hiện nhiều mã hóa PHP bằng tay và vì bạn là nhà phát triển Python và chưa bao giờ viết một dòng mã nào trong PHP, nên đây không phải là nhiệm vụ dễ dàng nhất.

Trong khi đó, khách hàng bắt đầu gửi cho bạn những email đáng sợ, hỏi tại sao công việc chưa hoàn thành, trong khi thời hạn là một tuần trước. Cuối cùng bạn đã hoàn thành mã hóa PHP và mọi thứ hoạt động hoàn hảo trên máy của bạn. Khách hàng hài lòng.

Sau đó, bạn bắt đầu triển khai trang web đến máy chủ lưu trữ để phát hiện ra rằng không chỉ trang web bị lỗi với một số lỗi khó hiểu mà cả công ty lưu trữ không hỗ trợ một tính năng của PHP mà bạn đã sử dụng rất nhiều trong mã của mình.

Cuối cùng, sau khi chi hơn 3.000 đô la cho dự án này, bạn có trang web hoạt động. Khách hàng tức giận vì thời hạn và vì "không có gì hoạt động như mong đợi với bạn". Bạn có hỏi $ 600 không? $ 3.000?

Tại sao nó xảy ra?

Những gì tôi minh họa trong ví dụ này xảy ra thường xuyên hơn bạn có thể tin. Tại sao? Bởi vì có quá nhiều biến số mà bạn không thể dự đoán và điều này làm tăng rủi ro. Ở đây, rủi ro đã tăng lên bởi:

  • Các thông số kỹ thuật không rõ ràng liên quan đến thiết kế trực quan,
  • Cái chết của nhà thiết kế,
  • Tính không tương thích của các plugin bạn đã chọn,
  • Sự hỗ trợ không tốt của các plugin bạn đã chọn,
  • Thực tế là bạn chưa từng sử dụng PHP trước đây,
  • Sự khác biệt giữa môi trường phát triển và môi trường sản xuất và không có dàn dựng.

Người ta có thể giải quyết những vấn đề đó bằng những cách tiếp cận cụ thể:

  • Rõ ràng và chính xác các yêu cầu chức năng và phi chức năng,
  • Quản lý kịch bản hit-by-a-bus (tức là nhà thiết kế phải chia sẻ mọi tài liệu với bạn để anh ta có thể chết bất cứ lúc nào mà không ảnh hưởng đến dự án),
  • Kiến thức trước về các công cụ và ngôn ngữ bạn phải sử dụng (đòi hỏi nhiều công việc),
  • Dàn dựng, thử nghiệm chuyên sâu, vv

Vấn đề duy nhất là với cách tiếp cận này, bạn phải nói với khách hàng của mình rằng anh ta sẽ trả ít nhất 5.000 đô la ngay từ đầu, vì thực sự đó là giá của các yêu cầu, đặc điểm kỹ thuật, thiết kế, thử nghiệm, v.v ... Cơ hội để khách hàng này chấp nhận báo giá của bạn là rất thấp.

Vậy không có gì để làm?

Nếu bạn không thể đưa ra một mức giá rất chính xác, bạn vẫn có thể đưa ra một xấp xỉ, tính đến mọi phần công việc cần làm riêng, với một chỉ số rủi ro bị ảnh hưởng đến mọi phần. Cao hơn là rủi ro dự đoán, cao hơn là giá.

Bạn có hai cách để làm điều đó:

1. Cách thức

Nếu bạn làm việc trên các dự án phù hợp với Waterfall / V-Model, điều này có thể hoạt động:

  1. Liệt kê các yêu cầu chức năng và phi chức năng của một dự án. Lấy tài liệu có chữ ký của khách hàng, giống như cách anh ta ký hợp đồng.

  2. Khi bạn đã có tài liệu này, bạn đã có:

    • Giá bạn đã bỏ ra để thu thập các yêu cầu và tạo tài liệu này. Điều này có thể đại diện cho một số tiền quan trọng, vì những tài liệu đó có thể thay đổi từ hai mươi đến một trăm trang cho một dự án thông thường, và là hàng trăm hoặc hàng ngàn trang cho các dự án lớn.

    • Sự hiểu biết rõ ràng, chính xác và đầy đủ về sản phẩm bạn được yêu cầu làm.

  3. Đi cùng với nhóm của bạn từng bước, phân tích từng yêu cầu và đánh giá:

    • Một mức giá trung bình của phần này của dự án,

    • Một mức giá tối đa mà không tính đến rủi ro,

    • Một chỉ số rủi ro.

    Cả ba sẽ được đưa vào tài khoản để xác định giá bạn sẽ đưa cho khách hàng.

  4. Tài sản rủi ro không phụ thuộc vào một yêu cầu cụ thể, mà là sự tương thích giữa các yêu cầu hoặc hệ thống nói chung.

Ưu điểm của phương pháp tiếp cận thủy lợi: khách hàng nhận được một mức giá khá chính xác, xem xét rằng bạn có một tầm nhìn rất rõ ràng về công việc phải làm và những rủi ro có thể phát sinh.

Nhược điểm của phương pháp tiếp cận thủy: bạn phải viết một tài liệu 200 trang trước khi đưa ra giá. Điều gì xảy ra nếu khách hàng hủy dự án trong khi đó, hoặc đi đến đồng thời của bạn? Toàn bộ quá trình cũng vô cùng nặng nề và các yêu cầu không thể thay đổi sau đó.

2. Cách nhanh nhẹn

Nếu bạn làm việc trên các dự án phù hợp với Scrum hoặc các mô hình nhanh nhẹn khác:

  • hoặc không đưa ra giá chung của dự án, mà là giá của mọi thành phần,
  • hoặc bạn có thể chỉ ra một mức giá tổng thể rất gần đúng lúc ban đầu, và sau đó đưa ra mức giá chính xác hơn.

Trong cả hai trường hợp, bạn nên có một sự tin tưởng mạnh mẽ giữa bạn và khách hàng, hoặc có những người xuất sắc trong bộ phận bán hàng. Nếu không thì,

  • trong trường hợp đầu tiên, người đó sẽ tin rằng bạn chỉ ăn cắp tiền của cô ấy để xin số tiền nhỏ hết lần này đến lần khác, và điều này sẽ không bao giờ kết thúc,

  • trong trường hợp thứ hai, người đó sẽ không hiểu tại sao bạn luôn thay đổi giá của mình, đặc biệt là nếu giá tăng hầu hết thời gian.

Ưu điểm của phương pháp Agile: khách hàng có thể hủy bỏ bất cứ lúc nào. Ngoài ra, nếu cô ấy hủy bỏ ở giai đoạn đầu, cô ấy vẫn có một số mã nguồn hoạt động.

Nhược điểm của phương pháp Agile: giá quá không chính xác hoặc thậm chí không được đưa ra. Hầu hết khách hàng sẽ không sẵn lòng làm ăn với bạn nếu bạn không cho họ biết họ sẽ phải trả bao nhiêu.


3

Không chấp nhận một dự án khi nó không rõ ràng cả kết quả và số tiền khách hàng cần phải trả. Tôi chỉ làm như sau:

  • Hãy đến với các bước và thanh toán khách hàng cần phải làm.
  • Khi bước trước được thực hiện và thanh toán đầy đủ và khách hàng hài lòng chuyển sang bước tiếp theo.

Đối với phương thức thanh toán, chọn thanh toán dựa trên các tính năng. Vì vậy, nếu khách hàng có cơ hội bỏ các tính năng nếu anh ta / cô ta không thể trả toàn bộ dự án.

Được trả tiền dựa trên các dòng mã (LỘC) là một điều ngu ngốc. Bởi vì LỘC không có nghĩa gì cả!. Hãy thông minh viết mã tốt và tính phí dựa trên tính năng!.

Chúc may mắn,


1
+1 để chỉ ra LỘC là số liệu sai. Và các mốc quan trọng là cách thông minh để được trả tiền
jqa

0

Không chấp nhận một mức giá cố định cho một cam kết kết thúc mở. Bạn sẽ bị lừa mỗi lần nếu bạn làm.


+1 'phát triển giá cố định' là chiến lược của nhiều doanh nghiệp thất bại
jqa
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.