中小团队技术团队管理涉及到哪些方面。

范围、时间、成本、质量是几个重要要素，这些管理相应的会涉及到资源、风险、沟通、采购、整合管理方面。

互联网团队项目管理职能，一般主要涉及范围管理（需求方面）、时间管理（进度方面）、成本管理（人力与金钱方面）管理、质量管理（功能BUG与性能方面）、资源管理（人和物即团队人员/制度/奖罚/招聘等）、风险管理、沟通管理等

目录

• 我们想要什么样的团队
• 团队什么时候需要管理者
• 管理者角色职责
  • 管理者角色
  • 管理者职责
  • 项目经理
• 研发团队成员角色
• 团队章程
  • 价值观
  • 仪式感
  • 会议
• 招聘面试
  • 内部统一的面试标准
  • 笔试题目
  • 实习生
  • 专业技术面试
  • 综合能力面试
  • 面试怎么聊
  • 鲶鱼引入差异性
• 新人入职
  • 入职
  • 跟踪观察期
• 绩效考核与奖罚
• OKR
• 团队激励
  • 物质激励方式
  • 精神激励方式
• 研发过程管理
  • 整合管理
  • 范围管理
  • 时间管理
  • 质量管理
  • 成本管理
  • 资源管理
  • 风险管理
  • 沟通管理
  • 采购管理
  • 敏捷开发
  • 项目团队发展模型
• 工具
  • 需求管理工具
  • 设计管理工具
  • 代码管理工具
  • 任务流程管理工具
  • 测试用例管理工具
  • 缺陷管理工具
  • 文档资源管理工具
  • 持续集成与发布管理工具
  • 其他工具
• 研发约定与规范
  • 版本管理
  • 编码规范
  • 发布规范
  • 测试规范
  • 竞品分析
  • 团队分享与培训
• 跨部门
• 经典理论
  • 马斯洛需求层次理论
  • 赫兹伯格的双因素理论
  • 麦格雷戈的X理论与Y理论&大内的Z理论
  • 弗洛姆的期望理论
  • 麦克利兰的成就动机理论
  • 亚当斯的公平理论
• 参考

我们想要什么样的团队

团队的人生观，也就是说我们想要什么样的团队，团队的态度，团队要活成什么样。

• 目标。团队的目标为公司盈利，或积累技术基础，或积累可能变现的流量，积累团队成就，让公司及团队更具荣誉感。
• 角色。团队有完整的成员角色。
• 一致性。团队内部三观一致、目标明确一致、利益一致。
• 高效直接。团队内部高效直率沟通、快速反馈不碍面子、拥有质疑精神、相互信任与理解
• 竞争。营造良性竞争氛围，允许嫉妒，但要提升自己而不是破坏他人的嫉妒。
• 参与。团队成员有知情权、发言权，有参与感、责任感、成就感
• 不唯上不唯书只唯实。考虑问题从实际出发，实事求是。
• 敢于面对问题，承认问题，分析问题，解决问题。

团队什么时候需要管理者

• 初创时，需要的是专业高手，团队成员专业能力相对较差，由专家型管理者领头带动大家向前，管理者不是必须的，没有太多可以管的。
• 进入稳定期，管理者需要具备较强的管理和专业技能，由于有各个领域丰富经验的成员，所以稳定期需要完善制度，需要一定程度流程化、规模化，确保成员大体按制度流程正确的做事，降本提效的同时，降低风险。越来越稳定了，甚至可以衍生出项目管理这个角色，但由于团队成员专业能力较强后，这个项目管理角色可能会是民主型亲和型风格的管理协调者。
• 团队开拓新渠道或转型时，同样需要专家以及陌生领域上的顾问，因为要活跃下僵化的思维，打破惯性，经常性的头脑风暴及自我否定，继续前行。
• 再次进入稳定期，有序的管理，使得团队更高效进取。
• 团队危机时刻，需要强制型的管理者，有能力出结果走出危机。

管理者角色职责

管理者角色

• 项目发起者
• 计划推动者
• 会议主持者
• 前线参与者
• 攻坚指挥者
• 教练导师
• 项目管理助理
• 质量验收者
• 客服
• 绩效考核人
• 团队组建人
• 时间进度协调者
• 成本估算调整人

管理者职责

• 明确目标
• 约定规范
• 获取资源
• 建立团队信息（成员信息、联系手册等）
• 分享培训
• 过程与质量管理

项目经理

• 影响力

  作为一个管理者，需要有较强的影响力。

  • 项目。做好项目
  • 组织。获得组织认可
  • 行业。对比对手，反思自我，发现机会
  • 专业。做T型人才。 参考
  • 跨领域。宣传管理、三观等

• 胜任力

  • 技术管理
  • 战略与商务
  • 领导力
    • 灵活运用6种领导力风格。6种领导力风格
    • 了解9种人格。9种人格
    • 熟知6个经典管理理论。团队管理10-六大经典管理理论
    • 冲突决策。5种冲突解决策略

• 执行整合力

  • 过程
  • 认知
  • 背景

研发团队成员角色

团队大小：7(±2)，敏捷开发盛行，超过10个人都是大团队，也可以是5（±2）更精简，早期每个角色有1个人承担就够。后期可以根据角色放大成员数量。

• 产品设计
• UI/UE设计
• 服务端工程师
• 客户端工程师
• 质量管理
• 技术支持(要求每月有技术对外联系客户)
• 项目管理

如果有就更好的原则：

• 团队角色完整，除非资源不足。我们更喜欢完整有团队感的整体，灵活有战斗力的整体。
• 男女搭配
• 新老配
• 开心果
• 富二代
• 爱国敬业诚信友善，踏实

团队章程

团队章程是为团队创建团队价值观、共识和工作指南的文件。尽早认可并遵守明确的规则，有助于减少误解，降低成本，提高效率。

价值观

团队里什么值得鼓励，就是团队的价值观。

鼓励什么，就容易得到什么。鼓励什么，时间就会花在什么地方，时间花在哪里，哪里的成就就会高些。

• 鼓励结果，鼓励质量效率，不鼓励加班，不鼓励工作量
• 鼓励沟通对事不对人
• 鼓励天道酬勤，鼓励敬业
• 鼓励沟通高效直接，直入主题
• 鼓励质疑精神、思考任务的目的
• 鼓励知识经验分享
• 鼓励写文章
• 鼓励提出建议和意见
• 鼓励诚信友善

仪式感

仪式容易培养使命感。使命感不是喊出来的，使命感来自团队成员自己深刻的理解和认同。有了这样的使命感后，团队当中的每一个人才会有某种自觉的意识。

团队的调性及一些好的习惯。

• 日常团队点餐吃饭

• 周报

• 周会

  说清楚在这个周期里，做了哪些有价值的事情，哪些有意义的事情，存在问题，如何改进或避免，未来计划等

• 月底对主要人员一对一月谈

• OKR目标与关键成果阶段性同步会

• 导师教练制度

• 重大突破阶段奖励

• 参加外部会议、组织培训等

• 团建。晚上的聚餐，周末周边游，周末游戏、桌游、电影等

会议

会议涉及开会的目的，会议的类型方式，什么时候开会，怎么开会

会议目的：

• 传达公司战略与指令
• 问题分析与解决方案
• 信息共享与经验交流分享
• 工作分配
• 树立典型
• 帮扶后进

会议方式：

• 站立会
• IM会议或远程
• 休闲区或小会议室（轻松活泼）
• 会议室（严肃正规）

会议类型：

• 团队周例会
• 立项评审
• 宣讲会
• 设计评审
• 产品验收评审
• 临时信息同步会

会议要素：

