互联网站开发流程的思考

ahhuang

最近乘着项目压力稍懈，挪出些时间，对比着时下比较火的诸如RUP，Agile Model（XP,SCRUM等等），重新审视和梳理一下整个开发流程。有了些有意思的发现，希望能和大家探讨探讨（这里俺们不是做学术研究，所以我们只谈软件过程当中的核心过程（软件开发周期），忽略支撑过程和组织过程）。

到目前为止，古典些的开发模型有诸如瀑布模型，演化（原型）模型，螺旋模型，喷泉模型等，现代些的有RUP，Agile。对于有一定规模（比如已有稳定的盈利来源）的互联网网站来说，通常倾向于瀑布模型，呵呵，不奇怪，如果你能够自主掌控需求和上线时间和节奏的话，瀑布模型最适合。

但同时，与传统的软件开发（无论是基于项目的，还是基于产品的）相比较，互联网站类还有一些自身的特殊之处：

• 首先是互联网站的客户群众面通常非常广泛（即便你针对是某一特定群体），且流动性很大。

       你很难去寻找特定的客户代表（产品经理）来共同开发和确定需求；

• 其次是为满足大众口味的多样性，我们通常会是并行开发许多的feature，这样也使得每个feature的开发周期（迭代周期）都非常短。
• 最后是多组feature上线之后，单个feature的实施效果评估比较困难

这也就决定了其在开发流程当中会有些特殊之处。而我们也把整个开发流程拆解成：
“需求的搜索发现阶段” --> "开发内容的确定落实阶段" --> "具体的开发阶段" --> "上线以及维护阶段"

[ 本帖最后由 ahhuang 于 2009-11-4 18:26 编辑 ]

ahhuang

流程的每个阶段，不外乎就是：
      谁（role），通过做啥事儿（action），取得什么样的成果（output），进而就达到什么目的（goal），之间要花多少资源（resources + effort）。

虽然我们能够自主的决定做什么，但这并不意味着你可以天马行空的乱来，因为你的周围有无数虎视眈眈的竞争者在等着你犯错误。“做正确的事”（方向）和“正确的做事”（执行力）这两架马车必须得是缺一不可。

在组织当中，我们通常是业务部，其中的产品经理通常是出任提出需求的角色。
问题是，大的互联网站的客户量（网民）少则数十万，多则上千万的，在这样一个眼球经济和意愿经济的行业中，“少量”（相对整个开发团队而言）的专职需求设计者并不足以把握各个用户层面的需求，另外当网站规模大到一定程度后，加之产品经理本身的人员流动性，他们也不可能在思考新需求的同时，对自己网站上的所有特性，以及之间的关联依赖性都能了如指掌，其结果也就是诸多创意本身的漏洞和风险，以及多个创意之间的矛盾和冲突，很难被全面的照顾到。

所以， 这个阶段的 “谁”，应当是产品经理为主体，联合各路诸侯的头目（主要是来自开发，测试，界面设计），在控制人数（3 ~ 5）和质量（能提出有效意见和建议的）的条件下，一道确认自己提出的需求。因为开发，测试，界面设计者，“进”可以开发出一些更好的想法，或者找到是替代方案，“退”可以指出需求中的遗漏，或是与既有功能，甚至是其他并行项目的功能的矛盾冲突之处。

[ 本帖最后由 ahhuang 于 2009-11-5 18:47 编辑 ]