Cách xây dựng tiến độ triển khai công nghệ

Vì vậy, tiến độ cần trả lời đồng thời bốn câu hỏi: phải làm những gì, công việc nào phải chờ công việc nào, ai hoặc nguồn lực nào thực hiện, và tại thời điểm nào dự án đủ điều kiện chuyển sang giai đoạn tiếp theo. Khi một trong bốn yếu tố thay đổi, lịch triển khai cũng cần được tính lại thay vì giữ nguyên một ngày đích không còn phù hợp.

Phân rã phạm vi thành các công việc có thể lập lịch

Đơn vị cơ bản của tiến độ là công việc có thể ước lượng, giao trách nhiệm và xác định điều kiện hoàn thành. Các nhãn chung như “triển khai hệ thống”, “tích hợp”, “kiểm thử” hoặc “đưa vào sử dụng” thường quá rộng để lập lịch vì bên trong mỗi nhóm còn nhiều hoạt động có thời lượng và quan hệ phụ thuộc khác nhau.

Chẳng hạn, một hạng mục tích hợp có thể gồm chuẩn bị môi trường, xác nhận giao diện dữ liệu, cấu hình kết nối, phát triển phần tùy biến, kiểm thử kết nối và xử lý lỗi. Nếu tất cả được gộp thành một dòng thời gian, chậm trễ ở một bước sẽ khó được phát hiện cho đến khi toàn bộ hạng mục trễ.

Mức phân rã nên đủ để mỗi công việc xác định được ít nhất:

·         Kết quả đầu ra cần tạo ra

·         Người hoặc nhóm chịu trách nhiệm

·         Điều kiện cần có trước khi bắt đầu

·         Thời lượng dự kiến

·         Tiêu chí xác nhận hoàn thành

Không cần chia một công việc thành các bước quá nhỏ nếu việc chia nhỏ không làm tăng khả năng ước lượng, kiểm soát hoặc phân công. Ngược lại, một công việc kéo dài qua nhiều giai đoạn nhưng chỉ có một trạng thái “đang thực hiện” thường là dấu hiệu cần tiếp tục phân rã.

Với triển khai công nghệ, phạm vi lập lịch cũng cần bao gồm những hoạt động thường bị bỏ sót như chuẩn bị dữ liệu, cấp quyền truy cập, thiết lập môi trường, kiểm thử người dùng, phê duyệt, đào tạo, chuyển đổi dữ liệu và chuẩn bị phương án quay lui. Những công việc này không trực tiếp tạo ra tính năng nhưng có thể quyết định thời điểm hệ thống đủ điều kiện vận hành.

Xác định quan hệ phụ thuộc trước khi chốt ngày thực hiện

Sau khi có danh sách công việc, bước tiếp theo là xác định logic thực hiện. Hai công việc xuất hiện cạnh nhau trong kế hoạch không có nghĩa là chúng có thể triển khai độc lập.

Quan hệ phổ biến nhất là công việc sau chỉ bắt đầu khi công việc trước hoàn thành. Ví dụ, kiểm thử tích hợp chỉ có ý nghĩa khi phiên bản cần kiểm thử đã được triển khai vào môi trường phù hợp. Tuy nhiên, không phải tất cả hoạt động đều phải nối tiếp hoàn toàn. Một số công việc có thể chạy song song hoặc bắt đầu khi công việc trước đã đạt đến một trạng thái đủ dùng.

Việc mô hình hóa phụ thuộc giúp phân biệt ba trường hợp quan trọng:

·         Phụ thuộc bắt buộc do kỹ thuật hoặc quy trình

·         Phụ thuộc do cách tổ chức nguồn lực

·         Phụ thuộc được đặt ra vì lựa chọn quản lý

Sự khác biệt này ảnh hưởng trực tiếp đến khả năng rút ngắn tiến độ. Phụ thuộc kỹ thuật thường khó loại bỏ, trong khi phụ thuộc do cùng một người phải thực hiện hai công việc có thể được xử lý bằng cách thay đổi phân bổ nguồn lực.

