MES LAB · Hệ sinh thái cộng đồng ← Về meslab.org
Học Phát triển sản phẩm — Basics
Basics · bài 14

Giữ cho dự án chạy đúng nhịp

9 phút · 1540 từ · 6/9/2026
Nguồn: chương 14 · Quản lý dự án phát triển sản phẩm — sách Thiết kế & Phát triển Sản phẩm, MES LAB

Phụ đề chữ lớn có sẵn trong video — tắt tiếng vẫn theo dõi được trọn bài.

Cách quản một dự án phát triển sản phẩm: nhìn ra ba kiểu việc, ước lượng công sức, lập tiến trình, dự phòng rủi ro. Vì dự án trễ phần lớn do không ai nắm được các việc đang móc vào nhau thế nào.

Một công ty điện tử dân dụng làm ổ cắm và công tắc thông minh họp giao ban sáng thứ hai. Trưởng nhóm hỏi vòng quanh, ai cũng trả lời đang chạy, tuần này xong. Vậy mà ngày ra mắt đã lùi hai lần. Đến lúc ngồi bóc ra mới thấy: nhóm phần mềm chờ bản mạch chốt, bản mạch chờ vỏ chốt kích thước, vỏ thì đợi bên bán hàng cho ý kiến về màu và nút bấm. Ba nhóm đều bận, đều đúng phần việc của mình, chỉ có điều cả ba đang xếp hàng chờ nhau mà không ai vẽ ra cái hàng đó.

Chúng tôi xin phép giấu tên công ty ấy, như mọi nhân vật trong kênh này. Quản lý dự án phát triển sản phẩm, nói cho mộc, là làm sao để một đống việc rời rạc ăn khớp với nhau và cùng cập đích vào ngày đã hẹn. Nó có hai nửa. Nửa đầu là lập kế hoạch: xác định mục tiêu, cách làm, các đầu việc, nguồn lực, tiền và thời gian. Nửa sau, thường bị xem nhẹ, là điều hành và kiểm soát suốt chặng đường, để thông tin tiến độ luôn đúng và để sửa kế hoạch kịp khi thực tế lệch đi. Khi công ty chạy nhiều dự án cùng lúc, chính cách quản lý mới quyết định được người và tiền chia ra sao cho khỏi giẫm chân nhau.

Chỗ bắt đầu tốt nhất là nhìn cho ra ba kiểu quan hệ giữa các đầu việc. Kiểu thứ nhất là việc nối tiếp: việc sau chỉ bắt đầu được khi việc trước xong hẳn, như xác lập thông số xong mới sàng ý tưởng, chọn xong phương án mới thiết kế mẫu. Loại này dễ theo dõi nhất nhưng hay thành điểm nghẽn, vì cả dây phải đứng chờ một mắt xích. Kiểu thứ hai là việc song song, có thể làm cùng lúc mà không phải chờ nhau: trong lúc bên cơ khí làm mẫu thì bên thử nghiệm đã soạn xong chương trình thử. Kiểu thứ ba khó nhất, tạm gọi là việc sóng đôi, tức hai việc buộc phải chạy cùng nhau và liên tục tác động qua lại. Thiết kế mẫu và thiết kế khuôn là cặp sóng đôi kinh điển, sửa bên này thì bên kia lập tức phải sửa theo.

Từ ba kiểu đó rút ra một nguyên tắc thực dụng: bóc tách công việc sao cho càng nhiều phần chạy song song càng tốt, vì đó là cách rút ngắn dự án mà không phải bắt ai làm thêm giờ. Nhưng song song cũng có giá của nó, vì các việc kết thúc vào những thời điểm khác nhau và người điều phối phải nhìn ra việc nào ngốn thời gian nhất để dồn người vào đó. Còn việc sóng đôi thì phải chấp nhận đây là chỗ nhiều rủi ro nhất, phải theo sát nhất, và tuyệt đối không giao cho hai nhóm ngồi hai nơi không nói chuyện với nhau.

Sau khi hình dung được các mối quan hệ, bước tiếp theo là liệt kê đầu việc. Ở đây có cái bẫy hay gặp: hoặc liệt kê quá thô, mỗi dòng là cả một giai đoạn, hoặc chi li đến mức bản thân danh sách thành một dự án. Kinh nghiệm chung là giữ ở mức vài chục đến vài trăm đầu việc tuỳ quy mô, sao cho với dự án nhỏ mỗi đầu việc cỡ một hai ngày công của một người, dự án lớn hơn thì cỡ một tuần của một nhóm nhỏ.

Có danh sách rồi thì phải ước lượng công sức cho từng việc, thường tính bằng người-ngày hay người-tuần. Chỗ này có một phân biệt nhỏ mà quên là hỏng cả kế hoạch: công sức ước lượng là thời gian làm việc thật, không phải số ngày trôi qua trên tờ lịch. Một việc tốn hai tuần công hoàn toàn có thể kéo dài sáu tuần trên lịch nếu người làm còn ba việc khác. Rất nhiều lời hứa trễ hẹn sinh ra từ chỗ nhầm này.

