项目管理者联盟 | 中国工程管理网 | 中国研发管理网 | 会员中心 | 资料库 | 论坛 | 博客 |
|
|
|
标题:如何让我们不再抱怨驱动开发?
楼主
|
|
飞眉 PMB:19763 省份:广东省 行业:IT软件 注册:2010/12/29 |
如果我去年没怎么发博客的话,是因为我们一直忙着完成我谈到过的“文明用语建设工具包(civilized discourse construction kit)”这件事。 (是的,实际上这就是公司的名字。这就是你让我来取名字的下场。弹珠机,人,有啥区别呢?我已经跟Bill Budge道歉过啦) 所以如果你像我的投资人那样,好奇为什么这个过程用了整整一年,我就应该解释一下我是怎么完成事情的,或者至少解释下我们是怎么完成Stack Overflow,Stack Exchange和现在的Discourse的: 对你所在领域中的每件事做足够详细的调研。成功的:他们现在做错了什么?失败的:他们有做对的地方吗?没有人应该比你更了解你所在领域的历史。你要有一个有道理的故事,你相信它,并且更重要的是,你能让别人相信它。 根据调研,组建一个团队并完成能做些有价值工作的最简化可实行产品(minimum viable product, MVP) 。如果你需要创始资金,是去争取的时候啦,所以我希望你很擅长第一步中的工作, 再有些名气,最好还已经很成功,否则你就完蛋了。 让你和你的团队开始没日没夜地使用最简化可实行产品。这远大于单纯的软件开发:这就是你的生活。如果你不活在你开发的软件中,每天,天天,一整天。。。事情就会不可避免地在每个参与者泪流满面中收场。说实话,如果我还要给你解释的话,你猜怎么着?你完蛋了。 开展简单的内测,从你那些“特别的网络朋友们”中收集对你已完成产品的反馈。我知道你是这样想的:朋友!该死!我早知道这些家伙迟早会派上用场!不管这些反馈有多蠢,开明地听取他们的意见。找出并修复每个出现的主要问题。你的产品会仍然很糟糕,但是会糟糕得少那么一丁点儿,你也会比不做这些工作完蛋得少那么一丁点儿。(这就是我们商务专家说的“竞争优势”。查查看。) 迅速地公开发布。这很糟糕,但不管怎样你都要交付它。不要搞砸了发布的组织工作。你知道我在说啥,因为你见过那些差的发布会。不要成为那些公司,不要成为那些团队。没关系,下一步你有的是时间堂而皇之地搞砸所有事。 嘿,记得那些依据第一步痛苦详细调研得到的好点子吗?看样子一旦你把它们放在现实中真实诚实的用户的面前,结果它们全部。。完全。。错了。接下来的一年你什么都不做,就修复你白痴般搞砸的事和愚蠢的错误吧。 ??? 利润! 我从没说过这是个开发软件的好计划,但是至少这是一个计划。 这些步骤中的每个都值得花一篇博客来说明,但是今天我只专注第六步,因为在我看来这是整个所谓“计划”中最关键的部分。我把这个阶段叫做“抱怨驱动的开发”: 尽你可能让更多的用户使用你的软件。 听取他们抱怨的所有事情。这……可能很多。 找出并修复人们一直不断抱怨的前3项问题。 再来一遍。 我们当前有一点不公平的优势是因为Discourse是一个讨论软件。我们就在Discourse上主持讨论关于Discourse的问题。但这也是我们最初为什么要开发一个开源的讨论平台–我深信,真正听取你用的意见对你的业务至关重要。 假设你有办法听取你用户的意见,抱怨驱动开发也没那么困难。在你深入进展到一个多年计划之前,你只要处理来用户的相当明显、很容易修复的抱怨。你只要面向他们倾听就行。正如Steve Krug在《Don’t Make Me Think | 点石成金》中说的: 你没必要找到所有问题,实际上你测试的任何东西,你永远也找不到所有的问题。并且因为如下事实,即使你找到了也没什么用: 你半天发现的问题,比你一个月修复的都多。 相对于你有资源去修复的问题,你总是能找到更多。所以重要的是你应该专注于修复最严重的问题。3个用户就很可能遇到很多与你测试任务相关的最严重的问题。 举个例子,我们发布Discourse的一个需求是所有标题和正文应该大于某个最小字符长度,因为我们认为特别短的帖子,特别是标题,不利于实际的交流。原则上讲,对我们来说这是一个重要的默认设置,因为它与我们核心任务强烈相关:开发一个软件提升因特网上有意义的交流。 不幸地是,用户讨厌它: 我觉得它特别的讨厌,它没有标志你必须输入多少字符。你只有“回复”按钮灰或不灰,并且不是所有用户一开始都意识到它是灰的。即使这样你点击“回复”按钮,如果你的帖子大多数是空白,它也可能弹回给你。它糟糕透了。 这是我们早期收到的反馈中持续最强的地方之一。因此发布后7天内,我们很快地在编辑器的右下角添加了一个实时字符数目。 |
回复 | 引用 发表时间:2014/4/30 20:01:19 |
! 您尚未登录,不能回复主题。 现在 登录 注册 |
|