10、项目管理和团队建设


==前言：主要探讨移动项目管理、线上问题分析与解决、团队建设。
     拆分需求若干次迭代、激励士气、控制风险。


==项目管理决定了开发速度
项目管理最忌讳的几件事：
     1）：领导者高高在上，执行者欺上瞒下。
     2）：理想美好但是不切实际。
     3）：一次性改变太多，导致树敌太多。
     无线项目的管理，与其他项目不同，它涉及到IOS、Android、Mobile API和QA团队的相互依赖、分工协作的事情。
(QA：质量保证，联系协调着：业务分析、开发人员、客户)


==项目管理中的三架马车
【
对于研发部门来说，一个完整的团队，应该包括产品经理、开发、测试这3个团队：其中
     产品经理是三驾马车的灵魂。
     开发团队是三驾马车的主力。
     测试团队是三驾马车中的保证。
（互联网公司都走敏捷流程。）
】


==为什么不能没有测试团队
【
1）开发人员自测，只会按照自己编程的逻辑进行测试。
2）测试过多地占用了产品经理的精力。
3）测试工作不是产品经理的专长，有些情况测试不到。
4）产品经理对bug的关注度不够，反馈处理时效性不够。
     =测试团队应该负担的工作如下：看，
*全功能回归测试
*探索性测试
*渠道包测试
*MobileAPI发布上线前的测试工作
*压力测试
*Monkey测试
*客人投诉回访
==测试团队：一方面他们要对质量负责，另一方面，他们及时反馈迭代过程中发现的各种风险。
】


==产品经理应该做的事情
【
     应该花80%的时间在需求上，以确保需求尽量清晰。
     每日站例会
     测试提出的bug，确定为产品问题，要重新定义逻辑或降低优先级，不予迭代。
     验收需求
-要突破成熟产品的借鉴，就需要在用户体验、运营策略上小功夫。
】


==开发人员的喜怒哀乐
【
     开发人员，只有他们能把产品经理的想法或者尝试付诸实践，这才是其价值所在。
     开发人员要想尽一切办法实现需求，而不是一天到晚发牢骚。
     =开发人员抱怨最多的是:
     1)一句话需求。
     2)开发过程中，产品需求频繁变动。
     3)产品经理搞不清楚业务逻辑。直到开发过程中才发现有问题。
     4)UI设计图、切图、标注图不到位。
所有这一切，只能怪互联网公司节奏太快，不能像软件公司那样按部就班的工作。
】


==项目经理的职责
【
在敏捷流程中，项目经理也称Scrum Master：
     1》项目经理不需要知道太多的业务逻辑，他只关心项目进度就够了。
     2》一个团队是否高效，完全取决于项目经理的水平。
项目经理的事情非常琐碎，他不需要技术和业务知识，但是却一天到晚跟着项目进度走，和各个团队沟通，协调资源。几项职责入下:
     1)搜集开发计划和测试计划。
     2)主持每天的站例会，并发送会议记要。绝对禁止发送报喜不报忧的会议记要。
     3)积极面对风险，及时调整计划，以减少风险。
     4)及时解决各个地方的瓶颈。
     5)推动bug的修复情况。
     6)监督开发团队的冒烟测试、测试团队的探索性测试、产品经理的验收工作。
     7)如果开发流程需要同步到jira，那么项目经理要负责创建Story和Task。同步项目进度。
】
==以上介绍了无线部门敏捷开发中各个团队的作用。


==优化团队结构，让敏捷流程跑的更快
【
     应该不断地优化团队的结构和开发模式，不断尝试，发现好的地方要坚持，发现行不通，观察一两个迭代后果断撤回来，再去想别的办法。


1、平行模式还是垂直模式
     ==平行模式：就是Android、IOS和MobileAPI各自为一个独立的团队。在项目初期，团队间定制好MobileAPI接口的格式，约定好联调时间，就可以各自开工了。然后到了联调时间，再进行集成测试。
     ==垂直模式：就是按照模块，拆分出若干小的团队，比如说会员中心，就由一个小团队负责这个模块，有相应的Android、IOS和MobileAPI开发人员，以及产品经理和测试人员。
     ==运用垂直模式：垂直模式的开发模式使得这支团队非常高效。当App开发人员发现有个MobileAPI接口不能使用时，立马会与后台人员联调，测试人员发现问题，会跟踪问题从前端到后台，直到问题解决。所有人都对一个团队负责，为一个目标而努力。
     ==运用平行模式：拆分成若干个独立小团队的开发模式。并不能确保每个人都是熟悉所分到的模块；想做重构的时候，并不能确保每个小组进度一样。
     教训：在团队没有成规模之前，不宜拆分。人多点即使要才分，也要一步步进行。
     总结：从短期看，人少的时候，平行模式比较有优势；从长期看，随着业务规模的扩大，垂直模式是大势所趋。毕竟，对于Team Leader而言，手下超过6个人就会有管理上的问题。


2、让HTML5站点和MobileAPI的进度提前一个迭代
     做了这几年的迭代，切身感受是，一个功能点，只要是MobileAPI和App同时开发，就会延期。而那些现成的MobileAPI接口，App开发人员可以直接拿来使用，一般不会延期。
     可以尝试让HTML5网站先行，请他们去扫雷，回和MobileAPI早一个迭代把这个功能在HTML5站点实现了，下一个迭代再接入App。HTML5网站的特点是开发周期短，往往一个页面App需要1天，二HTML5页面一个小时就做好了。


3、如何进行模块化分工
     模块化分工是一个需要长时间磨合、调整的过程。要确保"让合适的人做合适的事"
     --没太多技术含量的活，需要一个沙僧型任劳任怨的开发人员来负责。
     --重要的业务模块，要踏实勤奋的开发人员，确保质量并按时完成开发任务。
     --技术能力强的人，效率高，做有挑战的工作任务，比如说Monkey日志分析，线上Crash分析并修复。
     --沟通能力强的人，适合每天解决每天的用户投诉，从而准确定位问题。
】


==App敏捷开发流程
【
     每个公司都有自己的开发迭代周期，有4周的，有2周的，也有1周的。


1、四周时间的开发流程
==巧妙安排迭代间隙
（敏捷开发的周期，包括从需求准备、排期、开发、测试到上线、发版，可长可短。
     ==需要做：
     1)：总结上次迭代的若干问题。
     2)：修复上次迭代来不及处理的Bug。
     3)：做一些代码上的重构工作。
     4)：讨论新需求，划分到具体的开发人员和测试人员，评估出工时和工期。这时要求产品经理的需求文档已经到位。
项目管理者需要去协调沟通的:
     --有些需求要求美工给出原型图和切图。
     --有些需求需要后端MobileAPI提供数据。
     --如果MobileAPI的进度比App的进度能提前一个迭代周期，那么就能避免App和MobileAPI并行开发所带来的风险。
     5)：在迭代正式开始的前一天，开一个冲刺会，标志着本次迭代正式开始。


==控制4周迭代的节奏
     1)：开始2周，是开发时间
     ==在开发时间内可能遇到额外的问题:
     1》上一个版本发现了重大bug，要紧急修复并发版。
     2》陆陆续续发现一些线上的bug，虽然不是很严重，但要放到本次迭代内修复。
     3》产品经理经常插入一些紧急需求。
     4》一些需求，临时决定本次迭代不做。
          第二周周五，所有功能都已经开发完成了，也就是所谓的Code Complete.


     2）：第三周，测试工作进入全面测试阶段，。
     3）：第四周，这周主要是测试人员进行集中测试、探索性测试和全功能回归测试。
）


2、两周时间的开发流程
==迭代第1周：(周一：修复线上Crash    周一：需求确认会     周四：测试用例评审会)


==迭代第2周：(周三，Code Complete      周四，产品经理验收     周四，Bug日清     周五晚上，Code Freeze    周五晚上，小流量包)


3、一周时间的开发流程


4、即时更新策略
     随时更新就要用到插件化编程和脚本技术了。插件化编程仅限于Android，这是一个庞大的主题。脚本编程就同时适用于Android和IOS了。目前业界普遍使用Lua，以手机行业用得最多。真正实现哪个做完发布哪个版本。
】


==项目经理的百宝箱
【
     --项目经理的任务评估表
（*汇总产品经理的需求，形成一个excel。：需求名称、产品经理、需求地址、设计师、UI提供时间、MobileAPI接口负责人、MobileAPI联调时间、Android开发人员、Android工时、Android工期、测试人员、测试工时、测试工期
    *召开需求确认会，请产品经理为开发人员和测试人员讲解需求
     *搜集各个团队每个需求的负责人和工时、工期。
     *把每个Tesk都写到小纸条上，贴到敏捷白板上。
     *有些公司倾向于把所有Task都用Jira来管理，这就需要额外花一些时间去维护Jira。）
    
     --贴小纸条的艺术
（开工前几项内容：需求标题、开发人员、工时、工期、测试人员。
   开发时间轴：BackLog：代办列表、Doing：开发进行中、CC：开发完成，等待测试、Testing：测试中、Done：测试完成。
）
】


==敏捷迭代中的会议纪要
【
敏捷开发过程中的四种必不可少的会议纪要及邮件：
--第一种：站例会邮件
（1)：每个开发人员进度。
   2)：提测功能，当天新提测的功能要用红色高亮显示，以区分之前提测的那些功能。
   3)：UI和MobileAPI进度，列出目前还没有提供的UI和MobileAPI接口
   4)：发现问题，包括新增需求、变更需求、开发计划调整，都应该在这里列举出来。
   5)：风险评估，任何风吹草动，都要反映在风险评估中。
）


--第二种：测试团队邮件
（测试进度和Bug情况：每个开发人员当天的剩余bug数量，每个测试人员目前还没有验收的bug数量。）


--第三种：分析Monkey邮件
（每天下班前，开发团队和测试团队要执行Monkey测试，跑一个通宵。Monkey日志，尤其是崩溃，开发人员去修复。）


--第四种：项目总结邮件
（每次迭代结束后，都要举行项目总结会议，请每个团队成员给出本次迭代做的好的和不好的地方各3点。）
】


==开站例会的技巧
【
1、早上开会效果会更好。
2、务必全员准时参加。
3、站例会控制在15分钟。
】


==如何确保项目不延期
【
过失延期有如下原因：
1）：估算工时过于乐观。
2）：中途事件突发，影响士气。
3）：新项目功能过多，近两个月的工时一次性评估风险很大。
对于开发周期过长的项目，做功能需求的拆分，多做几次产品的迭代，每个迭代都非常明确地完成一个固定的功能。
】


==迭代风险管理
【
     举例：两周迭代开发，第二周的周三晚上，应完成所有的功能，称为Code Complete。如果这个点踩不到，就会延期。延期一般发生在MobileAPI。他们只是一个中间层，问题出在底层的系统上，包括搜索、产品搜索、产品信息、支付系统、会员体系等等，传统互联网公司的这些系统原型都是为网站服务的，不能直接搬到移动互联网上。
     避免延期解决方案有：
     -1）：让MobileAPI的进度提前两周(一个迭代)。
     -2）：让HTML5网站先行，App下个迭代后续跟进。(前去"趟雷"，以确保App开发少走弯路。)
     -3）：MobileAPI还是要和App一起开发。那么MobileAPI一定要在开工前做好技术调研，需要提供哪些接口，用到底层哪些功能。
   第二周的周四：做到bug日清，如果达不到，说明有风险。
   第二周的周五：即最后一天，全功能回归测试及发版。
】


==迭代中的测试工作
【
     不光是测试人员的日常测试工作，还包括开发人员组织的自测工作。
1、冒烟测试(真正的冒烟测试，是针对修复了一个bug而进行的一系列专门的测试。在开发人员空闲的情况下，把他们集中起来，围坐在一张圆桌上，把App的所有功能都测一遍，我们称之为“冒烟测试”。“冒烟测试”主要是解决测试人力不足、覆盖场景不全的问题。)。
     新进的开发人员，无文档可供参考，让他们一起参加冒烟测试，每测到一个模块，就请该模块的负责人把业务逻辑讲一下。不光是培养了新人，对于长期做某个模块的开发人员，也是需要了解其他业务模块，而冒烟测试是最好的培训课。
     第一个迭代，冒烟测试差不多5次就够了，每天一个小时测试一个模块，保证了稳定性和保证iPhone和Android的数据展示和业务也基本一致了。
