Why·Liam·Blog

人生若如初見

产品经理职责

  • 获取需求

  • 明确用户特征

  • 与一线客户交流

  • 获取、分析、描述

      - 迫切
    
      - 强烈
    
      - 高频
    
  • 市场报告
  • 行业文章
  • 竞争对手产品
  • 技术储备

      - 是否存在技术资源
    
      - 是否需要技术资源
    
  • 市场资源

      - 媒体、推广、公共
    
  • 运营资源

  • 发现新产品机会
  • 改进现有产品机会
阅读全文 »

很久没有更新了,最近发布了新的版本 2.0.0

没有详细的测试可能还会有一些 bug,喜欢的朋友可以先尝试一下 下载

这个版本主要做了一些优化

  1. 增加了自定义 Key 的功能(现在用的人太多了,大家最好使用自己的 Key)
  2. 去除了自动更新(GitHub 被墙,自动更新没什么作用了)

暂时可以看一下简单的 使用说明

阅读全文 »

本系列文章的开发环境为:

初步体验,手 Q 采用的应该是线性动画,即缩放比例等随着手指滑动的距离以一次方程的形式变化。动画达到最大幅度时截图如下(4.7 寸):

阅读全文 »

由于一些不可告人的原因,我们知道 Google 的各项服务在国内都是半死不活的状态。

然而,今天留白地发现,无论是网页版还是移动端的 Google 翻译,可以无障碍使用了。

尽管快到愚人节了,但这次真不是幻觉,Google 翻译 App 在中国大陆完全可用了。

根据刚刚大家的反馈,看来在不科学上网的情况下也是可以正常使用的 🤔 Google 也特意制作了一个标题为「100 秒了解升级版 Google 翻译」的视频,全部为普通话配音,为中国用户介绍这款应用。

阅读全文 »

首先是技术、交流沟通、演讲、领导力、处理问题能力等这些硬技能。这些毕竟是需要经验和知识的积累的,且总有提升空间。而在评估一个人的时候,同样被看重的,还有一些其他的很重要的方面。

第一,不想当然。看似及其明显的一个品性,却在实际工作中也是最珍贵的一个品性之一。尤其一些相对比较有经验、却其实对一个新系统知之不深的工程师,很容易想当然地根据经验推测一个系统或一段代码可能是如何如何,而不谨慎的校对。而能做到这一点,其实就能避免工作中很大一部分的错误。

第二,一定要正确。工程师是一个需要极其严谨的职位,并没有太多的容错性。你做的、执行的,一定是自己有把握是正确的事。如果没有把握,那就花功夫去弄清楚,多问多查多资讯。实在还是找不到答案,告诉别人这是一个推测,或者有一个对万一出错的备用方案。很多时候一个人在工作中被信任,也因为大家觉得他靠谱,他说行或者不行,都是有意义的,不含水分的。而如果过于急躁地喜欢表达观点或执行,却屡屡被证明是错的,久而久之,信任度就会减分。

第三,保持透明。任何时候不存侥幸心理。比如,不会因为觉得一个计划或者变更可能不被批准,就试图不声不响地做。或者应该提前发信件声明的、或是之后应该发信解释的一些情况以为有人不知道就保持沉默。事实证明,这种事本来按程序来不会有什么大问题,一旦钻空子就往往惹祸。这也是一个工程师办事可靠性的一个重要方面。

第四,有始有终。很多系统,一开始的设计和规划总是有意思的,接下来的实现和执行也是很好玩儿的,最后的各种扫尾包括修补、回答问题、完善文档、确保系统百分百工作等等可能相对会比较乏味一点。而能不能有始有终的将一件事完完整整地从头到尾很负责任地贯彻,也是工程师很重要的一个方面。

阅读全文 »

前一段时间写那篇《API 杂谈》的时候,其实是做 API 设计的时候。我们这个 API 最开始设计的时候支持三个项目,也就是三个产品共享的 API。经过设计阶段的抽象,整个 API 中大约百分之六七十的实现应该是共用的,每个产品只需要根据各自产品不同的部分,实现 API 每个产品相应 Handler 里面的一些程序。

因为三个项目的时间都比较紧张,所以这三个项目组同时针对各自的产品进行 API 的开发。并且由于业务原因,有些地方必须在短期内重用一些老代码。虽然我们有很完善的相互 Code Review 的机制,难免的,因为一些 Dependency 和 Deadline 的原因,最后实现还是和设计慢慢产生了差异。而这些差异如果听之任之,久而久之就会成为 Tech Debt。

因为 API 慢慢成型上线了,逐渐有了更多的产品希望使用我们的 API。理论上,他们只需要实现产品特有的百分之三十左右的逻辑,而且是在一个框架里实现,所以新产品的支持会相对很容易。但是由于并行开发中遗留的一些不完美,因此我们必须对其进行快速重构才能满足这样的需求。

于是,上周老大 JM 说:这周你别的事放一放,我们先把重构这事给做了吧。这一周下来,倒是有了几千行的代码量。因为白天还有很多别的工作,只能晚上写。虽然很累,但是收获颇多,说说自己的一些心得吧。

