Trong môi trường quản lý dự án hiện đại, việc tuân thủ tiến độ là một trong những yếu tố then chốt quyết định sự thành công. Khi đối mặt với áp lực cháy tiến độ “chậm deadline”, các nhà quản lý dự án cần vận dụng những kỹ thuật nén tiến độ một cách hiệu quả. Fast Tracking là một trong những kỹ thuật phổ biến và mạnh mẽ nhất, được áp dụng rộng rãi trong nhiều loại hình dự án.

1. Định nghĩa Fast tracking

Fast Tracking là một kỹ thuật nén tiến độ dự án, trong đó các hoạt động hoặc giai đoạn vốn được hoạch định thực hiện một cách tuần tự sẽ được điều chỉnh để thực hiện song song trong một khoảng thời gian nhất định.

Đọc thêm: https://www.atlassian.com/agile/project-management/fast-tracking

Cơ chế hoạt động của nó là thay đổi mối quan hệ phụ thuộc logic giữa các công việc, điển hình là chuyển đổi từ quan hệ Kết thúc-Bắt đầu (Finish-to-Start) sang quan hệ Bắt đầu-Bắt đầu (Start-to-Start).

2. Các thuộc tính của Fast Tracking

• 2.1. Cách tiếp cận: Phương pháp tiếp cận của Fast Tracking tập trung hoàn toàn vào việc sắp xếp lại trình tự thực hiện công việc. Kỹ thuật này không can thiệp bằng cách bổ sung nguồn lực, mà tối ưu hóa lịch trình dựa trên các nguồn lực hiện có, cho phép các luồng công việc chồng chéo lên nhau.
• 2.2. Tác động về chi phí: Về lý thuyết, Fast Tracking không làm tăng chi phí trực tiếp của dự án, bởi nó không yêu cầu phân bổ thêm ngân sách cho nhân sự hay thiết bị. Tuy nhiên, chi phí gián tiếp có thể phát sinh nếu rủi ro không được quản lý tốt, dẫn đến việc phải làm lại (rework) và tiêu tốn thêm thời gian cũng như tài chính để khắc phục sai sót.
• 2.3. Tác động nguồn lực: Fast Tracking không yêu cầu bổ sung nguồn lực mới, nhưng nó làm tăng đáng kể áp lực quản lý và điều phối đối với các nguồn lực hiện tại. Gánh nặng về giao tiếp, giám sát và phối hợp giữa các đội nhóm làm việc song song sẽ cao hơn nhiều so với làm việc tuần tự, đòi hỏi năng lực cao hơn từ người quản lý dự án và các trưởng nhóm.
• 2.4. Rủi ro về chất lượng: Đây là yếu tố cần được xem xét cẩn trọng nhất. Fast Tracking làm gia tăng rủi ro về mặt kỹ thuật. Việc bắt đầu một hoạt động khi hoạt động phụ thuộc trước đó chưa hoàn thành có thể dẫn đến các vấn đề về tích hợp, sai lệch thiết kế và các lỗi không lường trước. Chất lượng sản phẩm có thể bị ảnh hưởng nếu áp lực tiến độ làm lu mờ các quy trình đảm bảo chất lượng. Do đó, một kế hoạch quản lý rủi ro chặt chẽ là điều kiện tiên quyết.
• 2.5. Khả năng áp dụng: Kỹ thuật này phát huy hiệu quả cao nhất đối với các hoạt động có mối quan hệ phụ thuộc mềm (soft dependencies) – tức là các công việc có thể được phân tách và thực hiện chồng lấn một cách logic. Nó không phù hợp với các hoạt động có mối quan hệ phụ thuộc cứng (hard dependencies), ví dụ như không thể xây dựng mái nhà khi chưa hoàn thành phần móng.

3. Ứng dụng Fast tracking trong dự án Waterfall

Trong mô hình Waterfall, nơi kế hoạch tổng thể và biểu đồ Gantt là kim chỉ nam, Fast Tracking được triển khai như một hành động can thiệp có chủ đích để điều chỉnh tiến độ.

Quy trình này thường là một hành động khắc phục khi dự án đối mặt với nguy cơ chậm trễ so với kế hoạch gốc (baseline).

