Bạn có nên tính phí khách hàng giờ dành cho theo dõi sai? [đóng cửa]


17

Tôi đã thực hiện một thử thách CSS nhỏ để giải quyết cho một khách hàng và tôi sẽ được trả theo tỷ lệ hàng giờ. Cuối cùng tôi đã giải quyết được, mất 5 giờ nhưng tôi đã dành khoảng 25% thời gian theo dõi sai, thử một giải pháp CSS3 chỉ hoạt động trong các trình duyệt gần đây và cuối cùng phát hiện ra rằng không có dự phòng nào có thể thông qua JS (như tôi nghĩ ban đầu). Tôi có nên tính phí khách hàng 25% không?

Thêm chi tiết: Tôi không đưa ra ước tính, tôi thích thử thách, vì vậy tôi đã bắt đầu thực hiện trước khi đưa ra ước tính (nhưng tôi đã làm việc với anh ta trước đây, vì vậy tôi biết anh ta không phải là một trong những người có kỳ vọng không thực tế ). Vào lúc tồi tệ nhất, tôi sẽ dành 5 giờ không trả tiền cho một thử thách CSS hấp dẫn. Và tôi sẽ đưa ra ước tính công bằng nhất có thể cho cả hai chúng tôi, vì tôi đã hoàn thành công việc. :)

Chỉnh sửa: Cảm ơn tất cả các bạn, tôi ước tôi có thể chấp nhận nhiều hơn một câu trả lời! Cuối cùng tôi đã không thanh toán cho anh ta thêm giờ (tôi đã lập hóa đơn cho anh ta trong 3 rưỡi), nhưng tôi đã đề cập đến họ, để anh ta biết rằng tôi đã làm việc với nó nhiều hơn là tôi đã lập hóa đơn cho anh ta. Có lẽ đó là lý do tại sao anh ta ngay lập tức chấp nhận "ước tính" (trong trường hợp đó không phải là ước tính, do đó là trích dẫn).


Ước tính ban đầu bạn đã đưa ra cho khách hàng của bạn là gì?
JK

2
Bạn có hy vọng cho công việc nhiều hơn từ khách hàng? Những loại mối quan hệ bạn muốn thiết lập?
Steve Jackson

@Jonathan: Xem bản chỉnh sửa của tôi
Lea Verou

1
Bản sao có thể có: lập trình
Steve Jackson

1
Nó không phải là một bản sao, tôi đọc chủ đề đó trước khi tôi đăng câu hỏi của mình. Anh ấy nói về việc học những điều mới, không làm việc với giải pháp sai.
Lea Verou

Câu trả lời:


24

Tôi thường có những tình huống như vậy khi tôi dành vài giờ để làm một cái gì đó, sau đó nhận thấy rằng có một giải pháp một dòng dễ dàng hơn, hoặc ý tưởng đầu tiên của tôi quá tệ, v.v.

Nói chung, trong những trường hợp đó, tôi tạo ra sự khác biệt giữa ba tình huống:

  • Giải pháp mới được phát hiện là không rõ ràng và / hoặc một nhà phát triển trung bình có thể cũng đang đi sai hướng và / hoặc theo dõi sai là điều kiện tiên quyết để tìm ra giải pháp cuối cùng. Trong trường hợp này, tôi tính phí khách hàng cho thời gian theo dõi sai.

  • Giải pháp mới được phát hiện không quá rõ ràng, nhưng có lẽ rất nhiều nhà phát triển trung bình sẽ trực tiếp đi theo hướng này. Nói cách khác, nếu tôi nghĩ tốt hơn trước khi bắt đầu viết mã, có lẽ tôi có thể tìm thấy giải pháp cuối cùng trực tiếp, hoặc có thể không. Trong trường hợp này, tôi tính phí khách hàng, nhưng giảm giá một nửa hoặc một tỷ lệ phần trăm có vẻ phù hợp nhất.

  • Rõ ràng, tôi đã quá ngu ngốc, quá buồn ngủ hoặc không nghĩ gì cả trước khi tôi bắt đầu viết mã, vì giải pháp cuối cùng cực kỳ dễ tìm. Trong trường hợp này, ngay cả khi tôi dành hai ngày theo dõi sai, đó là trách nhiệm của riêng tôi và khách hàng không phải trả tiền cho điều đó.


Tôi không nghĩ các nhà phát triển "trung bình" sẽ giải quyết nó cả. Nhưng đối với những người có nhiều kinh nghiệm CSS trung bình, nó có thể sẽ là thứ 2.
Lea Verou

