Đáp: Cải tiến qui trình phần mềm KHÔNG phải là luyện tập kĩ thuật mà là chiến lược doanh nghiệp. Trong thế giới cạnh tranh, nếu bạn không tiến bộ, bạn bị ở sau và không doanh nghiệp nào có thể tồn tại với việc ở sau được rất lâu.

Người kĩ thuật phải hiểu rằng họ giữ vai trò rất quan trọng trong doanh nghiệp phần mềm và để thành công họ phải cung cấp sản phẩm và dịch vụ liên tục vượt quá mong đợi của khách hàng. Nếu họ chỉ tập trung vào cạnh tranh về kĩ thuật với các công ti phần mềm khác, họ mang định mệnh thất bại, vì họ chỉ duy trì ở tuyến cơ sở sống sót. Thành công tương lai phụ thuộc vào khả năng của tổ chức đi ra ngoài cạnh tranh và hội tụ nhất quán với việc vượt quá mong đợi của khách hàng. Khi một tổ chức có thể làm được điều này nó tạo ra dịch vụ khách hàng ngoại lệ mà đối thủ cạnh tranh của nó khó tìm ra cách sánh tương ứng.

Trong thế giới công nghệ đang thay đổi nhanh, qui tắc doanh nghiệp đã thay đổi và ‘mạnh nhất hay lớn nhất’ không còn chi phối mà ‘nhanh nhất’ sẽ chi phối. Thành công của bạn phụ thuộc vào bạn có thể tạo ra và thực hiện ý tưởng mới nhanh thế nào để giữ cho khách hàng hiện thời của bạn được thoả mãn, làm phát sinh khách hàng mới và chi phối thị trường. Mọi doanh nghiệp đều phải thiết lập mối quan hệ sống còn với khách hàng của họ bởi vì dịch vụ bạn cung cấp là quan trọng hơn sản phẩm bạn bán.

Đây là khái niệm tương đối mới nhưng bạn quan sát xu hướng trong thế giới công nghệ, bạn sẽ thấy rằng do cạnh tranh, phần lớn các công ti giữ cho giá sản phẩm của họ rất thấp nhưng họ trang điểm thêm bằng việc cung cấp dịch vụ phụ thêm. Nói cách khác, sản phẩm chỉ là ‘món khai vị’ nhưng dịch vụ là ‘món ăn chính thực’. Dịch vụ là nơi tiền được làm ra chứ không phải sản xuất, đó là lí do tại sao thoả mãn của khách hàng là mục đích số một của mọi cải tiến qui trình.

Tôi mạnh mẽ tin tưởng mọi người phải học nghĩ như người doanh nghiệp và đi ra ngoài mong đợi của khách hàng của bạn. Cho khách hàng chọn lựa về cách họ muốn được phục vụ và bạn sẽ thấy doanh nghiệp của bạn tăng trưởng nhanh thế nào. Nếu bạn đưa khách hàng của bạn vào cách họ muốn được đối xử, mối quan hệ với họ sẽ tăng trưởng mạnh hơn qua thời gian và từng khách hàng bạn có đều là một khách hàng đối thủ cạnh tranh của bạn không có và đó là qui tắc mới cho thành công của doanh nghiệp trong thế kỉ 21.

39.02 Hỏi: Tại sao đào tạo được yêu cầu cho trưởng thành của tổ chức? Tại sao chúng tôi phải được đào tạo khi chúng tôi đã có bằng từ đại học?

 Đáp: Tổ chức phần mềm chỉ có thể trưởng thành khi lực lượng lao động của nó có năng lực cao. Nếu bạn nhìn lại lịch sử, con người đã từng ở đây trong quãng 7 triệu năm nhưng 90% tiến bộ trong “công nghệ” đã xuất hiện trong 70 năm qua và internet điều gây tác động cực kì lớn cho cuộc sống chúng ta mới chỉ 7 tuổi. Trong thế giới thay đổi nhanh chóng này, giáo dục là cấu phần then chốt sẽ làm phân biệt ai sẽ thành công và ai sẽ không thành công.

Điều bạn đã học trong đại học chỉ là nền tảng cho việc học tiếp tục của bạn giúp bạn thịnh vượng và sống còn trong thế giới thay đổi nhanh chóng này. Công nghệ ngày nay có cuộc đời trên thị trường quãng 5 năm. Điều đó nghĩa là sự lạc hậu xuất hiện với tỉ lệ 20% mỗi năm hay 20% của lực lượng lao động phải học điều mới mỗi năm và trong vòng 5 năm toàn thể tổ chức phải làm cái gì đó khác đi so với điều họ làm hôm nay. Nhiều người trong thế giới doanh nghiệp không hiểu điều này, và mô hình doanh nghiệp của họ không phản ánh hiện tượng này, và đó là lí do tại sao chúng ta thấy nhiều tổ chức ra khỏi kinh doanh trong vài năm qua kể cả những tập đoàn khổng lồ bởi vì họ không thích nghi được với thay đổi.

Tổ chức thành công trong môi trường cạnh tranh cao này là tổ  chức thừa nhận rằng việc học và học lại thường xuyên là cách duy nhất để đối phó với thay đổi và còn tính cạnh tranh. Giải quyết với loại thay đổi này yêu cầu tổ chức có chiến lược hội tụ vào học tập. Nếu tổ chức không học điều mới, nó sẽ chết bởi vì điều sống còn duy nhất là thay đổi vì thay đổi cung cấp sự ổn định. Tổ chức càng chống lại thay đổi lâu, nó sẽ càng chết chóng hơn.

Thực tại, phần lớn các tổ chức phần mềm đều giải quyết với thay đổi trên cơ sở hàng ngày. Tất cả chúng ta đều biết phần mềm thay đổi, yêu cầu thay đổi và công nghệ phần mềm thay đổi mọi lúc. Điều then chốt là tính cạnh tranh, ai thay đổi nhanh hơn sẽ thành công nhưng thay đổi phải được quản lí và cách tốt nhất để quản lí là giáo dục.

Cải tiến qui trình là về thay đổi và giáo dục mọi người để thay đổi. Người lãnh đạo cải tiến qui trình phải là người cam kết tích cực với việc học riêng của họ. Người lãnh đạo có học tập tham dự việc đào tạo cùng hay trước người của họ. Họ hiểu tầm quan trọng của giáo dục. Họ xác định mục tiêu, họ cam kết cung cấp tài nguyên để làm nó xảy ra. Họ xác định rằng tài sản duy nhất họ có trong thế giới đang thay đổi nhanh chóng là khả năng của mọi người của họ để học nhanh hơn đối thủ cạnh tranh.

39.03 Hỏi: Là người đã tiến hành nhiều đánh giá CMMI, vấn đề chung trong tổ chức phần mềm mà thầy đã quan sát là gì?

Đáp: Vấn đề chung số một là lịch biểu không hiện thực. Khi đối diện với lịch biểu không hiện thực, tổ phần mềm thường hành xử một cách không hợp lí bằng việc tạo ra các yêu cầu rất nghèo nàn hay thiết kế hời hợt để cho họ có thể xô vào viết mã rồi kết thúc với sản phẩm chất lượng kém, chức năng không đúng, lỗi nghiêm trọng và chẳng ai ngạc nhiên – chậm chuyển giao.

