Làm việc với coder? 10 điều sau sẽ giúp đỡ công việc của bạn trở nên suôn sẻ hơn.

Nếu bạn phải đoán điều coder ghét nhất là gì, bạn sẽ trả lời sao?

Trên Quora, câu hỏi này đã lôi kéo 90 replies và gần 450k lượt xem. Rõ ràng việc này khá lôi kéo được sự quan tâm của mọi người. Điều khiến tôi ngạc nhiên là một vài việc mà các coder phàn nàn lại có thể tránh được khá rất dễ.

Trong bài viết này, tôi muốn giới thiệu với các bạn các best practices trong quản lý dự án được làm tại công ty tôi, giúp đỡ chúng tôi duy trì một quy trình làm việc phù hợp và giữ cho nhân lực của mình luôn có động lực làm việc.

Tôi nghĩ rằng sẽ rất thú vị khi hỏi các lập trình viên tôi làm việc cùng tại Apptension về những cái họ không thích, để tôi có thể đối chiếu quan điểm của họ với các câu trả lời trên Quora.

Những sai lầm cần tránh khi làm việc với các lập trình

Tại Apptension chúng tôi cố sức duy trì một không gian làm việc vui vẻ và năng suất, điều nãy đã được đưa vào chiến lược làm thương hiệu của mình.

Vì vậy, tôi đã hỏi đồng nghiệp của tôi một câu hỏi này: coder ghét gì?

Đây là những gì họ nói với tôi.

1. Requirement không ra gì

– Đôi khi đó là những lỗ hổng trong đưa ra, dự án không xác định hoặc trao đổi không rõ ràng giữa khách hàng, PM (project manager) và lập trình viên đến phần mềm còn nhiều thiếu sót.

– Nếu khách hàng hoặc người quản lý không nắm rõ về sản phẩm của họ, họ không nên mong muốn người khác có thể đọc vị họ và làm những việc họ chưa hề đề cập đến.

– Công việc của người quản lý là tổng hợp đưa ra tài liệu của dự án một cách hoàn chỉnh nhất, để lập trình viên không cần phải đoán già đoán non hoặc tự đi hỏi về các đưa ra đặc tả.

2. Những công việc lặp đi lặp lại

– Làm một việc lần này qua lần khác không những gây nhàm chán, nó còn có thể khiến con người ta mệt mỏi. việc này có thể diễn ra khi một người chỉ làm một dự án trong một thời gian dài. Nó cũng có thể diễn ra khi một chức năng mà khách hàng cứ đổi ý đòi sửa hoài.

– Dù lí do là gì đi nữa, nếu lập trình viên cảm thấy kiệt sức bởi các đưa ra lặp đi lặp lại, đó có lẽ là lúc người quản lý nên tiếp chuyện với họ. Nếu có thể, hãy điều chuyển nhân lực đó sang dự án khác. Đôi khi một sự đổi khác dễ hiểu ở công việc mà một người đang đảm nhiệm có thể làm công việc thú vị hơn nhiều và khiến cho người đó giữ lửa trong công việc. Tại Apptension, chúng tôi dùng Officevibe để nghiên cứu nhân lực một cách ẩn danh, để xem mức độ hài lòng của nhân lực trong công việc.

3. Technical debt (Nợ kỹ thuật)

– Technical debt là hệ quả của việc dùng phương án dễ hiểu mà không suy nghĩ về kỹ xảo mở rộng của dự án trong tương lai.
Nói cách khác: đó là kết quả của việc chọn lựa cách giải quyết việc không hẳn là tốt nhất mà chỉ vì nó có thể được làm nhanh chóng và rất dễ.

– Lý do các lập trình viên ghét Technical debt rất dễ hiểu: Cũng giống như nợ nần tài chính, một lúc nào đó bạn sẽ phải “trả nợ”, mà trong phát huy phần mềm có nghĩa là giải quyết cùng một việc một lần nữa.

