12 điều phá hủy sự sáng tạo của nhà phát triển

Rất nhiều bài viết đề cập đến vai trò của tech lead và người quản lý kỹ thuật. Một chủ đề khá phổ biến mà chúng ta thường gặp là làm thế nào để tăng năng suất của team. Nhưng trước khi bạn tập trung năng lượng để cố gắng tăng năng suất của mình, trước tiên bạn có thể muốn xem xét điều gì đã phá hủy nó. Thật không may, mặc dù Peopleware đã được xuất bản gần 30 năm trước, chúng tôi thấy rất nhiều team bị giảm năng suất rất lớn theo một số cách (tiêu cực) đáng chú ý!

Không ai mong muốn một lập trình viên hoàn thành công việc hàng ngày mà không cần truy cập vào máy tính, nhưng có nhiều công ty mong muốn các lập trình viên hoàn thành công việc mà không cần truy cập vào tâm trí của họ. Điều này cũng không thực tế.

Vì vậy, hãy đi sâu vào danh sách về 12 điều ngăn cản các nhà phát triển làm việc hiệu quả.

1. Sự gián đoạn và các cuộc họp

Sự gián đoạn là tác nhân giảm năng suất hàng đầu tới các nhà phát triển. Các nhà phát triển không thể dễ dàng quay lại nơi họ đã ở ngay trước khi bị gián đoạn. Họ cần phải đi vào tư duy để phát triển và sau đó từ từ quay trở lại nơi họ bị ngắt quãng. Điều này sẽ lấy đi hơn 30p của nhà phát triển. Và càng nhiều sự gián đoạn, sự thất vọng càng nhiều, công việc kém chất lượng, càng có nhiều lỗi và nó cứ thế diễn ra.

Còn các cuộc họp thì sao? Sự khác biệt duy nhất giữa một cuộc họp và sự gián đoạn đó là cuộc họp là một sự gián đoạn có kế hoạch, thậm chí nó còn tồi tệ hơn. Các nhà phát triển không thể tiến hành một nhiệm vụ nếu họ biết rằng họ sẽ bị gián đoạn trong khi thực hiện nó. Vì vậy, nếu họ có một cuộc họp trong một hoặc hai giờ, họ sẽ không thể tiến hành bất cứ điều gì, vì hầu hết các task về kỹ thuật mất khá nhiều thời gian.

Vậy, làm thế nào để có thể tránh được điều này?

Hãy tổ chức các cuộc họp ngắn vào đầu ngày hoặc ngay trước bữa trưa, hoặc thậm chí cuối giờ về để tránh những gián đoạn không cần thiết.

2. Micro-management

Trong các mức độ quản lý, micro-management có thể nói là người kém nhất về năng suất của các nhà phát triển. Chắc chắn, micro-management có xu hướng nhiều cuộc họp và gián đoạn ngoài dự kiến. Không chỉ có thế, họ thể hiện sự thiếu tin tưởng bằng cách đó, bạn cảm thâý họ liên tục làm giảm các kỹ năng và khả năng hoàn thành công việc của chính mình. Bất kỳ động lực nào mà một nhà phát triển có sẽ biến mất vào thời điểm xảy ra các lần gián đoạn đó. Tác động vượt quá năng suất. Micro-management có thể là lý do đầu tiên để các nhà phát triển rời đi, hoặc ít nhất, để thay đổi nhóm.

3. Sự mơ hồ

Có nhiều cách để minh họa cho sự mơ hồ. Các báo cáo lỗi như "Nó sai, hãy sửa nó!" không đủ thông tin để nhà phát triển giải quyết. Nhận tiện, chúng ta có template báo cáo lỗi có thể giúp đỡ trong trường hợp này.

Hoặc không rõ thông số kỹ thuật trên một tính năng, trong trường hợp đó, các nhà phát triển sẽ bắt đầu triển khai những gì họ cảm thấy đúng, trước khi họ phải bắt đầu lại từ đầu một khi người quản lý giải thích chi tiết hơn về hành vi dự kiến.

Ưu tiên không rõ ràng cũng thuộc về thể loại này. Thời gian mà một nhà phát triển tự hỏi nếu họ đang làm việc đúng nhiệm vụ có thể dễ dàng bỏ qua được. Và nếu bao giờ họ nhận được một nhận xét từ người quản lý hỏi tại sao họ làm việc với nhiệm vụ cụ thể này thì bạn sẽ nhận được rất nhiều sự thất vọng.

