Năm ngoái, tôi đã tiến hành một khoá đào tạo cải tiến qui trình ở Bắc Kinh cho vài người chủ công ti phần mềm. Sau đây là tóm tắt về khoá đào tạo đó:

Phần lớn những người phát triển không muốn thay đổi cách họ làm việc. Một khi họ học được cái gì đó, họ bám lấy nó. Nếu họ được đào tạo về lập trình, họ bám lấy lập trình. Đó là lí do tại sao nhiều người phát triển thường bắt đầu bằng viết mã và bỏ qua yêu cầu và thiết kế. Cho dù họ biết về vòng đời phát triển phần mềm nhưng họ vẫn nhảy vào viết mã vì phần lớn họ được dạy suốt ba năm lập trình trong đại học nhưng chỉ vài tháng về vòng đời phát triển. Do đó lập trình trở thành thói quen và kĩ năng của họ.

Phần lớn người quản lí không muốn thay đổi cách họ làm việc. Một khi họ học cái gì đó, họ bám lấy nó. Nếu họ được đào tạo trong quản lí, họ bám lấy quản lí. Đó là lí do tại sao những người quản lí bao giờ cũng thường bắt đầu bằng lịch biểu và bỏ quên qui trình, ước lượng, chất lượng và nỗ lực. Cho dù họ biết về vòng đời phát triển phần mềm nhưng họ vẫn hội tụ vào lịch biểu bởi vì phần lớn họ được dạy trong chương trình MBA rằng đáp ứng lịch biểu là quan trọng. Trường quản lí kinh doanh chỉ dạy về tài chính, tiếp thị nhưng hiếm khi nhắc tới chất lượng. Do đó chuyển giao sản phẩm theo lịch biểu để được trả tiền trở thành thói quen và kĩ năng của họ.

Thay đổi thói quen của những người “viết mã trước, hỏi câu hỏi sau” thành ai đó tuân theo qui trình là rất khó. Thay đổi thói quen của những người ưa thích “đáp ứng lịch biểu trước, hội tụ vào chất lượng khi bạn có thời gian” thành ai đó biết cách lập kế hoạch, cách ước lượng, cách thương lượng, tuân theo qui trình, là rất khó. Đó là lí do tại sao cải tiến phần mềm hiếm khi xảy ra trong công ti phần mềm.

Thách thức lớn nhất cho bất kì cải tiến qui trình nào là vượt qua những thói quen xấu đó. Không chỉ người quản lí phải quyết tâm làm cho cải tiến xảy ra mà họ phải sẵn lòng thay đổi cách nghĩ riêng của họ và học về qui trình cải tiến. Nếu người quản lí không thay đổi trước thì không cái gì sẽ thay đổi. Đây là lí do tại sao nhiều công ti thế đã thất bại vì người quản lí tin người phát triển phải thay đổi nhưng họ không phải làm gì cả. Họ sẵn lòng trả tiền cho nhà tư vấn để dạy cách làm tài liệu cho nhiều qui trình và hi vọng rằng cải tiến sẽ xảy ra vì họ không phải làm gì mấy bên cạnh việc ra lệnh cho người phát triển làm nhiều việc hơn.

Không có cấp quản lì nhìn vào trong và thay đổi cách nhìn của họ, cải tiến sẽ KHÔNG xảy ra. Dễ thấy cách người khác phải thay đổi, không dễ thế để cho bản thân họ thay đổi là vấn đề lớn nhất trong hầu hết các công ti phần mềm. Trong nhiều năm, tôi đã quan sát nhiều nỗ lực cải tiến phần mềm thất bại vì những người quản lí không hiểu việc “tự thay đổi” cơ bản này. Làm sao người phát triển có thể cải tiến được khi toàn thể qui trình phát triển dựa trên “lịch biểu hi vọng” do người quản lí ra lệnh. Làm sao cải tiến có thể xảy ra khi thái độ chung là: “Để cho dự án xong đã, đáp ứng lịch biểu trước rồi làm cải tiến sau.”

Mặc dầu cải tiến phần mềm có thể là quan trọng, nó là không cấp bách, không phải là ưu tiên cao nhất, cho nên nó thường bị bỏ qua. Nhiều lần, công ti chỉ muốn có chứng chỉ mức CMMI. Họ trả tiền cho tư vấn tới, cung cấp các khoá đào tạo, tiến hành đánh giá, rồi cấp cho một mảnh giấy như “Được chứng nhận CMMI mức 3.” Sau đó mọi sự sẽ trở lại bình thường như không cái gì xảy ra. Khi mà người chủ công ti còn tin rằng đó là tất cả mọi điều họ cần thì cải tiến chỉ là “trò chơi tốn tiền” chẳng có kết quả gì.

