Tôi đã tham gia vào ba dự án rõ ràng là thất bại. Những điều này khá đau đớn nhưng nhìn lại, hai trong số ba người không có hậu quả tiêu cực đối với sự nghiệp của tôi và thậm chí người thứ ba không phải là ngày tận thế.
Dưới đây là một số quan sát tôi nhớ lại.
Các nhà phát triển ở các vị trí cấp dưới ("mã theo thông số kỹ thuật", "sửa lỗi", những thứ như vậy) sẽ không bị ảnh hưởng nhiều, trừ khi họ chùng bước do tinh thần bị hạ thấp trong đội. Tại những vị trí như thế này, một chiến lược sinh tồn hợp lý và thậm chí đôi khi thành công có thể chỉ là làm tốt nhất có thể.
- Ví dụ, một trong những thất bại mà tôi gặp phải đã được khắc phục bằng cách khắc phục một cách đơn giản, có phương pháp hơn một trăm lỗi đã biết (kết hợp với cách tiếp cận đặc biệt thông minh để thúc đẩy tiến trình này bằng lãnh đạo công nghệ) cuối cùng đã khiến ban lãnh đạo quyết định khôi phục dự án và đưa ra đó là một cơ hội khác với một bản phát hành mới, từ đó tạo ra một thành công hợp lý.
Các lập trình viên ở các vị trí cao hơn, có ảnh hưởng sẽ tốt hơn để chuẩn bị chia sẻ những hậu quả tiêu cực của thất bại dự án. Một kiến trúc sư, lãnh đạo công nghệ, nhà phát triển cao cấp thường được kỳ vọng sẽ tạo ra một tác động đủ lớn để được coi là chịu trách nhiệm cho thành công hay thất bại của dự án.
Ở vị trí cấp cao, một người tốt hơn nên được chuẩn bị để đạt được từ thất bại "một cách gián tiếp", bằng cách phân tích những gì đã sai và những gì có thể được thực hiện tốt hơn.
Những kiến thức, bài học sau khi chết có thể là vô giá nếu được học đúng, sự nghiệp rất thành công ở các vị trí cấp cao có thể phụ thuộc vào mức độ chúng được học, như được giải thích trong câu trả lời xuất sắc này tại WP :
Sự phán xét không đến từ thành công, mà đến từ những thất bại. Hầu hết các công ty muốn thuê những người đã bị thất bại bởi các công ty trước đó ...
Trên một lưu ý thực tế hơn, người ta có thể coi phương pháp "phát hành tiếp theo / cập nhật" là một cách có thể thoát khỏi thất bại. Trùng hợp hay không (tôi nghĩ là không ), nhưng cả hai thất bại không gây thiệt hại cho sự nghiệp của tôi đều diễn ra theo những kịch bản rất giống nhau: phát hành Nlà một thảm họa hoàn toàn, phát hành N+1có thể chấp nhận được, phát hành N+2và sau đó là thành công rõ ràng.
Đi trong đôi giày của bạn, rất có thể tôi sẽ nỗ lực chuẩn bị / thúc đẩy ý tưởng "phát hành tiếp theo". Tạo (và giao tiếp !) Một cái gì đó giống như một danh sách dự kiến các vấn đề đã biết mà bạn muốn khắc phục sau khi phát hành theo kế hoạch. Dự thảo một bản đồ đường bộ không chính thức cho bản phát hành tiếp theo.
Hãy nghĩ về cách bạn có thể truyền đạt những ý tưởng này đến mọi người xung quanh, làm thế nào bạn có thể tác động đến quản lý để xem xét kế hoạch này. Nếu dự án có người có kỹ năng tiếp thị tốt, hãy cố gắng liên kết họ để khấu hao thiệt hại thất bại bằng cách gói các bản phát hành sắp tới thành các thuật ngữ mượt mà hơn, như "truy cập sớm", "beta", "xem trước khách hàng", "phát hành giới thiệu", đại loại như cái đó.
Hãy nghĩ về một kế hoạch dự phòng trong trường hợp nếu những người cao hơn sẽ xuất hiện điếc với ý tưởng này. Hãy nhớ câu chuyện trên về "sửa chữa hơn trăm lỗi đã biết"? Có một cơ hội cho mọi thứ thay đổi, thực sự.
Quản lý có thể bị điếc trước những ý tưởng phát hành tiếp theo ngay bây giờ, nhưng có một cơ hội tốt để họ xem xét lại khi đối mặt với bằng chứng thuyết phục mạnh mẽ về tiến độ chất lượng dự án.
- Rất có khả năng sẽ có khoảng thời gian khá dài giữa mã đóng băng để phát hành theo kế hoạch và quyết định quản lý để loại bỏ hoàn toàn. Thời gian đó là cơ hội của bạn: nếu bạn tập trung nỗ lực khắc phục các sự cố đã biết và "truyền giáo" đúng tiến trình, điều này có thể tạo ra sự khác biệt (như nó đã từng làm với tôi).
