Một vài mẹo xây dựng một team chất lượng
team leader
4
White

Lơi Rệ viết ngày 04/03/2016

Sự sống còn của các công ty kỹ thuật phụ thuộc vào nguồn nhân lực chất xám của họ. Thế nên rất thiết yếu cho việc đầu tư xây dựng team có khả năng hoạt động độc lập, chuyển giao nhanh và chất lượng để doanh nghiệp có thể chuyển mình nhanh để cạnh tranh trên thị trường.

Lý thuyết là như thế nhưng thực tế để xây dựng đc một mô hình như thế không phải là chuyện dễ làm và dĩ nhiên nó qua tầm hiểu biết của tôi. Và nếu tôi có hiểu đc đầy đủ thì nó không thể vừa vào một bài viết ngắn ở đây đc. Tôi muốn trích ra một số practices hay mà tôi học lỏm đc ở Envato, hầu hết đều đã được kiểm nghiệm nên các bạn độc giả có thể tự tin thay đổi cho phù hợp mà áp dụng.

Viết xuống tất cả mọi thứ

Vâng, làm việc trong môi trường năng động, với số thành viên team có thể 'đi đi về về' giữa nhiều team hay dự án thì rất quan trọng việc ghi xuống tất cả mọi thông tin quan trọng.

Có nhiều tool giúp cho việc tự động hoá quá trình này, các bạn có thể sử dụng một tài khoản Dropbox hay Google Drive để chia sẻ các file thông tin với nhau. Bên mình thì sử dụng GitHub để lưu trữ đơn giản là vì có thể tìm hiểu đc các thay đổi giữa các phiên bản.

Để tránh gây nhầm lẫn và mất thời gian cho các thành viên của team, một trang phụ lục với các link đến các mục thông tin là một practice tốt. Bên mình có template đơn giản như sau:

## Team các fan cuồng của Lệ Rơi

Một vài dòng giới thiệu về team, về ranh giới (boundary) của team (nếu dự án là một phần của một dự án lớn). 

Nên có một link hướng dẫn nếu người đọc không tìm thấy thông tin thì nên hỏi ai trong team.

### Danh sách thành viên team

