Hỏi: Tôi tin chúng ta nên học từ các công ti khác đã từng làm cải tiến qui trình. Họ có công bố các bài học rút ra của họ không?

Đáp: Có chứ, có vài bài học rút ra được công bố nhưng phần lớn mô tả kinh nghiệm của họ ở mức trừu tượng rất cao. Trong môi trường cạnh tranh, họ không muốn người khác biết chi tiết về cách họ đã làm nó cho nên khi tôi xem kĩ các tài liệu đã công bố, tôi để ý thấy rằng tất cả những tài liệu đó đều có những lời khuyên tương tự kiểu như:

1.      Thu được cam kết của cấp quản lí về cải tiến qui trình

2.      Điều phối tiến bộ trên cơ sở đều kì.

3.      Xác định và thực hiện cách đo phần mềm

4.      Thiết lập hướng dẫn về việc dùng CMMI

5.      Tạo ra SEPG để phối hợp các hoạt động cải tiến

Nhiều lời khuyên được phát biểu ngẫu nhiên như cam kết, bảo trợ của cấp quản lí, v.v nhưng họ thực sự ngụ ý gì? Tôi tin rằng bạn cần hiểu nghĩa thực đằng sau những từ này, thừa nhận sự tồn tại của những cái tạo khả năng và rào chắn thực trong tổ chức của bạn và dùng thông tin đó để lập kế hoạch các hoạt động cải tiến của bạn. Cách tốt nhất để học cái gì đó là thực hành hay học từ kinh nghiệm riêng của bạn (học qua hành).

 

Hỏi: Các phương pháp luận “Lập trình có cấu trúc” hay “Hướng đối tượng” có ảnh hưởng gì lên CMMI?

Đáp: Không, CMMI chỉ là khuôn khổ cho cải tiến qui trình chứ không phải là phương pháp luận. Nó nói rằng tổ chức “nên lựa chọn phương pháp luận có tác dụng cho họ và dùng nó tương ứng”. Nó không khuyến cáo phương pháp luận đặc biệt nào. CMMI là độc lập phương pháp luận.

 

Hỏi: Trong quan hệ khách hàng/nhà cung cấp, khách hàng muốn có khả năng tối đa còn nhà cung cấp muốn thực hiện với hiệu quả tối đa. Làm sao thầy cân bằng được khác biệt này?

Đáp: Đúng là cả hai bên đều có những mục đích khác nhau. Chìa khoá cho họ là thừa nhận điều này và phát triển hiểu biết về điều đang lái người kia. Có giá trị trong việc bù trừ mà nếu không thì không thể đi tới thoả thuận (tức là thương lượng về chất lượng đối với tốc độ và chức năng hay lịch biểu).

Hỏi: Tổ chức của tôi không làm tiến bộ gì với việc cải tiến qui trình. Là một thành viên SEPG, tôi thất vọng vì chẳng cái gì dường như làm việc. Xin thầy chỉ bảo.

Đáp: Là một thành viên SEPG, bạn bị thất vọng bởi vì chẳng cái gì được làm. Tất nhiên, cải tiến là làm mọi thứ tốt hơn chứ không tồi hơn. Tuy nhiên, để hiệu quả, hành động cải tiến phải thay đổi hành vi và thái độ của người quản lí và kĩ sư phần mềm. SEPG có thể khởi đầu thay đổi nhưng thay đổi thực sự chỉ xảy ra trên dự án phần mềm, điều có nghĩa là đó là trách nhiệm của người quản lí và kĩ sư chứ không phải là thành viên SEPG.

Đừng lẫn lộn vai trò của bạn với ai đó khác. Là thành viên SEPG, vai trò của bạn là phối hợp và tạo điều kiện cho hoạt động thay đổi. Chính người quản lí cấp cao và người quản lí dự án phải trông nom cho thay đổi xảy ra. Vấn đề là làm sao làm cho người quản lí và người kĩ sư phần mềm làm những điều không đóng góp trực tiếp cho việc chuyển giao sản phẩm phần mềm? Đây là vấn đề khó khăn vì nhiều lí do. Thứ nhất, người kĩ sư phần mềm và đặc biệt là người quản lí bao giờ cũng bận rộn. Thứ hai, họ có thể không hiểu điều SEPG muốn họ làm hay tại sao. Và thứ ba, họ có thể không tin rằng điều bạn đề nghị sẽ giúp họ làm việc của họ tốt hơn.

