Project Facilitation – Thúc đẩy Team phát triển - Part 2

Ở bài trước, tôi đã đưa bài viết của Amano-san về Project Facilitaion. Amano-san đã truyền tải đến các bạn mục đích “Đạt được cả 2 mục tiêu: Sự thành công của dự án và Nâng cao tố chất engineer (Quality of Engineering Life, QoEL)” cũng như những giá trị và nguyên tắc của nó. Ở bài viết này, tôi xin tiếp tục gửi đến các bạn bài viết của Amano-san về PF.

Chúng ta hãy cùng nhắc lại về những giá trị và nguyên tắc đó.

Lần này, trước hết tôi xin giới thiệu về bối cảnh của PF.

Bối cảnh của PF

Theo dõi đến đây chắc có lẽ cũng có người nhận ra rằng PF có nền móng được xây dựng từ một số phương pháp luận và process. Một trong số đó là phương thức phát triển Agile mà đầu tiên phải kể đến XP(eXtreme Programming) và Scrum. Cách thực hiện theo trình tự định nghĩa “Giá trị (value)” và “nguyên tắc (principal)” rồi thực hiện các activities cụ thể giống hệt với XP (Activities được gọi là practices). Kent Beck đã định nghĩa ra 5 giá trị và 14 nguyên tắc và các giá trị cũng như nguyên tắc của PF cũng chịu ảnh hưởng khá lớn từ những giá trị và nguyên tắc này.

Ngoài ra, nền móng của PF là các phương pháp luận “Toyota Production System:TPS” và “Lean Thinking”, yếu tố skill trong quan hệ con người như “Coaching”, “Facilitation”. Mỗi một yếu tố đều là nội dung tôi rất yêu thích và cảm thấy có ý nghĩa nên các bạn hãy thử tìm hiểu bằng cách như tìm kiếm bằng từ khóa v.v...Về Lean thinking thì tôi xin recommend 1 tài liệu. Ngoài ra, “Coaching” và “Facilitation” là lĩnh vực có tổ chức độc lập và có hệ thống chứng nhận trên thế giới nên tôi nghĩ đây là cơ hội tốt cho các bạn nghiên cứu về những lĩnh vực này.

	Về Lean và phát triển phần mềm thì vợ chồng Mary Poppendieck và Tom Poppendieck đã cho ra đời rất nhiều cuốn sách nổi tiếng nhưng trong đó tôi muốn recommend các bạn đọc cuốn “Implementing Lean Software Development

Từ lần trước, tôi đã giới thiệu đến các bạn 2 activities (Niko-niko Calender và Burndown chart). Lần này tôi xin giới thiệu thêm một số activities. Đây đều là những activities thực tế và như các bạn độc giả đang theo dõi tạp chí này cũng biết, đây chỉ là “điểm xuất phát” nên các bạn hãy tự mình cải thiện để tạo ra những hoạt động có ý nghĩa thực sự với team của các bạn. Figure 1 Henai Map của tác giả

Henai map là tool để các thành viên trong team hiểu biết lẫn nhau. Henai trong tiếng Nhật nghĩa là “Thứ mình vô cùng yêu thích”. Do việc xem tận mắt sẽ nhanh hơn là liệt kê ra những nội dung giải thích nên trước hết các bạn hãy xem Henai Map của tôi trong Figure 1 nhé.

Đây là nội dung tôi đã chuẩn bị khi lần đầu tiên cộng tác với các bạn Việt Nam cách đây khoảng 5 năm. Vào chuyến công tác lần đầu tiên, trước khi giải thích nội dung dự án, tôi đã giới thiệu bản thân bằng cách cho các thành viên dự án xem Henai map này.

Nội dung được ghi trên map này được tôi vẽ ra dưới hình thức Mindmap của Tony Buzan. Tuy nhiên, các bạn có thể vẽ Henai map theo kiểu khác cũng được. Ví dụ, có thể viết theo kiểu gạch đầu dòng đơn giản hay vẽ kiểu grid cũng được. Đầu tiên phải đưa ra được những thứ mà bản thân thích một cách nhiệt tình, chi tiết nhất có thể. Ngay trong Henai Map của mình, tác giả cũng muốn ghi chi tiết hơn về phần Japanese Sake )

