Khi tôi ở Trung Quốc năm ngoài, nhiều người quản lí nói với tôi là những “sai lầm” họ đã mắc phải.. Một người quản lí nói với tôi: “Tôi nghĩ CMMI sẽ giúp cải tiến cách những người phát triển làm việc nhưng không ai bảo tôi rằng điều đó cũng buộc cấp quản lí phải thay đổi cách chúng tôi quản lí dự án nữa.” Tôi ngạc nhiên: “Tất nhiên rồi, mô hình này được thiết kế phần nhiều cho người quản lí chứ không chỉ cho người phát triển. Nó yêu cầu người quản lí phải quyết tâm cải tiến cách phần mềm được phát triển.” Người quản lí này lắc đầu và giải thích: “Nó yêu cầu người phát triển thu thập dữ liệu, thực hiện các độ đo và cách đo rồi báo cáo cho cấp quản lí chứ. Nó cũng yêu cầu cấp quản lí có hành động sửa chữa về dự án dựa trên những dữ liệu này.” Tôi đồng ý: “Điều đó là đúng, người quản lí phải hành động dựa trên những dữ liệu đó.” Ông ấy nhìn tôi vì tôi không biết ý định của ông ấy: “Trong trường hợp đó, người quản lí phải làm cái gì đó về điều đó.”
Đột nhiên tôi hiểu ra. Dễ dàng bảo người khác thay đổi chừng nào bạn không phải làm cái gì cả. Nhưng không dễ thay đổi bản thân bạn. Bằng việc dùng mô hình như CMMI, nó làm cho mọi người đều phải thay đổi để làm cho chất lượng xảy ra, kể cả cấp quản lí. Về sau, tôi thấy ra rằng trong một số công ti, những người quản lí thích ra lệnh nhưng không muốn hành động. Bằng việc có cách đo và dữ liệu, nó buộc họ phải hành động và một số người không thích điều đó. Nếu dự án trượt lịch thì họ phải làm điều gì đó về việc đó. Trong quá khứ, một số người bỏ qua điều đó và để cho tình huống trở nên tồi tệ rồi họ cắt bỏ dự án thay vì sửa nó. Bằng việc có dữ liệu sớm hơn, điều đó cho người quản lí khả năng lấy hành động sửa chữa khi vấn đề được phát hiện đầu tiên nhưng trong một số tình huống, điều đó có thể không phải là điều người quản lí muốn biết.
Tôi nhắc họ rằng họ không thể vẫn làm theo cùng điều họ bao giờ cũng làm và mong đợi kết quả khác đi. Chất lượng không phải là cái gì đó xảy ra một cách tự nhiên vì nó yêu cầu nhiều công việc. CMMI là mô hình cho cải tiến phát triển phần mềm. Người phát triển phải thay đổi cách xây dựng phần mềm. Người quản lí phải thay đổi cách họ quản lí dự án. Người dùng phải thay đổi cách họ yêu cầu dự án làm điều họ muốn và khi nào họ muốn nó được làm. Họ không thể tạo ra yêu cầu không cần thiết vào phút chót. Nếu những hành vi này không thay đổi, chẳng cái gì sẽ xảy ra.
Người quản lí khác bảo tôi: “CMMI yêu cầu quá nhiều qui trình phải làm tài liệu. Nó buộc chúng tôi phải làm tài liệu cho chúng.” Tôi bảo ông ấy: “CMMI không yêu cầu cái gì cả, nó chỉ bản hướng dẫn. Nó nói cho ông về ông cần phải làm “cái gì” nhưng không nói “làm sao” làm nó. Bằng việc có qui trình tài liệu, nó giúp cho mọi người biết phải làm gì cho nên họ không bỏ qua những điều quan trọng. Nếu ông hội tụ vào “làm sao” thì ông làm tài liệu quá nhiều.” Ông ấy lắc đầu: “Chúng tôi không có thời gian làm tài liệu, chúng tôi bận lắm nên chúng tôi mua mọi tài liệu từ nhà tư vấn. Trong trường hợp đó, chúng tôi có đủ mọi tài liệu chúng tôi cần.”
Suốt thời gian của tôi ở Trung Quốc, tôi đã thấy việc mua tài liệu CMMI trong nhiều công ti. Điều người quản lí cần biết là các qui trình là cấu trúc cơ sở của công ti. Đó là cách công ti làm kinh doanh. Đó là cách công ti xây dựng phần mềm. Vì mọi công ti đều có cách khác nhau để làm mọi sự. Không công ti nào là giống nhau cho nên các qui trình nên phản ánh sự khác biệt hay cách thức mọi sự được tiến hành trong một công ti đặc thù. Không ai có thể dùng cùng một qui trình cho người khác ở chỗ khác. Chúng không khớp và không thể dùng được. Nếu qui trình được làm tài liệu mà họ mua từ ai đó không giống hệt như cách họ làm kinh doanh, nếu nó không là cùng cách người phát triển của họ xây dựng phần mềm, nếu nó không là cùng cách người quản lí quản lí dự án thì câu hỏi của tôi là “Những tài liệu kia tốt gì?” Khi tôi hỏi, người quản lí đơn giản trả lời: “Chúng tôi phải có tài liệu để qua được việc đánh giá CMMI.”
Người quản lí dường như tò mò: “Tại sao CMMI yêu cầu tài liệu?” Tôi giải thích: “Trước khi bất kì cải tiến nào có thể xảy ra, mọi người trong công ti của ông làm mọi thứ theo cách nào đó nhưng họ không viết chúng ra. Nó gần như chỉ trong đầu họ cho nên mọi người làm mọi sự một cách khác biệt và đó là lí do tại sao chất lượng của ông là không tốt lắm. Bước thứ nhất là yêu cầu họ viết nó ra. Tất nhiên cách thức họ làm có thể không hoàn hảo. Bằng việc kiểm điểm điều đã được thực hiện trong tài liệu, ông thấy một số lỗi và sửa chúng. Ông viết ra qui trình mới và yêu cầu họ dùng để xem liệu nó có tốt hơn không. Nếu nó là tốt thì ông muốn mọi người tuân theo nó. Đó là “cải tiến liên tục”. Người quản lí mỉm cười: “Nhưng điều đó gian nan và mất thời gian. Mua qui trình đã được làm tài liệu dễ hơn nhiều và nó giúp chúng tôi đạt tới CMMI mức 3 vì chúng tôi có mọi thứ được làm tài liệu.”
Many companies are eager to use the Capability Maturity Model Integration (CMMI) but managers do not know what will happen when their workers are starting to make improvement happens. When I was in China last year, several managers told me about the “mistakes” that they have made.
One manager told me: “I think the CMMI will help improving the way developers work but nobody told me that it also forces management to change the way we manages projects too”. I was surprised: “Of course, the model is designed more for managers than for developers. It requires that managers to commit to improve the way software is developed.” The manager shook his head and explained: “It requires developers to collect data, implement metrics and measurements then report to management. It also requires management to make corrective actions about the project based on these data.”. I agreed: “That is correct, managers must act on those data.”. He looked at me as I did not know his intention: “In that case, managers have to do something about it”. Suddenly I understood. It is easy to tell others to change as long as you do not have to do anything. But it is not easy to change yourself. By using an model like the CMMI, it makes everybody have to change to make quality happens, including management. Later, I found out that in some companies, managers like to give order but do not want to act. By having measurements and data, it forces them to act and some do not like it. If the project slips schedule than they have to do something about it. In the past, some ignored it and let the situation became worst then they just cancel the project rather than fix it. By having data earlier, it give managers the ability to take corrective action when the problem is first detected but in some situations, that maybe not what managers want to know.
I reminded them that they cannot still doing the same thing that they always do and expect different results. Quality is not something happens naturally as it requires a lot of works. The CMMI is a model for improving software development. Developers must change the way the build software. Manager must change the way they manage project. Users must change the way they ask project to do what they want and when they want it done. They cannot create unnecessary requests at the last minute. If these behaviors do not change, nothing will happen.
Another manager told me: “The CMMI requires too many documented processes. It forces us to document them.” I told him: “The CMMI does not require anything, it is only a guideline. It tells you “What” you need to do but not “How” to do it. By having a document process, it helps people to know what to do so they do not skip important things. If you focus on the “How” then you document too much.” He shook his head: “We do not have time to document, we are so busy so we just buy all documents from a consultant. In that case, we have all the document that we need.”
Throughout my time in China, I have seen the purchasing of CMMI documents in many companies. What managers need to know is processes is a basic structure of a company. That is the way company does business. That is the way company build software. Since every company has different way of do thing. No company is the same so processes should reflect the difference or the way things are conducted in particular company. No one can use the same process from another the place. They do not fit and cannot be used. If the documented process that they purchase from somebody is not the same way they do business. If it is not the same way their developers build software. If it is not the same way managers manage project then my question is “What good are those document?”. When I asked, a manager simply answered: “We must have documents to pass the CMMI appraisal.”
A manager seemed curious: “Why does the CMMI require documentation?” I explained: “Before any improvement can happen, people in your company do things in certain way but they do not put it in writing. It is mostly in their head so everybody do things differently and that is why your quality is not very good. The first step is ask them to write it down. Of course the way they do may not be perfect. By reviewing what has been done in a document, you can find out some errors and correct them. You rewrite the new process and ask them to use to see if it is better. If it is good then you want everyone to follow it. That is “Continuous improvement”. The manager smiled: “But it is hard and take time. Buying a documented process is much easier and it help us to achieve CMMI level 3 since we have everything documented.”