Do đó là một thành viên SEPG, bạn cần làm cho họ nhận ra rằng họ phải hành xử khác đi.  Chừng nào cấp quản lí còn sẵn lòng sống cùng với những hậu quả của qui trình hỗn độn, họ sẽ tiếp tục ở tại CMMI mức 1, bất kể điều bạn làm. Điều SEPG cần là nhấn mạnh vào việc thiết lập một hệ thống có trật tự để tạo ra cam kết dự án, kế hoạch được làm tài liệu, và chính sách chất lượng. Nếu họ không đồng ý làm điều này, chẳng cái gì khác sẽ có tác dụng.

Bạn cần lấy việc cải tiến từng bước mỗi lúc. Phải chắc rằng cấp quản lí đồng ý với nhu cầu cải tiến qui trình, và rằng họ biết chi phí và ích lợi của nó. Tuân theo bản lộ trình cho việc cải tiến qui trình và các nguyên tắc triển khai mà tôi đã biện minh trong xê mi na (Xác định, Thử nghiệm, Xét lại, và Thể lệ hoá). Cách tiếp cận này bao giờ cũng có tác dụng, nhưng cần thời gian, kiên nhẫn, và niềm lạc quan bền bỉ. Nó cũng cần quyền lãnh đạo nhất quán và thái độ có thể làm. Nếu bạn có thể thuyết phục được cấp quản lí về nhu cầu thay đổi, cách tiếp cận này sẽ có tác dụng. Nếu bạn không thể, chẳng cái gì có tác dụng.

Hỏi: Tôi nghe nói rằng doanh nghiệp phần mềm đang nở hoa ở Ấn Độ và nhiều công ti được làm khoán ngoài các dự án ở đó. Cái gì đã xảy ra ở đó?

Đáp: Doanh nghiệp phần mềm ở Ấn Độ không chỉ nở hoa mà còn bùng nổ. Lí do chính là chi phí lao động thấp, khả năng của kĩ sư phần mềm Ấn Độ trao đổi bằng tiếng Anh, khối lượng đường nối truyền thông điện tử bao la, và chương trình của chính phủ thúc đẩy công nghiệp phần mềm.  Theo báo cáo của World Bank, ngành công nghiệp phần mềm Ấn Độ đã duy trì trạng thái lãnh đạo của nó với tỉ lệ tăng trưởng hàng năm 30%. Năm 1996 xuất khẩu phần mềm một mình đã phá vỡ kỉ lục 1 tỉ đô la Mĩ và năm 2008 nó đã đạt tới 86 tỉ đô la trong kinh doanh một năm.

Để kinh doanh này phát đạt, kết cấu nền phải được thiết lập và hiện thời có hàng nghìn đường truyền dữ liệu tốc độ cao, nối các công ti phần mềm Ấn Độ với khách hàng trên toàn thế giới. Các trung tâm xuất khẩu phần mềm của Ấn Độ được nhập khẩu miễn thuế, cho tới 100% giá trị tài sản nước ngoài, và được vận hành tới 5 năm không thuế. Tôi tin những quyết định này đã là chất xúc tác trong việc xây dựng kết cấu nền cần thiết và làm cho vốn thành sẵn có cho đầu tư vào sản phẩm và gói phần mềm. Hiện thời, Mĩ và châu Âu vẫn là thị trường lớn nhất cho xuất khẩu phần mềm Ấn Độ.

