`
从此醉
  • 浏览: 1046495 次
  • 性别: Icon_minigender_1
  • 来自: US
社区版块
存档分类
最新评论

象牙塔式的开发

 
阅读更多

我向来不鼓励象牙塔式的开发模式——开发团队常年封闭在“高塔”之中,一门心思地做着魔法一样的软件。这些开发者根本不知道用户会怎样使用他们做出来的软件。你若问他们,“最近一次面见用户是在什么时候?”他们甚至可能都回答不上来!因为缺失强有力的证据,开发者都假设其他所有人都是开发者。这种想法的危险性就不用我多说了吧!

根据我的经验,越是把开发者孤立起来,他们最终做出来的产品就最糟糕。尽管大部分团队都有专人做业务分析(他们以隔离开发者与用户为己任),那也无济于事;反之亦然。营造一个专门的环境,使得开发者全然不知用户是谁,这种做法是很危险的:

我曾经在太阳公司的某个部门的全体员工大会上做过一次演讲。我问底下的人,“有谁在过去30天内跟客户面谈过?请举手。”几只手举了起来。我再问,“过去90天之内呢?”又多了一只手。“过去一年之内呢?”再多了两只手。要知道,当时在会议室里聚集了100多个人,他们可都直接负责为用户交付产品(Java培训课)啊……

跟客户面谈?这可是公然违背某些软件开发模式——这些模式的拥护者相信,只要产品规范定义清楚了,“工人”(程序员、撰稿人等)应该没必要去联络真实的用户。这其实是胡说!用户在还没看到产品之前能够清楚表达的东西,与他们在实际使用过之后所表达的相比,极少有完全符合的。这正如市场研究:人们不可能事先准确地说出他们对某样东西的反应;他们必须去尝试;你必须在一旁观察、倾听、了解,然后把你所了解到的带回去,并据此改进你的产品。对于用户来说,那种古老的瀑布模式几乎是有史以来最糟糕的东西,原因就在这里。

在整个项目周期内,请尽力将你的开发人员暴露在用户面前。让团队中的一位开发人员参加所有的用户会议。让开发人员参与可用性测试和验收测试。让他们看到一个典型的用户会在一些基本的电脑程序上挣扎不已——没什么比这能更有效地摘掉开发人员常戴着的“逻辑人”眼罩。开发人员根本就无法理解,普通用户居然不知道 ALT + TAB 是干嘛用的,更不用说怎么使用它了。只有让他们真正看到了,他们才会相信。

最近一段时间里,我参与的大都是些内部项目。我所指的内部项目的情况是,不管用户想用还是不想用,他们迫于无奈必须使用你做的应用程序。免费的东西就是这样。不过,在软件的质量方面,不禁让人忧虑重重。正如Joel Spolsky所述:令人遗憾的是,很多内部软件糟糕得一塌糊涂!这是真的。很可悲!这是象牙塔式开发的另一种表现形式:在“客户”的工作要求他们必须使用我的软件的情况下,我还有什么动力去在意他们的抱怨呢?

我更愿意做一些客户会付费的项目,或者至少得改进内部项目的处理方式,须给人的感觉是:用户为了你的产品是付了钱的。这就引出了Eric Sink所说的一种“互信关系”:

当人们从你那里购买软件的时候,他们对眼下和将来都有很多期望:

  • 他们相信,你的产品可以在他们的机器上正常工作;
  • 他们相信,如果他们碰到了问题,你会帮助他们;
  • 他们相信,你会持续不断地改进产品;
  • 他们相信,你会以一个公平、合理的价格为他们提供改进后的版本;
  • 他们相信,你的公司不会在短时间内破产。

因此,当你要求用户购买你的软件时,你也在请求他们信任你。但是,你对他们有多少信任呢?

软件厂商和用户之间的关系就像是两个人之间的关系一样。如果没有相互之间的信任,双方的关系就不会好。如果你单方面期望得到信任,而自己又不愿意付出,关系是建立不起来的。我经常看到一些软件创业者根本就不想信任用户。没错,信任别人容易使自己受伤。就像在人际关系里一样,信任是有风险的。我们可能会因此受到伤害。但如果没有信任,关系根本就起不了什么作用。

我禁不住自忖,大公司里对内服务的部门就应该像小型的软件公司一样运作——他们需要在整个公司里向其他部门积极地推销他们做的应用程序,并且向用户收费。我觉得,这可能使整个组织都变得更加精益、更加均衡,最终变得更为健康。另外,那些小而无用的项目(这在大公司里太常见了),如果没有了需求,也就自然死亡了。

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics