产品经理

产品思维——像产品经理一样思考

话说:不想做产品经理的程序猿不是好厨师,这几年随着产品经理这个岗位的火热,越来越多的程序猿、设计师、项目经理等专业人士转型去做产品经理。

做专业技术出身的人,往往会养成一种思维习惯,看问题的角度也会形成惯性,我们把这种思维习惯叫做工程师思维。
Read more

张小龙的微信

张小龙的微信产品思维(上)

第一部分 简单就是美

本文转载自虎嗅网,虎嗅根据点点网CEO许朝军的博客内容,把腾讯张小龙关于《微信背后的产品观》现场分享实录呈现给大家。这个系列共有三个部分,本文是第一部分。

Read more

scrumcn_htc_M8

顶尖产品经理有哪些特质?

在产品经理的金字塔中,占据塔尖10%的都具备下述特点中的几条,而塔尖1%的产品经理则具备以下所有品质。

视野开阔:  塔尖1%的产品经理思维不会被今天或当今市场环境中可以获取的资源所限制。他们会描绘出颠覆性的大机遇,并为抓住这些机遇而制定具体计划。

交流:  1%产品经理的提议是无法反驳或忽略的。他们会恰到好处地使用可以得到的数据,但也会利用偏好、信念以及激将法等让掌权者乖乖拿出经费、资金或其他资源并不再加以阻挠。
Read more

如何进行优先级排序

敏捷开发里边有很多地方需要多次进行优先级排序,本文将探讨其不同的应用场景,及其关系。

值得注意的一点是,敏捷开发中有无数的“自相似性”,比如估算,每年、每月乃至每天人们都在潜移默化地估计自己的任务;又如计划,也是每年每月每天都有成文或不成文的计划;而发布,也是每个故事自成单元,而又与其他的故事构成每月的交付,进而形成几个月的大版本交付……

由于这些自相似的活动颗粒度不同,一定不要认为只要做一次就可以了,也不要认为用一种方法做就可以了。要就具体活动思考这一活动的目标是什么,以及如何才能更好地达成这一目标。
Read more

估算和计划对最大化交付价值的重要性

由于我对估算和计划是在太感兴趣了,因此每当我看见有人在博客或者消息组里面宣称“估算是在浪费时间!别再做了!”我都会十分留意。有趣的是,这些针对估算和计划的争论从来都不会来自那些我们为他们开发产品或者系统的那些人,因为他们都明白估算和计划的意义(以及错误的估算和计划带来的痛苦)。

 

让我们来仔细想想那个观点。在你的人生当中,有多少件事情是你完全没用做计划的?我估计你会为婚礼做计划,为搬到另外一个城市做计划,为假期出行做计划,或者为任何你事先没有打算做计划的这类事情做计划。

 

假设你打算第一次去意大利旅行。你可能会计划去哪些城市,每个城市要呆多久,预算是多少等等。现在假设你打算第一百次要回去你长大的故乡,你也会进行计划——尽管你计划的内容是决定你不需要做任何计划。

 

计划,是一种考虑将来的行为。有时候,将来是存在着风险以及不确定因素的。在这些情况下,我们需要比对可预知的将来(如第一百次回故乡)做更多的计划。当未来是可预测的时候,我们要做的计划可能只是花费几个毫秒来决定我们并不需要做更深入的计划。

 

当然,一个软件项目远没有那么简单。

 

那么估算呢?我们真的需要估算吗?答案是肯定的。因为估算是计划的前提条件,你不可能在没用做任何估算之前就做计划,就算这些估算是非正式的或者是隐式的。当我在写这篇文章的时候,我还在飞往加州的飞机上。在登机之前,我决定去ATM机取一些现金,因为我估计在稍后我需要一些现金。然后我又估算了一下数额,大概200美金就足够了。在这个例子中,估算所花费的时间还不到一秒钟,我甚至都还没有意识到,它就已经发生了。

 

 

当一位Product Owner 说:“我希望加入这个特性,而不是那个”的时候,他其实已经在为每一项特性所需要的时间做估算了,虽然这是一种隐式的估算(或者叫做猜测好了)。当一位程序员决定在下班之前修复一个BUG,而不是开始做一个新的用户故事的时候,其实他也进行了一次隐式的估算,而他估算的是在到下班之前的这段时间里,他刚好有足够的时间完成这个BUG的修复工作。

 

 

