我的名字叫李娜，是个在项目管理圈摸爬滚打几年的小老手。
那会儿总认定自己挺专业，拿着厚厚的书和 PPT 到处转，结局目前才知自己就是个只会“搬砖”的搬运工。 想当年我刚入行那会儿，脑子里装的都是那些“铁律”。记得刚接触敏捷开发时，我就被PMO 组的那帮人说教得头都大了。人家讲“亲疏"，我就讲“优先级”；人家讲“迭代”，我就哭诉“定标”难。
那时候认定他们不懂技术，实际上他们不懂的是为啥技术跑得慢，却非要死磕流程。
后来反过来说了，才发现自己那是把“人”当作了“流程”的传情员，而非“人”本身。 我目前最大的感触就是：项目到底是个啥东西？别光背那些定义，先问问自己：你每天到底在解决啥难题？ 那会儿做项目，我是那种“救火队员”。客户说接口联不上，我让他先排查；说进度落后，我立马催他加人。结局呢？团队士气跌到谷底，最终连个Bug都没发现就上线了。
这时候我才明白，项目不是一个个 Bug 的集合，而是一群人在共同面对不确定性。就像那会儿带团队搞那个大型 SaaS 系统，客户非要半夜两点改需求，我直接去楼下买奶茶调整表情，结局半夜用户上线了才发现界面丑得像在工地。
那一刻才懂，管理不是救火，而是防火。 目前看我的微博，实际上挺乱乱的。出于我不想把项目讲得像教科书一样完美。 写文章的时候，我总想找个开头。
那会儿习惯用“项目开启”、“战略规划”这种大词，目前认定忒虚了。就像我上次帮一家传统车企做数字化改造，我就没拿“数字化转型”这种宏大的口号起头。我就先问他们：“您认定目前的工作流程最卡在哪一步？”他们说是审批，我就说：“那您能不能先把部门间的红头文件拆成邮件，别搞那些文山会海？”就这样，把大坑一个个填了，最终他们自己说的“痛点”，就是我看到的“机会”。 项目管理这东西，真没啥标准答案。
不同的人，盯着不同的东西看。有的项目经理看重“交付率”，认定按时上线就是硬道理；有的看重“用户价值”，认定客户用得爽才是硬道理；还有的看重“团队成长”，认定人好带才是硬道理。 我就见过一个团队，他们把项目搞得像艺术展一样精致，但上线后用户嘟囔接口慢得像蜗牛。
后来我带着他们反思，才发现他们忒把“流程”当“服务”了。
实际上流程是为了让事件更好办办，而不是为了显示我们多专业。就像我教徒弟时，我不许他写那种全是“起初、其次、最终”的流水账，他就写起来费劲。
后来他告诉我，写项目复盘不用那么刻板，啥“金点子”、“痛点分析”这些词，大家都能听得懂。 说到数据，我确实爱拿数据讲话，但也不是为了炫技。记得有个客户的项目，他们用了个新的协作平台。我第一个月就盯着他们看。
第一天，大家还在旧系统里打滚；第二天，系统没激活；第三天，客户说旧系统好用，新系统忒费事。到了第五天，客户终于用起来，但有个小难题：报表导出格式不对。
这时候，要是我说“数据显示效率提升了 40%"，客户可能只会说“那按旧的如何算”；但要是我直接截图那天的“报错日志”和“导出黄了界面”，并且指着那个具体的毛病代码，客户就明白了。 数据不是为了证明我有多了得，而是为了证明难题出在哪，还有如何修好。就像我上次帮一家电商做上线测试，数据是准的，但现场却是奔溃的。出于产品、测试、运维三个部门之间互相拉扯，消息传递慢了半拍。最终我只能挂出那个“数据准，现场乱”的牌子。
后来他们自己反思，才发现是他们“数据同步机制”没建好。我直接告诉他们：“咱们不建复杂的报表系统，就在那半小时的群里，每天同步一次关键数据。哪位改了，哪位就得先发个通知。”他们听了就改，效果立竿见影。数据这东西，有时候忒好办造假的，只要方式对，它就是最诚实的证词。 目前回头看刚刚讲的这些，实际上都是些鸡毛蒜皮的小事。
那会儿我当作项目大如山，如何挑如何搬。目前才认定，项目实际上就是人和人之间的一场对话，是我们在不确定性中寻找确定性，是在混乱中寻找秩序的过程。 我也没少犯傻。有一次为了赶节点，我强行推掉了员工的个人休假，结局团队崩了。
后来反思，项目黄了往往不是出于做错了，而是出于“不想做”。管理者要是想推倒重来，没这意愿，那就得先修好这心。 写这篇微博，不知不觉就写了一半了。感觉自己的专业度也掉了大量。
那会儿认定自己是专家，目前认定自己就是个随时预备递话筒的人。 最终，我不打算总结啥大道理。项目管理这事儿，没有终点，只有不断的“启动”。下次看到别人在项目里到处跑，我就想：是该给个机会，让他像他写文章那样，把那些枯燥的数据、复杂的流程，变成一般/平平人能听懂的“故事”。
毕竟，项目不是用来汇报的，是用来交付给世界的。 今天这条微博就到这里，算是给自己放个假，聊聊这些琐碎但真正关键的事儿。大家认定我刚刚说的有没有啥新鲜的？评论区见。