随笔：
印象中，大约是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（组长）限制住，有时候跟组长讨论一个问题，组长的理解可能存在偏差，导致由技术原因往外推脱某个需求无法实现，但说不定有组员是可以修正这个偏差的。但是处于层级关系或同事关系（层级关系其实并不明显），不方便表达，又或觉得怕会多事。这时候，往往需要我花较多时间去确认这个技术原因，而且可能也会造成一种不信任感。