1
@Lea Verou: khi tôi nói về "nhà phát triển trung bình", điều đó rất chủ quan. Nó cũng phụ thuộc vào trình độ của bạn và khách hàng nghĩ gì về trình độ của bạn. Nếu khách hàng của bạn biết bạn là người giỏi nhất và trả cho bạn hàng ngàn đô la mỗi ngày, thì "trung bình" chủ quan sẽ cao hơn nhiều so với việc khách hàng của bạn nghĩ bạn là một con khỉ mã.
Arseni Mourzenko

Chà, tôi nói về các hội nghị lớn về CSS, và anh ấy biết điều đó :) Nhưng tôi chắc chắn không kiếm được hàng ngàn đô la mỗi ngày: p (có nhà phát triển web nào không?)
Lea Verou

4
Tôi cũng sẽ tính đến tỷ lệ của bạn. Nếu tỷ lệ của bạn rất cao thì bạn được kỳ vọng sẽ tốt hơn mức trung bình do đó rõ ràng có thể có nghĩa là nhiều thứ hơn. Nếu tỷ lệ của bạn rất thấp thì bạn KHÔNG được dự kiến ​​là trên trung bình, điều này ít rõ ràng hơn.
Martin York

để sao chép-dán một nhận xét tôi đã thực hiện ở nơi khác: thời gian làm việc / suy nghĩ / nghiên cứu / tối ưu hóa một vấn đề là thời gian làm việc cho một vấn đề. NHƯNG điều gì về một người dành thời gian cho sth nên biết về (theo nhiệm vụ được thuê) và / hoặc đã được giải quyết (và là những gì được yêu cầu). Nói cách khác, không có lý do gì cho việc thiếu kiến ​​thức hoặc chỉ đơn giản là công việc chuyên môn tồi. Lưu ý , rằng một chuyên gia thực sự có thể (và nên) thực sự tạo ra một trường hợp thuyết phục về việc đã dành bao nhiêu thời gian và tại sao
Nikos M.

33

Tôi không nghĩ rằng bạn đã đi sai đường. Bạn đã mã hóa một giải pháp, thử nghiệm giải pháp (kudos) và thấy nó không hoạt động như bạn mong đợi. Bạn gỡ lỗi giải pháp và sau đó thực hiện sửa chữa của bạn bằng cách đi theo một hướng khác.

IMHO, đó không phải là ca khúc sai. Đó là sự phát triển phần mềm thường xuyên.

Nếu tôi là bạn, tôi sẽ tính phí trong 4 giờ.


1
Tôi thích cách bạn nghĩ: p :)
Lea Verou

2
Tôi đồng ý, về bản chất, nghiên cứu / thiết kế là một lĩnh vực mà ngay cả những ngã rẽ sai cũng quan trọng. Chứng minh rằng một cái gì đó không hoạt động (và để lại dấu vết) giúp bảo trì dễ dàng hơn vì anh chàng tiếp theo sẽ không thử.
Matthieu M.

1
Đó là cách tất cả các ngành nghề khác làm. Chỉ có các lập trình viên là "cao quý" (hoặc, nói thẳng, ngây thơ) thậm chí nghĩ về việc không thanh toán cho tất cả các giờ làm việc về vấn đề của khách hàng.
quant_dev

8

Hầu hết các chương trình chúng tôi viết, chúng tôi đang viết vì một giải pháp không phải là ngay lập tức, dễ dàng có sẵn. Tất cả mọi thứ chúng ta làm đều liên quan đến việc học một cái gì đó mới. Khách hàng không trả tiền cho bạn cho sản phẩm. Anh ấy đã trả tiền cho bạn để học cách xây dựng sản phẩm và cho bạn kết quả (và nếu anh ấy tự gọi đó là "thử thách", anh ấy đang mong đợi bạn học được điều gì đó). Xem "Waltzing with Bears" của Tom de Marco và Timothy Lister - "Nếu một dự án không có rủi ro, đừng làm điều đó".

Nếu bạn muốn trả lại cho khách hàng đúng cách, hãy gửi cho anh ta giải pháp của bạn cùng với chi tiết về các giải pháp không hiệu quả, để anh ta có thể chuyển chúng cho bất kỳ nhân viên nào khác mà anh ta thuê và giúp họ mất ít thời gian hơn.

