产品管理的极简主义

2022-03-09   出处: jacobian.org  作/译者:acob aka/binger

我是一个相当差的产品经理。这不是我擅长的东西,所以我没有任何可以称得上熟练的技能。事实上,我很容易被产品最重要的部分分心。我经常很幸运的和非常优秀的PM合作 — 但是有时候这不是一个好选择。

当我需要披上产品的外衣时,有一些简单的方法可以使用。这不是专家建议,只是一些技巧,来帮助我在做产品经理时不要太无用。

进行影响面分析

这个技能需要长期计划;当我需要从一堆想法中帮助一个团队做决定,决定需要在哪些想法上集中注意力时,我就用这个办法。

我这招是从 Craig Kerstiens学的,当我跟他一起在Heroku工作时。这项技能最开始他同Heroku Postgres团队合作时使用。你把潜在工作列在格子图上,映射到困难与影响。

当我做这件事的时候,是非常愉快的;我们不需要太在意困难和影响的定义;我们只是快速的把事情丢到矩阵中。
值得关注的是,那就是计划的全部了。左上方的项 — 高收益,低付出 — 显然赢了。右下角的项目 — 高付出低收益 — 显然是不该去做的。 然后你从中间选择一小部分项目,因为你想做更多的工作,这就是计划。

在使团队在短时间内同意做一系列工作的事情上,这个技能有奇效。看看Craig’s发出来的细节吧,有机会尝试一下。你不会后悔的。

难以估计的工时

在我写了一系列估时文章之后,一个问题出现了,怎样去处理庞大未知的工作呢?例如想一想将遗留的代码库融合进来:任何做过这个项目的人都知道前方一切未知。很难准确的知道需要什么任务。

在这个例子中,我用timeboxing法:选择任意长的时间—一周或者两周,经常只是看看我们到那了。在timebox的最后,我们对工作就会有更多的概念。我们可以回顾进度,然后关于如何推进做出更明确的决定。

Timeboxing非常给力,因为他从一个不同的方向去做预估。代替了“会用多久?”,timeboxing会这么问“我们两周能做什么?”

Timeboxing对那些在合理时间内无法完成的项目也非常有用。例如,考虑有大量的bug。花费所需的时间去把bug消灭为0似乎不太可能,但是每周花一天时间把bug数降下来是可行的。

Timebox在项目进度方面也是一个好办法,尽管前方有山一样的工作或者未知的坎。

在运行自动化之前写写操作手册

最后,是流程自动化。大部分软件开发者都知道自动化的诱惑:当我们看到一些手工的耗时操作时,把它转化为代码非常有诱惑力。

不幸的事实是,自动化也不总是像我们想象的一样好用:

很多同事被卡在这: 我们知道自动化过程不是我们想象的那么容易;但是我们也知道,这个过程是复杂的,易错的,乱的,甚至不如手动测试。

操作手册是这些情形的中间立场。当我看到一个过程后,我首要做的是些操作手册,而不是什么也不做或者直接去写码。操作手册是一系列执行任务的指令 — 像一份菜单。关键是要尽可能具体。如果这是某种包含代码的任务,你甚至可以包含点代码或者shell命令,看执行手册的人可以拷贝粘贴。

这离自动化的目标又近了几步 — 一致性,重复性,可靠性 — 通过付出少部分的努力。如果你后面决定自动化值得去花时间,操作手册可以作为详尽的说明来用。


声明:本文为本站编辑转载,文章版权归原作者所有。文章内容为作者个人观点,本站只提供转载参考(依行业惯例严格标明出处和作译者),目的在于传递更多专业信息,普惠测试相关从业者,开源分享,推动行业交流和进步。 如涉及作品内容、版权和其它问题,请原作者及时与本站联系(QQ:1017718740),我们将第一时间进行处理。本站拥有对此声明的最终解释权!欢迎大家通过新浪微博(@测试窝)或微信公众号(测试窝)关注我们,与我们的编辑和其他窝友交流。
156° /1562 人阅读/0 条评论 发表评论

登录 后发表评论