提问： 目前在进行一个内部的人事系统开发的项目。因为系统功能多，业务复杂，所以在系统的开发阶段，就想把用户拉入进来一起，看系统的开发成果与需求是否有偏差，避免后期发现不一致再修改。但又担心开发阶段BUG较多，要一直对应用户的问题和提出的需求变更，会影响开发进度。遇到这种情况，应该怎么处理呢？
老邱解答
其实让用户参与一起开发是对的，这也是符合我们现在最流行的敏捷思路。虽然他们并不一定懂得项目管理，但是他们作为用户代表却最知道自己想要什么。如果项目只是在需求调研的时候有用户参与，我们也写了需求清单和需求跟踪矩阵，然后我们按阶段发布。而用户需求和市场在不断变化，若干月后你往往会发现项目的交付物并不是用户真正想要的，这才是真的可怕。
作为一名出色的项目管理者真的是要懂得诱导需求，发现用户真正想要的是什么？帮用户梳理需求和交付才是真正的关键，而这个关键点就是学会使用需求跟踪矩阵。对于用户提出的各种需求，我们需要帮助他们记录需求源、需求、交付物和交付时间。而这样做的目的就是让我们的项目团队跟用户都有对于需求的直观讨论和理解，因为我们往往会发现项目交付时间是有限的，我们没有办法交付用户所有需求。对于这些需求其实也应该有优先级的，所以我们可以把需求变成：必须要的、可以要的、可选要的、不需要的。
有了对于WBS交付物和时间的加持，我们所有人都可以一目了然的进行需求的筛选和讨论。因为项目交付时间是固定的，所以我们团队和用户都需要舍弃一些可能是鸡肋的需求，选择我们特别想要实现的功能，这个跟踪矩阵可以大大的帮助到我们。而接下来就是范围说明书和WBS（工作分解结构）的制作了。
所以需求跟踪矩阵的意义就是连结着需求源头和交付的汇总表格，我们建议2周交付一些功能雏形给用户去确认。当然这时候可能会有新的需求（变更）的出现，我们也要讨论他们的新需求属于必须要的、可以要的、可选要的、不需要的？如果是必须要的，那么我们可以走变更流程找CCB（变更管理委员会）进行投票流程。
很多同学可能会把变更管理想象的很复杂，其实则不然。我们在变更管理计划中确定变更委员会成员即可，规则是少数服从多数（建议奇数人员），委员会成员中可以是产品经理、发起人、客户代表、商业分析师、团队成员等等。只要设置好规则，一切都是可以很好的推进的。
当然，现在互联网人的思维并不是要把项目做的那么完美，我们必须要做的那么实用。项目进度被不断拖延没有关系，我们可以砍掉一部分需求，我们事先发布。这种叫做：MVP（Minimum Viable Product）最小可行性。我们也支持边开发边使用慢慢的去贴合用户的需求。
之前很多瀑布式项目管理方法并不是说淘汰了或者不实用，只是现在的市场不确定性实在是太大，快速发布是我们项目管理的王道。我们作为项目管理者也应该适应这个思维和想法。或者说简单点，之前我们所有的佛系已经不存在了，内卷时代已经到来！
2024年已经到了9月份了，很多人都在抱怨2024年的项目一下子少了很多，对于项目管理也卷了很多很多，曾经很多企业大量的招人现在变成了裁员。部门人少了很多，但是要做的事情并没有少，对于项目的支持还是需要支持，卷啊，真的很卷。
我访谈了各个行业的企业家、项目经理，现在各行各业其实都面临着生存的压力和难题，每一个领域都面临着产能过剩、供大于需的问题。之前赚钱靠信息差的时代已经过去，现在一切都是透明的，一切都是需要竞争的。而广大用户消费低迷的情况一年比一年严重，不敢消费、不愿消费的现象却越来越严重。
互联网模式给我们带来了便捷，在便捷之余也给我们带来了很多产业毁灭性的打击。当然，时代在不断的演变和进步，我们改变不了很多很多，那么我们必须逼着自己去适应这些转变。因为，如果你不适应，那就意味着被淘汰。
我写的这些都是现实，他们存在于我们的工作，这些事情也发生在我们身边。一直有人问我，什么时候会好起来跟之前一样？工作很好找，大家全世界买买买，大家挤破头为了房票去买房，投资金融界疯狂投项目。
。。。。。。。。。呜
我真不知道~
我知道的是，今年所有行业都很难，所有职场都很难，打工人更难。
我知道的是，人类发展过程中创新永远是需要的，我们永远不能保持不变和原地踏步。不确定性也会带来大量的商业机会，项目的本质就是价值驱动，项目管理的方法永远是实用的。
记得今天给大家的分享：需求跟踪矩阵!