软件开发项目管理经验总结

软件开发项目管理经验总结

姜友瑶 2019-04-16 

          这是我从事软件外包工作以来的项目管理经验的总结，编写文章的目的是为了回顾和总结自己的一些想法，如果其中有不足的地方大家可以一起讨论交流。

项目经理的职责

     关于项目经理的工作职责有很多种说法，我自己是这样理解的作为一名项目经理第一目标就是

合理利用公司资源组织设计、开发、测试等各种资源完成项目的高质量交付，并保证项目的盈利。

这是衡量一个项目失败或者成功的唯一指标，当然有些项目是有战略意义的一开始就没打算盈利这样的项目就不能单纯的用成本来计算了。

   这里有几个小点我想说明一下，1、合理利用公司资源，无论公司大小资源总是有限的，公司不可能把所有的好的资源优质的资源都放到自己的项目组中，总是高高低低的人凑在一起，作为项目经理要能在资源和事情的总量，难度之间找到一个匹配的值。项目拿到手上，我们最少几个人能把这个事情做好要判断清楚。人多了浪费了成本，人少了事情做不完。

2、利用各种资源，有些资源是需要自己去争取的，当我们发现项目出了问题，但是公司给的资源又不足的时候，项目经理就要想方设法的去获取这些资源，而不是坐等公司来给我们解决问题，很多人都看过一个电视叫《亮剑》主角是李云龙，他就是一个很会自己找资源的人，当时的中央是给不了他们什么装备的，但是鬼子又要打怎么办？自己去鬼子哪里抢，去总部死皮赖脸要。正是因为他这样想尽办法为自己找资源，最后他那个团是富得流油的，打仗更是所向披靡。我们带项目也是这样，资源不够的时候要自己去找，只要你为了项目好总会从公司甚至是客户那里拉到支持。

3、高质量，盈利。一个项目盈利是一个方面，但是质量确实一个更长远的方面，项目过于赶工，降低要求最后伤害了客户也伤害自己，所以项目的质量和盈利必须要兼顾，要找到一个客户能够接受的质量区间，但是不建议过于苛求，因为没有bug的软件是不存在的。

   虽然站在公司的角度项目是否盈利是重要的指标，但是在我看来项目经理也有其他的一些重要的责任，作为项目经理上要对得起公司下要对得起跟着自己做事情的兄弟，所以 “让跟着自己做事情的人得到成长和锻炼” 也是项目经理的责任。也只有让和自己做事情的兄弟们觉得有收获别人才会愿意跟着你干，团队才会有执行力。当然如何让自己的团队觉得有收获也是有很多技巧的。比如给与团队成员技术指导，合理的安培开发计划在每一个迭代完成后给大家总结，及时给与激励等。后面我们的具体工作方法中都有体现。

  

 

项目经理应该具备的基本技能

具有2~3个以上的项目经验

熟悉JavaEE技术体系

熟悉敏捷开发流程

具有与客户沟通需求的能力

逻辑思维清晰能够理解复杂的业务需求并

具有管理团队的能力或者潜力

具有设计较复杂系统的能力

具有成本意识，交付意识理解外包项目的盈利模式

具有较强的抗压能力

具有责任心能够担当在所有人后退的时候要能迎难而上

学会利用各种有利资源帮助自己完成项目

开发团队组建

开发团队不能全部是新人，新人对公司框架以及开发模式不熟悉组织效率较低
开发团队必须有一人可以全身心投入在项目中，而且这个人知道整个项目的需求，这个人可以是项目经理也可以是项目的主要程序员
团队要及时沟通，如果发现团队中的成员不爱沟通项目经理要在早会中提出来，告知沟通的重要性，并且通过组织团建，或者茶话会给大家交流的时间，吐槽多了自然也会爱沟通一些
项目经理不但要管理团队的开发，而且要管理团队成员的心态，要保持团队成员每一个人都是积极主动的，不合适的人及时淘汰，留在团队中只会写bug给团队带来技术债务拖慢整个团队进度。木桶效应，效率最低的人会影响团队的进度。
团队的执行力一定要强，项目经理一定要反反复复的督促开发测试不厌其烦的跟进他们的进度，任何拖延的人都是对项目极大的威胁，如果项目经理视而不见，对细节问题置之不理，其最后的结果就是做了一个豆腐渣工程，这样的案例我们已经经历了太多，务必重视
特别留意团队中开发习惯不好的人
比如有的人喜欢写死id或者用户方便自己调试，但是写完代码只有又不删除，导致后期排查问题时间拖长，看似小问题实际是工作方式不对。遇到这种情况项目经理坚决对其进行罚款。把坏习惯扼杀在摇篮中。
如果团队中存在人员缺口或者人员不合适的及时和主管反馈进行调整
项目需求管理

和客户组建需求讨论群，拉上测试、主程、商务、老板以及相关的人员
讨论需求一定要带上测试，确保测试对需求和项目经理是一样清楚的
不明确的或者模糊的需求讨论完后如果对方是企业客户一定要发邮件和对方确，如是个人客户就需要用微信和对方确认确认的聊天记录截图发在钉钉群里留存。
微信确认话术模板：
   xx总，您好，经过今天的需求讨论我们确认xx功能的需求，功能是这样的 xxxxxx 您看是对的吗？
邮件确认话术模板：
   尊敬的XX您好，
      经过今天的需求讨论我们确认xx功能的需求，功能是这样的 xxxxxx ，如果没有疑问我们就按照这样设计开发了？如果有补充请在2个工作日内回复我们谢谢。
祝好！
       XX公司   项目经理：XXX
                                               2019-01-06
 
如果客户提出新的需求，首先要判断这个需求是否是报价单中涵盖的，情况一、如果是报价单中需求的补充则接受，并补充到需求文档中。
情况二、如果不是需求文档中涵盖的，就要区分这个需求如果不做会不会影响客户的主流程，如果会就要看付出的代价有多大，原则上累计需求变动在3个工作日（包括测试代价）我们是可以答应客户的。但是也要告知客户我们是要付出很多成本才能完成你这个新增的需求。如果不做也不会影响客户系统的流程，那么就要尽量的推掉。
如果既是影响主流程又是超过3天工作日的就要联系商务和客户进行报价洽谈，并告知客户因为做了这个功能会导致项目后延，看对方能不能接受。原则上项目的改动最好能推到验收付款后去完善。
如果需求出现大的变化，项目经理无法把控的一定要上报，但是也别一点点事情就上报，能自己处理的自己处理。上级往往对具体需求也不是很清楚
项目要求按照项目需求标准模板编写，如果项目比较简单那么就在原型上标注说明，但是也要有主流程的说明文档，以及分支流程的说明文档，而且原型标注要足够详细
安排UI进行设计，UI图要上传到Mockplus中并添加跳转点击，psd图传到蓝湖，方便前端人员查看尺寸
在需求梳理阶段要注意一个问题，对方是否具有成熟的需求思考，以及思路，如果有成熟的需求那我们只要理解就好，如果对方需求比较模糊那么就要求我们来做引导，既要让需求满足客户的使用场景又要保证我们能够在规定的时间开发出来，而且设计一定要合理。产品经理对业务设计不合理会导致需求变动多。
不要漏掉任何需求不明确的地方，因为需求不明确会导致后期的需求膨胀，而且会导致程序员不知道怎么开发，转而按照自己的思路胡乱猜测，从而写出很多bug。
项目资料管理

共享目录

项目启动时在共享文件中创建项目目录，并告知相关的开发人员，共享目录中包含项目的所有文档，包括需求说明书、原型设计、UI设计、测试用例、等等。所有需要用到的资料都应该放在共享目录中

 

敏捷开发流程管理

 

