Ước tính Chi phí sửa đổi mã của ai đó [đã đóng]


8

Tôi còn khá mới đối với phát triển web và chưa phải cung cấp ước tính cho nhiều dự án lớn (dự án lớn cuối cùng của tôi chỉ được thanh toán theo giờ mà không có thời hạn hoặc ngân sách nghiêm ngặt).

Một khách hàng đang yêu cầu tôi cung cấp ước tính chi phí và thời gian để cung cấp vô số thay đổi cho mã nhà phát triển khác cho một trang web (phụ trợ php / mysql).

Bất cứ ai cũng có thể cung cấp một số lời khuyên hoặc liên kết về cách đi về phân tích và ước tính điều này? Mã này thật kinh khủng (trang web ban đầu được gia công cho Ấn Độ từ nhiều năm trước) và thật khó để biết liệu tôi có bất ngờ vượt rào và thổi bay những ước tính của tôi ra khỏi nước hay không.

Câu trả lời:


4

Tôi nghĩ bạn không nên đặt tên ngay từ đầu. Nếu ai đó nói chuyện với bạn về một dự án, bạn nên làm đủ công việc miễn phí để tìm hiểu xem khách hàng muốn gì và chi phí có thể là bao nhiêu. Không nhiều hơn hoặc ít hơn thế.

Cung cấp cho họ một đề xuất, có thể cực kỳ ngắn gọn, nhưng cung cấp cho họ một cái gì đó mô tả những gì họ muốn và những gì bạn sẽ cung cấp. Bạn có thể đặt một phạm vi nếu bạn muốn, và thậm chí bạn có thể nói rằng đây là một ước tính thiện chí của người Hồi giáo nhưng số tiền cuối cùng sẽ dựa trên thời gian sử dụng.

Từ kinh nghiệm của tôi là một freelancer, có 3 bước chính để làm điều này:

  1. yêu cầu thanh toán 50% để bắt đầu công việc

  2. yêu cầu thanh toán cuối cùng trước khi bàn giao các tập tin

  3. yêu cầu một khối giờ cho công việc hoặc công việc đang diễn ra có thể sẽ bật lên theo thời gian

Chúc may mắn!


3
4. Bám sát súng của bạn khi khách hàng cố gắng đẩy lùi. 5. Hãy chuẩn bị đi bộ.
tzerb

ask for 50% downpayment to begin work... hm, không phải là một chút cao? Tôi thà nói 20%
šljaker

Tôi nghĩ rằng 50% khoản thanh toán cuối cùng sẽ là số tiền tốt nhất để yêu cầu khách hàng. Bằng cách này, anh ta sẽ không muốn yêu cầu một số lập trình viên khác thực hiện công việc của mình (một nửa số tiền khá lãng phí, phải không? Trong khi một phần trăm nhỏ sẽ dễ dàng bị từ bỏ hơn) và anh ta sẽ bị mắc kẹt với bạn đến cuối của nó.
appoll

1

Yêu cầu một tỷ lệ hàng giờ. Đừng để nhiều giờ xây dựng trước khi bạn lập hóa đơn.


Đúng. "Đừng để nhiều giờ tích tụ ..."
Năng động

1

Đi nhanh nhẹn! Đừng ước tính cả đống, đặc biệt nếu bạn không có nhiều kinh nghiệm trong vành đai của mình.

  • Nói chuyện với khách hàng của bạn và xem những gì cần được thực hiện / giao.
  • Đối với mọi chức năng / đơn vị công việc, hãy tạo một câu chuyện người dùng (phần kỹ thuật, viết mô tả phù hợp) và chia nó thành một hoặc nhiều nhiệm vụ (phần kỹ thuật)
  • Ước tính mọi câu chuyện của người dùng

Hãy nhớ rằng, ước tính theo định nghĩa của nó luôn luôn sai, nếu không nó sẽ được gọi là một số! Điều rất quan trọng là khách hàng của bạn cũng hiểu điều này!

Bạn nên làm giao hàng gia tăng. Nói với khách hàng để ưu tiên các câu chuyện của người dùng và chọn những câu chuyện sẽ được gửi trong lần lặp đầu tiên. Mỗi lần lặp lại nên kéo dài 2 tuần hoặc ít hơn, nhưng không quá 3 tuần! Khi bạn hoàn thành một câu chuyện người dùng (tất cả các nhiệm vụ của nó đã bị đóng), hãy thông báo cho khách hàng và yêu cầu anh ta xác minh nó trong khi bạn đang làm việc với câu chuyện người dùng tiếp theo.

Bạn không phải trả phí trước, bạn có thể làm điều đó sau mỗi lần lặp.

Chúc mừng mã hóa!


1

Vì bạn chưa quen với công nghệ có liên quan và không quen thuộc với cơ sở mã chất lượng kém hiện tại mà bạn sẽ phải làm việc, nên có thể ước tính có thể thay đổi ở một mức độ nào đó theo cả hai hướng. Nhưng hãy cho khách hàng biết về lý do sau :-P