* [Lệ Rơi](url to github or slack profile) (Tech Lead)
* [William Hung](url to github or slack profile (Product Manager)
* [Mỹ Linh](url)
* [Phương Thảo](url)

Danh sách alumni (những người từng làm việc cùng team) - nên công nhận đóng góp nhiều hay ít của các cựu thành viên

* [Trần Tiến](url)
* [Phú Quang](url)
* [Trịnh Công Sơn](url)

### Architecture

Đây là phần bạn nên kèm vào một hình diagram các apps/services mà team bạn quản lý. Nó cung cấp cái nhìn toàn cục về ranh giới của team bạn trong hệ thống lớn ở công ty. Dĩ nhiên là bạn đừng nên ghi quá chi tiết ở đây, hãy dành diagram chi tiết trong phần `README.md` của từng project nhỏ.

### Program

Đây là phần bạn ghi rõ cách thức team bạn làm việc với nhau, các tool link có thể được cho vào đây như là JIRA, Trello hay Excel. Nên có một diagram hướng dẫn workflow ở đây.

### Projects

* [Project Gotham](url)
* [Project Runway](url)

### How do we work?

Đây là phần tóm tắt workflow và cách thức team làm việc với nhau

* [Onboarding](url) <- link tới doc hướng dẫn thông tin dành cho người mới tham gia nhóm (quan trọng)
* [On call](url) <- trách nhiệm, kì vọng, cách viết report cho nhiệm vụ trực ca (nếu cty có phải làm)
* [Expectation](url) <- một doc chung chung về kì vọng tối thiểu của team về chất lượng công việc, vd bạn có thể nói GitHub PR phải như thế nào mới gọi là PR tốt, phương thức test, coverage ratio, vv

### Services

Liệt kê link các dịch vụ team sử dụng

* [NewRelic](url)
* [Rollbar](url)

Nếu team bạn có thể tạo một dashboard để aggregate toàn bộ các chỉ số đáng quan tâm thì bạn có thể đưa link lên mục này.

### Misc (linh tinh)

Mục này mình đưa vào các link về tooling giúp hỗ trợ team

Vd mình có export toàn bộ cái Google Bookmark các link liên quan đến team ra và chia sẻ thành link đến file đó ở đây.

Hoặc đưa link chia sẻ config file của vim, boxen, vv

Xem trang chính này như là bộ mặt chính của team, là cánh cửa của team ra thế giới bên ngoài. Mong các bạn tuỳ biến để phù hợp hơn.

Tự động hoá và đồng bộ hoá

Thời gian cài đặt có lẽ chiếm khá nhiều thời gian, nhất là khi một thành viên mới tham gia tạm thời, thường mình thấy các công ty bao giờ cũng mất ít nhất 1 ngày trắng để làm việc này, thật là lãng phí.

Hãy làm mọi cách có thể để đồng bộ hoá và tự động hoá công đoạn này, các tool bên mình áp dụng là boxen, dockervagrant.

Với thành viên cố định thì nên áp dụng boxen cho toàn team để cấu hình của mọi máy đồng bộ, giúp cho việc troubleshooting sau này dễ dàng hơn.

Với các thành viên khác nhóm có nhu cầu sử dụng các dịch vụ bên team bạn thì docker là đấng cứu rỗi, thứ nhất là nó nhanh và gọn hơn các giải pháp khác. Bạn có thể cho thêm vào file Dockerfile trong từ repo project để người dùng tự build hoặc tạo một repo chung trên Docker Hub.

Còn lại là vagrant, giải pháp này phù hợp cho các thành viên tạm thời khi tham gia một dự án nào đó trong team, họ dĩ nhiên cần một giải pháp nhanh hơn boxen và có khả năng thay đổi nhiều hơn là docker.

Thêm vào nữa, để tiết kiệm thời gian cài đặt một dự án nào, thay vì chạy một đống lệnh để bootstrap thì bạn nên tạo một file bootstrap ./scripts/setup.sh chẳng hạn.

Cuối cùng là tự động hoá các công đoạn deploy và test để có thể đạt đc Continuous Delivery (nếu đc). Các cộng cụ như Buildkite, CircleCI, CodeDeploy, Samson, vv. đều rất lợi hại, đa số đều có cơ chế hook để gửi về thông tin, team mình tích hợp nói với Slack để giúp cho người on-call có đc cái báo cáo rõ ràng về các sự kiện deploy trong ngày.

Tóm lại hãy đặt mình vào người không biết gì, hãy giúp họ nhanh chóng cấu hình xong máy để bắt đầu làm việc với team.

Hạn chế gây ngắt quãng trong thời gian biểu

Cái mà các lập trình viên ghét nhất có lẽ là họp. Và nhất là các buổi họp chen ngang các time slot liên tục, gây gián đoạn cho việc tập trung. Thế nên hãy hạn chế các cuộc họp ở mức chấp nhận đc, cho phép mọi người có quyền không tham gia họp và mỗi cuộc hẹn phải ghi rõ thời gian và agenda. Nếu các bạn sử dụng Google Calendar thì các bạn có thể thấy đc lịch biểu của các thành viên, hãy chọn slot thời gian để tất cả lập trình viên đều có ít nhất 2 tiếng làm việc liên tục, đừng có chen ngang kiểu 30' họ lập trình, 30' họp rồi 30' lập trình rồi lại họp tiếp.

Nếu điều gì không quan trọng thì nên giao tiếp ở dạng không trực tiếp như email hoặc qua chat room như Slack hoặc HipChat.

Loại bỏ các thành viên yếu kém

Đây là chủ đề khá tế nhị nhưng mình nghĩ nên chia sẻ luôn. Theo mình nhận thấy thì một khi xác định được một thành viên yếu kém và họ không thể theo kịp được nhịp độ của team thì cách tốt nhất là loại họ ra khỏi team. Nghe rất là tàn nhẫn và phũ phàng nhưng các team lead phải làm, nếu không làm được lâu dài nó sẽ tạo ra gánh nặng và làm tổn hại đến tâm lý chung của team. Mình nghĩ đã đi làm thì phải xác định rõ tâm lý, phải chuyên nghiệp, gạt bỏ các cá nhân để có thể đưa ra các quyết định khó khăn để team có thể đạt được vận tốc cao nhất. Mình nghĩ sẽ nhiều người bất đồng với mình về vấn đề này nên mình muốn nghe các ý kiến phản hồi về khoản này.

Tất cả là "vì mọi người" chứ không phải "vì tôi"

Môi trong những sai lầm mà các team lead thường gặp phải là chịu sự chi phối từ cấp trên dẫn đến việc dẫn dắt team theo suy nghĩ là tôi muốn thế này tôi muốn thế kia. Điều đó khá tai hại, thường là team sẽ nghe theo lead nhưng trong bụng có thể họ không vừa lòng. Nếu team mà làm việc mà cứ ấm ức trong bụng thì không tốt cho lâu dài. Cái team lead cần hiểu là chữ "mọi người muốn", hãy lắng nghe ý kiến của từng người, lập ra những session để mọi người có thể cùng thảo luận để đưa đến sự đồng thuận về cách thức làm việc. Hãy khéo léo dẫn dắt để team có thể đạt tốc độ cao nhất trên lộ trình được đặt ra (vâng, bạn nên đặt ra lội trình đi hơn là hướng dẫn cách vặn vô lăng).

Cuối cùng team lead nên đặt mình ngang hàng với mọi người, tránh việc đặt mình lên cửa trên theo cung cách làm việc của Châu Á. Nếu team lead không kết nối được với mọi người thì sớm hay muộn team đó sẽ lao xuống dốc thảm hại.

Nói không với mấy cái Agile/Lean bullshit

Vâng, tôi quan tâm nhiều về các phương pháp "hipster" như Agile, Lean và các process management blah blah khác. Nhưng tất cả chúng vẫn chỉ là cứt trâu mà thôi. Nghe thì rất hay ho nhưng thực sự không phải lúc nào cũng áp dụng đc hay nên áp dụng. Cái đích tối thượng là một team có khẳ năng chuyển giao valume (volume + value) hay (chất và lượng) cao nhất cho doanh nghiệp. Tôi đã từng kinh qua rất nhiều thay đổi trong practice khi áp dụng agile, từ scrum đến kanban, và nhiều thứ khác. Câu hỏi bạn nên hỏi các thành viên của bạn là họ có thấy đc giá trị khi làm những cái đó không, có nên tạo ra các biểu đồ graph tóm tắt nếu chỉ để loè cấp trên hoặc người ngoài? Hãy dành thời gian để thiết kế một mô hình sát với team nhất.

Chia sẻ và chia sẻ

Không ai có thể biết hết mọi thứ đc, có người sẽ có thiên hướng mạnh hơn người khác về khoản này hay khoản kia và điều đó hết sức là bình thường. Nếu team phải tối ưu hoá thì hãy ráng tối ưu hoá cho việc chia sẻ kiến thức và domain với nhau thay vì tôi ưu cho việc ai nấy lo. Điều này giúp giảm đi hiện tượng tắc cổ chai nếu một thành viên trong team nghỉ hoặc chuyển đi team khác. Các phương pháp chia sẻ hữu dụng như là pairing khi làm một feature mới hay review PR, mỗi tuần 30' họp chia sẻ tech talk, ghi lại toàn bộ các thông tin vào tài liệu nào đó, sử dụng Slack để tạo một room riêng cho việc thảo luận hoặc chia sẻ thông tin.

Kết luận

Không có team nào giống team nào, có thể tất cả điều ở trên sẽ không phù hợp với điều kiện văn hoá và môi trường ở cty bạn, cái điểm mấu chốt là cái cách tư duy về công cuộc cải tiến team, rất cần được sự quan tâm đúng mực của cấp quản lý. Xem con người là nguồn tài nguyên quí giá, nâng niu và chăm bẵm họ thì cty sẽ có 'quả' ngon.

Bình luận


White
{{ comment.user.name }}
Bỏ hay Hay
{{comment.like_count}}
Male avatar
{{ comment_error }}
Hủy
   

Hiển thị thử

Chỉnh sửa

White

Lơi Rệ

43 bài viết.
225 người follow
Kipalog
{{userFollowed ? 'Following' : 'Follow'}}
Cùng một tác giả
White
40 7
Trời se se lạnh, Melbourne chuyển mùa, ngồi trong quán cafe bắt đầu một ngày làm việc mới với suy nghĩ tại sao các bạn Việt Nam không muốn tham gia...
Lơi Rệ viết hơn 3 năm trước
40 7
White
39 15
Thế nào là làm việc từ xa? Internet, một trong những phát minh vĩ đại nhất của con người thế kỷ 20. Công nghệ này xoả bỏ rào cản vật lý giữa các n...
Lơi Rệ viết hơn 2 năm trước
39 15
White
28 5
(Ảnh) Sau hơn 8 năm sử dụng Rails (và vẫn cho đến những ngày hôm nay), Rails làm một cuộc cách mạng lớn trong xây dựng phần mềm nền tảng Web với n...
Lơi Rệ viết hơn 3 năm trước
28 5
Bài viết liên quan
White
0 0
Some Principles of HumanCentered Computing | | | ||| | The Aretha Franklin Principle | Do not devalue the human to justify the machine. Do not c...
huydx viết 2 năm trước
0 0
White
3 0
Mentoring is important Vừa đọc được một bài viết thú vị của Ryan Bigg trên medium: (Link) Đại ý của bài viết là : Thay vì tìm kiếm senior develo...
huydx viết hơn 2 năm trước
3 0
White
15 1
Con đường phát triển sự nghiệp (Career path) cho developer Các bạn sinh viên còn đang học hoặc mới ra trường sẽ khó hình dung được về những vị trí...
Huy Hoàng Phạm viết gần 3 năm trước
15 1
{{like_count}}

kipalog

{{ comment_count }}

bình luận

{{liked ? "Đã kipalog" : "Kipalog"}}


White
{{userFollowed ? 'Following' : 'Follow'}}
43 bài viết.
225 người follow

 Đầu mục bài viết

Vẫn còn nữa! x

Kipalog vẫn còn rất nhiều bài viết hay và chủ đề thú vị chờ bạn khám phá!