• 主题。明确会议主题，不深入讨论其他主题。
• 与会人员。尽量不大于10人，相干负责人。
• 时间。开始时间，预计结束时间，尽量在1个小时以内
• 会议资料。提前准备会议资料，提前一天或半天让与会人员有时间初步了解会议框架。
• 记录。要求有专人实时记录关键问题与信息，会后整理发给相关人员，一般由对项目了解较为广泛的人来负责，也可以为了培养成员相关能力，轮流记录。

会议记录：

• 时间
• 地点
• 主题
• 参与人员
• 主讲人
• 会议记录人员
• 主要事项
  • 存在的问题
  • 计划事项
  • 会议决定
  • 以上三项结合相关负责人

会议原则：

• 提前制定会议日程。至少提前一天通知会议相关信息，人员、时间、主题等
• 会前信息充分。会议前至少半天拉群并发会议资料
• 消除等级差。如决策人并不一定要坐在中间位置，除非是主持人
• 自由发言。充分给与团队知情权与发言权，尽量不一人独断
• 鼓励提出问题，允许犯错
• 沟通高效直接，聚焦主题不发散
• 点评对事不对人，不攻击人身
• 会议结果，坚决执行，共同负责
• 能站着开的就站着，如在会议室白板前

关于会议时间：

• 10点前尽量不开会
• 17点后尽量不开会
• 周一或周五开例会，其他时间尽量不开会
• 参会不迟到，迟到一分钟，浪费所有人10分钟
• 高效不超时，时间尽量控制在1小时内

例会总结：

公司一般会有周例会，会有月度会议，相应的也有周工作计划、月工作计划，甚至年度工作计划。中小公司新团队建议是每天早上最少一次会议，每天做次日工作计划。也就是说小团队（不够成熟、人员不够优秀）可以每天早上一次简单会议，这个简单的会议可以是IM的线上会议，主要是强调活动任务并互相确认目标与计划。

每个成员都需要有自己的材料总结，可以是PPT、MD文本等，主要内容：

• 过去一个周期总结
• 下一个周期计划
• 周期中出现的问题与解决方案
• 建议和意见反馈

总结内容不是简单流水账，概括性总结问题与结果，一般3~5项。周期计划不多，3~5项，视周期长短，灵活概括归纳计划，任务描述与期望结果。

招聘面试

内部统一的面试标准

建立统一的面试标准

• 了解不同岗位及其核心要求

  开发、产品、测试、设计等各自的专业知识要求不一样，需要各自负责人提供专业知识面试

• 确定岗位核心能力关键项

  由各自负责人提供专业面试关键项

  专业能力在10项之内，综合能力在10项之内

• 确定评分标准

  优秀s、合格a、待定b、不通过c

• 建立团队录用标准

  初级执行者合格以上，短期紧急情况下考虑待定

  小组负责人或高级执行者，合格以上

  专家，要求优秀，至少要比当下员工优秀的人

• 形成面试评估表

  复试面试官需要给出面试结论，是录用还是不录用，一般待定的和犹豫的按照经验都建议不录用。犹豫的肯定是哪里有问题或者觉得不够好，这样的同学来了也是一根刺，怎么用都难受。

笔试题目

对于研发，前端、后端的不同语言，有不同的笔试题，笔试是为了筛选基础不牢的混经验主义的应聘者，不浪费公司面试人力资源。

实习生

一般我们对实习生有4方面的要求：

• 学习能力。越好的学校越好的专业越好
• 沟通表达。有爱好，善于交流、思路清晰
• 三观态度。聊聊参加过的活动、学校团体干部、聊聊时事（贴近公司文化价值观，三观端正）
• 擅长潜质。聊聊对自己身上认为比较励志的一些事

人都具有特殊性，这只是我们对实习生一种普遍的看法，具体情况视具体面试情景。

面试时关心实习生的4大方向

专业技术面试

专业能力在10项之内，具体以岗位相关。待补充。

专业技术面试一轮是很危险，可以的话建议两轮技术面。

后端PHP面试题框架

前端面试题框架

综合能力面试

面试建议直接问，比如问：如果项目出现问题，刚好下班了，你选择怎么做？这面试者通常会认为自己会加班处理，这问题的意义不大。

• 求职动机。是否合理，是否不稳定因素。
• 工作经历。是否稳定。
• 离职原因。是否合理，是否与团队出现严重隔阂。
• 个人定位。有客观定位的人，脑子更清楚自己要做什么。
• 个人目标。有客观目标的人更积极。
• 学习能力、执行能力。学习能力才适应技术的发展。
• 兴趣爱好。深入了解可以了解一个人本质的性格。善于社交、运动的人更阳光乐观大气。
• 三观心态。对某些事件的看法，表达正常的世界观；作出选择，表达价值观。
• 做事态度。
• 责任感。面试也是测试，测试尽量在面试者不知道面试目的的情况下进行，效果最好。
• 心里承受力。比如对加班、临时工单、更高岗位的看法。
• 岗位匹配度。技术能力与综合能力是否与岗位相匹配。
• 薪资匹配度。个人对薪资增长的要求。

以上综合能力满足4-6项的初级人才可以考虑培养，满足7-9项的人才视为合格，10项满足的视为优秀。

学习能力、执行力比较好，而且足够勤奋和积极，有着积极的心态。

面试怎么聊

• 聊聊兴趣爱好。可以了解对方的性格和三观，也容易让面试氛围放松，缓和陌生人气氛。

• 聊聊希望做什么样的工作。不局限当前交流的职位，给出最理想的答案，哪怕是拼命挣钱为了40岁之后环游世界这样的回答。可以了解对方的工作态度、职业规划和个人目标，同时仍包含了兴趣因素。

• 聊聊在之前的工作中，最有成就感和最失望的事是哪个。「成就感」可以了解特长；「失望的事」给了一个吐槽的机会，考察面对困难和压力的心态。

• 聊聊自认为在工作中的特长和优势是什么。考察自我认知，了解亮点。

• 聊聊如果让你做这个职位，你会怎么做。给一个开放的话题让对方发挥，即使信息太少和准备不充分也没关系，看看对方短时间内的应对能力。毕竟不是为了得出什么正确答案，而是看分析问题的思路。

• 聊聊本次面试有什么感受，自我感觉交流的怎么样。考察自我认知和判断能力。

• 给与对方一个提问的机会，了解对方还关心什么，了解对方主动表达能力。

综合能力的面试，不同岗位有不同能力要求：

比如初级开发工程师我们看重专业知识、开发能力、项目经验、沟通能力、学习提炼能力、承压能力、态度、三观等

而有经验的高级工程师我们看重的是工作经验、以往优秀产品项目、专业知识、学习能力、设计能力、开发能力、调试能力、协调沟通能力、性能优化能力、架构设计、团队管理能力等

注意一些细节：

• 高级人才，一般不在招聘网里
• 是吸引而来还是招聘而来
• 是否有大企业背书或高校背书
• 重看经历、重查经历中的细节，细节不会骗人
• 人生目标、短期目标问题，有目标的人通常比没有目标或目标不明确的人表现更好
• 看法，对xxx的看法，可以了解一个人的三观与态度，特别是价值观，尽量与公司一致
• 沟通表达能力、形象思维、逻辑思维清晰程度

鲶鱼引入差异性

对具体的招聘岗位来说，技术不错、扎实肯干、能投入工作，这样的标准作为基础当然没有问题。但作为团队的统一标准，就未必合适了。因为团队是个综合的有机体，不能以绝对单一标准来衡量。即便是软件公司，即便招聘的是技术人才，也不能以这样做。如果全是同样的人，一方面大家不太容易因为差异产生新奇的感觉，所以难免感到乏味单调。更何况，许多程序员自己是闷瓜型，并不代表他希望呆在一个闷瓜型的团队中工作。

