Những bài học từ một dự án phần mềm

Lượm lặt từ 1 blog trên net. Đọc cũng thấy hay, có thêm vài kinh nghiệm. Mà sao giống cái accounting mình đang làm vậy ta!

Đây là một câu chuyện có thật về một dự án phần mềm trải qua 4 năm và tiêu tốn 35 triệu USD mà không đem lại kết quả nào, và có kế hoạch kéo dài thêm ít nhất là 4 năm nữa. Dự án này diễn ra tại một công ty sản xuất dụng cụ thể thao vào hàng đầu trên thế giới, doanh thu khoảng hơn chục tỷ USD một năm, có trụ sở tại Tây Bắc Mỹ, tạm gọi là công ty N.

Trên phương diện là một study case, đây là một dự án khá độc đáo, và có thể dùng làm bài học điển hình về nhiều khía cạnh khác nhau của một dự án phần mềm, nhất là dành cho các doanh nghiệp sản xuất, dịch vụ đang có ý định ứng dụng công nghệ thông tin vào quy trình sản xuất và hoạt động của mình. Bài viết này hướng tới các đối tượng là

• Giám đốc Công nghệ Thông tin của doanh nghiệp (CIO – Chief Information Technology Officer)
  
• Quản trị Dự án (Project Manager)
  
• Kiến trúc sư phần mềm (Software Architect)
  

và sẽ phân tích qua các khía cạnh sau đây của dự án:

• Quy trình Quản lý (Management Process)
  
• Quy trình phát triển phần mềm (Software Development Process)
  
• Kiến trúc phần mềm (Software Architecture).
  

I. Giới thiệu tổng quát về dự án và tổ chức nhân sự

Dự án này là một dự án xây dựng một hệ thống enterprise software nhằm mục đích phối hợp (collaborate) hoạt động giữa các bộ phận trong hệ thống sản xuất giày dép (Footwear Production) của công ty N trên khắp thế giới, bao gồm:

• Hệ thống quản lý tài liệu Thiết kế giày dép (Footwear production documents), bao gồm tài liệu, bản vẽ mẫu giày dép, tài liệu về nguyên vật liệu, màu sắc, công nghệ ...
  
• Hệ thống quản lý dự án sản xuất (Project Management) để quản lý các dự án cho từng mẫu giày dép, từ thiết kế qua tới thử nghiệm, sản xuất, tiêu thụ ...
  

Hệ thống phối hợp hoạt động giữa các bộ phận khác nhau của công ty N, từ Bộ phận Thiết kế mẫu sản phẩm ở Bắc Mỹ đến các Nhà máy sản xuất giày dép đặt tại châu Á và các Nhà cung cấp nguyên vật liệu trên khắp thế giới, bao gồm:

• Lưu chuyển và quản lý một cách tự động việc đưa mẫu thiết kế từ Bắc Mỹ đến sản xuất thử nghiệm tại châu Á
  
• Thử nghiệm, thu thập thông tin về sản phẩm mẫu, cải tiến, sản xuất chính thức và tiêu thụ, tự động theo dõi hệ thống lưu chuyển nguyên vật liệu và vận tải sản phẩm.
  

Trước đây, công ty đã có thời kỳ sử dụng mainframe computer và COBOL, sau đó tới thời kỳ sử dụng Power Builder và SAP để quản lý một số phần rất nhỏ trong quy trình sản xuất. Hiện nay, công ty muốn xây dựng một hệ thống hoàn chỉnh, toàn diện với những công nghệ mới hiện nay.

Công nghệ được sử dụng trong dự án là J2EE và Oracle database. Application Server là Apache Webserver kết nối với Tomcat servlet engine. Dự án này không phải được xây dựng hoàn toàn từ đầu (build from scratch), mà dựa trên một enterprise platform khá nổi tiếng trong loại phần mềm PDM/PLM (Product Data Management/Product Lifecycle Management) và Enterprise Collaboration Software, có tên là Windchill. Windchill là một sản phẩm J2EE của công ty PTC (Parametric Technology Corp.), trụ sở chính tại bang Massachusetts, Mỹ. Đây là một phần mềm nền tảng (platform), cung cấp toàn bộ cơ sở hạ tầng và các chức năng căn bản cho một hệ thống enterprise software.

