企业制度

研发体系介绍

一、组织架构

我们的研发体系是一个矩阵结构,分为 研发组部门 两类组织。研发组专注产品的研发和维护,部门专注人员的培养和发展。概览如下:

技术部 产品设计部
研发组1 工程师(产品、算法、测试) 产品经理、设计师
研发组2 工程师(产品、算法、测试) 产品经理、设计师
...

二、部门

部门在研发体系中主要指产品设计部和技术部,这两个部门围绕研发人员的招聘、培养和评价来开展工作。

招聘

结合研发组的需求,部门需要:

  1. 评估需要招聘的人员水平与人数,并为 HR 部门提供职位描述。
  2. 配合 HR 部门筛选简历,并负责第二轮的专业面试。
  3. 为 HR 部门提供候选人的面试反馈,并一同进行招聘决策。

培养

部门需要关注成员的职业规划和持续成长:

  1. 部门应当评审成员在实际工作中的产出,例如进行 Code Review 和设计图评审等,一方面是保证产品质量,一方面可以持续为成员提供专业能力的反馈和建议。
  2. 部门应当积极组织旨在提升成员专业能力和建设部门文化的各种活动,例如设计分享、Hackathon 等等。
  3. 部门主管应当定期和成员进行一对一谈话,了解成员远期的职业规划、近期的目标、最近的工作状态和遇到的困难,并一起制定相应的计划来帮助成员解决问题和达成目标。

评价

部门负责对成员的专业能力水平进行评价,包括入职评估和每个季度的绩效评价。

三、研发组

研发组围绕产品的研发和推进来开展工作。从 2018 年第一个季度(三月)开始,我们将正式建立 Business、Core、Foundation、Explore 四个项目组。

Business

Business 组的研发主要由客户需求和商务成单驱动,重点关注的是学校想做、但希悦可以不做的业务。目前来看可能有三类需求:

  1. 学校管理需求,例如志愿调研、选排课、课程管理、行政班、评教、教务与教师权限、插件商店等。
  2. 商务驱动需求,例如电子班牌,和各类学校既存系统的对接、学校个性主页、希悦官网等。
  3. 运维服务需求,例如帮助与支持中心。

由于其中有一些需求是对特定学校个性化的支持,而非核心功能,可以用尽量低的成本解决。因此 Business 组需要根据情况采用灵活的解决方案,包括但不局限于自主研发、外包团队和接入第三方服务。开发人员方面优先考虑全栈工程师。

Core

Core 组的研发主要围绕学生的有效数据积累和应用这条主线,包含这三类功能:

  1. 学生基础数据来源,例如课程、考勤与请假、成绩与评价、社团与活动、各类问卷等。
  2. 学生数据的展示与应用,例如周报、日程表、个人主页、目标管理等。
  3. 基于学生数据的 To C 探索,随着这一类探索的深入,可以单独拆成一个组。

Core 组的产品设计需要结合用户反馈与数据分析来综合考虑学校需求与师生体验。开发人员方面优先考虑全栈工程师。

Foundation

Foundation 组是支撑希悦所有产品的地基,负责基础性的建设:

  1. 基础设施,为研发工作提供多层次的支撑,例如阿里云设施、前端组件库、DevOps、设计与开发规范等。
  2. 基础能力,供上层业务调用,例如用户与账号体系、用户关系、中心权限系统、通知与通讯能力、开放平台、问卷能力、跨校能力等。

Foundation 组的研发成果不直接面向用户,基础能力的“用户”是上层业务,基础设施的“用户”是研发人员。基础能力的需求由上层业务需求总结而来,而其优化和迭代主要由数据分析驱动。

Foundation 组的工作内容偏底层与架构,对技术能力要求较高,人员以资深的前端和后端工程师为主。也因此,Foundation 组负有协助其他研发组进行技术选型和架构设计的责任。

Explore

Explore 组将在 18 年间逐步成型。Explore 组由教育专家领衔,致力于和创新意识极强的学校一同探索和试验一些教育创新产品。这些产品面向未来,扎根于我们的教育理念和理想,而非当前市场需求。

