【修炼一】开篇
【修炼二】框架图
【修炼三】规划
2013.5.12
规划阶段通常是项目启动第一个阶段,在此阶段里产品经理会将项目目标传递给项目经理。
万事开头难,好的开始是成功的一半,此阶段里项目经理就应该打起精神,迅速进入状态,做好战事准备。
我将按项目管理的5要素来分解在此阶段中,项目经理应该重点关注的事项。
【修炼四】技术预研
【修炼五】用户需求&系统需求
2013.5.26
需求阶段的工作是项目经理最繁忙的一个阶段,也是项目能否做好的一个重要分水岭。通常此阶段要完成系统需求的编写,工作思路的整理,工作计划的制定,人员工作的分工,并且伴有大量的评审。如果稍有不慎就很容易被拉入到漩涡中,失去了自己,不停的被别人推着走,心情苦闷不说,还会为整个项目埋下层层地雷,才是真正的悲剧。
因为用户需求是由主管/产品经理编写,系统需求有项目组编写,因两个需求工作有着一定程度的并行,因此合在一章写。
按项目管理的五要素分解如下:
1、干系人期望-目标
用户需求:
用户需求通常由主管或产品经理进行编写,主要目的站是在客户的角度上描述遇到的问题,并将其抽象为客户的使用场景及对应我们项目能够提供的解决方案。
用户需求文档在解决方案的描述通常粒度比较粗,因为在评审中解决方案的思路有可能被变更,过多的细化解决方案,工作量返工的成本会比较高。
用户需求的主要干系人:
1) 上级领导:评估该项目的价值,投入产出比是否合适
2) 行销部:评估该项目如何宣传,宣传的成本
3) 项目组:以用户需求为基础细化系统需求,并理解项目意义
系统需求:
系统需求通常由项目组提供,将用户需求评审过的解决方案具体化,此文档的主要干系人:
1) 主管/产品经理:系统需求是否能完全符合用户需求,是否有足够好的用户体验
2) 客服部门:技术支持是否便捷,成本如何
3) 开发人员:项目具体做成什么样子
4) 测试人员:项目如何验收,怎样算通过
文档要描述清,UI界面(及界面上约束)、关联功能影响,已知缺陷,异常场景,非功能性影响(性能,稳定性...)等。
2、沙盘-思路
1) 项目团队参加评审
在用户需求和系统需求阶段中,项目团队成员应该都参与评审,虽然评审过程中不一定发言,但是会有两个重要作用:
a、强烈的项目参与感
b、对项目原始需求的理解程度
c、对各干系人的期望的了解
2)需求质量保证
需求质量保证有两个很好的实践可以采用:
a、由下一阶段的模块作者编写需求文档
这样可以保证作者对需求的理解程度,同时在评审过程中能够纠正错误理解。由于下一阶段的作者通常来说更加熟悉改动或新增的模块,因此关联改动、已知缺陷发现比较容易被他们发现。
b、测试进行需求验收
记得前几年参加IBM的管理论坛,当时听到一个观点,深有感触。大概意思是:“只有可验收的需求才是完整的需求”。需求很难通过描述的粒度来判断是否完整,清晰,有看过篇幅特别长的需求文档,写了N多废话,但是仔细一推敲就能发现其中的很多遗漏点。
只有当测试的同事拿到需求文档后,能够清晰的知道如何来验收这些需求,没有任何二义性和模糊的地方,这样的需求才是完整,清晰的。
测试同事的项目全阶段的缺陷预防工作在我们公司推行已久,当目前为止还是需求阶段的缺陷预防产出最大。
3) 制定项目沙盘
项目沙盘有两个重要部分
a、干系人期望分析与落实方法
例:一个项目组为了更好的体验,翻新了系统的所有页面。那此时产品经理/主管的期望是很明确的,就是为了客户体验。
此时项目组应该在需求讨论时(DEMO),界面已经初步完成时,功能都已经调通时,分别各安排一次体验,以此达成产品经理的期望。
b、项目成功的关键因素分析
项目的成功关键因素可以使用鱼骨图进行分析,对于研发项目而言主要由3根大骨刺构成:人,流程,技术
例1:一个项目组主要都是有新员工组成,项目组面临的技术难度不大,这时候新员工的工作质量就会成为关键因素,此时可以做进一步分析。
![](https://img-blog.csdn.net/20130526115242943)
例2:一个项目组性能方法改动和提升技术是最主要的瓶颈,进一步分析如下:
![](https://img-blog.csdn.net/20130526115253256)
3、计划制定
1)使用估算清单
项目里总有一些例行工作,项目组在估算开始前应该整理出此清单,避免项目组成员遗漏估算项。
一些例行工作例如:环境搭建,每日构建环境的维护,迁入代码审核,评审时间,测试案例评审时间等
如果当前部门或公司已经提供估算清单,那只需要根据项目特点做下修改就可以了。
2)落实沙盘
想法和计划最大区别在于后者已经准备开始执行,不准备实施的想法终究只是想法。经过各种分析、各种集思广益得出的沙盘是智慧的结晶,需要将他们做到计划中。通常落实沙盘得到的计划就是项目组的缺陷预防计划。
3)自下向上估算,专家核对
估算的方法有很多,这是我所推崇的一种方法。详见下节:http://blog.csdn.net/liangjingbo/article/details/9008735
估算结束后应该产生项目的详细project及明确的里程碑。
4、风险管理
1) 复杂系统里的关联影响考虑不周
对于在现有系统新增或修改模块的项目,如果当前系统非常复杂,那么关联性问题将很有可能在此阶段被大量引入。针对这种情况可行的两种方法:
a、召集专家会诊
b、模块负责人提前分析(需要项目组给予时间)
2)估算项遗漏
估算项遗漏会直接导致工作量不准,这里常见的方法如:
a、使用估算清单检查例行工作是否有遗漏
b、使用需求根据矩阵核对需求是否有遗漏
c、专家把关估算表
3)需求评审变化,导致新增预研项
最令项目经理苦恼的问题之一就是需求的变化,其实有些时候变化的不是需求而是大家对于需求的理解。避免需求变化的带来的影响,需要做好两方面的工作:
a、需求缺陷预防,项目经理向组员传递良好的客户导向意识,将一些项目组自己能发现的不合理处尽量在前期提出,避免拖拉到后期带来更大的影响。
b、当需求变化不可避免时,要及时评估是否要进行补充预研,我看过很多心急的项目经理通常急于按计划推进阶段,结果在这上面吃了大亏。
4)团队的组织架构,不利于及时发现风险
每当我听到项目经理说“项目质量要等到转测试后才能知道到底怎么样”时,我都会给这个项目打上“高风险”“失控”的标签。打个形象的比喻,项目是开发团队的孩子,测试团队是医生,要想生个健康的宝宝,怀孕前期及期间的工作是最重要的。当一个孩子已经出生时,孩子的体制和健康情况已经有了基本定论,如果这时医生才检查出有严重缺陷(例如,某个模块的代码写得很差),那么已经很难补救了。因此项目组必须要时刻对项目的质量、进度有很准确的把握。
对项目的质量,进度的准确把控,对于大团队可能有多个选择,例如:
a、成立不同小组,由组长兼顾管理和技术。
b、独立出兼职的技术专家团队负责技术,项目经理负责管理
c、独立出全职的技术经理负责技术,项目经理负责管理
等...
组织结构的方法可以多种多样但是一个原则是要能够及时有效的发现风险。
在这方面我和我的搭档尝试过一种方法,可以作为一个实践供大家参考,我们当时制作了一个项目模块质量跟踪表,以及时发现风险。
跟踪表里的第一部分是:项目组的所有模块、负责人,涉及的专家名单
第二部分是:对模块复杂度,难易程度的自评、专家评定
第三部分是:对模块设计情况的自评和专家评定
第四部分是:对于编码阶段的代码质量自评,专家审核评定
...
5、团队管理
1)团队分工及成长计划
团队分工是项目需要和组员自身需求的平衡体,完全以项目为导向的团队会缺乏向心力和持续的战斗力。例如:
a、一个很优秀的组员,最近妻子怀孕临盆在即,那么项目组不应该给其安排工作量特别大的分工。
b、一个做技术很好的专家想转型为管理人员,那么继续安排他写代码也是不合适的。
好的项目经理应该了解项目组员的工作背景,家庭背景,工作诉求。团队分工时能够考虑大多数或是优秀人员的诉求,并同他们制定成长计划,这种激励是长期的。如德鲁克所说:“管理的本质是获得追随的人”
2)言路畅达(尊重)
发言权涉及到尊重他人的话题。想看下节:http://blog.csdn.net/liangjingbo/article/details/9008761
3)团队的口号、文化
团队的口号决定团队的文化,口号可以由大家一起讨论制定出来,好的口号往往是项目成功的最关键的心态因素的简写。我经历过两个项目组的口号如下:
a、细心,细心,我们再细心一些 (这个项目的特点是将近10个分支的代码合并到一起)
b、担起自己的责任 (这个项目的特点是模块关联性不高的新模块)
4)奖罚项
口号毕竟是虚的,设立了明确的奖惩措施后,比较容易让文化落地。奖罚项可以针对个人,也可以针对小组。例如:
a、强调细心的项目组,在编译打包出问题时需要犯错误那个人给整个团队买王老吉。
同样对于代码互审阶段做得最好的人,要给予奖励
b、强调担责任的项目组,在项目模块没有按期完成的情况下,模块负责人应该安排加班,优先自己搞定。
另外奖罚要做到对团队有更大的影响,需要做到短期,及时通报当前情况。
a、短期,就是奖罚的结果不能拉得过长,不能在项目结束时在评定,这时候木已成舟,对项目本身已经起不到作用。
b、及时通报,就是要按周或按天通报当前的数据统计情况,以便更大程度的影响大家的日常的工作心态
5)里程碑庆祝点
里程碑庆祝的重要性,想看下节:http://blog.csdn.net/liangjingbo/article/details/9008789
6)项目团队的例行日程
尽量将项目组能例行化的工作时间表明确下来,这样避免大家工作总是无规律的打断,影响工作效率。
例如:
a、项目组总是周五打包,打完包后验证基本功能,如果基本功能有问题,责任人需要当天排除出来,否则周末加班搞定。
b、每周日自动使用上周五的新包,升级所有测试环境
c、每周一项目周会,项目经理讲述项目当前情况
d、每天下班前,需要发送当天的日报给组长,组长在第二天早上10:00批复
【修炼六】时间估算的三步曲
项目绩效的重要衡量指标之一便是时间,这里总结下亲身经历的三步曲.
第一个阶段:项目经理简单估算+倒推+部门预备机动人员
优点:估算速度非常快(很多时候,项目计划都是从上级给的发布时间倒推出里程碑)
缺点:计划非常不准,项目成功率不高。主要原因是:
1)项目经理个人思维限制考虑事情不可能百分之百周全,尤其遇到新的项目经理,项目成功的几率更是直线下降。
2)部门的人员总是要干活的,当项目发生风险时,原计划的机动人员总是不够用,或是不能停下手头的事投入项目中,如果遇到多个项目同时需要机动人员支援时,整体部门基本要全线加班,集体奋斗了。
3)项目组成员参与度不够,如果工作加班,有一定怨言
总体来说:还好每当这时候项目经理都能身先士卒加班,这时候部门的同事都是难兄难弟,总是很辛苦,但是项目结果总是不理想,不能按期交付。
第二个阶段:公司级形成估算团队做专家估算
为了改进估算,同时保证各部门绩效的公平性,公司针对A部门的项目会找其他的部门的专家参与估算,估算使用3点发计算出版本时间点,如果某个专家估算的不 准,则要求重新估算或当面讨论,最终取得一致后将成为项目发布的绩效点.
优点:相对公平,有一定信服力
缺点:
1)容易出现扯皮现象,项目估算时间很长,并且外部估算的时间计划难以转化为内部计划,工作量浪费很大。
2)专家质量与主动参与度难以保证,尤其是参加多次估算后,专家容易倦怠
3)公司不关注人员分配,不考虑具体项目的最长路径,计算时间公式为:工作量/人力=项目时间
4)项目组成员参与度不够,如果工作加班,有一定怨言
总体来说:公司级的估算是CMMI引进到公司的,起到了很大作用,但是一定程度上造成了公司级的RDM组织和部门的对立,能力强的项目经理能够做很多线下活动,从而得到自己的绩效时间期望。
第三个阶段:部门自下向上估算+专家指导
其实第二个阶段和第三个阶段在一定程度上是有重叠的,第二阶段中,有一些先知先觉的项目经理,在公司开始进行估算前,首先进行了内部自下向上的估算,这样自己知道了自己的底限,如果有关键路径消除不掉,则要在总工作量加大,以达成自己的预期.
第三阶段主要的特点是项目估算以部门及项目为主导,当出现关键路径后,部门或公司专家帮助消除,如果消除不了,以项目估算为准做绩效点。
优点:
1)能够保证信服力
2)鼓励项目经理一开始把版本事情考虑周全,如果项目计划可行性非常高
3)全体项目人员参与的估算,更加准确,并且成员愿意为自己估算的时间负责
4)RDM和部门关系形成互助关系
5)估算结束后,直接产出可执行的项目计划
缺点:
1)估算周期稍长,通常需求基线后1-2周能给出
总体来说:这种方法是我个人最推崇的方法,能够有效提高员工的参与度及估算的准确度,同时维持组织的互助性,对版本成功非常有帮助。
【修炼七】团队建设-尊重
知识型工作者只有让他们感到被尊重,被认可才能激发出他们的工作热情。制造业工厂监工式的管理方法,绝对量化的考核指标在知识型团队管理中将会失效,
这是管理人员面临的挑战,德鲁克也在《卓有成效的管理者》中对管理者和这种监工做了明确区分,其中的观点是监工是上司,但不是管理者。
一个抱着积极、认真负责,打拼事业心态的员工做事的有效产出和机械完成任务的人员的有效产出是多么的不对等,这里不需要再列举各类研究结果。尊重是激励文化构建的基石,如果没有尊重,激励就是空中楼阁亦或是短暂的激情。本篇笔记重点谈谈在项目管理过程中对如何给予员工足够的尊重。
1、项目的意义
成就感是让团队努力向前的最好激励方案,任何项目的成立都是有意义的,如果能够让整个项目团队时刻清晰的认识到自己是再做一件对部门、乃至对公司意义重大的事,则往往能够焕发出团队很强的战斗力。受到关注就会给人被看重感,人就感觉到要对事情付更多的责任。
推荐策略:1)项目启动时,高层领导进行动员,宣传项目意义
2)项目中期,规划负责人/项目经理要能定期发出
一些
市场人员/客户对项目的
期望
3)项目结束后,高层领导要能够反馈项目获得的成绩
2、项目时间估算
我个人比较推崇的估算方法是自下向上的估算(具体可以上篇文章:时间估算的三步曲),自下向上的估算能够给予项目组员一定的
发言权及主人翁感,并且能够调动大家责任心,通常大家愿意为自己的决定负责,但是如果是领导直接压下来的任务尤其比较紧急时,通常有些抵触。当然在自下向上的估算中,要有专家进行指导和把关,包括估算漏掉的哪些事情,项目组内例行需要消耗的时间等,并且针对”狮子大开口“的时间需要进行讨论,达成一致。
在这种估算方法做出的项目计划下,如果项目最后出现了问题,尽管项目经理要承担直接责任,但是项目团队成员通常会比较自主的愿意与团队共度难关。因为决策是大家一起制定出来的。
推荐策略:尽量使用自下向上+专家指导的方法进行估算,如果有人员到位或者估算周期的有限制,至少要保证关键人员的参与,而慎用自上向下的估算方法.
3、善用加班文化
IT公司加班是件很自然的事情,如果哪家公司没有加班情况,反而会让人感觉不正常。做为项目经理应该首先理解,加班虽然是IT公司的普遍现象,但是确实是组员为了项目做出了额外的奉献,他们牺牲与家人团聚的时间,牺牲了休息时间,甚至影响了健康。这种行为值得我们尊重,我们要小心使用这项权力。
1)不要动不动就抛出一句“
这个今天搞不定,就打地铺解决”等,这种言论是对员工额外奉献的一个严重的漠视,而且带着很强的个人意愿
2)时时保证项目的进展的透明性,可以通过周会,日报的形式在团队中发布。当遇到赶工时,跟当事人讲解当前团队面临的困难,总之,加班是个艰难的决定,是为了整个团队的绩效,不是项目经理的个人意愿
3)任何加班时项目经理都应该尽量身先士卒带队
4)在一些公共场合,尤其有上级领导在时,公开表扬那些为团队做出很多额外贡献的人
5)绩效考核肯定以结果为导向,不能以加班多少论英雄,但要有其他措施安慰最辛苦的人
推荐策略:加班是一种奉献精神,我们要小心使用,认真对待。不能简单的当做管理者的权力,轻言肆用,否则久之必招其离心。
4、开放沟通的团队氛围
人都希望自己能够有发言权,能够对关心的事情产生影响。上至国家领导人的选举,下至日常的工作生活。如果发言权被长期压制,就会产生压抑和叛逆的心理。因此构建一个具有开放沟通的团队氛围则显得很重要。而往往言路开明后,项目经理总是能在一些讨论中,得到很多比预期更好的解决问题的方案。一个强权的管理者,容易获得一定程度上的执行力,但是容易被自己的盲点击败。而一个开明的管理者,往往能使用集体智慧,获得跟随者,更容易产生威望。
推荐策略:1)项目沙盘等关键策略制定时,要全体项目参与讨论
2)项目经理鼓励大家发现问题,提问问题,对于好的措施,能够采纳执行
5、责任到户 VS 大锅饭
从头到尾的
责任到户制应该是最理想的工作分配方式了,在这种分配方式下,团队成员有一块自己土地,通常愿意花更多的时间与精力去耕耘(例如:某个全新的模块),如果这个模块又是他一直想尝试的方面,那将会更加完美,我们有理由相信他将会在这里充满了激情。
然而世界上总没有十全十美的事情及百分百通用的方案,尽管责任到户制如此之好,但是在某些项目上我们达成不了这样的期望。
我所亲身经历过的两个版本就遇到了这样的状况。两个版本的共性是:在一个很大的系统上做覆盖面很大的,很多小点的修改(例如:更换所有UI系统),但是基于老系统的复杂性及历史问题,项目在中会遇到很多bug,各种各样,在bug没有查到原因之前并不好确定这个问题谁改动引发或是谁的责任,这种情况下责任到户制会出现失效。在面对系统这么多的bug时,项目经理很容易想到一种方法:“那就是给大家分配bug数,下指标,每天每人要解决3-4bug等”。两次项目经历中,项目经理确实都想到了这种方法,区别是前者实施了,后者被我阻止了。原因如下:
1)团队组员容易产生不被尊重感,被当成解决问题的机器
2)团队之间的协作会发生困难,而且过度强调这项指标,例如谁每天不修改完这个bug数,就要加班到10:00之类的,会导致部分组员开始取巧,每天争抢容易处理的bug
3)没法发挥人的主动性,将团队目标和个人目标相背离
这种情况下大锅饭的机制似乎更合适一些,如果团队没有达成目标则需要一起想办法或加班解决,而不是将这人归咎个某个人。
推荐策略:在正常项目中尽量使用责任到户制,而对于一些特殊项目,则选用大锅饭制,没有一成不变的方案,具体情况具体变通。
【修炼八】里程碑管理
一、背景
由于公司及部门的发展,项目经理已经开始面对人数众多,时间跨度较长的版本管理挑战。
如张湘辉(1994年加盟微软,现任微软大中华区CTO)所说:
以Windows 7为例,包含七八千万条甚至上亿条代码,五六千人同时开发,还有很多合作伙伴确保周边产品兼容。对这样一个超大的项目而言,不能一眼盯到结果,不能像跑百米一样,始终盯着终点。我们的经验是盯终点肯定乱,因为要经历非常漫长的过程。
从心理上说,当发现离终点还很遥远时,人就会泄气,不能以那么快的速度玩命跑下去。最好的方式,是将事情分成很多步骤来做。Windows7从开始到完成可能要耗时两年,以两年时间为一个周期,那么前六个月团队就会被弄垮,所以你必须以也许每两个月为一个终点。就像跑一千五百米,我们要考虑第一圈跑多快,第二圈跑多快。
这就需要把每个终点区分得很好,设定有效的里程碑,在逻辑上要很精准,是不是到了这个里程碑,同样要非常清楚。这样每个里程碑达到时,大家可以庆祝一下,重又奔向下个目标。如同爬珠穆朗玛峰,没有说不断爬上去,而是先到大本营,再到第几个营地,最后才能登顶。
从过去的3.0,BM2.0等较长时间的版本管理中,能够看出我们的里程碑管理做得并不好。以前的里程碑就是一些项目关键时间点的划分,例如:转测试,转联调等,项目组在里程碑处的行为基本就是核实是否满足进入下个阶段的标准,满足则进入。总体来说项目还是以最终发布时间点为目标,这样非常容易导致团队的疲惫。因此结合部门历史经验和其他公司的做法,产出里程碑管理的概念。
二、目的
里程碑管理目的是解决时间跨度较长或任务比较艰巨的版本管理问题。里程碑管理期望可以达到以下4个效果:
1、 使团队将长期目标划分为不同的短期目标,就像跑长跑一样,不是以5W米为目标,而是把目标分解到每一圈
2、 在里程碑处,团队进行有效的休整。就像队伍打仗时,一定要有休整,才能持续保证旺盛的战斗力
3、 促使组员进行上个阶段的总结,找出自己的不足,并吸取其他人的优点,从而让组员进行成长
4、 整理下个阶段的工作思路,促进大家进行整体思考,并对模块进行全面分析。
三、具体内容
1、给予项目组时间,进行全员总结,包括上个阶段的总结,下个阶段的工作思路,做成PPT
2、由每个人在会议上将自己的总结PPT进行分享 (做成ppt并在项目会议上进行分析,会引起大家的重视,自然效果会好)
3、进行表彰,表彰做得好的人员,由主管亲自颁发奖品(结合奖励措施)
4、用本小组经费进行欢庆,吃饭+KTV之类
四、计划支持
1、项目计划中安排好总结时间
2、制定里程碑奖励措施,并且在上个里程碑点处进行宣传,过程中进行相关数据统计
3、向公司提前申请所需的时间和金钱资源
2013.5.26
需求阶段的工作是项目经理最繁忙的一个阶段,也是项目能否做好的一个重要分水岭。通常此阶段要完成系统需求的编写,工作思路的整理,工作计划的制定,人员工作的分工,并且伴有大量的评审。如果稍有不慎就很容易被拉入到漩涡中,失去了自己,不停的被别人推着走,心情苦闷不说,还会为整个项目埋下层层地雷,才是真正的悲剧。
3、计划制定
【修炼六】时间估算的三步曲
项目绩效的重要衡量指标之一便是时间,这里总结下亲身经历的三步曲.
第一个阶段:项目经理简单估算+倒推+部门预备机动人员
优点:估算速度非常快(很多时候,项目计划都是从上级给的发布时间倒推出里程碑)
缺点:计划非常不准,项目成功率不高。主要原因是:
1)项目经理个人思维限制考虑事情不可能百分之百周全,尤其遇到新的项目经理,项目成功的几率更是直线下降。
2)部门的人员总是要干活的,当项目发生风险时,原计划的机动人员总是不够用,或是不能停下手头的事投入项目中,如果遇到多个项目同时需要机动人员支援时,整体部门基本要全线加班,集体奋斗了。
3)项目组成员参与度不够,如果工作加班,有一定怨言
总体来说:还好每当这时候项目经理都能身先士卒加班,这时候部门的同事都是难兄难弟,总是很辛苦,但是项目结果总是不理想,不能按期交付。
第二个阶段:公司级形成估算团队做专家估算
为了改进估算,同时保证各部门绩效的公平性,公司针对A部门的项目会找其他的部门的专家参与估算,估算使用3点发计算出版本时间点,如果某个专家估算的不 准,则要求重新估算或当面讨论,最终取得一致后将成为项目发布的绩效点.
优点:相对公平,有一定信服力
缺点:
1)容易出现扯皮现象,项目估算时间很长,并且外部估算的时间计划难以转化为内部计划,工作量浪费很大。
2)专家质量与主动参与度难以保证,尤其是参加多次估算后,专家容易倦怠
3)公司不关注人员分配,不考虑具体项目的最长路径,计算时间公式为:工作量/人力=项目时间
4)项目组成员参与度不够,如果工作加班,有一定怨言
总体来说:公司级的估算是CMMI引进到公司的,起到了很大作用,但是一定程度上造成了公司级的RDM组织和部门的对立,能力强的项目经理能够做很多线下活动,从而得到自己的绩效时间期望。
第三个阶段:部门自下向上估算+专家指导
其实第二个阶段和第三个阶段在一定程度上是有重叠的,第二阶段中,有一些先知先觉的项目经理,在公司开始进行估算前,首先进行了内部自下向上的估算,这样自己知道了自己的底限,如果有关键路径消除不掉,则要在总工作量加大,以达成自己的预期.
第三阶段主要的特点是项目估算以部门及项目为主导,当出现关键路径后,部门或公司专家帮助消除,如果消除不了,以项目估算为准做绩效点。
优点:
1)能够保证信服力
2)鼓励项目经理一开始把版本事情考虑周全,如果项目计划可行性非常高
3)全体项目人员参与的估算,更加准确,并且成员愿意为自己估算的时间负责
4)RDM和部门关系形成互助关系
5)估算结束后,直接产出可执行的项目计划
缺点:
1)估算周期稍长,通常需求基线后1-2周能给出
总体来说:这种方法是我个人最推崇的方法,能够有效提高员工的参与度及估算的准确度,同时维持组织的互助性,对版本成功非常有帮助。
【修炼七】团队建设-尊重
知识型工作者只有让他们感到被尊重,被认可才能激发出他们的工作热情。制造业工厂监工式的管理方法,绝对量化的考核指标在知识型团队管理中将会失效,
这是管理人员面临的挑战,德鲁克也在《卓有成效的管理者》中对管理者和这种监工做了明确区分,其中的观点是监工是上司,但不是管理者。
一个抱着积极、认真负责,打拼事业心态的员工做事的有效产出和机械完成任务的人员的有效产出是多么的不对等,这里不需要再列举各类研究结果。尊重是激励文化构建的基石,如果没有尊重,激励就是空中楼阁亦或是短暂的激情。本篇笔记重点谈谈在项目管理过程中对如何给予员工足够的尊重。
1、项目的意义
成就感是让团队努力向前的最好激励方案,任何项目的成立都是有意义的,如果能够让整个项目团队时刻清晰的认识到自己是再做一件对部门、乃至对公司意义重大的事,则往往能够焕发出团队很强的战斗力。受到关注就会给人被看重感,人就感觉到要对事情付更多的责任。
推荐策略:1)项目启动时,高层领导进行动员,宣传项目意义
2)项目中期,规划负责人/项目经理要能定期发出
一些
市场人员/客户对项目的
期望
3)项目结束后,高层领导要能够反馈项目获得的成绩
2、项目时间估算
我个人比较推崇的估算方法是自下向上的估算(具体可以上篇文章:时间估算的三步曲),自下向上的估算能够给予项目组员一定的
发言权及主人翁感,并且能够调动大家责任心,通常大家愿意为自己的决定负责,但是如果是领导直接压下来的任务尤其比较紧急时,通常有些抵触。当然在自下向上的估算中,要有专家进行指导和把关,包括估算漏掉的哪些事情,项目组内例行需要消耗的时间等,并且针对”狮子大开口“的时间需要进行讨论,达成一致。
在这种估算方法做出的项目计划下,如果项目最后出现了问题,尽管项目经理要承担直接责任,但是项目团队成员通常会比较自主的愿意与团队共度难关。因为决策是大家一起制定出来的。
推荐策略:尽量使用自下向上+专家指导的方法进行估算,如果有人员到位或者估算周期的有限制,至少要保证关键人员的参与,而慎用自上向下的估算方法.
3、善用加班文化
IT公司加班是件很自然的事情,如果哪家公司没有加班情况,反而会让人感觉不正常。做为项目经理应该首先理解,加班虽然是IT公司的普遍现象,但是确实是组员为了项目做出了额外的奉献,他们牺牲与家人团聚的时间,牺牲了休息时间,甚至影响了健康。这种行为值得我们尊重,我们要小心使用这项权力。
1)不要动不动就抛出一句“
这个今天搞不定,就打地铺解决”等,这种言论是对员工额外奉献的一个严重的漠视,而且带着很强的个人意愿
2)时时保证项目的进展的透明性,可以通过周会,日报的形式在团队中发布。当遇到赶工时,跟当事人讲解当前团队面临的困难,总之,加班是个艰难的决定,是为了整个团队的绩效,不是项目经理的个人意愿
3)任何加班时项目经理都应该尽量身先士卒带队
4)在一些公共场合,尤其有上级领导在时,公开表扬那些为团队做出很多额外贡献的人
5)绩效考核肯定以结果为导向,不能以加班多少论英雄,但要有其他措施安慰最辛苦的人
推荐策略:加班是一种奉献精神,我们要小心使用,认真对待。不能简单的当做管理者的权力,轻言肆用,否则久之必招其离心。
4、开放沟通的团队氛围
人都希望自己能够有发言权,能够对关心的事情产生影响。上至国家领导人的选举,下至日常的工作生活。如果发言权被长期压制,就会产生压抑和叛逆的心理。因此构建一个具有开放沟通的团队氛围则显得很重要。而往往言路开明后,项目经理总是能在一些讨论中,得到很多比预期更好的解决问题的方案。一个强权的管理者,容易获得一定程度上的执行力,但是容易被自己的盲点击败。而一个开明的管理者,往往能使用集体智慧,获得跟随者,更容易产生威望。
推荐策略:1)项目沙盘等关键策略制定时,要全体项目参与讨论
2)项目经理鼓励大家发现问题,提问问题,对于好的措施,能够采纳执行
5、责任到户 VS 大锅饭
从头到尾的
责任到户制应该是最理想的工作分配方式了,在这种分配方式下,团队成员有一块自己土地,通常愿意花更多的时间与精力去耕耘(例如:某个全新的模块),如果这个模块又是他一直想尝试的方面,那将会更加完美,我们有理由相信他将会在这里充满了激情。
然而世界上总没有十全十美的事情及百分百通用的方案,尽管责任到户制如此之好,但是在某些项目上我们达成不了这样的期望。
我所亲身经历过的两个版本就遇到了这样的状况。两个版本的共性是:在一个很大的系统上做覆盖面很大的,很多小点的修改(例如:更换所有UI系统),但是基于老系统的复杂性及历史问题,项目在中会遇到很多bug,各种各样,在bug没有查到原因之前并不好确定这个问题谁改动引发或是谁的责任,这种情况下责任到户制会出现失效。在面对系统这么多的bug时,项目经理很容易想到一种方法:“那就是给大家分配bug数,下指标,每天每人要解决3-4bug等”。两次项目经历中,项目经理确实都想到了这种方法,区别是前者实施了,后者被我阻止了。原因如下:
1)团队组员容易产生不被尊重感,被当成解决问题的机器
2)团队之间的协作会发生困难,而且过度强调这项指标,例如谁每天不修改完这个bug数,就要加班到10:00之类的,会导致部分组员开始取巧,每天争抢容易处理的bug
3)没法发挥人的主动性,将团队目标和个人目标相背离
这种情况下大锅饭的机制似乎更合适一些,如果团队没有达成目标则需要一起想办法或加班解决,而不是将这人归咎个某个人。
推荐策略:在正常项目中尽量使用责任到户制,而对于一些特殊项目,则选用大锅饭制,没有一成不变的方案,具体情况具体变通。
【修炼八】里程碑管理
一、背景
由于公司及部门的发展,项目经理已经开始面对人数众多,时间跨度较长的版本管理挑战。
如张湘辉(1994年加盟微软,现任微软大中华区CTO)所说:
以Windows 7为例,包含七八千万条甚至上亿条代码,五六千人同时开发,还有很多合作伙伴确保周边产品兼容。对这样一个超大的项目而言,不能一眼盯到结果,不能像跑百米一样,始终盯着终点。我们的经验是盯终点肯定乱,因为要经历非常漫长的过程。
从心理上说,当发现离终点还很遥远时,人就会泄气,不能以那么快的速度玩命跑下去。最好的方式,是将事情分成很多步骤来做。Windows7从开始到完成可能要耗时两年,以两年时间为一个周期,那么前六个月团队就会被弄垮,所以你必须以也许每两个月为一个终点。就像跑一千五百米,我们要考虑第一圈跑多快,第二圈跑多快。
这就需要把每个终点区分得很好,设定有效的里程碑,在逻辑上要很精准,是不是到了这个里程碑,同样要非常清楚。这样每个里程碑达到时,大家可以庆祝一下,重又奔向下个目标。如同爬珠穆朗玛峰,没有说不断爬上去,而是先到大本营,再到第几个营地,最后才能登顶。
从过去的3.0,BM2.0等较长时间的版本管理中,能够看出我们的里程碑管理做得并不好。以前的里程碑就是一些项目关键时间点的划分,例如:转测试,转联调等,项目组在里程碑处的行为基本就是核实是否满足进入下个阶段的标准,满足则进入。总体来说项目还是以最终发布时间点为目标,这样非常容易导致团队的疲惫。因此结合部门历史经验和其他公司的做法,产出里程碑管理的概念。
二、目的
里程碑管理目的是解决时间跨度较长或任务比较艰巨的版本管理问题。里程碑管理期望可以达到以下4个效果:
1、 使团队将长期目标划分为不同的短期目标,就像跑长跑一样,不是以5W米为目标,而是把目标分解到每一圈
2、 在里程碑处,团队进行有效的休整。就像队伍打仗时,一定要有休整,才能持续保证旺盛的战斗力
3、 促使组员进行上个阶段的总结,找出自己的不足,并吸取其他人的优点,从而让组员进行成长
4、 整理下个阶段的工作思路,促进大家进行整体思考,并对模块进行全面分析。
三、具体内容
1、给予项目组时间,进行全员总结,包括上个阶段的总结,下个阶段的工作思路,做成PPT
2、由每个人在会议上将自己的总结PPT进行分享 (做成ppt并在项目会议上进行分析,会引起大家的重视,自然效果会好)
3、进行表彰,表彰做得好的人员,由主管亲自颁发奖品(结合奖励措施)
4、用本小组经费进行欢庆,吃饭+KTV之类
四、计划支持
1、项目计划中安排好总结时间
2、制定里程碑奖励措施,并且在上个里程碑点处进行宣传,过程中进行相关数据统计
3、向公司提前申请所需的时间和金钱资源
【修炼七】团队建设-尊重
知识型工作者只有让他们感到被尊重,被认可才能激发出他们的工作热情。制造业工厂监工式的管理方法,绝对量化的考核指标在知识型团队管理中将会失效,
这是管理人员面临的挑战,德鲁克也在《卓有成效的管理者》中对管理者和这种监工做了明确区分,其中的观点是监工是上司,但不是管理者。
一个抱着积极、认真负责,打拼事业心态的员工做事的有效产出和机械完成任务的人员的有效产出是多么的不对等,这里不需要再列举各类研究结果。尊重是激励文化构建的基石,如果没有尊重,激励就是空中楼阁亦或是短暂的激情。本篇笔记重点谈谈在项目管理过程中对如何给予员工足够的尊重。
1、项目的意义
成就感是让团队努力向前的最好激励方案,任何项目的成立都是有意义的,如果能够让整个项目团队时刻清晰的认识到自己是再做一件对部门、乃至对公司意义重大的事,则往往能够焕发出团队很强的战斗力。受到关注就会给人被看重感,人就感觉到要对事情付更多的责任。
推荐策略:1)项目启动时,高层领导进行动员,宣传项目意义
2)项目中期,规划负责人/项目经理要能定期发出
一些
市场人员/客户对项目的
期望
3)项目结束后,高层领导要能够反馈项目获得的成绩
2、项目时间估算
我个人比较推崇的估算方法是自下向上的估算(具体可以上篇文章:时间估算的三步曲),自下向上的估算能够给予项目组员一定的
发言权及主人翁感,并且能够调动大家责任心,通常大家愿意为自己的决定负责,但是如果是领导直接压下来的任务尤其比较紧急时,通常有些抵触。当然在自下向上的估算中,要有专家进行指导和把关,包括估算漏掉的哪些事情,项目组内例行需要消耗的时间等,并且针对”狮子大开口“的时间需要进行讨论,达成一致。
在这种估算方法做出的项目计划下,如果项目最后出现了问题,尽管项目经理要承担直接责任,但是项目团队成员通常会比较自主的愿意与团队共度难关。因为决策是大家一起制定出来的。
推荐策略:尽量使用自下向上+专家指导的方法进行估算,如果有人员到位或者估算周期的有限制,至少要保证关键人员的参与,而慎用自上向下的估算方法.
3、善用加班文化
IT公司加班是件很自然的事情,如果哪家公司没有加班情况,反而会让人感觉不正常。做为项目经理应该首先理解,加班虽然是IT公司的普遍现象,但是确实是组员为了项目做出了额外的奉献,他们牺牲与家人团聚的时间,牺牲了休息时间,甚至影响了健康。这种行为值得我们尊重,我们要小心使用这项权力。
1)不要动不动就抛出一句“
这个今天搞不定,就打地铺解决”等,这种言论是对员工额外奉献的一个严重的漠视,而且带着很强的个人意愿
2)时时保证项目的进展的透明性,可以通过周会,日报的形式在团队中发布。当遇到赶工时,跟当事人讲解当前团队面临的困难,总之,加班是个艰难的决定,是为了整个团队的绩效,不是项目经理的个人意愿
3)任何加班时项目经理都应该尽量身先士卒带队
4)在一些公共场合,尤其有上级领导在时,公开表扬那些为团队做出很多额外贡献的人
5)绩效考核肯定以结果为导向,不能以加班多少论英雄,但要有其他措施安慰最辛苦的人
推荐策略:加班是一种奉献精神,我们要小心使用,认真对待。不能简单的当做管理者的权力,轻言肆用,否则久之必招其离心。
4、开放沟通的团队氛围
人都希望自己能够有发言权,能够对关心的事情产生影响。上至国家领导人的选举,下至日常的工作生活。如果发言权被长期压制,就会产生压抑和叛逆的心理。因此构建一个具有开放沟通的团队氛围则显得很重要。而往往言路开明后,项目经理总是能在一些讨论中,得到很多比预期更好的解决问题的方案。一个强权的管理者,容易获得一定程度上的执行力,但是容易被自己的盲点击败。而一个开明的管理者,往往能使用集体智慧,获得跟随者,更容易产生威望。
推荐策略:1)项目沙盘等关键策略制定时,要全体项目参与讨论
2)项目经理鼓励大家发现问题,提问问题,对于好的措施,能够采纳执行
5、责任到户 VS 大锅饭
从头到尾的
责任到户制应该是最理想的工作分配方式了,在这种分配方式下,团队成员有一块自己土地,通常愿意花更多的时间与精力去耕耘(例如:某个全新的模块),如果这个模块又是他一直想尝试的方面,那将会更加完美,我们有理由相信他将会在这里充满了激情。
然而世界上总没有十全十美的事情及百分百通用的方案,尽管责任到户制如此之好,但是在某些项目上我们达成不了这样的期望。
我所亲身经历过的两个版本就遇到了这样的状况。两个版本的共性是:在一个很大的系统上做覆盖面很大的,很多小点的修改(例如:更换所有UI系统),但是基于老系统的复杂性及历史问题,项目在中会遇到很多bug,各种各样,在bug没有查到原因之前并不好确定这个问题谁改动引发或是谁的责任,这种情况下责任到户制会出现失效。在面对系统这么多的bug时,项目经理很容易想到一种方法:“那就是给大家分配bug数,下指标,每天每人要解决3-4bug等”。两次项目经历中,项目经理确实都想到了这种方法,区别是前者实施了,后者被我阻止了。原因如下:
1)团队组员容易产生不被尊重感,被当成解决问题的机器
2)团队之间的协作会发生困难,而且过度强调这项指标,例如谁每天不修改完这个bug数,就要加班到10:00之类的,会导致部分组员开始取巧,每天争抢容易处理的bug
3)没法发挥人的主动性,将团队目标和个人目标相背离
这种情况下大锅饭的机制似乎更合适一些,如果团队没有达成目标则需要一起想办法或加班解决,而不是将这人归咎个某个人。
推荐策略:在正常项目中尽量使用责任到户制,而对于一些特殊项目,则选用大锅饭制,没有一成不变的方案,具体情况具体变通。
【修炼八】里程碑管理
一、背景
由于公司及部门的发展,项目经理已经开始面对人数众多,时间跨度较长的版本管理挑战。
如张湘辉(1994年加盟微软,现任微软大中华区CTO)所说:
以Windows 7为例,包含七八千万条甚至上亿条代码,五六千人同时开发,还有很多合作伙伴确保周边产品兼容。对这样一个超大的项目而言,不能一眼盯到结果,不能像跑百米一样,始终盯着终点。我们的经验是盯终点肯定乱,因为要经历非常漫长的过程。
从心理上说,当发现离终点还很遥远时,人就会泄气,不能以那么快的速度玩命跑下去。最好的方式,是将事情分成很多步骤来做。Windows7从开始到完成可能要耗时两年,以两年时间为一个周期,那么前六个月团队就会被弄垮,所以你必须以也许每两个月为一个终点。就像跑一千五百米,我们要考虑第一圈跑多快,第二圈跑多快。
这就需要把每个终点区分得很好,设定有效的里程碑,在逻辑上要很精准,是不是到了这个里程碑,同样要非常清楚。这样每个里程碑达到时,大家可以庆祝一下,重又奔向下个目标。如同爬珠穆朗玛峰,没有说不断爬上去,而是先到大本营,再到第几个营地,最后才能登顶。
从过去的3.0,BM2.0等较长时间的版本管理中,能够看出我们的里程碑管理做得并不好。以前的里程碑就是一些项目关键时间点的划分,例如:转测试,转联调等,项目组在里程碑处的行为基本就是核实是否满足进入下个阶段的标准,满足则进入。总体来说项目还是以最终发布时间点为目标,这样非常容易导致团队的疲惫。因此结合部门历史经验和其他公司的做法,产出里程碑管理的概念。
二、目的
里程碑管理目的是解决时间跨度较长或任务比较艰巨的版本管理问题。里程碑管理期望可以达到以下4个效果:
1、 使团队将长期目标划分为不同的短期目标,就像跑长跑一样,不是以5W米为目标,而是把目标分解到每一圈
2、 在里程碑处,团队进行有效的休整。就像队伍打仗时,一定要有休整,才能持续保证旺盛的战斗力
3、 促使组员进行上个阶段的总结,找出自己的不足,并吸取其他人的优点,从而让组员进行成长
4、 整理下个阶段的工作思路,促进大家进行整体思考,并对模块进行全面分析。
三、具体内容
1、给予项目组时间,进行全员总结,包括上个阶段的总结,下个阶段的工作思路,做成PPT
2、由每个人在会议上将自己的总结PPT进行分享 (做成ppt并在项目会议上进行分析,会引起大家的重视,自然效果会好)
3、进行表彰,表彰做得好的人员,由主管亲自颁发奖品(结合奖励措施)
4、用本小组经费进行欢庆,吃饭+KTV之类
四、计划支持
1、项目计划中安排好总结时间
2、制定里程碑奖励措施,并且在上个里程碑点处进行宣传,过程中进行相关数据统计
3、向公司提前申请所需的时间和金钱资源
【修炼八】里程碑管理
一、背景
由于公司及部门的发展,项目经理已经开始面对人数众多,时间跨度较长的版本管理挑战。
如张湘辉(1994年加盟微软,现任微软大中华区CTO)所说:
以Windows 7为例,包含七八千万条甚至上亿条代码,五六千人同时开发,还有很多合作伙伴确保周边产品兼容。对这样一个超大的项目而言,不能一眼盯到结果,不能像跑百米一样,始终盯着终点。我们的经验是盯终点肯定乱,因为要经历非常漫长的过程。
从心理上说,当发现离终点还很遥远时,人就会泄气,不能以那么快的速度玩命跑下去。最好的方式,是将事情分成很多步骤来做。Windows7从开始到完成可能要耗时两年,以两年时间为一个周期,那么前六个月团队就会被弄垮,所以你必须以也许每两个月为一个终点。就像跑一千五百米,我们要考虑第一圈跑多快,第二圈跑多快。
这就需要把每个终点区分得很好,设定有效的里程碑,在逻辑上要很精准,是不是到了这个里程碑,同样要非常清楚。这样每个里程碑达到时,大家可以庆祝一下,重又奔向下个目标。如同爬珠穆朗玛峰,没有说不断爬上去,而是先到大本营,再到第几个营地,最后才能登顶。
从过去的3.0,BM2.0等较长时间的版本管理中,能够看出我们的里程碑管理做得并不好。以前的里程碑就是一些项目关键时间点的划分,例如:转测试,转联调等,项目组在里程碑处的行为基本就是核实是否满足进入下个阶段的标准,满足则进入。总体来说项目还是以最终发布时间点为目标,这样非常容易导致团队的疲惫。因此结合部门历史经验和其他公司的做法,产出里程碑管理的概念。
二、目的
里程碑管理目的是解决时间跨度较长或任务比较艰巨的版本管理问题。里程碑管理期望可以达到以下4个效果:
1、 使团队将长期目标划分为不同的短期目标,就像跑长跑一样,不是以5W米为目标,而是把目标分解到每一圈
2、 在里程碑处,团队进行有效的休整。就像队伍打仗时,一定要有休整,才能持续保证旺盛的战斗力
3、 促使组员进行上个阶段的总结,找出自己的不足,并吸取其他人的优点,从而让组员进行成长
4、 整理下个阶段的工作思路,促进大家进行整体思考,并对模块进行全面分析。
三、具体内容
1、给予项目组时间,进行全员总结,包括上个阶段的总结,下个阶段的工作思路,做成PPT
2、由每个人在会议上将自己的总结PPT进行分享 (做成ppt并在项目会议上进行分析,会引起大家的重视,自然效果会好)
3、进行表彰,表彰做得好的人员,由主管亲自颁发奖品(结合奖励措施)
4、用本小组经费进行欢庆,吃饭+KTV之类
四、计划支持
1、项目计划中安排好总结时间
2、制定里程碑奖励措施,并且在上个里程碑点处进行宣传,过程中进行相关数据统计
3、向公司提前申请所需的时间和金钱资源
一、背景
由于公司及部门的发展,项目经理已经开始面对人数众多,时间跨度较长的版本管理挑战。
如张湘辉(1994年加盟微软,现任微软大中华区CTO)所说:
以Windows 7为例,包含七八千万条甚至上亿条代码,五六千人同时开发,还有很多合作伙伴确保周边产品兼容。对这样一个超大的项目而言,不能一眼盯到结果,不能像跑百米一样,始终盯着终点。我们的经验是盯终点肯定乱,因为要经历非常漫长的过程。
从心理上说,当发现离终点还很遥远时,人就会泄气,不能以那么快的速度玩命跑下去。最好的方式,是将事情分成很多步骤来做。Windows7从开始到完成可能要耗时两年,以两年时间为一个周期,那么前六个月团队就会被弄垮,所以你必须以也许每两个月为一个终点。就像跑一千五百米,我们要考虑第一圈跑多快,第二圈跑多快。
这就需要把每个终点区分得很好,设定有效的里程碑,在逻辑上要很精准,是不是到了这个里程碑,同样要非常清楚。这样每个里程碑达到时,大家可以庆祝一下,重又奔向下个目标。如同爬珠穆朗玛峰,没有说不断爬上去,而是先到大本营,再到第几个营地,最后才能登顶。
从过去的3.0,BM2.0等较长时间的版本管理中,能够看出我们的里程碑管理做得并不好。以前的里程碑就是一些项目关键时间点的划分,例如:转测试,转联调等,项目组在里程碑处的行为基本就是核实是否满足进入下个阶段的标准,满足则进入。总体来说项目还是以最终发布时间点为目标,这样非常容易导致团队的疲惫。因此结合部门历史经验和其他公司的做法,产出里程碑管理的概念。
二、目的
里程碑管理目的是解决时间跨度较长或任务比较艰巨的版本管理问题。里程碑管理期望可以达到以下4个效果:
1、 使团队将长期目标划分为不同的短期目标,就像跑长跑一样,不是以5W米为目标,而是把目标分解到每一圈
2、 在里程碑处,团队进行有效的休整。就像队伍打仗时,一定要有休整,才能持续保证旺盛的战斗力
3、 促使组员进行上个阶段的总结,找出自己的不足,并吸取其他人的优点,从而让组员进行成长
4、 整理下个阶段的工作思路,促进大家进行整体思考,并对模块进行全面分析。
三、具体内容
1、给予项目组时间,进行全员总结,包括上个阶段的总结,下个阶段的工作思路,做成PPT
2、由每个人在会议上将自己的总结PPT进行分享 (做成ppt并在项目会议上进行分析,会引起大家的重视,自然效果会好)
3、进行表彰,表彰做得好的人员,由主管亲自颁发奖品(结合奖励措施)
4、用本小组经费进行欢庆,吃饭+KTV之类
四、计划支持
1、项目计划中安排好总结时间
2、制定里程碑奖励措施,并且在上个里程碑点处进行宣传,过程中进行相关数据统计
3、向公司提前申请所需的时间和金钱资源
【修炼九】总设/概设/详设
2013.6.2
设计能力是技术人员水平的主要象征之一,项目组的技术人员跋涉了前面的各个阶段,终于迎来了由他们自己主导的时间。优秀系统的总设、优秀的模块的概设追根到底是设计人员的自己能力的展现,这要求他们有足够的视野,经验和思考。项目管理在设计阶段主要起到的作用是:
1、帮助设计经验不足的组员进行缺陷预防,保住设计质量的底线
2、给予经验丰富的专家以明确的目标,以便进一步提高设计的质量
3、降低返工的风险
按照项目的五要素,设计阶段分为以下阶段(图片可放大网页看):
![](https://img-blog.csdn.net/20130602213212828)
1、干系人期望-目标
在项目流程中划分总设,概设,详设的主要目的是:
总设:根据架构和需求将系统划分为多个功能和基础模块,并定义清这些模块的交互方法及接口。
概设:模块概要设计是将模块拆分成多个子模块,并定义清子模块间的交互方法及接口。
详设:将每个子模块的内部逻辑,流程图,甚至伪代码理清,为后续的编码直接服务。
在设计阶段常见的干系人:
1)主管/产品经理:他们主要期望产品的稳定性及扩展性,通常一个设计被大家认可,至少要包含这两方面中一个因素。
基础功能的稳定性能够迎来客户的好感,而扩展性能够降低后续再次开发的工作量,会被主管和产品经理所期望。稳定性通常在产品需求中会进行要求,
扩展性往往是可以获得亮点的突破口。
2)技术支持人员/客服人员:他们期望系统及模块能够被方便的调试排查问题,即设计的可维护性。
3)测试团队:测试期望开发在设计阶段能够考虑清自动化测试的方案,以便能够降低执行测试及回归测试的工作量。
4)项目经理/主管:在总设阶段能够抽出公共代码以便降低当前版本的风险及工作量,同时能够为后续的项目提供帮助。
2、沙盘-思路
1) 开始前挂牌讲解好的设计及槽糕的设计
能够做好一件事情的前提是,要当事人能够清晰“好”的判断标准是什么?如果要超预期,首先要当事人了解到“期望”是什么?因此对于新员工或是设计经验还不足的组员,能够帮他们理清“怎么样的设计才算是一个好的设计”至关重要,这样他们才能够在正确的方向上投入他们的精力。而做这件事情的一个最好的办法,就是开始设计前讲解当前部门或公司里的典型好的设计及坏的设计,如此这样能够让大家在出发前得到一个方向上的共识。需要注意的是:槽糕的设计教育的意义往往用处比好的设计更大,因为好的设计需要积累和灵感,而槽糕的设计往往是可以避免的,一个中规中矩的设计不是一个很高的要求。
2)健壮性分析
对整个系统及关键模块做健壮性分析往往非常有必要。因为当系统或关键模块遇到异常往往会给客户带来巨大的影响,甚至是不可恢复的损失。健壮性分析的主要的方法是罗列可能遇到的异常场景及系统或模块应该做出的处理如何。
例如:给客户提供用户认证的模块应该至少应考虑如下异常场景:
1)当系统内存不足时,如何保证认证的优先级
2)当进程出现假死后,如何检查出来,防止长时间无法影响认证请求
3)程序崩溃时,如何快速恢复进程
4)设备掉电或程序崩溃时,如何保证已经通过认证的客户,不用全部重新认证
等等
3)扩展性分析
扩展性对于可预计会经常变化的业务模块尤为重要。达成好的扩展性的方法是通过“高内聚,低耦合”,将业务代码和逻辑代码分离来实现。好的扩展性可以大大降低后续的开发成本,对于持续化的项目非常重要。
例如:做一个抓包的协议分析软件(譬如:wireshake),它的扩展性主要在于
1)后续可能会有更多的协议需要分析
2)后续可能会有更多的包分析结果的呈现方式
将这两部分做成插件式加载则是非常恰当的设计
4)可维护性分析(自动升级等)
可维护性设计通常包含两部分;
a、当系统或模块出现故障时是否容易排错
这里便要求系统或模块设计便提供方便的排错方法,以上面提到的用户认证为例:
例如:日志分级,我们可以将用户认证步骤分为12个步骤,并将每个步骤打印一条日志,则方便追踪问题。
内存打印,从后台输入参数可以将指定用户或所有用户当前的内存状态打印出来。
b、当系统或模块出现故障时,修复成本及风险是否可控
对于做产品的企业,一个故障排查出来后,通常外面在使用有问题的产品的客户已经很多,这时候能否方便,快速的更新则非常重要。而能否方便和快速,取决于系统或模块的可维护性。
例如:一个产品本身有自动升级功能,当前排查的故障在于网络流量更新,导致插件功能失效,同时主程序对插件有强校验,这时候我们就可以快速得将新的插件更新到网络上。
5)自动化测试分析
好的设计应该从一开始就为自动化测试进行考虑。一个系统或模块能够方便编写出基本功能的自动化测试案例对于质量是件非常有益的事情。以协议分析软件为例,我们可以设计如下的自动化方法:
a、编写一个工具可以生成指定协议的数据包
b、系统可以从文件中直接load数据包,进行协议分析,并且自动校验是否与输入期望的结果相符
6)方案选型评审
在设计开始之前,设计者应该将自己的想法及方案讲述给专家,方案选型的文档不要求复杂,可以是一封邮件,可以是一张图,但是做了这件事,能够避免设计大量返工。不得不说在工作中,经常发生一些诸如此类的感慨:“这件事怎么想成这样?” “这个肯定要重做了”等,这些都是没有做好基本思路确认的问题导致的。
3、计划制定
设计阶段的评审工作量是非常大的,如果此时项目组需要很多外部专家的把关,则需要提前和这些专家协商出一个时间并统一制定出一份评审计划,以防止评审时间延拖,导致下一个阶段的工作无法完全启动。
4、风险管理
1)太重技巧,过度设计
不得不说确实存在这样一些同事喜欢滥用或是说过度追求设计模式,本来一个不复杂的模块,生生要套上几个设计模式,搞得继承,多态一大堆,代码可读性大大下降。所以这里要需谨慎,事实往往证明经常夸夸其谈设计模式、方法的人,通常或多或少都有过度设计的毛病。因此对不熟悉的组员,不能仅根据其言行,便主观降低他的设计风险。
2)逻辑不周全,设计不足
相对于上个风险来说,对于一些设计经验不足的同事,往往习惯把一件事情看得简单化,导致编码阶段有很多意想不到的“惊喜”发生。经过好的详设后编码应该波澜不惊,不能有大波大浪。对于这些组员时,有一个基本的设计方面的流程约束就显得很必须了。 例如:详设必须把主要的函数都画出流程图,经过评审。
5、团队管理
1)新员工有师徒制
新员工往往没有什么设计理念,这时候不仅仅是评审和理清思路就可以解决问题的。这时候他们需要更加细致的指导,因此给他们安排一个师父,就很必要了。
2)评审时指定负责的专家
大家很多时候对于和自己没有直接关系的事情,会抱着得过且过的状态。在设计文档评审时,也有可能发生这样的情况。因此在评审前明确哪个专家需要对设计负责,会对质量把关非常有益处。
3)严格执行计划
经过估算后,设计阶段已然有明确的计划。制定项目计划时我们要尽量民主,但是当计划制定下来后,要维护其严肃性,不能一味的调整。
例如:有计划延期,无法调整时需要加班解决,也是在情理之中的,否则项目计划很快会成为一纸空文。
【修炼十】编码
2013.6.11
如果说一个男人最有面子的事是身边常伴漂亮的女伴,引别人侧目。那么程序员最有面子的事,一定是写下的漂亮的代码,引无数草莽感叹。
有趣的是,我们总是有机会看到这样的现象:一些老模块虽然设计不好,但是代码质量不错,所以依旧稳定,但是一些设计理念很好的模块,却被写得乱七八糟,漏洞百出。
代码是设计的最终产物,是一个程序员基本功,偷不得一分巧。如果一个人总是喜欢高谈阔论,那么去看他的代码,通常一眼看下去,就能知道他是“真正的高手”还是“空想家”。
项目管理的代码管理,通常期望达成以下几个目的:
1、避免出现杀手:“高手不是培训出来的,也不是管教出来的“,高手之所以视为高手,是因为其很少见,而成就高手的素质通常不是众生常具备的。但是项目组内的隐藏的杀手,却可以通过管理降低其出现的风险及危害。A/B角审核,签入代码控制等这些都是关卡。
2、保证代码质量:代码不一定能像高手写的那么极端漂亮,多一分便肥,少一分便瘦的地步,但是却可以通过管理保证大家代码的逻辑清晰度,可读性,减少边界错误,减少低级错误等。例如:工具扫描,单元测试,每日构建等。
3、培养人员:“近朱者赤,近墨者黑”,影响的力量是巨大的,通过编码阶段的互动交流,可以让一部分组员能够快速脱离”山寨“,进入”职业“状态,尤其对新员工有效。
按项目管理的五要素分解如下:
![]()
1、干系人期望-目标
编码阶段干系人的影响已经很小,可以先不讨论这节。
2、沙盘-思路
1)开始前挂牌讲解好的代码
同设计一样,很多时候往往不是大家不愿意写出好的代码,而是大家不知道好的代码是什么样的,因此在项目组开始编码前,讲解优秀的代码,会让组员开工之前,有一个学习的目标,会让编码工作变得更有意思。这里更好的做法找出那些和本项目组有关的优秀代码示例,更是事半功倍,例如:部门类似业务的好的代码。
2)公开走读计划
记得在管理上有个研究工作效率的故事,发现把工人召集到一个实验环境中,在设施完全一样的情况他们的工作效率和质量比平时都有大幅提高,逐个排除了很多影响因素,最后发现原来是”关注度提高“的原因。人都是有表现欲,当自己手头的上事被关注时,往往我们希望把自己最好的一面表现出来,人性如此。代码走读就是这个作用,大多数时候提前公布的走读计划比实际走读出那几个问题更重要。
安排走读计划时,需要注意到这几点;
a、走读成员要有威慑力和权威性,避免大家扯皮。例如:找专家,架构师,主管等
b、走读的结果无论好坏,都要公布,以便项目组形成一股良性氛围
c、当项目组模块很多时,可以抽查一定比例的模块走读,这样在走读计划公布时,不要明确模块,避免没有在走读计划内的模块作者,暗自庆幸。
3)A/B角审核
只有走读计划是不够的,因为走读通常要不少人参加,不可能将时间拉得过长,因此很多细的逻辑审核不到。另外走读模块往往是在这个模块代码已经或接近完成时,时间点偏晚,有些”木已成舟“的味道。和走读计划相配合的是进行A/B角审核,我们可以在设计或更早的阶段,明确项目组的A/B角关系。A/B角的好处在于,代码得到及时审核,测试阶段A/B角可以互担压力。
A/B角的常见组成方式如下:
a、项目组分成小组,组长担当B角
b、项目组有某些模块的专家,这些专家担当对应领域的B角
c、一个模块有几个人共同完成,他们互为A/B角
d、项目组不大时,由项目经理或质量经理担任B角
4)代码checklist及工具扫描
代码checklist是将大家常犯的共性错误集合成的检查表,例如:一些潜在的死锁风险,C++用法等。而工具扫描是为了排除一些低级错误,例如:内存泄露。 很多时候低级错误的排查bug的难度是不低的。
5)单元测试
做好的单元测试的核心在于两点:
a、要有好用,省时的单元测试案例编写工具,例如:C++ Test等
b、管理好单元测试案例,不能只做一次,而是每次代码发生变化,每次代码重新编译时,都能自动执行单元测试。如果单元测试只能用第一次,投入产出比,就会小很多。
c、能够在目标机上执行单元测试案例,这样能够避免大量打桩,导致工作效率下降。
6)代码签入控制
代码签入控制往往是强制A/B角的实施方法,即:收回A角的代码签入权限,只允许B角签入,如此能够保证B角的审核频率能够达到每个包一次.
7)每日构建
每日构建是指编码开始后,每天环境会自动从SVN/VSS上获取代码进行编译,并执行对应的单元测试案例,每天早上通报错误。每日构建的好处在于:系统在持续良性集成,避免联调开始后,大家一窝蜂的把代码签入,有大量的编译错误等,消除这些错误需要消耗很多时间,并容易犯错误。
3、计划制定
1) 代码走读计划
代码走读计划如上述第二点,需要提前预约专家,架构师等,并在项目组进行公布。
2) 配置管理计划
涉及到代码签入权限,编译环境维护权限等。例如:一个大项目组,如果编译环境没有控制权限,没有指定操作规范,很容易被大家搞乱套。
3) 单元测试计划
不是所有情况下,用单元都是合适的。例如:对于一个老模块的改动,此模块依赖很多外部资源,并且之前没有任何单元测试案例,这会导致编写对应改动的单元测试案例,成本很高,此时需要进行权衡投入产出,可能这时找此模块的专家进行审核是个更好的选择。
4、风险管理
1)编码进度不透明
大多数人都习惯先松后紧的工作方式。“犹记得大学时,老师布置了作业,两周期限,下课是交作业的最后期限,上课时,班上大多数同学们都是拿着借来的作业奋笔疾书”。编码阶段的时间在转集成前各阶段中,算上比较长的。而这个阶段的工作进度非常不好衡量。经常看到一个模块编码进度迅速从0%到90%,而后花了两倍的时间才从90%到100%,无法有效得知项目的进度,就是项目的风险。
这里有个好的做法可以参考,编码计划表从估算表中导出,因为估算表中每个估算项粒度通常不会超过2天。这样在编码进度表更新时,去除百分比,只能更新两种状态,未完成,完成,如此计算出的项目进度是比较准确的,同时也能够帮助组员理清当前自己的工作进度。
2)新员工代码质量
新员工的成长是需要团队付出精力的,针对他们我们往往要有更频繁的代码审核、指导 或安排责任心更强的B角。虽然新员工的操心在所难免,但是他们潜力也是无限的,耐心地培养后,总能从中收获到惊喜。
3)识别出风险模块
项目组的进度不同于齐步走,总是有前有后,质量同比也是有好有坏,那么在整个过程中通过上述的种种办法找出这些有风险的模块,进而采取调整措施是项目管理中不可缺少的部分。
4)需求实现有遗漏
任务分解时往往并不能完全根据需求进行,在代码实现时,因为大家的思维已经在很细节的层次,所以此时核对系统需求或需求跟踪矩阵,就很容易发现需求的遗漏项。
5、团队管理
1)每日构建有奖惩
有奖惩是为了提高大家对这件事的重视程度,当然每日构建通常犯的错误不是很严重,而且易于发现,针对这种场景,不适合采用过于严厉的惩处措施就不合适了。例如可以采用如下措施:
a、累计错误数,如果项目组整体达到5次,造成错误的同事请项目全体成员吃水果或喝饮料。
b、每天系统自动通告构建的结果
2)走读计划有奖惩
走读计划因为动用了外部资源,比较权威,惩处和奖励要重一些。例如:对于代码走读结果不好的组员,本季度取消得A资格,走读结果好的组员,给予奖品及季度优秀的考核。
3)进度在项目组定期通告
每周至少一次项目组在一起回顾上周的进度和下周的计划是很有必要的,这样容易让大家对整个团队产生归属感,并且能够得知其他人的工作进度,有个横比,从而能够自我进行进度调整。
4)严格执行计划
此阶段的项目计划的时间点是确定的,除非项目经理有把握控制后续的进度,否则尽量不要调整里程碑点。
1、干系人期望-目标