Vấn đề con người
Người quản lí dự án phần mềm giỏi phải biết cách tạo ra cân bằng giữa vấn đề kĩ thuật và vấn đề con người. Chỉ hội tụ vào vấn đề kĩ thuật có thể làm cho mọi người cảm thấy họ tuân theo mệnh lệnh như “người máy”. Trong khi chỉ hội tụ vào vấn đề con người có thể làm cho mọi người bỏ qua nhiệm vụ kĩ thuật và có thể làm việc như họ trong một đảng phái. Cân bằng này rất khó thực hiện tốt vì quản lí con người thường là điều khó nhất trong bất kì dự án phần mềm nào. Điều không may là phần lớn việc đào tạo quản lí dự án phần mềm đang hội tụ vào vấn đề kĩ thuật nhưng ít khi vào vấn đề con người.
Trong khi người phát triển phần mềm được đào tạo để làm các vấn đề kĩ thuật (thiết kế, viết mã v.v.) phần lớn chưa bao giờ nhận được đào tạo nào về cách làm việc trong tổ. Mọi người thường nói “tổ là nhiều hơn một người”, sự kiện là các kĩ năng và công việc và thành phần của tổ là rất quan trọng và phải được quản lí đúng. Việc tạo ra tổ là một điều nhưng giữ và duy trì tổ hiệu quả là vấn đề khác. Trong công ti phần mềm lớn, có nhiều chức năng và nhiều người từ các chức năng khác nhau thường không ở cùng vị trí. Chẳng hạn, người phát triển sẽ làm việc ở toà nhà này, tổ kiểm thử ở toà nhà khác và tổ chất lượng và tổ hỗ trợ có thể ở vị trí khác nữa. Tôi đã thấy rằng tách bạch càng có nhiều, càng nhiều vấn đề nảy sinh ra giữa các tổ. Điều quan trọng, khi có thể là để toàn thể tổ dự án ở gần nhất có thể được. Tôi bao giờ cũng đặt tổ kiểm thử và tổ phát triển ở cùng nhau để tránh vấn đề hiểu lầm hay trao đổi kém. Trao đổi tốt là yếu tố then chốt trong xây dựng quan hệ tổ. Các thành viên tổ phải trao đổi thường xuyên về nhiệm vụ của họ và cho phép họ ra quyết định có thông tin.
Tổ dự án phải chia sẻ cùng viễn kiến, bằng không tổ sẽ nhắm tới các hướng khác nhau. Điều quan trọng lúc bắt đầu dự án, người quản lí dự án phần mềm phải triệu tập một cuộc họp với mọi thành viên tổ để chia sẻ viễn kiến, mục đích và mục tiêu dự án của mình với tổ. Viễn kiến là phát biểu chính xác xác định ra “Cái gì”, “Tại sao”, và “Ai” của mục đích của sản phẩm phần mềm theo quan điểm doanh nghiệp. Chẳng hạn: Ai sẽ mua hay dùng sản phẩm phần mềm này? Phần mềm này sẽ làm gì cho người dùng? Tại sao chúng ta cần xây dựng phần mềm này? Phần mềm này sẽ giải quyết vấn đề gì? Điều quan trọng là làm cho mọi thành viên tổ hiểu các lí do doanh nghiệp của dự án. Nó sẽ tiết kiệm thời gian và nỗ lực trong pha phân tích yêu cầu bằng việc khử bỏ hiểu lầm về sản phẩm phần mềm. Một khi tổ hiểu viễn kiến, người quản lí dự án phải thảo luận về mục đích và mục tiêu dự án. Chẳng hạn: Chuyển giao sản phẩm chất lượng đúng thời gian, trong chi phí và đáp ứng mọi yêu cầu chức năng. Thời gian, chi phí và chất lượng là các mục đích của mọi dự án phần mềm nhưng người quản lí dự án phải soạn thảo chi tiết hơn như các mục tiêu và tìm kiếm sự chấp thuận từ các thành viên tổ. Đào tạo quản lí truyền thống coi người quản lí là ai đó đưa ra mục đích và mục tiêu mà tổ phải tuân theo. Khái niệm này sẽ không có tác dụng trong dự án phần mềm bởi vì điều gì xảy ra nếu các mục đích này là không thoả đáng? Điều gì xảy ra nếu các thành viên tổ không cảm thấy thoải mái với lịch biểu? Điều gì xảy ra nếu họ không tin rằng họ có thể đáp ứng cho các mục đích này? Đó là lí do tại sao người quản lí dự án phải thảo luận những mục đích này với tổ và hỏi ý kiến của họ. Thảo luận về mục đích và mục tiêu là mấu chốt bởi vì tổ phải đồng ý về điều họ phải làm. Họ phải có cơ hội lên tiếng về ý kiến của họ. Nếu tổ cảm thấy rằng người quản lí dự án không nghe ý kiến của họ, điều đó có thể làm hại nghiêm trọng cho tinh thần của tổ và có tác động xấu lên dự án. Trong vài ngày đầu của dự án, tổ hình thành và chứng danh của người quản lí dự án được thiết lập. Nếu tổ không kính trọng người quản lí, điều đó sẽ rất khó thay đổi. Nói cách khác, dự án đã “thất bại” từ đầu.
Người quản lí dự án phần mềm phải thảo luận chi tiết về kế hoạch dự án. Chẳng hạn: Các chức năng được thực hiện, phân công nhiệm vụ cho từng thành viên, thời gian cho các nhiệm vụ này và tìm kiếm cam kết từ các thành viên tổ. Điều này yêu cầu nhiều công việc trước khi có cuộc họp đầu tiên với tổ vì nó thiết lập nên chứng danh của người quản lí. Phần lớn các thành viên tổ sẽ hình thành ý kiến nào đó về “người quản lí dự án” của họ trong cuộc họp này. Phán xét của họ sẽ xác định liệu họ có muốn làm việc cho người này hay không. Qui tắc của tôi là: “Lịch biểu, chức năng, chi phí tất cả đều thương lượng được.” Người quản lí dự án giỏi phải thảo luận kế hoạch này với tổ, lắng nghe mối quan tâm và ý kiến của họ và nếu cần, sẵn lòng thay đổi tương ứng. Người đó phải sẵn lòng quay lại với khách hàng hay người quản lí cấp cao để thảo luận về những thay đổi này và tìm kiếm thoả thuận. Qui tắc khác của tôi là: “Lập kế hoạch dự án là nỗ lực tổ, không phải nỗ lực cá nhân.” Lập kế hoạch không phải là hoạt động một lúc mà liên tục trong toàn dự án với các thành viên tổ cung cấp cái vào. Người quản lí dự án phải lắng nghe một cách cẩn thận, thảo luận và thu lấy thoả thuận từ mọi thành viên tổ, để hoàn thành lần cuối bản kế hoạch dự án.
Trong khi thực hiện dự án, người quản lí dự án phần mềm phải thường xuyên giám sát tiến bộ để đảm bảo rằng tổ dự án đang làm việc tương ứng. Bản tính con người là tìm kiếm công bằng và điều quan trọng là công bằng với mọi người. Sẽ là không công bằng khi người quản lí thiên về người này hơn người khác trong đề bạt, lương và các thưởng khác. Điều này có thể làm tổn hại cho tinh thần của tổ và tạo ra vấn đề cho dự án. Vài năm trước đây, tôi đã được mời tới một công ti phần mềm nơi nhiều sinh viên của tôi cũng làm việc ở đó. Tôi đã bảo họ rằng tôi có cơ hội để gặp cấp quản lí của họ và hỏi liệu họ muốn tôi nói điều gì đó nhân danh họ không. Tôi nhận được nhiều email tương tự đáp lại cho email này: “Xin bảo họ học là người lãnh đạo chứ đừng là kẻ độc tài. Xin nhắc nhở họ rằng con người không phải là cái gì đó họ có thể vứt bỏ. Khi người quản lí không đối xử công bằng với mọi người, làm sao bất kì ai có thể mong đợi họ làm hết sức mình cho công ti được.” Những phàn nàn này từ những người phát triển, những người cũng là sinh viên cũ của tôi, đã làm bận lòng tôi nhiều. Sau vài cuộc họp với cấp quản lí, tôi kết luận rằng quản lí cấp cao thực sự đã không biết điều gì xảy ra trong công ti của họ. Họ có thể biết cái gì đó về kinh doanh của họ nhưng gần như không biết gì về con người. Nhiều người quản lí không có kinh nghiệm phần mềm vẫn quản lí dự án phần mềm. Họ không thể quản lí được cái gì đó họ không hiểu. Một cách lí tưởng, họ nên giỏi hơn những người họ quản lí nhưng nhiều người trong số họ tới vị trí của họ từ khu vực kinh doanh và không hiểu phát triển phần mềm chút nào. Là khách, tôi không thể nói nhiều được nhưng đã khuyến cáo rằng họ nên khởi đầu về đào tạo thêm về quản lí. Không may là người quản lí cấp cao bảo tôi: “Về căn bản, mọi vấn đề đều là kĩ thuật. Nếu ông biết điều ông muốn làm và có đủ người kĩ thuật thì không có lí do gì trong việc đào tạo quản lí thêm. Hiển nhiên, chúng tôi không có đủ người kĩ thuật và chúng tôi phải thuê thêm.” Vài tháng sau, tôi thấy quảng cáo rằng công ti đó muốn thuê nhiều người phát triển phần mềm. Đến cuối năm đó, công ti đó nộp đơn phá sản khi họ cạn kiệt mọi vốn.
Một cựu sinh viên về sau giải thích: “Họ không bao giờ thừa nhận vấn đề của họ. Họ giữ việc thuê ngày càng nhiều người phát triển và thêm ngày càng nhiều người trong các dự án muộn làm cho nó thành tồi tệ.” Nhiều người quản lí che giấu sự bất tài của họ bằng việc phàn nàn rằng họ không có đủ người kĩ thuật. Không ai biết cách quản lí con người cho nên thêm nhiều người, thêm nhiều vấn đề. Khi tổ bị cảm thấy dường như cấp quản lí không hỗ trợ cho họ thì điều đó gây hư hại nghiêm trọng cho tổ. Đây là chỗ “vấn đề trách cứ” xảy ra. Khi mọi người bắt đầu trách cứ lẫn nhau, việc làm việc tổ bị tan rã và chìm xuống thấp. Khi các thành viên tổ giận nhau, không ai sẵn lòng làm cái gì và chấm dứt làm việc với nhau. Đây là lí do tại sao nhiều dự án thế đã thất bại. Họ đã không thất bại về vấn đề kĩ thuật mà thất bại về vấn đề con người.”
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
