Sự lãng phí tiền bạc lớn nhất mà bạn đã thấy, và bạn đã làm gì về nó? [đóng cửa]

Thông thường chúng ta là những lập trình viên thấy các tổ chức lớn lãng phí một khoản tiền khổng lồ cho các giải pháp cồng kềnh và không hiệu quả cho các vấn đề. Điều này làm tôi đau đớn vì tôi thích các tổ chức được hưởng lợi từ các giải pháp giống tốt nhất. Tuy nhiên, khả năng của tôi với tư cách là một lập trình viên bị hạn chế khi ảnh hưởng đến những người ra quyết định quan trọng và thường thì quan điểm của tôi về vấn đề này bị hạn chế trong thế giới kỹ thuật nhỏ bé của chính tôi.

Vì vậy, câu hỏi của tôi là này. Sau khi gặp phải sự lãng phí tiền bạc quá lớn đối với một số phần mềm và / hoặc phần cứng thực sự có con dê của bạn, bạn đã làm gì để sửa nó hay bạn đã cam chịu cắn viên đạn và lẩm bẩm mãi mãi trong hơi thở của mình? Tôi thích nghe những trải nghiệm chung của bạn và đặc biệt là những bài học bạn đã học về cách giải quyết vấn đề này trong tương lai . Chúng ta không nêu tên, kinh nghiệm về cách giải quyết vấn đề quan trọng hơn sản phẩm vi phạm thực tế.

Trả tiền cho các sản phẩm thương mại lớn, cồng kềnh, có lỗi, trong phạm vi:

• Máy chủ ứng dụng;
• Công cụ kiểm tra;
• Môi trường phát triển.

khi các lựa chọn thay thế nguồn mở hoặc trọng lượng nhẹ rõ ràng là vượt trội.

Các bước của tôi thường là:

1. thiết lập một giải pháp thay thế làm tài liệu tham khảo - ví dụ: "Tôi sẽ thử nghiệm với máy chủ ứng dụng X thay vì máy chủ ứng dụng Y. Tôi có kinh nghiệm tốt với nó, bởi vì (...).";
2. bán đề xuất này cho các đồng nghiệp của tôi - "Tôi hiện đang phát triển nhanh hơn vì máy chủ X khởi động lại nhanh hơn nhiều và tôi không lãng phí tất cả thời gian đó";
3. bán cái này cho người quản lý trực tiếp - "Nhóm của chúng tôi bây giờ phát triển nhanh hơn vì chúng tôi đang sử dụng máy chủ X. Tất cả bắt đầu như một thử nghiệm nhỏ nhưng mọi người đều thích nó."

Tôi đã thấy quá nhiều ví dụ để đặt tên cho mục ưa thích, nhưng tôi đã nhận thấy một vài xu hướng chung trong lĩnh vực chính của mình, phát triển web:

1. Trang web Vanity . Đây là những trang web không phục vụ mục đích hữu ích cho bất kỳ ai bên ngoài tổ chức nhỏ ủy thác cho họ và được xây dựng xung quanh một sự bắt buộc ám ảnh với logo, hình ảnh của chính họ và bánh quế tự sướng. Phần tồi tệ nhất là những thứ này thường được tài trợ bởi khu vực công và được ủy quyền bởi những người không có đầu mối về web. (Ví dụ, đã từng có một bệnh viện NHS tin tưởng, người muốn phát triển một phiên bản nhỏ của Facebook cho mạng nội bộ của nhân viên của họ).

2. Được trả tiền là tốt nhất . Tư duy khẳng định rằng về bản chất phần mềm phải trả tiền phải tốt hơn nguồn mở. Rốt cuộc, nó được trả tiền, phải không? Tôi đã thấy rất nhiều khách hàng khăng khăng đưa ra những lựa chọn ngu ngốc đơn giản chỉ vì họ làm việc trong một nền văn hóa tự động giảm giá bất cứ thứ gì nguồn mở như một vấn đề của chính sách.

3. Thiết kế bởi ủy ban. Đây là nơi một nhóm người khổng lồ có "động não" và sau đó cố gắng kết hợp mọi ý tưởng crack-pot có trong thiết kế, chắc chắn dẫn đến một suy nghĩ tồi tệ thông qua sự lộn xộn thỏa hiệp mọi thứ có lợi cho việc cố gắng làm hài lòng tất cả mọi người ( và bởi tất cả mọi người, họ có nghĩa là ủy ban đưa ra quyết định, không phải người dân phải sử dụng ứng dụng).

4. Tư vấn. Đây là nơi bạn trả tiền cho một người đàn ông trung lưu (người không biết thực hành kinh doanh cũng như phát triển phần mềm) để cản trở và kiếm tiền bằng cách kéo dài quá trình phát triển với kỹ thuật lảm nhảm và nói chuyện kinh doanh.

Tôi không thấy ai đã đề cập đến cái này cả.

Xây dựng giải pháp của riêng bạn khi bạn có thể mua nó.

Biến thể của mẫu này:

• thậm chí không xem xét sự đánh đổi mua so với xây dựng
• creep phạm vi đáng kể của giải pháp trong nhà
• phạm vi hạn chế, nhưng cũng hạn chế tiện ích của giải pháp trong nhà

Hai mục yêu thích của tôi:

1. Thuê chuyên gia tư vấn (tự do) chỉ để tăng thêm năng lực sản xuất , trong khi họ nên đầu tư vào nhân viên của mình thay vào đó, bằng cách thuê chuyên gia tư vấn để mang lại kiến ​​thức mới và huấn luyện những người hiện có của họ.

2. Thuê người quản lý dự án quản lý người quản lý dự án khác quản lý người quản lý dự án khác cuối cùng (nghĩ) họ quản lý nhóm phát triển. Trong khi họ nên để nhóm tự quản lý và tập trung vào kinh doanh thay thế. Tôi đã thấy các dự án phần mềm nơi họ có nhiều người quản lý dự án hơn các nhà phát triển. Hãy tưởng tượng các cuộc họp.

Hạn chế tăng và thưởng dài hạn

Tôi nghĩ rằng nó được dạy trong Business 101 để không tăng lương cho nhân viên. Một trường hợp thứ cấp là để hạn chế mức lương của người biểu diễn vì họ cần phải phù hợp với một số mức lương nhất định.

Cuối cùng, nhân viên sẽ nhận ra thang lương của họ không phù hợp với ngành (hoặc đầu ra) của họ. Những người có sơ yếu lý lịch và kỹ năng cuối cùng sẽ rời đi, và mang theo tất cả kiến ​​thức của họ và có lẽ là một vài người bạn của họ. Những người còn lại (là những người biểu diễn dưới cùng) sẽ phải nhận lấy sự chậm chạp và sau đó dành nhiều thời gian hơn để thuê một người mới (theo tỷ giá thị trường). Vì vậy, công ty chỉ giao dịch một nhân viên ngôi sao cho cấp độ một của JR, và chỉ mất tất cả "tiền tiết kiệm" để giữ mức lương thấp.

Khi điều này tiếp tục, nhóm phát triển sẽ đấu tranh để giữ ngang bằng, và có thể sẽ ngày càng tồi tệ hơn cho đến khi một cái gì đó quyết liệt được thực hiện.

Câu trả lời này hơi khác so với hầu hết: không sa thải nhân viên sớm, hoặc nói khác đi, quá khoan dung với thói quen sai lầm của nhân viên . Đây là những điều tôi đã quan sát và không thể làm nhiều về tư vấn.

• Các nhà phát triển kém đã đưa ra các quyết định thiết kế của một dự án dẫn đến việc viết lại cuối cùng của nó (nó là một mớ hỗn độn).

• Nhà phát triển đã gửi dữ liệu nhạy cảm không được mã hóa cho Biểu đồ của Google vì họ nghĩ rằng sẽ rất tuyệt khi hiển thị biểu đồ hình tròn (biểu đồ hình tròn là một yêu cầu phải không? Không!).

• Các nhà phát triển đã tham khảo ý kiến ​​với một công ty trong quá khứ và chấp nhận một vị trí trực tiếp với họ. Anh ta làm một khuôn mặt và biến thành một prima donna tìm kiếm vị trí Trưởng nhóm Kỹ thuật và đi xa như nói chuyện với người quản lý của người lãnh đạo nói rằng họ nghĩ sẽ tốt cho anh ta khi đảm nhiệm vị trí lãnh đạo. Nói về sự táo bạo! Rất nhiều nhà phát triển không còn thích anh chàng này và anh ta đã đốt rất nhiều cây cầu trong vòng 2 tuần đầu làm nhân viên. Trên hết, anh ấy là một dev rất xanh chỉ mới tốt nghiệp 2 năm trước nhưng nghĩ rằng anh ấy thật tuyệt vời.

Một vài sai lầm là có thể hiểu được, nhưng khi có sự đồng thuận giữa nhiều nhà phát triển về thái độ hoặc trình độ kỹ năng của ai đó thì nên loại bỏ chúng sớm hơn là muộn hơn.

Một vài lần tôi đã chứng kiến ​​quản lý đưa các chuyên gia tư vấn cho mục đích duy nhất là tiêu tiền . Hầu hết thời gian điều này xảy ra vào cuối năm khi họ đang ở dưới ngân sách điên cuồng cố gắng tiêu tiền. Thông thường những chuyên gia tư vấn này sẽ được trả hàng trăm đô la một giờ và họ sẽ dành hàng tuần cho một bài thuyết trình PowerPoint sẽ không bao giờ được sử dụng.

Có một vấn đề lớn hơn nhiều tại chơi ở đây.

Nhiều công ty có một mục tiêu - để tăng sự giàu có của cổ đông. Những gì họ sản xuất là không liên quan. Làm thế nào họ sản xuất nó là không liên quan. Bao nhiêu chất thải họ sản xuất là không liên quan. Chi phí cho xã hội và hành tinh là không liên quan.

Vì vậy - hãy làm việc cho hoặc bắt đầu một công ty làm điều gì đó có lợi cho xã hội / hành tinh.

Trả tiền cho các công ty phần mềm lớn không chỉ cho sản phẩm của họ, mà còn cho "sự hỗ trợ" của họ.

Tôi đang làm việc tại một cơ quan của Chính phủ cho một nhóm nằm sâu trên giường với Oracle. Trong nhiều năm, họ đã được trả nhiều đô la cho phần mềm của họ. Xuất phát từ một nền tảng khởi nghiệp, điều này không có ý nghĩa gì với tôi - "tại sao không sử dụng MySQL hoặc Postgres?" Tôi được cho biết rằng chủ yếu là do sự hỗ trợ mà Oracle cung cấp, nếu có sự cố xảy ra, họ sẽ giúp bạn tìm ra giải pháp nhanh chóng.

Sự hỗ trợ là một trò đùa tuyệt đối. Có một vấn đề trong đó một ứng dụng web liên tục làm sập toàn bộ hệ thống. Nó dường như là kết quả của một truy vấn cơ sở dữ liệu chậm với sự kết hợp của mã được viết khủng khiếp (được viết bởi một nhóm các nhà tư vấn, nên là một câu trả lời hoàn toàn khác). Một "đội đặc nhiệm" (rên rỉ) đã được tập hợp để xác định vấn đề và khắc phục nó. Bao gồm trong lực lượng đặc nhiệm là một thành viên hỗ trợ của Oracle. Mỗi ngày tại EOB sẽ có một cuộc gọi hội nghị nơi các thành viên lực lượng đặc nhiệm sẽ cập nhật phần còn lại của đội với những phát hiện. Đó là một cuộc gọi đủ dài mà không ai muốn tham gia vào b / c, nó bắt đầu từ 5 và người Oracle chỉ làm cho nó tồi tệ hơn. Tại sao? Chà, nói "người" thậm chí không đúng. Đó là một số người. Có vẻ như cứ hai hoặc ba cuộc gọi hội nghị, đại diện của Oracle sẽ là người mới, người giải thích người tiền nhiệm của họ bây giờ đang ở một dự án khác hoặc đã đi nghỉ. Những người mới không bao giờ được thông báo bởi bất kỳ ai tại Oracle, vì vậy mỗi khi có người mới đến, chúng tôi phải lãng phí mười phút của cuộc gọi hội nghị để giải thích vấn đề một lần nữa. Của chúngđóng góp sau đó sẽ yêu cầu các tệp nhật ký J2EE, không chỉ bất kỳ con khỉ nào cũng có thể đọc mà còn vô dụng vì mã được viết khủng khiếp đang làm những việc như ném ngoại lệ IndexOutOfBound khi lập trình viên phát hiện ra lỗi khi phân tích cú pháp XML.

Có lập trình viên để hỗ trợ điện thoại dòng 1.

Có lập trình viên làm thử nghiệm.

Tôi biết rằng đây là một câu hỏi cũ và tôi sẽ may mắn nếu 3 người đọc câu trả lời này, nhưng đó là một câu chuyện thú vị để kể, vậy thì quái gì.

Tôi đã tham gia vào một dự án (hệ thống nhúng, phần mềm quan trọng an toàn, cổ phần rất cao) và tôi đã kinh hoàng trước những gì tôi tìm thấy. Những người sử dụng C (đặc biệt là con trỏ) không chính xác, không phân tích tĩnh, không đánh giá mã, không thử nghiệm ngoài việc "tích hợp nó với nhau, chạy nó, đánh bại nó, xem những gì phá vỡ".

Tôi đã viết một email rất dài trong tuần đầu tiên của tôi ở đó (với tư cách là một nhà tư vấn). Thật là khó chịu vì về cơ bản tôi đã nói rằng nó bị quản lý sai, các nhà phát triển đã ở trên đầu họ, không có quy trình nào được theo dõi, v.v. Nó nên đến VP của công ty, nhưng thay vào đó tôi đã gửi nó cho người quản lý phát triển đã thuê tôi. Anh ấy không hoàn toàn phòng thủ về điều đó, thực tế anh ấy đã thừa nhận nhiều thiếu sót và nói với tôi rằng tôi không phải là người đầu tiên chỉ ra chúng (không đùa, phải không?)

Để trả lời mấu chốt của câu hỏi ban đầu: Tôi đã đề nghị dành ATST 1 tuần một tuần để có được công cụ phân tích tĩnh Gimpel's Lint (PC-Lint / Flexelint) được định cấu hình & chạy trên nền tảng của họ và để chạy báo cáo đầy đủ về mọi thứ được tìm thấy . Tôi nói với họ rằng tôi hoàn toàn chắc chắn rằng chúng tôi sẽ tìm thấy một số "khung thời gian" ẩn giấu.

Họ đã tính tỷ lệ hàng giờ của tôi, nhân nó lên 40 và xác định nó "quá đắt để làm điều đó". Câu chuyện dài, tôi rời khỏi đó trong vòng 60 ngày. Khoảng 3 năm sau, tôi biết được việc thu hồi sản phẩm, chi phí lên tới 9 con số (100 triệu đô la), chưa kể thiệt hại cho danh tiếng của công ty.

Tôi sẽ không đề cập đến công ty, sản phẩm hoặc ngành công nghiệp, nhưng tôi vẫn giữ liên lạc với một trong những kỹ sư ở đó và khi anh ấy giải thích cho tôi điều gì đã gây ra sự thu hồi, tôi trợn mắt - đó là một vấn đề sẽ xảy ra thậm chí còn bị bắt bởi một công cụ phân tích tĩnh cơ bản (truy cập một mảng ngoài giới hạn). Công bằng mà nói, tôi không thể nói chắc chắn rằng vấn đề nằm ở mã khi tôi ở đó, nhưng tôi chắc chắn nếu họ đã chi tiền cho một loại công cụ phân tích tĩnh nào đó, lỗi đó sẽ không thoát ra.

Vì vậy, họ đã tiết kiệm $ 295 bằng cách không mua PC-Lint (OK, họ cũng đã tiết kiệm được một tuần để trả tiền cho tôi) - nhưng tôi không đủ khả năng để tính phí 100 triệu đô la trong một tuần.

Đó là những gì tôi gọi là một sự lãng phí tiền bạc khá lớn.

Nhắc tôi về một trò đùa mà nhiều bạn có thể đã nghe:

Bạn đã bao giờ nghe câu chuyện về động cơ tàu khổng lồ thất bại chưa? Các chủ tàu đã thử một chuyên gia khác, nhưng không ai trong số họ có thể tìm ra cách khắc phục động cơ. Sau đó, họ mang đến một ông già đã sửa chữa tàu từ khi còn là một cậu bé. Anh ta mang theo một túi dụng cụ lớn, và khi đến nơi, anh ta lập tức đi làm. Anh kiểm tra động cơ rất cẩn thận, từ trên xuống dưới.

Hai trong số các chủ tàu đã ở đó, theo dõi người đàn ông này, hy vọng anh ta sẽ biết phải làm gì. Sau khi nhìn mọi thứ, ông lão thò tay vào túi và rút ra một cây búa nhỏ. Anh nhẹ nhàng gõ một cái gì đó. Ngay lập tức, động cơ chao đảo vào cuộc sống. Anh cẩn thận cất cây búa của mình đi. Động cơ đã được sửa! Một tuần sau, các chủ sở hữu nhận được hóa đơn từ ông già với giá 10.000 đô la.

"Gì?!" các chủ sở hữu kêu lên. "Anh ấy hầu như không làm gì cả!"

Vì vậy, họ đã viết cho ông lão một ghi chú rằng: "Xin vui lòng gửi cho chúng tôi một hóa đơn được ghi thành từng khoản."

Người đàn ông đã gửi một hóa đơn có nội dung:

  Tapping with a hammer ........ $ 2.00

  Knowing where to tap ......... $ 9998.00

Nỗ lực là quan trọng, nhưng biết những gì bạn đang làm sẽ tạo ra sự khác biệt.

Đội ngũ phát triển cồng kềnh và năng suất khủng khiếp trong các công ty phần mềm.

Đây là hệ quả của mô hình phổ biến trong thế giới kinh doanh: tầm quan trọng của người quản lý được đo lường bằng số lượng cấp dưới, do đó mối quan tâm số một của người quản lý không phải là năng suất mà hoàn toàn ngược lại: năng suất kém hơn là lý do tốt nhất để thuê nhiều người hơn .

Trong một công ty bán phần mềm ... cung cấp cho nhân viên bán hàng toàn bộ hoa hồng cho tất cả các mod tùy chỉnh được bán, do đó, việc bán thứ gì đó đã tồn tại và chúng tôi có thể kiếm lợi nhuận gần như không mang lại lợi nhuận cho họ như bán một lần. Điều này được kết hợp với việc di chuyển nhân viên bán hàng nửa vòng đất nước từ các nhân viên kỹ thuật.

Điều này cũng có nghĩa là chúng tôi trong Phát triển không thể đáp ứng thời hạn bán hàng, khiến khách hàng không hài lòng và gặp khó khăn lớn trong việc hoàn thành bất kỳ công việc cốt lõi nào giúp sản phẩm tốt hơn cho mọi người. Áp lực gia tăng khiến chất lượng mã giảm và ảnh hưởng đến tinh thần, đặc biệt là khi chúng tôi nghe những câu chuyện về văn phòng bán hàng (điều mà tôi chưa bao giờ xác nhận).

Rất nhiều người trong chúng ta bực bội Bán hàng, nhưng thực tế đó không phải là lỗi của họ. Họ đã đi ra ngoài và bán càng nhiều càng tốt, làm những gì họ được khen thưởng theo đúng giới hạn đã được đặt trên họ. Đó là quản lý tồi đã gây ra tất cả những vấn đề này.

Có hai cái mà tôi đã trải nghiệm.

1. Hủy bỏ một dự án có ROI khổng lồ cho doanh nghiệp đã hoàn thành khoảng 80% và sau đó bàn giao 100 chiếc iPod khắc và mạ vàng cho các giám đốc điều hành cấp cao.

2. Sa thải vài trăm người và ngày hôm sau tuyên bố tăng lương và thưởng cho các giám đốc điều hành cấp cao.

Những thứ này không hoàn toàn liên quan đến lập trình, nhưng chắc chắn đã lãng phí rất nhiều tiền, cộng với việc cung cấp một cái tát vào mặt cho tất cả những người liên quan.

Tôi đã không bị sa thải, nhưng tôi cũng không được tăng lương hay iPod ...

Tôi đã thấy một vài dự án gia công khủng khiếp đã thành công trong việc tăng chi phí đáng kể trong khi không tăng hoặc thực sự làm giảm hiệu quả.

Trong trường hợp xấu nhất, đội ngũ thuê ngoài mới đã được đưa vào và có kỹ năng nhưng đội trên bờ hiện tại vẫn giữ nguyên vì nhóm thuê ngoài không tin tưởng thực sự làm bất kỳ công việc quan trọng nào.

Tại thời điểm này, điều hợp lý cần làm rõ ràng là chấp nhận thất bại và đóng cửa đội ngũ thuê ngoài nhưng vì ban quản lý không sẵn sàng thừa nhận rằng nó đã không hoạt động nên cả hai đội đều ở lại (với chi phí tăng đáng kể không tăng hiệu quả hoặc khả năng sử dụng) cho đến khi toàn bộ điều có thể bị chôn vùi.

Trong một trường hợp phát triển khác đã được thuê ngoài và nhóm ban đầu đã nghỉ việc. Hai năm sau, họ nhận ra rằng nó đã không hoạt động và trả tiền để mang lại toàn bộ lô trong nhà chỉ để thấy rằng ngoài các chi phí rất đáng kể của việc bàn giao khác, tác động của việc mất kiến ​​thức, phí tuyển dụng, chấm dứt hợp đồng và vì vậy trên, tổ chức thuê ngoài đã mất một đoạn đáng kể của mã nguồn.

. các dự án chủ yếu

Nợ kỹ thuật

Tôi đã thấy là "con ngựa chết" kinh niên của mã di sản. Hay hơn nữa, từ quan điểm của các chiến hào, vô số thời gian dành cho chế độ bảo trì khi cả đội biết rằng chúng ta nên ở chế độ thay thế.

Những gì chúng ta đã làm .... vẫn đang tiếp tục. Cố gắng để thay đổi tích cực từ bên trong

Kiểm tra năng suất

Đơn giản, không làm điều đó. Một lần nữa, vẫn làm việc trên sự thay đổi tích cực từ bên trong.

Tôi đã làm việc với một vài tổ chức nhà nước và họ thật tuyệt vời khi lãng phí tiền cho CNTT. Từ việc mua phần mềm trung gian cồng kềnh để giải quyết các vấn đề cực kỳ đơn giản đến việc trả hàng ngàn và hàng ngàn đô la cho một nhà cung cấp để họ tạo ra một CSV. Không có người trong nhà có đủ kinh nghiệm, có vẻ như họ sẽ bị mất chi phí trả trước hoặc bảo trì.

Trong các công ty phi phần mềm (ngân hàng, bảo hiểm) với CNTT nội bộ, tiền đến từ các nhóm kinh doanh khác nhau. Các nhóm kinh doanh trực tiếp nhận được doanh số từ các nhà cung cấp và sẽ đẩy nó lên CNTT. Họ đang trả tiền cho phần mềm / phần cứng và tiền lương của bạn để cuộc biểu tình của bạn sẽ không đi đến đâu.

• Trả tiền cho các ứng dụng cồng kềnh và phần mềm trung gian có giá trung bình năm con số và thậm chí không phù hợp với kiến ​​trúc hệ thống hiện có
• Sử dụng các phần mềm đắt tiền như HP QualityCenter, BMC Remedy, HP LoadRunner, v.v ... nơi có sẵn các tùy chọn tốt hơn và rẻ hơn
• Với các đội đa thành phố rất nhiều chi phí đi lại, đôi khi chỉ trong vài giờ họp
• Trả tiền cho giấy phép windows 7 mà somes với các máy mới và sau đó trả tiền một lần nữa để hạ cấp xuống Windows XP vì SOE mới (được thiết kế năm 2010) vẫn là XP
• Quá dung lượng trong phần cứng

Tôi làm việc trong nghề kiểm tra hiệu suất và tôi chứng kiến ​​(theo nghĩa đen) hàng triệu đô la mỗi năm bị các tổ chức xả xuống cống vì bốn lý do

1. Thuê một người đăng việc chỉ dựa trên giá, không đủ kỹ năng và không thường xuyên kiểm tra các kỹ năng của người kiểm tra hiệu suất. Thuê một người kiểm tra hiệu suất nghiệp dư cũng giống như thuê một thợ sửa ống nước nghiệp dư hoặc thợ điện nghiệp dư, họ sẽ mất nhiều thời gian hơn để làm các công việc cơ bản, rất nhiều kiểm tra và số dư trong quá trình bị mất, và khi bạn tìm ra cách xấu họ đã tốn kém khủng khiếp để sửa chữa (trong sản xuất). Là người điều hành cho nửa tá diễn đàn trong lĩnh vực này, tôi quan sát mọi người thường xuyên xuất hiện những người thiếu kỹ năng cơ bản về kiểm tra, giao tiếp, quản lý dự án, phát triển, phân tích hệ thống, v.v ... và họ chỉ đơn giản là bị ném vào một công cụ. Đối với người đã lưu ý LoadRunner là một sự lãng phí tiền bạc trước đó, nếu bạn ném một kẻ ngốc vào một công cụ, chỉ có một kết quả mà bạn nên mong đợi.

2. Không thu thập yêu cầu hiệu suất. Điều này tác động đến toàn bộ tổ chức vì bạn sẽ có một quan điểm khác về hiệu suất trong Kiến trúc, Kỹ thuật nền tảng, Kỹ thuật ứng dụng, QA chức năng và QA hiệu suất, không ai trong số đó có thể thực sự phù hợp với các bên liên quan kinh doanh (và thường không). Đây là một vấn đề quy trình đối với nhiều tổ chức, nhóm kiểm tra hiệu suất được yêu cầu cả hai để thu thập các yêu cầu về hiệu suất và kiểm tra chống lại chúng. Để kiểm tra và cân bằng hợp lý, bạn nên làm cái này chứ không phải cái kia. Liên quan đến 1 ở trên với đội ngũ nhân viên chưa trưởng thành, bạn sẽ có những người thậm chí không thể nhận ra yêu cầu hiệu suất phù hợp, không có điểm đo lường để xác thực với cấu hình tải và họ vẫn đang xây dựng "tập lệnh để chạy". Đây là một sự lãng phí thời gian và công sức và không có nhiều để cải thiện chất lượng. Hiệu suất cần một viễn cảnh chung trong toàn tổ chức và không phải là thứ chỉ có thể được giải quyết vào cuối nếu nó không được thiết kế để bắt đầu.

3. Kiểm tra hiệu suất quản lý môi trường. Tôi không thể cho bạn biết có bao nhiêu tổ chức bị trì hoãn để kiểm tra môi trường không sẵn sàng để chạy vào thời điểm tổ chức kiểm tra sẵn sàng tiến hành. Chỉ trong một khách hàng, tôi có thể thấy đây là một vấn đề trị giá hàng triệu đô la về số giờ bị mất trong khi chờ đợi

