怎样才能做好软件项目管理

六六 • 2023年2月2日上午11:11 • 项目管理 • 阅读 535

做好软件项目管理主要做好以下几方面：1、清晰的需求传达；2、合理的优先级排期；3、提前策划2-3版本；4、做好项目跟进；5、做好异常情况处理等。一般来说，最容易造成开发出来的产品与设计功能不符的原因便是需求描述的问题了。

项目管理不单单是在产品开发过程中进行，在对一个项目进行管理时，开发前的需求传达，项目排期，以及开发中的跟进开发，都是非常重要的，做好以上几点，版本按时上线也就不难了。

一、清晰的需求传达

尽可能还原用户使用场景

一般来说，最容易造成开发出来的产品与设计功能不符的原因便是需求描述的问题了。其实大部分情况下，写需求文档的人没有错，看文档的人也没有错。共享文档不等于达成共识。只是因为面对同一段描述，人与人之间的理解不相同，而且这种情况是一定会发生的。所以对于需求，一定要基于团队面对面讨论，保证对需求的理解一致。

我们要清楚的告知程序猿这个新功能所针对的目标用户是谁，使用场景是什么，以及这个项目解决了用户什么需求，总结下来就是5w1h：who、when、where、what、how、why（谁，在什么时候，在哪，解决什么问题，如何解决的，为什么去解决）。

功能流程清晰

需求场景介绍完了，程序猿们对项目也有认同感了，接下来的就是功能流程介绍了。

功能流程介绍分为业务流程介绍和数据流程介绍，业务流程介绍是站在用户的角度上来展示用户是如何使用的，按照用户的操作顺序，对照流程图进行讲解。比如：小明到家后打开APP，根据自己的需要选择相应的课程类别，选择类别后出现属于该类别的课程列表，然后再选择具体的课程进行训练，训练结束后系统将生成的图片供用户分享等等。

其实需求传达属于需求评审中讲解的内容，需求评审结束后，我们就要着手准备项目优先级排期了。

二、合理的优先级排期

什么样的功能能对用户产生最大的价值，这是需求管理中最重要的问题。因为在软件开发中，你想要开发的功能，永远比你能投入的资源多。因此，找到这一部分最有价值的功能，优先处理，尽早交付，才是需求管理的核心所在。

影响优先级排期的因素非常多，比如工作量、开发难度、客户权重、竞品、团队目标支持等等，而不同的团队可能还会有其他因素。所以比较好的通用做法是，根据工作量、开发难度、客户权重、竞品、团队目标支持等等维度，以及其他个性化维度，建立一个标准化的产品优先级模型，以打分的方式数据化评估需求优先级。

但要实现这点是需要完善的需求信息的，不在信息和数据层面完全无法支撑产品优先级模型，而我们是使用产品管理 Ship 进行反馈收集和需求管理，所以在一定程度能够解决这个问题。

在优先级确定之后，时间排期和开发顺序也非常容易就能确定了。这个时候我们较好是能够通过甘特图或者其他直观方式进行排期规划和跟进。

三、提前策划2-3版本

通常是2-3个版本，因为产品的迭代是有一条循环的流水线的：需求发掘-版本规划-方案策划-方案评审-UI 设计-开发-测试-发布。一般而言，为了效率最大化，我们都会争取做到相邻的两次迭代之间能够无缝对接。也就是流水线上每一个环节的人在完成了当前版本的工作后，就能立即执行下一个版本的需求。

产品策划提前两到三个版本的好处是，当开发过程中发现有余量时，可以把后续版本中的一些小的需求提前穿插到当前版本。

为什么不提前策划更多版本？很简单，避免闭门造车、纸上谈兵或构筑空中楼阁。极端的案例是提前策划无限个版本，这样明显是有问题的。

四、做好项目跟进

项目动态我们可以用每日站立会的方法来进行，开会的内容主要是昨天都做了什么，今天要做什么，遇到或者可能会遇到哪些问题。

站立会表面听起来是开会，但是实际上我们不需要拘泥于开会的地点和形式，我们可以在每天早晨刚到公司的时候和程序猿沟通，也可以午休后在工位上进行，甚至一起上厕所的时候也可以。

或者你可以找一些使用一些流程、进度可视化的工具，以便随时随地查看和沟通，就比如 PingCode 看板：

或者是Scrum 项目中的燃尽图：

然后我们要积极的去协调，来帮助程序员解决问题。较好在程序猿开发某个模块之前与他进行需求再确认，以确保最终开发出来的东西是我们心中所想的那样。

在这个过程中，需要我们自身有主人翁意识，灵活而又勤快的去推动项目的进行。

五、做好异常情况处理

虽然做足了准备，但还是经常会有异常情况出现，可能出现的异常情况有：

（1）程序员对需求理解有偏差

