细粒度的迭代计划到底要做到多细?

>>因为你有一天不在公司了，公司就像丢了半壁江山，反之，即使你离开公司，公司依然能有效的运行，这也是职业道德。

如果我哪天突然离开公司，公司还屁事没有的照常运转，说明我是在这里尸位素餐。混日子就是你的“职业道德”？

我要在一家公司干，我要拿比别人高的薪水，就是因为我在这个位置能做别人做不到的事，能起别人起不到的作用。做只有我才能做的贡献，这是我的职业道德。想办法创造条件让我不要走，这也是公司另外某些人的职业道德呢。

我觉得你的比喻不合理，你只看到制度中人的部分，而忽视了其他的部分，奥尼尔和姚明也不是一个人去打满全场，他也需要队友的配合，为什么同样的球队，同样的队员，有的主帅带就能拿总冠军，有的主帅就搞的一团糟，难道这是纸上谈兵，难道你会让主帅亲自上阵去打球！当然如果是渣滓球队让谁带都不可能拿总冠军，但是有的教练会让它拿第八名，甚至进入季后赛，而有的教练有可能直接使这支求队积分垫底，甚至解散。

所以，有效的发挥团队每个人的力量才是最关键的，让他能完成他所能完成的最大限度的任务，这就是成功

第一，我一直强调责权分明。作为PM，我发现手上的资源有问题，不足够完成任务，我立即向上反映了，这就不再是我的责任。领导有权决定具体的处理办法，他在运用这个权的同时他就得负这个责。他叫我就这么干下去，没问题，我还是会尽力，但就不能再叫我背失败的黑锅。

第二，请再看三遍《人月神话》（我是指那一篇文章）。如果你只有一个月时间，如果你已经感到来不及了，你最好不要再往里面放新人，那只会让你更加来不及。这种时候，新人能发挥的最大作用就是不发挥任何作用。

blackhost
现在的问题从管理上看是首先要时时刻刻考虑风险的问题.软件开发说到底还是一种商业活动,需要能够产生利润.而任何商业活动都要考虑到一个成本的低限,也就是不能做绝对不产生效益的事情.作为一个项目来说也就是必须要考虑到是不是在最坏的情况下也可以完成这个项目,只有在这个最基本的前提下,管理和协作才有价值.这其实也是CMM和ISO以及其他任何软件工厂学说不管怎么搞,他们也不会去涉及研究领域的原因.而我说得底线就是你的组织中有没有一个人可以在最大限度的情况下单独完成这个项目.只有在这个基础上你才有可能采取种种手段去争取更多的利益.当然这样的说法是有一个前提的,就是你不了解这个组织,不知道这个组织的能力到底如何.而那些成熟的团队,当然是会产生比一个人更大的力量的.但是你说的团队绝对不是这样一个团队.

你的说法很不明智,基本上都是在为你的论点提供方面的证据.为什么姚明和奥尼尔不可能一个人打一场比赛,但是却要围绕他们制度战术呢?为什么有的教练可以把一个球队带到一个更高的层次呢?他们怎么不说,我来制定一个万能的战术,你们只要按照我的战术打,就攻无不克呢?
一个团队当然应该充分发挥每一个成员的能力,但是这绝对不是什么最大的成功.软件开发不管怎么样说都是商业活动,成功的要求就是看是不是可以挣到钱.作为一个企业的成员,最基本的职业道德也是要看企业付出和收益的相比是不是可以接受.

讨论好象有点转向到PM的职责的问题上来了。
Weinberg说：问题其实就是你期望的东西和你体验的东西的差别。
你期望的PM会是个什么样？


以下《成为技术领导者--解决问题的有机方法》 “有效组织的障碍”节选。

障碍一：玩大游戏
管理课本上可能这么写：
   经理的定位是：解决问题并做出决定，而不是亲自执行实现目标所需要的行为；通常这些应由他人完成。
“发号施令”或“接受命令”的分类方法会导致“大游戏”的问题：“谁有权命令谁做什么事情？”  在许多组织中，就象在许多家庭和其他人际关系中那样，人们如此热衷于玩这种大游戏，他们根本没有时间去实现组织的既定目标。

障碍二:将人们视为机器那样去组织。
  忙于通过书面的过程和备忘录进行组织的领导者很快就会与下属疏远。

障碍三：亲自动手。
  组织其他人解决问题的最大障碍是，你自己以前作为问题解决者所获得的成功。

障碍四：奖励效率低小的组织。
。。。

有机地组织：
    对领导者工作的更好定义是：
    解决问题的领导者的定位是旨在营造这样一种环境：其中每个人都能
