看到这篇文章：
我脑海中的优秀技术团队
觉得讲得很不错，需要学习。
关于人
1. 好奇心。因为好奇心，对未知领域的探索，用技术来做很多神奇的事情，例如炫酷的动画？碉炸的算法？人工智能？游戏？物理引擎？漂亮惊艳的页面？想想你是不是因为这些技术而义无反顾的冲入编程大军的。
2.持之以恒的学习。
有时候如果实在看不到一个人对于持续学习的热情，我甚至直接生硬的问对方，“你业余时间会做些什么跟技术相关的事情”，然后得到的回答，
通常是“看书”“看论坛”“看源码”。其实这就是敷衍了事了，这些事情只是一个程序员最基本的一些学习方法。
你是如何“持续学习”的，你看过一篇文章之后，对于其中涉及的一些知识点，你如何去强化？如何去实践？甚至如何引入到工作中来？
你的工作或者是项目都做得平平无奇，那你看书看论坛都是在看什么呢？看了之后又解决了什么问题？
3.分析解决问题的方式。
如何判别一个解决方案的正确性？你如何一步一步分析问题？如何debug你的代码？然后，解决问题之后，你做了什么思考？
是否是你的知识面有问题，需要系统补充下某个方面的技术点？你是否研究了它周边的知识？写一篇博客，备忘顺便分享给网友？
这里又涉及到知识管理的方面。总之每次遇到问题其实都是一次对你的知识面的扩充时机，最终这些都会变成你的经验。
在工作多年之后，这些潜移默化的知识会让你能够快速对一个问题作出判断，会在你脑海中形成一套体系，帮助你快速分析和解决问题，
不管是你的方向是架构师，还是业务leader，都需要这些能力。
通常，你做事的方式态度，就决定了你的未来。
最终目的都是通过这些细节发现一个人的潜力：
好奇心决定了你能在技术这条道路上走多久；
学习方式决定了你能够在这条道路上越走越高；
而解决问题的方式则决定了你能否形成方法论，成为一位真正的资深工程师。
作为一名普通员工，我还期望有这些关键字：
乐于分享，让我可以被动扩充知识面；
和善真实，不为人情世故操心专心做个写代码的美男子；
牛逼哄哄，让我大开眼界的牛人那是最好不过的，光听那些名词就足够我出去吹半天了，对于开阔思路视野有奇效。
关于团队
1.团队是否在朝着一个更好的方向成长？
很多团队，基本没有“管理”。所谓管理，不是说有个老大管着你，指挥你做这个做那个，而是你这个团队是否有
“目标”
“规划”
“预期”。
你的团队是单纯的实现业务？还是有所规划？你理想中的团队架构是如何的？人员分配如何？技术栈如何？规范如何？流程如何？现在有何不足，作何改进？这些其实就是对“管理”的拷问。
而这些拷问，其实关注点主要就是你的团队是在健康成长，还是放养或者原地踏步？如果进入没有方向的团队，恐怕自身的成长也不会有大的进步。
2.团队做事方式是否规范？
这里的规范化有几种含义。
代码规范，这个不用多说，最基本也是最容易达成的，方法可以有eslint等，加上定期的代码review，以及团队内的规范文档等。
方法规范，如何引入新技术？多人开发如何进行？如何保障代码可用性？如何保障发布安全？如何有效利用日志？等等，
这些问题都需要形成方法论，有一套流程来保障。例如引入新技术，我们需要
调研试用 - 产出优劣报告 - 产出脚手架 - 多人review脚手架 - 分享+文档 - 新项目试验 - 问题总结分享 - 优化 - 全面投入使用，
过程中会要求一些产出，目的都是为了评估好优劣，并且形成一套规范，而不是随意引入一些不可控的技术。
上面提及的其他问题，我们都会形成自己的一套规范，落地分享和文档，跟踪执行。这就是团队规范的方法论。
流程规范，一个需求如何产生？如何评估其用户价值和可行性？如何进入开发手中？如何排期？是否有完善的项目管理流程？测试发布如何进行？
一个团队的开发如果是乱哄哄没有标准秩序的话，开发会很累，这些其实是项目经理的职责，
从开始对需求的把关，到产品经理的把关，到交互视觉把关，到技术方案排期评估，到联调跟进测试发布。做好不易，做不好大家就会很累。
规范化的最终目的，一个是提高开发效率，另一个是确保团队开发的可持续性，减少“坑”出现的几率。这些问题通常是创业公司技术团队的通病。
3. 共同成长和价值定位
一，让大家共同成长；
二，大家各司所致，找到自己在整件事情中的价值定位；
三，事情本身推动了团队开发效率，这是其最基本的价值。
作为一个个人，其实对团队的期望大体还有：
- 有足够的挑战，有机会接触各种问题并解决以此获得经验积累。
- 团队认可我的价值，而不是把我当成工具来使用。
- 团队有足够的成长空间，对自己有个清晰的定位。
结语
很难做一些方法论或者是管理思路的分享，一个是因为还不够成熟，大家都在摸索；另一个重要的原因是，很多方法论其实就是一句话或者几句话，更重要的是执行到位，否则说出来都会很虚。
但是团队到了一定阶段之后，一定要有目标和方法论，否则还是原始的行军状态，大家都会迷茫，内耗也会非常高。