Vấn đề chung thứ hai là nhiều thay đổi yêu cầu thế trong pha viết mã. Dường như là không ai có khả năng quản lí các yêu cầu một cách hiệu quả. Trong khi các yêu cầu thường thay đổi trong các pha sớm, có lúc vượt ra ngoài thời gian những thay đổi sẽ gây ra ngắt quãng cho phát triển. Để đáp ứng lịch biểu không thoả đáng và thay đổi thường xuyên bằng bất kì giá nào cũng phải hi sinh chất lượng. Khi khách hàng có khả năng đòi hỏi những điều như vậy và tổ chức cho phép điều đó xảy ra, có cơ hội cao rằng sản phẩm sẽ tốn kém và có thể không làm việc tốt.

Vấn đề chung thứ ba là khái niệm về việc dùng phần mềm thương mại bán trên thị trường Commercial off-the-shelf software (COTS) như một giải pháp tiết kiệm chi phí. Dường như là rất ít người hiểu khái niệm tích hợp COTS hay phân tích việc dùng đúng của họ. Có nhiều nghiên cứu trong công nghiệp lên tiếng báo động về tích hợp COTS như bom hẹn giờ thảm hoạ. Sản phẩm COTS làm việc hoàn hảo trong đề mô, trình diễn, có thể hỏng khi bị bắt phải vào cấu hình khác, tỉ lệ dữ liệu cao hơn hay thậm chí lỗi do vào dữ liệu. Tổ chức phải kiểm thử mọi sản phẩm COTS một cách kĩ lưỡng để làm lộ ra các hoàn cảnh chưa được kiểm thử trước đây. Nếu bạn có vấn đề sớm, gần như chắc chắn nó sẽ là phiền hà khi được dùng trong sản xuất.

39.04 Hỏi: Tại sao nhiều tổ chức khoán ngoài phần mềm của họ ra ngoại quốc? Đấy là vấn đề chi phí hay chất lượng?

Đáp: Một số tổ chức khoán ra ngoài vì tiết liệm chi phí, số khác khoán ngoài vì yêu cầu chất lượng. Tuy nhiên, có sự tố khác mà mọi người hiếm khi nói tới: “việc chán tăng lên về triệu chứng anh hùng”. Nhiều tổ chức, đặc biệt các tổ chức ở mức trưởng thành rất thấp bao giờ cũng dựa nặng vào vài cá nhân về bất kì kĩ năng phần mềm nào họ có để giải quyết phần lớn các vấn đề. Bất kì khi nào những người này ra đi, tổ chức mất năng lực đó (hay các phần năng lực đó). Để giữ họ, tổ chức phải trả lương cao hơn trung bình cho những người có kĩ năng găng và điều này giúp tạo ra văn hoá “Anh hùng” nơi các anh hùng bao giờ cũng được đối xử khác và được thưởng bằng nhiều tiền nhưng điều này làm tổn thương tinh thần tổ và doanh nghiệp về dài hạn. 

Trong doanh nghiệp phần mềm, làm việc tổ là rất quan trọng và nếu mọi người không làm việc cùng nhau hướng tới mục đích chung, sản phẩm sẽ có thể có nhiều lỗi và các vấn đề lịch biểu. Không công ti phần mềm nào có thể cạnh tranh thành công trong thế giới cạnh tranh cao độ này nếu chi phí phát triển của họ là quá cao và sản phẩm của họ có nhiều lỗi. Đó là lí do tại sao khoán ngoài đã trở thành phổ biến nơi tổ chức có thể làm kinh doanh ở nơi lao động có kĩ năng, sẵn lòng làm việc, có khả năng và động cơ để làm công việc chất lượng cao với trả lương ít hơn nhiều và đẩy nhiều “anh hùng được trả lương cao” ra khỏi doanh nghiệp.

39.05 Hỏi: Làm sao tôi thực hiện thay đổi trong tổ chức đã thất bại vài lần trong quá khứ?

Đáp: Đây là việc làm rất thách thức. Mỗi lúc một tổ chức thất bại trong cải tiến, nó đều làm tăng sự chống đối thay đổi và giảm việc tin vào những người chủ trương thay đổi. Để thực hiện thay đổi, bạn phải hiểu văn hoá tổ chức, các qui tắc rắc rối không được viết ra của tổ chức chỉ đạo hành vi mọi người. Bạn cần hiểu vấn đề mà bạn đang cố giải quyết, tại sao nó xảy ra hay được phép xảy ra cũng như giá trị hay ích lợi của thay đổi được đề nghị. Thay đổi là rất khó – bạn phải có người tài trợ người sẵn lòng hỗ trợ cho bạn và công việc của bạn.

Bạn phải hiểu hệ thống thưởng của tổ chức vì nó ảnh hưởng tới hành vi của họ. Bạn phải có kĩ năng trao đổi để thuyết phục mọi người bước ra khỏi vùng thoải mái của họ và làm việc cùng bạn. Bạn phải thu được sự tin cậy và kính trọng của họ bằng việc lập kế hoạch một cách logic từng nhiệm vụ cải tiến một cách cẩn thận và bắt đầu từ từ tăng tin cậy và kính trọng của họ.

39.06 Hỏi: Nếu lịch biểu dự án là không thoả đáng hay không hiện thực thì làm sao thầy biết khi nào dự án phần mềm được hoàn thành?

Đáp: Có nhiều cách nhìn khi nào dự án là được hoàn thành. Cách phổ biến nhất là khi nó được đưa ra cho khách hàng. Tuy nhiên, bạn có lẽ biết rằng việc đưa ra sản phẩm bị lỗi không có nghĩa là dự án của bạn được thực hiện.

Lời khuyên của tôi là trước khi bắt đầu một dự án, bạn cần tự hỏi bản thân mình “Cái gì là quan trọng mấu chốt cho dự án ‘này’?” và “Dự án này đang cố gắng giải quyết vấn đề gì?”

Bằng việc biết câu trả lời cho những câu hỏi này, bạn có thể xác định sản phẩm phần mềm phải tốt thế nào? Bạn sẽ đối diện với chọn lựa khó khăn của việc giữ cân bằng ý tưởng của bạn với các ràng buộc dự án như lịch biểu, tài nguyên, chất lượng, chi phí v.v.

Chắc chắn, mọi dự án sẽ có các ràng buộc khác nhau nhưng bạn phải cân nhắc chúng so với nhau một cách cẩn thận để xác định ưu tiên của cái gì là quan trọng và phải được làm trước hết. Bạn cũng cần xác định thuộc tính chất lượng nào phải được thực hiện để hỗ trợ cho những tính năng đó rồi dùng những dữ liệu này để soạn thảo ra lịch biểu đưa ra tăng dần và các tiêu chí chất lượng liên kết. Bạn cần thu được sự ủng hộ từ cấp quản lí của bạn và thương lượng điều này với khách hàng để làm vững chắc lịch biểu đưa ra. Một khi bạn đã thiết lập và chấp thuận kế hoạch đưa ra của dự án cùng các nhiệm vụ và tiêu chí thành công được nhận diện, bạn phải trao đổi kế hoạch này với tổ  dự án của bạn và bắt đầu theo dõi dấu vết tiến độ theo kế hoạch này. Từ đó trở đi, mỗi lúc bạn đưa ra phần mềm, bạn biết đích xác bao nhiêu công việc đã được hoàn thành và khi nào dự án phần mềm được thực hiện.

39.07 Hỏi: Cách đo then chốt cho CMMI mức cao hơn là gì?

