閱讀《MegaEase 遠程工作團隊協作協議 v1.3》後的一些感想

閱讀《MegaEase 遠程工作團隊協作協議 v1.3》後的一些感想

原文鏈接 https://coolshell.cn/articles/20765.html

從僱員的角度,談一談它對工作態度和實踐的啓發。

基本原則 Principles

  • Ownership & LeaderShip
    這是動力和激情的源泉。對所作事情要有責任感和使命感,而不是敷衍了事,得過且過。說的通俗點,就是把工作這個事當成自己的事兒,而且是自己的很重要而崇高的事情。當然,有些事情和項目的確不能以自己的意志轉移的,的確就是提不上勁兒,那就做好自己那塊,乾脆儘早抽身,及時止損。
    另外,具備Leadership並不一定是要當上領導,而是使自己具備如下特質:在周圍的人中能力突出,經常幫人解決問題,因此也被人依賴。

  • Initiative
    主動,主動再主動。積極的態度,主動的行爲。主動發現問題,主動解決問題。不要擔心提出傻問題、傻方案,時間會證明你的明智。人都有惰性,懶於早起,懶於早去解決問題。拖延和迴避,在工作中不是解決問題的好方法。

  • High Standard
    自始至終的高標準,即使臨時妥協,事後也要思考重構。

方法論 Methodology

金字塔原理:”想清楚,說明白“。其實說和想是一回事,唯一的區別就是,從想清楚到說明白,中間就差自信可靠的記憶。

  • 邏輯:不論是思考還是表達,都需要有邏輯。搞懂邏輯。

    • 推理論證兩種模型:演繹和歸納
      • 演繹:從通用到專用,從抽象到具體。將共性演繹到具體的性質。
      • 歸納:從特殊到一般,從具體到抽象。歸納出共性。
    • 常用的邏輯關係:
      - 因果關係
      - 相關關係
      - 演繹關係和歸納關係
      - 例證、引證和話證等。
  • 表達基本原則:結論先行,以上統下,歸納分組,邏輯遞進

  • 順序原則:先做重要緊急

    • 時間空間順序。很多時候,二者可以彼此轉換,重時間不重空間,重空間不重時間。一般而言,時間的敏感性更高些。
    • 重要性順序:人爲設定的優先級順序。
  • 一些常用方法

    • 表述性:SCQA(Situation情景背景,Conflict衝突發生了什麼事,Question疑問,Answer答案),適用於演講中描述事情、吸引注意力等
    • 總結性:STAR(Situation, Target, Action, Result),使用於職場總結、彙報,項目覆盤,簡歷製作等。
    • 日常工作:3PS(Problem,Plan,Priority和Summary), 適用於每日進展跟蹤,團隊成員間進度公開等。
  • 開始構建和使用金字塔:結合從上到下和從下到上的思考方向。

    • 從上到下:明確目標,確定理想,將空中樓閣慢慢落地。
    • 從下到上:從肯定要做且能做的做起,逐漸逼近小目標,進而實現大目標。
  • 應用示例:解決問題的過程,是以上各原則和方法的糅合的藝術

    • Situation —— 事情的背景
    • Target ——解決問題想要到達的目標。
    • 3PS —— 肯定有問題,問題是什麼?問題的原因(因果),與何想幹(相關),對已知事實、原因和相關的演繹與歸納。制定解決問題的計劃,從上到下和從下至上,優先級,做事的順序等。
    • Action —— 執行,貴在堅持,不斷反饋思考,對子問題不斷進行3PS.
    • Result 結果
    • Review 複查

實踐 Practices

  • Documentation Driven
    文檔,是一種深度思考的沉澱,是持久化的記憶。寫文檔的過程,也是輔助思考的一種過程。
    在整個的開發流程中,文檔可以很輕很敏捷,但不可以沒有。文檔是應對團隊結構變化、成員流動帶來的風險的有效辦法。
    做好代碼和文檔的統一。

  • Review
    重要的問題、方案和實現之後需要Review。 反思是進步的源泉。

    • Idea Review, 重要的想法自己想出來了,不要急於去實現,而是想象自己站到客觀的接受者角度,想想有沒有什麼重大bug或不妥。然後Share出來,讓大家也都聽聽看看,拋磚引玉,有時的確非常有用。
    • Design Review,一個好的設計文檔需要包括如下幾項:
      • 背景:事情的上下文情況,暴露出來的問題或痛點
      • 目標和意義
      • 解決方案:提出多個方法,進行優劣對比。令人信服的引用和數據。方案的優點和缺點。
      • 結論。
    • Code Review,代碼審查是編碼質量的基本保障,反向促進編碼人員的水平提升。
  • 3PS Update
    Problem,Plan,Priority和Summary. 每日開啓工作前,確定問題,制定計劃,分配優先級,對當前工作有個清晰的總結性認識。制定計劃是門學問,每個人都需要有自己的 milestone 計劃, 這個計劃最好是在2周以內,1周內是最好的。對於更細的每日計劃,可以嘗試使用“吃青蛙”理論,即那些在你腦袋中始終嘀咕、揮之不去的念頭儘早進行落地實踐,清空大腦纔會爲更具創造性地想法留下空間。可以對事務按重要、不重要、緊急、不緊急劃歸象限,重要緊急永遠第一位的,重要不緊急或緊急不重要都需要儘量分解到不緊急不重要或重要緊急。

  • Effective Meeting
    當然,3PS 也適用於會議。會以必須有議題,而且最好還有議案,與其對議題泛泛而談,不如就一個現成的提案進行實質性討論。會議期間不解決問題,只對問題的後續解決進行跟蹤(落實到人)。會議必需要有共識和結論。因此,可見會議前也需要發起人做相應的準備工作,包括如下分類:議題的收集、議案的提出(小範圍的討論)和參會人員的選取和信息同步等。

  • Disagree and Commitment
    決策制定之前,鼓勵充分的分歧、討論。一旦團隊形成決議,團隊的成員就必須支持這個決議,並在這個方向上做出貢獻。這是團隊效率和凝聚力的保證。

  • Simplification & Automation
    大道至簡。簡化你的代碼中的函數、類和API,簡化你的系統模塊,簡化流程,簡化會議… 自動化是一種高級的簡化。避免人肉運維。“人管代碼,代碼管機器,避免人直接操作管理機器的人肉運維”。

  • Calm Down
    時刻保持冷靜。避免衝動,特別是涉及線上、交付的工作。充分測試,充分思考,越是重要緊急,越要充分的考慮。

發佈了19 篇原創文章 · 獲贊 1 · 訪問量 2137
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章