• Bước 1: Phát hiện sai lệch và phân tích tác động: PM phát hiện một công việc trên đường găng bị chậm trễ, gây ảnh hưởng trực tiếp đến ngày kết thúc dự án.
• Bước 2: Phân tích phụ thuộc và các định cơ hội sử dụng fast tracking: PM rà soát lại các mối quan hệ phụ thuộc để tìm ra các phụ thuộc “mềm” có thể chuyển đổi sang thực hiện song song.
• Bước 3: Xây dựng kế hoạch sử dụng fast tracking: PM xây dựng một kịch bản mới, trong đó các hoạt động được xác định sẽ chồng lấn lên nhau.
• Bước 4: Quản lý các rủi ro: Các rủi ro mới phát sinh phải được nhận diện và đưa vào sổ đăng ký rủi ro (risk register). Kế hoạch truyền thông dự án được tăng cường.

Hãy đọc ví dụ sau để biết áp dụng fast tracking cho dự án waterfall:

Dự án xây dựng tòa nhà 25 tầng bị chậm tiến độ 2 tháng. PM quyết định cho đội xây tường và cơ điện vào làm từ tầng 1 lên ngay khi kết cấu hoàn thành đến tầng 10. Lợi ích là bù lại được thời gian phát triển, nhưng các rủi ro sau đây trở nên vô cùng rõ ràng:

• Rủi ro 1: Hiệu ứng “Domino”
  • Kịch bản: Trong quá trình thi công kết cấu tầng 20, đội kỹ sư phát hiện ra cần phải gia cố một cột chịu lực chạy dọc từ tầng 15 trở xuống để đáp ứng tiêu chuẩn phòng cháy chữa cháy mới cập nhật.
  • Hậu quả trực tiếp: Tại tầng 14, nơi đội cơ điện đã thi công xong toàn bộ đường ống nước và điện âm tường theo thiết kế cũ, giờ đây họ phải nhận lệnh đục phá những bức tường vừa mới xây để dịch chuyển hệ thống đường ống, tránh vị trí cột cần gia cố. Toàn bộ công sức và vật tư điện nước cho phần việc đó của tầng 14 coi như bị hủy bỏ.
  • Tác động: Tiến độ không những không được rút ngắn mà còn bị kéo dài thêm so với dự kiến ban đầu. Chi phí phát sinh cho việc phá dỡ, mua lại vật tư và thi công lại là rất lớn, trực tiếp ảnh hưởng đến lợi nhuận của dự án.

Rủi ro 2: Bỏ qua Điểm kiểm soát (Control Gate) và vi phạm phụ thuộc

• Bối cảnh: Trong bất kỳ dự án xây dựng nào, quy trình thi công tường và hệ thống điện âm tường luôn có một trình tự phụ thuộc cứng và một điểm kiểm soát bắt buộc.
  1. Bước A: Đội điện thi công toàn bộ hệ thống dây điện, ổ cắm, và hộp nối âm tường.
  2. Bước B (Cổng Kiểm soát Quan trọng): Kỹ sư giám sát hoặc thanh tra xây dựng tiến hành nghiệm thu kỹ thuật toàn bộ hệ thống dây điện khi chúng còn đang lộ ra ngoài. Đây là yêu cầu bắt buộc về an toàn, để đảm bảo dây đúng chủng loại, các mối nối chắc chắn và không có nguy cơ chập cháy.
  3. Bước C: Chỉ sau khi việc nghiệm thu ở Bước B được phê duyệt bằng văn bản, đội thạch cao mới được phép thi công, lắp đặt các tấm thạch cao để che kín tường.