Khi đã có tổng công sức, có thể ước lượng thô số người tối thiểu bằng cách lấy tổng chia cho quỹ thời gian dự án. Con số đó chỉ là điểm khởi đầu, vì thực tế luôn xen vào: có việc đòi kỹ năng rất chuyên như thiết kế khuôn mà không ai giữ nổi một chuyên gia khuôn ngồi suốt nửa năm cho một dự án; có người quan trọng còn nợ dự án cũ nên chỉ tham gia được nửa thời gian; và khối lượng việc tăng dần cho tới lúc chuẩn bị vào sản xuất rồi mới giảm, nên nhóm cũng phình ra rồi co lại theo. Về cơ cấu, những nhóm chạy nhanh thường giống nhau ở mấy điểm: quân số nhỏ, khoảng mười người trở lại; đủ các chức năng chính là kinh doanh, thiết kế và sản xuất; thành viên gắn với dự án từ đầu tới cuối; và họ nói chuyện trực tiếp với nhau.

Để cả nhóm và cấp trên hiểu giống nhau về dự án, nhiều nơi lập một tài liệu cam kết chung, tiếng Anh gọi là contract book, gom nhiệm vụ dự án, yêu cầu khách hàng, thông số, kế hoạch, nhân sự, kinh phí và rủi ro. Nó bổ sung dần chứ không cần đủ ngay, và giá trị nằm ở chỗ mọi người phải thống nhất vào một bản duy nhất, thay vì mỗi phòng giữ một hiểu biết riêng.

Phần trực quan nhất của kế hoạch là bảng tiến trình, nơi các đầu việc được đặt lên trục thời gian cùng các mốc như kiểm tra thiết kế, có mẫu kỹ thuật, hay có mẫu hoàn thiện đem đi giới thiệu. Công cụ vẽ phổ biến nhất là biểu đồ Gantt: mỗi việc một thanh ngang trải theo tuần. Gantt dễ đọc nhưng không nói rõ các việc phụ thuộc nhau ra sao, nên nhiều nơi dùng thêm biểu đồ mạng kiểu PERT để làm rõ việc nào không được phép trễ. Điều cần nhớ không phải là vẽ đẹp, mà là cả nhóm phải coi bảng tiến trình là bản đáng tin và bám theo.

Đi kèm tiến trình là ngân sách. Với hầu hết dự án phát triển sản phẩm, khoản lớn nhất là tiền cho con người chứ không phải vật tư. Điều đáng nói hơn con số là độ chắc chắn của nó: đầu dự án thì cả thời gian lẫn chi phí đều rất mờ, càng về sau càng rõ dần. Vì thế ngân sách luôn phải có một khoản dự phòng, và người duyệt cần hiểu khoản đó không phải sự thiếu chuyên nghiệp mà là cách thừa nhận thực tế.

Cùng lúc với ngân sách, nhóm nên ngồi liệt kê rủi ro. Có ba loại: loại đã gặp ở dự án trước, loại nghe nói đã xảy ra với sản phẩm tương tự, và loại chưa từng xảy ra nên không ai đoán được. Với hai loại đầu, cách làm rất giản dị: ghi ra từng rủi ro, đánh giá mức nghiêm trọng, viết kèm hành động ứng phó, chẳng hạn chốt hợp đồng khuôn sớm để tránh chậm giao. Với loại thứ ba thì chỉ có thể dự trù một khoản tiền và một khoảng thời gian, cộng thói quen phản ứng nhanh khi sự cố nổ ra.

Muốn dự án chạy nhanh hơn thì có vài việc đáng làm hơn hẳn hò hét tiến độ. Thứ nhất là bắt đầu sớm, bởi tiết kiệm vài tuần ở đoạn đầu cũng quý ngang vài tuần ở đoạn cuối, mà đoạn đầu lại hay bị thả trôi vì chưa ai thấy gấp. Thứ hai là giữ nguyên phạm vi, không đổi tập khách hàng, không thêm tính năng giữa chừng. Tính năng chèn vào lúc dự án đang chạy có nơi gọi vui là tính năng ma, vì chúng phá cả kế hoạch mà người dùng nhiều khi chẳng cần; cách chữa là đặt một mốc đóng băng tính năng, ai muốn thêm thì để dành cho đời sản phẩm sau. Thứ ba là làm cho thông tin chảy thông suốt, bằng bản cập nhật ngắn hằng tuần và bằng trao đổi trực tiếp thay vì thư từ qua lại.

Cuối cùng, dự án nào cũng nên có một buổi ngồi lại sau khi kết thúc. Không phải để truy trách nhiệm, mà để hỏi vài câu thẳng thắn: nhóm có đạt nhiệm vụ đã đặt ra không, mặt nào chạy tốt nhất, mặt nào tệ nhất, cách làm nào đáng giữ, vướng mắc nào lẽ ra đã lường trước được. Ghi lại thành một bản ngắn, dự án sau lôi ra đọc là đỡ kha khá học phí. Đây là thứ rẻ nhất trong toàn bộ chuyện quản lý dự án, và cũng hay bị bỏ qua nhất vì xong việc rồi ai cũng muốn nghỉ.

Vậy nên câu hỏi cuối. Trong dự án đang chạy ở công ty anh chị, đã có ai vẽ ra cái hàng người đang xếp chờ nhau chưa?