网站搭建报价,企业的网站建设费账务处理,免费下载素材网址,营销型网站建设公司平台产品的实现需要做好产品规划#xff0c;而产品的规划决定了产品的方向。本文从战略规划的重要性、产品定位、设计产品架构图三个方向#xff0c;详细地为大家梳理了产品实现的前期准备。 我们知晓了如何去发掘问题#xff0c;并找到解决方案。 可对于问题的处理#xff0c… 产品的实现需要做好产品规划而产品的规划决定了产品的方向。本文从战略规划的重要性、产品定位、设计产品架构图三个方向详细地为大家梳理了产品实现的前期准备。 我们知晓了如何去发掘问题并找到解决方案。 可对于问题的处理我们可以临时应付也可以相对稳固甚至于可以扩展挖掘以解决长期的问题和隐患。 基于互联网可快递迭代的情况以上三种处理方式都有其可取之处。 但是对于产品的整体性和发展来讲需要的是战略规划需要的是前瞻设计。 随着社会的快速发展开荒式的创业模式已经基本不存在加上大量资本存在快速入场和绞杀的情况这种可能性更加微乎其微。 随着房地产的严控过去一段时间的电梯式经济模式也已经不适用了。 坐上这趟电梯后续就不用怎么管收益、得到蹭蹭上涨的时代已经一去不复回了。 是的这是一个攀岩时代有多高的能力就上多高的台阶上了台阶还不一定稳还得小心意外风险。 让每一个人都在奋斗中去实现自己的价值。 产品的实现就更需要做好战略规划定好自己的北极星需求搭建好自己稳固的框架来实现稳扎稳打的推进。 先控制后碎部步步检核。 一、战略规划的重要性 在现实中遇见问题解决问题才会触发思考才能提升更进一步。 随着入行的深入见识了很明显的行业问题 没有最小闭环概念没有实现子系统的良好分割没有串联清楚全部的业务没有定好产品的优先级顺序。 1. 没有最小闭环 没有最小闭环常表现为只做功能未做直接的统计报表未做数据导出功能。 例如做了考勤的工作却未做出勤天数、异常打卡、迟到、请假、加班的统计数据。 功能应用是其中很重要的部分但是结果的反馈却能够提供很好的用户体验降低切换使用平台的抵触心理。 没有最小闭环也体现在整体业务流程没有完全梳理完整在哪些部分可以打断在哪些部分可以扩展。 例如在电商环境下购物的整个流程就是最小闭环从选择商品到下单到订单支付到收货确认这就是一个最小闭环。 但是基于最小闭环可以继续扩展如下图所示 2. 没有做好子系统分割 没有子系统做好分割主要是系统间的解耦问题。 为什么系统间的解耦很重要 按照现在B端的系统来讲少则6、7个子系统多则10几个几十个。 当前一个系统需要修改没有做好解耦的情况下就需要在新的代码里整体测试一遍会导致测试的工作量急剧增加也就是动一发而牵全身。 另一个就是修改了一小部分每个部分的人员都需要在出现问题就需要各种追查。这在实际上是不需要的。 如下图所示将一个系统抽象出来主要由三部分组成系统本身内部的功能、数据输入依赖输出能力。 订单系统需要依赖商品管理系统实现基于哪些商品下单输入依赖就是商品的查询。 对于订单系统来说输出能力就必须有订单查询能力。 而同时对于商品管理的系统来讲商品的查询就是他的输出能力。 做好系统间的独立就需要明确子系统本身功能集合明确系统的输出能力。 基于这个良好的解耦在其中某一个部分修改时就能明确是这个系统本身的问题。 如果存在接口调用的情况那就是需要做接口兼容。这样解决了之前需要联动才能完成的难题。 还能实现各个系统本身的自成长只要持久保持之前的输出能力后续的无限扩展就是内部系统的成长空间。 3. 没有串联清楚全部的业务 公司的发展一般模式都是先做一条主要的受益路线然后基于受益路线扩展上下游扩展路线的宽度。 上下游的事情比较难一点是绝对的跨行业情况。而横向扩展业务是绝大多数的选择。 比如正在经营的是一条销售线是去发展销售物品的上游生产线还是扩展更多的售卖渠道甚至于扩展更多产品的销售更多的倾向后面的部分。 基于公司业务的情况所实现的系统需要去支撑整体业务的运转。 就需要业务本身相对独立而在某些环节又是相同并行的就需要在系统实现上一一拆解。 在实际的案例中两种不同的业务模式代理、佣金基础的业务执行是一样的只是在费用结算时是不一样的。 代理依据订单来直接结算订单中的金额。 而对于佣金模式来讲则是以最后卖出去产品的数量来结算。 就是在这看似环节一样只在某一个环节不一样的情况下需要去拆解深挖。 以上的案例没有按照业务模式去完全拆解各个业务模式的支撑统一按照订单、第三方数据记账、销售结果上报的模式来处理就存在较多的问题需要去处理导致业务缠杂在一起。 同样是订单模块代理的订单需要垫付保证金需要追踪货物货物报损做到代理公司身上费用结算时包含保证金的处理。 而佣金模式则是需要公司给公司交保证金而不是订单内货物保证金整个跟踪过程并不需要实时跟进和反馈只需要确定最后的销售结果上报。 缠杂在一起时用户学习、使用困难学习成本高。如若直接拆分成为代理模式以及佣金模式就会爽利很多。 在业务拆解上不要偷懒。尽量的拆解出来最原始的材料再重新组合。 如果经多方、多次验证可以合并再统一。 子系统的一部分可左可右时一定再检核一下用最小闭环去检核一下。 去长远的角度看从更高层次去看从更多角度去看可左可右是肯定存在区别的只是当前是否能够识别。 要是万一难决断就选择其中一个并把当时考虑到的点记录下来。 互联网快速迭代的发展是可以兼容下部分偏差的。记录下来也是后续自我优化、对照的信息来源。 4. 没有定好产品的优先级顺序 B端系统简洁一些的子系统会拆解为6、7个复杂一些的或拆解10多个甚至更多。 在系统落地上一定做好子系统优先级顺序让前置系统先上线接受用户的真实使用从用户手上获取最直接的反馈。 系统研发常常出现经过调研确认、详细设计、业务评审、需求评审、测试检查、运营模拟等一系列情况后仍旧不符合实际的使用场景。 其实这本身长链条的传递就容易信息丢失更何况还存在调研对象不知道互联网模式的信息偏差存在不完全一致是现实存在的。 这个或许有点觉得不可思议但这就是我们的专业认知偏差我们以为我们知道实际上我们可能真的不知道。举个例子微信下面的四个菜单分别是。 基于这种情况产品研发的最好验证是先运行起来哪怕不是很好。 基于产品设计的关键流程整体设计是没有问题的出现的偏差主要是业务的熟悉度问题信息表达的问题。 先把一部分功能运行起来就能发现业务的盲区以及相关干系人的沟通范式。 第一版本哪怕是很小很基础的部分上线后运转起来再发现问题调整沟通就能迅速让这一环节整体运转起来。 这里同时也说明了最小闭环、系统分割的重要性。 最小闭环让这一块的功能完全转起来不会存在做一部分事情然后另外的事情又需要其他工具帮忙才能完成小细节最小闭环出的统计报表要有导出功能哟。 系统分割好当前系统可继续做升级优化上下游的系统可以独立研发基于新的变化做相应的调整就可以。 正是因为系统分割做得好解耦好新系统可以独立测试然后串联已上线的部分延长整体的生产流程类似火车车厢的拼接。 随着各个车厢的完成链接上线运行整个火车就越来越有生产力和价值。 在互联网产品的研发中一个系统的实现周期相对较长子系统之间存在相互依赖若是前置依赖没有完成后面的环节即使完成也不能纳入整体使用这对于研发团队是有很大打击的。 经历过一个团队系统复杂很高拆解子系统近20个需求的沟通确认也存在很大的问题在需求评审沟通上打一些折扣在执行上研发技术因为技术难点再截取一部分数据兼容、历史版本的处理再牵连一下整体就是一个滕网状态。整体在最前期有些冒进做了很多的系统工作整体的工作量巨大但是能交出去并真正使用的部分很少。 其中还因为产品需求调研的问题和思考逻辑的问题四大主要功能模块都经历了3次以上的改版。 最惨的是不是基础数据提供的2个系统每个经历3次改版还没有到用户手上验证过1次。好吧就是我当前的团队情况我认为我知道怎么办也提供了方案却没能被采用就在这里进行自我的深度剖析。自我较劲也好自我证明也罢就是希望通过复盘的方式让自己想的更完善一些。当然团队也有了新的改变就跟随团队一起前行吧。 产品的需求在团队里反复来了3次这个时候研发已经很不信任产品了。 为了稳住这个信任要花费很多精力啊 在这个情况下我还看到了互联网产品可能不成功的另一个原因产品团队的反复消耗掉了团队的信任团队内部战斗力降低。 整体战斗力的降低和士气低落导致向上获取资源变难最后产品的落地成盒。就在这里初窥管理的艺术和能量。 战略规划就是为了规避这些问题消除团队内部的内耗指明前行的方向在搏击互联网浪潮中极大的提高成功率。 二、做好产品定位 需要做一个好的战略规划就需要制定一个标准用于各个环节的决策产品定位就是这个标准。 所有的需求、团队资源是一个产品的小兵如何用有限的人力资源训练好自己的士兵在市场上打出来一片江山就需要建立自己的大本营。 为建立好自己的大本营需要回答核心的问题 这款产品以什么方式重点满足用户的哪种需求 “用户的哪种需求”是确定核心用户群的核心需求“重点”是把关键的需求做深做透彻“以什么方式”是在现有团队的条件下给出最优竞争力的解决方案。 这个需求要不要做这个需求怎么做这需求这样做能不能行…这一系列的问题都需要依据产品定位来确定。 在做产品定位时一定要找准自己的真实用户群。 即时通讯软件的用户是普通用户群而细分的相亲即时通讯软件的用户则是适龄单身青年。 客户管理软件的用户群则是销售代表而销售管理软件的用户群则是公司管理层甚至销售管理软件会内嵌客户管理软件。 这时客户管理软件就需要支撑管理层的功能例如客户的分析、评价客户的反馈客户的分配… 销售管理软件目标用户是公司级老板及销售总监级在功能的实现上辅助销售更好的做销售是延伸而记录销售的过程数据并基于过程数据分析销售情况及对销售代表进行评价才是支柱。 基于真实的用户基于真实用户的核心需求才能更恰当的搭建产品的最小闭环也才能最佳的做好产品定位。 微信是一种生活方式。 在每一次的微信升级中提示语句更多的为修复了一些已知问题。 在最开始的时候还浅意识认为基于微信这么大体量新一版的更新必然引起众多媒体的宣传和粉丝的挖掘测试因兴趣而引发推广是一种营销方式的延展。 实际上也正是因为这个体量那就没必要用这种方式来营销产品。 可是换做以产品定位来进行解读这个那就理所应当一些了。 微信是一种生活方式既然是生活就不需要太多的打扰与过多的干扰就是在我需要办什么的情况下就会出现需要的帮助及工具。 基于这个情况那每一次的版本升级是为了完善之前生活方式下可能走不通或有问题的那更新之后之前用那个生活方式的人就自己去经历而不用这个生活方式的人根本不需要感知到。 深度挖掘和匹配这就是产品定位的意义和作用。 同时产品定位也不是固定不变的随着市场的变化和发展在整体公司战略调整中是需要及时调整产品定位的。 互联网时代信息传播速度变快各个产品的竞争也日益严重。 更主要的产品之间的竞争并不一定来自直接竞品或者潜在竞品。存在跨行业竞争甚至于降维打击。 洛基亚47%的市场占有率也抵不住苹果智能手机全方位的碾压一个通讯工具是完全不可能抵抗一台能够通讯的电脑的。 柯达相机和胶卷即使到最后时刻也依旧是市场上最优秀的产品只是因为数码相机的发明未来已经没有胶卷的位置了。 银行或许怎么也没想到支付宝的出现让ATM机、线下网点、运钞体系、点钞能力员工、百万级的柜员原本引以为傲的整个体系在未来不被需要“无现金社会”达成典型的降维打击。 时代在飞速的前进产品既需要在时代的洪流中瞄准自己的锚钉住自己的价值也需要在适时的时间放开锚激浪潮头。 三、设计产品架构图 明确产品的定位描绘出产品的核心此后就需要将定位在现实中拆解开来逐步去实现。产品架构图就是落地实施前最好的指导。 类似建房前需要进行施工图设计进行材料入驻之后才是按部就班进行整体的建设。 产品架构图也需要达成这些指导主要包含产品的子系统构成系统之间的依赖关系从而也确定系统的优先级顺序。 框架搭建的好对于未来的扩展性就好很多。 尽管在软件研发中系统重构几乎不可避免但好的框架可以支撑更广泛的业务也能够在更大程度兼容业务保持更持久的生命力。 框架结构更稳定墙面完整性、隔热隔风能力更好房内配置更加稳固、可迁移性好构建完整的一间房本身的安全性、舒适性、实用性则更好。 而本身坚固安全的小房间可以相互叠加构建成为更大的建筑。 我们拆解的每一个子系统就是一个房间。 1. 电商MVP 以电商产品架构为案例进行产品架构的落地设计完善。 初期的电商就是将线下的店面销售搬上线利于客户下单是直接的直营销售。 初步形成主要是展示自己有多少商品让用户注册之后立即能够查看所购买内容找到自己所想的商品则立即下单并完成支付之后进行配送的跟踪则达成整个订单的完成。 则系统设计规划为商品管理、用户管理、订单管理、支付管理、配送管理。 这实际也是电商模式的最小闭环实现电商系列的MVP。 适用于店面直营销售可用于社区周边商超提供该工具利于周边住户下单购买。 2. 京东初始产品架构 随着客户的发展需要扩展相关业务的支撑在营销上进行发力。 需要支持获取客户、客户激活、客户变现以及客户列表也就是支持营销活动。 则系统规划扩展用户等级管理、营销活动管理。 用户等级管理实现VIP等管理以区别客户的不同潜在价值为运营活动提供支撑。 营销活动管理则实现活动通路满足打折、满减、满赠等一系列营销活动。 京东最开始着力在3C电器的销售初始也更多的坚持京东直营。 则需要以上产品架构的支撑。 之后京东决策在物流体系上发力构建更为快速、便捷的物流体系形成了京东的核心竞争力。 支持物流扩展出物流管理、仓储管理系统。 一个人的关注度有限加上产品体系的增大管理人员易存在较多盲点。 基于业务基于实际情况进行风险预警管理可以实现在未发生前发现问题在问题较小时尽早处理问题在问题发生以后总结经验防止类似问题重复发生扩展风险预警。 3. 电商平台化 以上均是一个店家的情况实际电商的模式存在很大部分的相似性可以实现一套产品管理很多商家产品则需要扩展完善。 既是实现平台化就需要实现商家管理扩展商家入驻的业务流程。 基于运营活动精细化的管理在订单完成时实现一定的经验积累及成果积累获取用户更多的使用时长增加客户黏性。 同时也通过积分的方式让利部分让用户获取更多的“实惠”逐渐将产品渗入到用户的生活中去从而扩展出积分管理。 大数据挖掘和分析在当下已经逐步趋于日常。 每个用户的使用偏好同样是洗发水不同用户可能偏好不同的品牌。 各个用户可能处于他自己的不同阶段有人可能处于画画研究的痴迷阶段有人可能处于初当奶爸的阶段… 大数据分析构建用户画像将最合适的产品主动推送到需要的用户身上极大的增加了用户好感也加快了产品变现周期扩展出数据挖掘。 产品的设计及规划立足于解决现实业务问题需要以业务为基准解决业务的实际问题凸显出产品的优势。 以上以电商行业为例初步构建产品架构图梳理产品规划。 以下为经验总结输出通用产品架构图。 当前业务的急速发展技术的快速迭代都在加速这个时代的变迁。 现如今已不简单的只是产品架构的搭建而其中各个环节的强化都在变得更具有扩展性和包容能力。 业务中台、数据中台将产品适应性、扩展性都急剧扩大。 在大平台的发展上这些新的技术是需要产品、技术共同去落地的站在巨人的肩上走得更远。 关于业务中台、数据中台且先留余地。