Hỏi: Khi nào chúng tôi nên bắt đầu xây dựng Thư viện tài sản qui trình – Process Asset Library (PAL)?

Đáp: Một quan niệm sai thông thường là ở chỗ Thư viện tài sản qui trình – Process Asset Library (PAL) không tồn tại mãi tới mức 3. Hệ quả là các tổ chức không thực sự chú ý nhiều tới nó sau khi thẩm định mức 2 thành công đã được hoàn thành. Thực ra, một số yếu tố của thư viện đó bắt đầu nổi lên ngay cả khi chuyển từ mức 1 sang mức 2.

Tài sản qui trình là những thực hành, thủ tục, khuôn mẫu, và ví dụ về những điều đã được dùng và được đo, tức là, chúng có dữ liệu liên kết mà có thể được so sánh và nhận diện như các thực hành tốt nhất. Những tài sản này không nên là các tài liệu qui trình được tạo ra một cách lí thuyết mà không có lịch sử sử dụng và được hỗ trợ bởi dữ liệu đo.

Vì những tài sản này tồn tại, tổ chức phải thu thập và lưu giữ chúng ở đâu đó để cho mọi người có thể dùng chúng. Bạn có thể chưa có PAL được xác định rõ nhưng bất kì loại kho nào cũng có ích. Nếu tổ chức đợi cho tới sau khi đạt tới mức 2 thành công, có nguy cơ họ sẽ làm mất nhiều “thực hành tốt nhất” của mình.

Lập kế hoạch trước là khôn hơn cả. PAL không phải là cơ sở dữ liệu hay web tưởng tượng – nó đơn giản có thể là tủ hồ sơ.

Hỏi: Cách tốt nhất để làm giảm lỗi phần mềm là gì?

Đáp: Kiểm điểm sản phẩm phần mềm đã từng diễn ra lâu rồi. Mục đích của chúng là nhận diện và loại bỏ các khiếm khuyết. Kiểu dễ nhất là kiểm mã đơn giản bằng người lập trình và dựa trên danh sách kiểm.  Để tránh thiên lệch cá nhân, “kiểm điểm ngang quyền” không chính thức bởi nhóm cùng làm việc trong cùng dự án hay tổ chức có thể được tiến hành. Nếu được yêu cầu, việc giám định chính thức bởi một tổ được huấn luyện tốt có thể được mời tới để giúp nhận diện các khiếm khuyết phụ.

Hỏi: Làm sao thầy cải tiến được qui trình phần mềm của tổ chức khi thế giới đang đi với tốc độ Internet? Đến lúc thầy hoàn thành một thẩm định thì thế giới đã thay đổi rồi.

Đáp: Vâng, quả thực thế giới kinh doanh đang đi với tốc độ Internet đấy. Bây giờ hơn bao giờ hết, tổ chức lại càng cần phản ứng nhanh chóng và chính xác. Cách nhất quán duy nhất để làm điều đó là gióng thẳng kế hoạch hành động của bạn – đặc biệt phần chiến lược như tầm nhìn và mục đích – với môi trường đang tiến hoá, chính là thực tại kinh doanh của bạn. Quản lí cấp cao nên đặt ra tầm nhìn và mục đích và chúng phải được dựa trên hiểu biết chính xác về chiều hướng đúng của tổ chức.

Bản kế hoạch hành động bao giờ cũng động chứ không tĩnh và được dùng để trao đổi về chiều hướng trong toàn tổ chức. Mọi người quản lí đều cần được tham gia vào việc theo dõi tiến độ của bản kế hoạch hành động và sẵn sàng điều chỉnh kế hoạch khi cần. Việc gióng thẳng cải tiến qui trình với mục đích doanh nghiệp tạo khả năng liên tục làm cải tiến qui trình trong “thời đại internet” khi mà tốc độ và không chắc chắn là một phần của phương trình.

Hỏi: Người quản lí của tôi không quan tâm tới cải tiến qui trình – chỉ quan tâm tới đạt mức độ trưởng thành. Làm sao tôi đổi được cách nghĩ của ông ấy?

