组织级项目管理实例分享——来自项目管理群的讨论

  • 时间:
  • 浏览:0

本文转自baoqiangwang51CTO博客,原文链接:http://blog.51cto.com/baoqiangwang/487494,如需转载请自行联系原作者

1、背景2、缺乏报告 报告 3、制度与监控4、QA审计最好的妙招与组织级技术管理的介入点当当让我们业务软件分公司,有80+人员,下设业务拓展部(市场),二个产品线(开发为主)、集成、支撑等各部门此外,还有另另有1个项目推进部(PMO)产品线下设各项目组。还要注意的是,原应产品线由经营指标导向,而项目组是产品线下属机构,或多或少或多或少,PMO实际上而是另另有1个弱PMO。你这个 实物形成有历史原应。即使从现状看,而是原应做成强PMO,原应毕竟各产品线的业务各异,与客户、各干系人的接口不原应通过PMO进行。实际上,有一定矩阵式的特点。产品线经理的考核,主而是经营指标导向的,两种生活有的是 或多或少或多或少指标,但明显弱多了。后要 ,产品线经理非常注意经营指标,而忽视或多或少或多或少关键指标,甚至出現或多或少短期行为,这有的是 都可不上能 理解的。具体的说,主要有以下问题报告 报告 :1、项目管理的随意性。名义上,产品线下属的单位是3-二个项目组,项目组的负责人叫项目经理。实际上,你这个 项目经理即便上了PMP课,在实际工作中,仍是非常随意的作坊式工作。而产品线经理我很多 对你这个 进行辅导,只关注客户的实还要求、经营指标等。2、对质量的极度忽视。在CMMI的观点中,把质量提高到前所未有的高度。在当当让我们的实践则相反,假使 用户无投诉,基本上我很多 当成项目经理你这个 大的过失,软件做的好坏完正以客户评价定。3、原应无质量要求,没有系统设计、技术架构、新技术引入也都谈不上,开发工作在低水平上重复,代码克隆率很高,复用率很低。另另另有1个 ,开发人员就缺乏两种生活技术成长的感觉,也会缺乏团队归属感。Kerry 说:产品经理的确只对产品的实物负责,项目经理对项目进度、风险、成本等进行管理老蔡说:4、原应管理的随意性,人为偏好,技术成长困难等因素,原应员工的受挫感的传播,团队难以形成好的氛围。Kerry的问题报告 报告 我先解释下。当当让我们的产品线经理是项目经理的直接领导,PMO有的是 项目经理的领导。或多或少或多或少,当当让我们负责的面向是完正一致的。或多或少问题报告 报告 等最后一并聊吧。5、各类管理信息无法到达分公司管理层,原应分公司工作被动,有时是客户投诉到总公司时,分公司领导才得知此事的情况。至于组织层面的整体技术管理,根本不可行,如同昨天说到的知识管理案例也是没有回事。根据另另另有1个 管理产品线的经验,针对你这个 问题报告 报告 ,我的考虑是(1)通过《项目流程》的制度,把职责、流程、流程中各角色职责、基本行为规范、基本软件过程定下来。(2)通过组织级QA审计,检查各项目的流程执行情况,一并取得一手信息,出理 信息被项目经理、产品线经理另另有1个管理层面屏蔽。(3)在信息通道打开另另另有1个 ,技术管理等或多或少管理手段逐步介入。现在就着上传的另另有1个文档给当当让我们说明一下当当让我们的工作最好的妙招Richard李明-项目主管-北京 说:嗯 有流程,信息流动好像有的是 很好老蔡说:李明的问题报告 报告 ,正是给你 要要说的。Richard李明-项目主管-北京 说:请继续哈老蔡说:首先,流程执行的第另另有1个要求是客观,实际为什么在么在会么会执行,为什么在么在会么会表达。当让我们有的是的是行业应用软件,一是软件开发流程,这是另另有1个时间段。在你这个 时间段中,原应会出或多或少或多或少或多或少或多或少版本,一般1周至另另有1个月出另另有1个版本。出版本后,要升级到现有系统去,没有就还要制作升级包,升级手册、数据库脚本你这个 的。升级操作是另另有1个而有的是 另另有1个时间段,但原应它非常重要,或多或少或多或少当当让我们也要记录和审计。打开《版本开发流程单》,这份文档,而是要求每个迭代版本开发时填写。评审等过程,错综复杂为签字,而不像CMMI要求的那样出评审报告。对于大的版本,比如另另有1个月出一次的,一般来说,会有与用户的原始交流,即用户提出原始需求后要 需求人员进行分析,出需求规格文档。再和开发人员、项目经理开会,确认做你这个 ,你这个 跟客户解释不做或另另另有1个 做。你这个 会议,我很多 求出评审报告和会议纪要,假使 相关开发人员签字认可。接下来项目经理根据当当让我们评审的结果,进行规划版本;后是测试最后项目经理审核整个版本包,产品线经理复核。原应是另另有1个紧急补丁,或多或少或多或少过程都可不上能 错综复杂。另另另有1个 ,实际上用于流程的时间,也非常少。等到版本或补丁制作完,刚现在结束准备上线时,还要进行现网操作审核你这个 细节就比较多,原应维护支撑部两种生活没有参与前期的开发,没有当当让我们就会对项目组期待很大,而其他人 不去关心版本的内容。另一面,项目经理也会有同样的期待,这里有的是 另另有1个漏洞了。QA审计要关注到你这个 升级操作是是不是明晰,是是不是可执行,是是不是可回退等。甚至,原应现场实施人员,一并也是次日保障人员,是是不是原应?对于另另有1个简单的补丁一般没有问题报告 报告 ,但原应大版本肯定不行。另另另有1个 ,理论上,项目成员只用了签字、填表的时间成本,就把关键的项目信息都透明出来了。补充上,刚才漏了。在CMMI中,提倡对每个项目的软件过程进行定制。在实践中,我认为基本不原应。或多或少或多或少我的做法是,根据项目的重要程度,新系统开发还是迭代式,分别管理。具体见《项目检查点》上的说明。另另另有1个 ,PMO维护一份项目清单,同步给各产品线,当当让我们按照项目检查点上的要求,结合整体的项目流程,另另另有1个 实际上就等同于,定义了5-6种标准过程,选取使用(PMO与产品线事前沟通选取)最后说下执行的情况。在最初,我摸索你这个 最好的妙招的另另另有1个 ,尽管要求项目成员填写的信息我很多 ,但通过有限的信息,以及相关的工作产品文档,都可不上能 发现或多或少疑点或不清晰的地方,后要 找相关人员访谈确认(你这个 访谈也跟CMMI不同,重实质不重形式上的覆盖率)。另另另有1个 ,发现了或多或少或多或少并有的是 一般意义上的流程执行问题报告 报告 。这类,都可不上能 发现补丁包制作错误,发回项目组重做后,才同意上线。(严格的说,是是不是同意上线有的是 QA的权力,QA审计是事后的审核点。因我是分公司管理层,才都可不上能 没有做)当我把你这个 最好的妙招移交给QA时,发现执行情况不理想。受CMMI熏陶我很多 ,每个流程单十几分钟就审核完了,要么而是完正违反流程,要么而是没有任何问题报告 报告 。为此,我重新考虑了其他人 的审核的最好的妙招,设计了《QA审计报告》文档。另另另有1个 我认为QA审计应该不受限于审计报告,而以主观经验带入为好,但另另另有1个 原应我对QA无法监督,而QA发现问题报告 报告 越少也无所谓。现在不得以加入文档化的审计报告另另另有1个 ,一方面,审计报告中体现出QA对项目原始数据的搜集。你这个 搜集主要有的是 通过询问项目人员,而是访问SVN、Jira等通过原始数据的搜集后,对于软件过程审计,应当能分蒸发掉或多或少有意义的结果。你这个 是有意义的结果呢?这类,另另有1个大版本,开发人员80的,有测试报告,但Jira上却没有BUG记录?原应不到小量的小BUG,这肯定不对。软件产品质量审计你这个 小节,侧重关注产品定义是是不是清晰,实际上与配置管理关系很大。或多或少或多或少项目组的配置管理非常混乱。部署包和升级步骤,基本上而是组织级技术管理的主要介入点之一(新系统开发的评审也是重要的介入点)。在你这个 点换成强控制,都可不上能 提高升级的成功率,减少回退和次日的问题报告 报告 数量、紧急补丁数量。你这个 要素,也是要求QA做独立意见的。徐文锦 - IT Consultant - singapore 说:问一下 当让我们有的是哪几次环境 除了dev 和production老蔡说:当我看后审计报告时,原应对QA意见明显不认可,都可不上能 找QA谈,顺便指导QA的工作。最后,版本上线情况跟踪分析,实际上形成了另另有1个闭环。都可不上能 关注到,项目经理、产品线经理是是不是有进行后续跟踪(或多或少或多或少产品线经理根本不管)。后要 与或多或少版本建立相关性,都可不上能 分析是是不是存在屡次升级失败,是你这个 原应等。通过你这个 审计报告模板,基本上QA的工作都可不上能 保证达到一定的细腻度。对于分公司层面进行上线最后的确认而是会太盲目。主要内容就你这个 了。麻烦徐文锦再表述一下问题报告 报告 ?徐文锦 - IT Consultant - singapore 说:你爱不爱我的是, 从开发环境 到 生产环境 中间还有哪几次环境哪几次步骤老蔡说:正常情况下,开发环境而是开发人员的工作电脑+数据库;测试环境在公司,也独立于开发环境。生产环境不出当当让我们公司。独立的测试环境,和正确的版本制作最好的妙招,理论上都可不上能 保证版本升级的正确性。不过,在实践中,项目组混同开发与测试环境的事情而是少见各位,还有问题报告 报告 吗?徐文锦 - IT Consultant - singapore 说:其他人 感觉 我很多 开发人员接触测试环境 即QAT 都可不上能 较大的提高软件质量.老蔡说:是的,当让我们有的是的是你这个 要求。后要 ,从分公司管理层面,到开发人员有管理层级的差距。原应去问项目经理,很原应还告诉你当当让我们分的很清楚,不到在工作实践中的QA数据能够发现问题报告 报告 。吴柯-管理-北京 说:当让我们有的是的是为其他人 的母公司开发软件吗?老蔡说:有的是 ,为电信行业客户开发。吴柯-管理-北京 说:哦,另另有1个大软件公司,业务软件分公司是另另有1个大产品线老蔡说:有的是 。当当让我们的分公司,给你理解成另另有1个独立公司,除了财务不出当当让我们,或多或少职能哪几次有或多或少。吴柯-管理-北京 说:产品版本和项目版本为什么在么在会么会同步?lastwinner-pm-bj 说:跟上进度了,老蔡今天讲的你这个 层次相对较高了给你 要问一下,另另另有1个 做,对QA的技术素质貌似要求很高呀?老蔡说:无所谓产品版本和项目版本,在配置管理混乱的情况下,不到根据各个项目的实际控制来说。实际上,基本是另另有1个地点的另另有1个项目另另有1个版本。产品,而是概念上的,用于包装给客户的。徐文锦 - IT Consultant - singapore 说:QA两种生活是软件开发中非常重要的另另有1个环节吴柯-管理-北京 说:另另另有1个 啊徐文锦 - IT Consultant - singapore 说:microsoft的office team   dev和qa的比例达到1:10老蔡说:lastwinner,原应历史原应,我这边的QA薪酬相当不低。徐文锦 - IT Consultant - singapore 说:后要 严格的项目一般是要求qa原应专门的deployment team 出包和部署吴柯-管理-北京 说:哪质量难以得到保障,产品发展代价反而更大lastwinner-pm-bj 说:怪不得分配的任务要求没有高徐同学说的微软的情况,国内或多或少或多或少公司够不适用的,连用友另另另有1个 的公司都做不到徐文锦 - IT Consultant - singapore 说:我两种生活国内公司 有点儿是小公司对于qa的要求太低  没能保证产品质量吴柯-管理-北京 说:比如另另有1个项目里发现的BUG,修改后或多或少项目我很多 用得上lastwinner-pm-bj 说:国内或多或少或多或少公司有的是 适用的(刚把 都 打成 够 了)老蔡说:当让我们有的是的是要求测试人员出包。即开发人员宣称代码原应好了,后要 测试人员打上版本标签,从SVN库中取文件,用另另另有1个 提供后的脚本构造编译出包。实际上,个别项目组做的到,大要素做不到。吴柯-管理-北京 说:你这个 是对的徐文锦 - IT Consultant - singapore 说:一般你这个 过程都可不上能 采用自动集成/编译/部署  ,不过一般还要专门的部署团队吴柯-管理-北京 说:版本一定要专人老蔡说:我的最好的妙招是,开发人员都可不上能 帮助测试人员写脚本。但提交测试和部署的版本包,一般是在开发人员无法接触的情况下生成的。吴柯-管理-北京 说:除了SVN以外,还用到你这个 辅助开发管理的工具吗?lastwinner-pm-bj 说:老蔡你爱不爱我的 "做不到",指的是代码的版本管理做不到还是说实际上当当让我们宣称的代码已做好是不符合实际的?老蔡说:另另另有1个 ,假使 测试通过的包,拿去升级一定没有问题报告 报告 。lastwinner-pm-bj 说:老蔡-技术总监-福州 says (13:24):另另另有1个 ,假使 测试通过的包,拿去升级一定没有问题报告 报告 。这话太绝对了,不过另另另有1个 做都可不上能 说99.9%的情况下有的是 会有问题报告 报告 徐文锦 - IT Consultant - singapore 说:原应你有兴趣都可不上能 研究一下TFS 和微软一整套的软件开发流程老蔡说:lastwinner,是项目经理的意识做不到。我现在的工作层次在组织级项目管理。lastwinner,别没有认真啊,两种生活99%没问题报告 报告 就原应非常非常好了。当当让我们目前升级的回退率至少5%,换成升级有问题报告 报告 的情况,应该快10%了。徐文锦 - IT Consultant - singapore 说:一般比较正交的测试 把bug降低到1%问题报告 报告 还是不大的, 原应有会写代码的qa 没有有的是再降低Bug率lastwinner-pm-bj 说:原应是意识问题报告 报告 ,没有通过你的最好的妙招灌输下去,多数项目经理就能具备另另另有1个 的意识,对吧?老蔡说:不而是灌输啊,要循序渐进,慢慢渗透进去。项目经理真想做,一定能做到的。吴柯-管理-北京 说:另另有1个产品一并支持多个客户?哪几次个?老蔡说:大要素产品是另另有1个。现在慢慢2-另另有1个的,但实际上,那个产品有的是 很大变更。你理解成项目或许更好些。徐文锦 - IT Consultant - singapore 说:问一下, 谁为版本回退/部署失败 负责?吴柯-管理-北京 说:以现场客户开发为主,还是在公司开发测试另另另有1个 在现场而是部署?老蔡说:项目经理在公司开发为主。吴柯-管理-北京 说:你这个 是电信的行业特点,还是当当让我们公司的业务特点,当当让我们公司做金融行业,大要素是现场开发?老蔡说:电信行业,一般我很多 大要素现场开发。金融行业,听说大要素是现场开发。吴柯-管理-北京 说:公司开发要求客户的需求质量比较高,变动而是能我很多 当当让我们这方面何如控制徐文锦 - IT Consultant - singapore 说:毕竟当当让我们和钱打交道....软件质量会要求比较高lastwinner-pm-bj 说:你这个 管理最好的妙招感觉能让PM较快的成长起来,后要 能 对其他人 的工作职责范畴有清晰的了解MicrosoftInternetExplorer402DocumentNotSpecified7.8Normal0吴柯-管理-北京 说:客户不参与最后的测试吗?徐文锦 - IT Consultant - singapore 说:应该是参与的吧吴柯-管理-北京 说:当当让我们测试完就直接上线?蔡晓东 说:新系统开发,会参与,但参与度低徐文锦 - IT Consultant - singapore 说:不过国内的就不好说了....电信你这其他人- -#蔡晓东 说:迭代式,或多或少或多或少情况原应是在线系统了,客户要求当当让我们1-2周上一次版本,当当让我们没有精力陪当当让我们测试。要测也是等上了再说。差我很多 了吧,这次记录其他人 发吧吴柯-管理-北京 说:当当让我们一般1-另另有1个月一次,1-2周会我很多 或多或少短,从需求、涉及开发到测试?徐文锦 - IT Consultant - singapore 说:原应是迭代一段话你这个 时间不算短,瀑布就惨了蔡晓东 说:行业不同。有时客户会要求2-半年来一次。吴柯-管理-北京 说:徐文锦 - IT Consultant - singapore 说:当让我们有的是的是何如出理 涟漪效应的, 有的是你在改了另另有1个地方 或多或少或多或少也受影响吴柯-管理-北京 说:差异还真大蔡晓东 说:当然还要迭代。不过目前主流过程对迭代支持有的是 好。scrum原应会好,后要 ,scrum的客户参与等是不可用的,当当让我们还要把客户做干系人管理,而有的是 类同团队成员。老徐的问题报告 报告 ,分另另有1个层面:项目层面,看经验;组织层面,就不到在QA质量审计,QA原应分公司管理层发现问题报告 报告 ,追溯下去分析了。吴柯-管理-北京 说: 用了scrum吗?蔡晓东 说:

 没有,我是在其他人 的最好的妙招论形成另另另有1个 ,才知道Scrum。感觉Scrum也是受应用场景限制的。