从开发走向项目管理
1、角色的改变
2、计划制定和执行
3、进度、质量和成本的控制
4、有效的沟通，
每个系统要做好自我保护， 量力而为， 而不是尽力而为。对于超出自己处理能力范围的请求，要勇于拒绝。
对于用户的重试行为，要适当的延缓。例如登录发现后端响应失败，再重新展现登录页面前，可以适当延时几秒钟，并展现进度条等友好界面。当多次重试还失败的情况下，要安抚用户。
当雪球发生了，直接清空雪球队列（例如重启进程可以清空socket 缓冲区）可能是快速恢复的有效方法。
对于“每个系统要有能力发现哪些是有效的请求，哪些是雪球无效的请求”，这里推荐一种方案：在该系统每个机器上新增一个进程： i n t e r f a c e 进程。I n t e r f a c e 进程能够快速的从socket缓冲区中取得请求，打上当前时间戳，压入channel。业务处理进程从channel中获取请求和该请 求的时间戳，如果发现时间戳早于当前时间减去超时时间（即已经超时，处理也没有意义），就直接丢弃该请求，或者应答一个失败报文。Channel是一个先进先出的通信方式，可以是socket，也可以是共享内存、消息队列、或者管道，不限。Socket缓冲区要设置合理，如果过大，导致及时interface进程都需要处理长时间才能清空该队列，就不合适了。建议的大小上限是： 缓存住超时时间内interface进程能够处理掉的请求个数（注意考虑网络通讯中的元数据）。
就是一个研发，带着大家去做技术选型、技术架构设计，等等这些东西。很多技术经理更多的是做计划、管人，但是我不一样，我喜欢技术，所以我更偏的做技术一些。
团队里面基本上是这样：有一个人非常懂底层，C/C++出身的，对操作系统的底层非常熟，喜欢看代码专研底层；还有一个人是J2EE、Java出身，对Java的架构和各种框架如Spring，Struts这些都很熟；还有一个人对面向对象和软件设计这些比较熟悉。还有人对软件的前端设计比较熟，做过Web Portal的设计；还有人对机器学习的算法和方法非常熟；还有一个人也倾向于底层，但是稍微倾向于网络这边。这些人，每个人都有一块自己非常强的东西，所以他们合作起来也会很舒服，因为他们可以从别人身上学东西，而且自己也能领着别人去做点东西。每个人都有自己的领导力，每个人都有自己的成长空间。我觉得这是让团队比较和谐的原因。
另外，我只是一个支持性的角色，团队主导一切，我只是在旁边支持他们。
他们愿意去学习自己不了解的领域。
陈皓：对。没有英雄。也没有闲人。每个人都有自己的长处，在这个长处上他可以领着别人做事情，同时也能从别人身上学到自己比较薄弱的东西。
一般就是研发经理跟他们沟通，也就是和是项目经理或产品经理沟通。不过我们沟通的时候跟别的地方不一样，不是说产品让我们做什么我们就做什么。我必须要让产品告诉我，你做这个能挣多少钱，为什么要做这个东西，做这个的利益是什么，有什么好处。你说不清楚，我们就不做。
他的基础应该是多元的，一个T型人才。
传统的软件交付过程是通过架构、业务、技术运维、保障等团队之间一步一步把交付物交给下一个环节，最后产生交付软件的价值。这种交付方式的一个明显缺点是各角色仅关注于自己本身的工作，在中间的流通环节产生了很多不必要的浪费，如时间成本和沟通成本等; 同时，这种阶段性的交付通常时间较长，一旦产生问题造成的影响也较大。敏捷开发是为解决这一问题而提出的解决方案。在这种方法里，业务人员也深入到开发当中，这样需求、开发、测试前面三个环节被打通了，但是，到部署的时候仍会出现问题：因为项目是直到最后才交给运维人员部署到线上，部署时经常出现比如IP 问题、机器资源问题、与线上已有程序的冲突等，要花费大量时间解决。出现这种结果是因为，虽然整个团队共同的目标是项目的最终实施，但是作为两个不同角色的部门，开发团队和运维团队对具体的目标仍有不同的追求。那么如何解决开发团队和运维团队之间的这种隔阂?DevOps 应运而
“你要培养一种文化，要建立一种机制。让运维人员参与到更早——只要项目开始，启动阶段就要把运维人员引入进来，一起开个会，让他们知道项目的进程”。同时，开发人员也需要了解到运维人员的工作状态