Từ chuyện giận dỗi của các bạn gái cho đến vấn đề rất lớn của nghề phần mềm

Tôi nói "Bây giờ người ta muốn xa mà em muốn giữ bạn thì phải chịu khó thôi. Thỉnh thoảng chủ động gọi cho nó hỏi han xem thế nào".

Một lúc sau, tự nhiên gấu nhớ ra rồi nói: "Nhưng hai lần đấy, một lần nó gọi điện cho em lúc buổi sáng ở công ty, gần đến giờ họp đến nơi rồi. Một lần thì em đang ngồi nói chuyện với mẹ anh, sao mà buôn được".

Đây chỉ là một câu chuyện khá đời thường mà tôi có dịp trải qua. Nhưng đằng sau câu chuyện "phức tạp" này lại là một vấn đề tôi gặp rất nhiều trong công việc hàng ngày dưới vai trò là một kỹ sư phần mềm: rất, rất thường xuyên chúng ta chưa nhận định đúng vấn đề mà đã vội vã đưa ra giải pháp. Cứ cho là gấu tôi làm lành được với bạn, lần sau lại gọi điện tâm sự vào những lúc không thích hợp – liệu có lại giận dỗi nhau nữa không?

Nhận diện vấn đề

Một chuyện khác: tại đất nước Singapore, gọi taxi vào những ngày mưa cũng khó khăn không kém gì ở nước ta. Nhiều người sẽ nghĩ ngay đến nguyên nhân là vì trời mưa nên ai cũng muốn đi taxi dẫn tới tình trạng cung không đuổi kịp cầu. Nếu có thể làm cách nào đó để tăng lượng taxi đón khách trong những ngày mưa, chắc hẳn cả hành khách lẫn các hãng xe đều hài lòng?

Sai hoàn toàn! Nghiên cứu dữ liệu GPS cho thấy mỗi khi trời mưa, gần như toàn bộ taxi của Singapore sẽ tìm chỗ trú vì sợ tầm nhìn giảm sút gây tai nạn. Giải pháp thực sự cần áp dụng (nếu có thể) không phải là tăng lượng xe lưu thông mà là tăng mức bảo hiểm hoặc cải thiện hạ tầng để tăng tầm nhìn trong những cơn mưa rào nhiệt đới tại đất nước này.

Lịch sử công nghệ có rất nhiều câu chuyện tương tự, nhưng điển hình nhất, khó quên nhất có lẽ là cuộc lật đổ của iPhone. Trong hàng năm trời, BlackBerry luôn tự hào nhờ khả năng tiết kiệm tối đa dữ liệu truyền tải nhằm tiết kiệm băng thông cho người dùng. Còn Nokia thì lại luôn tập trung phát triển điện thoại bền bỉ, pin "trâu".

Nhưng vấn đề mà các nhà sản xuất cần phải giải quyết không phải là tiết kiệm băng thông hay thời lượng pin mà là đảm bảo trải nghiệm cho người dùng. Khi iPhone ra mắt với trình duyệt đầy đủ, chiếc điện thoại của Steve Jobs liên tục khiến cho đường mạng của AT&T (công ty độc quyền iPhone trong nhiều năm đầu) gặp trục trặc. So với Nokia, pin của iPhone thực sự là thảm họa. Thế nhưng, tương lai đã được xác định: các bản sao iPhone ra đời dần dần để thay thế BlackBerry và Nokia.

"Giải pháp" phần mềm

Trong ngành phần mềm của chúng ta, trường hợp "chưa biết vấn đề là gì đã có giải pháp" cũng không hề ít. Bạn đã bao giờ "nghi oan" cho một vòng lặp "vô tội" khi chương trình gặp hiện tượng tràn bộ nhớ, trong khi lỗi thực sự là vì SQL? Bạn đã bao giờ gặp những coder hoặc CM không hiểu vì lý do gì chưa đọc kỹ log đã kết luận (sai) error và exception? Tôi tin rằng trong vài ba năm đầu, ai cũng sẽ mắc những sai lầm dạng này ít nhất một vài lần.

