这是我从事软件外包工作以来的项目管理经验的总结编写文章的目的是为了回顾和总结自己的一些想法如果其中有不足的地方大家可以一起讨论交流。
关于项目经理的工作职责有很多种说法我自己是这样理解的作为一名项目经理第一目标就是
合理利用公司资源组织设计、开发、测试等各种资源完成项目的高质量交付并保证项目的盈利。
这是衡量一个项目失败或者成功的唯一指标当然有些项目是有战略意义的一开始就没打算盈利这样的项目就不能单纯的用成本来计算了。
这里有几个小点我想说明一下1、合理利用公司资源无论公司大小资源总是有限的公司不可能把所有的好的资源优质的资源都放到自己的项目组中总是高高低低的人凑在一起作为项目经理要能在资源和事情的总量难度之间找到一个匹配的值。项目拿到手上我们最少几个人能把这个事情做好要判断清楚。人多了浪费了成本人少了事情做不完。
2、利用各种资源有些资源是需要自己去争取的当我们发现项目出了问题但是公司给的资源又不足的时候项目经理就要想方设法的去获取这些资源而不是坐等公司来给我们解决问题很多人都看过一个电视叫《亮剑》主角是李云龙他就是一个很会自己找资源的人当时的中央是给不了他们什么装备的但是鬼子又要打怎么办自己去鬼子哪里抢去总部死皮赖脸要。正是因为他这样想尽办法为自己找资源最后他那个团是富得流油的打仗更是所向披靡。我们带项目也是这样资源不够的时候要自己去找只要你为了项目好总会从公司甚至是客户那里拉到支持。
3、高质量盈利。一个项目盈利是一个方面但是质量确实一个更长远的方面项目过于赶工降低要求最后伤害了客户也伤害自己所以项目的质量和盈利必须要兼顾要找到一个客户能够接受的质量区间但是不建议过于苛求因为没有bug的软件是不存在的。
虽然站在公司的角度项目是否盈利是重要的指标但是在我看来项目经理也有其他的一些重要的责任作为项目经理上要对得起公司下要对得起跟着自己做事情的兄弟所以 “让跟着自己做事情的人得到成长和锻炼” 也是项目经理的责任。也只有让和自己做事情的兄弟们觉得有收获别人才会愿意跟着你干团队才会有执行力。当然如何让自己的团队觉得有收获也是有很多技巧的。比如给与团队成员技术指导合理的安培开发计划在每一个迭代完成后给大家总结及时给与激励等。后面我们的具体工作方法中都有体现。
开发团队必须有一人可以全身心投入在项目中而且这个人知道整个项目的需求这个人可以是项目经理也可以是项目的主要程序员
团队要及时沟通如果发现团队中的成员不爱沟通项目经理要在早会中提出来告知沟通的重要性并且通过组织团建或者茶话会给大家交流的时间吐槽多了自然也会爱沟通一些
项目经理不但要管理团队的开发而且要管理团队成员的心态要保持团队成员每一个人都是积极主动的不合适的人及时淘汰留在团队中只会写bug给团队带来技术债务拖慢整个团队进度。木桶效应效率最低的人会影响团队的进度。
团队的执行力一定要强项目经理一定要反反复复的督促开发测试不厌其烦的跟进他们的进度任何拖延的人都是对项目极大的威胁如果项目经理视而不见对细节问题置之不理其最后的结果就是做了一个豆腐渣工程这样的案例我们已经经历了太多务必重视
比如有的人喜欢写死id或者用户方便自己调试但是写完代码只有又不删除导致后期排查问题时间拖长看似小问题实际是工作方式不对。遇到这种情况项目经理坚决对其进行罚款。把坏习惯扼杀在摇篮中。
不明确的或者模糊的需求讨论完后如果对方是企业客户一定要发邮件和对方确如是个人客户就需要用微信和对方确认确认的聊天记录截图发在钉钉群里留存。
经过今天的需求讨论我们确认xx功能的需求功能是这样的 xxxxxx 如果没有疑问我们就按照这样设计开发了如果有补充请在2个工作日内回复我们谢谢。
情况二、如果不是需求文档中涵盖的就要区分这个需求如果不做会不会影响客户的主流程如果会就要看付出的代价有多大原则上累计需求变动在3个工作日包括测试代价我们是可以答应客户的。但是也要告知客户我们是要付出很多成本才能完成你这个新增的需求。如果不做也不会影响客户系统的流程那么就要尽量的推掉。
如果既是影响主流程又是超过3天工作日的就要联系商务和客户进行报价洽谈并告知客户因为做了这个功能会导致项目后延看对方能不能接受。原则上项目的改动最好能推到验收付款后去完善。
如果需求出现大的变化项目经理无法把控的一定要上报但是也别一点点事情就上报能自己处理的自己处理。上级往往对具体需求也不是很清楚
项目要求按照项目需求标准模板编写如果项目比较简单那么就在原型上标注说明但是也要有主流程的说明文档以及分支流程的说明文档而且原型标注要足够详细
安排UI进行设计UI图要上传到Mockplus中并添加跳转点击psd图传到蓝湖方便前端人员查看尺寸
在需求梳理阶段要注意一个问题对方是否具有成熟的需求思考以及思路如果有成熟的需求那我们只要理解就好如果对方需求比较模糊那么就要求我们来做引导既要让需求满足客户的使用场景又要保证我们能够在规定的时间开发出来而且设计一定要合理。产品经理对业务设计不合理会导致需求变动多。
不要漏掉任何需求不明确的地方因为需求不明确会导致后期的需求膨胀而且会导致程序员不知道怎么开发转而按照自己的思路胡乱猜测从而写出很多bug。
项目启动时在共享文件中创建项目目录并告知相关的开发人员共享目录中包含项目的所有文档包括需求说明书、原型设计、UI设计、测试用例、等等。所有需要用到的资料都应该放在共享目录中
研发计划每周一周三更新一次更新后发在群里通知所有人公司会从项目经理的开发计划是否及时更新以及计划是否落实到位来考核项目经理的工作
组织商务测试开发以及一位技术主管到场进行项目需求评审。 项目启动会议需要编写项目启动会议文档文档在标准文件中有模板。
需求讲解 准备好项目原型重要流程的流程图说明或者需求说明书
项目启动会议开完后休息5~10分钟休息之后开始进行需求的讲解需求如果比较多一定要分次讲解。因为一次讲的太多也不容易消化。可以选一迭代的功能进行讲解第二迭代的功能在第一迭代快结束的前2到3天进行讲解。但是要注意如果第一迭代的功能如果影响第二迭代在做表设计的时候要考虑到。
前端后端的故事点数标准不一样所以前后端的点数要分开计算计算奖金的时候比例也要分开计算。
分配任务记录在极客平台的任务管理中并配置好故事点数故事点数将会是后期计算项目奖金的重要指标故事点数越多奖金越多。
分配任务时一定要确保开发人员明确知道任务的要求和交付标准bug的产生90%来自开发对任务的要求不明确
所以在分配任务时可以在和开发讲解一遍需求不要嫌烦这比起到后期熬夜加班改bug来说舒服太多了。
数据库的设计可以由项目经理统一设计统一使用代码生成器生成代码。数据库设计一定要过评审项目经理设计的数据库由主管或者java负责人评审程序员设计的数据库由项目经理评审评审过后才能生成代码和数据库脚本。
注意我们只所以在代码生成器中生成建表语句是因为我们不想把建表权限给到开发人员而是由开发人员提供数据库sql项目经理审核SQL后项目经理执行或者项目经理发给指定的人去执行审核的时候要注意
我们在审核数据库sql的时候也是了解开发对于需求的掌握长度如果发现开发的sql不对那就可以反推出开发可能并不理解这个需求这时项目经理应该重新给开发讲解一下需求然后让开发修改sql这样就保证了开发对需求的理解也保证了数据库的正确性。开发如果要建表或者修改字段就必须提供对应的sql给项目经理。这也锻炼了开发的sql熟练程度。
生成的sql放在项目中统一保存项目中有一个db文件夹是用来存放sql的建表语句放在init文件中文件名中的010203代表执行sql的顺序增量sql放在increment中比如初始化的数据字典值的insert语句配置信息等都通过sql插入数据库且sql保存在项目中这样在部署新环境的时候就可以直接执行项目中的sql就可以初始化数据库了。而不需要同步开发与测试库导致开发的脏数据进入新的环境
对于复杂的功能要求开发编写设计文档设计文档的模板在公司标准化文件中开发编写完设计文档后项目经理需要进行评审评审通过开发才开始编程。
设计文档不是必须的但是每一个功能项目经理都要过设计方案或者直接提供设计思路给开发避免到后期出现对系统不可控的局面项目经理对实现方案不清楚对项目质量就没有信心。编程之前要做到以下三点
有bug的地方往往是需求不明朗或者需求复杂的地方面对这样的需求sm一定要引起重视确保自己和组员能够正确理解需求后才开始编程
程序的设计方案一定要和sm一起讨论确定一个合理的方案而不是任由组员自己设计
开发自测后提交代码到测试环境测试环境发版后通知测试测试通知的格式如下开发可以在表格中填好信息截图发给测试如果项目组使用了看板贴了纸质卡片也可以用纸质卡片移交
2、如果要移交故事卡片去测试则要求我们在拆分故事的时候一个故事是可以独立测试的而敏捷开发的要求也是故事独立可测
如果开发的是接口功能那么测卡片由前端开发人员提交。接口开发完成后要录入到极客平台的接口系统中。接口录入时一定要分模块禁止所有接口录在一个模块中。后台接口录入完成后要及时通知做前端的同事尽快联调只有联调完成功能才算是完。
在系统没完成之前测试不是不能介入而是只能做单个的单元测试或者几个小单元的集成测试。这是非常有必要的因为很多不成熟的开发对自己的代码都过于有“信心”导致很多细节问题没注意即使是一个功能也能写出很多问题。单元测试可以帮助避免这些问题从而降低集成测试的难度。
一个迭代一般是一个完成的流程或者功能所以在一个迭代结束后测试应该进行本迭代的集成测试工作每个迭代都应该出一个
在项目的进行过程中项目经理要竟可能多的参与测试工作不要沉迷于编码项目经理沉迷于编码对项目的质量风险是非常高的。项目经理是最了解需求的人而下面的程序员对需求理解总会存在一定长度与的偏差所以一定要通过项目经理的测试来纠正错误的需求理解。
一个迭代结束后务必找客户进行实际的测试一下不要求能验收功能但是一定要给客户演示一下这可以避免需求出现很大的偏差如果客户提出意见及时改正。
评审会是在每一个迭代结束后组织的一个茶线c;项目经理购买一点零食、瓜子项目组成员座在一起对本次迭代进行回顾和总结每个成员要总结以下几个问题
项目经理要做好会议笔记在会后把有用的总结整理后发在群里并对下个迭代提出要求。这些问题在开评审会的前一天要发给项目组成员让他们准备一下。
一般5万以上的项目要求分开测试环境与开发环境如果因为域名或者其他配置文件导致只能配置到同一个域名下那么也要尽量分开测试数据库和开发数据库只有在外部环境实在不能分开测试与开发时才把测试环境和开发环境放在一起。
在测试服务器上部署一个开发应用和一个测试应用并配置好jenkins
把配置好的域名信息jenkins信息tomcat配置信息日志配置信息文件上传配置信息发在钉钉群里
修改登录界面的欢迎语以及登录成功后的欢迎语改成客户系统名称
一般5万以上的项目要求分开测试环境与开发环境如果因为域名或者其他配置文件导致只能配置到同一个域名下那么也要尽量分开测试数据库和开发数据库只有在外部环境实在不能分开测试与开发时才把测试环境和开发环境放在一起。
在测试服务器上部署一个开发应用和一个测试应用并配置好jenkins
把配置好的域名信息jenkins信息tomcat配置信息日志配置信息文件上传配置信息发在钉钉群里
修改登录界面的欢迎语以及登录成功后的欢迎语改成客户系统名称
接口单一原则一个接口一个方法坚决只允许完成一件事情如果是同一类任务需要通过if判断来处理不同的逻辑那么if判断中的代码一定要抽取出方法而不能全部挤在一个方法中
禁止编写复杂sql除非不得已为之在实现功能和可读性之间我们更偏向于可读性
接口传值最小化前端传值给后台应该尽量少传后台能自己处理的就自己处理把业务逻辑尽可能的留在后台
禁止使用map传参写接口必须使用统一的AjaxResult类作为参数传递的格式
接口的录入公共参数不需要录入比如createBycreateTime limint 这些参数不需要录入。
如果处于测试需要要写死用户信息那么一定要通过去写不能再代码中硬编码
对于暂时无法实现的业务逻辑一定要在代码中加待办的标注 //TODO ,在发版本之前先检查一下所有的TODO标记
自己开发的功能一定要自己进行测试测试的时候要尽量使用符合业务要求的数据进行测试通过后在用非常规的字符进行测试自己测试完了在移交到测试那边测
编写查询功能一定要考虑数据库表的记录条数如果数据量上百万的表要尽量分历史表与作业表
bug要及时督促修复不要留到后期集中修复那样会导致后期要交版本的时候非常紧张
开发收到bug提示后要及时响应解决完bug后在极客平台把bug设置为解决状态,并选择方案为修复代码
确定好故事点数后每天必须完成既定的故事点数开发如果产生延期则在看板上标记延期多少点累计延期3天的点数就开始发红包没延期一天发5块钱
项目加班项目经理可以直接批准也可以拒绝加班费用计入项目的总费用加班费越多项目奖金越少。所以如果非项目本身的要求加班而是开发个人能力问题要加班项目经理可以不批加班申请。
测试拿到需求后要梳理清楚系统中存在多少个流程每个流程有几个分支流程。每个主流程设计一个测试用例主流程下的分支流程每个分支流程一个用例。
在系统初期功能比较独立没有关联测试在本阶段应该注重功能是否正常数据是否能够正常的被保存查询数据校验是否正确界面是否布局合理。在后期功能越来越多时进行多个单元的集成测试集成测试开发是不会再发测试申请的所以要自己安排
客户提出的bug客户要负责跟进督促开发解决并在客户要求的下一个版本之前回归所有客户提出的bug
了解开发计划指定测试计划确保在交付之前能够完成测试对开发提出要求何时一定要交付测试开发是懒惰的测试如果不提出要求开发一定会在最后一天才把功能开发完成。如果测试不提要求导致没有时间测试责任由测试负责
体验不好的界面坚决拒绝不管开发愿不愿意都要改对开发的宽容就是对客户的伤害对客户的伤害就是对公司整体员工的伤害。
每日填写测试日报日报发送给项目经理舒适姜友瑶
1、我们的报价报的应该尽量是公司内部成本价保证能开发完就可以不要刻意加价加工时。利润的事情商务去考虑
2、报价要按照一般程序员的开发速度考虑不能考虑我们本身自己的开发速度因为项目大部分是基层程序员开发
3、项目的报价需要考虑需求沟通成本复杂的业务在需求沟通系统设计UI设计方面都比较耗时这是功能之外的
5、如果需求比较简略那么要从功能的完整程度去考虑需求上是否有遗漏的功能然后和商务讨论是否要加上
6、报价前当面找销售去沟通让销售进行业务背景的讲解直接看文档没有业务背景会比较懵逼报价不准。
在过去的职业生涯中，我参与且Leader过不少项目。这些项目中有成功也有失败，回想起来项目中经历的痛苦给了我很多收获。把痛苦后的感悟和
一下，提醒自己避免在今后的项目历程中重蹈覆辙，也希望可以对大家有一些帮助。结合我的工作经验，目前所经历的都是企业内部的信息化项目，比如ERP系统、HR系统、信息安全体系等，此部分经验的总结与分享对您正在经历的项目是否适应，还请各位读者自行判断。
的学习)，开始反思，吸取教训，总结经验，并根据公司的实际情况，结合PMP的五大过程九个知识领域及CMMI的相关要求适当裁 减进行
是一系列的伴随着项目的进行而进行的、目的是为了确保项目能够达到期望的结果的一系列管理行为。 2.
过程中所花费的工作量及相应的代价。它不包括原 材 料和能源的消耗，主要是人的劳动的消耗。 成本估计和成本管理是软件管理的核心任务之一。 典型的估计方法包括： ⑴ 静态：Effor...
高效利用时间 每个人的工作都存在差异，每个人的思想境界也各有不同。但是，上帝很公平地给了每个人一天24小时，因此我们提出管理时间。 管理时间是每个人都可以做到的事情。每天把24小时规划好，也就管理好了自己。平时大家会说时间不够，事情做不过来，我建议大家把时间拿出来分析一下，根据工作性质合理安排时间。 对于项目经理，事情多、工作琐碎，这样就需要养成每天入睡前回顾一天工作的习惯，并对第二天的工作进行安排。 在安排工作上，要求本部门员工要把握主次、分清轻重缓急。这样，员工每天一到工作岗位上就能很快进入工作
相关的观点。无奈，以个人的角度和眼光，鉴于工作中出现的一些问题，还是想在这里以“关二爷绣花”的立足点聊一聊
相关的问题。 先简单地从个人经历说起吧。我工作过的第一家公司是一家在国内外牛逼哄哄的互联网
在这堂课中，我所学到的最重要的东西就是我懂得了，完成一个软件项目，不是想象中的那么简单。 软件项目所需要的，也不仅仅是编写代码那么简单。 现如今，完成一个软件项目，光靠一个人的努力是不够的。现在每个工程的项目，都需要巨大的工作量，而这些工作往往分配给团体来完成。而且，一个项目需要的不仅仅是编写代码，还需要设计，测试等等工作。因此，在完成一个软件项目的过程中，需要我们具备团队协调能力，能够...
来源｜开源中国编辑｜Judy很多企业在项目开发过程中都会遇到时间、预算、人员配比等各种问题，一款高效的、良好的
软件必须具备快速的、强大的且包含：调度、成本控制、资源分配、文档、协作以及沟通等功能。以下 10 款免费且开源的
软件版本管理规范版本：1.0 第一章目的 本规范详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等内容，使软件项目版本管理流程化并规范化，确保在系统开发和实施过程中项目的完整性和一致性。 第二章适用范围 所有系统开发及实施项目的软件项目都应进行版本管理。项目中所有正式文档和代码都应纳入配置库（可使用工具建立配置库，如本文描述使用的是SVN）进行版本管理。 第三章职责 配置库管理
