Nội dung bài viết
Tôi bắt đầu với WordPress: theme tùy chỉnh, plugin, website thương mại điện tử. Sau đó chuyển sang full-stack với React và Node.js, rồi sang vai trò quản lý dự án, và giờ là dẫn dắt một đội ngũ ở công ty của chính mình.
Nhìn lại chặng đường đó, có vài điều tôi ước mình hiểu sớm hơn. Không phải bài học kỹ thuật, mà là những thứ quyết định dự án thành hay bại.
Bug đắt nhất nằm ở giai đoạn requirement
Đây là bài học tôi phải trả giá đắt nhất để học được.
Có những dự án mà code viết rất sạch, kiến trúc gọn gàng, test đầy đủ, và sản phẩm bàn giao xong thì khách hàng nói: cái này không phải thứ tôi cần.
Không có kỹ thuật nào cứu được tình huống đó. Chi phí sửa một hiểu lầm ở giai đoạn khảo sát yêu cầu gần như bằng không. Chi phí sửa cùng hiểu lầm đó sau khi đã code xong thì gấp hàng chục lần, và sau khi đã lên production thì còn hơn thế nữa.
Từ khi làm quản lý dự án, thứ tôi đầu tư nhiều thời gian nhất không còn là code mà là làm rõ mọi điều mơ hồ trước khi ai đó bắt đầu gõ phím. Câu hỏi tôi hỏi nhiều nhất trong các buổi họp là “khi việc này xảy ra thì hệ thống nên làm gì?”, và nó thường lộ ra những khoảng trống mà cả hai bên đều tưởng bên kia đã nghĩ tới.
Người làm nghiệp vụ không biết họ muốn gì cho tới khi nhìn thấy
Điều này nghe có vẻ trách móc, nhưng thực ra là một sự thật rất bình thường về con người.
Khách hàng mô tả quy trình đặt phòng của họ bằng lời, bạn ghi lại thành tài liệu, hai bên ký xác nhận. Rồi khi thấy màn hình thật, họ nói “à không, trường hợp khách đặt nhiều phòng thì khác”. Thông tin đó không hề bị giấu, nó chỉ đơn giản là chưa được nghĩ tới cho đến khi có thứ cụ thể để nhìn.
Kết luận thực dụng: đừng chờ tới lúc bàn giao mới cho khách xem. Bản mockup, wireframe, hay một bản demo chạy được dù còn xấu, đều rẻ hơn rất nhiều so với việc code lại. Trên các dự án khách sạn tôi từng làm, chỉ riêng việc demo sớm và thường xuyên đã cắt được phần lớn những thay đổi lớn vào phút chót.
Ước lượng luôn sai, hãy thiết kế quy trình chấp nhận điều đó
Tôi chưa từng gặp ai ước lượng đúng một cách nhất quán, kể cả bản thân mình.
Vấn đề không nằm ở kỹ năng ước lượng mà ở bản chất công việc: bạn đang ước lượng thời gian cho thứ mình chưa từng làm. Nếu đã từng làm rồi thì đã có sẵn code để tái sử dụng.
Cách tôi xử lý hiện nay là không cố ước lượng chính xác hơn, mà là chia nhỏ hơn. Một hạng mục ước lượng ba ngày thì sai số có thể là vài ngày. Một hạng mục ước lượng ba tuần thì sai số có thể là vài tuần, và bạn chỉ phát hiện ra khi đã quá muộn. Chia nhỏ giúp sai lệch lộ ra sớm, khi vẫn còn thời gian điều chỉnh.
Code là để giao tiếp
Bạn đọc code nhiều hơn nhiều so với số lần viết ra nó. Hãy tối ưu cho người đọc tiếp theo, mà thường thì đó chính là bạn của sáu tháng sau, lúc đã quên sạch bối cảnh.
Điều này càng đúng khi bạn chuyển sang vai trò quản lý. Code tôi viết giờ được người khác bảo trì. Một hàm thông minh mà chỉ tôi hiểu là một khoản nợ tôi để lại cho đội.
Ship nhỏ, ship thường xuyên
Những thay đổi lớn thì rủi ro và khó review. Một pull request 2000 dòng sẽ được duyệt qua loa, vì không ai đủ sức giữ ngần ấy bối cảnh trong đầu.
Phát hành nhỏ và thường xuyên vừa giảm rủi ro vừa duy trì đà tiến. Và quan trọng hơn: khi có sự cố, bạn biết chính xác thay đổi nào gây ra nó.
Học công nghệ mới, nhưng chọn nền tảng để đứng
Trong 8 năm, tôi đã đi qua jQuery, WordPress, PHP thuần, React, Node.js, và giờ là các công cụ AI hỗ trợ lập trình. Công cụ thay đổi liên tục.
Nhưng những thứ chuyển được từ giai đoạn này sang giai đoạn khác thì không nhiều và ít thay đổi: hiểu cách HTTP hoạt động, biết thiết kế cơ sở dữ liệu, đọc được log để lần ra nguyên nhân, và diễn đạt được một vấn đề kỹ thuật cho người không làm kỹ thuật hiểu.
Kỹ năng cuối cùng bị đánh giá thấp nhất. Nó là thứ quyết định bạn dừng lại ở vai trò thực thi hay đi tiếp.
Làm việc với AI không có nghĩa là bớt chịu trách nhiệm
Trong dự án gần đây tôi xây dựng phần frontend với sự hỗ trợ của AI để bàn giao nhanh hơn. Nó thực sự rút ngắn thời gian đáng kể.
Nhưng có một ranh giới tôi giữ rất rõ: kiến trúc và mã nguồn cuối cùng vẫn là trách nhiệm của tôi. AI viết ra code chạy được không đồng nghĩa với code đúng, và càng không đồng nghĩa với code phù hợp với phần còn lại của hệ thống. Nếu tôi không hiểu một đoạn code trong dự án của mình, thì đoạn đó không nên tồn tại ở đó.
Chọn giải pháp đơn giản nhất giải quyết đúng vấn đề
Cám dỗ lớn nhất với người làm kỹ thuật là xây thứ thú vị thay vì thứ cần thiết.
Tôi đã từng thiết kế những hệ thống tính đến khả năng mở rộng cho lượng người dùng chưa bao giờ đến. Phần phức tạp thừa ra đó không biến mất, nó nằm lại và làm chậm mọi thay đổi về sau.
Bây giờ câu hỏi tôi tự hỏi trước mỗi quyết định kiến trúc là: nếu bỏ phần này đi thì điều tệ nhất có thể xảy ra là gì? Rất nhiều lần câu trả lời là “không sao cả”.
Điều quan trọng nhất
Nếu phải rút gọn tất cả những điều trên thành một câu: hiểu vấn đề trước đã.
Những sai lầm đắt giá nhất tôi từng chứng kiến đều không phải do làm sai kỹ thuật, mà do làm rất tốt một thứ sai. Chậm lại ở giai đoạn đầu để đi nhanh hơn về sau, đó là khoản đầu tư có tỷ suất sinh lời cao nhất trong nghề này.
