Bài học quản lý dự án và phương pháp hay nhất nào chúng ta có thể học hỏi từ ngành kỹ thuật và xây dựng?

Question

Thực tế là các dự án CNTT thất bại với một tốc độ đáng báo động (một số khảo sát cho thấy tỷ lệ thất bại là hơn 60%). Thông thường, các nhà quản lý dự án cố gắng "phục hồi" từ những thất bại này bằng cách ép các nguồn lực của họ để làm việc thêm giờ hoặc bằng cách thỏa hiệp chất lượng của các sản phẩm phân phối (giảm nỗ lực thử nghiệm, giảm phạm vi, vv). Thật không may, chất lượng phần mềm không được coi là rất quan trọng bởi các nhà lãnh đạo doanh nghiệp.

Tôi tự hỏi điều này có đúng với các ngành nghề khác không? Các dự án được quản lý như thế nào, ví dụ, trong ngành xây dựng nơi mà chi phí thất bại là rất cao và một sai lầm duy nhất có thể là thảm họa? Các dự án kỹ thuật lớn như tháp Eurotunnel và Petronas yêu cầu hàng nghìn người và hàng tỷ đô la để xây dựng và hầu hết các dự án này đã được hoàn thành thành công trong hoặc đôi khi thậm chí trước thời gian.

Có một số bài học chúng ta có thể tìm hiểu về cách các dự án được lên kế hoạch và quản lý trong các ngành khác không?

Answer 1

Hãy lấy một cây cầu làm ví dụ và so sánh nó với phần mềm.

Cầu sẽ có ít thông số kỹ thuật bên ngoài hơn. Nó sẽ có một số chi tiết kỹ thuật khá chính xác, nhưng rất nhiều trong số đó sẽ là nội bộ (chẳng hạn như điểm mạnh vật chất).

Nó sẽ được thiết kế bởi những người biết rằng thiết kế cầu không được vội vã quá mức. Nói chung, các kỹ sư dân dụng sẽ nhận được sự tôn trọng nhiều hơn từ quản lý của họ so với các nhà phát triển phần mềm. Các kỹ sư dân sự sẽ bổ sung thêm vào làm việc trong một không gian vấn đề hạn chế hơn nhiều. Không có nhiều cách để làm cầu nối như một hệ thống kiểm kê.

Khi thiết kế xong, một hoặc nhiều kỹ sư chuyên nghiệp được cấp phép sẽ đăng xuất trên đó. Điều này đang chấp nhận trách nhiệm thực sự.(Thay vào đó, không PE nào đặt cược vào giấy phép của mình về âm thanh của nó, và thiết kế sẽ không đi đâu cả.) Điều này không xảy ra trong phần mềm, một phần vì không gian vấn đề rất không bị giới hạn.

Cuối cùng, cây cầu sẽ được xây dựng, và điều này sẽ mất hàng tháng và rất nhiều thiết bị nặng. Phần mềm sẽ được xây dựng ban đầu với một trình biên dịch và tái tạo vô thời hạn với các công cụ rẻ tiền. Có một ý nghĩa tâm lý lớn ở đây: mọi người có xu hướng nghĩ về các dự án như có thiết kế quan trọng và các giai đoạn sản xuất quan trọng, và nếu sản xuất quá tầm thường có xu hướng nghĩ đến một phần của thiết kế là sản xuất.

Nếu phần mềm giống như kỹ thuật dân dụng, chúng tôi cần thực hành tiêu chuẩn, đầy đủ và đáng tin cậy, đối với hầu hết mọi thứ. Chúng tôi cần các kỹ sư để nghiên cứu các thực hành đó và sẵn sàng chứng nhận rằng phần mềm đó đã hoặc không được thiết kế đúng cách và trên thực tế chúng tôi cần các dự án được thực hiện theo các thực hành đó gần như hoàn toàn đáng tin cậy. Chúng ta cần giả định chính thức hơn về trách nhiệm ở đó. Chúng ta cần sự tôn trọng bên ngoài hơn, bởi vì các nhà quản lý không dám vứt bỏ một dự án xây dựng trị giá 10 triệu đô la bằng cách can thiệp thường sẽ không có chút phiền toái nào về việc làm rối tung một dự án phần mềm trị giá 20 triệu đô la.