Từ mạng lưới phụ thuộc có thể xác định đường găng, tức chuỗi công việc mà sự chậm trễ của chúng trực tiếp đẩy ngày hoàn thành dự án về sau nếu không có độ dự trữ thời gian. Những công việc ngoài đường găng vẫn cần kiểm soát, nhưng có thể có một khoảng linh hoạt nhất định trước khi chúng bắt đầu ảnh hưởng tới mốc cuối.

Do đó, khi cần rút ngắn kế hoạch, không nên giảm thời lượng đồng loạt. Cần ưu tiên xem xét các công việc nằm trên hoặc có khả năng chuyển thành đường găng. Rút ngắn một hoạt động đang có nhiều thời gian dự trữ có thể làm kế hoạch trông nhanh hơn ở cấp tác vụ nhưng không thay đổi ngày hoàn thành thực tế.

Đưa năng lực nguồn lực vào phép tính tiến độ

Một lịch trình chỉ dựa trên thời lượng công việc nhưng bỏ qua khả năng huy động nguồn lực rất dễ tạo ra kế hoạch không thể thực hiện. Nếu cùng một chuyên gia được xếp thực hiện ba nhiệm vụ toàn thời gian trong cùng khoảng thời gian, ba nhiệm vụ đó không thực sự chạy song song dù biểu đồ tiến độ thể hiện như vậy.

Nguồn lực cần được kiểm tra theo cả số lượng và năng lực chuyên môn. Trong dự án công nghệ, nhiều công việc phụ thuộc vào những vai trò khó thay thế ngay, chẳng hạn kiến trúc sư hệ thống, chuyên gia bảo mật, quản trị cơ sở dữ liệu, kỹ sư tích hợp hoặc người có quyền phê duyệt thay đổi. Một nút thắt ở nhóm này có thể chi phối lịch trình mạnh hơn số lượng nhân sự tổng thể.

Khi tính lịch, nên xem xét:

·         Mức độ sẵn sàng thực tế của từng nguồn lực

·         Những nhiệm vụ khác mà nguồn lực đang đồng thời đảm nhiệm

·         Lịch nghỉ, lịch bảo trì hoặc khung thời gian không được phép thay đổi hệ thống

·         Năng lực chuyên môn cần thiết cho từng công việc

·         Thời gian chờ phê duyệt hoặc hỗ trợ từ bên thứ ba

Cần phân biệt thời lượng công việc với khối lượng lao động. Một nhiệm vụ cần 40 giờ công không mặc nhiên hoàn thành trong một ngày khi có năm người tham gia. Một số phần việc có thể chia nhỏ, nhưng nhiều nhiệm vụ kỹ thuật bị giới hạn bởi trình tự xử lý, thời gian chạy hệ thống, thời gian chờ phản hồi hoặc số lượng người có thể phối hợp hiệu quả.

Khi phân bổ nguồn lực làm phát sinh xung đột, lịch phải được điều chỉnh bằng cách đổi thứ tự công việc, thay đổi người thực hiện, bổ sung năng lực phù hợp hoặc chấp nhận kéo dài thời gian. Giữ nguyên tất cả công việc trong cùng một khoảng thời gian chỉ khiến xung đột bị ẩn khỏi kế hoạch.

Ước lượng thời lượng theo điều kiện thực hiện và mức độ bất định

Thời lượng nên phản ánh thời gian có khả năng cần thiết trong điều kiện triển khai thực tế, không chỉ là thời gian thao tác kỹ thuật thuần túy. Một thay đổi có thể chỉ mất vài giờ để cấu hình nhưng cần thêm thời gian cho kiểm thử, chờ phê duyệt hoặc phối hợp với hệ thống liên quan.

Cơ sở ước lượng có thể đến từ công việc tương tự đã thực hiện, dữ liệu lịch sử, đánh giá của người trực tiếp thực hiện hoặc phân tích các thành phần nhỏ hơn. Với công việc có mức bất định cao, việc chỉ ghi một con số duy nhất dễ tạo cảm giác chính xác hơn thực tế.

