序
近日老板吩咐写一份码云操作手册。前前后后，兜兜转转，反复沟通，写了三版稿子，才符合老板的要求。
以前没写过操作手册，文档也写得不多，只有实施部署文档写得多一点。写实施部署文档，大多是在自身已经掌握软件的部署方法的情况下，记录综合软件实施部署的过程。所以写作起来，整体感觉很流畅，能较快捷的写完。
而这次写码云操作手册的情形是：码云没有用过，Git也仅了解过一点。所谓“Gitee操作手册”，该怎么写？写什么内容？完全不得要领。
如今手册已顺利交差，遂也总结一番，到底该如何写操作手册。
走过的歪路
第一版稿子，完全是Git的指令介绍。介绍诸如git clone指令怎么用，git commit怎么提交，提交后怎么解决合并冲突等等。
当时为什么会这样写？我想着的是，Gitee操作手册应该告诉阅读者，如何使用码云结合Git管理代码。所以操作者应该熟知Git操作。于是第一版稿子的内容即为Git的指令介绍了。
第一版稿子被老板打了回来，老板表示该版不是操作手册，而我应该也对码云还不甚了解，应当先自己使用一番。体验一下如何使用码云构建企业项目，并进行管理。再行编制操作手册。
第二版稿子动手之前，注册了码云企业版，结合码云官方帮助手册依样画葫芦。结果写操作手册时，极大的受到了码云帮助手册的影响。码云帮助手册的特点是大而全，详细介绍了各种操作，如何操作，从账户注册到企业版本升级维护，第三方服务集成等等等等。而我的第二版手册，等于是从码云帮助手册中，挑选除了企业版的操作介绍部分，结合一些自己感觉其他部分的也比较紧要的内容。结果，也被老板打了回来。
老板的意见是，角色不清晰，作为阅读者看完之后完全不知道该怎么办。你的操作手册应当告诉我，如果我是一个码云开发者，我应当如何开发我的项目，如果我是一位管理员，应该如何管理我的项目。
如何写操作手册
至第二版稿子完成之时，我应当算是对码云有了一定的了解。两版手册都作废的原因，我也思考了一番。结合老板的意见，所谓“Gitee操作手册”，到底该怎么写？到底该写什么内容？终于感觉拨开了云雾。
至少老板想要的操作手册是这样的。管理者读了手册，能一步一步的建立起码云账户、企业项目管理企业成员。项目参与者读了手册，能知道自己如何一步一步加入道码云，根据码云任务系统，编码、提交等。
总结
一份操作手册如何去写，不是要求大而全，不要不知所云，而要让某个特定的角色能迅速找到自己想要的达到某种目的的操作方法步骤。所以文档包含的内容、结构的编排都应该为这一点服务。而在这之前，写作者也应代入角色亲自体验一番如何操作。