需求分配

以上大致阐述了各组的业务目标与范围,但这些范围难免有交界和重叠。在实际操作中,我们会在这些定义的基础上考虑更多的现实因素,通过组与组之间的沟通去最终决定如何划分工作内容。

四、敏捷开发流程

希悦使用敏捷开发流程,该流程的模板请见:敏捷开发流程(各个研发组可能在该模板的基础上根据组内的实际情况有所调整)。为了兼顾团队能力和协作效率,每个研发组的人数应控制在 5 到 9 个人之间,其中通常包括一个产品经理、一个设计师、一个测试和多个工程师。根据实际情况会有所调整,比如增加产品助理、设计实习生或算法工程师。

五、需求管理流程

详见 需求管理流程图。

其中 简单需求 是对旧功能的一些比较简单明确的优化或补充,而 复杂需求 通常会提出一个全新的用户故事,需要研发新功能或者对旧功能做较大的调整,会影响甚至决定产品的走向。

在该流程中有两个关键会议:需求讨论会和方案评审会。

需求讨论会

每个月的第一个工作日召开需求讨论会,参会人员包括:

  1. 各研发组的产品经理
  2. CEO 和产品总监
  3. 设计总监和技术总监
  4. 市场总监和客户成功总监

会议目的是讨论和整理上一个月内出现的复杂需求。对于每一个需求:

  1. 参会者从各自的角度给该需求补充更多信息,包括其重要和紧急程度。
  2. 用户价值极低的需求将被拒绝。
  3. 有价值的需求将被协商分配至某一个研发组,再视该组本季度的 OKR 决定是否推迟到下个季度研发。

会后,产品经理整理将在本季度处理的需求到各自的 Backlog 进入后续的研发流程。

方案评审会

每周二下午四点召开方案评审会,参会人员与需求讨论会相同。

会议目的是:

  1. 再次确认需求。
  2. 及时发现和更正方案中的问题。
  3. 在产品方向上达成共识。

会前,产品经理需要提前一天发送参加评审的产品方案的相关资料,而参会者需要提前查看这些资料并做好问题备注,这些问题也可以提前通过邮件回复产品经理。

会上,每个方案先由产品经理进行讲解:

  1. 介绍该需求的背景、问题与目标。
  2. 陈述方案的基础逻辑和关键细节。
  3. 抛出存疑的和希望讨论的问题。

然后由听众进行提问和反馈。听众可以对需求本身进行补充,或以提问的形式指出潜在的问题,或提出改进方案的建议。PM 回答听众的提问会记录问题和反馈的要点。

会后,产品经理根据收集到的问题和反馈来完善方案。如果方案大改的话,需要重新参加方案评审会。

技术团队介绍

本文简要介绍希悦技术团队的相关的情况,包括指导原则,团队文化,以及新人入职流程计划,旨在让已经或即将加入希悦技术团队的小伙伴知道我们的工作理念和方式。

指导原则

希悦技术团队每个人的整体工作遵循如下三个核心原则:

宏观思考

站在更高的层面思考问题的本质,而不仅仅是解决眼前的问题,同时通过价值决策,确保个人价值、团队价值、公司价值的最大化。

技术驱动

崇尚通过技术让生活更美好,我们结合先进技术与客户需求为一体,让技术价值最大化。

追求极致

在宏观思考的基础上,不管是团队还是个人,以更高的标准要求自己,追求极致,探索本质,而不仅仅是完成工作

团队文化

分享与协作

我们(正在)设有内部技术WIKI,从技术规范,系统架构,最佳实践,团队协作等多个方面总结我们的经验,分享我们的成果,让团队达成共识。 同时通过团队协作,我们以最终实现用户价值为目标,倡导个人、团队、公司共同发展。

自下而上

在「透明开放」所有成员都能够获取全部信息的基础上,我们推崇自下而上的工作氛围。任何人都可以在遵循「指导原则」的基础上,提出并解决技术或团队上存在的问题,让整个团队良性发展,能够充分发挥个人价值。

代码 Review

为了保证优秀的代码风格和代码质量,传承优秀的技术基因,我们有代码 Review 机制,Reviewer 会从设计架构,代码风格,实现方式等多个层面进行 Review。

自动化测试

我们采用多维度的自动化测试保证代码和产品质量,通过自动化测试及时发现潜在问题,让我们能够得心应手的处理变化。

技术体系

基于我们的技术团队的指导原则和团队文化,我们正在着手构建完善的技术体系,旨在通过完善的技术体系,支撑快速的业务发展需要,下面是简要介绍。

平台化架构

整体上,我们采用平台化服务化的架构方向,通过合理的抽象,将后端业务进行标准化,服务化,最终构建统一的一体化的架构运维平台,为公司各产品线提供稳定的基础架构支撑。

关键词:微服务、Docker、HAPorxy、监控、自动化 、LNMP

基础支撑

为了提供我们的日常研发效率,我们也进行基础服务和支撑工具的研发。比如:

  1. 我们通过研发 UQL (Unified Query Language)来简化和规范业务中查询接口的编写
  2. 我们通过构建 全链路自动化测试体系 来统筹自动化测试,提高产品稳定性和测试效率,进而提高迭代效率
  3. 我们通过研发 SSR (Smart Sheet Renderer) 构建统一的数据导出服务,让任何符合规范的 API 都能方便导出数据。

关键词:基础服务、UQL、自动化测试,等等

前后端分离

我们采用前后端分离方式进行开发,后端提供 RESTful API,前端使用 Vue.js 等 MVVM 框架开发,前后端的职责更专注。

同时我们也将探索多端融合的技术,启动移动端 App 的相关工作。

关键词:RESTful API、Vue.js、MVVM、Hybrid App

数据平台

在研发业务开发的同时,我们也在搭建数据平台,通过数据平台,让数据说话,为业务和客户附能,为其提供管理和决策需要的数据支撑。

关键词:大数据,数据仓库,Python,可视化

业务开发

在整个技术体系的支撑下,业务不需要关注复杂的技术架构,只需专注业务,实现更加快速的业务迭代,满足用户需求,探索更多潜在机会。

关键词:敏捷、MVP,全栈

新手上路

对于新加入技术团队的同事,我们通过独立的流程确保其能够以最快的速度熟悉公司产品、协作流程和技术体系。

产品方面

  1. 学习希悦产品架构,宏观上对产品有基本了解
  2. 体验产品和阅读产品说明书,对产品各个模块功能有一定了解

团队协作

  1. 了解团队协作流程,
  2. 了解代码提交与 Review 流程
  3. 阅读并学习团队编码规范
  4. 阅读并学习团队 API 设计规范

技术体系

  1. 了解希悦技术体系,知道各个层面我们用到的技术
  2. 了解前后端技术架构,为开展工作提供基础

反馈环节

  1. 记录你遇到的问题,帮助团队不断完善整个流程
  2. 提出你的建议,推动团队团队技术建设

设计流程规范

设计工具

在希悦,我们使用 macOS 下的以下软件作为不同类型的设计生产工具:

用户界面:Sketch(唯一选项)

图标、插画:推荐顺序依次为 Sketch、 Adobe Illustrator、 Photoshop、或其他矢量/位图绘制软件。

平面设计:Adobe Illustrator(名片、邀请函、海报、背景板、展架), Adobe Indesign(手册、杂志)

演示文稿:Keynote ,如非必要情况,不使用 Powerpoint 进行演示文稿的制作。

动画效果:可根据自身情况选择 Principle、Adobe Effects、Keynote、HTML+CSS+JS

可交互原型:Adobe XD、Principle

核心设计原则

视觉设计:清爽细腻

在视觉设计层面,我们遵循清爽细腻的核心原则。在保证整体配色、布局清爽舒适的前提下,通过对控件、图标、插画、动效的细节处理,保证界面在观感上精致细腻。

交互设计:让用户偷懒

在交互设计层面,我们的核心原则是“让用户偷懒”。比如,为表单提供智能的默认填充项,在误删除后可以方便的撤回,用自然语言作为筛选条件而不是手动勾选。