Đầu tiên, liệt kê vô số thay đổi / tính năng mà khách hàng của bạn đã yêu cầu. Đối với mỗi yêu cầu, hãy xem xét và nghiên cứu mã nhỏ về cách thực hiện và kiểm tra nó. Bạn nên đầu tư thời gian này mà không hoàn trả trước khi đưa ra ước tính.

Thứ hai, tạo 3 cột để ước tính - trường hợp tốt nhất (xác suất 25%), trường hợp trung bình (50%), trường hợp xấu nhất (75%). Vì 2 lý do được đề cập trong đoạn đầu tiên, bạn có thể chọn ước tính trường hợp xấu nhất. Sau đó, bạn có thể thêm 20% thời gian đệm. Ví dụ, đối với một yêu cầu cụ thể, ước tính trường hợp tốt nhất của bạn là 2 ngày, trường hợp trung bình là 4 ngày và trường hợp xấu nhất là 5 ngày. Thêm 20% thời gian đệm, ước tính của bạn là 6 ngày.

Thứ ba, không đưa ra một điểm ước tính cố định, thay vào đó là một phạm vi. Đối với ví dụ trên, bạn có thể nói với khách hàng rằng ước tính là 4 đến 6 ngày. Khách hàng của bạn có thể nhấn mạnh vào ước tính cho toàn bộ danh sách các thay đổi. Trong trường hợp đó, bạn có thể thêm tối thiểu và tối đa phạm vi cho tất cả các yêu cầu. Sau đó cung cấp một ước tính cuối cùng trong phạm vi, giả sử 5 đến 6,5 tháng. Điều này có lợi thế sau: bạn có thể vượt quá ước tính cho một yêu cầu, nhưng có thể hoàn thành một yêu cầu khác trước đó. Tổng cộng, họ hủy bỏ lẫn nhau và ước tính cuối cùng giữ vững.

Thứ tư, khi bạn hoàn thành từng yêu cầu của người dùng và cung cấp tăng dần, hãy xem lại các ước tính trước đó của bạn cho từng yêu cầu. Đây là một quá trình liên tục và bạn nên điều chỉnh / tinh chỉnh dự toán khi bạn tiến hành dự án và kinh nghiệm của bạn phát triển. Nếu bạn thấy sự khác biệt giữa ước tính tinh chế và ước tính ban đầu của bạn vượt ngoài tầm kiểm soát, hãy ngồi ngay với khách hàng của bạn và thảo luận vấn đề.

Tôi đã học được những điều này từ cuốn sách "Ước tính phần mềm: Làm sáng tỏ nghệ thuật đen" của Steve McConnell. Tôi biết ơn anh ấy.


0

Bạn có thể trích dẫn tổng số dựa trên số giờ làm việc ước tính, làm rõ các giả định của bạn và thực tế là bất kỳ thời gian bổ sung cần thiết sẽ được thêm vào. Bằng cách này nếu bạn đi dưới (không chắc) bạn đi ra phía trước.

Đảm bảo chất lượng của mã hiện tại rõ ràng cho khách hàng. Nếu chúng hợp lý, chúng nên thích nghi với sự linh hoạt, nếu không thì hãy chuẩn bị đi.

Tôi đã ở trong tình huống này khi tôi bắt đầu và không may Stack Exchange không tồn tại vào thời điểm đó. Tôi đã trích dẫn một mức giá cố định và phải bảo lãnh cho thỏa thuận hai tháng. Tôi đã mất tiền và đốt một cây cầu vì tôi không thể giao hàng.


0

Nhìn vào cách các ngành công nghiệp tương tự làm điều đó. Một kiến ​​trúc sư sẽ không đưa ra ước tính chính xác về phần mở rộng nhà để xe mà không nhìn thấy tài sản trước.

Tính phí cho họ một khoản phí điều tra cho thời gian ban đầu của bạn. Giải thích rằng mã đang ở trạng thái mà bạn không thể đưa ra ước tính chính xác mà không cần nhìn sâu hơn vào tình huống hiện tại. Hãy chắc chắn rằng họ nhận được một cái gì đó ở cuối của nó, như một dấu hiệu của đức tin, một số tài liệu họ có thể cung cấp cho nhà phát triển khác nếu họ chọn, để cứu họ phải làm công việc tương tự.

Và sau đó, nếu điều quan trọng với bạn là bạn có được công việc phát triển thực tế, hãy nói với họ rằng nếu họ đến với bạn cho công việc phát triển thực tế, bạn sẽ loại bỏ 50% hoặc thậm chí 100% khoản phí đó khỏi hóa đơn cuối cùng. Bạn không thể thua và mọi người làm như vậy để có được thứ gì đó miễn phí.

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.