4. Seagull Management

Bạn đã bao giờ nghe nói về nó? Điều này xảy ra khi các nhà quản lý không giải quyết được hoàn toàn công việc, nhưng họ chỉ cần ngồi lại với nhau để loại bỏ tất cả. "Điều này là sai, và điều này có vẻ tồi tệ", v.v.., Hành vi này gây ra nhiều suy nghĩ tiêu cực, thất vọng cho nhà phát triển, làm cho nhà phát triển không thể quay trở lại với trạng thái ổn định về tâm lý cũng như sự tập trung hàng giờ, thậm chí là trong nhiều ngày.

5. Lợi ích cá nhân bị xâm phạm

Bạn đã bao giờ có một người quản lý hoặc nhà phát triển, người đã lấy lấy đi thành quả công việc của bạn đã làm trong tuần qua. Với nhà phát triển thì năng lực là trên hết. Cướp đi thành quả công việc của người khác là lấy năng lực của họ và loại bỏ nó khỏi người đó. Điều này được đánh giá khá cao trong danh sách, vì nó tạo ra quá nhiều căng thẳng đến nỗi nó làm giảm năng suất của toàn bộ các nhà phát triển trong một thời gian dài.

6. Môi trường - Tiếng ồn, chuyển động, thiết kế không gian làm việc

Điều này có vẻ lạ đối với những người không lập trình, nhưng môi trường mà các nhà phát triển làm việc có tác động quan trọng đến các hoạt động của họ. Ví dụ, có một số tiếng ồn, nghe thấy ô tô và xe tải chạy qua - giúp họ tập trung tốt hơn. Bởi vì đây là lý do tại sao rất nhiều người trong chúng ta đặt tai nghe vào tai.

Tương tự, nếu không gian làm việc được thiết kế để có nhiều chuyển động nhất có thể, điều đó sẽ không giúp họ tập trung! Hoặc có màn hình máy tính để bàn được định hướng theo cách mà các nhà quản lý có thể nhìn thấy rõ, điều đó tạo ra một số căng thẳng và thậm chí nhiều cơ hội hơn để bị gián đoạn.

7. Sự đáng sợ của phạm vi (scope)

Scope creep trong quản lý dự án đề cập đến những thay đổi không được kiểm soát trong phạm vi của dự án. Điều này có thể xảy ra khi phạm vi của một dự án không được xác định đúng.

Scope creep biến các yêu cầu tương đối đơn giản thành quái vật phức tạp khủng khiếp và tốn thời gian! Và hầu hết thời gian nó xảy ra trong quá trình phát triển! Chẳng hạn, đối với tính năng đơn giản:

Phiên bản 1 (trước khi triển khai): tính năng là Chế độ hiển thị bản đồ vị trí.

Phiên bản 2 (khi phiên bản 1 gần như đã hoàn thành): tính năng được đổi thành bản đồ 3D.

Phiên bản 3 (khi phiên bản 2 gần như đã hoàn thành): một lần nữa tính năng được đổi thành biểu thị 3D. Bản đồ vị trí mà người dùng có thể bay qua.

8. Quy trình định nghĩa sản phẩm

Cái này thoạt nhìn có vẻ lạ, nhưng thực sự khá dễ hiểu. Nếu một nhóm sản phẩm xác định các ưu tiên của nhóm mà không bao giờ xác thực thì sự quan tâm của các tính năng tương ứng và các nhà phát triển thấy rằng hầu hết các tính năng cuối cùng không được sử dụng, họ sẽ cảm thấy rằng những gì họ làm vô dụng và sẽ mất đi động lực. Tất cả chúng ta đều muốn cảm thấy có sức ảnh hưởng và điều đó có thể còn quan trọng hơn đối với các nhà phát triển.

9. Thiếu cân nhắc đến món nợ kỹ thuật

Nợ kỹ thuật là một quyết định có chủ ý để thực hiện giải pháp không phải là tốt nhất hoặc viết mã không phải là tối ưu nhất để phát hành phần mềm nhanh hơn. Nhận một số nợ kỹ thuật là không thể tránh khỏi và có thể tăng tốc độ phát triển phần mềm trong ngắn hạn. Tuy nhiên, về lâu dài, nó góp phần vào sự phức tạp của hệ thống, làm chậm các nhà phát triền. Những người không lập trình thường đánh giá thấp sự mất năng suất và bị cám dỗ luôn luôn tiên về phía trước, và điều đó trở thành một vấn đề.