Tùy thuộc vào bạn để thương lượng nếu anh ta nghĩ rằng anh ta trả quá nhiều. Chắc chắn, tôi sẽ mong đợi anh ta trả tiền cho bất kỳ việc học nào không dễ sử dụng ở nơi khác.


Bản thân anh không gọi đó là một thử thách, anh không biết đó là một thử thách. (mặc dù anh ta có thể thấy khó khăn khi quyết định thuê ngoài nó)
Lea Verou

Các downvoters xin vui lòng bình luận về lý do tại sao điều này đang bị hạ cấp?
Lunivore

5

Đôi khi giải quyết một vấn đề liên quan đến việc loại bỏ các giải pháp tối ưu khỏi một tập hợp các tùy chọn hợp lý. Quá trình loại bỏ là một trong những công cụ giải quyết vấn đề của bạn; khách hàng đang trả tiền cho bạn cho một giải pháp và sẽ yêu cầu bạn sử dụng bất kỳ công cụ nào theo ý của bạn.

Nó sẽ là một khách hàng không hợp lý, người hy vọng bạn sẽ ngay lập tức hình dung ra giải pháp tốt nhất - đi thẳng từ bản tóm tắt dự án đến bàn phím của bạn, nơi bạn phát ra một dòng mã không có khoảng trống nhanh và tối ưu. Điều đó không có nghĩa là không có khách hàng như vậy. Tôi đã có một khách hàng gọi vào giữa dự án để xác minh rằng thực tế anh ta chỉ trả tiền cho "lập trình, không gỡ lỗi". Và tất nhiên, có những khách hàng (hoặc ông chủ) mà lập trình là hành động vật lý của việc gõ.

Con hẻm mù của bạn có thể đại diện cho tiền chi tiêu tốt nhất của khách hàng: một nhà phát triển khác có thể không kỹ lưỡng như bạn và đã cung cấp một giải pháp rẻ hơn nhưng ít tương thích hơn trong tương lai.


2
Ghét phải chạy vào những kẻ có tư duy "lập trình, không gỡ lỗi" này. Như thể một nhà văn chỉ có thể bắt đầu viết ra một câu chuyện mà không cần đọc lại nó và thực hiện các thay đổi. Điều đó có thể sẽ trở thành một câu chuyện tệ hại nếu được viết theo cách đó :-).
Htbaa

5

những câu hỏi này khiến tôi phát điên ...

nếu một thợ máy hoặc luật sư dành thời gian giải quyết vụ việc / vấn đề của bạn, bạn đặt cược @ $$ bạn sẽ bị tính phí, ngay cả khi họ dành thời gian đi sai đường

lập trình viên cần bắt đầu định giá thời gian của họ nhiều hơn


Tôi đồng ý (do đó +1) thời gian làm việc / suy nghĩ / nghiên cứu / tối ưu hóa một vấn đề là thời gian làm việc cho một vấn đề. NHƯNG điều gì về một người dành thời gian cho sth nên biết về (theo nhiệm vụ được thuê) và / hoặc đã được giải quyết (và là những gì được yêu cầu). Nói cách khác, đây không phải là lý do cho việc thiếu kiến ​​thức hoặc chỉ đơn giản là công việc chuyên môn tồi. Lưu ý rằng một chuyên gia thực sự có thể (và nên) thực sự tạo ra một trường hợp thuyết phục về thời gian đã sử dụng và tại sao
Nikos M.

5

Những gì bạn đã làm là một điều hoàn toàn bình thường. Fred Brooks thảo luận về hiện tượng này trong chương "Kế hoạch vứt bỏ một lần" của cuốn sách bán kết về công nghệ phần mềm "Tháng huyền thoại".

Bạn đang làm việc trên một hợp đồng thời gian và vật liệu; do đó, bạn nên tính phí khách hàng của mình cho tất cả thời gian bạn dành cho dự án. Tùy thuộc vào khách hàng để xác định xem anh / cô ấy đã nhận đủ giá trị cho khoản đầu tư của mình hay chưa.


4

Tôi nhìn nó theo cách này: vào cuối ngày, đó là cuộc gọi của bạn những gì bạn tính phí. Có nhiều biến số như mức độ bạn muốn khách hàng hài lòng, mối quan hệ hiện có, kỹ năng bán hàng của bạn, v.v ... chúng ta đều quen thuộc với họ. Những gì bạn cuối cùng cung cấp cho khách hàng, và những gì họ thực sự muốn, là giá trị. Bạn đã mang lại giá trị gì cho khách hàng và giải pháp / khả năng cung cấp mà bạn cung cấp có giá trị với họ là gì?

