Kỹ thuật tại Let’s Do This
Chúng tôi không phải là công ty tối ưu hóa hay chủ nghĩa gia tăng; chúng tôi luôn hỗ trợ lẫn nhau trong việc đặt cược lớn và tìm ra cách tạo ra tác động lớn nhất có thể.
Điều này thường có nghĩa là chúng tôi thất bại, vì vậy chúng tôi chọn thất bại về phía trước. Thất bại, học hỏi, chuyển sang bước tiếp theo. Nếu bạn là một người theo chủ nghĩa hoàn hảo hoặc không thích rủi ro, bạn sẽ không hài lòng với LDT ở giai đoạn hiện tại của chúng tôi. Chúng tôi hiện đang trong giai đoạn chạy vòng quanh và đột phá và tin rằng điều đó hoàn thành tốt hơn là hoàn hảo. Tất cả các kỹ sư đều ở tuyến đầu, hoạt động rất gần với quá trình sản xuất và có toàn quyền tự chủ trong việc xây dựng, phát hành và hoàn nguyên.
Công nghệ của chúng tôi cũng phát triển rất nhanh. Ý của chúng tôi không phải là về việc sử dụng công nghệ tiên tiến, mà là chúng tôi (có thể là do giai đoạn của chúng tôi và liên tục tìm kiếm thị trường sản phẩm phù hợp) thường xuyên thêm công nghệ mới vào ngăn xếp, loại bỏ các thử nghiệm không hoạt động và thay thế sự lặp lại sớm của các ý tưởng khi sản phẩm phát triển.
Những gì có thể được coi là “cắt giảm” (có thể là một phần nào đó của QA hoặc sự nghiêm ngặt trong phạm vi kiểm tra), chúng tôi thấy là cần thiết để đáp ứng thời hạn. Chúng tôi luôn cố gắng tối đa hóa khả năng có thể phù hợp với nước rút và tiến gần đến mức cam kết nhất có thể. Chúng tôi cũng không lo lắng về việc chuyển giao quá mức. Nếu chúng tôi đã ước tính kém và thêm quá nhiều vào một giai đoạn hoặc nước rút, chúng tôi sẽ đánh giá lại trong giai đoạn lập kế hoạch tiếp theo và tự hỏi bản thân rằng liệu các dự án có còn được ưu tiên hay không hay đã di chuyển các mục tiêu (một lần nữa)? Các thành viên trong nhóm đến từ những công ty lớn và chậm chạp như Facebook và Google đã phát triển mạnh mẽ nhờ tốc độ làm việc của chúng tôi và hoàn thành tốt công việc ở đây (sau cú sốc ban đầu đó là 😉).
Kỹ thuật tại Plus
Chúng tôi ưu tiên thử nghiệm và ra quyết định dựa trên giả thuyết.
Khi đưa ra quyết định, trước tiên chúng tôi tự hỏi mình đó là cánh cửa “một chiều” hay “hai chiều”. Ở giai đoạn của chúng tôi, hầu hết các quyết định hóa ra có thể đảo ngược hơn chúng tôi nghĩ và việc đưa ra điều đó một cách rõ ràng sẽ giúp chúng tôi bối cảnh hóa mức độ rủi ro mà chúng tôi đang thực sự gánh chịu. Ví dụ: chúng tôi đã cố ý đưa các tính năng vào sản phẩm alpha của mình sẽ không mở rộng theo cách hiệu quả về chi phí vì chúng tôi muốn tìm hiểu và ưu tiên phản hồi của khách hàng từ sớm.
Chúng tôi lập kế hoạch càng nhiều càng hữu ích – thường là một hoặc hai quý mỗi lần – nhưng chúng tôi thực tế về khả năng dự đoán tương lai của mình. Chúng tôi coi các kế hoạch và mục tiêu sản phẩm của mình giống như các giả thuyết hoạt động được xác thực thông qua các tính năng vận chuyển cũng như việc sử dụng và phản hồi thực tế của khách hàng.
Chúng tôi muốn xây dựng một đội thực dụng, không giáo điều trong việc ra quyết định của mình. Đôi khi chúng tôi đưa ra quyết định dựa trên trực giác. Đôi khi chúng tôi phải bất đồng và cam kết. Và đôi khi chúng tôi hóa ra đã sai và cần phải thay đổi hướng đi. Vào cuối ngày, mục tiêu của chúng tôi là tối ưu hóa tốc độ học tập của chúng tôi hơn là tỷ lệ phần trăm những thứ chúng tôi đạt được ngay trong lần thử đầu tiên.
Đội kỹ thuật tại Stytch
“Thất bại nhanh” là một trong những giá trị cốt lõi của chúng tôi.
Để đổi mới nhanh chóng, chúng tôi phải sẵn sàng chấp nhận rủi ro và học hỏi từ bất kỳ sai lầm nào. Chúng tôi luôn tự hỏi mình, “Chúng tôi có suy nghĩ đủ lớn không?” và cố gắng tìm ra cách tốt nhất để làm việc nhanh chóng và hiệu quả. Một cách chúng tôi làm điều này là sử dụng hackathons của chúng tôi, chúng tôi thường có ba lần một năm. Chúng tôi dành một tuần để đưa ra những ý tưởng sáng tạo, độc đáo và không có sự giới hạn. Ví dụ: trong một cuộc thi hackathon trước đó, đội chiến thắng đã tích hợp Algolia để cải thiện trải nghiệm tìm kiếm trong tài liệu của chúng tôi. Sự thay đổi này có trực tiếp ngày hôm nay!
Mặc dù sai lầm là không thể tránh khỏi, nhưng chúng tôi không chăm chăm vào chúng và luôn tiến về phía trước một cách nhanh chóng. Nhóm nền tảng di chuyển từ Terraform sang Crossplane (để đơn giản hóa việc tự động hóa xây dựng trên cơ sở hạ tầng của chúng tôi) là một ví dụ tuyệt vời. Vì Crossplane là một dự án tương đối mới nên nó không có đầy đủ tính năng ngang bằng với Terraform, nhưng nhìn chung nó mang lại trải nghiệm tốt hơn. Chúng tôi đã hy vọng rằng hầu hết các tài nguyên của chúng tôi sẽ dễ dàng chuyển đổi thành Crossplane tương đương. Chúng tôi đã thành công khi di chuyển một số tài nguyên, nhưng đối với ECR (kho hình ảnh Docker của chúng tôi), nhà cung cấp AWS của Crossplane không có tính năng mà chúng tôi cần vào thời điểm đó, nhưng Terraform thì có. Chúng tôi nghĩ rằng chúng tôi đã bị mắc kẹt, nhưng Crossplane đã phát hành một nhà cung cấp mới bao gồm Terraform và nó có chức năng mà chúng tôi cần. Cảnh báo là nhà cung cấp vẫn đang trong quá trình xem trước, nhưng có vẻ như nó có thể là một giải pháp tiềm năng. Chúng tôi đã có thể làm cho nó hoạt động, nhưng chúng tôi nhận ra rằng nó chưa sẵn sàng sản xuất vì một vài lý do (chủ yếu là nó làm cho cụm EKS rất chậm). Chúng tôi đã quyết định xóa nhà cung cấp Terraform đó và di chuyển mã đó sau khi nhà cung cấp Terraform được cải thiện hoặc nhà cung cấp AWS đạt mức ngang bằng.