解决问题，做出决策，并实现这些决策，而不是领导者亲自动手来解决问题、
作出决策，并实现这些决策。



（以上节选不当之处见原文。）

    o6z兄的这个言论我便极不赞成了（甚至觉得有些感觉外行话了，我可能说重了，只是希望o6z再重新看看自己的语气。）。如果一个PM花太多的精力在coder，只是相当于一个senior coder的话，那么项目成功的可能性是非常小的，而且，随着项目的复杂度，项目规模增大，可能性急剧降低的。是不是manager不重要（是名头不重要），而是一个manager应该懂得怎么样去management，而不是developement。
我不清楚o6z兄是否看懂我的话，我谈的风险是项目风险，而不是企业经营风险。另外，o6z兄你理解的PM究竟是个什么PM，难道只是负责开发，带着团队一起编码的开发经理？经营的风险是由公司高层负责，而项目的风险，PM是需要负责并懂得去规避和解决的。

任何项目都有风险，一个好的PM应该在项目之初了解和把握这些风险，自然要像更高层表明，这点我是赞同的，也不存在和o6z兄的理解有何差别。只是任何意见都应该是建设性的，是怎么去解决或者降低，难不成，动不动就不做难道是好的方式？
这一点，我非常赞成o6z兄，这样的情况真的是不正常，并且相当的勉为其难，但是，这是事实，是大多数公司面临的事实，我们没有办法回避。谁都希望在一个资源充足丰富的公司，谁都希望在一个正规严格的公司，可我们依然要面对这样的现实而已。

我不懂o6z兄怎么可以批判我没有职业道德精神，这是非常极端甚至有些好笑的事情了。我可以告诉任何一个人，我凭自己的能力，凭着我责任感，我把许多人认为很难做甚至不能做的事情做得很好了（我相信比我高能力的更多，难不成就真不能做？），我没有放弃团队，没有放弃项目，我面临很多困难，靠自己，靠团队都一一解决，这是没有职业道德？我写到这里，都有些生气了，不过我相信o6z兄只是误解而已。管理和职业精神是两码事，我从来不会放大职业精神，而去强调任何事靠精神动力就足够；但我也不会放大管理，好像什么事只能当资源充足的时候才能完成。任何人都有困难，任何人都要面对困难，作为一个PM，必须要学会承担并分解包袱。
风险当然要避免，如果能避免所有风险，自然是最好，但是情况已经摆在眼前，是这个风险无法通过改善团队组成来避免，那怎么办？放弃？辞职？还是用其他手段去改善它？我选择了最后一种，也成功了，我不想夸大它，只是说，并不只有一二两种选择。
o6z兄还不怎么了解我这个项目，它是基于产品和项目的共同体，既不完全是产品，在项目接受到之前也不完全是项目，简单地讲，它是按项目运作的产品罢了。我们的客户也不是一个客户，而是整个电力系统。至于培训费用，我不太清楚o6z兄的意思，是不要培训？还是用其他费用？（那些费用又是拿来的？）
我实在好笑，我的态度又怎么表现我没有素质了？o6z兄把对公司管理的批评和对个人的职业道德批评完全混淆了。公司的管理当然不能建立在员工的奉献上，这点我也是非常赞成。但是员工之间的付出这和公司有什么关系？我不是公司高层的管理者，我不清楚没有管理者的职业道德是个什么表现？？要自私，要什么责任都推给别人，这就是管理者？呵呵，那我的确缺乏。

最后o6z兄的总结，我是赞成的（我只是对前面的一些不太赞成罢了），只是我不清楚o6z兄的职务，是老师么？很多东西比较理想化了。我们要对客户负责，但是我们不能不对老板负责，这在任何一家公司都这样（只要是企业都这样），如果一个企业给客户卖一个产品，如果你自己产品有问题，难不成还能跟客户讲么？（这个时候老板要你停下来，不要修改这个产品了，究竟是对客户负责继续修改还是对老板负责，去完成老板另外指定的任务呢？），扯职业道德扯远了，不是楼主的话题了。
    最后，我只是回到楼主的话题，迭代计划做多细，关键看你控制得多细。

