Vũ khí thứ tư // 팀
Code chỉ là một nửa. Nửa còn lại là con người.
IT팀의 사람들
Chạm nửa phải màn hình để lật trang ›
Tóm tắt ba chương trước
Chuyện đã đến đâu rồi?
Mới cầm cuốn này lên từ Chương 04? Đâ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ẻ gây ra ký tên lạnh người: "A." — dùng AI để đánh nhanh hơn con người.
● Một người chưa biết gì được kéo vào. Linh — mật danh ZERO, du học sinh Việt tại Hàn — trở thành mảnh ghép cuối của đội, với deadline 72 giờ.
● Ba vũ khí nền tảng đã thành thạo. Chương 01–03: ZERO học HTML dựng khung, CSS khoác áo, JavaScript thổi sự sống. Cô tự tay làm một app biết phản hồi và biết "nhớ".
● Nhưng cô vẫn làm một mình. Và một sản phẩm thật không bao giờ là việc của một người. Đã đến lúc bước vào một đội IT thật — nơi mỗi người đang giấu một điều.
Designer: "Gửi em file Figma, đúng spacing này."
QA: "Nút lỗi trên mobile, fix gấp."
ZERO: "…board là gì? Figma? QA là ai??"
Chương 04 // vũ khí thứ tư
Bạn không đơn độc.
IT팀의 사람들
Ba chương đầu, ZERO chiến đấu một mình trong đêm. Nhưng một sản phẩm thật không phải do một thiên tài làm ra — nó là tác phẩm của cả một đội ngũ, mỗi người một vai trò ăn khớp vào nhau.
Và hôm nay, cô bị ném thẳng vào guồng máy đó: project manager, designer, QA, trưởng nhóm… những vai trò cô chưa từng nghe tên, với một thứ ngôn ngữ riêng.
09:00 sáng · Điện thoại rung liên hồi
09:00 sáng — sáu tin nhắn từ sáu người lạ. ZERO loạn hết cả lên: ai là ai, ai có quyền nhờ mình làm gì?
"Em… em không biết những người này là ai, và ai có quyền yêu cầu em làm gì. Em loạn hết cả lên."
"Bình thường thôi. Một dự án thật không phải làm một mình — nó là cả một đội, mỗi người một vai. Không biết ai là ai, em sẽ lạc lối giữa chiến trường. Để anh vẽ cho em 'bản đồ tác chiến'."
Và lần đầu tiên, ZERO nhận ra: suốt những ngày qua cô tưởng mình chiến đấu một mình với code. Nhưng trong bóng tối, rất nhiều người ở vị trí của riêng họ đang chiến đấu với cùng một kẻ thù.
Vai trò quan trọng nhất ngoài lập trình viên
PM là gì?
Người quản lý dự án. PM không trực tiếp viết code. Việc của họ là làm cho cả dự án "chạy" trơn tru: quyết định làm gì trước, làm gì sau, theo dõi tiến độ, phân chia công việc, và là cầu nối giữa khách hàng và đội kỹ thuật.
PM giống "đạo diễn" của một bộ phim — không đóng vai nào, nhưng quyết định mọi thứ ăn khớp để phim hoàn thành đúng hạn.
PO (Product Owner · 제품 책임자): người quyết định sản phẩm nên có những gì.
Scrum Master (스크럼 마스터): người giúp đội làm việc theo quy trình Scrum trôi chảy, gỡ vướng mắc. Ở công ty nhỏ, một người có thể kiêm nhiều vai.
Các vai trò cốt lõi trong một dự án IT
Ai làm gì trong một đội?
Cột tiếng Hàn là cách gọi thường dùng trong công ty Hàn — học luôn để dùng.
| Vai trò | Tiếng Hàn | Nhiệm vụ |
|---|---|---|
| Frontend Dev | 프론트엔드 개발자 | Giao diện người dùng nhìn thấy (HTML/CSS/JS). Chính là thứ bạn đang học. |
| Backend Dev | 백엔드 개발자 | Máy chủ, cơ sở dữ liệu, logic ẩn phía sau. Bộ não sau màn hình. |
| Full-stack Dev | 풀스택 개발자 | Làm cả front lẫn back. Tiền bối chính là kiểu này. |
| Designer | 디자이너 | Thiết kế cho đẹp (UI) và dễ dùng (UX). |
| PM | 기획자 / PM | Quản lý tiến độ, phạm vi, con người. Cầu nối giữa khách và đội. |
| QA / Tester | QA / 테스터 | Kiểm tra ráo riết xem sản phẩm có hỏng không. Thợ săn bug. |
| DevOps | 데브옵스 | Đưa code lên máy chủ thật và vận hành an toàn. |
| Data Engineer | 데이터 엔지니어 | Thu thập và xử lý dữ liệu khổng lồ. |
| Tech Lead | 테크리드 / 팀리더 | Chịu trách nhiệm các quyết định kỹ thuật của đội. |
Hai từ hay nhầm
UI và UX
| UI · 사용자 인터페이스 | UX · 사용자 경험 |
|---|---|
| Giao diện — "trông thế nào" | Trải nghiệm — "dùng có dễ không" |
| Màu sắc, nút, bố cục | Luồng thao tác, cảm xúc người dùng |
| "Đẹp" | "Dễ dùng" |
Ví dụ: UI là chiếc remote TV đẹp; UX là việc bạn bấm nút có thấy dễ và đúng ý không.
"Nghĩ về một bộ phim đi. Diễn viên (frontend), kịch bản & đạo diễn (backend), tổ mỹ thuật (designer), nhà sản xuất (PM), dựng phim & kiểm duyệt (QA). Thiếu một ai là phim không ra. Bạn là một thành viên của một đội ngũ."
Không phải ngồi gõ code suốt ngày
Một ngày làm việc thật của lập trình viên
| Thời điểm | Hoạt động |
|---|---|
| Sáng | Họp standup ngắn (mỗi người nói 3 điều), kiểm tra tin nhắn, lên kế hoạch ngày |
| Trưa | Code phần được giao, kiểm tra (test), sửa bug |
| Chiều | Review code của đồng nghiệp, họp trao đổi, cập nhật tiến độ lên bảng |
| Cuối ngày | Commit code, ghi chú việc dang dở để mai làm tiếp |
Kỹ năng giao tiếp quan trọng ngang kỹ năng code. Một lập trình viên giỏi không chỉ viết code tốt mà còn biết giải thích ý mình, hỏi đúng câu, và phối hợp với đồng đội. Đừng nghĩ "mình chỉ cần giỏi kỹ thuật là đủ."
Ai làm gì khi có một tính năng mới?
Hành trình của nút "Thích"
Giả sử khách muốn thêm nút "Thích" vào trang. Tính năng này đi qua tay từng vai trò:
| Bước | Ai làm |
|---|---|
| 1. Quyết định cần tính năng này | PM & khách hàng |
| 2. Thiết kế nút trông thế nào | Designer |
| 3. Làm nút hiển thị trên trang | Frontend Dev |
| 4. Lưu lượt thích vào database | Backend Dev |
| 5. Kiểm tra nút chạy đúng không | QA / Tester |
| 6. Đưa lên cho người dùng thật | DevOps |
1. Ai chịu trách nhiệm phần người dùng nhìn thấy?
Frontend Developer — làm giao diện bằng HTML/CSS/JS.
2. PM có viết code không?
Thường là không. PM điều phối: quyết định làm gì trước, theo dõi tiến độ, làm cầu nối với khách.
3. UI và UX khác nhau ra sao?
UI là giao diện "trông thế nào"; UX là trải nghiệm "dùng có dễ và thoải mái không".
Khúc kết chương — danh sách tình nghi
Đêm đó, cả đội họp khẩn. Trên màn hình lớn hiện sơ đồ tổ chức — và một sự thật lạnh người: kẻ cài THE BUG phải là người biết rõ hệ thống từ bên trong. Một người từng thuộc về NOX TECH.
Trưởng nhóm khoanh tay: "Nói cách khác, kẻ phá hoại từng là một trong chúng ta." Ánh mắt mọi người thoáng nghi ngại lẫn nhau. ZERO cảm nhận được bầu không khí đặc quánh sự ngờ vực.
Tiền bối lặng lẽ gõ một cái tên vào ô tìm kiếm hồ sơ nhân sự cũ. Màn hình trả về: "Hồ sơ đã bị xóa." Anh nhíu mày. Ai đó đã xóa dấu vết trước cả họ.
⚿ Không có trên Google · văn hóa công sở Hàn
Ai là ai trong team IT Hàn — và họ thật sự cần gì ở bạn
✕ PM (기획자/PM): không quan tâm code đẹp xấu, chỉ quan tâm "có kịp deadline và đúng yêu cầu không". Hãy báo cáo tiến độ rõ ràng.
✕ Designer (디자이너): rất để ý từng pixel. Khi họ nói "8px", họ thật sự muốn đúng 8px.
✕ QA (테스터): công việc của họ là tìm lỗi của bạn. Đừng tự ái — họ đang bảo vệ sản phẩm.
✕ Senior (시니어): người review code bạn. Hỏi họ sớm còn hơn đoán sai cả ngày.
✕ Báo cáo (보고) sớm và thường xuyên — im lặng tự xử lý bị coi là thiếu trách nhiệm, kể cả khi bạn làm đúng.
✕ Khi gặp khó, nói "저 이거 잘 모르겠어요" (em chưa rõ chỗ này) được đánh giá cao hơn giả vờ hiểu rồi làm sai.
✕ Tôn ti (선후배) quan trọng, nhưng tinh thần "cùng giải quyết vấn đề" còn quan trọng hơn.
💬 "Tôi cần báo cáo với PM rằng tính năng sẽ trễ 1 ngày vì lý do kỹ thuật. Viết giúp một tin nhắn lịch sự, chuyên nghiệp bằng tiếng Hàn công sở."
💬 "Giải thích thuật ngữ code review, pull request, merge cho người mới đi làm ở công ty IT."
▤ Hồ sơ nghề nghiệp · sau khi hiểu đội ngũ
Bạn không chỉ là người code — bạn thành người làm nghề
- ✓Phối hợp đúng cách với PM, Designer, QA
- ✓Báo cáo tiến độ và bất đồng một cách chuyên nghiệp
- ✓Biết khi nào nên tự xử lý, khi nào nên hỏi
- ✓Hòa nhập được vào quy trình của một công ty thật
Đây là kỹ năng mà 90% khóa học code bỏ qua — nhưng nhà tuyển dụng cực kỳ coi trọng.
Một bóng người đi dọc hành lang vắng.
Dừng lại trước phòng máy chủ. Quẹt thẻ.
→ Thẻ ra vào: nhân viên đã NGHỈ VIỆC 3 năm trước.
→ Hệ thống đáng lẽ phải khóa thẻ này.
→ Ai đó đã kích hoạt lại nó từ bên trong.
Kẻ tấn công không đột nhập từ xa. Hắn đã đi bộ vào đây — bằng một tấm thẻ lẽ ra phải chết.
Cô tin họ. Tất cả bọn họ.
Tôi cũng từng như thế.
Rồi một người trong số đó đẩy tôi xuống vực.
— A._
Tin nhắn được gửi từ bên trong mạng nội bộ công ty.
"Biết vai trò rồi. Nhưng từng ấy con người làm sao cùng vận hành như một guồng máy để tạo ra một sản phẩm?"
Tiếp theo — Chương đặc biệt // Vòng đời một dự án.
Chương đặc biệt // cách một sản phẩm ra đời
Vòng đời một dự án thật
프로젝트의 일생
Toàn cảnh vòng đời một dự án phần mềm — đi đúng quy trình, tạo ra giá trị thật. Dưới đây, cả đội sẽ kể phần việc của mình qua từng giai đoạn.
"Hôm nay anh cho em xem thứ quan trọng nhất," tiền bối nói. "Không phải code. Mà là cách một sản phẩm thật sự ra đời — từ lúc còn là ý nghĩ trong đầu ai đó, đến khi hàng nghìn người dùng nó. Code chỉ là một mắt xích. Cả guồng máy mới là điều em cần hiểu."
Anh gọi cả đội lại. Mỗi người kể phần việc của mình trong một dự án giả định: làm một ứng dụng đặt món ăn.
Giai đoạn 1 — Ý tưởng & Lên kế hoạch
"Mọi thứ bắt đầu từ một câu hỏi: 'Người dùng cần gì?' Khách muốn app đặt món. Việc của tôi là biến mong muốn mơ hồ đó thành một kế hoạch rõ ràng: làm cái gì trước, cái gì sau, mất bao lâu, ai làm gì."
Giai đoạn này quyết định 50% thành bại. Một kế hoạch sai dẫn cả đội đi sai. Đó là lý do PM — người tưởng "không viết code" — lại cực kỳ quan trọng.
Giai đoạn 2 — Thiết kế (Design)
"Trước khi ai viết một dòng code, tôi vẽ ra app sẽ trông thế nào, bấm vào đâu thì ra gì. Tôi nghĩ về người dùng: làm sao để bà ngoại 70 tuổi cũng đặt được món chỉ trong 3 lần chạm. Đó là UX — trải nghiệm người dùng."
| UI | UX |
|---|---|
| Giao diện trông thế nào | Trải nghiệm dùng có dễ chịu không |
| Màu sắc, nút, bố cục | Luồng thao tác, cảm xúc người dùng |
| "Đẹp" | "Dễ dùng" |
Một app đẹp mà khó dùng sẽ thất bại. Một app đơn giản mà dễ dùng sẽ thắng. Thiết kế không phải "trang trí" — nó là cách sản phẩm phục vụ con người.
Giai đoạn 3 — Xây dựng (Development)
"Đến lượt em! Em biến bản thiết kế thành giao diện thật mà người dùng chạm vào được — bằng HTML, CSS, JavaScript. Cái nút 'Đặt món' mà bạn bấm? Em làm ra nó."
"Còn anh lo phần ẩn: khi em bấm 'Đặt món', đơn hàng được lưu ở đâu, nhà hàng nhận thông báo thế nào, tiền thanh toán ra sao. Tất cả diễn ra phía sau, người dùng không thấy."
Frontend và Backend như hai mặt của một tờ giấy — phải khớp nhau hoàn hảo. Đây là lúc kỹ năng code thật sự vào cuộc, nhưng luôn trong khuôn khổ kế hoạch và thiết kế đã có.
Giai đoạn 4 — Kiểm thử (Testing)
"Trước khi đến tay người dùng, tôi 'phá' app theo mọi cách: bấm lung tung, nhập sai, mạng yếu… để tìm lỗi. Thà tôi tìm ra bug trước, còn hơn để người dùng gặp."
Giai đoạn 5 — Ra mắt & Vận hành
"Tôi đưa sản phẩm lên 'sân khấu thật' (production), rồi canh giữ nó chạy ổn định 24/7. Có sự cố lúc 3 giờ sáng, chuông báo gọi tôi dậy."
"Và rồi vòng lặp lại bắt đầu: thu thập phản hồi, lên kế hoạch cải tiến, làm phiên bản tiếp theo. Một sản phẩm sống là sản phẩm không ngừng tiến hóa."
Năm giai đoạn trên là mạch chính của chương này — nhưng trong thực tế (xem sơ đồ 8 giai đoạn ở đầu chương đặc biệt), sau khi ra mắt là vận hành, thu phản hồi, rồi cải tiến quay lại từ đầu. Một sản phẩm sống là sản phẩm không ngừng tiến hóa.
1. Giai đoạn nào quyết định nhiều nhất tới thành bại?
Giai đoạn lên kế hoạch — kế hoạch sai khiến cả đội đi sai hướng dù code có giỏi.
2. Vì sao cần QA dù lập trình viên đã code cẩn thận?
Vì người viết code khó tự thấy lỗi của mình; QA "phá" app theo góc nhìn người dùng để tìm bug trước khi ra mắt.
3. Vòng đời dự án kết thúc khi ra mắt?
Không — sau ra mắt là thu phản hồi, cải tiến, làm phiên bản mới. Sản phẩm sống là sản phẩm liên tục tiến hóa.
Hết chương 04 // 14:30 chiều
ZERO nhìn cả đội — mỗi người một vai trò, một mảnh ghép — và lần đầu hiểu sâu sắc: một sản phẩm không phải do một thiên tài làm ra, mà do một đội ngũ phối hợp. Cô không cần giỏi tất cả. Cô chỉ cần làm tốt phần của mình, và hiểu cách nó khớp với người khác.
Tiền bối mỉm cười: "Đó là lúc em thành người làm nghề thật sự."
Giờ ZERO đã hiểu cả guồng máy. Nhưng hiểu từng vai trò là một chuyện — khiến cả đội không lạc nhịp, không trễ hạn, không giẫm chân nhau lại là chuyện khác.
58:30:00 ▸ 54:00:00
Còn 54 giờ. Một đội giỏi vẫn có thể thất bại nếu thiếu người cầm nhịp.
Chỉ huy tác chiến
Quản lý dự án: nơi một câu "đơn giản thôi mà" có thể thổi bay cả tuần làm việc. 다섯 번째 무기 — 관리
Còn 54 giờ. ZERO đã đi được 4/7 chặng — đã đi được hơn nửa đường.
Còn 54 giờ.
Kẻ nội gián đang ở trong đội.
Bạn vừa đọc xong Chương 04. Cách cả guồng máy vận hành ăn khớp đang chờ ở Chương 05.
🤍 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)