Đáp: Nếu tổ chức của bạn đã đạt tới ít nhất CMMI mức 3 bằng việc đã xác định các qui trình cho mọi nhiệm vụ dự án và tổ chức, thì bạn đã sẵn sàng cho cách đo nào đó để xem một cách khách quan bạn tốt thế nào và để chuẩn bị cho mức tiếp. Dữ liệu đo có thể giúp cho tổ chức nhận diện điểm mạnh, điểm yếu và cung cấp dữ liệu lịch sử cho lập kế hoạch tương lai. Sau đây là một số ví dụ được dùng với một dự án.

Quản lí yêu cầu

Nỗ lực được lập kế hoạch/thực tại để thực hiện qui trình này

Số các yêu cầu thay đổi qua thời gian

Số các không tuân thủ cho qui trình này

Lập kế hoạch và quản lí dự án

Nỗ lực được lập kế hoạch/thực tại để thực hiện qui trình này

Số các không tuân thủ cho qui trình này

Quản lí rủi ro

Nỗ lực được lập kế hoạch/thực tại để thực hiện qui trình này

Số rủi  ro qua thời gian (tăng hay giảm)

Số các rủi ro được giảm như do quản lí rủi ro

Số các rủi ro mở so với đóng

Số các không tuân thủ cho qui trình này

Quản lí cấu hình

Nỗ lực được lập kế hoạch/thực tại để thực hiện qui trình này

Số các lỗi liên quan tới CM

Số phần trăm các bản dựng kém

Số các không tuân thủ cho qui trình này

Đảm bảo qui trình và sản phẩm

Nỗ lực được lập kế hoạch/thực tại để thực hiện qui trình này

Số các kiểm định

Số các không tuân thủ cho qui trình này

Đo và phân tích

Nỗ lực được lập kế hoạch/thực tại để thực hiện qui trình này

Số các cách đo được thu thập nhưng KHÔNG được dùng

Số các không tuân thủ cho qui trình này

Phát triển yêu cầu

Nỗ lực được lập kế hoạch/thực tại để thực hiện qui trình này

Số các yêu cầu được dẫn ra

Số các yêu cầu thay đổi qua thời gian

Số các lỗi trong tài liệu yêu cầu

Số các không tuân thủ cho qui trình này

Thiết kế và thực hiện

Nỗ lực được lập kế hoạch/thực tại để thực hiện qui trình này

Số các lỗi trong thiết kế và viết mã

Số các mã thay đổi hàng tuần

Số các không tuân thủ cho qui trình này

Tích hợp sản phẩm

Nỗ lực được lập kế hoạch/thực tại để thực hiện qui trình này

Số lỗi được tìm ra

