转载自：http://www.shanghaitechwriter.com/2008/03/29/typical-day-as-a-technical-writer-at-ni-shanghai/

• Check for new emails. First thing in the morning, I check my mailbox for new messages. Most of the new messages are from our corporate office in Austin. We are 14 hours ahead of them, so while we went home the previous day, their day just started. They were busy resolving and addressing some of the issues we had in Shanghai.

• Fix and validate CARs. CARs, or corrective action requests, are software and documentation bugs that people have found and reported. Some are CARs that I need to fix while others are CARs I need to validate. I go through the CARs to see what the bugs/issues are and what I need to do.

• Attend documentation meeting. Meet with other technical writers to get status reports on everyone’s projects as well as receive any announcements and updates on department-wide and company-wide issues.

• Attend project meetings. Meet with the development team to find out project updates, changes and new features, to-do tasks, and issues to resolve.

• Meet with developers and content experts. If there are any changes or new features added to the product, I meet individually with the content experts to learn more about the changes.

• Play around with new features. I come back to my desk to explore the new features, how the changes affect the software as well as any documentation impact.

• Research online. I spend a good deal of time researching because the products I write about are highly technical and require basic engineering concepts and understanding, which I lack.

• Install, uninstall, and reinstall software application. Being a part of the software development process means we constantly have to reinstall the software to see the new changes.

• Troubleshooting.There’s always something that doesn’t work the way it’s suppose to. I spend a good amount of time figuring out what the problem is and reporting the issue/bug to the project owner.

• Provide feedback about software usability. Technical writers are the best “Beta users”and “guinea pigs” to experiment with new applications and products. I provide valuable feedback to developers on their product’s usability.

• Meet with lead writer/group manager. Once a week, I meet with my lead writer and manager to go over the status of my project, report any issues and difficulties I have, and receive suggestions/feedback about my work.

• Hold productivity forum meeting. Everyone shares tips, tricks, and anything useful to improve productivity at work.
• Eat lunch. Most of the time, I eat with my colleagues at the communal canteen for the whole office park. Sometimes we go out to nearby restaurants for group lunch. Occasionally, we order takeouts and deliveries.
• Check project schedule. I work on multiple projects with several deliverables (help files) simultaneously. It’s important to stay on top of the schedule for all the tasks and reviews that need to be accomplished in order to meet project deadline(s).
• Write new feature documentation (NFD). New features are documented separately and go through several rounds of review before being integrated into existing help.
• Go through tutorials to confirm accuracy. It’s important to go through the tutorials several times to make sure the content is logical, accurate, and that no steps or information are left out.
• Send NFDs or documentation for review. Every deliverable goes through several rounds of review before the final product is released.
• Report any bugs found in software or documentation. There are always bugs and errors found in software and documentation, whether my own projects or other people’s projects.
• Enter edits. After receiving feedback from reviewers, I need to enter all the edits. I might need to meet with content experts again to clarify a few details or missing information.
• Peer review other technical writer’s documentation. Every technical writer at NI has a peer reviewer and a lead reviewer. We help peer review each other’s documentation. Sometimes I need to learn other people’s products before I can review their documentation.
• Attend various training. There are several trainings throughout the week ranging from new products/features to leadership training to technical training. Sometimes I help out with English training for engineers.
• Visit the snack table. After working intensely, I take a break and grab something to eat from the snack table .
• Compile online help. Most of my deliverables are sourced in HTML or XML. I need to use various tools to compile all the project files including art and graphics into one help file.
• Use, modify, or give feedback about internal tools. LabVIEW, NI’s flagship product, is a graphical programming language. We’ve created several in-house tools using LabVIEW to accomplish and simplify many documentation-related tasks. Sometimes these tools break or don’t work well. I provide feedback and suggestions for improving the tools as well as create/modify the tools for my own use.
• Add new topics to our internal documentation. All the technical writers at NI contribute to our internal help system, which explains various procedures and instructions related to our daily tasks. Basically, it’s our manual for writing manuals! Yes, we’re pretty geeky like that.
• Review miscellaneous documents. Occasionally, I receive requests to review various documents, presentations, and articles written by developers and other departments.
• Write documentation plan. When I start a new project, the first thing I need to do is to write a documentation plan. This includes all the necessary information we need to know (product, industry, audience, users, type of documentation, risks, time frame, deadlines, etc…) before we start writing the documentation.
• Plan parties and events. I’m the social dictator for the technical communications group, so I plan all the social activities such as group lunch, outings, quarterly parties, and fun team-building activities.
• Attend deck parties. Every few weeks, the entire R&D team goes up to the roof of our building for some beer, snacks, and socializing.

