好的软件开发产品具备三个基本条件,价值、可用性、可行性,三者缺一不可。“价值”就是客户愿意采购,是否觉得你的产品有用,有多喜欢你的设计,产品没有价值,开发团队再优秀也是无济于事的。“可用性”就是软件的功能是否实现,是否实现最佳的用户体验。“可行性”就是技术上是否可以实现,寻找可行的技术方案。
一、市场需求与机会永远不会消失殆尽
要想在市场上崭露头角,必须发现新的热点,开拓新的市场,大家都在挖空心思寻找下一个热门产品。成功的产品往往不是什么全新的事物,只是新瓶装老酒,之所以成功,是因为这个“新瓶”做得更好、更方便、更便宜,改变了消费者对以前“老酒”的印象。只要市场上还有蹩脚的产品就有机会。
二、只有挑选合适的产品机会,才能向用户提供实用的解决方案
创业公司必须要用灵敏的嗅觉,从纷至沓来的机遇中迅速评估、挑选出市场潜力、可行的创意,过滤那些没有价值或时机尚不成熟的点子。
评估产品的机会目的在于,淘汰馊主意,避免浪费时间和金钱,挑选合适的产品机会,团结团队,理解产品,整合资源。
为了有效地评估产品机会,应问以下十个问题:
1、产品要解决什么问题?(产品价值)
2、为谁解决这个问题?(目标市场)
3、成功的机会有多大?(市场规模)
4、怎样判断产品成功与否?(度量指标或收益指标)
5、有哪些同类的产品?(竞争格局)
6、为什么我们最适合做这个产品?(竞争优势)
7、时机合适吗?(市场时机)
8、如何把产品推向市场?(营销组合策略)
9、成功的必要条件是什么?(解决方案要满足的条件)
10、根据以上问题,给出评估结论?(继续或放弃)
上述问题并不涉及到具体的解决方案,机会评估只讨论解决什么问题,挑选我们最合适的产品机会,然后再向用户提供解决方案。
三、制定产品原则,开发正确的产品
制定产品原则意味着决定什么是重要的、什么是不重要的、哪些原则是根本性的、战略性的,哪些是临时性的、战术性的。产品原则是与公司的价值文化严格统一的,好的产品原则甚至可以激发设计产品的灵感。有了重要性之分、主次之分,当团队在产品的细节设计上有争论时,我们不妨回过头来,仔细看一下我们的产品原则。
制定产品原则,告诉你哪些产品可以做,哪些不能做。根据创业公司的愿景、使命来制定产品原则,规划产品的路线图,哪些是公司应该聚焦的产品。
产品原则是产品线的战略指南,是公司的价值宣言,是用做团队内部的指导工具,也可以公开给客户、合作伙伴、投资人,用于向公众宣传公司的理念。
四、用高保真的原型来取代说明文档
产品说明文档在不同的公司、不同的团队都要有明确的书写规范,高保真原型是最直观的产品说明文档。产品原型可以让用户验证产品的创意,加深产品经理对产品的理解,避免开发团队浪费时间和精力开发没有把握的产品。测试的作用是理解目标用户如何看待产品解决的问题,发现原型与用户期望不一致或者不相容的地方,从而完善产品。对一个用户用心的观察,可以发现产品设计中的很多细节性问题。一切的错都是产品的错,用户永远没有错,我们要明白这一点。产品经理要敢于承认自己的错误,虽然付出了心血的东西,自己很难割舍,但是我们需要明白,一旦错误的产品面向市场大众时,它所引起的损失是不可估量的。
产品说明文档包含的范围很广,名字也挺别多,有产品需求文档、市场需求文档、业务需求文档、功能规格书等等,内容覆盖范围、详细程度、文档本身的质量差别很大,就连形式也是变化多端,有的是word文档,也有Wiki页面,也有用专业的需求管理工具生成的。由于是文字,很难将产品的功能特性写清楚,结果花了大量的时间编写,却很少人阅读。
使用高保真的原型来取代说明文档,可以详细体现产品的功能需求、信息架构、用户体验、交互设计、视觉设计等。放在真实的客户面前进行可用性测试,观察他们是否清楚如何使用,是否渴望使用你的产品,只有通过可用性和价值性测试,产品说明文档才算合格,产品才值得开发。
更让人吃惊的是,使用高保真原型还可以大大缩短产品上市时间。因为已经通过测试的高保真原型彻底解决了以往需求说明文档随时修改的问题。所以与其花很多的时间去编写说明文档,既没有读,又无法测试,还不如创建高保真的原型,与团队一起测试,交给目标客户进行测试,也许要反复修改多次才能确定原型,总比开发几个月后,做出一个糟糕的产品再重新返工更划算。
五、在产品发布前,至少保证特约客户是满意的
使用特约用户是确保产品不偏离用户需求最简单有效的办法,同时也是向潜在用户宣传、推荐产品的最佳手段。寻找特约用户可以解决两个问题:深入洞察目标用户的需求,又赢得用户对产品的推荐。
虽然客户不能直接给出产品需求,但他们能帮助你确定产品需求,挑选目标客户为特约客户,配合开发团队验证产品设计、回答问题、试用软件。如果能满足特约客户的需求,他们会乐于推荐产品。
特约客户最清楚产品要解决的问题,因为这些麻烦正在困扰着他们。让特约客户提前试用产品,越早使用产品就意味着越早解决他们的麻烦。
一般不要向特约用户收软件费用,否则合作关系将会变味,我们需要的是开发产品的伙伴,不要变成特约用户开发产品,最终变为了特约客户的特定要求,而不是满足通用客户的要求。
如果在邀请特约客户时遇到困难,很可能是因为产品要解决的问题不像前面想象的那么重要,这就意味着将来也很难销售出去,如果真的出现这种情况,我们要再次验证产品的创意是否有价值,可能需要重新考虑产品计划。
六、市场调研不如尽早、反复地进行可用性测试
调研的方法有很多,包括用户研讨会、用户调查、产品使用分析、拜访用户、可用性/现场测试、同类产品分析。市场部门夸大了市场调研的作用,而产品部门只看到了其局限性。结果有的团队忽视市场调研,产品偏离了正确的方向,有的团队太依赖市场调研,陷入了偏执。值得重视的是,市场调研结果可以作为研发产品的依据和参考,但不能决定产品研发的方向。成功的产品是基于以下两点认识:深入理解用户需求,以及明白什么样的解决方案在现阶段是可行的。
建议最好的方法是尽早地、反复地进行可用性测度,观察用户使用现有产品的反应,收集反馈意见,了解他们的真实想法,从用户的视角重新审视产品,不光阅读反馈信息,更要观察,记录用户的行为和反应。
合理地利用市场调研工具和方法可以回答以下几个关键问题:
1、谁是目标用户?
2、用户会怎样使用产品?
3、用户能想明白怎样使用产品吗?障碍在哪里?
4、用户为什么选用你的产品?
5、用户喜欢产品的哪些特点?
6、用户希望如何改进产品,增加哪些功能?
七、产品迭代并不是一味地增加功能
很多情况下,添加的新功能不仅不会为产品增色,反而会让开发产品性能变得更糟糕。我们可以进行请用户测试产品、向客户人员、销售人员了解情况,根据产品上的实时数据分析,通过分析这些数据,再结合产品的路线图及产品原则,列出想要添加的功能。
迭代改进开发产品不是简单地满足个别用户的要求,也不能对用户调查的结果照单全收,你应该找准方向,分析关键指标,有针对性地改进产品。
八、采用增量式敏捷开发模式取代传统模式
敏捷开发就是螺旋式开发,基本概念就是将产品功能切成为独立的、可以验证的小功能。这些通常是4-6周的时间,一些软件开发中会降到1-2周的时间。通过这种快速的迭代,提升项目的进度和质量。可以按照以下步骤来完成:
1、软件开发任务必须可线性分拆到独立验证的部件中,也就是说,如果某一工作任务完成后,经过验证,后续的重构工作不会很多或只需少量的工作。这一点非常重要,这也是很多专家认为敏捷开发不适用硬件开发最重要的主张,因为硬件开发在迭代后重构时间过长。
2、将工作分解到5个或更多的迭代,理想的情况下,每次迭代时间长度为2-4周。
3、每次迭代结束时验证产品的质量,并修复所有的主要缺陷。
因为需求是易变的,因此不像传统开发那样,一开始就制定整个产品的详细开发计划。而是提倡小步快跑的方式来开发整个产品功能,通过一个小计划接着一个小计划,通过反复迭代,最终实现产品的自我完善。能够看出,这种短节奏、快调整的开发模式,对于传统开发模型来讲,最大的好处是灵活多变,反应敏捷,任何时候,只要市场有变化,就马上调整下一步的开发计划,甚至是彻底放弃,及时止损。
九、视觉美感与功能可用性同样重要
许多企业开发软件认为产品视觉设计不重要,协调的配色、优美的字体、漂亮的布局只是花哨的外表,没有实际意义,重要的是功能和价值主张,但我们坚信,视觉设计虽然不能达成功能和价值,但可以满足用户的情感需求。
良好的交互设计满足产品功能、可用性的要求,而良好的视觉设计满足用户的情感需求,总之,良好的用户体验是产品交互设计、视觉设计共同合作的结果。
十、产品发布后的快速响应也是改进产品的最佳时机
产品发布后,多数公司会迅速撤走为研发产品和发布产品整合的资源,急于投入下一个项目,殊不知此时正是收集反馈信息、改进产品的最佳时机。急于撤军是项目管理和产品开发流程中的大忌。只要稍微延长项目周期,观察用户对产品的反应,效果就会有天壤之别。产品发布后的几天至一周内,所有项目成员应该留出时间作为快速响应阶段。这个阶段的主要工作是快速响应、处理产品发布后的用户反馈意见。关键问题不在于是否会出现问题,产品永远不可能完美,总会存在问题,关键问题在于能多快的解决问题。
综上所述,好的软件开发产品具备三个基本条件,价值、可用性、可行性,三者缺一不可。“价值”就是客户愿意采购。“可用性”就是软件开发的功能是否实现,是否实现最佳的用户体验。“可行性”就是技术上是否可以实现。
洛阳森竹软件科技有限公司—洛阳软件开发|洛阳网站建设|洛阳小程序制作|洛阳APP开发|洛阳软件外包|洛阳商标代理|洛阳知识产权|洛阳商标注册|洛阳软著申请|洛阳版权登记|
声明:转载此文是出于传递更多信息之目的。若有来源标注错误或侵犯了您的合法权益,请作者持权属证明与本网联系,我们将及时更正、删除,谢谢。选择森竹服务,开发少走弯路——洛阳森竹软件科技www.lysenzhu.com