技術管理學習筆記，總結，覆盤，思考，優化，不斷前行

1. 前言

程序員不單單隻有技術的深度，更應該有廣度的提升，比如產品思維，項目管理，運營，時間管理，溝通，領導力，.壓力管理，衝突管理，目標管理，經濟學，博弈論，商業模式，財報入門等等.

看看程序員，技術主管(Leader)，架構師有什麼區別：

技術管理最重要的兩個任務：

完成工作目標.
培養下屬.

在我眼中，我認爲技術管理並不是真正的純管理人員，只是一個懂技術的服務人員與領路人，有時候可以說是你成就了大家，倒不如說大家成就了你，也可以說是大家雙贏.

技術管理者需要爲團隊成員服務，有人需要資源就給協調資源，有人不明白目標就幫助他明確目標並制定其個人目標，
不同的模塊間接口無法確認就組織相關人員討論，xxx任務完成的好就給予明確肯定，
xxx所從事的技術方向迷茫就協助找到發展方向，
有人突然情緒低落效率低下及時發現背後的原因並在必要時提供支持… …(感覺是不是像保姆)

影響力的六大原則也是應該知曉的：互惠原則，承諾一致，社會認同，喜好，權威，稀缺

激勵別人無非就兩個因素（基礎因素與動力因素）：

技術管理者還需要幾點，以身作則，勇於承擔責任，共情能力，時刻牢記公司，團隊，項目目標，情緒控制，不傳遞負能量，不恥於下問，覆盤等等.(慢慢改變吧!!!)

團隊leader 負責工作羅列:

促織線上Carsh的修復
組織線上突發BUG
排查每日客人投訴的問題
解決團隊遇到的技術難題
組織每週 Code-Review
組織每週例會

團隊Leader一定要明確兩點：

不要給自己分配具體的需求開發，會發現，管理工作會消耗掉你大量的時間
努力不要使自己成爲瓶頸；很耗費時間的事情，及時分配到具體的開發人員。BUG如果都集中到自己手裏，那麼一定要及時分下去；

那些工作今早分出去給具體的開發人員呢？比如 Android項目的打包，代碼混淆，設計 Lib 框架，技術調研，Monkey日誌分析；

保持內心強大

要學會帶領團隊成長，不要事必躬親
要多進行思考
要學會風險管理
要保持內心的強大
要學會邀功(要給團隊成員邀功哈)

技術管理者的核心能力是什麼？

技術判斷力（某個技術項目“要不要做”，要做的話“能不能實現”，是否適合現在做，還要考慮技術風險，項目管理複雜度，成本等等，遠遠超出以前寫代碼的範疇）
技術判斷力包含
1.對結果的判斷(這個事情做還是不做，用什麼樣的指標來衡量它的好與壞，比如：開發人員提出要用Flutter對現有App進行重構，你要給出一個判斷做還是不做。技術人員想玩一玩新技術，而你作爲技術管理者，考慮的是現階段公司App的關鍵問題是什麼？假設說是App穩定性、開發速度不夠快，那麼Flutter作爲一種新技術框架，能不能解決現有的問題？如果不能，那麼現在引入它也許還不是最好的時候，可以安排一兩個技術人員做預研，開始關注這項技術。)，
2.對技術方案的判斷(對技術可行性、可維護性、成本收益等方面進行判斷，通常在技術方案評審環節給團隊進行指導)，
3.對風險的判斷(技術風險、項目執行風險、團隊風險等方面。技術管理者利用自己的經驗、思考分析、團隊討論等手段，識別出主要的風險，並採取措施進行規避)
提升技術判斷力，
1.團隊日常技術和產品工作彙報(獲取信息反饋，驗證技術判斷的大好時機，看看自己之前的技術決策產生哪些影響，有無需要調整的地方，也可以學到下屬們的思考和經驗，及時更新自己的技術和產品認知)；
2.參與技術方案評審(儘量參加，結合自己的理解和經驗給團隊反饋，架構判斷力也得到提升)；
3.主持系統頂層設計和規劃(擔任或主持系統頂層設計規劃，業務架構規劃，系統各層的劃分，子系統之間的數據交互協議，技術框架選型，系統容量規劃等等，從技術整體架構把控，再由團隊進一步展開更細的規劃)；
4.持續學習新技術(技術管理工作，並不是完全丟棄技術，只是放棄大部分代碼工作，新技術的學習不能停止)。