在项目的开发过程中，经常会出现这个问题，但这不能怪程序猿，毕竟写的再详细的文档，不同的人看也可能会产生不同的理解，还有可能是我们的文档写的不够详细。

针对这个问题，我们应该把主要精力要放在预防上面：

在程序猿开发某一个小模块前，尤其是新出现的或者是重点模块，主动去找程序猿进行需求再确认，再和程序猿讲明需求，也可以让程序猿口述一下需求，我们来听。最终目的就是要确认程序猿已经完全理解了需求，避免后续的更改与返工。

如果在开发过程中仍然出现了对需求的理解问题，比如前端和后端对接口的理解不一，如果你此时不去协调，那么这个问题可能会被搁置，后期还是会爆发出来。还有可能是理解错误的一方将另一方说服，从而造成后期的返工和改动，这是很伤的。

当发现双方有理解上的偏差时，一定要把双方叫在一起讨论，确保前端和后端都能正确的理解需求，再进行开发。在项目开始前一定和程序猿讲明，对需求有任何分歧一定要找你，大家商议解决，而不要私下讨论。

（2）出现需求变更

需求变更，无论是产品经理还是程序猿，看到这个词都会觉得头疼。

出现需求变更的原因主要有三个：

产品经理自己没有思考全面，比如对异常情况的处理不够细腻等等。我们应该尽量避免这种情况的发生，如果总出现这个问题，说明我们的工作是有疏忽的，程序猿也会对你产生不信任感。如果因为这个原因出现了需求变更，去找程序猿大爷说明吧，回来后对自己进行充分反思，并争取在下一次做得更好。
老板要求改需求，这种情况我们看似无能为力，但实际上也是有操作空间的。对于老板的要求，我们首先要仔细的思考利弊，如果仍然觉得之前的方案好，拿出证据向老板说明。如果老板的方案更好，那么我们就要有技巧的向程序猿说明。同样可以利用讲故事的方式，向程序猿说明更改需求的原因与必要性。这时就是考验你和程序猿关系的时候了，没事的时候记得和程序猿们打好关系哦。
自己脑袋中突然灵光一闪，觉得某个功能点有更好的方案。如果是这种情况，哪怕这个方案真的好，哪怕它能提升50%的转化率，我还是建议放在下个版本进行优化，如果我们站在程序猿的角度上想：“需求是你定的，我代码都写一半了，你突然有了更好的点子，然后就让我删除自己辛辛苦苦敲出来的代码，凭什么？”

人非圣贤，谁也不能保证自己名列前茅个方案就是完美的，当有了更好的点子时，我们不妨再增加一个优化版本，反正版本上线后我们也要收集用户反馈，把这个点子放在优化版本里不是更好么？

（3）项目进度延期

当发现项目进度已经落后的时候，我们首先要分析原因，根据原因来寻找解决办法。可能的原因有以下几个：

①团队沟通不畅

如果前期做好了预防，一般是不会出现这个问题的。但真出现了这个问题怎么办呢？此时我们就需要找到沟通不畅的当事人，询问原因，是成员之间不能正确理解对方的意思呢，还是互相不认可对方的观点。

如果是沟通不畅的双方没有办法正确理解对方的意思，那此时我们要做双方的“翻译机”，确保成员之间理解统一；如果是互相不认可对方的观点，那么此时，抓上项目经理或开发主管，一起来商量谁的解决办法更好。总而言之，一定要确保团队成员对项目理解的统一，大家带着同一个目标前进。

②程序猿能力不够

之前也遇到过这种问题，程序猿小A难以完成分配给他任务，这时我们就要叫上技术的大佬，然后让程序猿小A去叙述他遇到了什么难题，让大家一起解决，解决问题的方法我们就不掺和了，做好团队之间的桥梁就好。

③程序猿因为生活上的事导致情绪低落，开发积极性低

我们都是人，是有情感的动物，难免会因为生活上的的事情影响到工作，这时候，我们要从同事的身份中脱离出来，作为朋友，带着程序猿去吃点小菜，喝掉小酒，聊聊人生，看看美女，没事再给程序猿买点零食，送点温暖。此时对待程序猿要向对待自己女朋友一样温柔，帮他从情绪低谷中走出来，重新振作开始工作，这样无论是对于团队，还是对于他自己，都是有好处的。

④对工期预估过于乐观，项目排期出现了问题

项目排期，其实也是一个预估的时间，谁也不能保证一定可以准时完成，如果是项目排期出现了问题，一般项目经理会让大家用出神技：加班！！

当然此时我们也不能眼睁睁的看着程序猿们加班，我们可以发挥自己的价值：砍！需！求！虽然心很痛，但是看着程序猿们日益稀疏的头发，还是咬咬牙把需求砍掉吧，找机会再加。

如果砍无可砍，赶紧重新评估时间并向老大报告，避免因为自己项目的延期影响到整条产品线。