Số kết quả được dựng (như, # bản dựng kém)

Số các không tuân thủ cho qui trình này

Trắc nghiệm

Nỗ lực được lập kế hoạch/thực tại để thực hiện qui trình này

Số lỗi được tìm ra trong kiểm nghiệm

Số các không tuân thủ cho qui trình này

Kiểm nghiệm

Nỗ lực được lập kế hoạch/thực tại để thực hiện qui trình này

Số trường hợp kiểm thử

Số lỗi được tìm ra trong kiểm nghiệm

Số phần trăm các kiểm thử qua/không qua

Số các chu kì kiểm thử thực tế so với lập kế hoạch

Số tỉ lệ lỗi tìm ra so với giải pháp lỗi

Số các không tuân thủ cho qui trình này

Phân tích quyết định và giải pháp

Nỗ lực được lập kế hoạch/thực tại để thực hiện qui trình này

Số các phân tích quyết định và giải pháp được thực hiện theo dự án

Số các không tuân thủ cho qui trình này

Cải tiến qui trình

Nỗ lực được lập kế hoạch/thực tại để thực hiện qui trình này

Số các qui trình được dùng qua thời gian

Số các lỗi được tìm ra trong tài sản qui trình

Số các không tuân thủ cho qui trình này

Đào tạo

Nỗ lực được lập kế hoạch/thực tại để thực hiện qui trình này

Số giờ đào tạo được lập kế hoạch so với nhận được

Điểm đánh giá đào tạo

Số các không tuân thủ cho qui trình này

39.08 Hỏi: Khác biệt gì giữa kiến trúc và thiết kế? Kiến trúc là gì và tại sao chúng ta cần kiến trúc?

Đáp: Kiến trúc của hệ thống là cấu trúc của hệ thống, bao gồm các cấu phần, các thuộc tính thấy được bên ngoài của nó và mối quan hệ giữa chúng. Kiến trúc là tập các quyết định về cách tổ chức và cấu trúc của các cấu phần đó, lựa chọn chúng trong hoàn cảnh, nhận diện mối quan hệ của chúng và giao diện cũng như hành vi của chúng để thoả mãn tập các yêu cầu. Kiến trúc là thiết kế, nhưng không phải mọi thiết kế đều là kiến trúc. Kiến trúc hội tụ vào mức cao của hệ thống như các cấu phần chính và các ràng buộc mà không sa vào chi tiết kĩ thuật. Thiết kế hội tụ vào thực hiện các cấu phần này và tạo ra vật phẩm như tài liệu thiết kế và mã, tương ứng với kiến trúc đã được lập kế hoạch rõ.

Kiến trúc là quan trọng bởi vì nó phục vụ như phương tiện để tạo điều kiện thuận lợi cho trao đổi giữa những người có liên quan và người phát triển.  Nó giúp làm sáng tỏ các yêu cầu và ý định thiết kế mà không bị sa lầy vào mức chi tiết kĩ thuật.  Nó hỗ trợ cho ra quyết định về thuộc tính chất lượng nào đó bằng việc làm cho các thuộc tính này thành thấy được như tính chất bên ngoài của cấu phần hệ thống.  Nó bắc cầu qua lỗ hổng giữa yêu cầu và thực hiện và cho phép người thiết kế phân tích các cấu phần và cách nhìn để ưu tiên hoá các nhiệm vụ thiết kế và làm sáng tỏ các vấn đề thực hiện trong giai đoạn sớm. 

Nó phân rã các yêu cầu hệ thống quan niệm thành các cấu phần được nhận diện với tính chất thấy được bên ngoài cho nên người kĩ thuật có liên quan không thể dễ dàng hiểu được nó.  Nó biểu diễn các cách nhìn khác nhau cho những người có liên quan khác nhau mà không bị ràng buộc bởi khía cạnh thiết kế do vậy giúp cho người phát triển phân tích hệ thống và xác định mối quan hệ của chúng sớm trong pha phát triển.  Bằng việc có kiến trúc được làm tài liệu tốt, có thể tiết kiệm cho người phát triển nhiều thời gian trong phân tích và hiểu việc thực hiện hệ thống trong pha bảo trì.

39.09 Hỏi: Tại sao tổ chức cần có phương pháp luận chuẩn để thoả mãn yêu cầu mức 3? Chúng tôi có thể dùng bất kì cái gì chúng tôi có không?

Đáp: Một trong những sự tố then chốt trong cải tiến qui trình là chọn lựa phương pháp luận được xác định tốt với quản lí dự án vững chắc và quản lí chất lượng. Tổ chức có thể phí hoài nhiều tiền bạc và thời gian bằng việc cho phép mọi người chọn bất kì phương pháp luận và công cụ nào để xây dựng phần mềm. Đây là vấn đề chính dẫn tới khó khăn đáng kể khi tích hợp phần mềm xuất hiện. Không thể đặt các cấu phần không tương hợp, được tạo ra bởi đa dạng công cụ, lại với nhau. Phương pháp luận chuẩn được cần tới để đảm bảo rằng tổ chức tuân theo thực hành kĩ nghệ phần mềm tốt. Phương pháp luận phần mềm tốt có thể được phát triển trong nội bộ dựa trên nhiều năm thử và sai hay có thể được mua từ nhà cung cấp có danh tiếng.

39.10 Hỏi: Làm sao tôi tránh được sai lầm của dự án quá khứ và đảm bảo thành công cho dự án mới của tôi? Có bài học rút ra nào không?

Đáp: Có chứ, có nhiều bài học rút ra từ các dự án quá khứ. Tóm lại: Có bốn sự tố độc lập có thể tác động lên thành công của bất kì dự án nào. Chúng là: Chi phí, Chất lượng, Lịch biểu và Rủi ro. Logic là đơn giản: bạn không thể xây dựng hệ thống không đắt có chất lượng cao rất nhanh mà không có rủi ro thất bại. Tuy nhiên, có thể xây dựng một hệ thống có rủi ro thấp và chất lượng cao tức là hệ thống phải làm việc tốt và đáp ứng thành công các yêu cầu nhưng bạn phải giữ cân bằng lịch biểu và chi phí. Người quản lí dự án phần mềm tốt phải biết cách ước lượng lịch biểu và chi phí và điều chỉnh các sự tố này tương ứng.

Lịch biểu không hiện thực là “kẻ giết người” số một của bất kì dự án phần mềm nào và để tránh điều này, người quản lí dự án phải dựa vào dữ liệu lịch sử khi ước lượng và thương lượng với khách hàng dựa trên các sự kiện và dữ liệu này.

Sự tố then chốt khác là kĩ năng và tri thức về người của dự án. Ngay cả dự án được lập kế hoạch tốt cũng vẫn có thể thất bại bởi vì việc thực hiện không được giải quyết đúng do nhân viên thiếu kinh nghiệm. Điều này thường xảy ra do đào tạo không thích hợp, chuyển vị trí kém từ dự án này sang dự án khác và thiếu hệ thống kèm cặp để đào tạo nhân viên mới tuân theo qui trình.

Danh sách sau đây dựa trên “Bài học rút ra” từ trên 1,000 sai lầm rất tốn kém từ các dự án tôi đã kiểm điểm qua trong 10 năm qua. Tôi rút gọn chúng thành tám sai lầm đơn giản để người quản lí dự án có thể nhớ được:

1.    Bắt đầu dự án phần mềm với lịch biểu dự án được tạo ra qua đi ngược trở lại từ ngày hoàn thành.

2.    Thuê người lãnh đạo kĩ thuật chưa bao giờ xây dựng một hệ thống tương tự bởi vì thuê người có kinh nghiệm quá đắt.

3.    Không tuân theo phương pháp luận xác định bởi vì viết mã là mọi điều thực sự quan trọng.

4.    Không bận tâm với mô hình hoá nhưng xây dựng bất kì cái gì bạn cần khi nó tới.

5.    Khi vấn đề xảy ra, thuê thêm người phát triển để làm viết mã nhanh hơn.

6.    Bỏ qua kiểm thử vì dự án bị tụt sau lịch biểu.

7.    Thay đổi mã để hỗ trợ cho các yêu cầu mới mà không đưa người quản lí cấu hình tham gia.

8.    Mua sản phẩm phần mềm thương mại (COTS) để tiết kiệm tiền và chuyên biệt hoá nó nhiều để đáp ứng yêu cầu.

Để tránh các sai lầm tốn kém này, bạn cần tuân theo các qui tắc sau:
1. Không cắt góc, tuân theo phương pháp luận được xác định tốt và bám lấy nó. Trên đường dài, điều này sẽ trả giá thoả đáng.

2. Kiểm điểm từng cột mốc và hoạt động chính về tính chính xác và đúng đắn.

3. Giám sát cẩn thận việc quản lí cấp đỉnh hỗ trợ cho dự án. Phải chắc rằng người quản lí nhận biết về tiến bộ của tổ.

4. Thuê người lãnh đạo kĩ thuật có kinh nghiệm cho dự án.
Nếu bạn cứ muốn giữ chi phí thấp và vội vàng cho dự án xong, thì chất lượng sẽ bị tổn hại và rủi ro thất bại sẽ cao bất kể dự án được quản lí tốt đến đâu.

39.11 Hỏi: Tại sao mọi người không muốn cải tiến? Họ là ai? Làm sao thầy vượt qua được việc chống lại thay đổi?

Đáp: Có nhiều lí do mọi người không muốn thay đổi. Lí do then chốt là vẫn còn với “nguyên trạng” hay sợ “điều bất định”. Điển hình có bốn kiểu người chống lại thay đổi:

1)    Kiểu chống cự “A”: Những người này sẽ làm mọi điều trong quyền lực của họ để bác bỏ cải tiến bởi vì họ tin nó tạo ra gánh nặng phụ thêm cho họ. Họ bao giờ cũng có vài lí do tại sao cải tiến mới sẽ không có tác dụng và muốn mọi sự vẫn còn với cách làm mọi sự như cũ.

2)    Kiểu chống cự “B”: Những người này sẽ nói nhiều về cải tiến qui trình nhưng hầu như không có hành động. Họ giả vờ hỏi nhiều câu hỏi về cách nó thể được áp dụng cho khu vực của họ nhưng không đồng ý với bất kì cách tiếp cận nào. Logic của họ là “Nếu tôi không đồng ý với cách tiếp cận đó, tôi không phải thay đổi” hay “Nhếch môi có thể là việc thay thế tốt cho thay đổi”.

3)    Kiểu chống cự “C”: Những người này sẵn lòng chấp nhận bất kì cải tiến nào chừng nào họ không phải làm gì cả. Họ tin rằng cải tiến chỉ xảy ra cho ai đó khác nhưng không cho họ. Họ đòi hỏi công cụ tự động sẽ làm cải tiến cho họ.

4)    Kiểu chống cự “D”: Những người này có động cơ cải tiến chỉ nếu có sẵn giúp đỡ hay tài nguyên được cung cấp.

Để vượt qua chống cự lại thay đổi, bạn cần giáo dục mọi người về thay đổi qui trình và ích lợi nó có thể cung cấp cho mọi người. Bạn cũng cần đề nghị họ tham gia vào qui trình thay đổi để cho họ có thể “làm chủ” nó thay vì là ai đó khác – Quyền làm chủ là rất quan trong cải tiến qui trình. Bạn cần có cấp quản lí tham gia vào kiểm điểm các hoạt động trên cơ sở đều đặn để đảm bảo rằng nó sẽ xảy ra.

39.12 Hỏi: Tại sao chúng ta dùng mô hình ngoài cho cải tiến chất lượng thay vì mô hình được phát triển nội bộ?

Đáp: Phần lớn các mô hình cải tiến chất lượng đều so sánh hiệu năng của tổ chức theo mô hình bảng đo chuẩn hay chuẩn trong công nghiệp SEI/CMM đo hiệu năng của tổ chức theo mô hình CMMI. ISO 9000-2000 so sánh sự tuân thủ của tổ chức theo chuẩn ISO.  Bằng việc so sánh kết quả bên ngoài, tổ chức có thể nhận diện họ phù hợp với chuẩn công nghiệp tốt đến đâu và bằng việc biết sự khác biệt hay lỗ hổng họ có thể làm những điều chỉnh khi cần.

