对于一个 Leader，发现问题这是很重要的，这将包括产品问题、团队问题、代码质量问题，下面将分别阐述。

　　· 产品问题

　　曾经一个朋友跟我说过一件面试中的小事，一个技术官问他：

　　甲：“你是怎么定位自己的？”

　　乙：“我在上家公司的的offer是资深开发，在公司是团队Leader”。

　　甲：“我问的是你怎么定位自己？或者说，你是把自己定位成开发还是开发加产品”

　　乙：“抱歉，这个问题我之前没考虑太多，平时开发中，我更多的时间关注的是代码质量和用户体验”

　　对于以上的事情，我相信这是一个很普遍的现象，细节，真的决定着成败，站在产品的角度考虑问题，更有助于理清产品思路。之前在过完需求后，第一时间想到的就是我该如何去更好的实现这个功能，从程序员的角度出发，这是没任何错误的，但是从一个 Leader 的角度出发，这就是一个错误。

　　· 团队问题

　　这个问题，片面点说，这就是一个民主与集权的问题，因人而异，对不同的人不同的对待。工作中的队友一般分为两种，一种不指派任务就会忙自己的事，看书、看新闻、逛帖子，一种是做完事情后主动请缨，能否为公司、为团队多做一点，从而更快的提升自己，对于第二种，这样的队友很容易打理，可以实现过度民主，因为他知道自己该干嘛，会竭尽所能去多做点事，对于第一种，如果在项目进度宽松的时候，可以适当民主，每个人都有自己的爱好和业余生活，拓展一些其它技能也在所难免，在项目紧张的时候，过于民主可能会影响公司进度，因人而异，因地制宜。

　　· 代码质量问题

　　这个嘛，之前写过一些博客，分析了为什么有些人不适合重构代码，杂乱无章的写法，重构后不久，可能又面临着无法维护，还需要再次重构，恶性循环，当误了时间，降低了效率。做为 Leader，很有必要制定一些准则和规范，对于字段的命名统一规范，对于一些必要地方的注释，一些不必要的地方滥用注释，好的命名方式，可以减少很多不必要的注释，过多的注释或者错误的注释，会严重影响开发效率，误导他人或者自己。接下来就是一些可重用的代码，方便自己也方便他人。

　　对于代码质量，我认为应该不定期的 review，对于新加入的同事，可以抽出更多地时间去审阅代码，指出一些不足和不规范。对于一些老队友，在时间充足的情况下，可以互相审阅，互相批评指正，互相学习共勉，达到共同进步。