有的团队说:“我们不会进行估算的,我们只会把所有用户故事定义成同样的大小”,但是他们却没有意识到其实他们已经是在进行估算了。在这里,他们所估算的是一个用户故事要和其他用户故事的大小相同。其实,我认为要令所有用户故事大小相同,比要估算在大小一定范围内的大小不一的用户故事更困难。
其实,尽管你没有意识到,但是在不知不觉中你已经进行估算了。那些在博客和消息组里面说估算是浪费时间的人,正是忽略了这种估算的存在。
但是,这种随意的,下意识的估算足够吗?如果团队进行正式的估算会不会更好呢?

 

也许吧,但是并不是所有情况都适用。团队只有在深入调查后需要采取不同的行动的情况下才有必要进一步深入估计,否则就应该适可而止了。当然,如果进一步的计划能够让团队作出更好的决定(对交付日期更有信心,或者更好地为功能排列优先级等等),那么就应该进一步估算及计划。

 

举个例子,我们最近在给一个网站添加对我们的敏捷估算和计划的eLearning功能的支持。我没有询问负责这个功能的程序员完成该功能所需要的时间,但是我仍然能够有一个大致的概念知道需要多久能够完成。因为我和他已经在一起工作很久了,我对他的工作效率非常清楚。进一步地追问并不会为这个项目带来任何改变。

 

 

从上述可见,估算和计划是必须的。因为它们可以(而且应该)是轻量级的。如果进一步的估算不能让你做出更好的决定,那么你目前的计划就是足够了的。

敏捷规划和估算的12条指导原则

1.让整个小组参与。

特定活动的主要职责可能会落在某个人或者某个分组身上,例如确定需求的优先级主要是产品所有者的职责。但是,在最求可能具有高价值的项目时,要让整个小组 参与进来并做出承诺。例如,我们可以在一条建议中看到这一点,这条建议就是虽然可能很明显只有1~2个特定的小组成员会处理正在估计的故事或任务,但整个 小组做出的估计才是最好的。小组成员分担的职责越多,小组可以共享的成功也就越多。

2.在不同层次上进行规划。(产品Backlog->Spring Backlog->任务->每日计划)

不要错误地认为发布计划会让迭代计划没有用,反过来也一样。发布计划、迭代计划和每日计划分别以不同的精度覆盖了不同的时间范围,而且各有其特定的用途。

3.使用不同度量单位,让对规模和持续时间的估计保持独立。(规模和工作量的关系,故事点)

让对规模和持续时间的估计保持清晰区别的最佳方法是使用不会造成混淆的独立度量单位。使用故事点来估计规模,再使用速度把规模转换到持续时间是完成这一工作的好办法。

4.用功能或者日期来体现不确定性。

没有哪个计划是必然发生的。要确定您制定的任何发布计划中都包含对不确定性的体现。如果新功能的量是固定的,就把不确定性表示为一个日期范围(“我们会在 第三季度完成”或者“我们会在7~10次迭代中完成”)。如果日期是固定的,就需要表示在要交付的确切功能上的不确定性(“我们将在12月31日完成,产 品至少会包含这些新功能,最多可能只会再包含那些新功能”)。不确定性较大的时候,就使用较大的单位(例如迭代、月,季后是季度)。

5.经常重规划。(滚动计划)

利用每次新迭代开始的时候评估当前发布的关联度。如果发布计划是根据过时的信息或现在被证实为错误的假设制定,就更新它。使用重规划的机会来保证项目总是瞄准着向公司交付最大的价值。

6.跟踪进度并沟通。

有许多利益相关者会对项目的进度很敢兴趣。通过经常发布有关小组进展的简单而易于理解的指示器来让他们了解进度。耗散图和其它让人一眼就能看明白的项目进度指示器是最好的。

7.承认学习的重要性。

由于项目既是向产品增加新能力,也是产生新的知识,所以必须更新计划来包含这些新知识。随着我们更多地了解客户的需要,会把新功能增加到项目中。随着我们更多地了解我们使用的技术或我们合作的情况,会调整对进度率的期望和希望采用的方法。

8.规划具有适当规模的功能。(故事点的粒度问题,短周期迭代)

在不久的将来(接下来几次迭代中)就要增加的功能应该分解成相对较小的用户故事–通常就是需要1~2天,最多不超过10天的事项。我们最善于估计规模处于 一个数量级内的工作。让用户故事都处于这一范围内,可以让我们在估计和规划中付出的工作量和得到的准确度达到最佳的组合。它还可以提供足够小的用户故事, 让大多数小组合一在一次迭代中完成。当然,在较长时间的项目中,使用小用户故事会很费事。为了平衡这个影响,如果您要建立的发布计划覆盖的时间范围超过了 未来的 2~3个月,也许可以编写一些更大型的故事(称为史诗)或者使用主题,来对时间更遥远的工作进行估计,从而避免过于提前把大故事分解成小故事。

9.确定功能优先级。(计划安排之基本,规模和优先级)

按照让项目总价值最高的顺序来处理功能。确定优先级时除了考虑功能的价值和成本,还要考虑它能带来的学习效果以及开发它能够减少的风险。可以在早期消除一 个显著的风险的可能性,往往就足以保证先开发某个功能的合理性。与之相似,如果开发特定的功能可以让小组获得大量有关产品或他们开发它的工作的知识,也应 该考虑尽早开发这个功能。

10.把估计和计划建立在事实上

只要有可能,就把您的估计和计划建立在现实的基础上。确实,有些时候在某些公司中会需要在没有什么事实根据的情况下对类似速度之类的事做出估计。但是,只 要有可能,就应该根据事实的测量值建立估计和计划。这同样适于一个功能完成了多少的问题。很容易知道一个功能完成了0%的时候(我们还没有开始处理它), 也相当容易知道我们已经完成了100%的时候(产品所有者的所有满意条件测试都通过了)。在这两者之间就很难度量了–这项任务完成了50%还是 60%?由于这个问题太困难,最好还是坚持您所知道的:0%或100%。

11.保留一些松弛度。(项目进度和人员缓冲)

尤其是在规划一次迭代的时候,不要规划用掉所有小组成员100%。就像公路达到100%容量的时候完全停滞一样,如果将所有人的时间都规划成满负荷工作,开发小组的进度也会减慢。

12.通过前瞻规划协调做个小组。

在涉及多个开发小组测项目中,应该通过滚动前瞻规划来协调他们的工作。通过前瞻和把特定功能分配到即将来到的特定迭代,可以规划和调节小组间的依赖。

原文:http://blog.d8in.com/posts/618.html

敏捷开发中对进度的把握