脱离具体的事例谈理论是很少有结果的.这个问题就必须按照楼主的设定为前提.所以很多风舞飞扬的发言都是很不合适的.
比如在这个项目中一个pm究竟能发挥多大的作用让项目成功呢?是直接自己去动手在1个月的时间内去完成它,还是做所谓的管理加强,慢慢让团队来完成他呢?这是不是一个分歧,而是一种态度----你是不是严格的有操守的管理者的态度.任何一个团队中的人都应该以项目成功为最高的目标,而不是以团队建设/加强管理这里的目标为最高目标.作为一个这么短时间的项目,所谓的复杂大和可控制性极具增大的情况基本上不存在的,一个人完全是可以掌握的.当然这样说有一个前提,那就是管理层很好的对于风险和项目的规模作了预估.如果真的是一个人不能控制,那么就可以认为这个项目根本就应该是按照我们最开始说的,不去接受.
对于风险的问题,我想风舞飞扬可能有很多东西没有理解.一个项目的风险控制基本上不是项目内所能控制的,而是负责发起这个项目并且在管理这个项目的高层负责控制的,而pm只是负责组织对风险的观测和当风险转化以后在风险应对措施以及到位的情况下的具体实施.具体采取什么策略和措施,基本上pm没有半点的管理和决策权,因为风险发生的后果决定了风险不能在一个小的组织中得到最便宜的解决,也就是说一个PM只能调动其内部的资料的情况下来解决风险基本上是不可能的,这也就是每一个公司都应该有救火队员的原因.而这样的项目基本上给救火队员发挥得余地太小了,常常的情况是当第三周的结束以后才会有人去汇报项目可能会完成不了.
而风舞飞扬对于风险控制的缺少理解可以从下面的话中得到验证,当然很多的人都和他有相同的思维方式,因此我要特别的提出了项目的最大风险往往就在于没有风险应对机制。面对风险我们应该做什么呢？首先是我们必须理解风险，比如你说系统会在1个星期后不能完成，这就不是风险，而是必然会发生的事实。风险只是那些可能会发生的情况。面对这些风险首先是要做出一个判断风险是否发生的标准，也要建立一个风险释放的标准。并且对这些风险列出一个可能向现实转化的优先次序列表，并且制定一个建立这个列表维护制度。你并不需要对于所有的风险都在开始的时候建立应对措施，或者干脆就对所有的风险在开始阶段都不制定应对措施，而只是在风险发生的那个时候再进行因对性的措施。一个公司规模的组织，会有一套全方位的应对问题的解决计划，理想状态下风险转化后应该只需要调动这些已经制定好的计划就可以。而这应对计划是公司为所有的项目所准备的，而不是对具体一个项目准备的。这样的时候PM对于这样的措施基本没有什么发言的能力。
而风险是不会由于你采取了某种措施针对其运作，而真正的降低其发生的可能性的。你只能采取某种措施降低其转化以后造成的影响。同时由于风险都是可能会不发生的，所以你面对风险做出的种种措施都可能是浪费。而风险转化以后你的这些应对措施究竟是不是起到了作用也很难确定性的证明，而风险释放以后你也很难证明你的针对性措施究竟是不是起到了作用。而这些不确定性造成了当代风险控制方式已经从应对性的，变成了因对性的。基本上就是说由事先针对性的采取措施规避，变为了时候采取措施解决。
上面对风险说了很多，基本上是从一种态度开始给大家做一个风险管理的介绍。

最后还是回到这个项目上来这样的项目基本上没有什么成功的可能性，作为一个管理者最要紧的事就是去避免这样的事情方式，而不是让这些成功的可能性增高。实际上增高成功的可能性是一个逐步的长期的过程，在短短一个月中完成这样的工作根本就是不现实的。而这对于很多组织其实是很容易作到的。而最具有建设性的措施就是量力而为，不去做注定会失败的事情。
而从行业的整体性考虑，一个项目的失败往往会带来一片可能的客户的行业性流失。这个损失不是只针对项目失败这个个体企业的，而是整体的。现在之所以项目很不好找，一个重要的原因是很多项目由于不管有没有做的资格，大家都来参与一把，把价格搞得很对。这个时候客户如果是不成熟，就往往会以最低的价格成交，最后的结果一般都不会好。而客户如果成熟，则又会在商业和运作方式上对开发者进行多个层面的控制，造成很多不必要的成本付出。而实际上本来可以在源头上把好关，从自己这里把好关，能做的再作，不能做的就别做。这样往往不会有什么损失。但是由于种种原因很多企业都着急扩展，希望成为什么500大，结果就看出来了。
最后说说管理者的问题。管理者建立的是一套系统，这个系统应该可以在离开这个管理者的情况下也可以正常的运行。也就是说这个系统可以按照这个管理者的思路去发现适合这个系统的人和资源以补充道系统中，从而可以长期的运行。而管理者最大的一个工作就是分清楚管理者的责任，给出各个职位的资格。一个管理者可以自己付出额外的努力，但是绝对不能把这些付出当作除去自己以为人和人应尽的责任。如果没有这点素质，这个人就不能被认为有最基本的管理素质。而风舞飞扬缺少的就是这个，他自己还觉得可笑。真的很悲哀啊。实际上要想付出基本上可以解决现在任何的项目困难，大不了最后自己出钱找人做就是了。这在销售行当中很常见的。但是这样的方式绝对不是一个好方式。
实际上一个组织成熟与否的一个标志就是知道自己可以做什么，不可以做什么，而不是四面出击，什么都去做。学会拒绝是一个人成熟的标志，也是一个组织成熟的标志。

