发现新产品的网站

此博客中的热门博文

远离你身边的煤气灯人

发布于一月 04, 2022

今天讲个煤气灯人的故事，这可不是一个关于张牙舞爪的喷火小木偶的恐怖故事。我想说的远比恐怖故事惊悚多了。它毁人心智，杀人于无形。何为煤气灯人？如果你感觉这个词很陌生，那么朋友，你听说过PUA吗？ PUA（Pick-up Artist，把妹达人），一个近年来广为人知的群体，与其相关的理论亦称为“泡学”。大量不善交际的尝试者，几经辗转购入高价PUA课程，并将其珍若江湖两性秘笈。但同时在更多人眼中，PUA群体也沦为过街之鼠，人人喊打。甚至还有人故意在人际交往中，突显自己的直男直女本性，与“套路”二字划清界限。但你真以为自己能摆脱PUA吗——Nope，甚至也许你就是正在进行“情感操纵”的PUA本A 。 01. PUA，其实就是一种煤气灯人现今意义上的PUA，上可追溯至1944年，由美国导演乔治·库克执导的一部惊悚片《煤气灯下》（Gaslight）中的主角安东。在电影中，钢琴师安东（CharlesBoyer饰）为了将妻子宝拉（Ingrid Bergman饰）所要继承的大额财产据为己有，一面将自己伪装成潇洒体贴的丈夫，另一面又不断使用各种心理战术，联合家中的女佣企图将妻子逼疯。在丈夫缜密的心理操纵下，宝拉逐渐变得神经兮兮，怀疑现实、质疑自己，最后在精神上几乎完全依附于安东。这种试图破坏他人对现实的感知的情感操纵，也因该电影而得名为 Gaslighting（煤气灯操纵）。下面我挑选了几个经典的Gaslighting片段让大家品品： Part 1 信息封锁：在一段时间内不断重复强调某一信息安东和宝拉新婚满三个月时，外出去伦敦塔游玩。出门前安东送给妻子一枚小巧的白色胸针，声称是母亲去世前留给他的，并嘱咐宝拉把它收好。此时安东略显刻意地强调了一句： “你可能会弄丢，你知道的，你经常丢三落四” 。这是电影中安东第一次对宝拉实施Gaslighting，也是宝拉初步对自己产生怀疑。但是在二人离去之后，两位女佣之间的对话又再次佐证了，宝拉从未体现出任何异常。但是男主人安东，却不断向他们传输“女主人生病了”这一信息。如果说此时，仆人们还对女主人生病一事尚有所怀疑。那么接下来的事情，就令他们对于这一言论深信不疑了。当天的游玩结束后，安东便以饰物常年未佩戴、需要修理为由，向宝拉索要胸针。由于安东从一开始就并未将胸针放入宝拉的手包，而是偷偷将其藏在手心转移至别处，...

阅读全文

高可用用户中心设计

发布于五月 09, 2020

概述我们公司现在的账户体系比较混乱，每个系统都有一套自己的账户体系，没有办法进行统一的账户管理，比如统计一个人在哪个系统有账号，这样操作是比较麻烦的，还有就是我们如何进行用户行为分析，最终综合用户的信息进行用户的画像。这些都是需要解决的问题。常规的用户设计是统一账号和统一登录验证，统一注册等信息。但是结合我们公司的实际，发现这样的话我们的系统可能会出问题，我们无法屏蔽很多细节。我们的现状是：系统需要向用户隐藏是同一个公司的这个事实。也就是说我们做了用户中心的设计，但是不能让用户感知这个系统的存在。也就是说多个系统之间的登录都是需要隔离的。离论上不能做统一账号的登录，但是可以做统一账号的验证。同一个系统可能有多个马甲app，我想马甲app之间也需要登录隔离，虽然他们调用的是同一个后台系统，那么我们不得不面对一个问题，同一个用户同时下单的逻辑处理，需要后台做这种处理，否则就会出现严重的并发错误，而开发人员可能都没有注意到这个事实的存在，从而导致一些稀奇古怪的事情出现。 web端与app端应该是需要同时登录的，我们好像没有web的要求，但是好像有微信的web端的事情。假如我们有web端的登录，那么问题来了，我们要不要实现二维码登录web。目前看是可以先不实现的，但是作为设计考量我们不得不考虑这些。第三方账户的登录，我们是通过手机号作为唯一标识，那么不太好实现第三方的登录注册。但是我们可以后期实现，如果实现第三方的登录注册，那么问题来了，我们的设计貌似不支持，需要改动，就是改掉手机作为唯一标识的问题，但是想想好像是不影响的，只要数据能插入问题就不大，因为没有手机号，这些用户是不能登录需要手机的app，但是有的系统可以做特殊处理，从而支持第三方账户的登录注册。但是这样做也有缺点，就是用户利用多种方式进行注册，也就是说我们不得不解决一个问题就是用户可能存在多个账户的可能性。加入用户有微信注册的账户，然后又用手机登录，绑定微信，这个时候我们可能需要去系统中用微信的unionId或者openId查找一下是否有用户，有就不能绑定，没有才能绑定。如果有我们可能也知道了这个人有重复号的可能性。这个可能需要在做的时候处理。验证保密问题，公司居然都没有人提到这点。不过也对我们是通过手机号进行验证的。但是如果以后我们不在使用手机号，可能我们需要验证问题。还需要判断用户的活动记录...

