Thúc đẩy các nhà phát triển trong một dự án được coi là buồn tẻ?

Là người quản lý, tôi không thể luôn luôn tạo ra công việc tiên tiến. Một số dự án chạy trên chế độ bảo trì và tạo ra dòng tiền miễn phí lành mạnh cho công ty.

Là một nhà phát triển, điều gì sẽ khiến bạn gắn bó trong dự án này? Tôi đã nghĩ đến việc xây dựng lại thương hiệu cho công việc, nhưng tôi có thể làm với rất nhiều sự giúp đỡ ở đây.

EDIT: Cảm ơn tất cả các bạn đã góp ý. Cho đến nay đây là những gì chúng ta đã có:

1. Luân chuyển công việc theo sở thích của nhà phát triển
2. Môi trường làm việc linh hoạt
3. Phân bổ thời gian để làm việc trên các dự án vật nuôi
4. Xã hội và vui vẻ
5. Xây dựng thương hiệu của dự án
6. Sử dụng điều này như một bước đệm cho các dự án khác

Đối với các dự án trong chế độ bảo trì, hãy nghĩ về những gì tiếp theo. Điều gì cuối cùng sẽ làm cho họ không hấp dẫn đối với khách hàng của bạn? Để tránh lỗi thời, họ có cần các tính năng mới, hiệu suất tốt hơn hoặc để được đơn giản hóa? Nếu bạn bắt đầu lại, một số dự án có thể được sáp nhập? Chúng có nên được xây dựng với các công cụ, ngôn ngữ hoặc quy trình khác nhau không? Có những cải tiến hoặc hướng mà không ai xem xét? Có nhà phát triển của bạn trả lời một số trong những câu hỏi này. Xây dựng nguyên mẫu. Hãy thử một ngôn ngữ hoặc khung mới. Cung cấp cho một dự án một giao diện di động mới.

Dễ dàng hơn để thử nghiệm các lựa chọn thay thế khi không có thời hạn cuối cùng. Sử dụng thời gian buồn tẻ để vượt qua đối thủ cạnh tranh của bạn.

Bạn cần cung cấp cho họ một cái gì đó để chiếm thời gian của họ. Các dự án trong chế độ bảo trì thường không yêu cầu 40 giờ một tuần từ mỗi nhà phát triển. Nếu có thì có lẽ có gì đó không ổn với phần mềm, nhưng dựa trên cách bạn đặt câu hỏi, tôi giả sử rằng bạn đang tìm kiếm ý tưởng để chiếm lĩnh các nhà phát triển của bạn trong khi không có nhiều việc phải làm. Tôi không biết ngân sách tài chính của bạn là gì, nhưng tôi nghĩ một số ưu đãi như gửi chúng đến một hội nghị phần mềm có thể hữu ích. Một đề nghị khác có thể bao gồm rõ ràng cho phép họ khám phá sở thích riêng của họ trong 15 giờ một tuần. Ai đó có thể quan tâm đến việc khám phá các thuật toán sắp xếp nói hoặc thiết kế cơ sở dữ liệu. Nó có thể không liên quan trực tiếp đến doanh nghiệp của bạn, nhưng tôi không thể hình dung rằng cuối cùng bạn sẽ không được hưởng lợi từ kiến ​​thức gia tăng của họ. Chỉ cần đừng ép họ làm việc mà không có gì để làm. Cho phép họ chiếm thời gian của họ với một cái gì đó khác nếu không có nhiều việc phải làm. Tôi nghĩ thật công bằng khi yêu cầu tóm tắt những gì họ đang làm để đảm bảo rằng họ không chỉ duyệt web một cách ngẫu nhiên, mà hãy để họ khám phá một chút.

Làm cho nó vui vẻ để làm việc trên dự án.

Trong thực tế các dự án thú vị là khá hiếm. Và các nghiên cứu cho thấy hạnh phúc của nhân viên phụ thuộc rất nhiều vào xã hội và niềm vui. Họ ồ ạt đề cập đến đồng nghiệp khi họ được hỏi tại sao họ không rời bỏ công việc hiện tại.

Đó là lý do tại sao bạn phải luôn vui vẻ khi nghe thấy tiếng cười trong tòa nhà thay vì la hét.

Đối với tôi, động lực tốt nhất trong tình huống đó là các mục tiêu rất rõ ràng, đặc biệt là dưới dạng một đặc điểm kỹ thuật tốt. Hoặc, thay vì tốt nhất, đó là một trong số ít những thứ bạn còn lại để cung cấp. Lý do là nếu bản thân công việc không thú vị, biết rằng tôi sẽ làm lại một loạt những thứ buồn tẻ đó là một công cụ giải thích lớn hơn nữa. Điều đó có thể phụ thuộc vào lập trình viên nhận ra rõ ràng giá trị của một đặc điểm kỹ thuật, mặc dù.

Một điều nữa là làm rõ rằng thật buồn tẻ, các dự án tạo thu nhập là vì lợi ích của mọi người - không có thu nhập, không có công việc, v.v. Công việc cần phải được thực hiện, nếu không bạn sẽ không có đủ tiền để giữ chúng trên tàu Chỉ ra điều này một cách rõ ràng, đôi khi mọi người không nhận ra.