之前写过《写代码的四个境界》,重构绝不是简单的把代码从一个地方移到另一个地方,很多时候,有些地方可能比写代码还要需要技巧。因为是基于一些已经成熟的代码,所以一定程度上简单,因为有些细节已经实现了。但从另一个意义上来说,需要把一些功能块抽象、去重复、并重新构造。有的时候想想,有点像整理房间。那么最重要的一点,就是你知道最后整理完的理想状态是什么样,并且始终脑海里有这个构图。

阅读全文 »

我们是不是总是隐隐约约觉得竞争总是好的而垄断总是不好的?而事实是否如此?首先,男神 Thiel 所说的垄断并不是由于政府权力所带来的垄断,而是当一个公司的产品足够好,好到其他公司无法提供替代品所带来的垄断。

男神在书里说了垄断大法好啊!垄断才能挣钱!垄断才能创新!每一个成功的企业都是垄断的!虽然经济学认为「完全竞争」是一个理想的状态,可是在「完全竞争」的状态下没有公司能够长期盈利。此时可能有人会说处于垄断地位的公司会逐渐丧失创新能力,可是 Thiel 认为企业为了能够保住垄断市场的地位会不断努力创新,并且因为垄断能够带来丰厚的利润,这也能支持公司投资更多的创新项目。这种对科研与创新的长期投资可是那些挣扎在竞争当中的公司想都不敢想的呢。

不过在现实生活中垄断企业因为想避免对自己的审查总是想把自己伪装成竞争企业。以 Google 为例,到 2014 年的时候 Google 在搜索市场中的占有率是 68%,处于垄断地位。可是它会不断宣称自己是一家广告公司,而它在整个广告市场中的占有率只有 3.4%。另一方面,竞争企业会往往将自己的竞争市场描述为一个很小市场,仿佛自己是这个小市场中的垄断企业。将自己描述为垄断企业会显得自己很厉害,但是另一方面如果企业家误判市场也会让企业误判自己的竞争对象。比如说我在 Palo Alto 区开了唯一一家英式餐厅,若我把市场定义为英式餐厅,那么我自然就垄断了这个市场。可是在 Palo Alto 可能并不存在一群吃英式餐厅为主的消费者,所以我实际需要竞争的对象是整个 Palo Alto 区的所有餐厅才对啊。

那么垄断企业长什么样?男神认为他们一般有以下一个或者多个特点:

  1. 牛逼技术:要有比其他竞争者好 10 倍以上的技术。像 Google 的搜索算法就比它的竞争者好 10 倍以上,自然就垄断市场啦。男神还顺口说了一个小诀窍,要想有比别人好 10 倍的技术最简单的方法就是在一个没有人做的方向创新。
  2. 网络效应:网络效应说的是有些产品用的人越多就越有用,比如 Facebook。但是建立一个有网络效应的产品要注意从一个小群体开始,再慢慢扩展到大群体。比如说 Facebook 最开始只是为 Mark Zuckberg 的同学设计,然后这个产品将用户群扩展到了全人类。
  3. 扩张能力:一个好的 startup 应该有能迅速扩张的能力。技术公司就是一个很好的模式,因为很多技术产品做出来以后可以迅速扩展到很大的用户群中,而成本的增加并不会很多。
  4. 品牌:建立一个用户超爱的品牌也是实现垄断的方式,不过品牌总是要基于一个优秀的产品之上。
阅读全文 »

  1. 纵坐标单位和平均值都是通过插入—形状,右击形状,编辑文字。之后设置形状的填充和线条都为无色。字体颜色也会变成无色,要改一下。
  2. 坐标轴文字方向设置:选中坐标轴—右击,选择设置坐标轴格式—在 对齐方式、文字方式中设置
  3. 图例更改通过拖拽、拉长实现

某品牌在消费者心中的形象

注意点:对着要添加的散点单击鼠标右键选择刚添加的工具(JWalk Chart Tools)

2010年某集团成本构成示例

阅读全文 »

说实话回国的第一天 有许多的兴奋

或许是对一个新的生活的向往

毕竟这又为自己的生活增加了许多的可能性

与过去的生活说再见

在美国这些年的生活 改变了我的一些习惯

阅读全文 »

在大多数情况下,实际行动都是发生在其主观意义处于模糊的半意识、或者实际上处于无意识的状态中,行动者更有可能是在模模糊糊的意义上「知道」它,但并不明白自己正在干什么或者对它有着明确的自觉意识。

他的行动大多受本能驱使或者习惯使然。只是在偶然的、并且涉及大量同一行动的情况下,往往也只有少数人对于行动的主观意义——无论理性的还是非理性的——产生明确的意识。

完全自觉和明确的有意义行动的理想类型,只能是一种边缘情况,在分析经验事实的时候,任何历史学和社会学的研究都必须考虑到这一点。

—— 韦伯《经济与社会》

The Why·Liam·Blog by WhyLiam is licensed under a Creative Commons BY-NC-ND 4.0 International License.

WhyLiam创作并维护的Why·Liam·Blog采用创作共用保留署名-非商业-禁止演绎4.0国际许可证

本文首发于Why·Liam·Blog (https://blog.naaln.com),版权所有,侵权必究。

阅读全文 »
0%