金刚小书童

这篇是需求变更三步曲中的最后一篇，和各位分享项目流程执行不到位引起的需求变更和应对方法。1. 产品评审会，开成产品介绍会产品评审会，是对产品原型的评审；如果是采用用户故事，产品评审会更像是用户故事和故事地图讨论会。我们程序员写代码都清楚，不管我们多认真，自己验证再好，功能开发出来，测试都会测出很多问题，这个是必然的。所以，产品经理，不管再有经验，设计出来的产品原型，也一定是有很多遗落的、关系错误的、步骤缺失的、逻辑有问题的地方，所以产品评审会是必不可少的。而产品评审会没有做，或者没...

上篇分享了老板经常加需求改需求的四种情况和应对方法，这篇分享产品经理经常改需求、加需求的情况。产品经理经常加需求、改需求，主要有四种因素决定：1）老板的瞎指挥；2）产品经理本身的能力不足；3）程序员的能力不足；4）项目流程不合理和管理方法存在缺陷。这些因素要分开来分析，不同因素引起的问题要用不同的方法来解决，不能一概而论说产品经理经常改需求、加需求是产品经理的问题。这部分我们分成两篇文章来分享，这篇分析“人”的能力不足而引起的经常改需求、加需求的情况，...

项目中，确保开发进度的技巧有很多，我挑几个比较常用的技巧和大家分享。一、 随意的跟进项目进行过程中，项目经理、产品经理，可以随意得和工程师聊天，来了解情况，把控进度。比如在工作很累的时候，或去倒水的时候，很随意的找工程师聊两分钟，以关心、帮忙的角度出发。这样项目经理就能实时的发现问题，有需要沟通的地方，马上把事情处理掉，节省工程师的时间。产品经理也可以采用这种方法，看下工...

在公司经营不善，或者运营KPI不达标的时候，我们经常会听到运营团队说：“不是我们运营能力不行，是这个产品做的太烂，技术人员能力太差，做了这么个鬼东西，你让我们怎么运营，这神仙过来都没得救。” 事实真的是这样的吗？又为什么会出现这种情况呢？ 我们通常会认为研发阶段是工程师写代码的时候，实际上这个理解是有偏差，项目组做为团队运作，每个阶段各个业务模块都有事情要做。...

一、按“主次”划分：产品经理在整理需求的时候，先整理主要业务，再整理辅助业务，就适合用这种方法。一个迭代周期在两到三周，如果主要业务在三周内能完成，那第一个迭代时间就出来了，主要业务是多少天，迭代1就是多少天，不要强求一定要二周或者三周。如果主要业务要超过三周，那就要对主要业务做拆分，把一部分功能放到迭代2中，但要保证迭代1的业务流程要能跑通。迭代2比较简...

今天我们先来探讨一个比较好玩的问题，高级工程师和中级工程师的工作量一样多吗？我们普通认为，高级工程师的能力比中级强，拿的工资比中级多，工作量一定是比中级多。所以经常会见在一些企业中，越厉害的工程师，越是被当作牛使，难的他要做，别人不会做的，他要做，找不到人做的，他要做。而且还认为这是理所当然的，因为你拿的工资高啊。实际上，他们的工作量一样多才是正确的，每个人...

我们来看一个话题，运营多年的项目，工程师提重构，怎么处理？这是跨不过去的问题，只要项目运营一两年，或者是中途接手的项目，大部分工程师都会有一堆的吐槽，总会有人找你诉苦：“老大，这个项目得重构，不重构真不行。”。反正给你的感觉，不重构项目就做不下去。实际上真有这些问题吗？工程师说的是真的，就是有这么多的问题，但是真的要重构吗？不一定。这里有个原则：一、主业务的性能得不到满...

错误的竞品分析有一次我看见一个朋友圈分享，大致的意思是，说她从公司离职了，一次就删除了四十几个用来做竞品分析的同行app。搞一堆同行的app来做参考和分析，这个是行业的通性，师傅教徒弟是这样教，徒弟教徒孙也是这样教，所以你感觉不出它的问题。传统上产品经理做竞品分析有三个目的：一、抄。公司要做这类产品，我不会，就找来一堆同行的app来抄。说得有点直接，应该婉转的说是参考，这...

老板或客户只能提出想法，提不出完整的需求。没关系，你通过和他们沟通的信息，整理出产品的范围，找他们确认，他们会给你补充。他们提不出完整需求，这是肯定的，当你整理出范围，他们就有的放矢了。两三个来回，不仅范围，连细节都跟你讨论清楚。前面提到的地政系统那个项目，就是按这种方式做成功的。再说功能业务流程不清楚。这个更不是问题了，竞品那么多，随便拿两个出来分析，总能把流程分析出...

敏捷开发宣言 新时代解读敏捷开发时代背景在解读敏捷开发宣言之前，我们先来了解下敏捷开发提出来时的时代背景。敏捷开发是在九几年提出来，到2001年确定成型。在当年这个时代背景下，主流的软件研发项目有三类：一、软件企业做好系统，卖给其它企业使用，比如ERP类的系统。二、大型企业有软件需求，外包给软件企业开发。三、门户网站。这几种情况，基本上都是外包类、实施类项目。他们的共同点是，客...