阅读全文

Sniper 一个轻量级 go 业务框架的思考

发布于三月 01, 2021

阅读全文

如何老练地跟人沟通？

发布于四月 24, 2022

一、平常客套 1. 不说“辛苦你啦”，该说“您辛苦了”。 “辛苦你啦”是地位较高者对地位较低者使用的说法。 2. 不说“最近还顺利吗？”，改说“最近怎么样？” 工作顺不顺利是一个封闭式问题，只能用“是”或“否”来回答。让对方有一种被盘问的感觉。最近怎么样是开放式的问法，让对方掌握话题的主导权。类似的说法“今天玩得开心吗？” 3. 不说“你还记得我吗？”改说“我是上次跟您见面的某某。” 许久不见，谁记得你是谁，这样容易让双发尴尬。如果想把自己知道的事情告诉对方，一定要自己主动说，不要试探性的提问。这是人际关系的铁则之一。 4. 不说“下次一起吃饭吧？”改说“这个月末要不要一起吃个饭？” 很多时候说下次一起吃饭吧只是客套一下，后面迟迟不联络，有时候会影响别人对你的看法，觉得你是一个敷衍别人的人。要不你就别说，要说就说一个具体的时间，真吃。 5. 不说“你这么久不联系我，我可担心了”改说“你终于联系我了，我很开心。” 前一种说法会让人觉得被责备的感觉，多多少少心理不太舒服。而后一句大大方方的说出来自己的想法感受，都开心。 6. 不说“你今天很好看”改说“你今天也很好看”。咋得，我今天很好看，意思是昨天不好看？平时不好看？加一个也字避免不必要的误会。比如：现在双击屏幕的你今天也很好看。二、请求他人帮助或指派工作 1. 不说“可以占用你一点时间吗”改说“可以占用你1分钟时间吗？” 不同的人对一点时间定义不一样，对于时间一定要表达的尽量准确。比如“今天内”、“明天中午”、“半个小时”等等。 2. 不说“如果可以的话，请尽量早点给我。”改说“请月底前给我”。早点是多早，该说清楚的一定要说清楚，不要模棱两可。 3. 不说“这个再改改”改说“xx部分需要修改一下” 你说的这么笼统，谁知道你在说哪里。做出指示一定要具体，省时省力省口舌。 4. 不说“这个工作很简单，你能做吧？”改说“这个工作我想交给你来做。” 指派工作，不要高高在上，看不起谁呢？即使你没这个意思，不要评价工作的难易，分配工作，请表达出你的信赖和期许。 5. 不说“麻烦你了”改说“这个资料麻烦你了” 麻烦别人，说的具体一点，当然了，有时候说麻烦你了也可以，更具体一点会更好。 6. 不说“这个你顺便也做一下”改说“这个工作你能不能也做一下” “顺便”这个词不是很礼貌，让人觉得没有被尊重。 ...

阅读全文

个性化推荐从入门到精通

发布于二月 09, 2022