有意识地在团队里引入差异，引入“鲶鱼”，把团队气氛搞活起来，把活力调动起来。

我们观察开发团队的现状，对比理想的开发团队，继而决定在招人时需要侧重哪些方面，为团队引入差异性：

• 对于技术上不思进取的团队，就要引入技术精纯的人来抬高大家的眼界，激发大家对技术的热爱；
• 对于沟通沉闷的团队，就要引入性格开朗、能说会道的人来促进交流，让大家习惯更密切更频繁的交流；
• 对于生活比较单调的团队，就要引入有健康兴趣爱好而且有足够魅力的人来带动大家，让大家的生活丰富起来

按照这样的做法，或许短时间内确实“错过”了一些还不错的人。但总的来看，能够始终把团队保持在一个比较健康的状态，营造不错的凝聚力和工作氛围——不要忘了，带领团队是长跑。

新人入职

入职

• 入职前一周提前安排一周的工作计划
• 介绍公司概况及团队介绍
• 交流产品项目阶段状态
• 了解新人对工作的要求
• 第一天就明确告知工作内容
• 新员工公司大礼包（账号、代码仓库、WIKI、人事培训等）

跟踪观察期

跟踪周期：

• 第1个月每周新人跟踪
• 第1个月新人跟踪评估
• 第2个月或3个月转正跟踪评估

跟踪评估内容：

• 工作态度。积极性、认真诚恳。
• 工作能力。解决问题为准，结果导向，也关注过程。
• 工作绩效。工作完成度。
• 培养方向。方向没有那么快确定，一般需要月跟踪及根据公司项目实际情况定向培养，也需要了解新人的期望与意愿。
• 建议。对于新人从细节抓起。

结合新人自评：

• 工作内容
• 工作存在的不足与改进计划
• 对工作量与强度的看法
• 自己是否与岗位匹配
• 对上级指导者的评价
• 公司有哪些地方吸引你
• 公司有哪些地方需要加强或有哪些建议

绩效考核与奖罚

首先要明确知道考核的目的是什么，考核标准是什么，及考核奖罚制度是如何的。才能方便管理层主观评价一个员工，是在团队里比个人成绩，还是按个人同比，不论新人还是老人，不论是新手还高手。比如新手有进步，是给高分还是给低分，进步是进步了，但还不够优秀，给了低分影响新手积极性，给高分对高手不公平，因此需要一个多维度甚至360度的考核机制，比如从个人进步、态度、敬业度、团队贡献度综合评分，不同维度具备不同权重值，比如以团队贡献为基础，团队贡献的权重会是更高的一个评估维度。

绩效考核是手段，奖罚是表面目的，本质目的是促进团队自我肯定、自我否定，从而达到个人发展推动团队发展。

国内中小团队人不多，大部分研发项目都不方便采用KPI的方式做考核，可以结合OKR来评估。

• 考核

  一个人的考核系数：公司、部门、个人，三个系数，加权得到总评。团队对公司的贡献，个人对团队的贡献，个人自评。

  允许打分最小单位在0.5分
    
  非管理人员考核 = 个人进步×0.1 + 敬业×0.2 + 团队分×0.2 + 个人团队贡献分0.5  建议每一项打分在5～12之间
  
  管理人员考核 = 个人进步×0.1 + 敬业×0.2 + 团队分×0.4 + 个人团队贡献分×0.3  建议每一项打分在5～12之间
  
  比如一个团队自己打9分，团队上级领导打团队分8分，团队上级领导给团队的管理人员打分：个人进步分6分、敬业分8分、上级给管理员打的团队贡献分8分
  
  则最终：6*0.1+8*0.2+8.5*0.4+8*0.3 = 0.6+1.6+3.4+2.4 = 8分
  

  管理人员考核更看重团队成绩，而普通成员考核更看重个人团队贡献分。由于成绩来自于上级的主观的打分，所以也要求成绩点评，甚至要求个人自我打分与成绩点评，即使主观，也要符合客观事实，让考核成绩不至于太荒谬或恶意打分。而考核系数和项目有关，热火朝天大热的项目，难度系数降低。

  敬业这个指标，可以通俗的表现为考勤，直白点就是考勤时间是不是996，甚至以上，有点残忍。

  注：团队打分一般有团队自评与上级考评，对于团队与成员不够成熟时，可以上级考评为最终成绩；个人团队贡献分，同样有个人自评与上级考评，也同样可以考虑以上级考评为最终成绩；个人自评可以作为参考，如果对最终成绩有意见可以及时提出与上级或管理者沟通。

  模板简易参考：

  ---

  -	团队打分	团队点评
  自评	-	-
  上级考评	-	-

  ---

  被考评人	自评打分	自评评语	-	上级打分	上级评语	考评人
  cy	9	soso	-	9.5	good	jm
  cy	9	soso	-	9.5	good	jm

• 考核定义与分布

  打分	定义	分布	其他
  <6	不合格	>15%	-
  6	需要改进提高	>15%	-
  7	符合期望	50%	-
  8	部分超出期望	-	-
  9	超出期望	-	-
  10	持续一贯地超出期望	-	-
  11	杰出	-	-

  在考核上没有太多人性化，要求3-6-1分布，一个团队有10个人，那么会有3个评为好，6个人评为一般，至少有1个人评为差，这个差是团队里的最差。

  个人自评时，也需要了解每个分数档的含义，对自己负责。

• 职级

  职级体系，职级与职位有区别，职级与待遇挂钩，职位与职责挂钩。

  架构师的职级可以比自己的领导高，但职位可能会低于领导。

  职级是研发人员的向上通道。研发团队适合OKR+职级+主客观相结合评价，不适合KPI的方式，KPI适合商务销售市场有比较明确数据指标支撑的岗位。

• 奖罚及时到位

  奖惩一定要分明，奖励要求不能过于苛刻，要那种一般坚持大家都能做到的。

  惩罚就是原则性问题，一定要有力度，严格执行，否则原则就没有底线了。

  • 金钱

    • 按月考评打分给与同比例的项目约定奖金。比如10分拿100%的项目奖金。
    • 年终通过每月考评成绩得到年终奖或季度奖金

  • 职级

    职级，职级与职责和薪资挂钩。

    年中6月底与年末12月底各一次职级考评。需要有资格人员申请或上级推荐。

    有重大失误者，考虑降级甚至劝退。

  • 日常过失

    • 线上被列为重大bug。影响客户使用，影响产品口碑，公司亲自关注的。除了负责人首责，经手人也要求连带责任，公司层面降低绩效，团队内部惩罚，比如每星期的一次请团队吃的水果由负责任的人负责。
    • 覆盖他人代码，请对方吃顿饭
    • 工作时间占用同事太多时间帮忙的，请同事喝饮料之类
    • 每月bug最多惩罚

OKR

5分钟了解OKR - 9ong

OKR在中国能行得通吗

团队激励

如何激励团队成员

• 激励的目的是什么？激励人首先要超越自己，其次超越其他人，使得团队自我超越。

• 激励要有目标。得有个目标才知道往个方向努力，否则激励无效。

• 激励方式多样性。

  不同人需要不同的激励方式，每个人对马斯洛需求不一样，生理、安全、社交、尊重、自我实现需求逐渐上升，新人还处于安全需求期，需要基本的生活费用，管理人员则需要更多的尊重和自我实现。

• 激励公平性。奖励规则应该对所有人是公平的，或者是至少有两个激励规则可以覆盖两个以上不同群体。也就是奖励是每个人都有可能拿到的。

