Chi phí thiết kế dựa trên chi phí lập trình

Phương pháp của bạn là gì khi bạn cần xác định chi phí thiết kế UI nếu bạn biết chi phí (giờ làm việc) của lập trình trong một số dự án?

Giả sử, lập trình logic trong một số dự án có giá X đô la. Có một số phần trăm chung (như 30% chi phí lập trình) có thể giúp xác định chi phí thiết kế không?

Lĩnh vực quan tâm là phát triển điện thoại di động (chủ yếu là các công cụ kinh doanh và trò chơi 2D, không phải 3D). Có ít công việc thiết kế ở đây so với thiết kế web hoặc thiết kế trò chơi PC.

Không có tỷ lệ như vậy. Theo cùng một cách, chẳng hạn, sẽ không có phần trăm thời gian bạn sẽ làm việc về bảo mật. Một ứng dụng phải được bảo mật và sẽ yêu cầu một nửa nhân viên của bạn làm việc với nó. Một ứng dụng khác không có bất kỳ mối quan tâm bảo mật nào, vì vậy tác động lên lịch trình của bạn sẽ là tối thiểu.

Thời gian cần thiết để làm thiết kế trực quan phụ thuộc vào yêu cầu . Đây không phải là về loại phần mềm (bạn trích dẫn các công cụ kinh doanh, ứng dụng web và trò chơi).

• Nếu khách hàng của tôi không quan tâm đến thiết kế trực quan của một trang web, tôi sẽ dành vài giờ để tạo ra thứ gì đó cơ bản và sử dụng hai tháng làm việc còn lại cho các khía cạnh quan trọng hơn khác.

• Nếu khách hàng của tôi quan tâm đến tương tác người dùng, tôi sẽ dành vài tuần để tạo ra các khía cạnh khác nhau của thiết kế tương tác, đánh bóng khía cạnh trực quan, v.v., trong khi quan tâm ít hơn về các khía cạnh không quan trọng đối với khách hàng này đối với dự án này.

Trong cả hai trường hợp, nó vẫn là một ứng dụng web.

Nói chung, bạn có hai cách để nhóm các tác vụ khi tạo một ứng dụng.

• Điều đầu tiên là tuần tự: đó là những trạng thái bạn cần làm để đạt được thành công trong dự án của mình . Bạn bắt đầu bằng cách thu thập các yêu cầu chức năng và phi chức năng, bạn làm việc về đặc tả, kiến ​​trúc và thiết kế ứng dụng, bạn tạo các bài kiểm tra, bạn viết mã thực tế, bạn triển khai và duy trì ứng dụng.

  Ở đây, tùy thuộc vào mức độ nghiêm trọng và quy mô của dự án, bạn có tỷ lệ phần trăm tương tự từ dự án này đến dự án khác . Đối với một ứng dụng nhỏ được làm tại nhà, bạn sẽ luôn có 0% đến 5% cho các yêu cầu. Đối với một ứng dụng doanh nghiệp quy mô lớn yêu cầu QA mẫu mực, thời gian bạn thực sự sẽ viết mã sẽ là 15% đến 20%.

• Điều thứ hai là song song: đó là những việc bạn phải làm , với điều kiện là chúng gần như độc lập với quan điểm quản lý dự án và những việc bạn có thể làm hoặc bỏ qua. Nó bao gồm bảo mật, thiết kế trực quan, tính di động, hiệu suất, v.v.

  Ở đây, tỷ lệ phần trăm là không liên quan . Đây là một câu hỏi về các ưu tiên, không phải là quy mô của ứng dụng và mức độ QA cần thiết. Một ứng dụng kinh doanh có thể có trải nghiệm người dùng nổi bật, bởi vì các bên liên quan biết rằng dự án sẽ thất bại hoặc UX là một lợi thế cạnh tranh. Một ứng dụng kinh doanh khác có thể gần như không có thiết kế nào cả, vì không có gì phải đổi mới về mặt thiết kế.

