KĨ NĂNG LẤY YÊU CẦU CỦA NGƯỜI DÙNG/KHÁCH HÀNG (copy)

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.