– Để trả nợ, các lập trình viên thường cần viết lại code để hoàn tất “công việc còn dang dở”. Nó cũng gây ra việc trễ deadline, vì rất khó để ước tính được lượng việc cần làm để trả xong nợ.

phương án : đừng làm gì đó chỉ bởi vì nó có vẻ rất dễ. Hãy suy nghĩ về các phương án tốt nhất có thể và thực hiện nó chỉ 1 lần thôi.

4. Không đủ hoặc quá nhiều chức năng

– Không trọng dụng nhân lực có thể làm giảm động lực làm việc của họ, trong khi giao quá nhiều việc lại khiến họ mệt mỏi, kiệt quệ.
Một công ty tốt có thể giới hạn cả hai tình trang trên bằng cách phân chia nhân lực một cách phù hợp. Các công cụ như teamdeck có thể giúp đỡ quản lý, duy trì nguồn tài nguyên (nhân lực) phù hợp giữa các dự án và giám sát việc dùng tài nguyên của nhóm.

5. Sự gián đoạn

– Phải mất có thể tận 45 phút để một coder có thể vào guồng, ở trạng thái tập hợp sâu sắc nhất, đảm bảo năng suất lớn nhất. mặc dù vậy bị sao lãng lại nhanh hơn nhiều. Đôi khi chỉ một câu hỏi được hỏi trực tiếp hoặc từ những trình chat như Slack khiến coder đánh mất trạng thái tập hợp cực độ.

– Một cách khác khiến việc tập hợp gián đoạn là context switching (đổi khác ngữ cảnh). Điều này có thể diễn ra khi một lập trình viên đang phải đảm nhiệm nhiều dự án khác nhau trong ngày.

– Việc công ty điều chuyển nhân lực có thể gây lãng phí thời gian hoặc làm dự án bị chậm trễ vì nhân lực cần thời gian để chuyển từ dự án này sang dự án khác .Trong khi quản lý dự án, cố sức lên chiến lược cụ thể và tránh làm gián đoạn các coder khi họ đang làm việc.

– Đối với những gián đoạn nhỏ, hãy làm “quy tắc tai nghe”. Có nghĩa là nếu một nhà phát huy đang đeo tai nghe thì đừng làm phiền họ. Các việc quan trọng quan hệ đến dự án cố sức giải quyết trong cuộc họp scrum – đó là tác dụng của buổi họp đó. Việc này sẽ giúp đỡ công việc của coder ít căng thẳng và có tác dụng hơn.

6. Các cuộc họp không rất cần

– Không phải tất cả cuộc họp là rất cần. Và đảm bảo coder không cần lúc nào cũng phải có mặt trong đa phần các cuộc họp đó.

– mặc dù vậy, có những cuộc họp cần phải có sự góp mặt của các coder như sprint planning, các buổi đánh giá dự án hay retrospectives. Ở đây họ có thể trả lời các câu hỏi kỹ thuật hoặc để cùng thảo luận về quá trình phát huy.

– Lên chiến lược họp hành, quyết định xem các lập trình viên có cần tham dự hay không. Nếu không, họ có thể dành thời gian đó có tác dụng hơn cho dự án.

7. QAs kém

– Đảm bảo rằng code có chất lượng là điều quan trọng. Và hầu như các nhà phát huy đều hiểu được vai trò của QA.

– Nhưng điều mà coder ghét, là những tester trình độ kém, những người làm gián đoạn công việc của họ thay vì giúp đỡ tối ưu code với các báo cáo có ý nghĩa.

– Các QA kém nổi bật gây phiền hà và làm gián đoạn công việc khi họ ưu tiên các việc sai, chú trọng vào các lỗi nhỏ thay vì các việc chính hoặc khi họ bỏ qua các tin tức quan trọng trong các báo cáo lỗi.

