Vì sao họ bỏ họp

#

Điểm xuất phát của họ chắc bạn cũng thấy quen. Không ai chuẩn bị gì, họp thì bắt đầu muộn, và ai nói to nhất thì người đó thắng, bất kể đúng hay sai. Một tiếng sau bạn bước ra còn rối hơn lúc bước vào, và bắt đầu lục ngăn kéo xem còn viên paracetamol nào không.

Ban đầu Alan thử sửa lại cách họp: tối đa 15 phút, chương trình họp rõ ràng, họp xong bắt buộc phải có quyết định. Nhưng không duy trì được. Thảo luận cứ lan man, chẳng ai nhớ ai đã nói gì, còn người vắng mặt hay làm việc từ xa thì coi như chịu thiệt. Thế là họ chuyển hẳn sang viết.

Những lợi ích họ nêu ra, tôi thấy đều đúng. Viết buộc bạn phải chậm lại và suy nghĩ thật sự, nên cuộc thảo luận sâu hơn và lập luận chặt chẽ hơn. Mọi thứ được ghi lại rõ ràng, thay vì mỗi người nhớ một ít. Tranh luận không còn là cuộc thi xem ai ăn nói giỏi hơn. Và vì diễn đàn mở cho cả công ty, ai cũng có thể góp ý, chứ không chỉ những người tình cờ có mặt trong phòng họp.

GitHub làm diễn đàn chung của công ty

#

Diễn đàn đó chính là GitHub, một nền tảng vốn sinh ra để rà soát mã (code review), và Alan cứ thế vui vẻ “mượn” nó cho việc khác. Cách thiết lập đơn giản đến mức hơi ngại:

1. Tạo một tài khoản GitHub.
2. Tạo một kho mã (repository) riêng tư không chứa dòng mã nào (kho của họ tên là “Topics”).
3. Thêm một hệ thống nhãn (label) để phân loại các cuộc thảo luận.
4. Dùng tab Issues: issue đang mở là thảo luận đang diễn ra, issue đã đóng là quyết định đã chốt.

Họ đã vượt mốc 17,000 issue. Tức là có ngần ấy cuộc họp không bao giờ phải diễn ra, và, phần tôi thích nhất, họ có cả một lịch sử tra cứu được về lý do vì sao mỗi quyết định lại đi theo hướng đó. Nếu muốn lật lại một quyết định cũ, bạn có thể đọc trước xem lần trước những lập luận nào đã thắng.

Khi nào nên mở issue

#

Không phải quyết định nào cũng đáng mở một issue. Họ lọc bằng bốn câu hỏi: ai sẽ bị ảnh hưởng? có dễ quay lại không? gấp đến mức nào? mình có cần thêm bối cảnh trước khi quyết không?

Đại khái, quyết định nào tác động lớn và khó quay lại thì đưa lên diễn đàn, còn lại cứ để trên Slack. Họ dựa vào cách phân biệt “cửa một chiều” và “cửa hai chiều”. Quyết định một chiều là loại muốn quay lại thì quá tốn kém hoặc quá đau (ví dụ của họ là tăng giá), nên được xử lý đầy đủ bằng văn bản. Quyết định hai chiều thì dễ quay lại, tệ nhất cũng chỉ mất chút công sức, nên không cần thủ tục rườm rà.

LOCI: ai làm gì

#

Mỗi cuộc thảo luận đều phân vai theo mô hình LOCI: Lead, Owner, Consulted, Informed.

Lead chịu trách nhiệm về thành công của quyết định và đảm bảo cả đội hiểu rõ bối cảnh. Ngay từ đầu, Lead nói rõ mình muốn tham gia sâu đến đâu, sau đó tin tưởng giao cho Owner, chịu trách nhiệm về những gì đội làm ra, và chỉ lên tiếng khi thực sự không đồng ý. Mỗi thảo luận chỉ có đúng một Lead.

Owner là người chốt quyết định cuối cùng và kéo dự án đi tới. Owner giữ cho những người tham gia luôn nắm được tình hình và góp ý đúng hạn, tìm hiểu vấn đề, mở và đóng issue, rồi thông báo quyết định. Nếu vướng một bức tường không tự vượt qua được thì Owner tìm đến Lead. Mỗi quyết định chỉ có đúng một Owner.