Đáp: Bạn cần hỏi mức độ trưởng thành có nghĩa gì với tổ chức nếu không có dữ liệu cải tiến. Nếu bạn không được thoả mãn với câu trả lời thì bạn có chọn lựa: hoặc bạn tham gia hoặc bạn không tham gia vào trò chơi trưởng thành.

Hỏi: Tại sao có nhiều nhấn mạnh thế vào huấn luyện kĩ năng cho người mới? Sao không để họ học tại việc làm? Điều đó có thể tiết kiệm được nhiều tiền.

Đáp: Thực hành thuê người không có kinh nghiệm và rồi bắt họ làm việc vất vả cho tới khi họ mòn mỏi và bỏ đi, xem như cách tiếp cận tiết kiệm tiền, là rất thiển cận. Cách tiếp cận này sẽ bao gồm chi phí cho việc tuyển mộ liên miên – quảng cáo, duyệt xét, phỏng vấn v.v. – và chừng ấy sẽ ngốn hết bất kì tiết kiệm nào từ việc không cung cấp huấn luyện kĩ năng.

Người mới cần học về công cụ, miền ứng dụng, vòng đời phần mềm và phương pháp được thực hành trong tổ chức. Trong khi bạn có thể tìm ra người có hiểu biết về công cụ nào đó, miền ứng dụng và phương pháp quả thực yêu cầu huấn luyện. Nếu không có chương trình huấn luyện chính thức tại chỗ, hay nếu qui trình làm mọi thứ trong tổ chức không được nắm bắt, bạn rất có thể kinh nghiệm chi phí cao dưới dạng kiệt quệ dần người then chốt của bạn.

Huấn luyện trong công việc yêu cầu thời gian khá nhiều của những người có kinh nghiệm nhất của bạn trong khi họ đang được cần làm những điều gấp rút. Tuy nhiên, người thiếu kinh nghiệm sẽ phạm sai lầm và nếu sai lầm không được phát hiện đúng lúc, sự việc thậm chí còn có thể tốn kém hơn.

Một vấn đề được khách hàng của bạn bắt được là cực kì tốn kém, và phát triển liên miên ứng dụng chất lượng kém thậm chí có xu hướng tạo ra lắm vấn đề hơn. Chung cuộc, trong môi trường hỗn độn, người có kinh nghiệm nhất của bạn có thể bị thất vọng và bỏ đi và điều đó có thể là thoả thuận hời để “tài sản trí tuệ” của bạn bước ra cửa cùng họ.

Câu hỏi mấu chốt là “Chi phí cho việc phát minh lại bánh xe lặp đi lặp lại là gì?”

Vào thời mà khan hiếm lao động là căng thẳng, sẽ là khôn ngoan để lấy cách tiếp cận dài hạn tới quản lí con người bằng việc đầu tư vào huấn luyện kĩ năng và sử dụng tốt hơn các nhân sự bạn đã có.

Hỏi: Thầy có thông tin hay ích lợi hiệu năng của cải tiến qui trình trong các công ti thương mại khác không?

Đáp:

Bell Core nói lỗi thấp xuống 10 lần so với trung bình công nghiệp  khi tiến từ CMM mức 1 tới 4. (Bellcore Press Release Feb 5, 1997)

Motorola nói cải tiến năng suất lên 3 lần, giảm thời gian chu kì  3 lần và cải tiến chất lượng lên 7 lần khi 85% tổ chức phần mềm là CMM mức 3 hay trên. (Motorola Press Release, 1995)

Siemens nói giảm 50% về thời gian chu kì và 90% cải tiến về loại bỏ lỗi khi họ đạt tới CMM mức 3. (Wasterlid & Mobrin paper in SEPG 1997)

Hỏi: Chính sách là gì và tại sao chúng ta cần có chính sách về thực hành phần mềm để thoả mãn CMMI?