--会遭到质疑：开发人员更多的不是开发吗，怎么来测试了？
     1）：测试团队经常面临资源不足的情况，尤其是Android 和iPhone同时发版。
     2）：开发团队没有那么多的开发工作要做，因为产品团队经常会没有太多的需求。
     3）：App不同于MobileAPI开发。MobileAPI开发可以使用单元测试来保证质量，但App就很难做单元测试了。
     4）：App自动化测试就别指望了，那是大公司才愿烧钱去做的事。


2、探索性测试
（测试团队在新功能测试结束后，应该做一轮探索性测试。把所有测试人员组织在一起，逐个模块进行测试，可以每天一小时，分为3-4天进行。此外，测试团队所有成员都参与，可以保证每个测试人员对每个模块都熟悉，而不是长期只负责自己那个模块。）


3、Monkey测试
（Android项目每天下班前都要跑Monkey，然后每天会有专人分析Crash日志。Crash一般分为三种：
     1）：系统逻辑上的空指针。
     2）：系统问题，比如说不同手机ROM，问题也不太一样。
     3）：ANR。页面占用资源过多。（要把App中的电话拨打按钮都禁止、要确保Monkey能进入到App的所有页面、有很多页面需要用户登录才能进入、要把涉及支付的按钮都禁止，以防止在线上下单而造成的各种纠纷。）
）
】


==高层对敏捷流程的干预
【
     一般而言，一个敏捷流程是不需要总监级别的高层直接参与的。但是总监应该对敏捷流程适当干预，一方面要把握重构和产品的平衡，以确保一个“度”，另一方面则是要提高人力的利用率，可以从开发效率、座位安排、静时这些点入手，从而让团队始终有高产出。在
1、重构与产品需求的平衡
（一般会在两次迭代的间隙，来进行重构。另外，在迭代过程中，会有需求被砍掉或者弱化的时候，剩下的时间是来做重构的。
每次重构都要事先规划好：解决方案、工时、影响范围、测试方案
     好的重构方法是，拆分重构工作，循序渐进，每次做一点。这样既可以尽可能的完成需求，也可以降低重构的风险。）


2、提高效率，拒绝6*12
（疲劳作战后的表现为：战斗力急剧下降、质量下降，bug激增、脾气开始变得暴躁，容易发生冲突、每天就是在耗时间、上班越来越晚，午休时间变长。
     6*12适合于搞突击，但时间应该控制在3周以内。想提高开发人员的效率，还是想别的办法。
     8小时上班，除去其他时间，6小时是极限：
     -上班整理工位、吃早饭的时间
     -WC时间
     -饭后散步时间
     -午休时间
     -QQ闲聊时间
     -淘宝购物时间
     -各种被打扰时间
=作为负责人或项目经理应该注意以下几点：
     -要减少团队在QQ闲聊和淘宝购物上花费的时间，充分利用好这实打实的6个小时。
     -控制每个Task的工时，精细到0.5天。
     -减少被打扰时间。--静时。
）


3、无线部门的座位安排


4、静时，开发人员的时间被严重碎片化了。任何人都可能来打扰他们，比如说发现线上bug，比如说客人投诉、产品经理临时修改需求、领导视察等。屏蔽一切干扰，每周三下午的效率是最高的。
】


==总结--敏捷开发中的项目管理
【
管理学分两种：团队管理和项目管理。
--团队管理我推崇弱管理，别给团队成员加诸多的条条框框，给他们一个主题，让他们自由发挥。别让他们去做太多不擅长的事情。
--而项目管理我执行强管理，要清楚知道每个人每天的进度，以免劳动力的荒废。这时候需要一个强有力的项目经理来推进，以确保每次迭代能最大程度的完成需求，及时汇报剩余工时用于重构工作。
】

若该文为原创文章，转载请注明原文出处

本文章博客地址：https://blog.csdn.net/qq21497936/article/details/116087039

长期持续带来更多项目与技术分享，咨询请加QQ:21497936、微信：yangsir198808
红胖子(红模仿)的博文大全：开发技术集合（包含Qt实用技术、树莓派、三维、OpenCV、OpenGL、ffmpeg、OSG、单片机、软硬结合等等）持续更新中…（点击传送门）
其他（编程相关）


前言
  从事IT行业多年，一路从小杂兵成长为大团队Leader，对于研发整个体系比较清楚，其实大多人都经历过但是都忽略了的研发成本管控的一个关键的点就是研发过程中项目级和产品级的区别。


市场基本情况
  在IT行业飞速发展的今天，可以将IT公司分大体分为两类：