Có thể tách ba yếu tố khi đánh giá thời lượng:

1.    Khối lượng công việc: lượng thao tác hoặc sản phẩm phải hoàn thành

2.    Năng suất thực hiện: năng lực và mức độ sẵn sàng của nguồn lực

3.    Thời gian chờ: phê duyệt, phản hồi, xử lý hệ thống hoặc phụ thuộc bên ngoài

Việc thêm một tỷ lệ dự phòng giống nhau vào mọi công việc không thay thế được phân tích bất định. Rủi ro nên được đặt tại nơi nó thực sự phát sinh. Nếu một tích hợp phụ thuộc vào nhà cung cấp chưa xác nhận giao diện, chính hạng mục đó cần được nhận diện là bất định cao thay vì cộng thêm thời gian một cách cơ học cho toàn bộ kế hoạch.

Đối với các mốc có ảnh hưởng lớn, nên ghi rõ giả định làm cơ sở cho ước lượng. Ví dụ, thời lượng chuyển đổi dữ liệu có thể chỉ đúng khi chất lượng dữ liệu đầu vào đạt yêu cầu và khối lượng nằm trong phạm vi đã thống nhất. Nếu giả định bị phá vỡ, việc cập nhật lại thời lượng là điều chỉnh hợp lý chứ không phải sai lệch tùy tiện của kế hoạch.

Thiết kế mốc kiểm soát bằng tiêu chí hoàn thành

Mốc kiểm soát không nên chỉ là một ngày trên lịch. Mỗi mốc cần đại diện cho một trạng thái đủ điều kiện để dự án chuyển sang bước tiếp theo.

Ví dụ, “hoàn thành kiểm thử” là một mốc yếu nếu chưa xác định lỗi nào được phép còn tồn tại. Mốc rõ hơn có thể yêu cầu các kịch bản kiểm thử bắt buộc đã thực hiện, lỗi nghiêm trọng đã được xử lý và các vấn đề còn lại đã có quyết định chấp nhận hoặc kế hoạch khắc phục.

Một tiến độ triển khai công nghệ thường cần các mốc tại những điểm có thay đổi trạng thái đáng kể, chẳng hạn:

·         Phạm vi và thiết kế được phê duyệt

·         Môi trường triển khai sẵn sàng

·         Tích hợp kỹ thuật hoàn thành

·         Kiểm thử đạt điều kiện chấp nhận

·         Dữ liệu chuyển đổi được xác nhận

·         Sẵn sàng đưa hệ thống vào vận hành

·         Hoàn tất chuyển đổi và xác nhận vận hành ổn định

Không phải dự án nào cũng cần đúng các mốc trên. Mốc chỉ có giá trị khi nó tạo ra một quyết định kiểm soát cụ thể.

Cần đặc biệt phân biệt giữa “đã đến ngày dự kiến” và “đã đủ điều kiện qua mốc”. Nếu ngày go-live đã tới nhưng kiểm thử bắt buộc chưa đạt, việc giữ nguyên ngày chỉ để tuân thủ lịch sẽ chuyển rủi ro tiến độ thành rủi ro vận hành. Trong trường hợp đó, quyết định phù hợp phải dựa trên tiêu chí chấp nhận, mức độ ảnh hưởng và khả năng xử lý rủi ro chứ không chỉ dựa trên lịch.

Thiết lập baseline và kiểm soát thay đổi tiến độ

Khi phạm vi, phụ thuộc, nguồn lực và các mốc đã được xác nhận, kế hoạch có thể được thiết lập thành baseline để làm cơ sở so sánh với tình hình thực tế. Baseline không có nghĩa là lịch sẽ không thay đổi; nó tạo ra điểm chuẩn để biết thay đổi xảy ra ở đâu và tác động đến mốc nào.