Bạn có thể mất 10 phút để giải quyết vấn đề, nhưng bạn mất 10 năm để học cách giải quyết vấn đề đó. Điều đó xứng đáng được xem xét. Đồng thời, một số người trong chúng ta xem xét khả năng học tập "trong công việc". Tôi thường tìm hiểu mọi thứ, thực sự là trên xu của khách hàng, tôi coi đó là một hình thức bồi thường phi tiền tệ.

Bạn cũng có thể thêm nó vào hóa đơn, sau đó đánh dấu nó là "chiết khấu ưu đãi của khách hàng" trên hóa đơn, không tính phí và xây dựng một số thiện chí. Tôi làm điều đó mọi lúc mọi nơi, điều đó làm cho khách hàng cảm thấy tốt.

Ngoài ra, câu hỏi của bạn là nếu có những nhà phát triển đang kiếm được hàng ngàn đô la mỗi ngày, câu trả lời là có. Bạn cũng nên là một trong số họ, với kỹ năng của bạn. Tôi thực tế ở đó, và tôi không ở đâu trong cùng một liên minh với bạn về CSS.


1
+1, câu trả lời này không được đánh giá cao. Cả hai câu trả lời được bình chọn hàng đầu đều hoàn toàn thiếu quan điểm "giải pháp nào đáng giá cho khách hàng". Heck, đôi khi chúng tôi tính phí một khách hàng gấp 3 lần nỗ lực chúng tôi thực sự có được bởi vì điều đó có thể vẫn rẻ hơn cho anh ta so với bất kỳ giải pháp nào anh ta có thể nhận được từ một đối thủ cạnh tranh.
Doc Brown

2

Điều đó phụ thuộc vào thỏa thuận ban đầu.

Bạn có nói rằng bạn sẽ giao nó xong và sẵn sàng để đi không? Sau đó, bạn tính phí tốt hơn cho tất cả thời gian bạn dành để phát triển nó. Tất cả!


2

Nếu bạn thuê một luật sư để tranh luận về một trường hợp cho bạn, và họ làm hỏng nó và thua cho bạn, bạn vẫn trả hóa đơn của họ.

Đó là cách tất cả các ngành nghề khác làm. Không có lý do tại sao các lập trình viên nên làm khác.

Nếu khách hàng nghĩ rằng họ đã trả quá nhiều, họ sẽ không quay lại với bạn. Giữ họ như một khách hàng lặp lại là lý do lành mạnh duy nhất cho việc không thanh toán cho tất cả các giờ làm việc.


1

Nếu đó là một dự án mà tôi đặc biệt thực hiện để ai đó trả tiền cho tôi, trong khi tôi tự dạy mình một số công nghệ mới, tôi có xu hướng thực hiện nó với giá thấp hơn tôi thường tính hóa đơn thời gian. Mặt khác, bạn không thể trả giá quá thấp, hoặc nó sẽ gây rối mọi thứ với khách hàng đó mãi mãi ("Này, trở lại khi bạn làm điều đó thực sự tuyệt vời, bạn đã tính phí ít hơn thế này!") Nếu không, tôi không ' Hóa đơn cho thời gian mà tôi làm hỏng và kết thúc quá lâu.

Ngoại lệ của tôi đối với quy tắc này: Nếu lý do vấn đề mất hàng giờ để khắc phục là vì khách hàng đã nói xấu tôi về một cái gì đó mà họ đã phá vỡ, tôi sẽ tính phí cho toàn bộ.


1

Tôi thường sẽ không tính phí nếu đó là lỗi của tôi và tôi chỉ giật mình, nhưng tôi không thông minh chút nào. Tôi đã tìm thấy hầu hết những người thông minh trong kinh doanh áp dụng triết lý này rằng khách hàng đang trả tiền cho thời gian của họ , và không chỉ là kết quả cuối cùng. Có nhiều lần trong sự nghiệp của tôi, khi nhìn lại, tôi hối hận vì đã không nghĩ theo cách này. Tất cả những gì tôi nghĩ là kết quả cuối cùng có giá trị, thời gian của tôi là vô nghĩa trừ khi nó cải thiện kết quả cuối cùng. Tuy nhiên, người ta có thể bị lôi kéo và lãng phí rất nhiều thời gian do khách hàng thay đổi ý định, đồng nghiệp gây ra lỗi được giao cho bạn và trì hoãn công việc của bạn, ví dụ, và không chỉ vì bạn cần nghiên cứu thêm một chút trả trước để thực sự biết những gì bạn đang làm.

