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.

Phần lớn những dự án rối như canh hẹ mà tôi từng bị kéo vào đều không phải do mã nguồn tệ. Nguyên nhân là thông tin cần thiết không đến được đúng người, cho tới khi đã quá muộn. Từ khi nhận vai trò trưởng dự án (project lead) ở công ty, tôi bắt đầu ghi lại cách mình muốn điều phối giao tiếp, nếu có ngày ngồi vào ghế CTO. Đây là những ghi chép đó.

Xác định ai cần biết gì

#

Nền móng thì chẳng có gì hào nhoáng: một kế hoạch giao tiếp ghi rõ ai cần được báo, họ cần biết gì, bao lâu báo một lần và qua kênh nào. Tôi sẽ đòi có kế hoạch này ngay từ đầu mỗi dự án, kèm tên người phụ trách cụ thể, vì việc gì cũng giao cho “cả đội” thì rốt cuộc chẳng ai làm. Với các bên liên quan (stakeholder) cũng vậy: tìm ra ai thực sự quan tâm đến dự án, hiểu mỗi người thích được cập nhật theo cách nào, và đừng gửi cho CEO nguyên cái tin cập nhật bạn vừa đăng trong kênh của đội lập trình. Cuối cùng là đặt ra vài quy ước rõ ràng: bao lâu thì nên phản hồi, thế nào mới tính là gấp, kênh nào dùng cho việc gì. Phần lớn cái gọi là “vấn đề giao tiếp” thật ra chỉ là những kỳ vọng chưa ai nói ra thành lời.

Ví dụ về kế hoạch truyền thông cho một dự án phần mềm

#

Đây là kế hoạch tôi sẽ dùng làm điểm xuất phát rồi điều chỉnh dần. Mỗi dòng là một nhóm đối tượng cần được báo, chứ không phải một cuộc họp:

Bên dưới bảng là các quy ước, viết càng đơn giản càng tốt: gấp nghĩa là việc đó đang chặn một lần phát hành hoặc khiến khách hàng bị kẹt, nên hãy gọi điện thay vì nhắn tin; câu hỏi thì đưa vào chat, quyết định thì ghi vào công cụ quản lý công việc; phản hồi trong vòng một ngày làm việc. Với nhật ký quyết định, tôi dùng tài liệu ra quyết định, lưu dưới dạng GitHub Issues để chúng nằm ngay cạnh công việc.

Có hai điều giúp một kế hoạch như thế này thực sự vận hành. Dòng nào cũng có tên một người cụ thể ở cột cuối, và bản cập nhật cho ban lãnh đạo được viết ra chứ không chỉ nói miệng, nên có thể chuyển tiếp cho người khác mà không rơi rớt thông tin nào.

Công cụ và nhịp làm việc

#

Công cụ không quan trọng bằng mức người ta hay cãi nhau về nó. Slack để nhắn tin, Trello để quản lý công việc, Zoom khi cần nhìn mặt nhau mà nói chuyện. Chọn cái hợp với đội mình rồi đi tiếp. Nhịp làm việc mới quan trọng hơn: họp nhanh hằng ngày (daily stand-up) nếu đội làm theo Agile, cập nhật hằng tuần nếu chu kỳ dài hơn, và quan trọng là giữ đúng nhịp đó. Rồi hãy ghi chép lại mọi thứ. Quyết định, thay đổi, đầu việc cần làm (action item), tất cả đều đưa vào Notion hay Jira, như một phần của quy trình chứ không phải chuyện tiện thì làm. Sáu tháng sau, tài liệu là thứ duy nhất còn nhớ chuyện gì đã xảy ra.

Phần “mềm” mới là phần khó

#

Tất cả những gì ở trên chỉ là cơ chế. Việc khó hơn là hỏi cả đội xem cách giao tiếp hiện tại có thực sự hiệu quả không, và thay đổi khi nó không hiệu quả. Rồi còn chuyện đào tạo nữa: mỗi người trong đội đến từ một nền tảng khác nhau, và không phải ai cũng từng làm trong một dự án được vận hành tử tế. Còn phải biết lắng nghe cho đàng hoàng thay vì chỉ ngồi chờ đến lượt mình nói, và xử lý mâu thuẫn từ sớm, khi nó còn nhỏ. Mà chẳng có gì trong số này giải quyết một lần là xong: cách làm hiệu quả ở quý trước có thể lặng lẽ hết tác dụng, nên cứ phải kiểm tra lại thường xuyên.