产品设计:解决问题,而不是提供功能

在产品设计层面,我们以“解决问题,而不是提供功能”为核心原则。我们的产品在设计时应以简单高效的解决用户问题为出发点,而非单纯地从功能满足用户提出的需求。

工作流程

在希悦,产品经理与设计师分别进入各个项目组进行工作,我们的日常工作大致包含以下几个环节。

需求讨论

参见 研发体系 中的需求管理流程。

产品设计

在明确需求后,由产品经理设计某一功能的产品原型,这一过程中,有可能需要进行一次或多次用户调研。设计师与客户成功团队均需要一定程度的参与。

交互&视觉设计

由设计师进行交互&视觉设计,这一过程中,有可能会产出可点击高保真原型进行用户测试。

定期评审

除工作过程中的答疑指导外,设计总监每周会固定对已完成的设计图进行评审并形成反馈记录。每个大工作周期,会针对疑难问题组织产品设计讨论会。

调整修改

针对评审反馈或是实际上线后的客户反馈,对已有设计图、产品文档进行优化修改。

能力评定与晋升

每个月,我们会对设计师上个月的工作进行一次评价,评价内容包括:

工作效率

设计师对指定截止日期设计工作的完成效率,此处轻度超时、严重超时的评判以对他人工作的影响程度为准。

工作质量

对产品的理解

设计师能正确的理解产品和功能,做出与产品理念相符的优秀设计。如: 该项应与具体项目负责人与产品经理沟通后得出结论,设计总监/设计指导个人对产品的理解仅为对项目组/设计师的建议,不宜作为此项评价的参考。

对交互的把握

设计师能够基于对产品的理解,做出用户体验优秀的交互设计。如:页面间流转自然,页面内主次分明,层次划分合理、文案选择得当、用户操作后的反馈及时而有效。此项在评价时需参考产品经理的意见,如有不同意见应在说明中记录。

设计图质量

设计师产出的最终设计图符合质量要求,如:界面设计符合希悦成文的设计规范、与产品其他页面风格搭配和谐、符合公司的审美准则;插画、图标设计尺寸得当、配色美观、细节处理优雅。此项采用相对评价,以该设计师评级能够达到的水平作为标准预期进行评价。

基础工作质量

设计图文件命名合理、文件位置正确,文件内未出现非规范性的基本性错误。如:将对象/元素正确进行分组、界面设计中未对齐到像素、排版过于混乱、配色严重不和谐等。

每半年,会进行设计师的晋升评审,参考上述月度评审和个人晋升汇报进行设计师评级、薪酬的调整。

自我提升

希悦鼓励每位同事的自我提升,除个人努力外,在产品设计部,我们主要采用以下方式来帮助大家提升。

技能精进

每个月划分一部分工作时间,进行对专项能力提升有帮助的设计精进,如图标的打磨、插画的重绘、动效的调整、规范的补齐整理、Sketch文件的组件化重构等。

内部分享

由内部同事或是外部嘉宾进行产品设计相关的心得分享。

定期自查

定期组织对现有上线产品的设计、产品自查工作,反思问题并尝试给出优化方案。

会议指南

组织会议

1 什么会不用开?

有些单向传达信息的会不用开,可以用邮件替代,比如通知一件事情的最新进展。 即兴的简单讨论也不需要特意开会,几个人站一起几分钟就解决了。

2 什么时间开?

一天之中,人的精力从早到晚逐渐下降。需要思考与讨论的会议推荐安排在上午,核对进度与传达指令的会议安排在下午。 不要安排在“十分钟后“,给参会者留足准备的时间。

3 时长

越短越好。超过两个小时的会议考虑拆成多个。每开一个小时可以中场休息十分钟。

4 人数

开会人数尽量少,只邀请绝对必需的人,和强烈希望参与的人。除了效率低,人数过多的另一个问题是让很多人觉得自己不需要发言。 也要注意参会者岗位的多样性,不同岗位的同事可以提供不同的视角。

