Có niềm tin chung trong những người phát triển phần mềm rằng họ phải viết mã sớm nhất có thể được vì không có đủ thời gian cho các hoạt động khác. Đó là lí do tại sao nhiều người bắt đầu viết mã ngay khi họ nhận được đặc tả yêu cầu mà không dành thời gian để hiểu nhu cầu của khách hàng. Không ai hỏi khách hàng về mong đợi của họ hay nhu cầu của họ. Phần lớn những người phát triển đều bỏ qua pha kiến trúc; dành ít thời gian trong thiết kế, chỉ vẽ vài biểu đồ như biểu đồ luồng dữ liệu rồi nhảy vào viết mã. Nếu họ không hiểu cái gì đó, họ sẽ đoán cái gì được cần và vội vàng làm cho dự án được thực hiện để đáp ứng lịch biểu.

Kết quả thường là sản phẩm phần mềm không làm việc như mong đợi và họ phải làm lại để có được điều khách hàng muốn. Tình huống này làm tốn kém cho công ti về thời gian, nỗ lực và nhiều tiền. Ngày nay ít đại học dạy môn yêu cầu, và cho dù họ dạy, ít người phát triển sẽ theo nó. Lí do trong những người phát triển là nói chuyện với khách hàng mất thời gian và họ không có thời gian. Một người phát triển bảo tôi: “Khó mà hiểu được khách hàng muốn gì vì họ đổi ý thường xuyên.” Một người quản lí dự án giải thích: “Chúng tôi không thể nói chuyện được với khách hàng; họ sẽ đòi nhiều thứ hơn và làm phí thời gian của chúng tôi.” Khi tôi hỏi: “Điều gì xảy ra nếu đặc tả yêu cầu không rõ ràng? Làm sao bạn biết phải làm gì nếu bạn không muốn hỏi?” Câu trả lời thông thường là: “Chúng tôi đoán họ muốn gì. Nếu chúng tôi giỏi đoán, chúng tôi sẽ ổn nhưng nếu không thì chúng tôi phải sửa nó về sau.”

Tất nhiên, phần lớn thời gian họ sẽ tạo ra cái gì đó mà khách hàng không muốn và điều đó nghĩa là nhiều việc làm lại hơn, tốn kém hơn cho công ti. Tôi có thể hiểu tại sao những người phát triển ngần ngại nói chuyện với khách hàng; phần lớn không được đào tạo và không biết hỏi cái gì cho nên họ nghĩ khách hàng sẽ hỏi nhiều hơn và không bao giờ được thoả mãn. Nhưng tôi không thể hiểu được tại sao người quản lí không nói chuyện với khách hàng nếu dự án tiếp tục có tỉ lệ phải làm lại cao? Chừng nào chúng ta chưa thiết lập được đối thoại tốt giữa người phát triển và khách hàng, việc phát triển phần mềm chỉ là công việc đoán mò và dự án tốn kém.

Có nhu cầu khẩn thiết để dạy môn kĩ nghệ yêu cầu trong chương trình đại học để cho sinh viên có thể học cách thảo luận yêu cầu với khách hàng, xác định nhu cầu của họ, lập ưu tiên và giảm vấn đề làm lại. Sinh viên nên học việc đưa ra tăng dần mỗi lần thêm chức chức năng qua thời gian. Sinh viên nên học nói chuyện với khách hàng bằng cách hỏi câu hỏi về chức năng và cách khách hàng sẽ dùng sản phẩm của họ. Một khi người phát triển bắt đầu nói với khách hàng, họ sẽ học được nhiều điều về cách khách hàng làm công việc của họ và điều họ thực sự cần. Khách hàng có thể giúp đỡ giải thích và làm sáng tỏ chức năng được viết trong đặc tả v.v. Khi cả hai bên tham gia vào thảo luận về phải mất bao lâu để phát triển dự án, họ có thể trao đổi ý tưởng, phát triển các giải pháp tốt hơn và đồng ý về lịch biểu tốt hơn cho dự án.

—-English version—-

Talking with customers

There is a common belief among software developers that they must code as soon as possible since there is not enough time for other activities. That is why many start to write code as soon as they receive the requirements specification without spending time to understand the customers’ needs. No one would ask customers about their expectation or their needs. Most developers ignore the architecture phase; spend little time in design, just to draw some diagrams such as data flow diagram than jump into coding. If they do not understand something, they would guess on what is needed and hurry to get the project done to meet the schedule.

The result is often a software product that does not work as expect and they have to re-work to get what customers’ wants. This situation costs the company time, efforts and a lot of money. Today few colleges teach requirements engineering course, and even if they do, few developers would follow it. The reason among developers is talking with customers takes time and they do not have time. One developer told me: “It is difficult to understand what customers want as they change their mind often”. A project manager explained: “We cannot talk to customers; they would demand more things and waste our time.” When I asked: “What happen if the requirements specification is not clear? How do you know what to do if you do not want to ask? The common answer is: “We just guess what they want. If we are good at guessing, we will be fine but if not then we have to fix it later.”

Of course, most of the time they will produce something that customers do not want and that means more re-work, more costs to the company. I can understand why developers are reluctant to talk to customers; most are not trained and do not know what to ask so they think customers will ask for more and never be satisfied. But I cannot understand why managers do not talk to customers if the project continues to have high re-work rate? Until we establish a good dialogue between developers and customers, software development is just guesswork and costly projects.

There is an urgent need to teach requirements engineering course in the undergraduate program so students can learn how to discuss requirements with customers, determine their needs, set priorities and reduce the issue of re-work. Students should learn incremental releases that add functionality over time. Students should learn to talk with customers by asking questions about functionality and how customers will use their product. Once developers start talking to customers, they will learn many things about how the customers do their work and what they really need. Customers can help explain and clarify functionality written in the specification etc. When both sides engage in discussion about how long it takes to develop a project, they can exchange ideas, develop better solutions and agree on a better schedule for the project.