这点我赞成，不过这点刚好就反驳了o6z兄您自己的观点，风险是什么？风险怎么评估？说系统一周后不能完成是基于什么样的情况？加班？正常工作，高效率工作还是充分考虑一周内会遇到的问题？
    任何风险的评估以及预测必须基于一定条件，风险是不能空谈的。PM不能改变外部资源，不能改变外部环境，这非常正确，所以才会出现楼主和我所遇到的痛苦以及尴尬场面。一个PM此时该怎么做？是应该对任何条件都不进行评估而直接放弃还是找到一些适合的切入点，将风险化小，将某些优势化大？在博弈论和经济学上有一个非常有趣的观点，也就是弱势优势。我们再讨论一点，也就是gigix和o6z兄推崇的个人作战注意，如果做过基于web系统的人都会知道，一个人想在一两个月内做一个数十万行代码的系统根本是不可能的（上百个页面，可不是做网站，有得抄的），所以，团队是怎么都脱离不了的。
    另外，o6z在畅谈风险以及管理的时候，总会不自觉地将范围泛化到项目外部，比如公司或者市场环境等。在那些方面，我不了解，也无法了解，所以我只是在项目内部，更重要的是团队，项目过程控制以及技术三个方面去探讨一些问题（当然，这狭隘了许多，不过我想绝大多数PM所能关心的也就是这个，扯得太远，并无好处）。
    首先，我们看这样几点，项目的实施不是由PM说了算，而是由公司说了算，o6z兄在前面说得很清晰，到这里却又"故意"忘记了这点。其次，在短短的一个月完成这样的工作怎么叫不现实？o6z兄只是了解了团队的构成，却又是否了解楼主所需要开发的东西（只是原型啊），更加困难的我做到了，别人又何尝做不到那？（当然，我延迟了一个多礼拜，而且各种外部环境不同，任何东西不能简单比较，所以我并不是说什么项目都可以这样，我不想因为自己的言论而是所谓的偶然力量得到过分的放大。）。第三，对于项目的成功的评估是怎么样得到的？又是怎么样进行的？如果评估都是正确，为什么依然有那么多公司失败（最典型的就是ERP了）。
    的确，项目的经验，包括风险的评估，周期与资源的估计，过程的控制都是需要日积月累的，很多过去做不好做不到的，再未来并不一定。
   说到最后，我只是想说，经验最大的是来自于总结。

这个项目你的迭代计划就是你自己的开发计划，跟其余的人没有关系，这是我的观点。

没看到你的原帖，如果就是一个月的进度要求，你看你一个人能否搞定，可以搞定的话，再看看能有多少时间来培训这些新人，能花多少时间在这些人身上。

计划的制定完全以你为主，其余的人根本不可能在项目里面起到作用，这是规律，一个从来没有做过开发的人，你想想让他们独立完成一个数据列表，带增删改、翻页、查询、页面跳转，这样一个最常用的程序，他们从熟悉开发工具、配置环境、熟悉语言、了解框架、使用JDBC，还有的根本就不知道SQL的使用，我想怎么着也得一个月吧，你能让他们做什么？如果连怎么做都不知道，你有必要给他们制定什么计划吗？开发计划他们看不懂，因为他们心有余而力不足，你要给他们做的是培训计划。

项目经理的一个原则是理智，计划的制定要符合客观规律，而不应该相信激情、热情之类的因素，领导、客户的压力也不能影响你的判断，怎么做是一回事，怎么和领导客户沟通是另外一回事。

微软的开发方式要求项目经理在进度计划制定时保留20％－200％的缓冲，为什么？他们也说不出理由，反正要加。象你这样，如果非要新人进入项目开发，我的意见是你的进度计划要加200％－300％的缓冲。不信我们可以打个赌，:)。

我觉得还有一点是项目团队组织，不同的项目会有不同的项目组织，你觉得你的项目组织怎样是合理的呢？一个月能干完的项目，是什么样的项目？需要几个人，每个人的职责和能力要求是什么？最低要求是什么？然后再看手上的人，如果全是新人，要跟公司说清楚风险是什么，培训周期很长，在这个项目里面他们起不到什么作用，可以先让他们学习，然后把代码给他们看，至于你能不能抽出时间教，那要看进度完成情况了。