产品需求

近来二次阅读苏杰著人人都是产品经理，还是很有收获，为了促进自己反思，特记录在此。 产品经理是关于事和人的匹配。事，对公式来说，梳理清晰的业务是根本，对个人那是具体的任务。人，要具备相应能力，知识，技能和态度。 项目经理是任务的执行人，不是提出者，需要执行，计划和控制能力。产品经理是任务的提出者，更需要创造力和项目管理能力。项目越做越确定，是个闭环，产品越做越大，开放式的。 产品经理要学会面对真正的问题，去追问本质，多问问为什么，目的是什么，这样才能更好的提供解决方案～产品。 只做一次的事情找可行解，反复做的事情最优解。 产品经理的成长过程，有输入也得有输出，需求收集调研，分析需求，方案设计，流程，线框，架构，开发，测试，验证，交付，运营，优化。 需求提出来，做出来，推出去。 提出来，就是业务痛点或者新需求，是要解决的一个或者一系列问题，据此提出解决方案，当然要反复推敲，调研，分析，并确定定位和目标，然后筛选出方案。 做出来，对应的是根据定的方案，制定设计出具体操作任务，涉及细节，并评估出需要的资源和时间计划，以及操作的流程和方法，并按照计划交付产品。 推出去，意思是将产品交给用户和客户，真正的解决业务问题，提现产品价值。在运营中发现不足，再提升优化。 让产品有用，可用，好用，有人用。 来源： https://www.cnblogs.com/uplove/p/11920609

误区 之前我没有项目经验，在上一家公司的项目管理上，我只是照葫芦画瓢。 产品发起，整个项目没有项目经理这一说。或者说有，但却真的感受不到，一丁点也感受不到。 产品发起会议，或者开发发起会议。无论谁来发起会议，一般都会针对于某一具体需求或者某一具体实现方式。 没有具体的任务规划，任务拆得不够细致。这个和开发自身有关系。当然那时的公司确实没有一些指导性质的模板和导师。 任务分得不够细致，就会导致工期评估差距比较大。 各种O们的临时紧急需求，很多O没有技术背景和项目管理背景。很多时候提出的需求都是发生在项目开始过程中。 都是很急的需求，不得不重新估算时间和排期。开发为了避免延期风险，就是让产品排优先级，然后我们根据优先级估时。 直到有必要的需求都在这个迭代中计划上。 没人全局把控，产品从产品角度，开发从开发角度，业务从业务角度。始终没有一个最终的协调人。 产品在对各种O的对话中，气场和身份不足，导致需求基本是提出就会安排。即便是请出青岛总负责人出面沟通，最终的结果一般就是接受。 之前我们是青岛为开发，北京为产品、UI、前端、测试。异地沟通。电话会议是常有的事情，私下的临时沟通电话更是家常便饭。 信息同步、开会、理解程度 都会造成沟通上的成本增加。 紧急需求上线后，三个月没人反馈。问了才知道，财务提的需求他们没用过。 开会一般都会临时决定，发起人会准备资料

一、工具集合 ①　　Microsoft Office 　 　–　　Excel (数据统计，数据分析，数据报表，数据图例制作，进度控制，神器) 　　　 　 •　　Excel 文档结构（版式设计，逻辑结构表现，色彩） 　　　　•　　简单的函数计算 　　　　•　　数据组织 　　　　•　　图标制作（饼状图、柱状图、条形图、折线图） 　　–　　PowerPoint(演示利器) 　　–　　Word（文档） ②　　Microsoft Visio 　 　–　　流程图利器 　　–　　信息结构例图 　　（例图，学完补充） ③　　Axure 　 　–　　简易流程图 　　–　　原型利器 　　 　注意 　　 　　•　　Axure虽好，谨记它只是工具，不要被他所左右 　　　　•　　不要陷入到超级写实中去 　　　（例图，学完补充） ④　　Balsamiq Mockups 　 　–　　原型图草图利器 　　 　　•　　可以快递构建你想要的东西 　　　　•　　很好的支持移动性能 　　　　•　　元素丰富 　　　　•　　不容易干扰UI设计 　　　　（例图，学完补充） ⑤　　Mindmanager 　　–　　思维导图 　　–　　收集，归纳，整理想法与思路 　　（暂时未找到破解版，尝试用Xmind代替） 　　（例图，学完补充） ⑥　　二笔铅笔（包括各种笔） 　　•　　高速 　　•　　简介 　　•　　灵敏 　　•　