Tăng trưởng ngoại lệ trong công nghiệp phần mềm Ấn Độ đã là có thể bởi vì đội ngũ lớn các kĩ sư phần mềm được huấn luyện tốt và có chất lượng; chuẩn chất lượng của nó và việc truy nhập của nó vào giáo dục và công nghệ cỡ thế giới. Theo thu thập dữ liệu mới nhất, các nhà chuyên môn phần mềm ở Ấn Độ đã tăng trưởng tới ước lượng cỡ 1 triệu ngày nay, khi so với 140,000 năm 1995. Con số này được ước lượng tăng lên theo hệ số 10 cứ mỗi 5 năm. Các nguồn công nghiệp tin rằng không có đủ nhà chuyên môn để hỗ trợ cho tăng trưởng hiện thời. Việc thiếu hụt này thậm chí sẽ còn nghiêm trọng hơn nếu ngành công nghiệp phần mềm của Ấn Độ có khả năng giữ thị phần của nó trong kinh doanh toàn thế giới. Phần lớn các công ti phần mềm Ấn Độ chính đều giải quyết vấn đề với các chương trình huấn luyện và giáo dục tại chỗ của riêng họ, hỗ trợ từ các đại học địa phương và quốc gia, các trường cao đẳng kĩ nghệ và các thể chế giáo dục tư khác. Một số bắt đầu thám hiểm khả năng thiết lập doanh nghiệp trong các nước lân cận để tận dụng ưu thế lực lượng có kĩ năng lương thấp ở đó.

Dựa trên phân tích dữ liệu của tôi, tôi tin trong vòng mười năm nữa, ưu thế chi phí thấp của Ấn Độ sẽ giảm đi, nhưng lực lượng làm việc có kĩ năng và chuẩn chất lượng cao của nó sẽ vẫn còn là tài sản rất quan trọng mà sẽ tiếp tục giữ cho nền kinh tế của họ tăng trưởng với nhịp rất nhanh. Ở Ấn Độ, có quãng 5500 công ti phần mềm có chứng chỉ ISO 9000 và có xấp xỉ 185 công ti đủ tư cách CMMI mức 4 và 5, còn cao hơn nhiều con số tổ chức có mức trưởng thành cao ở Mĩ và châu Âu tổ hợp lại. Với nền giáo dục đẳng cấp thế giới, lực lượng lao động có động cơ nói thành thạo tiếng Anh, chuyển giao các sản phẩm chuẩn chất lượng cao cho khách hàng toàn thế giới, tôi nghĩ Ấn Độ sẽ vẫn còn rất thành công trong kinh doanh phần mềm trong nhiều năm tới.

 

Hỏi: Khác biệt giữa quản lí dự án và phương pháp luận phần mềm là gì?

Đáp: Đây là so sánh:

PHƯƠNG PHÁP LUẬN PHẦN MỀM                  QUẢN LÍ DỰ ÁN

Xác định khuôn khổ để giải quyết                  Xác định khuôn khổ lập kế hoạch

thách thức kĩ thuật                                           và quản lí

Xác định thuộc tính kĩ thuật                             Xác định cách chuyển giao sản phẩm

của sản phẩm mong muốn                                theo lịch biểu và trong ngân sách

Mô tả và tổ chức vật phẩm                               Mô tả và tổ chức công việc cần để

chuyển giao chính                                             sản xuất ra vật chuyển giao

Xác định điều cá nhân phải                               Xác định cách cá nhân sẽ

biết                                                                     tích hợp tri thức của họ

Xác định vai trò kĩ thuật và                               Xác định vai trò quản lí

trách nhiệm                                                        và trách nhiệm

Đo tiến độ theo các yêu cầu                              Đo tiến bộ theo kế hoạch

kĩ thuật                                                               dự án

 

Mối quan hệ giữa quản lí dự án và phương pháp luận phần mềm là tương tự như mối quan hệ của tiếp thị và bán hàng. Phương pháp luận phần mềm giống như tiếp thị — nó là bộ môn chiến lược liên quan tới “ĐIỀU” bạn phải làm để thành công:

Cách tốt nhất để nhận diện yêu cầu người dùng là gì?

Cái gì phải được làm để đáp ứng với các chuẩn chất lượng liên quan?