Wow! Now that I’ve written all this down, it looks like I do a lot of things, but not all in one day. This is more like a typical day / week / month as a technical writer.

Technical writing, despite people’s misconception, is not just about writing manuals and help files. Writing is part of the job but not all of it. As you can see from my typical day at work, I’m involved with many aspects of the software or product development. Technical writers provide a lot of valuable feedback to a product’s usability. We also perform a lot of tasks that require more than just good writing/communication skills. Interest in technology, ability to multi-task, ability to learn a lot of material in a short amount of time, critical and problem-solving skills, excellent research skills, attention to details, good communication skills . . . these are all skill sets that are required of a technical writer.

反对： 白俄罗斯、 玻利维亚、 中国、 古巴、 民主人民共和国韩国、 厄瓜多尔、 尼加拉瓜、 俄罗斯联邦、 叙利亚、 伊朗、 委内瑞拉、 津巴布韦。

Why China is so lonely?  Do most people support the stance of China government?

The followings are part of the text adopted by the general assembly : 

Strongly condemning continued widespread and systematic human rights violations by the Syrian authorities, the General Assembly  voted overwhelmingly to call on both the Government and allied forces and armed groups “to stop all violence or reprisals immediately”.

The technical writing process consists of four phases:

1. planning
2. writing
3. delivery
4. archiving

The Planning Phase

1.      gather existing information --- any or all of:

·        requirement specifications

·        functional descriptions

·        use cases

·        standards

·        contracts

·        etc.

2.      determine which documents and other information you will create:

·        product descriptions

·        installation guides

·        configuration guides

·        system administration guides

·        alarm-clearing procedures

·        error message

·        etc.

3.      if the documentation is to include tooltips, error messages, notifications, and dialog boxes, develop a plan to ensure that the wording of these is consistent, clear, and grammatical. Contact system architect to work out the details of your plan.

4.      determine how the documentation will be delivered to the customer

5.      when creating online help, it is essential to plan how users will navigate through the help topics before you start writing.

6.      determine which desktop publishing software and help-authoring too you will use. Order as required.

7.      work out the file structure and file-naming conventions for the documentation and online help.

8.      for online help, work out the relationships among the different files. Will some help files be used for more than one GUI screen?

9.      create your templates.

The Writing Phase

1.      write your documents and make a list of glossary terms as you write

2.      during slow periods, research glossary terms using more than one source.

3.      during slow periods, research the correct wording for copyright notices of any third-party and proprietary products that you mention in your documentation.

4.      when the documentation is complete, do a spell-check and review your work from cover to cover.

5.      send the documentation to the subject-matter expert (SME) for a technical accuracy check.

6.      make the required corrections.

7.      send the corrections back to the SME for verification.

The Delivery Phase

for documentation that is integrated with the application, talk to the system architect to work out the final details of integrating the documentation.

The Archiving Phase

1.      name your documentation folder on the network with the product name and version number. If you will be updating the documentation in future versions, create a new folder with the new version name and copy all the documents there.

2.      if your company has a document archiving system, use it.

you are done!

I didn’t get on a plane until I was 21. I’d grown up in a small town in the west of Ireland with the unfortunate moniker ‘Slash City’. Not the most exotic place in the world. So, when I did start to travel, I moved a lot.

The reason I could do this was mostly due to the mobile nature of technical writing and the opportunities gave me to travel. For most of my twenties I went from one contract to the next. London, Glasgow, Amsterdam, Berlin, San Francisco, Sacramento, New York… and then Taiwan. Well almost…

What brought you to China?

