同行评审作为保障软件质量的两大环节之一（另一大环节，请参阅《Bug or Bomb? 缺陷还是炸弹？》），其在软件项目管理中的普遍性已无需多言。可做着做着，都走了样。今天我们延续之前的讨论，想要做好同行评审，便要从它的过程下手——程序步骤、方法和人。

创业阶段的企业只关注直接支持产品交付的活动（比如编码），因此在内部管理上是随意而混沌的，几乎没有完整的规则和制度。

管理上的粗放造就了极大的灵活性——他们可以全权接纳客户变更，自如地调配人员，任意选择看似最佳的工作方法，快速决策……这些都是H公司得以快速成长的动力。也恰恰是这些，导致了他们无法有效管理变更，无法核算人力投入，依赖个别人员的个人能力，决策短视。

蒸蒸日上的创业公司，是新晋PM技术与管理思维转换的第一站。跨过这道门槛，PM的管理才能从纸上谈兵变为脚踏实地。

甲方公司是一家大型证券公司旗下的软件公司，有着一套标准的项目管理流程与规范，常年外包软件项目。这次，他们选择了一家极具性价比的新供应商。乙方公司是一家百人规模的民营企业，首次接触到像甲方公司这样利润丰厚的金融外包项目。

结果，这个预计8个月的项目延期了5个多月才勉强交付。甲方对乙方的满意度，也降到了冰点。

到底是什么，蚕食了乙方的利润？降低的甲方的满意度呢？且听我细细道来！

惊奇队长那篇，我们从语义的角度，谈了测试只能“保障”软件的质量，而非“保证”质量。
今天，我们从缺陷引入的角度，谈谈软件的质量还能如何得到保障。

案例中的Patrick自愿向公司作出承诺，才会认真努力。David被迫承诺，才会觉得干他P事。David的做法看似圆滑，却没有意识到即使是被迫承诺，也是作出了承诺。只要没能履行，便会伤及自身的职场信誉。

所以各位David，承诺不是小事，要在工作中，拿回承诺的主动权。

美队的领导魅力，不是因为神盾盖世，而是那句从嘴边到心里的“Together”。就凭这句话，他就能团结各路超级英雄，组成复联，一路刷怪。
作为程序员的Captain，PM应该有适合IT行业特征的领导力模型。这一篇，我们就来说说项目经理如何together项目组，实现项目目标。

软件开发的众多角色中，唯有QA是被扭曲的最严重的。​千万不要被QA的名字所迷惑。软件的生产者，才是唯一能保证质量的人。​

QA的质量保障工作，是通过直接保证软件开发过程的质量，来间接保障项目的质量​。

我们对软件开发进行管理，期望的是整个工作过程的性能越来越高。但是，却忽视了理想中设计的过程，与现实中执行的过程之间的差距。

因此，在胜任力的概念中，明确提出过程能力，就是从人的层面，深化过程性能的改善，填补这个漏洞。

看《知否知否，应是绿肥红瘦》，掌家大娘子盛明兰（赵丽颖饰）给佣人分配工作尚且“人岗匹配”。项目经理，你有怎么看待项目中的人员管理呢？

这一期，我们将软件开发的工作过程拆分成四大阶段，即立项、策划、实施（包含需求、设计、编码与测试）与结项。一一说明不同项目阶段的人员管理重点。

测试出的问题被称为bug。当一个程序员说“就剩几个bug了”，听起来是很轻松的，分分钟完活下班的感觉。可试想一下，如果你的体检报告里，赫然写着“高血压”，你觉得它是个bug，还是个bomb？

软件中，即使再小的bug，只要到了客户眼皮子底下，统统都是bomb。因为软件的不可见，会让客户失去安全感，从而变得小心谨慎，甚至吹毛求疵。

既然要保障质量得到改善，我们就应该在测试过程中，用对待bomb的心态，对待每一个bug。在交付之前，将bomb的隐患控制在最合理的范围之内。