5 组织流程

  1. 在 Trello 的会议看板中复制会议模板,在合适的列表中建卡片并填写信息。
  2. 设定开会时间为卡片的截止日期。
  3. 上传或链接会前阅读材料。
  4. 在评论中 @ 所有参会者。
  5. 会前可以在评论中进行讨论。
  6. 会后上传或链接会议记录。

6 会前准备

会前准备是会议成败的关键。

6.1 议题

议题即会议要解决的问题,和要达成的目标。请在卡片中进行准确、全面的描述。

6.2 角色

每个参会者都有角色和定位,会议组织者需要在卡片中明确每个人的角色和相应的要求,方便大家有的放矢地进行准备。例如在需求讨论会中,除开大家各自对产品和需求的观点,工程师还要从技术实现的角度提供反馈,设计师要考虑交互体验,客户成功经理则代表用户的声音。

6.3 材料

会议组织者需要上传所有需要参会者在会前阅读和思考的材料,也请所有参会者在会前安排时间认真准备。大家都有备而来,会议才能更快结束。

7 卡片整理

添加会议卡片时请随手整理列表。

  1. 每个列表里按会议时间排序,最新的在最上面,创建后请拖动卡片到适当的位置。
  2. 每个列表最多放 8 张卡片,如果已满,请将最底下(最旧)的卡片归档。

进行会议

1 开场

  1. 开场第一件事是介绍本次会议的议题、目标和环节。
  2. 开场第二件事是推选记录人。记录人在石墨的会议记录中创建新文档(文档名称的格式为 YY.MM.DD 会议主旨)并负责记录会议中的问题、发言要点与结论。其他参会者也可以打开该文档实时查看和补充会议记录。

2 基本原则

开会有一些基本原则需要遵守。

2.1 不要走神

不要走神,不要窃窃私语,也不要让手机出现在桌面上。有重要电话请出会议室接。

2.2 有序发言

有序发言,不要打断别人说话。有必要的话,可以使用发言抱枕,拿着抱枕才能说话,说完传递给下一位。

2.3 都得说话

积极发表意见和想法。主持人要主动邀请沉默的人发表意见。可以视情况采取转圈轮流发言的方式。

2.4 就事论事

冷静客观,就事论事,不做恶意的揣测。

3 会议类型

下面就几种常见会议类型为例补充一些细节。

Again,无论哪种会议,充分的会前准备都是会议成功的关键。

3.1 头脑风暴

头脑风暴尤其要求参会者在会前进行充分的思考并形成自己的观点和想法。流程如下:

  1. 主持人简洁、明确地介绍要解决的问题,并回答大家的提问。
  2. 大家遵循以下原则进行发言:

    a. 自由发散:自由发挥,想到什么说什么。只提想法不考虑实现。

    b. 不要评论:自己说自己的,不要评论、更不能批评别人的想法。

    c. 不要跑题:紧扣主题,不要跑题。

    d. 只求数量:只求数量,不求质量。质量问题在会后解决。

  3. 会后还可以在卡片中评论碰撞后产生的新想法。
  4. 主持人将记录的想法整理和过滤之后(一至两天内),召集小会对候选方案进行讨论和决策。

3.2 展示与分享

  1. 协商是随时提问还是展示完一并提问(先把自己问题都记着)。

    a.推荐在展示后提问,或者由展示者将内容分段,每一段结束后接受提问。

    b.如果后面的内容非常依赖于对前面内容的理解,可以采取随时提问的方式。只提重要的、帮助自己理解的问题,意见建议都请放到展示后。

  2. 展示者进行展示,并回答大家的问题。
  3. 收集大家对于展示内容的反馈和意见,有需要可以追加头脑风暴或决策的环节。

3.3 讨论与决策

  1. 主持人介绍问题背景和可行选项,并回答大家的提问。
  2. 全场轮流发表观点,直到所有意见都发表完毕。
  3. 最后由相关负责人拍板,或者进行全体投票(负责人可以有多票)。

薪酬体系与股权激励

简介

公平和透明的薪酬机制有益于公司的长期健康发展。在制定公司薪酬制度时,我们重点考虑了以下问题: 