Khi bạn bắt đầu bẻ cong các quy tắc và đưa ra ngoại lệ về loại thời gian làm việc nào nên được trả tiền và những gì nên miễn phí, cuối cùng có thể dễ dàng bị lợi dụng. Thời gian là số liệu dễ sử dụng nhất để thanh toán. Nó giải phóng bạn rất nhiều trách nhiệm phức tạp, có vẻ vô trách nhiệm, nhưng nó bảo vệ bạn khỏi bị lôi kéo và sự thiếu trách nhiệm của khách hàng dẫn đến việc cắt giảm lương.

Trong trường hợp của tôi, sẽ là vô vọng nếu tôi không thể buộc tội đi sai đường, vì tôi thường làm việc trên những thứ như thế này:

nhập mô tả hình ảnh ở đây

... cố gắng đánh bại thuật toán phân khu Catmull-Clark gần 40 năm tuổi đã cố thủ trong ngành và được cải tiến nhiều lần bởi các công ty như Microsoft và Pixar bằng cách cố gắng cung cấp kết quả trực quan hơn trong khi vẫn cạnh tranh như các công ty khổng lồ này tốc độ khôn ngoan.

95% thời gian trong những trường hợp như vậy, tôi đang đi sai tuyến đường, liên tục quay trở lại bảng trắng sau thất bại sau thất bại sau thất bại. Nếu tôi không thể tính phí cho những thất bại của mình, tôi đã vô gia cư rồi. Tôi thấy hơn một nửa công việc của mình là nghiên cứu, khi chưa có ai thử những thứ này trước đây và không có cách nào tôi có thể tìm ra cách tiếp cận hoàn hảo để giải quyết một giải pháp ngay lần thử đầu tiên (có thể là lần thử thứ 20). Đối với tôi, mục tiêu chưa bao giờ là thành công ngay lần thử đầu tiên mà là thất bại càng sớm càng tốt, với mỗi thất bại sau thất bại cung cấp một số manh mối về giải pháp chính xác, có thể thực sự có khả năng thay đổi thế giới, có thể là gì.

Không phải ai cũng có thể làm việc trong một khu vực chuyên sâu về R & D, nơi khách hàng muốn và mong đợi bạn đánh bại các kỹ thuật được thiết lập tốt nhất ngoài đó đơn giản chỉ vì bạn đang bắt đầu một dự án mới, nhưng đối với tôi lập trình không bao giờ là chuyện thường xuyên đơn giản và thiết lập một giải pháp là. Cách bạn thiết kế và tích hợp các bộ phận sẽ vẫn là duy nhất, luôn luôn là một hình thức nghệ thuật mang lại những ưu và nhược điểm độc đáo, không cơ học, không hoàn hảo về mặt khoa học, nếu không thì robot có thể làm được. Vì vậy, tôi nghĩ rằng chắc chắn chúng ta sẽ luôn phải trả phí cho việc đi xuống một số tuyến đường sai ở đây và nếu không chúng ta sẽ chỉ có thể kiếm được lợi nhuận từ công việc thường xuyên nhất mà chúng ta đã thực hiện hàng trăm lần mà chúng ta đã áp dụng chính xác như vậy giải pháp mỗi lần, trong trường hợp đó chúng tôi sẽ tính phí để nhấn nút sao chép và dán.

Không thể đoán trước

Một điều nữa là lập trình luôn khó khăn, không thể đoán trước, không bao giờ khá thường xuyên. Nó không giống như giao bánh pizza thường lệ, nơi mà tất cả những thứ như tai nạn xe hơi đều có thể được tính đến . Luôn luôn học hỏi trên trang web - Tôi không thể tưởng tượng nó sẽ trở thành thói quen hoàn toàn trừ khi có ai đó thực sự trả tiền cho tôi để thực hiện như một cách nhanh chóng lặp đi lặp lại. Luôn luôn có một số thử nghiệm và học hỏi đang diễn ra ở đó, và miễn là nó không quá mức, không cần phải cảm thấy tội lỗi về điều đó.

