Hầu hết developer mới vào doanh nghiệp đều bị choáng — không phải vì code khó, mà vì không ai dạy bạn quy trình. Bạn biết viết code, nhưng không biết khi nào cần viết, viết cho ai, và ai sẽ review. Sau 5 năm làm ở hai công ty product và một số dự án freelance, đây là những gì mình đúc rút về SDLC mà mình ước ai đó nói cho mình sớm hơn.

SDLC — Không phải lý thuyết, mà là cách team bạn vận hành#

SDLC (Software Development Life Cycle) nghe hàn lâm, nhưng mọi công ty phần mềm đều đang chạy một phiên bản nào đó của nó — dù có gọi tên hay không. Product hay outsourcing, startup hay enterprise, đều xoay quanh 6 giai đoạn cốt lõi dưới đây. Mỗi công ty sẽ customize cho phù hợp, nhưng bản chất không đổi.

1. Analysis & Planning — Hiểu bài toán trước khi chạm code#

Takeaway: Developer giỏi không phải người code nhanh, mà là người hỏi đúng câu hỏi.

Giai đoạn này quyết định 80% thành bại của dự án. Bạn cần hiểu rõ yêu cầu khách hàng, xác định scope, và đánh giá tính khả thi.

Thực tế đau thương:

• Khách hàng thường không biết chính xác họ muốn gì. Bạn phải đào sâu bằng câu hỏi “tại sao” liên tục.
• Scope thay đổi liên tục — đặc biệt dự án lớn. Không plan cho thay đổi = tự tạo rủi ro.
• Ngân sách, nhân lực, deadline luôn ít hơn bạn nghĩ.

Việc cần làm:

• Tổ chức meeting với stakeholder. Đừng chỉ ghi nhận yêu cầu — hãy challenge nó.
• Vẽ flow diagram để phát hiện bottleneck sớm.
• Chia nhỏ dự án thành milestone rõ ràng.

Công cụ: Jira/Trello (backlog), Lucidchart/Miro (flow), Confluence (docs).

2. Design & Prototyping — Blueprint trước khi xây#

Takeaway: Sai kiến trúc ở giai đoạn này = trả nợ kỹ thuật suốt vòng đời dự án.

Đây là lúc chuyển business requirements thành kiến trúc hệ thống. Chọn monolithic hay microservices, thiết kế database schema, prototype UI — tất cả phải rõ ràng trước khi viết dòng code đầu tiên.

Thực tế đau thương:

• Chọn sai tech stack hoặc kiến trúc sẽ khiến hệ thống khó scale và maintain.
• Business và IT thường không đồng thuận về thiết kế. Cần prototype sớm để align.

Việc cần làm:

• Thiết kế system architecture phù hợp với quy mô dự án.
• Tạo prototype cho phần UI/UX để lấy feedback sớm.
• Thiết kế database: bảng, quan hệ, index tối ưu.

Công cụ: Figma (UI/UX), Draw.io/Lucidchart (architecture), ER/Studio (database).

3. Software Development — Viết code có kỷ luật#

Takeaway: Code chạy được thì ai cũng viết được. Code mà người khác maintain được mới là chuyên nghiệp.

Giai đoạn này không chỉ là code feature. Bạn phải đảm bảo code có cấu trúc rõ ràng, dễ đọc, dễ test, và tích hợp được với module của người khác.

Thực tế đau thương:

• Module của bạn chạy ngon, nhưng ghép với module khác thì lỗi tùm lum — vì thiếu contract rõ ràng.
• Code “chạy được” nhưng 3 tháng sau không ai hiểu — kể cả bạn.

Việc cần làm:

• Tuân thủ coding standards của team. Không phải style cá nhân, mà là convention chung.
• Viết unit test cho logic quan trọng. Không cần 100% coverage, nhưng cần cover happy path và edge case.
• Tích hợp sớm, tích hợp thường xuyên. Đừng để code chờ merge hàng tuần.

Công cụ: VS Code/Visual Studio (IDE), Git + GitHub/GitLab (version control), SonarQube (code quality).

4. Testing — Không phải việc riêng của QA#

Takeaway: Bug tìm thấy ở production đắt gấp 10 lần bug tìm thấy lúc dev.

Testing là trách nhiệm của cả team, không chỉ QA. Developer cần viết test, review test case, và hiểu rõ các loại testing để biết mình đang thiếu gì.

Thực tế đau thương:

• Test coverage thấp → bug lọt production → mất uy tín với khách.
• “Works on my machine” — môi trường dev khác production là nguồn gốc của vô số incident.
• Automation test tốn effort ban đầu, nhưng tiết kiệm gấp nhiều lần về sau.

Việc cần làm:

• Viết test case: functional, non-functional, và đặc biệt là edge case.
• Unit test cho từng function/module.
• Integration test cho luồng dữ liệu giữa các service.
• Load test trước khi go-live để biết hệ thống chịu được bao nhiêu.

Công cụ: Postman/Swagger (API), Selenium/Puppeteer (UI automation), xUnit/NUnit (.NET test), JMeter (load test).

5. Deployment — Đưa lên production mà không đổ mồ hôi#

Takeaway: Deploy tay = deploy sai. Tự động hóa CI/CD là điều kiện cần, không phải nice-to-have.

Mục tiêu: đưa phần mềm lên production nhanh, an toàn, và rollback được ngay nếu có sự cố.

Thực tế đau thương:

• Downtime khi deploy ảnh hưởng trực tiếp đến doanh thu và uy tín.
• Không có rollback plan = canh bạc mỗi lần release.
• Staging khác production = tự lừa mình.

Việc cần làm:

• Setup staging giống production nhất có thể.
• Tự động hóa deploy qua CI/CD pipeline.
• Monitor ngay sau deploy — đừng đợi user report bug.
• Luôn có rollback plan rõ ràng.

Công cụ: Azure DevOps/GitHub Actions (CI/CD), Docker/Kubernetes (container), Terraform (IaC), Datadog/ELK (monitoring).

6. Operations & Maintenance — Phần mềm sống là phần mềm được chăm#

Takeaway: Deploy xong không phải là xong. 70% effort của một sản phẩm nằm ở maintenance.

Vận hành và bảo trì bao gồm: monitor hệ thống, fix bug production, vá lỗ hổng bảo mật, và liên tục cải thiện dựa trên feedback thực tế.

Thực tế đau thương:

• Bug chỉ xuất hiện ở production với data thật và traffic thật.
• Khách hàng luôn muốn thêm feature — scope không bao giờ “đóng băng” thật sự.
• Bảo mật là cuộc chơi liên tục, không phải checklist một lần.

Việc cần làm:

• Monitor performance, log, và error liên tục.
• Patch bảo mật kịp thời. Dùng Dependabot để track dependency.
• Tối ưu hóa dựa trên data thực tế, không phải phỏng đoán.

Công cụ: Grafana/Kibana (monitoring), Azure Monitor/New Relic (APM), Jira Service Desk (support), Dependabot (dependency update).

Kết#

SDLC không phải lý thuyết trên sách — nó là cách team bạn phối hợp mỗi ngày. Dù bạn là developer, QA, hay architect, hiểu rõ từng giai đoạn sẽ giúp bạn đóng góp đúng chỗ, đúng lúc, thay vì chỉ ngồi code rồi throw code qua tường cho người khác xử lý.