所谓“项目缓冲”其实只不过是加班?

现如今，关于软件项目管理的话题以及衍生出来的各种软件管理流程，确实不少；但是仅就软件项目的特点，究其本质，仍然没有太多变化，基于三角约束（范围、进度、成本）下的可交付、以及基于客户满意的软件质量。

同时，软件项目通常所面对的各种压力，与其它行业中常见的情形，也没有太多的变化，但是我们通常所看到的项目问题，往往表现为“进度问题”，为了解决这个问题，于是很多的项目都掉进了“加班赶进度”大坑，直到软件交付、回款到位。最后本着“下一个项目我们会改进”的意愿，不幸的掉入下一个大坑。

我们想“潇潇洒洒的活”，最后只不过是个“窝窝囊囊的活”，或者“窝窝囊囊的死”。

所谓的进度问题，掩盖了很多问题背后的问题，这个似乎是源自我们与生俱来的、并且受环境影响和不断强化的时间度量观念。
当还是小孩的时候，更容易被问及：还要多久才到家、还要多久才把饭吃完、还要多久才能把作业做完，而不是问：还有多远才到家、还有多少饭没吃完、还有多少作业没做完。当参加工作的之后，不断被问及的似乎就是：还有多少时间把这个功能完成、这个项目究竟还有多久才能搞定，而不是问这个功能还有多少验收条件待完成、这个项目(在当前的范围定义下)还有多少故事点/功能点没有完成。
即便是我们口头上说工作量，也会翻译成时间：某任务甲工作量比较大，5天；某任务乙工作量比较小，半天。

同时人们也非常关心钱，因此我们所做的软件项目大部分都是固定期限下的固定总价合同项目。

很多项目都不容易，需求范围蔓延、需求不断变化，期限固定、合同总价上限，没有英雄出面的情况下，只好咬紧牙关加班。


在总项目时间为6个月的启动会议上，某项目参与者用关键路径法在白板上一划，指出来这个是关键路径，我们要加项目缓冲，然后扯谈什么赚值分析法，什么加班会导致成本增加之类的，云云；另外一个人鬼扯了一通，然后基于当前的需求我们赴汤蹈火立即开始，后面需求变化了再作调整。
然后他们一同抬起屁股消失了。在后面6个月时间里，开发团队在兢兢业业工作，而他们不是在开会，就是在去开会的路上。
你期望发生的事情都不会发生，倒霉的担心最终变为现实。项目缓冲就是加班，调整就是加班，而且成本不会增加。这个我不多说，你懂的。

后来我通过Scrum了解到，这个其实就是“猪和鸡”的区别。



PMI在他们的那本砖头书《项目管理知识体系指南》对于加班说的比较委婉，叫做“赶工”，同时紧接着煞有介事的说赶工会带来成本的增加。

