提问者：郭女士
提问：小企业，老板介入很深，什么事都要管，老板自己没规划还朝令夕改，一个项目在进行中，老板时不时插入其他项目，还强调优先级较高，导致管理很乱项目进度被延迟，该如何管理领导？
老邱解答
在小型企业中确实存在这样的问题，你改变不了老板事事操心的工作习惯，毕竟很多这样摸爬滚打的老板是从基层做起来的。这样子的老板是比较务实的，虽然朝令夕改但都是围绕着项目不断创新和思索如何做的更好，而不像那些企业高官只会高高在上谈理想，遇到问题去甩锅那种。我一直更看好这类型的小型企业，虽然体量不大，但是在现今经济情况下面是更加的抗风险的，因为体量小。
如果你的企业是一个巨型企业，最大的问题就是内耗，以前经济好做啥都能挣钱的情况下可能这些内耗不足以影响整个企业运营，但是现在就好比拿出了一个照妖镜，这些企业也纷纷扛不住了。所谓船小好掉头，小企业就好比是一个小船，可能每个人需要身兼多职，但是这些都是为了整个企业盈利为目的去做。这里就出现了这位同学的疑惑，很多小企业老板亲历而为，很多项目的事情都会插手，朝令夕改。
首先我们要知道项目的目的是什么？项目是为了创造价值的，而不是为了做项目而去做项目。现今风云多变，未来的不确定性非常非常大，所以这一些朝令夕改确实在优化项目价值，那么对项目是有意义的。那是不是有一套什么机制去做这一类的项目呢？
对于不确定性大，项目需求多变，我们应该提倡敏捷式项目管理方法。
对于此类项目我们不建议再去写一大堆的项目文档，因为任何变更都会导致我们项目在不断更新文档，这样很浪费时间。但是没有规矩就不成方圆，项目目标写在哪里呢？我们怎么确认自己要做的事情呢？下面的东西可以帮助到你！
用户故事，userstory!
在敏捷类项目中，我们把需求站在用户视角来编写出来，为了更加方便大家一起沟通，我们可以用即时贴来贴出这些用户故事。这时候你的老板可以作为PO（产品所有者）的角度站在用户视角来提出他的需求（用户故事），有一个我们就写一个。我们可能有粗颗粒度的故事，也可能有非常细致颗粒度的故事，我们尽量需要把那些粗颗粒度的故事细化到尽可能的小。用户故事的写法：
格式：User Story通常以“作为一个<角色>，我想要<功能>，以便于<商业价值>”的格式来表达。
产品列表, Product Backlog
可以用白板也可以用其他敏捷的工具软件来体现这个产品代表列表，其目的就是让大家可视化的去了解这些用户故事的推进情况。因为用户故事很多，我们也尽可能的细化了这些故事，所以我们需要知道这些故事的优先级。那谁最了解业务呢？当然是你的这位朝令夕改的老板，他代表的就是PO！
我们可以使用莫斯科矩阵来确定这些故事的优先级。
M：Must 必须做，不做系统不能工作
S：Should 应该做，表示做了应该做的系统才能工作
C：Could 可以做，提供产品的附件价值，做了会让产品更有亮点
W：Would Not 不能做，不可以存在的功能
所以我们很清楚，我们现今需要做的就是must的用户故事了。但是这些故事并不是一样工作量，怎么办呢？这时候需要你的团队介入了！
敏捷扑克，Planning Poker
这个扑克的方法是基于德尔菲技术，大家匿名的用故事点来确定这些must要做的故事的大小。如果团队有7个成员，那么4票一致为这个故事点的最终大小。这些故事点有：1、2、3、5、8、13等等。
当故事点被确认之后，就是团队可以结对去认领我们接下来需要做的工作。而我们敏捷的冲刺也即将就要开始，当然我们规定了冲刺时间为两周，在两周内我们不能加入任何任务，哪怕是有问题我们也是继续冲刺。
老板的朝令夕改，怎么办？
作为敏捷的项目经理，我们很欢迎老板的朝令夕改，只要他提出的这些故事我们先用用户故事写下来作为记录即可。等下一次敏捷冲刺会议我们再让老板确认他这些故事的优先级和这些故事的故事点即可。
那我们的整个项目是开放透明的，我们是拥抱着变化来产出这些交付的，所以我并不担心做出没有价值的项目。
项目时间有限，做不了全部功能怎么办？
敏捷的所有用户故事本来就不需要全部做完，特别是那些Would Not 不能做的用户故事。而我们需要知道我们需要小规模发布，MVP原则（敏捷开发MVP是指在敏捷开发流程中,以最小的资源和时间制作出能够满足用户基本需求的产品,即最小可行性产品）。我们可以先推出我们项目的可交付成果，然后在上线之后我们慢慢修正和修改它，让它更符合用户需求即可。
所以，项目本就不是追求所有任务都需要做完，项目本不完美，就好比是每一个人。我们为了迎合市场需要最快速度发布我们的产品，在发布之后不断优化才是现今项目管理之道。
对于朝令夕改的老板，这并不一定是老板自身的问题，这是市场变化巨大，不确定巨大的种种问题。为了项目交付的最终价值，我们需要拥抱变化，我们也需要拥有更多的项目管理知识去武装自己。
2025年4月！