Lời khuyên cho người quản lí dự án phần mềm
Sau đây là đối thoại giữa người quản lí cấp cao (SM) người đưa ra lời khuyên cho người quản lí dự án phần mềm (PM)
SM: Anh có biết cách giữ việc làm của mình trong cuộc khủng hoảng tài chính này khi nhiều công ti đang giảm người không?
PM: Ông chủ của tôi sẽ giữ tôi nếu dự án của tôi có tác dụng tốt. Tuy nhiên tôi không biết tại sao một số dự án thành công và số khác thất bại. Tôi đoán đó là vấn đề may mắn. Nếu tôi may, tôi có thể giữ được việc của mình.
SM: Các dự án hầu hết thất bại là do thiếu lập kế hoạch và quản lí chứ không phải là do may mắn. Phần lớn mọi người bỏ qua việc lập kế hoạch và nhảy vào viết mã cứ nghĩ rằng họ sẽ làm tốt bởi vì họ tin “phần mềm là mã”. Nhiều người thậm chí không để thời gian xác định họ phải giải quyết vấn đề gì. Anh không thể dựa vào may mắn để giữ việc của mình được.
PM: Vậy tôi phải làm gì để đảm bảo dự án thành công?
SM: Có qui trình phần mềm mà mọi người quản lí phần mềm phải tuân theo. Viết mã là điều dễ làm nhất vì hầu hết mọi người đều được đào tạo viết mã nhưng không được đào tạo về qui trình phần mềm. Công việc phần mềm còn nhiều hơn viết mã; thực tế pha viết mã chỉ chiếm khoảng 20% của tổng công sức. Đừng phạm phải sai lầm như người khác bằng việc để quá nhiều công sức vào viết mã; điều đó sẽ làm phí thời gian của bạn, để lại cho bạn nhiều vấn đề.
PM: Qui trình phần mềm là gì?
SM: Qui trình phần mềm là tập các bước bạn phải tuân theo. Là người quản lí dự bán bạn cần:
Đánh giá nhu cầu nghiệp vụ của khách hàng.
Xác định các yêu cầu và trắc nghiệm với khách hàng và người dùng.
Xây dựng tổ dự án tốt.
Nhận diện qui trình chuẩn và cách đo phần mềm.
Tạo ra bản kế hoạch dự án với các ước lượng.
Thương lượng với khách hàng
Đào tạo tổ dự án và quản lí họ tương ứng.
PM: Anh ngụ ý gì bởi “đánh giá nhu cầu nghiệp vụ của khách hàng”?
SM: Để bắt đầu, bạn cần nhìn vào nhu cầu nghiệp vụ của khách hàng. Dự án chỉ thành công khi nhu cầu của khách hàng và người dùng được đáp ứng. Đây là điều quan trọng nhất cho các dự án của bạn bởi vì nhu cầu của họ chỉ đạo quá trình phát triển của bạn sẽ là cái gì. Bạn phải hiểu vấn đề của họ trước khi bạn có thể đi tới giải pháp. Bên cạnh đó, bạn cần biết khách hàng của mình (người trả tiền cho sản phẩm) và người dùng (người dùng sản phẩm) và thảo luận mọi điều với họ, xây dựng mối quan hệ với họ và để họ biết rằng bạn ở đó để hỗ trợ cho họ. Bạn phải nhớ rằng họ là người chung cuộc sẽ trả tiền cho công sức của bạn và hỗ trợ bạn nếu mọi sự không trôi chảy.
PM: Vâng. Giả sử tôi có quan hệ tốt với họ và hiểu nhu cầu của họ, tiếp đó là gì?
SM: Xác định yêu cầu cho dự án. Cái vào cho qui trình này nên tới từ khách hàng, người dùng, người phân tích hệ thống và người quản lí. Bắt đầu bằng việc hiểu đầy đủ mọi điều bạn phải làm kể cả những điều bạn phải chuyển giao cho họ. Nhiều người nghĩ chuyển giao duy nhất là sản phẩm phần mềm hay mã. Điều đó là không đúng, có nhiều điều hơn như tài liệu yêu cầu, tài liệu kiến trúc, tài liệu giao diện người dùng, tài liệu thiết kế, trường hợp kiểm thử v.v. Tất cả những điều này yêu cầu nhiều công việc cho nên điều tốt nhất cần làm là hỏi khách hàng của bạn những thứ gì họ cần và họ mong đợi chúng khi nào? Trao đổi là mấu chốt trong pha sớm của dự án. Đây là chỗ bạn phải dành ít nhất 20% nỗ lực để có được yêu cầu đúng.
PM: Anh có cho rằng 20% là quá nhiều không. Nó gần như bằng công sức viết mã.
SM: Tôi muốn dành nhiều thời gian cho pha yêu cầu hơn bất kì pha nào khác. Yêu cầu chỉ đạo mọi thứ, yêu cầu sai nghĩa là thất bại dự án. Đây là lúc bạn phải đầu tư nhiều công sức để hiểu điều khách hàng muốn và điều họ mong đợi. Không nắm được yêu cầu là nhân tố thông thường nhất trong thất bại dự án. Phần lớn mọi người dành ít hơn 5% công sức trong yêu cầu nhưng lại nhiều hơn 50% công sức cho viết mã và đó là lí do tại sao nhiều dự án thế đã thất bại. Nếu họ không hiểu yêu cầu, họ sẽ xây dựng sản phẩm sai và rồi phải sửa nó với chi phí tốn hơn và làm cho khách hàng rất bực bởi vì họ không có được cái họ muốn theo cách đúng hạn.
PM: Vâng, tôi nghĩ tôi hiểu quan điểm của anh vậy thì cái gì tiếp?
SM: Bước tiếp là xây dựng tổ dự án tốt. Tôi thích việc “Xây dựng” và bởi vì phải mất thời gian xây dựng tổ tốt. Bạn phải hiểu tri thức và kĩ năng của tổ mình để cho bạn có phân công công việc tương ứng cho họ. Bạn cần xây dựng tổ tốt với các vai trò và trách nhiệm được xác định rõ ràng để cho mọi người đều đảm nhiệm. Luôn lưu tâm, mọi dự án mới đều là cơ hội mới để cải tiến mọi thứ và bao giờ cũng có cơ hội thành công tốt hơn khi mọi người hiểu điều họ được giả định sẽ làm.
PM: Điều đó toàn là tốt thôi, nhưng làm sao anh tìm ra thời gian để hoàn thành tất cả những điều này? Tôi chỉ là một người và với đủ mọi thứ hiện tại đã làm tôi bận bịu hết thời gian rồi.
SM: Xây dựng tổ dự án tốt là nhân tố then chốt cho thành công dự án. Lựa đúng người thông thạo và có tâm trí đủ cởi mở để làm việc cùng nhau bao giờ cũng là thách thức nhưng đó là việc của người quản lí dự án và bạn phải lựa chọn cẩn thận. Mọi người trong tổ phải có năng lực kĩ thuật, kiên nhẫn, có kĩ năng làm việc tổ tốt, và có đủ kinh nghiệm để vận hành thành công. Bên cạnh những trách nhiệm trên, tổ này sẽ thực hiện các nghĩa vụ sau:
Hiểu nhu cầu của khách hàng.
Thiết lập mục đích, chiến lược và kế hoạch hành động.
Cung cấp ước lượng chi phí cho nhiệm vụ của họ.
Đào tạo và hỗ trợ người khác.
Cải tiến qui trình của họ bằng việc dùng các điều tra thoả mãn của khách hàng.
Bên cạnh tri thức chuyên gia của họ, bạn cần hỗ trợ và cam kết của họ để giúp bạn trong kiểm nghiệm yêu cầu. Tôi sẽ dành nhiều công sức vào việc xây dựng tổ bởi vì tổ tốt nghĩa là bạn có cơ hội thành công tốt hơn.
PM: Anh nhắc tới “Nhận diện qui trình chuẩn và độ đo.” Chúng ta làm điều đó thế nào?
SM: Bạn phải nhận diện qui trình chuẩn mà tổ của bạn phải tuân theo và tập các độ đo phần mềm. Qui trình chuẩn phụ thuộc vào yêu cầu của khách hàng dù chúng được xác định tốt và được làm tài liệu hay chúng vẫn còn thay đổi, cho nên bạn có thể lựa các phương pháp và qui trình thích hợp tương ứng. Bạn có thể lựa vòng đời thác đổ, vòng đời gia tăng đưa ra, hay bạn có thể muốn lựa phương pháp mau lẹ. Từng vòng đời đều yêu cầu qui trình khác nhau. Là người quản lí dự án, bạn phải biết bạn đang ở đâu và bạn đang làm tốt đến đâu trong toàn bộ qui trình. Bạn phải chứng tỏ được quyền lãnh đạo và kĩ năng quản lí của mình cho ông chủ của mình để họ biết họ sẽ thu được gì với tiền họ bỏ ra. Để có an ninh nghề nghiệp của bạn, bạn cần độ đo để chứng minh cho cấp quản lí rằng bạn đang quản lí dự án và có dữ liệu để chứng minh về nó. Độ đo giúp bạn tìm cái gì sai và cách sửa nó. Để tôi cho bạn một ví dụ, thử nghĩ về dự án phần mềm như bệnh nhân ở bệnh viện. Không bác sĩ nào sẽ chữa cho bệnh nhân mà không biết mọi triệu chứng. Tương tự vậy, làm sao bạn quản lí được dự án mà không biết các vấn đề của dự án? Độ đo thu thập dữ liệu cho bạn vì bạn cần biết tình trạng của dự án để có hành động sửa chữa. Tuy nhiên, độ đo phải không có tính đe doạ cho tổ. Đừng dùng chúng để đánh giá, phán xét cá nhân; chỉ dùng độ đo cho cải tiến qui trình và giám sát liên tục dự án của bạn. Bằng không, tổ chỉ báo cáo điều họ nghĩ bạn muốn thấy và điều đó là vô dụng. Bạn phải yêu cầu dữ liệu trung thực, chính xác, và nhất quán từ tổ.
PM: Tổ chức của tôi có nhiều vấn đề phần mềm mà có lẽ có thể có lợi từ độ đo. Nhưng làm sao tôi yêu cầu họ ước lượng và thu thập dữ liệu khi họ rất bận rộn làm việc cho dự án? Ông chủ của tôi nhấn mạnh vào việc dự án phải làm đúng thời gian và trong phạm vi ngân sách nào đó.
SM: Làm sao bạn biết lịch biểu đã cho là đúng nếu bạn không ước lượng công việc của bạn? Là người quản lí dự án, bạn phải chia nhỏ các yêu cầu thành nhiều nhiệm vụ và phân công chúng cho thành viên tổ. Từng thành viên đều phải ước lượng sẽ mất bao lâu thời gian để hoàn thành nhiệm vụ được phân công và báo cáo cho bạn. Bạn có thể tổ hợp tất cả những ước lượng này vào trong ước lượng lịch biểu dự án và so sánh với lịch biểu đã cho. Nếu ước lượng của bạn sánh đúng với lịch biểu đã cho, thế thì nó là hoàn hảo nhưng phần lớn thời gian chúng lại không sánh đúng cho nên bạn phải thương lượng với người quản lí và khách hàng của mình về ngày giao hàng.
PM: Anh nói về loại thương lượng nào vậy?
SM: Bằng việc biết dự án phải chuyển giao cái gì cho khách hàng và nhu cầu nào cần được thực hiện, kể cả về khoảng thời gian cần để hoàn thành mọi nhiệm vụ, bạn có thể xác định được liệu bạn có thể đáp ứng ngày chuyển giao của khách hàng hay không. Nếu có khác biệt lớn thì bạn phải thương lượng về ngày chuyển giao với khách hàng bằng hoặc là yêu cầu thêm thời gian, thêm tài nguyên hay thay đổi khối lượng công việc của dự án. Thương lượng là kĩ năng quan trọng cho mọi người quản lí dự án, điều không được dạy trong hầu hết các môn học kĩ thuật nhưng lại là kĩ năng bản chất của mọi người quản lí dự án. Bạn phải hiểu rằng phần lớn khách hàng chỉ đoán chừng ngày giao hàng vì họ không biết đích xác sẽ mất bao lâu cho nên họ lựa ngày xấp xỉ cho tiện. Đây là cơ hội cho bạn giải thích cho họ cách bạn đi tới thời gian được yêu cầu dựa trên ước lượng của bạn và đạt tới thoả thuận lẫn nhau về ngày chuyển giao cuối cùng. Tuy nhiên, với một số khách hàng, ngày chuyển giao là quan trọng nhất vì nó có liên quan tới các doanh nghiệp khác cho nên điều mấu chốt là khách hàng và người quản lí dự án đồng ý về ngày tháng hợp lí cho cả hai bên. Bởi vì hầu hết khách hàng không hiểu về phần mềm và hoạt động dự án, họ có mong đợi cao cho nên điều quan trọng là có nhiều cuộc họp để thảo luận về điều có thể được làm và điều không thể được làm. Là người quản lí dự án, bạn không muốn lâm vào những tình huống mà nhu cầu và mong đợi không sánh đúng. Chẳng hạn, khách hàng nghĩ tổ có thể làm dự án trong 6 tháng khi dự án có thể mất cả năm cho nên kĩ năng trao đổi và thương lượng là cực kì quan trọng.
SM: Thương lượng là kĩ năng quan trọng nhất của người quản lí phần mềm. Nhưng không may, rất ít chương trình đào tạo cung cấp loại đào tạo này. Trong thương lượng, có ba nhân tố người quản lí dự án nên thảo luận: Khối lượng công việc (Chức năng hay phạm vi), tài nguyên (người) và lịch biểu (Ngày tháng). Nếu ước lượng lịch biểu của bạn và ngày chuyển giao của khách hàng không sánh đúng, bạn có thể yêu cầu khách hàng cho bạn thêm thời gian bằng việc thay đổi ngày chuyển giao. Bạn có thể thương lượng lấy thêm người cho dự án và bạn phải làm điều này từ lúc bắt đầu dự án. Nhiều người có kĩ năng đúng có thể tăng tốc cho dự án, nhiều người có thể làm giảm tải việc của thành viên tổ. Tuy nhiên, thêm nhiều người vào giữa chừng dự án khi mọi sự không làm việc tốt có thể là thảm hoạ. Nhiều người sẽ làm vỡ công việc dự án, điều đã bị căng thẳng rồi. Nhiều người hơn nghĩa là nhiều trao đổi hơn và làm tăng độ phức tạp của tính động của tổ. Người mới không quen thuộc với công việc dự án cần thời gian để học, điều đó có nghĩa là những người đang làm việc phải dành thời gian đào tạo người mới và mất thời gian quí giá của họ dành cho công việc của họ. Vì các nhiệm vụ trong dự án phần mềm thường sẽ phụ thuộc vào nhiệm vụ của người khác, thất bại của một người có thể làm thiệt hại lớn cho tiến triển dự án. Qui tắc của tôi là không bao giờ thêm người giữa chừng dự án đặc biệt khi dự án đang bị trục trặc.
PM: Điều đó là thú vị đấy. Phần lớn những người quản lí sẽ thêm người cho dự án khi mọi sự không trôi chảy. Anh nói điều đối lập.
SM: Đó là lí do tại sao nhiều dự án phần mềm thất bại. Dường như là những người quản lí này không có kinh nghiệm trong quản lí dự án phần mềm. Dự án phần mềm KHÔNG phải là dự án xây dựng. Trong dự án xây dựng như xây nhà, thêm nhiều người sẽ giúp tăng tốc nó nhưng trong dự án phần mềm điều đó sẽ KHÔNG giúp gì mà tạo ra thêm vấn đề. Từ kinh nghiệm của tôi, điều quan trọng là thương lượng về người phụ ngay từ đầu dự án khi bạn cần đáp ứng lịch biểu của khách hàng.
PM: Vâng, vậy người quản lí dự án có thể thương lượng cái gì khác nữa?
SM: Người quản lí dự án cũng có thể yêu cầu giảm khối lượng công việc (chức năng) bởi vì ít việc hơn nghĩa là bạn có thể hoàn thành các yêu cầu trong thời gian cho phép để dự án có thể được hoàn thành thành công như mong đợi. Tuy nhiên, nếu sản phẩm phần mềm không có tất cả chức năng như được yêu cầu, người dùng có thể không hài lòng. Cách tốt nhất là hỏi người dùng mức ưu tiên để xác định chức năng nào bạn có thể làm trước và cái nào có thể để trễ vào thời gian muộn hơn bằng việc dùng cách tiếp cận đưa ra dần dần. Ngày nay, phần lớn phần mềm đều lớn và phức tạp nên rất khó làm mọi thứ ngay một lúc cho nên điều quan trọng là xây dựng phần mềm theo các bước tăng nhỏ. Bạn cần làm việc chặt chẽ với khách hàng để có được ưu tiên của họ và chốt cứng yêu cầu cho từng bước trước khi bắt đầu thiết kế. Đây là chỗ phương pháp mau lẹ rất phù hợp cho việc quản lí dự án tốt hơn. Bạn chia dự án lớn thành nhiều mảnh nhỏ và thực hiện từng mảnh như một dự án nhỏ. Khi cả hai bên có thoả thuận vững chắc về lịch chuyển giao thì người quản lí dự án có thể bắt đầu phân công cho các thành viên tổ theo vai trò và trách nhiệm của họ. Trong dự án phần mềm, không ai làm việc một mình mà bao giờ cũng trong tổ. Công việc tổ KHÔNG phải là nhóm người làm việc trong cô lập, mỗi người làm việc riêng của mình mà là nỗ lực hợp tác của tất cả thành viên của tổ để đạt tới mục đích chung. Đây là chỗ việc xây dựng tổ là bản chất; người quản lí dự án phải trao đổi và cung cấp sự lãnh đạo trong việc xây dựng tổ.
PM: Đó là đòi hỏi quá nhiều với người quản lí dự án.
SM: Bạn nghĩ người quản lí dự án phần mềm thành công phải làm gì? Họ phải dựa vào may mắn hay kĩ năng của mình? Bạn có muốn tăng cơ hội thành công và giữ việc của mình hay để mọi sự xảy ra cho bạn? Quản lí dự án là kĩ năng cần được đào tạo để có tri thức cơ bản rồi áp dụng nó vào dự án thực để cải tiến kĩ năng của bạn. Không may, ngày nay nhiều công ti bổ nhiệm người kĩ thuật giỏi vào làm người quản lí dự án mà không có đào tạo nào. Đây là sai lầm lớn vì nhiều người sẽ thất bại và họ mất người kĩ thuật giỏi và thu được người quản lí tồi. Nếu bạn muốn thành công, bạn phải đào tạo người quản lí dự án phần mềm. Có đào tạo về quản lí dự án nhưng nhiều người KHÔNG được đào tạo về quản lí dự án phần mềm cho nên bạn phải phân biệt họ. Phần mềm là duy nhất và yêu cầu giảng viên có nhiều kinh nghiệm, không có kinh nghiệm tất cả mọi điều bạn thu được là mớ lí thuyết mà có thể chẳng ích gì cho nghề nghiệp của bạn. Xây dựng tổ và thương lượng là hai kĩ năng nhưng có nhiều kĩ năng nữa như trao đổi. Để đảm bảo tổ hiểu yêu cầu và mục đích, người quản lí dự án phải thường xuyên trao đổi với tổ. Trao đổi là theo cả hai chiều cho nên tổ cũng phải để người quản lí dự án biết mọi điều về nhiệm vụ của họ và ý kiến của họ. Điều quan trọng là có báo cáo tiến độ hàng tuần mô tả cách dự án đang thực hiện, và nhiệm vụ nào đã được đạt tới.
PM: Đó là nhiều thứ và nhiều dữ liệu tôi phải thu thập.
SM: Có các công cụ giúp bạn thu thập dữ liệu phân tích về dự án của bạn. Các công cụ này sẽ giúp bạn phân tích độ phức tạp của phần mềm, kiểm trạng thái dự án, đánh giá tác động của thay đổi đã cho, và nhận diện vi phạm chuẩn. Dữ liệu này sẽ giúp bạn trong pha kiểm nghiệm và cung cấp dữ liệu khách quan cho quản lí dự án phần mềm. Người quản lí phần mềm tốt phải biết các công cụ này và nếu cần thì học một một học ngắn về cách dùng các công cụ này.
PM: Nhưng điều gì xảy ra nếu tôi có thể tìm ra một công cụ đích xác khớp với mọi yêu cầu của tôi?
SM: Có thể không có công cụ thoả mãn cho mọi thứ. Bạn phải xác định qui trình chuẩn cho phần mềm và lập kế hoạch về cách các công cụ này có thể khớp với từng qui trình cũng như điều gì cần được thực hiện trong từng pha như kiến trúc, thiết kế, kiểm nghiệm, tích hợp, đào tạo v.v. Có các công cụ cho từng pha như công cụ kiến trúc, công cụ thiết kế, và công cụ để thu thập độ đo, công cụ để kiểm thử cho nên bạn phải quyết định bạn muốn mua cái nào. Chính tại điểm này bạn phải ra quyết định cơ bản liên quan tới dự án của mình và bạn cần bao nhiêu công cụ bởi vì bạn sẽ cần làm ngân sách cho chúng. Đó là lí do tại sao người quản lí phần mềm cũng cần hiểu về tài chính và làm ngân sách và những điều này cũng phải được dạy trong môn học quản lí dự án phần mềm.
PM: Tại sao người kĩ thuật cần biết qui trình doanh nghiệp như tài chính và làm ngân sách?
SM: Bạn là người quản lí dự án và đó là việc của người quản lí. Ai khác sẽ làm điều đó cho bạn? Giả sử ông chủ của bạn cho bạn một ngân sách và số đó chỉ được một nửa điều bạn cần, bạn có thể hoàn thành dự án này một cách thành công được không? Nhiều người quản lí dự án phần mềm thụ động và không biết cách thương lượng, không biết hỏi cái gì, không biết ước lượng kích cỡ, phạm vi, tài nguyên, ngân sách và công cụ. Họ cần đào tạo bằng không họ sẽ không bao giờ thành công trong nghề của mình. Một công ti không đầu tư vào đào tạo sẽ không tồn tại lâu trong môi trường cạnh tranh này.
PM: Anh nhấn mạnh quá nhiều vào đào tạo. Anh nghĩ đào tạo là quan trọng thế sao?
SM: Vâng, nó là điều quan trọng nhất và là đầu tư tốt nhất mà công ti có thể làm. Tôi nghĩ điểm yếu chính của nhiều công ti là họ không hiểu bản chất của phần mềm. Họ không có vấn đề trong chi tiêu tiền về phần cứng nhưng rất keo kiệt trong đào tạo cho người của họ. Đào tạo cung cấp tri thức và kĩ năng và phải được coi là quá trình tiếp diễn. Đào tạo không bao giờ nên dừng lại vì công nghệ thanh đổi nhanh chóng. Hơn bao giờ hết, trong thời khủng hoảng kinh tế khi mọi sự đều chậm, đây là lúc cho bạn nhận đào tạo và thời gian cho đào tạo người của bạn về những kĩ năng mà họ sẽ cần khi mọi sự trở lại bình thường.
PM: Tôi đoán rằng đó là mọi thứ chúng tôi có được hôm nay. Nhưng tôi đánh giá cao lời khuyên của anh và tôi xin phép đi với cam kết cải tiến kĩ năng của tôi. Tôi hiểu rằng tôi không thể phụ thuộc vào may mắn mà vào kĩ năng của tôi trong thời không chắc chắn này. Quản lí dự án yêu cầu hiểu biết sâu sắc về cách phần mềm phải được lập kế hoạch và ước lượng. Người quản lí dự án tốt phải biết cách thương lượng với khách hàng và biết cách xây dựng tổ. Không có cách nào là tốt nhất cho người quản lí phần mềm mà không có đào tạo thêm.
Tác phẩm, tác giả, nguồn
- Tác phẩm: Quản lý dự án
- Nguồn: Blog của giáo sư John Vu, Carnegie Mellon University.
- Wiki hóa: https://kipkis.com
