Tớ tự đánh giá bản thân mình là một người sống “quá thoải mái” nên bản thân không có tham vọng sau này sẽ có thể trở thành người quản lý dự án cho các công ty lớn (trừ các dự án của mình). Tuy nhiên, trong quá trình học môn “Con người và tổ chức trong công nghiệp phần mềm” (tạm dịch từ “Human and Organizational Aspects in Software Engineering“), cái ý nghĩ mình sẽ quản lý một dự án như thế nào để đạt được những mục tiêu đề ra bỗng nhiên trở nên khá thú vị. Vẫn biết để quản lý được cả một nhóm người là cả một nghệ thuật, nhưng không ngờ là nó có nhiều chi tiết hay đến vậy. Điều này có lẽ một phần nhờ vào cách ông giáo sư truyền đạt nội dung và nhờ vào cuốn sách giáo khoa tuyệt vời Deatch March (Edward Yourdon).
Nội dung chính của khóa học nói một cách ngắn gọn là về quá trình quản lý một dự án phần mềm, trong đó giới thiệu một khái niệm khá nổi bật là “Death March project” (có thể hiểu như là những dự án chắc chắn sẽ thất bại ngay từ khi bắt đầu). Cuốn sách đi kèm cùng tên của tác giả Edward Yourdon là một trong những cuốn sách nổi tiếng trong giới IT lần đầu tiên giới thiệu khái niệm này đồng thời gợi ý những gì bạn nên làm nếu là một thành viên của dự án đó. Tuy chỉ mới học chưa hết nữa học kỳ nhưng một bài viết có lẽ sẽ không nói được tất cả những khía cạnh của chủ đề này. Trong bài viết này, tớ sẽ chỉ giới thiệu một vài điểm chính mà tớ thấy thú vị.
Trong phần đầu, tớ sẽ chỉ đơn thuần giải thích khái niệm về “Death march project” từ những gì tớ hiểu trong cuốn sách Death March nên nó sẽ hơi đơn điệu. Nếu bạn hiểu về khái niệmn này, có thể bỏ qua và đọc tiếp phần sau.
Death March Project
Như đã nói ở phần giới thiệu, bạn có thể hiểu về khái niệm “Death March project” như là những dự án mà thất bại là kết quả tất yếu. Thất bại ngay từ đầu - thậm chí ngay từ khi cái ý tưởng về dự án hình thành trong đầu người đứng đầu. Như định nghĩa từ cuốn sách:
“Death March project” là những dự án mà tất cả các thông số dự án đều gấp đôi những con số thật. Ví dụ: dự án buộc phải hoàn tất trong một khoảng thời gian chỉ bằng một nữa so thời gian cần thiết, số lượng người tham gia bị giảm một nữa so với những dự án cùng kích cỡ, ngân sách cho dự án bị cắt chỉ còn một nữa,… Hậu quả tất yếu là những người làm trong dự án phải làm việc gấp đôi những người khác.
Tất nhiên, bạn phải hiểu cách đánh giá sự thất bại hay thành công của một dự án: thành công không phải chỉ là có sản phầm ở cuối dự án. Thành công hay thất bại còn phụ thuộc vào nhiều yếu tố khác: làm sao có thể xem một dự án là thành công nếu nó tiêu tốn ngân sách gấp đôi, thời gian hoàn tất bị kéo dài gấp đôi trong khi sản phẩm cho ra lại có chất lượng rất kém & thậm chí không ai thèm dùng?
Để tiện liên hệ, tớ tạm dịch thuật ngữ “Death March projects” là “Những dự án chết”
Theo kinh nghiệm của tác giả cuốn sách, phần lớn những dự án chết thường được thấy ở các dự án nhỏ. Tuy nhiên, đây cũng chính là nhóm có tỉ lệ thành công cao nhất, trong khi tỉ lệ thành công của các dự án qui mô vừa và lớn thường gần như bằng 0 (có thể hiểu được điều này: những dự án càng lớn thì càng có nhiều người tham gia, dẫn đến rất nhiều những vấn đề trong quá trình quản lý)
Nguyên nhân nào dẫn đến những dự án chết? Tác giả cuốn sách có nêu khá nhiều nguyên nhân. Tớ tóm tắt ghi lại một vài trong số đố:
- Chính trị: tuy phần lớn những người lập trình đều ghét những suy nghĩ về chính trị nhưng đây là một yếu tố tất yếu trong các tổ chức.
- Những suy nghĩ hảo huyền của bộ phận kinh doanh và người quản lý: thường do thiếu kinh nghiệm.
- Sự lạc quan của tuổi trẻ: những người phát triển trẻ tuổi thường luôn tự tin theo kiểu “chúng ta có thể hoàn tất chúng cuối tuần này” mà không cần biết đến mức độ phức tạp của vấn đề.
- Quan niệm người lập trình đích thực không cần … ngủ.
- Sự cạnh tranh gay gắt của thị trường và những công nghệ mới: ép buộc bạn phải liên tục đầu tư nghiên cứu và áp dụng những cái mới, sợ rằng đối thủ của mình sẽ ra trước.
Bạn có thể tự hỏi, nếu một dự án đã được biết 90% là sẽ thất bại ngay từ khi khởi đầu thì tại sao người ta vẫn sẵn sàng tham gia nó? Một số nguyên nhân đáng chú ý được đề cập:
- Nguy cơ tuy cao, nhưng phần thưởng cũng lớn theo cùng mức độ
- Sở thích được đối đầu với những thử thách
- Vì nó tốt hơn là thất nghiệp
- Lạc quan của tuổi trẻ, tin tưởng rằng mình sẽ có thể đảo ngược được mọi chuyện.
Những vấn đề của các công ty lớn
Theo tớ, có 3 vấn đề trong các công ty lớn. Vấn đề thứ nhất là tất cả các công ty lớn đều có những vấn đề trong quá trình quản lý. Tất cả? Nghe có vẻ hơi vô lý nhưng từ những gì tớ hiểu thì đó là sự thật. Sự khác biệt chỉ là về mức độ của vấn đề mà thôi. Vấn đề thứ hai, quan trọng hơn, là bản thân những người quản lý của các công ty này không hề nghĩ hoặc không muốn nghĩ rằng mô hình quản lý của họ có vấn đề - cũng giống như hiếm ai có thể biết được khuyết điểm của chính mình. Vấn đề thứ ba là, ngay cả nếu có một ai đó trong công ty có nhiều kinh nghiệm biết được nguồn gốc của vấn đề và thậm chí là cả cách giải quyết thì anh ta cũng không có khả năng thay đổi được cả hệ thống: thứ nhất, không ai chịu nghe anh ta giải thích; và thứ hai, một mình anh ta không có đủ khả năng thay đổi một hệ thống làm việc của hơn 1000 người.
Điều quan trọng có thể thấy là ngay cả như người có đủ quyền lực trong công ty (như CEO) phát hiện ra vấn đề và quyết định thay đổi hệ thống, quá trình này cũng phải diễn ra theo từng giai đoạn bởi qui mô của dự án. Và bạn đoán điều gì sẽ xảy ra khi quá trình này hoàn tất? Những vấn đề mới lại nảy sinh, và vòng tròn cứ lặp lại.
Một trong những điều đáng chú ý ở phần trên là tuy số lượng dự án chết ở các doanh nghiệp qui mô lớn không nhiều nhưng xét trên tổng số lượng dự án, tỉ lệ dự án chết như định nghĩa ở trên lại là cao nhất. Giải thích cho điều này không khó: những dự án lớn đòi hỏi nhiều người tham gia (một dự án có thể có hơn 1000 người cùng tham gia là chuyện thường) và đó chính là điều rắc rối. Xem xét một cách kỹ càng thì những vấn đề chính của việc quản lý những dự án lớn bắt nguồn từ những hành động khác thường của những người tham gia.
Bản chất của con người
Thế nào là những “hành động khác thường”? Tớ chưa từng thực sự làm quản lý hay là nhân viên của một công ty nào, nhưng những bạn đã từng có lẽ sẽ đồng ý với ví dụ mà tác giả cuốn sách Death March đưa ra:
Nếu như bạn là một người quản lý dự án, bạn nghĩ sẽ có bao nhiêu nhân viên báo cho bạn rằng họ hoàn thành công việc trước thời hạn mà bạn đưa ra? Bạn sẽ hơi ngạc nhiên khi biết rằng có hàng trăm lý do khiến một nhân viên có thể không muốn để cho bạn biết là anh ta hoàn thành công việc trước thời hạn, một trong số đó có thể là cách mà bạn có thể sẽ trả lời họ khi bạn biết điều đó: “À, vậy là cậu thật sự hoàn thành nhanh hơn thời hạn tớ đưa ra. Có lẽ trình độ của cậu cao hơn mọi người. Lần sau tớ sẽ thu ngắn thời hạn lại.” Hiện tượng này thậm chí còn được tổng kết lại dưới dạng định luật Parkinson: công việc tự động nở ra để lấp đầy thời gian còn trống.
Nghe có vẻ hơi ngạc nhiên. Cá nhân tớ thậm chí chưa từng nghĩ đến khả năng này (nhưng có lẽ tớ sẽ bắt đầu nghĩ đến nó trước khi báo kết quả cho cấp trên :) ). Một câu hỏi dễ hiểu nảy ra trong đầu nhân viên sẽ là “tại sao mình phải báo cáo nếu như việc im lặng thì có lợi (được ngồi chơi), trong khi đem đi báo cáo thì chưa biết chừng lại phải làm thêm nhiều việc?”. Những hành động này không hẳn đã là sai trái, tuy nhiên - nó trái với những gì mà người ta trông đợi. Điều đáng tiếc là phần lớn mọi người đều như vậy.
Tiếp tục từ ví dụ trên: Nếu bạn là một nhân viên và cấp trên của bạn giao cho bạn một việc và hỏi bạn ước lượng sẽ cần tối đa bao nhiêu lâu để hoàn thành nó, bạn sẽ trả lời như thế nào? Từ ví dụ trước, thật dễ hiểu nếu bạn cố nâng thời gian bạn thật sự cần lên thêm khoảng 20% để đảm bảo rằng mình sẽ không bao giờ bị trễ hạn (vốn sẽ tạo ấn tượng xấu với “sếp”). Bạn nghĩ “sếp” của bạn sẽ không biết điều đó? Nói cho cùng thì “sếp” cũng chỉ là một nhân viên của “sếp cao hơn” mà thôi. Hậu quả là sếp của bạn sẽ cố tình ép bạn phải cắt thời gian thực hiện xuống bất kể câu trả lời của bạn ở trên có thật hay không. Và nếu như bạn nhớ ở phần đầu giới thiệu về khái niệm dự án chết, đây chính là một trong những nguyên nhân của nó.
Nói cho cùng, nguồn gốc của những vấn đề trong các công ty & không phải chỉ là từ những cấp quản lý mà từ chính mỗi thành viên trong tổ chức/dự án đó. Không ai muốn phải làm thêm việc chỉ để nhận cùng một mức lương. Tất cả mọi người đều lo cho những gì liên hệ trực tiếp với bản thân mình trước khi lo cho lợi ích của công ty mà họ đang làm việc. Xét cho cùng, đó là bản chất của con người mà không ai có thể thay đổi. Tức là, những vấn đề về quản lý của các công ty như đã đề cập trong phần hai sẽ không thể nào có thể giải quyết được một cách trọn vẹn.
Giải pháp cục bộ?
Có thể bạn sẽ hơi thất vọng về kết luận ở trên. Nhưng đó là bản chất của vấn đề. Giả như có một cách để giải quyết triệt để vấn đề thì phải chăng tất cả các công ty đều thành công? Tất nhiên là không có một cách nào như vậy cả. Tuy nhiên, mặc dù bạn không thể thay đổi cách cả một công ty hoạt động, bạn có thể giúp bạn sống trong môi trường đó và cả những người trong nhóm của bạn.
Một trong những gợi ý của tác giả cuốn sách là: nếu bạn là người quản lý cho một nhóm nhỏ của một dự án lớn với những vấn đề trong quản lý mà bạn là người thấy được chúng, hãy cố gắng tách biệt những hoạt động trong nhóm của bạn ra khỏi những ảnh hưởng của môi trường xung quanh và áp dụng những gì bạn cho là đúng.
Tất nhiên, bạn có thể nói là nếu ai cũng làm như vậy thì có phải là cả một dự án sẽ loạn cả lên không. Tuy nhiên, cũng giống như khái niệm đóng gói (”enscapsulation”) trong lập trình hướng đối tượng, điều quan trọng không phải là cách hoạt động bên trong mỗi nhóm mà là kết quả mà mỗi nhóm cho ra. Nếu mỗi nhóm đều cho ra kết quả đúng lịch trình của người quản lý cấp cao hơn thì bản thân người quản lý đó sẽ có thể ghép nối mọi thứ lại với nhau. Và đó cũng chính là vai trò của bạn trong nhóm nhỏ của mình. Người quản lý giỏi sẽ biết cách để có được kết quả cuối cùng với chất lượng và trong một thời gian hợp lý.
Một người quản lý giỏi không phải chỉ biết cách sắp xếp thứ tự công việc, phân công công việc cho từng thành viên với thời hạn hợp lý để rồi ghép nối lại, mà còn là mẹo để có thể lấy được những thông tin có giá trị, xác với thực tế từ mọi người trong nhóm cho dù như trong những ví dụ ở trên, ai cũng sẽ lo cho lợi ích của mình.
Không có nhận xét nào:
Đăng nhận xét