Công nghệ nào nên được dùng để hỗ trợ cho từng ứng dụng?

Quản lí dự án giống như bán hàng — nó là bộ môn vận hành liên quan tới “CÁCH” để thành công:

Tổ nên được tổ chức như thế nào?

Công việc phải mất bao lâu?

Làm sao bạn có thể biết bạn đang theo lịch?

Như với tiếp thị và bán hàng, kĩ năng trong cả hai môn này là cần cho thành công. Chẳng hạn, phần lớn các phương pháp luận phần mềm nhận diện sự tham gia của khách hàng như nhân tố thành công mấu chốt (điều cần làm). Quản lí dự án xác định sự tham gia của khách hàng bằng việc xác định khách hàng nào sẽ được tham gia và khi nào (cách làm nó). Tất nhiên, có sự chờm lấp giữa hai điều này. Nhiều phương pháp luận cung cấp hướng dẫn về ước lượng và lập lịch biểu. Cả hai bộ môn đều nhấn mạnh nhiều vào việc sản xuất ra sản phẩm chất lượng v.v. Mặc cho sự chờm lấp này, điều quan trọng là cần hiểu sự khác biệt giữa hai môn này bởi vì thực hành kém trong cả hai miền này đều có thể nảy sinh trong dự án thất bại.

——English version

 

Question: I believe we should learn from other companies that have been doing process improvement. Do they publish their lessons learned?

Answer: Yes, there are few published lessons-learned but most described their experiences in a very high level of abstraction. In a competitive environment, they do not want others to know in detail of how they did it so as I look closely at these published documents, I noticed that all of them have similar advises such as:

1.      Obtain management commitment for process improvement

2.      Monitor progress on a periodic basis.

3.      Define and implement software metrics

4.      Establish guidance on the use of CMMI

5.      Create an SEPG to coordinate improvement activities

Many advices are casually stated such as management commitment, sponsorship etc. but what do they really mean? I believe that you need to understand the real meaning behind these words, recognize the existence of real enablers and barriers in your organization and use that information to plan your improvement activities. The best way to learn something is to practice or learn from your own experiences (Learning by doing).

 

Question: What effect does methodologies such as “Structured Programming” or “Object Oriented” have on the CMMI?

Answer: None, the CMMI is only a framework for process improvement not a methodology. It stated that organization “should select a methodology that works for them and use it accordingly”. It does not recommend any specific methodology. The CMMI is methodology-independent.

 

Question: In a Customer/Supplier relationship, the customer wants maximum capability and the supplier wants to perform with maximum efficiency. How do you balance the differences?

Answer: It is true that both parties have different goals. The key is for them to recognize this and develop an understanding of what is driving the other. There is value in the trade- off that might not otherwise have come up (i.e. trading quality for speed or functionality for schedule).

 

Question: My organization is not making any progress with process improvement. As a SEPG member, I am frustrated since nothing seems to work. Please advice.

Answer: As a SEPG member, you are frustrated because nothing gets done. Of course, to improve is to make thing getting better not worse. However, to be effective, improvement actions must change the behavior and attitude of the managers and software engineers. The SEPG can initiate change but real change only happens on software projects that mean it is the responsibility of managers and engineers and not the SEPG member.

Do not confuse your role with somebody else. As SEPG member, your role is to coordinate and facilitate the change activities.  It is the senior managers and project managers to see that change happen. The question is how to get managers and software engineers to do things that do not directly contribute to delivering software products? This is a difficult problem for many reasons. First, software engineers and especially managers are always busy. Second, they may not understand what the SEPG want them to do or why. And third, they may not believe that what you propose will help them do their jobs better.

Therefore as a SEPG member, you need to get them to recognize that they must behave differently.  As long as management is willing to live with the consequences of a chaotic process, they will continue to be at CMMI Level 1, regardless of anything you do. What SEPG need are to insist on establishing an orderly system for making project commitments, documented plans for all projects, and a quality policy. If they do not agree to do this, nothing else will work.

