Thực thi hiện đại hóa kiến trúc: Từ khi nào ước tính trở thành hạn chót?

• Mẹo cho các dự án hiện đại hóa phần mềm phức tạp: cần xem ước tính như định hướng chứ không phải hạn chót.

• Trải nghiệm cá nhân:

  • Sau kỳ nghỉ vui vẻ ở Seoul và Sokcho, tác giả định viết về tư duy hệ thống và cuốn sách "Zen and the Art of Motorcycle Maintenance", nhưng kế hoạch đã thay đổi vì những sự việc trong 2 tuần gần đây.
  • Tác giả gặp tai nạn vào cuối tuần trước cuộc bầu cử ở Mỹ và cũng trải qua cuộc đình công của giới kỹ thuật tại công ty New York Times.

• Ước tính - nghệ thuật hay khoa học?:

  • Giải thích sự khác biệt về ước tính và quá trình thương lượng giữa giám định viên bảo hiểm và xưởng sửa xe trong quá trình sửa ô tô.
  • Nếu phát hiện hư hỏng ngoài dự kiến, có thể phát sinh thêm chi phí và cần sự phê duyệt từ công ty bảo hiểm.

• Sự tương đồng với hiện đại hóa kiến trúc phần mềm phức tạp:

  • Mô tả sự khác biệt giữa ước tính ban đầu và mức độ phức tạp thực tế trong quá trình hiện đại hóa phần mềm legacy.
  • Mỗi khi phát hiện thêm độ phức tạp, lại cần có phê duyệt bổ sung.

• Nhà lãnh đạo giỏi đặt đúng câu hỏi:

  • Việc đặt ra những câu hỏi đúng để giải quyết vấn đề phức tạp là rất quan trọng.
  • Bài viết bàn về cách phản ứng khi phát hiện độ phức tạp ngoài dự kiến.

• Tiếp tục hay coi như tổn thất toàn phần?:

  • Mô tả các trường hợp dự án hiện đại hóa được duyệt thêm chi phí để tiếp tục hoặc bị dừng lại.

• Bối cảnh phức hợp, hay chỉ là bối cảnh phức tạp?:

  • Sử dụng khung Cynefin để giải thích quá trình ra quyết định trong các tình huống phức hợp.
  • Nhấn mạnh tầm quan trọng của việc học hỏi và thử nghiệm trong các dự án phần mềm legacy phức hợp.

• Phủ nhận - tức giận - thương lượng - trầm uất - chấp nhận?:

  • Giải thích cách ứng phó với các tình huống ngoài dự kiến trong dự án hiện đại hóa.
  • Giới thiệu mô hình của Ron Westrum về cách văn hóa tổ chức phản ứng với những tình huống như vậy.

• Mẹo cho các lãnh đạo dẫn dắt sáng kiến hiện đại hóa:

  • Trong miền vấn đề phức hợp, cần cách quản lý mang tính thử nghiệm và việc chấp nhận thất bại là điều quan trọng.
  • Nếu lãnh đạo cố áp đặt trật tự, họ sẽ thất bại; để các mô thức tự xuất hiện mới là chìa khóa thành công.

• Một hy vọng mới:

  • Qua trải nghiệm sửa xe và xử lý bảo hiểm, bài viết nhấn mạnh tầm quan trọng của ước tính trong các dự án hiện đại hóa.
  • Tác giả hy vọng các công ty phần mềm và đội ngũ lãnh đạo sẽ dùng đúng khung đánh giá thành công.

[GN⁺]

Ý kiến trên Hacker News

• Đã có những trường hợp quản lý coi ước tính như hạn chót. Mỗi khi đặc tả thay đổi thường xuyên, người ta dùng phản ứng kiểu "nai gặp đèn pha" để câu thêm thời gian, đồng thời đưa ra ước tính bảo thủ nhất có thể và hoàn thành sớm hơn lịch như một chiến lược. Với quản lý giỏi thì không cần đến chiến lược như vậy.

• Các dự án hiện đại hóa thường có hạn chót mềm, cùng áp lực ngân sách và yêu cầu từ người dùng, nhưng chậm một ngày cũng không gây vấn đề lớn. Ngược lại, với những trường hợp như phóng tàu thăm dò không gian hay các tập đoàn lớn như Ford, lỡ hạn chót có thể gây thiệt hại rất lớn.

• Michelangelo từng ước tính sẽ hoàn thành lăng mộ của Giáo hoàng Julius II trong vòng 5 năm, nhưng thực tế mất tới 40 năm. Lý do là phạm vi dự án bị thu hẹp vì thay đổi yêu cầu từ khách hàng, vấn đề chuỗi cung ứng và việc tái đàm phán hợp đồng.

• Ước tính ban đầu thường bám rất lâu trong trí nhớ, và ngay cả khi có thông tin mới thì cũng thường khó thay đổi ước tính đó. Vì thế có những người ngại đưa ra ước tính.

• Thường xảy ra chuyện công ty bảo hiểm chỉ muốn chi trả đúng theo ước tính ban đầu. Điều này áp dụng với bảo hiểm ô tô, nhà ở lẫn sức khỏe, và không phải lúc nào cũng dẫn đến kết quả hợp lý.

• Điều quan trọng là đưa ra ước tính cho một phạm vi cố định, rồi bổ sung các mốc mới cho phần việc phát sinh được phát hiện thêm. Tuy nhiên, cách tiếp cận này đòi hỏi tầng quản lý phải hiểu được nó.

• Lãnh đạo nghĩ rằng hạn chót sẽ tạo động lực, nhưng đó là một cách tiếp cận sai. Nếu không điều chỉnh hạn chót theo thực tế, tinh thần của cả nhóm có thể đi xuống.

• Ủng hộ cách tiếp cận "No Estimates", theo đó chỉ có thể ước tính chính xác khi công việc giống hệt những gì đã làm trước đây, hoặc khi phần việc còn lại đã được định nghĩa rõ ràng.

• Có một công thức ước tính thú vị, là công thức không chính thức dựa trên kinh nghiệm cá nhân. Ví dụ, nó tính thời gian thực tế cần thiết bằng cách xem xét số người tham gia dự án, số công cụ mới, v.v.

• Hệ thống ước tính tốt nhất là mỗi người đưa ra ngày hoàn thành, rồi người đoán gần nhất sẽ được ăn trưa miễn phí. Cách này được dùng giữa bạn bè với nhau và cho kết quả rất chính xác.

• Doanh nghiệp muốn dự đoán chính xác tương lai, nhưng điều đó là không thể. Ước tính chủ yếu được nhấn mạnh ở tầng quản lý, và những người đưa ra ước tính chính xác cũng không được thưởng. Nếu chỉ tập trung vào thời gian, những yếu tố quan trọng khác có thể bị ảnh hưởng tiêu cực.