– Mặt khác, QA giỏi có thể đảm bảo chất lượng của phần mềm và giúp đỡ các lập trình viên trong công việc của họ, thay vì làm gián đoạn nó.

– Khi tuyển dụng người dùng của nhóm đảm bảo chất lượng (QA), hãy chọn lựa sáng suốt bởi vì nó sẽ không những đem lại chất lượng tuyệt vời cho phần mềm, mà còn làm cho mối quan hệ giữa họ và các lập trình viên ít đau thương hơn.

8. Lộ trình không rõ ràng

– Đối với mỗi chức năng trong phát huy phần mềm cần phải có một thời gian hoàn tất rõ ràng.

– Các mốc quan trọng giúp đỡ xác định khi nào một chức năng nhất định phải được hoàn tất, và khi nào khách hàng kì vọng lập trình viên thực hiện sản phẩm.

– Một lộ trình không rõ ràng hoặc thiếu sót làm cho nhóm khó khăn hơn trong việc đánh giá độ ưu tiên của các chức năng trong dự án và bàn giao chức năng đúng hẹn.

– Một lý do khác để lên lộ trình làm việc tốt hơn là việc làm việc theo team của lập trình viên cần phải đồng bộ công việc của nhiều người để bàn giao một chức năng nhất định.

– Khi chạy dự án cần tìm hiểu đã có lần thời điểm của nó, bao gồm các cuộc họp scrum, hạn bàn giao chức năng, và hạn bàn giao sản phẩm. tiếp nữa đánh dấu những mốc đó vào lịch của lập trình viên.

9. Không tính đến các sự kiện trong sprint planning

– Quản lý dự án phù hợp giúp đỡ các nhà phát huy chú trọng vào đúng việc đúng lúc.

– Tính các sự kiện như Sprint Review, Retrospective, Planning và Daily Standups trong lịch của lập trình viên đảm bảo luồng dự án hợp lí.

– Nếu không làm điều đó, mỗi lần gọi đi họp sẽ là một lần làm gián đoạn coder, và bạn đã biết rằng nó sẽ gây phiền nhiễu và gián đoạn công việc của họ.

10. Ước tính công việc theo giờ

– Uớc tính công việc theo giờ hay được xem như là “đọc lá chè” (một cách để dự đoán tương lai).

– Vì các coder khác nhau cần lượng thời gian khác nhau cho cùng một công việc, thật khó để đặt mốc hoàn tất chính xác.

– mặc dù vậy, vẫn còn nhiều nhà quản lý đưa ra ước tính thời gian cho công việc và coi chúng như là thời hạn hoàn tất công việc.

– Mặc dù việc một công ty ước tính một dự án sẽ mất bao lâu là quan trọng, nó cần được làm dựa trên các dự án giống như thời gian này và luôn biết rằng nó không có nghĩa là dự án mới sẽ cần chính xác số giờ đó.

– Để nâng cao kỹ xảo ước tính của mình, bạn có thể xem xét point của các story (chức năng phải hành động). Đó là một khái niệm Scrum được dùng để ước lượng công sức hoàn tất một story. Story point bao gồm cả số lượng công việc và tính phức tạp của nó. Nếu một công ty theo dõi story points, họ có thể dự đoán tốt hơn các dự án dựa trên các story giống như từ trước.

Kết luận

– Nắm rõ những điều khiến coder khó chịu, bạn có thể giữ cho nhân lực của mình động lực làm việc và chú trọng vào những thứ rất cần

– Tránh những điều trên trong công ty có thể giúp đỡ tạo ra một nơi làm việc hạnh phúc hơn cho nhóm của bạn.

– Và như nghiên cứu cho thấy, nhân lực hạnh phúc có năng suất lên đến 12% so với người không hạnh phúc.

BÀI VIẾT ĐƯỢC DỊCH TỪ NGUỒN https://hackernoon.com/10-things-you-can-do-better-while-working-with-programmers-68f92f671378

Nguồn viblo.asia