Tôi quan tâm đến việc biết cách xử lý một quy trình phát triển phần mềm hiện tại đã không được thay đổi trong nhiều năm và cuối cùng sẽ dẫn đến thất bại của sản phẩm và nhóm. Vâng, có lẽ cách dễ dàng hơn để giải quyết điều này là thay đổi công việc, nhưng với nền kinh tế này thì nói dễ hơn làm. Tuy nhiên, nếu bạn có ví dụ cụ thể và đã thấy hoặc đã nhiều lần trong cùng một tình huống và nghĩ rằng giải pháp tốt nhất để giải quyết các vấn đề này, là rời khỏi công ty, thì hãy ủng hộ câu trả lời của bạn. Vấn đề là, câu hỏi này thực sự có câu trả lời đặc biệt là nếu nhiều chuyên gia về vấn đề này chỉ ra rằng con đường tốt nhất để đi là: tuyến đường A.
Tôi biết hàng tấn nhà phát triển đã hoặc đang ở trong tình huống tương tự. Đây là một trong những lý do chính tại sao các công ty đi từ vị trí số 1 trong thị trường của họ để trở thành người cuối cùng hoặc thậm chí ra khỏi thị trường. Hy vọng rằng câu trả lời trong bài viết này sẽ giúp các nhà phát triển khác gặp phải trở ngại tương tự. Trong một nhóm phát triển nhỏ hoặc lớn, điều này thường xảy ra:
- Một số nhà phát triển dường như không quan tâm và quyết định đi theo dòng chảy và thích để lại mã với nhiều mã có mùi như vậy và quá trình phát triển như là,
- Những người khác cảm thấy mệt mỏi vì không có sự thay đổi và từ chức và chuyển sang một công ty khác,
- Những người khác dường như sợ nói chuyện và thích giữ im lặng,
- Đôi khi rất ít nhà phát triển hoặc chỉ một người cố gắng lên tiếng để cải tiến sản phẩm và nói với nhóm rằng tầm quan trọng của việc tuân theo các thực tiễn mã hóa tốt nhất và lợi ích của việc đó đối với khách hàng, người dùng và nhóm. Những nhà phát triển loại này thường quyết định ở lại với nhóm vì những lý do như công ty cung cấp lợi ích mà rất ít công ty phần mềm cung cấp hoặc sản phẩm có nhiều tiềm năng, v.v.
Sản phẩm trong nhóm của chúng tôi chỉ là một phần nhỏ mà công ty có được doanh thu vì nó có một chiếc ô sản phẩm (công ty này không phải là công ty phần mềm / phần cứng; do đó, không có vụ kiện bằng sáng chế liên tục, ít nhất là cho đến nay bất ổn). Những gì tôi đã học được cho đến nay trong những năm này từ kinh nghiệm của các nhà phát triển khác và kinh nghiệm của tôi là để thực sự biết một nhóm phát triển, phải mất thời gian, không phải ngày, cũng không phải tuần, mà là vài tháng. Trong quá trình phỏng vấn nếu nhóm muốn thuê bạn, hoặc cần bạn; họ làm cho mọi thứ nghe có vẻ tuyệt vời, và họ có thể cho bạn biết những gì bạn muốn nghe. Tuy nhiên, thực tế lại khác khi bạn bắt đầu làm việc trong nhóm đó và bắt đầu đào sâu vào mã và tiến tới quy trình SDLC hoàn chỉnh. Đây là khi là một nhà phát triển, bạn bắt đầu nhìn thấy thực tế của công việc bạn đã làm. Thực tế này khiến bạn khó muốn chuyển từ công ty này sang công ty khác bởi vì thật khó để biết liệu công ty bạn chuyển đến sẽ tốt hơn hay tồi tệ hơn. Vâng, bạn có thể đọc các đánh giá của Glassdoor, v.v., nhưng có bao nhiêu trong số những đánh giá trực tuyến đó là có thật, và không phải từ HR?
Điều gì sẽ là cách tốt nhất để giải quyết các vấn đề được nêu dưới đây khi xem xét rằng người quản lý ngay từ đầu đã luôn chống lại sự thay đổi và các nhà phát triển trước đó đã làm điều tương tự trong nhiều năm?
Thiếu sản phẩm Đổi mới trong nhiều năm: Sản phẩm có rất nhiều tiềm năng và mang lại doanh thu tốt cho công ty, nhưng sản phẩm có vẻ như đã được sản xuất 20 năm trước. Một số người dùng đã phàn nàn rằng sản phẩm không thân thiện với người dùng cũng không trực quan và những người khác đã đề cập đến việc sử dụng các ứng dụng như Gmail và cảm thấy thất vọng khi sử dụng sản phẩm vì không có các tính năng tương tự. Vấn đề chính ở đây là khi bạn cố gắng làm nhà phát triển để thay đổi sản phẩm và bắt đầu di chuyển các yếu tố chính của sản phẩm xung quanh chỉ một vài pixel (để làm cho nó thân thiện hơn với người dùng hoặc trực quan hơn), người quản lý hoảng loạn và nói với bạn để đặt nó trở lại nơi nó đã được. Nếu bạn cố gắng thêm một tính năng có lợi cho năng suất cho người dùng, người quản lý sẽ yêu cầu bạn xóa tính năng này vì "người dùng đã quen với việc thực hiện quy trình theo cách đó, v.v." Tôi nghĩ rằng bạn có quan điểm chống lại sự thay đổi, cải tiến và đổi mới (người quản lý không sẵn sàng thay đổi, ngay cả khi bạn là nhà phát triển cung cấp các lập luận mạnh mẽ về lợi ích). Công ty có một vài đối thủ cạnh tranh trong lĩnh vực (sản phẩm của một vài trong số đó cạnh tranh hơn), nhưng bằng cách nào đó công ty đã duy trì các khách hàng hiện tại trong nhiều năm.
Thiếu sự phối hợp quản lý dự án: Do đó, một số dự án được giao trễ, có lỗi và một số khách hàng phàn nàn (khách hàng cũng báo cáo lỗi) hoặc ngân sách được sử dụng quá nhanh trước khi giao dự án, v.v. Tôi đã cung cấp cho họ một vài mẹo phối hợp dự án và các ý tưởng hiện đang được sử dụng thường xuyên để theo dõi tiến độ của các dự án và nhiệm vụ cần thực hiện.
Phần mềm xấu Thực tiễn phát triển: Mùi mã được nhìn thấy trên hầu hết nếu không phải tất cả các tệp, không có tài liệu, dự phòng mã, tầng đầu cuối và mặt sau trộn trên cùng một tệp, các công cụ phát triển lỗi thời, không có môi trường thử nghiệm thực tế cũng như các công cụ kiểm tra (chỉ sao chép và dán các tệp từ môi trường dev đến sản xuất, và sau đó kiểm tra thủ công rằng mọi thứ có vẻ tốt và phát hành). Hầu hết các công cụ phát triển tôi sử dụng để phát triển và thử nghiệm mà nhóm không biết, vì nhóm chỉ sử dụng 2 IDE để phát triển mã và kiểm soát nguồn chỉ khả dụng cho môi trường phát triển. Các nhà phát triển khác đã cố gắng sử dụng các khung công tác mới nhất để cải thiện các vấn đề hiện tại, nhưng người quản lý không thích nó vì "nếu bạn rời đi, thì ai sẽ duy trì mã đó?, Hãy để nó theo cách đó" rời đi và chuyển đến một công ty khác.
Tóm lại, tôi chắc chắn các tình huống tương tự xảy ra với nhiều nhà phát triển ở các công ty khác nhưng do hoàn cảnh khác nhau, nhà phát triển có thể thích ở lại nhóm hơn là đến công ty khác vì lý do như (thuận tiện trong công việc, linh hoạt trong công việc, hoặc lợi ích của công ty hoặc chỉ vì một cơ hội tốt hơn đã không đến). Không có công ty hoàn hảo mà tôi biết, nhưng bạn sẽ là nhà phát triển ứng xử và tiếp cận tất cả các vấn đề này như thế nào để giữ mọi thứ tích cực và cuối cùng thúc đẩy thay đổi để cải thiện sản phẩm và cải thiện quy trình phát triển phần mềm (cho dù bạn có nhiều năm kinh nghiệm phát triển hay chỉ một vài)? Tôi biết đây là bài viết dài, nhưng tôi thích cung cấp thêm chi tiết để tăng cơ hội nhận được phản hồi hữu ích hơn.
Cảm ơn rất nhiều cho tất cả thông tin phản hồi và thời gian của bạn