39.13 Hỏi: Khác biệt gì giữa cải tiến chất lượng phần mềm (SQI) và đảm bảo chất lượng phần mềm (SQA)?

Đáp: Đảm bảo chất lượng phần mềm (SAQ) là tập các hoạt động được thiết kế để đảm bảo rằng sản phẩm phần mềm tuân thủ theo chuẩn và qui trình được xác định của tổ chức. Cải tiến chất lượng phần mềm (SQI) nói tới mọi nỗ lực để làm tăng tính hiệu quả và hiệu lực của phát triển và bảo trì phần mềm trong đáp ứng cho mong đợi của khách hàng. Nó là qui trình liên tục để đạt tới hiểu biết tốt hơn về nhu cầu của khách hàng, để thiết kế các sản phẩm canh tân, và để quản lí sản phẩm và dịch vụ phần mềm chất lượng cao. Thành công của cải tiến chất lượng dựa trên hiểu biết của mọi thành viên của tổ chức liên quan tới nhu cầu của khách hàng của họ (nội bộ và bên ngoài). Duy trì việc hiểu biết đó yêu cầu liên tục đối thoại và thương lượng với khách hàng và đo sản phẩm và dịch vụ của người ta so với mong đợi của khách hàng.

39.14 Hỏi: Tại sao chúng tôi thực hiện cải tiến chất lượng theo nhiều bước nhỏ hơn là một bước lớn để giải quyết mọi vấn đề? Có quá cẩn thận ở đây không?

Đáp: Cải tiến chất lượng liên tục Continuous Quality Improvement (CQI) là nhiệm vụ không bao giờ chấm dứt. Người Nhật Bản gọi nó là “kaizen” hay hoạt động liên tục có sự tham gia của mọi người, từ công nhân cho tới quản lí cấp đỉnh hướng tới mục đích cải tiến chung. Qui trình này hội tụ vào khám phá và khử bỏ căn nguyên của vấn đề bằng việc tuân theo các bước tăng nhỏ, thay vì thực hiện một “hoạt động cải tiến khổng lổ để giải quyết mọi vấn đề”. Cải tiến nghĩa là làm cho mọi thứ tốt hơn, không phải là chữa cháy.

Khi chúng ta lấy cách tiếp cận khổng lồ để giải quyết vấn đề, chúng ta không bao giờ có được căn nguyên bởi vì mục đích chính là dập đám cháy hay vấn đề. Bằng việc tham gia vào cải tiến liên tục, chúng ta tìm kiếm và biết nguyên nhân nào làm cho mọi sự xảy ra và rồi dùng tri thức này để giảm bớt biến thiên, khử bỏ lỗi và lãng phí, loại bỏ hoạt động không có giá trị cho doanh nghiệp và cải tiến sự thoả mãn của khách hàng. Thay đổi là khó bởi vì nó bao gồm nhiều hơn chỉ là qui trình mà còn cả con người và thói quen của họ. Về điển hình, khối lượng qui trình chiếm 80% của mọi vấn đề trong khi khối lượng con người chiếm 20% còn lại nhưng thay đổi hành vi con người sẽ chiếm tới 80% nỗ lực.

39.15 Hỏi: Nhóm chúng tôi đang hỗ trợ E-business và qui trình của chúng tôi chạy với tốc độ internet. Chúng tôi nghĩ CMM không cung cấp giá trị gì cho những điều thay đổi nhanh chóng như phát triển web và E-Business. Thầy nghĩ sao?

Đáp: Tôi tin có nhiều việc nói quá và đơn giản hoá về E-Business. Để bắt đầu E-business, bạn cần một website và điều đó là dễ dàng và nhanh chóng. Dựng lên một website để giải quyết các giao tác kinh doanh không khó nhưng làm cho nó hiệu quả, đổi qui mô được và thành công là vất vả hơn nhiều. Điều khó khăn nhất trong E-business là tích hợp hàng trăm hệ thống, cả thừa tự và mới, vào trong một hệ thống cố kết và vững chãi để hỗ trợ cho cách thức mới làm kinh doanh. Những nỗ lực này về việc thay đổi qui trình doanh nghiệp; thiết lập quan hệ khách hàng và nhà cung cấp tốt hơn; có truy nhập dữ liệu hiệu quả và hiệu lực; kiểm soát quyền làm chủ dữ liệu; lập kế hoạch chiến lược phân phối, và thiết kế chiến thuật tiếp thị yêu cầu nỗ lực lớn và dứt khoát không phải là cái gì đó bạn có thể làm nhanh chóng được.

Bạn cần lập kế hoạch, giám sát, kiểm soát và quản lí điều CMM có thể giúp đỡ bằng việc thiết lập kỉ luật kĩ nghệ cho qui trình phát triển của bạn. Xây dựng trang web là không tốn kém nhưng nỗ lực doanh nghiệp trực tuyến qui mô đầy đủ chưa bao giờ là vấn đề chi phí thấp cả. Quyết định sai có thể dẫn tới tác động chính lên doanh nghiệp vì khách hàng có thể đổi đơn hàng hay chuyển sang đối thủ cạnh tranh chỉ bằng một “cú bấm chuột”. Xin đừng lẫn lộn việc có website với việc tham gia vào E-business. Phần lớn các websites chỉ là phần mềm quảng cáo và dứt khoát KHÔNG phải là E-Business.

39.16 Hỏi: Thầy có cho rằng kĩ nghệ phần mềm đã đạt tới mức “kĩ nghệ chuyên nghiệp” không?

Đáp: Xét ngành công nghiệp phần mềm như một toàn thể, tôi phải nói rằng có các tiến bộ lớn được thực hiện trong vài năm qua. Chẳng hạn, dưới dạng giáo dục, tôi thấy nhiều người phát triển phần mềm là các nhà chuyên môn thực sự, những người chắc chắn được giáo dục về nền tảng về cả khoa học máy tính và kĩ nghệ phần mềm. Trong một số công ti, ý tưởng khoa học trực tiếp đưa tới phát triển sản phẩm tiên tiến, và tiến bộ về phát triển các sản phẩm này bị giới hạn trực tiếp bởi tốc độ của khám phá khoa học.

Tuy nhiên, dưới dạng vấn đề qui trình phát triển phần mềm, chúng ta vẫn còn con đường dài phải đi. Mặc dầu có thân tri thức lớn đã được nghiên cứu cho thời gian bây giờ và điều đó đã được làm thành con đường của nó đi vào trong thực hành ở một số công ti như Mô hình tăng trưởng năng lực nhưng thực hành của những điều này vẫn còn bị hạn chế. Với hầu hết các tổ chức phần mềm, nó vẫn còn có tính thủ công hơn là kỉ luật kĩ nghệ. Vào lúc này, không có tri thức trung tâm, được chuẩn hoá như Sổ tay của Perry cho kĩ nghệ hoá học.

Chương trình kĩ nghệ phần mềm IEEE cho nhà chuyên môn, chứng danh kĩ nghệ phần mềm được chứng nhận, Thân tri thức về quản lí dự án là những cột mốc lớn nhưng việc dùng các công trình kì diệu này vẫn không đạt tới đa số người hành nghề, ít nhất là chưa.  So sánh với các môn kĩ nghệ khác như kĩ nghệ dân sự đã có từ vài nghìn năm, kĩ nghệ phần mềm còn thiếu sự dư thừa tri thức được luật hoá, phong phú mà là cần thiết cho bất kì bộ môn kĩ nghệ trưởng thành nào.