Cải tiến thực phải tới với kết quả đo được. Nếu chất lượng là quan trọng, kết quả phải được đo theo chất lượng. Nếu lịch biểu là quan trọng thì kết quả phải là ở chỗ mọi dự án phải đáp ứng lịch biểu. Nếu lợi nhuận là quan trọng thì kết quả phải được đo bằng lợi nhuận tốt hơn cho người chủ. Cải tiến là về thay đổi cách toàn thể công ti tiến hành kinh doanh để đạt tới mục đích nào đó mà người chủ  công ti ước ao. Nếu người chủ ước muốn có mảnh giấy chứng nhận rằng công ti được đánh giá ở “CMMI mức 3” thì công ti sẽ nhận được nó sau khi trả nhiều tiền cho “nhà tư vấn vô đạo đức”. Không may, tình huống xấu này đã xảy ra trên khắp thế giới.

Năm ngoái, khi tôi gặp một số người chủ công ti phần mềm, họ bảo tôi rằng họ đã đọc cuốn sách của tôi về cải tiến phần mềm (nhiều sách của tôi đã được dịch sang tiếng Trung Quốc) và đồng ý với cách nhìn của tôi về cải tiến thực. Nhiều người bảo tôi rằng họ đã không trả tiền cho nhà tư vấn để cho họ “chứng chỉ” với hi vọng rằng họ sẽ nhận được nhiều kinh doanh hơn từ Mĩ và châu Âu. Cuối cùng nhiều công ti phương tây đã tới công ti của họ để tìm hiểu cơ hội kinh doanh. Tuy nhiên, tất cả các công ti này đều tiến hành kiểm điểm riêng của mình để thẩm tra “kết quả đã được chứng nhận”. Sau đó họ không bao giờ nghe nói gì về các công ti đó. Về sau, họ tìm ra rằng những công ti này đã quyết định làm kinh doanh với các công ti khác ở nước khác.

Khi những người chủ này thấy rằng tôi đã dạy ở Đại học Thanh Hoa, họ yêu cầu cuộc gặp gỡ với tôi vì tôi là một  trong các tác giả của CMMI. Tôi đồng ý giúp họ bằng việc làm buổi tập huấn tại Thanh Hoa nơi họ phải tuân theo một số chỉ dẫn để học về “cải tiến qui trình thực”.

Đầu tiên tôi yêu cầu họ viết ra viễn kiến về công ti của họ và điều họ muốn đạt tới trong năm tới chục năm tới. Điều này không dễ, nhiều người chủ có ý tưởng nào đó trong đầu nhưng chưa bao giờ thực tế viết chúng ra trên giấy. Tôi giải thích rằng viễn kiến là phát biểu chính xác xác định ra cái gì, tại sao và ai từ quan điểm doanh nghiệp. Nó thiết lập đích và mục tiêu doanh nghiệp có liên quan tới cách công ti vận hành. (Công ti làm kinh doanh gì? Tại sao bạn muốn cải tiến? Ai sẽ chịu trách nhiệm cho công ti? Ai là khách hàng của bạn? Công ti của bạn làm cái gì cho khách hàng? Lí do nào mà khách hàng muốn làm kinh doanh với công ti của bạn? Trạng thái môi trường vận hành sẽ là gì? Làm sao công ti của bạn được phân biệt trong thị trường toàn cầu? Mục đích của công ti là gì? Làm sao bạn đo được mục đích của bạn? V.v.).

Nhiều người ngạc nhiên rằng điều đó chẳng liên quan gì tới CMMI hay bất kì khía cạnh kĩ thuật nào mà họ mong đợi tôi khuyên họ. Tôi bảo họ rằng không có viễn kiến và mục đích rõ ràng, mọi người sẽ bị lẫn lộn và không biết lí do tại sao họ cần cải tiến qui trình. Trong quá khứ, nhiều người phát triển được bảo phải tuân theo chỉ dẫn CMMI nào đó như làm tài liệu qui trình nhưng họ không biết tại sao. Họ đã làm điều họ được bảo và sau khi hoàn thành tài liệu qui trình dài dòng, họ cất nó lên giá để  trưng bày nhưng thói quen của họ không bao giờ thay đổi. Họ tiếp tục bám lấy điều họ biết rõ nhất – viết mã và không cái gì thay đổi trong công ti cho nên cải tiến thất bại.

