为什么让新人写产品体验报告

在当前公司的控股公司中，每当一个新人入职后，会有一项工作，就是写写产品的体验报告。我认为非常好，所以在现在的公司就沿用了这种方式。在开始的时候执行的不太好，在设定这是转正必要的一项工作后，执行情况好了许多。

我们对显而易见的利益得失很容易看到并行动，但是对很多不那么显而易见的利益得失却总是缺乏思考而非逼不能行。在看我来写产品体验报告对每个人都是有益的，尽管它不会在提交的那一刻立即转化为 RMB，甚至我觉得更应该在寻找工作时就该带一份产品体验报告，江湖中也有用产品体验报告拿到 Offer 的事例。

对新人而言，一份用心思考的产品体验报告有助于我们尽快在企业落地，以便开展工作，为企业创造价值，获取回报。

首先，通过产品体验报告，在基本技能之上，能够进一步展现自己的能力，这东西是跟真金白银相关联的。比如文案能力如何，逻辑思维能力如何，系统性思考能力如何。更具体一些的比如是否具有发现问题的能力，是否能给出问题的路径与解决办法的能力，是否具有归纳总结的能力等等。要充分相信自己，在我看过的一些产品体验报告里，不管是经验丰富的还是刚刚步入职场的同学，均能提出一些对团队很有帮助的见解，这就体现了你的能力和企业对你未来成长的期许。

其次，除了产品之外，我们还需要从团队、企业工作的方式等方面评估一下这份工作是不是适合自己，是不是自己想从事的工作，借助体验产品的过程，自然而然的会跟不同团队的成员交流，而这些有助于给自己提供决策的依据。如果评估的结果是这份工作适合自己，那么能迅速融入团队是急需的。对工作方式的认可和执行，良好的交流与沟通是能够迅速融入团队的一种途径，而围绕产品展开无疑是比较自然的。

体验一圈之后，最终我们还需要回到跟自己从事的工作岗位相关之处，不管在什么部门，需要完成什么工作，都会跟公司经营的产品「服务」有所关联，公司不同组织结构内的团队也都是围绕着公司的产品，向用户输出价值，从而获得利润。从这个角度看，不管在什么岗位上，对产品了解的越多，越有利于开展自己的工作。

对于团队而言，很多时候我们都需要花费资源寻找用户，以获得产品的反馈，每一份新人的产品体验报告正是很好的一次用户反馈。这里面除了包括很多的问题和错误之外，还有一些不同视角的观点，这可以为产品的改进提供良好的探索路径，我们在局内很多时候看熟悉了就很容易固化思维，有时候换一种思维可能面临的难题就容易解决了，要勇于接纳新的看法和观点。另外，团队的每个成员也都有义务帮助新人尽快落地，融入团队以增强团队的战斗力，除了生活中的交流之外，以对产品的交流讨论作为切入点也是极其自然和有效的。

写产品体验报告更像是把产品作为一种连接器，通过这个连接器让大家共同获益。我想在生活中我们可能有意无意就进入到写产品体验报告的状态，只不过多数都在心里写，比如我们每买一样东西可能就写了一次产品体验报告。没有这么做的企业可以尝试一下，说不定会有特别的收获。

本文首发于我的微信公众账号「时间易逝」，欢迎订阅我的微信公众账号
在微信中搜索「doevents」或用微信扫描页面右上方二维码可订阅我的微信公众账号

想起了20多年前一个叫 TT 的软件

发表评论

儿子在平板上玩「我的世界」这个游戏，学会找到游戏录播视频边看边实践，玩的不亦乐乎。偶尔几次给我说要玩模组，这东西我不大懂，大概看了看录播的视频，好像都是在台式电脑上开玩的，每每提及时我都会说：『要玩这个得先会操作电脑，要会使用键盘鼠标这两个最基本的输入设备，鼠标已经会了「小游戏的功劳」，我教教你键盘怎么使用？』

后因学习拼音好像略微跟英文字母有冲突，所以在大概说了说键盘布局后也就不了了之了。最近学前班结束，我就琢磨着大概给他讲讲电脑的基本组成，并让他练习一下键盘的使用。

按照我的理解，要想很好的使用键盘可以通过对键盘键位的认识和重复性的练习来达到。对键盘键位的认识一方面要了解整个键盘区域的划分及其功能，另一方面是 10 根手指每一根都负责哪些键，如题图所示。重复性的练习则是提高熟练度，最终能够做到快速的盲打，提高熟练度的练习结合一款软件来配合练习应该会更好。

