Liệu Việc Phải Có Một Nhóm Người Mới Làm Được Phần Mềm Có Phải Là Một Trò Lừa Đảo?

Dòng tiêu đề trên chỉ là một giả thuyết mang tính chất suy luận, chứ không phải quan điểm bất di bất dịch của tôi. Trong những năm gần đây, tôi đã tự học được một bài học quan trọng: đó là cách phân công công việc hiệu quả trong quá trình phát triển, cách tin tưởng vào các module do đồng đội xây dựng, và cách tổ chức một tập thể đông đảo làm việc cùng nhau trên một dự án.

Nhưng giả sử đây thực chất là một trò lừa đảo thì sao? Đâu phải không có khả năng đó xảy ra.

Trên thực tế, số lượng những phần mềm thực sự phức tạp đến mức cần cả một đội quân phát triển có thể không nhiều như chúng ta tưởng. Việc phải có product manager, designer, front-end, back-end… đôi khi chỉ là hệ quả của thói quen ngành nghề chứ chưa chắc đã là nhu cầu thiết yếu.

Đôi khi chúng ta cần người khác tham gia chỉ vì: (1) Đó là chuẩn mực xã hội - mọi người đều làm vậy; (2) Thiếu chuyên môn ở một lĩnh vực cụ thể nên buộc phải nhờ đến chuyên gia; (3) Có những công việc nhàm chán lặp lại mà ta ngại làm, muốn giao lại cho người khác; (4) Cấp trên thấy tiến độ chậm nên vội vàng bổ sung nhân sự theo kiểu “gậy ông đập lưng ông”.

Nếu bạn tự mình hoàn thành một dự án lớn khiến người khác ngưỡng mộ, bạn có thể được tôn vinh như một thiên tài (dù xác suất này rất nhỏ), nhưng cũng dễ bị chế nhạo là kiểu “thợ thủ công gia đình”. Bạn sẽ kiệt sức vì phải tự làm tất cả những công việc nặng nhọc mà lẽ ra nên có người chia sẻ.

Thực tế mà nói, nếu bạn không muốn làm một việc gì đó, thì làm sao có thể giao việc ấy cho người khác chỉ vì “đây là việc của bạn ấy”? Khi làm theo nhóm, việc “không thuộc phận sự của tôi” trở thành cái cớ hoàn hảo cho sự thiếu trách nhiệm. Nhưng nếu công việc đủ nhàm chán và phức tạp, điều đó thực sự phản ánh rằng chúng ta chưa biết cách tận dụng máy móc để tự động hóa.

Về mặt kiến thức chuyên môn, lập trình viên nên có tư duy tự học thay vì phụ thuộc vào người khác. Nếu bạn thực sự yêu sản phẩm mình tạo ra, chính bạn đã là người dùng trung thành nhất, hiểu rõ nhất về các tính năng cần thiết và trải nghiệm tối ưu.

Hãy nhìn vào ví dụ của Google ngày đầu: khi chưa biết HTML, họ đã thiết kế một trang chủ đơn giản đến mức “ngây ngô” bằng GIMP. Nếu bạn tự cắt đứt đường lui, không trông chờ vào ai khác, bạn sẽ cắn răng tự làm tất cả. Thật bất ngờ là thời gian hoàn thành tổng thể của một người có thể không thua kém nhiều so với một đội nhóm giỏi, và chắc chắn nhanh hơn nhiều so với một tập thể kém hiệu quả.

Tỷ lệ thành công cũng chẳng hề thấp. Chất lượng phần mềm phụ thuộc hoàn toàn vào năng lực cá nhân bạn mà thôi.

Tôi thừa hiểu việc tự thân phát triển toàn bộ dự án nghe có vẻ “vác tù và hàng tổng”. Nhưng điều đáng suy nghĩ là đa số người ta không nhận ra rằng làm theo nhóm đôi khi còn tệ hại hơn. Khi tăng số lượng nhân sự lên đến một ngưỡng nhất định, dự án có vẻ “hoạt động tạm được” (tôi từng nghe tin đồn rằng IBM dùng cả một tiểu đoàn quân sự để bảo trì phần mềm). Và thế là không ai còn tin rằng một người có thể làm được tất cả.

Đây chỉ là suy nghĩ vu vơ của tôi thôi.

Nếu bạn thực sự muốn tự mình làm dự án, kẻ thù lớn nhất không phải là giới hạn năng lượng thể chất, mà chính là sự thiếu kiên quyết trong lòng – cái kiểu luôn hy vọng rồi sẽ có người đến thay mình. Lợi thế bạn nhận được là không phải tranh cãi về thiết kế, không phải uốn nắn code style cho người khác. Nếu nhận ra sai sót, bạn có thể thức trắng đêm sửa lại mà chẳng cần lo lắng ảnh hưởng đến tiến độ người khác. Hành trình ấy, dù vất vả hay thú vị, sẽ trở thành ký ức đáng giá. Niềm vui không nằm ở kết quả cuối cùng, mà chính trong quá trình trải nghiệm đó. Và dẫu sản phẩm ra đời có tệ đến đâu, bạn ít nhất vẫn có một người dùng trung thành – chính bản thân mình.