Làm thế nào để giải thích cho một người phi kỹ thuật tại sao nhiệm vụ sẽ mất nhiều thời gian hơn họ nghĩ? [đóng cửa]

Hầu như mọi nhà phát triển đều phải trả lời các câu hỏi từ phía doanh nghiệp như:
Tại sao sẽ mất 2 ngày để thêm biểu mẫu liên hệ đơn giản này?

Khi một nhà phát triển ước tính nhiệm vụ này, họ có thể chia nó thành các bước:

• thực hiện một số thay đổi đối với cơ sở dữ liệu
• tối ưu hóa thay đổi DB cho tốc độ
• thêm HTML giao diện người dùng
• viết mã phía máy chủ
• thêm xác nhận
• thêm javascript phía máy khách
• sử dụng bài kiểm tra đơn vị
• đảm bảo thiết lập SEO đang hoạt động
• thực hiện xác nhận email
• tái cấu trúc và tối ưu hóa mã cho tốc độ
• ...

Những điều này có thể khó giải thích với một người không có kỹ thuật, về cơ bản, họ thấy toàn bộ nhiệm vụ chỉ là kết hợp một số HTML và tạo một bảng để lưu trữ dữ liệu. Đối với họ có thể là 2 giờ MAX.

Vì vậy, có cách nào tốt hơn để giải thích tại sao ước tính cao cho người không phát triển?

Bạn vừa mới thực hiện nó trong câu hỏi của bạn.

Chia nhiệm vụ thành các bước riêng lẻ và đưa ra ước tính cho từng bước. Điều này sẽ cho thấy rằng bạn đã xem xét tất cả các tùy chọn và (hy vọng) bao gồm tất cả các tình huống.

Nếu thời gian quá lớn, bạn có thể thảo luận về những phần nào (ví dụ như xác nhận e-mail) không cần thiết trong trường hợp này với dữ liệu cụ thể thay vì chỉ cố gắng nhồi nhét một quart vào nồi pint.

Làm điều này thường xuyên đủ và hy vọng bạn sẽ dạy họ rằng thường có nhiều thứ để phát triển hơn là bắt mắt ngay từ cái nhìn đầu tiên.

Liệt kê các nhiệm vụ chỉ là hoàn hảo, nhưng hãy nhớ rằng các nhiệm vụ có ý nghĩa hoàn hảo đối với một kỹ sư có ý nghĩa rất nhỏ đối với một người không có kỹ thuật. Ví dụ, trong danh sách trên, tôi biết rằng "tối ưu hóa các thay đổi DB cho tốc độ" có thể là một hoặc một số nhiệm vụ tốn thời gian bao gồm lược tả mã, chạy nó để tìm kiếm các điểm chậm, xem xét nó với các chuyên gia hoặc ném nó qua thiết lập các thử nghiệm được xác định trước cụ thể cho sản phẩm. Và sau đó bạn có thể có vài giờ nếu không phải là những ngày đập đầu vào bàn trong khi bạn cố gắng tìm cách khắc phục những khu vực quá chậm.

Nhưng bạn có thể đã mất quyền quản lý dự án của mình trên từ "DB" nếu không phải là từ "tối ưu hóa".

Tôi thường thể hiện công cụ này cho ban quản lý dự án theo các bước LỚN bằng các từ mô tả rủi ro về mặt kinh doanh. Lấy danh sách của bạn, tôi sẽ đun sôi nó theo cách này nếu tôi đang nói chuyện với quản lý dự án của mình:

1. Đầu tiên, có hai phần cho vấn đề này - trang web mà người dùng nhìn thấy và máy chủ thực hiện công việc nặng nhọc. Cả hai phần cần phải có để tính năng này hoạt động.
2. Phần đầu tiên sẽ là để tạo một trang web có ý nghĩa với người dùng (thêm HTML giao diện người dùng, thêm javascript phía máy khách). Chìa khóa ở đây là trang web phải trông giống như một phần của sản phẩm này, nó phải hoạt động trong tất cả các trình duyệt mà chúng tôi hỗ trợ và phải thật mượt mà. Đây là những gì người dùng nhìn thấy, vì vậy nếu nó trông tệ, người dùng sẽ nghĩ sản phẩm của chúng tôi là xấu. Phát triển điều này và sau đó thử nghiệm sẽ mất X ngày.
3. Tiếp theo, cần phải có những thứ bên dưới trang web đang làm việc. Trong trường hợp này có nghĩa là chèn mô tả tính năng ở đây (ánh xạ tới - thực hiện một số thay đổi đối với Cơ sở dữ liệu, viết mã phía máy chủ, thực hiện xác nhận email, thêm xác thực, sử dụng kiểm tra đơn vị). Tôi không thể ném cái này cùng nhau. Nếu mã được phát triển và sau đó được kiểm tra, chúng tôi có nguy cơ gây thiệt hại cho dữ liệu của TẤT CẢ người dùng. Điều đó có nghĩa là một điều mới đơn giản có thể làm tổn hại danh tiếng của sản phẩm trên bảng - ngay cả đối với người dùng không sử dụng tính năng đặc biệt này. Thực tiễn phát triển của chúng tôi bao gồm điều này - chúng tôi thực hiện nhiều thử nghiệm để đảm bảo điều đó sẽ không xảy ra - nhưng điều đó có nghĩa là tôi phải lên kế hoạch để kiểm tra nó đúng lúc. Điều đó sẽ đưa tôi Y ngày.
4. Tốc độ là một vấn đề lớn trong sản phẩm của chúng tôi. Nếu mọi thứ không diễn ra nhanh chóng, người dùng sẽ nghĩ rằng sản phẩm không tốt. Vì vậy, sau khi tôi viết tất cả những thứ này, tôi cần phải hoàn thành công việc và đảm bảo rằng nó tương đương với hiệu suất. Đây là một vấn đề lớn trong các công cụ web - nếu mọi người thấy một trang web trở nên chậm, họ sẽ nhanh chóng chuyển sang một sản phẩm khác để đáp ứng cùng một nhu cầu, bởi vì thật khó để thấy sự khác biệt giữa chậm và hỏng. Loại công việc đó thường mất Z ngày (tối ưu hóa các thay đổi DB cho tốc độ, tái cấu trúc và tối ưu hóa mã cho tốc độ)

Tôi sẽ tránh mọi ước tính ít hơn nửa ngày. Ở một mức độ nào đó, họ sẽ phải tin tưởng rằng bạn biết bạn đang nói về điều gì. Và nếu họ thực sự nghĩ rằng sẽ chỉ có 2 giờ, thì hãy mời họ ngồi với bạn trong 2 giờ trong khi bạn đưa họ đi qua chính xác 2 giờ trong cuộc sống của một nhà phát triển SW - sau đó thực hiện lớp 101 mã hóa cho khoảng 2 giờ, để hiển thị chính xác những gì tất cả phải được xem xét để thậm chí bắt đầu giải quyết vấn đề.

Quan trọng nhất là những điều sau đây:

• Mua nói nhiều nhất về nhận thức của khách hàng và việc sử dụng sản phẩm, bạn sẽ tham gia nói ngôn ngữ của họ - ngôn ngữ của $$ - vấn đề là, nếu mã được hack cùng nhau một cách kém chất lượng, cuối cùng bạn sẽ mất việc - nếu không trên tính năng này, sau đó trên một số tính năng tiếp theo khi thực tiễn phát triển kém đã khiến cho không thể mở rộng mã.
• Đặt ra một chuỗi các sự kiện. Câu hỏi phi kỹ thuật tiếp theo sẽ là "nếu chúng tôi có nhiều nhà phát triển hơn bạn, điều này có xảy ra nhanh hơn không? Nếu vậy, nếu phải mất 40 giờ để thực hiện điều này, 40 người có thể thực hiện vào chiều nay không?" Câu trả lời, tất nhiên, là "KHÔNG! BẠN CÓ RA KHỎI MIND CỦA BẠN ??". Nhưng đó không phải là tốt nhất. Điều tốt nhất là có một chuỗi các bước hợp lý ở đây. Điều B không thể được thực hiện cho đến khi điều A diễn ra (nếu bạn chưa viết bất kỳ mã nào, bạn không thể thực sự tối ưu hóa hoặc kiểm tra nó ...). Mặc dù điều A và A 'có thể được thực hiện cùng nhau, vì vậy nếu họ có thể tha thứ cho anh chàng thông minh ở đó, bạn có thể giảm thời gian từ một tuần xuống còn 4 ngày, và nếu họ có thể đảm bảo hỗ trợ kiểm tra tuyệt vời, thì có lẽ bạn có thể 3 ngày. Có
• Tập trung vào rủi ro và được chuẩn bị để nói rằng một số rủi ro có giá trị tại thời điểm này. Đó là những gì các doanh nhân được trả nhiều tiền cho - tìm hiểu những rủi ro nào đáng để chấp nhận. Ví dụ: nếu tốc độ đưa ra thị trường có hiệu suất kém vì công ty của bạn có đủ tiền mặt để tạo ra số lượng máy chủ lố bịch trong thời gian ngắn, thì bạn có thể được yêu cầu bỏ qua tất cả những thứ đó trong bước 4 (tối ưu hóa mã / cơ sở dữ liệu ). Đó là quyền của họ - đó chỉ là công việc của bạn để giải thích những rủi ro vốn có trong quyết định đó.
• Tuy nhiên, nếu bạn không tin tưởng những người này, hãy xác nhận bằng văn bản - không cần phải đối đầu, chỉ cần một email nhanh chóng nói "đây là những gì tôi nghĩ chúng ta đã thảo luận, đây là những gì tôi không làm, đây là nguy cơ. Tôi sẽ làm điều đó ngay bây giờ, vì vậy hãy cho tôi biết nếu bạn không đồng ý ... nếu tôi không nghe thấy, bạn sẽ cho rằng đây là cách đúng đắn để tiếp tục ". Cho rằng quản lý sản phẩm có thể là trung tâm cho việc mất trí nhớ ngắn hạn, điều này khá hữu ích cho mọi người.

Có một câu nói, "Bạn không thể nhét mười pound (tào lao) trong một túi năm pound." Công việc của bạn là chỉ ra rằng nhiệm vụ là mười pound và họ đang yêu cầu thực hiện nó trong khung thời gian năm pound.

Điều duy nhất bạn thiếu là ước tính thời gian. Đặt ước tính thời gian cho mỗi nhiệm vụ và hiển thị cách tất cả những thứ này cộng lại với ước tính bạn cung cấp. Đừng cho phép bất kỳ ước tính nào lớn hơn 4 giờ. Nếu bạn có bất kỳ nhiệm vụ nào mà bạn nói "một ngày" hoặc "10 giờ", thì hãy chia nó thành các nhiệm vụ nhỏ hơn.

2h make some changes to Database
2h add front end HTML
   write server side code
     4h input validation
     4h database inserts
2h add validation
2h add client side javascript
   use unit tests
     2h client-side tests
     3h server-side tests
2h make sure SEO is setup is working
2h implement email confirmation
2h optimize DB changes for speed
2h refactor and optimize the code for speed

Bây giờ bạn đã có một hóa đơn được chia thành từng khoản chi phí. Tất cả đã nói, tổng cộng lên đến 27 giờ làm việc.

Bây giờ bạn có thể hiển thị điều này cho khách hàng của bạn và nói "Đây là những điều phải được thực hiện, với chi phí của mỗi." Sử dụng từ "chi phí", vì thời gian là chi phí và quản lý hiểu chi phí. Giải thích rằng bạn có thể bỏ hai nhiệm vụ tối ưu hóa vào cuối, nhưng chúng sẽ có tác động tiêu cực xuống đường và chúng chỉ chiếm 15% tổng ước tính.

