加载中…

加载中...

个人资料
人月神话
人月神话 新浪个人认证
  • 博客等级:
  • 博客积分:0
  • 博客访问:4,215,565
  • 关注人气:5,929
  • 获赠金笔:0支
  • 赠出金笔:0支
  • 荣誉徽章:
相关博文
推荐博文
正文 字体大小:

为什么做不出好产品

(2011-04-27 22:17:11)
标签:

产品

规划

开发

运营

分类: IT咨询
最近一直在思考这个问题,首先对这里谈的产品定义为企业信息化业务系统而非互联网产品。

当我思考这个问题的时候,再次发现了问题界定带来的目标明确对解决问题的关键作用。什么是产品?又什么是真正的好产品。对于产品我们始终在强调它是创造了业务价值的东西,而对于好产品则是最大化创造了业务价值+很高的用户满意度。

对于软件产品我们一直在考虑和传统产品的区别,对于传统产品我们说的多的是用户花钱买了产品,产品具有使用价值。而对于软件产品其价值又在哪里?软件产品的特殊性在于没有软件产品业务照常可以运转,那软件产品的重点就变化为了通过信息化实现的自动化,软件产品是一种工具类得产品,借助产品用户可以实现更高的工作效率,工作效率的提升带来的业务更加敏捷和高效。在这里我没有专门去强调软件产品对业务流程的固化,很多时候我们过于强调流程固化而忽略了真正的流程效率提升。

很多时候我们在想,我们的产品完全按照用户的需求得以实现,测试完整后发布,那我们产生出来的应该就是好产品。这里要注意是混淆了产品和项目的概念,项目很多时候关注的是项目目标是否真正达成,而产品最终关注的一定是业务价值是否提升和实现。从这个层面我们就更加容易理解产品生命周期长于项目周期,在项目启动前有业务价值驱动的产品规划和需求分析,在产品上线后有进一步的运维和使用分析。

通过前面的分析,我们再把好产品的产生过程做个简单的分解,即需求输入+加工和生产+输出推广。

需求输入和需求分析

在进行需求收集和分析的时候,我们过多的关注用户究竟要什么,关注用户需求的收集和需求挖掘。那我们不得不问,我们的产品是满足那些用户的需求,满足哪些岗位的用户需求?用户提这些需求的出发点是如何的?这些需求对整个流程绩效和业务价值的提升究竟是如何的?

提出这个往往会导致我们的需求分析很纠结,原因很多时候不在于系统,而在于业务本身架构和流程设计,系统的建设往往不是在解决企业业务流程的割裂,而是在助长流程的隔离,这也是产生大量的烟囱式的业务系统的原因。这个责任往往并不完全在业务系统开发方面,但是我们提出这个问题的原因在于我们要意识到企业架构和高端流程和数据分析对企业后续业务系统规划建设的重要性。

对于系统的建设我们一直在讲是一直分期建设,迭代规划的思路进行。那如何来分析收集到得需求的优先级,对于这点我认为唯一的优先级衡量标准就在于功能对业务价值的贡献度。这个业务价值有很多衡量标准,但是初步考虑可以考虑的即是流程效率提升多少,系统对业务能力的支撑能力提升多少?人力资源投入节余多少,人员效率提升多少等内容。

现在我们谈UCD和交互设计,关注用户体验,可以看到易用性越来越受到重视,但是我们一定要意识到系统的易用并不一定就代表了系统本身存在的价值高。一个系统首先是要有存在的价值,自动化了流程支撑了业务,其次再考虑如何通过易用性更好的提升效率。对于企业内业务系统不同于传统的互联网产品,企业大型业务系统一定是存在一定的学习成本,但是我们强调掌握了这些操作和学习后你能够获取最高的使用效率。

说这么多,一句话,在输入阶段真正关注需求后面隐含的业务领域和业务价值,而不是单纯的接受用户需求。一个好的产品不是单单的去满足需求,而是引导需求。

产品开发过程

在搞清楚了我们究竟需要生产了加工什么后,接着的问题就是如何保证这个产品能够按照要求,按质按量的产生出来。在这里借助CMMI里面的一个说法,即任何一个好产品的产生过程都离不开人,流程,方法工具技术三个方面的内容。

对于软件产品开发中人相当关键,或者说团队相当关键,对于一个新产品的开发,如果想临时的去组建一个开发团队就能开发出一个好产品那简直是天方夜谭的事情。只要我们有一个成熟的磨合过的团队,那么我们就会对开发出好产品有信心,这个团队从敏捷方法里面常谈到得就是,建立在充分信任上的高效沟通,建立在基础技术技能上的能力互补,建立在目标一致上的团队学习。

在这个基础上我们对团队提出更高的要求,即由过多的对技术的关注转化到对产品和业务的关注,技术可以成就一个产品,同时也可以毁掉一个产品。团队开发功能,如果不清楚功能本身带来的业务价值,不清楚功能对用户真正带来的贡献,或者根本就不清楚功能在业务流程或业务中位置和作用,那么如何做出一个好产品?产品不是一个玩具,产品不是按着技术人员的想法,而是应该考虑最终用户的想法。从这个意义上来讲,也是我们对团队要专门分离需求人员的原因,也需求还进一步分离为业务分析人员和系统分析人员的原因。

对于流程是产品质量保证的一个关键环节,只是我们再考虑是重流程还是轻流程,是传统还是敏捷?但是我们必须要强调的一点就是敏捷往往有更加严格的纪律和执行力,而不是抛弃流程,而是采用精益和价值驱动的思想,保留最有价值的流程。原来我们看到有个提法叫软件作坊,这里我不认为它是一个贬义词,我们可以看看现在传统的手工业作坊,往往有更加严格和缜密的流程。问题仅仅是流程下本身的生产率问题。

再回来看工具和技术,首先一定要注意到开发人员要避免技术狂热型,很多时候成也技术,败也是技术。没有最好的技术,只有最适合的技术。我们可以看到现在很多还采用PHP开发的互联网内容管理网站,这些网站都是很好的产品。对于技术和工具的选择一个重点就是满足需求+开放扩展性,产品的开发过程本身也是迭代形式的,只要技术有良好的开发扩展性就可以了,那我们可以预留足够的接口适应扩展和变化。

输出和推广

即时内部的信息化产品,也时刻不要忽略了产品需要去推广和宣传,信息化产品开发出来后的实施往往才是产品最终能否成功的一个关键问题。对于实施我想用产品推广和内部运营这个词,即要把产品推出去,而推出去的基础当然又是产品能够带来用户价值。通过产品本身的功能宣传,品牌宣传,培训,后续的ITIL流程等多个方面来保证产品在推广阶段的即时响应,提升用户的满意度。同时在推广的过程中不断的收集用户的反馈意见,作为下个迭代版本的需求输入。

内部产品推广和运营在这里先不展开讨论,但是要说的就是互联网产品的很多运营思路完全可以应用到内部产品的推广和运营上面。

0

阅读 收藏 转载 喜欢 打印举报/Report
  

新浪BLOG意见反馈留言板 电话:4000520066 提示音后按1键(按当地市话标准计费) 欢迎批评指正

新浪简介 | About Sina | 广告服务 | 联系我们 | 招聘信息 | 网站律师 | SINA English | 会员注册 | 产品答疑

新浪公司 版权所有