一类是软硬开发公司：多数定位是项目类公司，如某国际，某为外包，此类型也多是外包公司，小部分公司也做一些产品级的定制开发（一般是解决方案或者按照license出货）。
一类是产品提供商（服务类公司）：有特定的产品，持续迭代，特定的时候，该类主体为产品类公司。同时，不乏产品类公司做一些项目定制开发。

  其实以上两者并不是一定区分那么明显，会根据市场发展需要进行转变，大部分公司的路线都是项目级养活公司，逐渐走向产品级，最终转为产品提供商并做一些产品相关的项目开发，如国内某GPU厂。

  (PS：实际上稍微大一点的公司业务复杂程度，多样化程度不亚于过年回家应付七大姑八婆，此处只粗略加以区分）


请先思考以下问题（文章末尾解答）

思考问题1：老板1（你的老板或者甲方客户）希望做一个即时通讯软件，能实现聊天功能，文件传输功能，能查看哪些人在线，能发表情等等，是否能做？多长周期？成本多少？
思考问题2：老板2想要做一个三维引擎开发，希望将给的图进行三维点云渲染，能将其给的demo点云进行展示和基本的三维场景功能，是否能做？多长周期？成本多少？
思考问题3：老板3想要做一个白板软件，希望拥有某大厂的白板基本功能，是否能做？多长周期？成本多少？
思考问题4：老板4想要做一个物联网服务器平台，实现mqtt通讯，从前端看即可，是否能做？多长周期？成本多少？
思考问题5：老板5想要做一个数据处理平台，实现给定的几百文件数据处理，达到功能，是否能做？多长周期？成本多少？

（请带着以上问题，往下看）



关键点
  做产品与做项目有哪些区别，大多数的人面对这个问题还是较为模糊的，甚至简单认为两者是没有区别的，均是程序开发而已。但事实并非如此，做产品与做项目两者之间既存在本质的区别。


侧重点不同
项目的侧重点：时间和基本功能
  做项目侧重于时间驱动，因为时间就是成本，要压缩成本就要压缩时间，在功能上力求操作敏捷、易用、友好，如果在项目时间紧迫的情况下，至少要能保证每个功能都基本能用、主流程不出现bug，若有功能性bug会进行修复。

  做项目是以客户的需求为根本，按照客户的商定的需求进行定制开发，不明确的需求要第一时间与客户进行沟通，不在沟通内的将会存在后期扯皮现象。
产品的侧重点：时间、基本功能、体验优化、方案优化、代码优化和需求迭代升级
  做产品侧重于功能体验，做产品的时间相对来说比较充足，前期可采用带产品型思维的项目型管控方式，达到项目要求之后，进而不断迭代优化修复优化非功能性bug。（团队管理上，可称之为项目级Demo阶段，即第一阶段）

  要开发出有竞争力、受广大客户欢迎的产品为原则，功能响应速度要相对体验好，操作要简便、界面要美观，是多方努力的结果，而且周期往往以半年开始计算。（团队管理上，可称之为产品级Demo阶段，即第二阶段，该阶段的周期为0.5~3倍时间于项目级Demo阶段）

  做产品是为了满足某一应用市场而针对性进行一套装软件或一个产品的开发，对于产品的性能以及快速迭代扩展的要求更高，产品的需求也并不像软件项目一样完全明确，存在着后期根据需求、迭代升级的情况。（团队管理上，可称之为产品迭代升级阶段，即第三阶段）


构架与代码质量要求
项目的质量要求
  做项目的第一准则是客户的需求，项目的开发人员需要依据客户的需求进行定制开发，并且项目需要保证功能适用于当前客户的使用习惯，性能稳定，主功能流程不存在功能性bug；

  项目的质量更加侧重于某一客户的具体需求，保证交付的软件项目程序可运行、维护，实现基本功能即可。

  简单来说，项目的代码怎么方便怎么来，一般不会考虑耦合度、代码规范问题，研发尽快完成对应的任务即可，当然技术好的就算是项目型也会有统一的代码规范和较低的耦合度。
产品的质量要求
  产品的质量要求更加侧重于某一行业领域的应用场景，除主功能流程之外，对其他体验细节等进行优化，对代码进行优化，最开始时就会进行整体的一个基本构架，包括编码风格，模块划分等等，同时具备较好的可读性，可维护性和持续开发，使其所匹配的应用性更为广泛，并且对产品逻辑、代码可运维的要求更高。

  做产品的性能必须持续优化，因为产品为提升竞争力就必须比同类产品更好用，更敏捷，而且产品是一个不断完善升级的过程，对代码的框架以及维护性都具有更高的要求。

  简单来说，产品的代码兼具考虑后期拓展和整体构架，各开发者统一的代码规范，较好的可读性等等，代码也比较健壮，逻辑清楚。


时间投入
项目的时间投入：
  做项目的时间投入一般是根据项目的需求，进行评估。通常是从项目启动、需求调研、功能设计、业务开发、测试运行、验收交付为一个周期。

  项目有明确时间约束，什么时候开始，什么时候结束，每个节点都需要一目了然。通常以项目的验收单作为分项的里程碑及整体验收单作为项目的交付证明。
产品的时间投入：
  做产品的时间相对来说比较长，产品通常更加关注的是整个产品的规划、开发、推广、维护等。

  产品时间一般来说可以明确开始时间却不能明确真正的结束时间，因为产品是一直在进行迭代完善的过程，通常会通过不同的产品版本来区分维护、优化、升级。可以划分为三阶段时间：

项目Demo阶段：考虑构架等时间会比纯项目长
产品Demo阶段：基于之前的功能开始第一版本的稳定性，体验，各种非功能的bug和小优化
产品优化迭代需求升级阶段：对已有的功能进行各种优化，如播放器优化编解码性能，如原来使用的延时500ms，提升为400ms，看似小的优化，往往付出却是比其Demo功能开发的周期更长。



解析文前的问题
思考问题1
  老板1（你的老板或者甲方客户）希望做一个即时通讯软件，能实现聊天功能，文件传输功能，能查看哪些人在线，能发表情等等，是否能做？多长周期？成本多少？

  该问题需要进一步的沟通需求细节，实现通讯软件达到的具体功能点，以某种形式列出，并且列出类似的几款产品类似的功能，具体确认其功能需要达到哪种程度。才能进一步明确是否可行，周期，成本等，以下列出几种常见的情况：

-情况一：老板1要求的及时通讯是满足基本要求，为人相对好说话，公司内部使用，能基本聊天实现基本功能即可，完成验收。

-情况二：老板1要求的及时通讯是满足飞Q要求，实现基本要求，要达到200人同时在线群聊沟通等，还需要表情文字，gif，文件传输需要达到10MB/S，同时不影响聊天，基本很难验收。

-情况三：老板1使用后发现，QQ能做到多个群聊多人在线，你这个为什么不行，QQ可以同时做屏幕互动，语音这都是基本功能，之前说的基本功能就包括这些，根本无法验收。

-其他情况：只列举三种相对结果好、中、差的情况（往后的问题都是）。

  以上第一种情况一般是合作愉快，二就比较棘手，三最后一般是不欢而散，一方吃亏或者可能在法院上见。
思考问题2
  老板2想要做一个三维引擎开发，希望将给的图进行三维点云渲染，能将其给的demo点云进行展示和基本的三维场景功能，是否能做？多长周期？成本多少？

-情况一：老板2要求引擎后，能够将其给的点云打到展示的效果，评估时使用该点云评估，完成验收。

-情况二：老板2要求引擎后，能够将其给的点云打到展示的效果，进一步测试时，发现几千万的点云加载慢，上亿的点云面渲染卡顿，进一步探讨可行的解决方案，看情况是否验收。

-情况三：老板2要求引擎后，能够将其给的点云打到展示的效果，进一步测试时，发现几千万的点云加载慢，上亿的点云面渲染卡顿，当初要求就是点云渲染不卡顿，拿行业较好的软件对比，如用opengl只显示不卡，为什么用已有的开源引擎就卡，项目前的点云给的几千几万的点云，评估自然也不同，包括费用，此种情况根本无法验收。
思考问题3
  老板3想要做一个白板软件，希望拥有某大厂的白板基本功能，是否能做？多长周期？成本多少？

-情况一：前期对标某大厂的白板，基本功能，按照项目评估费用周期，后期达到基本功能需求，完成验收。

-情况二：前期对标某大厂的白板，基本功能，按照项目评估费用周期，验收时，如某某白板书写的比较顺和自然，可以同时播放4个4K视频，可以各种绘制操作带各种资源，老板3还是懂，一切商讨，看情况是否验收。

-情况三：前期对标某大厂的白板，基本功能，按照项目评估费用周期，验收时，如某某白板书写的比较顺和自然，可以同时播放4个4K视频，可以各种绘制操作带各种资源，此种无法验收，谈的是项目，做的是产品，根本无法验收。
思考问题4
  老板4想要做一个物联网服务器平台，实现mqtt通讯，从前端看即可，是否能做？多长周期？成本多少？

-情况一：前期以单个传感器谈，可以实现即可，mqtt自己可以撑几千个，达到基本功能，mqtt是否能撑住不在负责范围内，按照项目评估费用周期，完成验收。

-情况二：前期以单个传感器谈，可以实现即可，达到基本功能，按照项目评估费用周期，后续说mqtt可以承载几万，单实际无法承载，一口说就是之前谈的这个方案行得通，是你代码问题，不然这个方案行不通，项目无意义，不付款，此种狗血剧情，只收了基本功能的钱，还让承担服务器，基本无法验收”。

-情况三：前期以单个传感器谈，可以实现即可，达到基本功能，按照项目评估费用周期，后续说mqtt可以承载几万，单实际无法承载，一口说就是之前谈的这个方案行得通，是你代码问题，不然这个方案行不通，项目无意义，不付款，与此同时，提供其他方案，让乙方写一个可以支撑几万人同时在线的交互服务器，此种狗血剧情真实存在，只收了基本功能的钱（几千），还让承担几十万项目无法实现的后果（其方案本身存在问题，非不积极解决），还要告乙方，基本无法验收。
思考问题5
  老板5想要做一个数据处理平台，实现给定的几百文件数据处理，达到功能，是否能做？多长周期？成本多少？

-情况一：前期以处理的数据作为理论依据，完成功能，基本满足即可，完成验收。

-情况二：前期以处理的数据作为理论依据，完成功能，回去测试以几万几十万的数据去测试，发现无法承载，双方沟通，本身做的是基础的钱，不可能对大数据专门做优化处理，看情况是否验收。

-情况三：前期以处理的数据作为理论依据，完成功能，回去测试以几万几十万的数据去测试，发现无法承载，遂说未达到要求，必须达到要求才能给验收，基本无法验收。


建议的解决方法：最关键的需求评估沟通阶段
需求评估阶段，尽可能细致到功能，事先说明，积极配合
  很多东西看起来简单，单功能较多，纯工作量都较长，导致原先简单的东西估算成本低于实际付出太多，导致亏本，企业亏本那怎么可能做好。

  比如计算器，windows的计算器用起来还不简单吗，但请您认真查看他的功能，发现windows的计算器真不简单，完全复制一个没有十天半个月做不出，而且达到其优化程度，又要付出十天半个月，不信你就自己试试。

  比如windows画图，windows的画图看似简单，但请您认真查看其填充的功能，填充功能是要基于算法去做的，而不是简单绘制一下。

  所以功能要了解到具体的功能点，模糊的功能点跟甲方沟通好，可能存在的情况，双方达成一致，尽可能对双方有利，输和赢其实并不重要，重要的是你合适我也合适，生意才能长久。
需求评估阶段，尽可能细化性能，事先说明，积极配合
  很多东西看起来简单，如理论上mqtt可以承载几万，QChart可以承载几万点，nigix服务器可以承载几百人流媒体延迟500ms以内，这些都是理论上的，实际和理论多半都存在的差距都挺大的，也有确实是符合理论的情况。

  比如nigix流媒体，在局域网可以达到500ms，但在多终端的时候，其延迟就会逐渐增大，比如放到公网上，其延迟远远大于3000ms，请不要怀疑，笔者深入研究过某为、某讯、某牛、某构、某家云、某度各家的流媒体服务器方案以及开源的方案，都做过具体的测试，结果其方案官方给出的是3-10s之间，实际根据网络状况有时候啥都没有，有时候5s左右，要500ms以内必须使用其rtc服务。而对应的延时优化，是需要大量的专业人士在服务器、编解码、播放器各端进行各种优化，甚至是私有协议，如某家云的就基于rtc自己二次三年优化升级的，其延时比大厂的还低。

  比如一些局域网同传开发，软件号称局域网每秒几十MB，1对60同传，确实可以，忽略了网络条件，如无线情况下，P2P也好，传送120MB的文件同传，实际时间将近2小时，包括某大厂飞屏，过来测试1对多也是直接看不到影子，最后研发了rtp+fec+组播的方案，120MB同传文件可以达到2分钟传完即可。这也有个问题，几年后续因为外围测试环境被拆，更换新环境（干扰比较大），导致5分钟才能传完。


后话
  这篇文章想写很久了，以上的思考问题都是博主9年多以来亲身经历的，尤其最近五年对于项目、产品加上自身组建团队0到1的成功经验，一直想进行一定的归纳整理思考。


时间仓促，本文仅代表个人观点，不喜勿喷。


若该文为原创文章，转载请注明原文出处

本文章博客地址：https://blog.csdn.net/qq21497936/article/details/116087039

大型项目前端架构浅谈
目录：

1、综合

1.1、使用场景
1.2、核心思想
1.3、切入角度
1.4、其他


2、基础层设计

2.1、自建Gitlab
2.2、版本管理
2.3、自动编译发布Jenkins
2.4、纯前端版本发布
2.5、统一脚手架
2.6、Node中间层
2.7、埋点系统
2.8、监控和报警系统
2.9、安全管理
2.10、Eslint
2.11、灰度发布
2.12、前后端分离
2.13、Mock
2.14、定期备份


3、应用层设计

3.1、多页和单页
3.2、以应用为单位划分前端项目
3.3、基础组件库的建设
3.4、技术栈统一
3.5、浏览器兼容
3.6、内容平台建设
3.7、权限管理平台
3.8、登录系统设计（单点登录）
3.9、CDN
3.10、负载均衡
3.11、多端共用一套接口
3.12、流量峰值保障


4、总结

1、综合
我在2年之前，写过一篇中小型项目的前端架构浅谈。随着能力的上升，以及在阿里巴巴工作过，是时候写一篇大型项目的前端架构分析了。
本篇文章不会更多侧重于具体技术实现，而是尝试从更高角度出发，分析为什么要这么做，这些设计能解决什么问题，成本和收益如何。
由于作者能力有限，可能会有所缺漏或者部分错误，欢迎读者指出。
1.1、适用场景：
本篇文章，适用于单个/多个大型项目、拥有超过10个以上的前端开发的场景。
前端项目的规模不同，成本收益比也会有所差别。通常来说，人员越多、项目复杂度越高，那么收益/成本的比值越大。
对于人数较少、项目简单的开发团队，可能有部分措施不适用，因此应该根据具体情况来选用。
1.2、核心思想：
【1】解决问题：前端架构的设计，应是用于解决已存在或者未来可能发生的技术问题，增加项目的可管理性、稳定性、可扩展性。
【2】人效比：对于需要额外开发工作量的事务（本文中存在一些需要一定开发量的内容），我们在决定是否去做的时候，应该考虑到两个要素：第一个是花费的人力成本，第二个是未来可能节约的时间和金钱、避免的项目风险与资损、提高对业务的支撑能力以带来在业务上可衡量的更高的价值、以及其他价值。
【3】定性和定量：架构里设计的内容，一定要有是可衡量的意义的，最好是可以定量的——即可以衡量带来的收益或减少的成本，至少是可以定性的——即虽然无法用数字阐述收益，但我们可以明确这个是有意义的，例如增加安全性降低风险。
【4】数据敏感：专门写这一条强调数据作为依据的重要性。当我们需要说服其他部门/上级管理者，以推动我们设计的内容时，只有数据——特别是跟钱有关的数据，才是最有说服力的证明。
由于篇幅所限，本文很难直接给出定量的值，因此建议架构设计者，先确保项目中设计使用2.7里的埋点系统，根据埋点系统获取的数据，对项目效果进行定量分析，并以此写成PPT和其他部门/上级管理者进行协调。
1.3、切入角度：
分为基础层和应用层。
基础层偏基础设施建设，与业务相关性较低。
应用层更贴近用户，用于解决某一个问题。
部分两个都沾边的，根据经验划分到其中一个。
1.4、其他
由于已经谈到架构层级，因此很多内容，并不仅仅只属于前端领域，有很多内容是复合领域（前端、后端、运维、测试），因此需要负责架构的人，技术栈足够全面，对未来发展有足够的前瞻性。
文章的内容结构为：【项目】—>【解决的问题和带来的好处】—>【项目的实际意义】
2、基础层设计
2.1、自建Gitlab
这个是基础的基础了。本不应该提的，不过考虑到我最近面试的几家公司，有的公司（人数并不少）并没有使用Gitlab，因此专门提一下，并且使用这个的难度非常低。
强烈建议使用Gitlab进行版本管理，自建Gitlab难度并不大，方便管理，包括代码管理、权限管理、提交日志查询，以及联动一些第三方插件。
意义：
公司代码是公司的重要资产，使用自建Gitlab可以有效保护公司资产。
2.2、版本管理
版本管理的几个关键点：

    

        发布后分支锁死，不可再更改：指当例如0.0.1版本成功发布后，不可再更改0.0.1分支上的代码，否则可能会导致版本管理混乱。
    
    

        全自动流程发布；指应避免开发者提交后，手动编译打包等操作，换句话说，开发人员发布后，将自动发布到预发布/生产环境。开发人员不和相关环境直接接触。实现这个需要参考下面的2.3。
    
    

        多版本并存；指当例如发布0.0.2版本后，0.0.1版本的代码应仍保存在线上（例如CDN），这样当出现线上bug时，方便快速回滚到上一个版本。
    

意义：
提高项目的可控性。
2.3、自动编译发布Jenkins
这个工具用于在代码发布后，执行一系列流程，例如自动编译打包合并，然后再从Gitlab发布到CDN或者静态资源服务器。
使用这个工具，可以让一般研发人员不关心代码传到Gitlab后会发生什么事情，只需要专心于开发就可以了。
意义：
让研发人员专心于研发，和环境、运维等事情脱钩。
2.4、纯前端版本发布
纯前端版本发布分为两步：

    

        前端发布到生产环境——此时可以通过外网链接加正确的版本号访问到新版本的代码，但页面上的资源还是旧版本；
    
    

        前端通过配置工具（或者是直接更新html文件），将html中引入的资源，改为新版本。
    

解决的问题是：当前端需要发布新版本时，可以不依赖于后端（根据实际情况，也可以不依赖于运维）。毕竟有很多需求并不需要后端介入，单纯改个前端版本后就要后端发布一次，显然是一件非常麻烦的事情。
这个需要专门的工具，用于配置版本发布，我最近就在写这个。
意义：
提高发布效率，降低发布带来的人员时间损耗（这些都是钱），也可以在前端版本回滚的时候，速度更快。
2.5、统一脚手架
适用场景：有比较多独立中小项目。好处：

    

        可以减少开发人员配置脚手架带来的时间损耗（特殊功能可以fork脚手架后再自行定制）；
    
    

        统一项目结构，方便管理，也降低项目交接时带来的需要熟悉项目的时间；
    
    

        方便统一技术栈，可以预先引入固定的组件库；
    

意义：
提高开发人员在多个项目之间的快速切换能力，提高项目可维护性，统一公司技术栈，避免因为环境不同导致奇怪的问题。
2.6、Node中间层管理
适用场景：需要SEO且前端使用React、vue，或前端介入后端逻辑，直接读取后端服务或者数据库的情况。

    

        SEO：仁者见仁智者见智，虽然很多公司已经不做了，但通常认为，还是有一定意义的（特别是需要搜索引擎引流的时候），因此React或者Vue的同构是必须的。并且同构还可以降低首页白屏时间；
    
    

        前端读取后端服务/数据库：好处是提高前端的开发效率和对业务的支持能力，缺点是可能导致P0级故障。
    

意义：
让前端可以侵入后端领域，质的提升对业务的支持能力。
2.7、埋点系统
强烈推荐前端做自己的埋点系统。这个不同于后端的日志系统。
前端埋点系统的好处：

    

        记录每个页面的访问量（日周月年的UV、PV）；
    
    

        记录每个功能的使用量；
    
    

        捕捉报错情况；
    
    

        图表化显示，方便给其他部门展示；
    

埋点系统是前端高度介入业务，把握业务发展情况的一把利剑，通过这个系统，我们可以比后端更深刻的把握用户的习惯，以及给产品经理、运营等人员提供准确的数据依据。当有了数据后，前端人员就可以针对性的优化功能、布局、页面交互逻辑、用户使用流程。
埋点系统应和业务解耦，开发人员使用时注册，然后在项目中引入。然后在埋点系统里查看相关数据（例如以小时、日、周、月、年为周期查看）[原创水印-作者：零零水(王冬)，微信：qq20004604]。
意义：
数据是money，数据是公司的生命线，数据是最好的武器。
2.8、监控和报警系统
监控和报警系统应基于埋点系统而建立，在如以下场景时[原创水印-作者：零零水(王冬)，微信：qq20004604]触发：

    

        当访问量有比较大的变化（比如日PV/UV只有之前20%以下）时，自动触发报警，发送邮件到相关人员邮箱；
    
    

        比如报错量大幅度上升（比如200%或更高），则触发报警；
    
    

        当一段时间内没有任何访问量（不符合之前的情况），则触发报警；
    
    

        每过一段时间，自动汇总访问者/报错触发者的相关信息（例如系统、浏览器版本等）；
    

建设这个系统的好处在于，提前发现一些不容易发现的bug（需要埋点做的比较扎实）。有一些线上bug，因为用户环境特殊，导致无法被开发人员和测试人员发现。但其中一部分bug又因为不涉及资金，并不会导致资损（因此也不会被后端的监控系统所发现），这样的bug非常容易影响项目里某个链路的正常使用。
意义：
提高项目的稳定性，提高对业务的把控能力。降低bug数，降低资损的可能性，提前发现某些功能的bug（在工单到来之前）。
2.9、安全管理
前端的安全管理，通常要依赖于后端，至于只跟单纯有关系的例如dom.innerHTML= 'xxx '这种太基础，就不提了。
安全管理的很难从架构设计上完全避免，但还是有一定解决方案的，常见安全问题如下：

    

        XSS注入：对用户输入的内容，需要转码（大部分时候要server端来处理，偶尔也需要前端处理），禁止使用eval函数；
    
    

        https：这个显然是必须的，好处非常多；
    
    

        CSRF：要求server端加入CSRF的处理方法（至少在关键页面加入）；
    

意义：
减少安全漏洞，避免用户受到损失，避免遭遇恶意攻击，增加系统的稳定性和安全性。
2.10、Eslint
Eslint的好处很多，强烈推荐使用：

    

        降低低级bug（例如拼写问题）出现的概率；
    
    

        增加代码的可维护性，可阅读性；
    
    

        硬性统一代码风格，团队协作起来时更轻松；
    

总的来说，eslint推荐直接配置到脚手架之中，对我们提高代码的可维护性的帮助会很大。可以考虑在上传到gitlab时，硬性要求eslint校验，通过的才允许上传。
意义：
提高代码的可维护性，降低团队协作的成本。
2.11、灰度发布
灰度发布是大型项目在发布时的常见方法，指在发布版本时，初始情况下，只允许小比例（比如1~5%比例的用户使用），若出现问题时，可以快速回滚使用老版本，适用于主链路和访问量极大的页面。
好处有以下几点：

    

        生产环境比开发环境复杂，灰度发布时可以在生产环境小范围尝试观察新版本是否可以正常运行，即使出问题，也可以控制损失。
    
    

        对于大版本更新，可以先灰度一部分，观察埋点效果和用户反馈（即所谓的抢先试用版）。假如效果并不好，那么回滚到老版本也可以及时止损；
    
    

        当我们需要验证某些想法或问题的时候，可以先灰度一部分，快速验证效果如何，然后查漏补缺或者针对性优化；
    

灰度发布通常分为多个阶段：【1】1%；【2】510%；【3】3050%；【4】全量推送（100%）。灰度发布一定要允许配置某些IP/账号访问时，可以直接访问到灰度版本。
意义：
降低风险，提高发布灵活度。
2.12、前后端分离
这个并不是指常见的前后端分离，而是指在分配前后端管控的领域。
中小项目常见的情况是后端只提供接口和让某个url指向某个html，前端负责html、css、js等静态资源。
但大型项目并不建议这么做，建议前端负责除html以外的静态资源，而html交给后端处理，理由有很多：

    

        后端进行渲染，方便统一插入一些代码和资源，例如埋点js，监控js，国际化文本资源，页面标识符等。这些通常是后端通过调用某些服务直接写入的；
    
    

        当页面需要统一的头尾时（参考淘宝里我的淘宝页面），前端不应该关注这些跟当前页面无关的东西；
    
    

        某些东西，如果通过html来管理，那么耦合度太高了，违背了解耦和分离的原则；
    
    

        前端版本发布在后端引入某种功能模块后，可以从单独的页面控制前端发布内容，比更新html更方便，也利于灰度发布；
    

意义：
更规范的进行页面管理，降低页面和功能的耦合度，减少复杂页面的环境配置时间。
2.13、Mock
Mock也是常见前端系统之一，用于解决在后端接口未好时，生成返回的数据。
我个人不太建议开发一个专门的系统来Mock，更好的Mock手法是直接嵌入到脚手架之中。思路如下：

    

        当在开发环境下，访问链接通常是localhost:8000/index.html，此时加入后缀 ?debug=true；
    
    

        封装好的异步请求在发现当前链接有以上标志时，认为是测试环境，访问/userinfo 时，不去读取线上的数据（因为也读取不到），去本地环境读取 src/test_ajax/userinfo.json，并将内容返回给用户；
    
    

        异步请求正常拿到数据，在页面中显示[原创水印-作者：零零水(王冬)，微信：qq20004604]；
    
    
当线上接口可以获取到数据后，从network里找到返回的数据，放入/ src/test_ajax/userinfo.json中，此时再次本地调试的话，相当于使用的是线上的真实数据。
</li>


这种处理，可以降低mock的复杂度，随时更改mock时返回的数据，比单独开发一个mock系统性价比更高。
意义：
在前后端并行开发时，降低沟通交流成本，方便开发完毕后直接对接。
2.14、定期备份
备份是常被忽略的一件事情，但当我们遇见毁灭性场景时，缺少备份带来的损失是非常大的，常见场景：

    

        服务器损坏，导致存在该服务器上的内容全部完蛋；
    
    

        触发某致命bug或者错误操作（例如rm -f），导致文件和数据全部消失；
    
    

        数据库出现错误操作或出现问题，导致用户数据、公司资产遭受严重损失；
    

总的来说，没人想遇见这样的场景，但我们必须考虑这种极端情况的发生，因此需要从架构层面解决这个问题。常见方法是定期备份、多机备份、容灾系统建设等。
意义：
避免在遭遇极端场景时，给公司带来不可估量的损失。
3、应用层设计
3.1、多页和单页
除了特殊场景，通常推荐使用多页架构。理由如下：

    

        多页项目，页面和页面之间是独立的，不存在交互，因此当一个页面需要单独重构时，不会影响其他页面，对于有长期历史的项目来说，可维护性、可重构性要高很多；
    
    

        多页项目的缺点是不同页面切换时，会有一个白屏时间，但通常来说，这个时间并不长，大部分现有大公司的线上网页，都是这样的，因此认为是可以接受的；
    
    

        多页项目可以单次只更新一个页面的版本，而单页项目如果其中一个功能模块要更新（特别是公共组件更新），很容易让所有页面都需要更新版本；
    
    

        多页项目的版本控制更简单，如果需要页面拆分，调整部分页面的使用流程，难度也会更低；
    
    

        灰度发布更友好；
    

之前面试的一家，采用了单页的形式，之前因为种种原因，同时采用了ng和react。由于项目历史也比较久（3年以上），结果导致目前继续维护更新的难度很大，即使想部分重构，也很麻烦。
意义：
降低长期项目迭代维护的难度，
3.2、以应用为单位划分前端项目
在项目比较大的时候，将所有页面的前端文件放入到同一个代码仓库里，我之前参与过一家企业的前端项目开发，发现其就是这么做的。根据使用经验来看[原创水印-作者：零零水(王冬)，微信：qq20004604]，存在很多问题：

    

        会极大的增加代码的维护难度；
    
    

        项目会变得很丑陋；
    
    

        不方便权限管理，容易造成页面误更改或代码泄密；
    
    

        任何人都有权利改任何他能看到的页面（在合并代码的时候，管理人员并不能确定他本次修改的页面是否是需求里他应该改的页面）；
    
    

        发布成本高，即使改一个页面，也需要发布所有资源；
    

因此，我们应该避免这种现象的发生，个人推荐以应用为单位进行开发、发布。所谓应用即指一个业务涉及到的前后端代码，好处很多：

    

        方便进行管理，当某个业务有需求变更时，可以只给研发人员该业务前端应用的developer权限；
    
    

        在需要发布某业务时，只需要发布该业务的所属应用即可；
    

意义：
规范项目，增加代码的安全性，降低项目维护成本。
3.3、基础组件库的建设
这个蛮基础的，对于组件库的建设，不建议研发人员较少时去做这件事情，专职前端开发人数少于10人时，建议使用比较靠谱的第三方UI库，例如Antd，这样性价比更高。
设计基础组件库的前提，是要求统一技术栈，这样才能最大化基础组件库的效益。组件库建议以使用以下参考标准：

    

        使用ts；
    
    

        可扩展性强；
    
    

        适用程度高；
    
    

        文档清楚详细；
    
    

        版本隔离，小版本优化加功能，大改需要大版本更新；
    
    

        和UI协调统一，要求UI交互参与进来；
    

总的来说，建设起来后，利大于弊，但是需要专人维护，因此还是有一定成本的。
意义：
统一不同/相同产品线之间的风格，给用户更好的体验，减少单次开发中写UI组件时浪费的时间和人力，提高开发效率。
3.4、技术栈统一
前端有三大主流框架，还有兼容性最强jQuery，以及各种第三方库，UI框架。因此项目需求如果复杂一些，很容易形成一个大杂烩。因此前端的技术栈必须统一，具体来说，建议实现以下举措：

    

        三大框架选型其一，团队水平一般推荐Vue、水平较好推荐React，对外项目选React或者ng；
    
    

        需要兼容IE8或更老版本时，建议使用jQuery；
    
    

        组件库自建或者统一选择一个固定的第三方；
    
    

        一些特殊第三方库统一使用一个版本，例如需要使用地图时，固定使用高德或百度或腾讯地图；
    
    

        基础设施建设应避免重复造轮子，所有团队尽量共用，并有专门的前端平台负责统一这些东西，对于特殊需求，可以新建，但应当有说服力；
    

总的来说，技术栈统一的好处很多，可以有效提高开发效率，降低重复造轮子产生的成本。
意义：
方便招人，简化团队成员培养成本，以及提高项目的可持续性。
3.5、浏览器兼容
常见的问题是IE6、7、8，以及部分小众浏览器（PC和手机）产生的奇怪问题。因此应该考虑统一解决方案，避免bug的重复产生。常见解决方案有：

    

        配置postcss，让某些css增加兼容性前缀；
    
    

        写一个wepback的loader，处理某些特殊场景；
    
    

        规范团队代码，使用更稳定的写法（例如移动端避免使用fixed进行布局）；
    
    

        对常见问题、疑难问题，总结解决方案并团队共享；
    
    

        建议或引导用户使用高版本浏览器（比如chrome）；
    

意义：
避免浏览器环境产生的bug，以及排查此类bug所浪费的大量时间。
3.6、内容平台建设
为了提高公司内部的沟通效率，总结经验，以及保密原因。应建设一个内部论坛+博客站点。其具备的好处如下：

    

        可以记录公司的历史；
    
    

        研发同学之间分享经验；
    
    

        总结转载一些外界比较精品的文章，提高大家的眼界；
    
    

        增加公司内部同学的交流，有利于公司的团队和文化建设；
    
    

        对某些技术问题可以进行讨论，减少因没有达成共识带来的沟通损耗；
    

众所周知，大型互联网公司通常都有这样一个内部论坛和博客站点。其降低了公司的沟通和交流成本，也增加了公司的技术积累。
意义：
博客增强技术积累，论坛增强公司内部沟通能力。
3.7、权限管理平台
当公司内部人员较多时，应有一个专门的平台，来管理、规范用户的权限以及可访问内容[原创水印-作者：零零水(王冬)，微信：qq20004604]。权限管理平台有几个特点：

    

        必然和Server端天然高耦合度，因此需要有专门的控制模块负责处理权限问题（负责Server端开发处理，或者前端通过中间层例如Node层介入处理）；
    
    

        自动化流程控制，即用户创建、申请、审批、离职自动删除，都应该是由系统推进并提醒相关人士，必要时应能触发报警；
    
    

        权限应有时效性，减少永久性权限的产生；
    
    

        审批流程应清晰可见，每一阶段流程应具体明确；
    
    

        应与公司流程紧密结合，并且提高可修改性，方便公司后期进行流程优化；
    

意义：
使得公司内部流程正规化、信息化。
3.8、登录系统设计（单点登录）
当公司内部业务线比较复杂但相互之间的耦合度比较高时，我们应该考虑设计添加单点登录系统。具体来说，用户在一处登录，即可以在任何页面访问，登出时，也同样在任何页面都失去登录状态。SSO的好处很多：

    

        增强用户体验；
    
    

        打通了不同业务系统之间的用户数据；
    
    

        方便统一管理用户；
    
    

        有利于引流；
    
    

        降低开发系统的成本（不需要每个业务都开发一次登录系统和用户状态控制）；
    

总的来说，大中型web应用，SSO可以带来很多好处，缺点却很少。
意义：
用户体验增强，打通不同业务之间的间隔，降低开发成本和用户管理成本。
3.9、CDN
前端资源的加载速度是衡量用户体验的重要指标之一。而现实中，因为种种因素，用户在加载页面资源时，会受到很多限制。因此上CDN是非常有意义的，好处如下：

    

        用户来自不同地区，加入CDN可以使用户访问资源时，访问离自己比较近的CDN服务器，降低访问延迟；
    
    

        降低服务器带宽使用成本；
    
    

        支持视频、静态资源、大文件、小文件、直播等多种业务场景；
    
    

        消除跨运营商造成的网络速度较慢的问题；
    
    

        降低DDOS攻击造成的对网站的影响；
    

CDN是一种比较成熟的技术，各大云平台都有提供CDN服务，价格也不贵，因此CDN的性价比很高。
意义：
增加用户访问速度，降低网络延迟，带宽优化，减少服务器负载，增强对攻击的抵抗能力。
3.10、负载均衡
目前来看，负载均衡通常使用Nginx比较多，以前也有使用Apache。当遇见大型项目的时候，负载均衡和分布式几乎是必须的。负载均衡有以下好处：

    

        降低单台server的压力，提高业务承载能力；
    
    

        方便应对峰值流量，扩容方便（如举办某些活动时）；
    
    

        增强业务的可用性、扩展性、稳定性；
    

负载均衡已经是蛮常见的技术了，好处不用多说，很容易理解。
意义：
增强业务的可用性、扩展性、稳定性，可以支持更多用户的访问。
3.11、多端共用一套接口
目前常见场景是一个业务，同时有PC页面和H5页面，由于业务是一样的，因此应避免同一个业务有多套接口分别适用于PC和H5端。[原创の水印-作者：零零水(王冬)，QQ：20004604]因此解决方案如下：

    

        后端提供的接口，应该同时包含PC和H5的数据（即单独对一个存在亢余数据）；
    
    

        接口应当稳定，即当业务变更时，应尽量采取追加数据的形式；
    
    

        只有在单独一端需要特殊业务流程时，设计单端独有接口；
    

多端共用接口，是减少开发工作量，并且提高业务可维护性的重要解决方案。
意义：
降低开发工作量，增强可维护性。
3.12、流量峰值保障
实际场景中，经常会遇见过高的峰值流量。具体来说，假设平时网站每秒访问量的高峰在3-4k左右。通常来说，你设计能承载每秒1w访问的Server，基本是够用的。但生活总是充满意外，假如运营搞一个秒杀活动，每秒访问量的峰值超过2w甚至更多都是有可能的，这种情况下，很容易导致连锁反应，然后服务器原地爆炸。
为了应对这种特殊情况，我们需要做一些操作（通常需要Server端介入），常见解决方式有以下几种：

    
限流：比如告知用户排队、重定向到错误页等；
    
服务降级：比如说，某些非核心功能临时禁止使用；
    
缓存：包括页面静态资源缓存，和DB之间的缓存等；
    
扩容：一台机子不行，上两台，有手动扩容和自动扩容的区分；
    
同步变异步：某些操作从同步操作，变为异步非阻塞操作；
    
削峰：这个和限流的区别在于，用户还是能正常访问，只不过原本1秒内2w访问量，现在变为2秒或更久2w访问量；

总的来说，解决方法很多，架构师需要能理解整个业务模型和架构模型，才能正确对峰值流量提出有效的解决方案。
意义：
保障大促等活动，为业务的正常开展保驾护航。
4、总结
由于各个公司具体情况不同，项目也具有特殊性，因此以上设计不可强行套入，应根据自己公司规模、项目进展、人员数量等，先添加比较重要的功能和设计。并需要考虑到长期项目的可维护性和发展需要，对部分基础设施进行提前研发设计。
篇幅所限，因此无法面面俱到，只提了一些我认为比较重要的架构层面需要考虑的内容，欢迎大家补充。大家如果有自己的看法，欢迎回复，或者添加我的微信 qq20004604（昵称：零零水）进行讨论。
最后问一下，西安有没有不加班，并且需要前端架构师的公司，请联系我。

本章内容提纲
8.1 软件项目团队管理概述
8.2 项目组织的规划
8.3 团队人员获取
8.4 团队建设和日常管理
8.5 沟通管理
8.6 软件专业人员的非技术素养
8.1 软件项目团队管理概述
什么是软件项目团队？
    软件项目团队是由软件项目的不同干系人所组成的，具有共同目标、紧密协作的集体。
软件项目团队包括所有项目干系人：项目发起人、资助者、项目组（开发团队）、供应商、客户等。
有时，软件项目团队特指项目组（开发团队）。
软件项目团队的特点           
与一般的人力资源相比，软件项目团队的特点是：
临时性；
团队成员的不稳定性；
年轻化程度较高；
是高度集中的知识型团队；
成员的业绩不易量化考核。
什么是软件项目团队管理
美国的项目管理协会（PMI）的《项目管理知识体系指南》（PMBOK）对“项目人力资源管理”有如下定义：
为最有效地使用项目参与人员而执行的各项过程。包括针对项目的各利益相关方展开的有效规划、合理配置、积极开发、准确评估和适当激励等方面的管理工作。
软件项目团队管理的定义：
软件项目团队管理就是采用科学的方法，对项目组织结构和项目全体参与人员进行管理，在项目团队中开展一系列科学规划、开发培训、合理调配、适当激励等方面的管理工作，使项目组织各方面的主观能动性得到充分发挥，同时促进高效的团队协作，以利于实现项目的目标。


软件项目的人力资源特征
人既是最大的成本又是最重要的资源
人力成本：尽量使人力资源投入最小
人力资源：尽量发挥资源的价值，使人力资源的产出最大
软件项目团队管理的主要内容
项目组织的规划
    确定项目中的角色、职责和组织结构。
团队人员获取
    获得项目所需的人力资源（个人或集体）。
团队建设
    提高团队成员个人为项目做出贡献的能力；提高团队作为集体发挥作用的能力。
团队日常工作管理
    跟踪团队成员工作绩效，解决问题和冲突，协调变更事宜。
沟通管理
    对在项目干系人之间传递项目信息的内容、方法和过程进行综合管理。保证项目干系人及时得到所需的项目信息。
团队协作的重要性
良好的团队协作可发挥出集体的力量。

“Linus法则”：只要眼球足够多，所有臭虫都好捉。
               —— Eric Steven Raymond
                    《大教堂与市集》

类比：蚁群觅食。众多蚂蚁各自分散地寻找食物，找到后用一种非常高效的、可扩展的通信机制互相通信。
蚁群觅食
    
Linux的开发充分利用了全世界开发者的集体智慧，使得系统中的缺陷被迅速修复，而Linus通过在Internet上频繁地发布Linux版本来不断地向开发者反馈其开发成果。
在软件的高层设计中，在产品和项目的许多决策中，发挥集体智慧都是极为重要的，一个人往往按照其习惯的和擅长的思维方式和解决问题的方式，在一条路径上探索。而许多人在一个问题空间里进行探索，其效能远远超过单个人。
Raymond说：Linus最重要的贡献不是创建了Linux内核本身，而是开创了Linux的开发模式。
Linus说：我基本上是一个很懒惰的人，喜欢从实际上是别人做的事情上获得荣誉。
诸葛亮，智慧的代名词，治国能力极强，“鞠躬尽瘁，死而后已”。
但他事无巨细，都要亲自参与才放心。这样做不仅使自己过于劳累，也不利于人才的培养。他去世后蜀国人才凋零，很快就灭亡了。
一个企业或组织要想持续健康发展，不能只靠个别人鞠躬尽瘁，而要发挥集体的力量。
8.2 项目组织的规划
通过项目组织的规划，确定项目团队的角色，明确汇报关系（组织结构），分配人员职责，制定人员配置管理计划。
8.2.1 项目团队角色
8.2.2 项目的组织结构
8.2.3 项目人员职责分配
8.2.4 人员配置管理计划
8.2.1 项目团队角色
项目团队中的不同角色要形成一种相互配合、相互制约的关系，共同促进项目目标的实现。


软件项目团队中常见的角色包括：项目经理、系统分析人员、架构师、开发人员、测试人员、质量保证人员、项目管理和支持人员、市场人员、用户支持人员等。
不同类型的软件项目所包含的角色是有区别的。
例如：微软的一个软件产品项目团队通常由一个“产品单元经理”（Product Unit Manager）领导，包含有不同的角色。
微软的项目团队角色
产品管理人员
  获取和定义用户需求，市场分析和研究，产品推销和公共关系。
后勤管理人员
  对项目所需的设备、材料、软件工具等资源进行管理，保证项目能够平稳地进展。
注意：各种角色的地位是平等的，从而形成一个检查和平衡机制。
在小型项目中，可以简化团队的组成，也就是说，可以把一些角色组合在一起。


微软项目团队构成
Windows2000 Team
内部IT        50
市场人员      100
文档人员      100
本地化人员    110
培训人员      115
程序经理      450
技术支持人员  600
技术传播人员  1120
开发人员      900
测试人员      1800
合计          5345
Web Matrix Team
程序经理      2
开发组长      1
开发人员      7
测试组长      1
测试人员      13
合计          24
要明确定义角色的职责和能力要求。
项目经理是整个团队的核心角色，对项目的成败起着关键作用。
项目经理的责任
制定开发计划
  制定正确计划的前提是理解用户需求，理解项目目标。有全局观和系统观。
组织实施
  组建项目团队，为项目团队成员分配任务，有效调动每个人的能力。
项目控制
  监控项目的运行，积极预防问题的发生，纠正偏差。
项目经理的权利
组织领导要赋予项目经理足够的权利。
决策权：对项目事务有决策权。
项目资源的分配：对划拨给项目的资源（如人员和设备），项目经理有权决定具体的使用。
适当的财务权。项目经历要有适当的支配项目经费的权利，这样有利于控制成本，提高团队工作积极性。
项目经理的能力要求
管理能力
项目团队的组织、沟通、协调，充分发挥每个成员的能力和集体智慧。
项目团队与外部组织的沟通和协调。
很好的口才和写作能力。
技术能力。项目计划、人员的使用、技术评审等均需要一定的技术能力。
管理能力和技术能力哪个更重要？
视具体项目特征而定。
商业头脑。
  理解产品需求，市场策略，盈利模式、企业战略。
其他
  责任心、热情、抗压能力等。
8.2.2 项目的组织结构
项目的组织结构确定了团队成员（部门）之间的汇报关系。
项目的组织结构是项目团队所有成员为了进行分工协作，而在职务范围、权力和责任方面所形成的结构体系。
组织结构的本质是团队成员的分工协作关系；
组织结构的内涵是人们在职、责、权方面的结构体系，所以组织结构又称为权责结构。
项目的组织结构主要包括以下内容：
职能结构：为完成项目目标所需的各项业务工作及其比例和关系。
层次结构：管理层次（上下级）的构成，又称为组织的纵向结构。
部门结构：各管理部门的构成，又称为组织的横向结构。
职权结构：各层次、各部门在权力和责任方面的分工及相互关系。
没有什么好的或坏的组织结构，只有适合或不适合的组织结构。要根据具体的企业情况和项目情况来设计项目组织结构。
本小节的主要内容：
1.项目组织结构的类型
2.项目组织结构图
3.项目小组结构
4.有关项目组织人员规模的讨论
项目组织结构的类型
项目组织结构的类型与企业整体的组织结构有密切关系。
常见的项目组织结构有三种类型：
职能型
项目型
矩阵型
职能型组织结构的特点
职能部门是按照专业职能和业务来划分，例如研发部门、销售部门、财务部门等，研发部门又可进一步细分（如硬件、软件等）。
项目可以由一个或多个职能部门承担，项目成员分别受他所在的职能部门的经理管辖。
虽然也可能有项目经理，但其权利非常有限，通常只负责各部门间的沟通、协调、和监督作用，对项目成员没有完全的领导权。
职能型组织结构


职能型项目组织结构的优点
以职能部门作为承担项目任务的主体，可以充分发挥职能部门的专业优势和资源集中优势，有利于保障项目需要资源的供给和项目可交付成果的质量。
职能部门内部的技术专家可以同时被该部门承担的不同项目所使用，节约人力，减少了资源的浪费。
同一职能部门内部的专业人员便于相互交流、相互支援，对创造性地解决技术问题很有帮助。
当有项目成员调离项目或离开公司，所属职能部门可以增派人员，保持项目的技术连续性。
项目成员可以将完成项目和完成本部门的职能工作融为一体，可以减少因项目的临时性给项目成员带来的不确定性。
这种组织结构适用于主要由一个部门完成的项目或技术比较成熟的项目。
职能型项目组织结构的缺点
不能完全做到以项目目标作为驱动力和导向。职能部门往往集中精力于对本部门有益的工作上，而项目和客户的利益可能得不到优先考虑。
决策过程要经过多个管理层，过程繁琐，因此对客户和市场的需求反应迟钝而且容易失真。
当项目需要由多个部门共同完成时，权力分割不利于各职能部门之间的沟通交流、资源调配、团结协作。
项目成员在行政上仍隶属于各职能部门的领导，项目经理对项目成员没有完全的领导权。
项目型组织结构
项目型组织结构中的部门完全是按照项目需要进行设置的，是一种单目标的垂直组织方式。存在一个项目就有一个项目部门。
项目经理具有高度独立性、对项目享有完全的领导权。
完成每个项目目标所需的全部资源完全划分给该项目，完全为该项目服务。


项目型组织结构的优点
项目经理对项目可以全权负责，可以根据项目需要随意调动项目组织的内部资源或者外部资源。
项目型组织的目标单一，完全以项目为中心安排工作，能够对客户的要求做出及时响应，有利于项目的顺利完成。
项目成员有项目所需的技能，专属于本项目，不需要与其他项目共享关键人员。
组织结构简单，项目成员直接属于同一个部门，彼此之间的沟通交流简洁、快速，提高了沟通效率，同时也加快了决策速度。
项目型组织结构的缺点
不同的项目组织，资源不能共享，即使某个项目的专用资源闲置，通常也无法应用于另一个同时进行的项目，人员、设施、设备可能会重复配置，造成一定程度的资源浪费，成本较高。
公司里各个独立的项目型组织处于相对封闭的环境之中，公司的宏观政策、方针很难做到完全、真正的贯彻实施，可能会影响公司的长远发展。
在项目完成以后，项目型组织的使命即完成，项目成员有可能闲置甚至被解雇，对项目成员来说，缺乏一种事业上的连续性和安全感。
公司承担的项目之间处于一种条块分割状态，项目之间缺乏信息交流的机会。
没有强大的职能群体，技术支持困难，也阻碍了公司能力的持续提高。
矩阵型组织结构
同时具有职能型组织结构和项目型组织结构的特征，试图把两者的优点结合起来。
根据项目的需要，从不同的职能部门中选择合适的人员组成一个临时项目组织，由项目经理领导，他对项目的成功负有全部责任。
项目经理的职权由总经理直接授予。拥有一定的组织地位和权力。
职能部门有责任向项目提供最好的技术支持。


矩阵型组织结构的性质有强弱之分，这取决于项目经理对所拥有的职能资源的影响力。
当项目经理比职能经理对职能资源的使用有更大影响力时，矩阵结构才是强有力的。此时项目经理有能力提供技术指导、委派职责，对项目成员的工作成效有很大影响。
如果职能经理比项目经理更有影响力，那么矩阵结构就是软弱的。
矩阵型组织结构的优点
专职的项目经理负责整个项目，以项目为中心，能迅速解决问题。
公司的多个项目可以共享各个职能部门的技术骨干和其他资源，节约成本。
既有利于项目目标的实现，也有利于公司宏观目标方针的贯彻。
项目成员在事业稳定性上的顾虑减少了。
矩阵型组织结构的缺点
容易引起职能经理和项目经理权力的冲突。
资源共享也能引起项目之间的冲突。
项目成员（处在矩阵行和列的交织处）有多头领导。他们的任用、升迁、解雇的权力仍由职能部门经理把持，而职能部门经理对他们的绩效考核又必须通过项目经理才能完成。当职能部门经理和项目经理的命令相冲突时，可能会出现无所适从的情况。
使用矩阵型组织结构的注意事项
横向的项目组织与纵向的职能部门各自负责的工作和管理内容要明确，否则容易造成责任不清、双重指挥的混乱局面。因此矩阵型组织良好运作的关键是这两类部门的协调。
由于项目经理和职能经理都有各自的权力和责任，他们必须站在项目大局的高度进行良好的沟通和协调。避免出现以下情况：项目经理只考虑什么对自己的项目有利（而不关心其他任何方面），职能经理则认为自己的部门比任何项目都重要。
由于项目成员往往来自不同的职能部门，其工作目标和工作方法可能有所差异，在项目初期的磨合阶段可能会产生矛盾。要求项目经理及时识别矛盾，并控制和疏导由此产生的对抗。
由于项目成员从属于某个职能部门，项目经理必须解决好以下问题：
如何才能激励成员为项目工作，并保证对项目忠诚？
当项目指令和规则与部门政策相冲突，尤其是当成员感到自己的职能部门上司可能会对自己不满时，如何说服他按项目的要求做？
组织结构类型的选择
没有一种组织结构类型是万能的。要根据项目的实际要求和项目所处的企业环境进行选择。
大多数现代组织会在不同层次上用到所有这些结构，形成一种复合型组织结构。例如，基本属于职能型结构的公司，也可能会建立项目型的团队来开发重要的项目，这样的项目型团队具有项目型组织结构的许多特征，它可以从不同职能部门调来全职工作人员，可以制定自己的一套办事程序，甚至可以不按照标准和正规的请示报告系统来开展工作。
项目组织结构的设计
选择了项目组织结构的类型，只是在宏观上确定了项目组织结构的性质。
在此基础上，还要设计项目组织的各组成部分及其报告关系、责任关系。设计结果通常用项目组织结构图表示。
对于大型项目，可以分层次进行设计，即先考虑整体的组织结构，再逐层细化。
项目整体组织结构（举例）


箭头线表示管理流
开发组组织结构（举例）

项目支持组组织结构（举例）


项目小组结构
在大型软件项目中，通常根据软件的功能模块将从事开发的人员划分为若干小组(Team)，每个小组负责一个功能模块的开发。
小组的组织结构对小组的工作效率和工作质量有很大影响。
项目小组的人员要“少而精”。人数太多的小组会产生较大的沟通开销和沟通问题，影响工作效率和软件质量。
项目小组结构的类型
小组的结构形式可分为三类：
1.民主分散型（Democratic Decentralized, DD）。小组没有固定的领导，而是根据不同的任务来指定临时的任务协调员。决策由小组通过协商来共同制定，小组成员之间的通信是水平的。
2.控制集中型（Controlled Centralized, CC）。顶层的问题解决和小组内部协调由小组领导负责。小组领导和小组成员之间的交流是垂直的。
3.控制分散型（Controlled Decentralized, CD）。小组有一个固定的领导，来协调不同的任务。还设有若干二级管理者，负责子任务的完成。问题的解决仍然是集体行为，但解决方案的实现由小组领导划分给不同的成员或成员组。个人和成员组内部的交流是水平的，同时也存在沿着控制层次的垂直交流方式。
不同小组结构的比较
集中式的小组结构有权威指导和统一管理，能以较快的速度完成任务，适用于处理简单问题。分散式的小组结构能够激发人员的创造力和集体智慧，产生更多、更好的解决方案，因此更适合于解决困难的问题。
民主分散型（DD）的小组容易产生更高的士气和工作满意度，因此适用于那种生存期较长的小组。
民主分散型的结构内部通信路径较多，通信开销也较大。但适用于解决那种可模块化程度较低的问题，因为解决这样的问题需要大量的通信和交互。
小组结构
如果需解决的问题可以被高度模块化，控制集中型（CC）和控制分散型（CD）小组结构则比较适合。
有经验表明，CC和CD型小组产生的软件缺陷比DD型小组少。
选择小组结构时，主要应考虑以下因素：
需解决问题的难度。
软件的规模（用代码行或功能点度量）。
小组存在的时间（小组生命周期）。
问题可被分解和模块化的程度。
对系统的质量和可靠性的要求。
系统交付日期的紧迫性。
项目所需要的交流的频繁程度。
小组结构举例-主程序员小组
最早的小组结构形式是CC型，其代表是 “主程序员小组”（chief programmer team），最早由IBM公司于20世纪70年代初期开始采用。


主程序员小组的核心是一个具有丰富经验的工程师（主程序员），他负责计划、协调和审查小组的所有技术活动。程序员（通常2到5人）负责分析和开发任务。一个后备程序员支持主程序员的工作，并在必要时可替换主程序员的工作。
可能还会有若干技术专家、书写员及文档管理员来支持主程序员。
文档管理员可以为多个小组服务，他的工作包括：维护和控制所有软件配置项，收集和整理相关数据，分类和索引可复用软件构件，支持小组的研究和评估工作等。
小组结构举例：微软开发小组
在微软，一个稍大一些的产品部门，分成几个功能块组（Feature Team）。每个功能块组一般负责一个具体的功能模块，并由10到50人组成。根据功能模块的大小，功能块组可能被分成若干子功能块小组。最后每个功能块小组一般不超过10人，其中至少会有一个程序经理（Program Manager），几个开发人员和几个测试人员。


程序经理全权负责功能模块的完成。对功能进行定义、规划和设计；进行各种决策，掌握进度；协调开发和测试人员的工作并跟踪错误；协调本开发小组和外部其他部门（市场、用户支持等）的工作。
程序经理是管理者和协调者，不直接参与编程和测试。不同于其他软件公司的开发小组“技术负责人”。
有关项目组织结构和人员规模的讨论
项目组织中人员的沟通开销会随着人员数量的增加而增加。
假设项目中每个人员都可以和其他任何人员通信，那么通信路径数会随着人员数的增加而呈指数增加。
沟通路径


沟通开销也与项目组织结构有关。项目组织结构通常限制了人员之间的通信路径（例如一个人员或部门主要和有汇报关系/责任关系的人员或部门通信，控制集中型小组内部的通信路径少于民主分散型）。
由于不同人员/小组负责开发不同的软件模块，软件模块设计的弱耦合性也可有效减少不同人员或小组之间的通信。
开源项目的典型通信机制
世界各地的代码贡献者和测试者把他们的代码和缺陷报告通过Internet传送给项目核心组，项目核心组通过频繁地在Internet上发布新版本而对他们提供反馈，而代码贡献者或测试者之间几乎不需要通信。


8.2 项目组织的规划
8.2.1 项目团队角色
8.2.2 项目的组织结构
8.2.3 项目人员职责分配
8.2.4 人员配置管理计划
8.2.3 项目人员职责分配
为项目组织中的部门或个人分配职责，避免因责任不清而造成工作互相推诿，责任互相推卸的现象。
责任分配矩阵（Responsibility Assignment Matrix, RAM）是用来对项目团队成员进行分工，明确其角色与职责的有效工具 。
责任分配矩阵举例

RAM还可以用于更详细地定义团队成员与任务间的关系。

项目人员职责分配
对于很小的项目，可以通过RAM把职责直接分配给个人；对于较大的项目，RAM可以划分出多个层级，先把职责分配给子团队或部门，然后再继续细分。
如果需要详细描述角色的职责，也可使用文字叙述的方式，包括角色的职责、授权、能力和资格等信息。这样的文件可以称为岗位描述、角色-职责-授权表格等，对将来的项目有很好的参考价值。
8.2.4 人员配置管理计划
人员配置管理计划描述何时以何种方式满足项目的人力资源需求。
在项目期间，人员配置管理计划可能会不断进行更新，以指导项目的人员招募和团队建设工作。
根据具体项目的需要，人员配置管理计划可以是详细的或宽泛的，内容也有所区别，但一般应考虑以下内容。
人员配置管理计划的内容
项目团队组建的相关问题。例如，人力资源来自于组织内部还是外部？团队成员需要同地办公还是远距离分散办公？组织的人力资源部门可以为项目管理团队提供多大程度的支持？
时间表。说明项目对每个或每组团队成员工作时间的安排，以及招募活动何时开始。资源直方图是一种常用的人力资源图表工具。
资源直方图

成员遣散安排。确定团队成员的遣散方法和时间。在最佳时机把团队成员撤离项目，可节约成本，而且如果把成员平滑过渡到其他项目中去，可提高士气。
培训需求。如果预期分派的项目成员不具备所需的技能，则可以制定相应的培训计划。
表彰和奖励。用明确的奖励标准和有计划的奖励系统来促进所期望的员工行为。
合规性。人力资源的使用要符合相关的政府规定和其他既定的人力资源政策。
8.3 团队人员获取
根据项目团队的角色和职责、项目组织结构图和人员配置管理计划，获取完成项目工作所需的人力资源。
本节内容提要：
8.3.1 获取团队人员的方法
8.3.2 虚拟团队
8.3.1 获取团队人员的方法
预分派
  在某些情况下，一些成员已预先分派到项目中工作，例如在竞标过程中承诺分配特定人员到项目中，或项目的成功依赖于特定人员的专有技能。
谈判
  大多数人员的获取需要经过谈判。例如项目经理需要与职能部门经理或其他部门负责人谈判，以获得所需要的人员。
  在谈判时，项目的影响力会起作用。
招募
  当企业缺少完成项目所需的内部人才时，就需要从外部获得所需服务，包括招聘和分包。

在获取和任用项目团队人员时，除考虑人员的专业技能外，最好能结合人员的性格特征和兴趣，做到“知人善任”。
获取团队人员后的成果
项目人员分派到位
明确人力资源可利用情况
  人力资源可利用情况记录了项目团队成员在项目上可工作的时间。明确了项目团队成员在时间安排上的冲突，包括休假时间和承诺给其他项目的时间。
更新后的人员配置管理计划
  实际的项目人员分配很少能够完全符合最初的人员配置管理计划，因此需要对其进行变更。
8.3.2 虚拟团队
虚拟团队为项目团队人员的招募提供了新的可能性。虚拟团队是指拥有共同目标，但工作地点分散，在工作过程中很少或完全不面对面交流的一组人员。
电子通信设施的完善（电子邮件、即时通信、视频会议等）使虚拟团队成为可能。
虚拟团对的好处
可以组建在同一组织工作，但工作地点十分分散的团队。
雇用方式更为灵活，可以为项目团队增加特殊技能和专业知识，即使项目人员不在同一地理区域。
可以纳入在家办公的员工。不仅节省了工作空间和设备的费用，而且可能提高工作效率。
可以安排不同时区的人员的任务分工来减少任务的持续时间。
可以把行动不便的人纳入项目团队。
虚拟团对的约束
分配给虚拟团队员工的任务需求要十分明确。
协调分散的员工也许很难，特别是跨国和跨时区的情况。
计算工作量和付费也许需要按件计算，而不是按工时计算。
远程或者素不相识的协作者之间也许缺乏信任感。
8.4 团队建设和日常管理
项目团队建设是指提高团队成员的技能，以加强他们完成项目活动的能力；提高团队成员的信任感和凝聚力，以促进团队协作。
项目团队日常管理是通过观察团队的行为、管理冲突、解决问题，以及评估团队成员的绩效，来促进项目的进展。
团队建设和日常管理涉及到人际关系和人的情感、动机等因素，所以不仅需要制度上的保障，还需要项目管理者的“情商”，进行“人性化管理”。
8.4.1 培训
通过对团队成员的培训，可以提高项目团队的综合素质、工作技能和技术水平。同时有助于提高项目成员的工作满意度，降低项目人员的流动比例和人力资源管理成本。
针对项目的一次性和约束性（主要是时间和成本的制约）的特点，对于团队成员的培训主要采取短期性的、片段式的、针对性强、见效快的培训。
培训方式主要有两种：
岗前培训：对团队成员进行一些常识性的岗位知识和项目管理知识的培训；
岗上培训：主要根据开发人员的工作特点，针对操作中可能出现的实际问题，进行特别的培训，多偏重于专门技术和特殊技能的培训。
培训的方法有多种，例如课堂培训、在线培训，指导和辅导等。
8.4.2 人员激励
激励就是通过一定的引导行为来激发团队成员的工作动机和工作热情。
激励要因人而异。常见的激励方式有：
薪酬激励：必须让薪酬与绩效挂钩。
机会激励：获得机会实现职业发展。让员工有平等的机会参加学习、培训、从事有挑战性的工作和获得升迁等。
环境激励：企业内部良好的工作环境和氛围。例如管理层对工作人员的支持和关注，宽松和富有建设性的技术创新氛围等。
团队人员的激励
情感激励：员工需要被认同、被尊重、被关心。
有关激励的理论研究有很多，例如马斯洛的需要层次理论，海兹伯格的激励理论，麦格雷戈的X-理论、Y-理论，超Y理论，Z理论，期望理论等。
马斯洛的需要层次理论
人类的需要是分层次的（见下图）。人们的行为受到这一系列需要的引导和刺激。

在软件企业中，知识型员工普遍追求高层次的需要，企业管理者不能只停留在满足员工低层次的需要上。例如：
知识型员工的自尊心强，不要在公开场合批评和贬低员工的工作。
软件开发人员是追求自我实现的群体，企业管理者可以帮助他们制定职业生涯规划，尽力提供培训、工作锻炼的机会来帮助员工实现其职业发展需要。
Z 理论
Z理论是威廉.大内于1981年在《Z理论》一书中提出的，其基本思想是：企业经营管理者与员工的目标是一致的，二者的积极性可以融合在一起。Z理论的主要观点包括
（1）企业对员工实行长期或终身雇用制度，使员工与企业同甘苦共命运，并对员工实行定期考核和逐步提级晋升制度，使员工积极关心企业的利益和企业的发展。
（2）企业经营者不单要让员工完成生产任务，而且要注意员工培训，使他们成为多专多能的人才。
（3）管理过程既要运用统计报表、数据信息等鲜明的控制手段，而且要注意对人的经验和潜在能力进行诱导。
（4）企业决策采取集体研究和个人负责的方式，由员工提出建议，集思广益，由领导者做出决策并承担责任。
（5）上下级关系融洽，管理者对职工要处处关心，让职工多参与管理。
8.4.3 增强团队凝聚力的措施
通过一些措施加强团队的实际存在感。例如定期召开会议（包括项目启动会，项目评审会等）；可创建一个团队空间，在其中可以张贴项目组织结构图，项目进度图表等，大家可以一起工作和讨论问题。
可以组织一些正式或非正式的团队建设活动，增进团队成员的友谊，确立良好人际关系。
8.4.4 绩效评估
绩效评估就是工作行为的测量过程，即用过去制定的标准来比较工作绩效的记录及将绩效评估结果反馈给职工的过程。
绩效评估的根本目的是发现问题，完善工作，并使员工更好地发展。
按照目的划分，绩效评估的类型有：奖金分配评估，提薪评估，业绩评估，人事评估，职务评估，晋升评估。
绩效评估程序：
    （1）建立业绩考核体系。
    （2）将业绩期望告知员工。
    （3）测量实际业绩。
    （4）比较实际业绩和考核标准。
    （5）进行矫正。
8.4.5 冲突管理
项目的高压环境、责任模糊、技术上的不同观点等都可能引起团队成员之间的冲突。
如果适当管理，冲突的解决会带来益处，有助于提高创造力和做出好的决定，相反则会带来负面影响。
要管理冲突，应回答下面几个问题：
为什么会产生冲突？
该怎样处理冲突？
能否预测和防范冲突？
冲突的诱发因素
冲突的诱发因素有很多，常见的有：项目管理方式方法、技术见解、人力资源分配、成本估计、进度规划等。
各种原因的冲突在项目的不同阶段，其表现强度是不同的。例如技术冲突和管理方式方法冲突在项目后期的表现强度较弱，而在项目的中期则相对较强。
冲突的主要处理方式
1.问题解决（Problem Solving）：也称为“正视”（Confrontation）。双方一起积极地定义问题，收集问题信息，开发并且分析解决方案，直到最后选择一个最合适的方法来解决问题。这是冲突管理中最有效、最可取的一种方法。
妥协（Compromising）：双方协商并且都做出一定程度的让步，寻找一种能使双方都可接受的方法。
求同存异（Smoothing）：双方都关注他们同意的观点，而避免冲突的观点。
撤退（Withdrawal）：把眼前的问题搁置起来，等以后再解决。
强迫（Forcing）：采用一方的观点，否定另一方的观点。属于“赢-输”式的处理方式，除非有特殊情况，一般不推荐这种方法。
采用哪种处理方式视冲突的具体情况（为什么冲突？与谁冲突？）而定。
冲突管理的规划
在项目初期就应该对冲突管理进行计划，分析在项目的各阶段会出现哪些冲突，该怎样避免，怎样处理。
不适合在整个企业层次上建立冲突管理的政策和程序。因为每个项目产生冲突的情况和解决冲突的方法都有特殊性。
案例：IBM的团队建设绝招
IBM有一个让所有员工坚信不疑的游戏规则：干得好加薪是必然的。为了使每位员工的独特个性及潜力得到足够尊重，IBM一直致力于工资与福利制度的完善，并形成了许多值得我们参考的特色。 
1.激励文化
    薪水是企业管人的一个有效硬件，直接影响到员工的工作情绪。 IBM的薪资管理非常独特和有效，能通过薪资管理达到奖励进步、督促平庸的效果，IBM将这种管理已经发展成为了高绩效文化。
2.薪资与职务重要性、难度相称
       每年年初，IBM的员工特别关心自己的工资卡，自己去年工作干的好坏可以通过工资涨幅体现得有零有整。IBM的薪金构成很复杂，但里面不会有学历工资和工龄工资。
        IBM员工的薪金和其岗位、职务重要性、工作难度、工作表现和工作业绩有直接关系，工作时间长短和学历高低与薪金没有必然联系。在IBM，你的学历是一块很好的敲门砖，但绝不会是你获得更好待遇的凭证。
       在IBM，每一个员工工资的涨幅会有一个关键的参考指标，这就是个人业务承诺（Personal Business Commitments, PBC）。只要你是IBM的员工，就会有个人业务承诺（每年一次），制定承诺计划是一个互动的过程。从总裁开始，写下PBC，然后层层沟通和传达。某层员工会根据上
级经理人的目标去计划自己的目标，然后让下一层员工去建立他们较小的目标，如此类推。这样可以很有效地把所有员工的注意力重新放到最重要的事上。而且使各部门和上下级之间的目标都是关联的，降低了部门的自我中心意识。
你和你的直属经理坐下来共同商讨这个计划怎么做才切合实际，几经修改，你和你的老板其实立下了一个一年期的军令状，老板非常清楚你一年的工作及重点，你自己对一年的工作也非常明白，剩下的就是执行。大家团结紧张、严肃活泼的干了一年，到了年终，直属经理会在你的军令状上打分，直属经理当然也有个人业务承诺计划，上头的经理会给他打分，大家谁也不特殊，都按这个规则走。IBM在奖励优秀员工时，是在履行自己所称的高绩效文化。 
3.薪资充分反映员工的成绩
       个人业务承诺考核通常由直属上级负责对员工工作情况进行评定，上一级领导进行总的调整。每个员工都有进行年度总结，并与他的上级面对面讨论这个总结的权利。上级在评定时往往与做类似工作或工作内容相同的其他员工相比较，根据其成绩是否突出而定。评价大体上分10—20个项目进行。 
       评价工作全部结束后，就在每个部门甚至全公司进行平衡，分成几个等级。例如，A等级的员工是大幅度定期晋升者，B等员工是既无功也无过者，C等员工是需要努力的，D等员工则是生病或因其他原因达不到标准的。 
       从历史上看，65%—75%的IBM公司职工每年都能超额完成任务，只有5%~10%的员工不能完成定额。那些没有完成任务的人中只有少数人真正遇到麻烦，大多数人都能在下一年完成任务，并且干的不错。
简评
       激励在哪里都是需要的，激励的最佳力度取决于业绩与薪水之间的权衡。以业绩为基础的付酬方法的难点在于业绩的评估，其中的一个问题就是员工的行为一般不会完全转变成可以评估的业绩，而IBM的个人业务承诺（PBC）针对每个员工制定了单独的评估标准，很巧妙地解决了评估难的问题。同时，IBM不光注重自身的长远发展，同时又兼顾了员工的个人需求。
8.5 沟通管理
沟通是人与人之间的思想和信息的交换。沟通从一定意义上讲，就是管理的本质。据统计，项目经理80%以上的时间用于沟通管理。沟通失败是项目失败的重要原因。
沟通管理就是确定项目干系人的信息需要，并保证以合适的方式，把信息及时传递给他们。
沟通管理的基本原则是及时性、准确性、完整性、可理解性。
8.5.1 沟通需求分析
通过沟通需求分析可以明确各种项目干系人的信息需求。信息需求包括信息的类型和格式，以及该信息的价值。
为降低通信开销，应限制通信渠道。因此沟通需求分析需要依据项目组织结构图和项目团队成员的职责关系。
8.5.2 沟通方式
按传播媒介的方式可划分为书面沟通、口头沟通和电子媒介。
按组织系统可分为正式沟通和非正式沟通
按信息传播方向可分为上行沟通、下行沟通、平行沟通和越级沟通。
采用什么沟通方式取决于信息的内容、对信息需求的紧迫性以及项目环境等。
正式沟通
正式沟通是通过项目组织明文规定的渠道进行信息传递和交流的方式。
正式沟通的一种主要形式是“项目评审”。项目评审以会议的方式进行，用来检查项目当前的执行情况，并确定采取的管理措施。
项目评审可分为三种：定期评审、阶段评审和事件评审。
定期评审
1.定期评审：根据项目计划和跟踪采集的数据定期（例如每周）召开评审会议，对项目的执行状态进行评审，检查项目规模的变化、各项责任落实情况、项目进度是否得以保证、资源调配是否合理等等，对于出现的偏差制订纠正措施。
定期评审会议既是交流项目信息的方式，也是一个很好的激励方式。
阶段评审
2.阶段评审（里程碑评审）：在项目计划中规定的时间点（或里程碑处），对该阶段的任务完成情况和产品进行评审，目的是检查当前计划的执行情况，检查产品是否合格，对项目风险进行分析处理，并对下一阶段的项目计划进行必要的调整。
事件评审
3.事件评审：对项目进行过程中相关人员提交的事件报告（主要指对项目进度、成本、质量有影响的事件）进行评审，通过分析事件性质和影响范围，讨论事件处理方案，并判断是否影响项目计划，必要时采取纠正措施。
项目评审结束后，要产生一个评审报告，包括评审结果和所发现的问题。评审报告要及时发布。
非正式沟通
非正式沟通指在正式沟通渠道之外进行的信息传递和交流。它具有随意性和灵活性，并没有一个固定的模式或方法。例如聊天、非正式的面谈或聚会等。
软件项目团队中存在着大量非正式沟通。
非正式沟通补充了正式沟通的不足（正式沟通缺乏灵活性，且可能给项目人员带来压力），满足了项目人员的需要。
8.5.3 沟通管理计划
项目沟通计划确定项目相关人员的信息和沟通需求：谁需要什么信息，什么时候需要，怎样获得，选择的沟通方式，等等。
沟通计划是整个项目计划的一个附属部分，应在项目的前期阶段完成。在项目进行过程中，要根据沟通需求随时对其进行检查和修订，以保证它的持续有效性和适用性。
项目沟通计划的主要内容
项目干系人的沟通需求：他们需要什么信息，什么时候需要，这些信息对他们有什么价值。
沟通方式。描述传达信息所需的技术和方法。
人员联系方式。
工作汇报方式：明确表达项目组成员对项目经理或项目经理对上级和相关人员的工作汇报关系和汇报方式，明确汇报时间和汇报形式。
沟通时间安排。确定一些正式沟通的时间和频率。
沟通计划维护人：明确本计划在发生变化时，由谁进行修订，并对相关人员发送。
8.5.4 项目性能报告
项目性能报告一般应包括项目当前的范围、进度、费用和质量等方面的信息。许多项目还要求在性能报告中加入风险和采购信息。
及时发布项目性能报告可以使项目相关人员了解项目的当前状态、进展，以及下一步的工作计划。
项目评审报告就是一种很重要的性能报告，包括定期评审报告、事件评审报告和阶段（里程碑）评审报告。
项目周报模板
8.5.5 问题管理
项目团队成员在遇到问题时，不要总是一声不响、埋头苦干，而要及时与团队中相关人员交流。问题的及时解决可促进团队人员间的良好关系。
为了确保问题不被遗漏并及时得到解决，应创建一个问题跟踪列表（或使用变更控制工具来跟踪问题）。
问题跟踪列表


Open表示问题还没有解决；Resolved表示问题已解决，但还没有经过验证；已解决的问题经过相关人员验证后，状态称为Closed。
8.6 软件专业人员的非技术素养
8.6.1 团队意识
团队意识就是团队成员为了团队的整体利益和目标而相互合作、共同努力的意愿和作风。
团队意识具体表现在：
对团队的强烈归属感和一体感；
团队成员间的相互协作从而形成有机的整体；
对团队事务的尽心尽力和全方位投入；
使团队目标优先于个人目标；
愿意分享信息，理解别人的行为并产生适当的反馈；
当其他成员需要时给予帮助；
对别人的反馈作出积极地反应。
违反团队意识（团队精神）的常见做法：
不愿把自己的技术知识与别人分享，怕别人威胁自己的职位；
不喜欢与别人交流，不愿求助于别人，有问题后孤军奋战。
8.6.2 主人翁精神（Ownership）
主人翁精神是指对团体及其产品有一种“拥有”意识，因此主动关心团体的利益并愿意为之付出努力。
主人翁精神还表现在发挥主观能动性、敢于负责、勤于思考、勇于做出判断并表达自己的意见。
案例
当你加入一个产品开发团队以后，无论团队是只有一两个人，还是成百上千人，你都是产品的一个负责人（Owner），都要有这样一种精神和意识：“这是我的作品，我将制作它，我希望它能成功！”。
企业领导要有意识地通过各种方式培养员工的主人翁精神。如适当放权，配发股票等。
8.6.3 写和说的能力
写和说是人们向外界表达自己能力和才华的最重要途径。可是表达能力低下却是许多研发人员的通病。
要重视表达能力。“表达能力不重要，而技术才能才是最终要的”观念是错误的。
软件专业人员要不断与别人沟通。而且如果表达能力差，就无法胜任需求开发、系统设计、管理等高层次的工作。
怎样提高表达能力？“无他，唯手熟尔”。
珍惜每一次写文档、会议发言、作报告的机会，保证质量完成任务，通过多练逐步提高。
技术类的文档（包括开发文档、商务文档、产品说明书等）有四大要素：内容、逻辑、实证、措辞。
（1）内容充实，切忌空洞无物，大话、套话连篇。
（2）内容表述要逻辑清晰，容易理解。
（3）内容要有真凭实据，不能有虚构、夸张、造假成分。
（4）措辞追求“正确、准确、优美”。
当众发言（会议、演讲、报告、讲课等）要注意以下几点：
（1）事先做充分准备。多练几遍，熟悉内容，控制时间，避免在现场手忙脚乱。
（2）仪表整洁，精神抖擞。
（3）声音响亮。
（4）避免过分随意的口语和“口头禅”。
8.6.4 管理能力
管理能力是指带领团队完成目标的能力。
在企业里，不仅各级领导要会管理，而且还要让员工们懂得被管理（俗称洗脑）。
稳扎稳打的职业发展模式：先搞技术，拥有一技之长后再逐步转向管理。
做好管理工作，不仅要用脑，而且要用心，不仅要有智商（IQ），而且要有情商（EQ）。
怎样培养管理能力？  学习 + 实践
要学习本行业基础的管理知识
本门课程的知识；
能力成熟度模型（CMMI）；
从底层的管理者（如项目经理）做起，不断实践，积累经验，提高能力。
软件项目人员管理案例
圣人的话：
          在管理上，对于人力资源，要考虑：量材录用，帮助提高，绝不轻视弃置。 
本章小结
理解软件项目人力资源管理的主要作用和主要内容。
理解项目组织结构的确定：项目组织类型及其特征、不同小组结构的特征。
理解项目团队的建设：人员配备、培训、绩效管理、激励。
理解项目沟通沟通方式、冲突管理，了解沟通计划。
了解软件专业人员要有哪些非技术素养。