Tôi cho rằng mỗi người đều có một cách thức thực thi riêng của bản thân.
Trong bài này tôi sẽ mô tả một số nguyên tắc của mình khi thực thi. Tôi lựa chọn các điểm được thực hiện nhiều và khá nhất quán. Chúng gồm cả việc cá nhân nhà quản lý và vai trò thực hiện công việc thông qua người khác, đôi khi sẽ khó tách biệt. Bản thân nhà quản lý cần hoàn thành tốt việc cá nhân của mình mới có thể giúp công việc chung ra được kết quả.
Các nguyên tắc thực thi của cá nhân tất nhiên không được vi phạm các giá trị mà bản thân và tổ chức hướng tới. Bạn hoàn thành công việc nhưng lại phải day dứt về cách làm thì cũng không phải là điều tốt.
Dưới đây là các nguyên tắc thực thi của tôi. Bạn hãy hết sức cảnh giác khi đọc nhé.
Vào việc là phải chi tiết
Bạn cần đến “chiến lược”, phương hướng để có được hình dung toàn cảnh. Tuy vậy khi vào việc bắt buộc phải rất chi tiết.
Chi tiết tức là bạn cần có kế hoạch cụ thể cho công việc. Các đầu việc lớn được chia thành việc nhỏ hơn, và tiếp tục phân chia nhỏ hơn nữa. Tiếp tục công việc đó cho đến khi bạn không thể nhìn chi tiết hơn. Với từng đầu việc, hãy xác định đầy đủ các thông tin cần thiết để có thể hoàn thành. Hãy suy nghĩ về các rủi ro có thể gặp phải khiến công việc gặp khó khăn, và tìm cách để vượt qua chúng.
Trông có vẻ giống với bộ môn quản trị dự án, nếu chúng ta coi mỗi nhiệm vụ như một dự án. Ở đây tôi muốn nhấn mạnh đến yếu tố “chi tiết”. Tôi từng thấy không ít bạn Project Manager (PM) làm việc khá đại khái, kế hoạch chỉ ở dạng các đầu việc to, và khả năng hoàn thành cũng khá hạn chế.
Một vài ví dụ có thể giúp bạn dễ hình dung hơn
- PM báo cáo: Mốc bàn giao sắp tới team đánh giá là khả thi anh ạ (và không kèm theo thông tin nào chứng minh). Hãy hỏi lại: Em tính toán như thế nào để biết là khả thi? Liệu còn điểm rủi ro nào mình chưa lường tới? Thường nếu không làm rõ khối lượng công việc còn lại, cách thức bố trí công việc, tiến độ/chất lượng công việc của giai đoạn trước đó, sự tham gia của khách hàng … thì khả năng hoàn thành khó chắc chắn.
- Em đã thử rất nhiều phương án rồi, cái này không làm được anh ạ. Hãy hỏi lại: Em đã thử những cách nào và kết quả cụ thể là gì? Hồi còn làm kỹ thuật, tôi rất hay hỏi câu này, và thường là đều tồn tại một cách nào đó khác giải quyết được vấn đề mà người gặp không nghĩ tới.
- Khách hàng phàn nàn khối lượng công việc do team phát triển báo giá quá cao. Hóa ra là team ước lượng công việc theo kiểu rất “vo viên”, và PM cho rằng nên tin tưởng vào member mà không yêu cầu làm kỹ. Tôi hỏi lại các con số to và đề nghị bẻ nhỏ, sau một hồi giảm được 1/2 khối lượng công việc. Con số vẫn là bạn member đó đưa ra, và về sau tôi nhớ là khá khớp.
- Tôi thấy một bạn lập trình viên đang vò đầu bứt tai, hóa ra làm mãi không xử lý được dứt điểm yêu cầu. Tôi hỏi “Yêu cầu này cần được xử lý thế nào?” và viết lại vào giấy, bảo bạn thực hiện lần lượt rồi đánh dấu. Một lúc sau quay lại công việc đã được xử lý xong.
- GrowMind tổ chức rất nhiều workshop. Thường chúng tôi cần chuẩn bị rất cụ thể cho các đầu việc và tình huống trong workshop. Ai, làm gì, bằng cách nào, ở đâu,… cần được mô tả kỹ. Với các buổi quan trọng còn có “tập huấn”. Lần nào chuẩn bị kỹ càng đều khá yên tâm, còn chủ quan thì y rằng rất dễ dính chưởng.
Chỉ có quen với việc làm chi tiết, bạn dần mới để ý đến các “chi tiết nhỏ”. Chắc hẳn bạn đã từng loay hoay dùng răng để mở gói dầu gội đầu khi đi nghỉ? Tôi từng được một bác người Nhật dạy một bài học. Người Việt các cậu chỉ làm được tới 70%, trong khi người Nhật cần 100%. Chúng tôi sẵn sàng trả giá cao nếu các bạn làm được như vậy.
Làm chi tiết thường mất thời gian ban đầu. Tuy vậy, đó là thời gian cần thiết. Hậu quả của sự hỏng việc có thể sẽ lớn hơn rất nhiều so với thời gian bạn bỏ ra.
Để tránh bị sa đà vào các điểm nhỏ ngay từ đầu, bạn nên tiếp cận từ lớn tới nhỏ: đi từ các điểm lớn, chia nhỏ một lượt thành các điểm nhỏ hơn, rồi tiếp tục thực hiện. Cách này giúp bạn không bị mất đi bức tranh toàn cảnh.
Không phải lúc nào bạn cũng nhìn được hết các điểm cần lưu ý. Phương pháp và kinh nghiệm sẽ giúp bạn cải thiện. Những việc mới chưa rõ cách làm, bạn cần có cách tiếp cận khác (xem thêm nguyên tắc “Cách tiếp cận Agile”)
Bạn cứ chi tiết đủ nhiều, dần sẽ biết đâu là điểm quan trọng để đúc rút thành các nguyên tắc cho bản thân. Bài viết này cũng là một dạng chi tiết, sẽ có một bài khác ở dạng khái quát hơn. Tất nhiên có những người rất giỏi việc khái quát hóa. Có thể họ sẽ đi từ khái quát đến chi tiết.
Qua quá trình tương tác, tôi thấy thường có vẻ mọi người không thích sự chi tiết ^^. Nếu bạn giúp mọi người yêu thích sự chi tiết thì rất tốt. Tuy nhiên thà để mọi người không thích mình mà được việc, hơn là mọi thứ vui vẻ nhưng kết quả không như kỳ vọng.
Bám theo mục đích
Chúng ta giỏi nghĩ ra các ý tưởng cho hành động. Bạn hãy thử nhớ lại lần gần nhất team mình bàn ý tưởng triển khai cho một việc cụ thể xem có đúng vậy không.
Bản thân việc chi tiết hóa công việc cũng sẽ khiến tạo ra nhiều đầu việc.
Tuy vậy, nếu không để ý đến mục đích của công việc, rất có thể sau một hồi loay hoay bạn lại tự hỏi “Chúng ta đang làm việc gì ấy nhỉ?”.
Hãy lưu ý đối chiếu với mục đích ban đầu của công việc. Nếu bạn chưa rõ, hay suy nghĩ thêm hoặc hỏi lại. Túm lại, tất cả các đầu việc này cuối cùng có giúp chúng ta đạt được mục đích đề ra?
Còn gì tệ hơn nếu chúng ta rất nỗ lực cho một số việc mà thực tế lại không đóng góp được gì đáng kể.
Tôi cũng hay bị quên phần này. Nên có cơ chế để thường xuyên nhắc nhở bản thân. Trong công việc, thảo luận với người khác cũng là một cách tốt để có thêm sự lưu ý.
Sát sao khi triển khai
Hồi còn làm COO, tôi thấy đôi khi công việc rất nhàn ^^. Mỗi Manager mỗi thời điểm có một số nhiệm vụ chính cần giải. Lịch họp định kỳ 1-1 với các Manager đôi khi chỉ trao đổi “Việc A,B,C đến đâu rồi?”.
Chúng ta luôn có rất nhiều việc đang trong guồng quay. Các việc mới, hoặc các việc quan trọng nhưng không khẩn cấp thường ít được ưu tiên. Nếu không có việc theo dõi sát sao, công việc rất dễ bị trôi đi. Và mọi thứ lại tiếp tục như vòng quay hiện có.
Sát sao không chỉ là bạn cần nhớ việc. Toyota có món võ “Genchi Genbutsu”, dịch là “Real location, Real thing”. Tôi gọi là “Trải nghiệm trực tiếp”. Bạn cần có mặt ở nơi diễn ra công việc và trực tiếp quan sát nó. Tránh chỉ nhận báo cáo, vì nó không thể phản ánh đầy đủ các khía cạnh. Không báo cáo nào thể hiện được rõ nét sự hối hả khẩn trương, hoặc tinh thần hỗ trợ hết lòng vì mục tiêu của nhóm. Ngoài ra báo cáo là sản phẩm qua lăng kính của người tạo ra nó, tiềm ẩn sai sót hoặc thiếu thông tin bạn cần.
Lần đầu tôi tham gia kiểm tra dự án, rất sốc khi thấy một đoạn code siêu dài. Tôi đùa với bạn leader chuyên môn, rằng file này nên lưu lại để biết rằng công ty từng làm ra một đoạn code như vậy.
Các dự án phần mềm khi hỏi thường bảo có làm cải tiến. Tôi đề nghị mở file lưu thông tin cải tiến, là có thể đánh giá được chất lượng cải tiến tới đâu. (Và thường đến bước này sẽ phát hiện dự án lâu rồi chưa thực hiện hoạt động cải tiến). Tương tự là các hoạt động phân tích chất lượng, hay cách thức quản lý dự án. Nếu bạn đang quản lý công ty ITO và chưa thử audit dự án, hãy lưu ý nhé. Có thể bạn cũng sẽ rất sốc với kết quả ở lần đầu thực hiện.
Tôi cũng từng dành hai ngày cuối tuần để tham gia chương trình đào tạo cho lập trình viên khi nhờ một đối tác bên ngoài. Bên triển khai bảo, lần đầu em mới thấy có lãnh đạo cấp cao của khách hàng ngồi quan sát cả chương trình như thế ^^. Chỉ ngồi trong buổi học đó tôi mới có thể đánh giá được mức độ phù hợp của chương trình so với nhu cầu. Bản báo cáo không đủ để làm được việc đó. Với các chương trình của đối tác bên ngoài, tôi hoặc là Training manager của công ty đều có mặt như vậy.
Tôi có cậu bạn thân từng làm Manager của McDonald và Starbucks. Lúc mới vào, hắn phải tham gia huấn luyện 6 tháng tại tất cả các vị trí ở cửa hàng. Khi làm dịch vụ Delivery, hắn phải trực tiếp làm công việc của nhân viên giao hàng. Ngày trước tôi từng nghĩ Tây chỉ cần xong việc mà không quan tâm cách làm, hóa ra cũng không đơn giản như vậy.
Cách tiếp cận Agile
Với những việc đủ phức tạp và chưa rõ cách làm, mà thường quản lý rất hay phải đối mặt, bạn khó có thể hình dung mọi thứ ngay từ đầu. Agile có thể là giải pháp phù hợp với bạn.
Nôm na là:
- Start small
- Tiếp nhận phản hồi từ thực tế
- Learn fast
Thường mọi người thích tiếp cận với bài toán lớn. Chẳng hạn, triển khai quy trình cần làm bài bản theo các tiêu chuẩn như ISO/CMMi. Năng lực của đội ngũ cần được tiêu chuẩn hóa, và dựa vào đó để tiến hành xây dựng các chương trình đào tạo.
Cách tiếp cận đó đòi hỏi rất nhiều nỗ lực. Đầu ra thường là một hệ thống chuẩn chỉnh. Tuy vậy không có gì đảm bảo rằng bạn có thể triển khai được trên diện rộng. Đôi khi chi phí xây dựng hệ thống tài liệu và vận hành lớn hơn rất nhiều so với kết quả mang lại.
Ngày trước tôi tiếp cận bài toán xây dựng hệ thống quy trình cho công ty theo hướng: lựa chọn ~20-30% practices phổ biến nhất của CMMi level 3, mô tả lại cách thức công ty đang làm, chuẩn hóa lại trên diện rộng, cải tiến dần trong quá trình triển khai. Bắt đầu từ cỡ 9/2017. Mất khoảng 6 tháng (đến 3/2018) để có được bản quy trình hoàn chỉnh đầu tiên và thí điểm, sau đó bắt đầu lan rộng. Cuối 2018 có 80% các dự án chạy tại thời điểm đó tuân thủ phần lớn các hạng mục. Lưu ý thêm, năm 2018 công ty tăng trưởng gần gấp đôi về nhân sự nên việc triển khai cũng không phải đơn giản.
Tôi từng rất hãnh diện về tốc độ triển khai đó. Nó cũng bám khá sát theo luồng ở phía trên.
Tuy vậy, đến khi tôi hỗ trợ một công ty triển khai engineering process trong phạm vi khoảng 2 tháng, tôi mới thực sự hiểu hơn về ý tưởng “start small”. Và bây giờ tôi cho rằng quy trình nên được triển khai trong phạm vi 2 tuần.
Đưa thật sớm vào thực tiễn, quan sát đúc rút bài học và điều chỉnh. Hãy hết sức lưu ý với nửa sau, đó là điểm mấu chốt để nhiệm vụ được hoàn thành. Phản hồi từ thực tiễn thường sẽ không như bạn kỳ vọng, hãy biết cách đón nhận nó. Bài học và cải tiến thường dễ bị bỏ qua, và bạn sẽ khó tiến tới đích nếu không thực hiện điều đó.
Tài liệu về agile khá nhiều, bạn có thể dễ dàng tìm kiếm trên internet hoặc tham khảo thêm tại Học viện Agile (https://hocvienagile.com/blog/)
Dành đủ nhiều thời gian cho nhân sự
Phát triển năng lực đội ngũ phải là trách nhiệm của bạn trong vai trò quản lý. Bạn không thể ủy quyền điều này. Tất nhiên, bạn có thể cần đến sự hỗ trợ từ bên ngoài, miễn là bạn nhận thức được trách nhiệm của mình.
Khi đọc quyển “Thực thi”, tác giả có nhắc đến việc dành đủ nhiều thời gian cho công tác nhân sự, nhất là trong thời điểm mới. Có con số để tham khảo: 20% thời lượng khi mọi thứ vận hành tốt, và khi xây lại doanh nghiệp là 40%. Trước tôi từng phân bổ áng chừng phải 50% effort cho nhân sự, gồm cả việc triển khai các hoạt động học tập diện rộng.
Chỉ cần bạn cam kết dành đủ thời gian cho nhân sự, bạn sẽ nghĩ ra đủ hoạt động hữu ích có thể làm.
Xây dựng nền tảng thực thi cho đội ngũ
Ngoài việc hoàn thành công việc cá nhân, bạn cần xây dựng được cơ chế để năng lực thực thi tốt được lan rộng trong phạm vi bạn quản lý. Công việc là kết quả chung của nhiều người, không chỉ đến từ mình bạn.
Phần này nhìn chung phức tạp, nhiều điểm tôi cũng chưa làm tốt.
Nó bao gồm:
- Quy trình vận hành
- Văn hóa làm việc hướng tới kết quả và sự hiệu quả
- Hệ thống khuyến khích người có năng lực thực thi tốt
Quy trình luôn là một điểm quan trọng trong mọi cấp độ. Team 2-3 người vẫn cần đến nó, dù có thể bạn không nhận ra. Quy trình giúp cho bài học được nhân rộng và tránh lặp lại các vấn đề từng phát sinh. Quy trình nên được viết ra để có căn cứ đối chiếu và cải tiến. Ở chiều ngược lại, bạn cũng cần cảnh giác khi có quá nhiều quy trình. Mọi thứ cồng kềnh khó có được sự uyển chuyển.
Xây dựng văn hóa làm việc cần thời gian và sự chú tâm. Thú thật tôi cũng chưa thạo trong việc này. Tôi cũng có may mắn nhìn thấy case study tốt, nên càng nhận thức được mức độ quan trọng.
Bạn cần có cơ chế để nhận biết được những người có năng lực thực thi tốt, và tưởng thưởng xứng đáng cho họ. Ở đây nhấn mạnh về năng lực thực thi, không phải kết quả. (Nếu bạn chưa đọc bài MTMB #4 của tôi, bạn có thể tham khảo để hiểu rõ hơn về quan điểm này)
Nguyên tắc cuối cùng: thực thi thì phải “Được việc”
Với tôi đây là nguyên tắc quan trọng nhất.
Trách nhiệm thực hiện và hoàn thành nhiệm vụ phải là của bản thân mình. Thành công hay thất bại đều là do mình.
Việc giao cho người khác, không xong cũng là do mình. Ai bắt bạn giao nhiệm vụ đó cho họ?
Hãy tìm mọi cách để xoay sở. Cách này không được, tìm cách khác. Người này không xong, hãy tìm người khác. Đừng dừng lại cho đến khi hoàn thành.
Tất nhiên đừng quên rằng bạn có những giá trị mình theo đuổi. Và tổ chức của bạn cũng vậy.
Tổng kết
Còn nhiều thứ đủ quan trọng mà chưa được đề cập tới. Chẳng hạn như “Không được chủ quan”.
Tôi thấy viết ra thì dễ, chứ thực hành một cách kỷ luật mới khó. Bản thân tôi vẫn hay hỏng việc ^^, nên vẫn phải lưu ý nhắc nhở bản thân.
Ngoài ra không phải lúc nào bạn cũng cần tuân thủ đầy đủ các nguyên tắc. Nó cần thiết khi bạn có việc cần “xong”. Cũng có những việc quá trình trải nghiệm hay hơn nhiều so với kết quả.
Ở trên là cách tôi vẫn làm, hi vọng có thể mang lại vài ý tưởng tham khảo tới bạn. Nếu có điểm nào mới hoặc lâu nay quên để ý, bạn hãy thử nghiệm và quan sát. Ngoài ra nếu thấy ai thường xuyên hoàn thành tốt công việc, khả năng họ có bí kíp hay để bạn học hỏi.