Ngoài ra, hãy chắc chắn rằng bạn giải thích giờ / ngày của bạn là gì, thực tế. Ví dụ: nếu bạn được yêu cầu hỗ trợ kỹ thuật, hoặc duy trì cơ sở dữ liệu hoặc bất cứ điều gì, hãy tính điều đó vào ước tính của bạn. Đừng nói "Chà, tôi có thể thực hiện 7,5 giờ một ngày để viết mã tốt" bởi vì có lẽ bạn không thể. Nó có thể giống như 5 hoặc 6.

Sau đó, quan trọng nhất, theo dõi tiến trình của bạn. Nói rằng bạn có thể làm 5 giờ mỗi ngày của mã hóa. Sau đó, bạn sẽ có thể loại bỏ hai nhiệm vụ đầu tiên (trong ví dụ của tôi) vào thứ Hai, hoàn thành thứ ba và bắt đầu thứ tư vào thứ ba, v.v. Tạo một danh sách kiểm tra cho thấy điều này, để bạn có thể hiển thị chúng vào thứ Tư khi họ đến và nói "Làm thế nào mà bạn vẫn sẽ hoàn thành vào cuối ngày thứ Sáu?"

Xem các slide của tôi để nói chuyện của tôi Ngăn chặn khủng hoảng: Dự toán và theo dõi dự án mà tôi đã làm tại OSCON vài năm trước. Nhìn vào slide 21, "Lập kế hoạch trong tuần". Ngoài ra còn có một biểu đồ vận tốc mẫu .

Hỏi họ:

Bạn sẽ làm điều này như thế nào? Những mô-đun bạn sẽ thay đổi? Có bao nhiêu dòng mã? Ý nghĩa bảo mật là gì? Bất kỳ thay đổi đối với lược đồ cơ sở dữ liệu? Nếu bạn thực hiện bất kỳ thay đổi nào đối với DB, có bao nhiêu tệp bị ảnh hưởng? Mất bao lâu để thêm hình thức cuối cùng? Trung bình (trung bình số học) để thêm một hình thức là gì? Cái gì dài nhất? Tôi sẽ ước tính nó sẽ mất ít hơn một phút so với lâu nhất. Nếu bạn không biết phải mất bao lâu để thêm các biểu mẫu N cuối cùng, thì ước tính này chỉ được đảm bảo chính xác đến một bậc độ lớn.

Tôi có thể bảo bạn giải thích với họ rằng phần mềm của họ giống như một cỗ máy 100 tấn với 10.000 bộ phận khác nhau, phần lớn được kết nối theo những cách phức tạp. Lắp một mảnh 1 inch vào máy này cần một số kỹ thuật, để nó không làm hỏng máy, NHƯNG câu trả lời tốt hơn là:

Nếu bạn có kiến ​​trúc mã tốt hơn, nó có làm cho các tác vụ như thế này dễ dàng không? Và câu trả lời là hầu hết các nhóm phần mềm không phải là kiến ​​trúc sư giỏi (vì đơn giản là họ không tích lũy được hàng tấn mẫu chung, kiến ​​trúc hoặc họ không phải là chủ nhân của miền vấn đề để lường trước mọi vấn đề) và họ không phải lúc nào cũng là kỹ sư giỏi , vì vậy họ không cảm thấy tự tin khi đưa ra ước tính hoặc đưa ra lời hứa.

Giống như thế kỷ 20 để tích lũy kiến ​​trúc tốt và kỹ thuật xây dựng các tòa nhà lớn, các công cụ cho công nghệ phần mềm vẫn chưa xuất hiện trên dòng chính. Họ đang được phát triển: cần một tư duy mới. Xem Mã Zen tại wiki.hackerspaces.org/Hacking_with_the_Tao.