Làm việc trong một đội phát triển phân tán/bất đồng bộ

#

Nếu đội của bạn làm việc từ xa (remote) hoặc chủ yếu trao đổi bất đồng bộ (async), bài nói này rất đáng để bạn bỏ thời gian ra xem:

Tôi không làm hoàn hảo được hết những điều này, mà cũng chẳng ai làm được. Nhưng nhìn lại thì dự án nào suôn sẻ cũng có phần lớn những thứ trên, còn dự án nào khiến tôi khổ sở thì đều thiếu ít nhất ba thứ.

Chẳng ai thích bị hỏi “việc đến đâu rồi?”, nhưng đã là người dẫn dắt dự án ở công ty thì tôi vẫn phải nắm được tình hình. Cách dung hòa của tôi là biểu đồ lịch sử Git (git graph): trước khi hỏi ai điều gì, tôi mở nó ra xem trước, và phần lớn thời gian câu trả lời đã nằm sẵn ở đó. Chỉ cần liếc qua là thấy được hoạt động commit, các nhánh được tạo ra và hợp nhất (merge) vào ra sao, mà chẳng ai phải ngồi họp vì chuyện đó.

Biểu đồ thực sự nói lên điều gì

#

Nếu bạn chưa từng nhìn kỹ loại biểu đồ này: mỗi nút là một commit, mỗi đường tách ra là một nhánh, và cả biểu đồ đọc lên giống như dòng thời gian của dự án. Cách trình bày này chứa nhiều thông tin hơn bạn tưởng:

• Liếc một cái là biết đang có bao nhiêu nhánh hoạt động và commit được đẩy lên đều đặn cỡ nào.
• Một nhánh bỗng dưng im ắng, hay một nhánh mấy tuần rồi chưa hợp nhất, thường có nghĩa là ai đó đang bị kẹt. Đây là tín hiệu cảnh báo sớm rất đáng giá.
• Tần suất hợp nhất cho bạn biết cả đội đang phối hợp với nhau thế nào. Hợp nhất thường xuyên nghĩa là phần việc của mọi người thực sự đang được ghép lại với nhau; còn nhánh tồn tại quá lâu thường là dấu hiệu có người đang làm một mình một cõi.

Ít làm phiền hơn, trao đổi chất lượng hơn

#

Cái lợi dễ thấy nhất là tôi không phải làm phiền ai mới nắm được tình hình. Nhưng cái lợi lớn hơn nằm ở những lúc thật sự cần nói chuyện: cuộc trao đổi bắt đầu từ những gì biểu đồ cho thấy, chứ không phải từ phỏng đoán. “Nhánh này đứng yên từ thứ Ba rồi, có gì đang vướng không?” là câu mở đầu tốt hơn nhiều so với “có gì mới không?”

Nói rõ thói quen này cho mọi người biết cũng giúp ích. Tôi thường liếc nhanh vào hầu hết các buổi sáng, và xem kỹ mỗi tuần một lần. Cả đội đều biết nhịp đó, nên không ai bị bất ngờ.

Đừng biến nó thành công cụ theo dõi nhân viên

#

Đây là điều tôi phải tự nhắc mình hoài. Số lượng commit không đồng nghĩa với giá trị: một commit chỉn chu có khi đáng giá hơn năm mươi commit lặt vặt. Thấy được mọi commit không có nghĩa là bạn có quyền chất vấn mọi quyết định. Hãy tin đội của mình, và chỉ nhảy vào khi thấy một xu hướng thật sự có vấn đề. Còn khi đem biểu đồ ra trong một buổi trao đổi, hãy dùng nó làm điểm khởi đầu để góp ý, chứ không phải làm bằng chứng để buộc tội ai.

Xem biểu đồ trong terminal

#

Chỉ cần có Git là đủ, không phải cài thêm gì:

git log --graph --oneline --all --decorate

Ý nghĩa của từng tùy chọn:

• --graph: vẽ các đường nhánh và đường hợp nhất (merge) ở phía bên trái.
• --oneline: mỗi commit gói gọn trong một dòng, gồm mã hash rút gọn và dòng đầu tiên của thông điệp commit.
• --all: hiện tất cả các nhánh và tag, kể cả nhánh trên remote, chứ không chỉ nhánh bạn đang đứng.
• --decorate: in tên nhánh và tag cạnh commit mà chúng trỏ tới. Các bản Git gần đây đã tự làm việc này khi kết quả hiện ra terminal, nhưng thêm tùy chọn này thì khi bạn chuyển kết quả sang lệnh khác qua pipe, tên nhánh vẫn còn.

Sáng nào cũng gõ nguyên câu lệnh dài như vậy thì mệt, nên hãy tạo một alias:

git config --global alias.graph "log --graph --oneline --all --decorate"
git graph

Với một kho mã (repository) đã chạy lâu năm, biểu đồ đầy đủ sẽ dài cuộn mãi không hết. Vài cách để thu gọn lại:

git graph --since="2 weeks ago"    # chỉ hai tuần gần nhất
git graph -20                      # chỉ 20 commit gần nhất
git log --graph --oneline main..feature                # có ở feature, chưa có ở main
git log --graph --oneline --left-right main...feature  # cả hai phía, đánh dấu < và >

Hai dòng cuối dùng để so sánh hai nhánh. Ở đây tôi dùng git log thường chứ không dùng alias, vì alias có --all sẽ kéo tất cả các nhánh khác vào lại. Hai dấu chấm cho bạn thấy những gì feature có mà main chưa có. Ba dấu chấm kèm --left-right thì hiện cả hai phía, mỗi bên có gì mà bên kia không có, nên đây là cách nhanh để xem một nhánh tồn tại lâu đã đi lệch xa đến đâu.

Xem biểu đồ trong VS Code

#

VS Code có sẵn biểu đồ. Mở khung Source Control (Ctrl+Shift+G), bạn sẽ thấy Source Control Graph là một phần trong khung đó; tính năng này có từ phiên bản 1.93 (tháng 8 năm 2024). Mặc định, biểu đồ chỉ bám theo nhánh hiện tại và nhánh remote tương ứng, nhưng bạn có thể thêm các nhánh khác bằng bộ chọn nhánh trên thanh tiêu đề của biểu đồ. Nếu chỉ cần liếc qua thì như vậy là đủ.

Muốn xem tất cả các nhánh cùng lúc thì cài extension Git Graph của tác giả mhutchie (tìm “Git Graph” trong khung Extensions). Bạn có thể mở nó bằng mục Git Graph trên thanh trạng thái (status bar), biểu tượng Git Graph ở đầu khung Source Control, hoặc lệnh Git Graph: View Git Graph (git log) trong Command Palette. Bấm vào một commit để xem các tệp đã thay đổi, hoặc bấm vào một commit rồi giữ Ctrl/Cmd bấm vào commit khác để so sánh hai commit với nhau. Extension này không có bản phát hành mới nào từ năm 2021, nên biết thêm cách dùng biểu đồ có sẵn của VS Code cũng không thừa.

Nếu không thấy nút Git Graph đâu, nhiều khả năng extension chưa tìm thấy repository nào. Theo mặc định, nó chỉ kiểm tra đúng thư mục bạn mở, không tìm vào các thư mục con. Hãy mở thẳng thư mục của repository, hoặc tăng giá trị git-graph.maxDepthOfRepoSearch trong phần cài đặt.

Các công cụ khác

#

Hầu hết công cụ Git đều có biểu đồ ở đâu đó. gitk --all là trình duyệt lịch sử commit có sẵn của chính Git. GitHub, GitLab và Bitbucket đều có chế độ xem “network” hoặc “graph” ngay trong trang repository. Các ứng dụng desktop như SourceTree (miễn phí, của Atlassian), GitKraken, Tower và TortoiseGit trên Windows cũng đều vẽ được biểu đồ.

Chọn công cụ nào cũng được, mục tiêu vẫn chỉ có một: hiểu tiến độ, chứ không phải đi đếm commit.