CodeReview(代碼評審)

每週技術分享 每週一次，每次1個小時，單週(技術Leader)，雙週團隊成員輪流。Leader 主要偏內核修煉(比如設計模式，架構設計，等等)，團隊成員偏實戰中的經驗和心得體會，具體到代碼和項目層面.(比如優化，重構用到的東西等等)；題材可以不限制，當然也可以按照大家掌握的技術點打分，進行有效的技術短板提升；

2. 技術提升

每天進步一點或者看一會書，1個月，1年，堅持下來，慢慢就提升了，時間複利就是我們最好的朋友
程序員的主流成長髮展路線，是明顯的“T”形路線，縱深是技術的深度，橫向上，是廣度方面的，當然也包括技術專業之外的領域。

建議看看《認知天性》中說的後刻意練習時代:
1.學習的東西需要進行檢索
2.穿插練習，有助長期記憶.
3.反思是檢索的一種
結論：平時可以嘗試技術分享，講解給別人聽，重構代碼，嚴格要求自己，寫DEMO，或者自己寫一個小項目等等來檢索或者練習自己學習的設計模式，性能優化，自定義view，動畫等等知識點，有問題的再重點去學習，掌握. 後續也可以進行一些總結，反思，優化.

OKR目標管理學習：
平時很忙如何學習，建議做好年計劃(列出目標與關鍵結果)，分解爲月計劃，再細緻分解到周計劃，然後每週或者每個月檢查成果.

** 產品思維提升**
人人都是產品經理

運營瞭解

習慣養成指南：

提升的途徑有幾種方式：

閱讀優秀源碼，不只是單單閱讀，要理解別人爲何這麼做，要是你做會如何做，最後可以嘗試自己寫一個類似的檢索與練習下.
用指標嚴格要求自己: 代碼風格，內存，CPU，APP大小等等優化，交付時間，BUG率，冒煙測試通過率等等
講給別人聽，就是可以做一些分享，或者平時解決問題，能不能說明白原理，眼睛過的，不代表你真的懂.

業餘時間：

看看程序設計相關的書，文章和博客(不斷的吸取新東西，也可以寫一些小DEMO驗證)
參加一些技術主題論壇或會議
寫寫技術博客（輸出是一種提升，也在於總結和提煉知識）
創建自己的業餘項目(比如我寫的 AndroidTVWidget， android-tv-frame-new，實踐所學，獲得新的技能或加強舊的經驗，完整的經歷一次創造)

高質量文章編寫
首先，如果你寫文章的目的是爲了給自己看，那怎麼寫都無所謂，如果，你寫的文章是給別人看的，那麼感覺應該是這樣的：
1.針對簡單概念，你要介紹的全面，理論配合demo，能夠讓一個不懂的人看了之後懂了
2.針對有點難度的概念，你要一步一步地詳細介紹，讓剛入門的小夥伴們能夠仿照你的例子做出來
3.針對底層的東西，比如源碼，你要能把大致流程說清楚，並且能夠結合源碼分析出上層的東西。
這是寫一篇好的文章所應該達到的，總之，我們要明白，寫出來的文章主要是給別人看的，寫的時候要考慮這麼一個問題：如何寫才能讓別人更好地理解，這樣，好文章自然就出來了。

技術演講與分享

