隨筆：
印象中，大約是2015年，在top100（也可能是Qcon）自助餐廳見過一次鄒老師，那時候應該是《構建之法》第二版剛出吧，那時候，隱約覺得能軟體行業寫書的人肯定就算是大牛級的人物，那時候對書的認識也很淺薄，一來因為讀書少，二來讀過的書主要集中在教材課本類或小說類，因此會覺得專業類書籍想必是很晦澀很枯燥了，這個想法在2017年讀到《構建之法》之后被推翻了，頻繁穿插小故事，重點突出“人”而不是反復強調“事”，這樣的風格做為大學教材，真是一件讓人眼前一亮的事，
那時候的我，畢業4-5年，并沒有太多管理意識，憑的是自己做人和做事的基本準則，和分析問題的基本邏輯思路開展作業，2015年開始，很晦澀的看了德魯克的《卓有成效的管理者》，隱約形成了自己的一些管理的點，通過這些年的實踐，逐步把這些點串起來成了自己的線，能夠把整個“產品研發”的流程串起來，這期間對專案管理識訓比較大的，應該算是為期半年的CMMI培訓，啃掉一本大約2cm厚的英文版CMMI教案，當然這程序有同事一起參與，還有培訓老師的講解，難度降低了很多，后來讀《TCP/IP詳解》（卷1），也算是一個大部頭了，后面也主要是當做工具書了，關于“書”的另一個人生的轉折，應該算是初為人父的那段時間了吧，懷著對新生命的敬畏，我開始閱讀與兒童有關的書，也引發了我的閱讀興趣，
今年在公司的職位發生了一些變化，總想著怎么給自己一個重新開始的起點，正好有個能和鄒老師溝通的機會，那自己就再努力一把吧，規劃著把家里重新規劃了一下，在一個房間的角落放上一張桌子，電腦也從書房挪了過去（書房會有人休息），擺上簡單的必備件，支起一個小書架，擺上一盞小臺燈，仿佛回到了“寒窗苦讀”的學生時代，還真是有幾分感懷，想著給自己定一個短期的目標吧，一年內讀10本書，書單我還在策劃中，有些即使讀過的，也拿出來重讀一遍，每一本書寫一份完整的隨筆感受，其實這一篇隨筆寫到現在，我也發現了距離上一次我寫這么大段的文字已經久遠到記不清了，想想曾經在學生時代，每一期校刊都能找到我的作品，以至于畢業多年的一次聚會，我有個老師見到我的第一句話，問“你怎么還沒去當作家”，現在自己文筆已經退化到無法形成段落、形成章節、形成目錄的程度，都是很隨意的一些思維片段，這才發現要寫好一本書，是多么不容易的一件事情，不斷看、不斷寫、不斷回看、不斷修改，如此回圈，才會有進步，其實讀書不是目的，真正的目的在讀書背后的那個識訓，但目前也許是沒想清楚，也許是語言匱乏，就是沒法準確的把根本的目的描述出來，所以索性就讓這個目的在程序中逐步清晰，實踐（讀書）變成目標，可執行性應該就要強很多了吧，
至于計劃，目前每天晚上10點~11點，這1小時我基本都是可以空出來，那就暫定每天晚上排出這1小時來完成目標，每天用便簽，做當日的簡單小結，可以更隨意和凌亂，每周更新一次博客，做一次匯總，（1周7小時，1年416小時，每本書大約40個小時讀完），
《構建之法》：
這本書我在2017年看過一大半，我本身是硬體出身，沒有太多軟體開發經驗，寫過幾年邏輯編程語言（VHDL/Verilog），后來專案需要，做過嵌入式的韌體和應用軟體的部分修改，但代碼量應該比相同作業年限的軟體工程師要少了許多，
重讀這本書，我首先翻開目錄，打算開始從與自己目前的問題相關的章節開始入手，第一個章節我選擇了“第3章 軟體工程師的成長”，談到工程師的成長，首先談到的能力的衡量，讓我想到最近和某個同事聊到關于價值體現的問題，價值，很多人看起來是很抽象的一個詞，因為團隊里面很多人，沒有辦法很確切的表達自己的價值，
這里面存在諸多問題：
1、團隊對個人的期望，并沒有很清晰的表達出來，總是指望個人從職業性的角度，自己去悟（不具備主觀能動性？），
2、個人有很多情緒化的行為，準確說就如鄒老師所描述“存在思維誤區”，“麻痹分析”、“不分主次”、“過早優化”、“過早泛化”，
3、個人對職業發展思考的深入度不高，普遍還在第2級（養家糊口的作業）的層面，甚至更低，（這個可能我了解的存在片面性，但在執行時的效果就可以感受的出來）大部分處于下面這種的狀態，
“我就會這點手藝，至于手藝高不高，擱平時我是不愿意承認我不行的，但是一旦專案的難題來了，復雜度高了，我是不會的，我能做什么，我不關心，領導自己看著辦，”
- 這么說可能有點打擊團隊士氣，但最后的事實就是一旦爆發了稍微有復雜度的問題，能主動進行問題分析的人實在太少，都是被動的心態，這樣就導致解決問題的效率實在太低，而且我在里面需要花費大量的時間進行分析和協調，也可能我早期保姆式的管理方式有關，早期，因為人員離職等原因，我一個人對整個專案的熟悉程度遠大于當時的專案團隊其他人，大部分問題，都是我進行完整分析后，分解成很多小問題，再給到其他人處理，如何逐步變換自己的管理方式，這是個問題，
近期，公司也在重做績效考核，關于如何用客觀資料來度量團隊、個人的價值，是應該思考起來，而以前很多時候全憑主觀的判斷，存在不準確性、不公平性，或者大家吃大鍋飯的形式，這都是很危險的，但度量項的設計也確實是一項很考驗“理性”的作業，思路不應被“感性”所干擾，（我自認為應該是一個相對比較“感性”的人）
問題：
想到一個問題，關于當前團隊的狀態，我作為專案組帶頭人總需要疲于奔命的應付外部的一些問題，這些問題反饋給我，我需要根據我對系統的理解，將問題分解并進行逐步定位，分解成很多小問題，再給到其他人處理，如何逐步變換自己的管理方式，（文中已提到）
關于人的問題，1（組長）+3（組員）的模式，天花板往往會被1（組長）限制住，有時候跟組長討論一個問題，組長的理解可能存在偏差，導致由技術原因往外推脫某個需求無法實作，但說不定有組員是可以修正這個偏差的，但是處于層級關系或同事關系（層級關系其實并不明顯），不方便表達，又或覺得怕會多事，這時候，往往需要我花較多時間去確認這個技術原因，而且可能也會造成一種不信任感，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/219396.html
標籤：其他