Các công ty sản xuất có nhu cầu xây dựng B2B enterprise software để phối hợp hoạt động giữa các bộ phận khác nhau trong công ty, hoặc với các công ty khác, với các nhà cung cấp và khách hàng thường sẽ ít khi xây dựng từ đầu, mà sẽ mua Windchill (hoặc các sản phẩm tương tự, ví dụ như Matrix One, EDS, SAP, People Soft, IBM Dassault ...) về, cải biến và cài đặt thêm (customization) trên platform có sẵn để phù hợp với đặc điểm riêng của doanh nghiệp, và đưa vào sử dụng. Hiện có khoảng hơn 3000 công ty sản xuất lớn trên thế giới đang sử dụng Windchill để điều hành hoạt động của toàn bộ doanh nghiệp, trong đó có nhiều tên tuổi đáng kể như NASA, Boeing, Airbus, Lockheed Martin, Rolls Royce, DaimlerChrysler, Ferrari, Toyota, Bose ... Mỗi dự án triển khai Windchill cho một doanh nghiệp kéo dài vào khoảng từ 6 tháng đến 2 năm (Một thời gian tương đối ngắn cho việc triển khai Enterprise Software, bao gồm cài đặt hệ thống, cải biến và cài đặt thêm, performance tuning, administrator training, user training, chạy thử nghiệm và chạy chính thức).

Từ 4 năm nay, Công ty sản xuất hàng thể thao N cố gắng sử dụng Windchill làm nền cho hệ thống enterprise software của mình, và đã chi hơn 35 triệu USD cùng nhiều nhân tài vật lực vào dự án này..

Bộ phận Sản xuất giày dép (Footwear Production) của công ty N có bộ phận IT riêng của mình, nhưng để triển khai dự án, công ty thuê các chuyên gia tư vấn về Công nghệ thông tin để tiến hành. Đây là cách làm việc rất phổ biến ở Mỹ, vì việc phát triển phần mềm hoặc cài đặt các hệ thống mới chỉ mang tính chất thời vụ, nhưng lại đòi hỏi trình độ chuyên môn cao. Mặt khác, khi hệ thống đã hoàn thành, thì việc vận hành và bảo trì chỉ đòi hỏi trình độ chuyên môn tương đối thấp. Vì thế các công ty sản xuất và dịch vụ chỉ duy trì một đội ngũ IT với trình độ vừa phải, lương thấp để bảo trì và vận hành hệ thống, và khi có nhu cầu làm mới, thì sẽ thuê chuyên viên tư vấn với giá cao, nhưng chỉ trong thời gian thực hiện dự án. Cách làm này giúp cho công ty tiết kiệm chi phí hoạt động, và bảo đảm tính chuyên môn hóa cao (Giả sử là công ty thuê được chuyên gia tư vấn tốt, và tổ chức làm việc theo nhóm một cách có hiệu quả).

Trong quản lý dự án, công ty N sử dụng

1. Một Quản trị dự án (Project Manager) là nhân viên chính thức của N (Permanent full time employee).
   
2. Các nhân viên trong Dự án được chia làm ba nhóm chính:
   

• Nhóm Chuyên gia sản xuất giày dép (Domain expert – Trong trường hợp này, domain là footwear production. Nhóm còn gọi là Footwear Expert)
  
• Nhóm Phân tích Hệ thống kinh doanh (Business System Analyst)
  
• Nhóm Chuyên gia phần mềm (Application Engineer).

