产品需求

1.为什么决定从工程师转向产品经理? 我觉得产品相对于技术更加宏观一点，视野更加开阔一点，比如说我之前做技术的时候只是想着怎么把功能实现了，可是我并不清除这个功能是为了解决哪些需求产生的，这个需求的背景又是什么，当时我们公司也比较小嘛，流程也不正规，没有需求评审、需求移交之类的会议，prd写的也不清楚，很多事情都是口口相传的，这种感觉不是很好，并且我感觉我的性格要比开发更活跃一点，然后就转了产品。 2.拥有技术背景的最大优势是什么?最大的劣势又是什么? 优势是和技术沟通起来会更加方便一点，并且因为懂技术，所以在验收的时候我有时候也会考虑性能的问题，比如这个页面卡顿，我首先会通过抓包看是后台接口有问题还是前端绘制的时候有问题，产品上线之后的前几天我会每天登录bug搜集平台，看各个端的稳定性，会不会有一些线上没测出来的bug遗留，如果有问题给具体有问题的端的技术负责人沟通协调解决，根据bug搜集平台还可以做一些预测，比如说最近要发布iOS13.0，因为很多人安装的有测试版，我们就可以通过bug搜集平台看看最近新出了哪些bug，是否和13.0相关，防止13.0发布以后才发现bug。 当然这也是缺点，劣势很多事情会站在技术的角度考虑问题。以至于很多可能比较耗时耗力的需求，就不太愿意开发 3.在工程师向产品经理转型的过程中最大的收获是什么? 有什么是你希望你在工程师的时候就知道的事情?

1.今天完成：MockingBot企业版中创建项目，将小组成员加入同一项目中；开始参照墨刀中的产品需求模板写需求分析；用ProcessOn完成思维导图，对产品需求有进一步的认识。 2.明日计划：需求分析文档完善，写完功能介绍和产品逻辑，开始原型设计。有时间的话看看关于微信小程序开发的文档和网课。 来源： https://www.cnblogs.com/Jane165/p/11385428.html

入坑前端到今天也将近两年半了,这两天突然想到了第一次面试时面试官的一个问题-------你怎样理解前端的工作? 对于当时我一个小白而言完全是胡说一通,词不达意,搞得面试官一脸懵逼,现在想想那可能就叫尬聊吧……时隔两年在不断爬坑中对这个问题有了自己新的认识,今天趁着上午没什么事情,写下这篇博客,想到哪写到哪,谈一谈我所理解的前端。 技术方面: 第一阶段(新手村) 一个前端初学者必须所掌握的核心技能HTML,CSS,JavaScript,这三项是前端最底层的技术支持了,如果你看几年前的回答应该还会有一项jquery,但我个人觉得现阶段的前端圈jquery可以不作为必备技能,虽然Jquery对新人很友好,但现在mvvm框架满天飞Vue, Angular,React三分天下,用起来要比直接操作dom的jquery舒服很多,当然在这个阶段是打基础的阶段框架,类库什么的可以往后靠。原生Js永远都是重中之重,只会用框架不懂底层原理永远达不到精通,推荐红宝书Javascript高级程序设计,吃透红宝书打牢基础再去学习其他框架,妈妈就再也不用担心你的学习。接下来还有一项额外的技能PhotoShop,要知道ps可以不用去做,但必须要会,而且在一些小公司里UI只会丢给你一个PSD,没有什么Sketch之类的东西,也没人帮你切图,这些都需要你自己来处理,所以ps是额外的必备技能。 第二阶段(副本开启)

以前有看过敏捷开发相关的内容，被说不懂敏捷开发被人带着做敏捷开发，到后来我自己结合瀑布流与敏捷开发建立出一套比较能提高项目效率的“伪敏捷”模式。 一、敏捷开发是什么 敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。——来源百度百科 其实从上面的描述里面，敏捷开发的核心理念是“以用户需求进化”、“迭代、循序渐进”、“持续可用”，相比起瀑布式开发，敏捷开发更加强调团队合作、快速响应、持续产出。两种模式各有优缺，其实现在很少纯粹的敏捷，也很少纯粹的瀑布式开发，更多是将两者结合。 二、我的“伪敏捷开发” 纯粹的敏捷开发，是基于用户需求，然后团队分析团队建模，快速开发，快速上线。但是这种做法非常考验团队及对工作的把控，因为大部分公司一个产品都不是纯粹的产品，除了负责某个产品线外，还需要很大量的其他工作，而且团队素质能力也未必很高。所以纯粹的敏捷开发比较少见到。 大部分的公司团队都是用瀑布式，我做了一堆需求，然后批量一个团队开发，批量上线，每次上线都是生死大关一样，通宵是常态化的情况。我一开始也是这种做法，但是后来发现太累了，将需求拆解得更细

