Open by Default: Triết lý chia sẻ trong phát triển phần mềm

Tôi lớn lên trong cộng đồng phần mềm bằng những dòng code người khác mở ra cho mình. Hãy thử hình dung một ngày không còn thư viện miễn phí, không framework, không blog chia sẻ kinh nghiệm: tốc độ học hỏi của cả ngành sẽ tuột dốc ngay lập tức. Vì vậy tôi tin vào một nguyên tắc đơn giản: nếu không có lý do chính đáng để giữ kín, tôi sẽ mặc định mở.

Open by Default nghĩa là coi việc chia sẻ thông tin, dữ liệu và bối cảnh như trạng thái bình thường; chỉ khi có rủi ro thật sự lớn cho cộng đồng hoặc khách hàng thì ta mới khóa lại.

Niềm tin đó không phải lúc nào cũng dễ giữ. Tôi từng làm việc với những đồng nghiệp sẵn sàng gửi cả folder tài liệu cho người mới và ở đó tôi học được cách giải quyết những bài toán lớn. Nhưng tôi cũng từng ở nơi mà mỗi đoạn code đều phải xin phép, mỗi cuộc trao đổi bị kéo vào phòng kín. Người giỏi vẫn giỏi, nhưng sự sợ hãi khiến họ trở nên nhỏ bé.

Bước ngoặt đến khi tôi rời vị trí individual contributor để dẫn một team. Lúc ấy, đóng góp của tôi không còn đo bằng số dòng code mà bằng việc môi trường có đủ trong suốt, đủ tin cậy để mọi người làm hết khả năng hay không. Tôi nhận ra đồng đội của mình đều thông minh, chỉ thiếu bối cảnh và sự định hướng. Nếu tôi giữ chặt thông tin, họ sẽ mãi chờ tôi trả lời; nếu mọi thứ đều mở, họ tự kết nối điểm lại và ra quyết định nhanh hơn nhiều.

Tôi dần nhận ra ba trụ cột giúp “mặc định mở” không bị biến thành khẩu hiệu rỗng. Trụ cột đầu tiên là minh bạch: mọi kế hoạch, quyết định, giả định đều phải có nơi lưu lại và ai cũng truy cập được. Một chiếc document rõ ràng luôn mạnh hơn một cuộc họp kín vì nó cho người đọc quyền chất vấn. Trụ cột thứ hai là hợp tác thực sự, nghĩa là không chỉ share thông tin mà còn mời người khác chỉnh sửa, bổ sung, phản biện. Câu nói của Eric Raymond “Given enough eyeballs, all bugs are shallow” đến giờ vẫn đúng. Trụ cột cuối cùng là cộng đồng: càng mở thì đội càng kết nối được với những góc nhìn ngoài chiếc hộp nội bộ, từ đó sản phẩm an toàn và đa dạng hơn.

Khi những trụ cột ấy vận hành, lợi ích xuất hiện rất rõ. Trong phát triển phần mềm, team có thể release sớm, thử nghiệm nhanh vì không ai phải chờ thông tin. Peer review trở nên tự nhiên vì mọi người có bối cảnh giống nhau. Trong quản lý đội, sự minh bạch giảm bớt những giả định độc hại — mọi người hiểu vì sao ưu tiên thay đổi, biết ai đang bị tắc, và kiến thức không bị nhốt trong đầu một cá nhân nào nữa.

Dĩ nhiên, “open” không phải thuốc tiên. Bản năng con người hay né tránh việc phơi bày sai sót. Doanh nghiệp đôi lúc tạo áp lực phải nói thứ họ muốn nghe thay vì sự thật chưa đẹp. Việc viết lại bối cảnh, cập nhật tài liệu, gỡ bỏ thông tin nhạy cảm… đều tốn thời gian. Nhưng trải qua vài lần thất bại vì giấu giếm, tôi học được rằng chi phí của sự đóng kín còn cao hơn: quyết định sai nhiều hơn, sự tin tưởng sụp đổ nhanh hơn, và người giỏi rời đi sớm hơn.

Cách tôi duy trì nguyên tắc này là luôn bắt đầu bằng tài liệu: mọi quyết định sản phẩm, mọi giả định kỹ thuật đều có chỗ ghi lại, đường link được gắn ngay vào task. Tôi cố gắng giữ các bảng công việc luôn cập nhật để bất kỳ ai bước vào đều biết chúng tôi đang đi đâu. Trên hết, tôi nói thẳng với team rằng quyền được đặt câu hỏi là bắt buộc chứ không phải đặc ân; khi người dẫn dắt chủ động cho phép, cả nhóm sẽ dần bớt ngại ngùng.

Ngày nào đó tôi rời vị trí hiện tại, thứ giá trị nhất tôi để lại không phải là đoạn code nào — chúng sẽ nhanh chóng bị viết lại — mà là một văn hóa tin rằng chia sẻ là trạng thái bình thường. Khi “open” trở thành phản xạ tự nhiên, đội ngũ mạnh hơn từng cá nhân rất nhiều, và đó chính là lý do tôi vẫn kiên trì theo đuổi triết lý này.

Bài viết dựa trên trải nghiệm cá nhân kết hợp với những quan sát về best practice trong cộng đồng làm sản phẩm số.