Ước lượng dự án/3
Nhiều dự án phần mềm có vấn đề bởi vì lịch biểu khách hàng đặt cho họ. Bởi vì người quản lí dự án không biết cách ước lượng thời gian cần để hoàn thành dự án cho nên họ đồng ý với bất kì ngày tháng nào khách hàng đặt ra. Không may, phần lớn các khách hàng cũng không biết dự án có thể được thực hiện trong bao lâu cho nên họ đặt một ngày tháng tuỳ tiện mà họ thích. Đó là lí do tại sao dự án ở vị thế xấu vì ngày tháng bị đặt dựa trên phỏng đoán chứ KHÔNG dựa vào thời gian cần thiết.
Nhiều người quản lí dự án cũng không biết cách lập kế hoạch cho công việc của họ. Họ vội vàng cho dự án bắt đầu bằng việc ra lệnh cho tổ dự án xô vào thiết kế và bắt đầu viết mã bởi vì với họ phần mềm là mã. Chẳng mấy chốc mọi người có thể viết mã nhanh hơn họ có thể hoàn thành dự án. Một số người quản lí dự án muốn chứng tỏ “tiến độ của họ” cho người quản lí cấp cao bằng việc cho tổ viết mã và kiểm thử sớm nhất có thể được bởi vì người quản lí cấp cao chỉ thấy tiến độ khi dự án đi vào pha kiểm thử, vì điều đó có nghĩa là dự án gần hoàn thành và sẵn sàng cho chuyển giao. Điều này sẽ đưa dự án vào tình huống sinh lỗi vì công việc được thực hiện vội vàng để sang pha kiểm thử.
Nhiều người phát triển không biết cái gì tốt hơn. Họ chi tuân theo chỉ đạo của người quản lí dự án bởi vì họ thích viết mã. Tất nhiên, họ biết về các pha khác trong vòng đời nhưng phần lớn các trường nhấn mạnh vào viết mã cho nên họ làm điều họ đã học giỏi nhất bằng việc làm pha viết mã. Tôi đã thấy nhiều người phát triển đổ xô qua yêu cầu, thiết kế trong vài ngày để họ có thể viết mã. Một số người thậm chí còn nói: “Viết mã trước, hỏi câu hỏi sau.” Kết quả là sản phẩm phần mềm với nhiều lỗi và có thể không có được điều khách hàng cần.
Tất nhiên khách hàng không hài lòng và nhiều người yêu cầu: “Đó KHÔNG phải là điều tôi muốn. Thay đổi nó đi nếu không tôi sẽ không trả tiền.” Người quản lí cấp cao muốn đạt tới sự thoả mãn của khách hàng sẽ gây sức ép lên người phát triển: “Trở về và đổi mã của các anh theo điều khách hàng muốn nhưng chóng chóng lên vì không còn nhiều thời gian đâu.” Dưới loại sức ép này, mọi người sẽ trách móc ai đó khác.
Kịch bản này thường xảy ra trong mọi công ti nhưng ít người biết phải làm gì bởi vì mọi người đều trách ai đó khác. Là người phát triển, bạn có thể biết rằng lịch biểu là không hợp lí và nói với người quản lí dự án “Lịch biểu đó dường như không đúng.” Tuy nhiên, người quản lí có thể nói “Lịch biểu đó tới từ khách hàng. Anh không hiểu về sự hài lòng của khách hàng sao? KHÔNG phải việc của anh đi bảo khách hàng rằng họ là sai.” Cho nên bạn lắc đầu và trở lại viết mã bởi vì đó KHÔNG phải là lỗi của bạn. Tất nhiên người quản lí cũng có cùng cảm giác không thoải mái nhưng đó cũng KHÔNG phải là lỗi của người đó bởi vì người đó đã không đặt ra ngày tháng. Khách hàng cũng có cùng cảm giác nhưng người đó nghĩ, đó KHÔNG phải là lỗi của mình vì người đó đã đặt ngày tháng tuỳ tiện nhưng tổ đằng nào cũng đã chấp nhận nó rồi. Khi không ai chịu trách nhiệm về bất kì cái gì thì dự án sẽ thất bại. Khi điều đó xảy ra, sẽ có tổn thất vì khách hàng sẽ KHÔNG chấp nhận sản phẩm và sẽ KHÔNG trả tiền. Người quản lí sẽ KHÔNG tự sa thải mình cho nên người dễ nhất chịu trách móc là người ở vị trí thấp nhất: người phát triển. Mọi người sẽ nói rằng đó là lỗi của người phát triển vì anh ta không hoàn thành dự án tương ứng theo điều khách hàng yêu cầu. Là người phát triển, bạn là cái bung xung cho mọi thứ.
Cho nên bạn phải làm gì? Khi bạn mua máy MP3, điện thoại di động, hay laptop bạn có thương lượng về giá, đúng không? Cho nên tại sao bạn không học cách thương lượng lịch biểu? Tại sao bạn chấp nhận nó mà không hỏi gì? Điều bạn cần là chuẩn bị cho thương lượng. Khi người quản lí nói ngày chuyển giao là sáu tháng, bạn phải bảo họ: “Để tôi kiểm lại xem liệu tôi có thể làm được điều đó trong lịch biểu mà ông yêu cầu không.” Cho dù bạn biết lịch biểu đó là không hợp lí, ĐỪNG tranh cãi vào lúc đó bởi vì bạn CHƯA chuẩn bị để thuyết phục họ. Bạn cần thời gian để đi tới lịch biểu logic và hợp lí bằng việc kiểm điểm lịch đã cho với tổ. Năm hay mười người là tốt hơn một người cho nên cùng với tổ, bạn làm ra kế hoạch dự án với mọi việc được chia ra tới mức chi tiết về bao nhiêu chức năng, bao nhiêu nhiệm vụ, cũng như nỗ lực được cần tới để hoàn thành toàn thể dự án và thời gian kết thúc chúng. Bây giờ, bạn có thể tới người quản lí như một tổ và bảo họ lịch biểu là gì. Như một tổ, bạn chỉ cho người quản lí thấy bản kế hoạch dự án với mọi công việc và thuyết phục người quản lí rằng tổ biết điều họ đang nói tới.
Nếu bạn có thể chỉ ra cho người quản lí cách bạn đi tới lịch biểu mới hoặc là ông ấy đồng ý với bạn hoặc là ông ấy phản đối nó bằng kế hoạch khác. Về căn bản, cả bạn và người quản lí bắt đầu thương lượng trên cách thức logic và hợp lí để giải quyết vấn đề này. Nếu dự án cần tám tháng và KHÔNG phải sáu tháng, điều cuối cùng người quản lí muốn là đồng ý với lịch biểu sáu tháng bởi vì nó sẽ thất bại. Người quản lí sẽ phải trở lại với khách hàng và báo cho người đó biết về lịch biểu mới. Không người quản lí nào muốn dự án thất bại nếu người đó biết rằng người đó có thể mất việc của mình. Không người quản lí nào muốn thấy người của họ bảo họ: “Tôi đã bảo ông rằng cần tám tháng nhưng ông đã không chịu nghe.” Cho nên đến lượt người quản lí thuyết phục khách hàng và rất có thể là ông ấy sẽ đề nghị bạn đi cùng ông ấy bởi vì đó là công việc của bạn và bạn biết tất cả chi tiết. Đây là cơ hội của bạn để chứng tỏ cho khách hàng về năng lực ước lượng của bạn và kĩ năng thương lượng của bạn. Nếu họ đồng ý với bạn và dự án hoá ra thành công, mọi người sẽ biết về bạn và đó là cơ hội của bạn có được cái nhìn tốt trước quản lí cấp cao và khách hàng.
Tất nhiên, bạn phải học nhiều về ước lượng dự án và cách thương lượng và trao đổi. Không may, phần lớn các trường KHÔNG dạy những kĩ năng này cho nên bạn cần tự học chúng. Có nhiều bài báo tuyệt vời trên internet về những chủ đề này cho nên xin tìm chúng đi. Khi bạn có thể đi tới lịch biểu hợp lí, khi bạn có thể thương lượng với khách hàng thì bạn sẵn sàng bước sang vai trò tiếp: Vị trí quản lí dự án.
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