今天的分享将为大家解答以下几个问题：你的公司是否适合采用个性化推荐？如果需要个性化推荐，该如何做好？产品运营在参与到一个推荐系统的构建当中，有哪些常见的坑？有哪些可以避开这些坑的一些简单方法？以及如何修炼成一个优秀的推荐产品经理？一、“四个关键”为你揭开推荐系统的神秘面纱个人认为，推荐系统是根据用户以及不同的场景差异，对信息进行合理的排序、过滤，解决信息过载问题的一套机制。这个定义中包含四个关键点，如下： 1.“根据用户以及不同的场景差异” 对于很多刚开始做推荐的人可能会忽略这一点，大部分人在思考推荐时想的更多的可能是基于用户来做，但其实我从众多实践中发现，很多时候推荐产生价值不仅仅只是说以用户进行区分，相关场景的差异会对于最后推荐效果产生巨大的影响。 2.“推荐的本质是对信息进行合理的排序、过滤” 很多人认为推荐是一个魔盒，非常神奇，其实究其本质是企业有成千上万甚至上亿的 item，不管这些 item 是文章、视频，还是电商里面的商品，然后现在有某个人在一个具体的场景里面，企业需要把这些 item 给他看，那应该把哪个放在第一个？这就是推荐系统背后的运作原理。 3. “推荐系统要解决信息过载的问题” 举个例子，如果你的企业只做爆款商品，整个公司只卖两个商品，这样用户一看就明白了，显然也不需要推荐，所以做推荐的一个前提条件是你公司本身提供的业务里面的信息太多了，对于一个正常的自然人来说，他处理不了那么多信息的时候，企业才需要去帮助用户解决信息过载的问题，从而为用户设计这样一套机制。 4.“一套机制” 这点很好理解，推荐系统是由不同的算法、规则等构成的一套机制。这四点是我从产品视角为你解读了什么是推荐系统，以及他的一些简单作用。二、推荐系统、广告系统、搜索系统三者有何不同？事实上，解决我在前面提到的一系列问题，推荐系统并不是唯一的方法。比如，前面所提到的排序、过滤，做技术的同学应该很容易联想到，搜索和广告系统也涉及排序、过滤，且搜索也一定程度上解决了信息过载。那么，这三个系统，它到底有什么区别呢？我从 5 个方面对其进行了对比，下面将一一讲述： 1. 用户获取信息的方式。广告与推荐系统，用户都是被动的，但搜索不一样，用户是主动搜索的，他需要输入一些关键词，会加入一些自己的意见和重点。 2. 点击率要求。这三个系统...

阅读全文

项目管理标准模板

发布于九月 22, 2020

之前写了一篇《技术管理标准模板》，其中项目管理部分并没有具体深入，而这一技能不仅仅是对于技术Leader的要求，从我的经验看来，只要是程序员，具有项目管理能力都是如虎添翼的，即使你走的是专业路线。本文即基于自己的经验，从项目的启动和迭代阶段总结了敏捷项目管理的一些标准动作。启动阶段相关干系人沟通，同步项目背景、业务价值等启动会议：召集相关干系人，明确业务相关信息，确定相关流程制度等需求收集和分析-> 总体需求文档，概括性的功能与非功能需求列表初步的产品规划-> 每一轮迭代的需求列表、发布时间创建项目基础设施-> 可持续交付到测试环境的基础项目，包括各个端的代码库、到测试环境的流水线等。迭代阶段两周为一迭代，包括需求、设计、开发、测试、发布。关键点在于需求的拆分、优先级以及并行化。 1. 需求评审对本轮迭代的需求尽心评审确认。前置条件：产品经理对此轮迭代进行需求确认，产出需求条目，按优先级排列；需求需要拆的足够小，把大需求拆成一个个能够独立开发测试发布的小需求 2. 工作规划根据本轮迭代需求做WBS任务分解 WBS工作项分解: 甘特图里程碑结点: 表格或者里程碑图风险管理：风险点预估、严重程度、可能性、应对措施 3. 设计/技术评审分别对交互设计和技术设计进行评审前置条件：设计师需要输出设计图；技术部分做概要设计和系统设计，随着每一轮迭代进行更新维护 4. 测试用例评审由QA安排，会前需要提前将测试用例文档发给产品经理与研发，提前标注有疑问的用例。 5. 开发、测试过程的监控持续交付：开发和迭代测试，需求开发完成后即测试并进行缺陷跟踪。会议每日站会：全员站会，了解整体状况，对暴露出的风险和问题作出集体决策。项目周会：10人以上团队。解决整体计划层面、跨团队协同配合的问题。项目周报汇总项目总体状况，回答三个问题项目的整体进展状态到底如何？风险可控吗？目标达成有没有问题？ 6. 版本全量测试对所有已经开发完的功能进行交叉测试、全量测试、埋点测试、回归测试、第三方云测。 7. 验包发布此迭代所有功能开发测试完成后，提交审核流程，各流程审核人验收通过后发布。 ...

阅读全文

搜索此博客

KTSee.eu.org