某公司的产品面试，面试前该公司让面试者做一道笔试题，笔试题目为： 针对以下需求提供一个解决方案：在卡牛 -信用卡管家APP里面，我们的用户需要一个寻找 附近银行网点/ATM 的功能： 请交付你针对这个需求，设计的 Axure 原型界面的解决方案 在原型里面标明业务规则和你对这个需求的分析思考过程（脑图、流程图等等） 通过本道题目，将讲述为某产品添加一个功能需求，从策划到上线将会走那些流程。 在一家小型的创业公司，从项目的需求 ——项目的落实——项目的上线，他们大致会走这样的流程： 产品策划 – UI设计 – 研发评审 – 测试评审 – 研发阶段 – 测试阶段 – 上线 。结合那个面试题，详细的讲述产品策划这块，简要的描述一下后续几个流程。 根据以上笔试题，我们可以得知：卡牛 -信用卡管家 APP 的用户反馈得知，用户希望在卡牛 APP 有一个可以寻找 附近银行网点／ATM的功能。 # 产品策划 在产品策划中，首先是获取产品需求、然后对产品需求进行筛选、评估。获取产品需求主要来源可以分为 内部渠道和外部渠道。外部渠道的来源于 “用户反馈、用户调研、竞品分析、市场、合作伙伴”；内部渠道的来源于“公司战略、产品经理本身、产品数据分析、其他部门的反馈” 。 当获取到产品需求时，接下就会进行需求评估， 需求评估将会利用以下方法：客户满意度、马斯洛需求、重要紧急四项型、调研强制排序

如何成为一个优秀开发组长 岗位职责： 开发组长的工作范围到底是什么？ 个人能力：个人足够强大，才能让组员信服 需求管理：清晰的产品方向，才能让团队顺利前进 技术上：架构设计，核心代码编写 团队管理：目标管理、人员培养、团队绩效，产品、研发、测试协调 需求管理： 1.需求规划：一定要制定需求规划，决定大的发展方向的，需求规划一定的推到出来的。 2.需求识别：什么是伪需求，什么是真需求。 3.需求改变：开发阶段，站在技术角度改变需求，让需求更加完善。 4.需求减少：定期下线不必要的需求，减少维护成本。 需求是提升团队效率的第一因素，做太多非核心的需求反而成为团队负担 如何站在技术角度管控需求 定期找业务线及大产品经理要产品规划及市场计划，针对产品规划中每个模块的价值要清楚理解，有疑问及时组织会议进行讨论，产品规划清楚后，制定对应的技术规划和人员安排 如果一个团队经常攻关，说明此团队产品规划做的非常差 怎么帮助产品经理梳理需求 产品经理角度，功能开发越多越好。怎么能够让他清晰的认识到投入产出比，研发设计、开发，对老功能影响，测试成本，后续的维护成本 团队管理： 怎么成为一个伟大的团队。 一个强大的团队，需要每个人都强，有一个环境脱节了，团队强大不起来。 人员管理：人员培养，清楚知道每个人的背景及追求（最好家庭情况都要了解），合理的分配工作及组员职业规划。 团队会议：团队晨会，团队周例会

　 　转载自 LANCEYAN.COM 　　说起敏捷开发，并不是因为敏捷而敏捷。这几年的敏捷开发已经被很多敏捷咨询服务商神话了，这个东西并不是神器，实施了就可以解决所有软件公司的问题，而是要结合自己公司的特点和问题摸索出适合自己的一套模式。 　　大家都知道，创业公司刚开始需要研发出一款产品并且能够使公司赚钱的产品，不过大部分创业公司没有那么容易一下就能做出来，很多公司还没有成功的产品资金链就断掉了，公司也死掉了。我们公司是这样一个状况，有一条产品线可以维持公司开支并仅仅刚够盈余，要扩大高速发展还不够，一直维持就没有创业的意义。另一条线是做技术创新为未来能够开发一款人气爆棚的产品摸索着，但是又不能饿着肚子去开发。我们是如何结合自身的特点实施敏捷开发的呢？一个难题，很大的难题！ 　　我们技术团队人员是这样的配置：1名技术总监、2名资深开发工程师、1名高级开发工程师、2名潜力开发工程师、1名前端开发、1名测试。技术总监需要处理很多团队管理、客户管理的工作，能够参与项目的时间最多每天二分之一。2名资深开发需要负责给其他工程师做导师，参与新项目开发时间大概有80%。高级工程师要预留项目学习时间，参与项目的时间大概有90%。潜力开发工程师需要有一些时间学习技术和项目，但是基本可以做到70%的时间投入项目。前端开发和测试哪里有需要就在哪里革命，属于机动部队。 　　现在总共有六个老项目在维护

一、了解市场需求 　 　— 与潜在用户交流尝试能否获取需求 　　— 明确存在于该机会中的目标用户群体与特征 　　— 与直接面对客户的一线同事交流，如销售，技术，运营，市场等 　　— 获取，分析，评估用户的需求 　　　　 • 需求的收集 　　　　• 需求的分析评估 　　　　　 　— 是否迫切 　　　　　　— 是否强烈 　　　　　　— 是否高频 1.1、分析竞争状况 　　 — 市场报告 　　— 行业文章 　　— 使用竞争对手的产品 1.2、自身资源与满足用户需求的匹配程度 　　 — 技术资源（是否有技术储备，案例：微信与米聊） 　　 　　 • 是否存在技术资源 　　　　• 是否需要技术预研 　　— 市场资源（媒体资源，推广渠道，公关资源） 　　— 运营资源 （现在团队能否支撑可能发生的用户需求和与之相对应的其它需求） 1.3、该阶段目标 　　 — 发现创新产品的机会 　　— 返现改进现有产品的机会 1.4、该阶段输出文档，根据汇报对象与实际情况 　 　— 商业需求文档 BRD（Busuiness Requirment Document） 　　　　 • BRD 你要给产品，运营，管理层等很多人看，要讲清楚为什么有这个需求，需求的边界和业务目标，所需资源等等； 　　 — 市场需求文档MRD （Market Requirement Document） 　　　　• MRD给产品、运营