Sau đó, chia tải. Cố gắng tìm ra cách giữ giới hạn của công việc nhàm chán và phiền phức (tùy thuộc vào loại công việc, phân chia các ngày trong tuần, phân chia công việc, v.v.) để không ai có cảm giác họ bị mắc kẹt với tất cả những thứ lộn xộn trong khi những người khác phải làm những điều hài hước.

Sau đó, cố gắng thậm chí với những điều thú vị. Và nói chuyện với các nhà phát triển, họ có thể có những ý tưởng tốt.

Bạn phải thay đổi nhận thức về dự án "buồn tẻ". Nếu nó tạo ra thu nhập tốt, điều đó không thể làm được.

Thông thường, các dự án này là tốt cho các lập trình viên của bạn là người tầm thường và hạnh phúc là tầm thường. Bạn biết đấy, những người không đam mê lập trình và những người chỉ xem nó như một cách để trả các hóa đơn. Bây giờ, hãy hiểu điều gì đó: Tôi không nói điều này bởi vì họ là những lập trình viên yếu hơn và bạn muốn làm cho cuộc sống của họ trở nên khốn khổ. Tôi đang nói điều này bởi vì đây thường là những kiểu người không mong đợi công việc của họ sẽ là nguồn hoàn thành trong cuộc sống của họ. Bởi âm thanh của nó, những âm thanh này giống như áp lực thấp, dòng thu nhập ổn định. Nhiều khả năng, những công nhân này rất vui khi nhận một số công việc dễ dàng, áp lực thấp.

Tất nhiên, điều đó không có nghĩa là bạn chỉ có thể giao cho họ những nhiệm vụ buồn tẻ và quên chúng đi. Có lẽ bạn có thể cung cấp cho "Người chơi A" 80% nhiệm vụ thú vị / 20% nhiệm vụ buồn tẻ, "Người chơi B" của bạn có thể là 50/50 và "Người chơi C" của bạn có thể là 20/80.

Hãy để các nhà phát triển của bạn kiếm được thời gian trả tiền để làm việc với các dự án thú cưng / nguồn mở / thú vị của riêng họ bằng cách thực hiện một số công việc nặng nề. Cung cấp cho họ một số hỗ trợ với các loại dự án này, đặc biệt nếu công việc nằm trong dự án hoặc chương trình nội bộ. Đó là một chiến lược mà Google sử dụng, tôi nghĩ sao?

Tôi phải thừa nhận rằng tôi chưa bao giờ làm việc trong một dự án buồn tẻ và không thú vị, vì vậy tôi không chắc rằng tôi hiểu câu hỏi của bạn. Và tôi phát triển hệ thống doanh nghiệp để kiếm sống. :) Nghiêm túc mà nói, trong thực tế tôi đã thấy rằng các lập trình viên bị làm phiền bởi công việc "nhàm chán" ít hơn tôi mong đợi. Công việc vô ích, như điền vào bảng chấm công mà không ai từng kiểm tra là vấn đề lớn hơn nhiều. Điều đó đang được nói:

Biết sở thích lập trình viên của bạn; một số lập trình viên không thích GUI, một số tránh xa SQL. Cố gắng tôn trọng sở thích đó, vì một nhiệm vụ nhàm chán với một lập trình viên có thể thú vị với người khác. Nếu không thể phân chia công việc theo cách như vậy vì bất kỳ lý do gì, hãy làm cho nó trở nên thú vị bằng cách tăng tính cạnh tranh - hãy để họ cạnh tranh ai sẽ là người đầu tiên hoàn thành phần của mình hoặc tạo bảng điểm cho phần nào có mã ít nhất lỗi trong QA. Microsoft được biết đến với văn hóa doanh nghiệp của họ, điều này khiến các lập trình viên cạnh tranh theo các cách tiếp cận khác nhau và chọn cách tốt nhất cuối cùng hoặc kết hợp các phần tốt nhất của mỗi cách tiếp cận trong sản phẩm cuối cùng.

Việc sở hữu một phần sản phẩm và kiểm soát nó cũng làm tăng đáng kể sự tham gia của một người. Ngược lại, không có gì nhàm chán hơn việc có ai đó quản lý công việc của bạn. Ngoài ra, nếu có một nhiệm vụ định kỳ mà mọi người đều ghét, giải thích bức tranh lớn hơn - đó là việc phải làm và tại sao và xoay người thực hiện nó mỗi tuần thường là quá đủ.

Tôi đã có / nhìn thấy thành công với việc sử dụng loại dự án này như là con đường dẫn đến những dự án thú vị hơn.

Nếu tất cả các nhà phát triển mới và trung cấp của bạn bắt đầu trong các dự án "buồn tẻ" đặt câu hỏi của các nhà phát triển cấp cao (những người đang ở các dự án khác hầu hết thời gian) và bạn nói rõ rằng bạn càng làm tốt trong khu vực bảo trì thì càng tốt có khả năng bạn sẽ có được sự tham gia trong tương lai vào công việc mới, sau đó giả sử bạn có một nhóm tốt và thực sự theo dõi với sự thay đổi nhóm thỉnh thoảng và thỉnh thoảng kéo các nhà phát triển chính vào công việc mới mà các nhóm sẽ tự sắp xếp.

Nếu bạn có một nhóm xấu, hoặc một nhóm rất tốt thì phương pháp này có thể không phù hợp với bạn.