PHÂN BIỆT: Doing things right vs doing the right things (Chọn đúng việc để làm và làm đúng việc cần)

Bạn đã từng làm 1 dự án thất bại chưa?

Theo bạn một dự án phầm mềm thế nào được gọi là thất bại?

Sản phẩm làm ra không đúng requirement của khách hàng! (Quality)
Sản phầm làm ra không đúng deadline của khách hàng! (Time)
Sản phẩm làm ra vượt quá chi phí ban đầu! (Cost)

Cả 3 lý do trên đều đúng.

Tuy nhiên lần này tôi muốn chia sẻ về 1 dự án làm đúng requirement của khách hàng, release đúng hạn, chi phí trong hạn mức cho phép. Nhưng nó vẫn bị đánh giá là thất bại!

Vậy dự án đó đã làm sai điều gì?

Tìm hiểu thêm: Effective khác với Efficient như thế nào?

Và tôi đã phần nào lý giải được qua 2 khái niệm Doing things right (chọn đúng hướng, chọn đúng việc để làm) & Doing the right things (làm việc đúng, làm chuẩn chỉ, xây đúng cái mong muốn ban đầu).

1. Doing things right (Chọn đúng hướng, chọn đúng việc để làm)

Làm việc đúng tức là làm việc chu đáo đến từng chi tiết, thậm chí là những tiểu tiết và bảo đảm tuân thủ chặt chẽ mọi quy trình, mọi thủ tục mà công việc đó quy định.

Lấy một ví dụ vui như sau. Có công ty nọ được mướn mở một con đường băng qua một cánh rừng già. Họ chuẩn bị hết sức chu đáo từ rất sớm, muốn chắc chắn mọi máy móc, dụng cụ đều phải thật tốt và thậm chí còn cắt cử cả các chuyên gia đi cùng đội làm đường hòng lúc nào máy móc, thiết bị, dụng cụ... cũng trơn tru, sắc bén hết. Lại còn có cả những đầu bếp và chuyên gia dinh dưỡng phục vụ nữa chứ, họ muốn không có ai trong đoàn bị mất sức vì phải ăn kham ăn khổ hết. Họ thuê các nhà toán học tính giùm xem mỗi ngày có thể làm được bao nhiêu công việc để dự toán cho chính xác cái ngày hoàn thành. Họ đang tiến hành mọi việc rất đúng.

Thế rồi vào một ngày đẹp trời kia có người trèo lên cây, phóng mắt nhìn ra bốn phương tám hướng mà thốt lên: NHẦM RỪNG mất rồi!

lost in the forest

2. Doing the right things (Làm chuẩn chỉ, xây đúng cái mong muốn ban đầu)

Làm chuẩn chỉ, hay làm đúng việc, tức là lựa chọn một công việc đúng đắn để thực hiện nó. Dùng khả năng của mình để nghĩ xem cách tốt nhất có thể hoàn thành công việc là gì. Làm thế nào để công việc ấy thực sự có hiệu quả. Sau đó mới bắt tay vào làm.
Khi làm xong, cũng bớt thời gian suy nghĩ xem làm thế nào để lần sau ngay từ đầu đã có quyết định sáng suốt khi phải lựa chọn đúng việc cần làm.
Đó chính là phải có cái nhìn tổng thể, hay BỨC TRANH TOÀN CỤC. Xác định xem để thành công thì điều gì quan trọng hơn, hoàn thiện các kỹ thuật của riêng mình hay tập trung vào các hạng mục trong kế hoạch công việc chung để có thể chắc chắn là mình đang ở ĐÚNG KHU RỪNG (không như cái công ty NHẦM RỪNG trong câu chuyện trên).

Đến đây thì phần nào đã có thể trở lại câu hỏi đầu bài rồi ạ.

Câu trả lời là dự án đó tuy đã làm rất tốt doing things right (Chọn đúng hướng) nhưng lại thiếu doing the right things (Làm chuẩn chỉ).

Họ đã bỏ ra toàn bộ thời gian để ngâm cứu spec, làm theo từng đầu mục của spec đến từng chi tiết một, hoàn toàn tin rằng kỹ lưỡng như thế này thì kiểu gì những cố gắng của họ sẽ được đền đáp. Chính vì chỉ tập trung làm theo đúng design khách hàng đưa ra mà thiếu quan điểm làm ra một sản phẩm có thể sử dụng được trong thực tế. Nên mặc dù dự án đó hoàn thiện nhưng lại không thể dùng được.

3. Vậy trong dự án, một QA - chốt cuối cùng đảm bảo chất lượng cho sản phẩm, cần phải có nhận thức như thế nào?

Các công cụ hỗ trợ bạn nâng cao chất lượng tổng thể (total quality)

Nếu QA trong dự án chỉ biết tiến hành kiểm tra chất lượng cho sản phẩm làm ra đúng với yêu cầu mà khách hàng mong muốn. Với mỗi một sai khác của chức năng dù lớn hay nhỏ đều so với spec để bắt bug. Nếu mục đích cuối cùng chỉ là tìm bug thì hoàn toàn chỉ là doing things right (Chọn đúng hướng, chọn đúng việc).

QA muốn doing the right things (Làm đúng việc, làm chuẩn chỉ) thì để test có hiệu quả không phải là tập trung chạy cho hết testcase hay checklist. Hoặc so sánh từng dòng trong spec mô tả của khách hàng với chương trình để bắt bug. Mà cần phải hiểu được spec của khách hàng, tư duy phải mạch lạc, xem xét được tối đa các trường hợp có thể xảy ra dưới quan điểm của một người dùng thật sự.
Đồng thời cũng cần mạnh dạn trao đổi suy nghĩ của bản thân về những trường hợp từ spec được phán đoán là chưa hợp lý hoặc không thân thiện với người dùng.
Tích cực Q&A với phía khách hàng. Spec càng không rõ ràng thì càng cần Q&A nhiều. Đến khi nào không còn "concern" nữa thì thôi.
Ngoài ra còn một yếu tố cũng khá quan trọng. Đó là sự tin tưởng vào ý kiến của bản thân mình. Khi nhận định vấn đề theo mình là hợp lý và nên sửa đổi theo hướng đó thì cần đưa ra được các quan điểm, dẫn chứng chứng minh và bảo vệ quan điểm ấy. Trên tinh thần học hỏi và sẵn sàng nhận đóng góp ý kiến. Mục đích cuối cùng nhằm đưa ra một sản phẩm ngoài đúng yêu cầu còn thân thiện với người dùng và dễ sử dụng.