项目管理--01定义及流程

                                                                      作为leader一定要跳出coder的思维

                                                                                                                                  上面这句话要铁记啊！！！尤其是刚转岗PM。
          码而优则仕，从coder到team leader要完成这一转变需要付出很大的代价，这一代价主要体现在没有系统的学习项目管理，可能大部分是懵乎乎的就开始做管理了，做着自以为很系统，科学的管理，在各种坑里翻滚。我很不幸有一个严苛老师教，诸君很幸运，我将把自己的转变从零开始记录分享给各位。
          先看定义：项目管理就是指组织一定的资源来完成一定的任务的管理过程。既资源一定，任务一定。后续的讨论都会围绕着这个主题进行讨论。
        根据以上两个一定，来看项目从一开始的计划提出，到上线运行，我们都要做哪些事情？有哪些环节？各个环节的产物及其作用是什么？怎样有效规避客观BUG和主观BUG。从而高效的带领团队完成任务。
        先看项目实施过程：
1、项目计划；
2、需求调研&方案；
3、需求评审；
4、基本设计；
5、需求评审；
6、详细设计；
7、单元测试书；
8、共通；
9、代码；
10、CI评审；
11、测试脚本；
12、单元测试；
13、集成测试；
14、内部确认；
15、UAT测试；
16、系统上线。
        很长的一个流程，起码在日企里项目开发是一个很细致的内容，我们的邻邦同行会花费大部分时间在系统设计上，而且是甲方乙方共同参与的设计评审，之后才是开发。

    从这里可以看出，在整个项目开发流程当中代码只是占用了很小的一部分。
    所谓行必果，做了事情就要有成果对工作进行固化，也是为下一步工作填充垫脚石。那么首先就要知道面对开发流程的每个环节，我们应当取得怎么样的成果：

这张表格里提到了几个文档：

我不知道这篇文章会有多少人看到，也不知道看到的这些人是不是需要这些文件范例，何况还有版权问题，所以这里先不贴出来了，有想要的请给我留言吧。

核心用户：又称Key User 关键用户；通俗一点讲，甲方谁来提出需求，谁就是核心用户。其他人甚至是甲方老板都不在;列，核心用户一般在项目启动会议的时候进行指定。
评审：评审的目的是减少项目Miss，有自审和他审。一般项目计划、需求方案由客户评审，基本设计由技术人员评审，代
    码评审建议由TL评审（原因么，就是TL技术水准在那里的有信服力，不建议同级别代码人员之间做评审，尤其是两个杠精之间）；
内部确认：内部确认的范畴有：
    1、确认测试阶段脚本；
    2、确认测试结果；
    3、确认确认脚本覆盖这个业务；
    4、确认所有bug是否全部解决；
    5、确认遗留问题是否达成一致意见；
内部确认的作用相当于工厂里质检，所有的从公司出去的产品都要经得起质检的检测，否则就是垃圾程序。
版本管理： 包含需求变更、代码变更；需求变更在UAT阶段尤为明显。代码的版本建议以一个模块为一个版本。
    版本管理的根本目的是减少混乱，节约开发成本。
    手段：
  业务版本管理：
    1、变更台账；
    2、需求变更记录；
  代码版本管理：
    1、定期备份；现在大部分公司使用git进行vcs，所以建议定期进行代码合并。因为在代码变化较大时候进行合并最容易造成冲突而且解决起来很是消耗精力
    2、代码注释；在代码注释模板中增加@Version项
    3、Version Log；
共通管理： 所谓共通是指在系统应用开发过程中相同或相似的机能被多次使用到，所以做成共通。供其他coder调用，以节约开发成本，其实这样想来，广义一点讲权限机能就是共通的。 在项目准备期（需求理解）由TL进行业务梳理，把共性较高的机能抽取出来。
本篇完