Hơn nữa, các thành viên trong team hãy cho nhau xem Henai map của mình, giải thích một cách nhiệt tình để mọi người hiểu về mình hơn. Việc hiểu biết cả những khía cạnh bên ngoài công việc của các thành viên cùng làm một công việc có khá nhiều tác dụng trong việc thực hiện dự án. Nói theo quan điểm về giá trị trong PF thì điều đó có tác dụng trong việc xây dựng “mối quan hệ tin cậy”.

Giữa những người làm việc lần đầu cùng nhau thì ngay cả đối với những thành viên mình nghĩ là mình hiểu rất rõ thì qua việc vẽ Henai map và nói chuyện về nó, các bạn cũng sẽ phát hiện ra những điểm mà mình chưa từng nghĩ tới. Chúng ta có thể áp dụng hoạt động này khi Kick-off dự án hay khi có thành viên mới tham gia vào dự án v.v..

Giới thiệu hoạt động: Standup Meeting

Standup meeting cũng có một vài phương thức thực hiện nhưng cách chính thống nhất là: mỗi sáng khi bắt đầu công việc của một ngày thì tập trung team lại và chia sẻ với toàn bộ các thành viên trong team 3 nội dung “Việc đã làm ngày hôm qua”, “Việc sẽ làm hôm nay”, “Đang cảm thấy vướng mắc ở đâu”. Quan trọng là mọi người cần vừa đứng theo tên, vừa thực hiện meeting và meeting cần thực hiện nhanh chóng, nhiều nhất cũng trong vòng 15 phút (Nếu đứng họp thì sẽ không rơi vào tình trạng meeting kéo dài, chậm chạp.) Trong phương pháp phát triển Agile “Scrum” thì Standup meeting được gọi là “Daily Scrum”. Ngoài ra, ở Nhật gọi hoạt động này là “Morning Meeting”

Điểm chính là “Không thực hiện giải quyết issue bằng hoạt động đó”. Các bạn hãy hiểu rằng mục đích chính của standup meeting không phải là nơi bắt đầu bàn về issue mà là nơi chia sẻ tình hình công việc, điều chỉnh nhịp độ (Rhythm ) của dự án và tạo nên flow làm việc trong ngày. Nếu có thành viên nào đó đang gặp vấn đề khó khăn thì lý tưởng nhất là cần có sự hợp tác với nhau kiểu như “Nếu là vấn đề đó thì tuần trước tôi mới gặp vấn đề tương tự xong nên sau đây tôi sẽ giúp bạn nhé”

