古有将相,今有产品狗与程序猿

最近在看大秦帝国,其中丞相范雎与将军白起的一段对话不由让我想起了产品狗与程序猿的撕逼。古今对比,人物角色虽然有高低之别,但一个是设计者,一个是执行者,其中的关系矛盾却是相似的。


其中范雎首先提出了攻人之法,却并未说明操作细则,白起追问道:“今后遇到降兵降民,是杀还是不杀。” 这仿佛程序猿在问:“这个功能的规则能不能具体一点,是做还是不做。” 在软件开发过程中,首要的便是需求设计,如果需求设计模糊,各种定义模棱两可,便会产生很多问题,首先程序员会猜测需求,带着问题开发,接着自行决定需求,进而引发各种争论扯皮,你有你的一套理解,我有我的一套理解,争论没有尽头,如果这些都以文档的形式明确的表述出来,那争论自然消除了。明确需求的一个要点是细化,而不是提一个笼统的概念让人去猜,软件开发中,项目的成败常在于细节,如果错误是代码引起的,或许很快就可以修改好,但如果是因为需求设计错误或者需求细节不明确引起的偏离,就可能打破原有的代码结构,需要花大量的时间去重新设计、编码和测试。这些问题在需求设计阶段解决成本最低,但人对需求的理解也有一个由浅入深的过程,在开发过程中,要时时保持沟通,这样才能保证开发的产品能够满足需求的准确定义,程序员也应该主动地去深入乃至推动需求的细化和合理化,这是对公司负责,也是对自己负责。

然后范雎提出远交近攻之法,这同样是一个模糊的定义。“何为远,何为近?” 当范雎回答了白起的疑问后,白起又说:“是远交近攻,还是近交远攻,是不交而攻,还是交而不攻,如此种种,应当全凭当时之时势而定,怎么能用远交近攻这四个字就定夺一切军情呢,过于拘泥,反而会受其累。” 如果让这位战神来做开发工程师,也是十分合格的,他考虑到了需求未来变化的可能。这就好似软件开发中需求的多变性,稳定需求是个神话,这很重要的一个原因是用户、客户不能明确自己的需求,而在需求分析阶段对产品经理要求是比较高的,他需要去推动使用者发现、理解需求,需要有特定领域知识,并且用准确的术语表述出来,也就是需要有讲故事的能力,既能与用户沟通,又能和开发沟通,时时跟进,从而使需求的未来变化有一个良好的管理,这样有助于执行者,也就是开发人员能更充分全面地考虑到系统未来的变化可能,从而有更好地架构和编码。如果产品经理都不能很好地把握需求,忽东忽西,忽远忽近,这会让开发无所适从,最后做出来的产品却不是用户或者客户想要的,白忙一场。对此,我们可以以小步快走的形式,开发一部分,发布一个小版本,获得用户的反馈,然后进一步设计调整,再开发一部分,发布一个小版本,如此循环。

需求基本定下来了,接下来主要就是执行了,就像秦王和丞相期待白起这位战神能打个大胜仗一样,产品和老板也总是希望能出来几个牛人,快速开发功能,快速解决问题,但是,开发中也有一些人技术很水,有时偷懒,导致项目延期乃至最后失败,于是产品也常常会觉得开发不给力。A级程序员的开发效率是普通程序员的十倍以上,这是事实,但寄希望于大牛也是十分片面的想法,秦军的胜利在于商鞅变法以后整套耕战制度的发挥的巨大作用,团队项目的成功也在于从需求分析到项目部署上线整个流程的合理和健全。

java达人

ID:java_daren


                                   

友情推荐

漫话五大名著

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值