一、技术管理工作

1、给团队成员信心，给资源协助。

2、要有技术说服力，上一线工作，从管理上给团队支持。

3、“我才刚到任，还不熟悉情况，你们酌情处理。”

4、具备能力：

（1）深入理解一门或多门编程语言。

（2）深入理解多种流行框架。

（3）系统架构能力强，拥有复杂系统的设计经验。

（4）积极跟随开源社区。

（5）积极了解业界技术发展。

（6）沟通能力强、情商高。

（7）有产品意识，不是技术迷。

（8）会带人，服从领导，责任心强。

（9）会写专利。

（10）随叫随到。

（11）再会点别的更好。

5、给团队指明方向，包括技术方向、业务方向、个人成长方向。

6、不惧怕外在的威胁，团队成员都在看着，决不能懦弱，要勇敢。

7、学东西不止要听懂，还要会执行，还要能讲解给别人听。

8、要吸取失败的教训，总结经验。

9、不断抽时间和团队成员一起探讨架构、业务流程、技术难点、技术方向。

10、具备决策能力：

（1）开放的提炼能力。

（2）准确的预测能力。

（3）准确的决断能力。

（4）克服从众心理。

（5）增强自信心。

（6）决策勿求十全十美，注意把握大局。

11、抓细节。

12、保持学习能力：

（1）通过网上的碎片信息来学习。

（2）通过读书来系统地学习。

（3）通过和别人交流来学习。

13、以人为本。

14、控制自己的情绪。

二、团队建设、人员管理

1、招聘，STAR：

（1）背景（SITUATION）：看取得的业绩与个人能力有关，还是与行业市场状况有关。

（2）任务（TASK）：看工作经历，具体任务内容。

（3）行动（ACTION）：看如何完成工作，采取的行动。

（4）结果（RESULT）：看行动的结果。

2、组建团队：

（1）“独狼”成员，要多关注他们的工作，如果出现问题及时纠正。

（2）“英雄”成员，要具备一定技术功底能和他们交流，资源对他们有所倾斜，放在关键项目中。

（3）“内向”成员，对他们的发言要给予正面支持，当面认可他们的贡献。

（4）避免“负能量”成员。

（5）避免“搞办公室政治”成员。

3、提高效率：

（1）先确保做正确的事情，再把正确的事情做对。

（2）弄清楚资源瓶颈，围绕它来组建流程，提升效率。

（3）工具化、自动化。

（4）高效的组织，每个人都会主动优化流程，并持续改进。

4、指出大方向，然后做好充分的检查，以确保成员做出正确的决定并实现。

5、会议需要记录，包括：参加人员、谈论议题、讨论过程大体描述、每个议题的最终结论、遗留问题、下次会议时间及议题等。

6、以结果为导向。“客户期望我做出什么样的成果？”然后再对整个项目进行规划。

7、你领导的级别越高，你的报告就越要精简，越要注重大局，细节更少、局面更大、文字更少、项目符号更多。

8、避免只把问题带给领导，最好是拿几套潜在的解决方案和问题一起给他。

9、主动承担，关注老板时刻关注的事情，超水平完成这些任务。

10、覆盖的团队成员不要超过10人，多于10人以上可以用分小组间接管理。

11、面对面交流时，关注对方，放下手机，停止处理电子邮件或写代码，看着对方，用眼神交流，仔细聆听对方在说什么。注意，信息并不局限于他们的话语，还有他们的姿势、身体语言、热情或专注的程度。

12、影响团队的因素：

（1）对工作努力的人，薪资方面要有所倾斜。

（2）让成员感受到愿景（Vision）。

（3）团队沟通氛围。

13、发挥成员的长处，抵消成员的短板。

14、OKR关注的是目标，KPI关注的是指标。关注目标的时候我们会思考接下来我要做的事情是什么；关注指标的时候我们会思考自己的工作如何评价。

三、产品开发过程管理

1、开发经理的职责：

（1）对产品开发全过程进行组织和管理，按预期交付产品开发的成果。

（2）管理产品开发团队，为成员提供技术和业务上的支撑，使之高效而愉快地工作，并获得最满意的工作体验。

（3）管理对外关系，以取得外部对交付成功及过程的最满意评价。

2、开发经理的主要任务：

（1）与产品经理交流。

（2）负责产品开发交付。

（3）完成产品开发收尾。

（4）管理干系人的关系。

（5）管理项目团队。

3、开发经理须具备的基本素质：

（1）领导力。

（2）责任心。

（3）积极主动。

（4）抗压能力。

4、瀑布式开发模型：需求->设计->实施->交付。

5、Scrum主要着重于项目管理，团队中的项目经理需要在每个客户需求到来的时候制定Sprint的周期，定义每个Sprint的目标，分派任务、进行监督，最后总结得失并开始计划新的Sprint。

6、软件开发生命周期管理方式：CMMI、RDMS

（1）CMMI（能力成熟度模型集成）是一种过程改进的方法，可用于指导一个项目、一个单位或一个企业的过程改进。