Tôi thường mơ ước trở thành một nông dân hoặc một cái gì đó chỉ để tôi có thể tìm thấy nhiều chuyển động thường xuyên hơn trong công việc của mình, không phải lúc nào cũng vượt qua ranh giới của kiến ​​thức hiện có. Thay vào đó, tôi cố gắng bù đắp bằng cách biến cuộc sống của mình ra ngoài công việc như thường lệ và trần tục nhất có thể, để thêm một số dự đoán và chuyển động thường ngày ở đâu đó vì sự tỉnh táo, khiến tôi trở nên nhàm chán trong cuộc sống bên ngoài của công việc - Tôi tìm thấy đủ nhiều trong công việc.

Anh ấy nói về việc học những điều mới, không làm việc với giải pháp sai.

Làm việc trên giải pháp sai là học những điều mới, phải không? Bạn có biết đó là một giải pháp sai lầm khi bạn bắt đầu, hoặc bạn đã tiếp tục làm việc với nó ngay cả sau khi bạn biết rằng nó là vô vọng sai? Hy vọng không phải là cái sau. Thông thường quá trình học tập là thông qua sai lầm. Đó là giáo viên tốt nhất. Chiến lược hiệu quả nhất mà tôi đã tìm thấy là chỉ cần mắc lỗi càng sớm càng tốt, để khám phá ra rằng, thực sự, họ đã thiết kế sai lầm càng sớm càng tốt trước khi chúng tôi cam kết mọi thứ với họ và kết hôn với những giải pháp như vậy, vì tôi không thể đếm được và dự đoán với sự chắc chắn gần 100% là những sai lầm sẽ được thực hiện. Chúng chỉ đắt nếu chúng được phát hiện rất muộn.


0

Nó thực sự phụ thuộc vào cách bạn đề xuất dự án, và dự án có thể xuất hóa đơn như thế nào.

Ví dụ, nếu đó là một hợp đồng dựa trên khả năng giao hàng thì tất cả các giờ bất kể nên được theo dõi đối với dự án ngay cả khi đó là để học một cái gì đó mới.

Nếu đó là hợp đồng dựa trên thời gian và vật liệu thì bạn cần phải nhạy cảm hơn nhiều đối với việc này. Ví dụ, nếu bạn đang ở trong bối cảnh của vấn đề và có vấn đề thì nó sẽ được tính hóa đơn. Một ví dụ về điều này là nếu bạn đang học một API kế thừa hoặc một chút mã và cố gắng để nó hoạt động với mã của bạn.

Tuy nhiên, nếu bạn bị theo dõi bên cố gắng làm điều gì đó hoặc chỉ muốn học cách làm theo cách mới, thì tôi sẽ chỉ lập hóa đơn cho thời gian thực hiện giải pháp thực tế chứ không phải là thời gian tôi học.

Tôi không đồng ý với Lunivore, rằng họ trả tiền cho chúng tôi để học hỏi. Họ trả tiền cho chúng tôi vì chuyên môn của chúng tôi và hầu hết thời gian chúng tôi phải biết làm thế nào để làm điều đó. Họ trả tiền cho chúng tôi để thực hiện.

Nói tóm lại, ff ước tính ban đầu của bạn không bao gồm thời gian tìm hiểu vấn đề thì có lẽ bạn không nên lập hóa đơn cho nó. Viết nó như một kinh nghiệm học tập và biết lần sau bạn sẽ không có sự chậm trễ đó.

Chỉnh sửa: Vì sau này bạn đã xác định rằng không có ước tính, tôi chắc chắn sẽ không bao gồm thời gian đó nếu bạn nghĩ rằng đây sẽ là một ứng dụng khách lặp lại. Tôi cũng sẽ luôn cung cấp một ước tính trả trước trong tương lai.


-1

Để giải quyết vấn đề này, tôi hình dung những gì tôi nghĩ là một trường hợp xấu sẽ xảy ra và trích dẫn dựa trên hàng giờ về những gì tôi nghĩ rằng nó nên được thực hiện với một trích dẫn tối đa được đặt ra bởi trường hợp "xấu". Bằng cách này, chúng ta đều là người chiến thắng.


Tôi không thích điều đó, bởi vì khách hàng luôn thua, trong trường hợp đó không phải là trường hợp "xấu".
Lea Verou

có một sự khác biệt giữa trường hợp "xấu" và trường hợp "tệ nhất". Nếu đó là trường hợp xấu nhất, tôi sẽ mất.
Dave

Hmm, điểm tốt. Tuy nhiên, nếu đó là một trường hợp "tốt" thì sao?
Lea Verou

sau đó là theo giờ. Tôi sẽ tính phí cho bạn x số tiền mỗi giờ lên đến h giờ.
Dave
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.