Đội ngũ phát triển phần mềm (DEV) của Ecomobi đang đóng vai trò then chốt trong việc hiện thực hóa sản phẩm và duy trì chất lượng hệ thống. Để đáp ứng tốt hơn với nhu cầu ngày càng cao về tốc độ và hiệu quả, quy trình làm việc của team DEV cần được nhìn lại và cải tiến. Team “No Name” thông qua bài viết này trình bày vai trò của DEV, sơ đồ quy trình hiện tại, phân tích điểm mạnh – điểm yếu, các thách thức đang gặp phải, và đề xuất giải pháp cụ thể nhằm tối ưu hiệu suất làm việc.
1. Chức năng / Vai trò
Trong Tech & Product của Ecomobi, DEV Team giữ vai trò trung tâm và là lực lượng nòng cốt đảm bảo hệ thống luôn vận hành hiệu quả, ổn định và không ngừng đổi mới. Họ không chỉ là những người trực tiếp viết mã, mà còn là kiến trúc sư công nghệ góp phần định hình và nâng tầm toàn bộ hệ thống. Vai trò của DEV Team bao gồm:
- Phát triển hệ thống: Thiết kế, lập trình và triển khai các tính năng mới theo yêu cầu từ bộ phận hoặc ban lãnh đạo.
- Bảo trì và cải tiến: Liên tục sửa lỗi, tối ưu hiệu năng và cải thiện trải nghiệm người dùng dựa trên phản hồi thực tế.
- Tích hợp và kết nối: Đảm bảo hệ thống có thể giao tiếp linh hoạt với các nền tảng nội bộ hoặc bên thứ ba.
- Đảm bảo an toàn dữ liệu: Triển khai các biện pháp bảo mật, kiểm soát phân quyền và bảo vệ thông tin người dùng.
- Tư vấn kỹ thuật: Hỗ trợ các bộ phận khác trong việc hiểu rõ khả năng kỹ thuật, từ đó đề xuất các giải pháp công nghệ phù hợp với nhu cầu.
Nhờ vào sự kết hợp giữa chuyên môn kỹ thuật và tinh thần đồng hành cùng tổ chức, DEV Team đóng vai trò không thể thay thế trong hành trình phát triển toàn diện của Ecomobi.
2. Quy trình làm việc hiện tại
Sơ đồ quy trình làm việc được tham khảo và vẽ lại dựa trên file “Quy trình làm việc” của Dev Team. Chi tiết file xem tại đây.
3. Điểm mạnh – Điểm yếu – Thách thức của quy trình.
3.1 Điểm mạnh
| Điểm mạnh | Mô tả |
| Tuân thủ đúng mô hình Scrum | Có đầy đủ các bước từ Refinement → Sprint Planning → Daily → Retro. |
| Rõ ràng vai trò và luồng xử lý task | – Phân tách bước chuẩn bị task (so sánh doc/design). – Có self test, log work, báo cáo kết quả. – Luồng commit – review – merge – test mạch lạc. – Có chuẩn hóa về git, định dạng code và cập nhật tiến độ. |
| Daily rõ ràng và chi tiết | – Task nào chưa làm, lý do. – Task nào làm hôm nay. – Theo dõi trạng thái task các thành viên. |
| Self Test & Review | – Có bước kiểm tra code, giúp giảm lỗi trước khi đến tay tester. – Giảm lỗi trước khi release. |
3.2 Điểm yếu- Thách thức
| Điểm yếu | Hệ quả | Thách thức |
| Dev phải thực hiện quá nhiều thao tác thủ công (log work, review, báo cáo, test…). | Giảm thời gian dành cho việc coding thực sự, kéo dài thời gian hoàn thành sprint | Tốn thời gian, hiệu suất thấp |
| Quy trình phụ thuộc nhiều vào người, thiếu hệ thống hóa | Khó onboarding người mới, khó scale team hoặc dự án lớn. | Giảm khả năng mở rộng team |
| Không có bằng chứng test, khó review/debug khi có bug. | Tăng chi phí xử lý lỗi, stress cho Dev và Tester, ảnh hưởng đến chất lượng release. | Vòng lặp bug fix kéo dài, dễ trôi task. |
| Không tracking các action items sau buổi retro. | Các vấn đề lặp lại, không cải thiện chất lượng, retro trở nên hình thức. | Dù đã biết vấn đề nhưng vẫn không khắc phục được -> Tốn thời gian, hiệu suất thấp |
| Dev không chủ động kiểm tra nguyên nhân issue do giới hạn quyền DB production. | Dev mất thời gian chờ đợi từ các bên khác (Ops, DBA), dẫn đến chậm xác định nguyên nhân issue, giảm tính chủ động. | Có thể bỏ qua thời điểm vàng để tái hiện cũng như xử lý issues. |
| Dev chỉ biết task mình, không biết task của người khác. | Team thiếu tính liên kết, khó hỗ trợ lẫn nhau, tăng rủi ro bottleneck nếu 1 người nghỉ. | – Thiếu tính phối hợp. – Gây chậm tiến độ khi phát sinh lỗi hoặc phụ thuộc giữa các task. – Khó khăn trong việc chia sẻ kiến thức. |
| Comment code không đầy đủ, khó maintain. | Khó onboarding người mới, khó cho các team liên quan đọc hiểu code. | – Khó khăn trong việc đọc hiểu code. – Tăng rủi ro khi sửa lỗi hoặc maintain. – Gây phụ thuộc vào người viết code. |
4. Giải pháp/cải tiến & lợi ích sau khi cải tiến.
| Mục tiêu | Giải pháp | Mô tả | Lợi ích |
| Review code | Ứng dụng CI/CD với các công cụ như GitHub Actions, GitLab CI, Jenkins để kiểm tra build tự động. | Kết hợp AI tool với CI pipeline để kiểm soát chất lượng code trước khi merge. | AI gợi ý & highlight issue => tiết kiệm 30–50% thời gian review |
| Build & Merge | Sử dụng công cụ Danger.js, Mergify, Reviewpad | AI hỗ trợ nhận diện và xử lý PR có nguy cơ xung đột hoặc vi phạm quy chuẩn sớm. | Bot cảnh báo conflict, enforce rule merge, build test tự động |
| So sánh doc & design | Sử dụng công cụ: Visily, Figma AI plugins | Chuyển bản vẽ giao diện sang wireframe, highlight sự khác biệt giữa bản mô tả và design. | Tool AI detect chênh lệch, báo ngay cho BA/Dev xử lý. |
| Log work / quản lý task | – Theo dõi effort thực tế: sử dụng công cụ Timely by Memory.ai, RescueTime. – Log work từ commit Git: sử dụng công cụ Jira Smart Commits – Tích hợp Jira report hoặc các tool như Timely, Harvest để track để đánh giá effort actual & est. | – Ghi lại thời gian làm việc thực tế, tự động sync với Jira hoặc Trello. – Tự động update Jira task status và log work thông qua cú pháp trong commit message (VD: git commit -m “PP-123 #time 2h #comment done API”). – Review estimate ở Retro để cải tiến cách ước lượng. | Tự động ghi nhận worklog từ IDE, Git hoặc desktop time tracker. |
| Viết & test unit | – Xây dựng template unit test. – Sử dụng static code analysis (ví dụ: SonarQube) và auto test bằng Postman/Newman hoặc Cypress. | Tự động viết unit test và chạy test trên code mới commit. | Sinh test case tự động, self-test chính xác và nhanh hơn. |
| Quản lý chặt chẽ Action item sau mỗi buổi Retro | Sử dụng công cụ theo dõi: Jira/Trello/Notion để tracking riêng action items retro. | – Sau mỗi buổi Retro, team Leader ghi rõ từng Action Item và giao nhiệm vụ cụ thể cho từng người phụ trách action đó. – Đặt deadline rõ ràng cho từng action. – Review định kỳ: Mỗi đầu Sprint Planning, dành 5 phút để update trạng thái các Action Item từ Retro trước. | – Không để vấn đề cũ tái diễn. – Cải thiện liên tục chất lượng Sprint. |
| Nâng cao khả năng teamwork, giảm silo giữa các Dev | – Daily sync có chiều sâu hơn. – Kiến thức chung về project. – Cross review | – Yêu cầu mỗi Dev không chỉ báo cáo task của mình mà còn nêu rõ các phụ thuộc với task khác (nếu có). – Dev Lead nắm toàn bộ tình hình, sẵn sàng điều phối khi có rủi ro bottleneck. – Tổ chức “Chia sẻ dự án” mỗi tuần 1 lần (15-30 phút), mỗi Dev sẽ giới thiệu module mình đang làm cho cả team. – Mỗi Dev thử làm reviewer cho một task của người khác hoặc thay phiên nhau hỗ trợ cross-task trong sprint. | – Nâng cao tinh thần teamwork Phát hiện sớm các điểm tắc nghẽn hoặc phụ thuộc giúp sprint vận hành trơn tru – Góp phần tăng chất lượng sản phẩm và đảm bảo đúng tiến độ vì team kiểm soát được toàn cục. – Chia sẻ kiến thức và tăng khả năng thay thế khi có Dev vắng mặt, nghỉ phép hoặc nghỉ việc. |
| Xây dựng quy chuẩn cho việc comment và ghi chú code (Job, Queue, API, …) | – Template chuẩn comment cho từng loại code – Review code yêu cầu kiểm tra comment. – Áp dụng tool tự động kiểm tra mức độ document/comment: Dùng plugin như PHPStan, ESLint kèm quy tắc kiểm tra comment với mức độ tùy chỉnh. – Training hoặc sharing nội bộ về best practice comment | – Comment trước function, class và các block logic quan trọng: mục đích, đầu vào, đầu ra, xử lý đặc biệt. – PR/Code Review checklist sẽ thêm bước “Check comment đầy đủ và đúng chuẩn”. | – Tăng khả năng maintain. – Giảm rủi ro khi thay đổi nhân sự. – Tiết kiệm thời gian cho cả team. – Tạo môi trường làm việc chuyên nghiệp và chuẩn hóa hơn. |
| Cải thiện quyền truy cập, hỗ trợ kiểm tra dữ liệu production | – Thiết lập môi trường staging/sandbox. – Xây dựng quy trình request hỗ trợ | – Chuẩn bị một môi trường staging mô phỏng gần như 100% production (data ẩn danh mã hóa nếu cần). – Tự động đồng bộ dữ liệu production về staging định kỳ (hàng tuần hoặc trước mỗi Sprint). – Nếu cần check trực tiếp trên production, thiết lập form yêu cầu rõ ràng (về lý do, dữ liệu truy vấn, thời gian cần thiết), gửi cho Ops/DBA. – Thời gian SLA (Service Level Agreement) phản hồi trong vòng 1-2 giờ để tránh delay. | – Chủ động kiểm tra nguyên nhân. – Giảm thời gian chờ đợi từ bộ phận khác. |
Quy trình làm việc hiện tại của team Developer đã xây dựng được nền tảng tương đối vững chắc theo phương pháp Scrum. Tuy nhiên, để nâng cao hiệu quả và thích ứng với quy mô lớn hơn, việc cải tiến theo hướng tự động hóa, tập trung hóa dữ liệu và tích hợp công cụ hỗ trợ thông minh là điều cần thiết. Việc tối ưu quy trình không chỉ giúp nâng cao hiệu suất làm việc mà còn xây dựng một team phát triển chủ động, minh bạch và sẵn sàng thích ứng với mọi thay đổi.