避免薪酬倒挂:我们将通过多种方法诊断薪资的公平性,有效评估职位价值,注重薪酬分配的基础,避免新员工工资因市场竞争水涨船高,老员工的薪水却没有相应增长的不公平现象。

消除薪酬谈判:我们认为,并非取决于工作能力和贡献的薪酬谈判,将在组织内部造成无必要的不公平。因此,我们给出的offer将完全取决于对候选人的独立评判,而非谈判技巧。

简单透明:作为一家精简的创业公司,我们力求用透明、自动化的机制尽可能地保证薪酬的公平。

月薪的计算 

每位同事的月薪由以下公式得出: 

薪酬 = 职业基准 × 能力评级 + 团队影响力 + 竞争力补偿 

职业基准

职业基准 是不同职位类型的月薪基数, 该基础将随公司的发展进行调整。当前各职位类型的基数如下: 

类型 职业基准
软件工程师 14,000
视觉设计师 8,000
产品经理 8,000
用户体验 8,000

以上是我们现有的职位类型,将来会根据需要增加新的类型。 

能力评级

能力评级(Ability)是不同的能力等级,纵向衡量员工完成自身工作的能力。Ability 所对应的数值如下表所示: 

基础设施与框架 业务开发 产品与体验 代码与文化
L0 初级工程师 不能熟练使用 需要指导 按设计实现有困难 代码可读性欠佳
L1 中级工程师 能熟练使用 能熟练完成常规业务 重视产品体验 代码可维护性强,遵循规范和最佳实践
L2 高级工程师 能设计和迭代小型基础设施 能设计并实现大型业务模块 对产品有独立思考 善于总结和分享工程经验与最佳实践
L3 技术专家 能设计和迭代大型基础设施 能规划并带领中小型项目的研发工作 有优秀的产品思维 对部门运作和人才培养有基本的思考
L4 高级专家 有全局视野,能做整体规划与设计 能规划并带领大型项目的研发工作 对市场和产品愿景有深刻的理解和洞见 对部门运作和人才培养有全局性的思考和洞见

每个级别之间还有两个小等级,比如 L1.1、L1.2

团队影响力

团队影响力(Impact)指在团队中的影响力和贡献,团队影响力横向衡量员工完成自身工作以外的能力,对应的数值如下图所示: 

等级 Impact 说明 举例(软件工程师)
I0 0 默认值 新加入的成员
I1 1,000 在完成自身工作以外,参与公司互动并带来积极影响 技术演讲、参与产品讨论、参与设计过程
I2 3,000 在完成自身工作以外,为公司带来业务、产品、文化创新 为公司的产品提出了新插件思路,并组织落实实现
I3 5,000 在完成自身工作以外,为公司带来业务、产品、文化创新,产生实际收益 为公司的设计了新的产品线,得到用户验证

竞争力补偿

竞争力补偿(Competition)是对新入职员工的补偿项,它衡量员工未来可能给公司带来的潜在价值。 

  • 该项的设计目的是
    • a. 补偿目前能力有限,但有较高发展潜力的新员工,例如无工作经验的本科毕业生。
    • b. 增加公司的薪酬竞争力。
  • Competition 的范围在 0 - 4000 内。
  • Competition 的应用于员工入职的第一年。

参数确认 

对于新加入的成员,Ability 和 Competition 会根据面试情况确定,Impact 为 I0。 在试用期结束后我们会重新评定各个指标,如果发现入职时评定过低我们会给予一定补偿。 对于在职的同事,会根据实际工作情况每年地 review 和调整这三个指标。 

期权设置 

工作超过一年半的员工都有机会申请获得公司的期权。在咨询公司法务并请教了行业内的投资相关人士后,我们发现期权有以下两个问题: 

  1. 在国内的法律环境内期权实际上是不受保护的
  2. 未上市之前,公司的期权实际上是没有流通性的

我们希望彻底解决以上两个问题,让公司的期权真正具有价值。幸运的是,公司盈利每年都有较快的增长,公司的实际资产状况良好,因此合伙团队决定,员工在获得期权的同时获得公司的财务报表,并可以在离职时由公司的自由资金进行兑换。考虑到工商部门的流程时长,我们会在期权批准的半年内,在工商层面注册以从法律层面上保护员工股权。 

