2008-11-08 23 views
6

Tôi đã làm việc trên một "big bang" viết lại cho, nghĩa đen, hơn hai năm. Ban quản lý đã liên tục bỏ qua và bỏ qua các cuộc gọi của tôi để phân bổ thời gian/nguồn lực để đo lường hiệu suất, lập kế hoạch dung lượng và tối ưu hóa trước khi ứng dụng thay thế ứng dụng web hàng đầu của họ.Đề kháng với thử nghiệm hiệu suất cho một vụ nổ lớn viết lại?

Cuối cùng, họ đã đồng ý làm điều đó (và chúng tôi đã ngăn chặn thành công việc này bằng cách đưa ra một máy chủ beta song song đang được sản xuất và sẽ là mục tiêu của các thử nghiệm). Tôi không thích điều đó, họ chờ đến cuối cùng để ưu tiên điều này, nhưng tốt hơn là không bao giờ muộn hơn.

Mọi người có đề xuất gì để xử lý các tình huống như thế này trong tương lai? Cách tốt nhất để giáo dục các nhà quản lý/khách hàng về sự cần thiết cho các loại xét nghiệm này là gì.

Tôi đã hiển thị cho họ hướng dẫn về hiệu suất của Microsoft trên CodePlex, hoàn chỉnh với cảnh báo rõ ràng từ các chuyên gia dày dặn trong các trang mở đầu. Tôi cũng đã cho họ xem cuốn sách "Phát hành nó!" và hướng dẫn tác giả của nó đưa ra về "cuộc gọi 3 giờ sáng". Điều đó cuối cùng đã thuyết phục họ miễn cưỡng, nhưng sự thật là điều này cần được ưu tiên phát triển và được đo một phần trong quá trình phát triển trước khi kiểm tra hệ thống hoàn chỉnh.

Nhiều nhà quản lý và kỹ sư cũ chỉ viết ASP, nhưng chưa bao giờ làm .NET, được sử dụng để tự viết mã và không hiểu tất cả các tùy chọn để lưu vào bộ nhớ đệm, điều chỉnh và theo dõi sức khỏe trong các ứng dụng .NET mới hơn.

Cảm ơn

Trả lời

0

Ghi chú cẩn thận về dự án phát triển này, bao gồm những vấn đề về hiệu suất sẽ được triển khai sau khi triển khai. Mọi người sẽ bemoan các vấn đề, và bạn có thể khéo léo đề nghị rằng họ ưu tiên loại vấn đề cao hơn trước đó. Một số người sẽ chỉ chấp nhận bằng chứng trực tiếp của người đầu tiên.

5

Làm cho họ đồng ý về những con số vững chắc cho những gì họ mong đợi hệ thống có thể hỗ trợ (số người dùng/nhiệm vụ đồng thời), sau đó trở thành một phần rõ ràng của công việc phát triển để đảm bảo hệ thống có thể đáp ứng các yêu cầu.

6

Những gì bạn không nhận ra (và nhiều kỹ sư không) là đây là "tình huống bán hàng", không phải là kỹ thuật. Nó không quan trọng nếu khách hàng là trong nhà hay không, quá trình này là phần lớn giống nhau.

Bán hàng là tất cả về việc tìm ra loại vấn đề nào thúc đẩy khách hàng của bạn và sau đó cho biết cách sản phẩm của bạn giải quyết một hoặc nhiều vấn đề của họ. Nếu họ không nghĩ rằng họ có vấn đề về hiệu suất, thì họ không - điều đó đơn giản. Mặc dù bạn có thể giáo dục họ đến mức họ nhìn thấy mọi thứ theo cách của bạn, "bán giáo dục" là tốn kém về thời gian và tiền bạc, và nhiều khách hàng phẫn uất được nói "điều họ đã biết". Có vẻ như bạn phải giáo dục nhóm này bằng cách đánh bại họ bằng đầu sách, nhưng có thể có những cách dễ dàng hơn để hoàn thành mục tiêu của bạn.

Nó sẽ là gì? Tôi không biết, nhưng họ làm, vì vậy hãy hỏi họ. Hỏi xem cuối cùng đã đẩy họ ra quyết định gì. Nó có thể là một nhận thức đột ngột rằng bạn đã đúng, nhưng nhiều khả năng nó là một cái gì đó cơ bản hơn, giống như một nỗi sợ ngày càng tăng bị làm nhục trong phòng họp hoặc thị trường. Họ không thể nói như vậy trực tiếp, nhưng nếu bạn thực sự lắng nghe câu trả lời của họ, bạn có thể đọc giữa các dòng. Trong bán hàng, thực hiện một postmortem trên một cuộc gọi bán hàng (thành công hay không) là rất quan trọng để hiểu những gì thúc đẩy khách hàng của bạn và làm thế nào bạn có thể điều chỉnh kỹ năng của riêng bạn trong việc trình bày ý tưởng.

