 |
| Một dạng dashboard của RedmineCRM, mô tả khối lượng công việc của từng cá nhân nhóm theo trạng thái. Nguồn: RedmineCRM |
Xuất phát từ nhu cầu sử dụng 1 hệ thống mã mở, linh hoạt trong việc quản lý dự án, đồng thời cũng vì phải có 1 nơi lưu trữ quản lý các thay đổi đ/v hệ thống CNTT nói chung (do cty kiểm toán yêu cầu), chúng tôi tìm đến trac[1] trước tiên (chứ ko phải là Redmine[2]). trac về cơ bản khá tốt, đặc biệt phần quản lý tickets/issues, lại được viết bằng python, là ngôn ngữ lập trình mà cá nhân tôi rất thích. Nhưng trac cũng có cái dở, tồn tại 1 số vấn đề tương đối nghiêm trọng: đa số các chức năng quản trị chỉ được hỗ trợ thông qua dòng lệnh và còn tạo mỗi dự án 1 database riêng[3]... Các vấn đề này khiến cho việc quản trị trac khá vất vả. Vì thế sau khi dùng khoảng 2 năm, đến 2010, chúng tôi quyết định tìm phần mềm mới thay thế trac. Và Redmine sau bao nhiêu năm sử dụng, đã không phụ lòng mong mỏi của chúng tôi.
Công việc chuyển dữ liệu từ trac sang Redmine không quá khó khăn (dễ đến nỗi anh chàng phụ trách việc này ko kịp viết lại tài liệu :D). Kế đến, tất cả các chức năng quản trị như quản lý người dùng, nhóm, phân quyền, quản lý dự án... tất cả đều được thực hiện dễ dàng thông qua giao diện thay cho việc dùng dòng lệnh. Thế là chúng tôi nhào vào viết wiki, tạo issues (lúc này ko còn gọi là tickets theo cách gọi của trac nữa)... Mỗi nhân viên của team có 1 issue, gọi là CV của anh A, hoặc issue CV của anh B. Một số dự án lớn thì lại tạo issue riêng để lưu tất tần tật tài liệu, trao đổi... chỉ trong 1 issue đó. Sau này dùng lâu rồi, tôi mới hiểu có đồ chơi là 1 chuyện, nhưng dùng thế nào, cho việc gì và làm sao hiệu quả... thì là 1 chuyện khác.
Đi thẳng vào mục đích/lợi ích của Redmine, sau khoảng 7 năm dùng các hệ thống Issue Tracking riêng (trac, Redmine, JIRA)[4] cũng như module tích hợp trong các hệ thống github, Google Code..., là 1 lãnh đạo cần phải quản lý công việc của nhân viên dưới quyền, tôi nhận thấy Redmine dùng tốt cho 3 mục đích:
- Quản lý dự án. Rất nhiều tài liệu, slides, blog posts trên Internet nói về chuyện dùng Redmine cho việc này. Tôi cũng sẽ đề cập 1 chút vv quản lý dự án nhưng xin hẹn ở 1 chủ đề riêng.
- Quản lý tri thức. Nói tên nghe rất "kêu", nhưng ẩn đằng sau đó chỉ là Wiki mà thôi :D.
- Quản lý vận hành, bao gồm cả những dạng quản lý hỗ trợ (Service Desk). Cái này đối với tôi là tinh hoa của việc vận dụng 1 hệ thống Issue Tracking. Cũng vì gọi chung là Issue Tracking thay vì Project Management mà tôi nhận thấy phải dùng Redmine cho cả việc vận hành/hỗ trợ người dùng này. Nói thêm 1 chút, một trong những thành quả lớn nhất mà tôi đạt được đó là, khi các bạn trong team của tôi nghỉ việc, tôi chỉ việc assign issues cho các bạn khác thay thế mà ko phải lo lắng xem quá trình bàn giao công việc có thiếu sót chỗ nào không. Tuyệt hơn nữa, các bạn mới cũng có thể lục lại những CV đã hoàn tất (closed issues) làm cho quá trình hoạt động của team không bị ngắt quãng, không bị mất thông tin của bất kỳ CV nào (nói thế chứ 1 số CV các bạn đó không lưu nên chuyện mất mát thông tin là vẫn xảy ra).
Tôi cũng quan sát khá nhiều công ty, khá nhiều chuyên gia CNTT, kể cả 1 số công ty tư vấn/kiểm toán quốc tế. Phần đông họ vẫn chỉ cần đến email, 1 số công cụ như Word, Excel, MS Project, Notes... và cảm thấy "đủ". Nhưng cũng khá nhiều nơi đã bị tôi thuyết phục sau khi họ cần tìm giải pháp cho 1 trong 3 vấn đề tôi nêu trên. Đặc biệt có 1 phòng ban trong công ty của tôi đã sử dụng Redmine khoảng 2 năm từ 2013 đến nay, đã lưu và xử lý hơn 15000 yêu cầu hỗ trợ với hơn 1000 người dùng, trên cùng 1 hệ thống dùng chung với team của chúng tôi.
Có lẽ với chừng này thông tin, tôi hi vọng đã thuyết phục được các bạn trong việc quyết định sử dụng Redmine (hoặc 1 hệ thống tương tự như JIRA) với 3 mục tiêu nêu trên. Chúc các bạn dùng công cụ này thành thạo & hiệu quả.
(Bắt đầu bớt email, chuyển sang Redmine thôi!!??!!)
(Còn tiếp)
PS. Khi đọc lại bài viết này, tôi nhận thấy bài viết chưa hay lắm khi tiêu đề nói về Redmine, nhưng đoạn đầu lại đề cập tới trac. Tôi đã thử nhưng thấy bản thân không thể viết lại hay hơn. Bạn đọc xem góp ý nhé.
----
[1]: http://trac.edgewall.org/
[2]: http://www.redmine.org/
[3]: http://trac.edgewall.org/wiki/TracAdmin
[4]: https://en.wikipedia.org/wiki/Issue_tracking_system, https://en.wikipedia.org/wiki/Comparison_of_issue-tracking_systems
5 comments:
Em thấy nói về trac chỉ làm nền để nổi bật cái hay của Redmine thôi :D.
Btw, 101 trong "Redmine 101" là gì vậy anh?
Cám ơn anh về bài mới.
Cám ơn em đã nhận xét. Thực tế anh đã dùng trac trước rồi Redmine sau, đúng những gì trong bài viết chứ ko có ý định lăng xê ưu ái đứa nào hơn :D.
Ngoài ra trước trac, anh còn dùng Backpackit của Basecamp (do sếp của anh tìm rồi bắt nhân viên xài, giờ nó đã về hưu) nhưng nó giống 1 Notetaking Software, ko phù hợp để quản lý dự án.
Về 101, trích từ https://en.wikipedia.org/wiki/101_(number)#In_education
> In American university course numbering systems, the number 101 is often used for an introductory course at a beginner's level in a department's subject area. This common numbering system was designed to make transfer between colleges easier.
Woa, em không ngờ anh reply nhanh vậy. Giờ em mới vào check bài mới.
He he, em cũng chưa thấy opensource vào ngon và ổn định hơn redmine.
Giờ em mới biết cách đánh số ngầm 101 này.
Btw, em biết đến blog anh qua bài NSM, em thấy background của anh cũng seem Splunk nữa :D. Các bài của anh đậm chất kinh nghiêm chứ không kiến thức tổng quan, anh tạm pending hay ngừng hẳn chuỗi bài NSM/Splunk vậy anh?
Hiện số lượng phần mềm anh đang dùng cho chuyên môn đếm trên đầu ngón tay ;(, trong đó có Redmine, Splunk gần như là 2 phần mềm chủ đạo. Anh nhận thấy viết tổng quan ko hiệu quả, ai cũng đã viết rồi cho nên anh chỉ viết những gì chưa có thôi :D.
Anh còn 1 số chia sẻ về NSM/Splunk nhưng chưa có thời gian viết. Cụ thể là cách tuỳ biến để Splunk hiển thị KQ theo mong muốn của bản thân; rồi quan trọng nhất đ/v NSM theo anh là data. Bản thân anh mất rất nhiều thời gian cho việc "hiểu" data mà anh đang có.
Anh cũng sẽ viết 1 số bài khác nữa. Tất cả chung quy về những kinh nghiệm, chính kiến của bản thân. Vd khi nào thì mail, khi nào chat, điện thoại, gặp trực tiếp, khi nào mới Redmine. 1 bài ngắn nữa về kinh nghiệm quản lý firewalls :D.
Hi vọng thời gian tới sẽ sắp xếp viết tiếp.
Cảm ơn anh đã chia sẻ chân thành.
Về mảng NSM, các bài viết của anh là "thực" nhất trong các bài tiếng Việt mà em đọc. Mặc dù hơi ít bài :D
Chúc anh có một nice day và nhiều thời gian rỗi để có thể tiếp tục sharing.
Post a Comment