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.