（2）CMMI成熟度等级：初始级、管理级、定义级、量化级、优化级。

（3）RDMS（研发管理体系）致力于公司的产品开发并提供最佳的实践及指导方法，适用于公司产品开发全生命周期的管理。研发管理体系框架一般包括概念、定义、设计、实现、验证、移交、维护等多个步骤。

7、项目启动会议程：

（1）介绍议程和来宾。

（2）介绍项目目标、阶段计划、管理方法。

（3）发布项目的组织结构图。

（4）确认关键角色及其职责，并作出承诺。

（5）参会人员针对介绍内容进行提问交流。

（6）高层领导做项目动员发言，激励和鼓舞士气。

（7）各个相关部门领导表态支持项目工作。

8、开会评审需求或方案时，针对需求理解不一致情况的处理：

（1）开任何会议，不要上来就讲解方案，应该先讲解场景。每个场景先讨论背后的需求并定义清楚。

（2）大家一起讨论、研究这个场景背后的需求是不是最佳场景，能不能删除这个场景，或者是否有其他场景可以替代这个场景同时还能满足背后的需求。

（3）如果是需求的最佳场景，再开始讨论这个场景下的产品解决方案。

（4）这时候再打开事先设计好的产品原型图、产品流程图、状态图、用例图，你会发现有很多需要修改，修改之后就是大家一起生成的方案。

9、产品需求一般包括：产品需求规格说明书、产品需求矩阵。

10、需求评审方面：

（1）WHY：为什么做这个需求？

（2）WHAT：需求的价值是什么？

（3）WHEN：需求期望什么时候上线？截止日期？

（4）HOW：需求是否完整？正常场景是什么？异常场景是什么？技术上分别怎么应对？

11、需求评审后编写技术方案，方案中必须有业务流程图和时序图。业务流程图是为了梳理开发对业务的理解，确认是否和需求一致。时序图是为了梳理本次需求涉及的系统交互。

12、总体设计包括：

（1）产品描述。

（2）涉及约束。

（3）总体设计：产品设计的技术总体介绍，主要包括软件架构及模块划分、模块描述。

（4）接口设计。

（5）备选方案及方案对比。

（6）集成要点。

13、设计方针：

（1）一个不能工作的“最佳设计”的价值是值得怀疑的。

（2）应该在设计的早期阶段尽量对软件结构进行精化。

（3）结构简单通常表示为设计风格优雅，同时保持高效。

（4）模块划分首先要有合理性，减少耦合。

（5）先使它能工作，然后再使它快起来。

（6）从坚实的内核做起。

（7）从小到大慢慢来：一点一点由小变大，而不是通过一次性组装变大。

14、概要设计格式：

（1）简介，说明编写的目的。

（2）总体架构。

（3）模块说明。

（4）接口说明。

（5）数据结构设计。

（6）系统出错处理设计。

（7）在这阶段，设计者会大致考虑并关注模块的内部实现，但主要仍集中于模块的划分、分配任务、定义调用关系。模块间的接口与传参在这阶段要制订得十分细致明确，需要编写严谨的数据字典，避免后续设计产生误解。

（8）概设文档最重要的部分是分层数据流图、结构图、数据字典以及相应的文字说明等。

15、详细设计：

（1）一个模块对应一篇详细设计文档。

（2）文档最重要的部分是模块的流程图、状态图、局部变量及相应的文字说明等。

（3）常用的描述方式：流程图、N-S图、PAD图、伪代码等。

16、编码技巧：

（1）优先考虑核心模块的压力测试。

（2）确保过程可控。

（3）不满意的预留地方写注释。

（4）用人人看得懂的逻辑。

（5）不要沉迷于框架。

（6）使用熟悉、成熟的技术。

（8）细节没优化前，别谈架构。

（9）多留日志。

17、编码原则：

（1）简化控制流程。

（2）为循环设置上限次数。

（3）不使用动态内存分配。

（4）不使用冗长的函数。

（5）低断言密度。

（6）以最小范围级别声明数据对象。

（7）检查参数和返回值。

（8）限制预处理程序的使用。

（9）限制指针的使用。

（10）编译所有代码。

18、根据时间管理的经验，安排工作的原则顺序为：重要/紧急工作>重要/不紧急>不重要/紧急>不重要/不紧急。

19、成员工作安排：对工作进行拆分，每天的工作要能说清楚它的具体目标、要求标准等，这样才能让大家有存在感和参与感。

四、技术调研、技术预研

1、技术调研：是针对粗粒度需求实现方案进行的研究，很有可能对所需技术根本不清楚，需要通过调研项目来完成技术了解、技术选型、技术可行性分析、技术方案设计等工作。

2、技术预研：是针对细粒度需求的实现方案进行的预先尝试，主要针对的是通过技术调研所选择的技术，同时结合我们产品化时的实际需求，对实现时存在的不确定性因素、细节等进行预先研究、尝试，从而减小产品化过程中的技术实现风险。

