架构师

架构是属于偏技术的，你需要洞察软件开发的各个环节，然后理清各个环节参与者的关系和诉求，然后解决它们的问题。

软件开发从需求管理，产品设计，交互设计到编码设计，测试，运维。 涉及到产品， UI，开发，测试，运维等一系列角色。 如何通过合理的架构解决它们的问题，它们的痛点是架构师需要考虑的。 目前我对其他角色的理解还不是很到位，因为这里仅仅针对前端这个角色进行分析，分析它们的问题和痛点。

前端

首先明确下前端流程设计。  前端流程设计指的是能否快速进行前端项目基础工程，常用业务模块以及开发流程的搭建能力。 具体来说就是能否快速建立一个项目的code base。包括前端技术选型，模块化方案，代码规范化，构建自动化，组件化目录设计，代码优化处理，数据统计，同构项目结构设计等，基于这个设计，团队就可以在此基础上快速高效开发。

后端

对于后端，基本大同小异，由于前端的运行环境通常是浏览器，后端运行环境通常是服务器。所以考虑的东西不一样，后台会更多考虑数据可靠，服务伸缩扩展。所以目前后台架构层面都是基于服务治理，包括之前的web service到现在的微服务。 具体来讲，后台流程设计包括后端技术选型，服务或者接口的组织方案，代码规范化，构建自动化，性能优化处理（现在sql优化很多都放到dba去做了，很多sql都需要dba通过才可以放生产），数据统计（api响应时间等），日志管理，配置管理等等。

运维

对于运维，他们需要保证软件正常稳定地对外提供服务。 他们的工作通常是监控宿主机运行状态，关注虚拟机的各项指标（cpu 内存 带宽等）。同时还会做一些分流限流等软操作和平滑升级、重启等强运维性操作。docker等虚拟容器技术的发展给了运维无数的可能，之前我参加过一个k8s的分享会，就有很多的运维同学参加，他们都想要赶上这个机会，创造更大的价值。k8s 之所以这么成功，是因为他解决了软件开发中运维的痛点，加上云技术的发展，企业可以把项目直接托管到云上，现在中小企业可以在没有专业运维的情况下做得很好。

除此之外，你要懂一点产品。

team leader

管理人员

team leader 是偏管理的，你需要带领你的团队，首当其冲的是领导能力。 你需要有一定的威信，让人们信服你，同时你要有一定的亲和力，不至于你的威信太过尖锐而难以融入团队。良好的沟通是team leader的前提，简单来说沟通是通过有效方法正确表达自己或理解别人观点的一个过程。作为领导者，不仅需要具备全面严谨的逻辑，良好的沟通能力是帮助我们高效工作必不可少的技能。

管理需求

team leader除了带领开发人员高效出活，还有一个重要作用就是“挡需求”，剔除不合理需求或者合理划分任务优先级，如果能够人尽其用，合理发挥每个人的长处也是极好的。具体来说，就是对于产品的需求变更，作为leader不要立马接受变更，而是评估需求等级。  如果是小的不会花费很长时间，考虑接受修改。如果需要花费时间很久，就要重新排期确认工作量和优先级。如果是细小问题，建议放到下个版本迭代。

解决团队问题

team leader 解决问题应该有清晰的思维。  对于代码类问题，大家都碰到测试或者产品向你反应问题，说哪哪不对。遇到问题不能急躁，更不能盲目修改。  第一步确认问题，弄清楚是不是真的问题。 是不是由于没有设置host，使用了网络代理等。第二步，如果确实是问题，可能是代码问题，也可能是产品考虑不周问题。第三步，看是不是自己代码问题还是依赖的代码环境等问题。如果不是自己问题要立马反馈。如果是的话就要评估工作量，如果工作量很大，可以考虑新版本解决，工作量小可以马上进行修复。

进度把控

team leader的还有一个重要作用是把控进度，提前暴漏问题。需求如果不能按期交付，需要提前暴漏给相关人，千万不要最后才告诉大家。   leader  通常会被要求做时间评估， 那么评估时间的时候最好能考虑到需求变更，各种会议的时间，这点非常重要，一般而言，一周工作时间按照20-30小时评估就差不多了。