工作职能总结报告

千里之行,始于足下.不积跬步无以至千里,不积小流无以成江河.这一次,我仔细的梳理了我以往的工作与任务,在梳理中去思考,希望在此机会来提升自己.

我感觉一个敏捷开发的团队,最致命的要害就是混乱,针对需求合理的安排开发计划,业务逻辑的讨论,需求的变更的及时反馈,客户的对接,部门之间的对接,团队内部的氛围等等,每以个环节的偏差都会成为混乱的根源.

再者,开发技术的差距,代码质量的掌控和项目的热情也影响着产品的质量.

我希望我们能有自己的一套技术体系而且熟悉他,虽然我也一直在努力提升自己的水平.但是毕竟时间有限,越到后来越发现自己会的东西太少了,要学的东西又太多太多了

         现在,我在对刚才提出的问题细细的梳理一遍.

         需求的制定一开始是在少数人手中,而实际开发者却在这少数人中少之又少,甚至说只有我自己知道,这个时候制定的需求文档我会尽量的把细节展现出来.有时候”三人成虎”的事情也会难免发生,口头传递的东西也会记不清,更不要说实际开发中,容易混淆或者模糊的需求再一次确定而又来不及书面分析,所以为了解决这个事情,每次需求变更和再讨论,我都会尽量记录下来.树管家开始,每一个模块都是在所有开发者讨论之后再安排计划的.用纸牌法,即每个人对所有模块预估自己的时间,汇总除以人数,得到大家的平均开发时间,最后根据时间分摊模块.

         业务逻辑的复杂程度对开发成本的影响在CRM经手后,是感慨最深.首先,客户总是用自己专业的角度来衡量一个软件是否成功.这给开发人员明显带来了不小的困难.说白了,我们是门外汉,一个软件下来,所有开发人员都是半入行的水平了.有句笑话说,外包公司感三年,出来就变成一个社会百科全书.但是这件事目前我感觉是无法避免的.这也算是考验一个开发人员的学习能力了.但是这个东西还是影响着开发者对项目的热情,毋庸置疑.还有一点非常重要,因为门外汉的缘故,也会被客户牵着鼻子走.一开始需求文档的似是而非或者干脆不懂,业务很难实现,大大增加了开发成本和热情.最终导致的局面也会很尴尬.在一开始我也许会很耐心,本着学习的态度和客户交流,但是牵扯到项目的业务以及需求的变更也会变得很无力.

         至今我看的段子最多的就是关于程序员和产品经理.我感觉只要做一天开发,需求变更永远不能避免.但是应对这个问题,我还没有找到合适的方法.我感觉目前来讲,需求的变更对于客户,管理人员,开发人员都是很尴尬的问题.作为客户的直接对接人,我必须谨慎对待每个改动,想着怎么应对客户和开发人员,而客户可以凭他们的业务知识,或者别的方式,提需求,不要求成本的提需求,而开发人员肯定对需求变更是抵触的.我希望建立一套完善的需求体系,不管改需求也好,新需求也好,都能在各个角色里面坦然应对.目前,针对每个需求或者bug我都是建立一份文档记录

         现在讲客户对接,我认为是最消耗时间和精力的事.一个电话过来一个小时内做不了任何事情.而且处理客户关系上是非常消耗精力的.尤其是一边开发一边对接.这个时候最多的就是牵扯到需求的变更,这个时候我感觉更需要产品经理的角色来应对这个情况.客户对接影响着公司的形象和未来,应该是非常慎重的事情.

         着眼于项目的开发进度,我感觉部门之间的配合也是非常重要的.毕竟项目开发不是一个人的事情,部门之间的进度更是重要.接口和页面对接,直接影响我们的进度.

         团队的氛围这一点我可能还是年轻,但是我会努力改变自己,提升自己.

现在总结我的职能

1.       项目对接/分析/非配

2.       技术分享(偶尔会有)

3.       客户直接对接/需求的处理

4.       部门之间的对接:需求/接口/页面

5.       代码的开发

6.       Bug修改/维护

7.       服务器部署/管理

…

论语讲,君子务本.我希望在这次简单梳理后我能够更加正视自己的工作.从细节做好,尽量完善自己,提升自己.成长的路上不是一帆风树,与君共勉!

工作职能总结报告