Câu chuyện "chưa biết vấn đề đã có giải pháp" đôi khi sẽ xảy ra ở phạm vi rộng hơn: không chỉ là một hàm, một module mà là cả một hệ thống. Khi mới startup công ty dịch vụ phần mềm, bạn tôi từng nhận được hợp đồng tăng cường mức độ "tự động" và "hiệu quả" cho hệ thống quản lý đơn từ của một công ty. Sau khi phân tích rất kỹ, bên bạn đưa ra kết luận rằng hệ thống cũ thực chất đã hiệu quả ở mức tối đa – do các yêu cầu nghiệp vụ riêng, hệ thống này không thể gia tăng mức độ tự động hóa.

Nhiều người sẽ nói với bạn rằng kỹ năng quan trọng số 1 của coder là... đọc log.

Với lời khuyên từ phía bạn là gia tăng người và cải tiến chu trình offline thay vì cải tiến hệ thống, khách hàng làm theo và nhanh chóng đạt được hiệu quả mong muốn. Nhờ lời khuyên rất "có tâm" này, bạn tôi sau đó cũng đã xây dựng được mối quan hệ tốt đẹp với khách hàng, mở đường cho các dự án sau. Sau này, bạn thường nói với tôi rằng "Cũng may mà không mời chúng nó đập hết đi làm lại. Con hệ thống đấy cũng phức tạp, mà ban đầu tao vẫn thiếu người cứng".

Quá yêu kỹ thuật

Với riêng giới coder, chuyện "không nhận diện đúng vấn đề" thường mang màu sắc khác: đặt kỹ thuật lên trên nhu cầu thực tế. Bản thân tôi đã từng trải qua trường hợp này: chúng tôi cần áp dụng tính năng bảo mật hai lớp (2FY) cho trang web của công ty. Tôi nghĩ ngay đến chuyện tìm thư viện, tự code ra tính năng khá mới mẻ và thú vị này. Sếp (Tây) nghe thấy thế, nhăn mày rồi nói "Lương của công ty trả cho bọn mày quá nhiều, đừng phí thời gian vào những thứ người khác đã làm rồi. Dùng hàng Google đi".

Rõ ràng là tôi đã sai. Vấn đề mà tôi cần giải quyết là làm thế nào để trang bị 2FY cho trang web một cách kinh tế nhất chứ không phải là làm thế nào để tự mình tạo ra 2FY cho trang web. Hiểu sai vấn đề, tôi đã nhảy tới một giải pháp không vừa lòng sếp.

Yêu code là tốt, nhưng bạn cần hiểu code (và hệ thống IT) chỉ là MỘT PHẦN trong hệ thống doanh nghiệp cũng như các giải pháp kinh doanh.

Cũng tại công ty này, tôi từng có một bạn đồng nghiệp rất cá tính và cũng rất cuồng công nghệ. Cách đây khoảng 3, 4 năm, khi Perl đang là ngôn ngữ "hot" nhất thế giới, cậu ta dành rất nhiều thời gian để code các tính năng hệ thống bằng Perl thay vì sử dụng Java như nhiều developer trong công ty. Kết quả là trong phần lớn trường hợp, cậu ta mất 2 ngày để tạo ra những tính năng Java có thể làm trong 2 giờ.

Khi cậu dev này rời công ty, chẳng mấy ai cảm thấy tiếc nuối cả. Sếp nói "Nó rất thông minh, nhưng mà...".

Bạn ạ, cả tôi, cả những người "sếp" hay các bậc đàn anh đi trước chúng ta đều sẽ có rất nhiều câu chuyện dở khóc dở cười về các tình huống "chưa nhận diện vấn đề đã đưa ra giải pháp" trong nghề phần mềm. Nhưng có lẽ đọc đến đây, tôi tin rằng bạn đã hiểu thông điệp tôi muốn nói: trong mọi tình huống, hãy tạm dựng năm phút, một giờ, một ngày để đánh giá liệu mình đã tìm ra cội nguồn của bài toán cần giải quyết? Chưa nhận diện vấn đề mà đã vội vàng đưa ra giải pháp, bạn có thể sẽ tạo ra thêm nhiều vấn đề mới hoặc chí ít là phí phạm thời gian, tiền bạc của mình và những người liên quan.

Lời khuyên này áp dụng cả vào cuộc sống và tình cảm. Bạn thân mến, hãy thử "tư vấn" cho tôi biết: ở vị trí của "gấu" tôi, bạn sẽ giải quyết như thế nào nếu bị gọi điện tâm sự tình cảm trong giờ làm?