Làm thế nào để giải thích rằng kích thước mẫu không ảnh hưởng đến chiều dài dự án

Chúng tôi có các dự án doanh nghiệp lớn mà họ thường liên quan đến việc sao chép dữ liệu từ cơ sở dữ liệu nguồn sang cơ sở dữ liệu đích và sau đó thiết lập một số ứng dụng bổ sung đồng bộ hóa dữ liệu này, v.v.

Dự án cuối cùng chứa 250.000 mục (hàng dữ liệu). Dự án tiếp theo sẽ chỉ chứa 4.000 mặt hàng. Người quản lý dự án / người kinh doanh tin rằng dự án nên là 1/10 thời gian để hoàn thành bởi vì nó chỉ là một phần nhỏ của quy mô của dự án cuối cùng.

Sự tương tự tốt là gì tôi có thể sử dụng để giải thích rằng viết mã để truyền dữ liệu từ hệ thống này sang hệ thống khác có cùng số lượng bất kể các mục số - viết nó cho 1 mục hoặc 100.000.000 sẽ mất khoảng thời gian tương tự từ một chương trình quan điểm.

Nói với họ rằng nó giống như xây dựng một đường cao tốc bốn làn mới đến một vùng xa xôi của đất nước. Cho dù con đường đó được sử dụng bởi 100 chiếc xe mỗi ngày hay 1000 chiếc xe mỗi ngày, nỗ lực tạo ra con đường sẽ giống nhau.

Nếu được hỗ trợ, nếu nó hỗ trợ 1.000.000 xe ô tô mỗi ngày, bạn sẽ phải làm cho con đường trở nên mạnh mẽ hơn một chút, nhưng bất kể, bạn sẽ phải chặt những cây giống nhau, nổ tung trên cùng một ngọn núi, ngang bằng nhau của bụi bẩn, và các hoạt động này là khá nhiều chi phí cố định cho dù có bao nhiêu xe sử dụng đường.

Đưa cho họ một máy tính và yêu cầu họ thêm 1238783423 vào 9858238483, mất bao lâu. sau đó yêu cầu họ thêm 3423 vào 8483 và nói với họ rằng bạn mong câu trả lời nhanh hơn khoảng 100000 lần.

Bạn cũng có thể giải thích lượng dữ liệu (có thể) ảnh hưởng đến khoảng thời gian phần mềm sẽ chạy để không chạy theo thời gian phát triển.

Đặt nó vào quản lý nói.

Nếu bạn xây dựng một máy để tạo các vật dụng với tốc độ 1 vật dụng mỗi giây, thì việc bạn sử dụng nó để tạo ra 100 vật dụng hoặc 10000 vật dụng là không quan trọng, bản thân máy cũng mất thời gian để xây dựng.

sự khác biệt là ở thời gian chạy, không phải thời gian xây dựng.

Tất cả các lớp quản lý làm việc với vấn đề như thế này với các nhà máy phụ tùng giả định.

Đừng sử dụng một sự tương tự. Chỉ cần giải thích nó.

• Đối với một số lượng rất nhỏ các mặt hàng (10?), Việc chuyển đổi thủ công là rẻ nhất. Đừng viết một chương trình nào cả.
• Đối với một số lượng nhỏ các mục (100?) Sẽ rất đáng để viết một chương trình. Bạn có thể tiết kiệm bằng cách bỏ qua một số hoán vị của dữ liệu về mặt lý thuyết là có thể, nhưng không xuất hiện trong thực tế trong bộ dữ liệu nhỏ. Hoặc xuất hiện với số lượng nhỏ đến mức chương trình có thể từ chối chúng và chúng có thể được chuyển đổi thủ công. Việc chạy các phân tích nhanh trên dữ liệu là khả thi để kiểm tra xem các trường hợp góc có thực sự xuất hiện trong dữ liệu hay không. Nếu chúng không xuất hiện, chúng có thể bị bỏ qua.
• Khi bạn vượt qua điểm này, kích thước thực của dữ liệu không có tác động. Bạn cần phải viết một chương trình nghiêm túc có thể xử lý bất kỳ đầu vào nào có thể. Chương trình có thể xử lý 1.000 mặt hàng hoặc 100.000. Nó chỉ mất nhiều thời gian hơn để chạy.

