阿里感悟

http://ifeve.com/thinking-in-ali/
http://ifeve.com/grow-up-on-writing/
在此给大家推荐一本书《金字塔原理》 ，一种思考、表达和解决问题的方法，我目前的写作方式就是尽量遵循金字塔原理的。
http://ifeve.com/alithink-9/

如何才能突破自己的能力？

首先要做的是改变习惯。在阿里很流行的一句话是，当自己不舒服的时候就是自己成长的时候。比如老大和我说要学会到先规划再做事情，而不是想到哪做到哪。这句话看起来简单，但是做起来很难，因为要打破自己已有的做事习惯，就像你习惯8点起床，现在让你每天6点起床，你肯定会很不习惯。

如何改变习惯。

我看过一本行为心理学书叫《思维改变生活》，里面有个理论非常好，说的是观念和行为是能互相影响和改变的。 观念能改变行为，比如你的观念是认为由于自己从来没当过主持人，所以不能胜任主持人这个角色，于是不愿意尝试当主持人这个行为。行为能改变观念，但是当你真正当过一次主持人之后，得到了大家的认可，你就觉得没什么，主持人其实很好当，从而改变了你的观念。所以我们要勇于尝试改变自己的观念和行为。

改变哪些习惯。我认为有三点，第一点是要改变自己思考的层面，第二点是要改变自己做事的心态，第三点是要改变自己思考的方式，这也是我认为阿里不同层级之间的差距也是这三点。

思考的层面。要知道自己应该做什么。

• 更高的视野。是否有站在更高的层级来思考当前的工作，比如自己应该做什么事情。
• 学会规划。规划哪些事情未来可以做，哪些不可以做。如果你不会规划事情，你就在别人的规划里。

思考的方式。要知道自己如何做事。

• 要想办法提高效率。比如我们经常登陆到线上机器查看日志，有的人一台一台的查询日志效率很低，有的人则会想有没有更快的办法，一次可以多台机器查询到日志，后者效率显然比前者高，而且学会了新的技能。
• 思考能否能通过解决一个问题从而解决了一系列问题。不能只为解决眼前的事情而工作。
• 对要做的事情是否进行了全面的思考。
• 遇到问题，是会优先会找别人解决，还是先尝试自己解决，自己如何解决，有没有想过通过完美的解决这个问题，从而帮助团队解决了一系列的问题。

做事的心态。要知道自己如何把事情做好。

• 用心做事。比如最近我在定义几十个数据模型对象，如果自己不去思考对象之间的抽象和关系，全部按照别人给的文档来定义模型，可能1个小时左右就能定义完成。但是为了复用性更强，以后更容易维护，就要花数倍的时间，比如在定义模型的时候充分思考哪些属于一个对象里的属性，哪些对象用聚合，继承或组合。其实这个事情不难，所以我觉得这不是能力问题，而是做事的心态。
• 做项目还是做产品的心态。做项目是一次性的做完想着以后也不维护，做产品要考虑到可扩展性，做完了不仅能满足这次的功能，还能满足以后的扩展。
• 做事的心态能够决定未来能力的高度。

http://ifeve.com/new-employees/

第一。定计划

对于新员工一定要给帮主他们制定学习和工作计划，做到计划驱动学习，互联网开发要学的东西比较多，对于新员工生来说不知道该先学什么后学什么，学到什么程度。所以计划驱动比较重要，在工作和学习之前给新员工列一份详细的学习和工作计划，并询问下新员工这个计划有没有问题，能否完成。学习之前我会大概和他讲解下，让他有个概念。比如sofa是一个什么样的框架，它是用来解决什么样的问题的，它和你用过的框架有什么优缺点。

第二。执行任务

让新员工理论学习的周期一般比较短，主要是让他在实战中学习和成长，刚来几个星期就应该让他直接进入项目，从小需求开始做起，然后让他做一下需求的设计，导师要学会逐渐放权，不要总想着这个交给他做会不会有问题，他会不会做不出来。要给新员工压力，有压力才能快速成长。