Về Standup meeting thì các bạn nên đọc qua một lượt bài báo đăng trên mạng "It's Not Just Standing Up: Patterns for Daily Standup Meetings" (http://martinfowler.com/articles/itsNotJustStandingUp.html) Của tác giả Jason Yip thược công ty ThoughtWorks nổi tiếng thế giới trong lĩnh vực tư vấn các phương thức thực hiện Agile.

Trường hợp là Remote team ở cách xa nơi làm việc (VD: Nhật và Việt Nam) thì thực tế không thể tập hợp được các thành viên trong team nhưng không được bỏ cuộc. Quan trọng là trong team, mọi người đưa ra được ý tưởng làm thế nào để có thể thực hiện được standup meeting hướng đến mục đích ban đầu.

Giới thiệu activities： Retrospectives

Hoạt động có liên hệ trực tiếp với “Kaizen”- một trong những nguyên tắc của PF là hoạt động “Retrospectives” này. “Retrospectives” là chủ đề mà chỉ với tên gọi của nó thôi cũng có thể viết được cả 1 cuốn sách và thực tế đã có rất nhiều sách viết về nó.

“Retrospectives” đúng như tên gọi của nó, là hoạt động được thực hiện nhằm mục đích nhìn lại các hoạt động của chúng ta và làm cho hoạt động của chúng ta trở nên tốt hơn. Nếu cách quá lâu mới thực hiện thì cũng không có ý nghĩa gì nên tôi recommend các bạn thực hiện với khoảng cách 1~2 tuần 1 lần. Tùy theo tổ chức mà cũng có khi thực hiện nhìn lại toàn bộ thời gian thực hiện dự án vào cuối dự án thông qua buổi “Postmorterm” tóm tắt kiến thức, kinh nghiệm để sử dụng trong dự án sau. Bản thân hoạt động này tất nhiên có ý nghĩa của nó. Tuy nhiên, như tôi đã đề cập nhiều lần, trong PF thì coi trọng yếu tố “Hiện tại” nên trọng tâm nằm ở chỗ làm cho “dự án hiện nay” tốt lên hơn là “Dự án tiếp theo”. Vì vậy, trong thời gian thực hiện dự án thì cần thực hiện”Restropective” nhiều lần.

Ở đây, chúng tôi xin giới thiệu “KPT”- framework về tư tưởng cơ bản nhất mà chúng tôi sử dụng khi thực hiện Restropective. Nói như vậy nhưng có lẽ đã có team thực hiện Restropective bằng hình thức KPT này rồi nhỉ. Những bạn thành viên của các team này hãy coi như nội dung sau là phần ôn tập.

Đầu tiên, KPT là chữ viết tắt của các từ lần lượt là Keep/Problem/Try. Keep là “Duy trì những việc đã thực hiện tốt”, Problem là “Những điểm khó khăn, khó thực hiện, cảm thấy chưa tốt”, Try là “Những việc muốn thử trong các hoạt động từ nay về sau”. Tác giả chúng tôi thường điền nội dung vào format nêu trong Figure 2 Figure 2 Format cơ bản của KPT

Điểm mấu chốt ở đây là không chỉ coi Problem là “issue, những điểm chưa tốt”. Nếu chỉ nêu lên những issue rõ rệt, dễ nhận thấy thì sẽ khó thực hiện được ý định ban đầu là lặp đi lặp lại những cải thiện (kaizen) nhỏ. Ngoài ra, không chỉ cần Try để giải quyết các Problem mà còn cần phát huy những nội dung đã nêu ở mục Keep và cả mục Try được nữa thì tốt.

Các bước cơ bản để thực hiện Restropective sử dụng format KPT như sau

1. Nhớ ra các activities
2. Xác nhận những hoạt động đã làm tốt (Keep)
3. Đưa ra các vấn đề (Problem)
4. Xem xét/phân tích nguyên nhân
5. Suy nghĩ cách cải thiển đối với các nội dung trong Keep và Problem (Try)
6. Suy nghĩ những việc muốn thử (Try)
7. Lựa chọn việc muốn thử (Try)

Thực ra tôi muốn giải thích chi tiết từng bước một nhưng do khuôn khổ bài báo có hạn nên ở đây tôi xin lược bỏ phần nội dung chi tiết. Kể cả trong trường hợp các bạn không xử lý những mục ở Keep hay Problem đã xác định ở trên mà nếu có ý tưởng muốn thử nghiệm trong dự án sau thì hãy tự do nêu ý kiến. Ngoài ra, tôi nghĩ rằng không thể thực hiện toàn bộ nội dung Try đã nêu ở các bước thứ 5 và thứ 6 nên hãy chọn một vài nội dung sẽ thử thực hiện trên thực tế ở bước 7. Quan trọng là khi đã lựa chọn nội dung rồi thì phải mô tả cụ thể activities và nhận được sự đồng thuận của cả team

Tôi đã giới thiệu những hoạt động tiêu biểu nhưng số lượng activities có thể nhiều hơn số lượng team. Như tôi đã viết vừa nãy, các bạn hãy tự sáng tạo ra những activities của riêng mình. Nếu có thể thì đặt tên cho hoạt động đó và hãy giới thiệu chúng với tôi nhé.

Tôi nghĩ rằng các bạn cũng đã hiểu một chút về mô hình này rồi, sau đây chỉ chờ các bạn thực hiện thôi! Các bạn hãy thử thực hiện, mỗi khi gặp khó khăn thì thực hiện trao đổi luôn nên các bạn hãy thử làm trên thực tế và phát hiện những điểm chưa tốt, chưa hoàn chỉnh để cải thiện nhé.

Theo tạp chí Geek and Tech - Tác giả Amano-san