奖金 

我们为每位在职员工发放年终奖金。年终奖的金额是浮动的,规则为:

年终奖 = 年终时候的薪水 × 个人绩效 × 公司绩效 

其中个人绩效为四季度绩效分的平均数(参见工作评价与反馈)。公司绩效由该年度公司是否达到预期目标来定。(详情参考公司内部文件:绩效考核与薪酬奖励的实施办法)。

结语 

以上的机制借鉴了 Leancloud 的 薪酬体系,具体的公式按照我们的情况做了调整, 希望每个人都能清楚自己薪酬的由来以及发展空间,也让潜在的应聘者一目了然地了解可能的薪酬范围。 

任何制度都会经历在实践中完善的过程,我们会根据反馈在发展中不断地完善这个薪酬体系。 

招聘制度

我们认为,好的招聘流程应当包含两个要素:一方面能筛选出合适的候选人,另一方面能让团队成员得到锻炼。好的面试体验应该让我们开拓见识,有所收获。 

第一步:简历筛选与补充 

目标:验证候选人的简历是否展示了他的优秀或潜力

实施者:HR与用人部门人员 

内容

  1. HR 对简历进行初步筛选。
  2. 用人部门主管进行二次筛选,确定是否发放面试通知。
  3. HR 进行电话联系,补充简历中缺失信息(例如入职时间、期望的薪酬)、预约面试时间,并获得入职背景调查的授权。
  4. HR 与其所在单位进行简历核实,补充主管评价——真诚、能力(效率)、责任心、团队合作。内推和外推人核实信息、补充推荐理由、核实期待薪酬,并预约面试时间。对于实习生或应届生等缺乏历史资料的候选人,可由相关岗位主管进行电话面试或远程笔试。

成果:制作基本信息包传递给有关部门进行面试准备 

第二步:专业能力面试 

目标:验证候选人在面试过程中是否展示出了优秀的专业能力(30分钟) 实施者:部门负责人及协作同事

内容:进行专业面试,同时必须有协作同事在场做为「观察者」。 观察者在需要时可以提问。必要时可以组织多轮面试。

成果:面试后10分钟撰写信息包,并汇总到HR处。 

第三步:(可选)下属或跨部门面试 

目标:验证候选人在面试过程中是否展示出了影响他人的能力(30分钟)

内容:带领团队的能力以及跨部门合作的能力

实施者:一位合作部门负责人与所有下属参与面试

成果:面试后10分钟内撰写信息包,传递给HR部门

第四步:CEO面试 

目标:验证候选人在面试过程中是否展示出良好的成长潜力(15分钟)

实施者:CEO

内容:入职期望,个人规划等

成果:独立作出判断,根据HR计算的推荐薪酬,并根据信息包在当天给出入职决策。

其他补充资料 

  1. 面试题库(详情见内部指南)
  2. HR管理信息包模板(详情请见伙伴云) HR应该为每一个人提供足够清晰的信息,以便快速决策。
  3. 信息包填写原则 大家应该记录面试者的客观表现(提炼),并撰写自己的评价。
  4. 内部与外部推荐申请表(详情请见伙伴云) 推荐人应当谨慎使用推荐权,认真思考推荐理由并填写必要的信息。
  5. HR组织工作反思 HR每个季度应对简历通过情况做反思整理。 HR每个季度应完成对薪酬计算的统计回归,并与相关部门人员开会讨论。 HR每个季度应根据绩效成果完成对推荐人、招聘委员人员的评估,并向CEO汇报。

放假与请假

公司目前采用业务组模式进行开发,因此在保证项目进度的前提下,我们允许各个项目小组灵活、个性化的分配工作时间,但考虑到目前的产品开发状态,现场协同工作是件非常重要的事情,因此我们在请假与放假上有一定的限制,这个制度也会随着公司发展更新迭代。

工作时间

