作者归档：月夜

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

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

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

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

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

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

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

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

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

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

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

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

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

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

发表评论

在传统软件企业工作 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的，……」的想法。但如果你把收银这个场景的主体作为你的用户场景，然后再与你的本职工作联系起来，开始思考，应该会有截然不同的收获。

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

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

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

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

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

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

又是一年招聘季

发表评论

又是一年一度的招聘季，团队很缺人，在 HR 部门同学的大力支持下见了不少的人，也放出几个 Offer ，但人员缺口还是有不少的。在见到的这些人中，有相当一部分就是在碰运气，没有丝毫的准备，这在我看来是挺奇怪的一件事情，记得以前写过一篇「找工作时做这些准备会更有效」，从通用性的准备工作上说了一些，借这个招聘季，结合我们的职位缺口，我再絮叨一下这些事情。

开发工程师

从用人方来看，针对不同工作经验的开发工程师会有不同的期待。具体到我们这里，首先是对开发基础技能的期待，这是基础；其次，我们还比较期待能够在过往项目经验中选一个点，讲清楚使用技术解决了那些问题以及有什么收获；第三，我们还期待能够聊聊对工作的期望。这是三个主要的方面，其他的都是加分项。

基础技能不再细说，从其他两方面说说。对于过往的经验，用人方主要是想看到你是否在过往的工作中获得了足够的成长，有多少竞争力；对未来工作的期望，是想看看你是否对工作有一个明晰的认识和规划，面对你的期望能给你提供什么。

大部分应聘者都会有一个场合需要介绍一下自己，对于开发工程师，在我看来，选择一个过往工作中令你刻骨铭心的点来介绍会更好，如果没有这样的刻骨铭心那也可以选择一个让你最得意的点，这样介绍有什么优势呢？

从一个让你记忆深刻的点能够较容易的讲清楚，同时这一个点既然能够让你记忆深刻，必然不是孤立的，无论从技术上还是从技术背后解决的业务问题域都跟这个点是相关的，这样无论从技术的横向和纵向还是从业务场景出发就能较清楚的体现个人的成长，进而体现你的竞争力。当然这个点对于不同的开发工程师其大小是不同的，选择自己能够驾驭的点。

比较糟糕的是按照时间顺序介绍经历的公司和经历的项目，这是目前的主流介绍方式，乍一看做了很多的项目，但泛泛的讲，又不能突出一个重点，花了不少时间的同时，反而不能体现自己的竞争力，当然把这个点选择为整个工作历程并能驾驭的人除外。有部分的人看起来具有丰富的项目经历，具有丰富的工作经验，但只是不断重复复制上一年的经验。

比如你从开发一个「购物车」开始讲你怎么理解 Cookie，怎么理解 Session，进而接触了缓存，然后如何如何……，也可以从做前端的工作中发现公司产品面向三个方向：PC、手机、非手机智能终端，从开始逐个实现各个设备的前端到如何抽取出公用性的内容形成类库，然后建立不同分支以适应不同的设备……，你也可以从最开始的架构是如何分层的说起，并在业务开展过程中的演变……，你还可以从做前端的过程中怎么实现了团队协作的自动化说起……。

不管从什么开始说起，多数都应该涵盖在完成任务「目标」的过程中，发现了问题，然后解决了问题，总结之后获得了成长，然后设定下一个目标，职业生涯应该在这样的过程中呈螺旋上升态势。

产品经理

我们这里对于产品经理的定义是「产品经理是其所负责产品的 CEO」，简单的来说就是要负责产品整个生命周期管理。虽说人人都是产品经理，但其实并不是。在有限的资源下让产品持续的行走在正确的道路上，这其实是相当困难的，以至于到现在我还在持续不断的学习中。

产品经理涉及的范围非常的广泛，从对行业的知识洞察、用户的了解到形成自己的产品理念开始，在协调永远有限的资源中你得找到一条属于自己的路。这要求产品经理具有很宽的知识技能体系，并能够将这知识技能体系转换成产品各个阶段的产出，同时你还得有一定的运气。从这点上来看不是人人都能做产品经理的，但是每一个产品经理都是不同的。对于产品经理并没有太好的评判标准，我一般会从几方面跟前来应聘的人聊一聊。

首先，我会跟他聊聊他之前做过的产品，主要包括这些产品是做什么的？产品的用户是谁？产品解决了用户的那些问题？产品的现状如何？等，还会找一些同领域内的产品让他谈谈这些产品。

其次，我会跟他聊聊对于我们的了解程度，进一步谈到对我们要做的产品的了解，一般这部分聊的过程中最后都由我来简单的介绍我们在做的产品，其实信息就在哪里，我更期望的是在看到职位要求的时候看到其中一条是要求有医药零售相关的从业经验，然后产生景安网络跟医药零售有啥关系的疑问，进而找到信息，然后有所准备……

第三，我想聊聊如果作为我们目前在做产品的产品经理，准备怎么做。比较遗憾的是第二个环节很少有进行充足准备的，而又不具有领域内的知识，这就很难聊了。一般出现这样的情况时，我就会转入应聘者对于工作的期望和一些基于期望的疑问交流。

最后，一般我会聊聊业余生活都在干什么，就比较热门的产品的优劣交换一下各自的看法，对于产品经理常用的工具交流一下各自的看法。

通过这四方面我其实想知道的是，在过去完成任务「目标」过程中是否获得了成长；对信息是否保持足够的敏感以及你的信息获取及归纳方式；在获取的有限信息下，是否对该产品有兴趣，能够多快的了解产品背后的行业领域知识；产品终归要在生活中被使用，业余生活接触的产品要远远多于工作中接触的产品，业余生活都干些什么对产品经理很重要。

絮叨这么多，其实说的就是在找工作的时候还是需要认真做一些准备工作的，一方面应该总结一下自己的过往并找出优势，另一方面找到匹配自己下一个阶段目标的工作岗位并做一些针对性的准备，在郑州这个地方对于 IT 人才的需求目前还处于饥渴状态，无论是待价而沽还是稳步成长，好好准备后都会有所斩获。