制定开发计划，研发计划每周一，周三更新一次，更新后发在群里通知所有人，公司会从项目经理的开发计划是否及时更新以及计划是否落实到位来考核项目经理的工作
项目启动会议   组织商务，测试，开发以及一位技术主管到场进行项目需求评审。 项目启动会议需要编写项目启动会议文档，文档在标准文件中有模板。
需求讲解  （准备好项目原型+重要流程的流程图说明或者需求说明书）项目启动会议开完后休息5~10分钟，休息之后开始进行需求的讲解，需求如果比较多一定要分次讲解。因为一次讲的太多也不容易消化。可以选一迭代的功能进行讲解，第二迭代的功能在第一迭代快结束的前2到3天进行讲解。但是要注意如果第一迭代的功能如果影响第二迭代，在做表设计的时候要考虑到。
任务拆分  拆分任务录入极客平台，可以多个人一起拆分。项目经理判断任务拆分的是否合理
故事点数  前端后端的故事点数标准不一样，所以前后端的点数要分开计算，计算奖金的时候比例也要分开计算。
分配任务，分配任务记录在极客平台的任务管理中，并配置好故事点数，故事点数将会是后期计算项目奖金的重要指标故事点数越多奖金越多。分配任务时一定要确保开发人员明确知道任务的要求和交付标准bug的产生90%来自开发对任务的要求不明确，所以在分配任务时可以在和开发讲解一遍需求，不要嫌烦，这比起到后期熬夜加班改bug来说舒服太多了。
数据库设计 数据库的设计可以由项目经理统一设计，统一使用代码生成器生成代码。数据库设计一定要过评审，项目经理设计的数据库由主管或者java负责人评审，程序员设计的数据库由项目经理评审，评审过后才能生成代码和数据库脚本。
注意：我们只所以在代码生成器中生成建表语句是因为我们不想把建表权限给到开发人员，而是由开发人员提供数据库sql项目经理审核SQL后项目经理执行或者项目经理发给指定的人去执行，审核的时候要注意
建表语句中是否有注释，
字段长度是否符合要求
字段命名是否符合数据库规范
是否满足业务需求
我们在审核数据库sql的时候也是了解开发对于需求的掌握长度，如果发现开发的sql不对那就可以反推出开发可能并不理解这个需求，这时项目经理应该重新给开发讲解一下需求，然后让开发修改sql，这样就保证了开发对需求的理解也保证了数据库的正确性。开发如果要建表或者修改字段就必须提供对应的sql给项目经理。这也锻炼了开发的sql熟练程度。
sql管理  生成的sql放在项目中统一保存，项目中有一个db文件夹是用来存放sql的，建表语句放在init文件中，文件名中的01，02，03代表执行sql的顺序，增量sql放在increment中，比如初始化的数据字典值的insert语句，配置信息等都通过sql插入数据库，且sql保存在项目中，这样在部署新环境的时候就可以直接执行项目中的sql就可以初始化数据库了。而不需要同步开发与测试库，导致开发的脏数据进入新的环境
设计文档 对于复杂的功能要求开发编写设计文档，设计文档的模板在公司标准化文件中，开发编写完设计文档后，项目经理需要进行评审，评审通过开发才开始编程。
讲解设计方案  设计文档不是必须的但是每一个功能项目经理都要过设计方案，或者直接提供设计思路给开发，避免到后期出现对系统不可控的局面，项目经理对实现方案不清楚对项目质量就没有信心。编程之前要做到以下三点
需求明确
    有bug的地方往往是需求不明朗或者需求复杂的地方面对这样的需求sm一定要引起重视确保自己和组员能够正确理解需求后才开始编程
方案合理
    程序的设计方案一定要和sm一起讨论，确定一个合理的方案，而不是任由组员自己设计
理解一致
   对于上面2个方面，上面要确保和组员的理解达成一致避免发生乌龙事件
移交测试
开发自测后，提交代码到测试环境，测试环境发版后，通知测试测试，通知的格式如下，开发可以在表格中填好信息，截图发给测试，如果项目组使用了看板贴了纸质卡片，也可以用纸质卡片移交

测试拿到开发的移交申请后自己安排测试时间，在24小时内定要反馈测试结果

开发移交故事卡片有几个好处
1、测试清楚知道哪些功能是可以测试的，
2、如果要移交故事卡片去测试，则要求我们在拆分故事的时候一个故事是可以独立测试的，而敏捷开发的要求也是故事独立可测

如果开发的是接口功能那么测卡片由前端开发人员提交。接口开发完成后要录入到极客平台的接口系统中。接口录入时，一定要分模块，禁止所有接口录在一个模块中。后台接口录入完成后要及时通知做前端的同事，尽快联调，只有联调完成，功能才算是完。

单元测试   在系统没完成之前，测试不是不能介入，而是只能做单个的单元测试，或者几个小单元的集成测试。这是非常有必要的，因为很多不成熟的开发对自己的代码都过于有“信心”导致很多细节问题没注意即使是一个功能也能写出很多问题。单元测试可以帮助避免这些问题，从而降低集成测试的难度。
集成测试  一个迭代一般是一个完成的流程或者功能，所以在一个迭代结束后测试应该进行本迭代的集成测试工作，每个迭代都应该出一个测试报告 测试报告标准待测试给出
项目经理测试  在项目的进行过程中项目经理要竟可能多的参与测试工作，不要沉迷于编码，项目经理沉迷于编码对项目的质量风险是非常高的。项目经理是最了解需求的人，而下面的程序员对需求理解总会存在一定长度与的偏差，所以一定要通过项目经理的测试来纠正错误的需求理解。
客户迭代功能演示  一个迭代结束后务必找客户进行实际的测试一下，不要求能验收功能，但是一定要给客户演示一下，这可以避免需求出现很大的偏差，如果客户提出意见及时改正。
评审会  评审会是在每一个迭代结束后组织的一个茶话会，项目经理购买一点零食、瓜子，项目组成员座在一起对本次迭代进行回顾和总结，每个成员要总结以下几个问题
这个项目遇到的最大困难

