我们的研发体系是一个矩阵结构，分为 研发组 和 部门 两类组织。研发组专注产品的研发和维护，部门专注人员的培养和发展。概览如下：
| 技术部 | 产品设计部 | |
|---|---|---|
| 研发组1 | 工程师（产品、算法、测试） | 产品经理、设计师 |
| 研发组2 | 工程师（产品、算法、测试） | 产品经理、设计师 |
| ... |
部门在研发体系中主要指产品设计部和技术部，这两个部门围绕研发人员的招聘、培养和评价来开展工作。
结合研发组的需求，部门需要：
部门需要关注成员的职业规划和持续成长：
部门负责对成员的专业能力水平进行评价，包括入职评估和每个季度的绩效评价。
研发组围绕产品的研发和推进来开展工作。从 2018 年第一个季度（三月）开始，我们将正式建立 Business、Core、Foundation、Explore 四个项目组。
Business 组的研发主要由客户需求和商务成单驱动，重点关注的是学校想做、但希悦可以不做的业务。目前来看可能有三类需求：
由于其中有一些需求是对特定学校个性化的支持，而非核心功能，可以用尽量低的成本解决。因此 Business 组需要根据情况采用灵活的解决方案，包括但不局限于自主研发、外包团队和接入第三方服务。开发人员方面优先考虑全栈工程师。
Core 组的研发主要围绕学生的有效数据积累和应用这条主线，包含这三类功能：
Core 组的产品设计需要结合用户反馈与数据分析来综合考虑学校需求与师生体验。开发人员方面优先考虑全栈工程师。
Foundation 组是支撑希悦所有产品的地基，负责基础性的建设：
Foundation 组的研发成果不直接面向用户，基础能力的“用户”是上层业务，基础设施的“用户”是研发人员。基础能力的需求由上层业务需求总结而来，而其优化和迭代主要由数据分析驱动。
Foundation 组的工作内容偏底层与架构，对技术能力要求较高，人员以资深的前端和后端工程师为主。也因此，Foundation 组负有协助其他研发组进行技术选型和架构设计的责任。
Explore 组将在 18 年间逐步成型。Explore 组由教育专家领衔，致力于和创新意识极强的学校一同探索和试验一些教育创新产品。这些产品面向未来，扎根于我们的教育理念和理想，而非当前市场需求。
以上大致阐述了各组的业务目标与范围，但这些范围难免有交界和重叠。在实际操作中，我们会在这些定义的基础上考虑更多的现实因素，通过组与组之间的沟通去最终决定如何划分工作内容。
希悦使用敏捷开发流程，该流程的模板请见：敏捷开发流程（各个研发组可能在该模板的基础上根据组内的实际情况有所调整）。为了兼顾团队能力和协作效率，每个研发组的人数应控制在 5 到 9 个人之间，其中通常包括一个产品经理、一个设计师、一个测试和多个工程师。根据实际情况会有所调整，比如增加产品助理、设计实习生或算法工程师。
详见 需求管理流程图。
其中 简单需求 是对旧功能的一些比较简单明确的优化或补充，而 复杂需求 通常会提出一个全新的用户故事，需要研发新功能或者对旧功能做较大的调整，会影响甚至决定产品的走向。
在该流程中有两个关键会议：需求讨论会和方案评审会。
每个月的第一个工作日召开需求讨论会，参会人员包括：
会议目的是讨论和整理上一个月内出现的复杂需求。对于每一个需求：
会后，产品经理整理将在本季度处理的需求到各自的 Backlog 进入后续的研发流程。
每周二下午四点召开方案评审会，参会人员与需求讨论会相同。
会议目的是：
会前，产品经理需要提前一天发送参加评审的产品方案的相关资料，而参会者需要提前查看这些资料并做好问题备注，这些问题也可以提前通过邮件回复产品经理。
会上，每个方案先由产品经理进行讲解：
然后由听众进行提问和反馈。听众可以对需求本身进行补充，或以提问的形式指出潜在的问题，或提出改进方案的建议。PM 回答听众的提问会记录问题和反馈的要点。
会后，产品经理根据收集到的问题和反馈来完善方案。如果方案大改的话，需要重新参加方案评审会。
本文简要介绍希悦技术团队的相关的情况，包括指导原则，团队文化，以及新人入职流程计划，旨在让已经或即将加入希悦技术团队的小伙伴知道我们的工作理念和方式。
希悦技术团队每个人的整体工作遵循如下三个核心原则：
站在更高的层面思考问题的本质，而不仅仅是解决眼前的问题，同时通过价值决策，确保个人价值、团队价值、公司价值的最大化。
崇尚通过技术让生活更美好，我们结合先进技术与客户需求为一体，让技术价值最大化。
在宏观思考的基础上，不管是团队还是个人，以更高的标准要求自己，追求极致，探索本质，而不仅仅是完成工作
我们（正在）设有内部技术WIKI，从技术规范，系统架构，最佳实践，团队协作等多个方面总结我们的经验，分享我们的成果，让团队达成共识。 同时通过团队协作，我们以最终实现用户价值为目标，倡导个人、团队、公司共同发展。
在「透明开放」所有成员都能够获取全部信息的基础上，我们推崇自下而上的工作氛围。任何人都可以在遵循「指导原则」的基础上，提出并解决技术或团队上存在的问题，让整个团队良性发展，能够充分发挥个人价值。
为了保证优秀的代码风格和代码质量，传承优秀的技术基因，我们有代码 Review 机制，Reviewer 会从设计架构，代码风格，实现方式等多个层面进行 Review。
我们采用多维度的自动化测试保证代码和产品质量，通过自动化测试及时发现潜在问题，让我们能够得心应手的处理变化。
基于我们的技术团队的指导原则和团队文化，我们正在着手构建完善的技术体系，旨在通过完善的技术体系，支撑快速的业务发展需要，下面是简要介绍。
整体上，我们采用平台化服务化的架构方向，通过合理的抽象，将后端业务进行标准化，服务化，最终构建统一的一体化的架构运维平台，为公司各产品线提供稳定的基础架构支撑。
关键词：微服务、Docker、HAPorxy、监控、自动化 、LNMP
为了提供我们的日常研发效率，我们也进行基础服务和支撑工具的研发。比如：
关键词：基础服务、UQL、自动化测试，等等
我们采用前后端分离方式进行开发，后端提供 RESTful API，前端使用 Vue.js 等 MVVM 框架开发，前后端的职责更专注。
同时我们也将探索多端融合的技术，启动移动端 App 的相关工作。
关键词：RESTful API、Vue.js、MVVM、Hybrid App
在研发业务开发的同时，我们也在搭建数据平台，通过数据平台，让数据说话，为业务和客户附能，为其提供管理和决策需要的数据支撑。
关键词：大数据，数据仓库，Python，可视化
在整个技术体系的支撑下，业务不需要关注复杂的技术架构，只需专注业务，实现更加快速的业务迭代，满足用户需求，探索更多潜在机会。
关键词：敏捷、MVP，全栈
对于新加入技术团队的同事，我们通过独立的流程确保其能够以最快的速度熟悉公司产品、协作流程和技术体系。
在希悦，我们使用 macOS 下的以下软件作为不同类型的设计生产工具：
用户界面：Sketch（唯一选项）
图标、插画：推荐顺序依次为 Sketch、 Adobe Illustrator、 Photoshop、或其他矢量/位图绘制软件。
平面设计：Adobe Illustrator（名片、邀请函、海报、背景板、展架）， Adobe Indesign（手册、杂志）
演示文稿：Keynote ，如非必要情况，不使用 Powerpoint 进行演示文稿的制作。
动画效果：可根据自身情况选择 Principle、Adobe Effects、Keynote、HTML+CSS+JS
可交互原型：Adobe XD、Principle
在视觉设计层面，我们遵循清爽细腻的核心原则。在保证整体配色、布局清爽舒适的前提下，通过对控件、图标、插画、动效的细节处理，保证界面在观感上精致细腻。
在交互设计层面，我们的核心原则是“让用户偷懒”。比如，为表单提供智能的默认填充项，在误删除后可以方便的撤回，用自然语言作为筛选条件而不是手动勾选。
在产品设计层面，我们以“解决问题，而不是提供功能”为核心原则。我们的产品在设计时应以简单高效的解决用户问题为出发点，而非单纯地从功能满足用户提出的需求。
在希悦，产品经理与设计师分别进入各个项目组进行工作，我们的日常工作大致包含以下几个环节。
参见 研发体系 中的需求管理流程。
在明确需求后，由产品经理设计某一功能的产品原型，这一过程中，有可能需要进行一次或多次用户调研。设计师与客户成功团队均需要一定程度的参与。
由设计师进行交互&视觉设计，这一过程中，有可能会产出可点击高保真原型进行用户测试。
除工作过程中的答疑指导外，设计总监每周会固定对已完成的设计图进行评审并形成反馈记录。每个大工作周期，会针对疑难问题组织产品设计讨论会。
针对评审反馈或是实际上线后的客户反馈，对已有设计图、产品文档进行优化修改。
每个月，我们会对设计师上个月的工作进行一次评价，评价内容包括：
设计师对指定截止日期设计工作的完成效率，此处轻度超时、严重超时的评判以对他人工作的影响程度为准。
设计师能正确的理解产品和功能，做出与产品理念相符的优秀设计。如： 该项应与具体项目负责人与产品经理沟通后得出结论，设计总监/设计指导个人对产品的理解仅为对项目组/设计师的建议，不宜作为此项评价的参考。
设计师能够基于对产品的理解，做出用户体验优秀的交互设计。如：页面间流转自然，页面内主次分明，层次划分合理、文案选择得当、用户操作后的反馈及时而有效。此项在评价时需参考产品经理的意见，如有不同意见应在说明中记录。
设计师产出的最终设计图符合质量要求，如：界面设计符合希悦成文的设计规范、与产品其他页面风格搭配和谐、符合公司的审美准则；插画、图标设计尺寸得当、配色美观、细节处理优雅。此项采用相对评价，以该设计师评级能够达到的水平作为标准预期进行评价。
设计图文件命名合理、文件位置正确，文件内未出现非规范性的基本性错误。如：将对象/元素正确进行分组、界面设计中未对齐到像素、排版过于混乱、配色严重不和谐等。
每半年，会进行设计师的晋升评审，参考上述月度评审和个人晋升汇报进行设计师评级、薪酬的调整。
希悦鼓励每位同事的自我提升，除个人努力外，在产品设计部，我们主要采用以下方式来帮助大家提升。
每个月划分一部分工作时间，进行对专项能力提升有帮助的设计精进，如图标的打磨、插画的重绘、动效的调整、规范的补齐整理、Sketch文件的组件化重构等。
由内部同事或是外部嘉宾进行产品设计相关的心得分享。
定期组织对现有上线产品的设计、产品自查工作，反思问题并尝试给出优化方案。
有些单向传达信息的会不用开，可以用邮件替代，比如通知一件事情的最新进展。 即兴的简单讨论也不需要特意开会，几个人站一起几分钟就解决了。
一天之中，人的精力从早到晚逐渐下降。需要思考与讨论的会议推荐安排在上午，核对进度与传达指令的会议安排在下午。 不要安排在“十分钟后“，给参会者留足准备的时间。
越短越好。超过两个小时的会议考虑拆成多个。每开一个小时可以中场休息十分钟。
开会人数尽量少，只邀请绝对必需的人，和强烈希望参与的人。除了效率低，人数过多的另一个问题是让很多人觉得自己不需要发言。 也要注意参会者岗位的多样性，不同岗位的同事可以提供不同的视角。
会前准备是会议成败的关键。
议题即会议要解决的问题，和要达成的目标。请在卡片中进行准确、全面的描述。
每个参会者都有角色和定位，会议组织者需要在卡片中明确每个人的角色和相应的要求，方便大家有的放矢地进行准备。例如在需求讨论会中，除开大家各自对产品和需求的观点，工程师还要从技术实现的角度提供反馈，设计师要考虑交互体验，客户成功经理则代表用户的声音。
会议组织者需要上传所有需要参会者在会前阅读和思考的材料，也请所有参会者在会前安排时间认真准备。大家都有备而来，会议才能更快结束。
添加会议卡片时请随手整理列表。
开会有一些基本原则需要遵守。
不要走神，不要窃窃私语，也不要让手机出现在桌面上。有重要电话请出会议室接。
有序发言，不要打断别人说话。有必要的话，可以使用发言抱枕，拿着抱枕才能说话，说完传递给下一位。
积极发表意见和想法。主持人要主动邀请沉默的人发表意见。可以视情况采取转圈轮流发言的方式。
冷静客观，就事论事，不做恶意的揣测。
下面就几种常见会议类型为例补充一些细节。
Again，无论哪种会议，充分的会前准备都是会议成功的关键。
头脑风暴尤其要求参会者在会前进行充分的思考并形成自己的观点和想法。流程如下：
大家遵循以下原则进行发言：
a. 自由发散：自由发挥，想到什么说什么。只提想法不考虑实现。
b. 不要评论：自己说自己的，不要评论、更不能批评别人的想法。
c. 不要跑题：紧扣主题，不要跑题。
d. 只求数量：只求数量，不求质量。质量问题在会后解决。
协商是随时提问还是展示完一并提问（先把自己问题都记着）。
a.推荐在展示后提问，或者由展示者将内容分段，每一段结束后接受提问。
b.如果后面的内容非常依赖于对前面内容的理解，可以采取随时提问的方式。只提重要的、帮助自己理解的问题，意见建议都请放到展示后。
公平和透明的薪酬机制有益于公司的长期健康发展。在制定公司薪酬制度时，我们重点考虑了以下问题：
避免薪酬倒挂：我们将通过多种方法诊断薪资的公平性，有效评估职位价值，注重薪酬分配的基础，避免新员工工资因市场竞争水涨船高，老员工的薪水却没有相应增长的不公平现象。
消除薪酬谈判：我们认为，并非取决于工作能力和贡献的薪酬谈判，将在组织内部造成无必要的不公平。因此，我们给出的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）是对新入职员工的补偿项，它衡量员工未来可能给公司带来的潜在价值。
对于新加入的成员，Ability 和 Competition 会根据面试情况确定，Impact 为 I0。 在试用期结束后我们会重新评定各个指标，如果发现入职时评定过低我们会给予一定补偿。 对于在职的同事，会根据实际工作情况每年地 review 和调整这三个指标。
工作超过一年半的员工都有机会申请获得公司的期权。在咨询公司法务并请教了行业内的投资相关人士后，我们发现期权有以下两个问题：
我们希望彻底解决以上两个问题，让公司的期权真正具有价值。幸运的是，公司盈利每年都有较快的增长，公司的实际资产状况良好，因此合伙团队决定，员工在获得期权的同时获得公司的财务报表，并可以在离职时由公司的自由资金进行兑换。考虑到工商部门的流程时长，我们会在期权批准的半年内，在工商层面注册以从法律层面上保护员工股权。
我们为每位在职员工发放年终奖金。年终奖的金额是浮动的，规则为：
年终奖 = 年终时候的薪水 × 个人绩效 × 公司绩效
其中个人绩效为四季度绩效分的平均数（参见工作评价与反馈）。公司绩效由该年度公司是否达到预期目标来定。（详情参考公司内部文件：绩效考核与薪酬奖励的实施办法）。
以上的机制借鉴了 Leancloud 的 薪酬体系，具体的公式按照我们的情况做了调整， 希望每个人都能清楚自己薪酬的由来以及发展空间，也让潜在的应聘者一目了然地了解可能的薪酬范围。
任何制度都会经历在实践中完善的过程，我们会根据反馈在发展中不断地完善这个薪酬体系。
我们认为，好的招聘流程应当包含两个要素：一方面能筛选出合适的候选人，另一方面能让团队成员得到锻炼。好的面试体验应该让我们开拓见识，有所收获。
目标：验证候选人的简历是否展示了他的优秀或潜力
实施者：HR与用人部门人员
内容：
成果：制作基本信息包传递给有关部门进行面试准备
目标：验证候选人在面试过程中是否展示出了优秀的专业能力（30分钟） 实施者：部门负责人及协作同事
内容：进行专业面试，同时必须有协作同事在场做为「观察者」。 观察者在需要时可以提问。必要时可以组织多轮面试。
成果：面试后10分钟撰写信息包，并汇总到HR处。
目标：验证候选人在面试过程中是否展示出了影响他人的能力（30分钟）
内容：带领团队的能力以及跨部门合作的能力
实施者：一位合作部门负责人与所有下属参与面试
成果：面试后10分钟内撰写信息包，传递给HR部门
目标：验证候选人在面试过程中是否展示出良好的成长潜力（15分钟）
实施者：CEO
内容：入职期望，个人规划等
成果：独立作出判断，根据HR计算的推荐薪酬，并根据信息包在当天给出入职决策。
公司目前采用业务组模式进行开发，因此在保证项目进度的前提下，我们允许各个项目小组灵活、个性化的分配工作时间，但考虑到目前的产品开发状态，现场协同工作是件非常重要的事情，因此我们在请假与放假上有一定的限制，这个制度也会随着公司发展更新迭代。
为了减少大家在交通拥堵上耗费的时间以及缓解一定程度的睡眠压力，我们推荐的初始工作时间是周一至周五 10:00 AM - 19:00 PM，这期间包含 1 小时的午休时间，因为我们也不想你边打盹边敲代码。
我们会尽可能满足每一个发起的请假需求，但所有请假需求都会根据公司的发展状况和项目进展的情况去考量，因此我们并不保证所有请假需求都会获得批准，希望大家理解。
原则上公司不鼓励随意任性地因私请假，但我们相信，每一次的请假都是事出有因的。因此，除去因生病、婚丧、洪水、雷击等不可抗力因素导致的请假，如确有请假需求，请和所在项目组的负责人及同事友好商议，在不影响工作进度的前提下，尝试用弹性工作时间、调休或者远程办公等灵活机动的工作形式妥善安排自己的工作。
最后请在伙伴云表格的 请假申请表 中发起请假事项，并关联所在项目组负责人以及 HR 进行请假事项的审批和归档。
无论是何种请假，只要你无法在正常工作时间在岗，都请填写 请假申请表，以便公司了解你的动向，并在你需要的时候及时帮助到你。
根据《职工带薪年休假条例》，除国家规定的法定节假日外，累计工作满一年后，你有可供选择的7天带薪年假，年假的发起请根据公司项目进展情况有规划的和项目组负责人及同事商议安排，之后请告知部门负责人及其他可能会受到影响的同事。
最后请在伙伴云表格的 请假申请表 中发起年假申请事项，并关联项目组负责人以及HR进行年假事项的审批和归档。
公司也会根据项目进展情况统一安排年假。
我们每个月会进行一次 一对一对谈，每个季度会进行一次 工作评价（performance review）。一对一对谈 的目的是提供一个反馈的机会，同时让主管更好地了解你。工作评价 的目的是对你近3个月内的工作表现进行一个评估，并与年终的薪酬奖励挂钩。
每个成员都需要每个月与主管进行一对一的简短面谈，面谈内容可以包括个人发展规划、工作问题反馈等，主管应该确保每一次面谈都有记录。一对一对谈是私密的，并不公开给所有的人。
工作评价每个季度进行一次，包含以下三个方面。工作评价是完全公开的，每个人都可以看到其他人的全部评价。
所有同事都需要对其他人进行同伴评价。内容包括：
每个主管会为每位下属写主管评价和反馈，同时打出本季度的绩效得分。
主管的绩效分由以下部分组成：
| 项目 | 占比 | 举例 |
|---|---|---|
| 个人能力 | 20% | （个人角度）确实表现出与「高级软件工程师」相称的业务能力，例如…… |
| 工作成果 | 40% | （公司角度）确实给公司带来了预期的收益，如果不是，原因是什么 |
| 工作以外的贡献 | 20% | （公司角度）除工作外的对公司的正面影响，详细说明 |
| 个人成长 | 20% | （个人角度）个人能力的微分 |