•　　深刻理解三大文档的写作目的与应用场景 •　　理解并掌握PRD文档的用途与作用 •　　理解并掌握PRD文档： 　 　 –　写作思路 　　–　写作方法 　　–　写作格式 ♦　　产品需求文档（Product Requirement Document,　PRD）的英文简称 　 　–　　PRD文档向上是对MRD内容的继承与发展，向下则是要把MRD文档里面的各种理论要求 　　　　技术化，向研发部门与设计部门说明产品的功能和性能要求。 　　–　　PRD文档是产品文档中最底层最细致的文档，所以写作的时候，需要细致耐心。 --------------------------------------------------------------- 再看下这三个文档的区别 •　　BRD-这么做有什么好处，并说明好处在哪里 　 　–　　举例：唐僧出发前，参见唐黄，告诉唐黄西去取经的重要意义与大兴佛法的好处，唐黄答应，并发放免签 　　　　护照，于是唐僧带着任务出发了。 •　　MRD- 通过BRD明确了这个事情值得一做后，描述应该怎么做，并说明这么做的原因 　 　–　　举例：唐僧上路了，但是他需要选择走哪条路线，带几个人，为什么这么走，为什么带这些人，要说清楚 　　 　　 •　　A路线：妖怪多 　　　　•　　B路线：神仙多 　　　　•　　C路线：美女多 　　　　•　　经过分析，唐三藏决定C路线 •　

概述 本场景描述的是针对10以下小型产品研发团队或小型项目的敏捷应用场景。Leangoo单团队敏捷开发项目模板是基于Scrum模型定义的，所以这里所说的单团队是指只有一个Scrum团队的场景。 Scrum是用于开发和维护复杂产品的一个框架。上世纪90年代，Scrum在全球已得到广泛应用,Scrum最初用于产品研发，目前已广泛用于软硬件开发、互联网、人工智能、学校、政府、市场、管理组织运营等诸多领域。随着技术、市场和环境的复杂度和不确定性持续增长，Scrum在处理复杂性方面的效用日益得到证实。下图是Scrum的框架和流程： ​ 在Leangoo中建立敏捷项目 对小型团队来说，在 Leangoo 中建立一个敏捷项目就可以很好的支持团队的产品或项目研发。如果下图所示： ​ 项目示例： ​ Leangoo的敏捷项目模板会默认创建“产品Backlog”看板，缺陷看板和第一个迭代的迭代看板（在Scrum中，迭代叫做Sprint），您可以根据需要创建后续迭代的看板。您也可以根据产品和项目的特征，判断是否需要通过使用Leangoo脑图工具创建产品路线图规划。 产品路线图规划和需求管理 产品路线图是重要的产品管理工具。产品路线图是一个高层次的战略计划，它描述了产品在未来一段时间可能会如何发展和壮大。产品路线图确保整个产品团队持续关注产品的目标，帮助产品负责人把握产品的战略方向

实习报告基本要求   1实习基本情况。 应该有实习单位基本情况介绍，个人实习情况的概述和叙述。包括实习目的、意义、时间、地点、实习任务、实习岗位，在实习中从事了哪些具体工作等内容的叙述。 2实习体会与经验。 包括成绩与收获、缺点与教训。总结的目的就是要肯定成绩，找出缺点。成绩有哪些，有多大，表现在哪些方面，是怎样取得的 缺点有多少，表现在哪些方面，是什么性质的，怎样产生的，都应讲清楚。为便于今后的工作，须对以往工作的经验和教训进行分析、研究、概括、集中，并上升到理论的高度来认识。 3实习总结。 下一步目标与整改措施。根据今后的工作任务和要求，吸取前一时期工作的经验和教训，明确努力方向，提出改进措施等。 正文 根据学校对本科生的毕业实习要求，我在广东知得失网络科技有限公司（曾用名：广州朝舜网络科技有限公司）担任产品助理进行关于产品的毕业实习。 实习目的      毕业实习的目的是： 于学校而言， 让我们接触实际，了解社会，增强劳动观点和社会主义事业心、责任感;学习业务知识和管理知识，巩固所学理论，获取本专业的实际知识，培养初步的实际工作能力和专业技能。 对我而言，我毕业之后想从事与产品相关的工作（产品经理），但我对产品的认知只停留在书本上，没有实践过，所以想通过这么一份“产品助理”的实习，让我能够从理论层面转变为时间层面。为就业打下一点基础。 实习内容 主要是协助产品经理细化部分需求