4. Các nhà quản lý dự án không hiểu về kiểm thử hiệu năng là gì, nhiệm vụ nào có liên quan hoặc mức độ nỗ lực tại chỗ, nhưng ai đang ra lệnh cho các hoạt động nên diễn ra trong bao lâu. Điều này dẫn đến sự khác biệt trong lịch trình dự án hoàn toàn liên quan đến cách các hạng mục đã được lên lịch (và kết quả là chi phí vượt mức). Điều này liên quan trực tiếp đến 1 ở trên cũng như đối với những người thử nghiệm chưa trưởng thành không thể dự đoán chính xác số lượng và loại nhiệm vụ cũng như thời gian thực hiện các nhiệm vụ. Đó là một tiên đề rằng nếu bạn cho phép một người không hiểu bạn làm gì và tại sao bạn làm điều đó để ra lệnh cho cách bạn làm việc và bạn sẽ mất bao lâu, thì con đường này sẽ dẫn đến thất bại. Nó xảy ra tất cả quá thường xuyên trong thử nghiệm hiệu suất.

Hệ thống kiểm soát phiên bản độc quyền. Với trạng thái Git và Mercurial, tôi không hiểu tại sao mọi người lại tìm kiếm thứ gì đó với người giữ cổng.

Bạn không chỉ phải trả tiền cho VCS, bạn còn phải trả cho mỗi người dùng. Ngoài ra, tính linh hoạt của bạn bị bắn vào chân. Bạn cũng có thể mặc một chiếc áo phông có chữ "I ♥ Vendor Lock In !!!"

Tôi cảm thấy ngày nay thật không vui khi không sử dụng một VCS (D) miễn phí. Nếu bạn muốn có nhiều tiện ích bổ sung đi kèm, những thứ như Kiln có sẵn.

Tôi không nghĩ rằng tôi sẽ đi làm cho một người khăng khăng đòi BitKeeper hoặc tương tự.

Tôi gần như đã nói điều tương tự về trình giả lập, nhưng các sản phẩm như Simics tiếp tục mang lại lợi thế đáng kể so với các lựa chọn thay thế miễn phí.

Cuộc họp tình trạng & báo cáo hàng tuần

Một tổ chức tôi làm việc là tất cả về các báo cáo tình trạng hàng tuần - được triển khai ở 3 cấp độ khác nhau. Nhà phát triển dẫn và kiểm tra khách hàng tiềm năng cho mỗi trong số 4 - 6 dự án trên chuyến bay báo cáo tiến trình của họ trong một email dài, sau đó được người quản lý tiếp theo đưa lên, lần lượt được tóm tắt tùy ý bởi người tiếp theo.

Ngày làm việc tiếp theo, tất cả các khách hàng tiềm năng của dự án tập trung trong một cuộc họp kéo dài 1 giờ để xem qua báo cáo.

Hiệu quả một ngày mỗi tuần được dành cho báo cáo tiến độ của tuần đó. Hãy nhớ rằng đây là tất cả tách biệt với các cuộc họp hàng ngày và các cuộc họp demo / hồi tưởng hàng tuần.

Tôi làm việc cho một cơ quan công cộng. Thực sự không có cách nào để giải thích thỏa đáng mức độ lãng phí có thể xảy ra khi nơi làm việc bị luật pháp hóa và liên minh quá nhiều đến nỗi việc sa thải ai đó thực tế là gần như không thể.

Các nhà quản lý chơi vượt qua các bưu kiện với các nhân viên tồi, và hy vọng loại bỏ tất cả chúng cùng một lúc dưới sự tái cấu trúc. Một số nhân viên xấu được thăng chức, chỉ để di chuyển họ ra khỏi một khu vực cần cải thiện. Bất kỳ nhân viên tốt nào cũng phải vật lộn liên tục chỉ để bù đắp cho công việc của nhân viên tồi. Nhân viên bạn sẽ không giữ trong 3 tháng rèn nghề 40 năm. Số tiền họ lãng phí cho sự nghiệp như vậy là thiên văn.

Tôi đã làm việc trong khu vực tư nhân trước đây và thấy rất nhiều chất thải, nhưng chất thải của khu vực công là một môn thể thao hoàn toàn khác, chứ đừng nói đến trò chơi bóng.

Nó đã được đề xuất trong một bình luận rằng thiết lập các tội lỗi cho nhân viên hoạt động kém sẽ giúp đỡ. Nó sẽ giúp trong việc nó sẽ hạn chế thiệt hại họ có thể làm, nhưng sẽ không ảnh hưởng đến nguyên nhân gốc rễ của vấn đề. Tôi nghĩ rằng điều tốt nhất sẽ là việc áp dụng một số quy trình tuyển dụng và quản lý khu vực tư nhân, và thay đổi luật pháp để giúp các cơ quan công quyền dễ dàng hơn trong việc cho phép các nhân viên làm việc kém hiệu quả. Các công đoàn cũng nên thay đổi chính sách của mình khi tham khảo ý kiến ​​với chính phủ - vai trò của họ trong việc bảo vệ các thành viên của họ rất quan trọng, nhưng họ nên nhận ra rằng đôi khi các thành viên của họ thực sự ra khỏi chiều sâu của họ, và nên được tiếp tục

