2018年我的开发管理总结
最近找工作有好一段时间都没有消息，从一开始焦躁不安慢慢开始习惯这个过程，这个时间总算让我静下来，仔细考虑一下自己到底想要什么，想做什么，能做什么。想了个把月还是没有想清楚，只是觉得综合我的经验，“开发管理”这个工作会适合我，也有兴趣去应对其中的挑战。在技术领域我的技术水平一直一般，并不出众，但是在综合性管理实务上积累了一些经验，我相信这些经验中有些是比较独特的，是值得拿出来分享。通过分享希望能获得反馈和交流，客观来认识自己，从中找到自己的答案。
其次，是开发能力，这是从较为长期的角度来看，技术好能有更强的业务实现能力（能实现以前很难实现的需求），提高开发效率（开发快且质量好），
最后，是新技术应用（或称研发），从业务发展的角度来看，新技术和业务的结合能否创新业务过程或产品，从开发能力角度来看，新技术是否能够提高开发效率。
（针对偏重业务逻辑的系统，偏重专利技术实现的系统不同。一般系统概括地讲，没有什么算是核心技术，系统实现的业务逻辑才是公司的核心价值。有专利技术的公司一般也会从组织架构上把核心技术人员独立出来和实现业务逻辑的开发团队分开）
从高层来看，分两个层面，一是系统架构，二是开发人员
系统架构是一个系统质量、安全、可靠，能否快速适应业务变化上的根本。
当系统不是由一个人实现时，再好的系统架构，如果开发人员水平一般，也难保证产出的进度和质量。（这里不考虑协同工作方面，只讨论技术能力）
1.项目管理
需求、计划、进度、质量、实施、迭代衔接
项目管理是一项管理工具，管理类职位都会用到。有的技术管理要全权负责项目管理，有的有独立项目经理负责，技术管理负责协助项目过程管理。
项目管理的职责是统筹和协调不同职能人员共同在期限内达成项目目标。
首先，要明确项目的目标是什么。项目目标的业务价值是什么。准确理解管理层对项目目标的规划和期望。
明确项目的实施目标，时间范围——多长时间完成，业务范围——达成业务目标需要哪些业务，业务过程分别有哪些，每个业务过程为了实现什么目的，全部的业务过程是否达成项目的目的，每个业务过程涉及哪些人、职位、职责，项目范围——从业务范围中识别出项目目标系统的需求范围，按业务职能进行归纳整理，确定大致的项目模块。
项目成功的要素之一，高层管理的明确授权和各职能部门积极配合，项目前期要主动做好这些沟通工作。（如果没有这些，项目过程中更需要主动去各职能部门沟通）
需求调研，和各相关业务部门沟通，各业务部门当前如何执行业务过程，探讨基于新系统将如何改变业务过程，明确需求联络人和需求责任人。
第三方对接的业务过程，第三方的联络人和需求责任人。
调研技巧，了解现有业务过程要找业务一些人员，熟悉业务过程和相关背景情况的。从部门经理了解基于新系统的业务过程的设计，人员职责。
需求整理分析，
梳理基于新系统的各业务流程，系统的范围和职责，与系统交互的人员、岗位、职责，与系统交互的操作。按业务职能进行归纳分类整理（不同的业务模式、公司管理模式有不同的分类方法，遵循企业的管理方式进行分类）。
梳理系统用户类型：公司用户——组织结构（系统相关的）、人员、职位、岗位，第三方用户——人员、组织结构、职责等，第三方系统。
编制系统需求文档，和各业务负责人确认，和项目投资人确认。确认系统范围是否能准确支持业务过程，达成业务目标。
1.2.计划
根据需求范围和开发团队规模、能力水平，是否要分阶段开发，还是一次完成。需求规模大最好是分阶段进行，每一个阶段都按一个子项目进行。根据需求的业务优先级划分阶段。
需求分析和系统建模分析
在确定完整开发计划前，要让开发团队进行需求分析（需求复杂更要），从需求文档中进行提取业务领域模型（类似ER），根据系统的操作需求进行系统控制模型的设计。系统建模是在根据需求在设计系统内部结构和工作逻辑，使之能满足系统需求。这个过程中会产生细节与业务方的沟通和确认。
系统建模完成后，根据系统的逻辑结构，确认开发人员的分工（模块与功能），开发人员预计开发用时，技术负责人审核开发预计用时。
综合各职能开发人员（前、后台开发、测试）的开发计划，制成完整的开发、测试、发布计划。
为什么要花时间做系统建模分析后才确定计划？计划是开发人员根据对需求的理解和设计实现的逻辑，并依据自己的能力、经验做出的估算值，包含着开发人员对按时完成计划的承诺（激发主动性有更好的执行力），同时让计划的时间周期更真实、合理，更能反映实际的可能结果（和管理层的期望是否偏差，进行双向沟通，促成一致）。系统内部逻辑设计更合理，有更好质量保证，开发人员的分工、任务衔接也更合理、有效，促进开发内部的协作更有效。
项目有截止日期，但开发计划远超截止日期，怎么办？开发计划要向项目干系人汇报，让项目管理层了解到更真实的时间成本。提出解决方案：从业务优先级的角度上，划分多阶段进行。适当增加开发人员，或者调用更高能力水平的人员。激励工具：奖励和惩罚机制。降低质量、安全的期望。增加每日工时（加班）。
1.3.进度
计划执行过程中，以日为时间单位更新项目进度，以重要任务节点和周间隔向项目管理层、项目干系人、项目组成员更新项目进度
掌握进度方法：（1）问询项目开发人员，收集整理。——站会、单个问询、主程问询（2）借助项目管理工具，让项目开发人员每天实时更新开发任务完成进度（小时单位）。管理方通过工具查看进度，或产生进度报表。
阻塞问题的发现和解决
肯定会遇到阻塞进度的问题。如何及时发现问题？一线的项目人员主动报告，要求人员有主动性和预计性（个人性格——勇敢担当、团队氛围、公司文化）。问询项目进度时，发现延期问题，预计可能的会阻塞的问题（经验判断）。
应对阻塞的方法，如果是预计会发生阻塞，设计好应对措施。如果已经发生延期，分析原因（主观、客观，主观导致延期占少数），有把握能在具体时间内（可接受的）完成，记录延期问题和处理方案，造成的后果、增加的成本，相应地调整计划，向项目组、项目管理层汇报。（不要在项目过程中进行批评和指责，而是重点在快速有效的解决阻塞，尽快让项目进度恢复正常。项目进度压力正是考验团队协作，个人抗压、激发潜能，暴露或展示个人真正实力的时候）
1.4.质量
保证系统开发质量的方法有：开发设计评审、代码单元测试（白盒）、功能测试（黑盒）、代码评审、重构，还有性能测试、安全测试分别用来保证系统的性能需求和安全需求。
开发设计评审
为什么要做开发设计评审？开发设计是一个开发人员对目标系统、模块、功能的内部逻辑的设计，这个设计思路是否具有完备的逻辑性和系统性，是否满足全部功能需求和非功能需求，不同水平的开发人员是存在差别的。越早发现设计上的缺陷，越小成本来提升质量。设计评审也是提升开发人员能力的一个过程。
怎么做开发设计评审？在需求分析阶段，每个开发人员在确定的分工范围内进行实现逻辑设计，以文档为载体，记录和整理自己的实现逻辑。集中开发人员由高级开发人员主持，逐个开发人员表述自己的设计思路，由其他开发和高级开发人员进行点评。设计评审后，由开发人员根据自己的设计进行开发时间的预估（项目计划阶段）。高级开发人员要确保设计思路具有完备的逻辑性和系统性，满足全部功能需求和非功能需求。需不需要需求人员出席？建议不要，如果是系统层面的设计评审，是有必要需求人员出席，如果只是模块层面的设计评审，需求人员的参与程度很低。如果评审发现有需求待细化和理清，这正好说明开发人员没有做好分析设计的工作，需要改进在分析设计的方法和态度。会后单独去找需求人员去细化和确认，然后单独评审。
设计评审又推迟了开发时间，开发人员抱怨，管理层不理解，进度压力怎么办。简化评审的过程和形式，比如只安排一天时间做系统设计，文档要求简单。和开发人员解释并化解他们对进度的压力（自己承担）。事先得到管理层的理解，哪怕默许。总之，相信这个过程对整体进度有积极作用，就要有决心自己承担进度压力。
测试用例评审？主要指功能测试（黑盒）的用例评审。测试也要做计划，测试计划是项目计划的一部分（关键节点），在需求分析和开发计划阶段，为了制定更合理的测试计划，测试人员对需求进行分析，编写测试用例。通过测试人员的需求分析过程，完善需求的逻辑性和系统性。测试用例评审是和需求人员的确认，主要讲述人是各测试人员，评审人是需求人员。开发人员是否参与我没有定论，参与的好处，这个评审的焦点是需求，因此开发人员参与能保证需求的细节和变化同步掌握。不参与的原因是，如果需求没有太大不同，开发人员的参与程度很低。
代码单元测试，可称为白盒测试，参考自测试驱动开发方法，测试驱动开发-自动测试体系的基础。（编写单元测试）方法大致是，针对一个功能接口，设计各种情况下的输入然后验证对应输出的结果是否符合预期。验证过程由系统批量自动执行。测试驱动开发，因为单元测试可以反复多次自动执行来检验功能的实现是否符合需求，利用这个自动验证特点，先写好单元测试代码，然后再去实现功能内部逻辑，直到功能接口能通过全部单元测试，这样功能开发完成。这种开发方式，让开发人员先不考虑功能内部实现逻辑，而是先从功能外部来考虑，功能在系统环境中，如何满足需求（功能的用户是谁？功能的用户应该怎样使用功能来满足他们的需求？），同时还要保证在各种系统异常情况时能有效处理。对很多开发人员来说，这是一种新的开发思维，理解了还要学习实践，积累一段时间后，才能产生开发效率提升的效果。单元测试的第二个优点，每次系统迭代开发，随代码提交触发的单元测试自动执行（持续集成），能检验发现代码改动是否影响了既有功能，尽早发现bug和冲突。因为单元测试其实也是一整套代码，也就是需要设计、开发、维护、清除等工作，一开始实施这个方法会增加开发工作量，可能是这个原因，我还没见到实际采用这种测试驱动开发方法的团队。这个方法不是开发过程必需的，如果开发过程成熟稳定，可以考虑引入实践。
功能测试，测试阶段的主要工作。由测试人员根据测试用例执行测试，发现不符合预期结果的记录到bug跟踪系统。bug跟踪系统是这个阶段重要的管理工具，从一个bug到记录、开发人员确认、修复、测试人员回归通过、关闭，有一套bug跟踪处理的过程。记录bug主要做好分类、可复现的操作过程说明、异常信息、正确的期望结果。成熟的bug跟踪系统能有效地支撑起这个过程。
代码评审，在已经完成的代码基础上，由高级开发人员进行代码走读。目的是发现代码的逻辑缺陷、安全缺陷、是否违反代码规范等，提高代码质量和提升开发人员能力水平。配套的工具有静态分析，能够帮助发现代码中的违反规范、缺陷代码。代码评审一般在开发阶段的后期，能发现的问题少，而且往往一个点会展开讨论哪个更好很长时间，提高代码质量的效果一般。从这个工作的目的来讲，要更好达到这个目的，应该试试从开发总结的方向来组织，不仅仅只是高级开发人员检查，开发人员自己对比开发前的设计思路进行总结，激活开发人员主动性，培养会思考总结的自我学习习惯。还有重要的一点，评审发现了的问题，要明确改进目标，落实到人和时间，以及验证交付等过程。
重构，指的是比较大工作量的改写既有代码的工作。针对现有系统的质量、性能、安全等问题（累积的、严重的，影响后续迭代开发效率的-不灵活），经过分析发现了可以改进的架构、模块、功能，明确重构的目标、范围，按一个项目过程进行。重构不是重写，是在现有代码基础上改进。参考重构的具体方法，可以有效的开展重构代码的工作。
性能测试和安全测试，根据需求和成本，是否需要（能不能）安排。成本因素，性能和安全需要非常专业的人员，不像一般开发人员比较稀缺。性能测试相比安全测试比较找到人做（内部学习培养）。
发布，在功能测试通过后，发布系统到正式环境。前端app打包签名发布，web前端、后台打包发布。利用持续集成和发布的工具fastlane、jenkins，发布操作触发后，自动从代码仓库提取代码，编译、打包、（app签名）、部署到目标环境（app上传到市场）。参考devops实践
实施，就是如何将系统运用起来，最短时间发挥出系统最大效果，达成项目业务目标。
对外部终端用户，在产品功能设计时（需求阶段），就需要考虑界面和交互方式容易理解，简化用户的操作，目的是用户不用太多学习过程，能快速掌握系统的使用方法。
对业务用户，在需求阶段确定了新业务过程后，制定新业务过程的规范手册，说明工作流程，明确过程中各部门、职位、岗位人员的流程职责。涉及组织结构变化和岗位职能调整的，在系统发布前做好沟通准备工作。培训，对实施涉及的业务人员进行培训，说明新业务流程，职能变化情况，搭建培训环境，让业务人员练习操作，熟悉系统中业务操作过程。外部业务（商业）用户也需要做好新业务流程和系统操作的培训。
1.6.迭代衔接
假如系统分阶段开发，怎样能让两个阶段之间的工作衔接更紧密，更充分利用好项目成员的时间？要先做好一个完整迭代的流程规范化，就是开发过程清晰，每个环节的人员分工，环节之间怎样互相配合协作，开发团队的每个人都非常清楚。（这个规范化是当前项目团队达成一致的最佳实践，外部的规范化或最佳实践都是参考，启发团队成员去思考发现团队效率的问题有哪些，根源是什么，可以采用什么方法来改进。）有了一个规范的迭代流程，就容易找到两个迭代之间可以衔接的点，比如前一个迭代进入到测试后期就可以安排开发人员进行下一阶段需求分析和设计评审。
最有效的迭代衔接，是去中心化的迭代，也就是团队每个人都积极主动，不需要人居中去协调统筹，通过每个人互相之间的有效沟通来协调工作，每个人都以项目目标为先。
项目管理，从技术管理人员的角度来说，可能更具体一点就是开发过程管理。在不同的公司，不同的组织结构和职能分工的前提下，开发过程管理对于技术管理者会有不同的要求，无论管的范围是多还是少，都应该站在更高的业务层面，推动过程的持续改进，提升开发过程的生产效率。
对开发过程建立和改进，同时要思考开发人员的组成、分工，主要的工作职责。
完善开发过程是一个持续的工作，要有开发人员的参与，因为他们是工作在这个过程中的一线人员，对自己和同事的能力、态度，对过程效率的体会都有更直接的了解，开发管理者要激发他们针对过程，敢提问题，组织他们对问题说出自己的想法（分析原因），说出自己的改进的办法，综合讨论意见，最后重要的是，确定下来一个具体改进的方法，明确改进方法中各个人的分工，然后落实到实际开发过程中。每一次对开发过程的改进尝试都参考戴明环PDCA方法（计划-执行-检验-改进）
能够调动开发团队的每个人积极参与工作过程的改进中，就能激发他们的主动性。一个高效率的开发团队，是能持续自我学习提高的，是能自动自发的努力达成目标的，至于统筹管理，已经不重要了，即使有这个岗位，他也是团队中平等的一份子，只是可能更积极活跃些。
我把能自我管理的团队作为实现高效率团队的目标，是基于我相信，每个人在满足物质报酬之外，更加希望能完善自我，在一个集体中实现自我价值，这个意愿是真实的，而我看到很多情况下是被压抑被忽视的。如果你希望团队能有很好主动性能自我管理自我学习，你只需要给予他们自主的空间和时间，然后就是信任和等待。
我感到，在我实际工作的压力，大多都源于管理层的不信任和没有耐心，对于他来说这是有正当的客观理由的，但那些很难解释他们把人放在第二位。也包括我自己作为管理者的时候，这应该也是要在管理意识上学习提高的过程。
一个问题，人只有在被动的压力下，才能提高效率，才能激发潜力吗? 如果认为这个答案是不，那怎样能让人产生主动的想法，去提高效率、激发潜能，首先前一个问题，人会不会有这种主动性的想法？当然有，除非他没有想到这种主动性带来的好处--一个独立自我意识的存在——我为什么是我？唤醒一个人的独立自主的意识太难了，通俗点的说法，主动性能让开发人员更多的感受到开发——编写代码——带来的乐趣和成就感，或者说下被动压力的负面，压抑、和自己没啥大关系的成就、对业务目标的无感。不能产生主动性，有的人是没有想到主动性的好处，有的是觉得没有这样的环境。因此要有人去讲，去解释，去启发他们。也要和管理层沟通，无论什么方法要争取到尝试的机会，有空间和时间来实践，用结果来证明有效和可靠。
2.技术管理
2.1.系统架构
什么是系统架构？什么系统架构是‘好的‘？
承载业务逻辑的信息系统，抽象于具体的业务逻辑，
根据业务需求，在不同时期，系统架构有不同的形式。
系统架构有很多层次，
1.网络 基础的公司内部网络基础框架，支撑公司内网的系统运行。 这是归在运维的工作。
目标系统可能部署在公司内网、私有云（私有服务器托管数据中心）、公有云
有擅长网络架构设计和网络部署知识的人来进行部署和维护，是后面组织devops的硬件基础。
初级的叫网管，能负责网络拓扑设计和实施，实现和维护网络通讯的基础服务，确保稳定、安全和高速。
服务器的采购、配置、维护。偏重硬件方面。
ad、mail、ftp系统的搭建，账号密码的权限管理。
这方面也属于是公司IT服务管理（ITSM）的主要部分，看公司的组织结构设计。有规范的ITSM可以指导这项工作做的更完善和规范。
高级网络工程师，除了具备丰富经验的网管能力外，熟悉linux、windows服务器环境的管理维护，
重要的是懂虚拟化技术，能实施虚拟服务器和集群的搭建，能建立服务器自动监控和报警机制。这就是devops的基础了。
能做服务器性能优化。
熟悉各数据中心的线路情况，能分析私有云全国线路访问速度，并制定优化策略，联系和谈判并实施，优化私有云服务器访问速度。
服务器安全配置有经验。制定服务器维护规则，保证服务器的高可靠性和安全性。
制定应急方案，持续评估各种灾难风险，制定相对应的应急和挽救措施。
制定公司内网网络安全策略。监控私有云的网络安全。也需要纳入到灾难风险的防范范围。
安全是一个很专业，无法绝对把握的技术。但网络工程师应该在网络安全范围内尽可能进行全面、规范化的管理。
根据公司规模和对安全需求程度，可以增加专门的安全技术人员，或者购买第三方安全公司的专业安全服务。
2.信息系统架构
首先是Java、Net、PHP语言的区别，
基于Java的技术非常丰富，是主流技术语言，开发人员也容易招募和培养。
.Net 主要C#语言，遗留系统或经典的企业信息管理系统会采用。
PHP 初创企业比较多采用，网站和电商相关业务系统也比较多采用。相比Java特点是开发和部署更快一些，但开发人员相对难招，系统规模扩大后，扩展灵活性、高并发支持的技术方案不如Java丰富，那么容易实施。
系统架构的选项
有单一、分布式系统，更复杂的SOA。
根据系统规模的大小、发展快慢和开发维护成本综合考虑，
总的来说，系统架构要保证能实现快速迭代开发，快速实现业务需求，同时要保证系统的健壮性，不能因为快速迭代，搞混乱了系统架构，引入高成本的系统性隐患。（为了满足快速迭代，技术债务不可避免，这需要在业务和技术之间不停寻求某种平衡的过程，开发经理应该注意系统架构的变化，做好不断完善系统架构的准备）
一个互联网业务系统抽象来看，面向C端（用户端），有web、h5、app前端（微信服务号），业务逻辑都在后台。
还有一个web面向B端，比如业务管理后台（B端还会有应该指外部商家或合作商户，看业务模式），如果是B端也有移动环境下的需求，还会有h5、微信、甚至app的前端。
通过web后台，初始和配置系统，设置好常用的业务参数。
前端和用户交互，接受用户的输入，系统进行业务逻辑处理、数据存储。
公司业务人员通过web后台，进行业务操作，系统进行业务逻辑处理（比如，统计、推送等）、数据计算和存储。
在只有单一web前端时，可以采用类似jsp服务器脚本方式直接处理用户交互，这样整个系统可以为一个项目工程。系统架构简单、开发快，开发人员规模很小，人员和过程管理很少。通常后台web前端会采用这种技术方案（只有web前端需求时）
多种前端时，系统业务逻辑以api接口方式提供给前端调用。项目工程会按前、后端进行分离，开发也按前后端进行分工。此时增加前端开发人员以及前后端协作开发的过程管理，以确保开发质量和进度。
适应业务规模的变化，
（1）用户量和访问量的增长，系统要增加支持的并发量，保证速度和稳定。
简单的方案是升级服务器硬件，对服务器系统进行并发优化配置（操作系统和web、应用服务器层面）。
增加访问缓存层比如CDN，memcache，注意，缓存数据的更新逻辑要符合业务要求。
分布式部署，负载均衡+多实例应用服务，
并发瓶颈很快会传递到数据存储层，在高并发的请求下如何保证数据的唯一性？
按业务逻辑分库，多数据库实例。
(2) 突发爆发性增长，系统要弹性支持，保证系统整体稳定
增加系统自动监控和报警（devops实践）。
公有云，自动部署应用实例
增加排队的业务和系统逻辑，缓冲访问量
(3) 安全性 DDOS攻击、短信轰炸、
DDOS攻击 防范和应对——CDN引流
短信轰炸 增加验证码验证
https 通信加密
我在分布式系统架构的知识和经验都很不足，分布式系统架构确实也很复杂，了解这方面的知识其实不难，难在要有实际工作的积累。
前端架构
web前端，
app前端，MVC是基础的模式，每个业务模块按MVC进行职责分离。如果服务基于api，网络通信|api服务 作为基础层，向上层提供服务，以Model对象为接口交互数据。
MVC | MVVM （先按业务分）
api服务 | UI基础组件（弹出窗、提示、列表的下拉更新和上划加载、导航条）
网络通信 | 持久存储 | 统计 | 分享
数据、图像缓存、web页面、https认证、Socket | 简单键值对、SQLite、加密、KeyChain
兼容性，设备兼容：1.针对各种屏幕尺寸、分辨率，页面都能很好的适配，不变形，2.设备是否存在，读写的数据规格是否能统一。系统兼容：支持的各操作系统版本API的兼容。
安全性，数据通信加密，app加固（混淆、反编译），本地加密读写。这只是app前端安全级别，属于系统级别的安全性一部分。
稳定性，不能出现闪退、卡死（假死），涉及app全部范围，主要原因在内存处理上。开发、测试阶段确保逻辑分支要严谨、有效，代码静态检查工具，代码评审。要在发布后能快速定位原因，要通过系统提供的系统异常处理机制，捕获异常发送到远程服务器。第二类主要问题是异常情况处理，网络变化或异常、接口异常（延时、无响应）、特殊机型。热更新，发布更新包，app在线下载修复bug。
多媒体，图片、视频、声音，高级图像处理：图像识别、机器学习（图片分类、图像人脸、文字识别、语言分析）、AR
感应器，蓝牙、NFC、指纹、GPS等
发布管理，app推广渠道的跟踪、统计。app市场的发布过程、审核材料、审核问题跟进、下载统计。持续集成 - fastlane+Jenkins自动打包、签名、发布到测试平台、发布到市场。
H5混合，开发周期不受市场审核限制，可在线更新。H5与原生功能的相互调用。
跨平台技术，React Native以JS为开发语言的跨平台原生app，可以降低app开发人力成本，提高开发效率——一个模块可以由一人同时实现iOS和Android。并且可以部分UI组件复用到H5页面。
2.2.开发人员
态度、能力，基本上也就是划分人员的两个主要维度。在能力相同的情况下，态度积极的更好。
态度，培养起积极主动的态度。要改变一个人态度，首先你要先了解这个人（具体的一个人），现在是什么态度，为什么有这个态度，怎么去改变。这需要很多的思考、沟通、双方面（我和这个人）的实践，需要一定的时间才能做好的事情。而且，你还不一定能成功。一个团队里，能真正能改变态度的人很难做到全部。但这件事还是可以做到的。从哪些和我相投容易说服的人开始，再针对大部分有良好自我发展意愿的人，细心耐心的交互，只要大部分人能体现出态度的改变，剩下的也能带动起来。按这个策略去实施是可行的。
注意，态度根本的改变，是环境，我只是在有限范围内创建了一个可以去主动发挥的空间来营造一个环境，但公司的大环境——管理层的态度才是决定性的。管理层是否认可这种创造自主性空间环境背后的管理方式，会决定这个环境的有效期有多久，除非你有证据（业绩）能证明这个管理方法是有效的。这个矛盾，是开发管理者需要面对的挑战。
绩效考核是可以用于态度管理的工具。只是工具之一，因为并非对所有类型的人都有效，要有更多的方法。
能力，技术能力是开发效率提升的根本。这是一项长时间投入才能产生效果的工作。但也要走在公司业务发展的前面，时间紧迫性也是有的，所以要注重方法的灵活运用。
通常，绩效考核会有能力考核的维度（如果没有，需要建立这样的考核制度），通过这个管理工具激励人员平时注重提升能力。
首先要建立一套衡量标准（指标）来量化能力水平，这样通过一段时间的量化比较来检验提升的效果。怎么建立量化能力的标准？参考专业技术的知识结构，从基础知识到专业知识，同时也参考招聘市场上不同等级技术人员的能力要求，挑选公司业务发展需要的重视的、可行性好（好量化评估的）的指标。然后是量化值的定义，比如10分制还是5分制，每个分数级别要定义清楚对应代表的熟练水平。重要的是，这些量化指标项目要开放和开发人员一起讨论，要有大家对评价项目的共识。量化指标要确定定期更新的维护制度，比如季度、半年，一方面为了改进实践中发现的偏差，另一方面保持和技术发展同步。
有了激励工具来推动，下面的问题我觉得更重要，能不能让更多的开发人员主动去提升能力？-调动自我学习的主动性。如何做能提升能力？-如何更有效的学习？这些问题的目的是为了让技术能力提升更有效的落实。调动自我学习的主动性是一种引导的力量，学习时间的利用和学习效果上都比被动的更好一些。调动的切入点从为什么要提升开始，要先了解每个人的职业发展意愿，不同的技术、经验、年龄、性别都会有不同的想法，要真心去谈，在了解的基础上，提出和公司的技术发展需求上找到结合点。一般人首要动机是待遇，有利于待遇提升这是最直接的动因，其次是自我价值的实现，能够在一个集体中具有更大的价值，具体一点就比如能最大地发挥自己才能（这是真的有效的一个动因，至少我相信是，不会是全部人，但大部分人是有的），以两个动机作为沟通的基础，既要站要他们个人的角度，也要站在公司发展需要的角度，提出务实有效的建议。（注意：要务实要务实）这种沟通效果不保证对所有人有效，而且要有平时与同事的良好互动基础。有效学习的方法，也是因人而异，有一个方法实施起来效果好，需要投入精力和时间。以项目管理的方式进行协助，确定好一个时期内的学习目标（或者一个学习目标分阶段），学习目标一定要结合公司实际业务或者实际项目，我会在过程中不定期了解进度，并在结束时间点，检验学习目标。通过外部监督压力来促使学习过程更有效的落实。这种辅助方式因为要投入时间成本，不可能同时应用到所有人，只对当前业务发展需要的技术能力进行应用。其他个人的学习，推荐采用这种项目方式进行自我管理，在达成学习目标后，再通过技术分享的方式进行加强。重点，一定要注重实战、和公司实际业务的结合、有实际产出的系统。
不要忘了需求分析阶段的系统设计评审和测试阶段的代码评审，也是提升能力的一个重要环节，这里的实战性很强，效果通常最好。
团队氛围，绝大多数人喜欢融洽的团队环境，容易融入，有自己的位置，没有压力，能互相促进能力提升（能学到东西）。这种环境的价值从管理层的角度来看，有更好团队协作效果，面对压力有比较乐观的态度。其实也能称之为团队文化。怎样创建好的团队氛围，和管理者自己的管理思维和个性有关，我自己偏好轻松融洽的团队环境，自己和同事们以一种平和轻松的方式来交流，其实同事们之间本身就能互相很好交流，管理者只是放开自己，整个团队交流也就公开的放开交流了。具体的做法很个性化，我和同事沟通的准则是真心、以平等同事的角度、多听少说、尊重理解包容，也要会主动硬插话（很少有人主动找老大聊天），因为有职位利益上的关系，我不指望能有同级同事之间的对等沟通，所以如果同事们聊的话题不适合介入的话就不硬插话或者识趣走开。管理者做这个工作，一是为了维护和同事之家良好合作关系，在执行管理工作时能有机会获得他们的支持和配合。二是为了培养团队内部更广泛的人员关系，更开放的沟通环境，可以促进更大范围的人员关系的建立。在项目和研发学习的过程中，要保持持续稳定的压力推动，压力和引导力相比，压力还是更为基础，在保持和提高生产效率、激发个人潜能上是最有效的方法。工作压力主要来自于时间，要达到目标所需要的时间很紧张，有时限定的时间感觉几乎不可能实现。因此推动压力的第一，要说明清楚目标、范围以及完成目标的时间限制。推动压力的第二，是没有按时达成目标的惩罚，这是使压力产生推动效力。惩罚的方法，训斥、绩效差评、罚款、扣工资、扣奖金、辞退（要遵循劳动法，事先和人事确认）。要事先和同事说明清楚惩罚的规则。过程中和结束后惩罚要有决心执行。
--
其次，是开发能力，这是从较为长期的角度来看，技术好能有更强的业务实现能力（能实现以前很难实现的需求），提高开发效率（开发快且质量好），
最后，是新技术应用（或称研发），从业务发展的角度来看，新技术和业务的结合能否创新业务过程或产品，从开发能力角度来看，新技术是否能够提高开发效率。
（针对偏重业务逻辑的系统，偏重专利技术实现的系统不同。一般系统概括地讲，没有什么算是核心技术，系统实现的业务逻辑才是公司的核心价值。有专利技术的公司一般也会从组织架构上把核心技术人员独立出来和实现业务逻辑的开发团队分开）
从高层来看，分两个层面，一是系统架构，二是开发人员
系统架构是一个系统质量、安全、可靠，能否快速适应业务变化上的根本。
当系统不是由一个人实现时，再好的系统架构，如果开发人员水平一般，也难保证产出的进度和质量。（这里不考虑协同工作方面，只讨论技术能力）
1.项目管理
需求、计划、进度、质量、实施、迭代衔接
项目管理是一项管理工具，管理类职位都会用到。有的技术管理要全权负责项目管理，有的有独立项目经理负责，技术管理负责协助项目过程管理。
项目管理的职责是统筹和协调不同职能人员共同在期限内达成项目目标。
首先，要明确项目的目标是什么。项目目标的业务价值是什么。准确理解管理层对项目目标的规划和期望。
明确项目的实施目标，时间范围——多长时间完成，业务范围——达成业务目标需要哪些业务，业务过程分别有哪些，每个业务过程为了实现什么目的，全部的业务过程是否达成项目的目的，每个业务过程涉及哪些人、职位、职责，项目范围——从业务范围中识别出项目目标系统的需求范围，按业务职能进行归纳整理，确定大致的项目模块。
项目成功的要素之一，高层管理的明确授权和各职能部门积极配合，项目前期要主动做好这些沟通工作。（如果没有这些，项目过程中更需要主动去各职能部门沟通）
需求调研，和各相关业务部门沟通，各业务部门当前如何执行业务过程，探讨基于新系统将如何改变业务过程，明确需求联络人和需求责任人。
第三方对接的业务过程，第三方的联络人和需求责任人。
调研技巧，了解现有业务过程要找业务一些人员，熟悉业务过程和相关背景情况的。从部门经理了解基于新系统的业务过程的设计，人员职责。
需求整理分析，
梳理基于新系统的各业务流程，系统的范围和职责，与系统交互的人员、岗位、职责，与系统交互的操作。按业务职能进行归纳分类整理（不同的业务模式、公司管理模式有不同的分类方法，遵循企业的管理方式进行分类）。
梳理系统用户类型：公司用户——组织结构（系统相关的）、人员、职位、岗位，第三方用户——人员、组织结构、职责等，第三方系统。
编制系统需求文档，和各业务负责人确认，和项目投资人确认。确认系统范围是否能准确支持业务过程，达成业务目标。
1.2.计划
根据需求范围和开发团队规模、能力水平，是否要分阶段开发，还是一次完成。需求规模大最好是分阶段进行，每一个阶段都按一个子项目进行。根据需求的业务优先级划分阶段。
需求分析和系统建模分析
在确定完整开发计划前，要让开发团队进行需求分析（需求复杂更要），从需求文档中进行提取业务领域模型（类似ER），根据系统的操作需求进行系统控制模型的设计。系统建模是在根据需求在设计系统内部结构和工作逻辑，使之能满足系统需求。这个过程中会产生细节与业务方的沟通和确认。
系统建模完成后，根据系统的逻辑结构，确认开发人员的分工（模块与功能），开发人员预计开发用时，技术负责人审核开发预计用时。
综合各职能开发人员（前、后台开发、测试）的开发计划，制成完整的开发、测试、发布计划。
为什么要花时间做系统建模分析后才确定计划？计划是开发人员根据对需求的理解和设计实现的逻辑，并依据自己的能力、经验做出的估算值，包含着开发人员对按时完成计划的承诺（激发主动性有更好的执行力），同时让计划的时间周期更真实、合理，更能反映实际的可能结果（和管理层的期望是否偏差，进行双向沟通，促成一致）。系统内部逻辑设计更合理，有更好质量保证，开发人员的分工、任务衔接也更合理、有效，促进开发内部的协作更有效。
项目有截止日期，但开发计划远超截止日期，怎么办？开发计划要向项目干系人汇报，让项目管理层了解到更真实的时间成本。提出解决方案：从业务优先级的角度上，划分多阶段进行。适当增加开发人员，或者调用更高能力水平的人员。激励工具：奖励和惩罚机制。降低质量、安全的期望。增加每日工时（加班）。
1.3.进度
计划执行过程中，以日为时间单位更新项目进度，以重要任务节点和周间隔向项目管理层、项目干系人、项目组成员更新项目进度
掌握进度方法：（1）问询项目开发人员，收集整理。——站会、单个问询、主程问询（2）借助项目管理工具，让项目开发人员每天实时更新开发任务完成进度（小时单位）。管理方通过工具查看进度，或产生进度报表。
阻塞问题的发现和解决
肯定会遇到阻塞进度的问题。如何及时发现问题？一线的项目人员主动报告，要求人员有主动性和预计性（个人性格——勇敢担当、团队氛围、公司文化）。问询项目进度时，发现延期问题，预计可能的会阻塞的问题（经验判断）。
应对阻塞的方法，如果是预计会发生阻塞，设计好应对措施。如果已经发生延期，分析原因（主观、客观，主观导致延期占少数），有把握能在具体时间内（可接受的）完成，记录延期问题和处理方案，造成的后果、增加的成本，相应地调整计划，向项目组、项目管理层汇报。（不要在项目过程中进行批评和指责，而是重点在快速有效的解决阻塞，尽快让项目进度恢复正常。项目进度压力正是考验团队协作，个人抗压、激发潜能，暴露或展示个人真正实力的时候）
1.4.质量
保证系统开发质量的方法有：开发设计评审、代码单元测试（白盒）、功能测试（黑盒）、代码评审、重构，还有性能测试、安全测试分别用来保证系统的性能需求和安全需求。
开发设计评审
为什么要做开发设计评审？开发设计是一个开发人员对目标系统、模块、功能的内部逻辑的设计，这个设计思路是否具有完备的逻辑性和系统性，是否满足全部功能需求和非功能需求，不同水平的开发人员是存在差别的。越早发现设计上的缺陷，越小成本来提升质量。设计评审也是提升开发人员能力的一个过程。
怎么做开发设计评审？在需求分析阶段，每个开发人员在确定的分工范围内进行实现逻辑设计，以文档为载体，记录和整理自己的实现逻辑。集中开发人员由高级开发人员主持，逐个开发人员表述自己的设计思路，由其他开发和高级开发人员进行点评。设计评审后，由开发人员根据自己的设计进行开发时间的预估（项目计划阶段）。高级开发人员要确保设计思路具有完备的逻辑性和系统性，满足全部功能需求和非功能需求。需不需要需求人员出席？建议不要，如果是系统层面的设计评审，是有必要需求人员出席，如果只是模块层面的设计评审，需求人员的参与程度很低。如果评审发现有需求待细化和理清，这正好说明开发人员没有做好分析设计的工作，需要改进在分析设计的方法和态度。会后单独去找需求人员去细化和确认，然后单独评审。
设计评审又推迟了开发时间，开发人员抱怨，管理层不理解，进度压力怎么办。简化评审的过程和形式，比如只安排一天时间做系统设计，文档要求简单。和开发人员解释并化解他们对进度的压力（自己承担）。事先得到管理层的理解，哪怕默许。总之，相信这个过程对整体进度有积极作用，就要有决心自己承担进度压力。
测试用例评审？主要指功能测试（黑盒）的用例评审。测试也要做计划，测试计划是项目计划的一部分（关键节点），在需求分析和开发计划阶段，为了制定更合理的测试计划，测试人员对需求进行分析，编写测试用例。通过测试人员的需求分析过程，完善需求的逻辑性和系统性。测试用例评审是和需求人员的确认，主要讲述人是各测试人员，评审人是需求人员。开发人员是否参与我没有定论，参与的好处，这个评审的焦点是需求，因此开发人员参与能保证需求的细节和变化同步掌握。不参与的原因是，如果需求没有太大不同，开发人员的参与程度很低。
代码单元测试，可称为白盒测试，参考自测试驱动开发方法，测试驱动开发-自动测试体系的基础。（编写单元测试）方法大致是，针对一个功能接口，设计各种情况下的输入然后验证对应输出的结果是否符合预期。验证过程由系统批量自动执行。测试驱动开发，因为单元测试可以反复多次自动执行来检验功能的实现是否符合需求，利用这个自动验证特点，先写好单元测试代码，然后再去实现功能内部逻辑，直到功能接口能通过全部单元测试，这样功能开发完成。这种开发方式，让开发人员先不考虑功能内部实现逻辑，而是先从功能外部来考虑，功能在系统环境中，如何满足需求（功能的用户是谁？功能的用户应该怎样使用功能来满足他们的需求？），同时还要保证在各种系统异常情况时能有效处理。对很多开发人员来说，这是一种新的开发思维，理解了还要学习实践，积累一段时间后，才能产生开发效率提升的效果。单元测试的第二个优点，每次系统迭代开发，随代码提交触发的单元测试自动执行（持续集成），能检验发现代码改动是否影响了既有功能，尽早发现bug和冲突。因为单元测试其实也是一整套代码，也就是需要设计、开发、维护、清除等工作，一开始实施这个方法会增加开发工作量，可能是这个原因，我还没见到实际采用这种测试驱动开发方法的团队。这个方法不是开发过程必需的，如果开发过程成熟稳定，可以考虑引入实践。
功能测试，测试阶段的主要工作。由测试人员根据测试用例执行测试，发现不符合预期结果的记录到bug跟踪系统。bug跟踪系统是这个阶段重要的管理工具，从一个bug到记录、开发人员确认、修复、测试人员回归通过、关闭，有一套bug跟踪处理的过程。记录bug主要做好分类、可复现的操作过程说明、异常信息、正确的期望结果。成熟的bug跟踪系统能有效地支撑起这个过程。
代码评审，在已经完成的代码基础上，由高级开发人员进行代码走读。目的是发现代码的逻辑缺陷、安全缺陷、是否违反代码规范等，提高代码质量和提升开发人员能力水平。配套的工具有静态分析，能够帮助发现代码中的违反规范、缺陷代码。代码评审一般在开发阶段的后期，能发现的问题少，而且往往一个点会展开讨论哪个更好很长时间，提高代码质量的效果一般。从这个工作的目的来讲，要更好达到这个目的，应该试试从开发总结的方向来组织，不仅仅只是高级开发人员检查，开发人员自己对比开发前的设计思路进行总结，激活开发人员主动性，培养会思考总结的自我学习习惯。还有重要的一点，评审发现了的问题，要明确改进目标，落实到人和时间，以及验证交付等过程。
重构，指的是比较大工作量的改写既有代码的工作。针对现有系统的质量、性能、安全等问题（累积的、严重的，影响后续迭代开发效率的-不灵活），经过分析发现了可以改进的架构、模块、功能，明确重构的目标、范围，按一个项目过程进行。重构不是重写，是在现有代码基础上改进。参考重构的具体方法，可以有效的开展重构代码的工作。
性能测试和安全测试，根据需求和成本，是否需要（能不能）安排。成本因素，性能和安全需要非常专业的人员，不像一般开发人员比较稀缺。性能测试相比安全测试比较找到人做（内部学习培养）。
发布，在功能测试通过后，发布系统到正式环境。前端app打包签名发布，web前端、后台打包发布。利用持续集成和发布的工具fastlane、jenkins，发布操作触发后，自动从代码仓库提取代码，编译、打包、（app签名）、部署到目标环境（app上传到市场）。参考devops实践
实施，就是如何将系统运用起来，最短时间发挥出系统最大效果，达成项目业务目标。
对外部终端用户，在产品功能设计时（需求阶段），就需要考虑界面和交互方式容易理解，简化用户的操作，目的是用户不用太多学习过程，能快速掌握系统的使用方法。
对业务用户，在需求阶段确定了新业务过程后，制定新业务过程的规范手册，说明工作流程，明确过程中各部门、职位、岗位人员的流程职责。涉及组织结构变化和岗位职能调整的，在系统发布前做好沟通准备工作。培训，对实施涉及的业务人员进行培训，说明新业务流程，职能变化情况，搭建培训环境，让业务人员练习操作，熟悉系统中业务操作过程。外部业务（商业）用户也需要做好新业务流程和系统操作的培训。
1.6.迭代衔接
假如系统分阶段开发，怎样能让两个阶段之间的工作衔接更紧密，更充分利用好项目成员的时间？要先做好一个完整迭代的流程规范化，就是开发过程清晰，每个环节的人员分工，环节之间怎样互相配合协作，开发团队的每个人都非常清楚。（这个规范化是当前项目团队达成一致的最佳实践，外部的规范化或最佳实践都是参考，启发团队成员去思考发现团队效率的问题有哪些，根源是什么，可以采用什么方法来改进。）有了一个规范的迭代流程，就容易找到两个迭代之间可以衔接的点，比如前一个迭代进入到测试后期就可以安排开发人员进行下一阶段需求分析和设计评审。
最有效的迭代衔接，是去中心化的迭代，也就是团队每个人都积极主动，不需要人居中去协调统筹，通过每个人互相之间的有效沟通来协调工作，每个人都以项目目标为先。
项目管理，从技术管理人员的角度来说，可能更具体一点就是开发过程管理。在不同的公司，不同的组织结构和职能分工的前提下，开发过程管理对于技术管理者会有不同的要求，无论管的范围是多还是少，都应该站在更高的业务层面，推动过程的持续改进，提升开发过程的生产效率。
对开发过程建立和改进，同时要思考开发人员的组成、分工，主要的工作职责。
完善开发过程是一个持续的工作，要有开发人员的参与，因为他们是工作在这个过程中的一线人员，对自己和同事的能力、态度，对过程效率的体会都有更直接的了解，开发管理者要激发他们针对过程，敢提问题，组织他们对问题说出自己的想法（分析原因），说出自己的改进的办法，综合讨论意见，最后重要的是，确定下来一个具体改进的方法，明确改进方法中各个人的分工，然后落实到实际开发过程中。每一次对开发过程的改进尝试都参考戴明环PDCA方法（计划-执行-检验-改进）
能够调动开发团队的每个人积极参与工作过程的改进中，就能激发他们的主动性。一个高效率的开发团队，是能持续自我学习提高的，是能自动自发的努力达成目标的，至于统筹管理，已经不重要了，即使有这个岗位，他也是团队中平等的一份子，只是可能更积极活跃些。
我把能自我管理的团队作为实现高效率团队的目标，是基于我相信，每个人在满足物质报酬之外，更加希望能完善自我，在一个集体中实现自我价值，这个意愿是真实的，而我看到很多情况下是被压抑被忽视的。如果你希望团队能有很好主动性能自我管理自我学习，你只需要给予他们自主的空间和时间，然后就是信任和等待。
我感到，在我实际工作的压力，大多都源于管理层的不信任和没有耐心，对于他来说这是有正当的客观理由的，但那些很难解释他们把人放在第二位。也包括我自己作为管理者的时候，这应该也是要在管理意识上学习提高的过程。
一个问题，人只有在被动的压力下，才能提高效率，才能激发潜力吗? 如果认为这个答案是不，那怎样能让人产生主动的想法，去提高效率、激发潜能，首先前一个问题，人会不会有这种主动性的想法？当然有，除非他没有想到这种主动性带来的好处--一个独立自我意识的存在——我为什么是我？唤醒一个人的独立自主的意识太难了，通俗点的说法，主动性能让开发人员更多的感受到开发——编写代码——带来的乐趣和成就感，或者说下被动压力的负面，压抑、和自己没啥大关系的成就、对业务目标的无感。不能产生主动性，有的人是没有想到主动性的好处，有的是觉得没有这样的环境。因此要有人去讲，去解释，去启发他们。也要和管理层沟通，无论什么方法要争取到尝试的机会，有空间和时间来实践，用结果来证明有效和可靠。
2.技术管理
2.1.系统架构
什么是系统架构？什么系统架构是‘好的‘？
承载业务逻辑的信息系统，抽象于具体的业务逻辑，
根据业务需求，在不同时期，系统架构有不同的形式。
系统架构有很多层次，
1.网络 基础的公司内部网络基础框架，支撑公司内网的系统运行。 这是归在运维的工作。
目标系统可能部署在公司内网、私有云（私有服务器托管数据中心）、公有云
有擅长网络架构设计和网络部署知识的人来进行部署和维护，是后面组织devops的硬件基础。
初级的叫网管，能负责网络拓扑设计和实施，实现和维护网络通讯的基础服务，确保稳定、安全和高速。
服务器的采购、配置、维护。偏重硬件方面。
ad、mail、ftp系统的搭建，账号密码的权限管理。
这方面也属于是公司IT服务管理（ITSM）的主要部分，看公司的组织结构设计。有规范的ITSM可以指导这项工作做的更完善和规范。
高级网络工程师，除了具备丰富经验的网管能力外，熟悉linux、windows服务器环境的管理维护，
重要的是懂虚拟化技术，能实施虚拟服务器和集群的搭建，能建立服务器自动监控和报警机制。这就是devops的基础了。
能做服务器性能优化。
熟悉各数据中心的线路情况，能分析私有云全国线路访问速度，并制定优化策略，联系和谈判并实施，优化私有云服务器访问速度。
服务器安全配置有经验。制定服务器维护规则，保证服务器的高可靠性和安全性。
制定应急方案，持续评估各种灾难风险，制定相对应的应急和挽救措施。
制定公司内网网络安全策略。监控私有云的网络安全。也需要纳入到灾难风险的防范范围。
安全是一个很专业，无法绝对把握的技术。但网络工程师应该在网络安全范围内尽可能进行全面、规范化的管理。
根据公司规模和对安全需求程度，可以增加专门的安全技术人员，或者购买第三方安全公司的专业安全服务。
2.信息系统架构
首先是Java、Net、PHP语言的区别，
基于Java的技术非常丰富，是主流技术语言，开发人员也容易招募和培养。
.Net 主要C#语言，遗留系统或经典的企业信息管理系统会采用。
PHP 初创企业比较多采用，网站和电商相关业务系统也比较多采用。相比Java特点是开发和部署更快一些，但开发人员相对难招，系统规模扩大后，扩展灵活性、高并发支持的技术方案不如Java丰富，那么容易实施。
系统架构的选项
有单一、分布式系统，更复杂的SOA。
根据系统规模的大小、发展快慢和开发维护成本综合考虑，
总的来说，系统架构要保证能实现快速迭代开发，快速实现业务需求，同时要保证系统的健壮性，不能因为快速迭代，搞混乱了系统架构，引入高成本的系统性隐患。（为了满足快速迭代，技术债务不可避免，这需要在业务和技术之间不停寻求某种平衡的过程，开发经理应该注意系统架构的变化，做好不断完善系统架构的准备）
一个互联网业务系统抽象来看，面向C端（用户端），有web、h5、app前端（微信服务号），业务逻辑都在后台。
还有一个web面向B端，比如业务管理后台（B端还会有应该指外部商家或合作商户，看业务模式），如果是B端也有移动环境下的需求，还会有h5、微信、甚至app的前端。
C端 | | B端
web、h5、微信、app | 业务逻辑/数据存储 | web（h5、微信、app）通过web后台，初始和配置系统，设置好常用的业务参数。
前端和用户交互，接受用户的输入，系统进行业务逻辑处理、数据存储。
公司业务人员通过web后台，进行业务操作，系统进行业务逻辑处理（比如，统计、推送等）、数据计算和存储。
在只有单一web前端时，可以采用类似jsp服务器脚本方式直接处理用户交互，这样整个系统可以为一个项目工程。系统架构简单、开发快，开发人员规模很小，人员和过程管理很少。通常后台web前端会采用这种技术方案（只有web前端需求时）
多种前端时，系统业务逻辑以api接口方式提供给前端调用。项目工程会按前、后端进行分离，开发也按前后端进行分工。此时增加前端开发人员以及前后端协作开发的过程管理，以确保开发质量和进度。
适应业务规模的变化，
（1）用户量和访问量的增长，系统要增加支持的并发量，保证速度和稳定。
简单的方案是升级服务器硬件，对服务器系统进行并发优化配置（操作系统和web、应用服务器层面）。
增加访问缓存层比如CDN，memcache，注意，缓存数据的更新逻辑要符合业务要求。
分布式部署，负载均衡+多实例应用服务，
并发瓶颈很快会传递到数据存储层，在高并发的请求下如何保证数据的唯一性？
按业务逻辑分库，多数据库实例。
(2) 突发爆发性增长，系统要弹性支持，保证系统整体稳定
增加系统自动监控和报警（devops实践）。
公有云，自动部署应用实例
增加排队的业务和系统逻辑，缓冲访问量
(3) 安全性 DDOS攻击、短信轰炸、
DDOS攻击 防范和应对——CDN引流
短信轰炸 增加验证码验证
https 通信加密
我在分布式系统架构的知识和经验都很不足，分布式系统架构确实也很复杂，了解这方面的知识其实不难，难在要有实际工作的积累。
前端架构
web前端，
app前端，MVC是基础的模式，每个业务模块按MVC进行职责分离。如果服务基于api，网络通信|api服务 作为基础层，向上层提供服务，以Model对象为接口交互数据。
MVC | MVVM （先按业务分）
api服务 | UI基础组件（弹出窗、提示、列表的下拉更新和上划加载、导航条）
网络通信 | 持久存储 | 统计 | 分享
数据、图像缓存、web页面、https认证、Socket | 简单键值对、SQLite、加密、KeyChain
兼容性，设备兼容：1.针对各种屏幕尺寸、分辨率，页面都能很好的适配，不变形，2.设备是否存在，读写的数据规格是否能统一。系统兼容：支持的各操作系统版本API的兼容。
安全性，数据通信加密，app加固（混淆、反编译），本地加密读写。这只是app前端安全级别，属于系统级别的安全性一部分。
稳定性，不能出现闪退、卡死（假死），涉及app全部范围，主要原因在内存处理上。开发、测试阶段确保逻辑分支要严谨、有效，代码静态检查工具，代码评审。要在发布后能快速定位原因，要通过系统提供的系统异常处理机制，捕获异常发送到远程服务器。第二类主要问题是异常情况处理，网络变化或异常、接口异常（延时、无响应）、特殊机型。热更新，发布更新包，app在线下载修复bug。
多媒体，图片、视频、声音，高级图像处理：图像识别、机器学习（图片分类、图像人脸、文字识别、语言分析）、AR
感应器，蓝牙、NFC、指纹、GPS等
发布管理，app推广渠道的跟踪、统计。app市场的发布过程、审核材料、审核问题跟进、下载统计。持续集成 - fastlane+Jenkins自动打包、签名、发布到测试平台、发布到市场。
H5混合，开发周期不受市场审核限制，可在线更新。H5与原生功能的相互调用。
跨平台技术，React Native以JS为开发语言的跨平台原生app，可以降低app开发人力成本，提高开发效率——一个模块可以由一人同时实现iOS和Android。并且可以部分UI组件复用到H5页面。
2.2.开发人员
态度、能力，基本上也就是划分人员的两个主要维度。在能力相同的情况下，态度积极的更好。
态度，培养起积极主动的态度。要改变一个人态度，首先你要先了解这个人（具体的一个人），现在是什么态度，为什么有这个态度，怎么去改变。这需要很多的思考、沟通、双方面（我和这个人）的实践，需要一定的时间才能做好的事情。而且，你还不一定能成功。一个团队里，能真正能改变态度的人很难做到全部。但这件事还是可以做到的。从哪些和我相投容易说服的人开始，再针对大部分有良好自我发展意愿的人，细心耐心的交互，只要大部分人能体现出态度的改变，剩下的也能带动起来。按这个策略去实施是可行的。
注意，态度根本的改变，是环境，我只是在有限范围内创建了一个可以去主动发挥的空间来营造一个环境，但公司的大环境——管理层的态度才是决定性的。管理层是否认可这种创造自主性空间环境背后的管理方式，会决定这个环境的有效期有多久，除非你有证据（业绩）能证明这个管理方法是有效的。这个矛盾，是开发管理者需要面对的挑战。
绩效考核是可以用于态度管理的工具。只是工具之一，因为并非对所有类型的人都有效，要有更多的方法。
能力，技术能力是开发效率提升的根本。这是一项长时间投入才能产生效果的工作。但也要走在公司业务发展的前面，时间紧迫性也是有的，所以要注重方法的灵活运用。
通常，绩效考核会有能力考核的维度（如果没有，需要建立这样的考核制度），通过这个管理工具激励人员平时注重提升能力。
首先要建立一套衡量标准（指标）来量化能力水平，这样通过一段时间的量化比较来检验提升的效果。怎么建立量化能力的标准？参考专业技术的知识结构，从基础知识到专业知识，同时也参考招聘市场上不同等级技术人员的能力要求，挑选公司业务发展需要的重视的、可行性好（好量化评估的）的指标。然后是量化值的定义，比如10分制还是5分制，每个分数级别要定义清楚对应代表的熟练水平。重要的是，这些量化指标项目要开放和开发人员一起讨论，要有大家对评价项目的共识。量化指标要确定定期更新的维护制度，比如季度、半年，一方面为了改进实践中发现的偏差，另一方面保持和技术发展同步。
有了激励工具来推动，下面的问题我觉得更重要，能不能让更多的开发人员主动去提升能力？-调动自我学习的主动性。如何做能提升能力？-如何更有效的学习？这些问题的目的是为了让技术能力提升更有效的落实。调动自我学习的主动性是一种引导的力量，学习时间的利用和学习效果上都比被动的更好一些。调动的切入点从为什么要提升开始，要先了解每个人的职业发展意愿，不同的技术、经验、年龄、性别都会有不同的想法，要真心去谈，在了解的基础上，提出和公司的技术发展需求上找到结合点。一般人首要动机是待遇，有利于待遇提升这是最直接的动因，其次是自我价值的实现，能够在一个集体中具有更大的价值，具体一点就比如能最大地发挥自己才能（这是真的有效的一个动因，至少我相信是，不会是全部人，但大部分人是有的），以两个动机作为沟通的基础，既要站要他们个人的角度，也要站在公司发展需要的角度，提出务实有效的建议。（注意：要务实要务实）这种沟通效果不保证对所有人有效，而且要有平时与同事的良好互动基础。有效学习的方法，也是因人而异，有一个方法实施起来效果好，需要投入精力和时间。以项目管理的方式进行协助，确定好一个时期内的学习目标（或者一个学习目标分阶段），学习目标一定要结合公司实际业务或者实际项目，我会在过程中不定期了解进度，并在结束时间点，检验学习目标。通过外部监督压力来促使学习过程更有效的落实。这种辅助方式因为要投入时间成本，不可能同时应用到所有人，只对当前业务发展需要的技术能力进行应用。其他个人的学习，推荐采用这种项目方式进行自我管理，在达成学习目标后，再通过技术分享的方式进行加强。重点，一定要注重实战、和公司实际业务的结合、有实际产出的系统。
不要忘了需求分析阶段的系统设计评审和测试阶段的代码评审，也是提升能力的一个重要环节，这里的实战性很强，效果通常最好。
团队氛围，绝大多数人喜欢融洽的团队环境，容易融入，有自己的位置，没有压力，能互相促进能力提升（能学到东西）。这种环境的价值从管理层的角度来看，有更好团队协作效果，面对压力有比较乐观的态度。其实也能称之为团队文化。怎样创建好的团队氛围，和管理者自己的管理思维和个性有关，我自己偏好轻松融洽的团队环境，自己和同事们以一种平和轻松的方式来交流，其实同事们之间本身就能互相很好交流，管理者只是放开自己，整个团队交流也就公开的放开交流了。具体的做法很个性化，我和同事沟通的准则是真心、以平等同事的角度、多听少说、尊重理解包容，也要会主动硬插话（很少有人主动找老大聊天），因为有职位利益上的关系，我不指望能有同级同事之间的对等沟通，所以如果同事们聊的话题不适合介入的话就不硬插话或者识趣走开。管理者做这个工作，一是为了维护和同事之家良好合作关系，在执行管理工作时能有机会获得他们的支持和配合。二是为了培养团队内部更广泛的人员关系，更开放的沟通环境，可以促进更大范围的人员关系的建立。在项目和研发学习的过程中，要保持持续稳定的压力推动，压力和引导力相比，压力还是更为基础，在保持和提高生产效率、激发个人潜能上是最有效的方法。工作压力主要来自于时间，要达到目标所需要的时间很紧张，有时限定的时间感觉几乎不可能实现。因此推动压力的第一，要说明清楚目标、范围以及完成目标的时间限制。推动压力的第二，是没有按时达成目标的惩罚，这是使压力产生推动效力。惩罚的方法，训斥、绩效差评、罚款、扣工资、扣奖金、辞退（要遵循劳动法，事先和人事确认）。要事先和同事说明清楚惩罚的规则。过程中和结束后惩罚要有决心执行。
两个和压力相关的做法，在个别同事体现出过高压力的反应时，要帮助舒缓压力，或者转化部分压力为积极态度，或者调整工作消除部分压力（压力要有但不要过分，尊重体谅不同人的承受能力，尽可能多一点转化为积极主动的态度）。不合理的进度承诺，有客观和主观两种情况，先说主观情况-过低估计，过低估计在开发进展时产生越来越大的压力，如果前期能预见到，又是项目主过程任务，做好沟通调整计划或者设计好风险应对措施，如果不是项目主过程任务，要根据同事的个性来处理，个性坦诚有担当的，只需要注意他的压力应急是否过大就可以了，不愿担当的，责成自己反思-说明主观过低估计的根源，按惩罚机制执行，最后再调整范围和计划。客观情况-经过分析后仍必须不合理进度，或者没有分析的进度要求，这种情况我会首先做好承担责任的心理准备（除非我已经不想干了），一方面将凭着分析后的计划向上级做好期望平衡，一方面梳理需求和系统设计，准确识别出重要任务和主要范围，调动能调动的资源来保证重要任务的顺利执行，事先和大家做好解释和安抚，减少消极情绪，尽可能转化部分压力到积极主动方面，在测试阶段把控问题的处理优先级，优先处理重要且紧急的bug，其他不紧急的按重要程序排列，排列到时间限制之外都可以。在这种客观背景下，我个人认为不适宜去对团队应用惩罚，同时自己要准备好承担上级惩罚的心里准备。这种情况，其实也是上级对管理者自身的一种压力推动，转化部分压力为动力，激发潜能，主动担当，积极的看法是这也是自己一个提升能力的机会。要会自己调节压力，不指望上级会在你感到压力承受不了时来帮你缓解压力，尽可能保持乐观的心态，多从乐观积极的一面来帮助自己。如果成功的完成了任务，首先想感谢同事们，他们对我的帮助很难表达出来。对于上级给予的压力，从积极一面来讲，对自己的职业发展是有利的，综合来看，我也希望能有一个通情达理的老板。