• 激励认可性。激励需要得到认可。奖金本身就是一种认可，但不长久；名誉认可，比如最佳员工、优秀员工等评奖，配上定制的礼品，是一种较为长久的认可。

物质激励方式

物质激励方式也都比较直接的激励方式。

• 高名誉价值和低金钱价值

  证书、奖杯、定制礼品、与老板共进午餐等虚拟奖励，满足人的社交、尊重需求。这是最好的奖励方式。

• 高价值商品奖励

  iPhone、iPad、华为手机、小米设备等。

• 现金奖励

  与高价值商品奖励一样，容易使得人过分依赖于金钱，而且容易混淆薪资与奖金的概念，奖金是一种额外的奖励，而不是固定在薪资部分中。在奖金消费后，容易再次失去积极性。

• 佣金奖励

  要谨慎，一定是要那些有利于销售的人才能关联佣金，在互联网行业中，基本上没有公司会将研发体系下的人员关联到销售佣金上，这方面个人觉得是这类公司需要改革的地方，后期互联网产品边际成本低时，完全可以考虑，从生产到运营到销售一体佣金，目前看比较难以实现，可以考虑特殊的个例销售分成。

• 提升个人能力

  给与更多机会和晋升通道

精神激励方式

精神激励方式是潜移默化的，不那么直接说出口，间接的激励。

• 榜样激励。 团队负责人在团队中树立榜样，激励团队成员。除了负责人，还可以树立团队中榜样，鼓励典型。
• 目标激励。 目的让员工对团队前途充满信心。将个人目标上升到团队目标。
• 授权激励。 有重任在肩的人更有积极性。放权给成员负责。激发成员。
• 尊重激励。 马斯洛需求中，在满足生理与安全需求后，社交需求与尊重需求是人追求的。试着用请求、商量、探讨的语气，不要端着架子，官架子一时爽而已。
• 沟通激励。 通过消息不对称满足成员知情权，激发被尊重感。私下批评，公开表扬，批评对事不对人，表扬对人。
• 信任激励。 信任说到底还是尊重激励，用人不疑，允许犯错。把重要的事交给你做，信任你，做错了，一起补救，给你犯错的机会，信任你。
• 宽容激励。 允许犯错，弥补错误。
• 赞美激励。 赞美是最好的激励方式，在我们看来。赞美应该若有其事的赞美，赞美不能空泛，要具体到人家真的有的具体细节上。还可以给带高帽，某方面的专家，擅长疑难杂症，方案高手等高帽子。
• 竞争激励。 鲶鱼效应，残忍但很有效的手段措施。有活力才能有创造力。要注意引导良性竞争，避免恶性竞争。
• 文化激励。 企业文化认同感，企业价值观，良好的企业环境等，让人舒适有正能量。
• 惩戒激励。 不得已的方式，“签军令状”式的公开员工承诺。少一点惩罚，多一点鼓励，说的轻松，做到难。

当然精神激励大到以上的方式，小到一个微笑、点头、目光关注、大家跟我往前冲等肢体语言。

不要尴尬的激励，激励需要合适的时机、合适的场合、合适的激励方式与表达方式。

团建，我们不认为是用来激励员工的，团建是让团队互动，让团队相互更深入了解彼此，现在看团建已经是所有公司必备福利，已经不是作为奖励。

研发过程管理

项目过程管理流程：

整合管理

• 制定项目章程

  项目章程是证明项目存在的正式书面说明和证明文件。

  项目章程是一份简短的文档，以简洁明了的方式说明了项目。章程通常在设计时就考虑了高层管理，章程应包含项目的范围，目标和参与者，这样任何人都可以在短时间内了解项目概念。

  项目章程还应划定许多角色和职责，必要时包括利益相关者，同时概述项目中的一些目标和截止日期。

• 制定项目管理计划

  项目管理计划，就是说明项目执行、监控、收尾方式的一份文件。内容包含：项目管理过程是什么样的，项目选择的生命周期，项目干系人有哪些，范围基准，绩效基准等等

• 立项

  • 项目背景分析
  • 项目目的
  • 项目目标
  • 初步范围说明
  • 项目里程碑
  • 项目组织结构

• 干系人

  对于项目来说，有权利的，有利益的人，分布在四象限里，权力大利益大的，权力大利益小的，权力小利益小的，权力小利益大的，这四类人分别对待，重点管理第一类人，让第二类人满意，让第三类人来监督，及时告知第四类人。

• 指导与管理项目执行

  监督、指导、引导、管理项目执行

• 监控项目过程、实施整体变更控制

• 项目总结

范围管理

项目要做什么

• 需求梳理

  深入了解需求，梳理需求，按模块功能归类，自顶向下逐步细分功能点

• 定义范围

  明确项目的范围、合理性、目标，以及主要可交付的成果。

  范围边界，是应该做的工作和不应该做的工作的分界线，需要比较明确的阶段范围说明。

  可交付成果，要仔细定义，这是很重要的项目产出，服务、文档、数据等。

• 创建WBS

  WBS组织并定义了整个项目的范围。WBS分解后方便任务分配、时间估算、成本估算、跟踪交付成果。

  WBS表涵盖编号、模块、详细内容、负责人、关联任务、时间、开始时间、完成时间等信息

  WBS没有所谓的正确的方式，可以使用草图、excel、项目管理工具project等，只要能满足，可灵活运用。

• 范围变更

  对应文档、WBS相应调整

• 控制范围

  项目成员应该将工作时间和资源放在范围边界之内的工作上，反之回报将非常少。所以项目团队要注意控制当下项目范围。

时间管理

项目什么时候完成

在给定的时间内完成项目是项目的重要约束性目标，能否按进度交付是衡量项目是否成功的重要标志。进度控制是项目控制的首要内容。

• 定义活动

  在WBS分解后，得到项目的所有叶子任务，每个叶子任务都是可以由单人短时间内完成。

• 排列活动顺序

  一般来说，每项活动的执行可能需要依赖于另外一些活动的完成，也就是活动与活动之间存在先后依赖关系，在有此依赖关系的基础上，我们需要确定各个活动之间的组织关系。

  • 前导图法。
  • 箭线图法。常用方法。箭尾是紧前活动事件，箭头是紧随活动事件。

  当然依赖关系，可以是客观的固有的强制性依赖关系，也可以是团队人为确定的依赖关系。

  依赖关系除了先后顺序依赖关系外，两个活动同时开始我们称为平行关系，两个活动有部分在一段时间内平行进行，我们称为搭接关系。

• 估算活动工作量

  要估算活动历时，需要估算活动的工作量。我们觉得通过代码量来评估的算法，都是为了评估而评估。软件产品本身的复杂性、历史经验的欠缺，估算工具的缺失，甚至人为错误，很难适应现在开放的互联网，工作量的估算，在成本估算中会提到一些，大多还是结合团队经验和团队状况。

• 估算活动持续时间

  估算所有活动的工作量后，以一个最小粒度的活动作为单位，估算活动持续时间，并作为活动单位时间，其他活动参考该单位时间估算活动持续时间。

• 关键路径法

  关键路径算法的核心思想是将WBS分解的活动按逻辑关系加以整合，统筹计算出整个项目的工期和关键路径。

  从开始结点到结束结点的最长路径称为关键路径，关键路径上的活动关键活动。

• 制定进度计划

  我们可以借用一些项目管理工具，比如excel、project、wiki等进度管理工具制定进度计划，并用于监控进度。我们常见的是进度列表数据与甘特图的结合，可视性更好，近些年也有很不错的线上管理工具提供更好的进度管理工具，国内的worktile等在这方面做的不错。

