• <sub id="h4knl"><ol id="h4knl"></ol></sub>
    <sup id="h4knl"></sup>
      <sub id="h4knl"></sub>

      <sub id="h4knl"><ol id="h4knl"><em id="h4knl"></em></ol></sub><s id="h4knl"></s>
      1. <strong id="h4knl"></strong>

      2. 在創(chuàng)業(yè)公司該如何解決技術開發(fā)團隊的考核問題

        時間:2024-10-18 15:58:24 賽賽 如何創(chuàng)業(yè) 我要投稿
        • 相關推薦

        在創(chuàng)業(yè)公司該如何解決技術開發(fā)團隊的考核問題

          團隊考核即團隊績效考核,就是對團隊完成其職責和對工作結果的考評,是對其工作貢獻程度的衡量和評價,直接體現出各個層次團隊在企業(yè)中的價值大小,是績效考核的核心內容。以下是小編整理的在創(chuàng)業(yè)公司該如何解決技術開發(fā)團隊的考核問題,希望對大家有所幫助。

        在創(chuàng)業(yè)公司該如何解決技術開發(fā)團隊的考核問題

          團隊考核存在的問題

          現在創(chuàng)業(yè)公司的技術開發(fā)部門其實很難進行考核,無論是KPI還是OKR,我覺得在實際操作過程中都有不少問題,這不是說考核的方法不對,而是我覺得在落地操作的時候并不那么的接地氣,那么問題或者阻礙有哪些呢?

          1、目標不明確

          這是創(chuàng)業(yè)公司都會存在的問題,因為創(chuàng)業(yè)公司的首要任務是活下去,所以朝令夕改,邊做邊調整的情況是司空見慣的,而習慣于瀑布式開發(fā)的團隊,對于這樣的做法做著做著就不行了,關鍵是開發(fā)人員非常反感需求的頻繁調整,這對于開發(fā)團隊的士氣也會造成較大的影響。

          那么有人會說,敏捷開發(fā)不就解決這些問題了?是的,在一定的條件下,的確可以解決問題,但是這對于開發(fā)人員、項目經理、產品經理,甚至于部門負責人的要求都是非常高的,真正用好敏捷開發(fā)的我自己看來屈指可數。

          2、考核的依據過于主觀

          一般來說,無論哪種考核方式,都是要評估工作量的,但是開發(fā)與賣產品不一樣,開發(fā)人員在接到任務的時候,其實是不知道要做多久的,很可能都是做著做著發(fā)現其實需求并不合理,一問業(yè)務部分,然后又改了需求,但是修改之后工作量可能就變化了(這個關于工作量的問題,我也是在讀《人月傳說》時特別有感受),所以大部分的項目都是由項目經理來評定的,萬一項目經理的經驗不準,或者老板極其強硬的縮短開發(fā)周期,那么團隊就會死的很難看了。

          尤其是拼命干了之后,開發(fā)人員并沒有得到充分的認同,對老板來說可能老板更加相信是自己的眼光和遠見,團隊越是這樣完成任務,接下來任務會更緊,而且變得更加的理所當然,這也是程序員特別苦悶的地方,誰讓我們IT人當老板的不多呢?

          3、考核最終的呈現不透明

          一般我們IT人員搞開發(fā),大部分還是拿穩(wěn)定薪水的,畢竟不壓榨開發(fā)人員,公司哪里來的收益,資本主義的概念在現代開發(fā)項目中最有體現,尤其是老板是業(yè)務出生的,你跟他說工作量,這個用了什么技術,那個通過什么算法,老板基本都是云里霧里,那是為什么?因為不懂啊,不懂技術啊,因為不懂所以天然就會懷疑,因為懷疑所以并不理解技術人員在完成項目過程中的辛苦與汗水,完成之后,好一點的給個項目獎,但是因為整個過程沒有得到最希望認可的人來理解,那么就算完成了還是成就感缺缺。

          歸根結底,對于技術人員開發(fā)的考核不透明,對開發(fā)人員自己不透明,做的只有自己知道,對外就更不透明,大部分開發(fā)人員做出來的功能,其實是沒人去用的,處理自己和測試人員,沒人知道這個功能有多棒!

          那么,是不是有什么方法解決呢?

          有啊,比如:招個特別牛的IT總監(jiān)就可以,因為人家經驗豐富,對于這些問題應該比較了解,通過他再跟老板溝通應該就會好,當然這也是很多企業(yè)解決的方法,但問題是,我看到更多的還是CTO是個大坑這樣的言論(各位CTO先不要噴,并不針對人,只是存在這種存在情況)。

          對此,有何方案

          那么這三個問題,有沒有辦法解決? 目標該怎么定?工作量怎么評估?如何通過考核透明向老板正名?

          看了《阿米巴模式》之后,我就有了下面的一個實施方案,拿出來大家討論討論:

          由全體人員對工作量進行評估,而不是僅僅由項目經理負責;

          評估之后取全體人員評估的平均值;

          選3個開發(fā)人員,按照其對于團隊的了解,基于平均值進行調整,最后選用最合適的方案,方案使得每個人的工作量最終應該差不多時間完成,而團隊以完成最長的那個人評估的工作量作為整體項目完成時間,而方案的擬定人作為這個項目任務的負責人;

          項目實際開發(fā)時,計算個人實際完成和團隊實際完成天數,比照原來估計的分別產生個人完成效率和團隊完成效率;

          個人完成效率可以迭代到下一次任務中作為平均值調整的參數,團隊完成效率之外可以再提供一個項目完成時的表現打分,僅僅是大家對于開發(fā)人表現的打分,其實也可以理解為,大家對于個人在整個項目完成過程中這個人對于團隊的共享價值。

          依次反復之后,會有一些結果, 我自己按照上述方法在我自己的開發(fā)團隊執(zhí)行了4次,第一次誤差比較大,畢竟沒有什么借鑒,但是隨著一次一次的嘗試,一方面團隊的人員會比較熟悉這套方法,除了每個人具體評價的值不透明,所有過程都是透明的,公開的,自己都可以計算;另一方面的確有激勵的作用,畢竟原先一個人評價20天完成的任務,12天完成了,成就感就非常高(無論是團隊內部,還是上升到老板層面),所以解決了上述的一些問題。

          但是,這個方法本身還存在問題需要繼續(xù)完善,比如:除了開發(fā)其他崗位的執(zhí)行并不理想、人員太少的情況下不太適合、臨時或者突發(fā)增加的任務依然還需要靠項目負責人來分配等等,這也沒辦法。但是,我希望通過團隊和大家的努力共同打造一個合適我們IT技術人員的考核方法。

          高效研發(fā)的5個關鍵步驟

          第一步:立項——定方向

          在豌豆莢的整個研發(fā)過程中,立項稱為ProductBrief或者Project Brief。團隊的產品經理會撰寫一個1-2頁的文檔,然后和執(zhí)行團隊進行評審,如果評審通過,立項就成功了。文檔一般包含會包含以下內容:

          1. 愿景:一句話表達清楚要做什么;

          2.分析市場機會和趨勢,決定當前策略;

          3. 確定目標用戶的特征和核心需求;

          4. 現存的解決方案和各自的優(yōu)劣勢;

          5. 該項目對豌豆莢的利益點;如果不做該項目,哪些競爭對手會做,對競爭對手的利益點;

          6. 需要哪些技術的支持和驅動,哪些技術是豌豆莢的弱項;

          7. 人力需求;

          8. 項目的緊急程度,是否需要快速推進;

          9. 發(fā)布策略;

          10.核心衡量指標,用來衡量成功的指標。

          第二步,OKR 體系——定目標

          對一個項目來說,設定目標是非常重要的,因為這決定了如何去做,以及能做到何種程度。豌豆莢采納的目標管理是從 Google 引進的 OKR 體系(Objectives& Key Results,目標與關鍵成果),這跟傳統的 KPI(Key Performance Indicator,關鍵績效考核)稍微有些區(qū)別:

          1. OKR 首先是溝通工具:豌豆莢共有 300 多人,每個人都要寫 OKR。為了便于溝通,所有這些OKR都會放在一個文檔里。任何員工都可以看到 CEO 的這個季度最重要的目標是什么,HR 團隊這個季度的目標是什么。

          2. OKR是努力的方向和目標:OKR代表你到底要去哪里,而不是你要去的地方具體在哪里。

          3. OKR必須可量化。比如健身時設定鍛煉目標,如果只是定義成「我們要努力提高身體素質」,肯定不是一個好的 OKR,因為無法衡量,好的OKR是「今年的跑步時間較去年增加一倍」。

          4. 目標必須一致:制定者和執(zhí)行者目標一致、團隊和個人的目標一致。首先,制定公司的OKR;其次,每個團隊定自己的 OKR;第三,每個工程師或設計師寫各自的OKR。這三步各自獨立完成,然后對照協調這三者的OKR。在豌豆莢,OKR跟個人績效沒有關系,因為OKR 系統的結果和每個人并不直接掛鉤。

          5. 通過月度會議Review ,時時跟進OKR:在月度會議上需要確定如何去達到目標,是一個幫助達到目標的過程。

          6. 通過季度會議 Review ,及時調整OKR:互聯網的變化非常快,所以豌豆莢每季度有一個OKR 的 review,調整的原則是目標(Objectives)不變,只允許調整關鍵成果(Key Results)。

          第三二步,項目管理——控進度:

          目標設定以后,非常重要的就是執(zhí)行,一般的項目管理實際上就是控制進度。

          1. 任務/進度勤同步。整個公司所有人的 calender,包括會議、要做的事情、項目的時間節(jié)點都需要及時同步。在整個戰(zhàn)略布局上,如果某個項目工期非常緊,就必須進行更多的溝通,確保每一個環(huán)節(jié)都沒有問題。

          2. 站立會議 (Daily Sync):每天進行站立會議,一般控制在十分鐘之內,每個人說明自己今天要做的工作,需要什么幫助,有誰可以幫忙,可以更有效的調節(jié)資源和公關。

          3. 多方位溝通(Google Docs / Gmail / Hangouts):對非緊急的事情,兩個團隊或者是兩個人一起討論所有的設計。Hangouts用于做快速響應。

          4. 周會(Weekly Report):每周總結。豌豆莢的團隊產品經理要做周報,匯報這周的工作、發(fā)布、取得效果以及數據。

          5. 數據系統:MUCE 是豌豆莢的數據系統,上面有全公司所有的產品數據和運營數據。MUCE 的數據能夠用來驗證產品的假設、方向等。

          第四步,人員管理——帶團隊:

          項目是由一個個具體的人來執(zhí)行的,所以帶團隊非常重要,在人員管理上,豌豆莢有三個基本原則:

          1、 Re-Organization& 換組:公司鼓勵員工換組,每個人都有機會到喜愛的團隊做更有趣的事情。只要在原團隊的績效合格,每季度都可申請換團隊或換工作內容。員工的績效不與 OKR 掛鉤,公司鼓勵員工挑戰(zhàn)難度、超越優(yōu)秀,低 Level 的事情做不到優(yōu)秀會被懲罰,做事不及格也會被懲罰。

          2、One on One:在帶人方面, One on One 非常重要。One on One 指的是每個團隊的 manager 需要定期(最佳間隔是每周一次)與自己團隊中的每個成員進行一對一討論或者對話。在豌豆莢,manager 首先是一個教練,應該幫助自己團隊的成員成長。通過 One on One,manager 需要了解每個團隊成員現階段的狀態(tài)和遭遇的困擾,分享職業(yè)規(guī)劃,幫助他們正確地處理問題,更好地實現個人成長。

          3、個人 OKR 和 Performance 體系:每個員工在每個季度初需要確定自己本季度的 OKR,在一個季度結束后需要根據自己這個季度的工作完成情況給 OKR 打分。每半年公司會進行一次 Performance Review,主要是 review 員工過去半年的績效,并根據 Performance Review 的結果變更 Job Ladder(業(yè)務職級)和薪酬。值得一提的是,在豌豆莢,所有的個人Performance Review 的成就內容及級別都是全公司共享公開的,如下圖所示。這個對于很多公司來說是不可想象的,豌豆莢為什么要這么做?因為一方面對于豌豆莢來說可以做到更為公 平和透明,另一方面也給每位豌豆提供了更好學習和成長自己的樣本,激勵大家在產品研發(fā)中更高質量的挑戰(zhàn)和要求自己。

          第五步,興趣管理——排干擾:

          1、 激發(fā)興趣:HackDay,是豌豆莢一個特殊的節(jié)日,開始于2010年,類似黑客馬拉松。通常在春節(jié)假期回來的那一周,產品設計師和工程師們 3-5 人組成一隊,在連續(xù)48小時的時間里,充分展現工程團隊的創(chuàng)意和想像力,完成一些比日常開發(fā)更 geek、更有趣的東西。

          豌豆莢為了鼓勵大家更好的完成挑戰(zhàn),也會設計一些特別有特色的獎品,歷史上2012 年提供的是蘋果剛出 Macbook Retina,2013年是 Google Glass,2014 年則是程序員最愛的 Herman Miller 頂級座椅。

          在歷史的 Hackday 中,有不少作品最終都成了重要產品對外發(fā)布,比如 MUCE、豌豆洗白白和 IAS(應用內搜索),都成為了豌豆莢極具特色的產品。

          2、 控制興趣:PolishWeek,讓公司慢下來,對已有產品的細節(jié)進行精細化的過程。在大量開發(fā)和新產品上線的過程中,我們會擔心因為走得太快而對產品的 細節(jié)關注不夠。在連續(xù)3個工作周后,第4周通常是 PolishWeek。在 Polish Week 的這一周,豌豆莢內部不會進行新產品或新功能的開發(fā),而主要是對現有的產品和服務進行打磨,解決一些細節(jié)問題和小 bug,譬如產品內一些字體的統一等等。平均每個 Polish Week 會解決產品中各種 Bug 大約 200 個。

        【在創(chuàng)業(yè)公司該如何解決技術開發(fā)團隊的考核問題】相關文章:

        該如何為你的創(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

        創(chuàng)業(yè)團隊該拿怎樣薪水11-18

        如何解決大學生返鄉(xiāng)創(chuàng)業(yè)根本問題03-21

        80后該如何創(chuàng)業(yè)?11-18

        創(chuàng)業(yè)CEO解決雞與蛋的問題06-14

        創(chuàng)業(yè)達人:校園創(chuàng)業(yè)該如何創(chuàng)11-21

        国产高潮无套免费视频_久久九九兔免费精品6_99精品热6080YY久久_国产91久久久久久无码
      3. <sub id="h4knl"><ol id="h4knl"></ol></sub>
        <sup id="h4knl"></sup>
          <sub id="h4knl"></sub>

          <sub id="h4knl"><ol id="h4knl"><em id="h4knl"></em></ol></sub><s id="h4knl"></s>
          1. <strong id="h4knl"></strong>

          2. 亚洲天堂久久伊人网 | 欧美性爱A免费在线观看 | 亚洲一级在线观看 | 日本免费在线看AⅤ视频 | 日韩欧美乱国产日韩欧美 | 免费国产午夜精华视频 |