Ken Schwaber 在《Scrum敏捷项目管理》中，对于如何将Scrum应用于固定期限项目上，坦诚的表示暂时没有答案，但是可以将Scrum的实践部分应用于前期阶段的需求分析和软件架构搭建。Mike Cohn在《敏捷估计与规划》中，也提到了如何面对传统类型项目(相对于敏捷项目），他针对于此讨论了两种项目缓冲：功能缓冲、或者进度缓冲。前者严格遵循固定期限，但是可能会裁剪部分预期功能；后者则估计一个期限范围，并且通过渐进明细的方式使得这个期限范围更精确。在敏捷项目的语义中，唯一提到加班的地方只有一处：“不提倡加班”。


乔布斯说“工作本身就是一种奖励”大概也包括加班。在国内，据说某人也提到过“加班是不对的，但是把该完成的事情放到加班时间去做也是不对的。”这就似乎包含强制加班了。

对于一线人员，正常情形下都会比较关心 强制加班。
现如今的加班强人们不但包括了“铁人”，也包括了“牛人”（牛，都是任劳任怨的）。以Scrum为例，在敏捷的语义中，由于错过了沾手可得的机会，他们成了不受善待的猪。
敏捷不是神器，也不是银弹，但是它从几个方面提供了关于“加班”的更多观点：敏捷项目不是固定期限的，这个更符合软件项目的自然属性；敏捷项目针对于“工作量”除了给出传统时间度量定义，也提供了另外的理解；敏捷项目关注软件质量，在加班缓冲对于软件质量的伤害这个问题上，有着更客观的理解。

加班本身只是一个项目管理工具，用于对冲项目负面风险损失，或者用于争取项目正面风险价值。工具本身没有错，但是很多时候，我们的项目从一开始就把加班作为必要工具滥用之。

再回到我们前面说的“进度问题”，如果有人说，你们出现进度问题，是因为加班所致，逻辑上真的似乎不太讲得通；而如果有人说，万米长跑落败了，是因为一开始就太用力跑的缘故，这下子大家都懂。





大小: 45.9 KB
查看图片附件

效率×时间＝成果
加班增加了时间，但肯定会降低效率，所以要平衡下。

ccxw1983 写道
效率×时间＝成果
加班增加了时间，但肯定会降低效率，所以要平衡下。


这个道理说出来应该都不难懂。在一个项目团队中，不同的项目利益相关者的立场倾向肯定会有所差异。我们说需要科学的管理实践，如果项目团队中有太多“站着说话不腰痛”的人，问题首先来源于项目之外。

在项目压力下，狂加班能给人尤其给老板们安全感，在老板和一线员工之前如果存在有太多打酱油型的所谓“项目经理”，是个悲剧。

好的项目过程，不需要项目经理。

引用
在老板和一线员工之前如果存在有太多打酱油型的所谓“项目经理”


不知道你所谓的一线员工是什么，包括销售、市场、人力什么的支撑角色还是仅仅指核心的软件生产团队甚至就是指开发人员
如果你说的一线员工就是指开发人员的话，那么恭喜，项目经理还真的是打酱油的

我们销售可以不力乱答应客户，市场营销可以很烂搞不清楚方向，HR可以招实习生来凑人头，架构师可以乱搞，需求分析可以稀里糊涂，而且有各种客观理由不能做到更好，但是开发人员不在底线时间内做出东西，那就是千夫所指，除了加班还有其他路么？

估计你公司的打酱油项目经理也就是个开发头目，没权力管上面那帮人，连影响上面那帮人的能力也没有
那他除了酱油还能做什么？

所谓好的项目过程不需要项目经理，估计你是敏捷看多了。
你项目经理还在打酱油阶段，谈这个还早
等到了团队内每个成员都有自我管理意识，都懂什么管理再说吧

如果把项目管理=软件开发管理，那只有无语了，太多打酱油的玷污了项目管理这个词

谢谢答复，最初个人只是随便写写，不曾想到还是有朋友能把这个帖子抬起来。


seeckt 写道
引用
在老板和一线员工之前如果存在有太多打酱油型的所谓“项目经理”


不知道你所谓的一线员工是什么，包括销售、市场、人力什么的支撑角色还是仅仅指核心的软件生产团队甚至就是指开发人员
如果你说的一线员工就是指开发人员的话，那么恭喜，项目经理还真的是打酱油的

我们销售可以不力乱答应客户，市场营销可以很烂搞不清楚方向，HR可以招实习生来凑人头，架构师可以乱搞，需求分析可以稀里糊涂，而且有各种客观理由不能做到更好，但是开发人员不在底线时间内做出东西，那就是千夫所指，除了加班还有其他路么？


我文字使用上并不太严谨，这里说的一线员工，确实说的是开发测试人员。因为本人作为程序员工作了一些年，得到的一些总结也限于个人，并不准备拿来立论，只限于分享的目的。
开发人员不在底线时间做出东西，原因有多种。这个就好比销售上不能在一段时间内完成销售指标。可能是水平能力问题，也可能是运气，也有可能是大跃进式的目标所致。
总体说来，我不太同意你说的开发人员不能在底线时间做出东西，就必须加班：视情况而定，如果开发已经在尽力了，加班并不能得到更好的效果。
但可以也许可以是"千夫所指"：因为错过时间窗导致市场机会丧失。只是这里要被千夫所指的，不应该仅仅是开发人员。


引用

估计你公司的打酱油项目经理也就是个开发头目，没权力管上面那帮人，连影响上面那帮人的能力也没有
那他除了酱油还能做什么？


不涉及任何具体的公司，但你这里提到的现象在我工作过的公司里确实存在，程度不同。



引用

所谓好的项目过程不需要项目经理，估计你是敏捷看多了。
你项目经理还在打酱油阶段，谈这个还早
等到了团队内每个成员都有自我管理意识，都懂什么管理再说吧

如果把项目管理=软件开发管理，那只有无语了，太多打酱油的玷污了项目管理这个词


我敏捷看的不多，敏捷开发实践经验也没几年。我们的观点不同，但是站在敏捷的角度，唯一能做的就是信任你的团队成员，并且他们也不必须要懂管理。

“项目管理”这个词现如今已经严重兑水，所以一般也不太好意思、也不太有自信跟人说我是项目经理。

这里说的“不需要项目经理”，这句话本身其实漏洞很多，在Scrum中所谓的“不需要Manager”，是因为在Scrum提倡的敏捷过程框架中，manager这个角色是没有的；而所谓的不需要项目经理，大概是因为从传统项目过程转型而来的很多团队，如果他们保留了项目经理这个角色，最后可能只是做到表面上的“敏捷”。事实上我们的项目一开始不必须要做到“是不是敏捷、是不是Scrum”，但是基本上如果用脑思考、亲身实践，你最后做的很多事情就是敏捷倡导的。

关于“软件开发管理”，暂时无法界定其概念范围，因为大到产品管理、项目管理、小到软件项目工程实践，或者软件规模度量、需求分析之类的等等，都可以作为纳入其中。这里我就不跟这个话题了。:)