• 定期监控进度

  每周固定时间检查进度，我们建议重点查看分析关键活动的进度偏差情况，如果发现进度严重落下，需要对进度进行调整，一般是先进度压缩。建议团队成员应该及时反馈进度不畅问题，不应该在严重落下等进度监督时才提出不畅问题，一来已经影响进度，而来会再影响其他关联活动计划。

  项目进度计划调整：

  • 进度压缩的方法：
    • 关键活动调整，如范围缩小
    • 增加资源数量
    • 提高资源利用率
    • 改变流程、技术算法
    • 加班赶工
    • 外包赶工
    • 非关键活动调整保证关键活动可进行
    • 增减活动

  加班赶工是常用的方法，不改变活动之间的顺序，可以分配更多的资源用于加班赶工，但通常为延期的项目增加人员往往进度会更慢。

质量管理

项目要做成什么样

• 质量投资效益

  • 减少返工，降低成本
  • 提高生产力，提高效率
  • 增加利润
  • 提高品牌力

• 规划质量

  • 过程质量

    软件工程的三要素：过程，方法，工具。过程是软件工程中很重要的因素。过程涉及软件开发流程环节、规范约束等。

  • 文档质量

  • 产品质量

    产品质量属性：参考系统架构质量属性

    涉及：性能、可靠性、可用性、安全性、可修改性、可维护性、功能性、可改变性、可测试性、互操作性。

    每个产品项目都有一个质量期望。比如网站的可靠性，3个9，4个9，日访问100万，支持1k并发等。

• 设计用例

  在设计阶段，测试通过测试用例工具，根据需求设计测试用例。 测试用例管理工具：excel表、testlink、testhub、

• 实施质量保证（执行测试用例）

• 实施质量控制（测试迭代）

• 现代质量管理观点

  • 质量是规划出来的。不是检查出来的。
  • 质量不仅仅说的是产品，包括产品整个过程。
  • 质量管理，人人有责。质量管理不仅仅是质量管理部门的事。
  • 如有质量问题，责任应该从上到下划分。基层质量管理人员不应该负主要责任，但会影响其绩效。
  • 范围、时间、成本影响质量。质量并不是单纯的质量，而是要符合、适用、多方满意，需要考虑时间、成本问题。
  • 改进质量要重视预防和评估。

成本管理

项目要花多少钱

• 估算成本

  对项目投入的各种资源成本进行估算，估算也主要靠分解和类推进行。

  • 自顶向下估算法。

    参考过去已完成项目成本，推算当下项目总成本，并按比例分配到各个模块中去。强调项目的普遍性，由于项目的特殊性，该估算法往往不是很准确。

  • 自底向上估算法

    在任务分解后，将已经明确的子任务工作量加起来得到项目总工作量/成本。忽略了任务之间有联系，估算值往往偏低，需要灵活校调整。

  • 差别估算法

    将以上两种方法相结合，当然我们还要考虑项目具有发展性质，所以估算就是估算无法做到精确，也需要不断的跟进调整。

• 成本预算

  成本预算是将成本估算分配到项目的各项具体工作上。以确定项目各项工作和活动成本定额。

  成本预算考虑一些因素：

  • 非直接成本。租金、保险、其他管理费用。
  • 隐没成本。项目之前已经发生过的成本。
  • 学习曲线。新技术的尝试与试验。
  • 时间要求。过短，项目风险高，项目压力大，过长，项目成本大
  • 质量要求。成本会影响质量要求。
  • 保留。为风险和未预料的情况而准备的保留成本。

  预算步骤：

  • WBS
  • 分摊项目总成本到WBS各个模块任务，为每个模块任务建立预算成本，在将所有模块任务的语段成本相加，不超过项目的总预算成本。
  • 将每个模块任务分配得到的成本再二次分配到下级模块任务活动上。
  • 确定各项目成本预算支出时间计划，以及每个时间点对应的累计预算成本，制定出项目成本预算与计划。

• 控制成本

资源管理

项目需要谁来做

这个章节只谈研发过程中需要的人力资源。

• 规划资源

  • 确定团队所需角色。参考研发团队成员角色
  • 团队章程。参考 团队章程

• 获取资源

  • 组建团队
    • 内部挖掘
    • 招聘面试。参考招聘面试
  • 实物资源
    • 设备
    • 材料
    • 账号信息等

• 团队建设

  • 内部培训
  • 团队激励。参考团队激励

• 管理项目团队

  • 绩效考核。参考绩效考核与奖罚
  • 分享鼓励
  • 引导培养

风险管理

项目可能会出现什么问题，具体是什么问题，怎么监测并应对

风险两个部分：内部风险和外部风险，但最大最多的风险都是来自内部，来自上级的变更。

风险管理在于降低负面风险的概率，提高项目成功的可能性。

• 风险库表

  将风险记录在档，方便跟踪。

  涉及内容：

  编号、风险描述、（风险类型、影响分类、识别人、识别日期）、（优先级、生存期、生存点、影响原因分析描述）、（应对策略、负责人、开始时间、结束时间）、（跟踪频率、风险状态、关闭日期、审核人、跟踪记录）

• 风险识别

  • 如何定义风险

    风险点：架构设计中潜在的、存在问题的架构决策带来的隐患，从而影响系统的某种质量属性。

    非风险点：在一个范围内，可接受的影响某种质量属性。

    敏感点：为了实现某种特定的质量属性，一个或多个组件所具有的特性。

    权衡点：影响多个质量属性的特性，是多个质量属性的敏感点。

  • 如何识别风险

    不谈书上那些理论的了，网上查下很多。看一些当下国内常用的方法，项目是项目团队启动的整理设计的实现的，自己难发现自己存在的风险：

    • 参考识别。以前的类似项目经验总结。
    • 内部会议识别。项目相关人员的头脑风暴会议。
    • 实名自下而上。项目相关的周报，月报，项目例会等。
    • 匿名收集。匿名意见建议收集。
    • 财务审计。
    • 专家审计。
    • 项目流程图。能比较完整的画出流程图的，做到闭环的，基本都有依据，除非不负责任。

  • 风险来源

    • 技术风险：范围、需求、设计、实现、性能、安全
    • 管理风险：估算、规划、沟通、监控、制度
    • 内部资源风险：人力资源、开发环境、项目依赖
    • 外部环境风险：客户、服务商、市场、自然风险…

• 风险评估

• 风险应对

  识别风险，进一步分析风险，给出应对风险策略规范。

  有风险，一定要上报。

  规避负面风险影响，转移第三方，或减轻影响。

  风险也有积极的影响，提高影响。

• 风险监测

  定期监测风险，人工手动，可以借助脚本工具等。

沟通管理

项目整体和谐有序，团队成员目标、行动一致

高效沟通的前提是消息对称，及双方对信息的理解一致。

• 沟通原理

  

  从沟通原理图，我们了解到沟通不畅的原因在于：

  • 保证信息传递方向正确性
  • 保证信息沟通渠道通畅
  • 保证信息包含的内容准确性
  • 减少噪音的产生

• 沟通漏斗

  心里想的100分，说出来的是90分，对方听到的是80分，对方理解后是70分，对方按60分执行。

  公司想法是100分，部门理解90分，项目团队理解80分，小组分析只剩70分，个人执行60分，甚至更低。

  • 减少消息传递层级数
  • 保证消息传递正确性
  • 保证消息传递不被阻断
  • 尽量保证消息传递及时确认反馈

• 沟通方向

  • 向上沟通
  • 同级沟通
  • 向下沟通

• 沟通工具

  • 面对面。最友好。
  • IM工具
  • 邮箱
  • 远程会议
  • 信息系统备注留言

• 减少噪音

  • 5w2h法（who、when、where、what、why、how、how much）
  • 约定沟通标准流程

