Nội dung chính
Đọc bản tiếng Anh tại đây.
Technical Writer là người “phiên dịch” tài liệu kỹ thuật thành ngôn ngữ dễ hiểu. Công nghệ và sản phẩm ngày càng phức tạp kéo theo sự phát triển mạnh mẽ của lĩnh vực technical writing. Khi xu hướng này vẫn đang tiếp diễn, cơ hội thăng tiến hoặc chuyển hướng sự nghiệp IT với vị trí Technical Writer vẫn rộng mở cho bạn.
ITviec đã trò chuyện với Amit Singh, một Technical Writer 9 năm kinh nghiệm, hiện làm việc tại Wizeline – công ty dịch vụ công nghệ hàng đầu thế giới, giúp doanh nghiệp xây dựng các sản phẩm và nền tảng kỹ thuật số đi kèm với tài liệu kỹ thuật chất lượng cao.
Cùng đọc những chia sẻ của Amit để có cái nhìn toàn diện về công việc, kỹ năng cần có và định hướng phát triển sự nghiệp của một Technical Writer.
I. Technical Writer là ai?
Technical Writer là người nghiên cứu về các sản phẩm kỹ thuật hay công nghệ phức tạp, sau đó chuyển thể các khái niệm kỹ thuật chuyên ngành thành ngôn ngữ và định dạng dễ hiểu hơn, dựa trên các template và style guide mẫu.
3 dạng nội dung Technical Writer thường viết:
- Tài liệu kỹ thuật cho người dùng cuối: User guide/ User manuals, Online-help, Installation guide, Configuration guide, Troubleshooting guide, Command line interface guide, Administration guide, API guide, Quick start/ getting started guide, release notes…
- Tài liệu dự án và quy trình: Dự toán dự án, báo cáo dự án, bản trình bày Powerpoint, tài liệu đào tạo, tài liệu lập kế hoạch, mẫu dự án, hướng dẫn văn phong, hướng dẫn cho nhân viên mới…
- Tài liệu cho Sales và Marketing: Blog/ bài báo phát hành sản phẩm, tài liệu Marketing, bài viết kiến thức nền tảng, Câu hỏi thường gặp (FAQs)…
Công việc của Technical Writer là gì?
Công việc chính của Technical Writer là:
- Tham gia scrums, phỏng vấn kỹ sư, thu thập thông tin đầu vào
- Phát triển tài liệu dựa trên chủ đề và theo mô hình gia tăng của phương pháp Agile
Để làm điều đó, Technical Writer cần phối hợp với nhiều bên liên quan như software developer, tester, product/ project manager, sales & marketing, chăm sóc khách hàng… để thu thập tất cả thông tin cần thiết.
Để dễ hình dung hơn, chúng tôi hỏi Amit về mối liên hệ giữa công việc của Technical Writer với các team phát triển sản phẩm khác. Tại sao cần một team technical writing riêng khi Dev hay QA/ QC cũng có thể viết các tài liệu kỹ thuật?
Theo Amit, Developer hoặc QA/ QC cũng thường viết các tài liệu như user guides hay release notes, nhưng tốt nhất vẫn nên có một team viết kỹ thuật riêng.
Vì Dev hay QA/QC chỉ có thể viết phần kỹ thuật họ làm, trong khi Technical Writer có thể viết tất cả. Developer cũng thường giỏi viết code hơn viết văn, còn Technical Writer có nền tảng ngôn ngữ vững chắc và có chứng chỉ chuyên môn cho công việc này.
Theo Amit, các công ty lớn như Cisco có hệ thống quản lý nội dung khổng lồ bằng document, khi đó họ cần có đội ngũ technical writer chuyên nghiệp.
Điều này mang lại 3 lợi ích:
- Chất lượng. Amit tin rằng “nếu tập trung vào một lĩnh vực, bạn có thể làm việc hiệu quả hơn”. Vì vậy, một Technical Writer chuyên nghiệp chắc chắn sẽ viết document tốt hơn một kỹ sư.
- Thời gian và công sức. Khi có team viết kỹ thuật chuyên nghiệp, các tính năng được giải thích cặn kẽ, thậm chí có video hướng dẫn trực quan. Nhờ đó, công ty tốn ít chi phí cho mảng chăm sóc khách hàng hơn.
- Độ tin cậy. Nếu tất cả các tính năng được ghi lại xác thực và hợp pháp, khách hàng sẽ tin tưởng sản phẩm và doanh nghiệp của bạn hơn.
II. Quy trình phát triển một Tài liệu kỹ thuật
Ngày nay, quy trình viết kỹ thuật đòi hỏi nhiều thời gian để nghiên cứu và phát triển. Trong phương pháp Agile, technical writing nên được thực hiện song song với việc phát triển và test sản phẩm trong một sprint 2 tuần.
Năm 2010, mọi thứ đơn giản hơn nhiều. Tài liệu cho người dùng được viết trong MS Word và xuất dưới dạng PDF. Nhưng bây giờ chúng ta đã có các định dạng đầu ra đa dạng dựa trên công cụ biên soạn XML.
Technical writing là một quy trình tuần hoàn, được gọi tên là DDLC (Document Development Life Cycle – Vòng đời phát triển tài liệu). DDLC gói gọn việc quản lý tài liệu kỹ thuật từ bản viết nháp đầu tiên cho đến bước duy trì và cập nhật.
4 giai đoạn của Vòng đời Phát triển tài liệu:
- Giai đoạn 1. Phân tích (Nghiên cứu và thu thập thông tin)
Technical writer nhận yêu cầu về tính năng từ Product Owner hoặc bất kỳ ai chịu trách nhiệm về việc ra mắt sản phẩm. Họ phân tích các yêu cầu đó và thu thập các thông tin sau:
+ Người đọc: Technical Writer cần biết mình đang viết cho ai. Nếu người đọc ở level beginner, tài liệu chỉ nên có các tính năng cơ bản và ngôn ngữ đơn giản. Nếu người đọc là chuyên gia, có thể thêm các tính năng nâng cao, sử dụng nhiều từ ngữ chuyên môn và hoa mỹ hơn.
+ Kiểu tài liệu: Trước khi viết, Technical Writer cần biết kiểu tài liệu nào sẽ hiệu quả nhất. Ví dụ: Online-help là kiểu phù hợp nhất để viết về UI phần mềm, trong khi User Manual hữu ích cho các sản phẩm phần cứng.
+ Tool kit: Bộ công cụ trợ giúp phổ biến như:
– Công cụ biên soạn: Robohelp, Framemaker, Microsoft Word…
– Công cụ chụp màn hình: Hijack Pro, SM Snap, MS paint
– Công cụ tạo đa phương tiện: Camtasia Studio, Adobe Captivate…
Tiêu chí để lựa chọn các công cụ là dựa trên kiểu tài liệu. Ví dụ:
– Framemaker và Microsoft Word thường được chọn để viết User Manual.
– Robohelp dùng để tạo Online-help hoặc Web-help cho ứng dụng.
- Giai đoạn 2: Thiết kế.
Có 4 yếu tố Technical Writer cần thiết kế:
+ Table of content (Mục lục): Có thể xem là sơ đồ ban đầu, hệ thống phân cấp hoặc kiến trúc của tài liệu, hiển thị rõ số trang cho từng chủ đề.
+ Style Guides / Style Sheets: Gồm các tiêu chuẩn đảm bảo tính nhất quán của toàn bộ tài liệu. Style guide giúp xác định giọng văn, sắc thái, những điều nên – không nên làm khi viết tài liệu.
Những Style guide nổi tiếng đã được phát hành là:
– Manual Style of Technical Publication (MSTP) của Microsoft
– Chicago Manual of Style
– Style of elements của Shrunk & White
Microsoft’s Manual Style of Technical Publications (MSTP) được xem là “kinh thánh” của Technical Writer, được sử dụng trên toàn thế giới. Tuy nhiên, mỗi công ty sẽ tuỳ chỉnh style guide dựa trên sản phẩm của họ.
+ Template hoặc outline: Giúp thiết lập cấu trúc tài liệu, gồm các cấp độ tiêu đề, số lượng bảng và hình ảnh,…
+ Kế hoạch dự án: Bao gồm các chi tiết của dự án như: tổng số chủ đề liên quan, số lượng Technical Writer tham gia, thời gian viết và đánh giá dự kiến,…
- Giai đoạn 3. Phát triển nội dung.
+ Viết nháp: Technical Writer viết bản nháp đầu tiên dựa trên hiểu biết của bản thân (và những gì họ tự nghiên cứu).
+ Review: Cần ít nhất 2 vòng review để đảm bảo nội dung thống nhất và chính xác:
– Review ngôn ngữ: Technical Writer tự kiểm tra chính tả, ngữ pháp, dấu câu… để đảm bảo ngôn ngữ nhất quán và tuân theo style guide.
– Review kỹ thuật: Technical Writer gửi tài liệu cho SME (Subject-Matter Expert) review và ký xác nhận để đảm bảo nội dung chính xác về mặt kỹ thuật.
SME là ai?
SME có thể là bất kỳ ai như Developer, Product Owner, QA/ QCs – miễn là có hiểu biết sâu sắc về các tính năng và là đầu mối liên hệ với khách hàng.
Trong phương pháp Agile, thường có một người quản lý kỹ thuật cho từng tính năng cụ thể. Người đó chính là SME mà Technical Writer cần tìm đến.
- Giai đoạn 4. Cung cấp & Bảo trì:
Một khi tài liệu được phát hành và gửi cho khách hàng, công việc cập nhật và bảo trì sẽ không quá khó khăn. Một Technical Writer có thể nhận trách nhiệm bảo trì cho 2-3 tài liệu đã đi vào hoạt động.
+ Bảo quản: Tài liệu kỹ thuật cần được bảo quản để có thể tái sử dụng. Hệ thống quản lý nội dung (CMS) như Microsoft SharePoint, Astoria và Documentum sẽ rất hữu ích ở đây
+ Cập nhật: Nếu team trong nhà hoặc khách hàng report bug, Developer sẽ fix lỗi, sau đó thảo luận với Technical Writer để xác định các thay đổi trong tính năng. Sau đó, Technical Writer nào viết document sẽ chịu trách nhiệm cập nhật lại tất cả các tài liệu liên quan.
DDLC là một vòng lặp. Để quản lý vòng lặp này, bạn cần các công cụ quản lý quy trình hợp tác như Jira, Rally. VD: Manager có thể tạo checklist gồm 2 – 16 mục, Technical Writer sẽ đánh dấu vào các mục mình đã làm xong như: kiểm tra ngữ pháp, style guide, kỹ thuật…
Quy trình tóm tắt để bắt đầu viết tài liệu kỹ thuật cơ bản:
- Viết tự do
- Brainstorm
- Nghiên cứu / Lập kế hoạch
- Phác thảo / Thiết kế
- Viết nháp
- Sửa (và tiếp tục sửa)
- Hiệu đính và chỉnh sửa lần cuối
- Xuất bản
- Bảo quản và cập nhật
2. Nguyên tắc để viết một bản technical writing chất lượng là gì?
Amit cung cấp một số từ khóa để đánh giá chất lượng của tài liệu kỹ thuật:
- Dùng đúng ngữ pháp
- Viết ngắn gọn
- Dùng thể chủ động, giọng văn tích cực và trung lập về giới tính
- Tránh những câu dài dòng và phức tạp
- Sử dụng dấu câu chính xác
- Làm theo style guide và template
- Dùng cấu trúc song song và cách viết tối giản
Trước đây, mọi thông tin lẫn lộn trong một tài liệu duy nhất dài 100 – 200 trang gây khó khăn cho người dùng. Hiện nay, các tính năng được chia thành các phần nhỏ. Độ dài tài liệu trung bình cho một tính năng chỉ khoảng 1-2 trang. Trong một tháng, team của Amit sẽ phát triển 10 – 15 trang tài liệu kỹ thuật cho 10 tính năng khác nhau.
3. Technical writing khác gì với Content writing?
Châm biếm, cảm xúc hoặc hài hước đều không được khuyến khích trong các Style guide của technical writing, khác với khi viết content, blog hoặc tài liệu marketing.
Như Amit nhận định: “Tài liệu kỹ thuật phải là những hướng dẫn hoặc mệnh lệnh đơn giản. Chỉ vậy thôi, không cảm xúc, không thấu cảm”.
Một điểm khác biệt nữa là tài liệu kỹ thuật rất nặng tính “kỹ thuật”, vì vậy chỉ có khán giả mục tiêu của tài liệu đó mới có thể hiểu được, trong khi gần như mọi người đọc đều hiểu được nội dung blog.
III. Làm thế nào để trở thành Technical Writer?
Theo Amit, bất kỳ ai có những tố chất sau đều có thể trở thành Fresher Technical Writer:
- Ngoại ngữ tốt
- Chú ý đến chi tiết
- Chú trọng chất lượng
- Kỹ năng nghiên cứu và phân tích tốt, đặc biệt là phân tích đối tượng
- Giao tiếp tốt, có thể cộng tác với các team khác nhau để thu thập thông tin
- Có khả năng xây dựng môi trường làm việc hợp tác
- Tính sở hữu (ownership)
- Kỹ năng đa nhiệm và quản lý dự án khi làm nhiều dự án cùng lúc
- Hứng thú với việc nghiên cứu sâu để hiểu về sản phẩm
- Hiểu cơ bản về code là một lợi thế để phát triển tài liệu về API hoặc cho Developer, hoặc có thể dùng code snippet để hiểu rõ về sản phẩm
Để phát triển thành Senior Technical Writer, bạn cần rèn luyện thêm những kỹ năng sau:
- Quản lý dự án
- Đa nhiệm
- Làm việc song song trên nhiều dự án
- Hướng dẫn/ cố vấn
- Tự động hóa quy trình để giảm bớt công việc
Về cách cải thiện kỹ năng viết kỹ thuật, Amit đưa ra một số lời khuyên:
- Tập thói quen đọc để “nâng trình” ngữ pháp và ngôn ngữ
- Thực hành nhiều hơn với các công cụ soạn thảo dựa trên XML
- Cộng tác với các Technical Writer khác
- Tham dự các sự kiện về technical writing để cập nhật xu hướng thị trường
- Tham gia các khoá học có chứng chỉ liên quan đến viết technical writing
- Thực hành diễn thuyết trước đám đông/ toastmasters
IV. Định hướng phát triển sự nghiệp của Technical Writer
Hiện nay, nhiều lĩnh vực có nhu cầu tuyển dụng mạnh mẽ với vị trí Technical Writer, trong đó có:
- Mạng – viễn thông
- Lưu trữ đám mây
- Công nghiệp chất bán dẫn
- Chăm sóc sức khỏe
- Tài chính / ngân hàng
- Thương mại điện tử
- Truyền thông và giải trí
- Tự động hoá công nghiệp
Nếu bạn quyết định theo đuổi nghề Technical Writer, có hai định hướng phát triển sự nghiệp cho bạn:
1. Thăng tiến lên Quản lý/ Giám đốc: Nếu học thêm các ngôn ngữ lập trình như Java hoặc Python, đồng thời hoàn thành chứng chỉ API và quản lý dự án, bạn có thể thăng tiến lên BA, Project Manager, Product Owner, hoặc Delivery Manager. Nếu làm việc trong một tập đoàn lớn, bạn thậm chí có thể trở thành Director / VP của mảng quản lý tài liệu.
Xem thêm việc làm Java chất tại đây.
Xem thêm việc làm Product Manager chất tại đây
2. Tiếp tục là một Technical Writer độc lập: Điểm khác biệt lớn nhất là lương của bạn sẽ thấp hơn so với người thuộc cấp quản lý.
Nhận định về ý kiến cho rằng: “Đối với Technical Writer, càng tập trung vào thị trường ngách càng tốt cho sự nghiệp”, Amit không đồng tình. Anh cho rằng, tinh thông kiến thức của một lĩnh vực cụ thể có thể giúp bạn vượt trội trong lĩnh vực đó, nhưng sẽ giới hạn tiềm năng của bạn. Là một Technical Writer, Amit tin rằng viết lách mới là kỹ năng quan trọng nhất, do đó bạn nên sẵn sàng viết cho bất kỳ lĩnh vực hoặc công nghệ nào. Nó sẽ mở rộng và đa dạng hóa công việc của bạn.
Mức lương của Technical Writer
Mức lương của một Technical Writer độc lập (không phải quản lý) có thể dao động từ 1500 – 6000USD/ tháng (ở khu vực Ả Rập).
- Đối với junior: Mức lương 1000 – 1500 USD/ tháng cho vị trí cộng tác viên nếu chưa thành thạo công cụ, sản phẩm, style guide…
- Đối với mid-level/ senior: Bạn cần học rất nhiều về quy trình viết và các công cụ biên soạn trong 2 – 4 năm để đạt được level này, khi đó mức lương của bạn sẽ tăng lên.
- Mức lương cao nhất (5000 – 6000USD / tháng) được trả cho technical writer có thể hiểu các ngôn ngữ lập trình như Python, Java, hoặc có thể đọc API và tài liệu dành cho developer. Bạn có thể mất khoảng 10 – 15 năm để đạt được level này.
- Mức lương của technical writer ở công ty outsource có thể thấp hơn so với lương ở công ty product.
Về bonus: Bạn có thể nhận được 100% tiền thưởng dự án nếu hoàn thành các yêu cầu như: năng suất, chất lượng, khả năng cộng tác nhóm và dựa trên hiệu quả hoạt động của công ty.
V. Tài liệu dành cho Technical Writer
Sách tham khảo dành cho Technical Writer:
- Sách ngữ pháp: Wren and martin
- Style guide: Manual of Style for Technical Publications (MSTP) của Microsoft
- Technical Communication 12th Edition của Mike Markel
- The Insider’s Guide to Technical Writing của Krista Van Laan
- Technical Writing Process: The simple, five-step guide that anyone can use to create technical documents such as user guides, manuals, and procedures của Kieran Morgan
- The Handbook of Technical Writing with 2020 APA Update 12th Edition của Gerald J. Alred, Walter E. Oliu & Charles T. Brusaw
Các khoá học dành cho Technical Writer
- Các khoá technical writing cơ bản
- Coding for writers: Basic programming
- Các khoá học về API và developer documentations
- Các khoá học về Kiến trúc thông tin (Information architecture) và Bản đồ thông tin (Information mapping)
Những Technical Writer nên theo dõi:
Keith Johnson, Sandhya Ranganathan, Anu Kothari, Anupama Honamore, Suraj Pratap.
VI. Kinh nghiệm thực tế của một Technical Writer
- Quyết định bước ngoặt trong sự nghiệp:
Amit bắt đầu với vị trí Technical Writer trong lĩnh vực Hàng không vũ trụ với sản phẩm là sổ tay hướng dẫn bảo dưỡng linh kiện máy bay. So với các công ty phần mềm, mức lương ở đây rất thấp. Trong suốt 6 năm, công việc không có nhiều thay đổi nên Amit muốn tìm kiếm điều gì đó mới mẻ hơn.
Sau đó, anh quyết định chuyển sang làm Technical Writer cho lĩnh vực phần mềm và nhận ra: Có một khoảng cách rất lớn giữa lương thưởng, sự cân bằng công việc – cuộc sống, con người và công nghệ ở đây. Sau quyết định bước ngoặt đó, Amit đã nhận được nhiều cơ hội nghề nghiệp tốt hơn.
- Khó khăn & áp lực của một Technical Writer là gì?
Với Amit, khó khăn lớn nhất của Technical Writer chủ yếu ở việc giao tiếp với các bên liên quan để đảm bảo tài liệu được review và phê duyệt đúng hạn.
Ví dụ, trong Agile, code có thể thay đổi phút chót. Khi đó, Technical Writer cần có thông tin từ Developer, nhưng “cái khó” là khi Dev mải viết code và không phản hồi ngay. Giải pháp của Amit là dành nhiều thời gian để “học” kỹ về sản phẩm. Nhờ đó, ngay cả khi Dev không phản hồi sớm, Technical Writer cũng có thể dự đoán và viết nháp, sau đó chỉ cần một cuộc gọi nhanh để “chốt” với Dev.
Ngoài ra, áp lực có thể nhiều hơn nếu bạn làm trong môi trường startup. Khi công ty không có ngân sách cho một team Technical Writer mạnh, team 4-5 người có thể phải làm công việc đáng lẽ cần tới 10 người.
Tuy vậy, làm Technical Writer sẽ không quá khó nếu bạn học hỏi nhanh, hiểu sản phẩm dễ dàng và sẵn sàng mày mò nghiên cứu. Đừng nghĩ Technical Writer chỉ cần ngồi chờ người khác cung cấp thông tin để viết, trên thực tế họ luôn phải là người chủ động.
- Sai lầm đáng nhớ nhất của một Technical Writer 9 năm:
Sai lầm để lại bài học sâu sắc nhất cho Amit xảy ra vào năm thứ 4 – 5 trong sự nghiệp, khi anh làm cho Automation Anywhere – một công ty làm về RPA với sản phẩm chatbot trả lời tự động.
Sản phẩm đang được phát triển nhưng thời gian phát hành tài liệu đang tới gần. Do đó, Amit đã tự viết 2-3 bước cài đặt dựa trên kinh nghiệm của mình và bỏ qua bước xác minh kỹ thuật. Các bước đó hiển hiên không chính xác nên người dùng không thể thực hiện việc cài đặt.
Bài học rút ra của Amit là “đừng bao giờ tin vào bản năng của bạn”. Luôn xem xét các thông số kỹ thuật của sản phẩm và thẩm định trước khi kết luận. Luôn dựa vào data và xác minh thông tin với SME cho đến khi mọi thứ rõ ràng, cũng như sẵn sàng thảo luận trước khi viết, xuất bản hoặc gửi tài liệu cho khách hàng. Nếu không sẽ xảy ra rủi ro khiến khách hàng mất tin tưởng vào doanh nghiệp của bạn.
- Lời khuyên cho các Technical Writer tương lai:
- Hiểu đối tượng mục tiêu của bạn là ai (rất quan trọng).
- Hiểu rõ mức độ “kỹ thuật” của tài liệu. Ví dụ: User guide hay Quick start guide không quá nặng tính “kỹ thuật”, mà chỉ cung cấp cái nhìn tổng quan về sản phẩm.
- Giữ tính nhất quán, luôn nâng cao kỹ năng chuyên môn và cập nhật các xu hướng mới trên thị trường.
- Luôn tuân thủ style guide của công ty, bằng cách xem lại các tài liệu kỹ thuật trước đó để xác định điểm chung về giọng điệu, ngôn ngữ và bản quyền. Nếu các tài liệu về sau khác hoàn toàn với tài liệu trước đó, khách hàng có thể sẽ bối rối không biết đó là tài liệu “chính chủ” hay đã được sao chép bất hợp pháp.
Thông tin về Amit Singh
Amit bắt đầu hành trình làm Technical Writer vào năm 2010 và gia nhập Wizeline vào năm 2021. Anh ấy yêu cách hoạt động của công ty, văn hóa và giá trị mang lại cho khách hàng thông qua các sản phẩm.
Trong sự nghiệp của mình, Amit đã làm việc trong nhiều lĩnh vực khác nhau như viễn thông, mạng, lưu trữ dữ liệu, truyền thông và giải trí, tự động hóa quy trình bằng robot và thương mại điện tử…và với nhiều loại tài liệu khác nhau như User guide, API guide, Blog,….
Xem thêm việc làm IT hấp dẫn tại Wizeline.