上网搜了一下指法练习的软件，在线的大部分以 Flash 游戏的方式提供，尝试后发现并不好用。需要下载的动辄好几十兆，我突然就想起了 20 多年前我用的一款叫 TT 的打字练习软件。

随着回忆中浮现的昔日画面，TT 这个软件产品也越来越清晰，这是一个非常小的软件，应该不到 100K，具有由浅到深练习体系，从最简单的几个键到全键盘的练习体系都有，还具有游戏的关卡模式，有速度和错误率统计功能。我记得我们当时在略微熟练以后常常轮换着在宿舍的电脑中进行 PK 看看谁盲打的速度快及正确率高，或者看看谁能闯过多少游戏关卡，也蛮有乐趣的。当然玩这个软件的时间并不长，不知道当时有多少人在用这个软件，但我想用过的都应该多少会记得它。

从现在来看这是一个优秀的产品，首先这个产品解决了用户核心需求，也就是用这个产品能够提高正确打字的速度，解决用户核心需求的产品才能产生价值。其次，给出的解决方案足够简洁，可能包括上手使用简单、重复但不枯燥、清晰的阶段性目标、达到目标的反馈。

一开始容易上手会有一个好的开端，使用的人不会因为难度过高或挑战过大而过早的放弃，这个产品构建的由部分到局部，由浅入深的阶梯体系使得开始用的人能有一个良好的开端，通过不断的进阶中给你不同的选择，最终达到作为一款工具提高效率的目的。

整个键盘就一百多几个键，常用的键大约有 40 来个，这样的练习肯定会重复，重复一般会带来枯燥，这个产品通过游戏关卡的方式，逐渐增加字母的方式来完成进阶的挑战，大大降低重复带来的枯燥，使得在练习的时候有那么一点点有趣，在当时黑黢黢的屏幕和命令后的 DOS 时代，体验做的也不错，在挑战每次目标的时候有动静结合的交互，还有声音提示。

每选择产品提供的一项功能，会清晰的给出一个阶段性的练习目标，对这些阶段性目标中的字母使用各种组合进行随机处理，既能够很直观的看到完成一次练习你要达到的目标，也很好的练习了各个手指的熟练度。

在每一次向目标迈进的过程中，会有即时的反馈，能够很直观的以视觉、动态及声音提示向用户进行反馈。你时刻知道你正在那里，还有多长时间完成，这次的挑战比上次的挑战有进步与否，过程中有多少地方有错误等等这些都会给予反馈。

我想我们现在在做的产品可以在完成用户核心需求的基础上，考虑从这四个方面着手使得整体的解决方案更简洁。

我眼中的传统软件企业和互联网企业

发表评论

在传统软件企业工作 15 年后，转换阵地进入一家互联网企业，转眼快 3 年了，说说在这两种类型企业工作的一些感触。

先说说这家互联网企业，是做数据中心的，主要为中小企业提供互联网的基础服务，属于B2B模式。我对数据中心的理解是它主要解决数据在两个方面的问题：

数据在空间维度的传递「通信」；
数据在时间维度的传递「存储」。

围绕这两个要解决的主要问题构建一系列基于软硬件的产品，在构建产品过程中和传统软件企业的工作方式还是有很大不同的，具体体现在组织结构和产品开发方式有不小的差异。

组织结构

组织结构的不同在我看来最终会反应到对资源使用的效率与整体的协作力。

传统的软件企业对于组织结构的设定就是一棵树，从上到下逐渐扩展层级，高度取决于团队的规模，宽度取决于职能部门的规模。

这种组织结构比较好的一方面是每个组织成员对于所处的位置比较清晰，从职能内部来讲分工也比较明晰，有利于工作任务的分工，其由于职能部门的分割自带分组特性，可以把每个职能部门看成一条流水生产线。

不好的一面是跨职能部门的协作型缺乏灵活，沟通成本随着层级递增成指数增长，在多职能部门间涉及到客户时多有扯皮，就职能部门内部来讲往往资源过剩，最大的直接体现是你工作几年后发现每天都很轻松。

我所经历的工作企业大多采用这种组织结构，从搜索引擎中搜一下「组织结构」，能够看到的搜索结果中的图片也大都是这样的组织结构。