Tóm lại, phần mềm quá non nớt một kỷ luật để làm việc như kỹ thuật dân dụng.

Answer 2

Có sự khác biệt giữa phát triển phần mềm và kỹ thuật hoặc công nghiệp xây dựng - có thể thay đổi thông số kỹ thuật.

Đi bộ trên mặt nước và phát triển phần mềm từ đặc điểm kỹ thuật dễ dàng nếu cả hai đều bị đóng băng.

- Edward V Berard (from here)

Bạn có thể tìm thấy lời giải thích chi tiết hơn về sự khác biệt trong cách tiếp cận để quản lý dự án vào đầu của "Extreme Programming Applied" cuốn sách.

Answer 3

Tôi nghĩ sự khác biệt lớn nhất là họ sẽ không bao giờ xem xét việc bắt đầu một dự án với cùng một loại yêu cầu kém chất lượng mà chúng tôi đưa ra. Có lẽ chúng ta cũng nên ngừng làm như vậy và buộc mọi người phải xác định những gì họ muốn trước khi chúng tôi bắt đầu cố gắng viết mã.

Tôi muốn thêm rằng chúng tôi là một ngành công nghiệp cho một công việc tồi tệ của việc đẩy lùi với một dòng thời gian và ngân sách mới khi các yêu cầu (chẳng hạn như chúng) thay đổi. Chúng tôi bắt đầu thực hiện nhiều hơn nữa việc đẩy lùi này tại đây, cho khách hàng biết thêm bao nhiêu giờ (và nhiều tiền hơn) thay đổi được yêu cầu, thêm hai ngày nữa để thực hiện hạn chót và khiến họ chính thức đưa ra yêu cầu thay đổi . Số lượng các thay đổi được yêu cầu đối với các yêu cầu nội bộ giảm đáng kể khi chúng tôi nhấn mạnh sẽ có chi phí cho sự thay đổi. Sự thay đổi này cũng chuyển chúng tôi từ một trung tâm chi phí đến một trung tâm lợi nhuận trong công ty vì chúng tôi đã làm rất nhiều công việc phụ nhưng không tính phí cho khách hàng nhiều hơn ước tính ban đầu.

Answer 4

Bài học có thể học được từ kỹ thuật: tôn trọng các yêu cầu không hoạt động.

Yêu cầu chức năng là khó đủ, như họ mong đợi người dùng, nhà phát triển, nhà phân tích và bất kỳ ai khác có liên quan để có thể xác định những gì cần thiết để kinh doanh.

Các yêu cầu không phải chức năng là những kỹ sư và kỹ thuật đưa ra những người chức năng có thể bị mù. Nó rất dễ dàng để bỏ qua hoặc giảm bớt các phi chức năng. Một số PM mà tôi đã từng làm trước đây không muốn nghe về những người không có chức năng vì họ không thể trực tiếp bị ràng buộc với nhu cầu kinh doanh và giới thiệu các nhiệm vụ có thể đe dọa đến các số liệu "về thời gian và ngân sách".

Ví dụ

chức năng yêu cầu: tàu sang trọng phải có khả năng mang theo số tiền X của hành khách

yêu cầu

phi chức năng: Ship đủ lớn để thực hiện số tiền X của hành khách cần có thân Y đơn vị dày để duy trì tính toàn vẹn ngay cả khi tác động với tảng băng trôi

Đếm chi phí

Tại sao PM phần mềm không tôn trọng các yêu cầu không phải chức năng? Bởi vì chi phí cho sự thiếu tôn trọng như vậy là khác nhau cho kỹ thuật hơn là để phát triển phần mềm.

Chi phí bỏ qua các yêu cầu không hoạt động trong ví dụ về tàu của tôi: mất mạng.

Chi phí bỏ qua đối với những người không có chức năng trong phần mềm: một số điều kỳ quặc được gọi là nợ kỹ thuật, sau này sẽ được người dùng loại bỏ khỏi nhóm dự án và tiền thưởng hoàn thành của nhóm dự án.

Cấp các ví dụ của tôi là đơn giản. Không phải tất cả các kỹ thuật đều dẫn đến cái chết trong khi một số phần mềm bị lỗi chắc chắn có thể (hệ thống điện tử, y tế, hoặc hệ thống kiểm soát giao thông là một vài ví dụ).Nhưng tôi nghĩ bạn có ý tưởng.