Đáp: Chính sách là phương tiện qua đó ý định của quản lí cấp cao được làm cho tổ chức biết tới. Nó đơn giản là tập cơ sở các qui tắc hay chiều hướng mà quản lí cấp cao mong đợi mọi người tuân theo. Do đó, nhận biết về chính sách là điều bắt buộc đối với những người được trông đợi sẽ thực hiện chính sách. Chính sách bao giờ cũng xem xét những việc thưởng phạt nào đó và không thể bị vi phạm. (Vi phạm chính sách bị xử lí còn nghiêm trọng hơn lầm lỡ qui trình).

Tương tự, tập các thực hành mà không có hỗ trợ thích hợp và hậu thuẫn bởi chính sách có thể không có khả năng được lâu bền. Việc không lặp lại những thực hành đó không vi phạm ‘chính sách” vì nó không tồn tại. Cho nên chính sách là điều bắt buộc để duy trì bền vững thực hành tốt. CMMI có yêu cầu những chính sách nào đó có tại chỗ cho miền qui trình phần mềm – tổ chức có thể có một chính sách bao quát cho mọi khu vực qui trình hay các chính sách tách rời cho từng khu vực qui trình.

Hỏi: Thầy thấy gì khi thế giới phần mềm thay đổi quanh thầy và dự kiến của thầy là gì cho mấy năm tới?

Đáp: Thế giới phần mềm thực sự thay đổi nhanh chóng và sẽ tiếp tục thay đổi. Ngày nay hầu hết các dự án đều nhỏ (5 tới 10 người) khi so với 10 năm trước khi các dự án lớn (50 tới 200 người) là phổ biến.  Cách chúng ta xây dựng hệ thống cũng đã thay đổi với ít việc phát triển và nhiều tích hợp hơn. Nhiều tổ chức đang làm tốt hơn vài năm trước, họ có thể dự đoán chính xác điều gì cần lấy để phát triển phần mềm và có vận hành trôi chảy được kiểm soát. Nhiều tổ chức phần mềm đang quản lí như doanh nghiệp, không như hỗ trợ. Ngày càng nhiều tổ chức phần mềm đang tiến lên các mức CMMI (Có trên 150 tổ chức ở mức 5 bây giờ, so với 3 trong vài năm trước). Mọi thứ trở nên ngày một phức tạp hơn bởi vì phần mềm đã đi tụt sau phần cứng và chiếm giai đoạn trung tâm. Nó đã tạo ra giá trị có nghĩa lớn cho doanh nghiệp và sẽ tiếp tục tăng trưởng về tầm quan trọng. Tuy nhiên, cùng với phần mềm, có nhiều vấn đề phải được giải quyết và điều chúng ta làm về chúng sẽ xác định phần mềm sẽ trở thành một phần của doanh nghiệp nhanh bao lâu. Chẳng hạn, một số phát triển phần mềm được coi như nghiên cứu và phát triển R&D nhưng, gói COTS lại bị nhiều người coi như chi tiêu vốn (đặc biệt nếu có cấp phép toàn công ti) và bị khấu hao cũng giống như bất kì tài sản nào khác.  Khi các công ti ôm ngày càng nhiều COTS (và họ đang thế), phần mềm quả trở thành tài sản trên bảng cân đối.  Khi các công ti thực hiện cải tiến để giảm chi phí, phần mềm trở thành yếu tố chiến lược của chiến lược công ti.  Cứ xem các báo cáo hàng năm của các hãng lớn như GE, Microsoft, Oracle và IBM và xem các chiến lược đó là gì.

Tôi tin ngày nay mọi người đều thông minh hơn nhiều và hiểu phần mềm tốt hơn họ đã hiểu vài năm trước đây.  Người dùng, khách hàng, luật sư, kế toán viên, và các nhà chuyên môn phi phần mềm khác đều biết nhiều hơn về phần mềm so với niềm tin chúng ta đặt vào họ.  Thực tế là thế giới đã trở nên rất mang học thức phần mềm (nhưng có thể không thông minh phần mềm toàn bộ).

Hỏi: Làm sao CMMI có tác dụng trong môi trường Web? Mô hình này có lạc hậu trong kỉ nguyên Internet không?