我所在的互联网企业采用矩阵式组织结构，在传统的树形组织结构上，职能部门在垂直上是由很多小团队组成的，有直接隶属于职能部门的团队，主要负责完成公用性的任务，其他的小团队则为各个产品团队人员，这种产品小团队在横向和纵向受到双重管理，具体来说，涉及到产品相关的产品经理会从横向综合调配各个职能部门中隶属于产品团队的人员，完成目标。涉及到职能部门行政管理则由职能部门统一管理，大概如下图这个样子。

这种组织结构好的一面是能够最大化利用资源，打通了横向的隔离，协作效率极高，比较灵活，会大大降低沟通成本。如果要开设新的产品线，从横向纵向组建相互隔离的团队即可，而这种纵横隔离也最大程度上降低了互相扯皮的发生。

比较不好的一面是对每个团队的领头人要求极高，针对每一个点要确立明确的目标并能正确的理解目标，执行目标。

这种组织结构也跟互联网产品的开发有很大的关系，每个组织都是独一无二的，还应当以自身的特点出发，其他的仅能借鉴不能套用。

产品开发方式

传统软件企业在产品开发方式上，比较依附软件工程的理论，无论是瀑布式还是RUP（统一软件开发过程）迭代式，都讲求产品的大而全的规划和论证，重文档，重流程，重测试，所以动不动一个软件产品开发好几年，每更新一次再来个半年一年的，不能说这样的产品开发方式不好，针对特殊领域的产品开发，这种方式还是很有优势的，比如在航空航天、金融等领域这样的产品开发方式还是挺有优势的。

互联网企业在产品的开发方式上跟传统软件企业略有不同，当要开发一款产品时，首先要围绕总体的目标找到假设的最核心的，最小化的可执行「产品」，快速实现后上线验证是否为用户带来了价值，根据验证的结果再做接下来的动作。

比如验证失败了（这是常态，所以互联网企业大多允许一定程度的试错），再寻找另一个假设的最小化可执行「产品」，直至找到或者承认失败。假如幸运的验证成功了，也就是找到用户了，那接下来用户自然会倒逼驱动产品的迭代发展，在这个过程中用户甚至还会帮助企业建立服务流程，考核体系，这也就是平常讲的「以用户为导向」。

这两种产品开发方式跟面对的用户类型也有不小的关系，如果用户是企业，一般企业用户追求大而全，这几年传统企业都在积极+互联网，但思考的出发点还是从大而全，从局域网向广域网，或许在这方面可以针对互联网的产品开发方式进行借鉴，在+互联网的时候先确立一个最小化的目标进行验证，毕竟这种产品开发方式的思路很大一部分就来自传统生产企业「丰田的精益生产」。

这里说的是软件产品开发相关的企业，其实传统企业都是可以借鉴一下，如果把每项业务看做一个产品，业务负责人看做一个产品经理，不论从组织结构上，还是在业务开展上都可以结合自己的特点进行尝试。

如何寻找没有版权限制的高质量图片

发表评论

在版权限制之外同样存在很多高质量的图片素材可供使用，对于并没有很多预算或无法获得授权的朋友是一个不错的选择。今天说说我寻找图片经常去的一些网站供大家参考。

摄图网 699pic.com

摄图网「699pic.com」是一个提供免费正版摄影图的网站，目前这个网站大概有 100 多万张图片，平常我偶尔去这里，之所以第一个放这个网站是因为这个站点访问是最无压力的一个站点，要使用这个网站的图片需要注册账号。

pixabay.com

pixabay.com 这个网站的图片及其质量是蛮不错的，访问同样无压力，但访问速度稍稍有些慢，这是我寻找图片常去的一个网站，一般都会有不错的收获，支持多尺寸免费下载，不过需要注册一个账号并保持登录状态，其实不下载也是可以使用的，要看具体使用场景而定。

pexels.com

pexels.com 同样也是一个图片及其质量蛮不错的站点，访问同样无压力，这里也是我经常去的一个地方，速度也不错，针对每一个图片都会显示详细的信息，比如对于拍摄的相机型号、光圈、焦距等，支持多种尺寸的下载，目前下载并不需要注册一个账号。

Google.com

