背景：公司接到一个亿级的项目，软件大概占到1/4的比例，整个项目包含了硬件和软件团队。软件团队是要实是一个软件产品，让其控制各种硬件设备做自动化运作，并打通上下游系统的数据。软件同时统计分析（包括机器学习和AI) 整个项目设备的运作和任务执行情况，服务于后续运营优化。
项目成员结构：
大项目经理，对这个项目负责。对于在项目中要做的事情，可以和普通项目经理一样，只是维度会更高一级，可以理解成PMO
硬件团队经理负责机械设备安装调试
软件团队经理，对软件功能，进度和人员安排负责
软件团队Leader（偏技术），对软件功能需求和技术实施负责，也负责和硬件集成测试调试
一开始，现场只有2~4名软件人员，大家对自己需要负责的模块非常清楚，目标非常明确，可以说是斗志昂扬，有问题就上手找原因和方案。每天都主动加班，基本每天都自觉上班10个小时，没有怨言，出现了高效敏捷团队的迹象。现场没有Leader，只有项目经理（产品经理）。
项目进入的中期，越来越多的软件成员加入到项目中，每个人分工开始细化。但是，项目的问题愈来愈多，而且效率越来越低，并没有想象中的人员增加，加速整个项目的效果，发生了什么事情？
软件团队的Leader不在现场，而是一个远程国外的Leader，偶尔来现场，凝聚力可想而知。因为缺少对现场情况的把控，加上自己Lead这样一个团队的意愿不高，导致工作分配和进度没有把控住。所以就出现了大家只关注自己的问题，和自己没有关系的坚决不碰，因为大家都觉得自己只是一个工程师，这些协调的事情应该等待Leader来统筹。而对于进度，自己做完的任务，反正没人跟踪，“滑水”在所难免。但凡有积极性的人主动领活，下次再有未认领的任务，项目经理只能出面直接分给积极性高的。这个人因为接触过这个模块，所以以后这个模块的任务就会更多得给他。后果就是越积极的人，最后工作越多。后面大家学精了，什么事情躺平就是，千万不要积极，等着派活就好。派多了也不要积极去做，做得越快，新活就会流到他的手上。人性的懒惰表露无疑，难道这是大家的错？
这样的项目，很难想象它能有效率。其中的项目管理也没有任何日程安排，基本都是今天什么问题，明天解决什么问题，完全没有长期的规划，团队成员之间，也不知道自己往什么地方走，只能走一步算一步。而派活的事情，没有远程Leader，也没有指定现场的Leader，技术团队也是分割出明确的地盘，跨领域的问题，爱找谁找谁。
针对这种，对整个团队调整如下：
1. 远程Leader砍掉，在现场找一个Leader，这个Leader需要有影响力，需要懂软件开发流程和能够评估工作量，需要对业务有所了解。
2. Leader不要做开发，对于收到的问题或变更，找到对应可以做的人，评估方案和预估工作量，并对进度做安排和跟踪
3. 每天上午和下午例会15分钟。这个时间绝不能超，如果内容拖拉大家会因此产生反感，心不在焉，效果急剧下降。可以把详细内容放到会后单独找对应人员了解和安排。如果任务遇到问题，临时找不到方法，pass，会后再详细了解，并指定应对方案，是加多时间，还是修改方案，还是另外加人。
4. 对于新功能，一定要找到产品经理或客户了解需求，必要的时候叫上开发人员一起了解。对于优先级比较低的问题或功能，可以放到一个池子里，等后续有多余人力再做。
5. 每个人的任务，工作量，难度系数，完成及时性，bug紧急性，修复情况，bug造成的影响等信息需要量化，后续提供给实施人员直线经理用于KPI考评参考
以上调整的特点是增加的量化考评机制，以结果为导向，透明公平。当然，如果不想把整个团队弄得怎么“卷”，我们也可以不全部透明公开这些数据，而只是告诉大家有对应的考评机制。对于优秀的项目成员，会给与本项目经理特意颁发的感谢奖状。
以上方法实施的时候，也要考虑平衡，人不是机器，也需要融入一些情感。比如有些人抢活不敢太积极，比较内向，有些人”吃像“比较难看。作为项目经理，需要适当派活给那些抢活不积极，但是效率还可以的人员，也应该定期听取成员的意见，看他们做某些模块的意愿，对于需要帮助的成员，也要定期找其他成员做培训和指导（这些指导也应该要记录到任务里，算KPI）。
软件项目管理的方法理论非常多，但是无非都是权衡预算进度和质量, 以目标为导向。还是要在工作中不断使用和调整，根据实际情况把各方法融会贯通，结合使用，甚至和跨领域的知识结合。这里强调的是，人永远应该是项目首要关注的，人心涣散，项目就很难管了。整个项目运作过程中，一定要考虑每个成员的感受，如果可以，还要考虑他们每个人的发展。在同一个项目，就是“一家人”，而不能真的把他们当成资源看待，耗尽了事。对于公司，对于你的人际和个人心历都是很大的损失。如果考虑到每个成员的成功，项目一般很难失败，即使项目失败，你也将收获满满。
欢迎留言，向大家学习！