In the 90s, Taiwan was hot. Hard to believe today but it had tons of technical writing work back then. And still does but to a lesser extent. So I decided to go… but changed plans and went to Beijing instead with some friends. It just seemed more ‘exotic’ and in the 90s was still not as explored as today. Since moving there, I’ve worked in Shanghai, Hong Kong and Beijing.

Is the IT industry in China growing rapidly?

It’s exploding especially in the area of mobile devices, ecommerce (now that credit cards are available) and gaming. Chinese love gaming.

It is also driven by a new middle class who have the funds to make high-end purchases, e.g. diamond-encrusted mobile phones, and other status symbols. China is very brand conscious, which partly explains the demand for fake items.

One of the misconceptions about China is that it’s a communist country. In reality, there is a very strong class structure and as Deng said, ‘to be rich is glorious.’

Most of the IT development is located in:

• Shanghai which has a financial hub and is home to Sohu.com and Sina.com. Both listed in the NYSE.
• Dalian where Intel has created the largest ‘fab’ for creating semi-conductors and others devices.
• ShenZhen where RenRen (Chinese Facebook) and QQ (huge gaming sites) have their operations.

Shanghai also has satellite towns dedicated to outsourcing with very modern infrastructures.

Beijing is the admin centre like Washington, DC in the US.

What cultural traits work for and against the Chinese technical writer?

You can look at it from different angles:

• Language: University graduates with English degrees would be far behind their counterparts in Europe and India. So, quality suffers from this perspective.
• Communication: Chinese students are brought up to listen and follow, so having a ‘discussion’ can become difficult as they may withhold opinions rather than share as it’s not seen to be appropriate. It’s the opposite of western kids who’ll sprout all type of nonsense, simply to have an opinion.
• Leadership: One downside is that it can be difficult to gauge the true status of a project as project managers may, for example, work over the weekend (with the team) rather than admit they’re behind schedule. The ‘listen and follow’ mentality can also disallow underlings from voicing their opinions, i.e. so the team lead doesn’t lose face.
• Innovation: one of the surprises when I moved there was that most everyone could build their own PC. They were disappointed I couldn’t. This stems from having to make do with less, so most have learnt how to find shortcuts and workarounds.

How do Chinese technical writers get training?

Some are English graduates who move into Technical Writing. I don’t know if any universities on the mainland teach tech comms modules. I could be wrong. Most learn from:

• Overseas Technical Writers – brought in to build a team and create writing and publishing guidelines. There are some lucrative opportunities for Technical Writers who can lead up these projects and provide the framework for Chinese Technical Writer, especially for US firms who’ve partnered with local IT firms.

• Online university courses – while not ideal, these courses give them guidelines on what’s required and where they can improve.

Is there a particular style guide writers follow in China?

Not that I’m aware of, though I’ve seen many copies of the Microsoft Style Guide For Technical Publications in different offices.

Is outsourcing a trend that you see growing or increasing in China?

Manufacturing has taken a hit recently due to increases in salaries and currency exchange rates. Also, countries like Vietnam are positioning themselves as better value, i.e. low cost, alternatives to China.

From an IT perspective, Shenzhen and Shanghai are leading the field.

BusinessWeek believe Shanghai is the No. 2 city for outsourcing specialties, such as business analytics, finance and accounting, product development, research and development, and testing. Service Providers include Accenture, Cognizant, HP, Infosys, Wipro, and Unisys. (See Top Emerging Outsourcing Cities.)

Likewise, ‘…the offshore service outsourcing business that Shenzhen enterprises undertake has exceeded 5 billion U.S. dollars for the first time; the contract value has amounted to a record of 5.08 billion U.S. dollars, which ranks No.1 in the country… other services outsourcing enterprises such as IBM, Evans, Da Zhan, Peng Kai, Freeborders, and CS&S are accelerating the expansion of business in Shenzhen’ (Shenzhen Becomes China’s Largest IT Service Outsourcing Base).

What cultural obstacles do you struggle with in working with the Chinese in a tech comm setting?

The perceived value of Technical Writing is very low in China.

What this means is that most local firms will not invest in Technical Writers and use developers instead. Or get a graduate with an English degree to write the guides but the end result is less than satisfactory.

