Gửi tâm sự cho trang tin, tôi bỗng hiểu vì sao coder ghét quy trình, và điều đó thực sự không nên

Cách đây ít lâu, tôi có gửi tới người bạn, biên tập viên (BTV) của trang tin tức rất nổi tiếng để dãi bày một chút tâm sự về tình yêu âm nhạc tuổi trẻ của mình. May mắn là bài viết được lựa chọn để đăng, nhưng bạn tôi cũng góp ý rằng chẳng có ai muốn đọc một bài viết chỉ có mỗi chữ dài dằng dặc mà không có minh họa đẹp mắt. Theo yêu cầu của bạn BTV, tôi gửi thêm các ý tưởng hình ảnh để đội ngũ designer của báo thực hiện nhằm tạo ra một "thành phẩm" cuối – bài viết cho bạn đọc – hấp dẫn cả về nội dung lẫn trình bày.

Và thế là tôi lại note ý tưởng hình ảnh của mình vào bài viết cũ và gửi cho người bạn này kia để cậu ta gửi sang bên design. Xong xuôi, tôi ngồi yên chờ đợi bài mẫu lên trang.

Khâu phối hợp không đảm bảo nhất quán của chúng tôi.

Nhưng đến khi bài viết đó đến tay tôi thì mọi thứ lại không như mong muốn. Gần như toàn bộ các ý tưởng hình ảnh của tôi bị loại bỏ và thay thế là các bức hình và caption do chính designer lựa chọn. Trong khi bài viết cuối vẫn được đón nhận rất tốt bởi bạn bè của chúng tôi, tôi vẫn cảm thấy không vừa lòng.

"Mày ơi, sao idea của tao designer không dùng tí nào thế?"

"Để tao nhắn design nick face của mày, tự trao đổi nhé".

Và đây là câu trả lời tôi nhận được từ bạn designer:

"Ơ nhưng anh H gửi em file Word làm gì có note này của anh, chỉ bảo em lên ảnh cho bài thôi mà?"

Quy trình đảm bảo chất lượng

Khi mọi thứ trở nên rõ ràng, công việc nào cũng đơn giản.

Vấn đề chúng tôi gặp phải là như thế này: bạn của tôi đã gửi nhầm bài viết chỉ có text mà không có ý tưởng hình ảnh bên trong. Ghi chú của bạn không rõ ràng, quá trình liên lạc giữa ba phía (tôi, bạn tôi và designer) cũng còn tồn tại nhiều bất cập dẫn đến tình trạng không nhất quán.

Một vấn đề như vậy có thể giải quyết một cách rất đơn giản bằng một quy trình được quy định rõ ràng: khi gửi file bài viết thì phải có ý tưởng hình ảnh thì mới được BTV thông qua. BTV thông qua thì mới được gửi đến bên designer. Công việc của designer phải được quy định rõ ràng là thiết kế ảnh dựa trên ý của người viết. Trong quá trình designer thực hiện công việc phải đảm bảo có sự theo dõi và góp ý của người viết và BTV.

Nhưng điều đáng nói ở đây là ở chỗ khi sinh ra một quy trình như vậy thì phải có một người đứng ra kiểm tra rằng tất cả mọi người đã làm đúng quy trình. Nếu tôi chưa viết ý tưởng hình ảnh mà đã gửi phần text đi thì người này sẽ quở trách tôi. Tôi sẽ cảm thấy khó chịu.

Thực lòng mà nói, không phải cứ thiếu quy trình hay QA là hỏng việc.

Đáng nói hơn nữa là việc làm theo đúng quy trình có thể sẽ không hề giúp cải thiện chất lượng của sản phẩm cuối. Nếu tôi viết tốt, bạn design biết tạo ra ảnh đẹp thì bài báo vẫn sẽ được độc giả khen ngợi. Tôi thấy sự khó chịu của tôi là hợp lý.

Bản chất của quy trình

Như bạn có thể thấy trong tình huống của tôi, một quy trình không hề có ý nghĩa trực tiếp tới chất lượng của sản phẩm. Một lần nữa, tốt vẫn là tốt, đẹp vẫn là đẹp. Nhưng nếu như chúng tôi một quy trình rành mạch, rõ ràng, những rủi ro như việc design cứ "tằng tằng" vẽ bằng ý tưởng của riêng mình thay vì bằng ý tưởng của tác giả sẽ trở thành hiện thực. Chất lượng của sản phẩm cuối ở đây có thể bị ảnh hưởng khi độc giả nhận được một bài viết có các bức ảnh không nhất quán 100% nội dung với bài viết.

Ý nghĩa của quy trình với nghề coder (hay bất cứ lĩnh vực nào khác của nghề phần mềm) cũng vậy. Việc tạo ra một quy trình rành mạch không hề có ý nghĩa trực tiếp đến việc bạn code có "thối" hay không. Nhưng một quy trình có code review sẽ loại bỏ được phần lớn rủi ro bạn gửi code "thối" đến khách hàng.

Có thể nói QA như cái phanh: Không giúp cho động cơ khỏe hơn, có làm cho chiếc xe chậm hơn và quan trọng nhất, dùng để tránh rủi ro.

Tương tự, một quy trình rành mạch sẽ giúp những người làm phần mềm tránh được những rủi ro như: làm việc thừa (vô nghĩa), viết test case bằng requirement cũ, thiếu tài liệu tham chiếu vì để mặc thành viên lưu trữ bằng... não, sử dụng các tiêu chuẩn lỗi thời hoặc không phù hợp, code/test theo kiểu "mỗi người hiểu một ý" v...v... Bản chất những rủi ro này vẫn có thể không ảnh hưởng trực tiếp đến chất lượng code ngay tại thời điểm hiện tại, nhưng một khi chúng trở thành hiện thực, công việc của bạn có thể trở nên khó khăn hơn rất nhiều. Bạn sẽ mất thêm nhiều thời gian, mất thêm công sức và tệ nhất là ảnh hưởng đến chất lượng của sản phẩm về lâu về dài.

Chính bởi vậy nên tôi mới nói, bạn nói "QA không giúp tăng chất lượng sản phẩm" cũng có phần đúng. Trong một thế giới hoàn hảo, nơi bạn hoàn thiện công việc của mình một cách bài bản, nơi cả dự án là một guồng máy trơn tru, công việc QA sẽ là vô nghĩa. Nhưng bạn sai ở chỗ, thế giới của chúng ta không bài bản, và thế là các quy trình sinh ra, các QA đi "gõ đầu" coder để đảm bảo những rủi ro rình rập sẽ không biến thành hiện thực.