项目经理被问到最多的问题就是,“这个项目什么时候才能完成?”
被问的时候,可能项目才定下来,仅仅知道大概的功能模块,非功能性需求还模糊不清,甚至团队成员都没到位。但是上级、销售、客户急切地要知道,这个项目什么时候才能完成?
被问的时候,也可能项目已临近结束,或者说临近当初计划的交付日期。然而待完成的功能还有一堆,测试出来的bug有一大堆,客户又提出了新的需求,团队正有人要离职 …。但是上级、销售、客户非常急切地要知道,这个项目到底什么时候才能完成?
这还不算糟糕。更头疼的问题是:“再有三周,项目应该完成了吧?”
因为后者根本不是问题,而是命令。项目经理必须要能够合理解释为什么三周不能够完成项目;或者说明在三周内,能够完成什么。
我们都用过MS Project, 但是那上面的漂亮表格对这样的困境毫无帮助。相反,正是Project 中的甘特图和日程表,埋下了陷阱。因为,在Project 中无法预估需要多少工作日才能完成模糊不清的需求,也无法体现实际情况发生变化后对进度的影响。
当我们讨论进度的时候,其实包含了两个未知的变量。第一是完成需求所要的工作量,包括需求定义、开发内容边界;第二是团队的工作能力,包括成员的行业知识专业技能,成员之间、成员和外部的沟通能力,等等。
关键就在于,这两项都是变量。如果任务是搬一千块砖头,每分钟每人能搬10块,那么结果是显而易见的。
在敏捷开发中,采用相对估算和迭代求精的方法来处理项目进度的问题。
首先是工作量。用估算代码行数或者界面元素的方式,就像论斤卖书一样,只适用于粗制滥造的软件生产过程。用户需要的并不是代码或者按钮,而是可靠易用的功能。
在敏捷方式中,先由用户和设计人员粗略估计各个功能模块的相对规模和难度,给出一定的分值。分值不代表具体人月,起相对比较的作用。例如有查询、显示、修改三个模块,如果实现显示模块的工作量是10分,那么查询模块可能是15分,而修改为20分。
下一步,选择一个工作量估分最低的模块,例如这里是显示模块,然后进一步考量其工作量。例如要准备数据库、设计界面、执行查询,显示内容等等。假设这轮估算得出此模块需要10人天,从而得出单位分值对应的人天为1;那么,整个项目就需要45人天。
这个估算建立在对项目的初步了解上,主要依赖项目经理的经验。有偏差?没关系。接下来通过迭代来求精。先来实现显示模块,如果事实上花费了12人天,那么根据比例关系,剩余内容的估算大约就是42人天。
当然,比例关系也不是一成不变的。随着模块的逐个完成,项目经理对项目的认识也在加深,他可以再调整剩余模块的相对分值。
在实际操作中,项目经理首先按照优先级排列功能模块。然后把高优先级的模块尽可能地细分,再选择分值最小的模块开始开发。统计总工作量时,按比 例累加其他模块的工作量,并加一定的调整系数,因为模块的复杂度不是线性增长的。每次迭代开发完成后,逐步降低调整系数。通常4~5次迭代后,可以将调整 系数归零。
在上面的例子中,第一次估算的初步结果是45人天,因为完全是凭经验,因此要给较大的调整系数,比如说0.4,因此给出的估算工作量区间为[45*0.6,45*1.4],即27到63人天之间。为保险起见,项目经理上报的工作量为70人天。
第二次估算,剩余内容的初步估算为42,调整系数下降为0.3,因此给出估算区间为30到50人天之间。依此类推,通过不断迭代,对剩余工作量的估算将越来越精确。
这样估算的好处在哪里?
首先,工作量变量的很大一部分因素,存在于非功能需求,例如界面的美观程度。而同 一项目的不同模块之间,非功能需求往往是一致的,相对估算法过滤了这一层复杂度。团队能力这一变量因素也是如此。当然,随着项目的进展,成员的开发能力应 该有一定的上升,但随着加班出差等因素,投入程度也可能下降,因而会相互抵消。总之在周期6个月以内的项目中,很少出现团队工作能力戏剧性变化的情形。因此相对估算也过滤了这个复杂度。
其次,迭代求精的方式让项目经理对估算时间更有把握。最初出现偏差是必然的,但只要团队稳定,没有大的需求变动,估算范围将迅速收缩。这比一次性报数更准确。
它的额外好处是,敏捷开发是遵循优先级的,即使对剩余时间(即低优先级模块的开发时间)的估算不十分准确,影响也不是非常大。
对比一下甘特图方式,在开发初期就要把各个模块的开发时间估算出来以统计总量,这就是瀑布开发的模式。
进度问题的另一方面,是项目经理如何了解团队以及每个开发人员的开发速度。当任务分配之后,项目经理如何做到心中有数,估算任务实际完成时间。
敏捷开发过程中,由开发人员自己来估算完成该任务所需要的时间。当然,每个人的能力不同;每个人的心态也不同,有的人保守,有的人乐观。没关系,还是靠迭代来逐步求精。
在每天的例会上,开发人员被要求对当前任务的剩余开发时间做重估。不同于Project 统计每人每天在任务中花费了多少时间,敏捷方式只关心这项任务还需要多少时间去完成,直到归零,然后再来统计实际的工作时间。
为什么?因为统计开发过程中的花费时间是毫无意义的。这和搬砖头不同,也许昨天用了8个小时没有一点进展,今天一旦想通了就事半功倍。我们真正关心的,就是到底还需要多少时间来完成任务,而不是已经花费掉不可恢复的时间成本。
在每天例会中,项目经理需要注意时间曲线保持水平的成员,他是不是遇到瓶颈了,是 否需求帮助?也要留意时间曲线下降幅度过大的成员,他发现了什么好的办法,有没有低估需求?这样,项目经理会更面向结果,只要按计划保证质量完成任务就 行,成员到底花了多少时间是个人的事。传统做法记录每个人每天的工作内容,第一是因繁琐而失真。其次,一旦上级发现某人工作时间不够(即便他完成了任 务),忍不住会派新任务,从而造成越干活越多,反过来打击程序员的积极性。
敏捷估算的关键之处,是把成员能力这个变量的估算,交给最合适的人去做,即程序员本人。然后通过比较历次迭代时的预估和实际时间,给出校正系 数,以避免程序员过于保守或过于乐观。这肯定不是绝对准确的,但效果往往比项目经理自己拍脑袋估算,然后强行指定deadline 要好得多。
在敏捷开发中,做计划比计划本身更重要。项目经理需要时刻向前考虑,考虑各种动态因素,而不是死报着计划本身。在进度估算的时候,项目经理应该在不同阶段,根据实际情况,给出合乎情理的回答。

 

来源:软件开发网