Another factor is that in Asia it’s not uncommon for technical documents to be more focused on diagrams, i.e. images rather than text.

In Japan, I saw some wonderful documents — like the Google Chrome User Guide — that were mostly illustrations and helped you see what needed to be done more quickly. So, there may be cultural issues here as well.

Cost is also an issue.

Most Chinese IT firms are very spartan and cost-conscious, looking for ways to reduce costs at all times. So, paying for tech docs can be hard to justify with local firms.

Personally, I worked mostly with US firms that were short of trained writers on the ground or (occasionally) did bespoke consultancy for a few Chinese firms, but that was mostly to return favors rather than for financial reasons.

How long do you plan to stay in China?

We moved back recently so junior can go to high school in Ireland. He learned to read and write mandarin while we there, so it’s time for a different adventure now.

My suggestion to any Technical Writers thinking of going there is to link up with US firms, e.g. Intel, Microsoft, and IBM, and try to get a contract. Stay in the larger cities as you’ll be able to get creature comforts that ease the transition and also find it easier to navigate.

An alternative is to contact Chinese firms that have floated on the Nasdaq/NYSE and see if they need writers in their local offices. Sina and Sohu are two of the most prestigious – both based in Shanghai.

Finally, before you move… visit for a few weeks especially off-season and see if you like the vibe. It’s a great place but you have to take it on it’s own terms.

鹅、鹅、鹅，曲项向天歌。

白毛浮绿水，红掌拨清波。

悯农  李绅
锄禾日当午，汗滴禾下土。

谁念盘中餐，粒粒皆辛苦。

静夜思 李白
床前明月光，疑是地上霜。

举头望明月，低头思故乡。

相思 王维
红豆生南国,春来发几枝?

愿君多采撷,此物最相思

《草》白居易
离离原上草，一岁一枯荣。
野火烧不尽，春风吹又生。

改变以往的时间观念，将周五晚上设定为周末休闲生活的起跑时间，周六则是活动时间，周日是身心放松时间，周日晚餐后则是下周工作的起跑时间，这样的安排，将会明显消除周一忧郁症。

从星期天开始，上班族就会感觉呼吸越来越沉重，第二天常常带着忧郁的表情去公司上班。

忧郁的星期一是上班族的天敌。

如何才能带着轻松愉快的心情有效克服掉周一综合症呢？

日前，我从日本人大前研一那里偷学一招，供大学借鉴使用。

他认为，最重要的方法就是做好周末的时间分配工作。也就是说，我们需要提前对周末生活做计划。

一定要从周五晚上就开始周末的休闲活动：

周五下班后，八点左右最好就能到家。千万别抱着轻松而无计划的快乐心情，无节制的看电视，在周五晚间把自己搞得很疲惫，以至于周六上午昏昏欲睡。这样的话，会让周六的宝贵时间白白浪费掉。

周五回家后，可以带着轻松的心情，好好收拾一周以来搁置的家务，好好和家人在一起吃一顿晚饭，有节制的看一段电视节目或看一部电影。

星期六，享受体力型的休闲活动；星期天，让身心充分休息。

容易让身心疲惫的活动，比如爬山、近郊旅游、逛街、尽量安排在星期六。而将享受美食、理发、美甲、按摩、和家人在家附近溜达等放松型的休闲活动，都尽可能放在星期天。

星期天的晚餐后，开始为周一的工作做准备。

吃完星期天的晚餐，洗完澡之后，就到了周日的晚上。

到了这个时间，人们都会想到周一的工作，但是心里还是继续想着：“现在是周末，所以。。。。”，也试着看电视或看书，但总是无法集中精力。实际上，星期天的晚餐之后，很难轻松享受休闲生活，而是自然地想起工作上的事情。这是上班族普遍的现象。

既然如此，我们不如吧周日晚餐作为周末休闲生活的结束标志。以此为划分点，开始为明天的工作做准备。

当然，这段时间内，最有效的工作就是确认未来的时间安排，例如未来一周，甚至一个月的工作计划安排。

如此一来，有了确定的计划和充分的休息，周一一早，工作将会明确而又顺利，效率也会极大提高。周一综合症自然被消除了。