KĨ NĂNG LẤY YÊU CẦU CỦA NGƯỜI DÙNG/KHÁCH HÀNG (tham khảo)
nhân
có vài bạn đặt vấn đề kĩ năng mềm của môt IT manager, CIO,... mình muốn
bàn về việc lấy user requirements, mà theo mình nó vận dụng được nhiều
kĩ năng mềm của một người hành nghề CNTT.
<< entry này sẽ dài, bạn nào ngán đọc dài xin bỏ qua cho. >>
dù là một kĩ sư phần mềm, một người thiết kế PM, một người cung ứng
giải pháp PM, một IT manager, hay chí đến một CIO/CTO thì yêu cầu của
người dùng (hay khách hàng) đều là đầu mối để chúng ta làm việc, để đáp
ứng lại bằng một (hệ) giải pháp. người dùng có thể rât khác nhau đối
với các chức năng tạm kể ra bên trên, nhưng làm sao để nắm bắt được các
yêu cầu của những đối tương ấy vẫn là trách nhiệm quan trọng của người
hành nghề CNTT.
trong nhiều hoàn cảnh, một số người làm CNTT ở
VN hiện nay (có thể ở nhiều chức vụ khác nhau) nhận các đặc tả yêu cầu
người dùng (user requirements spec.) hay thâm chí đặc tả các thiết kế
giải pháp từ người khác. khâu thu thập và lập văn bản các yêu cầu người
dùng vì thế được/bị bỏ qua. đó là một thuận lợi ngắn hạn nhưng lại là
một thiệt thòi trong dài hạn đối với người hành nghề CNTT. vì lẽ, việc
thu thập yêu cầu người dùng là một công đoạn khó khăn và đòi hỏi nhiều
bản lĩnh trong toàn bộ chu trình phát triển giải pháp CNTT (và có thể
nói, tương tự cho nhiều ngành nghề khác, nhưng ở đây xin thu hẹp trong
khung CNTT).
**
một trong những phản ứng “tê tái” nhất
mà người nộp kết quả giải pháp phải đón nhận là câu phán: “đây không
phải là giải pháp tôi đang mong đợi, tôi đâu có cần cái này? bạn đã làm
sai ý tôi rồi!”. úi. và trong kinh nghiệm của ngành nghề này, câu phán
đó không phải là điều hiếm khi được nghe.
và hầu như đa phần
các trường hợp dẫn đến kêt quả ấy là do khâu lấy yêu cầu người dùng đã
không được làm tốt. trong kinh nghiệm bản thân hành nghê và kinh nghiệm
làm huấn luyện đào tạo mình có nhận xét: người làm kĩ thuật càng có
nhiều "kinh nghiệm kĩ thuật" lại càng dễ có nguy cơ gặp khó khăn khi lấy
yêu cầu người dùng, nếu bản thân người ấy không nắm vững các phương
pháp để lấy yêu cầu, mà trong đó việc tự "trấn áp" cách nghe, cách hiểu,
cách nói, cách tiếp thu vấn đề "rất i tờ" của mình. vấn đề và các trở
ngại thì nhiều, do đó, sau nhiều năm chiêm nghiệm, người ta đã đưa ra cả
một chuyên ngành về “yêu cầu người dùng”. các bạn quan tâm có thể thử
nhờ bạn Google truy tầm qua chủ đề “user requirements”, hoặc chính xác
hơn, “requirements engineering” để có thể có được những thông tin, tài
liệu liên quan đến chủ đề phức tạp này. nó cũng cho chúng ta thấy mức
độ quan trọng và số vốn trí tuệ và kinh nghiệm hiện được thu thập và hệ
thống hóa chung quanh chủ đề này ra sao.
ở đây, mình chỉ mong
khơi gợi vấn đề, và kêu gọi được sự quan tâm của các bạn đồng nghiệp mới
vào nghề, hoặc chưa có cơ hội đối mặt và quan tâm đủ với các thử thách
của công việc thu thập yêu cầu người dùng. mình cũng chưa nói đến việc
hiểu, phân tích và sau đó là đáp ứng lại với các yêu cầu ấy. hiện nay,
ngành software engineering đã đủ trưởng thành đề hệ thống hóa các qui
trình, và ngay cả các loại tài liệu, artifacts cần được tạo ra trong
suốt các qui trình ấy. ngay cả với các phương pháp agile, một cách này
hay cách khác người ta cũng sẽ phải đề cập đến “user requirements” và
phương pháp thích hợp để ứng phó với v/đ này. << minh không nhằm
đi vào chi tiết của các phương pháp ấy ở đây. các tài liệu, sách vở
giáo khoa liên quan sẽ đầy đủ, khúc chiết và có hệ thông hơn những gì
mình có thể ghi nhanh ở đây.>>
**
một điều mình
cũng thường được nghe (và phần nào trải nghiêm): “lắm khi người khách
hàng cũng không biết họ cần/muốn gì.” ở các xã hội mà việc sử dụng CNTT
càng giới hạn thì câu này càng được nghe nhều hơn. chắc phải có phần
nào sự thật trong ấy.
tuy nhiên, cho phép mình nhận xét vấn đề
này ở một góc khác. thường, câu nhận xét trên "đúng" là do chúng ta
muốn nghe người khách hàng cho ta biết về cái “giải pháp” mà họ nghĩ là
họ cần; và như thế thì họ sẽ bí. đàng khác, người dùng thường phải có
một thứ nhu cầu. một thứ vấn đề, nên họ mới cần nói chuyện với chúng ta.
cho nên, nếu ta cố tìm cách để nghe cái nhu cầu, những trở ngại, khó
khăn ấy (qua tầm nhìn và ngôn ngữ nghiệp vụ của họ) thì cơ hội được nghe
họ nói sẽ nhiều hơn. còn “giải pháp” là thứ rồi đây, qua làm việc (có
khi gian khổ, nhọc nhằn) với họ, và dựa trên tri thức chuyên môn của
người làm CNTT chúng ta hi vọng hình dung ra, thiết kế ra và thực hiện
được giúp họ. bỡi thế, hỏi họ “cần gì” trong ý nghĩa “giải pháp” có thể
họ sẽ không nói (rõ ràng) được, nhờ họ mô tả tình huống khiến họ ới đên
CNTT thì có cơ khá hơn.
<< về phương pháp và công cụ,
sách vở sẽ cho chúng ta nhiều cách hiệu quả để đáp ứng với cái nạn
"người dùng ko biết họ muốn gì". >>
cũng cần nói thêm, sẽ
có những người khách hàng (hoặc người thay mặt cho khách hàng -- thí
dụ: bà con marketing, sales, hay product planning :)) sẵn sàng, hồ hỡi
đưa ra yêu cầu của họ ở dạng giải pháp. đây thường là một điều đau đầu
khác. vì một người dùng / khách hàng có thể sẽ đưa ra một thứ giải pháp
sai, hoặc phiến diện, hoặc không thích hợp với những nhu cầu thật sự mà
họ đang gặp phải (chưa nói các yếu tố công nghệ, hệ thống, v,v,). nếu
người nhận yêu cầu không khéo léo và tinh tế kéo người khách hàng quay
về được chính các "yêu cầu thật" của họ thì mối nguy đôi bên sẽ dắt tay
nhay đi xuống một lộ trình không mấy sáng sủa. giải pháp ở đầu ra có
nguy cơ giải quyết một loại yêu cầu... khác.
các giáo trình,
tài liệu về requirements engineering sẽ chi li hơn, đầy đủ hơn về các
tình huống và các phương áng (cũng như công cụ, phương tiện) để ứng xử
các tình huống ấy, mình xin không bàn thêm. chỉ xin tạm kết: kĩ năng thu
thập yêu cầu của người dùng là một kĩ năng rất quan trọng, nó vận dụng
nhiều loại kĩ năng mềm của người làm CNTT. tìm hiểu, học tập và rèn
luyện các kĩ năng ấy để hoàn thành tốt công đoạn lấy yếu cầu này là một
trong những bước cần quan tâm của một người hành nghề CNTT muốn đi xa.
mình sẵn sàng trao đổi thêm với các bạn quan tâm hay có kinh nghiệm khác hơn.
