做项目负责人的总结

JannieConne 8年前

来自: http://www.cnblogs.com/archy_yu/p/5243947.html

之前一直是做游戏开发,虽说也算是项目负责人之一吧,但是基本只是负责后端架构和后段逻辑,只要做到两点,1:服务器可以承载一定用户量,2:逻辑没有问题就好了,剩下的诸如流程交互页面画风之类的,全部在自己的考虑范围内,对,还有进度,也不在考虑范围内,因为一般都是客户端是瓶颈,服务器不是瓶颈,甚至有点闲。
来到新公司之后,既要负责技术,也要负责项目,前两三个月有点吃不消,也有点不适应;因为要统筹安排美工和程序协调开发,并且要保证业务逻辑流程的顺畅。难免要经历一个难产期,或者阵痛期。索性,索性,坚持过来了。


说一说刚开始时候的不适应吧或者说刚开始时候做的不好的地方吧。
首先说说写需求:
1:首先是总是丢需求,这一点也是总监跟我说了n次的地方,可是仍旧是在这里犯了n-1次错误;拿最近这个商城来说,因为是基于微信,所以需求中要体现对微信的接口和约束;更要体现如果去管理微信公众号,这块确实是被我忽视了,的的确确的被忽视的,完完整整的丢掉了;而没有这块就无法接入微信,切记切记;后来在读一本书的时候,提到了约束,如果丢掉了约束,可能就会导致最终的产品进行大返工,切记切记。
2: 需求不完整,一些活动的需求,无法形成闭环,或者说有疏漏的地方,这里确实要再文档成型之前,对每一个模块,每一个功能,每一个需求,每一个流程做一个头脑风暴;虽说无法避免疏漏的地方,但是一定要避免无法形成闭环,无法形成闭环,无法形成闭环,重要的事情说三遍,切记!


说说整体架构这块:
1:首先是一定要多视图;因为利益相关者不同,架构设计文档要给到程序,运维,老板,其他架构师等不同的角色看,所以架构设计要从不同的视图来体现,比如给程序的,要从模块划分,层次划分的角度来;给运维的,要从不同机器之前联系的角度来,等等,总之要多视图
2:抛出难题,或者说风险控制,总之把风险全部抛出,分析那个风险最大,那个所需要考虑和投入设计的精力也就最多
3:考虑扩展,考虑分布,考虑负载
4:考虑客户端,这块一直是疏漏,总监也总是提醒我,要多关注些客户端,客户端不可太大,否则加载会很慢,考虑压缩,考虑框架的选取,以轻,稳,简为原则,这块的的确确是疏漏的


我们再说说做计划:
1:可能是对这种javaweb的项目不熟悉,所以最初也就是贾哥给了一个泛泛的计划节点,就是demo版本的deadline;现在熟悉了,切记切记,要做计划做计划,分解计划,做到周计划。
2:根据开发进度调整计划,在实际的开发过程中,常常发现缺界面,丢逻辑之类的事情,虽说可以通过前期需求和设计避免,但是这样又需要在需求分析和概要设计上花费太久时间,所以需要补充的功能之后,要调整计划,调整计划,切记狂加班消耗开发热情。
3:美工的计划要早于开发,工程师在开发任务的时候,切记切记,美工已经把界面给到,这样就需要保证美工的计划要早开发一个星期左右的时间,这样才能保证开发顺畅的进行。


年前写的文章,写了之后一直不肯发布,是因为觉得错误犯的有点低级。年后虽说旧项目还在维护,也同时开启了新项目,现在再做需求基本能做到完整完善,并且使用面向对象的方式,做设计也能考虑的比较全面了。就不必藏着掖着,就把这篇文章发布好了。