Kỹ thuật ở Mode
Bạn không thể đổi mới nếu bạn sợ thất bại.
Thành công của chúng tôi dựa trên khả năng duy trì sự đổi mới tồn tại ở mọi cấp độ của công ty. Chúng tôi biết rằng cách nhanh nhất để ngăn chặn sự đổi mới là làm cho nó không an toàn khi thất bại, đó là lý do tại sao chúng tôi đã làm việc chăm chỉ để đảm bảo rằng mọi người ở Mode đều có thể chấp nhận rủi ro. Chúng tôi sẽ thử điều gì đó ngay cả khi chúng tôi không chắc chắn 100% rằng nó sẽ thành công bởi vì chúng tôi biết rằng miễn là chúng tôi đã cố gắng hết sức có thể để loại bỏ rủi ro, không ai sẽ xấu hổ nếu chúng tôi không thành công. Trong mọi việc chúng tôi làm, chúng tôi có tâm lý “Trách nhiệm chung, Rủi ro được chia sẻ”.
Việc đảm bảo an toàn khi không thành công đòi hỏi phải có quy trình khám nghiệm sau khi chết không khiển trách và để làm được điều đó, chúng tôi có Đánh giá sau hành động (AAR). Trong AAR, chúng tôi bắt đầu với giả định rằng mọi người đều làm tốt nhất có thể với thông tin họ có vào thời điểm đó. Những người tham gia tập trung vào cách hiểu và cải thiện các hệ thống và quy trình dẫn đến thất bại, hơn là ai đã làm sai điều gì. Chúng tôi sử dụng các cuộc họp này như cơ hội để củng cố rằng Mode là nơi an toàn để thất bại, xây dựng các biện pháp bảo vệ mạnh mẽ hơn chống lại các thất bại trong tương lai và gắn kết nhóm lại gần nhau hơn.
Kỹ thuật tại Ladder
Bạn có thể mong đợi để giao mã vào ngày đầu tiên của bạn.
Trong khi chúng tôi cố gắng viết mã chất lượng cao, chúng tôi nhận ra những sai lầm và các trường hợp cạnh gây ra lỗi là không thể tránh khỏi. Chúng tôi có thiên hướng về tốc độ hơn sự hoàn hảo; chúng tôi phát hành tính năng càng sớm, chúng tôi càng có thể thu thập nhiều dữ liệu và lặp lại nhanh hơn để cung cấp cho người dùng trải nghiệm tốt nhất có thể. Chúng tôi không ngại phá vỡ sản xuất (điều đó xảy ra!). Trên thực tế, chỉ khi làm như vậy chúng tôi mới có thể học cách xây dựng các biện pháp bảo vệ tốt hơn để chống lại những hỏng hóc trong tương lai. Cuối cùng, điều này dẫn đến một hệ thống miễn dịch cụm, giúp chúng tôi triển khai nhanh hơn và an toàn hơn (xem Phân phối liên tục bên dưới).
Nếu xảy ra sai sót, chúng tôi không bao giờ đổ lỗi cho bất kỳ người nào. Thay vào đó, chúng tôi rất vui khi được tham gia, giúp khắc phục sự cố trong tầm tay và học hỏi từ nó trong những lần retro không chê trách được. Ví dụ: chúng tôi đã từng đặt tên sai cho một biến môi trường và vô tình chạy một ứng dụng khách sơ khai trong quá trình sản xuất. Để tránh loại lỗi này xảy ra trong tương lai, chúng tôi đã thêm kiểm tra thời gian chạy để ngăn máy chủ gặp sự cố này không bao giờ phục vụ lưu lượng truy cập thực. Mặc dù đây là một ví dụ nhỏ, bằng cách lặp lại quy trình ngược không chê trách được hơn 90 lần, chúng tôi đã xây dựng một môi trường nơi thực sự an toàn khi mắc sai lầm vì có một mạng lưới an toàn mạnh mẽ.
Làm việc tại Zapier
Chúng tôi tự hào về việc có một môi trường an toàn, đáng tin cậy.
Nhóm Zapier có tính cộng tác cao. Các kỹ sư làm việc chặt chẽ với sản phẩm và thiết kế để đưa ra kế hoạch sản phẩm, sau đó làm việc cùng nhau như một nhóm kỹ sư để đặc tả nó và xây dựng các nguyên mẫu. Chúng tôi khuyến khích mọi người lên tiếng và chia sẻ ý tưởng của họ, đồng thời nhận ra rằng tất cả chúng tôi đều sẽ mắc sai lầm trong quá trình thực hiện. Bất cứ khi nào có vấn đề xảy ra, chúng tôi đều tham gia để giúp giải quyết vấn đề và không bao giờ đổ lỗi cho bất kỳ cá nhân nào. Trên thực tế, một trong những kỹ sư cấp cao của chúng tôi, Grant, đã cởi mở chia sẻ kinh nghiệm của mình: “Một thay đổi mà tôi thực hiện đã hạ gục Zapier trong khoảng 30 phút. 🤦♂️ Ai đó đã mở ra một sự cố và tôi đã nhảy ngay vào nó để sửa chữa tạm thời tại chỗ. Không có ai trách tôi về những gì đã xảy ra. Tất cả chúng tôi đều tập trung vào việc đi đến một giải pháp. Mọi người đều đồng cảm và kiên nhẫn với sự việc, điều này chỉ giúp chúng tôi đi đến hướng giải quyết nhanh hơn và phản ánh [một cách không khiển trách] trong quá trình khám nghiệm sau khi chết. Điều đó khiến tôi thực sự hạnh phúc khi được làm việc tại Zapier.”
Kỹ thuật tại Indent
“Cái giá của sự thất bại là giáo dục.” – Devin Carraway, Sổ tay SRE của Google
Chúng tôi đã học được nhiều điều nhất từ những thất bại của mình. Chúng tôi đã có các công ty, sản phẩm và dự án đều thất bại và đó là một số trải nghiệm học tập có tác động nhất của chúng tôi. Việc phạm sai lầm cho phép chúng tôi suy nghĩ kỹ hơn và chủ ý hơn về các quyết định của mình, bao gồm cả việc suy nghĩ cẩn thận về các vai trò trước khi đăng chúng. Chúng tôi đã phát hiện ra rằng khi một dự án thất bại, đó không phải là lỗi của bất kỳ người nào, mà là do các kỳ vọng được quản lý không đúng cách hoặc sắp xếp sai / sử dụng sai nguồn lực. Chỉ trong một môi trường mà bạn thất bại đủ để học – nhưng không quá nhiều đến mức bạn cảm thấy không hiệu quả – thì bạn mới thành công.
Chúng tôi muốn Indent trở thành một nơi ấm áp, nơi bạn có thể cảm thấy an toàn, làm việc tốt nhất của mình và cảm thấy hài lòng về những gì bạn làm. Điều này có nghĩa là có thể chấp nhận rủi ro và học cách bạn có thể lặp lại và cải thiện trong tương lai.
Đánh đổi: Chúng tôi nghiêng về việc thất bại sớm và thường tìm hiểu những gì chúng tôi cần để thực hiện lần lặp tiếp theo thành công, thay vì mạo hiểm đi quá sâu vào một nền tảng lung lay có thể dẫn đến chi phí cơ hội đáng kể. Có một số vấn đề nhất định yêu cầu câu trả lời chính xác trong lần thử đầu tiên và chúng tôi cố gắng phân biệt xem đó là “cánh cửa một chiều” hay một quyết định mà chúng tôi có thể tiếp cận lặp đi lặp lại.
Đội kỹ thuật tại Sibi
Chúng tôi tin vào việc tham gia võ đài quyền anh và học bằng cách làm.
Để đổi mới và phát triển nhanh chóng, Sibi sẵn sàng chấp nhận rủi ro. Biết rằng phải bỏ lỡ một vài lần để đạt được một cú swing chiến thắng, chúng tôi rất vui khi được nhảy vào võ đài quyền anh ẩn dụ. Đối với chúng tôi, cách tốt nhất để học hỏi là nhận ra rằng không có sai lầm nào là lỗi của bất kỳ người nào. Thay vào đó, chúng tôi coi mỗi bước sai lầm là một cơ hội học hỏi để cải thiện bản thân. Ví dụ: khi một thành viên trong nhóm gần đây đã phá vỡ sản xuất, chúng tôi đã tập hợp lại với nhau, chia sẻ một vài chiếc bánh nướng nhỏ và làm cho trải nghiệm thú vị trong khi giới thiệu cơ hội học hỏi. Nói chung, có rất ít biện pháp bảo vệ bởi vì chúng tôi kỷ niệm việc học hỏi từ những sai lầm của mình. Mặc dù có một yêu cầu kéo để đẩy lên thành thạo, chúng tôi xem nó như một công cụ giao tiếp nhiều hơn. Đó chủ yếu là một cách để làm rạng rỡ cộng đồng và mục đích, chứ không phải để đánh giá liệu bạn có đang viết mã hoàn hảo hay không.
Đội ngũ kỹ thuật tại ReadMe
Chúng tôi triển khai hàng ngày và không sợ mắc sai lầm.
Để đổi mới nhanh chóng, chúng tôi tin tưởng vào việc chấp nhận rủi ro đã được đo lường. Không phải mọi thứ sẽ diễn ra hoàn hảo, và điều đó không sao cả. Vì việc triển khai diễn ra hàng ngày, thời gian lâu nhất mà bất kỳ ai thực sự phải đối phó với hậu quả của một dòng mã nguy hiểm tiềm ẩn là 24 giờ. Các thành viên trong nhóm luôn sẵn sàng tham gia và giúp đỡ nếu có điều gì đó không diễn ra như kế hoạch và chúng tôi không bao giờ đổ lỗi cho bất kỳ người nào.
Khi thất bại xảy ra, chúng tôi có thể nói một cách trung thực về những gì đã xảy ra và những gì chúng tôi có thể làm tốt hơn vào lần tới trong quá trình hồi cứu kỹ thuật hai tuần một lần của chúng tôi. Điều đó có nghĩa là, chúng tôi cũng có một số lan can nhất định, bao gồm quá trình xem xét và QA chắc chắn để đảm bảo chúng tôi đang vận chuyển mã chất lượng cao.