• Kịch bản Fast Tracking: Dự án đang chậm tiến độ. Để tiết kiệm một tuần, Giám đốc dự án quyết định cho đội thạch cao vào làm việc sớm. Họ cho rằng hệ thống điện ở các phòng ngủ là “tiêu chuẩn” và chắc chắn sẽ qua nghiệm thu. Vì vậy, họ cho phép đội thạch cao che tường phòng ngủ trong khi đội điện vẫn đang hoàn thiện các khu vực phức tạp hơn như phòng bếp.
• Hậu quả trực tiếp: Khi thanh tra xây dựng đến để thực hiện Bước B, họ vào khu vực phòng ngủ và phát hiện toàn bộ hệ thống dây điện đã bị che lấp hoàn toàn bởi các tấm thạch cao mới tinh. Họ không thể kiểm tra chất lượng mối nối, loại dây sử dụng, hay cách đi dây bên trong.
• Tác động: Ngay lập tức, thanh tra ra văn bản yêu cầu dừng thi công và ra lệnh tháo dỡ toàn bộ phần tường thạch cao đã lắp đặt ở các khu vực đó để lộ ra hệ thống điện cho việc kiểm tra. Yêu cầu này về mặt quy trình và an toàn là không thể thương lượng. Chậm trễ nghiêm trọng: Quyết định Fast Track tưởng chừng tiết kiệm được một tuần giờ đây đã gây ra sự chậm trễ có thể lên tới 2-3 tuần, bao gồm thời gian tháo dỡ, chờ lịch kiểm tra lại, và thời gian thi công lại từ đầu. Chi phí tăng vọt: Chi phí cho các tấm thạch cao bị phá hỏng, chi phí nhân công để tháo dỡ, chi phí dọn dẹp, và chi phí lắp đặt lại toàn bộ. Vi phạm quy trình: Gây ra các vấn đề tiềm ẩn về pháp lý và an toàn, ảnh hưởng đến hồ sơ nghiệm thu của toàn bộ dự án.

Rủi ro trong kịch bản này không phải là “sơ sót” ngẫu nhiên, mà là một sai lầm mang tính hệ thống, gây ra trực tiếp bởi việc bỏ qua một cổng kiểm soát chất lượng và vi phạm một phụ thuộc cứng vì áp lực tiến độ – đây chính là bản chất nguy hiểm nhất của việc áp dụng Fast Tracking một cách sai lầm.

Fast Tracking có phải mâu thuẫn so với các bước phát triển trong dự án Waterfall?

Một trong những câu hỏi sâu sắc nhất về phương pháp luận là: Liệu việc áp dụng Fast Tracking vốn là thực hiện song song có đi ngược lại với tiêu chuẩn cốt lõi của Waterfall là “làm xong bước 1 mới đến bước 2” không? Câu trả lời có thể gây ngạc nhiên: Không, nó không vi phạm.

Cần phân biệt rõ giữa triết lý thiết kế lý tưởng và bộ công cụ quản lý thực tiễn. Triết lý của Waterfall hướng đến một quy trình tuần tự lý tưởng để tối đa hóa sự kiểm soát và giảm thiểu rủi ro. Tuy nhiên, các bộ kiến thức quản lý dự án tiêu chuẩn như PMBOK® của Viện Quản lý dự án (PMI) được xây dựng cho thế giới thực, nơi sự chậm trễ là không thể tránh khỏi. Chính vì vậy, các tiêu chuẩn này cung cấp sẵn các kỹ thuật được công nhận – trong đó có Fast Tracking – như một “quy trình xử lý ngoại lệ” chính thức và có kiểm soát.

Do đó, Fast Tracking không phải là hành động “phá vỡ” quy tắc, mà là việc áp dụng một quy tắc khác trong cùng một bộ tiêu chuẩn để đưa dự án trở lại đúng mục tiêu về thời gian.

Nó tương tự như việc một phi công tuân theo kế hoạch bay đã định (kế hoạch Waterfall), nhưng khi gặp bão (sự cố chậm trễ), họ được phép sử dụng các quy trình khẩn cấp đã được phê duyệt để thay đổi đường bay (áp dụng Fast Tracking) nhằm đảm bảo mục tiêu cuối cùng là hạ cánh an toàn và đúng giờ. Hành động đó không phải là vi phạm luật bay, mà chính là một phần của luật bay.

4. Ứng dụng fast tracking trong Mô hình Agile

Trong mô hình Agile, Fast Tracking không phải là một giải pháp tình thế được áp dụng khi dự án gặp sự cố. Thay vào đó, đây là một nguyên tắc vận hành nền tảng, là một phần không thể tách rời của quy trình làm việc.