Đáp: Mỗi ngày cái mới lại bắt đầu nảy ra cùng với những ý tưởng mới hay việc đóng gói lại các ý tưởng và gọi chúng là e-này hay e-nọ. Cái gì là khác biệt giữa môi trường Web và môi trường phát triển phần mềm khác? Bạn có phải lập kế hoạch công việc của mình không? Bạn có cần đảm bảo thay đổi được kiểm soát không? Bạn có muốn theo dõi mọi dự án tương ứng và đưa ra đúng thời gian không? Tôi tin khác biệt duy nhất trong môi trường Web là bạn phải làm mọi thứ tốt hơn và nhanh hơn. CMMI chỉ là mô hình cải tiến; nó có thể được dùng trong bất kì môi trường nào và được áp dụng theo nghĩa thông thường.

Hỏi: Khác biệt giữa người quản lí và người lãnh đạo là gì?

Đáp: Người quản lí là ai đó được đề bạt  vào vị trí để:

- Thực thi kế hoạch

- Phản ứng với nhu cầu của tổ chức

- Làm đúng mọi sự

- Hội tụ vào hệ thống, kiểm soát, thủ tục, qui trình, và chính sách

- Đưa ra chỉ đạo cho cấp dưới

Người lãnh đạo là ai đó có thể:

- Xây dựng tầm nhìn và tạo hứng khởi cho mọi người theo tầm nhìn đó

- Khởi đầu mọi sự một cách dự ứng

- Làm điều đúng

- Nói được “cái gì và tại sao ”

- Hội tụ vào con người

- Phục vụ người khác

- Phát kiến

Mọi người bao giờ cũng theo người lãnh đạo nhưng tổ chức bao giờ cũng cần người quản lí để giữ mọi sự trong kiểm soát. Sự cân bằng được cần tới cho bất kì tổ chức nào để thành công. Mọi người dường như không được kích động hay được nhiệt tình về các vấn đề ngắn hạn như lập ngân sách, duy trì trạng thái dự án, hay phát triển chính sách công ti. Họ muốn biết tổ chức đang đi tới đâu và làm sao họ sẽ giữ vai trò trong việc đưa tổ chức đi vào tương lai được nhìn thấy trước của nó. Mọi tổ chức không chỉ cần năng lực lãnh đạo như phát kiến, mà cũng cần năng lực quản lí như đạt tới các kết quả tuyến đáy. Nhưng nếu một tổ chức được quản lí quá mức và lại được lãnh đạo quá thiếu, họ phải cố gắng thúc đẩy quyền lãnh đạo nào?

Hỏi: Làm sao chúng tôi có thể thoả mãn việc phối hợp giữa nhiều nhóm khi một số nhóm và khách hàng không quan tâm? Chừng nào chúng tôi còn chuyển giao phần mềm đúng thời gian, họ hài lòng và không muốn can thiệp vào công việc của chúng tôi.

Đáp: Bạn có chắc khách hàng của bạn chỉ quan tâm tới lịch biểu và KHÔNG quan tâm về chất lượng và chi phí? Ta hãy nhìn vào hai biến cố găng nhất của máy bay trong chuyến bay: cất cánh và hạ cánh. Dự án phần mềm cũng phản chiếu điều này: hai biến cố găng nhất là phân tích yêu cầu và kiểm thử hệ thống.  Trong chuyến bay, cùng tổ bay thực hiện cả hai việc cất cánh và hạ cánh.  Trong phần mềm — không may – tổ làm yêu cầu và tổ kiểm thử hệ thống thường không tương tác nhau. Phối hợp liên nhóm yêu cầu tương tác và đối thoại giữa tất cả các nhóm hỗ trợ cho dự án để thám hiểm sự khác biệt và tương đồng của những bộ môn cô lập này.  Người quản lí dự án phải mời các thành viên — nhà phân tích, người kiểm thử, và bất kì ai đã từng ở bất kì đâu chỗ giữa — cùng tham gia vào. Nếu họ có tham gia, điều tuyệt vời có thể xảy ra và bạn sẽ thoả mãn việc phối hợp liên nhóm (mức 3).

—-English  version—–

Question: When should we start to build the Process Asset Library (PAL)?

