产品经理

Android 还可以走多久？ 最近，有人问我这么一个问题： 「萧哥，我做 Android 开发两年多时间了，但是最近总是很焦虑，看着人工智能越来越火，很担心 Android 要不行了，想问下，我现在要转行么？Android 还可以走多久？」 这个问题我觉得还蛮有代表性的，今天就姑且给大家谈谈这个话题。 毫无疑问，人工智能是下个十年要进入的时代，而且现在已经有蓄势待发的意思，但是人工智能跟 Android 开发完全不冲突，人工智能它是一门技术与科学，它可以应用于各行各业，方方面面，同样，它也可以应用于手机端，这两年也有不少手机厂商推出了 AI 芯片，以后人工智能在手机上的应用会有很大潜力。 那有人可能会担心， 未来 Android 会不会如当初的塞班一样很快就被取代呢？ 这个担心是多余的，正是由于有了诺基亚的前车之鉴，现在各大互联网公司危机意识都很强，想再出现一例诺基亚这样的事情是很难了，再说了，Android 和 iPhone 的背后要知道那可是 Google 和 Apple 啊，这两家富可敌国的科技公司，想要被颠覆那基本就是做梦，现在想要出现第三个操作系统那得经过 Google 和 Apple 的允许才行，所以，未来五到十年，甚至更长，手机将永远会是 Android 和 iPhone 的天下，而随着科技的发展，未来取代手机的绝对不是另外一种手机，而可能会是新的载体，如眼镜

参考资料 产品经理90天实战班 结束语 把自己当成一个产品去经营。 来源： https://www.cnblogs.com/zenronphy/p/12147881.html

参考资料 产品经理90天实战班 结束语 把自己当成一个产品去经营。 来源： https://www.cnblogs.com/zenronphy/p/12147881.html

前言：文章来自Worktile产品经理的产品需求管理经验分享。 作为B端产品经理，我接触过很多研发及产品团队，每个团队对产品需求的管理方法不尽相同，各有千秋。下面我来分享一下我司的产品团队是如何管理产品需求的，其实也就是一个产品需求在Worktile中的流转过程，希望我们的经验可以对各位有所帮助，也欢迎各路大神交流指点。 下面我通过需求流转的不同阶段来介绍我们如何做需求管理： 需求收集 管理需求的第一步首先是要进行需求的收集。我们的需求来源除了产品经理自己通过市场调研等各种渠道分析出的需求，来自用户的需求、建议、缺陷，都是由销售、客户成功的同事在一个公开的项目 （公共Backlog） 中提交，然后产品经理和设计师会定期对需求池的需求进行评审处理； 以下是在需求收集阶段我们会设置的一些关键属性： 1.需求描述 对于2B的产品需求，信息无非是角色、场景、原因、目的、预期这几点。但由于不同企业的角色、场景等信息复杂多样，所以无法形成统一的标准化数据来源，因此，我们规定以任务标题来描述需求最终的预期，其他必要信息通过任务描述来进一步补充； 2.功能分类 因为Worktile有“项目”、“消息”、“简报”、“网盘”等不同的应用，不同的应用是由不同的产品经理负责的，所以让需求提交人选择【功能模块】的原因是为了方便产品经理根据自己负责的应用筛选需求； 3.需求类型 新功能、交互优化、视觉优化

现在软件和互联网大概有哪些方向？ 1、首先是需求从哪里来? 1.1 客户的项目 如果做的是客户的项目，需求当然是从客户那里来的，当然客户绝对是软件开发的小白（其实也不能这么绝对啦，我也见过极少客户中很优秀的软件人才），他们很难清楚地描述自己真正的业务要求，这时候就需要有个人隆重出场了：业务分析师。对于大公司，业务分析师是专职的，对于小公司，项目经理或者开发骨干也就硬着头皮上了。业务分析师需要把需求理理清楚，交给后面的架构人员做设计。 业务分析师如果在某个行业干久了，就会变成业务专家，例如你把国内各大银行的核心系统项目都做了个遍，那你对银行业务的熟悉程度甚至可能超过银行的特定人员，这时候你就超级值钱了，不仅仅能分析业务，更能够帮助银行优化业务，你说牛不牛？ 问：业务分析师需要懂技术吗？ 答：最好是懂一点，你分析出来的东西是要码农们实现的，如果不考虑现有的技术，一味地迎合用户，肯定会被码农们骂死。 如果你是由程序员成长起来的业务专家，技术精湛，那就坐着数钱玩吧。 1.2 公司的产品 如果你做的是产品，例如微信、QQ、淘宝、魔兽世界、征途、大话西游，那需求其实是自己公司的人来定义的。 定义这个需求的现在有个时髦的职业：产品经理。像张小龙就是微信的超级产品经理，史玉柱就是征途的骨灰级产品经理。 产品经理主要根据用户的心理和体验来设计产品，让大家用的爽，好的产品经理现在非常吃香

产品关键词与分类 用心听用户，但不照做 不但要听用户怎么说，还要看用户怎么做 人人都爱提主意 用户是产品的一部分；如果你是游戏的免费用户，那你其实是游戏提供给付费玩家的一个功能 产品架构、产品设计、产品管理、产品运营 想清楚自己肯定不要做什么，就可以逐步找到自己的定位 这是一个供给充足、市场细分、用户选择很多的时代，情愿选择让一部分人爱你爱得发疯，另一部分人恨你恨得要死，也不要让所有人都觉得你还OK，你是个好人，然后就没有然后了。这就是产品的调性、品牌的人格化。 核心用户定义得越精准，产品设计、推广等过程中的目标将越明确。 概念提出与筛选 可怜的是，很多产品根本没有任何“唤起点”，用户怎么想到用你？这也意味着你还没找到自己的典型场景。所以，只要是一个“点”，就不要怕小，怕的是没有独特性，怕的是不够典型。 先找定一个对手，打透以后再考虑视野和格局，再扩展 竞品选择 相似产品，同样的产品功能解决同样的用户需求 满足同样需求的不同产品功能，替代品，调研的不仅是功能，而是用户的深层需求；同样的功能解决不同的用户需求，不同需求场景下，不同的潜在竞品；解决方案经常变，但问题不变，元问题 所有消耗用户时间的产品 问题和解决方案，不一定先有哪个，最重要的是要找到它们的匹配。这才是产品经理价值的本质。 划分用户的目的是为了需求场景的差异化 种子用户 配合意愿高 久病成医，有自己的想法，用户顾问

本文简述产品经理的工作方法及应用之商业需求分析。 一、需求采集 1、需求来源渠道 ①公司内部（老板、其他部门或同事） ②产品经理自己（策划、挖掘） ③公司外部（用户、客户、伙伴） 2、需求获取方式 ①业务发展的要求 ②用户调查结论 ③用户反馈分析 ④产品数据分析 ⑤竞品分析 3、需求管理表（要素） ①来源渠道 ②需求描述 ③需求性质：优化、新增、bugfix、idea ④需求评述 ⑤备注：提出人、提出时间 ⑥后续计划：排期、留存、暂缓、合并、搁置 4、产品需求池 汇总管理（部门级别） 二、需求分析（价值、成本） 1、需求分类 ①功能类（加法、减法） ②数据类 ③运营类 ④体验类 ⑤设计类 2、四象限定位法 ①重要并急需 ②重要不急需 ③不重要但急需 ④不重要也不急需 三、需求筛选（团队评审、汇报） 1、需求决策 战略定位 产品定位 用户需求 2、战略方向 起步阶段--关注产品最核心的功能 发展阶段--优化、扩展、完善 迭代阶段--设计、体验、运营 3、产品定位 战略方向更偏向于市场 产品定位更注重功能定义 4、用户需求 不把需要当成需求 不把产品形态当成本质 四、需求处理 需求处理、转向开发 五、文档（产品管理分析文档） 分类 分析（四象限） 分级（包括优先级、时间、人员） 原因（搁置、是否启动、何时启动） 周期（更新） 来源： https://www.cnblogs.com

产品经理经常需要与RD进行需求沟通，有个很有名的幽默漫画是这样画的。 产品的需求，经由产品经理定义成产品规格后，开始找RD讨论。而一切的错，也就从客户（或Product Manager）口中的需求开始。 PM：「我们要发展一种在无重力状态下也可以使用的多功能原子笔，也就是说墨水不会因处在无重力下就无法送达笔尖。」 RD：「这个想法做不到。因为OOXX，所以XXOO」 PM：「可是之前看日本技术展的时候，他们有展示不受重力影响的液体封装技术。你们要不要研究研究，这么快就说做不到，会不会太草率？」 RD心理在干：「你到底有没有听懂我讲话啊？就不可行啊！讲不听。就说产品经理每次都在外面看到什么新玩意，就自己High了起来。明明是外行又要装内行，专门想出一些怪东西来整我们！」 PM又说：「客户说他们对这种产品有很大的需求，这个订单对我们公司很重要。」PM开始拿客户需求这个神主牌来压。 PM心里也干：「这些RD超没干劲，每次开需求给他们，他们东闪西躲，就是不想做事情，老是说做不到，明明就有人做的到。RD都欺负PM在开发知识上不如RD。可恶！」 上面的需求沟通，到底出了什么问题？ 曾经有人教过Mr PM，跟RD沟通，要「态度柔软，但立场坚定」，或是「要怀疑RD说的每一个做不到，要常常找出别人做得到的证据，逼RD就范」 。 PM和RD的关系，就在这些经验传承之下，越来越紧张，不是你压倒我

我们下面需要完成这样一个应用场景： 1.早上；2.测试人员、产品经理、开发人员陆续的来公司上班；3.产品经理规划新需求；4.开发人员开发新需求功能；5.测试人员测试新功能。 规划需求，开发需求新功能，测试新功能是一个有顺序的，我们把thread1看做产品经理，thread2看做开发人员，thread3看做测试人员。 1.使用线程的join方法 join(): 是Theard的方法，作用是调用线程需等待该join()线程执行完成后，才能继续用下运行。 应用场景： 当一个线程必须等待另一个线程执行完毕才能执行时可以使用join方法。 package com.wwj.javabase.thread.order; /** * @author wwj * 通过子程序join使线程按顺序执行 */ public class ThreadJoinDemo { public static void main(String[] args) { final Thread thread1 = new Thread(new Runnable() { @Override public void run() { System.out.println("产品经理规划新需求"); } }); final Thread thread2 = new Thread(new Runnable() { @Override

app开发软件开发专业团队 每次产品的开发，我们总是说要按流程，按流程，需求要明确，要明确等等等…可是因为各种条件的限制，或者客户爸爸的要求，又或者我苛刻的要求。我们总是会乱流程。借此机会（在平时请教技术大牛以及自己看资料的情况下），好好的梳理一下软件开发正常的流程，也促使团队走向正规化。 一般软件开发分为8个阶段，具体如下，请从右往左看。 如果看得不是很明白，下面做具体解释： 1、明确需求阶段 这个事情呢，是产品经理做的事，一般要求和开发人员一起开个需求讨论会，主要讨论需求的合理性以及存在的必要性，后台开发人员可以提出自己的建议，然后产品结合客户爸爸以及开发的建议决定需求是否需要开发。 2、产品原型阶段 这个事情呢，还是产品经理的事，产品经理根据需求文档着手设计产品原型。原型设计好后，给客户爸爸和老板过目后觉得没问题。然后交给开发人员。双方讨论功能的合理性以及存在的必要性。然后，产品经理就得确定需求文档（PRD）了。 3、UI设计阶段 这个阶段是UI设计师根据产品经理给出的原型图以及PRD设计出一套符合要求并且好看的UI界面出来。 4、前端设计页面阶段 当UI设计师设计好页面后，前端工程师就可以根据UI设计的原图。然后用前端代码将设计图展示出来，包括各种特效效果，色值，以及布局的合理性。 5、后台开发阶段 首先，程序猿们知道明确的需求后，得凭着自己毕生所学设计出合理的数据库，建表