39.18 Hỏi: CMMI nhấn mạnh rằng chúng ta phải có chính sách tại chỗ cho thay đổi xảy ra. Chúng tôi có cần hình thành nên tổ để viết chính sách và thủ tục để thoả mãn yêu cầu của CMMI không?

Đáp: Tôi tin chính sách, thủ tục cho cải tiến qui trình là không quan trọng bởi vì thay đổi KHÔNG phải là về chính sách, chiều hướng mà là cấp quản lí sẵn lòng chấp nhận thay đổi và sẵn lòng lãnh đạo thay đổi. Chính sách, thủ tục, chuẩn và hướng dẫn chỉ là bổ sung cho quyền lãnh đạo của cấp quản lí bởi vì thay đổi là về chia sẻ viễn kiến và chia sẻ dự định và không có “quyền lãnh đạo” đúng tổ chức sẽ không thành công cũng giống như con thuyền không bánh lái.

Điều bản chất là có quyền lãnh đạo vì chính sách, thủ tục không là gì ngoài mảnh giấy và hầu hết những người quản lí có lẽ đằng nào cũng sẽ không nhìn tới chúng. Điều tổ chức cần là quyền lãnh đạo đúng với người quản lí có năng lực hiểu cải tiến là chìa khoá cho thành công dài hạn.

39.19 Hỏi: Ích lợi của việc đạt tới mức trưởng thành cao hơn là gì?

Đáp: Có nhiều ích lợi từ việc đạt tới các mức CMM cao hơn. Sau đây là một nghiên cứu từ Casper Jones về nghiên cứu năng suất phần mềm, xem xét 12,000 dự án phần mềm từ giữa 1983 và 2002. Jones thấy rằng với dự án có kích cỡ 5000 điểm chức năng, trưởng thành càng cao thì càng ít lỗi và hiệu quả loại bỏ lỗi càng tốt hơn.

Như có thể thấy, các mức 3, 4, và 5 là tốt hơn nhiều dưới dạng cả khối lượng lỗi tổng thể và mức độ hiệu quả loại bỏ lỗi. Một trong những ích lợi chính của việc đạt tới mức CMM cao hơn là kiểm soát chất lượng tốt hơn, điều đưa lại kết quả dự án tiên đoán được nhiều hơn.

English version

CMMI39

39.01 Question:

Why do you advocate customer satisfaction as the most important goal of process improvement? As technical organization should we focus on technical goal first?

Answer:

Software Process Improvement is NOT a technical exercise but a business strategy. In a competitive world, if you do not making progress, you are behind and no business can survive being behind for very long.

Technical people must understand that they play a very important part in the software business and in order to be successful they must provide products and services that continually exceed the customer’s expectations. If they only focus to compete technically with other software companies they are doomed for failure, because they only stay at the survival base line. The future success is depending upon the organization’s ability to go beyond the competition and focus consistently on exceeding the expectations of customers. When an organization can do this it creates an exceptional customer service that its competitors find difficult to match.

In the fast changing world of technology, the business rule has changed and it is no longer the ‘strongest or largest’ dominate but the ‘fastest’ will. Your success is dependent upon how fast you can create and implement new ideas to keep current customer happy, generate new customer and dominate the market. Every business must establish viable relationships with their customers because the services you provide are more important than the products you sell. This is a relative new concept but if you observe the trend in technology world, you will see that due to competition, most companies keep their products’ price very low but they make up by provide additional services. In other words, the product is only the ‘appetizer” but the service is the ‘real main course’. Services are where money being made not production, that is why customer satisfaction is the number one goal of every process improvement.

I strongly believe technical people must learn to think like business person and go beyond your customers’ expectations. Give your customers a choice on how they want to be served and you will see how fast your business grow. If you involve your customers in how they want to be treated, the relationship with them will grow stronger over time and each customer you have is one customer your competitor do not and that is the new rule for success of business in the 21st century.

39.02 Question

Why training is required for organization maturity? Why should we have to be trained when we already have a degree from university?

Answer:

A software organization can only mature when its workforce is highly capable. If you look back into history, human being have been here for about 7 million years but 90% of the advances in “technology” have occurred in the past 70 years and the internet which has tremendous impact in our life is only 7 years old. In this fast changing world, education is the key component that will discriminate who will succeed and who will not.

What you learned in university is only the foundation for your continuous learning that helps you to thrive and survive in this fast changing world. Technology today has a shelf-life about 5 years. That means obsolescence occurs at the rate about 20% per year or 20% of the workforce must learn new thing every year and within 5 years the entire organization must do something different from what they do today. Many people in the business world do not understand this, and their business model does not reflect this phenomenon, that is why we see so many organizations go out of business in the past few years including many giant corporations because they failed to adapt to changes.

The organizations that succeed in this highly competitive environment are the ones that recognize that constant learning and relearning is the only way to cope with changes and be competitive. Dealing with this kind of change requires the organization to have a strategy focusing on learning. If an organization do not learn new thing, it will die because the only survival is change because change provide stability. The longer the organization resists change, the faster it will die.

Actually, most software organizations deal with change on a daily basis. We all know software changes, requirements changes and software technology changes all the time. The key is competitive, who change faster will succeed but change has to be managed and the best way of managing changes is education.

Process improvement is about change and educates people to change. Leaders of process improvement must be people who actively committed to their own learning. Learning leaders attend training with or before their people. They understand the importance of education. They defines learning objectives, they commit resources to make it happen. They understand that the only asset that they have in the fast changing world is their people ability to learn faster than its competitors.

39.03 Question:

As a person who conducted a lot of CMMI assessments, what are the common problems in software organizations that you have observed?

Answer:

The number one common problem is unrealistic schedules. When faced with an unrealistic schedule, software teams often behave irrationally by producing very poor requirements or a superficial design so they can rush into coding then ended up with low-quality product, incorrect functions, seriously defective and to no one surprise – late delivery.

The number two common problem is so many requirements changes during coding phase. It seems that no one is able to manage requirements effectively. While the requirements normally change in the early phases, there is a time beyond which changes will cause disruption to the development. To meet unreasonable schedule and constantly changes at any cost sacrifices quality. When customers are able to demand such things and the organization allows it to happen, there is highly chance that the product will be costly and may not work well.

The third common problem is the notion of using Commercial off-the-shelf software (COTS) as a cost saving solution. It seems that very few people understand the concept of COTS integration or analyze their usage properly. There were so many researches in the industry sounding alarm on COTS integration as disaster time bomb. A COTS product that works perfectly in demonstrations, may crash when subjected to different configurations, higher data rates or even data-entry errors. The organization must test all COTS products thoroughly to expose previously untested conditions. If you have problem early, it will almost certainly be troublesome when used in production.

39.04 Question:

Why so many organizations are outsourcing their software oversea? Is it cost or quality?

Answer:

Some organizations outsourced for cost saving, other outsourced because of quality requirements. However, there is another factor that people rarely talk about: “The growing tired of the hero symptom”. Many organizations, especially the very low maturity always rely heavily on few individuals for whatever software skills they have to solve most of the problems. Whenever those people quit, the organizations lose that capability (or portions thereof). In order to keep them, the organization has to pay above-average rates to people with critical skills and this help create the “Hero” culture where heroes are always treated differently and rewarded with more money but this hurt the team spirit and the business in the long term.  In software business, teamwork is very important and if people do not work together toward a common goal, the product will likely have a lot of defects and schedule problems. No software company can compete successfully in the highly competitive world if their software development cost is too high and their products have lot of defects. That is why outsourcing has become popular where organization can take the business to where the skilled labor is willing, able and motivate to do high quality work with much lesser pay and put many “High paying heroes” out of business.