Answer:  A common misconception is that a Process Asset Library (PAL) does not exist until Level 3. Consequently, organizations don’t really pay much attention to it until after a successful Level 2 assessment has been completed. In truth, some elements of that library begin to emerge even when moving from Level 1 to Level 2.

Process assets are practices, procedures, templates, and examples of things that have already been used and measured, that is, they have associated data that can be compared and identified as best practices. These assets should not be process documents created theoretically without a history of usage and backed up with measured data.

Since these assets exist, the organization must collect and store them somewhere so people can use them. You may not have a well-defined PAL yet but any sort of repository can help. If the organization waits until after successful attainment of Level 2, chances are they will have lost many of their “best practices”.

It’s much smarter to plan ahead. A PAL does not have to be a fancy database or web—it can simply be a file cabinet.

Question: What is the best way to reduce software defects?

Answer: Reviews of software products have been around for a long time. Their purpose is to identify and remove defects. The easiest type is a simple code checking done by the programmer and based on a checklist.  To avoid individual bias, an informal “peer review” by a group working in the same project or organization could be conducted. If required, a formal inspection by a well-trained team could be called in to help identify additional defects.

Question: How do you improve the software process of an organization when the world is moving at Internet speed? By the time you complete an assessment the world is already changing.

Answer: Yes, indeed the world of business is moving at Internet speed. Now more than ever, organizations need to react quickly and accurately. The only consistent way to do that is to align your action plan—particularly the strategic parts such as vision and goals—to the ever-evolving environment that is your business reality. Senior management should set vision and goals and they must be based on an accurate understanding of the true direction of the organization.

An action plan is always dynamic not static and is used to communicate direction across the organization. All managers need to get involved in tracking the progress of the action plan and be ready to adjust the plan when needed. Aligning process improvement to the business goals makes it possible to continue doing process improvement in “internet time” when speed and uncertainty are part of the equation.

Question: My manager is not interested in process improvement—only in achieving a maturity level. How do I change his mind?

Answer: You need to ask what a maturity level means to the organization without the improvement data. If you are not satisfied with the answer then you do have a choice: Either you participate or you don’t in the maturity level game.

Question: Why is there so much emphasis on skill training for new people? Why not let them learn on the job? That could save a lot of money.

Answer: The practice of hiring inexperienced people and then working them hard until they burn out and leave is, as a cost saving approach, very short sighted. This approach will include the cost of ongoing recruiting—ads, screening, interviews, etc.—and by far will offset any savings from not providing skill training.

New people need to learn about the tools, the application domain, the software life cycle and the methods practiced in the organization. While you may be able to find people who are knowledgeable in some tools, the application domain and methods do require training. If there is no formal training program in place, or if the process of doing things in the organization is not captured, you are likely to experience high costs in the form of an ongoing drain of your key people.

On the job training requires significant time from your most experienced people when they are needed to do critical things. However, inexperienced people will make mistakes and if mistakes are not caught in time, it can be even more costly.

A problem caught by your customer is extremely expensive, and ongoing development of a poor quality application tends to produce even more problems. Finally, in a chaotic environment, your most experienced people may be frustrated and leave and that can be a good deal of your “intellectual property” walking out the door with them.

The critical question then is “What is the cost of reinventing the wheel time and time again?”

In a time when the labor shortage is critical, it would be wise to take a long-range approach to people management by investing in skill training and making better use of the personnel you already have.

Question: Do you have information on performance benefits of process improvement in other commercial companies?

Answer:

Bell Core claimed 10X lower defects than the industry average when advancing from CMM level 1 to 4. (Bellcore Press Release Feb 5, 1997)

Motorola claimed 3X productivity improvement, 3X cycle time reduction and 7X quality improvement when 85% of software organizations are CMM level 3 or above. (Motorola Press Release, 1995)

Siemens claimed 50% reduction in cycle time and 90% improve in defects removal when they achieved CMM level 3. (Wasterlid & Mobrin paper in SEPG 1997)

Question: What is a policy and why do we need to have a policy on software practices to satisfy the CMMI?

