如何选择产品最优路径以行情交易终端产品为例

　　产品设计最重要的不是产品经理知道产品需要做成什么，而是产品经理知道如何找到一条最优的产品路径，以最小的代价，最少的时间，实现出本阶段内最佳状态的产品。
　　01：hr什么是好产品？
　　对于这个问题，每个用户可能都清楚它的答案一款产品通过加上哪些功能，可以变得操作更简单，体验更良好，功能更全面，几乎每个人都可以提出非常多的建议。
　　但我们做的每一件事情，背后都有很多隐形代价，当做了这个需求后，它的代价可能是另外一个也很重要的需求被延后开发，或者是另外一些功能的实现效果打了折扣，既机会成本。
　　所以，产品设计最重要的不是产品经理知道产品需要做成什么，而是产品经理知道如何找到一条最优的产品路径，以最小的代价，最少的时间，实现出本阶段内最佳状态的产品。
　　所以，产品经理需要能够看到所有的产品路径和解决方案，并了解每一个路径和方案的优劣势和性价比，最终做出最优决策。
　　金融行情交易客户终端的应用，既可以给炒股用的，也可以交易期货、现货、邮币卡或其他虚拟货币等，其产品模式基本都是由行情模块、资讯模块和交易模块组成。
　　此类产品的形态和通用路径基本都是：自选amp；gt；分时amp；gt；K线amp；gt；交易。
　　通用的主路径基本都是唯一的，但是可选的分支路径则可以定义出很多，譬如以用户操作路径为导向的产品功能研发路径：自选amp；gt；分时amp；gt；K线amp；gt；指标amp；gt；盘口amp；gt；F10amp；gt；资讯amp；gt；成交明细amp；gt；交易amp；gt；资金。
　　这是一条理想状态下的产品路径，所有的功能模块都要想，交付时间也不着急，从用户操作视角一层层递进。
　　这样实现的好处就是稳，前一环节的功能为下一步的新功能提供基础，但是当项目遇到了各种矛盾的情况下，时间和研发资源可能不足以支撑这样的常规路径，那么就必然面对各种取舍。
　　所有的时间问题，背后一定都是工作量问题。
　　所以，当研发资源有限的情况下，产品经理的一种常规解决方案就是：保留流程链，但是减少流程环节个体上投入。
　　如果还是保留常规的产品主路径：自选amp；gt；分时amp；gt；K线amp；gt；指标amp；gt；盘口amp；gt；F10amp；gt；资讯amp；gt；成交明细amp；gt；交易amp；gt；资金；
　　那么还可以调整的便是：
　　自选（先不实现云自选同步功能）amp；gt；分时（不做缩放功能）amp；gt；K线（减少K线的可选周期）amp；gt；指标（减少指标数）amp；gt；盘口（减少字段）amp；gt；F10（减少字段）amp；gt；资讯（不提供分类和标签功能等）amp；gt；成交明细（仅保留基础字段）amp；gt；交易（减少快捷交易下单方式）amp；gt；资金（减少报表维护）。
　　这种思路的优点就是流程链仍旧都保留，只是下调了质量标准，但是当未来又有时间了之后，则可以重新补回来，且届时不会出现架构和布局上的大问题。
　　但是这种模式会暴露更多的矛盾点，核心是通过减质量的方式达到，本来是项目时间进度的矛盾，现在则是功能操作和体验的矛盾，容易陷入被动的需求缝补循环中。
　　那么另外一条可考虑的产品策略方式则是：通过深入理解业务和需求，进行功能性的合并，但是仍可支持各类不同的操作需求。
　　下面就以一个产品为例，做步骤解析：
　　02：第一步：对功能链的功能环节进行理解，找出共性环节，进行合并整理
　　譬如分时页面头部的合约基础属性与盘口、F10中的属性，有多少是相同类似的，如何做巧，将这3者有效关联复用，譬如保证金金额、保证金比例和杠杆这3个字段，有极大的效果相似度和计算公式，那么便可以选择一个字段展示即可。
　　首先剔除了这些不同页面中的重复元素后，接下来则是页面功能的设计，或许便不需要独立的分时、盘口和F10这3个页面，而仅需要在分时页面保留下一个合适的切换信息框，用以展示筛选后保留下来的元素。
　　由上图可以直接看出：图1中的涨跌图3中的涨跌，图1中的最新、买卖价、持仓图3中的最新、买卖价、持仓，图2中的涨跌停图3中的涨停跌停，图1的合约属性图2的合约属性
　　第二步：从后端架构来思考前端应用层面功能的取舍与重新包装
　　所有的复杂系统的研发必然都是后端的工作量大于前端。
　　譬如，交易模块中的止盈止损单和云条件单功能。
　　如果是本地开发，则这2者的功能架构基本一致，无非是止盈止损单是云条件单的一种特殊选定品种和方向的模式。
　　从用户需求上来看，条件单也是大集合，止盈止损单是小集合，也就是条件单的产品功能覆盖了止盈止损单，而且后端架构上也对应一致。
　　故而，产品经理的决策便可以是：保留云条件单，合并前端的止盈止损单与云条件单页面，如果做的更好的话，在云条件单页面中以良好的用户体验来表达出止盈止损单的状态概念。
　　另外，性价比高的小东西可以多做，在这个案例中，止盈止损单的页面被暂时砍掉了，但是止盈止损单的按钮入口（譬如在持仓或下单的场景）可以保留。如此，用户其实并没有发现少了功能，需求操作也没有受到任何影响，但是少了一个前端页面的工作量。
　　第三步：拥有更全面的视野来思考产品
　　功能设计、原型交互、数据定义，这些已经是后期的执行环节。当我们去思考一款行情交易APP，最好的需求体验是什么时，我们需要清楚地知道这唯一性的答案：帮用户赚到钱。
　　正如借贷类产品的最好体验就是借到钱，返佣类平台的最好体验则是省钱，至于稳定性、体验性、操作模式都是为这些核心目的服务。
　　那么，我们来分析一款行情交易APP如何帮用户赚到钱？是要依赖丰富的盘口信息，还是依赖丰富的多种下单方式？
　　解决这个核心问题需要和业务运营共同合作，如果直接提供给用户胜率较高的免费策略指标、有较高价值的操作建议方案的资讯内容，这些可以直接影响到用户的盈利赚钱需求，哪怕之前体验功能做得再一般，有这些带盈利价值的功能远比体验层面的优化更重要。
　　所以，由此分析得出：
　　在配合的情况下，有价值的资讯和指标功能比其他各种的工具小功能都更加重要。至于各种不同类型的快捷下单方式，限价单、市价单、超价单、排队价单等仅仅是前者操作的补充结果。
　　故而，唯一的真正主路径只有：分时amp；gt；指标（能指导盈利的指标）amp；gt；资讯（能指导盈利的资讯）amp；gt；交易。
　　除此之外，其他还能做得更好的，便是项目管理了了解和熟悉自己的团队，知道自己的研发团队更擅长最哪个功能领域模块，准确地评估时间，定义好关键路径，做好更兼容的架构设计，避免返工等。
　　另外，还有就是要留意对用户敏感但是一般不会表述出来的细节点，譬如移动端的流量消耗问题。
　　譬如一个行情交易的APP产品虽然很稳定，速度也非常快，但是使用起来，一个小时耗1G的流量，用户显然是无法接受的。
　　要解决这个问题，有很多的工作量需要提前处理，譬如本地缓存、增量加载和按需推送等，这些需要在架构层面便需要兼容支持。