26 Jan, 2021
Cải tiến quy trình phần 2
Để cải tiến, công ti phải có viễn kiến rõ ràng để trao đổi với mọi nhân viên về chiều hướng mà người chủ muốn đi.
Không có điều đó, mọi người có thể bị lẫn lộn viễn kiến và có thể quyết định đi vào các hướng khác nhau. Sau khi người chủ đã hoàn chỉnh viễn kiến của họ, tôi yêu cầu họ viết ra mục đích doanh nghiệp của họ. Phần lớn mọi người viết ra về giảm lỗi, tăng lợi nhuận, làm ra nhiều tiền hơn, có nhiều khách hàng hơn, mở rộng doanh nghiệp toàn cầu v.v. Rồi tôi yêu cầu họ về điều sẽ cho phép họ đạt tới những mục đích này. Tất nhiên, câu trả lời điển hình là có sản phẩm và dịch vụ có chất lượng vì chất lượng là điều họ có trong đầu. Câu hỏi tiếp của tôi là họ cần gì để xây dựng sản phẩm chất lượng?
Sau vài thảo luận giữa các nhóm, kết luận cuối cùng là “Tri thức và kĩ năng”. Tôi hỏi họ: “Họ thu nhận những điều này ở đâu? Sinh viên đại học có những kĩ năng này không? Các đại học có dạy về kĩ năng cải tiến không?” Nếu sinh viên tốt nghiệp đã có những kĩ năng này thì tại sao công ti không có sản phẩm có chất lượng và phải cải tiến? Cho nên chúng ta đi xuống lí do chính của thói quen xấu như người phát triển không tuân theo qui trình được xác định. Thói quen xấu của việc bỏ qua các pha và nhảy vào viết mã. Thói quen xấu của người quản lí thiết lập lịch biểu mà không ước lượng v.v. Tôi giải thích cho họ rằng khi dự án không có qui trình mà nó sẽ dùng, người phát triển sẽ làm bất kì cái gì họ muốn. Đến cuối, họ sẽ dành nhiều thời gian vào việc sửa lỗi và không có thời gian để cải tiến phần mềm. Khi dự án dường như trượt lịch, mọi người đều hoảng hốt. Người phát triển sẽ hội tụ vào công việc cá nhân của riêng mình để chắc rằng nếu cái gì đó xảy ra, đó không phải là lỗi của họ. Khi các thành viên tổ không làm việc cùng nhau và rút lui khỏi tương tác với nhau, việc điều phối dự án sẽ thất bại. Khi sự việc thành tồi tệ, mọi người sẽ bỏ qua những điều như kiểm thử, tích hợp v.v. làm nảy sinh sản phẩm chất lượng thấp. Khi khách hàng phàn nàn về lỗi, công ti phải sửa chúng. Sẽ tốn kém nhiều để sửa lỗi sau khi đưa ra cho khách hàng. Hậu quả là chi phí cao hơn, thời gian dài hơn, khách hàng giận dữ, người phát triển thất vọng, và người chủ mất tiền.
Có bằng chứng rằng các công ti hội tụ vào qui trình đã đạt tới sự hài lòng của khách hàng, đáp ứng lịch biểu, chất lượng cao hơn và lợi nhuận nhiều hơn. Nếu người phát triển chỉ nhận được đào tạo kĩ thuật trong đại học thì họ sẽ cần đào tạo thêm về kỉ luật tuân theo qui trình. Họ phải hiểu ích lợi của qui trình cho nên đào tạo qui trình là quan trọng. Tuy nhiên, để thay đổi thói quen, đào tạo phải bắt đầu từ cấp quản lí trước. Nếu người quản lí thay đổi thói quen, mọi thứ sẽ thay đổi bởi vì người phát triển sẽ tuân theo chỉ đạo của họ. Tất nhiên, đổi thói quen mọi người, 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 họ 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 là khó nhưng mọi đào tạo đều phải bắt đầu với cấp quản lí.
Điều này dường như là điều ngạc nhiên lớn với nhiều người chủ. Nhiều nhà tư vấn thường hội tụ đào đào tạo người phát triển về cách làm tài liệu qui trình cho nên có nhiều câu hỏi và thảo luận về cách tiếp cận này. Tôi giải thích cho họ rằng có qui trình được làm tài liệu sẽ chỉ giúp cho công đi qua được đánh giá CMMI nhưng không thay đổi thói quen xấu của nhân viên. Vì hoạt động làm tài liệu tốn thời gian, thường vài tháng hay đôi khi vài năm, trong trường hợp đó nhà tư vấn có thể làm được nhiều tiền hơn. Để làm cải tiến thực xảy ra, cấp quản lí phải ra quyết định đúng bằng việc để bản thân họ là “tấm gương” cho những người phát triển đi theo. Nếu họ không thay đổi thói quen xấu của họ, không cái gì sẽ xảy ra và trong tình huống này, điều này sẽ làm ra khác biệt giữa thành công và thất bại.
Lí do là trong hoạt động cải tiến, cấp quản lí phải lập kỉ luật cho những người phá luật hay những người từ chối tuân theo qui trình. Điều quan trọng cho công ti là đặt ra qui tắc mới cho cải tiến qui trình và điều đó phải bắt đầu từ cấp quản lí. Tất nhiên, lập kỉ luật đúng là dễ hơn được thực hiện, và đó là vấn đề nhạy cảm. Nếu người quản lí không tuân theo qui trình, họ có thể có thời gian khó khăn khi lập kỉ luật cho ai đó làm cùng điều đó. Chẳng hạn, nếu một người phát triển bỏ qua thiết kế và nhảy vào viết mã, người quản lí phải ra quyết định về cách xử trí với tình huống này. Điều gì xảy ra nếu người quản lí cũng đặt lịch biểu dựa trên trực giác thay vì tuân theo qui trình ước lượng? Người phát triển có thể cãi rằng vì lịch biểu không được ước lượng tốt và quá ngắn, người đó không có thời gian để tuân theo vòng đời phát triển. Người đó phải bỏ qua một số pha chỉ để làm cho công việc của mình được thực hiện xong. Trong nhiều công ti phần mềm, người phát triển thường nghĩ rằng họ có thể phá luật và làm bất kì điều gì người đó muốn làm chừng nào họ vẫn làm cho công việc của họ được hoàn thành. Đây là thói quen xấu phải được thay đổi nếu công ti muốn cải tiến. Nếu người quản lí không tuân theo qui trình, những thành viên tổ khác sẽ chú ý tới điều đó, và họ sẽ trở nên không bằng lòng. Nếu họ cảm thấy rằng người quản lí không thay đổi, họ sẽ nghĩ họ cũng có thể làm cùng điều đó. Điều này có thể làm yếu đi năng lực của công ti để cải tiến.
Để bắt đầu cải tiến qui trình, người chủ phải đặt chiều hướng rõ ràng. Không ai được ở trên qui tắc, ngay cả người quản lí cũng không được. Nếu họ làm sai, họ phải chịu cùng kỉ luật được giáng cho người phát triển. Điều này tạo ra môi trường công bằng nơi mọi người cảm thấy bình đẳng. Tất nhiên, cách người chủ lập kỉ luật cho nhân viên là quan trọng. Họ không muốn quá khắt khe nếu điều đó là không cần thiết. Nếu họ làm điều này, nhân viên sẽ sợ họ. Cải tiến không nên là cái gì đó mà họ sợ nhưng là cái gì đó họ cần.
Theo ý kiến riêng của tôi, điều quan trọng nhất trong cải tiến qui trình là khuyến khích hay thưởng để đạt tới mục đích. Với khuyến khích đủ, mọi nhân viên sẽ làm việc chăm chỉ để làm cho sự việc xảy ra. Họ sẽ dành thời gian của họ, nỗ lực của họ để giúp người quản lí thành công. Đây là chỗ tôi quay lại đặt mục đích doanh nghiệp về cải tiến. Mục đích kém nhất là đạt tới mức CMMI vì nó không ngụ ý gì cho bất kì ai. Mục đích thực phải là cái gì đó đo được và “thực” như giảm lỗi 20% mỗi năm, cải tiến số các dự án đáp ứng lịch biểu lên 50% trong hai năm v.v. Cái gì đó đơn giản mà mọi người có thể hiểu được. Chẳng hạn, hôm nay lỗi trung bình là 20 lỗi trên một nghìn dòng mã lệnh và nếu tỉ lệ lỗi trung bình giảm đi trong năm nay đến 20%, mọi nhân viên có thể có điểm thưởng vào cuối năm. Điểm thưởng có thể là bằng tiền hay vài ngày nghỉ phụ thêm, cái gì đó nhân viên muốn. Với khuyến khích đúng, mọi sự sẽ thay đổi. Sẽ có sức ép trong các nhân viên để giảm số lỗi, người phát triển sẽ giám sát thành viên tổ để chắc rằng mọi người sẽ tuân theo qui trình và kiểm thử mã của họ một cách cẩn thận. Nếu người quản lí yêu cầu kiểm điểm nhiều hơn để nhận diện và sửa lỗi, người phát triển sẽ kiểm điểm cẩn thận điều họ làm bởi vì không muốn là “kẻ làm hỏng” người ngăn cản mọi người được nhận khuyến khích. Đây là chỗ thay đổi thói quen xấu xảy ra vì người phát triển muốn quan sát lẫn nhau và nhắc nhở họ về việc tuân theo qui trình.
Vơi người chủ người thực sự muốn cải tiến doanh nghiệp của họ, họ cần cân nhắc cải tiến như cái gì đó có ưu tiên cao bởi vì đó là quyết định doanh nghiệp chứ không phải quyết định kĩ thuật. Để cải tiến, mọi người trong công ti phải đảm nhiệm để hoàn thành nhiệm vụ của họ. Người chủ công ti phải mạnh trong các thông điệp rằng nhiệm vụ cải tiến là quan trọng và phải không được để trễ. Chỉ với tầm quan trọng và chỉ đạo khẩn thiết từ cấp cao nhất của công ti và với khuyến khích đúng, mọi người sẽ làm việc vất vả để thay đổi thói quen xấu của họ. Khi những điều này xảy ra, cải tiến sẽ xuất hiện. Để làm cải tiến thực xảy ra, người chủ và người quản lí phải thừa nhận rằng nhiệm vụ đầu tiên của họ là thay đổi bản thân họ khỏi thói quen xấu. Rồi điều đó có thể đưa tới thay đổi lớn lao. Bằng không việc cải tiến phần mềm sẽ không được thực hiện.
—-English version—-
Process Improvement part 2
To improve, company must have a clear vision to communicate to every employees about the direction that owners want to go. Without it, everybody may be confused and may decide to go into different directions. After having owners completed their vision. I asked them to write down their business goals. Most wrote down reduce defects, increase profits, make more money, have more customers, expand business globally etc. Then I asked them on what would allow them to achieve these goals. Of course, the typical answer was having quality products and services since quality was what they had in mind. My next question was what do they need to build quality product?
After several discussions among the group, the final conclusion was “Knowledge and skills”. I asked them: “Where do they acquire these things? Do university graduates have these skills? Does university taught improvement skills?” If graduates already had these skills then why company did not have quality products and had to improve? So we got down to the main reason of bad habit such as developers not following a defined process. The bad habit of skipping phases and jumped into coding. The bad habit of managers set up schedule without estimations etc. I explained to them that when a project does not have a process that it will use, developers will do whatever they like. In the end, they will spend more time in correcting defects and no time to improve the software. When the project seems to slip schedule, everybody panic. Developers will focus on their own personal works to make sure that if something happens, it is not their fault. When team members are not working together and withdraw from interactions with each others, project coordination will fail. When thing get worst, people will skip things such as testing, integrating etc. resulting in low quality product. When customers complain about defects, company have to fix them. It will cost more to fix defects after release to customer. The consequences are higher costs, longer time, customers angry, developers frustrate, managers panic, and owners lose money.
There are evidences that companies that focus on process have achieved customers satisfaction, meeting schedule, higher quality and more profits. If developers only receive technical training in college then they will need additional trainings in the discipline of following a process. They must understand the benefits of process so process training is important. However, to change bad habits, training must start with management first. If managers change their habit, everything will change because developers will follow their direction. Of course, changing the habit of people who prefer “meet schedule first, focus on quality when they have time” into someone who know how to plan, how to estimate, how to negotiate is difficult but every trainings must start with management.
This seemed to be a big surprised to many owners. Many consultants often focused on the training of developers about how to document the process so there were several questions and discussions about this approach. I explained to them that having documented process will only help company to pass the CMMI appraisal but not change employees’ bad habits. Since documentation activities take time, often several months or sometime years, in that case, consultants can make more money. To make real improvement happens, management must make the right decision by setting themselves as “models” for developers to follow. If they do not change their bad habits, nothing will change and in this situation, this will make the difference between success and failure.
The reason is during improvement activities, management must discipline people who break rules or who refuse to follow the process. It is important for the company to set new rules for process improvement and it must start with management. Of course, properly disciplining is easier said than done, and it is a sensitive issue. If managers do not follow the process, they may have difficult time discipline someone who do the same. For example, if a developer skips design and jump to coding, manager must make a decision on how to deal with this situation. What happen if manager also sets schedule based on intuition rather than follow the estimate process? Developer could argue that since the schedule is not well estimated and too short, he does not have time to follow the development life cycle. He must skip some phases just to get his work done. In many software companies, developers often think that they can break rules and do whatever they want as long as they get their work done. This bad habit must be changed if company wants to improve. If a manager fails to follow a process, other team members will notice it, and they will become resentful. If they feel that managers do not change, they will think they can do the same. This can weaken the ability of a company to improve.
To start process improvement, the owner must set direction clearly. No one should be above the rules, not even the managers. If they do wrong, they should get the same discipline that is given to developers. This creates a fair environment where everyone feels equal. Of course, how owners discipline employees is important. They do not want to be too harsh if it is not necessary. If they do this, employees will fear them. Improvement should not be something that they fear but something that they need.
In my own opinion, the most important in process improvement is incentives or reward for achieving the goal. Given sufficient incentives, every employees would work hard to make thing happens. They will allocate their time, their efforts to help managers to succeed. This is where I returned to the setting the business goals of improvement. The worst goal is to achieve a CMMI level since it does not mean anything to anybody. The real goal must be something measurable and “Real” such as reduce defects by 20% each year, improve number of project that meet schedule by 50% in two years etc.. Something simple that people can understand. For example, today the average defect is 20 defects per thousand lines of code and if the average defect rate decreases this year by 20%, every employees could have a bonus at the end of the year. The incentive bonus could be monetary or few extra vacation days, something that employees want. With the right incentive, thing will change. There will be pressure among employees to reduce the number of defects, developers will monitor team members to make sure that everybody will follow the process and test their code carefully. If managers require more reviews to identify and fix defects, developers would carefully review what they do because nobody would want to be the “Spoiler” who prevent people from getting the incentive. This is where changing bad habits take place as developers would watch each other and remind them about following the process.
For the owners who really want to improve their business, they need to consider improvement as something with high priority because it is a business decision not technical decision. To improve, every person in the company must be held accountable for completing their tasks. Company owners must be strong in the messages that improvement tasks are important and must not be delayed. Only with the importance and urgency direction from the top of the company and the right incentive, people will work hard to change their bad habits. When these things happen, improvement will happen. To make real improvement happens, the owners and managers must recognize that their first task is to change themselves from bad habits. Then it can lead to substantive change. Otherwise the software improvement work will not get done.