Answer: Policy is a means by which the intent of senior management is made known to the organization. It is simply a basic set of rules or directions that senior management expects people to follow. Therefore, awareness of the policy is a must for those who are expected to implement the policy. Policy is always looked at with certain amount of sanctity and can not be violated. (Policy violations are dealt with more seriously than a slip-up in processes).

Similarly, a set of practices without adequate support and the backing of a policy may not be able to be sustained. Not repeating those practices does not violate a ‘policy’ since it does not exist. So a policy is a must to sustain good practices. The CMMI does require certain policies in place for software process areas—organizations can have one policy to cover all PAs or separate policies for each PA.

Question: What do you see as the software world changing around you and what would be your prediction for the next few years?

Answer: The software world is really changing fast and will continue to change. Today most projects are small (5 to 10 people) when compare with 10 years ago when big projects (50 to 200 people) were popular.  The way we build systems also has changed with less developing and more integrating. Many organizations are doing better now than few years ago, they can forecast accurately what it will take to develop software and have their operations well under control. More software organizations are being run like a business, not as a support. More and more software organizations are advancing their CMMI levels (There are over 150 level 5 organizations now, compare with 3 few years ago). Everything became more sophisticated because software has come from behind hardware and takes the center stage. It has created significant value to the business and will continue to grow in importance. However, with software, there are many issues that must be solved and what we do about them will determine how fast software will become part of the business. For example, some software developments are treated as R&D but, COTS packages are treated by many as capital expenditures (especially if there is a enterprise-wide license) and is depreciated just like any other asset.  As companies embrace more and more COTS (and they are), software does become an asset on the balance sheet.  As companies implement improvement to reduce cost, software becomes a strategic element of the corporate strategy.  Look at some of the annual reports for big firms like GE, Microsoft, Oracle and IBM and see what these strategies are.

I believe people today are much smarter and understand software better than they ever did few years ago.  The users, customers, lawyers, accountants, and other non-software professionals knew a lot more about software than we are giving them credit for.  As a matter of fact, the world has become very software-literate (but may be not totally software smart).

Question: How does CMMI work in the Web environment? Is the model already obsolete in the Internet era?

Answer: Each day new start ups are popping up with new ideas or re-packaging of old ideas and call them e-this or e-that. What is the different between the Web environment and other software development environment? Do you have to plan your work? Do you need to ensure changes are controlled? Do you want to track all projects accordingly and release on time? I believe the only different in the Web environment is you have to do everything better and faster. The CMMI is only an improvement model; it can be used in any environment and applied with common sense

Question: What is the different between a manager and a leader?

Answer: A Manager is someone who is promoted into a position to:

- Execute a plan

- React to organization needs

- Does things right

- Focus on systems, controls, procedures, processes, and policies

- Giving direction to subordinate

A Leader is someone who can:

- Build a vision and inspire people on that vision

- Initiate things proactively

- Do the right things

- Articulate “what and why”

- Focus on people

- Serving others

- Innovate

People will always follow a leader but organization always need managers to keep things under control. A balance is needed for any organization to be successful. People don’t seem to get excited or enthused about shorter-term issues like formulating a budget, maintaining the project status, or developing a company policy. They want to know where the organization is going and how they will play a role in moving the organization into its envisioned future. Every organization not only needs leadership competencies like innovation, but also management competencies like achieving bottom-line results. But if an organization is over-managed and under-led, what leadership behaviors should they attempt to foster?

Question: How can we satisfy the coordination among many groups when some groups and customers are not interested? As long as we deliver software on time, they are happy and do not want to interfere with our work.

Answer: Are you sure your customers only care about schedule and NOT quality and cost? Let look at the two most critical events of an airplane in flight: takeoff and landing. Software projects also mirror this: the two most critical events are requirements analysis and system testing.  In flight, the same crew executes both takeoff and landing.  In software — unfortunately – the requirement crew and the system test crew usually don’t interact. Intergroup coordination requires an interaction and dialogue between all groups supporting project to explore the differences and similarities of these isolated disciplines.  Project manager must invite participants — analysts, testers, and anyone who has ever been anywhere in the middle — to join in. If they did, wonderful things could happen and you would satisfy the intergroup coordination (Level 3).