摘要：本文是敏捷开发产品管理系列的第七篇。（序言及设立迭代目标，产品版本规划，产品用户群规划，新产品研发，预估会议，Product Servant，Product Owner团队，产品线管理），也是敏捷开发团队管理系列（拟）中的一篇。目的在之前的《Product Servant》一篇中曾经提到，作为产品经理或产品总监，都应该有自己的方式来根据市场和用户情况来管理产品的走向，其中前者更倾向于具体的功能，而后者则更倾向于市场方向的竞争力；前者要求细节，后者要求高度。那么，这两个人到底谁是传统意义上的Product Owner呢？另一个常常被问到的问题是：“我们只有一个产品经理，而有20多个开发人员，这一 阅读全文

摘要：本文是敏捷开发产品管理系列的第六篇。（序言及设立迭代目标，产品版本规划，产品用户群规划，新产品研发，预估会议，Product Servant，Product Owner团队，产品线管理）马与马车夫的故事这是心理学上的一个比喻。马拉着车向前走，它说：控制车去哪里的是我，我走，车就走；我停，车就停；我转，车就转。马车夫笑了，他说：控制车去哪里的是我，我让车走，车就走；我让车停，车就停；我让车转，车就转。后座的客人笑了，他说：难道你不是以送客人回家为生？当我们成为Product Owner的时候，一个极其危险的旅程开始了。产品的生命周期几乎没有产品，在开始赢得市场之后，乃至如日中天后，都会走下坡路。 阅读全文

摘要：本文是敏捷开发产品管理系列的第五篇。（序言及设立迭代目标，产品版本规划，产品用户群规划，新产品研发，预估会议，Product Servant，Product Owner团队，产品线管理）粗估会议是一个较少使用的敏捷实践，但其作用还是很明显的。WhyScrum里边，有两个关于需求的比较头疼的问题。一个是PO不太懂技术，不知道故事大约需要多久才能完成。为什么PO要知道？因为如果划分的颗粒度不好，会导致有的故事太大或太小；而且如果不知道故事的大小，就比较难大致预测未来的几个迭代能做完哪些故事，版本计划不好做。二个是如果只依赖短暂的Sprint Planning Meeing，往往团队对故事的理解不够 阅读全文

摘要：本文是敏捷开发产品管理系列的第三篇。（序言及设立迭代目标，产品版本规划，产品用户群规划，新产品研发，预估会议，Product Servant，Product Owner团队，产品线管理）上周在培训做“用户故事的用户建模”练习的时候，就有人提出一个疑问：这么短的时间里边，能定义好用户群和用户群分类吗？答案是：不能。用户群的规划是产品概念期就应该完成的工作，它是一个产品管理工作，而非需求管理工作。用户群定位这里仅就自己所从事的互联网行业提出一些简单看法。这些看法与本人在做的产品密切相关，因此在别处可能会不适用，仅作参考。我们整体把用户分为人气用户和付费用户两种。这个与互联网通行的分类方法很接近，相 阅读全文

摘要：本文是敏捷开发产品管理系列的第二篇。（序言及设立迭代目标，产品版本规划，产品用户群规划，新产品研发，预估会议，Product Servant，Product Owner团队，产品线管理）本文是一篇旧文，原名为《“迭代期内无变更”与敏捷开发产品版本规划》，因符合本系列内容，做相应修改后重新编排发出。迭代期间无变更？支持派说：对，如果经常变，我们怎么开发啊。反对派说：不对，敏捷开发不能上来就确认了需求，要的就是在开发中逐步了解需求，怎么可能不变呢。只在开发层面，这个问题无解。让我们站在产品版本规划的高度来看这个问题。基于商业目标的产品版本规划下个产品版本（或下个迭代）中到底应该有什么功能？最重要的 阅读全文

摘要：本文是敏捷开发产品管理系列的第一篇。（序言及设立迭代目标，产品版本规划，产品用户群规划，新产品研发，预估会议，Product Servant，Product Owner团队，产品线管理）序言之前的“敏捷开发用户故事系列”已经提到了微观层面的需求管理问题。由于敏捷开发的提出者和实践者主要是开发团队及其领导，因此一般较少提及产品的整体规划、商业目标这些内容。本系列汇集了本人在做产品管理的时候的一些心得，以及在与不同企业交流、做互联网软件分析的时候的一些所得，与大家分享。本系列的顺序整体由微观到宏观排序，拟包括设立迭代目标，产品版本规划，新产品研发，Product Owner团队，产品线管理等话题。 阅读全文

摘要：2011-10-14：新版本已经发布，新增内容6页，增加目录及《敏捷开发用户故事》系列。此版本就是原定10.31才发布的版本，因下半月要参与一本杂志、一本书的编写，所以提前写好免得惦记。本文仅作通知，下载请访问主贴：http://blog.csdn.net/cheny_com/article/details/6616794部分页面预览： 阅读全文

摘要：本文是项目经理的商务指南系列中的第三篇。（之一：序言及项目本质，之二：认识责任，之三：认识客户，之四：认识谈判，之五：认识项目进展，之六：认识回款，之七：将项目推向不败之地）被动而弱小的客户客户常常被认为是主动的一方，可以蛮横，强硬地与乙方谈判，但事实其实不是这样。多数甲方的信息中心，尽管也签署过若干项目，但每种软件，却都只有一次机会立项；这和我们乙方能同时给多个甲方开发相同的软件比，信息不可谓不闭塞，经验不可谓不缺乏；乙方可谓知己知彼，既懂业务又懂开发还懂成本，而对方经常只知道预算（其实他们连应该预算多少都不知道）；最致命的一点是，在整个开发过程中，开发进展对甲方几乎完全不透明，令其凭空生出 阅读全文

摘要：今天参加MPD2011深圳站，听到最重要的乃是徐锋老师课上的一些内容，本来有一个很长的笔记，但是其实里边不过关是只言片语的摘抄，形成不了章句，干脆把一些重要观点摘录于此。徐锋老师是做投资的，不是顺便聊聊这个话题，对业务模式和需求收集模式的评价，是他们判断一个企业是否值得投资的重要依据，因此下面的内容是他们实际工作中真正要用得到的，所以很宝贵。1. 当尝试使用技术手段解决某个实际需求的时候，一定要注意业务圈和技术圈人群的重合性，存在需求的人，是否在使用这种技术比如：“妈妈”们肯定很关心如何育儿，以及幼儿教育，所以开一个相关网站好不好呢？结论是要如果10年前开，不好，因为那时候的妈妈差不多都是19 阅读全文