项目管理探索之路
项目管理探索之路（持续更新）
前言
下面所有的观点都是本人亲身经历后，反思总结出的内容，也许并不是每句话都是合理和合适的，但实践是检验真理的唯一标准，理论学的再好，不实践也等于空，本文记录的就是实践探索经验，算是项目管理反思录吧。
对于不同的项目，面对的挑战难度是不一样的，划分项目规模的标准有很多，比如合同价格、项目团队成员人数（人力成本）、系统业务复杂度以及规模等等。
其中用合同价格划分是最简单的一种，在本文，把合同价在一百万以下的项目称之为小型或中小型项目，一百万到五百万的合同价划分为中型项目，五百万以上划分为大型项目，一千万以上划分为超大项目。（当然还有总合同额上亿的项目，阿里、广联达等大厂会接到智慧城市等这样的大合同，但没有哪一个公司能单独吃的下这么大的蛋糕，实际上也没必要所有业务都自己做，基本上签下总承包合同后，会和多加单位签分包合同）
对于大型或超大项目而言，一般都是多项目管理，即一个工程分为多个项目管理，多个项目之间进行协作，最后集成到一起的过程。我们通常称管理大型项目的管理者为大项目经理。大项目经理的管理工作更多的是间接管理，而不是所有工作直接管理，原因很简单，因为一个人的精力是有限的，对于大型项目而言，通常是由多个不同的开发团队同时展开工作，系统的业务之多，干系人之复杂都和一般的小型项目是完全不同的。不可能所有事情都亲力亲为，也不可能每个环节都盯的及时。
团队沟通的必要性
通常情况下，一个团队并不是所有人都聚集在一个办公室工作，而是有几个人在客户现场，有几个人同时兼顾其他项目，有几个人在同一个项目的其他团队工作，实际的工作环境是复杂多样化的，像这样不在一个地点办公的团队有个学名，叫虚拟团队，虚拟团队中的沟通比在一个办公室中的沟通更具有挑战性，同时也更加需要沟通。
如果在同一个地点办公，那么面对面沟通是最常用，也是最有效的沟通手段，沟通成本非常低。比如每天定时开站会碰进度和问题，有问题也可以直接当面沟通。如果是虚拟团队，那么电话、文字聊天、视频会议是最常用的沟通手段，这些沟通方式理论上是没有面对面沟通高效的，所以不定期的也会遇到很多问题，比如理解容易出现偏差、感受不到对方的情绪而导致冲突发生等等。所以说虚拟团队的沟通更有挑战，需要更加注意；同时沟通也更加重要，因为只有沟通良好，才能保证工作顺利进行。
建议定期组织在一起办公，可以是一天或两天，频率可以是一周或几周不定，同时工作之外组织见面的团建活动，从而凝聚团队，减少矛盾和冲突。
高效的会议
有过几年工作经验的可能会遇到这样的会议：会议时间过长、会议没有主题或者主题经常跑偏、会议没有最终结论、会议没有重要相关人参与等，这些点我也经常吐槽，项目的协调大多是以会议的方式来进行的，举行高效的会议可以化解项目存在的诸多问题。建议按如下流程开一个会议，以形成高效会议。
- 事先制定一个例会制度；预先创建沟通模板，并进行简短的培训，让团队成员明白会议的通用规则；
- 明确会议的目的和期望结果。是彼此互通信息还是要确定一个解决方案；
- 在会议之前将会议资料发给参会人员。提前阅读，直接在会上讨论，可以有效节省会议时间；
- 发布会议通知，明确会议的时间、地点、参会人员、会议主题、目的。会议时间包括开始时间和持续时间。
- 可以借助视频设备，让异地成员参与或演示；
- 会议要有会议纪要，对会议记录进行备案，做到有据可依，也有利于督促和检查工作的完成情况。
- 会议结论必须分发到相关人员并落实执行。
- 会议必须有会议主持人（一般为会议发起人），主持人负责主持和控制会议进行，需要把握好会议时间议程情况和会议是否偏题等。
面对面会议确实是最有效的沟通手段，但不是唯一的沟通手段。使用即时通讯软件、共享文档、正式的书面文档、非正式会谈、电子邮件等，都是沟通方式，而且沟通方式单一本身也是一种问题。
选择合适的沟通方式
前面说到，沟通方式有多种，应该在不同的场景下选择合适的沟通方式，有些事情文字聊天说不清楚就应该立即打电话确认，两个人说不清楚或者无法定论，应该拉着相关负责人或者项目经理一起讨论，大家达成一致意见后再开展工作。沟通方式不应该是单一的，选择合适的沟通方式可以让工作效率事半功倍。
需求的明确与不明确
制订开发计划
制订开发计划应该提前明确任务项的负责人，一个任务项只有一个主负责人，其他人可以辅助。
开发计划应该明确几个重点保证完成的任务，不应该奢求所有任务项都保质保量完成（实际中也很难做到），尤其是在多项目并行开发的环境中。
对于优先级低的任务项，如果不影响项目重要里程碑的推进，理论上延期几日是正常的。保证计划中所有任务项都按时完成的想法是不切实际的，安排计划的主要目的是让大家明确目标和任务，方便进度跟踪，同时加快项目开发进度，并不是要严格机械的按照计划来完成任务。
也许会有人说，允许一些任务项延期，是不是意味着人员的工作更加松散和轻松了呢，这个问题如果让我回答，我会说是的，确实是这样的，这就会涉及到另外一个问题，把握度。客观来说，项目工期越短，任务越紧急，要求开发人员的工作强度越大，越疲惫；如果项目工期长，任务不紧急，那么开发人员也就没必要天天加班；两者冲突是必然的。一味的安排高强度任务项，严格按照计划要求产出物，时间长了会让开发人员身心俱疲，不仅是白天在公司非常忙，晚上回到家也什么都不想干，只想躺尸、刷手机。这是一种恶性循环，时间长了也就留不住人，离职率上升。
另外，指定开发计划，务必提前和相关人员商量，看时间是否允许，尽量避免没有商量就直接下达任务的情况，除非你对这个人的所有工作事项都非常了解。
估时不准 —》子任务项遗漏 —》 需求理解不准确
测试与开发的工作协同
测试提bug，开发改缺陷。现在很多项目都是用迭代开发模式，每次迭代都会上线若干新功能，同时对之前已上线的功能做完善和调整。
bug 修复-上线
也并不是所有的bug项都解决掉，才能上线，这是个错误的想法。
应该定期组织复盘
抓主要关键点集中突破
项目管理中有一个管理进度的图表，叫项目进度网络图，里面表明了所有主要任务的工作量、先后顺序以及开始结束时间，并且
明确每个人的职责
不要轻易与客户直接说不
不轻易与客户直接说不，这其实是情商的一种体现，在甲乙方这种特殊关系上，拒绝也是需要技巧的，甲方客户提不合理的要求，这其实是在所难免的，直接回绝不，效果反而会更差，即便是这次客户同意去掉需求，日后可能会施加更多的压力。
应该让客户经理适当的参与团队内部一些会议，比如技术决策、需求讨论等，目的是让客户了解实现需求不是那么容易的事情。如果确定要拒绝客户，很多时候可以把时间线拉得很长（两个月后提供）或者说走合同变更（加钱），让客户选择。
技术人转管理的悲哀
实际工作中，确实有不少管理人是从技术人员转型过来的，个人认为，一个技术开发人员转型项目经理要比一个测试或运维岗转型项目经理更难一些，这不是我从哪本书上看的结论，而是我多年来观察身边人的行为得出的结论。
为什么更难，主要还是开发思维与管理思维差别大，各自工作的关注点和侧重点不一样，需要主观的意识到这种差别，并且做出有效的自我调整。
为什么用悲哀这么严重的词语，还是和我的实际经历有关，有位前领导，是典型的技术开发人员转型过来的管理岗，他其实已经是一家小公司（20人）的一把手了，理论上大大小小所有的事他说了都算。他的技术能力不能算多么优秀，逻辑思维能力也还可以，但他的管理能力实在是非常一般，甚至可以说是不合格，最主要的不是我一个人这么认为，大部分接触过他，和他打过交道的都一致认为：他不是一个好的管理者。不好在哪里：
他总是很忙，喜欢在那些业务逻辑中自得其乐，喜欢和客户讨论需求是不是合理，喜欢和开发人员讨论技术实现、程序效率问题。曾经有位同事问他这样一个问题：“你现在为什么还在写代码，不应该把重点放在管理上吗？” 这个问题你猜他怎么回答，他的回答：“如果xxx 离职了，他写的代码我就看不懂了。”当时我的同事就对他大跌眼镜，后来我越来越坚定，他的管理理念是错误的。
管理岗位，80%以上的时间应该放在沟通上，而不是自己做某件具体的事情，把不确定的事情确定下来，把不稳定的因素想办法稳定下来，才是首要职责。
管理人员也需要有人带
对于管理岗的新人来说，自己应该多请教有经验的人，不要所有事独断专行，太过自信。对于公司来说，应该花心思培养和培训管理人员。
不要把开发人员盯的太死
我相信，每个人都不希望自己工作时，后面有个人频繁催活：什么时候能完成啊？现在进度怎么样了？今天上午能演示吗？上午不行的话下午能干完吗？
制定靠谱的项目计划并且按时了解进度，是对的；在重要的活动节点上集中解决问题，比如一周内必须把重要问题解决掉，否则影响后续进展，这样的场景下实行短频快的开发节奏也是对的，但这样的节奏不应该一直持续，因为在有限的时间内解决重要问题，工作强度是非常大的，加班熬夜、压力大的状态如果持续时间很长，人的心态也会变得不好，容易崩溃。
每个人的能力不同，待遇不同，承担的责任和任务也是不一样的，每个人应该制定切实可行、靠谱的开发计划，然后按照计划按部就班的开展工作，管理人员也没必要一天两三遍的和开发人员要进度，这样会让开发人员觉得没有信任感，时间久了也会反感这样的工作模式。
可以每天按时把大家叫到一起开站会，过一个每个人的进度和情况，注意时间不要太长，三五分钟说完，然后大家各自忙各自的，如果有问题再单独找，分析滞后的原因所在。
绩效考核
项目干系人的复杂度
项目的干系人复杂度越高，项目工作就越难做。
我们经历过这样一个项目，真正的甲方客户和A公司签合同，A公司把整个项目的一部分交给公司B来做，B公司再与我们一起开发，相当于我们接过来的是三手项目，如果因为自己开发平台原因限制或者需求不合理，找B公司沟通，而A公司又觉得这不是问题，那么这个沟通就很不好处理了。
所以与甲方隔着层级越多，项目工作就越难开展。最理想的状态是直面甲方，沟通成本最低。
项目管理实践
下面是敏捷迭代开发的经验：
两周一个迭代sprint （单周、双周）
每个迭代的需求和任务项在迭代前的周五进行
单周的周一开迭代总结会
单周的周一或周二提供开发计划和测试计划；
双周的周一碰进度和问题；
任务项目标：每个迭代的任务项设定优先级，优先级高的定为发版目标，优先级次之的定为开发完成目标；
bug 目标：同样每个迭代的高优先级bug 定为必须修复完成，中低优先级的bug定为下个迭代继续完善；
技术评审、代码审查、问题回顾 这几项工作不可缺少，应该定期举行，提高团队整体质量。
与上级、下级、平级沟通，应该提出建设性的要求
README
参考：
本人亲身实践
修改记录：
2022-01-01 米开 第一次修订