Nhóm Chuyên gia sản xuất giày dép là những nhân viên chính thức của công ty N, công việc hàng ngày là thiết kế mẫu giày dép, giao dịch với các nhà máy ở châu Á và công ty cung cấp nguyên vật liệu trên khắp thế giới, là những người sẽ cung cấp thông tin về quy trình, phương pháp và logic làm việc của công việc footwear production cho Dự án.

Nhóm Chuyên gia Phần mềm (Application Engineer) có nhiệm vụ dựa trên những thông tin về quy trình, phương pháp và logic làm việc để xây dựng phần mềm tự động hóa những công việc đó. Trong nhóm này, các vị trí Senior đều là các chuyên viên tư vấn, và ở những vị trí lập trình, có xen lẫn những nhân viên tư vấn có kinh nghiệm và nhân viên chính thức của N.

Trong những dự án phức tạp, đòi hỏi có sự giao tiếp chặt chẽ, chính xác giữa nhóm cung cấp thông tin về sản xuất, dịch vụ với nhóm làm ra phần mềm, thường sẽ có một nhóm trung gian gọi là Nhóm Phân tích Hệ thống sản xuất (Business System Analyst), đóng vai trò trao đổi thông tin giữa Nhóm Domain Expert và Nhóm Application Engineer. Trong Công nghệ Phần mềm, thông thường những chuyên gia sản xuất, dịch vụ và những Chuyên gia Phần mềm nhìn công việc và hệ thống từ những góc nhìn khác nhau, và sử dụng những thứ ngôn ngữ khác nhau để mô tả về hệ thống. Do đó, những chuyên gia trong nhóm Phân tích Hệ thống sản xuất phải vừa có kiến thức về sản xuất lẫn kiến thức về làm phần mềm (về độ am hiểu chuyên môn sâu thì không cần thiết phải như các nhóm Chuyên gia Sản xuất và Chuyên gia Phần mềm, nhưng phải am hiểu các khái niệm cơ bản và thuật ngữ) để có thể làm trung gian giữa hai nhóm. Trong nhóm Phân tích Hệ thống sản xuất có cả chuyên viên tư vấn lẫn nhân viên chính thức của công ty N.

Điểm yếu nhất trong ba nhóm của công ty N là Nhóm Phân tích Hệ thống sản xuất. Nhóm này (hoàn toàn trái ngược với yêu cầu) không có một khái niệm gì cả về sản xuất giày lẫn về sản xuất phần mềm. Điều này làm nảy sinh ra tình trạng hoạt động không hiệu quả trong quy trình quản lý và quy trình làm phần mềm.

II. Những điểm yếu trong quy trình quản lý (Management Process)

Công ty N không có một phương pháp chuẩn (methodology) nào trong việc quản lý dự án phần mềm. Dựa trên quá trình thu thập thông tin, chưa xây dựng thành Use Case, chưa qua phân tích và làm specification, mới chỉ dựa trên một vài mục đích, nhận định, công ty đã đưa ra một số giới hạn về thời gian, nhân lực, ngân sách, mà không có căn cứ cụ thể.

Về mặt quản lý, công ty hoàn toàn không có phương pháp cụ thể về việc phân chia trách nhiệm, quyền hạn giữa các nhóm và các thành viên trong các nhóm. Điều này dẫn đến tình trạng có những lúc công việc bị ách tắc hoặc sai lệch, nhưng không tìm được nguyên nhân chính một cách kịp thời, và không quy được trách nhiệm cho đối tượng nào cần phải sửa chữa hoặc có hình thức xử lý.

Công ty cũng hoàn toàn không có một hệ thống hợp lý để theo dõi quá trình làm việc, theo dõi về ngân sách và tiến độ để có thể điều chỉnh cho phù hợp. Điều này dẫn đến các giai đoạn của dự án thường xuyên bị chậm deadline và vượt quá ngân sách dự tính.

