我們的研發體系是一個矩陣結構，分(fēn)爲 研發組 和 部門(mén) 兩類組織。研發組專注産品的研發和維護，部門(mén)專注人員(yuán)的培養和發展。概覽如(rú)下：
| 技術(shù)部 | 産品設計(jì)部 | |
|---|---|---|
| 研發組1 | 工程師(shī)（産品、算法、測試） | 産品經理、設計(jì)師(shī) |
| 研發組2 | 工程師(shī)（産品、算法、測試） | 産品經理、設計(jì)師(shī) |
| ... |
部門(mén)在研發體系中主要指産品設計(jì)部和技術(shù)部，這兩個部門(mén)圍繞研發人員(yuán)的招聘、培養和評價來(lái)開展工作。
結合研發組的需求，部門(mén)需要：
部門(mén)需要關注成員(yuán)的職業規劃和持續成長：
部門(mén)負責對成員(yuán)的專業能力水平進行評價，包括入職評估和每個季度的績效評價。
研發組圍繞産品的研發和推進來(lái)開展工作。從(cóng) 2018 年(nián)第一個季度（三月）開始，我們将正式建立 Business、Core、Foundation、Explore 四個項目組。
Business 組的研發主要由客戶需求和商務成單驅動，重點關注的是學校想做、但(dàn)希悅可以不做的業務。目前來(lái)看(kàn)可能有三類需求：
由于其中有一些需求是對特定學校個性化的支持，而非核心功能，可以用盡量低的成本解決。因此 Business 組需要根據情況采用靈活的解決方案，包括但(dàn)不局限于自主研發、外包團隊和接入第三方服務。開發人員(yuán)方面優先考慮全棧工程師(shī)。
Core 組的研發主要圍繞學生的有效數據積累和應用這條主線，包含這三類功能：
Core 組的産品設計(jì)需要結合用戶反饋與數據分(fēn)析來(lái)綜合考慮學校需求與師(shī)生體驗。開發人員(yuán)方面優先考慮全棧工程師(shī)。
Foundation 組是支撐希悅所有産品的地基，負責基礎性的建設：
Foundation 組的研發成果不直接面向用戶，基礎能力的“用戶”是上層業務，基礎設施的“用戶”是研發人員(yuán)。基礎能力的需求由上層業務需求總結而來(lái)，而其優化和叠代主要由數據分(fēn)析驅動。
Foundation 組的工作内容偏底層與架構，對技術(shù)能力要求較高，人員(yuán)以資深的前端和後端工程師(shī)爲主。也因此，Foundation 組負有協助其他(tā)研發組進行技術(shù)選型和架構設計(jì)的責任。
Explore 組将在 18 年(nián)間逐步成型。Explore 組由教育專家領銜，緻力于和創新意識極強的學校一同探索和試驗一些教育創新産品。這些産品面向未來(lái)，紮根于我們的教育理念和理想，而非當前市場需求。
以上大(dà)緻闡述了各組的業務目标與範圍，但(dàn)這些範圍難免有交界和重疊。在實際操作中，我們會在這些定義的基礎上考慮更多的現實因素，通過組與組之間的溝通去(qù)最終決定如(rú)何劃分(fēn)工作内容。
希悅使用敏捷開發流程，該流程的模闆請(qǐng)見(jiàn)：敏捷開發流程（各個研發組可能在該模闆的基礎上根據組内的實際情況有所調整）。爲了兼顧團隊能力和協作效率，每個研發組的人數應控制在 5 到 9 個人之間，其中通常包括一個産品經理、一個設計(jì)師(shī)、一個測試和多個工程師(shī)。根據實際情況會有所調整，比如(rú)增加産品助理、設計(jì)實習生或算法工程師(shī)。
詳見(jiàn) 需求管理流程圖。
其中 簡單需求 是對舊功能的一些比較簡單明确的優化或補充，而 複雜需求 通常會提出一個全新的用戶故事(shì)，需要研發新功能或者對舊功能做較大(dà)的調整，會影(yǐng)響甚至決定産品的走向。
在該流程中有兩個關鍵會議(yì)：需求討(tǎo)論會和方案評審會。
每個月的第一個工作日(rì)召開需求討(tǎo)論會，參會人員(yuán)包括：
會議(yì)目的是討(tǎo)論和整理上一個月内出現的複雜需求。對于每一個需求：
會後，産品經理整理将在本季度處理的需求到各自的 Backlog 進入後續的研發流程。
每周二下午四點召開方案評審會，參會人員(yuán)與需求討(tǎo)論會相(xiàng)同。
會議(yì)目的是：
會前，産品經理需要提前一天發送參加評審的産品方案的相(xiàng)關資料，而參會者需要提前查看(kàn)這些資料并做好問(wèn)題備注，這些問(wèn)題也可以提前通過郵件(jiàn)回複産品經理。
會上，每個方案先由産品經理進行講解：
然後由聽衆進行提問(wèn)和反饋。聽衆可以對需求本身(shēn)進行補充，或以提問(wèn)的形式指出潛在的問(wèn)題，或提出改進方案的建議(yì)。PM 回答聽衆的提問(wèn)會記錄問(wèn)題和反饋的要點。
會後，産品經理根據收集到的問(wèn)題和反饋來(lái)完善方案。如(rú)果方案大(dà)改的話(huà)，需要重新參加方案評審會。
本文簡要介紹希悅技術(shù)團隊的相(xiàng)關的情況，包括指導原則，團隊文化，以及新人入職流程計(jì)劃，旨在讓已經或即将加入希悅技術(shù)團隊的小夥伴知道我們的工作理念和方式。
希悅技術(shù)團隊每個人的整體工作遵循如(rú)下三個核心原則：
站(zhàn)在更高的層面思考問(wèn)題的本質，而不僅僅是解決眼前的問(wèn)題，同時通過價值決策，确保個人價值、團隊價值、公司價值的最大(dà)化。
崇尚通過技術(shù)讓生活更美好，我們結合先進技術(shù)與客戶需求爲一體，讓技術(shù)價值最大(dà)化。
在宏觀思考的基礎上，不管是團隊還(hái)是個人，以更高的标準要求自己，追求極緻，探索本質，而不僅僅是完成工作
我們（正在）設有内部技術(shù)WIKI，從(cóng)技術(shù)規範，系統架構，最佳實踐，團隊協作等多個方面總結我們的經驗，分(fēn)享我們的成果，讓團隊達成共識。 同時通過團隊協作，我們以最終實現用戶價值爲目标，倡導個人、團隊、公司共同發展。
在「透明開放(fàng)」所有成員(yuán)都(dōu)能夠獲取全部信息的基礎上，我們推崇自下而上的工作氛圍。任何人都(dōu)可以在遵循「指導原則」的基礎上，提出并解決技術(shù)或團隊上存在的問(wèn)題，讓整個團隊良性發展，能夠充分(fēn)發揮個人價值。
爲了保證優秀的代碼風(fēng)格和代碼質量，傳承優秀的技術(shù)基因，我們有代碼 Review 機(jī)制，Reviewer 會從(cóng)設計(jì)架構，代碼風(fēng)格，實現方式等多個層面進行 Review。
我們采用多維度的自動化測試保證代碼和産品質量，通過自動化測試及時發現潛在問(wèn)題，讓我們能夠得心應手的處理變化。
基于我們的技術(shù)團隊的指導原則和團隊文化，我們正在着手構建完善的技術(shù)體系，旨在通過完善的技術(shù)體系，支撐快(kuài)速的業務發展需要，下面是簡要介紹。
整體上，我們采用平台化服務化的架構方向，通過合理的抽象，将後端業務進行标準化，服務化，最終構建統一的一體化的架構運維平台，爲公司各産品線提供穩定的基礎架構支撐。
關鍵詞：微服務、Docker、HAPorxy、監控、自動化 、LNMP
爲了提供我們的日(rì)常研發效率，我們也進行基礎服務和支撐工具的研發。比如(rú)：
關鍵詞：基礎服務、UQL、自動化測試，等等
我們采用前後端分(fēn)離(lí)方式進行開發，後端提供 RESTful API，前端使用 Vue.js 等 MVVM 框架開發，前後端的職責更專注。
同時我們也将探索多端融合的技術(shù)，啓動移動端 App 的相(xiàng)關工作。
關鍵詞：RESTful API、Vue.js、MVVM、Hybrid App
在研發業務開發的同時，我們也在搭建數據平台，通過數據平台，讓數據說(shuō)話(huà)，爲業務和客戶附能，爲其提供管理和決策需要的數據支撐。
關鍵詞：大(dà)數據，數據倉庫，Python，可視化
在整個技術(shù)體系的支撐下，業務不需要關注複雜的技術(shù)架構，隻需專注業務，實現更加快(kuài)速的業務叠代，滿足用戶需求，探索更多潛在機(jī)會。
關鍵詞：敏捷、MVP，全棧
對于新加入技術(shù)團隊的同事(shì)，我們通過獨立的流程确保其能夠以最快(kuài)的速度熟悉公司産品、協作流程和技術(shù)體系。
在希悅，我們使用 macOS 下的以下軟件(jiàn)作爲不同類型的設計(jì)生産工具：
用戶界面：Sketch（唯一選項）
圖标、插畫(huà)：推薦順序依次爲 Sketch、 Adobe Illustrator、 Photoshop、或其他(tā)矢量/位圖繪制軟件(jiàn)。
平面設計(jì)：Adobe Illustrator（名片、邀請(qǐng)函、海報、背景闆、展架）， Adobe Indesign（手冊、雜志）
演示文稿：Keynote ，如(rú)非必要情況，不使用 Powerpoint 進行演示文稿的制作。
動畫(huà)效果：可根據自身(shēn)情況選擇 Principle、Adobe Effects、Keynote、HTML+CSS+JS
可交互原型：Adobe XD、Principle
在視覺設計(jì)層面，我們遵循清爽細膩的核心原則。在保證整體配色、布局清爽舒适的前提下，通過對控件(jiàn)、圖标、插畫(huà)、動效的細節處理，保證界面在觀感上精緻細膩。
在交互設計(jì)層面，我們的核心原則是“讓用戶偷懶”。比如(rú)，爲表單提供智能的默認填充項，在誤删除後可以方便的撤回，用自然語言作爲篩選條件(jiàn)而不是手動勾選。
在産品設計(jì)層面，我們以“解決問(wèn)題，而不是提供功能”爲核心原則。我們的産品在設計(jì)時應以簡單高效的解決用戶問(wèn)題爲出發點，而非單純地從(cóng)功能滿足用戶提出的需求。
在希悅，産品經理與設計(jì)師(shī)分(fēn)别進入各個項目組進行工作，我們的日(rì)常工作大(dà)緻包含以下幾個環節。
參見(jiàn) 研發體系 中的需求管理流程。
在明确需求後，由産品經理設計(jì)某一功能的産品原型，這一過程中，有可能需要進行一次或多次用戶調研。設計(jì)師(shī)與客戶成功團隊均需要一定程度的參與。
由設計(jì)師(shī)進行交互&視覺設計(jì)，這一過程中，有可能會産出可點擊高保真原型進行用戶測試。
除工作過程中的答疑指導外，設計(jì)總監每周會固定對已完成的設計(jì)圖進行評審并形成反饋記錄。每個大(dà)工作周期，會針對疑難問(wèn)題組織産品設計(jì)討(tǎo)論會。
針對評審反饋或是實際上線後的客戶反饋，對已有設計(jì)圖、産品文檔進行優化修改。
每個月，我們會對設計(jì)師(shī)上個月的工作進行一次評價，評價内容包括：
設計(jì)師(shī)對指定截止日(rì)期設計(jì)工作的完成效率，此處輕度超時、嚴重超時的評判以對他(tā)人工作的影(yǐng)響程度爲準。
設計(jì)師(shī)能正确的理解産品和功能，做出與産品理念相(xiàng)符的優秀設計(jì)。如(rú)： 該項應與具體項目負責人與産品經理溝通後得出結論，設計(jì)總監/設計(jì)指導個人對産品的理解僅爲對項目組/設計(jì)師(shī)的建議(yì)，不宜作爲此項評價的參考。
設計(jì)師(shī)能夠基于對産品的理解，做出用戶體驗優秀的交互設計(jì)。如(rú)：頁面間流轉自然，頁面内主次分(fēn)明，層次劃分(fēn)合理、文案選擇得當、用戶操作後的反饋及時而有效。此項在評價時需參考産品經理的意見(jiàn)，如(rú)有不同意見(jiàn)應在說(shuō)明中記錄。
設計(jì)師(shī)産出的最終設計(jì)圖符合質量要求，如(rú)：界面設計(jì)符合希悅成文的設計(jì)規範、與産品其他(tā)頁面風(fēng)格搭配和諧、符合公司的審美準則；插畫(huà)、圖标設計(jì)尺寸得當、配色美觀、細節處理優雅。此項采用相(xiàng)對評價，以該設計(jì)師(shī)評級能夠達到的水平作爲标準預期進行評價。
設計(jì)圖文件(jiàn)命名合理、文件(jiàn)位置正确，文件(jiàn)内未出現非規範性的基本性錯誤。如(rú)：将對象/元素正确進行分(fēn)組、界面設計(jì)中未對齊到像素、排版過于混亂、配色嚴重不和諧等。
每半年(nián)，會進行設計(jì)師(shī)的晉升評審，參考上述月度評審和個人晉升彙報進行設計(jì)師(shī)評級、薪酬的調整。
希悅鼓勵每位同事(shì)的自我提升，除個人努力外，在産品設計(jì)部，我們主要采用以下方式來(lái)幫助大(dà)家提升。
每個月劃分(fēn)一部分(fēn)工作時間，進行對專項能力提升有幫助的設計(jì)精進，如(rú)圖标的打磨、插畫(huà)的重繪、動效的調整、規範的補齊整理、Sketch文件(jiàn)的組件(jiàn)化重構等。
由内部同事(shì)或是外部嘉賓進行産品設計(jì)相(xiàng)關的心得分(fēn)享。
定期組織對現有上線産品的設計(jì)、産品自查工作，反思問(wèn)題并嘗試給出優化方案。
有些單向傳達信息的會不用開，可以用郵件(jiàn)替代，比如(rú)通知一件(jiàn)事(shì)情的最新進展。 即興的簡單討(tǎo)論也不需要特意開會，幾個人站(zhàn)一起幾分(fēn)鍾就(jiù)解決了。
一天之中，人的精力從(cóng)早到晚逐漸下降。需要思考與討(tǎo)論的會議(yì)推薦安排在上午，核對進度與傳達指令的會議(yì)安排在下午。 不要安排在“十分(fēn)鍾後“，給參會者留足準備的時間。
越短越好。超過兩個小時的會議(yì)考慮拆成多個。每開一個小時可以中場休息十分(fēn)鍾。
開會人數盡量少，隻邀請(qǐng)絕對必需的人，和強烈希望參與的人。除了效率低，人數過多的另一個問(wèn)題是讓很多人覺得自己不需要發言。 也要注意參會者崗位的多樣性，不同崗位的同事(shì)可以提供不同的視角。
會前準備是會議(yì)成敗的關鍵。
議(yì)題即會議(yì)要解決的問(wèn)題，和要達成的目标。請(qǐng)在卡片中進行準确、全面的描述。
每個參會者都(dōu)有角色和定位，會議(yì)組織者需要在卡片中明确每個人的角色和相(xiàng)應的要求，方便大(dà)家有的放(fàng)矢地進行準備。例如(rú)在需求討(tǎo)論會中，除開大(dà)家各自對産品和需求的觀點，工程師(shī)還(hái)要從(cóng)技術(shù)實現的角度提供反饋，設計(jì)師(shī)要考慮交互體驗，客戶成功經理則代表用戶的聲音。
會議(yì)組織者需要上傳所有需要參會者在會前閱讀(dú)和思考的材料，也請(qǐng)所有參會者在會前安排時間認真準備。大(dà)家都(dōu)有備而來(lái)，會議(yì)才能更快(kuài)結束。
添加會議(yì)卡片時請(qǐng)随手整理列表。
開會有一些基本原則需要遵守。
不要走神，不要竊竊私語，也不要讓手機(jī)出現在桌面上。有重要電話(huà)請(qǐng)出會議(yì)室接。
有序發言，不要打斷别人說(shuō)話(huà)。有必要的話(huà)，可以使用發言抱枕，拿着抱枕才能說(shuō)話(huà)，說(shuō)完傳遞給下一位。
積極發表意見(jiàn)和想法。主持人要主動邀請(qǐng)沉默的人發表意見(jiàn)。可以視情況采取轉圈輪流發言的方式。
冷(lěng)靜(jìng)客觀，就(jiù)事(shì)論事(shì)，不做惡意的揣測。
下面就(jiù)幾種常見(jiàn)會議(yì)類型爲例補充一些細節。
Again，無論哪種會議(yì)，充分(fēn)的會前準備都(dōu)是會議(yì)成功的關鍵。
頭腦風(fēng)暴尤其要求參會者在會前進行充分(fēn)的思考并形成自己的觀點和想法。流程如(rú)下：
大(dà)家遵循以下原則進行發言：
a. 自由發散：自由發揮，想到什麽說(shuō)什麽。隻提想法不考慮實現。
b. 不要評論：自己說(shuō)自己的，不要評論、更不能批評别人的想法。
c. 不要跑題：緊扣主題，不要跑題。
d. 隻求數量：隻求數量，不求質量。質量問(wèn)題在會後解決。
協商是随時提問(wèn)還(hái)是展示完一并提問(wèn)（先把自己問(wèn)題都(dōu)記着）。
a.推薦在展示後提問(wèn)，或者由展示者将内容分(fēn)段，每一段結束後接受提問(wèn)。
b.如(rú)果後面的内容非常依賴于對前面内容的理解，可以采取随時提問(wèn)的方式。隻提重要的、幫助自己理解的問(wèn)題，意見(jiàn)建議(yì)都(dōu)請(qǐng)放(fàng)到展示後。
公平和透明的薪酬機(jī)制有益于公司的長期健康發展。在制定公司薪酬制度時，我們重點考慮了以下問(wèn)題：
避免薪酬倒挂：我們将通過多種方法診斷薪資的公平性，有效評估職位價值，注重薪酬分(fēn)配的基礎，避免新員(yuán)工工資因市場競争水漲船(chuán)高，老員(yuán)工的薪水卻沒有相(xiàng)應增長的不公平現象。
消除薪酬談判：我們認爲，并非取決于工作能力和貢獻的薪酬談判，将在組織内部造成無必要的不公平。因此，我們給出的offer将完全取決于對候選人的獨立評判，而非談判技巧。
簡單透明：作爲一家精簡的創業公司，我們力求用透明、自動化的機(jī)制盡可能地保證薪酬的公平。
每位同事(shì)的月薪由以下公式得出：
薪酬 = 職業基準 × 能力評級 + 團隊影(yǐng)響力 + 競争力補償
職業基準 是不同職位類型的月薪基數， 該基礎将随公司的發展進行調整。當前各職位類型的基數如(rú)下：
| 類型 | 職業基準 |
|---|---|
| 軟件(jiàn)工程師(shī) | 14,000 |
| 視覺設計(jì)師(shī) | 8,000 |
| 産品經理 | 8,000 |
| 用戶體驗 | 8,000 |
以上是我們現有的職位類型，将來(lái)會根據需要增加新的類型。
能力評級（Ability）是不同的能力等級，縱向衡量員(yuán)工完成自身(shēn)工作的能力。Ability 所對應的數值如(rú)下表所示：
| 基礎設施與框架 | 業務開發 | 産品與體驗 | 代碼與文化 | |
|---|---|---|---|---|
| L0 初級工程師(shī) | 不能熟練使用 | 需要指導 | 按設計(jì)實現有困難 | 代碼可讀(dú)性欠佳 |
| L1 中級工程師(shī) | 能熟練使用 | 能熟練完成常規業務 | 重視産品體驗 | 代碼可維護性強，遵循規範和最佳實踐 |
| L2 高級工程師(shī) | 能設計(jì)和叠代小型基礎設施 | 能設計(jì)并實現大(dà)型業務模塊 | 對産品有獨立思考 | 善于總結和分(fēn)享工程經驗與最佳實踐 |
| L3 技術(shù)專家 | 能設計(jì)和叠代大(dà)型基礎設施 | 能規劃并帶領中小型項目的研發工作 | 有優秀的産品思維 | 對部門(mén)運作和人才培養有基本的思考 |
| L4 高級專家 | 有全局視野，能做整體規劃與設計(jì) | 能規劃并帶領大(dà)型項目的研發工作 | 對市場和産品願景有深刻的理解和洞見(jiàn) | 對部門(mén)運作和人才培養有全局性的思考和洞見(jiàn) |
每個級别之間還(hái)有兩個小等級，比如(rú) L1.1、L1.2
團隊影(yǐng)響力（Impact）指在團隊中的影(yǐng)響力和貢獻，團隊影(yǐng)響力橫向衡量員(yuán)工完成自身(shēn)工作以外的能力，對應的數值如(rú)下圖所示：
| 等級 | Impact | 說(shuō)明 | 舉例（軟件(jiàn)工程師(shī)） |
|---|---|---|---|
| I0 | 0 | 默認值 | 新加入的成員(yuán) |
| I1 | 1,000 | 在完成自身(shēn)工作以外，參與公司互動并帶來(lái)積極影(yǐng)響 | 技術(shù)演講、參與産品討(tǎo)論、參與設計(jì)過程 |
| I2 | 3,000 | 在完成自身(shēn)工作以外，爲公司帶來(lái)業務、産品、文化創新 | 爲公司的産品提出了新插件(jiàn)思路(lù)，并組織落實實現 |
| I3 | 5,000 | 在完成自身(shēn)工作以外，爲公司帶來(lái)業務、産品、文化創新，産生實際收益 | 爲公司的設計(jì)了新的産品線，得到用戶驗證 |
競争力補償（Competition）是對新入職員(yuán)工的補償項，它衡量員(yuán)工未來(lái)可能給公司帶來(lái)的潛在價值。
對于新加入的成員(yuán)，Ability 和 Competition 會根據面試情況确定，Impact 爲 I0。 在試用期結束後我們會重新評定各個指标，如(rú)果發現入職時評定過低我們會給予一定補償。 對于在職的同事(shì)，會根據實際工作情況每年(nián)地 review 和調整這三個指标。
工作超過一年(nián)半的員(yuán)工都(dōu)有機(jī)會申請(qǐng)獲得公司的期權。在咨詢公司法務并請(qǐng)教了行業内的投資相(xiàng)關人士後，我們發現期權有以下兩個問(wèn)題：
我們希望徹底解決以上兩個問(wèn)題，讓公司的期權真正具有價值。幸運的是，公司盈利每年(nián)都(dōu)有較快(kuài)的增長，公司的實際資産狀況良好，因此合夥團隊決定，員(yuán)工在獲得期權的同時獲得公司的财務報表，并可以在離(lí)職時由公司的自由資金進行兌換。考慮到工商部門(mén)的流程時長，我們會在期權批準的半年(nián)内，在工商層面注冊以從(cóng)法律層面上保護員(yuán)工股權。
我們爲每位在職員(yuán)工發放(fàng)年(nián)終獎金。年(nián)終獎的金額是浮動的，規則爲：
年(nián)終獎 = 年(nián)終時候的薪水 × 個人績效 × 公司績效
其中個人績效爲四季度績效分(fēn)的平均數（參見(jiàn)工作評價與反饋）。公司績效由該年(nián)度公司是否達到預期目标來(lái)定。（詳情參考公司内部文件(jiàn)：績效考核與薪酬獎勵的實施辦法）。
以上的機(jī)制借鑒了 Leancloud 的 薪酬體系，具體的公式按照(zhào)我們的情況做了調整， 希望每個人都(dōu)能清楚自己薪酬的由來(lái)以及發展空間，也讓潛在的應聘者一目了然地了解可能的薪酬範圍。
任何制度都(dōu)會經曆在實踐中完善的過程，我們會根據反饋在發展中不斷地完善這個薪酬體系。
我們認爲，好的招聘流程應當包含兩個要素：一方面能篩選出合适的候選人，另一方面能讓團隊成員(yuán)得到鍛煉。好的面試體驗應該讓我們開拓見(jiàn)識，有所收獲。
目标：驗證候選人的簡曆是否展示了他(tā)的優秀或潛力
實施者：HR與用人部門(mén)人員(yuán)
内容：
成果：制作基本信息包傳遞給有關部門(mén)進行面試準備
目标：驗證候選人在面試過程中是否展示出了優秀的專業能力（30分(fēn)鍾） 實施者：部門(mén)負責人及協作同事(shì)
内容：進行專業面試，同時必須有協作同事(shì)在場做爲「觀察者」。 觀察者在需要時可以提問(wèn)。必要時可以組織多輪面試。
成果：面試後10分(fēn)鍾撰寫信息包，并彙總到HR處。
目标：驗證候選人在面試過程中是否展示出了影(yǐng)響他(tā)人的能力（30分(fēn)鍾）
内容：帶領團隊的能力以及跨部門(mén)合作的能力
實施者：一位合作部門(mén)負責人與所有下屬參與面試
成果：面試後10分(fēn)鍾内撰寫信息包，傳遞給HR部門(mén)
目标：驗證候選人在面試過程中是否展示出良好的成長潛力（15分(fēn)鍾）
實施者：CEO
内容：入職期望，個人規劃等
成果：獨立作出判斷，根據HR計(jì)算的推薦薪酬，并根據信息包在當天給出入職決策。
公司目前采用業務組模式進行開發，因此在保證項目進度的前提下，我們允許各個項目小組靈活、個性化的分(fēn)配工作時間，但(dàn)考慮到目前的産品開發狀态，現場協同工作是件(jiàn)非常重要的事(shì)情，因此我們在請(qǐng)假與放(fàng)假上有一定的限制，這個制度也會随着公司發展更新叠代。
爲了減少大(dà)家在交通擁堵上耗費的時間以及緩解一定程度的睡眠壓力，我們推薦的初始工作時間是周一至周五 10:00 AM - 19:00 PM，這期間包含 1 小時的午休時間，因爲我們也不想你(nǐ)邊打盹邊敲代碼。
我們會盡可能滿足每一個發起的請(qǐng)假需求，但(dàn)所有請(qǐng)假需求都(dōu)會根據公司的發展狀況和項目進展的情況去(qù)考量，因此我們并不保證所有請(qǐng)假需求都(dōu)會獲得批準，希望大(dà)家理解。
原則上公司不鼓勵随意任性地因私請(qǐng)假，但(dàn)我們相(xiàng)信，每一次的請(qǐng)假都(dōu)是事(shì)出有因的。因此，除去(qù)因生病、婚喪、洪水、雷擊等不可抗力因素導緻的請(qǐng)假，如(rú)确有請(qǐng)假需求，請(qǐng)和所在項目組的負責人及同事(shì)友好商議(yì)，在不影(yǐng)響工作進度的前提下，嘗試用彈性工作時間、調休或者遠(yuǎn)程辦公等靈活機(jī)動的工作形式妥善安排自己的工作。
最後請(qǐng)在夥伴雲表格的 請(qǐng)假申請(qǐng)表 中發起請(qǐng)假事(shì)項，并關聯所在項目組負責人以及 HR 進行請(qǐng)假事(shì)項的審批和歸檔。
無論是何種請(qǐng)假，隻要你(nǐ)無法在正常工作時間在崗，都(dōu)請(qǐng)填寫 請(qǐng)假申請(qǐng)表，以便公司了解你(nǐ)的動向，并在你(nǐ)需要的時候及時幫助到你(nǐ)。
根據《職工帶薪年(nián)休假條例》，除國(guó)家規定的法定節假日(rì)外，累計(jì)工作滿一年(nián)後，你(nǐ)有可供選擇的7天帶薪年(nián)假，年(nián)假的發起請(qǐng)根據公司項目進展情況有規劃的和項目組負責人及同事(shì)商議(yì)安排，之後請(qǐng)告知部門(mén)負責人及其他(tā)可能會受到影(yǐng)響的同事(shì)。
最後請(qǐng)在夥伴雲表格的 請(qǐng)假申請(qǐng)表 中發起年(nián)假申請(qǐng)事(shì)項，并關聯項目組負責人以及HR進行年(nián)假事(shì)項的審批和歸檔。
公司也會根據項目進展情況統一安排年(nián)假。
我們每個月會進行一次 一對一對談，每個季度會進行一次 工作評價（performance review）。一對一對談 的目的是提供一個反饋的機(jī)會，同時讓主管更好地了解你(nǐ)。工作評價 的目的是對你(nǐ)近3個月内的工作表現進行一個評估，并與年(nián)終的薪酬獎勵挂鈎。
每個成員(yuán)都(dōu)需要每個月與主管進行一對一的簡短面談，面談内容可以包括個人發展規劃、工作問(wèn)題反饋等，主管應該确保每一次面談都(dōu)有記錄。一對一對談是私密的，并不公開給所有的人。
工作評價每個季度進行一次，包含以下三個方面。工作評價是完全公開的，每個人都(dōu)可以看(kàn)到其他(tā)人的全部評價。
所有同事(shì)都(dōu)需要對其他(tā)人進行同伴評價。内容包括：
每個主管會爲每位下屬寫主管評價和反饋，同時打出本季度的績效得分(fēn)。
主管的績效分(fēn)由以下部分(fēn)組成：
| 項目 | 占比 | 舉例 |
|---|---|---|
| 個人能力 | 20% | （個人角度）确實表現出與「高級軟件(jiàn)工程師(shī)」相(xiàng)稱的業務能力，例如(rú)…… |
| 工作成果 | 40% | （公司角度）确實給公司帶來(lái)了預期的收益，如(rú)果不是，原因是什麽 |
| 工作以外的貢獻 | 20% | （公司角度）除工作外的對公司的正面影(yǐng)響，詳細說(shuō)明 |
| 個人成長 | 20% | （個人角度）個人能力的微分(fēn) |
