Báo cáo Quản lí dự án cho kĩ sư - Làm thế nào để áp dụng tư tưởng hệ thống vào trong quản lý dự án
Bảng phân công công việc trong nhóm:
Mức độ hoàn
thành công việc
Thành viên
Công việc
1. Đọc toàn bộ bài viết, nắm ý của từng phần, phân
công công việc cho các thành viên.
2. Dịch và thuyết trình phần “fixes that fail”.
3. Thiết kế power point trắng cho phần thuyết trình
cá nhân.
Cao Việt Cường
(nhóm trưởng)
100%
1. Đọc và nắm ý toàn bộ bài thuyết trình của nhóm.
2. Đưa ra ý tưởng, thiết kế và chỉnh sửa hiệu ứng
cho power point của toàn bộ bài thuyết trình.
3. Tổng hợp file word thành bài báo cáo hoàn
chỉnh.
Trần Vân Anh
1. Đọc và nắm ý toàn bộ bài thuyết trình của nhóm.
2. Dịch và thuyết trình 2 phần “levels of
Trần Hoàng Anh Khoa understanding” và “the tragedy of commons”.
3. Thiết kế power point trắng cho phần thuyết trình
cá nhân.
1. Đọc và nắm toàn bộ bài thuyết trình của nhóm.
2. Dịch và thuyết trình 2 phần “limits to growth” và
Hà Nhật Tảo
“shifting the burden”.
3. Thiết kế power point trắng cho phần thuyết trình
cá nhân.
HOW TO APPLY SYSTEMS THINKING IN MANAGING PROJECT
( Làm thế nào để áp dụng tư tưởng hệ thống vào trong quản lý dự án)
Trong những phần trước đã đề cập đến vấn đề tư tưởng hệ thống có thể giúp ta hiểu được
những động lực trong các mối quan hệ giữa người với người. Nói chung, các công việc dự án
được con người đảm nhiệm nên ta cần phải áp dụng những khái niệm về tư tưởng hệ thống để có
thể hiểu và quản lý được các dự án.
1. FIXES THAT FAIL
Hãy bắt đầu bằng một vấn đề thường gặp nhất trong dự án: công việc bị chậm tiến độ so với
kế hoạch. Dẫn đến việc yêu cầu nhân viên phải tăng ca thêm vài giờ làm mỗi ngày để cho kịp
tiến độ. Nếu chỉ trong 1 tuần, có thể nhân viên sẽ đồng ý làm 12 giờ mỗi ngày để xúc tiến công
việc. Lượng công việc hoàn thành chắc chắn sẽ tốt hơn trước. Tuy nhiên, sau một vài tuần, người
nhân viên đó sẽ phạm rất nhiều sai lầm (chắc chắn là cần được sửa lại). Hơn nữa, bạn sẽ thấy
rằng năng suất cũng như chất lượng của nhân viên đó tụt dốc nhiều so với những gì bạn thấy
trong tuần đầu tiên. Thực chất, nếu bạn để ý sẽ thấy lượng công việc mà nhân viên đó dù có dốc
hết sức làm cũng chỉ bằng lúc anh ta làm việc bình thường (40 giờ một tuần). Nhưng bạn đã vô
tình làm mất đi năng suất công việc bởi bây giờ phải tốn thêm thời gian sửa lỗi mà anh ta gây ra
và điều này đã giảm đi năng suất của nhân viên khá nhiều.
Cần phải làm một điều gì đó để giải quyết tình trạng này.
Bạn sẽ quyết định rằng nếu tăng ca không phải là đáp án, vậy thử tăng nguồn lực thì vấn đề có
được giải quyết không? Bạn thuyết phục sếp huy động thêm một người mới đến hỗ trợ. Thật
ngạc nhiên rằng lượng công việc hoàn thành do hai người không khác gì so với một người. Đáng
quan tâm hơn cả là nhiều lỗi có thể xảy ra hơn nữa. Chuyện gì đã xảy ra ở đây?
Bạn họp lại với các thành viên ban đầu của nhóm dự án, có ý kiến cho rằng: “Chuyện đó rất
đơn giản. Người mà anh mới đưa đến hỗ trợ tôi không biết gì về việc tôi đang làm. Tôi phải
hướng dẫn hắn gần như cả ngày thứ hai. Sau đó, tối thấy anh ấy làm sai rất nhiều lỗi và tôi phải
là người giúp sửa hết những lỗi đó, và tôi vẫn phải làm tăng ca để đào tạo hắn, để sửa lỗi cho
hắn. Tôi không cần bất kỳ sự giúp đỡ nào khác, điều đó sẽ tốt hơn!”
Đây là một ví dụ của “fixes that fail”. Bắt một nhân viên phải làm việc tăng ca sẽ gây ra sự
mệt mỏi kéo dài cho nhân viên đó. Do vậy mà anh ấy sẽ mắc nhiều lỗi hơn trong công việc.
Những lỗi đó cần phải được sửa chữa, như vậy nhân viên lại phải làm cực hơn, làm cho anh ấy
mệt mỏi hơn và rồi lại gây ra nhiều lỗi hơn. Cứ như vậy nó sẽ tạo thành một vòng lẩn quẩn
không giải quyết được vấn đề. Và rồi nếu có 1 người mới được điều đến để hỗ trợ dự án. Nhân
viên cũ lại phải chỉ dẫn cho người mới đến, không chỉ làm giảm năng suất làm việc mà còn buộc
nhân viên cũ phải làm việc mệt nhọc hơn, lỗi lại tiếp tục xảy ra và vòng tròn trên được lặp lại.
Một ví dụ khác, có một công ty tên là Acme Electronics sản xuất ra các linh kiện rồi sau đó
chuyển các linh kiện đó cho một công ty khác lắp ráp lại với nhau thành sản phẩm. Thỉnh thoảng,
khách hàng báo về có một số vấn đề liên quan đến 1 trong những linh kiện đó. Và nếu như công
ty có khả năng giải quyết vấn đề đó, họ sẽ gửi kỹ sư thiết kế đến. Do công việc chủ yếu của
những kỹ sư này là thiết kế ra những linh kiện mới nên công việc thiết kế của họ bị dừng lại. Họ
lập kế hoạch để giải quyết vấn đề cho khách hàng rồi mới trở lại công việc.
Không may là thời hạn để hoàn thành công việc thiết kế linh kiện không thay đổi, và họ bị trễ
tiến độ. Giải pháp duy nhất hiện có là làm việc cật lực để cố gắng hoàn thành công việc được
giao. Kết quả vẫn giống như trường hợp trên, chất lượng công việc của họ bị giảm sút, không đạt
yêu cầu. Linh kiện mới được tung ra thị trường, lại có vấn đề với những linh kiện này ở khách
hàng. Công việc thiết kế lại bị trì trệ. Họ làm nhiều hơn để hoàn thành công việc, và rồi lại tạo ra
sản phẩm không tốt, cứ như vậy vòng tròn ấy sẽ lặp lại tuần hoàn.
Từ thường được dùng để mô tả trường hợp này là “fire-fighting” (chữa cháy). Theo từ điển,
“Fire-fighting” có nghĩa là “the practice of dealing with problems as they arise rather than
planning strategically to avoid them, in business”. Các kỹ sư thường làm việc theo kiểu chữa
cháy như vầy mà không có một kế hoạch gì để ngăn chặn những hậu quả (fires) cho tương lai.
3 trang
28/04/2022
3440
Bạn đang xem tài liệu "Báo cáo Quản lí dự án cho kĩ sư - Làm thế nào để áp dụng tư tưởng hệ thống vào trong quản lý dự án", để tải tài liệu gốc về máy hãy click vào nút Download ở trên
File đính kèm:
- bao_cao_quan_li_du_an_cho_ki_su_lam_the_nao_de_ap_dung_tu_tu.docx