怎么解决的

学到了什么

对后期的工作又有那些启发

项目经理要做好会议笔记，在会后把有用的总结整理后发在群里，并对下个迭代提出要求。这些问题在开评审会的前一天要发给项目组成员让他们准备一下。

项目进度汇报    每周五进行一次项目进度汇报发送给主管
 

开发环境搭建

在git上创建一个空仓库，把开发组的组员加入到git中，在极客平台创建项目把成员拉入到项目中并分配好职务
在框架版本库中拉取最新的版本，把代码上传到新建的空仓库，注意删除框架版本中的git信息
创建2个数据库一个开发一个测试，创建4个数据库账号，其中2个只有增删改查权限，另外两个具有修改数据库表结构的权限
-- 创建数据库
CREATE DATABASE db_databaseName DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
-- 授予数据库所有权限
GRANT ALL PRIVILEGES ON db_databaseName.* TO 'db_dev_user_data'@'%' IDENTIFIED BY 'db_dev_user_data' WITH GRANT OPTION;
-- 创建开发者数据库权限
grant usage on db_databaseName.* to 'db_dev_user_scop'@'%' IDENTIFIED BY 'db_dev_user_scop';
-- 赋予增删改查权限
GRANT EXECUTE,select,update,delete,insert on db_databaseName.* to 'db_dev_user_scop';
 
 

分开测试环境与开发环境 一般5万以上的项目要求分开测试环境与开发环境，如果因为域名或者其他配置文件导致只能配置到同一个域名下，那么也要尽量分开测试数据库和开发数据库，只有在外部环境实在不能分开测试与开发时才把测试环境和开发环境放在一起。
在测试服务器上部署一个开发应用，和一个测试应用，并配置好jenkins
把配置好的域名信息，jenkins信息，tomcat配置信息，日志配置信息，文件上传配置信息发在钉钉群里
修改登录界面的欢迎语，以及登录成功后的欢迎语，改成客户系统名称
分开测试环境与开发环境 一般5万以上的项目要求分开测试环境与开发环境，如果因为域名或者其他配置文件导致只能配置到同一个域名下，那么也要尽量分开测试数据库和开发数据库，只有在外部环境实在不能分开测试与开发时才把测试环境和开发环境放在一起。
在测试服务器上部署一个开发应用，和一个测试应用，并配置好jenkins
把配置好的域名信息，jenkins信息，tomcat配置信息，日志配置信息，文件上传配置信息发在钉钉群里
修改登录界面的欢迎语，以及登录成功后的欢迎语，改成客户系统名称
代码编写要求

遵循前后台代码规范
项目中不允许出现多余的代码，代码生成器生成的代码如果没有用到要及时清除
接口单一原则，一个接口一个方法坚决只允许完成一件事情，如果是同一类任务，需要通过if判断来处理不同的逻辑，那么if判断中的代码一定要抽取出方法而不能全部挤在一个方法中
禁止硬编码，所有的配置一定要写到配置文件中
禁止编写复杂sql，除非不得已为之，在实现功能和可读性之间我们更偏向于可读性
接口传值最小化，前端传值给后台应该尽量少传，后台能自己处理的就自己处理，把业务逻辑尽可能的留在后台
禁止使用map传参写接口，必须使用统一的AjaxResult类作为参数传递的格式
接口的录入公共参数不需要录入比如createBy，createTime limint 这些参数不需要录入。
接口录入要进行分类，不能全部录在一个分类下
如果处于测试需要要写死用户信息，那么一定要通过拦截器去写，不能再代码中硬编码
对于暂时无法实现的业务逻辑一定要在代码中加待办的标注 //TODO ,在发版本之前先检查一下所有的TODO标记
自己开发的功能一定要自己进行测试，测试的时候要尽量使用符合业务要求的数据进行测试，通过后在用非常规的字符进行测试，自己测试完了在移交到测试那边测
每天下班前要提交当天完成的代码，代码提交的备注尽量写清楚本次提交的目的
编写查询功能一定要考虑数据库表的记录条数，如果数据量上百万的表要尽量分历史表与作业表
金额计算要使用专门的类BigDecimal
及时解决程序员的环境、配置等问题，让其安心开发
bug要及时督促修复不要留到后期集中修复，那样会导致后期要交版本的时候非常紧张
BUG修复

