最近在看一本关于Scrum敏捷开发方面的书，联想到了工作这几年的一些零散感触。趁着有写东西的激情，挑些整理一下。
先整理一下我理解的产品与项目的区别，这个比较简短，而且在后面的软件开发方法学中会有涉及。
到现在算是做了三年的产品和一年的项目。大概去年和同事聊我们现在做的是产品还是项目时，我说是项目，他觉得是产品。当时我是凭感觉，但一时没有想出特别的区别方法。后来某天上班走在路上时，突然想出总结了以下产品与项目区别：
产品：先做后卖，不好没人想买，迫使团队不断升级产品赶超对手。
项目：先谈后做，控制成本满足需求，以后尽量避免变更。
接下来是关于软件开发方法学的争议。
最近看的书里狠狠的批判了瀑布方法学，把案例公司的项目失败的原因归根在了方法学上，这是我很不认同的。当然了，书的几个编著人这样做是有目的的。当书里写道Scrum模式的敏捷开发时，有一点我是很赞同的，就是提出人的重要性，强调以人为本，加强沟通。
瀑布方法学虽然很老了，也有不少人批判。我也曾经怀疑指责过，查过不少资料，知道了有迭代式方法学、递增式方法学、RUP、XP等。两年前痛恨瀑布方法学的同时也迷惑了，有些方法学看似很好，但在实际操作中也会有局限和困难。
后来和一位十来年经验的项目经理聊方法学，解开了我大半疑问。严格的瀑布方法学是不合适的，但它仍然是软件开发的基本框架方法，具体工作中，可能根据需要融合迭代式或者递增式等其他方法学。
刚刚参考《面向对象分析与设计(UML 2.0版)》的时候，还看到了类似的说法，算是合并方法学的思想。在中大型公司中，我是比较赞同这种方法的。如果是小团队，可能又会选择更敏捷高效的方法。
因为产品和项目的特点不同，具体的操作和方法也会有不同。下面谈的有点偏向于项目规划和需求方法了。
有一种经典的项目失败场景是：项目做完，客户看到时说不是他想要的，和他想的不一样。。。这时大家都傻眼都痛苦了，程序员更悲剧了。
对于这种情况，我认为首要是需求阶段的问题。（当然，基本前提是项目组是团结合作、有能力、也是努力实现目标的。）即使SRS（软件需求规格说明）很详细很正确，如果只是文字描述，客户是很难有直观理解的。在客户看到有形的产出前，常常很难确定自己的想法。
理论上的方法应该也有不少。以前跟两个项目经理聊过，他们的经验是，利用高保真原型，拿高保真原型给客户看和体验，这样客户会有直观的概念和想法，根据反馈再完善需求。这样就把风险尽量前置了，而且制作原型的时间和成本比开发一套系统要低得很多。
曾经和一个项目经理做比较大的项目时，他甚至把项目周期的一半时间分配给需求分析和高保真原型，可见对需求的重视。刚开始有点诧异，时间比例比一些理论值大了不少。虽然不一定是最合理的，但对一些目标和时间比较明确的大点的项目来说，很有实战意义。
如果是做产品，上面这种方法就太低效了。既然是产品，就应该有个产品经理（参考文章：产品经理的主要职责）。如果团队合作默契、互相信任，需求的交流和工作应该是高效的。产品经理对需求应该有清晰的认识，如果有大变更或者变更多，首先是产品经理的责任。在原型方面也可以减少很多工作量，对于复杂的产品，也许画个线框图。对于简单的，草纸或者口头交流清楚更好了。不管哪种，当面交流是最高效、效果最好的方式。
话说回来，产品经理也不一定是拍板的人，也可能是夹板和炮灰，也有不少人达不到职责应有的水平。对于部门和人员多、分工详细的大公司，产品经理也不一定负责详细需求。接着就会引申出流程和内耗一些问题。方法学又开始纠结了。。。
各种方法学在具体操作时都有成功和失败的案例，个人觉得没有哪种是最优的，要看公司和产品/项目特点，团队和个人，甚至还有客户的特点。方法学和流程什么的还是人定的，目的是帮助团队，需要情况灵活应用和调整，关键还在人。
最近评论