可乐小组项目第二次讨论——用户体验设计 时间：2019年11月12日 　　地点：应用楼教室 　　照片： 主题：用户体验设计 　　项目进度：初步开发阶段，确立项目需求 　　完成功能点：初步页面 物流配送平台搭建用户体验设计的目标 用户界面对大多数计算机使用者而言，是人和计算机进行沟通的载体。我们常说的一个软件对用户是否友好、是否体贴用户指的就是用户界面这个问题。人性化的设计是计算机软件工程的重要指标，因为软件最终是要服务于用户，用户是我们设计的中心。 优秀的用户界面设计是使产品赢得用户、赢得市场的基础，但如何判断用户界面设计的优劣呢,怎样的用户界面设计才能提高产品的市场竞争力呢,这里我们需要引入一个概念，即“使用性”的概念。使用性是一种以用户为中心，关于用户和系统间相互作用的特殊性质，它描述的是“某产品在特定的使用环境中为特定的目标用户所使用，从而快速、有效、满意的完成特定任务的程度”。因此，用户界面的使用性决定着人机交互的效率和效果。一个具备较好使用性的用户界面能够让用户全神贯注于其正在进行的工作，而不是去注意他在使用什么操作界面和系统工具。 衡量软件用户体验设计的标准 随着计算机硬件、软件和网络产品的发展和更新换代，产品的使用性得到了越来越多的重视，甚至还逐渐延伸到了工业产品和生活用品的设计和生产领域。 性能的好坏已不能用“对用户是否友好”这个单一的、程式化的概念来概括

Scrum是一种用于开发创新产品和服务的敏捷开发方式，我们首先来看一下敏捷开发过程和特点，并着重介绍Scrum框架的角色、活动和工件等内容，然后介绍团队利用TAPD中的需求管理、缺陷管理、迭代管理等应用功能来帮助团队有效实践Scrum敏捷开发。 何为敏捷开发？ 敏捷开发所倡导的是通过若干个短期的迭代周期（也称为冲刺sprint，范围一般是1周- 1个月），按一定的优先级不断增量开发和实现产品功能，每次迭代获得一个可运行的产品增量功能包。 敏捷开发首先需要建立一个按优先级排列的产品列表，其中由产品需求、功能优化或功能缺陷等类型清单项组成，排在前面的是优先级高的项，优先纳入迭代计划进行实现，这些项在纳入迭代计划前进行分解和细化，达到满足开发团队实现的粒度。 越往后排的项优先级越低，这部分需求暂时不会提上开发实现日程，当前阶段可以粗略描述，也不必急于细化，以应对可能的变更。 每次迭代开始阶段，从产品列表中选取一定数量的清单项作为本次迭代需要完成的目标任务，通常是由各方利益相关者讨论决定的，数量的多少视开发团队的情况而定，尽量匹配开发团队的开发节奏。 迭代过程中开发团队每天通过站立会的形式沟通工作进展和面临的问题，在这期间一般不再接受新的产品项或其他开发任务，特殊情况可以接受任务的置换。 在每次迭代结束时，团队一起评审已实现的产品功能等工作项，并根据反馈优化当前的工作和开发方式。在这过程中

首先说一下我还是喜欢做测试，目前发现自己的需求分析做的不是很好。 产品小白学习录： 1、在每次得到一个需求分析的说明时，知道它想要知道做什么东西的同时还要去构思它的整体架构（最好用思维导图画出来，比如需求页面里面需要显示的要素）这样和项目经理沟通的时候那你就知道你你哪块不懂或者哪一块的逻辑错误了。 2、一定一定在开始原型设计的时候把你的页面构思好，做成脑图可以先给项目负责人（如果她是开始做需求调研的那个人的话）看看你的流程和页面要素有没有问题。不然在后面你是一边做一边想那就很有可能是你做了一点发现流程偏了或者是还有哪一个要点漏了没有考虑进去，造成你要重新做or改很多版。一次性敲下你就少纠结很多东西，只剩页面布局问题。 3、做产品的一定要做好沟通，主要是和最能知道用户实际需求的人。（这个本来是产品要做的事，但目前我是个新人还不是很了解当前系统的用户的使用需求很多东西只能靠自己的想象这样不是很实际设计的东西不会贴合用户的实际使用情况。）这个对我来说是最痛苦的，我个性在不是很有安全感的环境下去放开自己去和其他人沟通，前期的时候老是被leader说你别老是默默做要多问一下，不然做出来的东西不对后面还要改这样很浪费时间和影响进度。所以沟通真的很重要，当然把握好那个问的度也很重要，怎么样问的让人觉得你有去理解需求深度、不会被认为过度的确认而导致其他人觉得你很烦这个也是要好好学习的