为了减少大家在交通拥堵上耗费的时间以及缓解一定程度的睡眠压力,我们推荐的初始工作时间是周一至周五 10:00 AM - 19:00 PM,这期间包含 1 小时的午休时间,因为我们也不想你边打盹边敲代码。

请假

我们会尽可能满足每一个发起的请假需求,但所有请假需求都会根据公司的发展状况和项目进展的情况去考量,因此我们并不保证所有请假需求都会获得批准,希望大家理解。

平时请假

原则上公司不鼓励随意任性地因私请假,但我们相信,每一次的请假都是事出有因的。因此,除去因生病、婚丧、洪水、雷击等不可抗力因素导致的请假,如确有请假需求,请和所在项目组的负责人及同事友好商议,在不影响工作进度的前提下,尝试用弹性工作时间、调休或者远程办公等灵活机动的工作形式妥善安排自己的工作。

最后请在伙伴云表格的 请假申请表 中发起请假事项,并关联所在项目组负责人以及 HR 进行请假事项的审批和归档。

无论是何种请假,只要你无法在正常工作时间在岗,都请填写 请假申请表,以便公司了解你的动向,并在你需要的时候及时帮助到你。

带薪年假

根据《职工带薪年休假条例》,除国家规定的法定节假日外,累计工作满一年后,你有可供选择的7天带薪年假,年假的发起请根据公司项目进展情况有规划的和项目组负责人及同事商议安排,之后请告知部门负责人及其他可能会受到影响的同事。

最后请在伙伴云表格的 请假申请表 中发起年假申请事项,并关联项目组负责人以及HR进行年假事项的审批和归档。

公司也会根据项目进展情况统一安排年假。

工作评价与反馈

我们每个月会进行一次 一对一对谈,每个季度会进行一次 工作评价(performance review)。一对一对谈 的目的是提供一个反馈的机会,同时让主管更好地了解你。工作评价 的目的是对你近3个月内的工作表现进行一个评估,并与年终的薪酬奖励挂钩。 

一对一对谈 

每个成员都需要每个月与主管进行一对一的简短面谈,面谈内容可以包括个人发展规划、工作问题反馈等,主管应该确保每一次面谈都有记录。一对一对谈是私密的,并不公开给所有的人。 

工作反馈示例

  1. 公司在哪些方面给你提供更多资源或支持可以让你工作得更好?
  2. 对于你的主管或管理团队的工作有哪些反馈和建议?
  3. 对于团队建设、公司文化有哪些反馈和建议?

工作评价 

工作评价每个季度进行一次,包含以下三个方面。工作评价是完全公开的,每个人都可以看到其他人的全部评价。 

1 个人评价 

  1. 请列出过去一个季度你参与的工作、承担的职责、完成的具体内容。请尽可能地详尽。如果有在自己日常职责之外的贡献,也请单独列出。
  2. 针对以上列出的工作请给出对自己工作的评价,并总结具体原因。
  3. 针对上面的问题,有哪些地方有改进的空间?请列出在下个季度的具体改进计划。
  4. 给自己一个绩效分。绩效分数在 0.0 至 2.0 之间,其中 1.0 表示工作达到期望,低于 1.0 表示低于期望,高于 1.0 表示高于期望。这里的「期望」和每个人的职能、级别相关。

2 同伴评价 

所有同事都需要对其他人进行同伴评价。内容包括:

  1. 请列举你与该同事在过去一个季度里的协同工作情况:一起做了什么,完成哪些具体内容,有哪些可以改进的地方?没有可以写无。
  2. 该同事在过去一个季度里给你最大的帮助是什么?没有可以写无。
  3. 给该同事一个绩效分。

3 主管评价 

每个主管会为每位下属写主管评价和反馈,同时打出本季度的绩效得分。 

主管的绩效分由以下部分组成:

项目 占比 举例
个人能力 20% (个人角度)确实表现出与「高级软件工程师」相称的业务能力,例如……
工作成果 40% (公司角度)确实给公司带来了预期的收益,如果不是,原因是什么
工作以外的贡献 20% (公司角度)除工作外的对公司的正面影响,详细说明
个人成长 20% (个人角度)个人能力的微分