Vấn đề ở đây là không có định nghĩa được chấp nhận rộng rãi về thiết kế trong phát triển phần mềm. Ví dụ, đối với nhiều người, ranh giới giữa thiết kế và mã hóa không thể được rút ra mạnh mẽ, và một số người coi thiết kế và mã hóa là như nhau:

http://www.developerdotstar.com/mag/articles/reeves_design_main.html

Từ quan điểm này, chi phí thiết kế là chi phí lập trình. Những người khác nghĩ rằng "vẽ một số sơ đồ UML" hoặc "tạo một số bố cục GUI" là thiết kế - đặc biệt là khi tác vụ này được gán cho một số người không lập trình. Nếu đó là trường hợp, hãy hỏi những "nhà thiết kế" về nỗ lực của họ, và bạn sẽ dễ dàng tìm thấy chi phí thiết kế của mình.

Vì vậy, trước tiên hãy làm rõ cách bạn xác định thiết kế trong nhóm của mình và nếu nhiệm vụ này được thực hiện trong nhóm của bạn bằng cách nào đó "tách biệt với mã hóa". Nếu bạn không thể tách biệt nhiệm vụ thiết kế một cách rõ ràng, đừng cố tách riêng dưới dạng chi phí, điều đó sẽ không có nhiều ý nghĩa.

EDIT: từ nhận xét của bạn, bạn đã nói rõ rằng bạn có nghĩa là thiết kế giao diện người dùng (mặc dù bạn quên thay đổi tiêu đề gây hiểu lầm cho câu hỏi của bạn). Tuy nhiên, bạn phải xác định nơi bạn vẽ đường giữa "thiết kế giao diện người dùng" và "mã hóa". Có phải thiết kế UI cho bạn chỉ "vẽ một số biểu mẫu bằng bút chì và giấy"? Đây có phải là thiết kế hành vi chính xác của giao diện người dùng của bạn từ quan điểm của người dùng? Có phải đó là thiết kế hoạt động bên trong của các biểu mẫu của bạn, ví dụ như khi bạn thiết kế ứng dụng của mình dưới dạng kiến ​​trúc MVP? Tất nhiên, dựa trên điều đó (và dựa trên yêu cầu của ứng dụng của bạn), bạn có thể đi đến những kết luận khác nhau về tỷ lệ phần trăm thiết kế UI có thể trong trường hợp của bạn.

Tôi nghĩ rằng bạn đang đi về nó ngược lại. Nếu bạn kỳ diệu biết chi phí lập trình chính xác (tôi không thấy điều này khả thi như thế nào), thì có lẽ bạn không cần giai đoạn thiết kế, và có lẽ vấn đề bạn đang cố gắng giải quyết rất đơn giản.

Nếu bạn muốn nói cách ước tính Thiết kế UI, đó là một lãnh thổ khác. Tùy thuộc vào lĩnh vực, đôi khi UI được xử lý như một sự bổ sung muộn, nơi bạn có thể thoát khỏi một ước tính tầm thường như x% thời gian dự án. Các lĩnh vực bạn đề cập ở đây mặc dù 100% người dùng phải đối mặt, vì vậy tôi sẽ bắt đầu với một thiết kế UI cùng với nỗ lực lập trình. Ngay cả khi đó, thật khó để định lượng một cách khái quát nó như là một% của tổng thời gian phát triển - chúng ta cần nhiều bối cảnh hơn. Rốt cuộc, đã có rất nhiều game có AI xuất sắc, v.v., nhưng lại từ chối rất nhiều người vì chúng có thiết kế giao diện / đồ họa tồi. FWIW, mọi người thậm chí đã điều khiển Skyrim thành công rực rỡ vì nó có lỗi thiết kế UI cho PC (Các điều khiển được điều chỉnh nhiều bộ điều khiển hơn là điều chỉnh kb / chuột).