Nhái Cốm Blog

I love you just the way you are

0R8A4000_

Quản lý lập trình viên

Leave a comment

Tác giả: Jon Evans (@rezendi)
Bài gốc: On Managing Developers

Lược dịch

Tôi là một kĩ sư phần mềm, tiểu thuyết gia, nhà báo, đồng thời cũng là một nhà quản lý; và quản lý các lập trình viên là công việc khó nhằn nhất mà tôi từng làm (không phải công việc nặng nhọc nhất nhưng là công việc khó nhằn nhất). Tôi không tự coi mình là chuyên gia hay một nhà quản lý xuất sắc; nhưng tôi có thể đảm bảo với bạn rằng tôi là một người cầu thị. Dưới đây là một số bài học rút ra từ sai lầm của chính bản thân tôi.

Nắm quyền phụ trách không có nghĩa bạn đang nắm quyền kiểm soát

Điều trớ trêu trong việc quản lý đó là chức vụ của bạn càng cao bao nhiêu, khả năng kiểm soát thực sự của bạn càng ít đi bấy nhiêu. Khi bạn chỉ là một người lập trình bình thường, bạn bắt máy tính thực hiện chính xác những gì bạn muốn. Khi bạn là một nhà quản lý, bạn chỉ hy vọng rằng mọi người hiểu những gì bạn muốn và sau đó tin tưởng (hoặc cầu nguyện) rằng họ sẽ thực hiện chính xác yêu cầu trong thời gian quy định.

Các nhà quản lý có xuất phát điểm là lập trình viên, đặc biệt là những lập trình viên đa năng (full-stack – hay còn gọi là “tài tử”) như tôi, thường gặp khó khăn với vấn đề này. Điều này đặc biệt chính xác khi họ từng do dự trong việc lựa chọn công việc lập trình hay quản lý (một số kết hợp cả hai). Tự mình làm hết mọi việc để đảm bảo nó được thực hiện chính xác là vô cùng khó khăn.

Vẫn đề trở nên khó khăn hơn nữa khi phải phân biệt giữa việc “đó không phải là cách tôi sẽ làm” và “đó là cách làm sai, cần phải tái cấu trúc / viết lại / bố trí lại” khi xem xét công việc của một ai đó. Nhưng bạn cũng phải tạo cơ hội cho những người mới vào để họ phát triển cũng như tạo môi trường cho những lập trình viên có kinh nghiệm để họ phát huy. Bạn phải buộc mình lui lại và chấp nhận rằng việc có ảnh hưởng lớn hơn đi kèm với việc giảm bớt khả năng kiểm soát.

Những nhà quản lý không có xuất phát điểm là kĩ sư thậm chí có ít khả năng kiểm soát cũng như thiếu hiểu biết về quá trình phát triển và khó khăn có thể mắc phải hơn. Tôi không tin kết luận này lắm nhưng không phủ nhận rằng có những người như vậy, thậm chí một số còn là những người giỏi nhất tôi từng làm việc cùng hay làm việc cho. Điều họ mang lại (hy vọng thế) là tăng khả năng suy nghĩ như một khách hàng, người vận hành hay người dùng cuối. Và có lẽ cũng nâng cao khả năng tránh xa khỏi ám ảnh rằng mọi thứ phải luôn nằm trong tầm kiểm soát. Những lập trình viên tiến thân thành nhà quản lý có xu hướng tự coi mình như vị tướng thống lĩnh một đội quân trong khi thực tế bạn là một hoa hiêu đang hy vọng hướng dẫn con tàu vượt qua cơn bão. Ở đó, điều những thủy thủ đoàn làm thực sự rất quan trọng.

Agile rất tốt. Nhưng tại sao là Agile?

Mọi người nói nhiều về phương pháp phát triển; câu trả lời là “quá nhiều” nếu bạn hỏi tôi. Ở nhiều nơi, “phát triển linh hoạt” (Agile development) đã được hệ thống hóa thành một quy trình cố định với những quy định cụ thể cho từng tiến trình như “standup”, “scrum” và “sprint”. Những quy tắc này được ám chỉ mơ hồ như là những nguyên tắc cơ bản trong tuyên ngôn của Agile bao gồm “Tính cá thể và tính tương tác quan trọng hơn qui trình và công cụ” và “Phản ứng với các thay đổi quan trọng hơn tuân thủ kế hoạch”. Vậy các công ty đã tạo ra và tuân theo những gì? Quy trình Agile, công cụ và kế hoạch. Chẹp! Nếu bạn là thạc sĩ được chứng nhận về Scrum, bạn đang làm hoàn toàn sai.

Bất kì quá trình riêng biệt nào được tạo ra có lẽ đều không thích hợp. Nhóm phát triển tốt nhất mà tôi từng làm việc cùng luôn khởi đầu một ngày bằng việc họp nhanh (standup). Một nhóm tệ hại nhất tôi từng gặp cũng làm như vậy. Mọi người tung hô ý kiến của Lean Startup về “Minimum Viable Product” nhưng họ cũng nói về nó như là một thiết kế lỗi thời. Họ muốn một thiết kế phải “đẹp” và “hoàn hảo” để bất kì dự án mới nào đều có thể thành công. Các cuộc họp trực diện có thể cực kỳ hiệu quả nhưng liệu có khả thi cho các nhóm làm việc từ xa ở các vùng địa lý khác nhau? Câu hỏi là: ai mới đúng? Ở đây, như thường lệ, câu trả lời là “điều đó còn tùy”.

Đừng hiểu lầm tôi. Tôi không khuyên bạn vứt bỏ tất cả những phương pháp tốt đã được tạo ra. Tôi chỉ muốn nói rằng các hệ thống cũng như phương pháp bạn chọn cho bất kì dự án nào nên mềm dẻo và linh hoạt; tùy thuộc vào nhóm phát triển cũng như hoàn cảnh cụ thể.

Thật may mắn là tôi được làm việc cho một công ty sử dụng phương pháp Agile nhưng vẫn quan tâm đến những gì thực sự quan trọng. Điều quan trọng nhất của phương pháp phát triển linh hoạt (Agile development) nằm trong chính tên của nó. Bạn phải linh hoạt. Và bạn phải tiến nhanh. (Tất nhiên thực tế là bạn phải viết mã kiểm tra. Điều đó không có trong tên phương pháp nhưng nó cũng rất quan trọng). Theo kinh nghiệm bản thân của tôi, sự trì trệ trong phần mềm chịu ảnh hưởng của hiệu ứng Lindy. Vì vậy bạn phải chuyển gia mã lệnh thường xuyên và liên tục; hiện tại trì hoãn càng nhiều, tương lại bạn càng trì hoãn nhiều hơn. Giống như một con cá mập, nếu bạn không bơi, bạn sẽ chết đói.

Công việc chết tiệt là công việc của bạn

Về cơ bản, công việc của người quản lý là giúp người khác làm việc hiệu quả hơn. Cách tốt để thực hiện điều đó là gì? Thực hiện công việc theo cách của họ. Điều này có nghĩa là bạn phải tìm ra công việc quan trọng nào mà lập trình viên ghét nhất rồi làm việc đó cho họ.

Rất hiếm lập trình viên thích viết tài liệu. Điều này đồng nghĩa viết tài liệu là công việc của bạn. Việc kiểm tra là thực sự quan trọng nhưng cũng chẳng mấy lập trình viên thích viết mã lệnh kiểm tra. Đây cũng là công việc của bạn. Không phải toàn bộ mã lệnh kiểm tra, việc này không cần thiết, nhưng phải đủ để tạo ra một ví dụ, một chuẩn để thúc đẩy những thứ tiếp theo. Bạn không phải là lập trình viên? Hãy học, đủ để tự mình viết mã lệnh kiểm tra. Nếu bạn là một lập trình viên? Hãy xây dựng bộ khung kiểm thử sao cho người khác có thể dễ dàng thêm vào nếu cần. Nếu bạn nghĩa kiểm tra chất lượng là công việc của người khác hay không thuộc trách nhiệm của bạn thì bạn thực sự là một nhà quản lý rất, rất, rất tồi.

Bạn cũng phải làm công việc chết tiệt khác là kết nối mọi người với nhau. Nếu một lập trình viên nói với bạn “đây là một mớ bòng bong, chúng ta phải chấp nhận thương đau bằng việc tái cấu trúc và làm lại cho đúng, tất nhiên phải lui thời hạn hoàn thành lại”, bạn có lẽ cần phải ủng hộ ý kiến đó dù sẽ phải chấp nhận mất mát trong ngắn hạn. Về lâu dài, bạn sẽ được đền đáp. Chỉ giữ những vấn đề kĩ thuật lại nếu nó không gây ra ảnh hưởng về lâu dài.

Kết luận của kết luận của kết luận: con người chính là vấn đề

Thật không may, có lẽ bạn cũng đã biết, con người thật đáng ghét. Người ta chõ mũi vào chuyện của bạn, trêu ngươi, làm ngơ, làm phiền, biến mất, bỏ rơi hoặc mất niềm tin vào bạn; thông thường chẳng vì lý do chính đáng nào cả. Thử đoán xem? Nếu bạn là một nhà quản lý, sự mất kiểm soát của họ là của bạn và ngay cả những vấn đề của họ cũng là vấn đề của bạn. Hãy làm quen với điều này. Bạn cần sớm nhận ra vấn đề của mọi người và có kế hoạch ứng phó với các vấn đề đó.

Ngoài ra, mọi người làm việc theo những cách khác nhau với tốc độ khác nhau. Đó là cách lịch sự để nói rằng việc thuê nhân viên thực sự là quan trọng, bởi vì như tôi đã nói, con người thật sự đáng ghét.

Nhưng đợi chút, bạn có biết cách làm cho mọi người (thật kinh ngạc) ít đáng ghét không? Không phải tôi cố tính tạo sự chú ý nhưng bài học đáng nhớ nhất trong sự nghiệp của tôi là: khi mọi người thấy có thể tin tưởng bạn cũng là lúc bạn thấy tin tưởng mọi người. Tôi thề đó là sự thật!

Vì vậy đừng bao giờ phỉ báng bất kì ai. Lời khen đáng giá nhất mà tôi nhận được là từ ông chủ cũ sau cuộc phỏng vấn. Ông ấy chậm rãi nói với tôi: “Tôi khi biết anh làm thế nào nhưng khi anh nói, mọi người trở nên chân thành hơn”. Hãy nói sự thật theo cách bạn nhìn nhận. Nói khách sáo, xin đừng hiểu lầm tôi, nhưng phải thật lòng. Chỉ có như vậy bạn mói nhận được sự tin tưởng từ người khác.

Về cơ bản bạn là người phiên dịch kĩ thuật cho mọi người

Những nhà quản lý diễn giải toàn cảnh dự án thành những nhiệm vụ độc lập cho từng lập trình viên cùng với những chi tiết cũng như các tương tác cụ thể sẽ diễn ra. Họ cũng diễn giải lại công việc thực hiện bởi lập trình viên nhằm giúp khách hàng, người vận hàng cũng như người dùng cuối có thể hiểu công việc đã hoàn tất. Và có lẽ điều quan trọng nhất là diễn giải lại chi tiết lỗi, hạn chết và cơ hội cho khách hàng, người vận hàng cũng như người dùng cuối. Bất kì dịch giả chuyên nghiệp nào cũng sẽ nói với bạn rằng điều này có nghĩa bạn cần phải hiểu công việc sâu sắc hơn chính bản thân tác giả. Với họ, đó là trực giác nhưng với bạn, đó là công việc. Chia nhỏ mọi thứ theo cách làm sao để bất kì ai đều có thể hiểu được.

Dưới danh nghĩa của một tác giả, tôi xin nói rằng những dịch giả không nhận được bất kì vinh quang nào cuốn sách mang lại. Tất cả những quyết định tốt có được là do tác giả. Tương tự vậy, những người sáng lập (trong trường hợp của chúng tôi là khách hàng) nhận được ca ngợi về sự sáng tạo còn lập trình viên nhận được sự ca ngợi về mã lệnh. Chẳng ai nhìn một em bé xinh xắn rồi ngợi ca những nữ hộ sinh cả.

Vậy thì tại sao lại phải làm công việc này? Lý do như tôi nói là từng cá nhân lập trình viên có thể kiểm soát rất tốt nhưng học lại thiếu tầm ảnh hưởng. Không làm và nhìn nhận theo cách của họ, quyết định bạn đưa ra sẽ ảnh hưởng vĩnh viễn đến việc liệu cái bạn xây dựng có tốt hay không. Và nếu điều đó chẳng có ý nghĩa gì với bạn, bạn không chỉ là một nhà quản lý tồi, bạn còn đang hoàn toàn sai đường lạc lối.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s