Blog
“Response API này trông khác với thiết kế Figma phải không?”
Chiều thứ Sáu, ngay trước khi release. Một tin nhắn duy nhất trên Slack khiến cả team đứng hình.
PM đã cần mẫn cập nhật ticket trên Jira. Designer đã mải mê hoàn thiện file Figma. Kỹ sư đã ship PR hết tốc lực. Ai cũng làm tốt nhất trong lĩnh vực của mình — vậy mà, khoảnh khắc mọi thứ ghép lại, sự lệch pha là không thể phủ nhận.
Diễn biến tiếp theo có thể đoán trước: khảo cổ Slack vào tối thứ Sáu. “Spec này được quyết định ở đâu?” “API này không khớp với ticket gốc — ai đã thay đổi?” Không ai có câu trả lời, vì bối cảnh đằng sau quyết định chưa bao giờ được ghi lại ở đâu cả.
Chúng tôi rơi vào địa ngục “không ai có lỗi, mọi thứ đang cháy” này nhiều lần hơn chúng tôi muốn thừa nhận. Beaket ra đời từ trải nghiệm đó.
Spec được thiết kế để nói dối
Không phải spec tệ. Mà cấu trúc xung quanh nó bị hỏng.
Thông tin tự nhiên sống ở những nơi khác nhau — PM sống trong Jira, designer trong Figma, kỹ sư trong GitHub. Điều đó bình thường. Mỗi công cụ giỏi nhất ở lĩnh vực của nó, và bạn không nên chống lại điều đó.
Vấn đề nằm ở hành động sao chép tất cả vào một “nguồn sự thật duy nhất.”
Khoảnh khắc bạn chép thông tin sang Notion hoặc wiki, lúc đó có hai bản sao. Khi một bản được cập nhật, bản kia trở thành lời nói dối. Một spec ngừng được duy trì sẽ mất đi lý do đằng sau các quyết định trong quá khứ và trở thành di tích ngày càng trôi xa khỏi triển khai thực tế.
Đây không phải vấn đề kỷ luật. Đây là vấn đề cấu trúc. Miễn là bản sao tồn tại, trôi dạt là tất yếu.
Kết nối, đừng sao chép
Vì vậy chúng tôi từ bỏ cách tiếp cận “tập trung mọi thứ.” Xây thêm một wiki nữa chỉ dẫn đến cùng kết cục.
Thay vào đó, Beaket vẽ ra mối quan hệ giữa các thông tin đã tồn tại.
Bạn không sao chép thiết kế Figma hay thảo luận GitHub vào Beaket. Mỗi công cụ vẫn là nguồn sự thật cho lĩnh vực của nó. Beaket đơn giản kết nối các nguồn đó thông qua bối cảnh của tại sao quyết định được đưa ra.
Cụ thể, nó cấu trúc các quyết định dự án quanh ba loại node:
- Spec — Yêu cầu nghiệp vụ. Chúng ta đang xây gì, và tại sao?
- Brief — Bản ghi quyết định thiết kế. Điều gì đã được quyết định từ góc độ thiết kế, tại sao, và điều gì sẽ hỏng nếu thiếu nó.
- ADR — Bản ghi quyết định kỹ thuật. Tại sao chọn cách tiếp cận này? Những phương án nào đã được xem xét và loại bỏ?
Ba loại này kết nối với nhau qua các cạnh, tạo thành đồ thị quyết định. Bạn không viết đặc tả chi tiết trong Beaket. Bạn ghi lại điều gì đã được quyết định, tại sao, và nó kết nối với gì — không gì hơn.
Quy tắc “Viết ít hơn”
Thành thật mà nói, đây là khía cạnh gây tranh cãi nhất của sản phẩm.
“Chẳng phải nên cho phép mọi người viết chi tiết hơn sao?” Tất nhiên câu hỏi đó được đặt ra. Nhưng khoảnh khắc bạn cho phép viết chi tiết, bạn đã xây thêm một wiki nữa. Và wiki luôn luôn mục ruỗng.
Vì vậy chúng tôi cố ý đưa ràng buộc vào Beaket: viết ít hơn.
Tiêu chí rất đơn giản — liệu bạn trong tương lai có quay lại tìm lý do sau sáu tháng không? Nếu có, hãy viết xuống. Nếu không, đừng viết. Danh sách tham số và các bước triển khai thuộc về GitHub. Beaket chỉ giữ đơn vị tối thiểu của tại sao.
Đây là đánh đổi có chủ đích. Beaket sẽ không bao giờ là công cụ tài liệu thiết kế toàn diện. Đó là by design.
Ready Flag: Bắt tay, không phải phê duyệt
Có thêm một cơ chế mà chúng tôi vui vì đã xây dựng.
Sau khi một Spec được viết, cả designer và kỹ sư đều độc lập đặt cờ “Ready.” Designer báo hiệu “Tôi hiểu yêu cầu từ góc độ UI.” Kỹ sư báo hiệu “Tôi hiểu chúng từ góc độ kỹ thuật.” Chỉ khi cả hai cờ được đặt, Spec mới chuyển sang trạng thái “Ready.”
Đây không phải quy trình phê duyệt. Đây là cái bắt tay.
Không phải “Tôi đã đọc rồi,” mà là “từ góc độ của tôi, chúng ta sẵn sàng.” Đó là cơ chế bảo vệ cấu trúc chống lại việc bắt đầu triển khai trên yêu cầu mập mờ.
Và nếu một Spec thay đổi sau khi đã được đánh dấu Ready, bán kính ảnh hưởng — mọi Brief và ADR liên kết — sẽ tự động được hiển thị. Không cần đào bới lịch sử Slack nữa.
Theo dấu quyết định
Beaket theo dõi lịch sử thay đổi không chỉ ai thay đổi gì, khi nào. Nó còn ghi lại tại sao.
Chọn bất kỳ đoạn văn bản nào, và bạn có thể truy vết khi nào nó được thay đổi, bởi ai, và vì lý do gì. Chúng tôi gọi đây là Decision Trail.
Đây không phải tính năng hào nhoáng. Nhưng sáu tháng sau, khi ai đó hỏi “tại sao spec này lại như vậy?” — câu trả lời nằm ngay đó. Chỉ riêng điều đó đã thay đổi tốc độ ra quyết định của cả team.
Những gì chúng tôi chưa biết
Chúng tôi không nghĩ Beaket phù hợp với mọi team.
Với team nhỏ ngồi cùng phòng, nơi bối cảnh được chia sẻ tự nhiên, nó có thể là quá mức cần thiết. Với tổ chức hàng trăm người, chúng tôi chưa xác thực đủ.
Điều chúng tôi chắc chắn là: mất bối cảnh đằng sau quyết định luôn có chi phí. Và chi phí đó tăng theo cấp số nhân khi team mở rộng và thời gian trôi qua.
Beaket là công cụ để giữ chi phí đó trong tầm kiểm soát — một cách có cấu trúc. Nó không phải viên đạn bạc. Nó giống bảo hiểm hơn.
Nếu team của bạn từng ở trong tình huống không ai giải thích được tại sao một quyết định thiết kế được đưa ra — hãy bắt đầu bằng cách kết nối chỉ một quyết định. Xem nó đưa bạn đến đâu.