3、技术调研报告：首先阐述从需求整理到明确方向再到搜索技术调研方案及初步筛选的过程及结果，接着介绍具体的测试方案确定、测试环境搭建、测试用例编写及运行的过程，最后针对调研项目中得到的一些实际业务场景下的运行数据进行对比、分析，通过解释数据产生的原因来明确下一步计划。

4、技术预研：首先根据细化的需求（有可能是产品化需求的一部分难点需求）对系统整体进行定义，接着通过列举方案明确的本次预研论证过程，再通过论证过程反复执行列举、论证、推翻、再列举这一过程，最后是对本次预研获得的最终结论进行总结。

5、技术调研一般针对每一项技术都会有一份单独的报告，然后汇总成一份调研报告（对各项进行汇总、对比、总结）。

6、技术预研一般只有一份报告，通过这份预研报告说明预研项是否成功，是否可以采用该种方案、技术并进行下一步的产品化立项。

7、技术调研思路：

（1）了解动机。

（2）明确目的：需要明确本次调研项目可能涉及的具体技术内容（可以不明确，通过模糊搜索方式进行初步筛选即可），确定调研过程中需要对各个技术的差异点、技术实现原理进行总结，并通过测试数据、数据对比及原因分析，分析哪种技术或者框架适用于用户提出的实际需求。

（3）确定步骤：尽量多地收集各种方案和资料；迅速粗略地过一遍上述方案和资料，大体上总结出几种可能合适的方案；针对几种方案，一边调研每种方案，一边做笔记；最后拿着笔记做最后的横向对比；得出结论，同时因为做了笔记，反馈的素材也有了。

（4）结论跟踪：反馈的内容有几点是需要写进去：简要说明下调研需求；介绍跟需求相关的前置知识；目前有哪些方案，具体分析各个方案的优缺点及适合的场景；技术调研的结果是怎样的，不可行的话是因为什么，可行的话说说最终决定使用何种方案（自己无法决定的话可以开个分享讨论会），并说说该方案跟其他方案比有何优势；假如是新库的引进，需要简要介绍该库的使用方法及内部原理；调研过程中碰到了哪些问题，如何解决；

8、技术调研的过程：需求整理→明确技术方向→搜索技术调研方向→调研方向初步筛选→选择技术调研方向→确定调研测试方案及用例→调研执行→调研数据对比→调研结论。

五、系统架构

1、架构拆分的原则：首先来源于业务自身的组织架构，软件架构要保持和业务组织架构的匹配关系。

2、架构师回答这些问题：

（1）我们这个系统的边界是什么？

（2）我们系统由哪几部分组成？

（3）各模块之间怎么通信？

（4）选择什么样的基础技术？

（5）为什么要这样选择？

（6）技术方案未来会遭遇哪些坑？

（7）我们的备选方案有哪些？

（8）从技术角度这个应用将来如何持续扩展功能？

3、架构师都要有觉悟，理解并发现问题永远比解决问题更加重要，遇到问题首先进行分析，不要急于解决问题。

4、架构师要发现问题的主体，并确定核心问题。在确定业务核心生命周期以及核心生命周期的主体之后，架构师还需要对业务核心生命周期进行分析，剥离出非核心生命周期，并根据当前人员的状况，合理地分配非核心生命周期的权责。这样不同的人就可以并行且互不影响地做不同的事情。

5、工具：MindManager，EnterpriseArchitect。

6、架构师要把时间花在研究生命周期规律和业务的增长上，花在选择合适的技术上，而不只是追求新潮的或自己喜欢的技术。

7、业务、架构和技术之间是共生的关系，而不是互斥的关系。业务是核心，技术是解决业务问题的工作，而架构是让业务长大的组织方法。

8、架构拆分的原则如下：

（1）如果必须要生命周期的主体在连续时间内持续执行，不能够被打断并更换生命周期主体，那么被拆分的生命周期，不能切分出去。

（2）每个生命周期的负责人对所负责生命周期的权利和义务必须是平等的。

（3）切分出来的生命周期不应该超出一个自然人的负载。

（4）切分是内部活动，内部无论怎么切，对整个系统的外部都应该是透明的。

9、应用架构设计的建议：

（1）系统定位和边界要清晰，对应的业务定位和边界要清晰。

（2）系统要实现松耦合、高内聚。对外界系统要透明、简单、易理解。

（3）易变的、尝试中的新业务要避免影响现有业务的稳定性。

（4）系统之间数据要实现单向流转。

（5）架构设计核心目标是支持业务，有时候不合理的存在是合理的。

10、应用架构师在进行架构时要充分理解用户的需求，准确定义用户的需求，通过与用户交流从而为他们开发综合的解决方案。应用架构师在架构过程中会在不同程度上影响人员、流程和技术，一旦他开始进行架构的构建，就是在创造一种环境和条件，让流程更加有效、高速和符合用户的需求。

11、系统架构师是一个最终确认和评估系统需求、给出开发规范、搭建系统实现的核心框架、澄清技术细节、扫清主要难点的技术人员，主要着眼于系统的“技术实现”。