写产品文档的几点注意.docVIP

写产品文档的几点注意 1）文档一般由word工具编写。 2）文档的声明。包括文档的标题，一级标题，文档简介，文档出处，文档时间，文档版本等。排版合理即可，没有字体大小的硬性规定。应该位于文档的最前面，占一页。 3）文档的目录。不论文档长短与否，必须要有目录。 4）在文档中必须要有清晰的章节安排。多使用一级标题，二级标题等。 5）页码必须要有 6）关键字可以使用不同颜色标出。但颜色不可使用过多，推荐正文黑色，关键字使用红色。醒目标注也不可过多，容易让人眼花。 7）要有批注。 8）需要效果实现的地方一定要配图。 9）一定多使用表格。 10）比较大的图和一些资源不要直接引入文档，应作为附件。 11）附件在最后注明。并且需附上联系人。 12）如有补充说明，应在页尾申明。 12）应将所有文档文件打包压缩。 附另一文章 需求文档注定是给所有人看的，它就是产品的定义。 文档围观的人包括：你的老板（如果产品够大，还会需要老板的老板），设计师，工程师，测试工程师。有时还应该包括产品前端：如运营，销售，甚至市场部同事。 在通过各方的评审和签字后，一般来说，这个文档就是一锤定音的事。若有更改，就是需求变更了。 所以，在需求文档撰写前和撰写中，对产品方向和用户的把握要足够强，从产品目的，到每个链接的含义，都需要准确地定义。基本上，当你开始写文档时，应该万事俱备。一边想一边写，那说明你还没有想明白这个产品是怎么回事。 在有些公司，需求文档会包括产品的最终设计界面。即在文档提交给大家围观前，产品界面已经确定完毕。 ---------------------------------------------------------------------------------------------- 需求文档写作的一些建议 格式无所谓。用WORD的多，HTML，在线文档都成，我还见过PPT写的！ 产品定义部分一定要详细描述。按功能模块写，跨功能的定义用流程和关系来描述。多站在用户的角度上，去定义用户任务，用户流程，页面逻辑关系等。 使用准确的用语，注意边界情况。比如，一个文本框最多输入多少个字符？是阿拉伯数字还是皆可？超过字数会怎么样？ 多画图。把原型包括进去，或者把产品界面包括进去，不然就画出来。否则除了你，没多少看得懂。 一个需求文档，一些通用部分是必须要包括进去的，我总结了一个示例。 当然， 很多时候有可能是创业公司，或是小版本快速上线，要求会宽泛得多得多。 比如现比较推崇的Agile敏捷开发，会更强短平快，削弱文档的沟通而加强团队的直接交流，简化流程，快速反馈，快速迭代等等。这种情况下，需求文档会极大简化，咱就不在这探讨了。 ---------------------------------------------------------------------------------------------- 文档信息，版本记录，责任人等 项目背景，产品目的 文档约定（采用的标准，通用名词等） 可行性分析 前期调研 产品预期 对其他产品的影响 产品定义功能详述（文档主体部分） 功能模块 用例 用户流程 数据需求 业务规则流程 产品非功能需求 对性能的需求 安全性需求等 产品风险或潜在问题 篇二： 部门及员工绩效考评制度 部门及员工绩效考评管理制度 为规范公司对部门和员工的绩效考评制定本制度。 1.目的 通过对部门和员工日常工作和行为规范的考核、考评，建立公司绩效考评管理系统，促进个人工作素养和整体工作效率的不断提高，防止和纠正部门和员工渎职、失职、违纪、违规行为，保证公司绩效目标管理的达成。 2.适用范围 适用于公司内部对部门和员工的各级考评、各类行为规范的考核的管理。 3.职责和权限 3.1总经理或其授权人或公司主管领导对总经理办公室和人力资源部有考评权和考核权，负责对各类考评、考核结果的最终认定。 3.2公司成立由总经理或其授权人、主管领导、总经理办公室和人力资源部等职能部门组成的考核小组，考核小组对各部门有考评权和考核权。 3.3各部门和生产单位负责人对本单位的员工进行管理,行使考评权和考核权。 3.3人力资源部负责归口公司考评和考核结果，并将结果与绩效工资挂钩。 3.4员工和部门对同级和上级单位有考评和考核的建议权。 4.绩效考评管理程序和考核管理办法及考核实施细则 4.1绩效考评、考核管理程序 4.1.1员工每月26日向部门负责人汇报或提交工作总结，作为月度考核的依据。 4.1.2部门负责人根据员工的工作总结、工作表现和工作目标