Who-What&When-Why-How-Future-Recap
Who: 自我介紹，讓聽衆瞭解自己，建立連接；
What&When: 今天要分享的主題，通過簡短介紹吸引聽衆的注意力、好奇心；
Why: 爲什麼要做這個架構改造、技術升級，整個項目的背景是什麼樣的，結合對聽衆的瞭解，做特定的介紹；
How: 深入淺出 3~4 個最核心的內容點，當然爲了全面性，你可以都羅列出來，但介紹的重點建議控制在 3~4 項；
Future: 讓大家瞭解你未來的計劃，你對技術趨勢的看法等等；
Recap: 對今天的主題再做一個回顧，讓聽衆加深對核心內容記憶。

技術人員的會議如何高效開
高效會議

怎麼提高英語水平呢？

使用google，直接英語關鍵字查詢資料，閱讀資料
需要買的書，有英文版的，就絕不買中文版，剛開始一兩年的閱讀速度會很慢，後來就好了。
學習視頻課程時，儘量看國外的公開課，不要開字幕，集中所有的注意力去聽，去理解，一兩遍不行就多遍。
自己做筆記、日記都換成英文來寫，不斷的迫近英語思維方式。
至於說口語，對於絕大多數人來說不怎麼重要，等你每天都需要用的時候，再去刻意地練習。

避免能力陷阱

做的越多就越擅長，越擅長就越願意去做。這就容易被你當前的狀態所侷限。
這樣的一個循環能讓我們在這方面獲得更多的經驗，但卻容易陷入能力陷阱，在其他方面無法突破。

學會延時滿足
第一個原因：做事從不分你我。做完自己的工作後，對於大部分同事的問題，只要能幫助解決，儘量都去做。所以成長得非常快。第二個原因是，做事從不設邊界。負責技術，但遇到產品上的問題，也可以積極參與方案的討論。很多人說，這個不是我該做的事情，但做這些事情讓我得到了各種鍛鍊，這對個人之後轉型做什麼有很大幫助。

哪些事情儘量少做(雞湯)

當某個事情產生短期快感，建議少做，比如熬夜刷手機，看抖音，玩遊戲，深夜擼，睡懶覺。做一些長期堅持收益巨大的，如讀書，學習，健身，理財；
痛苦與想回避的地方，越能讓我們成長；跨越
永遠記住，身體健康是根本；不要以熬夜加班爲光榮了，身體真的出問題，後悔莫及；

3. 項目管理

如何分配任務，跟蹤進度，溝通，等等，是一個剛進入技術管理者應該必備的技能.

項目有三大目標：時間、成本和質量

項目幾個要點：以目標爲導向，以計劃爲基礎，以控制爲手段

後來在工作中我每天都嘗試着問自己這些問題。
時間：項目計劃在什麼時候完成？有哪些工作，分別在什麼時候完成？是否發生了偏差？如果有偏差，怎麼處理？
質量：軟件功能完整嗎？軟件操作方便嗎？運行結果正確嗎？運行效率夠快嗎？軟件代碼符合規範嗎？客戶用起來滿意嗎？

按照公司，團隊實際情況，合理應用項目管理手段（比如敏捷，瀑布等等）.
在開發前，建議項目的團隊成員需要知道任務的優先級，尤其是多任務並行的時候.
也可以善用清單對於項目各個環節進行把控檢查.

避免被動管理
這裏需要避免進入被動管理(消極管理)，任務分配不代表就結束了；
被動管理就是一開始不做計劃，也沒有風險評估和備案，開發過程中也沒有定期跟蹤任務狀態，更沒有根據成員的工作狀態調整計劃，驗收的時候出現延期或者各種問題又或者導致被動的趕進度加班；被動管理對個人，團隊，公司，被害而無一利；
所以需要做好計劃，風險評估，備案，定期跟蹤任務狀態，調整計劃；

3.1 技術管理者進行項目管理主要解決幾個問題