39.05 Question:

How do I implement change in an organization that failed several time in the past?

Answer:

This is a very challenging job. Each time an organization fails to improve, it increases the resistance to change and lower confidence in the people who advocate changes. In order to implement change, you must understand the organizational culture, the intricate unwritten rules of the organization that dictate people behavior. You need to understand the problem that you are trying to solve, why it happened or allowed to happen as well as the value or benefits of the proposed change. Change is very difficult – you must have a sponsor who is willing to support you and your work. You must understand the reward system of the organization since it does influence their behaviors. You must have communication skill to convince people to step out of their comfort zone and work with you. You must earn their trust and respect by logically plan each improvement task carefully and start slowly to increase their trust and respect.

39.06 Question:

If the project schedule is unreasonable or unrealistic then how do you know when a software project is competed?

Answer:

There are many views on when the software project is completed. The most popular one is when it is released to the customer. However, you probably know that releasing a defective product does not mean your project is done.

My advise is before starting a project, you need to ask yourself “What is critically important to ‘this’ project?” and “What problem(s) is this project trying to solve?”

By knowing the answers to these questions, you could determine how good the software product must be? You will face a difficult choice of balancing your idea with the project constraints such as schedule, resources, quality, costs etc.

Certainly, every project will have different constraints but you must weigh them against each other carefully to determine a priority of what is important and must be done first. You also need to determine what quality attributes must be implemented to support those features then use these data to draft an incremental release schedule with important features and associated quality criteria. You need to obtain support from your management and negotiate this with the customer to firm up a release schedule. Once you have established an approved projects release plan with tasks and success criteria identified, you must communicate this plan with your project team and begin tracking progress against this plan. From there on, each time you release the software, you know exactly how much work have been accomplished and when the software project is done.

39.07 Question:

What are the key measurements for higher CMMI level?

 Answer:

If your organization is already achieve at least CMMI level 3 by having defined processes for all project and organizational tasks, then you are ready for some measures to objectively see how good you are and to prepare to the next level. Measurement data can help an organization identify strengths, weaknesses and provide historical data for future planning. Following are some example to be used with a project.

Requirements Management

Planned/actual effort to perform the process

Number of Requirements change over time

Number of Non-compliances for this process

Project Planning and Management

Planned/actual effort to perform the process

Number of Non-compliances for this process

Risk Management

Planned/actual effort to perform the process

Number of Risks over time (increasing or decreasing)

Number of Risks mitigated due to risk management

Number of Risks open vs. closed

Number of Non-compliances for this process

Configuration Management

Planned/actual effort to perform the process

Number of CM-related defects

Number of Percentage of bad builds

Number of Non-compliances for this process

Process and Product Assurance

Planned/actual effort to perform the process

Number of audits

Number of Non-compliances for this process

Measurement and Analysis

Planned/actual effort to perform the process

Number of Measures collected but NOT used

Number of Non-compliances for this process

Requirements Development

Planned/actual effort to perform the process

Number of Derived requirements

Number of Requirements change over time

Number of Defects in requirements documents

Number of Non-compliances for this process

Design and Implementation

Planned/actual effort to perform the process

Number of Defects in design and code

Number of code changes per week

Number of Non-compliances for this process

Product Integration

Planned/actual effort to perform the process

Number of Defects found

Number of build results (e.g., #bad builds)

Number of Non-compliances for this process

Verification
Planned/actual effort/schedule to perform the process

Number of Defects found in verification

Number of Non-compliances for this process

Validation
Planned/actual effort to perform the process

Number of Test cases

Number of Defects found in validation

Number of or test pass/fail percentage

Number of actual test cycles vs. planned

Number of Rate of defect find vs. defect resolution

Number of Non-compliances for this process

Decision Analysis and Resolution

Planned/Actual effort to perform the process

Number of DARs performed per project

Number of Non-compliances for this process

Process Improvement

Planned/actual effort to perform the process

Number of processes used over time

Number of Defects found in process assets

Number of Non-compliances for this process

Training
Planned/actual effort to perform the process

Number of Training hours planned vs. received

Training evaluation scores

Number of Non-compliances for this process

39.08 Question

What is the different between architecture and design? What is architecture and why do we need architecture?

Answer:

The architecture of a system is the structure of the system, which consists of components, its externally visible properties and the relationships among them. Architecture is a set of decisions about the organization and structure of those components, the selection of them within context, the identification of their relationship and interfaces as well as their behaviors to satisfy a set of system requirements. Architecture is design, but not all design is architecture. The architecture focuses on the high level of a system such as major components and constraints without getting bogged down on technical details. Design focuses on the implementation of these components and produce artifacts such as design documents and code, according to a well planned architecture.

Architecture is important because it serves as the means to facilitate communication between stakeholders and developers.  It helps clarify requirements and design intention without getting bogged down into technical detailed level.  It supports management making decision on certain quality attributes by making these attributes visible as an external property of a system component.  It bridges the gap between requirements and implementation and allows designer to analyze components and views to prioritize design tasks and clarify implementation issues in early phase.  It decomposes a conceptual system requirements into identified components with externally visible property so non technical stakeholders can easily understand it.  It represents different views for different stakeholders without being constrained by design aspect thus help developers to analyze the system and determine their relationship early in the development phase.  By having a well documented architecture, it could save developers a lot of time in analyzing and understanding system implementation during maintenance phase.

39.09 Question

Why does organization need to have a standard methodology to satisfy level 3 requirements? Can we use whatever we have?

Answer:

One of the key factors in process improvement is the selecting of a well-defined methodology with solid project management and quality management. An organization can waste a lot of money and time by allowing people to select whatever methodology and tools to build software. This is a major problem that leads to significant difficulty when software integration occurs. It is impossible to put incompatible components create by variety of tools together. A standard methodology is needed to ensure that the organization follows good software engineering practices. A good software methodology can be in-house developed based on years of trial and error or can be purchased from a reputable vendor.

39.10 Question

How do I avoid past project mistakes and ensure success for my new project? Is there a lessons learned?

Answer:

Yes, there are plenty of lessons learned from past projects. In summary: There are four interdependent factors that can impact the success of any software project. They are: Cost, Quality, Schedule, and Risk. The logic is simple: you cannot build an inexpensively system of high quality very fast with no risk of failure. However, it is possible to build a system that is low risk and high quality i.e. the system must work well and successfully meet requirements but you must balance schedule and cost. A good software project manager must know how to estimate schedule and cost and adjust these factors accordingly.

Unrealistic schedule is the number one “Killer” of any software project and to avoid this, project manager must relies on historical data when estimate and negotiate with customer based on these facts and data.

Another key factor is the skills and knowledge of people on the project. Even a well-planned project can still fail because the implementation is not handled correctly due to the inexperienced staff. This usually happen due to inadequate training, poor transitioning from one project to other and the lack of a mentoring system to train new staff to follow the process.

The following list is based on “Lessons Learned” from over 1,000 very costly mistakes from projects that I have reviewed in the past 10 years. I reduced them to eight simple mistakes so software project managers can remember:

1.    Start software project with a project schedule created by working backwards from a completion date.

2.    Hire a Technical Lead that has never built a similar system because hiring experienced people is too expensive

3.    Does not follow a specific methodology because coding is all that is really important.

4.    Does not bother with modeling but build whatever you need as it comes.

5.    When problem happens, hire more developers to make coding go faster.

6.    Skip testing because the project is behind schedule.

7.    Change the code to support new requirements without involvement of configuration management people.

8.    Buy Commercial Off-The-Shelf (COTS) product to save money and customize it a lot to meet requirements.

To avoid these costly mistakes, you need comply with the following rules:
1. Do not cut corners, follow a well defined methodology and stick to it. In the long run, this will pay off.
2. Review each major milestones and activities for accuracy and correctness.

3. Carefully monitor top management support for the project. Make sure that managers are aware of the progress of the team.

4. Hire an experienced technical lead for the project.
If you insist on keeping costs low and hurrying the project along, then quality will suffer and the risk of failure will be high no matter how well the project is managed.

39.11 Question:

Why people do not want to improve? Who are they? How do you overcome the resistant to change?

Answer:

There are many reasons people do not want to improve. The key reasons are to remain with the “Status quo” or afraid of “The Uncertainty”. Typically there are four types of people who resisting change:

1)    Type “A” resistant: These people will do everything in their power to reject the improvement because they believe it creates extra burden for them. They always have several reasons why new improvements will not work and want things to remain with the old way of doing thing.

