Mỗi tuần, đội ngũ chúng tôi đều nhận được những câu hỏi quen thuộc: nên bắt đầu từ đâu, học kỹ năng nào trước, và quy trình làm việc thật sự khác gì so với lý thuyết trên lớp. Bài này là tổng hợp từ những gì chúng tôi đã cùng trải qua với lập trình viên, kiểm thử viên và quản lý dự án. Đây không phải đáp án duy nhất, chỉ là một góc nhìn từ người đã đi qua nhiều dự án khác nhau.

Vì sao cần tìm hiểu kỹ về nghề trong ngành công nghệ

Ngành công nghệ thay đổi nhanh hơn phần lớn các lĩnh vực khác. Một quy trình được coi là chuẩn cách đây ba năm có thể đã lỗi thời hôm nay. Chính vì vậy, kinh nghiệm thực tế thường có giá trị hơn lý thuyết sách vở, nhất là khi bạn mới bước vào nghề.

Chúng tôi từng làm việc với một đội phát triển phần mềm chỉ khoảng sáu người. Lúc đầu mọi thứ khá lộn xộn. Ai viết theo cách nào thì viết, không ai review chéo, việc bàn giao gần như dựa vào trí nhớ. Khi họ áp dụng một quy trình rõ ràng hơn, số lỗi phát sinh sau khi ra mắt giảm đi rất đáng kể. Từ trải nghiệm đó, chúng tôi tin rằng quy trình mới là thứ quyết định chất lượng công việc về lâu dài, không chỉ là kỹ năng cá nhân.

Người ngoài ngành đôi khi thấy công việc công nghệ khá khó hiểu. Nhưng khi tách nhỏ ra, phần lớn công việc xoay quanh ba trụ cột: kỹ năng chuyên môn, cách phối hợp trong nhóm và khả năng thích ứng khi yêu cầu thay đổi liên tục. Hiểu rõ ba trụ cột này sẽ giúp bạn định hướng tốt hơn trước khi chọn một vị trí cụ thể.

Nghề QA: vị trí hay bị hiểu nhầm nhất

Rất nhiều người hỏi chúng tôi QA là gì và công việc của QA cụ thể ra sao. Nhiều người nghĩ đó chỉ là ngồi bấm thử phần mềm. Thực tế, công việc này đòi hỏi tư duy logic khá cao và một sự cẩn thận gần như khó tính.

Người làm QA phải hình dung hàng chục tình huống người dùng có thể gặp, kể cả những trường hợp hiếm khi xảy ra. Họ viết test case, chạy kiểm thử thủ công lẫn tự động, rồi báo lỗi cho lập trình viên theo một mẫu chuẩn. Một báo cáo lỗi tốt, có bước tái hiện rõ ràng và ảnh chụp màn hình, có thể tiết kiệm cho cả nhóm nhiều giờ tranh luận vô ích.

Một đồng nghiệp cũ từng nói đùa rằng làm QA giống như đóng vai người dùng khó tính nhất có thể tưởng tượng. Người làm QA giỏi thường có thói quen đặt câu hỏi hoài nghi, không tin ngay khi ai đó khẳng định “đã chạy ổn”.

Nếu bạn trẻ muốn thử sức vị trí này, chúng tôi khuyên rèn tính kiên nhẫn và kỹ năng viết tài liệu rõ ràng trước. Công cụ thì có thể học dần trong quá trình làm việc. Thói quen tỉ mỉ thì khó xây dựng hơn nhiều khi đã đi làm lâu năm.

Agile giúp nhóm công nghệ bớt rối loạn như thế nào

Nhiều đội hiện nay làm việc theo Agile hoặc Scrum. Nghe có vẻ phức tạp, nhưng bản chất khá đơn giản: chia công việc thành các chu kỳ ngắn, thường gọi là sprint, kéo dài từ một đến hai tuần. Mỗi sprint có một mục tiêu rõ ràng, và cuối chu kỳ cả nhóm cùng nhìn lại kết quả.

Cách làm này giúp tránh tình trạng cả tháng không ai biết dự án đang đi về đâu, rồi đến lúc gần hết hạn mới phát hiện chậm tiến độ. Việc nhìn lại sau mỗi chu kỳ cũng cho phép điều chỉnh sớm.

Chúng tôi cũng từng thấy một đội áp dụng Agile không đúng cách. Họ họp liên miên nhưng hiếm khi ra quyết định cụ thể. Vấn đề không nằm ở quy trình mà nằm ở cách điều phối. Quy trình chỉ là công cụ, người dẫn dắt mới quyết định nó có phát huy tác dụng hay không.

• Họp đứng mỗi sáng, giới hạn dưới mười lăm phút.
• Ghi toàn bộ công việc lên một bảng chung để ai cũng nắm được bức tranh.
• Cuối mỗi chu kỳ chỉ tập trung vào một câu hỏi: lần sau nên làm khác điều gì?

Sau khi rút gọn theo những nguyên tắc này, đội đó làm việc nhẹ đầu hơn hẳn. Họ không tăng số buổi họp mà chỉ làm mỗi buổi có ích hơn.

Kỹ năng mềm quan trọng không kém chuyên môn kỹ thuật

Nhiều người nghĩ làm công nghệ chỉ cần giỏi code. Kinh nghiệm của chúng tôi cho thấy điều đó chỉ đúng một phần. Một kỹ sư rất giỏi nhưng không biết giải thích lý do kỹ thuật cho người không chuyên có thể khiến dự án bị hiểu lầm. Có những trường hợp trễ tiến độ chỉ vì các cuộc trao đổi vòng vo kéo dài hàng tuần.