• 干系人

  参考整合管理 - 干系人

  管理干系人期望。了解团队各个成员的要求与期望，了解团队对成员的要求与期望。

  考核绩效。自我考评与上级考评，双方考评相互知情，有分歧及时沟通，下属往往是吃亏不愿说的一方。

• 沟通表达

  沟通时能说人话就别打官腔。逐级汇报是控制风险，对小公司来说，效率低下就是最大的风险。要反复沟通，反复沟通，反复沟通，重要的事要说三遍，小公司团队中的问题绝大多数是由于沟通产生，也可以通过沟通解决。

  对于管理者来说，沟通表达是一项要求很高的综合素质。参考 团队7大沟通技巧 、 如何用沟通解决工作问题 、 职场团队-沟通

• 3要3不要

  • 赞美和鼓励的话要说
  • 感激和幽默的话要说
  • 与人格有关的话要说
  • 没有准备的话不要说
  • 没有依据支持不要说
  • 情绪欠佳时候不要说

• 冲突常用解决方法

  • 进度冲突：常通过合作解决问题来解决
  • 优先级冲突：妥协调解，整合意见
  • 人力资源冲突：缓和、包容，求同存异，各退一步
  • 技术观点冲突：聆听，但命令
  • 管理程序冲突：撤退回避

采购管理

项目是否需要找第三方协助完成

外包采购在互联网公司很常见，特别是中小公司，因为没有互联网的基础设施，比如需要购买服务器、云服务等

现在国内互联网平台服务资源已经很多了，不用总是去找国外的，国内阿里、腾讯、华为、百度、网易等大公司及其子公司或投资的公司都提供了免费或付费的互联网技术基础服务，从早期的网站建设到现在的深度学习人工智能服务等等，应用服务齐全。采购需要相应领域专家提供建议和意见，货比三家，结合团队和公司实际情况制定采购计划。

• 规划采购（评估）
• 实施采购
• 管理采购
• 采购确认与结束

敏捷开发

• 什么是敏捷开发

  敏捷开发方法与极限编程

  虽然敏捷开发将软件开发分成多个迭代，但是也要求，每次迭代都是一个完整的软件开发周期，必须按照软件工程的方法论，进行正规的流程管理。

  具体来说，每次迭代都必须依次完成以下五个步骤。

  • 需求分析（requirements analysis）
  • 设计（design）
  • 编码（coding）
  • 测试（testing）
  • 部署和评估（deployment / evaluation）

  每个迭代大约持续2~6周。

• 敏捷项目管理流程

• 敏捷开发原则与价值观

  敏捷开发与极限编程原则与价值观

• 其他

  • 需求分析与讲解
  • 产品立项评审、需求评审、设计技术评审、验收评审
  • 需求打分。集中讨论或打牌的方式
  • 任务分配。负责人自动领取、强制分派，主任务的人创建子任务，下一级同样适合自动领取或强制分派的方式

项目团队发展模型

• 形成

  团队间相互信任程度低，大家都保守观望，既有点兴奋期盼，又焦虑怀疑。

  • 典型特征

    有礼貌、相对客观、有所保留、防卫心理

  • 典型的疑问

    在寻找自己的目标；寻找自己的角色定位；摸索自己的具体任务；试探与其他同事的沟通与配合，是否合得来；

  • 士气

    一般，还行，高但又有所保留。

• 震荡

  随着项目的深入，团队进入了震荡期，成员间的沟通配合越来越多，相互冲突频发，权威也时常受到挑战。有挫折有愤怒有紧张有对立。

  • 典型特征

    冲突、争吵、否决、攻击，不再那么客观，开始形成圈子

  • 典型的疑问

    职责混沌，不知道如何发起配合，不知道是否可以这么做那么做

  • 士气

    低落，甚至低谷

• 规范

  经过震荡期，团队暴露出了很多问题，团队调整去伪存真，通过规范制度来约束解决问题，规范沟通，规范流程，建立互信。

  • 典型特征

    开始有组织性，团队内部有序，整体能力提升

  • 典型疑问

    接受自己的定位、职责，接受团队的规则

  • 士气

    再次提升

• 成熟

  规范后的团队，也逐步稳定产出了，产出也逐步得到认可，团队整体更团结，矛盾不在内部，而在外部了，具有集体感、责任感、归属感、荣誉感，配合默契，有积极开放的态度。

  • 典型特征

    合作、高效、无私、集体感、归属感、荣誉感、挑战

  • 典型疑问

    身心扑在了项目上了，忘了自我。

  • 士气

    高涨

• 解散

  没有不散的宴席。目标完成或项目终止或转移，团队终止。

  • 典型特征

    互相推诿，自私，低效，无成就感，无归属感

  • 典型疑问

    考虑自身成长，前景

  • 士气

    低落

工具

• excel

  资源时间进度管理

• project

  资源时间进度管理

• confluence + jira

  confluence与jira的使用

• TAPD

  创业公司使用TAPD 腾讯旗下

• pingcode

  worktile旗下

  团队敏捷协同工具

需求管理工具

• jira
• tapd
• pingcode

设计管理工具

• sketch
• Adobe
• photoshop
• 墨刀
• Axure
• MockPlus

代码管理工具

• github
• gitlab
• svn

任务流程管理工具

• jira
• tapd
• pingcode

测试用例管理工具

• wiki
• tapd
• pingcode

开源：MeterSphere

这是一份过时的清单，但有些内容是个方向引导：测试工具清单

缺陷管理工具

• jira
• tapd
• pingcode

测试工具清单

文档资源管理工具

• confluence wiki
• 语雀
• 腾讯文档
• wps文档
• 石墨
• 看云
• 幕布
• 有道云
• 印象笔记
• docsify
• hugo

持续集成与发布管理工具

• jenkins
• github
• docker
• k8

其他工具

wps：

• 文字word
• 表格excel
• 演示ppt
• pdf
• 流程图
• 脑图
• 图片设计
• 表单

表单收集：

• 金数据
• 问卷星
• 麦客
• wps

数据分析：

• 神策分析
• 数加
• 友盟
• 百度统计
• 腾讯统计

流程图、思维导图：

• processon
• xmind
• 百度脑图
• MindManager
• visio
• wps

研发约定与规范

版本管理

版本管理约定3位

例如V1.1.9

V1是重大更新版本号，需要公司高层立项确定

V1.1大更新版本号，通过项目管理流程确定，一般由项目管理人负责

V1.1.9小更新版本号，由于迭代较快，通过敏捷快速发布流程，可灵活确定及时发布。比如产品运营提出的小需求或临时工单bug

V1.1.9.20200101，有时内部需要个未发布前的测试版本号，我们可以通过带时间格式或顺序数字来表示内部测试用版本，但对外发布只要前3位，即：V1.1.9。

关于里程碑版本号：比如alpha、beta、rc、release，可以适当在里程碑版本号加上后缀。比如V1.1.9.beta

参考：软件版本号那些事

编码规范

• 前端编码规范

  参考 前端编码规范

• 后端编码规范

  参考 代码整洁之道-php版、PHP编码规范

发布规范

测试规范

• 测试用例

• 准入测试

  准入测试目的：避免开发实现与产品设计严重不符合。

  准入测试人员：测试、开发、产品、设计、运营等所有关心产品的人员。

  准入测试内容：整体流程、功能完整 、数据产生、数据展示、数据加工。

  准入测试标准：功能不缺失，整体流程通畅，没有与产品设计严重不符的实现。

  准入测试停止：测试人员先进行冒烟测试，若发现重大缺陷（1级bug超过2个）或bug过多时（2级bug超过8个），或者流程卡壳导致基本流程无法走通，测试无法正常进行，可以暂停测试返回开发。

  其中阀值根据实际情况沟通灵活快速调整。

  准入测试用例：粒度大到功能模块节点，保证产品流程走通，不卡壳比如首页、登录、发布、购买、退货、分享、通知主要流程模块。