Do không có Phương pháp chính thức (formal methodology) để đánh giá về khả năng, trình độ cũng như tốc độ làm việc của từng nhóm và từng nhân viên trong dự án, và do không có đủ trình độ về Chuyên môn Sản xuất giày dép và Chuyên môn về Công nghệ Phần mềm để có thể nhận định được về năng lực và kết quả làm việc thực sự của nhân viên, nên Quản trị Dự án (Project Manager) và Ban Lãnh đạo Dự án thu thập thông tin bằng cách nói chuyện với nhân viên này trong dự án để tìm hiểu về nhân viên kia, họp với nhóm này để lấy thông tin về nhóm kia trong dự án, và dẫn đến những đánh giá chủ quan, cảm tính và thường không chính xác. Sự đời ở đâu cũng thế, những kẻ nói giỏi và những kẻ hay nói thường là làm ăn không ra gì, và thông tin thường là sai lệch. Vì thế Ban Lãnh đạo Dự án hoàn toàn không có một nhận thức chính xác về trình độ nhân viên, tiến trình của dự án, và không nắm bắt được chi tiết những gì đang thực sự xảy ra trong dự án.

Công ty N thực hiện khâu tổ chức thực hiện dự án một cách hết sức máy móc. Hàng tuần, có những cuộc họp cố định vào thứ hai để báo cáo tiến độ công việc, vào thứ ba để xem xét thiết kế phần mềm và thứ năm để trao đổi thông tin giữa các nhóm Chuyên gia Sản xuất, Chuyên gia Phân tích Hệ thống Sản xuất và Chuyên gia Phần mềm. Ngoài ra còn rất nhiều cuộc họp phụ khác. Một tuần làm việc có 40 tiếng, đã có một vài lần tôi phải tham gia họp 30 tiếng một tuần, và có một vài ngày tôi phải ngồi 6 tiếng trong phòng họp.

Mặc dù có cuộc họp để báo cáo tiến độ công việc, nhưng vì thiếu một phương pháp tốt để theo dõi, phân tích, đánh giá tình hình và phân chia trách nhiệm, nên những cuộc họp này chỉ giúp cho Quản trị Dự án nhận ra những gì đã làm được, những gì còn lâu mới xong, mà không biết tại sao, có cách nào làm nhanh hơn không, đâu là vị trí khó khăn tại thời điểm này của dự án ...

Cuộc họp về xem xét thiết kế phần mềm cũng không có tác dụng gì bổ ích mấy, vì công ty N đã tốn 4 năm và chi phí hơn 35 triệu USD để xây dựng một hệ thống phần mềm có nhiều vấn đề về mặt thiết kế (tôi sẽ phân tích kỹ hơn trong phần liên quan tới Kiến trúc phần mềm). Đại khái cũng như trong xây dựng, khi người ta đã vẽ ra một thiết kế có vấn đề và xây nên một vài phần móng có vấn đề, thì việc xây thêm và gia cố cũng khó mà dẫn đến một kiến trúc gì thực sự tốt và có giá trị sử dụng được. Vì thế, các cuộc họp này chỉ nhằm đưa ra những giải pháp chắp vá, tạm thời để tạo ra những chức năng có liệt kê trong danh sách mục đích xây dựng phần mềm.

Nhưng những cuộc họp về trao đổi thông tin giữa các nhóm làm việc mới thực sự là thảm họa. Có một quy định hết sức máy móc là Nhóm Chuyên gia Sản xuất chỉ được nói chuyện với Nhóm Phân tích Hệ thống sản xuất, rồi nhóm này sẽ đi nói lại với Nhóm Chuyên gia Phần mềm. Nhóm Chuyên gia Phần mềm cần hỏi thông tin gì, cũng chỉ được phép nói chuyện với Nhóm Chuyên gia Phân tích, rồi nhóm này sẽ đi hỏi Nhóm Chuyên gia Sản xuất và truyền đạt lại.

