本周工作繁忙，目前正在处理的几个项目都比较棘手，其中有两个项目我还是项目经理、产品经理一肩挑，确实有些吃不消。不过的工作的过程虽然辛苦，但总是会有所得，每天问问自己，今天的自己是不是比昨天又进步了，哪怕是进步一点点心里也是快乐的。

1、没钱还总提需求的用户，如何沟通不得罪他

这个项目我是产品和项目一肩挑，而且还有一点特殊的情况，这个项目已经做了一期，一期是其他人负责的，项目已验收全部完成付款。但问题是到了二期，项目的预算迟迟不到位，而用户的需求又源源不断。

我一接手这个项目，面临的就是用户的各种吐槽，因为上一任做的太好了，所有需求都是按时、按质交付，用户满意度很高。到我接手了，客户没钱了，需求却没有少，研发没办法持续投入，结果我就成了唱黑脸的，硬顶着这些需求不做。

如何在这种情况下，既能顶住客户的压力不投入，又能不得罪用户呢？我的办法是把我和公司的态度剥离，显然这是一种策略，不是真的为了自己卖了公司。

研发不投入的策略是我和产品老大以及市场部门的老大共同的决定，如果用户非要做那些需求，那就需要用户拿出点诚意来和市场部门谈判。

得到公司的认可我就可以大胆的阻击用户需求了，阻击用户需求也不是一刀切，系统本身有问题会在第一时间解决，小的优化需求也会支持，而且不是一下子就不投入了，投入的曲线是逐渐降下来的。刚开始研发一周投入2-3天，慢慢减少到一周投入1天，这种减少是有缓冲的，让用户感觉是在逐渐退出，而不是拿了钱就走了。

在适当的时机抓住一次机会，有一次用户提了几个大需求，评估下来研发的工作量大概1个人月，这次就顶着不干了，用户找我，我就“甩锅给公司了”，装作一副自己也很着急的样子，其实我也很着急，只是研发属于资源池，我也调动不了，我也特别想做您提的需求，需求越多，对我们系统的后期发展越有利，让用户感觉完全站在用户的角度替他着想。

用户说能不能我直接找你们销售，我就建议他找甲方的项目经理，让甲方项目经理找我们市场部门协调这块的事，后来他就照我的建议办了，压力就转移到甲方项目经理头上，用户对我不会有太大怨言。

客户（甲方项目经理）也是不能得罪的，毕竟后续还要做项目，就要把这件事提前沟通，后来他找了我和用户一起沟通了这个事，发现他也确实没这个能力协调，我就建议他把这件事汇报给他的领导，让高层之间对话解决这个问题，这样压力又转移了。

就这么一步步走下来，我并没有因为扛着不做需求，让用户觉得非常不爽，为后续继续合作打下了基础。

2、项目经理有压力，研发有动力

有一个项目是省里的项目，有专职的项目经理，接近尾声了，前期这个项目需求确认的流程没有执行好，导致交付的时候留下很多隐患。明明是按照用户提的需求做的功能，但用户就是不认可，这样就只能将用户的新诉求放到遗留问题中承诺完成，这样验收才能走的下去。

上周项目经理又找我沟通需求，评估开发计划，虽然我和他私人关系不错，还是怼了回去，让他先找用户签字，签完字用户认了这个需求我们再安排研发资源，排详细的开发计划。这样项目经理就有了压力，明白研发资源不能滥用，只能再找用户详细确认需求。

让用户签字，用户也会更加谨慎，也会再仔细的看需求文档和原型设计，这样最终确认的需求与最终的交付就不会出现太大的偏差。

所以项目经理有压力，把压力传导给用户，后端的研发人员才不至于陷入频繁需求变更的陷阱，这样研发才更有成就感，也更有工作的动力。

3、听领导的还是听专家的？

领导不应该对技术管的过细，这样会限制底下人的成长，甚至让事情变得更糟。上周因为工程负责人的失误，在系统部署的时候，数据库和附件服务没有安装到正确的存储分区上，这样就会随着数量的不断增大，存储空间不足，而另外比较大的存储空间却派不上用场。

针对这个问题，我想到的第一个解决方案就是能否将两个隔离的分区虚拟到一起，这样数据增长会自动跨分区存储，我又查阅了百度，感觉方案是可行的，然后就找研发和集成专家沟通了一圈。大家的结论是一致的，目前这种场景这个方案不可行，只能将数据库和附件服务迁移到新的存储分区上。

我当然尊重技术专家的意见，我们再讨论如何进行迁移时，领导过来了问了以下这个事情，就坚持认为不需要迁移，只要把两个存储分区虚拟化到一起就行了，专家虽然反驳了半天，领导还是不听，最后也只能硬着头皮去继续研究，结果最后的结果还是不可行。因为MySQL这个版本不支持这么做，最后领导也就只能认了，结果数据库迁移的事又耽搁了好几天。

4、抽象、总结很重要

上周有一个奇葩的工作，其他产品经理收到一个任务，客户让他对产品的一个小功能写一个两千字的创新，他干不了然后找我帮忙，我虽然比较擅长包装方案，可这个功能实在太小了几句话就能说明白，还硬要写出一个创新确实有些强人所难。说的太夸张不真实，说的太简单字数又不高，还要有创新点，高度抽象，这个着实让我也犯了难。

最后还是让我发现了一个套路，那就是总结几个显得高度很高的关键词，这些关键词要加上数字，连起来给人的感觉很专业，就像政府作报告，既能提纲挈领又能抓住要点。比如：“四化一通“（电子化、智能化、可视化、移动化，端到端全生命周期贯通）；比如：“一个提升、两个抓变，三个措施”等等诸如此类的句式，一下子让你的文字显得高大上。

虽然有些为赋新词强说愁的意思，这种高度抽象总结的能力对产品经理来说还是非常重要的，不管是写方案，还是给领导汇报都是很有用的。

5、提升原型设计的速度

原型设计这件事已经很久没有亲自操刀了，有些生疏了，前一阵子看我们一个需求人员画原型，为了找一个合适的组件，东找一个，西找一个，只是找合适的组件就花了半天的时间。

Axure里有一个很重要的功能叫自定义组件库，自己可以把常用的原型组件都打包放到这个组件库里，我以前是把这个自定义的组件库分为2类的，一类是web组件，一类是APP组件，在网上看到好的组件我就把它封装放到我的库里，这样日积月累，80%以上的原型绘制，通过自己的组件库就可以解决了，不用再浪费时间找来找去。

其实这就是组件化思维，以前我写PPT一样，我不但会把各类PPT样式模板组件化，还会将实际的产品方案组件化。这样我想写一个新的方案，确定PPT的布局和样式就去样式模板库里去找，确定ppt内容就去专题方案组件库里去找，这样工作效率会提高很多。

原型软件只是工具，我们不应该把时间浪费在如何使用工具上，而应该把精力聚焦在如何通过工具设计出简洁、易用的产品上。

本文由 @奋斗De奶爸 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议