- 相關(guān)推薦
在創(chuàng )業(yè)公司該如何解決技術(shù)開(kāi)發(fā)團隊的考核問(wèn)題
團隊考核即團隊績(jì)效考核，就是對團隊完成其職責和對工作結果的考評，是對其工作貢獻程度的衡量和評價(jià)，直接體現出各個(gè)層次團隊在企業(yè)中的價(jià)值大小，是績(jì)效考核的核心內容。以下是小編整理的在創(chuàng )業(yè)公司該如何解決技術(shù)開(kāi)發(fā)團隊的考核問(wèn)題，希望對大家有所幫助。
團隊考核存在的問(wèn)題
現在創(chuàng )業(yè)公司的技術(shù)開(kāi)發(fā)部門(mén)其實(shí)很難進(jìn)行考核，無(wú)論是KPI還是OKR，我覺(jué)得在實(shí)際操作過(guò)程中都有不少問(wèn)題，這不是說(shuō)考核的方法不對，而是我覺(jué)得在落地操作的時(shí)候并不那么的接地氣，那么問(wèn)題或者阻礙有哪些呢？
1、目標不明確
這是創(chuàng )業(yè)公司都會(huì )存在的問(wèn)題，因為創(chuàng )業(yè)公司的首要任務(wù)是活下去，所以朝令夕改，邊做邊調整的情況是司空見(jiàn)慣的，而習慣于瀑布式開(kāi)發(fā)的團隊，對于這樣的做法做著(zhù)做著(zhù)就不行了，關(guān)鍵是開(kāi)發(fā)人員非常反感需求的頻繁調整，這對于開(kāi)發(fā)團隊的士氣也會(huì )造成較大的影響。
那么有人會(huì )說(shuō)，敏捷開(kāi)發(fā)不就解決這些問(wèn)題了？是的，在一定的條件下，的確可以解決問(wèn)題，但是這對于開(kāi)發(fā)人員、項目經(jīng)理、產(chǎn)品經(jīng)理，甚至于部門(mén)負責人的要求都是非常高的，真正用好敏捷開(kāi)發(fā)的我自己看來(lái)屈指可數。
2、考核的依據過(guò)于主觀(guān)
一般來(lái)說(shuō)，無(wú)論哪種考核方式，都是要評估工作量的，但是開(kāi)發(fā)與賣(mài)產(chǎn)品不一樣，開(kāi)發(fā)人員在接到任務(wù)的時(shí)候，其實(shí)是不知道要做多久的，很可能都是做著(zhù)做著(zhù)發(fā)現其實(shí)需求并不合理，一問(wèn)業(yè)務(wù)部分，然后又改了需求，但是修改之后工作量可能就變化了（這個(gè)關(guān)于工作量的問(wèn)題，我也是在讀《人月傳說(shuō)》時(shí)特別有感受），所以大部分的項目都是由項目經(jīng)理來(lái)評定的，萬(wàn)一項目經(jīng)理的經(jīng)驗不準，或者老板極其強硬的縮短開(kāi)發(fā)周期，那么團隊就會(huì )死的很難看了。
尤其是拼命干了之后，開(kāi)發(fā)人員并沒(méi)有得到充分的認同，對老板來(lái)說(shuō)可能老板更加相信是自己的眼光和遠見(jiàn)，團隊越是這樣完成任務(wù)，接下來(lái)任務(wù)會(huì )更緊，而且變得更加的理所當然，這也是程序員特別苦悶的地方，誰(shuí)讓我們IT人當老板的不多呢？
3、考核最終的呈現不透明
一般我們IT人員搞開(kāi)發(fā)，大部分還是拿穩定薪水的，畢竟不壓榨開(kāi)發(fā)人員，公司哪里來(lái)的收益，資本主義的概念在現代開(kāi)發(fā)項目中最有體現，尤其是老板是業(yè)務(wù)出生的，你跟他說(shuō)工作量，這個(gè)用了什么技術(shù)，那個(gè)通過(guò)什么算法，老板基本都是云里霧里，那是為什么？因為不懂啊，不懂技術(shù)啊，因為不懂所以天然就會(huì )懷疑，因為懷疑所以并不理解技術(shù)人員在完成項目過(guò)程中的辛苦與汗水，完成之后，好一點(diǎn)的給個(gè)項目獎，但是因為整個(gè)過(guò)程沒(méi)有得到最希望認可的人來(lái)理解，那么就算完成了還是成就感缺缺。
歸根結底，對于技術(shù)人員開(kāi)發(fā)的考核不透明，對開(kāi)發(fā)人員自己不透明，做的只有自己知道，對外就更不透明，大部分開(kāi)發(fā)人員做出來(lái)的功能，其實(shí)是沒(méi)人去用的，處理自己和測試人員，沒(méi)人知道這個(gè)功能有多棒！
那么，是不是有什么方法解決呢？
有啊，比如：招個(gè)特別牛的IT總監就可以，因為人家經(jīng)驗豐富，對于這些問(wèn)題應該比較了解，通過(guò)他再跟老板溝通應該就會(huì )好，當然這也是很多企業(yè)解決的方法，但問(wèn)題是，我看到更多的還是CTO是個(gè)大坑這樣的言論（各位CTO先不要噴，并不針對人，只是存在這種存在情況）。
對此，有何方案
那么這三個(gè)問(wèn)題，有沒(méi)有辦法解決？ 目標該怎么定？工作量怎么評估？如何通過(guò)考核透明向老板正名？
看了《阿米巴模式》之后，我就有了下面的一個(gè)實(shí)施方案，拿出來(lái)大家討論討論：
由全體人員對工作量進(jìn)行評估，而不是僅僅由項目經(jīng)理負責；
評估之后取全體人員評估的平均值；
選3個(gè)開(kāi)發(fā)人員，按照其對于團隊的了解，基于平均值進(jìn)行調整，最后選用最合適的方案，方案使得每個(gè)人的工作量最終應該差不多時(shí)間完成，而團隊以完成最長(cháng)的那個(gè)人評估的工作量作為整體項目完成時(shí)間，而方案的擬定人作為這個(gè)項目任務(wù)的負責人；
項目實(shí)際開(kāi)發(fā)時(shí)，計算個(gè)人實(shí)際完成和團隊實(shí)際完成天數，比照原來(lái)估計的分別產(chǎn)生個(gè)人完成效率和團隊完成效率；
個(gè)人完成效率可以迭代到下一次任務(wù)中作為平均值調整的參數，團隊完成效率之外可以再提供一個(gè)項目完成時(shí)的表現打分，僅僅是大家對于開(kāi)發(fā)人表現的打分，其實(shí)也可以理解為，大家對于個(gè)人在整個(gè)項目完成過(guò)程中這個(gè)人對于團隊的共享價(jià)值。
依次反復之后，會(huì )有一些結果， 我自己按照上述方法在我自己的開(kāi)發(fā)團隊執行了4次，第一次誤差比較大，畢竟沒(méi)有什么借鑒，但是隨著(zhù)一次一次的嘗試，一方面團隊的人員會(huì )比較熟悉這套方法，除了每個(gè)人具體評價(jià)的值不透明，所有過(guò)程都是透明的，公開(kāi)的，自己都可以計算；另一方面的確有激勵的作用，畢竟原先一個(gè)人評價(jià)20天完成的任務(wù)，12天完成了，成就感就非常高（無(wú)論是團隊內部，還是上升到老板層面），所以解決了上述的一些問(wèn)題。
但是，這個(gè)方法本身還存在問(wèn)題需要繼續完善，比如：除了開(kāi)發(fā)其他崗位的執行并不理想、人員太少的情況下不太適合、臨時(shí)或者突發(fā)增加的任務(wù)依然還需要靠項目負責人來(lái)分配等等，這也沒(méi)辦法。但是，我希望通過(guò)團隊和大家的努力共同打造一個(gè)合適我們IT技術(shù)人員的考核方法。
高效研發(fā)的5個(gè)關(guān)鍵步驟
第一步：立項——定方向
在豌豆莢的整個(gè)研發(fā)過(guò)程中，立項稱(chēng)為ProductBrief或者Project Brief。團隊的產(chǎn)品經(jīng)理會(huì )撰寫(xiě)一個(gè)1－2頁(yè)的文檔，然后和執行團隊進(jìn)行評審，如果評審通過(guò)，立項就成功了。文檔一般包含會(huì )包含以下內容：
1. 愿景：一句話(huà)表達清楚要做什么；
2.分析市場(chǎng)機會(huì )和趨勢，決定當前策略；
3. 確定目標用戶(hù)的特征和核心需求；
4. 現存的解決方案和各自的優(yōu)劣勢；
5. 該項目對豌豆莢的利益點(diǎn)；如果不做該項目，哪些競爭對手會(huì )做，對競爭對手的利益點(diǎn)；
6. 需要哪些技術(shù)的支持和驅動(dòng)，哪些技術(shù)是豌豆莢的弱項；
7. 人力需求；
8. 項目的緊急程度，是否需要快速推進(jìn)；
9. 發(fā)布策略；
10.核心衡量指標，用來(lái)衡量成功的指標。
第二步，OKR 體系——定目標
對一個(gè)項目來(lái)說(shuō)，設定目標是非常重要的，因為這決定了如何去做，以及能做到何種程度。豌豆莢采納的目標管理是從 Google 引進(jìn)的 OKR 體系（Objectives& Key Results，目標與關(guān)鍵成果），這跟傳統的 KPI（Key Performance Indicator，關(guān)鍵績(jì)效考核）稍微有些區別：
1. OKR 首先是溝通工具：豌豆莢共有 300 多人，每個(gè)人都要寫(xiě) OKR。為了便于溝通，所有這些OKR都會(huì )放在一個(gè)文檔里。任何員工都可以看到 CEO 的這個(gè)季度最重要的目標是什么，HR 團隊這個(gè)季度的目標是什么。
2. OKR是努力的方向和目標：OKR代表你到底要去哪里，而不是你要去的地方具體在哪里。
3. OKR必須可量化。比如健身時(shí)設定鍛煉目標，如果只是定義成「我們要努力提高身體素質(zhì)」，肯定不是一個(gè)好的 OKR，因為無(wú)法衡量，好的OKR是「今年的跑步時(shí)間較去年增加一倍」。
4. 目標必須一致：制定者和執行者目標一致、團隊和個(gè)人的目標一致。首先，制定公司的OKR；其次，每個(gè)團隊定自己的 OKR；第三，每個(gè)工程師或設計師寫(xiě)各自的OKR。這三步各自獨立完成，然后對照協(xié)調這三者的OKR。在豌豆莢，OKR跟個(gè)人績(jì)效沒(méi)有關(guān)系，因為OKR 系統的結果和每個(gè)人并不直接掛鉤。
5. 通過(guò)月度會(huì )議Review ，時(shí)時(shí)跟進(jìn)OKR：在月度會(huì )議上需要確定如何去達到目標，是一個(gè)幫助達到目標的過(guò)程。
6. 通過(guò)季度會(huì )議 Review ，及時(shí)調整OKR：互聯(lián)網(wǎng)的變化非�？�，所以豌豆莢每季度有一個(gè)OKR 的 review，調整的原則是目標（Objectives）不變，只允許調整關(guān)鍵成果（Key Results）。
第三二步，項目管理——控進(jìn)度：
目標設定以后，非常重要的就是執行，一般的項目管理實(shí)際上就是控制進(jìn)度。
1. 任務(wù)/進(jìn)度勤同步。整個(gè)公司所有人的 calender，包括會(huì )議、要做的事情、項目的時(shí)間節點(diǎn)都需要及時(shí)同步。在整個(gè)戰略布局上，如果某個(gè)項目工期非常緊，就必須進(jìn)行更多的溝通，確保每一個(gè)環(huán)節都沒(méi)有問(wèn)題。
2. 站立會(huì )議 (Daily Sync)：每天進(jìn)行站立會(huì )議，一般控制在十分鐘之內，每個(gè)人說(shuō)明自己今天要做的工作，需要什么幫助，有誰(shuí)可以幫忙，可以更有效的調節資源和公關(guān)。
3. 多方位溝通（Google Docs / Gmail / Hangouts）：對非緊急的事情，兩個(gè)團隊或者是兩個(gè)人一起討論所有的設計。Hangouts用于做快速響應。
4. 周會(huì )（Weekly Report）：每周總結。豌豆莢的團隊產(chǎn)品經(jīng)理要做周報，匯報這周的工作、發(fā)布、取得效果以及數據。
5. 數據系統：MUCE 是豌豆莢的數據系統，上面有全公司所有的產(chǎn)品數據和運營(yíng)數據。MUCE 的數據能夠用來(lái)驗證產(chǎn)品的假設、方向等。
第四步，人員管理——帶團隊：
項目是由一個(gè)個(gè)具體的人來(lái)執行的，所以帶團隊非常重要，在人員管理上，豌豆莢有三個(gè)基本原則：
1、 Re-Organization& 換組：公司鼓勵員工換組，每個(gè)人都有機會(huì )到喜愛(ài)的團隊做更有趣的事情。只要在原團隊的績(jì)效合格，每季度都可申請換團隊或換工作內容。員工的績(jì)效不與 OKR 掛鉤，公司鼓勵員工挑戰難度、超越優(yōu)秀，低 Level 的事情做不到優(yōu)秀會(huì )被懲罰，做事不及格也會(huì )被懲罰。
2、One on One：在帶人方面， One on One 非常重要。One on One 指的是每個(gè)團隊的 manager 需要定期（最佳間隔是每周一次）與自己團隊中的每個(gè)成員進(jìn)行一對一討論或者對話(huà)。在豌豆莢，manager 首先是一個(gè)教練，應該幫助自己團隊的成員成長(cháng)。通過(guò) One on One，manager 需要了解每個(gè)團隊成員現階段的狀態(tài)和遭遇的困擾，分享職業(yè)規劃，幫助他們正確地處理問(wèn)題，更好地實(shí)現個(gè)人成長(cháng)。
3、個(gè)人 OKR 和 Performance 體系：每個(gè)員工在每個(gè)季度初需要確定自己本季度的 OKR，在一個(gè)季度結束后需要根據自己這個(gè)季度的工作完成情況給 OKR 打分。每半年公司會(huì )進(jìn)行一次 Performance Review，主要是 review 員工過(guò)去半年的績(jì)效，并根據 Performance Review 的結果變更 Job Ladder（業(yè)務(wù)職級）和薪酬。值得一提的是，在豌豆莢，所有的個(gè)人Performance Review 的成就內容及級別都是全公司共享公開(kāi)的，如下圖所示。這個(gè)對于很多公司來(lái)說(shuō)是不可想象的，豌豆莢為什么要這么做？因為一方面對于豌豆莢來(lái)說(shuō)可以做到更為公 平和透明，另一方面也給每位豌豆提供了更好學(xué)習和成長(cháng)自己的樣本，激勵大家在產(chǎn)品研發(fā)中更高質(zhì)量的挑戰和要求自己。
第五步，興趣管理——排干擾：
1、 激發(fā)興趣：HackDay，是豌豆莢一個(gè)特殊的節日，開(kāi)始于2010年，類(lèi)似黑客馬拉松。通常在春節假期回來(lái)的那一周，產(chǎn)品設計師和工程師們 3-5 人組成一隊，在連續48小時(shí)的時(shí)間里，充分展現工程團隊的創(chuàng )意和想像力，完成一些比日常開(kāi)發(fā)更 geek、更有趣的東西。
豌豆莢為了鼓勵大家更好的完成挑戰，也會(huì )設計一些特別有特色的獎品，歷史上2012 年提供的是蘋(píng)果剛出 Macbook Retina，2013年是 Google Glass，2014 年則是程序員最?lèi)?ài)的 Herman Miller 頂級座椅。
在歷史的 Hackday 中，有不少作品最終都成了重要產(chǎn)品對外發(fā)布，比如 MUCE、豌豆洗白白和 IAS（應用內搜索），都成為了豌豆莢極具特色的產(chǎn)品。
2、 控制興趣：PolishWeek，讓公司慢下來(lái)，對已有產(chǎn)品的細節進(jìn)行精細化的過(guò)程。在大量開(kāi)發(fā)和新產(chǎn)品上線(xiàn)的過(guò)程中，我們會(huì )擔心因為走得太快而對產(chǎn)品的 細節關(guān)注不夠。在連續3個(gè)工作周后，第4周通常是 PolishWeek。在 Polish Week 的這一周，豌豆莢內部不會(huì )進(jìn)行新產(chǎn)品或新功能的開(kāi)發(fā)，而主要是對現有的產(chǎn)品和服務(wù)進(jìn)行打磨，解決一些細節問(wèn)題和小 bug，譬如產(chǎn)品內一些字體的統一等等。平均每個(gè) Polish Week 會(huì )解決產(chǎn)品中各種 Bug 大約 200 個(gè)。
【在創(chuàng )業(yè)公司該如何解決技術(shù)開(kāi)發(fā)團隊的考核問(wèn)題】相關(guān)文章：
該如何為你的創(chuàng )業(yè)公司融資？02-27
農村該如何創(chuàng )業(yè)03-26
青年該如何創(chuàng )業(yè)03-26
自己該如何創(chuàng )業(yè)03-26
創(chuàng )業(yè)期如何組織創(chuàng )業(yè)團隊03-08
如何解決大學(xué)生返鄉創(chuàng )業(yè)根本問(wèn)題03-21