Trong khi đó, như đã nói, Nhóm Chuyên gia Phân tích lại bao gồm những người không có khái niệm gì về cả Sản xuất giày lẫn Sản xuất Phần mềm, nên Nhóm Phân tích chỉ đóng vai trò như Nhóm đưa tin giữa hai nhóm Chuyên gia Sản xuất và Chuyên gia Phần mềm. Hơn nữa, do không có trình độ chuyên môn, nên nhóm Phân tích không đọc được Use Case Diagram để trao đổi với nhóm Phần mềm, mà cũng không biết các thuật ngữ như size-range, color-bucket ... để nói chuyện với nhóm Sản xuất. Như vậy, hoàn toàn không có một thứ ngôn ngữ chính xác để trao đổi về mặt phân tích yêu cầu, thu thập thông tin và thiết kế hệ thống cho toàn bộ dự án. Ngoài ra, cách tổ chức trao đổi thông tin cũng kỳ quặc: Trong thứ năm của một tuần, Nhóm Phần mềm họp với Nhóm Phân tích, bàn đi bàn lại một hồi, rút ra là có một số vấn đề sau đây chúng ta chưa biết. Nhóm Phân tích sẽ đem vấn đề đó đi hỏi nhóm Sản xuất vào cuộc họp thứ năm tuần kế tiếp. Và trong cuộc họp ngày thứ năm của tuần tiếp sau nữa, Nhóm Phân tích sẽ đem câu trả lời về cho Nhóm Phần mềm. Như vậy là mất 3 tuần cho một câu hỏi và trả lời, và việc này diễn ra trong 4 năm nay, mặc dù đi bộ từ khu nhà của Nhóm Phần mềm xuống Nhóm Sản xuất mất đúng 3 phút, và tất cả các nhân viên trong dự án đều có điện thoại và e-mail. Đó là chưa kể đến sự thiếu hiểu biết chuyên môn của Nhóm Phân tích dẫn đến việc trình bày sai, thiếu phương pháp ghi chép tài liệu (documentation methodology), nên có những vấn đề phải hỏi đi hỏi lại.

Có hai trường hợp điển hình. Một lần có một chuyên gia phần mềm hỏi “Trong thiết kế mẫu, người ta quản lý cỡ giày như thế nào, theo giá trị chính xác (exact size, nghĩa là từng con số 5,6,7,8,9 ..), hay theo khoảng cỡ (size-range, tức là 5-7, 8-10 , 11-12 ...). Sau vài tuần trao đổi đi, trao đổi lại, Nhóm Phân tích không đưa ra được câu trả lời cụ thể. Chuyên gia phần mềm đành phải làm một câu hỏi có nhiều chọn lựa (multi-choice question), gồm có a) Quản lý theo giá trị chính xác, b) Quản lý theo khoảng cỡ, c) Quản lý theo kiểu khác, đề nghị viết rõ, rồi đưa cho Nhóm Phân tích đi hỏi Nhóm Sản xuất, đề nghị khoanh vào a hoặc b hoặc c, thì mới có câu trả lời là a).

Nếu không có quy định quá máy móc là Nhóm Phần mềm không được giao tiếp với Nhóm Sản xuất , hoặc nếu Nhóm Phân tích biết chuyên môn cơ bản và biết sử dụng thuật ngữ, thì tình trạng không đến nỗi thế.

Trường hợp thứ hai là có lần có chuyên gia phần mềm hỏi: “Về mặt quản lý vận tải, trong một lần gửi hàng, có thể có hàng hóa của nhiều đơn đặt hàng được gửi cùng một chuyến hay không?”.