Quản lý thời gian cũng là yếu tố đáng chú ý. Công việc công nghệ thường có nhiều đầu việc chạy song song: sửa lỗi gấp, viết tài liệu, họp với bộ phận khác. Nếu không biết sắp xếp ưu tiên, người làm rất dễ rơi vào trạng thái bận cả ngày mà chẳng việc nào hoàn thành trọn vẹn. Chúng tôi thường khuyên đồng nghiệp mỗi sáng chọn ra ba việc quan trọng nhất, phần còn lại để sau.

Tinh thần chủ động học hỏi mới là yếu tố sống còn. Công nghệ mới xuất hiện liên tục, và người không chịu cập nhật sẽ tụt lại khá nhanh dù trước đó từng rất giỏi. Chúng tôi hay nhắc các bạn trẻ dành đều đặn một khoảng thời gian mỗi tuần để đọc tài liệu mới hoặc thử một công cụ lạ, thay vì chờ đến khi bị yêu cầu mới bắt đầu học.

Công cụ hỗ trợ giúp quy trình trơn tru hơn

Bên cạnh kỹ năng con người, công cụ hỗ trợ cũng góp phần không nhỏ vào chất lượng quy trình. Các đội kỹ thuật thường dùng bảng quản lý công việc, hệ thống theo dõi lỗi, kho mã nguồn chung và công cụ giao tiếp nội bộ. Chọn đúng công cụ cho đúng nhu cầu quan trọng hơn nhiều so với dùng thật nhiều công cụ cùng lúc.

Một tình huống rất phổ biến là làm việc từ xa. Nhiều người trong ngành cần truy cập vào máy tính đặt ở văn phòng khi đang ở nhà. Chúng tôi từng hướng dẫn khá chi tiết cách truy cập vào máy tính chia sẻ từ xa, và đây là kỹ năng gần như ai làm nghề cũng sẽ cần ít nhất một lần.

Một khía cạnh khác ít người để ý là tốc độ tải trang. Với đội phát triển sản phẩm web, hiệu năng chậm không chỉ là lỗi kỹ thuật mà còn ảnh hưởng trực tiếp đến trải nghiệm khách hàng. Khi cần tham khảo thêm, bạn có thể đọc bài website tải chậm khiến khách bỏ đi giữa chừng. Đây cũng là nhóm lỗi mà kiểm thử viên phải soi kỹ trước khi sản phẩm ra mắt.

Áp dụng tư duy quy trình công nghệ vào đời sống hằng ngày

Quy trình làm việc của dân công nghệ không chỉ hữu ích trong ngành. Nhiều nguyên tắc có thể áp dụng cho bất kỳ ai muốn sắp xếp công việc và cuộc sống gọn gàng hơn.

Cách chia nhỏ công việc thành từng bước ngắn giống mô hình sprint rất hợp khi học một kỹ năng mới. Thay vì đặt mục tiêu lớn và mơ hồ kiểu “tháng này phải giỏi tiếng Anh”, hãy chia thành các phần nhỏ có thời hạn rõ ràng, rồi đánh giá lại sau mỗi giai đoạn. Cách này giúp dễ theo dõi tiến bộ và ít nản hơn.

Tinh thần hoài nghi của người làm QA cũng đáng học. Trước một quyết định quan trọng, thử tự đặt câu hỏi ngược lại với kế hoạch của mình, giống như cách kiểm thử viên soi lỗi sản phẩm. Thói quen này giúp tránh nhiều sai sót không đáng có.

Chúng tôi từng áp dụng cách làm này khi lên kế hoạch cho một dự án nội dung khá lớn. Thay vì làm một mạch từ đầu đến cuối, cả nhóm chia thành các đợt nhỏ, mỗi đợt được đánh giá lại trước khi tiếp tục. Công việc trôi chảy hơn và ít phải quay đầu sửa lại.

Vài lưu ý cho người muốn chuyển sang ngành công nghệ

Không ít độc giả hỏi liệu có nên chuyển sang công nghệ khi đã ngoài ba mươi tuổi. Câu trả lời của chúng tôi luôn là còn tùy mục tiêu và khả năng thích nghi của từng người, không có công thức chung nào phù hợp với tất cả.

Nếu bạn thích công việc đòi hỏi tư duy logic, không ngại học liên tục và chấp nhận kiến thức có thể lỗi thời sau vài năm, ngành công nghệ vẫn còn nhiều cơ hội. Ngược lại, nếu cần sự ổn định tuyệt đối và không thích thay đổi thường xuyên, nên cân nhắc kỹ hơn.

Lời khuyên nhỏ từ đội ngũ chúng tôi là thử làm một dự án nhỏ trước khi quyết định chuyển hẳn, dù là dự án cá nhân hay tình nguyện. Trải nghiệm này cho bạn cảm nhận thực tế về nhịp độ công việc, thay vì chỉ hình dung qua sách vở hay video hướng dẫn. Nếu đang cân nhắc những kỹ năng cần chuẩn bị, bạn có thể tham khảo thêm các kỹ năng cần học khi chuyển ngành sang công nghệ ở tuổi 30.

Chia sẻ về nghề nghiệp, kỹ năng và quy trình làm việc trong ngành công nghệ không bao giờ có một đáp án duy nhất. Mỗi đội nhóm vận hành theo một cách riêng, và điều quan trọng là chọn lọc những gì hợp với hoàn cảnh của mình. Hy vọng những trải nghiệm trong bài giúp bạn có góc nhìn rõ hơn, dù đang làm trong ngành hay chỉ muốn sắp xếp công việc gọn gàng hơn mỗi ngày. Nếu muốn hình dung rõ hơn một ngày làm việc thực tế, bạn cũng có thể đọc thêm một ngày làm việc thực tế của dev backend.