建議拿到或者討論項目或者需求，第一件需要做的事情就是技術可行性評估.
項目或者需求，我感覺執行應該符合 Smart原則.
各個項目需要分清輕重緩急.

先不要急着給出承諾以及開發計劃，先了解幾個方面：

背景瞭解一下，爲什麼做這個事情，解決什麼問題，目的不明確的不接.
做哪些東西，具體的需求內容，不知道具體內容的，不接.
最傻屌的需求舉例：做一個聊天軟件，我做你TMD，聊天有那些具體需求內容哈，範圍那麼大！！！
郵件需要發出來(至少你的上級應該知道這件事情)，還要有需求規格文檔等等.
還要了解他們是否已經需求，設計評審過，沒有評審，儘量不要接.

根據我多年的瞭解，項目失控往往有幾個原因：

需求不到位
問題主要表現幾個方面：
(1) 需求/原型/設計圖評審太隨意，導致後續改來改去
(2) 產品需求與技術人員脫節

沒有指定完整的項目目標
問題主要集中在需求方面：
（1）需求過多，系統過於龐大、複雜；
（2）需求不穩定，用戶無法決定他們真正想要解決的問題；
（3）需求模棱兩可；
（4）需求不完整。

拙劣的計劃和評估
對項目的難度和工作量評估不準確，導致項目的進度永遠達不到進度表的要求，並且被無限期地拖延下去。

採用新技術
新技術的採用，有時的確可以極大地提高生產效率，並解決一些棘手的問題，幫助項目最終成功。但同樣可能會引出新問題，給項目的失敗埋下禍根：
（1）項目組成員對新技術掌握有限，並且迫於項目進度的壓力，很少有機會去深入地研究和實踐這些技術；
（2）新技術不一定成熟。

缺乏或根本不具備項目管理方法
項目經理不懂管理，沒有“章法”。這種情況下項目經理有兩種做法，一是想到什麼做什麼，胡亂出招；二是等事情做，有問題才覺得工作很充實。這兩種做法的最終結果都是一樣的：項目問題不停冒頭，成爲了“打地鼠式管理”方式。

團隊中缺少資深人員
資深人員通過其豐富的經驗（特別是失敗的經驗），可以給項目組提供成熟的解決方案，幫助項目組識別風險、解決突發事件等，如果缺少資深人員，項目陷入失控的概率就會大大增加。

硬件/軟件供應商的低劣表現
將項目中的部分工作或產品外包，是很常見的事情。如果供應商不給力，有時只有乾着急的份。特別是國內層層轉包的情況，導致真正幹活的人費用非常低廉，根本無法保證進度和質量。

質量無法滿足要求
質量達不到要求，導致項目失控也是很常見的。功能做了一遍又一遍，每次接近一點，卻始終不能達到。如果性能或可靠性存在問題，還有可能給客戶造成重大損失，帶來更加嚴重的後果。

項目受控

保證目標和計劃的可行性
採用成熟可行的技術方案
密切監控項目狀況
保證團隊和諧，激勵員工士氣
時刻將質量銘記於心

3.1.1 任務分解

任務分解需要搞清楚幾件事情：

做成什麼樣子，demo? 提測？發出去的版本？問清楚才能開始做任務分解，因爲影響開發的時間以及質量問題.
什麼時間完成，截止日期，沒有具體的截止日期不做. (影響質量，開發的時間，排期等等，需要根據具體的開發週期商討磨合)
資源是否到位(設計，測試，其它部門，外部協助等等)，協調資源.

顧名思義，就是將一個項目分解成N個小任務，參考敏捷開發的需求池概念。
開發任務分解(將一個或者多個需求分解成幾個開發任務)，定人，定時間(開發週期)。
技術選型(適配分辨率，Rxjava，網絡請求庫等等)，架構，技術難點，風險需要暴露出來，包括選用新技術也需要考慮幾個方面(學習，招聘，時間，機會成本，風險也需要考慮).

