Hiện tại, mình đang là leader của một team sản phẩm (Product) gồm 17 thành viên. Trách nhiệm của mình là đảm bảo các sản phẩm ra tiền và đồng thời tổ chức team hoạt động một cách trơn tru.
Thời gian lead team của mình khoảng 2 năm, trong đó có 1 năm là lead team chuyên môn và 1 năm lead team Product nhiều vai trò như bây giờ. So với một leader thì tuổi mình rất trẻ, vậy nên mình chưa bao giờ đánh giá cao khả năng lead của mình.
Tuy nhiên gần đây mình có ngồi trò chuyện và consult cho đồng nghiệp về việc vận hành team và nhận ra: cách mình lead team cũng pro phết, hẹ hẹ. Và tình cờ gần đây anh CEO bảo không thấy mình viết nữa, rồi khen chia sẻ ok các thứ, hề hề. Vậy nên mình quyết định chia sẻ những triết lý về lead team mình đã áp dụng trong công việc.
Mong nhận được chia sẻ và đóng góp thêm từ bạn.
1. Triết lý chứ không phải phương pháp
Điều này áp dụng cho chính bài viết này luôn, mình dùng từ “triết lý quản lý” chứ không phải là “phương pháp quản lý” như mọi người hay dùng.
Với mình, phương pháp nó chỉ là cách triển khai của triết lý. Vậy nên khi nắm rõ triết lý rồi thì bạn chỉ cần tìm một phương pháp triển khai cho hợp lý, nó có thể là những phương pháp có sẵn hoặc bạn tự tạo ra.
Nó như là làm đúng việc hơn là làm việc đúng. Còn tuyệt vời nhất thì là làm đúng việc và làm đúng cách.
Lấy ví dụ về quy trình của team, mình xây dựng từ Scrum theo triết lý về Agile.
Khi nhắc đến Agile, mọi người thường nghĩ tới sprint, các buổi sprint planning, sprint review, daily standup,… Và khi mình mới áp dụng Agile thì cũng vậy, mình áp dụng các practice của Scrum cho team bao gồm:
- 1 sprint diễn ra trong 2 tuần.
- Có 1 buổi sprint planning, 1 buổi sprint review.
- Nhiều buổi daily standup vào 9h sáng đầu ngày.
Và nó không hiệu quả với team mình, vì:
- Fail sprint liên tục, nhiều DoD không đạt vì task gấp, và đạt DoD rồi thì Dev ngồi chơi.
- Họp hành liên tục vì nhiều product, mọi người dần mất ý thức về việc đâu là buổi sprint planning, đâu là buổi sprint meeting.
- Người note daily standup sáng mệt mỏi vì phải chuẩn bị và đi nói chuyện, Dev thì đến sớm không muốn code vì kiểu gì đang code cũng bị ngắt quãng để report.
Và sau khi tối ưu các thứ, đây là phiên bản quy trình của team mình:
- 1 sprint diễn ra trong 1 tuần => Việc kiểm soát tiến độ tốt hơn.
- Gộp sprint planning và review thành 1 buổi sprint meeting => Đỡ phải đau đầu xem nghĩ họp thì trình bày gì.
- Daily standup chuyển về 17h30 cuối ngày (2 ngày / tuần), có BOT thông báo report tự động => Để Dev có thể làm công việc yêu thích nhất vào đầu ngày – code, và bớt việc thông báo cho người take note.
Việc thay đổi này dựa theo 2 triết lý:
- 3 trong 4 tuyên ngôn của Agile, trừ phần customer collaboration (vì không có), đại khái là làm sao teamwork tốt, thích ứng với thay đổi một cách nhanh chóng.
- Mục tiêu của quy trình là khiến việc vận hành trơn tru, bớt đau đầu chứ không phải đẻ thêm việc để rồi đau đầu hơn.
Mặc dù so với quy trình của Scrum gốc khác biệt rất nhiều, và phiên bản của mình nghe còn hơi ngu nhưng nó là phiên bản sau khi đã được cải tiến nhiều lần và đang hoạt động trơn tru ở team mình.
So it works!
Quy trình như thế có thể cải thiện nữa không? => Có.
Mình có quyết định cải thiện nữa không? => Tạm thời không.
Tại sao? => Mình trình bày ở phần 3. Alignment
Việc quan tâm tới “triết lý” hơn là “phương pháp” cũng giúp việc học của mình trở nên dễ dàng hơn. Nó giúp mình hiểu sâu hơn những phương pháp quản lý mình học và nhớ một cách đơn giản hơn.
2. Văn hoá trước, năng lực sau, và sự trao đổi giá trị
Khi đảm nhận vị trí leader, mình mới thấy những mô tả về “giá trị cốt lõi” của các công ty – điều mà trước đây mình cho rằng là màu mè, không cần thiết lại là điều cực kỳ quan trọng trong việc xây dựng tổ chức.
Vì đó là những đặc trưng về con người trong tổ chức và để trả lời câu hỏi “những người như nào thì phù hợp với tổ chức?”. Kể cả không ghi rõ ràng ra, thì mỗi tổ chức hầu như mọi người đều có thể cảm nhận được đặc trưng về con người của tổ chức đó.
Hồi mới tham gia vào việc tuyển dụng, mình cứ thấy ai giỏi là đề xuất tuyển.
Giờ thì khác, để tuyển một người vào team, thì mình sẽ cân nhắc 2 câu hỏi chính:
- Con người có phù hợp với văn hoá team không?
- Bạn có thể mang lại giá trị cho team không?
- Team có thể mang lại giá trị đặc biệt cho bạn không? <= Quan trọng
Về định nghĩa về văn hoá thì có rất nhiều, mình thì thích định nghĩa về văn hoá theo Lăng kính số 3 trong quyền Quản Trị Bằng Văn Hoá của thầy Giản Tư Trung:
“Văn hoá của một chủ thể là cách sống và cách làm người của chủ thể đó”
Vậy nên nếu ứng viên có “cách sống và cách làm người” phù hợp với “cách sống với cách làm người” của team thì đáp ứng tiêu chí 1 – là tiêu chí về văn hoá.
Về tiêu chí 2, liên quan đến năng lực thì quá rõ ràng rồi.
Về tiêu chí 3, đây là tiêu chí mà mình thấy các bài viết về tuyển dụng ít nói tới nhưng đó lại là tiêu chí key nhất của mình khi chọn 1 người vào team, đó là việc team có tạo ra giá trị đặc biệt cho bạn không?
Tại sao phải là đặc biệt? Vì khi đi làm thì ai cũng nhận được lương rồi, thì đó là giá trị cơ bản. Giá trị đặc biệt là những thứ ngoài yếu tố thu nhập. Đó nên là những yếu tố mà chỉ team của bạn hoặc số ít các nơi có thể đáp ứng cho ứng viên.
Điều này quan trọng vì nó quyết định ứng viên có gắn bó lâu dài được với tổ chức hay không.
Sai lầm của những người lead mới là tuyển những người giỏi quá, họ phát triển quá nhanh dẫn đến công ty không còn cho họ cơ hội học hỏi nữa, và họ rời đi (tuỳ trường hợp, nhưng mà mình thấy nhiều phết).
3. Alignment
Từ này mình không biết nên dùng từ tiếng việt gì nên giữ từ gốc.
Đã bao giờ bạn dùng 1 app, thấy một số lỗi mà mãi không được sửa chưa? Hay có những vấn đề trong team tồn tại mà các sếp cũng chả thèm ngó tới, tại sao?
Vì đa số trường hợp, đó không phải là điều được ưu tiên.
Ví dụ, với team mình, việc ưu tiên nhất là khiến sản phẩm ra tiền chứ không phải tối ưu quy trình. Do đó, nguồn lực mình dành cho tối ưu quy trình cũng ít thôi, có những vấn đề tồn tại nhưng mình cũng kệ, hẹ hẹ. Nhưng vấn đề là làm sao để các thành viên hiểu rằng kệ là một điều nên làm.
Có những quyết định từ cấp trên khiến bên dưới cực kỳ gây tranh cãi, thậm chí còn phẫn nộ, gây ra những ảnh hưởng tiêu cực. Việc này xảy ra cực nhiều, tổ chức càng to, càng dễ xảy ra.
Với mình, mọi quyết định đều có cơ sở, và ở vị trí càng cao, họ càng phải chịu nhiều trách nhiệm cho quyết định của mình. Vậy nên sự mâu thuẫn, tiêu cực xảy ra chỉ đơn giản là bên dưới không hiểu được những vấn đề của bên trên, hay đơn giản là hai bên không hiểu nhau, không có sự alignment.
Alignment hiểu là khi mọi người trong một tổ chức đều đi trên một con đường, hướng tới chung một mục tiêu.
Có một câu chuyện trong một lần mình đi sự kiện về UX Design cũng về chủ đề này:
- UX Design A hỏi: “BA (outsource) không đồng ý design của mình, làm sao để thuyết phục BA chọn design của mình?”
- Anh Chung trả lời: “Tốt nhất là nghe theo BA đi em ạ, vì BA là người giao tiếp với khách hàng và chịu trách nhiệm deliver đúng những gì khách hàng yêu cầu. Vậy nên BA đang là người đại diện khách hàng, việc họ từ chối design của em tức là design của em không hợp lý với khách hàng.”
(Chi tiết câu hỏi và trả lời đã được điều chỉnh vì mình không nhớ chính xác, nhưng đại khái vậy)
Trong một tổ chức, thì người bên dưới như là bạn UX Design kia, chưa hiểu những ràng buộc và mục tiêu của bên trên – BA nên hay có những suy nghĩ tương tự vậy.
Do đó, khi build team, mình luôn đảm bảo có sự alignment giữa tất cả các thành viên với nhau. Đảm bảo rằng:
- Mọi người đều biết mục tiêu quan trọng nhất của team: Sản phẩm ra tiền.
- Dev hiểu mục tiêu của Product là làm sản phẩm phục vụ user, chứ không phải làm khó Dev.
- Product hiểu rằng viết requirement ngu là thời gian Dev, Test tăng gấp 2 lần.
- Test hiểu rằng có những lỗi nhỏ, ảnh hưởng ít thời user thì có thể bỏ qua.
- …
Mình có lợi thế khi triển khai sự alignment cho team vì mình xuất thân từ Dev, đã từng Test, đã từng trực tiếp call và support user nên mình hiểu hầu hết pain point của các vị trí.
Và khi hiểu mọi người rồi thì việc làm sao để mọi người hiểu mình không khó.
Những điều mình đã làm để khiến cả team align với nhau:
- Trình bày performance về business của team trong các buổi sprint meeting để team biết tình hình hoạt động của product như nào, chia sẻ kiến thức về business với cả team.
- Dí Product đọc dev docs, viết test case.
- …
Có một điều hay khi align như vậy là nhiều khi Dev hay Test đề xuất được những thay đổi cực kỳ giá trị cho user mà Product nhiều khi không để ý.
Khi mọi người đã align với nhau thì các mâu thuẫn nhỏ gần như là không có. Nếu có thì một là giải quyết rất nhanh, align lại với nhau là xong, hai là không giải quyết được (nghỉ việc).
4. Tập trung vào vấn đề, không phải con người
Phần 2…
5. Sếp là nhất
Phần 2…
0 Comments