• 多轮测试

• 准出标准

• 产品验收

• 线上跟踪

竞品分析

团队分享与培训

跨部门

• 技术委员会

  目的：利用公司内各方面的经验、资源来提高公司内部技术复用率、技术流动效率、方案可行性可靠性。

  技术沟通、分享与技术选型

  • 公司级别的技术方案
  • 前沿技术研发
  • 研发岗位的职称评审等
  • 公司内部技术学习与培训
  • 对外部输出技术内容

• 评审委员会

  目的：产品阶段性评审，可自由加入评审委员会

  产品、设计、测试、开发、运营商务、客服等人员参与，由一个与本项目关系不大的人员作为本次评审操作者，由他按本产品评审主持人的要求操作产品，并由所有参与人员作出评判审核。

  • 产品立项评审
  • 需求评审
  • UI/UE评审
  • 设计评审
  • 发布评审

经典理论

马斯洛需求层次理论

（来源：知示）

马斯洛需求层次简单易理解，从上图，我们通过自己的理解与想象都可以差不多明白这5个层次的需求及自己的需求层次。

• 生理需求

  这是物质生理需要，人得先生存着，这是基础，是本钱。

  缺乏物质生理保证，人就不会考虑道德、法律，脑子里只想着如何维持生命体，从而不择手段做出任何事。

• 安全需求

  社会公平、环境安全、身体健康、稳定就业、一定财产支持。

  缺乏安全的人，会恐惧、紧张焦虑、彷徨不安，视周边一切对自己都是不利的，意识里容易做出刺激性感应的行为。

• 归属与爱需求

  归属与爱需求，我们也常称为社交需求。人是社会人，是一个与周边事物有着联系，事事有联系，时时有联系，亲人、朋友、伙伴、同事，每种关系都会有一种关爱存在，我们爱他人，他人爱我们。

  叶落归根，人想要有个归属，家庭、事业单位、公司企业。

  缺乏归属的人，容易不理性无道德的寻找归属、同类、朋友。

• 尊重需求

  比如成就、荣誉、地位、晋升机会等，包括自我价值的个人感觉与他人对自己的认可与尊重。

  得不到尊重，就会强迫自己做一些让别人尊重自己的事，有理性的，有不理性的，利用暴力恐吓他人来尊重自己，努力读书就业发达，努力做生意赚更多的钱，赚更多的钱捐款让更多人尊重自己。

• 自我实现

  最高层次的需求，看到这个，有点能理解马云说他不关心钱的话了，能理解大企业家们有要投身教育、环保、救灾等利国利民的事。他们在做他们想做的事了，他们在做小时候想要做的事，马云和功夫巨星们拍电影，和王菲唱歌等，虽然个人对马云也不是很感冒，但也许马云真的就是想实现自己的这些愿望。当然普通人也可以有自我价值实现，我们也可以实现小时候的一些愿望，也可以做一些自己想做的事，只是马云能做到的愿望比我们多，比我们大。有人的自我实现只是想要让更多人尊重他，是尊重需求也是自我实现。

  梳理自己的人生观，自己想要什么样的人生，对人生的态度是什么样的，人生的路自己要怎么做。

  缺乏自我实现的人，觉得自己的生活被空虚感、无意义感推动着，想要在这个世界上留下自己的浓厚的一笔。

• 参考

  如何看待马斯洛需求层次理论

  马斯洛需求层次理论模型

  以心理学最近三四十年的进展看，马斯洛的需求层次理论还有实用价值吗

  马斯洛需求在生活、学习、工作中运用

赫兹伯格的双因素理论

• 双因素理论

  双因素理论，又称激励保健理论。在保健因素维度的努力只能消除人的不满，但不会带来满意感，只有激励因素才能给人带来满意感。

  双因素：内在激励因素、外在保健因素

  满意的反义词不是不满意，而是没有满意。

  不满意的反义词也不是满意，而是没有不满意。

  在满意与不满意之间，有没有满意、没有不满意两个过渡状态。

  内在激励因素	外在保健因素
  工作本身	公正性原则
  成就	工资
  成长	福利
  认可	补贴
  责任	人际关系
  晋升	工作条件
  地位	工作环境
  奖金	工作稳定性

• 工作中双因素对比

  

  （来源：管理学原理）

  通过这张图我们发现高频率导致不满意的因素大多是保健因素：

  • 公司政策和行政管理。朝令夕改最容易令人不满意。
  • 监管。默默地监管还过得去，赤裸裸的告诉你在监管你，会让人心生不满。
  • 与上级的关系。有些人因为上级的原因留下，但更多人因为上级关系缘故离去。
  • 工作环境。人都有一个舒适区，不论是心里还是身体的。
  • 薪酬。薪酬是个典型，给多了就满意，不给多没有满意，相对给少不满意，给少更不满意。
  • 与同事关系。和谐，愿意和同事并肩通行。不和谐，每天抬头见，看了心里不舒服。
  • 个人生活。属于场外因素，负面的生活情绪影响到了工作。
  • 地位。大多人对自己都有较高的期待，总会幻想自己无用武之地，地位不足容易产生不满。
  • 安全感。落后就会挨打挨骂，没有安全感，难以产生满意。

  而促进满意的因素大多是内在激励因素：

  • 成就。团队令人有成就感，有荣誉感，进而提升责任感。
  • 认可。认可也是一种成就。
  • 工作内容。能者多劳，承担更多，得到认可。
  • 责任。责任与权利成正比，承受多大责任，享受多大权利。
  • 进步、成长。人天生向上，成长是自己对自己的认可，能得到别人的认可。

• 管理中运用

  实际运用双因素激励理论的一个窍门就是先解决保健因素，再考虑激励因素，即先让员工没有不满意的地方，然后再推出可以令其满意的地方。

  要注意，激励手段难以让不满意的因素消失或逐渐减弱，要找到不满意的地方，去消除或减弱不满意的地方。

• 参考

  • 双因素在人事管理中的运用

  • 通俗理解双因素理论

麦格雷戈的X理论与Y理论&大内的Z理论

• X理论

  关键词：金钱激励、惩罚

  X理论认为人的本性是坏的，逃避工作厌恶工作的，因此必须用强制监督的方法进行威胁，才能让他们付出努力去认真工作。

  从管理者的角度，管理者认为下属们：不喜欢工作、逃避责任、活力有限创造力不足。

  X理论管理者认为：企业管理的唯一激励方法，就是以金钱奖励来激励生产，只要增加金钱奖励，便能取得更高的产量。这种理论特别重视满足员工的生理与安全需求，同时也很重视惩罚，认为惩罚是最有效的管理方式。

• Y理论

  关键词：团队目标、个人需求

  Y理论认为人并不是懒惰的，他们对工作的喜欢与讨厌是由工作能否带来满足感决定的，且更愿意承担责任，热衷于发挥创造性与才能。

  从管理者的角度，管理者认为下属们：工作和生活一样有乐趣、用于承担责任、有活力、富有创造力。

  Y理论管理者认为：能使员工在努力实现团队目标的同时, 也实现个人目标，满足个人需求。所以安排具有吸引力和富有意义的任务，充分发挥个人能力，满足一定程度的自我实现，才能有效实现团队的目标。Y理论讲究双赢。

• Z理论

  Z理论参考了X理论与Y理论。

  Z理论强调管理中的文化特性，主要由信任、微妙性和亲密性所组成。

  信任，对成员的认可，满足其尊重需求，激励其认真对待工作。

  微妙性，深入了解成员的不同个性、特长与细节，分配合适的工作，组成合适的搭档团队。

  亲密性。提倡建立一种亲密和谐的伙伴关系。

  Z理论具有东方国家的含蓄。