Google.com 是我经常使用的一个搜索引擎，用于任何想在互联网上搜寻东西的时候，查找图片也不例外，有专门的图片搜索站点。直接访问这个站点还是有些压力的，其实这个站点是不能直接访问的，需要找一些途径来使用它。正如下图中红色箭头指向的位置，在进行图片搜索的时候，Google人性化的提供了一个工具按钮，使用该按钮后会有一排的选项，比如大小、颜色、类型、时间、使用权限等，在使用权限中可以找到没有版权限制的图片，结合其他选项就能获得高质量的图片列表，通过不断的变换搜索关键词从而找到满足自己使用的图片。

以上是我在寻找图片时经常使用的一些站点，希望这些对你也有用，在这些站点寻找图片主要依据关键字搜索获得，我主要是直接使用图片会多一些，最多有少量的尺寸修改。如果是设计师想从图片中获得设计灵感，还有不少其他的去处，比如国内的「花瓣」，国外的「Pinterest、Dribbble、Uplabs」，如果你有更好的发现，并愿意分享，非常希望你能告诉我。

去当收银员，该当个怎样的收银员？

发表评论

最近认认真真的当了当收银员，并让团队的成员轮着去当收银员，有一定的效果，但跟我期望的尚有一些距离。那么如果去当收银员，该当个怎样的收银员呢？

这主要取决于自己是如何定位这件事，如果定位于收银本身，那可能每一次轮到自己时就会相当乏味的在那里坐上那么一天，几次之后心里难免产生「我特么的是来干xxx的，……」的想法。但如果你把收银这个场景的主体作为你的用户场景，然后再与你的本职工作联系起来，开始思考，应该会有截然不同的收获。

比如我是作为一个产品经理去做收银员，我可能会开始思考在这个场景下目前产品的使用情况是否跟期望的一致，往来的客户具有什么样的特征，什么时段客流量会多一些，什么产品好卖，内部的业务是如何开展的，内部是如何管理的，周边环境什么样，什么样的推广可能会有效……，一旦开始这样思考才有可能确立产品下一步的目标，才能持续性的改进当下的产品。

比如我是作为一个架构师去做收银员，我可能会开始思考所做的架构是否良好的支撑当下收银环节的业务模型，针对不同用户角色的功能架构是否跟实际相匹配，架构的逻辑结构十分合理，物理架构是否有改进地方，是否遗漏了重要的质量要求，是否遗漏了约束下的架构设计部分的内容……，一旦开始这样思考才有可能持续的演化整体的架构，从而让架构更贴合用户的使用，不论是外部用户还是内部团队的用户。

比如我是作为一个设计师去做收银员，我可能会开始思考当下我的设计是不是更有利于让使用者使用，自己用起来是不是很容易，当下他们使用情况怎么样，是不是能够很直接的找到想要的展现，他们的基本特征是什么，设计面向的是什么行业，具体的场景是什么样的……，一旦开始这样思考，相信设计就不光是色彩的运用与美的展现。

比如我是作为一个程序员去做收银员，那就可以真正的用一用自己开发的最终产出，看看在处理实际业务的时候是不是像自己想象中的那样出类拔萃，顺便也可以看看其他小伙伴完成部分是不是也是同样的出类拔萃，是使用良好，还是问题多多，设计的是不是合理，结合场景也可以思考很二的需求是不是真的很二，需求怎么对应到开发的实现……，当将场景业务、具体使用和技术实现互为对应与融合之后，回过头来在看看我的开发，我相信会更好，每一个技术实现毕竟都会对应到实际的应用领域。

当然这样做并不容易，但是我们可以一点一点做起，如果每个人将这些一点一滴的体验带到整个团队，并最终体现在产品中，想想产品会变得怎样。现实中还有很多类似「让你去当收银员」这样的阶段性任务，遇到这样任务的时候我们应该想一想该怎么定位接到的这些任务，相当程度上这个任务不是真的就是让你去当一个「收银员」，那不如直接找一个专职的来做更合适。

目前这个阶段去做「收银员」是期望大家从不同的角度来近距离的接触一下我们产品中的其中一种类型的用户，以便对于我们在做的产品隶属的行业有个直观的认识，毕竟团队所有成员并不太具备这个行业领域的知识，近距离接触用户的实际场景可能是一条获取行业领域知识的路径，这个阶段的长短取决于团队的通力合作，用户就在那里，而我们的产品还在路上。