Và lần sau, bạn sẽ biết đặt câu hỏi mở về những gì khách hàng của bạn muốn đạt được và những vấn đề của họ hiện tại và về lâu dài. Nó sẽ luôn hoạt động? Tất nhiên là không, nhưng việc học cách đối phó với khía cạnh xã hội của các vấn đề kỹ thuật là một kỹ năng có giá trị để có được.

+0

Điểm tuyệt vời. Mặt khác, đôi khi tôi đã thử hỏi, và chỉ nhận được những câu trả lời mơ hồ, lảng tránh. Điều đó có nghĩa là người ra quyết định không biết họ muốn gì và hy vọng họ sẽ biết điều đó khi họ nhìn thấy nó. –

+1

Thật vậy. Câu chuyện của người dùng rất có giá trị để buộc mọi người phải cụ thể và cụ thể. Họ nói, "Chúng tôi muốn một trang web thực hiện " và bạn nói "Ý tưởng tuyệt vời! Bây giờ, khi người dùng ở trên trang này và họ nhấp vào ô này ... bạn * muốn làm gì xảy ra? " Vv –

2

Đừng thảo luận điều này như là một điều chỉnh hiệu suất mở và quá trình đo điểm chuẩn, vì điều đó sẽ làm cho các nhà quản lý cũ lo ngại rằng bạn đang trên chuyến thám hiểm câu cá hoặc mạ vàng hệ thống.

Thay vào đó, hãy thảo luận đó là bài tập chứng nhận. Xác định mức lưu lượng truy cập hiện tại của bạn, thêm vào lề an toàn và giải thích rằng thử nghiệm của bạn nhằm xác nhận rằng hệ thống sẽ đứng vững với cuộc sống thực.

Bạn vẫn có thể thực hiện công việc điểm phát sóng hiệu suất; bạn chỉ cần cung cấp cho các ông chủ tóc nhọn mà comfrt rằng tất cả công việc của bạn là đi đến các mục tiêu kinh doanh hữu hình.

2

Có tất cả các loại cách thuyết phục mọi người - ví dụ bạn đề cập đến là "yêu cầu thẩm quyền cao hơn". Tuy nhiên, hầu hết các nhà quản lý sẽ không nhất thiết phải được thuyết phục bởi hướng dẫn kỹ thuật.

Đối với các tình huống như thế này, tôi đã sử dụng phương pháp dựa trên rủi ro. Đối với mỗi dự án, tôi giữ một nhật ký rủi ro, xác định các rủi ro lớn nhất đối với dự án, khả năng, tác động và các tùy chọn giảm thiểu. Thông thường, bạn có thể định lượng các mục đó - và điều đó cho phép người quản lý đưa ra quyết định đúng đắn.

Lúc đầu rất của việc viết lại, log nguy cơ của bạn có thể đã có sự xâm nhập sau:

rủi ro: Hiệu năng hệ thống không đáp ứng được người dùng mong đợi

Khả năng: unknown

Tác động: người dùng cuối bỏ trang web do thời gian tải quá nhiều. Dự án không thành công.

Chi phí tác động: $$$ bất kể chi phí dự án của bạn là bao nhiêu.

Giảm thiểu: kiểm tra hiệu suất hai tuần một lần.

Chi phí giảm thiểu: $$$ bất kể bạn nghĩ chi phí nào trong thời gian và tiền bạc

Đề xuất: chạy thử nghiệm hiệu suất để định lượng rủi ro.

Hầu hết các nhà quản lý sẽ rất khó chịu với rủi ro mà khả năng không xác định, nhưng chi phí là sự thất bại của dự án. Mặt khác, bạn không yêu cầu một cam kết lớn - chỉ đủ để định lượng rủi ro.

Tôi muốn xem lại nhật ký rủi ro thường xuyên với các bên liên quan của dự án - ít nhất là hàng tháng. Tôi luôn bắt đầu với những rủi ro "có khả năng ảnh hưởng cao/khả năng cao", nhưng sau đó chuyển sang các rủi ro "khả năng tác động cao/không xác định". Nó cũng là một ý tưởng tốt để phân phối các ghi chú cuộc họp, ghi lại các quyết định của các bên liên quan về từng rủi ro. Một lần nữa, một người quản lý nhìn thấy tên của họ gắn liền với một quyết định bỏ qua một nguy cơ tác động cao, trong một hồ sơ bằng văn bản, sẽ suy nghĩ cẩn thận về quyết định này.

Khi bạn có thể định lượng rủi ro - bằng cách chạy một số kiểm tra hiệu suất - bạn có thể đưa ra các quyết định dựa trên rủi ro hơn, dựa trên chi phí và khả năng xảy ra sự cố hiệu suất. Đây cũng là một cách hay để quản lý các vấn đề phi chức năng cổ điển khác như bảo mật, khả năng truy cập và khả năng mở rộng.

Bằng cách định lượng vấn đề, bạn biến nó thành quyết định kinh doanh, chứ không phải quyết định kỹ thuật.

Các vấn đề liên quan