• 管理中运用

  一切从实际出发，全面、联系、发展的运用XYZ理论，在团队中实施合适的管理方法。

  有些简单、单调、重复的任务，可以考虑X理论，通过金钱奖励来促进生产的顺利进行，可以找那些当下更看重金钱的成员，也可以周期性安排其他成员参与这些具有奖励性质的工作。

  而对于富有创意、挑战性的工作任务，在满足参与该项工作成员的个人挑战与成长、认可与尊重需求下，认真靠谱的完成工作任务。特别是这些有组织、领头、管理能力的技术人才，如果单纯只用金钱奖励，长此以往，容易心寒沦为雇佣兵，缺乏责任感、归属感。成就是他们最大的奖励，当然金钱奖励要适当有。

• 参考

  管理学中的XYZ理论

弗洛姆的期望理论

期望理论认为，个体完成各种任务的动机是由他对这一任务成功可能性的期待及对这一任务所赋予的价值决定的。个体自认为达到目标的可能性越大，从这一目标中获取的激励值就越大，个体完成这一任务的动机也越强。

• 模型

  期望理论可以归纳为一个模型公式：

  动力值 = 结果价值 x 成功概率
  
  或
  
  期望效用 = 结果效用 x 发生概率
  

• 目的

  追求效用最大化

• 范例

  创业开早餐店，我们想通过卖早餐挣钱的想法有多大，取决于：

  • 1、我们对钱的兴趣有多大，也就是钱可以满足我们多大的需求价值；
  • 2、我们对卖早餐能挣到钱的信心有多大，我们对在当前环境下卖早餐能挣到钱的信心有多大，也就是我们认为当下卖早餐赚到钱的发生概率有多大。

  想买个手机，用上iPhone 12手机可以为我们带来的快乐是90分（满分100），以3000的薪资努力赚钱，3个月内买到iPhone12的可能性是10%，那买iPhone12对于我们的的动力是90 * 10% = 9；而用上小米10青春版可以为我们带来的满足和快乐是70分，以3000的薪资努力赚钱，3个月内买到小米10青春版的可能性是60%，那买小米10青春版对于我们的动力就是 70 * 60% = 42；很明显，根据效用最大化假设，我们会更多的考虑小米10青春版。

  让一个设计人员分配每周设计一个页面模板，遇到节假日按节假日出几张营销图，这份任务一开始富有挑战创意，后面做多了，显得单调重复，给设计人员带来的成长、挑战、奖励都在下降，而页面模板和营销图片已经不再是产品的高亮点时，结果价值趋近于0，由于不复杂容易完成，概率高，但总体动力值不高。

  让一个研发人员解决一个性能提升问题，由于项目都有自己的实际情况，这是一个具有特殊性富有挑战的任务，提升性能可以为公司明显降低成本，提高效率，具有成就感、成长性的任务，个人认为结果价值高，成功概率取决于个人能力与经验，如果是刚毕业不到3年，可能解决不了，概率基本为0，动力值可想而知；如果有一定项目优化经验，具备较高的技术能力，成功概率就高些，动力值也就高；如果让一个系统架构师来优化解决一个小问题，有点杀鸡用牛刀，对架构师来说，虽然一个性能优化，即使再小对公司都是很重要的，但相对于架构师来说，结果价值不高于其他架构调优、管理等带来的结果价值，综合下来动力值不高。

麦克利兰的成就动机理论

成就动机理论，和马斯洛需求层次理论有些相似的地方。

成就动力理论提出了个人在工作情景中的三种动机理论：

• 成就需要

  成就需要表现为追求某种能表现事业成就的目标，这种就是成就动机。

  个人在做事时与自己所持有的良好或优秀标准相竞争的冲动或欲望。

• 亲和需要

  亲和需要通常表现为希望建立友好亲密的人际关系，寻求被他人的喜爱和接纳。亲和需要较高的人，会以自己作为集体的一员而感到满足，倾向于与人交往，追求人与人之间的友谊和信赖，喜欢合作而不是竞争，希望彼此沟通理解。这在马斯洛需求层次中的归属与爱需求很相似。

• 权力/影响力需要

  控制或影响他人，而不被他人控制的需要。

  人往高处走，追求支配他人的权利，追求社会地位荣誉感，追求对别人的影响，要求或喜欢别人的行动符合自己的期望。他们工作出色，往往更多的是因为可以获得社会地位和得到他人的尊重，其次才是个人成就的满足感。与马斯洛需求中的尊重需求、自我实现相似。

• 管理运用

  在生涯初期的人，更多需要的是成就需要驱动人进步，而成熟后，有领导能力的个人更需要影响力来影响他人完成工作。成就需要强的人更多的是考虑当下个人如何做好；影响力需要强的人，会优先考虑谁适合完成这项工作。

  时代发展至今，结合东方国家温婉含蓄的人性，影响力需要强的人更适合作为管理者，也同样需要亲和需要强，管理不是冷冰冰的，管理是有人情味的，但通常影响力需要是建立在个人前期的成就需要基础上，学而优则仕。

• 素质冰山模型

  

  素质冰山模型把人的素质描绘成一座冰山，这座冰山分为水面之上的和水面之下两个部分。水上的部分是表象特征，指的是人的知识和技能，通常容易被感知和测量。水下的部分是潜在特征，主要指的是社会角色、自我认知、潜在特质、动机等，这部分特征越到下面越不容易被挖掘与感知。

  成就动机理论中指出，预测绩效的最好因素不是诸如学历、技能等外在条件，而是人的深层素质，也就是水下的冰山部分。

  这个比喻看似浅显，却蕴含着巨大的理论价值和实践价值，它揭示出影响个人绩效的最主要的素质并非是我们传统认为的工具类的硬件素质。

  成就动机理论提出的胜任素质的概念，对人力资源管理产生了极为重大的影响，它涉及到人力资源管理的各个方面，分别为工作分析、人员招聘、人员考核、人员培训以及人员激励提供了可操作的方法。

亚当斯的公平理论

美国行为科学家亚当斯提出公平理论，又叫社会比较理论。

公平理论的的基本观点是：当一个人做出了成绩并取得了报酬以后，他不仅关心自己所得报酬的绝对量，而且关心自己所得报酬的相对量。因此，他要进行种种比较来确定自己所获报酬是否合理，比较的结果将直接影响今后工作的积极性。

职场上，大部分人在消极或低谷的时候，会发出这样的玩笑疑问：公司不提高工资待遇，我凭什么好好的多干活？有些公司老板也经常发出：你不好好工作多干活，我怎么给高工资？这双方陷入困境。

这就涉及到了公平理论，也就是社会比较理论，人总会把自己的报酬与付出比与他人的进行比较；或者拿自己当下的报酬与付出比与自己过去相比较。当然人也往往对自己的付出评估过高，对自己报酬评估有过低，导致主观不公平的现象。

• 管理者对成员的评估激励尽量客观公平，即使有主观判断，也允许讨论调整，避免消息不对称导致的不公平。
• 管理者应该有一定评估标准，树立典型，传达团队内付出价值比，引导树立正确的公平观。

参考

• 欧姆社项目管理注释小结-9ong

• T型人才

  T型人才是指按知识结构区分出来的一种新型人才类型。用字母“T”来表示他们的知识结构特点。“—”表示有广博的知识面，“|”表示知识的深度。两者的结合，既有较深的专业知识，又有广博的知识面，这类集深与博于一身的人才。

• 怎样判断自己是九型人格中的哪一种？