比如，開發一款影視工具，有影視搜索，影視詳情等等. 影視詳情可以分解出很多小任務或者實際的開發任務(API接口 2天，界面 3天，邏輯代碼1天，設計資源等等)

1.對於需要使用的新技術，要估算學習和調研的時間。(新技術引入的成本)
2.我們需要編寫什麼樣的接口？
3.我們需要創建什麼樣的架構？
4.我們需要更新哪些表？
5.我們需要更新或是編寫哪些組件？
6.根據統計，每個程序員每天的有效工作時間是5個小時左右，其他時間都被溝通，喝水，休息，上洗手間等佔據，所以如果某個任務估算超過5個小時，那就代表了這個任務完成需要超過一天的時間。
7.對於開發任務，估算儘可能的細，一般來說，每個任務的估算不應該超過5個小時，如果超過5個小時，就應該再把這個任務細分。只有儘可能細的估算任務，總的時間是大概精確地，因爲估算時間是一個正態分佈，有的任務估算的時間偏大了，有的時間任務估算的時間偏小了，估算越細，總體下來估算還是準確了。

3.1.2 任務分配問題

注意幾點：

不要擔心別人做不好，學會授權，輔助培養.
多給別人選擇的機會.

也可以嘗試改善分配工作的方式：所有任務列出來，然後進行分配(每個人從任務池挑選適合自己的，自己想做的)

3.1.3 進度跟蹤

不是安排了開發任務就放任不管了，需要進行進度跟蹤。
可以每天的站會也可以單獨的溝通，主要是爲了提前發現問題，對進度，風險把控。

站會需要關注的3個問題：

昨天做了什麼？
今天準備做什麼？
需要哪些同事配合或遇到什麼困難？

站會注意事項：

避免討論具體問題，會議後私下討論。
時間最好爲5~15分鐘之內。

站會只是提了一個方式，根據實際情況而定，如果大家都加班到了10點，你還一大早9點開站會或者開會同步問題，我想大家心裏一定是TMD的，換位思考，共情下.

3.1.4 多任務並行如何處理

將所有的需求列入需求池，按照每週的開發計劃來，不急就排到下週或者下下週，排期.
如果真的很急，那就找上上級以及相關人員商討，任務的優先級，看看那些需要扔出來的.
比如有需求 A1, A2, B1, B2 正常弄，中間插入 C1，說的很急，必須這周完成，那麼找上上級以及相關人員商討，如果B2優先級不高，那就排到下週去.
多任務並行需要考慮優先級，人力資源等等問題.

4. 目標管理

作爲技術管理，一定要確保團隊目標與公司目標一致、個人目標與團隊目標一致，只有這樣，才能產生協力，有效實現預期。
讓每個人都有參與感(共同制定團隊目標和個人目標. 讓員工參與到上層目標分解到團隊目標，團隊目標分解到個人目標的過程)
三種目標(公司目標，團隊目標，個人目標)[必須符合Smart原則]
團隊，公司，個人目標一致，才能產生協力，有效實現預期.
要將團隊成員的個人目標與團隊相結合，就必須理解下屬的痛苦，快樂，爲何在這裏工作等，
針對每個具體的個人來考慮團隊目標對於他個人的意義.

Smart原則：

OKR(“O”就是目標，—Objectives，“kr”即關鍵結果——Key Results)

比如定了目標，提升團隊的10%效率，關鍵結果有公共庫，統一開發環境等等.

5. 時間管理

四象限法則：

6. 壓力管理

從一個程序員走向技術管理崗位，壓力真的很大，原來只是管好自己就OK拉，現在不僅要管好自己，還要管理下屬，還有和其它部門溝通，還要面對領導以及更高級的管理，更悲慘的是，你還要對整個團隊的結果以及成長，狀態負責任到底；

新任技術管理會擔心自己不稱職，擔憂別人對自己的看法，評價，這些心理和情緒活動，會帶來連綿不斷的壓力；