Theo dõi tiến độ không nên chỉ dựa trên tỷ lệ phần trăm hoàn thành do người thực hiện tự ước lượng. Một công việc báo cáo hoàn thành 90% trong nhiều tuần liên tiếp cung cấp rất ít thông tin về thời điểm thực sự kết thúc. Với các nhiệm vụ quan trọng, nên gắn trạng thái với đầu ra hoặc tiêu chí có thể xác nhận.

Các chỉ số kiểm soát có thể bao gồm:

·         Ngày bắt đầu và kết thúc thực tế so với baseline

·         Số ngày chênh lệch tại các mốc chính

·         Thời gian dự trữ còn lại của các công việc gần đường găng

·         Số phụ thuộc chưa được giải quyết

·         Mức sử dụng của các nguồn lực đang tạo nút thắt

·         Tỷ lệ mốc đạt đúng điều kiện chấp nhận

Khi một công việc chậm, tác động cần được truyền qua toàn bộ chuỗi phụ thuộc. Không nên chỉ kéo dài thanh thời gian của công việc đó mà giữ nguyên tất cả các nhiệm vụ phía sau nếu chúng thực tế không thể bắt đầu đúng kế hoạch.

Cũng cần thiết lập ngưỡng quản trị để xác định loại thay đổi nào nhóm dự án có thể tự xử lý và loại nào cần phê duyệt. Một điều chỉnh không ảnh hưởng đường găng có thể chỉ cần cập nhật lịch tác nghiệp, trong khi thay đổi làm dịch chuyển mốc đưa hệ thống vào vận hành thường cần đánh giá lại nguồn lực, phạm vi hoặc phương án triển khai.

Kiểm tra tính khả thi của tiến độ trước khi phê duyệt

Trước khi chốt kế hoạch, cần kiểm tra lịch như một hệ thống liên kết thay vì xem từng dòng công việc riêng lẻ. Một tiến độ có thể hợp lý ở cấp từng nhiệm vụ nhưng vẫn bất khả thi khi tổng hợp các phụ thuộc và giới hạn nguồn lực.

Việc rà soát nên tập trung vào các câu hỏi sau:

·         Mọi công việc bắt buộc đã có đầu ra và người chịu trách nhiệm chưa

·         Các phụ thuộc kỹ thuật và phê duyệt đã được thể hiện chưa

·         Có nguồn lực nào bị xếp chồng trong cùng thời gian không

·         Các công việc trên đường găng có thời lượng dựa trên giả định hợp lý không

·         Mốc kiểm soát có tiêu chí chấp nhận cụ thể không

·         Những phụ thuộc bên ngoài đã có thời gian chờ phù hợp chưa

·         Kế hoạch có chỉ ra cách xử lý khi giả định quan trọng thay đổi không

Một lịch có ngày hoàn thành sớm nhưng dựa trên nguồn lực không tồn tại hoặc các công việc chưa đủ điều kiện bắt đầu không phải là tiến độ tối ưu. Đó chỉ là một lịch chưa phản ánh đầy đủ ràng buộc.

Tiến độ tốt phải tạo ra khả năng kiểm soát: khi một điều kiện thay đổi, nhóm dự án có thể xác định công việc nào bị ảnh hưởng, đường găng có thay đổi hay không, nguồn lực nào cần điều chỉnh và mốc nào phải được dự báo lại.

Tiến độ triển khai công nghệ vì vậy nên được xây dựng từ logic thực hiện thay vì bắt đầu từ ngày đích. Phạm vi cần được phân rã thành công việc có thể kiểm soát; các công việc phải được nối bằng quan hệ phụ thuộc; thời lượng phải phản ánh nguồn lực và điều kiện thực tế; còn các mốc phải có tiêu chí hoàn thành cụ thể.

Sau khi thiết lập baseline, kế hoạch cần tiếp tục được cập nhật theo kết quả thực tế và tác động lan truyền của mỗi thay đổi. Cách tiếp cận này không bảo đảm dự án sẽ không phát sinh chậm trễ, nhưng giúp thời điểm hoàn thành có cơ sở hơn và cho phép người quản lý nhìn thấy sớm nguyên nhân, mức ảnh hưởng cũng như phương án điều chỉnh.