Vũ khí thứ năm // 관리
Bốn chữ "đơn giản thôi mà" — thổi bay cả tuần làm việc.
프로젝트 관리
Chạm nửa phải màn hình để lật trang ›
Tóm tắt bốn chương trước
Chuyện đã đến đâu rồi?
Mới cầm cuốn này lên từ Chương 05? Đây là tất cả những gì bạn cần biết:
● Một hệ thống bị tấn công. Website NOX TECH biến mất lúc 02:44 sáng. Kẻ ký tên "A." dùng AI để đánh nhanh hơn con người. Deadline: 72 giờ.
● ZERO — người chưa biết gì. Linh, du học sinh Việt tại Hàn, chưa từng viết một dòng code, trở thành mảnh ghép cuối của đội cứu hệ thống.
● Ba vũ khí nền tảng. Chương 01–03: cô học HTML, CSS, JavaScript — tự tay làm một app biết phản hồi và biết nhớ.
● Chương 04 — Bước vào đội ngũ. ZERO gặp PM, designer, QA, trưởng nhóm. Cô hiểu ra: mình không cần giỏi tất cả — chỉ cần khớp với người khác. Nhưng một trong số họ có thể chính là "A."
Một việc quan trọng khác thì chẳng ai làm — ai cũng tưởng người kia lo.
// còn chưa tới nửa đường, mà đội đã bắt đầu lạc nhịp.
Chương 05 // vũ khí thứ năm
Giỏi thôi
là chưa đủ.
프로젝트 관리
Cả đội đều giỏi. Nhưng giỏi mà không có người cầm nhịp thì vẫn giẫm chân nhau, vẫn trễ hạn, vẫn để lọt việc. Và trong một cuộc đua 72 giờ, mỗi giờ trôi phí là một giờ "A." tiến thêm.
Đến lúc ZERO chạm tới thứ vũ khí ít ai ngờ tới — không phải một dòng code, mà là cách giữ cho cả con tàu đi đúng hướng: quản lý dự án.
11:00 sáng · Trưởng nhóm đập tay xuống bàn
Sự hỗn loạn biến thành những tấm thẻ ngăn nắp. Deadline không phải kẻ thù — sự hỗn loạn mới là.
Giữa lúc nước sôi lửa bỏng, một sự cố ngớ ngẩn xảy ra: hai lập trình viên vừa sửa cùng một lỗi — phí mất hai giờ. Trong khi đó, một việc quan trọng khác lại chẳng ai nhận, vì ai cũng tưởng người khác lo.
"Không thể tiếp tục thế này! Chúng ta đang giẫm chân nhau và bỏ sót việc. Với deadline thế này, một giờ lãng phí là một giờ tiến gần tới thất bại. Phải có cách quản lý cho rõ ràng — NGAY."
Anh kéo ra một tấm bảng khổng lồ, dán đầy thẻ giấy nhiều màu: Việc cần làm · Đang làm · Đã xong. ZERO lần đầu hiểu vì sao những đội giỏi vẫn bình tĩnh giữa khủng hoảng: sự hỗn loạn được biến thành những tấm thẻ ngăn nắp — mỗi tấm là một việc nhỏ, có người chịu trách nhiệm, có trạng thái rõ ràng.
Trước tấm bảng Kanban · trưởng nhóm thử lính mới
ZERO, cái thẻ "sửa trang đăng nhập" này — cậu nghĩ làm xong trong bao lâu?
(tự tin) Dạ… chắc nửa ngày ạ?
Cậu đã tính lúc nó hỏng và phải làm lại chưa? Lúc phải hỏi anh thiết kế? Lúc máy chủ test bị lỗi?
(im lặng) …Em chỉ tính phần code chạy ngon thôi.
(xen vào) Ai mới vào nghề cũng vậy. Người ta ước lượng "lúc mọi thứ suôn sẻ" — nhưng phần mềm hiếm khi suôn sẻ. Cứ lấy con số em nghĩ rồi nhân đôi, thường lại gần sự thật hơn.
Trễ deadline phần lớn không phải vì code chậm, mà vì ước lượng thiếu phần rủi ro. Chia nhỏ việc, ước lượng từng mảnh, và luôn chừa chỗ cho điều bất ngờ — đó là nghề, không phải phép màu.
"Quản lý dự án" thực ra là làm gì?
Là một công việc lớn có mục tiêu rõ ràng và thời hạn cụ thể (ví dụ "xây xong website bán hàng trong 2 tháng"). Quản lý dự án nghĩa là sắp xếp con người, công việc và thời gian sao cho đạt mục tiêu đúng hạn mà không vỡ trận.
Hai cách làm việc
Agile và Waterfall
| Cách làm | Mô tả | Ví von |
|---|---|---|
| Waterfall 워터폴 | Kế hoạch → thiết kế → phát triển → kiểm thử → ra mắt. Đi tuần tự một mạch. Mạnh khi kế hoạch đã rõ. | Thác nước chảy một chiều từ trên xuống |
| Agile 애자일 | Chia nhỏ, lặp lại theo chu kỳ ngắn: làm – kiểm tra – sửa. Linh hoạt với thay đổi. | Xếp Lego, lắp dần từng chút |
Scrum — chiến thuật Agile phổ biến nhất
Cách làm Agile phổ biến nhất: đội chia công việc thành các chu kỳ ngắn, mỗi chu kỳ giao một phần sản phẩm chạy được, rồi lặp lại. Dưới đây là các thuật ngữ Scrum bạn sẽ nghe mỗi ngày.
Từ vựng nghe mỗi ngày
Thuật ngữ Scrum
| Thuật ngữ | Ý nghĩa |
|---|---|
| Sprint 스프린트 | Một chu kỳ làm việc ngắn 1–2 tuần. Phải hoàn thành mục tiêu đã chọn trong đó. |
| Backlog 백로그 | Danh sách toàn bộ việc cần làm, xếp theo độ ưu tiên. |
| Daily Standup 데일리 스탠드업 | Họp ngắn (đứng) mỗi ngày. Chỉ nói 3 điều: hôm qua làm gì / hôm nay làm gì / đang vướng gì. |
| Sprint Review 스프린트 리뷰 | Cùng kiểm điểm thành quả khi sprint kết thúc. |
| Retrospective 회고 | Nhìn lại "điều gì tốt, điều gì cần cải thiện" để lần sau làm tốt hơn. |
Một tấm bảng chia thành các cột theo trạng thái. Mỗi việc là một tấm thẻ, được kéo từ cột này sang cột kia khi tiến triển. Nhìn vào bảng là biết ngay ai đang làm gì, việc nào còn kẹt.
Nhìn thấy dòng chảy công việc
Bảng Kanban trông thế nào?
Ngôn ngữ của tiến độ & deadline
| Thuật ngữ | Ý nghĩa |
|---|---|
| Deadline · 데드라인/마감 | Hạn chót bắt buộc phải hoàn thành. |
| Milestone · 마일스톤 | Mốc mục tiêu quan trọng giữa chặng đường dự án. |
| Scope · 범위 | Phạm vi công việc mà dự án bao gồm. |
| Scope Creep · 스코프 크리프 | Việc cứ lén tăng dần ngoài kế hoạch. Kẻ thù lớn nhất của PM. |
| MVP | Minimum Viable Product — bản tối thiểu chỉ có chức năng cốt lõi. Ra mắt trước rồi cải tiến sau. |
| Estimation · 추정 | Dự đoán việc này mất bao nhiêu thời gian/công sức. |
Chu kỳ làm việc cốt lõi của Scrum
Một Sprint diễn ra thế nào? (ví dụ 2 tuần)
| Thời điểm | Việc diễn ra |
|---|---|
| Ngày 1 (Sprint Planning) | Cả đội chọn từ backlog ra những việc sẽ làm trong 2 tuần này. |
| Mỗi sáng (Standup) | Họp ngắn 15 phút: hôm qua làm gì, hôm nay làm gì, vướng gì. |
| Suốt sprint | Code, test, kéo thẻ Kanban từ "đang làm" sang "đã xong". |
| Ngày cuối (Review) | Trình bày thành quả cho mọi người & khách. |
| Sau Review (Retro) | Nhìn lại: điều gì tốt, điều gì cần cải thiện cho sprint sau. |
Vì làm một dự án khổng lồ trong một lần dễ sai và dễ nản. Chia thành các chặng ngắn 2 tuần, mỗi chặng có thành quả thấy được, giúp đội luôn biết mình đang ở đâu và điều chỉnh kịp thời. Đây là tinh thần "ăn voi từng miếng một".
Kẻ thù thầm lặng của mọi dự án
Scope Creep
Là khi phạm vi công việc cứ phình to dần ngoài kế hoạch ban đầu — mỗi lần "tiện thể thêm cái này", "chỉnh chút kia". Từng yêu cầu nhỏ tưởng vô hại, nhưng cộng lại khiến dự án trễ hạn và kiệt sức.
Mọi thay đổi đều phải được ghi lại và đánh giá — "việc này thêm bao nhiêu thời gian?". Không phải để từ chối khách, mà để mọi người cùng hiểu cái giá thật của mỗi yêu cầu. Nói "có, nhưng sẽ cần thêm X ngày" tốt hơn nói "có" rồi vỡ kế hoạch.
1. Sprint là gì?
Một chu kỳ làm việc ngắn (1–2 tuần) với mục tiêu cụ thể phải hoàn thành.
2. Agile và Waterfall khác nhau cơ bản ở đâu?
Waterfall đi tuần tự một mạch; Agile chia nhỏ, lặp lại theo chu kỳ ngắn, linh hoạt với thay đổi.
3. MVP nghĩa là gì?
Minimum Viable Product — bản tối thiểu chỉ có chức năng cốt lõi, ra mắt trước rồi cải tiến sau.
Kỹ năng khó mà quan trọng
Ước lượng thời gian
"Việc này mất bao lâu?" là câu hỏi người mới sợ nhất. Ước lượng sai khiến cả dự án trễ. Vài nguyên tắc giúp bạn ước lượng tốt hơn:
| Nguyên tắc | Ý nghĩa |
|---|---|
| Chia nhỏ rồi cộng | Ước lượng từng việc con nhỏ rồi cộng lại, chính xác hơn đoán cả khối. |
| Nhân đôi linh cảm đầu | Người mới hay lạc quan; con số đầu tiên thường cần nhân 1.5–2 lần. |
| Tính cả việc "ẩn" | Test, sửa bug, họp, review… đều ăn thời gian. |
| Báo sớm khi trễ | Trễ là chuyện thường; báo sớm để cả đội điều chỉnh, đừng giấu. |
Ngay cả lập trình viên 10 năm kinh nghiệm cũng thường ước lượng sai. Đây là một trong những việc khó nhất của nghề. Đừng tự trách khi ước sai — chỉ cần học để lần sau ước tốt hơn, và luôn báo sớm khi thấy sắp trễ.
Ưu tiên việc: ma trận quan trọng – khẩn cấp
| Loại việc | Cách xử lý |
|---|---|
| Quan trọng + Khẩn cấp | Làm ngay (vd: lỗi nghiêm trọng trên Production) |
| Quan trọng + Không khẩn | Lên lịch làm (vd: cải thiện cấu trúc code) |
| Không quan trọng + Khẩn | Giao bớt nếu được (vd: việc nhỏ ai cũng làm được) |
| Không quan trọng + Không khẩn | Để sau hoặc bỏ (vd: tính năng "có thì hay") |
Người mới hay sa vào việc "khẩn nhưng không quan trọng" vì chúng tạo cảm giác bận rộn. Hãy luôn tự hỏi: "việc này có thật sự quan trọng không, hay chỉ đang ồn ào đòi sự chú ý?"
⚿ Cực kỳ quan trọng với người làm cầu nối, phiên dịch, sales IT
Tiền ở đâu? Man-month & báo giá
Khi khách hàng Hàn hỏi "Cái này làm mất bao nhiêu tiền? Bao lâu xong?", bạn cần hiểu câu trả lời đến từ đâu — kể cả khi không phải người trực tiếp code.
"Em không hiểu — sao một tính năng nghe đơn giản mà báo giá lại cao thế ạ? Chỉ là thêm một cái nút thôi mà?"
"Vì cái 'nút' đó không chỉ là cái nút. Nó cần thiết kế, code, kết nối database, kiểm thử, sửa bug, rồi review. Trong phần mềm, thứ đắt nhất không phải máy móc — mà là thời gian của con người. Và thời gian con người được đo bằng một đơn vị: man-month."
Đơn vị đo công sức: một người làm trong một tháng = 1 man-month. Nếu một tính năng cần "3 man-month", nghĩa là một người làm 3 tháng, hoặc ba người làm một tháng. Ở Hàn, từ 공수 (gong-su) được dùng rất nhiều trong họp.
Chi phí ≈ (số man-month cần thiết) × (đơn giá một man-month). Vì vậy khi nghe "dự án này 50 man-month", bạn hiểu ngay: đây là dự án lớn, tốn nhiều người-tháng, và giá sẽ cao tương ứng.
Vì sao "thêm một tính năng nhỏ" lại tốn tiền?
Việc ẩn sau "gửi email nhắc việc"
Khách nói: "Thêm cho tôi tính năng nhắc việc qua email thôi mà, đơn giản đúng không?" Thực ra một yêu cầu "nhỏ" ẩn chứa nhiều công sức:
| Việc ẩn phía sau | Công sức |
|---|---|
| Thiết kế: khi nào gửi, gửi mấy lần, nội dung gì | ~0.5 ngày |
| Code: kết nối dịch vụ email, viết logic hẹn giờ | ~2 ngày |
| Lưu cài đặt của từng người vào database | ~1 ngày |
| Kiểm thử: gửi đúng giờ chưa, có spam không, lỗi thì sao | ~1 ngày |
| Sửa bug phát sinh + review code | ~1 ngày |
Cộng lại: một tính năng "đơn giản" hóa ra tốn khoảng 5–6 ngày công — gần một phần tư man-month. Nhân với đơn giá, con số không hề nhỏ.
"Vâng để em hỏi bên kỹ thuật ạ." → thụ động, mất uy tín, khách thấy bạn không nắm việc.
"Tính năng này nhìn đơn giản nhưng cần khoảng X ngày công vì phải làm A, B, C. Em sẽ gửi anh bảng ước lượng chi tiết." → chủ động, hiểu việc, đáng tin.
⚠ Người đi trước cảnh báo · ngân sách
3 điều về budget mà sách giáo khoa không nói
✕ "Báo giá thấp để được nhận việc" là cái bẫy. Nhận giá thấp rồi vỡ kế hoạch còn tệ hơn mất hợp đồng. Ước lượng thật thà bảo vệ cả bạn lẫn khách.
✕ Luôn cộng thêm "đệm" cho rủi ro. Dự án thực tế hầu như luôn phát sinh. Người có kinh nghiệm cộng thêm 20–30% vào ước lượng gốc để dự phòng.
✕ Thay đổi giữa chừng = phải báo lại giá. Đây chính là Scope Creep. Mỗi yêu cầu mới đều có cái giá của nó — ghi lại và báo rõ, đừng "làm cho xong".
1. Man-month là gì?
Đơn vị đo công sức: một người làm việc trong một tháng. Dùng để tính chi phí và báo giá dự án.
2. Vì sao một tính năng "nhỏ" vẫn có thể tốn nhiều tiền?
Vì phía sau nó là cả chuỗi việc ẩn: thiết kế, code, kết nối database, kiểm thử, sửa bug, review — tất cả đều ăn thời gian con người.
3. Khi khách yêu cầu thêm tính năng giữa chừng, nên làm gì?
Ghi lại yêu cầu, ước lượng công sức thêm, và báo lại giá/thời gian — thay vì âm thầm "làm cho xong" rồi vỡ kế hoạch.
Hết chương 05 // 15:40 chiều
Tấm bảng Kanban đầy ắp thẻ — mỗi thẻ là một mảnh của cuộc đua. Lần đầu tiên, ZERO hiểu vì sao người ta cần quy trình. Không phải để hành hạ nhau. Mà để không ai gục ngã một mình.
Một email vừa tới từ khách hàng quan trọng nhất. Trưởng nhóm đọc xong, mặt tái đi.
"Khách hàng K muốn dời lịch ra mắt… SỚM HƠN. Còn 40 giờ."
Cả phòng lặng đi. Rồi cánh cửa kính bật mở.
54:00:00 ▸ 40:00:00
Mất trắng 14 giờ chỉ trong một câu nói. Đội ngũ giỏi, quy trình chặt — vẫn có thể vỡ trận vì một biến số không kiểm soát được. Biến số nguy hiểm nhất không nằm trong code. Nó ngồi phía bên kia bàn.
Biến số nguy hiểm nhất
Khách hàng: nơi kỹ thuật gặp con người, kỳ vọng gặp thực tế — và mọi thứ có thể đổi trong một cuộc gọi. 여섯 번째 무기 — 고객
Còn 40 giờ. ZERO đã đi được 5/7 chặng — chặng khó nhất vẫn còn ở phía trước.
Còn 40 giờ.
Biến số nguy hiểm nhất vừa bước vào.
Bạn vừa đọc xong Chương 05. Khách hàng — nơi mọi kế hoạch có thể đổ trong một cuộc gọi — đang chờ ở Chương 06.
🤍 Cùng xuất bản ZERO — đặt trước giá sáng lập
Đọc online MIỄN PHÍ tất cả các chương (bản giản lược). Bản online FULL — đủ mọi chương & mọi phần chuyên sâu, không lược — chỉ 89k. Khi đủ 500 đơn, sách được in màu & xuất bản; chưa đủ → hoàn 100%.
89k / 229k · bản online FULL / bản in (giá sáng lập)