Nhưng nếu tái cấu trúc không bao giờ là một phần của các ưu tiên, nó sẽ không chỉ ảnh hưởng đến năng suất mà còn cả chất lượng sản phẩm.

10. Đa công cụ và phần cứng

Các nhà phát triển sử dụng nhiều công cụ để lập trình, đẩy và hợp nhất mã của họ mỗi ngày. Càng tự động hóa, càng tốt. Không cần phải nói rằng nếu bạn sử dụng các công cụ "ancient", sẽ ảnh hưởng đến năng suất của bạn. Tương tự, có một màn hình lớn so với chỉ một máy tính xách tay có thể có làm việc. Với chi phí phần cứng và tiền lương của nhà phát triển, chỉ cần tăng 5% năng suất chắc chắn là điều đáng để đầu tư vào mọi thời điểm! Chỉ cần cung cấp các công cụ và phần cứng mà nhóm nhà phát triển của bạn thích.

11. Tài liệu hướng dẫn

Khi học code, chúng tôi được yêu cầu comment đầy đủ và chi tiết với tần suất thường xuyên. Thật không may, nhiều lập trình viên giải thích không chính xác điều này có nghĩa là họ phải bình luận dòng code để giải thích những điều mà họ làm, đó là lý do tại sao chúng ta thường thấy mã như thế này.

r = n / 2; // Đặt r thành n chia cho 2
// Vòng lặp trong khi r - (n / r) lớn hơn t while (abs (r - (n / r))> t) {r = 0.5 * (r + (n / r));
// Đặt r thành một nửa của r + (n / r)
}

Bạn có biết mã này làm gì không? Tôi cũng không. Vấn đề là trong khi có rất nhiều ý kiến mô tả những gì đoạn code này đang làm, thì không có mô tả nào nói lên tại sao nó lại làm như vậy. Nếu có một lỗi trong chương trình và bạn tình cờ tìm thấy mã này, bạn sẽ không biết bắt đầu từ đâu.

12.Deadline

Điều cuối cùng này nói lên xu hướng của các nhà quản lý là để các nhà phát triển tự estimate, sau đó thúc đẩy họ hạ thấp các ước tính đó càng nhiều càng tốt, và sau đó coi chúng là deadline! Các nhà quản lý thậm chí sẽ xem xét rằng, vì bản thân các nhà phát triển đã quyết định dựa trên ước tính, họ đã cam kết về deadline, và do đó deadline được coi là đủ hợp lệ để chia sẻ với quản lý cấp trên.

Không có gì đáng ngạc nhiên, các nhà phát triển cảm thấy rằng những deadline đó là không hợp lý và có chút gì đó tùy tiện; điều này tạo ra căng thẳng và làm giảm khả năng tập trung.

Làm thế nào là tất cả những điều duy nhất cho các nhà phát triển? Nếu bạn nhìn vào tất cả 12 điều, chúng thực sự là khá phổ biến đối với hầu hết các công việc dựa trên dự án khác. Chỉ là tác động của mỗi điều trên này thậm chí còn quan trọng hơn đối với các nhà phát triển, vì họ cần tập trung để tiến tới các nhiệm vụ của mình.

Nếu bạn nhận ra một số điểm đề cập ở trên có trong công ty của bạn, có thể sẽ rất thú vị khi giải quyết chúng với các nhà phát triển của bạn. Nói chuyện với họ; tìm hiểu xem đây có phải là một vấn đề không và làm thế nào để giải quyết nó. Dù họ nói điều gì, điều quan trọng nhất là tin tưởng vào phản hồi và hiểu biết của họ. Và trong khi công nghệ ngày nay rất khác so với 30 năm trước, bài học vẫn như vậy. Bạn không thể bỏ qua yếu tố con người khi bạn xem xét năng suất của đội. Lặp lại các quy trình , môi trường và thói quen làm việc của bạn với nhóm của bạn và để họ hướng dẫn bạn cách có năng suất và tác động cao nhất.

Nguồn tham khảo: https://medium.com/@AdelHanyads/12-things-that-destroy-developer-creativity-4cbc574f556a