• 做项目管理的这些日子
  • 胡萝卜 发表于 2016/3/5 10:33:00 | 分类标签: 项目管理 程序员 架构设计
  • 之前一直是做游戏开发,虽说也算是项目负责人之一吧,但是基本只是负责后端架构和后段逻辑,只要做到两点,1:服务器可以承载一定用户量,2:逻辑没有问题就好了,剩下的诸如流程交互页面画风之类的,全部在自己的考虑范围内,对,还有进度,也不在考虑范围内,因为一般都是客户端是瓶颈,服务器不是瓶颈,甚至有点闲。

     来到新公司之后,既要负责技术,也要负责项目,前两三个月有点吃不消,也有点不适应;因为要统筹安排美工和程序协调开发,并且要保证业务逻辑流程的顺畅。难免要经历一个难产期,或者阵痛期。索性,索性,坚持过来了。

    说一说刚开始时候的不适应吧或者说刚开始时候做的不好的地方吧。

     首先说说写需求:

     1:首先是总是丢需求,这一点也是总监跟我说了n次的地方,可是仍旧是在这里犯了n-1次错误;拿最近这个商城来说,因为是基于微信,所以需求中要体现对微信的接口和约束;更要体现如果去管理微信公众号,这块确实是被我忽视了,的的确确的被忽视的,完完整整的丢掉了;而没有这块就无法接入微信,切记切记;后来在读一本书的时候,提到了约束,如果丢掉了约束,可能就会导致最终的产品进行大返工,切记切记。

     2: 需求不完整,一些活动的需求,无法形成闭环,或者说有疏漏的地方,这里确实要再文档成型之前,对每一个模块,每一个功能,每一个需求,每一个流程做一个头脑风暴;虽说无法避免疏漏的地方,但是一定要避免无法形成闭环,无法形成闭环,无法形成闭环,重要的事情说三遍,切记!

    说说整体架构这块:

     1:首先是一定要多视图;因为利益相关者不同,架构设计文档要给到程序,运维,老板,其他架构师等不同的角色看,所以架构设计要从不同的视图来体现,比如给程序的,要从模块划分,层次划分的角度来;给运维的,要从不同机器之前联系的角度来,等等,总之要多视图

     2:抛出难题,或者说风险控制,总之把风险全部抛出,分析那个风险最大,那个所需要考虑和投入设计的精力也就最多

     3:考虑扩展,考虑分布,考虑负载

     4:考虑客户端,这块一直是疏漏,总监也总是提醒我,要多关注些客户端,客户端不可太大,否则加载会很慢,考虑压缩,考虑框架的选取,以轻,稳,简为原则,这块的的确确是疏漏的
     
    我们再说说做计划:

     1:可能是对这种javaweb的项目不熟悉,所以最初也就是贾哥给了一个泛泛的计划节点,就是demo版本的deadline;现在熟悉了,切记切记,要做计划做计划,分解计划,做到周计划。

     2:根据开发进度调整计划,在实际的开发过程中,常常发现缺界面,丢逻辑之类的事情,虽说可以通过前期需求和设计避免,但是这样又需要在需求分析和概要设计上花费太久时间,所以需要补充的功能之后,要调整计划,调整计划,切记狂加班消耗开发热情。

     3:美工的计划要早于开发,工程师在开发任务的时候,切记切记,美工已经把界面给到,这样就需要保证美工的计划要早开发一个星期左右的时间,这样才能保证开发顺畅的进行。

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

  • 请您注意

    ·自觉遵守:爱国、守法、自律、真实、文明的原则

    ·尊重网上道德,遵守《全国人大常委会关于维护互联网安全的决定》及中华人民共和国其他各项有关法律法规

    ·严禁发表危害国家安全,破坏民族团结、国家宗教政策和社会稳定,含侮辱、诽谤、教唆、淫秽等内容的作品

    ·承担一切因您的行为而直接或间接导致的民事或刑事法律责任

    ·您在编程中国社区新闻评论发表的作品,本网站有权在网站内保留、转载、引用或者删除

    ·参与本评论即表明您已经阅读并接受上述条款

  • 感谢本文作者
  • 作者头像
  • 昵称:胡萝卜
  • 加入时间:2013/5/23 0:00:00
  • TA的签名
  • 这家伙很懒,虾米都没写
  • +进入TA的空间
  • 以下内容也很赞哦
分享按钮