招聘的隐形成本

3、4 月份是离职高峰期,很多人领完年终奖,高高兴兴地去寻找新的就业机会。

有人离职,公司自然也要花大力气招聘,所以每天都有很多人到公司面试,有人应聘自然要有面试官,对于技术型岗位,面试官更多是用人部门较为资深的工程师。
现状
面试过程中,更多考察技术,也会介绍一下目前的公司的业务和产品, 不管合格的、不合格的,面试过程基本上都得要 1 个小时,假如一天有 5 个人来面试,则需要花费 5 人/时 的工作时间,而参与面试的人中,入职率又是极低的。

本来项目已经人员紧张,面试还要花费工程师巨大的时间成本,从而导致了效率的进一步下降。
解决方法

  1. 对于技术型岗位,准备好能够完[……]

继续阅读

远离拖延:一个简单易行的时间管理方法

都说 Deadline 是第一生产力,很多事情不到最后一刻就没有动力去做。很多人研究、使用了各种 GTD 工具,依然做不好时间管理。

作为一只产品汪,日常工作比较琐碎,文档撰写、原型设计、分析数据、和工程师沟通产品问题等等,工作经常被打断,因而顾此失彼,回顾一周,觉得自己不停在忙,又记不起究竟在忙些什么。

为了解决这个问题,在一周开始之前,我会先在 Evernote(当然也可以用有道笔记、为知笔记等软件)上新建一个如下图的笔记:

笔记分为周一到周五,以及本周计划一栏,如果某些安排是已经确定了的,那就把它填写到对应的时间下面,比如预定好的会议、跟别人承诺过的时间等等[……]

继续阅读

RTB 广告投放流程详解

RTB 广告简单来说,就是把访客的每次页面浏览,通过拍卖的形势卖给广告主,谁出的价高就把访客的这次浏览卖给谁,然后显示相应的广告。RTB 整个过程主要的三个参与者为 AdExchange,SSP(供给方平台)和 DSP(需求方平台),下面就详细说说其中的原理和流程。
竞价流程

 

注:下放的编号和上图中的序号对应

  1. 用户浏览媒体网站,媒体网站通过添加的 SSP 代码向 AdExchange 发起广告请求。
  2. AdExchange 将这次请求的关键信息(如域名 URL、IP、Cookie 等)同时发送给多家 DSP,我们把这个请求称为 Bid Reques[……]

继续阅读

使用 ETag 识别唯一用户

在网络上,Cookie 是识别用户的基础,无数的广告投放平台,通过 Cookie 来记录用户的 ID,监测用户看过什么广告、点过什么广告、看过哪些网页,通过这些信息推算用户的兴趣爱好,进而再推送更加精准的广告。

越来越多的浏览器推出“无痕浏览”、“隐私模式”等功能, 360 等安全卫士软件也自带了清理 Cookie 的功能,这就导致常规使用 Cookie 识别用户身份的手段越来越不准确,这里介绍另一种方法,使用浏览器缓存的特性,来记录和识别用户的唯一身份。
浏览器的缓存策略
当用户浏览不同的网页时,图片等静态资源会重复下载,比如网站的 logo,每浏览一次,logo 图片都会重复下载[……]

继续阅读

APP 创业者必知的产品和服务

随着移动互联网创业的火热,面向创业者的产品和服务越来越多,它们涉及到 APP 生命周期的方方面面,合理使用这些服务,可以大大加快研发速度,节省成本,我整理了一个常见服务的列表,不定期更新。
1. 短信服务

2. 社会化分享

3. 推送服务

4. 数据统计分析

5. 即时通讯
在线聊天[……]

继续阅读

iOS APP 安装来源分析原理介绍

线上推广移动 APP,不同渠道带来的安装量、留存率、付费等指标是衡量渠道价值的关键,在 Android 平台,通过分包来区别不同渠道,在 iOS 平台,这就成了一个难题 [注1]。一般来说实际的场景是这样:

用户在 A 应用中看到了 B 应用的广告,对 B 感兴于是点击了广告,程序自动跳转到 APP Store,用户安装后又在 B 应用中付费购买了高级功能。

如果广告投放在多家媒体,他们将广告共同引流向 APP Store,不同媒体广告的曝光和点击容易被监测, APP 的安装量通过友盟等工具也容易被监测,但因为有 APP Store 这个屏障,最终 APP 的安装和广告渠道是无法对[……]

继续阅读

产品经理如何做测试?

本文不是教产品经理如何转行做测试,而是在团队没有测试人员的情况下,如何快速承担起测试的工作,以下是正文:

大公司有明确的职位分工:工程师、测试、设计、运营都由不同的人负责,测试自然就是测试工程师的事,而在中小型创业公司,人员匮乏,很多团队只有工程师和产品经理,工程师负责开发,开发以外的事情全都由产品经理承包,这其中自然包括测试。测试是产品上线前的质量检验,只有通过测试,产品才能放心的呈现到用户面前,本文就详细说说,产品经理该如何做测试。

我们不探讨测试究竟分多少种,每种类型又是如何定义,产品经理的测试任务基本只涉及一种:功能测试,测试的内容就是:工程师实现的产品,和 PM 最初定义[……]

继续阅读

产品经理该如何和工程师沟通?

沟通是一门艺术,产品经理和工程师之间的沟通更是,笔者总结,有以下几点需注意:
1. 在需求正式开发之前,介绍清楚需求背景
在项目开始之初,一般会定义好商业需求文档,说清楚为什么要做这个产品,能给公司带来什么价值,有什么战略意义,可能有什么风险,这些主要是给领导回汇报争取资源用,我的建议是将这些同样给研发团队讲一遍,让团队所有成员清楚自己所做的东西的价值,有了共同的目标,也更有助于凝结团队力量,共同完成目标。
2. 让工程师感受到所做的东西所带来的效益
成功上线不只意味着在服务器上敲完命令,新功能正式生效,对研发团队来讲,也代表了前一阶段的成果,让大家及时感受到最新的成果是激励团队的重要[……]

继续阅读

不要轻易重构

在项目维护的过程中,由于工程师水平的参差不齐,很多需求时间紧、任务重,或又因前几任工程师离职没做好交接,导致了大量的可读性差、效率低下的代码,这时候,在职的工程师最想做的恐怕就是重构代码,将那些垃圾代码舍弃,按照自己良好的设计重新实现一遍。

在工程师看来,重构之后有非常多的好处:

  1. 代码更简洁,可读性、可维护性更强
  2. 实现新的需求效率更高
  3. 新人的学习成本更低

重构之后丢弃了过往的累赘,往往也会丢弃了过往的经验。尽管过去的代码十分丑陋,但它们确确实实可以正常地运转。如果要重构,能保证新的代码不会像过去团队的代码一样,慢慢变丑陋吗?依然会面临同样的风险,而且,过去团队已经付[……]

继续阅读

基于 Github Issues 的单页面静态博客

玉伯的博客 https://github.com/lifesinger/lifesinger.github.com/issues 让我第一次知道 github issues 还可以这样用 ,作者发了很多干货技术文章,让我不由得感叹 ,文章不在于形式,也不在于写在哪里,只要是好文,总不会被埋没。

即便如此,很多人仍然希望能有一个独立域名、可以自由修改主题的博客。Wordpress 、Typecho 太重,还要买 VPS、部署服务器环境、安装插件、主题,太折腾人,于是我想,完全可以利用 Github 提供的 API 来实现一个只有一个静态页面的博客,具体思路如下:

  1. 作者在 Githu[……]

继续阅读