The Mythical Man-Month

Hiệu ứng Hệ thống thứ hai

Hệ thống thứ hai hay Hiệu ứng hệ thống thứ hai mà một kỹ sư thiết kế ra là hệ thống nguy hiểm nhất mà kỹ sư đó đã từng thiết kế, khi kỹ sư đó hướng tới việc tích hợp chặt chẽ tất cả những tính năng cộng thêm anh ta đã tạo ra nhưng lại không thêm vào hệ thống đầu tiên (do sự giới hạn thời gian). Vậy thì, khi bắt đầu thực hiện hệ thống thứ hai, một kỹ sư nên luôn ghi nhớ rằng anh ta nên nhạy cảm với việc tăng cường nhiều tính năng kỹ thuật.

Quản lý tiến trình

Câu hỏi: Một dự án lớn sẽ trở thành trễ một năm như thế nào? Câu trả lời: Một ngày tại một thời điểm! Việc không giữ đúng thời hạn tăng dần cuối cùng sẽ dồn lại và phát sinh sự chậm trễ lớn. Tiếp tục chú ý để đạt các mốc nhỏ rất cần thiết tại mỗi cấp quản lý.

Nhận thức về tính toàn vẹn của hệ thống

Để tạo một hệ thống thân thiện với người dùng, một hệ thống phải có một nhận thức toàn vẹn, điều chỉ có thể đạt được bằng cách tách biệt kiến trúc khỏi việc thực thi. Một kiến trúc sư trưởng (hoặc một nhóm nhỏ kiến trúc sư), sẽ hành động như là một user, quyết định cái gì sẽ được để vào và cái gì sẽ được bỏ ra khỏi hệ thống. Một "ý tưởng siêu hạng" bởi một người sẽ không được thêm vào nếu nó không phù hợp với toàn bộ thiết kế hệ thống. Thực tế, để đảm bảo một hệ thống thân thiện với người dùng, một hệ thống có thể có ít hơn những tính năng mà nó có thể có nhưng những tính năng đó đều được cân nhắc thận trọng. Nếu một hệ thống sử dụng quá phức tạp, nhiều tính năng sẽ trở thành vô dụng vì không ai có thời gian để học hỏi nó.

Tài liệu sử dụng

Kiến trúc sư trưởng là người sẽ tạo ra tài liệu kỹ thuật của hệ thống dưới hình thức tài liệu hướng dẫn sử dụng. Tài liệu nên mô tả đặc điểm kỹ thuật của hệ thống một cách chi tiết, ví dụ: tất cả những gì mà người dùng thấy được. Tài liệu nên được chỉnh sửa theo phản hồi từ nhóm phát triển và người dùng.

Hệ thống Pilot

Khi thiết kế một hệ thống mới, nhóm sẽ thiết kế một hệ thống "vứt đi" (cho dù nó có mục đích hay không). Hệ thống này là một "kế hoạch thử nghiệm" để biểu diễn những kỹ thuật để sau đó thiết kế lại toàn bộ hệ thống. Hệ thống thứ 2 "thông minh hơn" nên được chuyển một lần đến khách hàng, từ khi việc gửi hệ thống pilot, dù hệ thống pilot không gây ra vấn đề gì nhưng có thể gây lo âu cho khách hàng, và cuối cùng là hủy hoại danh tiếng của hệ thống, có khi là cả của công ty.

Tài liệu chính thức

Mỗi quản trị dự án nên tạo một tập các tài liệu gọi là tài liệu chính thức có vai trò định hướng cho mục tiêu của dự án, cách thức đạt được những mục tiêu đó, ai sẽ là người đạt đến những mục tiêu đó, khi nào thì sẽ đạt được những mục tiêu đó, và giá trị của những mục tiêu đó. Những tài liệu này có thể sẽ làm xuất hiện sự mâu thuẫn và có thể chỉ ra rằng khó mà đạt được những mục tiêu đó.

Đánh giá dự án

Khi đánh giá thời gian của một dự án, nên nhớ rằng, để lập trình một sản phẩm (có thể bán cho khách hàng) và hệ điều hành thì sẽ khó gấp ba lần để viết một ứng dụng. Nên luôn giữ trong đầu về thời gian sẽ phải bỏ ra để giải quyết những vấn đề kỹ thuật, những phản đối với việc quản trị hay những nhiệm vụ không thuộc về kỹ thuật, ví dụ như họp hành.

Trao đổi thông tin

Để tránh những thảm họa, tất cả những cá nhân trong một dự án nên giao tiếp với các thành viên trong nhóm bằng nhiều cách nhất có thể (e-mail, điện thoại, họp, ghi chú v.v...). Thay vì phải giả định điều gì, lập trình viên đó nên hỏi kiến trúc sư của dự án để làm rõ mục đích của một tính năng mà mình sẽ hiện thực, trước khi thực hiện với một giả định mà nó có thể dẫn tới việc hoàn toàn sai.

Nhóm phẫu thuật

Như nhiều nhóm phẫu thuật trong khi phẫu thuật, có một phẫu thuật viên là người dẫn đầu, sẽ tự mình thực hiện những công việc nguy cấp nhất trong khi chỉ đạo nhóm của anh ta giúp đỡ mình hoặc thực hiện những phần việc đơn giản hơn. Tương tự, sẽ có một "lập trình viên giỏi" thực hiện những phần việc khẩn cấp trong khi cả nhóm cung cấp những gì cần thiết một cách kịp thời. Ngoài ra, Brooks cho rằng một lập trình viên giỏi sẽ nhanh hơn gấp 5-10 lần so với một lập trình viên bình thường. Tham khảo Organization and Team Patterns.

Ổn định mã nguồn và đặt phiên bản hệ thống

Phần mềm thì không thể thấy được. Bởi vậy, nhiều thứ chỉ có thể xuất hiện một khi một khối lượng công việc cho hệ thống mới đã hoàn tất và cho phép người dùng có thể sử dụng nó. Software is invisible. Therefore, many things only become apparent once a certain amount of work has been done on a new system, allowing a user to experience it. This experience will yield insights, which will change a user's needs or the perception of the user's needs. The system should, therefore, be changed to fulfill the changed requirements of the user. This can only occur up to a certain point, otherwise the system may never be completed. At a certain date, no more changes would be allowed to the system and the code would be frozen. All requests for changes should be delayed until the next version of the system.

Tool chuyên dụng

Cho dù mỗi lập trình viên đều có riêng cho mình một số tool đặc biệt, mỗi một nhóm cũng nên chỉ định một người tạo tool, người đó sẽ tạo những tools được thiết kế đặc biệt cho công việc mà nhóm đang làm. ví dụ, một tool sinh mã nguồn tự động dựa trên yêu cầu của khách hàng. Ngoài ra, một hệ thống tool lớn nên được thực hiện bởi một nhóm chuyên viết tool, được quản lý bởi quản trị dự án.