第三。代码检查

导师也是在实战中进行辅导，主要是做代码审查和提问。

代码审查。对于新员工的代码，一开始需要花大量的时间帮做Core Review，逐行审查，审查出有问题的代码，和新员工讲清楚哪里有问题，应该如何修改，帮助其在实战中提高代码质量。做到让新员工每日check in代码，导师每日进行CodeReview。

用提问的方式提高思考能力。指导学生采用引导的方式比灌输的方式要更好些，学生遇到问题会提问，如果直接告诉他答案，他吸收的会非常少，所以一般我会采用提问的方式引导学生思考，比如这段代码还能进行优化吗？这两个SQL语句能不能合成一个？培养团队合作意识也会采用提问的方式，首先和他讲一个真实的案例，在XX公司里来了一位新员工，因为对系统不是很熟悉，文档又非常少，也没有导师帮他review代码，所以他修改代码的时候引发了一个严重的BUG，结果导致自己得加班到1点才解决这个问题。从这个案例中你有哪些体会？通过案例和提问让他意识到团队合作的重要性。

 第四。总结

总结是非常重要的一个环节，能够帮助新员工有战略性成长。总结分成两个步骤，肯定和建议。

肯定。在公共场合肯定他做得好的地方，在团队的项目总结会中提出表扬和肯定，肯定下他最近工作中做的好的地方。比如很擅长提问，做事情非常积极。肯定的地方就是希望他能保持住。

建议：首先给他一些成长的建议，然后再说说最近工作中有待改进的地方。

• 建议提高沟通能力。有时候同事问问题给出的描述信息太少，我必须通过不停的反问才知道他到底是在问一个什么问题，于是和他讲，沟通的时候要站在听众的角度来提问，提问的时候尽量多描述问题的细节，一旦听众听明白了就会马上回答你，否则听众必须通过不停的思考和反问去知道问题到底是什么，反问越少提问效率越高。
• 不要问重复的问题。说过的事情必须用东西记住，这样可以节约双方的时间。比如告诉学生开发服务器root的密码，就必须马上记在印象笔记里。
• 先思考再提问。如果每个问题自己都不思考就问导师，这样的成长就不容易成长，要养成百思不得其解之后再询问同事的好习惯。
• 定期提问。有问题首先先自己思考下，如果解决不了就先记下来，然后选择一个固定的时间一起提问。如果想到一个问题就提问，自己会养成懒得思考的习惯，而且会不断打断我的工作，影响工作效率。

写在最后。对导师的建议

作为导师在培养学生的过程中自己也会有成长，需要用心，有耐心和责任心。

• 用心沟通。如果新员工有需要改进的地方，要在私下说他有待改进的地方，并解释的非常详细，这样既不会打消新员工的积极性，也能帮助新员工提高。
• 指导需要有耐心，实习生写出的代码肯定存在很多问题，也有可能同一个问题反复出现，出现次数多了肯定会生气，但发现后指导就可以了，相信他不是故意的，下次会改正。不能一味的去指责他怎么会写出这样的代码，谁没有经历过这样的时候呢。指责多了反而会打消实习生学习的积极性，不利于学生的成长。
• 责任心。出现问题是自己的责任，如果由于实习生的代码引起的线上的故障或BUG，不要责怪学生，而应该责怪自己，因为自己没有严格执行CodeReview。
• 教学相长。不要抵触当导师，教学是相长的，在带学生的过程中，学生的很多问题能引起自己的思考，让自己学的东西能更加扎实，在教的过程中，自己要理清思路，整理好后和实习生讲，讲的过程中有一种温故而知新的感受，能够提高自己的技术能力。

降低成本的敏捷设计

如何进行敏捷设计？