测试要把发现的bug提到极客平台上并选择对应的开发人，和功能
开发收到bug提示后要及时响应解决完bug后，在极客平台把bug设置为解决状态,并选择方案为修复代码
          

3、测试收到开发解决的bug后进行bug的回归，如果确实解决了则关闭bug

 

 

每日站会

开站立会之前一定要和团队约定好站立会的规则，下面给出一个标准的模板

 

站会的团队规则

晨会：9:15-9:30
晚会：17:45
迟到：发红包5块
一级BUG：发红包5块
发包失败：发红包5块
代码质量差：发红包5块
开发延期：每延期一天发红包5块
 

每日晨会讲三个问题：

昨天做了什么，是否完成
今天打算做什么
提出团队或者自己的问题如：
阻碍工作的问题
需要协助的问题
可以改进的问题
代码或者功能有变动需要通知其他人知晓的问题
晨会的目的是同步信息，发现阻碍项

项目经理要总结工作情况，鼓励与批评对应的人。

 

 

每日故事点数

一个开发每天要完成多少故事点数这个是个问题，

每日的故事点数=本迭代总点数/( 开发人数 * 迭代天数 )

确定好故事点数后，每天必须完成既定的故事点数开发，如果产生延期则在看板上标记延期多少点，累计延期3天的点数就开始发红包没延期一天发5块钱

项目加班审批

项目加班项目经理可以直接批准，也可以拒绝，加班费用计入项目的总费用，加班费越多项目奖金越少。所以如果非项目本身的要求加班而是开发个人能力问题要加班项目经理可以不批加班申请。

 

系统测试

测试用例

测试拿到需求后要梳理清楚系统中存在多少个流程，每个流程有几个分支流程。每个主流程设计一个测试用例，主流程下的分支流程每个分支流程一个用例。

测试用例必须找项目经理评审

 

单元测试

在系统初期功能比较独立，没有关联，测试在本阶段应该注重功能是否正常，数据是否能够正常的被保存，查询，数据校验是否正确，界面是否布局合理。在后期功能越来越多时进行多个单元的集成测试，集成测试开发是不会再发测试申请的所以要自己安排

 

测试职责

全面了解项目的需求，项目经理在和客户讨论需求时测试要在现场。
测试要审核需求文档，在需求文档中找出逻辑不合理的地方并协助项目经理修改。
一定要在客户群里，客户反馈的问题测试和项目经理都可以回答
客户提出的bug客户要负责跟进，督促开发解决，并在客户要求的下一个版本之前回归所有客户提出的bug
了解开发计划，指定测试计划，确保在交付之前能够完成测试，对开发提出要求何时一定要交付测试，开发是懒惰的测试如果不提出要求，开发一定会在最后一天才把功能开发完成。如果测试不提要求导致没有时间测试责任由测试负责
所有bug录入极客平台，不厌其烦的督促开发修改bug
体验不好的界面坚决拒绝，不管开发愿不愿意都要改，对开发的宽容就是对客户的伤害，对客户的伤害就是对公司整体员工的伤害。
每日填写测试日报，日报发送给项目经理，舒适，姜友瑶
 

报价注意事项

1、我们的报价报的应该尽量是公司内部成本价保证能开发完就可以，不要刻意加价加工时。利润的事情商务去考虑

2、报价要按照一般程序员的开发速度考虑，不能考虑我们本身自己的开发速度，因为项目大部分是基层程序员开发

3、项目的报价需要考虑需求沟通成本，复杂的业务，在需求沟通，系统设计，UI设计方面都比较耗时这是功能之外的

4、考虑测试成本

5、如果需求比较简略，那么要从功能的完整程度去考虑需求上是否有遗漏的功能然后和商务讨论是否要加上

6、报价前当面找销售去沟通，让销售进行业务背景的讲解，直接看文档没有业务背景会比较懵逼报价不准。
————————————————
版权声明：本文为CSDN博主「姜友瑶」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/jackjyy/article/details/89337409