3 điều không ổn của công ty cũ (phần 1)

Manh

November 4, 2017

Bài viết

Bài viết này nhằm mục đích chỉ trích những vấn đề mà bản thân mình cảm thấy không ổn khi làm việc trong công ty công nghệ. Công ty cũ ở đây có thể là một, hoặc một vài công ty mà mình đã từng làm việc, ngắn hạn hay dài hạn. Tuy nhiên bài viết này sẽ không đề cập đến vấn đề của một tập thể xác định nào.

Mình sử dụng cụm từ “công ty cũ” ở đây để nhấn mạnh tính trải nghiệm được đưa vào bài viết, để phân biệt với các bài phân tích dựa trên những quan điểm hoặc cơ sở khác.

(Note: hiện tại mình đã ngừng đi làm và tiếp tục học ngành Kỹ thuật Phần mềm của đại học FPT)

Trên đây là vài dòng mở đầu để mọi người hiểu rõ về mục đích của bài viết, từ đó có thể nhìn nhận vấn đề mà mình đưa ra một cách toàn diện hơn: theo các khía cạnh kỹ thuật, quản lý, đạo đức nghề nghiệp, người chủ, người làm thuê, leader, team member … thay vì nghĩ rằng đây là một bài nói xấu các công ty mình không thích và không còn làm việc ở đó 😀 .

1. Task tracking

Công việc sẽ rất kém hiệu quả khi không thể biết được cả team đang làm những task nào, và cần thiết hơn có thể là biết về những task đã được dự định trước. Đặc biệt mình không hề đồng tình với một leader giao việc bằng lời nói với team member hoặc để một vài team member tự giao việc cho những team member khác.

Nói về vấn đề giao việc, cá nhân mình thấy nó ảnh hưởng trực tiếp từ tầm nhìn của leader lớn hay nhỏ. Bởi nếu như có thể hình dung toàn cục hơn về sản phẩm đang phát triển, sự cải thiện có thể được tạo ra khi bạn điều chỉnh những task mà bạn giao để hợp với dự định mà bạn vẽ ra trong tương lai (đây chính là mục đích của thiết kế phần mềm).

Khi phát triển một sản phẩm cho người sử dụng, leader sẽ là người chịu trách nhiệm định hình. Thiết kế tốt cần được chứng minh rõ trước khi có sản phẩm vận hành được. Cụ thể hóa thiết kế và mổ tả tốt các task cũng là một phương pháp khiến team member của bạn thấy thuyết phục và làm việc có định hướng hơn là họ chỉ hiểu rằng đang được giao một công việc và phải hoàn thành nó.

Leader không nên viện cớ “bận code” để hạn chế thời gian điều phối công việc ở trong team. Code của leader kém quan trọng hơn việc hỗ trợ các thành viên khác code thật tốt – một leader xuất sắc sẽ làm được điều này thay vì biến mình thành nhân vật “gánh team”. Leader thường làm việc tốt hơn người khác bởi trong tâm trí của họ có nhiều hình dung và nhiều thông tin hơn, từ đó suy ra rằng một ai đó cũng có thể làm tốt nếu như họ tiếp cận được với những điều tương tự như leader.

Nếu không có yêu cầu cụ thể được viết ra cho các task và làm tốt task tracking, hãy cùng mong đợi những điều sau đây sẽ xảy ra:

– Chất lượng task kém: khi không làm rõ những điều leader muốn team member làm, họ sẽ tốn hầu hết thời gian giải quyết các khía cạnh họ cho là quan trọng. Thử tưởng tượng một database engineer mất vài ngày để thiết lập các tối ưu cho nhiều kết nối đồng thời và nhận được thông tin rằng team code chỉ sử dụng 1 kết nối. Tất nhiên một database engineer có kinh nghiệm sẽ đề phòng được vấn đề này. Ý tưởng mình muốn nói ở đây đó là một người quản lý cần đảm bảo được công việc tiến triển tốt dù team member là người mới ra trường, họ chưa biết có những trường hợp nào sẽ xảy ra và sẽ tốt hơn khi họ chỉ cần tập trung hoàn thành những gì được giao. Team member biết làm rất nhiều thứ nhưng không biết như thế nào là hiệu quả cho sản phẩm mà bạn muốn. Hãy chỉ cho team member biết bạn cần gì. Người thiết kế cần định nghĩa như thế nào là “tốt” để người thực thi tiến hành công việc.

– Tốn nhiều thời gian: team member sẽ có khả năng sẽ phải băn khoăn về công việc khi có nhiều phương pháp để đạt được kết quả mà leader đưa ra. Và thường một team member sẽ khó nắm bắt được công việc của những bên khác để đưa ra lựa chọn phù hợp. Trường hợp team member chưa hiểu rõ, họ sẽ trao đổi với đồng nghiệp, hoặc hỏi lại leader hay là cả hai. Dù là trường hợp nào xảy ra, thì đều là những yếu tố trì hoãn công việc thực sự được tiến hành.

– Không có sự thống nhất: vòng tuần hoàn giao việc và thực thi công việc cần có thêm những công đoạn khác xen vào giữa để tránh sự tùy hứng. Các bước trung gian chính là công cụ hỗ trợ leader tạo nên một phong cách làm việc xác định, không mập mờ. Khi đã rõ ràng và có thể xác định, bạn sẽ biết bước nào là bước kém hiệu quả và tiến hành sửa đổi bước đó. Task tracking sẽ quản lý từ việc đề xuất yêu cầu: mọi cá nhân tham gia vào công việc đều có thể mô tả một ý tưởng mới để cân nhắc thực thi và nhận được đánh giá của cả team. Khi có thể khuyến khích có thêm nhiều ý tưởng, team sẽ học được cách đánh giá độ quan trọng và tính thực tế của một task để quyết định ưu tiên hay bỏ qua task đó,… Cách này sẽ chia sẻ trách nhiệm lên cả team thay vì chỉ 1-2 người đảm nhận việc phân bố task thì có vẻ sẽ hơi quá sức và dẫn đến những tiếp cận không hiệu quả.

Comments

comments

Related Posts

3 điều không ổn của công ty cũ (phần 2)

Manh

November 22, 2017

Bài viết

2. Code Review Không nhiều công ty có quy trình Code Review, đặc biệt là các công ty outsource. Họ thường bỏ qua review để cam kết thời gian hoàn thành ngắn nhất và nó cũng dường như là “thừa” khi sản phẩm đã làm hài lòng khách hàng, ít nhất là cho tới thời […]

Read More

Tiếp tục viết blog

Manh

November 2, 2017

Bài viết

Chào các bạn đang xem trang DevNT.org. Đã gần 1 năm qua mình chưa viết thêm bài mới nào cho blog. Quãng thời gian vừa rồi có sự chuyển đổi về hướng đi trong sự nghiệp lập trình của mình đó là tập trung hơn cho lập trình game thay vì lập trình ứng dụng […]

Read More