情緒控制很重要，如果情緒失控，受到壓力大喊大叫，推卸責任，逃避，沮喪，團隊的成員也會慢慢變成你的樣子，可怕，可怕；所以，要儘量避免用消極的行爲應對壓力，要努力積極的面對壓力，用於承擔責任，一起以解決問題爲目標。

學會暫停：當領導批評你，同事指責你，下屬埋怨你，產品經理懟你，… …先暫停10秒再來反應，避免被打或者逃的本能控制；可以建立儀式化幫助控制自己的情緒(比如默唸三聲“解決問題”或深呼吸三次或閉眼10秒鐘)
問問自己下列問題：

真正的問題是什麼？
自己這麼做，有助於問題解決麼？
自己的目標是什麼？
自己這麼做，能實現目標麼？
淡定，不控制情緒，會讓自己現在或將來惹禍上身麼？影響工作發展麼？
會弄僵自己與他人的關係麼？
給別人帶來傷害麼？

宣泄情況應當以不傷害他人爲原則

常見的宣泄方式：傾訴(家人，朋友，同事，心裏諮詢師，陌生人傾訴，書面傾訴—壓力日記)，聲音(比如大笑等)，哭，運動(健身，散步，跑步，爬山，羽毛球等)，睡覺，冥想

7. 衝突管理

競爭：高度堅持不合作(強迫政策)，犧牲一部分的利益，換取自己的利益或團隊整體的利益，特徵是正面衝突，直接發生爭吵，爭論或其它對抗方式，爲了取勝不惜任何代價；
迴避：不堅持與不合作，雙方意識到衝突存在，試圖忽略和放棄衝突，不採取任何措施，也不維護自身利益；
妥協：中等程度的合作；衝突雙方都讓出一部分要求和利益；特徵就是沒有明顯的輸家和贏家；

8. 溝通

溝通是無論技術人員，還是技術管理者，都應該必備的被動技能

溝通一般有兩個目的：1. 獲取或同步信息；2.達成共識，得到承諾；

有效的反饋機制：

自我評估：項目評估，關鍵目標分析.
下屬的反饋：一對一溝通，週期性會議
同級的反饋：一對一談話，郵件等.(同級可以是其它部門負責人，比如測試，產品等)
上級的反饋：主動，持續，週期性的讓上級給你反饋.
結論：向他人收集反饋，事先準備話題列表，提高溝通效率. 收集反饋信息後，進一筆分析，分出正面，負面. 只有將反饋與經歷結合，煉化成經驗和教訓，才能指導後續的行動，不斷進步.

8.1 溝通的幾個要素

1.溝通應該形成閉環
2.溝通最重要的環節，傾聽，第一，體現對對方的尊重；第二，通過聆聽別人把話講完、講透，更容易理解別人所要表達的真正含義。有效聆聽纔是溝通中最爲重要的。
3.還有最後一個，需要注意，情緒的控制，一切的溝通是圍繞解決問題的，不是爭吵，更不是牴觸情緒，會給別人留下不好合作的印象.

8.1.1 溝通循環四步

首先是傾聽，澄清傾聽後的理解，提出自己的觀點，最後確認對方是否瞭解我們的觀點.

8.1.2 溝通的三大要素

8.1.3 保持信息一致性

不要進行‘信息過濾’，對上要如實報告，對下要如實傳達

8.2 作爲技術管理者，日常的溝通分爲幾種

8.2.1 向上溝通

向上管理以及溝通搞清楚幾個問題：

表現符合上司的期待嗎？
上司信任你嗎？
瞭解上司的管理風格嗎？
上司有那些優點嗎？
瞭解自己的需求與期待嗎？
與上司討論過自己的職業生涯規劃嗎？
瞭解上司的文化背景嗎？
適應於多爲上司共事嗎？

需要做到的幾件事情：