Consulted là những người mà ý kiến của họ thực sự ảnh hưởng tới việc cân nhắc được mất. Họ phải góp ý kịp thời, dù chỉ để nói “tôi không có gì thêm”, và phải lên tiếng cảnh báo (đẩy lên Lead nếu cần) khi thấy quyết định đang sai nghiêm trọng. Alan giới hạn nhóm này khoảng sáu người, vì càng thêm người góp ý thì càng tốn thêm thời gian.

Informed thì đơn giản là những người được báo tin, thường là sau khi quyết định đã chốt. Đây là giao tiếp một chiều, không ai chờ họ phản hồi. Owner là người quyết định ai bị ảnh hưởng đủ nhiều để cần được thông báo.

Một issue gồm những gì

#

Issue nào cũng dùng chung một mẫu (template). Mẫu này vừa giúp suy nghĩ rõ ràng hơn, vừa ngầm dạy các bạn mới vào nghề cách bóc tách một vấn đề:

• Phạm vi (Scope): lý do có cuộc thảo luận này, kèm một dòng hay bị xem nhẹ là “issue này KHÔNG bàn về…”
• Bối cảnh và tài liệu: đường dẫn tới các thảo luận và tài liệu trước đó
• LOCI: ai là Lead, Owner, Consulted, Informed
• Hạn chót: góp ý trước khi nào, khi nào đóng issue, khi nào cần có giải pháp
• Đề xuất giải pháp: một phương án cụ thể, hoặc vài lựa chọn để cân nhắc
• Câu hỏi: hỏi thẳng từng người cụ thể để xác nhận hoặc bác bỏ từng giả định cụ thể, để issue không thành lá thư bỏ vào chai thả trôi

Quy tắc viết để mọi thứ không bị ì

#

Tranh luận bằng chữ cũng có thể lê thê y như tranh luận bằng miệng, nên họ đặt ra quy tắc. Viết ngắn gọn. Họ trích lời Boileau: “Điều gì đã nghĩ thấu thì sẽ nói ra rõ ràng.” Nếu bạn không viết được nó ra một cách đơn giản, tức là bạn vẫn chưa thực sự chắc. Mọi thứ viết ra đều phải qua phép thử “Thì sao?”: nếu bình luận của bạn dẫn tới hệ quả gì mà người đọc chưa thấy ngay, hãy nói thẳng ra.

Với Owner, việc theo sát về sau quan trọng không kém lúc mở đầu. Phải giữ cho cuộc thảo luận bám vào “câu hỏi triệu đô”, tức đúng cái điểm vướng thực sự quan trọng, thay vì để nó tan vào tiểu tiết. Thường xuyên tóm tắt lại những gì đã thống nhất và những gì còn bỏ ngỏ. Còn nhắc nhở qua Slack thì chỉ là phương án cuối cùng, dành cho những phần góp ý đã quá hạn hoặc chuyện thực sự gấp.

Owner cũng ẩn đi những bình luận không giúp cuộc thảo luận tiến lên. Ai cũng phải thạo cách định dạng trên GitHub, từ tiêu đề, chú thích cuối trang, bảng cho tới phím tắt, vì khi viết thì hình thức gần như quan trọng ngang nội dung.

Không cần đồng thuận, không có khán giả

#

Có hai quy tắc giữ cho cách làm này không biến thành kiểu quyết định theo hội đồng.

Thứ nhất, Owner ra quyết định theo kiểu mà Alan gọi là “nhà độc tài sáng suốt”. Họ tìm hiểu các ý tưởng, cân nhắc rủi ro, chất vấn đồng nghiệp, nhưng không đi tìm sự đồng thuận và cũng không bắt buộc phải làm theo mọi điều người khác nói. Alan nói thẳng họ không phải một nền dân chủ: nhân viên nào cũng là cổ đông, và lợi ích của công ty đặt trên lợi ích của một đội hay một cá nhân. Khi Owner đã khá chắc về một hướng đi, họ quyết, mọi người cùng làm thử, và khi đã thấy được tác động thì cùng nhìn lại xem quyết định đó đúng hay sai.

