第一章：焦油坑
读过Frederick Brooks所著人月神话的朋友一定还会记得开篇处作者关于焦油坑的随笔。史前史中，没有别的场景比巨兽们在焦油坑中垂死挣扎的场面更令人震撼。上帝见证着恐龙、猛犸象、剑齿虎在焦油中挣扎。它们挣扎得越猛烈，焦油纠缠得就越紧，没有任何猛兽足够强壮或具有足够的技巧，能够挣脱束缚，它们最后都沉到了坑底。
究其深意，在我看来，作者提起焦油坑，更想说明的是即使你自身足够强大，也没有办法摆脱束缚从险境中逃身。IT项目，也是如此。
大到系统核心软件设计，小到单位网页开发，都会存在诸多的复杂问题和影响因素，而项目是一个足够复杂的动态过程，以至于我们很难将其做到极致。作为产品经理，项目四要素（工作范围、时间、质量、成本），人员，环境，组织方式，外部约束，风险管控，团队维系等外置因素都是要考虑的东西。只有将所有的要素达到尽量的平衡，这个团队才有最强的战斗力，也就才有可能做到项目成功。否则一个要素出现小的差错可能都会导致巨大的损失。
在英国历史学家诺斯古德·帕金森1958年出版的《帕金森定律》一书中有一个"金字塔上升现象"，和焦油坑很相像，尽管每个人都很忙但组织效率却越来越低，尽管每个人都在往上走，但导致在每个岗位角色上都难得到技能过关高效率的人员。
在《人月神话》中也谈到了一些方法尽量避免焦油坑，加上自己的理解，总结一下：
①：项目初期
开发初期不要一拥而上，要保持精干的团队（类似于外科手术团队），从稳定的核心开始单点突破，逐层扩展。要用生长（grow）的方式来开发系统。在开发大型软件时候掉进焦油坑的几率远远大于小型软件，小型软件就算掉进去也很容易跳出来，有一定的试错成本。但是如果前期的团队选不好，产品策划选不好，开发架构选不好，这个坑依旧是在所难免。特别是在一些创业公司，很多创业公司，创业初期，架构选的不对，在业务需要快速发展的时候，这时候自身产品架构就会拖后腿，如果一开始产品设计或开发人员能力不足，会直接导致产品设计失败，漏洞层出不穷。
就算后期公司可以活下来，以后也要请好的架构师来进行重构。所以在有条件的情况下，在项目初期把架构搭好，把大体规划确定好，会少很多的麻烦，方便以后拓展。
②：项目中期
在项目的中期，随着业务的生长（grow），团队中的成员也越来越多，新鲜血液的加入对团队来说是好事，但重要的难点在于，如何保证团队概念的一致性？
在书中提到了一个概念："贵族专制式的开发"，我们要保证，团队整体的概念设计必须由一个人，或者非常少数有着极其默契的人来实现。
在以后系统越复杂，规模和工作量越来越大，但是工作量和项目周期并不是一个简单的线性关系，这对于产品设计和开发人员的整体把控能力和相关业务经验要求也就越高。这也不可避免的让更多的人参与项目，参与的人员越多，人员的沟通效率也就越低。而这时候，最关键的关键就是要保证沟通和验证效率！建立好一条有效的沟通机制和测试流程，这是非常费精力的工作，需要全体人员努力，但是完成之后，非常值得，解决大问题。
③：项目后期
这里指的项目后期是指项目上线运行一段时间后，因为项目周期长，几经易手的代码构造可能已经过时，但是如果前期代码不规范，后期维护简直就是难上加难，特别在一些外包公司中容易出现这种问题。17年我在百度听一场内部报告的时候，有这样一个观点：
项目的生命历程中，往往会出现一个"不可能三角"，我们只能尽其所能优化两项目标，绝无可能做到完美
这时候为了避免进入"焦油坑"，产品经理的取舍很重要，如何选出放弃的一角，让老板们认清现状，对于放弃的一角达成一致这很关键。其实最好是放弃挣扎，直接开始重构。天下没有不散的宴席，一个项目最终的分化或是死亡都是好的归宿结局，这时候产品经理要坚决果断，做好善后工作，总结经验，尽量减少时间成本和人力成本，摆正心态迎接新的挑战。
以上是我读《人月神话》第一章的心得体会，受限于我的知识储备，以上观点希望能够抛砖引玉。如果日后的项目中我有什么新的收获，我也会及时更新，一起交流^_^
网友评论