• 分阶段设计。先设计必须要的东西，快速拿到产出，暂时不用的先不要设计，想不清楚的也暂时不要设计。没事的时候就多想想系统的设计有没有问题，有问题即时提出来，然后修改掉。
• 快速讨论设计方案。自己设计出来的东西先找某个同事简单过下，如果在设计评审中还有很多问题，那浪费的人日会更多，因为参与设计评审的人很多，不通过还要开复审。一只笔，一个黑板擦，一面玻璃板足以完成一次设计，用笔直接在板上画一下自己的设计思路，并和同事进行讨论，确认之后把设计图拍照提交到文档库，或者用工具Visual Paradigm画出来。
• 不需要的不设计。优先以最小人力解决问题，能用简单的方法解决问题，就不要用复杂的办法。比如，能通过打通网络解决系统间访问问题，就不要走代理，这样可以节约很大的设计和开发成本。能通过业务解决的问题，就不要想用系统解决，比如人工操作修改数据，和系统启定时任务批量修改数据。

敏捷设计的思路是只做必要的设计，需要的时候再重构。

缺点：可能的确是有些场景在设计的时候没有考虑到，导致系统在未来很特殊的场景下不能支持业务需求。到时候可能就需要打补丁或者用很奇怪的方式实现。

敏捷设计评审会议

• 减少会议。为了会议的高效，我们之前的做法是会合并几个会议，在Kick Off会议之后直接进入设计评审会议，因为定会议室，投影仪，让参会人员准时参加都需要一定的成本。设计评审会议一般是半个小时到1个小时。设计者讲下自己的设计，可以使用PPT或直接在黑板上画一下自己的想法。如果是对已有功能的修改，需要先讲这块功能原来是什么样，现在需要修改成什么样，涉及到哪些修改点，自己是如何设计的。如果设计方案审批不通过，则设计者需返工，因为我们强调简单设计，所以即使返工，成本也不会很高。同样为了高效，设计者重新设计的方案不需要再开一次设计评审会议，只需要把相关人叫到座位旁边确认下就可以。
• 减少参与者。只邀请必须参加的人，非必须单相关的单独沟通。
• 高效评审。设计评审中很重要的一点是参加评审的人必须有足够的耐心和胸怀听明白别人的设计，设计评审是为了优化设计者的设计方案，而不是为了挑战设计者，或给设计者挑刺。任何设计方案都有它的优缺点，所以评审人在听完设计之后，需要先思考下这个设计方案的优缺点是什么，再想想自己的设计方案是什么？对于设计者没有考虑或讲到的点，可以通过反问的方式让对方补充。

http://ifeve.com/how-to-do-team-work-from-alibaba/
提倡需求串讲。上游的质量决定了下游的质量。在软件开发中需求文档属于最上游的输出，所以我们格外重视需求评审。

为了提高设计和评审的效率，并且能够让全员充分参与到设计和评审中，我们团队提倡结对设计、简单设计、交叉设计和全员参与设计评审。

• 提倡结对Code Review。如果模块是由一个人设计的，那么Code Review时审查者只能帮助队友Review出代码中是否有坏味道，却很难Review业务逻辑是否完全正确。因此，提倡结对Code Review，每个模块由两个人设计，然后分开开发，最后交叉Code Review，这样能Review对方代码中的业务逻辑是否正确。

阿里内贸团队敏捷实践(二)自组织管理

http://ifeve.com/alithink-interview/

• 利用初面官通过复面。在初面快结束时，面试官出于礼貌会问你有什么想问我的吗？这个时候很多人都不问或者问不关键的问题。我建议询问面试官自己的不足，针对这些不足如何提高，以及自己最得意的项目有哪些不足，如何改进，拿着这些建议和准备去参加复面会更容易通过。

• 社招选择年底应聘。年底跳槽的人少，各部门的head count必须用完，所以要求可能会相对低些。所以年底相对于年初和年中比较容易进入阿里。