Giáo dục tốt hơn là nói xuống :)

Không thực sự là một sự tương tự, nhưng tôi vẫn tin rằng một cách tốt để đối phó với lập luận này: chứng minh có một lỗ hổng chết người trong đó.

Dự án trước của bạn bao gồm (từ những gì tôi nhận được) sao chép dữ liệu với một số sửa đổi trên đó.

Nếu tôi hiểu đúng, đó là điều mà một nhóm gồm 100 nhân viên kế toán có thể làm trong vài tháng. Vậy thì tại sao họ lại ném các nhà phát triển phần mềm vào vấn đề?

Bởi vì phần mềm bạn tạo không quan tâm liệu nó sẽ xử lý 10 hoặc 10 triệu mẩu dữ liệu (không chính xác, nhưng tôi nghi ngờ các nhà quản lý của bạn quan tâm đến O(n)sự phức tạp). Vì vậy, nó có thể rẻ hơn, nhanh hơn và sạch hơn (quy trình ít lỗi hơn).

Nếu bạn cấp tiến hơn, bạn thậm chí có thể đề nghị rằng nếu họ không thích nhóm phần mềm hoạt động nhanh như thế nào, họ luôn có thể gọi kế toán để thực hiện công việc bằng tay.

Điều này làm cho cuộc sống của người quản lý của bạn dễ dàng hơn nhiều trong khi bạn đang phát triển dự án cuối cùng và bây giờ, khi họ phải áp dụng logic tương tự để tìm ra phần mềm tiếp theo không quan tâm nếu nó sẽ hoạt động trên 10 triệu hoặc 4 000 hàng, họ đột nhiên quên nó.

Tôi nghĩ trong trường hợp của bạn, các nhà quản lý chỉ đơn giản là chơi một trò chơi ước tính và đang cố gắng buộc nhóm làm việc nhanh hơn, bằng cách chỉ ra sự khác biệt giữa 4000 và 250000 và hy vọng có một chút 'tội lỗi'. Tôi có thể sai, nhưng tôi đã thấy điều này được thực hiện trước đây.

Đó là một cách khủng khiếp để quản lý một nhóm lập trình viên (thực ra là bất kỳ loại nhóm sáng tạo nào) và nó không giúp được ai.

Tôi biết bạn đã yêu cầu một sự tương tự, nhưng tôi nghĩ đó là kỹ thuật sai.

Tôi tin rằng, như những người khác đã đề cập khi thông qua, rằng bạn cần nhấn mạnh rằng kích thước dữ liệu ảnh hưởng đến thời gian chạy , chứ không phải thời gian xây dựng .
Vì vậy, hãy chia nhỏ chúng cho bạn - bạn thực sự có hai dự án con, xây dựng và chạy. Dự án xây dựng nên (phần lớn) không liên quan đến lượng dữ liệu sẽ chạy trên đó, nó chỉ quan trọng với các loại dữ liệu.
Đối với thời gian chạy - chắc chắn, họ có thể tính theo kích thước dữ liệu (không bao gồm bất kỳ chi phí cố định không tầm thường nào).

Giống như nếu bạn phải lái xe đến Melbourne - nhưng trước tiên bạn phải chế tạo chiếc xe.
Chắc chắn, lái xe đến Sydney có thể nhanh hơn - nhưng việc chế tạo phương tiện cũng mất cùng thời gian.
_{Được rồi, tôi đã cho bạn một sự tương tự sau khi tất cả.}

Có lẽ là một chiếc điện thoại? Khách hàng của bạn muốn một chiếc điện thoại tùy chỉnh. Nếu anh ta thực hiện 0 cuộc gọi mỗi ngày hoặc 100 cuộc gọi mỗi ngày, sẽ mất cùng một khoảng thời gian để tạo ra điện thoại của anh ta.

Dữ liệu điện thoại truyền đi tương tự với dữ liệu được sao chép bởi chương trình của bạn.

