基于 Github 的 OKR 實施方法以及企業(yè)協(xié)同方法

前言<a id="orgheadline1"></a>

Github 對于軟件開發(fā)者的重要性不言而喻,但是其實大部分人僅僅用到了其冰山一角。本文嘗試介紹一套通過 Github 進行 OKR 實施以及企業(yè)協(xié)同的方法。OKR 的介紹見文章最后的參考鏈接。

如何管理 OKR?<a id="orgheadline3"></a>

OKR 的特點<a id="orgheadline2"></a>

OKR 管理制要求公司每年、每季度都要確定一套 OKR,而且數(shù)量有嚴格的限制,最多有 5 個 O,每個 O 最多 4 個 KR。OKR 除了在公司進行 Review 時會稍作調整,其他時間基本上是不需要再進行修改的。
由此可見,OKR 有幾個特點:

  1. 有限性,整個公司一年產(chǎn)生幾個文檔足已
  2. 公開性,所有的 OKRs 對公司內部所有人可見
  3. 穩(wěn)定性,OKRs 不會頻繁被修改

基于上述特點,在 Github 上建一個企業(yè)內部的公共倉庫,把 OKRs 作為 Wiki 錄入到該倉庫中再合適不過了。

如何管理 Review<a id="orgheadline5"></a>

Review 的特點<a id="orgheadline4"></a>

OKR 要求公司以及每個員工要定期 Review,公司每月一次即可,而員工每月、每周都要 Review,Review 的內容包括“目標,進度,遇到的問題,問題原因,下一步計劃”。由此可見,Review 的特點如下:

  1. 數(shù)量大,每人每周產(chǎn)生一個 Review
  2. 可討論性,周 Review 的發(fā)起人是員工,但是針對其中所描述的問題,可能需要其他同事參與進行討論
  3. 變化性,基于問題討論之后,應該對下一步的計劃有所影響,所以 Review 中的“下一步計劃”可能需要修改幾版后才能穩(wěn)定下來
  4. 通知性,Review 的提交以及問題的討論都要求相關同事及時得到通知
  5. 知識性,員工以及公司的 Review,不管對員工個人還是公司,都是累積的知識,不應該用完就被完全廢棄
  6. 時效性,過期的 Review 應該被歸檔保存起來,避免瀏覽時過度影響當前的 Review
  7. 便于追溯、檢索,凡是積累的知識都應該能夠追溯和檢索,否則沒有意義。

基于這些特點,我認為 Github 里的 Issues 是一個完美的選擇。
每周五的時候為每個員工分配一個 issue,員工以評論的形式提交自己的周 Review,并@ 相關的同事予以關注(當然也可以讓員工自己發(fā)起 issue,并分配給自己)。
相關的討論可以在下面肆意的進行。確定好了下一周的計劃后可立即修改。

到了下一周的周五,如果上周五 issue 中計劃的任務全部完成,則 close 掉該 issue。如果沒完成則繼續(xù)保持 open 狀態(tài)。
同時,本周五還會生成一個新的 issue。多個 issue 在身,員工的壓力自然就來了,OKR 的目的也就順利成章地達到了。

如何掌控進度<a id="orgheadline6"></a>

還有個問題是:管理層如何對全局的進度進行掌控?這個時候,Github Issues 里另外一個好東西要派上用場了,那就是 Milestones。
我的方法是為每個周建立一個 Milestones , 將其截止時間定到下一周的周末,并把本周所有的 issues 都關聯(lián)到此 Milestone 上。
這樣到了下一周,管理層通過查看 Milestones 的狀態(tài)即可完全掌握全局的進度,并且能很方便的通過查看 open 狀態(tài)的 issues 追蹤到出現(xiàn)問題的相關人員。

如何關聯(lián)產(chǎn)品的需求<a id="orgheadline7"></a>

研發(fā)團隊的工作是基于產(chǎn)品需求的,這些產(chǎn)品需求同樣以 issues 的形式存在,但是可能會散落在一個個不同的代碼倉庫中。而我們的周 Review 是在一個公共倉庫中進行。
顯然,將不同產(chǎn)品的需求 issues 放在公共倉庫里是不合適的,而且也不便于關聯(lián)相關的代碼。更不能在兩邊將相同的 issues 重復寫一遍。

好在 Github 里每個 issue 不僅有一個相對于本倉庫的內部鏈接,而且有一個全局的 URL 與之相關聯(lián)。
有了這個前提,我們就可以輕易的解決這個問題了。只需要在周 Review 里把下周即將要開發(fā)的 issues 以鏈接的形式寫進去即可。
由于 Review 是每周寫一次, 而且每個周每個人能開發(fā)的 issues 一般也就三五個,因此寫 Review 以及編輯其中的 issues 也不會成為什么負擔。

總結<a id="orgheadline8"></a>

上述就是我們正在實施的 OKR 計劃中涉及實際執(zhí)行層面的的幾個問題的總結,是針對前期遇到的一些問題的重新思考,隨著執(zhí)行的深入可能還會遇到其他問題,相應的解決辦法也會持續(xù)更新到此文檔。

<a id="orgtarget1"></a>

參考鏈接<a id="orgheadline9"></a>

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯(lián)系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發(fā)布,文章內容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 230,321評論 6 543
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 99,559評論 3 429
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 178,442評論 0 383
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經(jīng)常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 63,835評論 1 317
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 72,581評論 6 412
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 55,922評論 1 328
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,931評論 3 447
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 43,096評論 0 290
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 49,639評論 1 336
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 41,374評論 3 358
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 43,591評論 1 374
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 39,104評論 5 364
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發(fā)生泄漏。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 44,789評論 3 349
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 35,196評論 0 28
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 36,524評論 1 295
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 52,322評論 3 400
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 48,554評論 2 379

推薦閱讀更多精彩內容