我有个领导也去研究过敏捷，结果人家说你搞不成，因为你的团队还不够优秀

后来我想想，确实如此。
不需要有项目管理者，那是需要每个人都能够自我管理，或者互相补完以后能够完成自我管理。

每个人都是自己的公司
完成一项任务 -- 项目管理
持续总结经验教训 -- 运营管理
自我激励、学习培训 -- 人力资源
考虑怎么使自己能力谋求更大收益 -- 市场营销
和新公司谈判薪酬 -- 商务
沟通、办公室政治 -- 公关
包打听 -- 商情
……
说实在的，在现在环境下我还真没见过几个人有这样宽广的视野和知识技能，有的基本也是经理总监往上了
往往搞开发的就是只关注码代码的一坨人，其他方面一概无视或鄙视

现在IT人太多从码农的视角看问题的了，事实上码代码只是项目活动的很小一部分，我们理解上的项目也只是真实项目的一部分，比如商务不去跑到单子，我们PM连立项都搞不成
而实际上我们常常把码代码看成近似于项目的全部， 把其他参与项目的角色当成酱油、忽悠
太强调自己在项目中的作用，那当然有我们不愿意看到的效果
因为责权利是一致的，如果自己都认为项目成功基本是靠码代码，那项目完不成的时候你不加班谁加班?

引用
基本上如果用脑思考、亲身实践


我喜欢关注风险管理，会把国际、国家、行业环境变动放在风险列表的第一条，
把未知风险放在风险列表的最后一条
这个就是表现了对未知风险持续的探索

平时多看看风险列表，想想有什么风险没有被识别，已识别的风险是否有应对方法
如果大多数风险都在变成问题前被消灭掉了，
那么后面项目过程就是该验收的验收，该回款的回款
好的项目是没有故事的，
不需要惊心动魄的情节，不需要个人能力精彩体现，甚至不需要组织关注
当然也基本不需要加班
反过来说，我经历过几个加班厉害的项目，大多做成了烂账

