该专栏中，最喜欢这篇文章了，因为最近做管理时，就遇到了文章中提到的，【平衡问题】。多谢老师指导。感恩。

总结一句话：分配任务时，你要对你分配任务的人有一定的了解，你认为这个人适合这项任务。同时这个人对任务要有正确的理解，能够做出合理的规划，并且这个人的人品一定要好。最后一项人品好最重要，前三项是可以后天培养，但人品是无法轻易改变的，所以一个人的人品决定了其职业生涯的高度。

读后感：在提出意见时不要直接了当的说出问题，要根据当前的场合、职级关系、性格特点、亲疏关系等多种条件进行判断，要就事论事不要加入个人情感，不要有批评对方的态度存在。提出问题时要对问题进行包装，可以采用“三明治”法，先表扬对方的辛苦付出，在提出建议，最后在肯定对方的能力。 个人感想：不知什么原因导致自己总是认为不要说太多废话，认为任何事物能够一句话就能说清其本质，才是能力的表现。处于这种心态，在平时的沟通、交流、讨论的过程中，总是不喜欢对自己的观点加以包装，沟通的过程缺少铺垫，和后期的收尾。这种想法需要改变。在以后与人的交流过程中，表达自己的观点时要做好铺垫和收尾，让自己的表达更加丰满，柔和。

每天在地铁上听一篇，今天是最后一节课了。安姐的文章内容朴素无华，好多地方很有同感。期待自己在极客时间的下一次进阶。

现在自己的解决方案是，带一遍新人，然后让新人把这个过程维护到公司的wiki上。新人看wiki 不能上手，说明wiki有不完善的地方，哪里有困难，通过带新人一次，印象比较深刻也有针对性的补充文档。通过不断积累，让文档不断完善，大部分问题都能通过这样的积累而解决。

我是做Android开发的，负责的是公司Android APP内的一个模块，整个APP是插件化的架构，即APP本身所在项目是一个空壳，通过配置来决定哪些模块会集成进APP。我们这边的做法是： Step 0. Push检查：在每次push之前，检查提交者是否已经自测过了自己修改代码相关的全部分支，并会生成一个自测覆盖率，提交到commit信息中。如果自测覆盖率过低，reviewee需要给出合理原因解释。 Step 1. Merge检查：在提交PR前，先进行代码静态检查，比如lint检查、组里资深工程师根据业务制定的“坏味道”检查等，这样可以避免绝大部分低级错误和常见的共性错误。 Step 2. 人工review，reviewer会指定一个资深同学和一个新人，资深同学把关，新人学习和了解其他同学coding的思路。同时也鼓励新人提出自己的见解，进行思想碰撞。reviewee是新人的话，reviewer会更加注重实现细节，会讨论和比较其他的实现方式；是资深同学的话，会更加侧重在整体架构设计上。 Step 3. 代码合入后，会走一个自动化的打包和集成工作。打包后会集成进APP，这个过程会在APP范围内进行全局检查，确保没有底层项目接口变更导致上层项目接口调用失败的问题。 Step 4. 集成后形成一个apk，然后跑自己业务以及整个APP核心路径的单元测试。这一步其实目前我们还没有，但我觉得是有必要的，正在计划推动落地。

非常清晰的项目流程，见树叶之前，先见森林。希望国内越来越多的互联网公司可以以此为标准，参考实践。

安姐的亲切睿智，令人喜欢。

所有发自内心的关心，才是真的关心。 一对一，给领导和下级之间打开了一扇窗户，想法和意见可以彼此沟通。 学会倾听，才是一对一最重要的事情。 谢谢安姐。

理想中的氛围和团队应该是，整体人性化一些，不强制，但是建立饱和度要求（一周加5小时？）。另外团队成员要有责任心，有想法，有目标，关键时候能打硬仗。这个在初期选人就很关键。年轻人（未婚无娃）时间更充裕一些，乐于探索和接触新技术，新方法，更有追求和冲劲，即使不在家也会继续学习，思考问题。