Thứ hai, số người tham gia được kiểm soát. Quy tắc “hai chiếc pizza” của Jeff Bezos cũng đúng với cách làm việc bất đồng bộ (async): issue càng đông người thì mỗi người càng góp ít. Quá khoảng sáu người là hiệu ứng khán giả xuất hiện, và chất lượng góp ý đi xuống. Chuyện thông báo cũng theo cùng tinh thần đó. Alan tin rằng ai cũng đã tự cấu hình thông báo GitHub cho mình (vào Settings, rồi tick “Web and Mobile” ở cả “Participating” lẫn “Watching”), nên việc gắn thẻ (tag) thẳng tên người trong phần Câu hỏi được giữ ở mức tối thiểu.

Những gì tôi học được

#

Bạn không bao giờ kể lại được trọn vẹn một cuộc họp cho người vắng mặt, nhưng một quyết định đã viết ra thì ai cũng đọc được. Alan không nói đây là hệ thống tốt nhất hay duy nhất, chỉ là hệ thống hợp với họ: ít bị ngắt quãng hơn, ít hiệu ứng khán giả hơn, và quyết định được đưa ra sau khi đã lùi lại một bước để nhìn, với đầy đủ dữ kiện trên giấy. Tôi chưa định chuyển mọi quyết định của đội mình sang GitHub issue, nhưng cái mẫu dưới đây thì sẽ vào thẳng kho mã của chúng tôi.

Mẫu đề xuất, dùng làm mẫu issue (issue template) trên GitHub

#

Hãy lưu nội dung dưới đây thành tệp .github/ISSUE_TEMPLATE/decision.md trong kho mã mà bạn dùng làm diễn đàn, và mỗi lần có người mở issue mới, GitHub sẽ gợi ý sẵn mẫu này. Các mục trong mẫu là của Alan; phần LOCI và nhãn là tôi thêm vào.

---
name: Quyết định
about: Đề xuất một quyết định và thu thập góp ý bằng văn bản
title: "[Quyết định] "
labels: decision
---

## Phạm vi
- Mục tiêu của issue này là ...
- Issue này KHÔNG bàn về ...

## Vì sao tôi mở issue này

## LOCI
- Lead:
- Owner:
- Consulted:
- Informed:

## Mốc thời gian
- Góp ý trước ngày:
- Chốt quyết định trước ngày:

## Bối cảnh và tài liệu

## Đề xuất

## Câu hỏi

Nên dùng GitHub Issues hay GitHub Projects?

#

Nếu bạn đang tính dùng GitHub để quản lý dự án theo nghĩa rộng hơn, thì nên biết hai phần này làm hai việc khác nhau. GitHub Issues là nơi diễn ra cuộc thảo luận, và khi issue đã đóng thì là nơi lưu lại quyết định. Còn một GitHub Project là một bảng công việc, ở dạng cột kiểu Kanban (board) hoặc dạng bảng tính (table), đặt chồng lên các issue của một hay nhiều kho mã, với các trường (field) do bạn tự định nghĩa như trạng thái, người phụ trách hay hạn chót. Với một diễn đàn ra quyết định như của Alan, chỉ cần nhãn và danh sách issue là đủ. Hãy thêm một Project khi bạn muốn thấy mọi quyết định đang mở trên cùng một màn hình, sắp xếp theo ngày phải chốt, và khi bạn bắt đầu theo dõi cả các đầu việc phát triển, bàn giao sản phẩm ở cùng chỗ đó. Đó cũng là lúc phần lớn các đội rốt cuộc dùng cả hai.

Trong hầu hết các dự án tôi từng tham gia, khâu chậm nhất không phải là viết mã. Mà là xếp hàng chờ: các quyết định chất đống sau lịch làm việc của một người quản lý, chờ một cái gật đầu mất ba ngày mới tới. Giao tiếp bất đồng bộ và đội tự chủ là cách chữa quen thuộc, và tôi tin vào nó. Nhưng về bản chất, cuộc chuyển đổi này là bài toán niềm tin khoác áo bài toán công cụ.

Vì sao việc gì cũng phải chờ duyệt

#

Công bằng mà nói, văn hóa xin duyệt cũng có gốc gác của nó. Kiểm soát cho người ta cảm giác mọi thứ được chính xác: nếu quyết định nào cũng phải qua bàn quản lý thì chẳng có gì đi chệch hướng được. Một quyết định sai không chỉ làm hỏng dự án mà còn làm sứt mẻ uy tín của người quản lý, nên nỗi sợ chiếm phần rất lớn. Đôi khi người quản lý thật sự nghi ngờ đội chưa đủ kinh nghiệm để tự quyết cho tốt. Và đôi khi chỉ là thói quen còn sót lại: sơ đồ tổ chức xưa nay vẫn vận hành như vậy, thì cứ thế vận hành tiếp.