Cách làm việc này xuất phát từ chính mục tiêu của Agile: tối đa hóa giá trị trong một khoảng thời gian cố định (Sprint). Để đạt được mục tiêu đó, đội nhóm một cách tự nhiên và chủ động phải thực hiện các công việc song song để loại bỏ thời gian chờ đợi – vốn bị coi là lãng phí.

Để minh họa, hãy xét quy trình phát triển một tính năng trong một Sprint 2 tuần: “Người dùng có thể đăng nhập bằng email”.

• Nếu làm tuần tự:
  1. Ngày 1-3: Lập trình viên Backend làm việc một mình để hoàn thành 100% API đăng nhập. Lập trình viên Frontend và Tester phải ngồi chờ.
  2. Ngày 4-6: Lập trình viên Frontend nhận API và bắt đầu xây dựng giao diện. Lập trình viên Backend và Tester tiếp tục chờ.
  3. Ngày 7-10: Tester nhận sản phẩm hoàn chỉnh và bắt đầu kiểm thử. Cả hai lập trình viên ngồi chờ phản hồi.
  • Kết quả: Quy trình này tạo ra vô số “thời gian chết” (idle time), đi ngược lại triết lý của Agile và có rủi ro rất cao không hoàn thành kịp tính năng trong Sprint.
• Cách làm song song (tư duy Agile mặc định): Một đội Agile hiệu quả sẽ tự nhận thấy quy trình trên là bất hợp lý. Thay vào đó, họ sẽ vận hành theo một quy trình song song mặc định:
  1. Ngày 1 (Làm song song): Cả đội (Backend, Frontend, QA) cùng nhau phân tích và thống nhất về xây dựng và ghép API
  2. Ngày 2-5 (Triển khai song song):
     • Lập trình viên Backend xây dựng API thật.
     • Lập trình viên Frontend, dựa vào xây dựng giao diện với API giả (mock-up).
     • Tester, dựa vào yêu cầu, viết các kịch bản kiểm thử tự động (automation scripts).
  3. Ngày 6 trở đi (Tích hợp và kiểm thử liên tục): Ngay khi các phần đầu tiên của API thật sẵn sàng, việc tích hợp và chạy các kịch bản kiểm thử đã được chuẩn bị trước sẽ diễn ra.

Sự song song này không phải là một “lệnh” can thiệp từ bên ngoài. Đó là cách làm việc tự nhiên và hiệu quả nhất mà đội nhóm tự nhận thấy để có thể hoàn thành mục tiêu trong một khoảng thời gian ngắn.

Do đó, trong Agile, Fast Tracking không phải là một hành động bạn làm, mà là một cách bạn tư duy và vận hành hàng ngày.

5. Các kỹ thuật Fast Tracking nâng cao

Khi các nguyên tắc cơ bản đã được áp dụng, việc tối ưu hóa tốc độ đòi hỏi một cách tiếp cận hệ thống, nâng Fast Tracking từ cấp độ đội nhóm lên cấp độ tổ chức.

• 5.1. Tự động hóa qua Quy trình CI/CD: Tích hợp và triển khai liên tục (CI/CD) tự động hóa và song song hóa chuỗi quy trình build, kiểm thử và triển khai, loại bỏ tối đa thời gian chờ của con người.
  Khi một lập trình viên đẩy code lên, hệ thống CI/CD sẽ tự động và song song thực hiện các công việc: (1) build ứng dụng, (2) chạy hàng trăm bài kiểm thử tự động, và (3) triển khai phiên bản đã qua kiểm thử lên môi trường Staging. Một chuỗi công việc thủ công mất nhiều giờ giờ đây được thực hiện song song chỉ trong vài phút.
• 5.2. Quản lý mức độ phụ thuộc (Cross-team Dependencies): Các đội thống nhất về các giao diện chung (API Contracts) để có thể phát triển độc lập và song song, chỉ tích hợp ở giai đoạn cuối, tránh việc phải chờ đợi lẫn nhau.
  Để phát triển tính năng “Gợi ý sản phẩm”, đội Frontend không cần chờ đội Backend hoàn thành API. Hai bên chỉ cần thống nhất trước về cấu trúc dữ liệu (API Contract). Sau đó, đội Frontend làm việc với một API mock up, trong khi đội Backend xây dựng API thật song song, loại bỏ hoàn toàn thời gian chờ đợi.