—-English version—-

Process Improvement part 1

Last year, I conducted a process improvement training in Beijing for several software company owners. Following is a summary of that training:

Most developers do not want to change the way they work. Once they learn something, they stick with it. If they are trained in programming, they stick with programming. That is why many developers often start with coding and ignore requirements and design. Even they know about software development life cycle but still jump to coding because most are taught three years of programming in college but only few months about development life cycle. Therefore programming becomes their habits and skills.

Most managers do not want to change the way they work. Once they learn something, they stick with it. If they are trained in managing, they stick with managing. That is why many managers always often start with schedule and ignore process, estimates, quality, and efforts. Even they know about software development life cycle but still focus on schedule because most are taught in their MBA program that meeting schedule is important. Business Management school only taught financial, marketing but rarely mentioned about quality. Therefore deliver product on schedule to get paid becomes their habits and skills.

Changing the habit of people who prefer “Code first, ask question later” into someone who follow a process is very difficult. Changing the habit of people who prefer “meet schedule first, focus on quality when you have time” into someone who know how to plan, how to estimate, how to negotiate, follow a process, is very difficult. That is why software improvement rarely happens in software companies.

The greatest challenge for any process improvement is overcoming these bad habits. Not only managers must commit to make improvement happens but they must be willing to change their own thinking and learn about improvement process. If managers do not change first then nothing will change. This is why so many companies failed because managers believe developers must change but they do not have to do anything. They are willing to pay consultants to teach developers to document a lot of processes and hope that improvement will happen since they do not have to do much beside order developers to do more works.

Without management looking inward and changing their view, improvement will NOT happen. It is easy to see how others must change, not so easy for themselves to change is the biggest problem in most software companies. For many years, I have observed so many software improvement effort failed because managers do not understand the basic “self change”. How could developers improve when the entire development process relies upon “hopeful schedules” dictated by managers. How could improvement happens when the general attitude is: “Get the project out, meet schedule first then do the improvement later”.

Although software improvement maybe important, it is not urgent, not the highest priority, so it is often neglected. Many times, company only wants to have a CMMI level certificate. They pay consultant to come in, provides training courses, conducts an appraisal, then issues a piece of paper such as “Certified CMMI level 3”. After that everything will return to normal as nothing happen. As long as company owner believes that is all they need then improvement is only an “expensive game” without any results.

Real improvement must come with measureable results. If quality is important, the result must be measured in quality. If schedule is important then the result must be that all projects must meet schedules. If profit is important than the result must be measured by better profits for the owners. Improvement is about changing the way the entire company conduct business to achieve certain goals that the company owner wishes. If the owner wishes to have a piece of paper certifies that the company is appraised at “CMMI level 3” then the company will receive it after paying a lot of money for an “unethical consultant”. Unfortunately, this sad situation happened all over the world.

Last year, when I was in China I met several software company owners. They told me that they have read my book on software improvement (Several of my software books has been translated into Chinese) and agreed with my view about real improvement. Many told me that they did pay consultants to give them “certificates” with the hope that they will receive more businesses from the U.S and Europe. Eventually many western companies did come to their companies to explore business opportunities. However, they all conducted their own reviews to verify the “certificated results”. After that they never heard anything from them. Later, they found out that these companies decided to do business with other companies in another country.

When these owners found out that I was teaching in TsinghuaUniversity, they requested a meeting with me since I was one of the authors of the CMMI. I agreed to help them by giving a workshop at Tsinghua where they have to follow some instructions to learn about “real process improvement”.

First I asked them to write vision about their company and what do they want to achieve in the next five to ten years. This was not easy, many owners had some ideas in mind but never actually write them down on a piece of paper. I explained that the vision is a concise statement that defines the What, Why, and Who from the business point of view. It establishes the business objectives and goals relate to how the company operates. (What business does the company do? Why do you want to improve? Who will be responsible for the company? Who are your customers? What would your company does for the customers? What are the reason customers want to do business with your company? What will be the state of the operational environment? How will your company be distinguished in the global market place? What are the company goals? How do you measure your goals? Etc.).

Many were so surprised that it had nothing to do with the CMMI or any technical aspects that they would expect me to advise them. I told them that without a clear vision and goals, people would be confused and do not know the reason of why they need to improve the process. In the past, many developers were told to follow some CMMI instructions such as document a process but they did not know why. They did what they were told and after completed a lengthy process document, they put it on the shelf for display but their habit never change. They continued to stick to what they knew best – coding and nothing changed in the company so the improvement failed.