Một dự án tôi đã làm việc với một tổ chức tài chính lớn. Có số lượng lớn các cuộc gọi hội nghị hàng ngày và tôi ước tính rằng họ đã đốt khoảng 100 nghìn đô la mỗi ngày chỉ bằng các cuộc gọi hội nghị. Dự án kéo dài khoảng 2 năm. Họ có hàng tấn hệ thống kế thừa và khi những thay đổi tiết kiệm ánh sáng ban ngày được thực hiện vài năm trước, họ đã trả cho Microsoft khoảng nửa triệu đô la để đưa ra bản vá DST cho NT 3.51.

Chúng tôi đã có một lượng công việc nhỏ và hầu như không lập hóa đơn và bảng lương trong một cửa hàng nhỏ nơi tôi làm việc. Giải pháp: thuê một chuyên gia tư vấn hiệu quả và thư ký riêng cho sếp để anh ta có thể thực hiện nhiều công việc "thịt và khoai tây" hơn.

Giải quyết thiếu hụt ngân sách bằng cách tăng chi tiêu ... thất bại.

Về mặt tích cực - chuyên gia hiệu quả đã cung cấp một bảng xóa khô, nơi chúng tôi theo dõi số giờ có thể thanh toán và số giờ phải trả ... đoán xem ai có số giờ ít nhất có thể tính hóa đơn.

Hãy xem, chúng ta đã từng chi hơn nửa triệu đô la để thực hiện công việc để giành được hợp đồng triệu đô. Quá nhiều cho lợi nhuận trên đó. Một số người trong nhóm phát triển đề xuất dự án đã cố gắng chỉ ra điều này nhưng nó đã trở thành niềm tự hào cho công ty nhỏ của chúng tôi để giành chiến thắng trước các công ty Fortune 500 mà chúng tôi đang cạnh tranh. Chúng tôi đã thắng và mất tiền trong tay với hợp đồng nắm tay vì lý do đó và những lý do khác nhưng chúng tôi có quyền khoe khoang.

Là một nhà thầu chính phủ một lần, tôi buộc phải làm thêm giờ không được trả lương vì hợp đồng cho phép và nhà thầu được trả tiền cho thời gian làm thêm của tôi. Tôi không chỉ bị cuốn vào công việc của mình và dành 4 giờ mỗi Chủ nhật để lướt Internet mà không có việc gì để làm. Không cần phải nói tôi đã đi rất nhanh sau khi họ bắt đầu điều đó vô nghĩa.

Mua Clarity làm hệ thống quản lý dự án của chúng tôi, một ứng dụng thương mại rất tệ, 100% những người sử dụng nó đã năn nỉ quay lại hệ thống trồng trọt cũ của chúng tôi (một người thích và chọn nó đã chuyển sang một số khác công ty), mọi người thậm chí đã tình nguyện làm việc vào thời gian riêng của họ để thêm báo cáo họ muốn vào hệ thống cũ của chúng tôi. Nhưng chúng tôi đã đầu tư tiền nên chúng tôi bị mắc kẹt với nó. Nói cách khác, từ chối bỏ đi thứ gì đó không hiệu quả chỉ vì nó đắt tiền.

Chất thải tuyệt vời. Một chi tiêu CNTT đã bị cắt giảm bởi nhiều triệu. Vì vậy, cách để làm điều này là đưa dân IT đến từ khắp nơi trên thế giới. Đặt chúng trong một khách sạn flash trong một tuần. Sau đó, trong tòa nhà nơi tổ chức các cuộc họp, đặt một tầng mới. Đá cẩm thạch tất nhiên. Và qua đêm, giữa các cuộc họp mỗi ngày, tòa nhà đã được trang trí lại. Đó là mỗi buổi tối trong một tuần.

Ơ ... ưu tiên ai?

Vùng đất tuyệt vời.

Công ty tôi làm việc đã trả 800 đô la cho Giấy phép CHART FX - Thậm chí đó không phải là tiền của tôi mà tôi cảm thấy bị cướp.

http://www.softwarefx.com/sfxNet Products / ChartFX /

Chỉ cần đá, phần mềm của họ sẽ đặt các tệp ở khắp mọi nơi bao gồm các tệp đăng ký và chương trình .... vâng tất cả những thứ đó cho một số biểu đồ tìm kiếm.