敏捷光用在开发上是不够的，公司也要能够拥抱变化，勇于重构

引用
我有个领导也去研究过敏捷，结果人家说你搞不成，因为你的团队还不够优秀

后来我想想，确实如此。
不需要有项目管理者，那是需要每个人都能够自我管理，或者互相补完以后能够完成自我管理。



我也是这么认为的  敏捷团队里面很强调"信任",但同时也需要"热情",这个"热情",大概就是从成员对于项目的主人翁精神和态度上来说的。从常理上来讲,要我们信任一个人，至少是某些方面要过得去，最好能达到"优秀"。

敏捷项目框架可以被裁减和调整，因为敏捷本身是一个目标，而不是具体的做法或者手段。有些项目要实施敏捷，在一些场合中会非常困难，例如人员技能素质无法实施TDD测试驱动开发；或者由于工作单位体制以及文化的原因，竭力阻止敏捷所带来的变革和各团体利益之间新的冲突。

总之搞不成敏捷，不够优秀肯定不行（但50%的敏捷也许够，事在人为，有那份心最重要），够优秀也未必行。


引用

现在IT人太多从码农的视角看问题的了，事实上码代码只是项目活动的很小一部分，我们理解上的项目也只是真实项目的一部分，比如商务不去跑到单子，我们PM连立项都搞不成
而实际上我们常常把码代码看成近似于项目的全部， 把其他参与项目的角色当成酱油、忽悠
太强调自己在项目中的作用，那当然有我们不愿意看到的效果
因为责权利是一致的，如果自己都认为项目成功基本是靠码代码，那项目完不成的时候你不加班谁加班?


敏捷项目环境其实是一个理想国，现今阶段还是比较少见。敏捷项目倾向于非固定期限、非固定合同总价的，作为咨询类型项目，按工料合同签订的项目，与敏捷应该是一个比较理想的搭配。当然是否能够敏捷，首先要从销售阶段解决问题，客户是否认同是关键。
除了项目类型的定性；另外一方面也是因为牵扯到一群人一起做事，涉及到人性因素，个中因素有时候会变得微妙和不必要的复杂。

固定期限固定总价的合同项目，在市场竞争和成本压力下，出现很多“不可能完成的任务”，项目的环境已经被扭曲，再加之所处的项目链上如果是在下游，这个时候不是敏捷不敏捷的问题，基本上没有救药。不敏捷也许更好。

我个人把敏捷当做一个理想状态，能带来的好处不只是工作上的，"敏捷是一种生活方式”，因为它让你的工作和生活更加均衡。
还有很远的路要继续走......

热情这个东西在中国很不好说
西方的码农已经到了自我实现层面了，从出生保医疗，成长保教育，结婚给房子外带家电家具，失业了还有一两年救济金拿……
中国呢，哪怕高收入，来个通货膨胀、结婚生子或者家庭成员重病，生活就没保障，谈何自我实现
对于3、4K收入的底层员工，公司企业文化做的再好、再关系员工生活关系员工职业发展，房租涨个500、1000的，该走人还是走人
社会保障不起来，垄断不消灭，却要求企业搞产业结构改革而不再靠低人工成本的血汗工厂纯粹在推卸责任，这种形势下引进敏捷、CMMI、PMP什么的都是企业在自救，但是由于先天畸形，成长也是不完全的，全盘照读是找死，就算按自己的情况转化管理思想，也是背了国家转嫁过来的巨大风险

因为加班可能没有多少加班费或者没有，所以才这么想的。

如果加班按 1.5 倍或2倍计算。可工作时间却是1倍，猪都会算啊。加班效率会降低

将加班纳入项目计划的人基本上管理不到位。
除非真的是没办法，短时间内必须的。