Học IT 3, 4 năm rồi mới nhận ra mình không muốn dành cả ngày để viết code có thể khiến nhiều người khá hoang mang. Bạn vẫn thích công nghệ, hiểu logic, dữ liệu và hệ thống, nhưng những lúc hứng thú nhất lại là khi được phân tích một vấn đề, tìm xem quy trình đang kẹt ở đâu hoặc nghĩ cách làm cho công việc chạy gọn hơn.
Nếu đang ở đoạn này, bạn vẫn còn nhiều hướng để đi tiếp với nền tảng IT mình đã có.
Học IT nhưng không muốn làm Dev thì còn những hướng nào?
Một hệ thống số hiếm khi được tạo ra bởi riêng Developer.
Trước khi một tính năng được viết thành code, có người cần tìm hiểu người dùng đang gặp vấn đề gì, quy trình hiện tại diễn ra thế nào, dữ liệu cần lưu ra sao và giải pháp nên hoạt động theo logic nào.
Sau khi hệ thống được xây, cũng cần người kiểm tra, triển khai, theo dõi và tiếp tục cải tiến.
Vì vậy, nếu vẫn muốn làm gần công nghệ, bạn có thể tìm hiểu một số hướng như:
Business Analyst
Business Analyst thường đứng giữa nhu cầu nghiệp vụ và đội ngũ xây dựng sản phẩm. Công việc có thể gồm tìm hiểu quy trình, làm rõ yêu cầu, xác định các trường hợp sử dụng và giúp team hiểu hệ thống cần giải quyết vấn đề gì.
Product
Người làm Product quan tâm đến vấn đề của người dùng, giá trị của từng tính năng, thứ tự ưu tiên và hướng phát triển của sản phẩm.
Quality Assurance
Nếu thích tìm lỗi, kiểm tra logic và đặt câu hỏi “nếu người dùng làm thế này thì chuyện gì xảy ra?”, Quality Assurance cũng là một hướng đáng cân nhắc.
Solution Builder
Solution Builder tập trung vào việc hiểu cách một công việc đang vận hành, xác định vấn đề rồi chuyển bài toán đó thành một giải pháp số có thể sử dụng.
Đây cũng là hướng khá phù hợp với những người thích logic và công nghệ nhưng muốn dành nhiều thời gian hơn cho bài toán vận hành.
Thử nhìn vào một bài toán thực tế
Giả sử bạn thực tập trong phòng nhân sự:
- Mỗi ngày, team nhận rất nhiều hồ sơ ứng tuyển từ nhiều nguồn khác nhau.
- Có hồ sơ gửi qua email.
- Có hồ sơ từ form tuyển dụng.
- Một số CV được nhân viên tự tải xuống rồi đưa vào Google Drive.
- Sau đó nhân sự phải mở từng hồ sơ để kiểm tra, ghi thông tin ứng viên vào một file, chuyển cho người phụ trách chuyên môn và chờ phản hồi.
Một thời gian sau, mọi thứ bắt đầu rối:
- Có ứng viên đã phỏng vấn nhưng file vẫn ghi “Đang sàng lọc”.
- Có CV chưa ai xem.
- Một số hồ sơ thiếu thông tin nhưng không ai phát hiện.
- Muốn biết một vị trí đang có bao nhiêu ứng viên ở từng vòng, team phải lọc file thủ công.
Nếu là Developer, bạn có thể nghĩ tới việc xây một hệ thống tuyển dụng.
Nhưng trước khi xây, có một loạt câu hỏi cần được giải quyết:
- Ứng viên nộp hồ sơ ở đâu?
- Những thông tin nào cần được lưu?
- Ai là người sàng lọc hồ sơ?
- Ứng viên đi qua những trạng thái nào?
- Ai có quyền chuyển ứng viên sang vòng phỏng vấn?
- Khi hồ sơ thiếu thông tin thì xử lý ra sao?
- Nếu một hồ sơ nằm ở trạng thái “Chờ review” quá ba ngày, ai cần được nhắc?
- Quản lý cần xem báo cáo gì?
Đây là phần công việc mà Business Analyst, Product, người làm automation hay Solution Builder đều có thể tham gia ở những mức độ khác nhau.
Solution Builder sẽ nhìn bài toán này như thế nào?
Một Solution Builder có thể bắt đầu bằng việc vẽ lại quy trình:
Ứng tuyển → Sàng lọc → Review chuyên môn → Phỏng vấn → Đề nghị tuyển dụng → Kết thúc
Sau đó xác định các thành phần cần có trong giải pháp.
1. Dữ liệu
Mỗi ứng viên cần có tên, vị trí ứng tuyển, nguồn hồ sơ, CV, trạng thái hiện tại, người phụ trách và lịch sử xử lý.
2. Trạng thái
Ví dụ:
- Hồ sơ mới
- Đang sàng lọc
- Chờ review chuyên môn
- Chờ phỏng vấn
- Đã phỏng vấn
- Offer
- Không phù hợp
3. Phân quyền
Nhân sự có thể cập nhật hồ sơ.
Người phụ trách chuyên môn có thể review ứng viên thuộc vị trí của mình.
Quản lý có thể xem toàn bộ pipeline tuyển dụng.
4. Workflow
Khi ứng viên chuyển sang “Chờ review chuyên môn”, hệ thống tự gửi thông báo cho người phụ trách.
Nếu sau một khoảng thời gian vẫn chưa có phản hồi, hệ thống có thể nhắc lại.
5. Báo cáo
Team có thể xem:
- Có bao nhiêu ứng viên ở từng vòng?
- Vị trí nào đang thiếu ứng viên?
- Hồ sơ nào đang bị giữ quá lâu?
- Ai đang phụ trách từng ứng viên?
Bạn vẫn đang làm việc với công nghệ.
Nhưng điểm bắt đầu là câu hỏi:
Công việc này nên vận hành như thế nào để ít phụ thuộc vào thao tác thủ công hơn?
Làm sao biết mình có hợp với hướng này?
Bạn có thể tự kiểm tra bằng 5 dấu hiệu khá đơn giản.
1. Bạn hay hỏi “Tại sao phải làm bước này?”
Khi nhìn một quy trình, bạn thường tò mò lý do tồn tại của từng bước.
2. Bạn thích biến thứ lộn xộn thành thứ có cấu trúc
Một file dữ liệu rối khiến bạn muốn sắp xếp lại.
Một quy trình truyền miệng khiến bạn muốn vẽ thành flow.
3. Bạn thích logic hệ thống
Bạn hứng thú với những câu hỏi như:
“Nếu A xảy ra thì bước tiếp theo là gì?”
“Ai được phép làm việc này?”
“Trạng thái nào được chuyển sang trạng thái nào?”
4. Bạn thường nghĩ đến cách giảm việc thủ công
Thấy ai đó copy dữ liệu giữa ba file mỗi ngày, bạn sẽ tự hỏi có thể tự động hóa đoạn nào.
5. Bạn thích giải quyết bài toán thực tế
Bạn muốn nhìn thấy một quy trình sau khi cải tiến giúp mọi người đỡ phải hỏi nhau, nhập dữ liệu ít hơn hoặc theo dõi công việc dễ hơn.
Nếu thấy mình hợp với vài điểm trên, bạn có thể thử tìm hiểu các vai trò nằm giữa nghiệp vụ và công nghệ trước khi quyết định rời hẳn khỏi IT.
Có thể thử ngay bằng một bài tập nhỏ
Chọn một quy trình quen thuộc.
Ví dụ:
- đăng ký nghỉ phép
- mượn thiết bị
- quản lý hồ sơ ứng viên
- duyệt nội dung
- đăng ký phòng họp
- xử lý yêu cầu hỗ trợ
Sau đó viết ra 6 câu trả lời:
- Ai bắt đầu quy trình?
- Họ cần cung cấp dữ liệu gì?
- Công việc đi qua những bước nào?
- Ai chịu trách nhiệm ở từng bước?
- Những trường hợp nào thường khiến quy trình bị kẹt?
- Có bước nào có thể tự động hóa hoặc nhắc việc?
→ Nếu bạn thấy việc bóc một quy trình như vậy khá thú vị, hãy thử đi tiếp một bước.
Dùng một công cụ no-code/low-code như Cleeksy DOP, một spreadsheet hoặc một nền tảng automation để biến quy trình đó thành một giải pháp đơn giản.
Đừng bắt đầu bằng câu hỏi “mình cần học tool nào”.
Hãy bắt đầu bằng một vấn đề thật.
Từ đó bạn sẽ dễ nhận ra mình thích phần nào của công việc hơn: phân tích, thiết kế giải pháp, làm sản phẩm, automation hay lập trình.
Nếu đang học IT nhưng không muốn làm Dev, phần nào trong một dự án khiến bạn thấy hứng thú nhất?