2)    Type “B” resistant: These people will talk a lot about process improvement but take very little action. They tend to ask a lot of questions about how it be applied to their area but disagree with any approaches. Their logic is “If I do not agree with the approach, I do not have to change” or “Lip service can be a good substitute for change”.

3)    Type “C” resistant: These people are willing to accept any improvement as long as they do not have to do anything. They believe that improvement only happens to somebody else but not them. They demand an automate tool that will do the improvement for them.

4)    Type “D” resistant: These people are motivated to improve only if help is available or resources are provided.

To overcome the resistant to change, you need to educate everyone on the change process and the benefit it can provide for everyone. You also need to ask them to participate in the change process so they can “Own” it rather than somebody else – Ownership is very important in process improvement. You need to have management involve in reviewing improvement activities on a regular basis to ensure that it will happen.

39.12 Question

Why do we use an external model for quality improvement rather than in-house developed model?

Answer:

Most quality improvement models compare organizational performance against a benchmarking model or a standard in the industry.  The SEI/CMM is measuring the performance of an organization against the CMMI model. ISO 9000-2000 compare the compliance of an organization to an ISO standard.  By comparing the results externally, the organization can identify how well they fare with the industry norm and by knowing the different or gaps they can make adjustments as necessary.

39.13 Question:

What is the different between Software Quality Improvement (SQI) and Software Quality Assurance (SQA)?

 Answer:

Software Quality Assurance (SAQ) is a set of activities designed to ensure that software product is complying with organizational defined standards and processes. Software Quality Improvement (SQI) refers to all efforts directed to increase effectiveness and efficiency of software development and maintenance in meeting customer expectations. It is a continuous process to achieve a better understanding of customer’s needs, to design innovative products, and to manage high quality software products and service. The success of quality improvement is based on the understanding of every member of the organization concerning the needs of their customers (internal and external). Maintenance of that understanding requires continuing dialogue and negotiation with the customer and measurement of one’s products and services against the customer expectations.

39.14 Question:

Why do we implement quality improvement in many small steps rather than a big step to solve all problems? Are we too careful here?

Answer:

Continuous Quality Improvement (CQI) is a never ending task. The Japanese call it “kaizen” or continuous activities that involve everyone, from workers to top-management toward a common improvement goal. This process focuses on discover and eliminate root causes of problems by following small incremental steps, rather than implementing one huge “improvement activity to solve all problems”. Improvement means making things better, not fighting fires. When we take a huge approach to solving problem, we never get to the root causes because the main goal is to put out the fire or the problem. By engaging in continuous improvement, we seek to learn what causes things to happen and then use this knowledge to reduce variation, eliminate defects and wastes, remove activities that have no value to the business and improve customer satisfaction. Change is difficult because it involves more than just process but also people and their habits. Typically process account for 80% of all problems while people account for the remaining 20% but changing people behavior will take about 80% of the efforts.

39.15 Question:

Our group is supporting E-business and our process runs at the internet speed. We do not think the CMM provides any valuable to things that change quickly like web development and E-Business. What do you think?

Answer:

I believe that there are a lot of exaggeration and oversimplification about E-Business. To start an E-business, you need a Web site and that is easy and fast. Putting up a Web site to handle business transactions is not difficult but to make it effective, scalable, and successful are much harder. The most difficult thing in E-business is the integration of hundreds systems, both legacy and new, into a cohesive and robust system to support the new way of doing business. These efforts of changing business processes; establish better customer and supplier relationships; have effective and efficient data access; control data ownership; plan distribution strategy, and design marketing tactics require significant efforts and definitely not something you can do quickly. You need to plan, to monitor, to control and manage which the CMM could help by establish an engineering discipline to your development process. Building a web site is not expensive but a full-scale online business effort is never a low-cost proposition. A wrong decision could lead to major impact in business because a customer can change order or switch to a competitor at the “click of a mouse”. Please do not confuse having a website with engaging in E business. Most websites are only brochure-wares and definitely NOT E-Business.

39.16 Question

Do you think software engineering has reached the level of “Professional engineering”?

 Answer:

In considering the software industry as a whole, I would have to say that there are significant progresses made in the past several years. For example, in terms of education, I see many software developers are indeed professionals who are certainly educated in the fundamentals of both computer science and software engineering. In some companies, scientific ideas directly lead to advanced product development, and progress on the development on these products is directly limited by the speed of scientific discovery.

However, In terms of software development process issues, we still have a long way to go. Although there is a large body of knowledge that has been researched for some time now and which has made its way into practice at some companies such as the Capability Maturity Models but the practice of these is still limited. To most software organizations, it is still more of a craft than an engineering discipline. At this time, there is no central, standardized knowledge such as Perry’s Handbook for chemical engineering. The IEEE software engineering curriculum for professional, the certified software engineering credential, the Software Project Management Body of Knowledge are great milestones but the utilization of these wonderful works has not reached the majority of practitioners, at least not yet.  Comparing to other engineering disciplines such as civil engineering which has been around for several thousand years, software engineering lacks the abundance of rich, codified knowledge that is necessary for any mature engineering discipline.

39.18 Question:

The CMMI insists that we must have policies in place for change to happen. Do we need to form a team to write policies and procedures to satisfy the CMMI requirements?

Answer:

I believe policies, procedures for process improvement is not important because change is NOT about policies, directions but management willing to accept changes and willing to lead the changes. Policies, Procedure, Standards, and guidelines are only supplement to management leadership because change is about share vision and share destiny and without true “leadership” organization will not be successful just like a boat without rudder.

It is essential to have leadership because policies, procedures are nothing but a piece of paper and most managers will probably disregard them anyway. What the organization need is true leadership with competent managers that understand improvement is a key for long term success.

39.19 Question:

What is the benefit of achieving higher maturity level?

Answer:

There are many benefits from achieving higher CMM levels. Following is a study from Casper Jones of the Software Productivity Research that examined 12,000 software projects between 1983 and 2002. Jones found that for project of 5000 function point in size, the higher the maturity the lesser defect and better defect removal efficiency.

As can be seen, levels 3, 4, and 5 are significantly better in terms of both overall volumes of defects and defect removal efficiency levels. One of the main benefits of achieving the higher CMM levels is better quality control, which pays off in more predictable project outcomes.