喜歡你的上級，不要抱怨或者恨他，至少要理解他。積極配合老闆完成工作。
瞭解上級的處境，爲他排除萬難，助他一臂之力，讓你的老闆工作更有成效。
把上級當成鮮活的個體，摸透老闆偏好的工作習慣，向老闆的習慣靠攏。
瞭解上級的強項和弱點，代替老闆完成他不擅長的，無法照顧到的或者不願意做的工作。
讓上級知道你打算做什麼，不打算做什麼，正在忙什麼，目前處於什麼狀態。主動反饋。
珍惜老闆的時間和資源，不要用瑣事耗盡老闆的時間和經歷。
管理雙方的預期和目標。上級每年，每季度都會對你又期望。主動溝通，及時反饋，避免造成上級對你的期望和你自己的期望有偏差。

主動，持續，週期性的讓上級給你反饋，定期和上級溝通，瞭解他對你的評價，聆聽他的建議（一方面彙報自己的工作，讓他知道你的狀態，另一方面管理過程遇到的困惑拋出來，請他指點下）.

8.2.2 橫向溝通

8.2.3 向下溝通

其實，對待技術人員最要緊的兩個字就是——尊重。
如果我們能給他們足夠的尊重，他們就一定會配合我們的工作.(其實無論是技術人員，還是其它人，我們都應該尊重別人)
多和下屬溝通交流，瞭解他的生活，工作，真正地關注，關心，傾聽對方。（比如聊房子，車子，房貸，喜歡的球星，遊戲等等）

可以定期進行一對一的溝通，迴避與下屬的溝通，就是放棄了彼此瞭解，建議信任的機會，團隊會越來越消極… …

一對一溝通，首先對話前問自己（來自關鍵對話）：

參考談話過程：
1.開始時闡明目的，爲溝通定調：比如，“今天想請你幫忙我，我這段時間管理上做的事情有什麼效果”。“和你談談最近的工作結果，一起討論下一步工作安排”。等等
2.分享事實經過和你的想法：比如，“月初引入每日站會… …擔心給大家帶來負擔，因此想…” 。
3.徵詢對方的觀點，鼓勵對方做出嘗試：比如，“我想知道你對這件事的看法”。“我希望聽你坦誠地講講發生了什麼事情”。徵詢對方觀點，多用開放式問題。

8.2.4 其它溝通(外部客戶或其他合作單位的溝通)

9. 其它

9.1 思考方式

PDCA循環：計劃，行動，檢查，糾正

覆盤：回顧目標，評估結果，分析原因，總結規律

5W2H方法：Why爲什麼？What做什麼？Who 誰做？when 什麼時候做？where 哪裏做？how 怎麼做？how much 做多少？
Why爲什麼：爲什麼做這個需求？
What 做什麼：需要做哪些事情？
Who 誰：需要哪些人蔘與？
When什麼時候：事件範圍和具體日期？事件表？
Where什麼地點：在哪裏做？
How怎樣做:用什麼方法完成？計劃是怎樣的？怎樣做完成好？
How much：質量如何？做多少數量？做到什麼程度？耗費成本？

9.2 自我營銷

所有一切的價值，取決於你能給它人帶來如何的價值.
自我品牌風格，寫博客(高質量文章)，開源社區，開源庫，寫書等等.
品牌符號(統一的logo熊貓，網名冰雪情緣).
品牌是幹什麼的？TV開源愛好者.

9.3 自我相關

承擔責任：更多金錢還是更多責任，長遠看，正確選擇應該是更多責任
引人注目：記錄活動日誌提供演講或培訓，分享發表意見保證“曝光率”
自學：增加技能和知識，培訓課程，相應的資質證書，學會分享
成爲問題的解決者：解決別人無法解決或不願意解決的問題
關於辦公室政治：不與同事討論公司與其它同事不好.

技術管理學習筆記

文章目錄