Bối cảnh: Công ty nhận được một dự án cấp tỷ, trong đó phần mềm chiếm khoảng 1/4. Toàn bộ dự án bao gồm các nhóm phần cứng và phần mềm. Nhóm phần mềm thực sự là một sản phẩm phần mềm cho phép nó điều khiển các thiết bị phần cứng khác nhau để vận hành tự động và mở dữ liệu từ các hệ thống ngược dòng và hạ nguồn. Phần mềm đồng thời phân tích thống kê (bao gồm machine learning và AI) hoạt động và thực hiện nhiệm vụ của toàn bộ thiết bị dự án nhằm phục vụ tối ưu hóa hoạt động tiếp theo.

Cơ cấu thành viên dự án: Người quản lý dự án lớn, chịu trách nhiệm về dự án này. Những việc cần làm trong dự án có thể giống như những việc của những người quản lý dự án thông thường, ngoại trừ quy mô sẽ ở mức cao hơn. Có thể hiểu rằng người quản lý nhóm phần cứng PMO chịu trách nhiệm lắp đặt và gỡ lỗi thiết bị cơ khí. và người quản lý nhóm phần mềm chịu trách nhiệm về các chức năng phần mềm, tiến độ và sắp xếp nhân sự. Trưởng nhóm (có khuynh hướng kỹ thuật) chịu trách nhiệm về các yêu cầu chức năng phần mềm và triển khai kỹ thuật, đồng thời chịu trách nhiệm kiểm tra và gỡ lỗi tích hợp phần cứng.

Lúc đầu, chỉ có 2 đến 4 nhân viên phần mềm tại chỗ. Mọi người đều hiểu rất rõ về các mô-đun mà họ chịu trách nhiệm và mục tiêu của họ rất rõ ràng. Tôi chủ động làm thêm giờ mỗi ngày, về cơ bản có ý thức làm việc 10 tiếng mỗi ngày, không phàn nàn, đồng thời cho thấy dấu hiệu của một tập thể hiệu quả và nhanh nhẹn. Không có người lãnh đạo tại chỗ, chỉ có người quản lý dự án (người quản lý sản phẩm). Ở giai đoạn giữa của dự án, ngày càng có nhiều thành viên phần mềm tham gia dự án và sự phân công lao động của mọi người bắt đầu được cải tiến. Tuy nhiên, dự án ngày càng có nhiều vấn đề và hiệu quả ngày càng thấp. Không có sự gia tăng nhân sự như mong đợi để đẩy nhanh hiệu quả của toàn bộ dự án. Trưởng nhóm phần mềm không có mặt tại chỗ mà là trưởng nhóm từ nước ngoài xa xôi. Anh ấy thỉnh thoảng đến công trường nên bạn có thể tưởng tượng được sự gắn kết. Do không kiểm soát được tình hình tại chỗ và chưa sẵn sàng lãnh đạo một nhóm như tôi nên việc phân bổ công việc và tiến độ không được kiểm soát. Vì vậy, mọi người chỉ tập trung vào vấn đề của mình và từ chối động đến những việc không liên quan đến mình, bởi ai cũng cảm thấy mình chỉ là kỹ sư và những vấn đề phối hợp này nên chờ Leader điều phối. Về tiến độ và nhiệm vụ bạn đã hoàn thành, dù sao cũng không có ai theo dõi nên việc “trượt nước” là điều khó tránh khỏi. Chỉ cần những người có động lực chủ động nhận công việc, lần sau có nhiệm vụ chưa có người nhận, người quản lý dự án chỉ có thể ra mặt và trực tiếp giao cho những người có động lực cao. Bởi vì người này đã được tiếp xúc với mô-đun này nên sẽ có nhiều nhiệm vụ hơn cho mô-đun này được giao cho anh ta trong tương lai. Hậu quả là những người càng có động lực thì càng làm việc nhiều hơn. Sau này mọi người cũng học hỏi được nhiều điều, cứ thoải mái giải quyết, đừng hung hăng mà chỉ chờ người ta giao việc thôi. Đừng chủ động làm nếu có quá nhiều việc, bạn làm càng nhanh thì công việc mới sẽ chảy vào tay anh ấy. Bản chất lười biếng của con người được bộc lộ rõ ​​ràng. Thật khó để tưởng tượng rằng một dự án như vậy có thể hiệu quả. Quản lý dự án không có lịch trình nào về cơ bản, vấn đề gì hôm nay và vấn đề gì sẽ được giải quyết vào ngày mai? Không có kế hoạch dài hạn nào cả. Các thành viên trong nhóm không biết họ sẽ đi đâu và chỉ có thể thực hiện từng bước một. thời gian. Khi điều phối công việc, không có người lãnh đạo từ xa hoặc người lãnh đạo tại chỗ được chỉ định. Đội ngũ kỹ thuật cũng phân chia lãnh thổ rõ ràng đối với các vấn đề liên miền, họ có thể đến gặp bất kỳ ai họ muốn.

