Ngăn Ngừa Lỗi Nhỏ: 7 Nguyên Tắc Kỹ Thuật Mỗi PM Nên Biết
Hai tuần trước khi ra mắt, mọi thứ đều có vẻ ổn — cho đến khi một thay đổi "nhỏ" trong một thành phần chung gây ra sự cố trong quá trình thanh toán. Ba đội phát triển sở hữu ba phiên bản khác nhau của cùng một logic. Việc khắc phục mất vài ngày.
Nghe có vẻ quen thuộc? Đó không thực sự là một "lỗi". Đó là sự không khớp yêu cầu và đây là loại tình huống mà các quản lý sản phẩm có thể ngăn chặn nếu họ hiểu cách mà kỹ sư suy nghĩ.
Bạn không cần phải biết lập trình. Nhưng bạn cần phải hiểu ngôn ngữ phát triển phần mềm đủ tốt để nhận diện rủi ro, đặt ra những câu hỏi sắc bén hơn, và thực hiện các thỏa thuận với kỹ sư trưởng của bạn.
Dưới đây là 7 nguyên tắc kỹ thuật, bằng ngôn ngữ dễ hiểu, có thể cứu vãn lộ trình phát triển của bạn (và cả sự bình tĩnh của bạn):
1. DRY — Don’t Repeat Yourself
Mỗi quy tắc bị trùng lặp = gấp ba lần rủi ro. Một thay đổi nên xảy ra ở một nơi duy nhất. Hãy thúc đẩy việc sử dụng các thành phần tái sử dụng thay vì giải pháp sao chép-dán.
2. KISS — Keep It Simple, Stupid
Phức tạp là một gánh nặng. Ít nhánh hơn, ít trường hợp ngoại lệ hơn, ít đau đầu hơn. Luôn hỏi: cách đơn giản nhất để đạt được kết quả này là gì?
3. YAGNI — You Ain’t Gonna Need It
Xây dựng cho "nếu" sẽ làm tắc nghẽn danh sách công việc của bạn. Giao hàng những gì người dùng cần hôm nay, không phải những gì họ có thể cần trong tương lai.
4. Nợ Kỹ Thuật Là Tiền Thật
Những lối tắt là những khoản vay có lãi suất. Nếu bạn không lập ngân sách thời gian cho việc tái cấu trúc, "mẹo nhanh" đó sẽ làm chậm bạn vào quý sau.
5. APIs & Microservices
Biết giới hạn của hệ thống của bạn. APIs sạch = ít bất ngờ hơn, công việc song song nhanh hơn, và dễ dàng hợp tác hơn.
6. Kiểm Soát Phiên Bản & Thực Hành Ra Mắt An Toàn
Giao hàng ≠ ra mắt. Học những kiến thức cơ bản về Git, các cờ tính năng, và phát triển dựa trên nhánh chính để bạn có thể tách biệt việc triển khai và ra mắt.
7. Đơn Giản Là Tối Ưu
Ở mọi cấp độ — mã, phạm vi, hệ thống, phát hành — sự đơn giản luôn thắng. Đó là điều giúp các đội duy trì tốc độ mà không gặp sự cố.
Tại Sao Điều Này Quan Trọng Đối Với PMs
Nếu bạn có thể nói về DRY, KISS, nợ và chiến lược ra mắt trong quá trình lập kế hoạch, bạn sẽ không còn là "người viết vé" nữa mà bắt đầu trở thành một đối tác thực sự của kỹ thuật. Đó là cách bạn ngăn chặn "lỗi nhỏ" làm gián đoạn các lần ra mắt.
Mẹo chuyên nghiệp:
Hãy dành 20 phút với kỹ sư trưởng của bạn trong tuần này và hỏi: Nguyên tắc nào trong số này, nếu chúng ta áp dụng một cách nhất quán hơn, sẽ giúp chúng ta nhanh hơn nhất? Sau đó, hãy đưa nó vào vòng lập kế hoạch tiếp theo của bạn.
Nếu bạn muốn phiên bản đầy đủ của bài viết này (với các ví dụ cụ thể, trích dẫn và tài liệu tham khảo), tôi đã công bố nó ở đây: 7 Nguyên Tắc Phát Triển Phần Mềm Mỗi Quản Lý Sản Phẩm Nên Biết.
Các Thực Hành Tốt Nhất
- Thúc đẩy việc tái sử dụng mã: Đảm bảo rằng mã của bạn có thể được sử dụng lại trong các dự án khác để tiết kiệm thời gian và công sức.
- Thường xuyên kiểm tra và đánh giá kỹ thuật: Thực hiện các cuộc họp đánh giá định kỳ để xác định các vấn đề về nợ kỹ thuật và tìm cách giải quyết chúng.
Những Cạm Bẫy Thường Gặp
- Quá nhiều tính năng không cần thiết: Hãy nhớ rằng không phải tất cả các ý tưởng đều cần được triển khai ngay lập tức.
- Thiếu giao tiếp với đội ngũ kỹ thuật: Đảm bảo rằng bạn luôn giữ liên lạc để không bỏ lỡ thông tin quan trọng.
Mẹo Tối Ưu Hiệu Suất
- Sử dụng công cụ kiểm tra hiệu suất: Giúp theo dõi hiệu suất của ứng dụng để phát hiện các vấn đề kịp thời.
- Tối ưu hóa mã: Luôn tìm cách tối ưu hóa mã để giảm thiểu thời gian tải và cải thiện trải nghiệm người dùng.
Khắc Phục Sự Cố
- Phân tích lỗi: Khi phát sinh lỗi, hãy phân tích kỹ lưỡng để tìm nguyên nhân gốc rễ và không chỉ sửa chữa tạm thời.
- Ghi lại và chia sẻ: Ghi lại các sự cố và cách giải quyết để các thành viên trong đội có thể học hỏi từ kinh nghiệm này.
Các Câu Hỏi Thường Gặp
- PM cần biết gì về kỹ thuật?
PM nên hiểu các nguyên tắc cơ bản về phát triển phần mềm để có thể giao tiếp hiệu quả với đội ngũ kỹ thuật. - Làm thế nào để giảm nợ kỹ thuật?
Thực hiện kiểm tra định kỳ và lập kế hoạch cho việc tái cấu trúc mã khi cần thiết.
Tài nguyên thêm:
