产品经理

本文笔记全部来自极客时间《硅谷产品实战36讲》 05 | 硅谷产品经理每天在做什么？ 1、导读 （1）本章主要讲述，作者作为产品经理的一天是什么样子的。 （2）以发布新版视频版权管理系统为例，讲述作者一天的工作规划。 （3）和用户讨论，和市场营销经理做市场调研，和数据科学家分析用户特点，目的是为了制定一个详细、具体的产品功能列表，并设定需求的优先级。 2、产品经理开发初期一天的日程 （1）10:00 用户调研确认痛点 （2）12:00 头脑风暴寻找解决方法 （3）13:00 午饭 （4）13:30 跨组的产品经理交流，复用资源 （4）14:30 讨论确定成功指标 （6）15:00 思考产品：整合用户调研和头脑风暴的内容，写需求文档。 （7）17:00 和营销经理讨论市场调研情况。 （8）18:00 晚饭 （9）19:00 下班时间，回复邮件和工作信息 3、产品经理开发末期一天的日程 （1）10:00 早晨的站立会议，协助解决问题。 （2）10:30 和设计师修改方案以解决架构限制问题。 （3）11:00 和设计师、工程师确定具体要实施的解决方案 （4）11:30 向老板汇报近期的进展（告知风险点、需求资源支持） （5）12:00和新同事吃饭，描绘产品蓝图，吸引其加入 （6）13:30 部门产品经理组会：了解上层近期思想和决定，和其他部门交流，寻找合作点。 （7）14:00 自由时间

本文笔记全部来自极客时间《硅谷产品实战36讲》 04 | 产品经理和项目经理有什么区别？ 1、导读 （1）产品经理：Product Manager；项目经理：Project Manager。 2、产品经理和项目经理的区别？ 产品经理 （1）定义：产品经理的工作性质是能够带领一个产品团队做出决定，开发出用户想要的产品。 （2）产品经理需要制定路线图，为团队指引方向，明确所做事情的先后顺序。 （3）产品经理一般会固定在一个产品上，致力于产品的发展、体验和用户量的提升。 项目经理 （1）定义：项目经理的工作性质是能够组织团队在有限的时间内按期完成一个非常复杂的项目。 （2）项目经理把一个很大的项目拆解成以一个小的task，分配给不同的工程师，其成功标准在于能否按期完成项目。 （3）项目经理会经常使用JIRA这样的工作流管理软件。 3、产品经理和项目经理如何合作？ （1）产品经理确定产品的痛点、目标群体、成功指标。和用户调查部门合作提出需求，和市场部门合作评估市场前景。 （2）写需求文档，和工程师讨论需求是否能做，将需求交给项目经理，项目经理负责拆解、分配任务。 （3）存在多个项目合作时，项目经理要负责组织每周沟通会议，包括：邀请相关负责人、制定会议进程、会议模式，并负责会中达成共识的落实。 （4）项目完成，产品经理和市场营销部门制定产品发布的计划和策略。 （5）产品发布

在广义上是指任何能够让计算机通过图灵测试的方法和系统，而狭义上则是指通过研究人类智能产生的方式来让电脑模拟人的智能。 对于AI产品经理做实际操作产品来说就是通过：大数据+先进算法+算力来完成的。 一、数据阶段 数据阶段：AI产品经理包含传统产品经理。 经过数款实战产品总结，AI产品经理与传统产品经理的关系是包含关系――即AI产品经理包含传统产品经理。 笔者想了一下，我们产品同学为啥总讲跟传统产品经理的区别？应该是AI产品经理核心能力应该会什么？AI产品经理的思维模式是什么？ 就像AI产品经理也是要懂传统产品经理会的内容，产品经理本身会的东西就比较多，不同的工作思考模式也有差异，所以本篇先讲AI时代的AI产品经理应该有的能力模型部分。 AI产品经理与传统产品经理是一种包含和递进关系（AI产品经理包含传统产品经理），不是并列对比。 1. AI产品经理的核心能力 1.1 AI能力模型 能力模型是AI产品经理自我评估强项弱项的关键环节，只有知道自己的不足，才知道需要加强的地方。 通过对AI产品经理能力模型列表的直观查验，会发现AI产品经理能力模型是覆盖传统产品经理能力模型的。 能力模型： 从传统产品经理市场来看，产品经理岗位已经出现大量细分，如前端产品经理、后台产品经理、数据产品经理、支付产品经理、ERP产品经理、CRM产品经理、供应链产品经理，POP产品经理等

19年第一季度，已脱手PMO工作，转到项目中。但作为项目组合的全局掌控者，仍会受PMO的控制。因此根据被动了解情况，记录PMO19年下半年及20年初的运作。 19年强调了产品概念，把产品经理制上升到部门管理理念中；其次主推BT&IT项目，开展了共16个项目；主抓流程绩效管理，流程绩效衡量指标及流程owner概念。如果把部门的建设当做一个IT项目，那么组织、流程、数据，都涵盖到了。组织层面，由IT部门上升为流程&IT部门，流程与IT本就不应分家，IT的本质，就是玩信息流，承载业务流；纳入了CRM产品管理部，CRM是老板top1关心系统，由其主抓，因此之前组织架构上隶属总裁办。并且处于项目阶段时，与部门管理无强关联性。但项目上线后，作为公司级信息系统，应纳入IT部门统一管理。特别CRM与其他系统，存在大量对接。资源由一个部门统一协调效率与效果上更优；成立产品部，开发、BA、SA、PM都隶属其中。以产品团队为基本单元，采用产品经理管理制度，开发运维一体化，由产品经理调动开发资源。流程层面，以拉通IPD及LTC两大流程为目标；借由BPM系统迁移，开始梳理全公司流程，并做优化，先定人再定事，流程有owner负责。数据层面，以流程绩效指标驱动。 总结19年部门工作，借由领导视角，3+2+1。三个输出：人才、管理（流程）、业绩；两个转变：以功能为中心转变为以用户体验为中心

从开发到上线差不多用了3个月，其实第一个月就把大部分功能实现了，之后两个月都是需求的再次确认和修改BUG，期间穿插的做别的一些事情。总的来说比较顺利，一马平川没有任何卡住的地方，也没有出现“大脑CPU使用率突然飙升的情况”，但瑕疵太多，在此做一下简单的记录。 简单介绍一下我们的作战方式。页面由专门的人切，只制作出部分页面，类似的自己搞定，之后的样式问题自己搞定，一个产品经理，两个程序员，所有的需求都问产品经理，基本上是除了切页面，其他的都由我们程序自己搞定。做的是一个公司内部的项目管理软件(网站)的改版和升级，对于我来说基本上是新开发一个系统，因为以前的实现方式不太好，我换了一个实现方式，大约重写了91.1%的代码。 对需求的理解不够全面 。了解需求来自两个方面一个是产品经理另一个是现有代码。产品经理先跟我大致的介绍了一下，然后自己看现有的代码，两者结合得到自己的想法，于是开始开发，期间有问题随时问产品经理。刚开始的时候加入太多自己的想法在里面，导致对需求的理解有些偏差，导致后期做了一些不必要的修改，修改就是对原有代码的破坏，本来写得还行的代码，被一点点的修改，因为小的修改我们总是不在意，慢慢的代码就变得不好理解，到后期对部分代码产生陌生的感觉，我怎么会写出这样的代码。尽管开发期间多次确认过需求，但还是有的地方被忽略掉了。用于理解消化需求的时间太少，导致后期一连串的恶化反应

优测云服务平台 是移动云测试平台，拥有50余名测试领域专家，300余人专业测试团队，10余年终端测试服务经验，提供兼容性测试、自动化测试、云真机，设备分享等多种服务方式。 最近的用例评审让我感受颇深，以下是我对于测试用例评审的一些感受，发出来供大家讨论学习。 听听大家对测试用例评审的吐槽？ “测试用例设计是测试的事情，为什么评审要我们参加？” “测试用例已经很多了，不知道需要评审什么，我能提供什么？” “用例评审太枯燥了，200个用例case用一条一条评吗？” “这个是别人的开发的功能，跟我没关系。” 相信以上几句话是评审时常听到的话，那么为什么要进行测试用例评审？ 这里从参与用例评审几个角色来（测试、开发、产品经理、项目经理）分析下进行用例评审的目的以及意义。 测试： 由于不同测试同学对于需求的理解和用例设计都不同，为了提升用例的完整性、合理性、高效性，可以通过评审的方式，收敛不同人以及不同专业的意见，丰富测试用例。测试是无穷尽的，没有人能保证自己的设计用例覆盖完全。 开发： 测试和开发对于需求理解未达成一致，通过评审与开发对需求进行double check，保证在测试前对需求理解的一致性，以免执行测试过程中产生争议和扯皮。 暴漏出开发在实现过程中代码逻辑考虑不充分的地方，提前预警，避免逻辑处理考虑不充分导致的缺陷。 开发可以从实现层面评审用例，补充测试用例中

世界上只有两种物质：高效率和低效率；世界上只有两种人：高效率的人和低效率的人。 —— 萧伯纳 在产品开发过程中，涉及到的人员泛而杂，但最主要的人员还是产品、设计和开发。一个产品的成功与否取决于他们如何有效沟通，如何共同协作来尽可能提高质量和工作效率。高效的工作可以是通过并行工作缩短迭代周期，也可以是通过文档方式进行有效协同。但无论采取哪种方式，我们都面临一个现实而又复杂的问题—团队协作。 那么，如何建立起产品、设计和开发人员之间的高效团队协同呢？一种实现方法是产品和设计去学习使用开发工具，不需要从头到尾开发App，但至少能如实和迅速的交流设计意图，进行有效沟通。或者是开发人员去学习使用设计工具，了解产品和设计相关的专业知识。通过这种方法，其中的复杂性可想而知。 设计图与前端界面是否一致，这是前端工程师与UI设计师的协同工作中最关键的一环。有过经验的产品、设计师和开发人员都知道，设计图与前端界面实现不一致的问题时有发生。所以经常写完的前端页面都需要去修改，周而复始。特别是做移动端Web，频繁的修改页面不仅让参与的人员觉得很烦，也非常非常浪费时间和心力。通过自身经验的总结以及对工作流程的梳理，我发现，大部分工作流程可以分为两种情形。 情形一 （偷懒的）UI设计师：只负责设计UI界面，出PSD，AI与PSD效果图，不出标注图。 前端开发：拿到PSD文件去测量里面间距，去切图，实现前端页面

公司的软件测试流程： 1、采集用户需求（产品经理+软件实施工程师） 2、编写基础版需求文档（产品经理/产品经理助理） 3、需求文档评审（产品经理+开发经理+测试经理+客户） 4、沟通需求方，完成需求文档的修改（产品经理+客户） 5、下发需求文档至开发经理和测试经理 6、开发经理出具开发版需求文档，测试经理出具测试版需求文档 开发部门的运作流程 1、需求文档部门内部评审 2、下发开发任务（开发经理） 3、开发人员进行编码工作 4、开发人员本地环境下代码自测 5、自测完成合并代码至公司源码库 6、源代码打包部署至开发和测试环境 7、知会测试人员进行测试（showcase） 8、根据测试反馈进行bug解决 9、配合运维人员打包上线 测试部门的运作流程 1、需求文档部门内部评审 2、下发测试任务（测试经理） 3、测试人员根据需求模块分配进行测试用例的输出 4、测试用例评审 5、测试人员完成测试用例的修改，等待开发通知测试工作的开始 6、执行测试用例，提交bug 7、跟踪bug进行bug的回归测试 8、打包上线后进行回归测试 视频链接：https://www.bilibili.com/video/av47476628 来源： CSDN 作者： 飞翔的小仙女儿 链接： https://blog.csdn.net/weixin_43784779/article/details/103945225

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 用户需求瞬息万变，而 手机软件UI设计 为适应变化的用户需求，也相应的发生着变化。但是，这并不意味着用户需求和UI设计趋势就是无迹可寻的。事实上，根据前几年的手机app界面设计变化的特点，尤其是2017年的变化特点，我们也是可以对2018年的设计趋势有一个基本的预测。 所以，这里为大家分析和介绍2018手机应用UI设计的9大趋势，希望对大家有所帮助： 1). 重叠空间感的延用 字体，图形以及颜色的重叠，不仅能够能够使界面设计更加独特且吸引眼球，同时也能营造出超越2维的空间感。这也是为什么近几年来，重叠空间概念广为UI设计师们争相使用。 而且，相同元素的重叠，结合阴影，前后次序，以及延长，淡化到消弭等的变化，会使整个设计更具科幻效果和表现力。 因此，重叠空间感的沿用将会是2018年的一大趋势。 2).颜色渐变将继续流行 无论是手机app界面的logo, 背景还是按钮之类部件的设计，即便是单一的颜色选择，结合 色彩的渐变 和多样的图形，也是可以展现出丰富的层次感和画面感。 因此，颜色的渐变不仅会在2017年全年流行，也将于2018年继续流行下去。 3).透明度的广泛应用 透明度的设置结合颜色的变化，能够营造出多彩玻璃的质感。所以，UI设计师们广泛的将其应用到各种手机App的logo设计之中

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