Trước đây công ty N không có hệ thống theo dõi vận tải, mọi giao dịch được làm bằng giấy tờ. Thay vì đi hỏi trực tiếp những người từ trước đến nay vẫn theo dõi việc vận tải bằng sổ sách, Ban Quản trị Dự án họp nhau đoán già đoán non, và cho rằng việc theo dõi nhiều đơn đặt hàng khác nhau trong một chuyến vận tải là quá khó(?), nên cho rằng phần mềm chỉ cần theo dõi mỗi chuyến vận tải là một đơn đặt hàng thôi, bất chấp ý kiến của Nhóm Phần mềm là về mặt công nghệ không có gì khó, và ý kiến của Nhóm Sản xuất là trước nay vẫn có nhiều trường hợp một chuyến hàng chứa nhiều đơn đặt hàng. Sau khi Nhóm Phần mềm cài đặt xong Hệ thống theo dõi Đơn đặt hàng và Vận tải, công ty N cử một nhóm 3 người sang châu Á để đưa cho các nhà máy ở châu Á sử dụng thử và thu thập ý kiến phản hồi, thì mới nhận ra là phải làm hệ thống theo dõi nhiều đơn đặt hàng khác nhau trong một chuyến vận tải. Kết quả là toàn bộ công việc trong hai tháng trời phải bỏ đi hoàn toàn, làm lại từ đầu.

Một hiện tượng khác điển hình cho sự thiếu cả Kiến thức lý thuyết lẫn Kinh nghiệm thực tế trong Quản lý Dự án phần mềm của Ban Lãnh đạo Dự án là mỗi khi dự án chậm so với thời hạn, Ban Lãnh đạo Dự án lại thuê thêm lập trình viên vào, nhằm cứu vãn tiến độ công việc. Bất kỳ một nhân viên quản trị dự án phần mềm nào khi mới tập tọng vào nghề cũng phải nghe qua định luật Brooks: “Thêm người vào một Dự án phần mềm bị chậm thì chỉ làm cho nó chậm hơn.” Định luật này được Brooks chứng minh bằng mô hình toán học một cách chính xác, và đã được kiểm nghiệm qua rất nhiều dự án phần mềm trong thực tế.

III. Những điểm yếu trong quy trình phát triển phần mềm (Software Development Process)

Công ty N sử dụng một Quy trình Phát triển phần mềm chuẩn trong Công nghệ Phần mềm là Rational Unified Process (RUP). Hiện tại, trong ngành Công nghệ Phần mềm, đại đa số các Dự án Phần mềm lớn và phức tạp đều sử dụng RUP làm Quy trình Phát triển phần mềm. Quy trình này gồm có 4 giai đoạn:

• Khởi đầu (Inception)
  
• Dự thảo chi tiết (Elaboration)
  
• Thực hiện xây dựng (Construction)
  
• Chuyển giao (Transition).
  

Nhưng một quy trình tốt không bảo đảm cho sự thành công của một dự án phần mềm. Phương pháp tiến hành các bước trong các giai đoạn của một dự án là một yếu tố hết sức quan trọng. Trong toàn bộ ba giai đoạn đầu của dự án, công ty N đều phạm phải các sai lầm hết sức cơ bản. Giai đoạn bốn (Transition) chưa bao giờ có, vì chưa bao giờ có sản phẩm chính thức đưa vào sử dụng, nên chưa có sai lầm. Suốt 4 năm từ lúc bắt đầu Dự án cho đến nay, sau khi tiêu tốn hơn 35 triệu USD, công ty N mới đưa ra được một vài kết quả thử nghiệm:

- Hệ thống Quản lý Vật liệu (Material Management). Nghe tên thì như vậy, nhưng thực chất đây là một hệ thống cho phép ghi đối tượng về vật liệu vào database, thêm, xóa, sửa, tìm kiếm ..., nghĩa là các chức năng thông thường của một chương trình quản lý cơ bản bất kỳ cái gì.

- Hệ thống Quản lý màu sắc (Color Management) : Đây là một hệ thống cho phép thêm, xóa, sửa, tìm kiếm màu sắc trong database.

- Hệ thống quản lý Dự án (Project Management), thực ra chỉ là một hệ thống tạo thêm, xóa, sửa, tìm kiếm tài liệu cho các dự án, chứ không có quản lý tiến trình (workflow management) và theo dõi tiến độ dự án (project progress tracking), đang trong giai đoạn chạy thử nghiệm và có đầy lỗi.

Theo Blog HoangThanhTu

Posted in: case-study