哈斯日志
纪录我们在网路上奔波的历程!
  • »新帖子
  • 信息与传播的散淡思索2013年10月16日
  • 互联网硬件的思维 2013年10月16日
  • McDonald’s Theory 麦当劳理论2013年10月15日
  • 基于垂直需求定制智能硬件方案2013年10月16日的演讲稿
  • 手机的第二屏---有多图建议wifi下阅读2013年10月16日
  • 以用户体验之名2013-10-18
  • 念碎碎--苹果的售后服务2013年10月18日
  • 有感于安卓应用市场2013年10月18日
  • 手机APP的选择探讨2013年10月18日
  • App割裂了移动互联网的体验2013年10月18日


  • » @twitter
  • 没有最好只有更好 2013年10月15日-哈斯日志
    没有最好只有更好 2013年10月15日
    星期日, 三月 26, 2017
    在网络产品的开发和项目实施的过程中,快速实现快速迭代,是大家的一个共识,这个有两个因由,

    其一,网络产品,一定是客户端和服务端连接协作的一种软件模式,通过服务端的升级或者推送,是能够让客户端实现升级和跟进的。

    其二,任何一个产品不放到足够广阔的应用环境中,都无法充分验证,而互联网时代的产品和应用环境尤其如此,复杂到仅仅靠样例case分析是无法归纳或者涵盖全部的,所以互联网产品、移动互联网产品都强调简单,再简单。精简产品模型,提炼核心价值,让核心价值足够简洁明快地显现给用户,把产品的价值高效地传递给产品,是所有产品的基本把握点。

    那么互联网产品到底做到什么程度算是完善的,算是可以进入迭代循环的,这是一个抽象又具体的问题。最近看到一篇文章提到麦当劳理论,很有意思,很多时候决策判断的过程是有点这样的无厘头[回复“麦当劳”可获取原文]。

    我所理解的麦当劳理论在互联网产品决策判断中的应用,跟这类情景类似,就是无法拿出最优解的时候,我们先拿出一个类似“麦当劳理论”这样的参照,这样决策的判断参照系就是清晰明确的。

    没有最好只有更好,在前进中发展,在发展中完善。那么做到什么样的产品状态才算是到了可发布状态,我归纳起来有这么几个特征:

    1 流畅使用:稳定性、可用性的基本问题要解决
    一个网络产品访问不稳定,要想正常使用靠运气,那你希望做成也就智能靠运气了。稳定的服务、清晰的价值输出是基本的要求。

    再有就是使用要流畅顺利,不能因为产品设计的逻辑因由,和设计者本身的主观偏好、甚至团队建制组织架构等非常因素,把产品的架构、产品的交互设计到繁复不可理解,难以接受的地步。

    而作为产品人员如何在个体认知和用户群体行为认知上达成比较好的一直,则是考验产品人员素养和能力的一个重要点。

    2 灰度发布,经过一定范围的“适配”测试,没有明显的事理缺陷
    如前面所属,一个产品在经历设计、开发、测试不可能完美无缺,即使你愿意投入时间,不断封闭打磨,也许要最终面向市场、面向用户各种复杂的使用环境和使用场景。更何况,今天这样一个开放的市场上,时间往往是最大的成本,我们可以投入的资源、人力和智慧上,与时间相比都是可扩展的,只有时间和机会是线性不可逆,错过了就失去了。

    原则上,可以实现灰度发布。所谓灰度发布就是新版本部分推送,经过一定周期的使用和用户实际参与的考验没有太大问题的时候,再逐步扩大范围,这样既可以整体系统的稳定,也可以发现、调整问题,以减少不好的或者问题的影响度。

    3 大系统小做,容易上线,升级更新不做大幅度的重新安装使用
    在软件系统架构设计上,我这里说的不是纯的技术架构,包含产品架构和产品更新迭代的逻辑,把一个复杂的系统精简掉、模块化掉,没一部分都单独存在单独发展,用腾讯微信技术总监周颢的语言描述就是“大系统小做”。这个说起来容易,做起来很不容易,君不见一个小APP动辄20M~30M的。

    怎么把大系统做小,也是看起来简单,其实不容易实现的一个功能,比如独立功能插件化、功能模块化,这是最简单最基本的思路,但是功能的拆分在产品和技术的实现上就不是那么容易搞得事情了。

    围绕产品本身的基础、核心功能做扩展,在保障基础功能的易用可用的前提下,不断把延伸功能通过显性化的方式、组件化的方式参与到软件设计本身中来,在软件设计中,看到的东西要以用户看到的东西为基础进行归纳总结,而不是以技术框架、技术团队、甚至公司的组织形态的东西来表现。

    This Written at 三月 26, 2017 by loverty.  

    0条评论

    发表评论

    << Home