荐书|《大教堂与集市》

当年乐帝没有入行产品时，写过前端代码，经常因为实现某个功能去github找现成的开源框架使用，对开源领域也是又爱又恨。爱在知识的共享降低了全世界软件行业的开发成本，恨在水平太渣无法成为其中一员，只能仰望。，读《大教堂与集市》，一方面对开源软件领域感兴趣，另外一方面是被形象的标题吸引了。

书中大教堂与集市是很形象的两种比喻。大教堂给人庄严肃穆的感觉，就像机构的软件项目从立项到完结，有强有力的机构进行管理和质量把控。而集市熙熙攘攘，就像开源软件项目没有严格的标准，也没有强有力的机构来管理。表面上看开源社区很“乌合之众”，但当今全球普及手机系统Android和iOS却都是开源的产物，开源社区好像又不那么“乌合之众”。

乐帝所在公司部门由于老板关注较多，每个版本都会有一些老板的需求，老板需求放到最高优先级是天经地义的。在开发资源一定条件下，一些优先级低的需求就总会被列出排期之外。久而久之，产品细节需求和体验总得不到改进。这种统一立项到完结可以归入大教堂模式的一种。

在特定时间点开发有余闲资源，为了解决细节需求和体验总进入不了排期的问题，最好的方式便是用开发的余闲资源消化掉细节需求。于是引入了“需求池”的概念，并号召开发人员有更强的自主性，自主选择和安排需求池中的需求。从单一需求起止时间点来说，需求池类的模式与统一立项模式的差异在于前者是一条条溪流，后者是小溪汇成的瀑布流。每个溪流互补相关各成体系，更像是熙熙攘攘的集市；瀑布流则是整齐划一同进同退，更像是庄严肃穆大教堂。

溪流式的项目开发方式转变，相当于从瀑布流拆分出多条流，实际项目中每多出一条流，项目复杂度和沟通成本便会与开发人员数目平方成正比。如此高的复杂度和沟通成本开源软件行业是如何解决的？

开源软件与机构软件项目有一个本质的差异。开源软件作品参与者往往源于开发者自身的需求和热爱驱动其持续改进开源软件，自驱动能力强。而在机构软件项目中有太多的软件开发者不需要也不热爱开发软件，只是将编程当差事，为的是拿薪酬，自驱动能力弱。相比较而言，前者与后者本质上在于动力差异。

如上所述在机构软件项目，采取溪流式的项目开发方式，一方面开发人员不会像开源软件参与者动力足，那么利用能动性自主选择和安排消化掉小需求，就会成为无压力无时间节点的死需求；另一方面因为多条流产生的项目复杂度和沟通成本总会需要人来买单，“产品经理为产品负责”便把多出的复杂度和沟通成本付诸到产品人员身上。

上述两类问题已经在溪流式开发方式中暴露：产品经理找开发要时间点，开发会不理解不是必须上为什么还要时间，将不必须做为上线标准认知为不做；产品经理在手中项目多于5个，很多精力都放到了跟项目和沟通上。

乐帝认为机构软件项目想用溪流式开发方式，首先便是从整个项目链体系均衡责任与义务角度来考虑落实。而非像想改善交通拥堵问题，只拓宽链条上部分路段，让链条上其他环节因由宽向窄，承受更大的负荷。这样一定会部分人工作量和压力陡增，而其余人则享受着集市般的自在人生。

关于产品经理读书会

专注于为爱读书的产品人提供书籍推荐、读书交流、以书会友的环境，欢迎爱读书的产品人分享读书感悟、找寻改变世界之路。