• 5.3. Chủ động xây dựng kỹ thuật: Chủ động xây dựng các thành phần hạ tầng, kỹ thuật nền tảng trong các Sprint hiện tại để chuẩn bị cho các tính năng lớn trong tương lai. Điều này đảm bảo khi cần, nền tảng đã sẵn sàng để phát triển tính năng mới ngay lập tức.
  Để chuẩn bị cho tính năng “Thanh toán trả góp” phức tạp trong tương lai, đội phát triển chủ động thêm các “công việc kỹ thuật” vào các Sprint hiện tại. Họ sẽ xây dựng các dịch vụ thanh toán nền tảng song song với việc phát triển các tính năng kinh doanh thông thường, giúp nền tảng sẵn sàng khi cần đến.

6. Các lưu ý khi áp dụng Fast Tracking

Để kỹ thuật Fast Tracking phát huy hiệu quả và không gây ra các hậu quả tiêu cực, việc tuân thủ một số nguyên tắc cốt lõi sau là vô cùng quan trọng:

• Ưu tiên hàng đầu cho giao tiếp: Khi các hoạt động diễn ra song song, nhu cầu giao tiếp và phối hợp tăng lên theo cấp số nhân. Tần suất các cuộc họp điều phối nhanh (quick sync-up, stand-up) cần phải tăng lên. Thông tin phải được luân chuyển một cách liên tục và minh bạch giữa các bên liên quan để tránh hiểu lầm và sai lệch.
• Quản lý rủi ro chủ động: Đừng chỉ chấp nhận rủi ro, hãy quản lý nó. Trước khi quyết định Fast Track, hãy lập một danh sách các rủi ro mới có thể phát sinh (như đã phân tích ở ví dụ Waterfall) và xây dựng kế hoạch ứng phó cho từng rủi ro. Thường xuyên rà soát lại các rủi ro này trong suốt quá trình thực hiện.
• Phân tích các phụ thuộc: Không phải công việc nào cũng có thể Fast Track. Cần phân biệt rõ ràng giữa “phụ thuộc cứng” (bắt buộc về mặt vật lý/logic) và “phụ thuộc mềm” (do quy trình hoặc thói quen). Chỉ nên áp dụng Fast Tracking cho các công việc có phụ thuộc mềm và có thể phân tách một cách logic.
• Yêu cầu sự ổn định về scope: Fast Tracking và việc thay đổi phạm vi liên tục là một sự kết hợp thảm họa. Đối với các hoạt động đang được thực hiện song song, phạm vi công việc cần được “đóng băng” ở mức độ cao nhất có thể để giảm thiểu rủi ro phải làm lại trên diện rộng.
• Duy trì chất lượng: Áp lực thời gian có thể tạo ra cám dỗ về việc bỏ qua hoặc thực hiện sơ sài các bước kiểm thử, code review. Đây là một sai lầm nghiêm trọng. Các cổng kiểm soát chất lượng phải được duy trì nghiêm ngặt. Việc tự động hóa kiểm thử là một yếu tố hỗ trợ đắc lực cho nguyên tắc này.

Kết luận

Fast Tracking là một kỹ thuật nén tiến độ hữu hiệu, có khả năng mang lại lợi ích lớn về mặt thời gian cho dự án. Tuy nhiên, đây không phải là một giải pháp có thể áp dụng tùy tiện. Sự thành công của Fast Tracking phụ thuộc mật thiết vào việc phân tích kỹ lưỡng các mối quan hệ phụ thuộc, đánh giá đúng mức độ rủi ro, và thiết lập một quy trình quản lý, giao tiếp đủ mạnh mẽ để điều phối các hoạt động song song. Dù trong bối cảnh khắc phục sự cố của Waterfall hay là một phần trong triết lý của Agile, việc vận dụng kỹ thuật này đòi hỏi sự cân bằng tinh tế giữa tốc độ và sự cẩn trọng.