员工转正述职报告大全

　　非常高兴成为公司的一名正式员工，试用期二月以来，我学到了很多，对于需求分析也有了更多的了解，最多的感想就是：需求表达!与业务人员、开发人员或者测试人员沟通都需要表达清楚自己的想法，写需求文档更加需要表达清楚需求意愿，表达不完整或者表达模糊不清都会导致需求错误，开发不准确，浪费开发时间。

　　写需求文档要很好地表达需求，首先要懂得向业务询问细节。比如，新增报表，除了基本需求，字段的来源?算法有哪些?更新频率是?默认加载的数据是?这些都需要问清楚，这样才可以把需求表达的更加到位，这里所讲的主要是提问的技巧，提问越细致需求表达就会更有东西可写，更好把握。(这时候沟通显得尤其重要，也是我的弱项)

　　写文档要非常明确。比如，更改页面时，路径表达细致：“PMS-采购管理-采购订单-全部订单”，这样开发一看就可以知道需要更改的页面是哪个。新增字段时，字段表达清晰：“供应商编码”在“采购员”之后，在查询条件和查询结果中均需显示，这样开发就知道新加的东西是加在什么地方。这是位置的明确，还有时间、频率等等这些明确，如更新时间是凌晨6：00、或者写18：00等具体时间，而不能写，上班前、下班后这些模糊的时间。写需求时，需要尽量不用模糊的用词，比如“定期”是什么概念，固定一周一次还是一月一次，还是用户可以自定义，或者是提供几个标准选项让用户自选?所有这些不明确的定义，都是需求分析过程中要重视的。总之，表达越明确精简，开发起来就越清楚。

　　写文档要条理清晰。以前，我写需求都是想到哪里，就写到哪里。这样，总是会发现漏了东西，越补越多，最后把自己也绕晕了。所以，写需求之前就需求要把要做的需求分模块、分功能、分类型列出来，之后想起来再往里面补充。即写需求之前把框架先理出来，在写需求。

　　挖掘潜在的需求。这里指的潜在需求，是我们平时将它默认，当做常识忽略的需求。比如，我们常常默认开发环境，以至于上线后换了环境导致出错，类似的还有浏览器。导出数据时应该为PDF格式，由于没有说明，开发导出的数据是E_cel格式。

　　表达的方式有多种，文档就考验需求人员的文字功底了，有时候一句话、一个字都需要反复推敲。要让业务和技术都看明白的确不容易，我认为应该多画图，一张图有时候能抵几千字。什么流程图啊、数据流图啊、组织结构图啊、用户界面示意图啊什么的，能画图的地方就多画图，图加上文字，理解就不容易跑偏。

　　接下来的日子，我更加需要多加学习，尽量提高我的表达能力，并做到通过自己独立思考，去解决一些问题或需求。