You need to take improvement one step at a time. Make sure that management is in agreement with the need for process improvement, and that they know its costs and benefits. Follow the roadmap for process improvement and deployment principles that I have advocated in my seminar (Define, Pilot, Revise, and Institutionalize). This approach always works, but it takes time, patience, and unfailing optimism. It also takes consistent leadership and a can-do attitude. If you can convince management of the need for change, this approach will work. If you can’t, nothing will work.

 

Question: I heard that software business is booming in India and many companies are outsourced projects there. What has happened there?

Answer: Software business in India is not just booming but exploding. The main reasons are the low cost of labor, the ability of Indian software engineer to communicate in English, the vast amount of electronic communication links, and government program to foster the growth of the software industry.  According to World Bank report, Indian software industry has maintained its leading status with a yearly growth rate of 30%. In 1996 software exports alone have broke the record of US $1 billion and in 2008 it has reached US $86 billion a year business.

For this business to thrive an infrastructure must be set up and currently there are thousand high speed sophisticated data communication links, connecting Indian software companies to their customers world-wide. India software export centers are provided duty free import, up to 100% foreign equity, and up to 5-years operations without any tax. I believe these decisions were catalyst in building the necessary infrastructure and make capital available for investment into software products and packages. Currently, U.S and Europe remain as the largest market for Indian software exports.

The exceptional growth in Indian software industry has been possible because India’s large pool of qualified and well trained software engineers; its quality standards and its access to a word-class education and technology. According to the latest data collection, the software professionals in India have grown to an estimated 1 million today, as compared with 140,000 in 1995. This number is estimated to increase by a factor of 10 for every 5 years. Industry sources believe that there are not enough professionals to support the current growth. This shortage will even be more severe if the Indian software industry is able to secure its share of the world-wide business. Most major Indian software companies are working on the problem with their own in-house education and training programs, support from the local and national universities, engineering colleges and other private educational institutions. Some begin to explore the possibility of set up business in other near by countries to take advantage of a lower wage skilled workforce there.

Base on my data analysis, I believe within the next ten years, India’s low cost advantage will diminish, but the skilled work force and its high quality standards will remain a very important assets that will continue to keep their economy growing at a very fast pace. In India, there are about 5500 software companies with ISO 9000 certification and approximately 185 companies have qualified for CMMI level 4 and 5, which is much higher than the number of high level maturity organization in the U.S and Europe combined. With a world class education, a motivated workforce fluently in English, deliver high quality standard products to customer worldwide, I think India will remain very successful in software business in many years to come.

 

Question: What is the difference between project management and software methodology?

Answer: Here is a comparison:

SOFTWARE METHODOLOGY                  PROJECT MANAGEMENT

Defines a framework for solving                  Defines a framework for

the technical challenge                                 planning and managing the

work

Specifies the technical                                 Specifies how to deliver the

attributes of the desired product                 product on schedule and

within budget

Describes and organizes the major            Describes and organizes the

deliverables                                                   work needed to produce the

deliverables

Defines what an individual must     Defines how individuals will

know                                                               integrate their knowledge

Specifies technical roles and                      Specifies management roles

responsibilities                                              and responsibilities

Measures progress against the                  Measures progress against

technical requirements                                 the project plan

 

The relationship between project management and software methodology is similar to that of marketing and sales. Software methodology is like marketing — it is a strategic discipline concerned with “WHAT” you must do to be successful:

What is the best way to identify user requirements?

What must be done to meet relevant quality standards?

What technology should be used to support each application?

Project management is like sales — it is an operational discipline concerned with “HOW” to be successful:

How should the team be organized?

How long should the work take?

How can you tell if you are on schedule?

As with marketing and sales, skill in both disciplines is necessary for success. For example, most software methodologies identify customer involvement as a critical success factor (what to do). Project management then defines customer involvement by determining which specific customers will be involved and when (how to do it). Of course, there is some overlap between the two. Many methodologies provide guidance on estimating and scheduling. Both disciplines place great emphasis on producing a quality product etc. Despite the overlaps, it is important to understand the differences between the two because poor practices in either area can result in a failed project.