Người quản lý của bạn dường như nhầm lẫn giữa thời gian với thời gian thực tế của chương trình. Nhưng sự hiểu lầm của họ có thể khác nhau. Họ có thể cho rằng có ít "lĩnh vực" liên quan hơn. Không chỉ ít hồ sơ dữ liệu. Nếu có 100000 trường dữ liệu riêng lẻ, đó sẽ là một nỗ lực lớn của nhà phát triển so với chỉ 10 trường. Thêm bản đồ làm việc từ hệ thống đến hệ thống. Trong trường hợp này, chúng thực sự có thể đúng, nhưng vẫn có một số chi phí liên tục liên quan và bạn không thể đơn giản chia cho số lượng trường để có thời gian.

Như tôi muốn mô tả, dữ liệu có 2 chiều dài và chiều rộng. Độ dài là số lượng bản ghi, chiều rộng là tổng số cột trên tất cả các bảng

Bây giờ khi bạn muốn nhập dữ liệu, nó giống như việc chặn một lỗ thông qua một lỗ. Bạn cần tạo một lỗ đủ lớn cho kích thước nhỏ nhất, sau đó mang khối qua

bây giờ với 10 triệu và 10 nghìn kích thước nhỏ nhất vẫn là chiều rộng. Vì vậy, nó là chiều rộng quyết định mất bao lâu để tạo ra lỗ.

Để hoàn thành phép ẩn dụ, ff đó là độ dài nhỏ hơn bạn chỉ cần nhập dữ liệu theo cách thủ công

Tôi nhập hàng trăm tệp khách hàng mỗi tuần.

Một điều tôi đã tìm thấy là các tệp nhỏ thường mất nhiều thời gian hơn để phát triển nhập dữ liệu vì:

• Họ ít tuân theo các quy tắc (chúng tôi có cấu trúc tệp tiêu chuẩn, tôi chưa bao giờ thấy một khách hàng nhỏ nào cung cấp cho chúng tôi dữ liệu ở định dạng chuẩn mà chúng tôi yêu cầu nhưng những người lớn hiểu tại sao điều đó lại quan trọng)
• Chúng có xu hướng có nhiều vấn đề toàn vẹn dữ liệu hơn, đặc biệt nếu chúng đến từ tệp Excel chứ không phải cơ sở dữ liệu (nơi các tệp lớn có xu hướng đến) đã được xây dựng quy tắc toàn vẹn dữ liệu
• Chúng ít có khả năng được cung cấp ở cùng định dạng mỗi lần.

Chúng tôi đã phát hiện ra rằng chúng tôi tiết kiệm rất nhiều thời gian trong quá trình phát triển bằng cách xây dựng gói SSIS cha mẹ có quy trình con chuẩn và mọi thao tác cần thiết để lấy dữ liệu ở dạng chuẩn có thể được thực hiện ở cha mẹ. Theo cách đó, vấn đề là có bao nhiêu hồ sơ khi chúng ta ước tính nhưng vấn đề gần với tiêu chuẩn là tệp chúng ta đang nhận được. Bây giờ chúng tôi không nhận được nhiều khiếu nại khi những thứ nhỏ hơn mất nhiều thời gian hơn để phát triển vì chúng không phù hợp với tiêu chuẩn.

Viết một chương trình giống như thuê một nhân viên mới. Bạn phải dạy họ nơi tìm dữ liệu, phải làm gì với dữ liệu đó và làm thế nào để cung cấp cho bạn kết quả. Bạn phải để mắt đến họ một lúc để chắc chắn rằng họ đang làm đúng. Có thể mất một chút thời gian để đào tạo họ nếu họ có một công việc phức tạp / quan trọng hoặc nếu họ sẽ làm một số lượng công việc rất lớn, nhưng phải mất một khoảng thời gian đáng kể cho dù thế nào đi chăng nữa.

Nhiều nhà quản lý đã quen thuộc với chi phí liên quan đến việc đào tạo một nhân viên mới, vì vậy điều này có thể có ý nghĩa với họ.

.