为什么现在开始谈这个问题？
大部分长期在 IT 行业的人都无可避免的走向新的方向，技术管理是其中之一。
今天看到一个视频，雷军在演讲时，谦虚的说自己在 29 岁时因为金山董事会没人出来领导金山，不得不临时成为了金山的 CEO。
虽然是大佬的谦辞，但仍然是可信的。
和很多传统行业不同，在 IT 行业，技术人员转管理往往是被"逼"的。
因为某些原因，或许是人事变动、项目压力等各种情况，基层的技术经理其实不是一个香饽饽，更多的是烫手山芋。
对于技术人员来说，最理想的情况是成为技术专家，在技术的乌托邦中颐养天年。
现实情况是，国内的 IT 公司在技术上并不会有多少优势，更多的是需要服务业务，通过实现业务来盈利，其竞争力往往不来自于技术本身。
这就让 IT 从业者的工作性质从技术研究者变成了工程实践者，需要做一些取舍，干一些脏活、累活。
而基层的技术管理者——技术经理，刚好处于这样一个特别的位置。
在生活中反映这一状态的是，很多技术交流群都在讨论技术管理，和同行交流时，话题最多的也是技术管理的话题。
我自己也在 Thoughtworks 这家以敏捷"著称"的公司工作，很多时候也需要成为类似技术经理的角色参与项目，而这家公司在项目管理上不得不说有"自己的一套"。
即便如此，也需要经过自己的思考验证，识别敏捷实践的局限性，并加以克服，才能在工作中更好的应用。
所以计划每周将日常收集到的技术管理问题整理下来，类似于系统设计相关话题一样发布到公众号上和大家见面。
会以什么样的风格来写？
我读过不少项目管理的书和文章，但是不得不说，对于技术管理而言，很难依靠书上的知识实践。
更多的情况是根据团队实际情况，制定一些合乎情理又能执行的政策。
因此，后续的内容会以实际项目的问题和案例驱动，通过提问的方式探讨一些话题。
例如：
- 为什么我们要做工作量估算？
- 为什么需要按照用户故事拆分工作任务？
- 为什么需要使用迭代？
- 为什么我们会坚持每日 Code Review？
通过问题不仅能知道怎么做，更重要的是需要分析出问题背后的根本原因。
其次，管理是一个非常难得能力，有个段子说的是 "但凡收过四个人的小组作业，也不会觉得管理几百人轻松。"
因此，大量内容可能是整理自一些社群的交流活动，一些内容来自和业内专家的对话、访谈。
可能在内容上尽量以对话录、故事、工作清单等形式组织。
最后，我在整理的过程也是学习的过程，达到和大家交流的目的，会尽量通俗、具体、口语化。
如何互动和反馈?
思想的碰撞才能让问题更加深刻，如果有任何技术管理相关的话题希望讨论，可以通过公众号留言、微信群等渠道和我联系。
进群微信 ID：shaogefenhao
谢谢大家!