Để ý mà xem, trong bốn lý do đó chỉ có một lý do thực sự nằm ở phía đội. Ba lý do còn lại đều là chuyện của người quản lý.

Để tự chủ thì cần những gì

#

Tự chủ mà không cùng nhìn về một hướng thì chỉ là hỗn loạn, có điều tinh thần mọi người phấn chấn hơn. Khi ai cũng thực sự hiểu mục tiêu chung, những quyết định họ tự đưa ra phần lớn sẽ tự khắc cùng hướng. Bí quyết chỉ có vậy. Đào tạo cũng quan trọng, vì tin một người được trang bị đầy đủ thì dễ hơn tin một người chỉ có nhiệt huyết. Nên giữ lại vài ranh giới: có những quyết định thực sự nên để quản lý đưa ra, và nói rõ đó là những quyết định nào sẽ giúp tránh được những bất ngờ tệ nhất. Sau đó cứ để vòng lặp phản hồi vận hành, và coi những sai lầm không tránh khỏi là học phí chứ không phải bằng chứng để quy lỗi.

Nếu niềm tin đã sứt mẻ (mà ở những đội đang cố thoát khỏi văn hóa xin duyệt thì thường là đã sứt mẻ, từ cả hai phía) thì không có đường tắt nào cả. Hãy gọi tên vấn đề trong một buổi nói chuyện cởi mở, để phía quản lý nhận phần lỗi của mình trước, rồi kiên trì nhất quán đến nhàm chán trong nhiều tháng. Vai trò rõ ràng và những buổi trao đổi định kỳ (check-in) hàn gắn được nhiều hơn mọi cử chỉ hoành tráng.

Phần bất đồng bộ mới là phần dễ

#

Nói qua về công cụ trước: Slack hay Microsoft Teams đều ổn cả. Việc thật sự cần làm là tài liệu. Khi không ai ngồi chung phòng hay chung múi giờ, những quyết định được viết ra chính là trí nhớ của cả đội. Hãy đặt quy ước về thời gian phản hồi để bất đồng bộ không lặng lẽ biến thành “không ai trả lời”; “trong vòng một ngày” tốt hơn nhiều so với “lúc nào rảnh”, và quy ước này nên được ghi vào kế hoạch truyền thông của đội, ngay cạnh phần ai nhận bản cập nhật nào. Và hãy thực sự dạy mọi người cách viết một tin cập nhật cho người khác đọc sau sao cho tử tế, vì kỹ năng này không tự nhiên mà có: đủ bối cảnh để người đọc ra quyết định, nói rõ cần quyết định điều gì, và hạn chót là khi nào. Chẳng hạn như thế này:

Cần chốt trước thứ Năm: thử lại thanh toán
Hiện tại, khi thanh toán bằng thẻ thất bại, hệ thống chỉ thử lại (retry) một lần sau 24 giờ, và câu hỏi “Đơn hàng của tôi đâu rồi?” đang là loại yêu cầu hỗ trợ nhiều nhất.
Phương án A: thử lại ba lần trong vòng 24 giờ (mất khoảng nửa ngày làm). Phương án B: giữ nguyên, thay vào đó gửi email báo cho khách.
Tôi đề xuất chọn A. Chi tiết và số liệu có trong tài liệu tôi gửi kèm.
Nếu đến 17 giờ thứ Năm không ai phản đối, tôi sẽ bắt đầu làm theo phương án A.

Một tin như vậy thì ai đọc lúc 7 giờ sáng hay 11 giờ đêm, ở múi giờ nào, cũng có thể trả lời được mà không cần họp.

Bạn có thể triển khai Slack trong một buổi chiều. Còn niềm tin thì phải mất hàng tháng, và chính nó quyết định mọi thứ ở đây có thành hay không. Hãy làm rõ mục tiêu, và để một sai lầm chỉ tốn một bài học chứ không tốn cả sự nghiệp của ai. Làm được vậy thì phần bất đồng bộ gần như tự vận hành.