产品工作流程
工作流程一、 贯穿始终的任务（非线性的）
1.1 需求收集
（1）描述：需求基本可分为两种：主动采集和被动采集。主动采集是指深入业务方工作环境，去发现流程的不合理、日常遇到的问题，将问题剖析后转为需求；被动采集则是指业务方在工作中遇到的问题，并且迫切希望解决的问题。需求收集过程中沟通的问题：
l 业务方过于强势，对于问题直接给了不太专业的解决方案，照做就完蛋了，也完全体现不出产品的价值，要学会提问，思考为什么他们希望以这种方式解决问题。
l 业务方回答不到点上，长篇大论，完全跑偏。这时候直接打断并非好方法，我习惯是耐心听取，提取有用的信息，并在恰当的时机与他们再次确认，适当得把话题掰回正轨。
l 业务方不够专业，不能清晰表达流程，沟通起来效率不高。可以索取业务原始数据和协助文档，从结果倒推流程，再找业务方确认。
（2）工具：
l 五why分析法：用于痛点挖掘（涉及多角色时需要分别梳理不同角色的痛点）；
l 用户故事：抽象业务，罗列痛点，一句话描述需求，一群什么样的用户在什么场景下想解决什么问题，解决过程碰到什么问题，最后用户怎么解决的。
（3）产出物：
l 需求背景：业务介绍，什么人在什么过程中遇到了什么问题，希望怎样。
l 涉及角色：参与具体业务的所有协作人
l 对接人：协助产品了解当前业务逻辑的人
1.2 需求整理排期
（1）描述：将需求入库后，需要定期整理，将已经不满足当前业务的需求出库，能合并的合为一个需求，有必要拆解的拆为多个需求。按照优先级得分、紧急状态去规划近3个迭代的需求（并非定死，迭代周期期间有可能穿插一些紧急的需求，按实际情况操作）
（2）工具：
l 需求打分表：按照需求类别、需求级别、优先级别等不同纬度打分，给排期提供数据上的支撑。
l 四象限法：同样用于评估哪些需求先满足，哪些可以先缓一缓。
（3）产出物：
l 近期三次迭代的需求规划
1.3 解决线上问题
（1）描述：产品经理的本质就是用合理的方式解决一个又一个难题。随着新版本迭代或者已有功能的使用中，业务人员常常会遇到系统出问题，有可能是系统bug、也有可能是功能流程问题、甚至仅仅是使用问题（无法理解怎么操作）等等。面对不同的问题，需要灵活处理，自己能解决的最好，不能解决的要及时调配资源辅助，特别是一些紧急的问题，耽搁少许可能就会导致严重的损失。
（2）工具：
l 强大的内心：遇事不慌，冷静得直面问题
l 积极主动的态度：客户、系统问题，产品都是首当其冲，你不冲在前方，也别指望在他人引领下走向光明。
l 责任心：事不关己，高高挂起的态度永远成为不了优秀的产品
l 良好的沟通力：高效、专业，当然也要适当注意言辞
（3）产出物：
l 修复好的系统bug
l 问题转需求
l 客观正视自己设计的需求方案（用户不会用，还得多想想自己的原因）
1.4 跨职能协作
（1）描述：产品经理需不需要懂业务？答曰：产品经理必须非常熟悉业务（尤其是B端产品）。要达到业务和软件系统的最佳融合，产品经理必须十分熟悉业务，在产品架构、功能迭代方向上，确保业务能够有效落地。解决方案上，并非要把系统设计的多么完美，要尽可能结合现实，考虑实际落地场景，承担部分项目经理的责任。
（2）工具：
l 业务数据分析
l 业务方向规划
（3）产出物：
l 跟随业务优化的系统优化
l 数据分析结论和应对方法
二、迭代任务（线性）
2.1 需求设计
（1）描述：需求设计是产品经理硬实力的体现，需求文档力求逻辑清晰、易读性高，以确保开发团队内协助高效。在设计过程中，基于需求背景、用户痛点、业务场景、业务角色等梳理需求目标，以目标为导向思考解决方案
（2）工具：
l 用户现场调研：深入业务方的日常行为及工作，发现根本问题
l HMW分析法：拓展问题解决的方向，发散思维寻求更多解决方案
l 竞品分析：了解其他相似功能或模块设计逻辑，体验产品的过程中，重点关注用户、使用场景、需求，吸取主流设计模式的优点。
（3）产出物：
l 需求概括：需求背景、目的、目标用户等，这些在需求收集阶段就要梳理出来，在需求设计阶段细化
l 业务流程图：涉及角色、交互的系统，梳理关键流程节点，前期厘清流程避免后期大面积返工，当然最终流程也需要跟业务方确认后再设计细节
l 功能流程图：包含主流程、详细子流程，考虑多线程流程、逆向流程等
l 功能架构：按照层级结构往下拓展，eg：端（管理后台、H5）->模块（商品管理、库存管理）->功能（新增、删除）->子功能（批量删除）
l 信息架构：每个子功能需要哪些信息支撑，由下至上梳理
l 页面结构和原型：页面间跳转逻辑，页面内组件交互备注说明、业务规则说明等。
l 其他：修订历史、简单核心用例
2.2 需求评审
（1）描述：需求评审，是每个产品经理必须经历的工作环节。在评审会议上，前端、后端、测试、UI、业务方、领导等不同角色都有可能参与，每个角色对于需求的关注点不同，目的有四：评估需求的价值（做还是不做）、评估需求方案的合理性、初步评估技术可行性、明确需求开发的事项。所以如何高效完成需求评审、让大家都能理解你做的方案，是一个产品经理的基本素养，和赢得团队信任的基础。
（2）评审流程：
l 首先是界定需求类别：需求本身可分为：功能优化、功能拓展、新功能。不同类别的需求描述着重点不同。
l 介绍需求背景：上来就讲功能点绝对是莫名其妙的，可能讲完了在场各位连你到底要做什么都还不知道。
l 描述当前业务流程：明确涉及的角色，描述当前关键业务节点，目的是让大家都了解业务逻辑，以便去判断方案是否存在大方向的偏差。
l 描述需求目标：根据背景和业务流明确此次方案的边界，要解决哪些问题，谁通过什么方式来解决。
l 描述方案/功能流程图：列出主要的功能模块/功能点，讲清楚需要哪些功能点来解决哪些对应的问题
l 细致描述页面流程：采用逻辑+模块的表达方式，功能流程图上每个关键节点都是一个产品模块，先讲清楚每个链上的产品模块，再讲模块的功能。上帝视角与用户视角结合，既要说明逻辑、模块、功能等概念，也会从一个具体配置人员的角度讲一讲他们该如何使用这个系统。
l 描述需求考核指标：此次需求设计的效果验证，最好能提供一些可量化的数据指标，即完成这个需求后能带来哪些数据的变动。
（3）产出物：
l 会议记录：在会上，在讲的同时也要把出现的问题记录下来，整理待解决的问题，并与大家确认无遗漏
l 问题解决方案：针对待解决的问题，给出其他更合适的解决方案，小问题发出确认即可，大问题还要约第二次评审，无论是大小问题，在修改需求文档时都需要记录修订时间、内容、修订人，同时通知相关人员
l 版本排期：最后一次评审会确定就要排期，这个可以跟相关部门的负责人沟通，比如技术经理，需要多久时间完成迭代任务，什么时候提测、什么时候可以上线
2.3 参与技术方案评审
（1）描述：需求通过评审后两天，技术人员在充分理解需求后，要过一遍技术方案，产品参与技术方案评审有两个目的：第一是听技术人员讲一遍需求，过一遍核心业务点，可以了解技术人员对需求的理解是否存在偏差，是否有遗漏；第二同时也是产品学习的一个过程，去充分理解技术实现的过程，在需求开发过程中可降低沟通成本。
2.4 参与测试用例评审
（1）描述：提测前两天，测试人员要细致得列出所有的功能的测试点，然后在会上一条一条过，产品参与测试用例评审目的有二：第一是辅助测试人员完善测试用例，需求细节在文档中没有描述清楚，在会上就是很好的纠错环节；第二是发现自己没有考虑到的点，逻辑上的不完整，异常页面缺失等，尽早发现问题，规避风险，同时也警醒产品在下一轮迭代设计中，尽可能考虑周全。
2.5 测试周验收需求
（1）描述：测试周中期阶段，测试人员基本已经把需求主流程跑通了，产品要参与实现效果验收。一切顺利的情况下，把控实现的细节；如果有部分功能子需求来不及实现了，需要记录下来并入库往后排期。
2.6 迭代培训
（1）参与人：本次迭代涉及到的业务方人员
（2）培训框架：
l 功能适用场景：描述需求背景、此次功能目的和要解决的问题，必须要提及本次迭代的功能界线。
l 适用的角色：即谁会用到这个功能
l 功能逻辑，流程：各角色之间是如何使用此功能协助的，需要特别注意哪些点
l 操作指引：在实际的线上系统，完整操作一遍作为演示。
（3）目的：推进功能的使用，降低用户作出改变的成本
2.7 跟踪上线的功能
（1）验证需求：根据需求设计时设定的验证方案，通过线上数据、用户反馈、使用者建议等评估此次需求是否达到预期，找出达不到预期效果的根本原因，思考下一步工作思路。
（2）收集新需求：对于新上线的功能，业务方在使用过程中的问题需要详细记录，必要时转为新需求，持续跟进已上线的功能，不断优化迭代，适应业务高速发展。
绛旓細鏈湡锛孴ower灏辨潵鏁欏ぇ瀹跺浣曞揩閫熸惌寤轰竴濂浜у搧杩愯惀鐨宸ヤ綔娴佺▼锛屽疄鐜版瘡涓骇鍝佽繍钀ラ渶姹傜殑娴佺▼鍖栫鐞嗐傚彟澶栵紝Tower杩樿创蹇冨湴涓哄ぇ瀹舵彁渚涗簡MRD銆丅RD銆丳RD鍙婁骇鍝佽繍钀ョ敾甯冧節瑕佺礌绛夊疄鐢ㄤ骇鍝佹枃妗ｏ紝甯姪澶у鏇村ソ鍦扮悊娓呰繍钀ユ濊矾锛屽紑鍚ā鏉垮嵆鍙洿鎺ラ鍙栧摝锛屼竴璧锋潵鐪嬬湅鍚э綖涓閿惎鍔ㄩ」鐩湪Tower妯℃澘搴撲腑锛屾偍鍙互鐩存帴鎵惧埌浜у搧杩愯惀...
绛旓細杩欏氨鏄竴涓嚜鏈夊搧鐗屽埗閫犱笟鍏徃鐨勬柊浜у搧寮鍙戝叏杩囩▼锛圤EM鍨嬪叕鍙镐笌鍏剁暐鏈変笉鍚岋級锛岃繖涓紑鍙娴佺▼锛屼篃鏄疘SO9001璐ㄩ噺浣撶郴涓殑鏍稿績閮ㄥ垎锛屾槸ISO9001浣撶郴涓渶閲嶈銆佷篃鏄渶澶嶆潅鐨勪竴閮ㄥ垎锛岃蛋瀹岃繖涓祦绋嬪皯鍒欏嚑涓湀锛屽鍒欏嚑骞存垨鏇寸敋锛屾墍浠ヨ锛屽紑鍙戜竴涓畬鏁寸殑鏂颁骇鍝佹槸绉戝鐨勩佹槸涓ョ懢鐨勩備緵鍙傝冦
绛旓細鐮斿彂閮ㄧ粍缁囨垚鍛樺浜у搧鍚勫姛鑳芥ā鍧楃殑鐮斿彂鏂规杩涜绛栧垝锛岀紪鍒惰缁嗙殑浜у搧鍔熻兘妯″潡鐮斿彂鏂规锛屽苟缁勭粐鐩稿叧鎴愬憳瀵规柟妗堢殑瀹屾暣鎬у拰姝ｇ‘鎬ц繘琛岃瘎瀹″拰楠岃瘉锛岀紪鍒躲婂紑鍙戣鍒掕瘎瀹℃姤鍛娿嬨傜爺鍙戦儴杈撳嚭涔﹂潰鏂囨。锛氱數鍘熺悊鍥俱佸厓鍣ㄤ欢娓呭崟銆佸嵃鍒舵澘鍥俱佺‖浠惰璁¤鏄庛佽蒋浠娴佺▼鍥俱佽蒋浠舵竻鍗曘佽蒋浠惰璁¤鏄庛佺粨鏋勮璁＄ず鎰忓浘銆佽閰嶇ず鎰忓浘...
绛旓細鏂浜у搧寮鍙戣鏈変竴濂楃瀛︾殑绋嬪簭銆備竴鑸彲鍒嗕负鍏釜闃舵锛1銆佹瀯鎬濈殑褰㈡垚銆傛墍璋撴瀯鎬濓紝鍗冲垱鎰忥紝鏄寚涓烘弧瓒虫煇绉嶅競鍦洪渶瑕佽屾彁鍑虹殑璁炬兂銆傛瀯鎬濈殑涓昏鏉ユ簮锛氳喘涔拌呫佹壒鍙戝晢鍜岄浂鍞晢銆佺珵浜夎呫佸叾瀹冩潵婧愩2銆佹瀯鎬濈殑绛涢夈3銆佽惀涓氬垎鏋愩4銆佷骇鍝佸疄浣撳紑鍙戙5銆佸埗瀹氱敓浜т笌钀ラ攢璁″垝 銆6銆佹柊浜у搧杩涘叆甯傚満銆
绛旓細浜у搧鐮斿彂娴佺▼绠浠 涓嬩袱鍓浘鏄骇鍝佺爺鍙戠畝鍖栨祦绋嬪浘,浜や簰璁捐鐜妭琚鍔犲湪鎻愬嚭闇姹備笌瑙嗚璁捐涔嬮棿,鍙互鐩磋鐪嬪埌浜や簰璁捐璧峰埌浜嗘壙涓婂惎涓嬬殑浣滅敤,浣嗗疄闄呬笂浜や簰璁捐甯堝仛浜嗕粈涔,濡備綍涓庡叾浠栧矖浣嶆洿濂界殑鍚堜綔,涓嬮潰灏嗚繘琛岃缁嗙殑瑙ｈ銆傚湪姝や箣鍓,鎴戜滑鍏堣浣忎氦浜掕璁＄殑鏈川:瑙勫垝浜や簰琛屼负鏂瑰紡,璁捐杈炬垚琛屼负鐨勬渶鏈夋晥褰㈠紡銆 娌℃湁浜や簰璁捐...
绛旓細鐒跺悗锛屽湪杩欎竴姝ラ渶瑕佸畾涔 MVP锛堟渶灏忓彲琛屾浜у搧锛変互鍙婁骇鍝佺殑鍏抽敭璺緞锛堟渶灏忓叧閿笟鍔娴佺▼锛夛紝骞跺舰鎴愰渶姹傛竻鍗曚互鍙婂姛鑳芥竻鍗曪紝鎺掑垪濂戒紭鍏堢骇銆傞櫎姝や箣澶栵紝鎴戜滑甯歌鐨勭珵鍝佸垎鏋愬拰鐢ㄦ埛璋冪爺涔熸槸鍦ㄨ繖涓姝ュ畬鎴愶紝骞朵氦浠樼浉搴旂殑璋冪爺鍒嗘瀽鎶ュ憡銆傝繖涓姝ョ殑鏍稿績灏辨槸鍥寸粫鈥滆В鍐崇敤鎴蜂粈涔堥棶棰樷濇潵灞曞紑宸ヤ綔銆備笁銆佺粨鏋勮璁♀斺旀瀯寤轰骇鍝...
绛旓細浜у搧璁捐鐨勪竴鑸娴佺▼ 椤圭洰鍓嶆湡娌熼 鍓嶆湡娌熼氭槸椤圭洰绔嬮」鐨勫墠鎻愬拰璧勬枡杈撳叆鏉ユ簮锛屽繀椤诲拰瀹㈡埛灏辫璁℃柟鍚戙佽璁″唴瀹广佽璁￠鏍肩瓑杩涜娣卞叆鍦版帰璁ㄥ拰娌熼氥備織璇濊锛氱（鍒涓嶈鐮嶆煷宸ワ紝鍙湁鍓嶆湡缁嗚嚧鐨宸ヤ綔鎵嶈兘淇濊瘉鏃ュ悗椤圭洰鐨勯『鍒╄繍琛屻傚競鍦鸿皟鏌 甯傚満璋冩煡鏄骇鍝佹棩鍚庤兘涓庡競鍦虹浉铻嶅悎鐨勫繀涓嶅彲灏戠殑涓鐜紝鍙湁鎶辩潃浠庨浂寮濮嬬殑...
绛旓細涓涓畬鏁寸殑鏂浜у搧寮鍙戣繃绋嬭缁忓巻鍏釜闃舵锛氬垱鎰忎骇鐢熴佸垱鎰忕瓫閫夈佷骇鍝佹蹇靛彂灞曞拰娴嬭瘯銆佽惀閿瑙勫垝銆佸晢涓氬垎鏋愩佷骇鍝佸疄浣撳紑鍙戙佽瘯閿銆佸晢鍝佸寲銆傛柊浜у搧寮鍙戞槸鎸囦紒涓氫粠浜嬫柊浜у搧鐨勭爺绌躲佽瘯鍒躲佹姇浜э紝浠ユ洿鏂版垨鎵╁ぇ浜у搧鍝佺鐨勮繃绋嬨傛柊浜у搧寮鍙戣繃绋嬬殑绗竴涓樁娈垫槸瀵绘壘浜у搧鍒涙剰锛屽嵆瀵规柊浜у搧杩涜璁炬兂鎴栧垱鎰忕殑杩囩▼銆備竴涓ソ鐨...
绛旓細1.閮ㄩ棬鍒跺害浣撶郴鎼缓锛氬缓绔浜у搧閮ㄧ浉搴旇绔犲埗搴︺宸ヤ綔娴佺▼鍙婂伐浣滄爣鍑嗐 2.閮ㄩ棬宸ヤ綔缁熺锛氬叏闈富鎸侀儴闂ㄥ悇妯″潡锛堜骇鍝佽鍒掋佸畾宀楀畾缂栥佹嫑鑱樸佽冩牳銆佸煿璁級宸ヤ綔锛屾寚瀵笺佺洃鐫ｅ憳宸ュ伐浣滐紝纭繚浜у搧閮ㄧ殑楂樻晥杩愯锛涚粍缁囧埗璁㈤儴闂ㄥ勾搴﹀伐浣滆鍒掞紝骞惰惤瀹炲疄鏂斤紝纭繚骞村害浜у搧閮ㄥ伐浣滅殑鍚堢悊寮灞曪紱 3.鍐呭閮ㄦ敮鎸佷笌鍏崇郴鍗忚皟锛...
绛旓細閫氳繃璇勫锛屽伐鑹烘妧鏈汉鍛樺簲瀵硅瘯鐢熶骇杩囩▼涓彂鐜扮殑璁捐銆佸伐鑹虹己闄疯繘琛屽綊绾虫荤粨锛屽埗瀹氭敼杩涙帾鏂斤紝鍚屾椂淇敼鐩稿叧鐨浜у搧鍥炬牱銆丅OM鍙婂伐鑹烘枃浠剁瓑锛屽苟灏嗕互涓婂舰鎴愮殑鎶鏈枃浠跺拰璧勬枡鎸夈婃枃浠跺拰璧勬枡鎺у埗绋嬪簭銆嬪強銆婃枃浠跺拰璧勬枡褰掓。绠＄悊绋嬪簭銆嬪畬鎴愮鐞嗐佸綊妗宸ヤ綔銆備骇鍝佺敓浜у伐鑹娴佺▼鎿嶄綔绠＄悊 涓銆佹诲垯锛1銆佸伐鑹烘槸浜у搧鐢熶骇鏂规硶鐨...
