Nhật Ký Quyết Định cho Startup
Startup đưa ra hàng trăm quyết định mỗi tuần. Hầu hết biến mất vào thread Slack và cuộc họp bị quên. Cách xây dựng nhật ký quyết định thực sự hiệu quả.
By Ellis Keane · 2026-03-16
Năm 1986, tàu con thoi Challenger vỡ tan 73 giây sau khi phóng. Cuộc điều tra sau đó phát hiện rằng các kỹ sư tại Morton Thiokol đã nêu lo ngại về các vòng đệm O-ring vào tối hôm trước, lập luận rằng thời tiết lạnh khiến việc phóng không an toàn. Ban quản lý đã bác bỏ họ. Quyết định được đưa ra trong một cuộc họp qua điện thoại, và dù có biểu đồ và lời khai tồn tại, lý do cốt lõi đằng sau việc bác bỏ bị phân tán giữa các bên tham gia và không bao giờ được truyền đạt đáng tin cậy lên trên chuỗi chỉ huy.
Tôi không so sánh các quyết định sản phẩm của startup bạn với thảm họa tàu con thoi (ít nhất là không phải hầu hết). Nhưng chế độ thất bại cơ bản giống hệt với những gì tôi thấy xảy ra ở các startup mỗi tuần, chỉ với rủi ro thấp hơn: một quyết định được đưa ra, lý do đằng sau nó tồn tại trong đầu ai đó hoặc một thread Slack sắp cuộn ra khỏi màn hình, và ba tháng sau không ai có thể tái tạo lý do tại sao chúng ta chọn phương án A thay vì B. Không phải vì quyết định sai – đôi khi nó rất tốt – mà vì bối cảnh khiến nó đúng đã bốc hơi.
"Một quyết định được đưa ra, lý do đằng sau nó tồn tại trong đầu ai đó hoặc một thread Slack sắp cuộn ra khỏi màn hình, và ba tháng sau không ai có thể tái tạo lý do tại sao chúng ta chọn phương án A thay vì B." – Ellis Keane
Nhật ký quyết định cho startup không phải là bài tập quan liêu. Đó là sự khác biệt giữa "chúng ta đã thử điều đó và nó không hiệu quả" (hữu ích) và "tôi nghĩ chúng ta đã nói về điều đó một lần?" (vô dụng).
Giải Phẫu Một Quyết Định Bị Mất
Hãy để tôi theo dõi một quyết định cụ thể qua vòng đời của nó, vì phiên bản trừu tượng của vấn đề này ít thuyết phục hơn phiên bản cụ thể.
Là một ngày thứ Ba vào tháng Hai. Trưởng bộ phận kỹ thuật và PM của bạn đang thảo luận trong một thread Slack về việc nên xây dựng hệ thống thông báo tùy chỉnh hay sử dụng dịch vụ bên thứ ba. Thread có 47 tin nhắn (tôi biết, nhưng thế là bình thường), và đến tin nhắn thứ 38, họ đã chốt phương án dịch vụ bên thứ ba vì việc tự xây sẽ mất ba sprint và hạn chót ra mắt là hai sprint nữa.
PM tạo issue trong Linear: "Tích hợp [Service X] cho thông báo." Một kỹ sư nhận việc, bắt đầu xây dựng. Thread Slack về mặt kỹ thuật vẫn còn đó, nhưng không ai đánh dấu hoặc liên kết nó từ issue trong Linear.
Tua nhanh đến tháng Năm. Dịch vụ bên thứ ba gặp vấn đề về độ tin cậy. Ai đó hỏi: "Tại sao chúng ta không tự xây điều này?" PM nhớ cuộc trò chuyện nhưng không nhớ chi tiết. Trưởng bộ phận kỹ thuật đang nghỉ thai sản. Thread Slack ở đâu đó trong kênh #engineering từ tháng Hai, nhưng không ai nhớ ngày chính xác, và tìm kiếm Slack trả về 200 kết quả cho "notification" (vì tất nhiên mọi nhóm đều thường xuyên thảo luận về thông báo).
Nhóm dành 45 phút trong cuộc họp để tái tạo lại lý do ban đầu. Cuối cùng họ đi đến kết luận tương tự – ràng buộc về thời gian vẫn còn hiệu lực – nhưng 45 phút đã mất, và nghi ngờ vẫn còn đó. Nhân lên với hàng chục quyết định mà một startup đưa ra mỗi tháng, và bạn có một lượng thời gian đáng kể dành cho việc tranh luận lại các lựa chọn đã được đưa ra một cách chu đáo.
Tại Sao Startup Đặc Biệt Kém Ở Điều Này
Các công ty lớn (dù có nhiều khuyết điểm) thường có bộ nhớ thể chế được mã hóa trong quy trình: bản ghi quyết định kiến trúc, RFC, tài liệu thiết kế đi qua các chu kỳ xem xét chính thức. Các quyết định có thể bị chôn vùi trong Confluence, nhưng ít nhất chúng được ghi lại ở đâu đó có thể tìm thấy.
Startup không có cơ sở hạ tầng đó, và việc xây dựng nó có cảm giác giống hệt loại gánh nặng cần tránh khi bạn nhỏ và nhanh. Có lập luận hợp lý rằng "chúng ta sẽ chỉ nhớ" hoạt động với 4 người, và nó hoạt động – cho đến khi người thứ 5 tham gia và không có bối cảnh nào về lý do tại sao mọi thứ lại như vậy.
Điều khác khiến việc theo dõi quyết định ở startup đặc biệt khó là sự phân mảnh công cụ. Các quyết định xảy ra ở khắp nơi: thread Slack, cuộc gọi Zoom, bình luận Notion, thảo luận Linear, đánh giá PR trên GitHub, và (ngày càng nhiều) trong DM không bao giờ đến kênh chung. Mỗi công cụ nắm bắt một phần của quyết định, nhưng không cái nào nắm bắt toàn bộ, và các liên kết giữa chúng được duy trì bởi bộ nhớ con người, thứ (nói thật lòng) là cơ sở dữ liệu kém tin cậy nhất mà bất kỳ ai trong chúng ta có.
Nhật Ký Quyết Định Thực Sự Cần Gì
Có sự cám dỗ để quá kỹ thuật hóa điều này. Tôi đã thấy các nhóm xây dựng cơ sở dữ liệu Notion phức tạp với 15 thuộc tính mỗi mục – loại quyết định, mức độ tác động, trạng thái xem xét, các bên liên quan, OKR liên quan – rồi không bao giờ sử dụng chúng vì chi phí điền tất cả các trường đó cho mỗi quyết định cao hơn giá trị được cảm nhận.
Nhật ký quyết định cho startup cần đủ nhẹ để mọi người thực sự sử dụng. Đây là những gì quan trọng:
Bản thân quyết định. Một câu. "Chúng ta đang sử dụng Service X cho thông báo thay vì tự xây." Không phải một đoạn văn – một câu.
Ai đưa ra và khi nào. Tên và ngày. Nghe có vẻ hiển nhiên nhưng đây là phần quan trọng nhất khi ai đó đặt câu hỏi về quyết định sáu tháng sau. Không phải về việc đổ lỗi (ít nhất là không phải hầu hết) – mà về việc biết ai cần hỏi về lý do ban đầu.
Những phương án nào đã được xem xét. Hai hoặc ba gạch đầu dòng. "Đã xem xét tự xây (ước tính 3 sprint, hạn chót quá gấp)" và "Đã xem xét Service Y (giá không mở rộng quy mô qua 10K người dùng)." Đây là phần ngăn chặn việc tranh luận lại – nếu các phương án và sự đánh đổi được ghi lại, nhóm không cần khám phá lại chúng.
Cuộc thảo luận diễn ra ở đâu. Liên kết đến thread Slack, issue Linear, bình luận Notion – bất cứ nơi nào cuộc tranh luận thực sự diễn ra. Đây là trường được đánh giá thấp nhất. Không có nó, mục nhật ký là một lời khẳng định không có bằng chứng. Với nó, bất kỳ ai muốn đầy đủ bối cảnh có thể đọc cuộc trò chuyện gốc.
Điều gì sẽ thay đổi quyết định. Điều này là tùy chọn nhưng cực kỳ hữu ích cho các startup nơi bối cảnh thay đổi nhanh. "Chúng ta sẽ xem xét lại điều này nếu hạn chót ra mắt dịch chuyển hơn 4 tuần" hoặc "Điều này giả định chúng ta ở dưới 10K thông báo hàng tháng." Biến một bản ghi tĩnh thành một bản ghi sống.
Nhật ký quyết định tốt nhất cho startup là cái mà nhóm bạn thực sự điền vào. Năm trường, mỗi trường một câu. Nếu mất hơn 90 giây để ghi lại một quyết định, hệ thống sẽ chết trong vòng một tháng.
Đặt Nó Ở Đâu
Tôi đã thấy các nhóm thử ba cách tiếp cận, và tất cả đều có sự đánh đổi.
Cơ sở dữ liệu Notion. Đây là cách phổ biến nhất và hoạt động khá tốt. Tạo cơ sở dữ liệu với năm trường ở trên, thêm mẫu để điền nhanh, và liên kết mỗi mục với trang dự án liên quan. Nhược điểm: Notion là nơi các spec tồn tại, không phải nơi các quyết định xảy ra, vì vậy bạn đang dựa vào ai đó vào Notion sau khi quyết định được đưa ra ở nơi khác. Bước "sau đó" đó là nơi tỷ lệ bỏ cuộc xảy ra.
Trực tiếp trong Slack. Một số nhóm sử dụng kênh #decisions chuyên dụng và đăng tin nhắn có định dạng cho mỗi quyết định. Điều này ít ma sát hơn (quyết định có lẽ đã được đưa ra trong Slack rồi), nhưng tìm kiếm của Slack khiến việc tìm quyết định theo dự án hoặc phạm vi ngày trở nên khó khăn, và việc thiếu các trường có cấu trúc có nghĩa là tính nhất quán giảm dần theo thời gian.
Trực tiếp trong Linear. Nếu quyết định liên quan đến một quy trình cụ thể, việc ghi lại nó như một bình luận trên issue Linear liên quan giúp quyết định gần với công việc mà nó ảnh hưởng. Nhược điểm là các quyết định trải dài nhiều issue hoặc dự án không có ngôi nhà tự nhiên.
Không cái nào trong số này thực sự tốt, nếu thành thật mà nói. Vấn đề cơ bản là quyết định xảy ra trên nhiều công cụ nhưng nhật ký tồn tại trong một công cụ, vì vậy luôn có một bước thủ công để thu hẹp khoảng cách. Bước thủ công đó là điểm thất bại duy nhất cho mọi nhật ký quyết định tôi đã thấy.
Những Gì Chúng Tôi Đang Xây Dựng tại Sugarbug
Cách tiếp cận chúng tôi áp dụng với Sugarbug là phát hiện các quyết định khi chúng xảy ra trên các công cụ, thay vì yêu cầu ai đó ghi lại chúng thủ công.
Khi một thread Slack đạt đến kết luận ("Ок, hãy đi với Service X"), khi một cuộc thảo luận issue Linear được giải quyết, khi đánh giá PR trên GitHub kết thúc với sự phê duyệt – tất cả đây đều là tín hiệu rằng một quyết định đã được đưa ra. Sugarbug tiếp nhận những tín hiệu này, phân loại chúng và liên kết chúng với các nhiệm vụ và người liên quan trong đồ thị tri thức. "Nhật ký quyết định" không phải là cơ sở dữ liệu riêng biệt mà ai đó phải duy trì – đó là cái nhìn về các quyết định đã được nhúng vào các công cụ hiện tại của bạn.
Chúng tôi vẫn đang hoàn thiện độ chính xác phân loại (tìm ra sự khác biệt giữa "một quyết định" và "chỉ là cuộc trò chuyện" khó hơn âm thanh), nhưng cá cược định hướng là việc ghi lại quyết định tại nguồn, nơi chúng thực sự xảy ra, đáng tin cậy hơn việc yêu cầu con người sao chép chúng vào một hệ thống riêng biệt.
Nếu điều đó thu hút bạn, sugarbug.ai có thêm chi tiết. Nhưng hệ thống thủ công ở trên sẽ phục vụ tốt hầu hết các startup cho đến khi nhóm đủ lớn để tỷ lệ bỏ cuộc khi ghi nhật ký thủ công trở thành vấn đề thực sự – thường là khoảng 8–12 người, theo kinh nghiệm của chúng tôi.
Ngừng mất quyết định vào cuộn Slack. Sugarbug tự động ghi lại chúng từ các công cụ nơi chúng thực sự xảy ra.
Q: Nhật ký quyết định của một startup nên bao gồm những gì? A: Tối thiểu: bản thân quyết định (một câu), ai đưa ra, khi nào, những phương án nào đã được xem xét, và cuộc thảo luận diễn ra ở đâu. Trường cuối cùng quan trọng nhất – không có liên kết đến cuộc trò chuyện gốc, nhật ký là lời khẳng định không có bằng chứng, và khi ai đó đặt câu hỏi về nó sáu tháng sau bạn lại quay về tái tạo từ bộ nhớ.
Q: Sugarbug có tự động xây dựng nhật ký quyết định từ các công cụ hiện có không? A: Đó là hướng chúng tôi đang đi. Sugarbug tiếp nhận tín hiệu từ Slack, Linear, GitHub, Notion và các công cụ khác, phân loại chúng vào đồ thị tri thức. Khi phát hiện quyết định – PR được phê duyệt, cuộc thảo luận Linear được giải quyết, thread Slack kết thúc với bước tiếp theo rõ ràng – nó tự động liên kết quyết định đó với nhiệm vụ và người liên quan. Chúng tôi vẫn đang tinh chỉnh phân loại (phân biệt "quyết định" với "cuộc trò chuyện" thực sự khó), nhưng việc tiếp nhận tín hiệu và liên kết đang hoạt động.
Q: Startup nên cập nhật nhật ký quyết định bao lâu một lần? A: Lý tưởng nhất là ghi lại quyết định khi chúng được đưa ra, không phải tổng hợp hàng tuần. Đến thứ Sáu, lý do đằng sau quyết định thứ Ba đã mờ nhạt, và khả năng ai đó điền chính xác trường "các phương án đã xem xét" giảm nhanh. Nếu ghi thủ công, hãy biến nó thành thói quen 90 giây ngay sau quyết định. Nếu sử dụng công cụ như Sugarbug, mục tiêu là ghi lại theo thời gian thực từ các công cụ nơi quyết định thực sự xảy ra.
Q: Sugarbug có thể theo dõi quyết định trên Slack, Linear và GitHub không? A: Sugarbug kết nối với cả ba (và Notion và Figma) và duy trì đồ thị tri thức về mối quan hệ giữa các cuộc trò chuyện, nhiệm vụ và thay đổi mã. Khi một quyết định xuất hiện trong thread Slack, dẫn đến issue Linear và tạo ra PR trên GitHub, Sugarbug liên kết toàn bộ chuỗi để bạn có thể theo dõi quyết định từ nguồn gốc đến thực hiện mà không cần ai phải tạo thủ công các liên kết đó.
Q: Sự khác biệt giữa nhật ký quyết định và bản ghi quyết định kiến trúc (ADR) là gì? A: ADR thường là tài liệu chính thức cho các lựa chọn kỹ thuật quan trọng – "chúng ta đang sử dụng PostgreSQL thay vì MongoDB" – với các phần có cấu trúc cho bối cảnh, quyết định và hậu quả. Nhật ký quyết định cho startup rộng hơn và nhẹ hơn: nó nắm bắt các quyết định vận hành hàng ngày (nhà cung cấp nào, hạn chót nào, tính năng nào cần cắt) mà ADR sẽ coi là quá nhỏ để ghi lại. Cả hai đều có giá trị; nhật ký quyết định bao gồm 95% quyết định không đảm bảo ADR chính thức nhưng vẫn cần có thể truy xuất.