Để đối phó với điều này, toàn bộ nhóm sẽ được điều chỉnh như sau: 1. Loại bỏ người lãnh đạo từ xa và tìm người lãnh đạo tại chỗ. Người lãnh đạo này cần phải có tầm ảnh hưởng, hiểu rõ quy trình phát triển phần mềm và có khả năng đánh giá khối lượng công việc, đồng thời cần phải có. một sự hiểu biết về doanh nghiệp. 2. Người lãnh đạo không nên phát triển. Đối với những vấn đề hoặc thay đổi nhận được, hãy tìm người có thể giải quyết chúng, đánh giá kế hoạch và ước tính khối lượng công việc, đồng thời sắp xếp và theo dõi tiến độ. 3. Tổ chức các cuộc họp thường xuyên trong 15 phút mỗi sáng. và buổi chiều. Không được vượt quá thời gian này. Nếu nội dung kéo dài, mọi người sẽ cảm thấy chán ghét và mất tập trung, hiệu quả sẽ giảm mạnh. Bạn có thể để lại thông tin chi tiết cho người tương ứng sau cuộc họp để hiểu và sắp xếp riêng. Nếu nhiệm vụ gặp phải sự cố và bạn tạm thời không thể tìm ra giải pháp, hãy vượt qua, tìm hiểu thêm về vấn đề đó sau cuộc họp và chỉ định kế hoạch ứng phó, xem có nên thêm thời gian, sửa đổi kế hoạch hay thêm người bổ sung hay không. 4. Đối với các tính năng mới, hãy nhớ tìm người quản lý sản phẩm hoặc khách hàng để hiểu yêu cầu và gọi cho các nhà phát triển để cùng nhau hiểu khi cần thiết. Đối với các vấn đề hoặc tính năng có mức độ ưu tiên thấp hơn, bạn có thể đặt chúng vào một nhóm và đợi cho đến khi có quá nhiều nhân lực để xử lý chúng sau. 5. Các thông tin như nhiệm vụ của mỗi người, khối lượng công việc, độ khó, tiến độ hoàn thành, mức độ khẩn cấp của lỗi, trạng thái sửa chữa, tác động của lỗi, v.v. cần được định lượng và sau đó cung cấp cho người quản lý trực tiếp của nhân viên thực hiện để tham khảo đánh giá KPI. những điều chỉnh trên là: Cơ chế đánh giá định lượng được bổ sung hướng tới kết quả, minh bạch và công bằng. Tất nhiên, nếu không muốn bắt cả nhóm “nghiên cứu”, chúng tôi cũng không thể công khai toàn bộ số liệu một cách minh bạch mà chỉ nói với mọi người rằng có cơ chế đánh giá tương ứng. Đối với các thành viên dự án xuất sắc, giấy chứng nhận đánh giá cao do người quản lý dự án đặc biệt cấp sẽ được trao. Khi thực hiện các phương pháp trên, bạn cũng phải cân nhắc đến sự cân bằng. Con người không phải là máy móc và họ cũng cần kết hợp một số cảm xúc. Ví dụ, một số người không dám tích cực đấu tranh để kiếm sống và sống nội tâm hơn, trong khi một số người lại xấu hơn khi nói đến việc “ăn thích”. Với tư cách là người quản lý dự án, bạn cần phân công công việc một cách hợp lý cho những người không chủ động gấp rút làm việc nhưng vẫn làm việc hiệu quả. Bạn cũng nên thường xuyên lắng nghe ý kiến ​​của các thành viên để xem họ có sẵn lòng thực hiện những module nào đó không. , bạn cũng nên thường xuyên tìm các Thành viên khác để đào tạo và hướng dẫn (những hướng dẫn này cũng phải được ghi vào nhiệm vụ và được tính là KPI). Có nhiều phương pháp và lý thuyết về quản lý dự án phần mềm, nhưng chúng tất cả đều về việc cân nhắc lịch trình ngân sách và chất lượng và hướng tới mục tiêu. Vẫn cần phải liên tục sử dụng và điều chỉnh chúng trong công việc, đồng thời tích hợp và sử dụng các phương pháp khác nhau tùy theo tình hình thực tế, thậm chí kết hợp với kiến ​​thức đa lĩnh vực. Điều được nhấn mạnh ở đây là con người phải luôn là mối quan tâm hàng đầu của dự án. Nếu mọi người bị phân tâm, dự án sẽ khó quản lý. Trong toàn bộ quá trình vận hành dự án, phải quan tâm đến cảm xúc của từng thành viên và nếu có thể là sự phát triển của mỗi người. Trong cùng một dự án, chúng ta là “một gia đình”, và chúng ta không thể thực sự coi chúng như nguồn tài nguyên, và chúng sẽ cạn kiệt. Đó sẽ là một mất mát lớn cho công ty cũng như những trải nghiệm cá nhân và cá nhân của bạn. Nếu xét đến sự thành công của từng thành viên thì dự án nhìn chung rất khó thất bại, thậm chí nếu dự án thất bại thì bạn cũng sẽ đạt được rất nhiều.

  。

Chào mừng bạn đến để lại tin nhắn và học hỏi từ mọi người! .

  。

Cuối cùng, bài viết về hàng chục triệu dự án phần mềm hỗn loạn này kết thúc tại đây. Nếu bạn muốn biết thêm về hàng chục triệu dự án phần mềm hỗn loạn, vui lòng tìm kiếm các bài viết của CFSDN hoặc tiếp tục duyệt các bài viết liên quan. trong tương lai blog của tôi! .