太原Android培训
达内太原android培训中心

0351-5608878

热门课程

领导不懂技术软件开发员应该怎么办

  • 时间:2017-11-15
  • 发布:达内太原安卓培训学院
  • 来源:伯乐在线

对于程序员来说,编写软件和开发软件都是自己的本职工作这是毋庸置疑的,但是让人头痛的就是一些程序员的领导并不是技术型的领导,反而可能是岗位平调等其他因素来的,这就导致了在工作对接上容易出现问题。

所以,为了消除这种问题,我们今天就给大家简单做一个关于软件开发的知识点普及,希望对大家的工作有所帮助。

领导不懂技术软件开发员应该怎么办

更快,更好,更便宜——软件开发的艺术

没人想交付延迟的、超过预算的软件,我从没见过一个软件开发者会大早上起床后心里想着“我就想把工作干得很差劲,我怎能让老板花更多钱呢?”但是,有太多的软件项目进行得都并不顺利。而且对于每一个新项目来说,似乎在加快软件开发速度方面的压力变得越来越大。所以,如果我们正在从事软件开发的工作,那么我们应该怎么做呢?我们应该如何在不降低软件质量的前提下加快开发速度呢?

现在,我不是以某种专家的身份在这儿写东西。我从没运营过自己的软件公司,也没传播从丰富的学术研究或对照实验中提炼而出的理念,我写这篇文章是为了组织我自己的想法,因为我想要设法了解我所看到的周遭所发生的一切。

为了正确地看待此事,我们首先需要搞清楚为什么要开发软件?所有软件生产的意义是什么?我们为什么最开始要做的就是开发软件?咱们暂且把开源当做房间里的大象搁置一边,先来探讨一下商业软件。咱们先从生意说起。

生意就是指减少客户的痛苦

按照我的理解,为了达成一笔成功的交易,我们首先应该找到使人们痛苦的东西(找痛点),可能是一种隐喻形式的或字面形式的痛苦(但通常是隐喻形式的),然后我们以钱作为交换,为他们提供减少痛苦的方法。例如,人们发现编程很难(很痛苦),所以开辟了编程书和编程课的市场;有些人不喜欢他们自己的外表,所以带动了健身、化妆品、美容等等整套完善产业的发展。生意从某种程度上给客户传达的观念是它们可以减少客户的痛苦(或对痛苦的感知),而且如果人们相信我们可以减少他们的痛苦,那么他们就会很乐于给我们付钱。

在软件产品业务中,软件就是我们用来减少客户痛苦的东西。对于这种类型的业务,软件开发就是提供价值的关键环节。客户买(或订购)一件产品,那么软件开发这一环节负责把它开发出来。当然,这只适用于产品业务。如果我们把咨询服务或IT作为一种支撑功能进行售卖,那么情况就会有所不同。可是但凡主要核心业务是软件产品的,那么完成该业务的手段就是软件开发。

将开发时间对业务的影响最小化

如果我们能够很好地做到“理解他人”,那么软件开发这项活动就能稳步推进。在软件开发过程中,我们会更加了解那些我们致力于解决的问题,所以我们可以开始设计更优的解决方案,因而我们创造的软件产品也需要有所改进。为了实现此目标,我们需要一支敏锐的开发团队、一支可以快速传播价值并且迅速应对变化的团队,这是软件开发实践中的核心目标。

所以如果不给开发者提供他们所想要的,那么我们该做什么呢?简单的答案是,去问开发者。但是,请在合适的时间,用合适的方式问他们。我们需要理解的一点是,开发者往往是天生的问题解决者。优秀的开发者热爱他们的工作,热爱的原因是他们整天能解决有趣的、复杂的难题,并且能够因此而挣钱。优秀的开发者陶醉于迎接复杂的挑战并且找到简约漂亮的解决方法。所以他们应该能想出精彩的点子以变得更加敏锐。但是许多组织鼓励开发者专注于错误的问题,这种鼓励可能既不是深思熟虑的也不是有意而为之,但是却时常发生。

专注于错误的问题

这是怎么发生的?我们怎么可能甚至不知道自己在做错事,以至于最后让开发者专注于错误的问题呢?因为我们将开发者从消费者身边拉开。一个项目一有任何合理的规模,我们就会找来项目经理和业务分析师。[5]我们拉来这些人是出于一个非常好的理由——开发者无法完成所有的事。软件项目是复杂的,代码已经够复杂了,但是另外更重要的是,还有各种工作诸如决定构建的内容、规划开发的阶段、制定推广部署的计划、联络客户……不一而足。代码已经够让开发者操心了,所以我们需要这些额外人员来帮忙。

但是,这样做使得这些额外人员成为了开发者面向世界的接口。与外部持股者进行协调沟通的是项目经理和业务分析师,尤其是项目经理非常在意项目的交付。项目经理向管理部门汇报情况,管理部门关心的是:

项目需要耗费多少资金?

项目需要进行多长时间?

为什么项目需花费这么多资金?

为什么项目拖延到这么晚?

为什么项目还没有完成?

我的天哪,这个项目拖到这么晚每天需要烧我们多少钱?

于是我们可以理解为什么之后项目经理开始变得专注于预测项目了。他们想要计划、结构、评估,他们想要知道什么时候在发生什么事。当他们向管理部门汇报的时候,所做的预测和估量会让他们显得更称职,所以他们才会向开发者探讨预估、报告和截止日期。所以之后,开发者开始专注于预估、报告和截止日期,他们将精力集中在这些预估和预测性上来让取悦项目经理。

但是这样做有一点不如人意的是,预估和预测性都是不可能解决的问题。每次一个开发者开始着手一个新任务时,他们就面临一个不安的事实:任何一个给定的任务背后都可能有一个潜在复杂性的大坑,也可能没有。我们都希望任务是简单的,但是它有可能并不简单,你永远都不会知道。

打破这种恶性循环

之前,我建议去问问开发者怎样才能减少软件开发时间对业务的影响,但是当开发者处于“赶进度”模式时,我们不可能得到从他们那儿得到很好的回复。当我们进入这种环境问道:“我们怎样才能开发得更快?”可能会得到两种回复中的一种:

1.用火烧了它。

“我们需要出走两年,然后重头再来。”这种情况通常在开发者已经被技术债务彻底压垮时发生。技术债务太繁重了,所以他们感觉唯一的出路就是宣告破产。他们这样做可能也有一定的道理,但与此同时,我们可能并没有相应的预算作为支撑,而且当我们过后重建的时候市场必然不会一成不变。

2.愤慨。

“我们已经开发地更快了,我不敢相信你竟然觉得你只用半个小时的头脑风暴就能修复这个复杂的问题!你怎么敢?!”这种情况通常在开发者觉得自己被迫发行低质量代码时发生。他们感觉当客户抱怨漏洞时,自己受到了客户的谴责。而且他们的愤慨很可能是有一定理由的。开发者怀着这种心态是不会帮我们的,除非我们可以向他们表达我们听到了他们的心声。他们需要知道我们理解他们的顾虑,我们同样也需要表明我们正在严肃地考虑做一些改变。

在以上两种情况中,开发者的顾虑是正当的,但他们只关注了自己。我们希望创造一种每个人都为将软件开发时间对业务的影响降到最低而努力的环境。如果开发者不能摆脱这种心态的话将难以达成以上愿景。一切策略开始的前提是,向他们表明我们正在严肃地考虑做一些改变,这通常包括寻找减压的方式,即使那只是暂时的。

但是即使这样,开发者仍然只会关注自己,除非再做一些改变。他们关于如何提升自己的工作成效会有大量的主意,其中一些想法可能很不错,但是有风险。我们需要让开发者转移对自身压力的关注,而将注意力集中在将软件开发时间对业务的影响降到最低上。我们需要让他们直面客户痛苦。

使开发者直面客户痛苦

我们接下来该如何使开发者直面客户痛苦呢?不计其数的人已经对此写过详尽的文章,所以这里我只是轻描淡写一下。这儿按照从最低效到最高效的顺序有三条观点:

1.让开发者将使用自己制造的产品作为他们日常工作的一部分。

这在业界被称为喝自己的香槟,或吃自己的狗粮。这样做的好处是使开发者变成了产品的用户,所以任何明显的错误或问题也会令开发者自己感到烦恼。这种方法存在一个问题,那就是开发者并不是典型的用户(大多数时候)。开发者使用软件的方式通常有别于大多数的客户,所以尽管这样可以帮开发者修复主要的漏洞,但是可能无法为典型的使用案例提供很好的见解,而且这也并非一直具有实践性。比如说,假想我们正在为牙科保健员生产一个SaaS产品,这时开发者可能很难将这SaaS产品融入他们的工作流。

2.让开发者在支持团队中轮班工作。

一个更佳的方式是鼓励开发者参与到一些产品的支持团队中去。(他们可能需要极强的鼓励。)这张方式可以让开发者亲自体验客户痛苦。所以,他们接电话或收邮件(或推特,或其他种种)时,客户告诉他们问题所在。开发者做这件事长达一定时间后,他们也将会开始发现常见问题的规律,他们会注意到一次次涌现的问题。无需重复听那些相同的牢骚会成为修复软件可用性问题的一大动力。不幸的是,人们几乎不会联系支持部门告诉他们产品运行得多么棒,所以得到的反馈是有点偏见的。

3.定期让开发者坐在用户身边,看他们是如何使用软件的。

这种方法是最不方便的,因为它需要最多的组织进行协调,但这也可能收获最好的结果。利用这种方法,开发者可以得知正常人是如何在现实生活中使用软件去做实在的事的。他们能看得到好的、坏的和丑的。

长期持续这样做是一件辛苦的事,需要耗费精力,需要进行组织,而且大多数开发者会对此有一种本能的抵触。我写这个感觉有点笨拙,因为虽然我理应做这件事,但我并没有经常这样做,但我相信值得付出努力做这件事。

使开发者直面客户痛苦是一种用悉心努力克服认知偏见的训练过程。这是一条“让人学会谦卑”的漫漫长途。我们开发者往往认为我们要更聪明,而且许多开发者还要更加聪明,但是我们并不是无所不知。也许我终于搞清楚了一元绑定运算和操作组合的关系,这很好,但是这并不意味着我知道了我们客户每天使用我们的软件时会遇到什么。使开发者直面客户痛苦提醒我们自己我们所真正了解的东西是多么有限。

现在,所有这种面向客户的温情举措非常模糊,都存在一个明显的问题。简单来说,这并没有让开发者的开发速度更快。事实上,这夺走了本应该用来编程的时间,所以可以认为这反倒使得开发速度变得更慢。所以我为什么认为以上说法对呢?简单来说就是如果你工作奋进的方向是错误的,那么开发速度的提升没有丝毫意义。使开发者直面客户痛苦重要的是方向而非速度。

咨询开发者

我们想要可持续性地将软件开发时间对业务的影响降到最低,我的假设是如果你为开发者指引了正确的方向,那么你可以在此基础上咨询他们接下来该如何做的意见。如果我们让他们落实他们的意见,那么我们便应该能看到结果。

理想地来说,这是一个持续推进的过程。我们问开发者他们是否有任何能够加快软件开发速度的方法,然后我们对提供的方法进行试验,几周之后再回来,打听进展状况,继而再去问开发者加速的方法。就这样一直问他们,直到你每次你连问都不用问就可以直接进入他们的工作区域。他们于是开始这样说:“我们所做的路由引擎的重构真的成果不错。但是我觉得如果我们把那种逻辑的一部分移出来,放入微服务层,那么我们就可以更快地进行缝补和撕毁。”你可能并不知道那意味着什么,但是如果我们看到漏洞减少、客户更加满意,那么大家就都成为了赢家。

具体到你自己的团队,用什么样的方式询问他们取决于你自己。有些人喜欢头脑风暴研讨会,另一些人更倾向于调研或一对一专访。每种方法都有其不同的优缺点,但是无论你选择哪种方法,请确保弄清了限制。如果你仅有一笔很小的预算,要明说。如果没有灵活延长任何截止期限的余度,请告诉开发者。假设你拥有聪明的、能干的开发者,他们能够把以上这些都考虑在内。而且如果他们没搞明白,甚至在你多次解释说明后仍不明白,那么你也从中学到了点东西……

务必在探讨限制时小心谨慎。如果你告诉开发者没有预算、截止期限是定死的、没有一丁点回旋的余地……那么他们无疑将回复你他们无力帮助,这种情况下你应该格外小心。高质量软件若想要提高生产速度,就需要花费金钱。开发者需要知道我们愿意为他们和他们的工具投资。如果没有预算、没有延长截止期限的余地、没有情况好转的迹象……那么聪明的开发者就会去考察其他方面,这种做法让我喝彩。这是一种没有胜方的局面,这种局面会吸引情感投资。向开发者展示我们在乎、并且愿意向他们和他们的未来投资,向他们解释我们目前正处于资源严重受限的困境,这样他们便可能会愿意想一些创造性的解决方案帮我们挣脱当前困境。

假设

我在这儿要做一个较大的假设,我假设当你向你的开发者解释限制时,他们都很聪明,完全能够理解。最大最显而易见的限制就是我们并没有无穷无尽的金钱去挥霍。开发软件很费钱,远比大多数人预期的或意识到的要多得多。好的软件开发者得花不少钱去请。我在这儿的假设是有至少有一个或两个聪明的开发者可以能够理解以上情况。

可悲的是一些开发者就是不理解,那么你该怎么做呢?答案并不简单,但是我推测开发者不理解的原因是他们从来都没有机会以更大的眼光去看待问题。他们只被要求做去做不现实的预算和加快开发速度,并没有从客户或那些付他们薪水的人的角度去考虑问题。唯一使他们开始理解的方式就是有人展示给他们看。

我要做的另一个大假设当我们把开发者带到委托人员面前时,我们相信他们不会让公司难堪。当然了,也有很多次我和委托人开会时,开发者说了蠢话或宣泄不满的情况,毕竟并不是每个人都做好了站在幻灯片前展示推销游说本领的准备。但是如果我们相信一个开发者能够仅礼貌地握握手打招呼,那么他们当然至少也能做到坐在一角,静静地看人们使用软件?[10]也许他们需要有人首先能带带他们。但是如果从来没被给过机会,一个人还能以什么方式去学做一个组织优秀的大使呢?

但是我离题了,咱们回到提升软件开发速度上。

安全带和引擎升级

咱么假设你的团队里全是聪明的开发者。当你让他们出主意时,他们可能首先想出许多听上去是反直觉的东西,比如像:

测试驱动开发(TDD)

持续集成

结对编程或mob编程

代码审查

所有的这些技术都会降低开发速度……TDD很像是完成同样的结果却用了两倍的代码量,而结对编程就像利用了两个高产的开发者却将结果削减了一半。我能理解一些质疑,但这不只是时髦的流行语(大多数的这些技术已应用了几十年之久),它们自然有存在的充分理由。

让我试着用类比解释一下:当你开车时,你要系安全带。近些天我们希望车能自带安全气囊和防撞缓冲区,但是当你想开得真的很快时,你要戴赛车安全带、头盔和防火服,我们还会将翻滚护架、气流偏导器和粘型轮胎加到车上。这个类比不完美,但是希望你能明白我想表达什么。首先,一些诸如TDD和代码检查的方式会使你开发速度变慢,他们会变得笨拙,不易习惯。但正是这些保障团队更加安全地加速进展。

像TDD和持续集成这样的技术是关于提升软件质量的,这意味着生产中会产生更少的漏洞。在漏洞流出前将其捕获意味着会减少重做的次数、减少尴尬、更愉悦客户。问题通常会被更快(耗资更少)得被修复。随着时间流逝,不耗费在修复漏洞上的时间增加。另外,这些技术支撑下写出的代码往往更为灵活,更易改变或再用。这意味着我们可以花费更少的时间去对抗脆弱的代码库,能花费更多的时间去添加新的特征或修改功能。最终结果是软件更好,开发速度更快。

加紧反馈环

这样的要点是减少从写代码到交付客户所经历的时间。这样的话,开发者可以观测到新的代码是如何减少客户痛苦的。掌握了客户反馈,那么他们可以进一步提升代码等等,这样我们就创造了一个良性循环。

如果你在过去几年一直在追随IT发展趋势,那么对良性循环一定很熟悉。良性循环听上去很像持续交付,但是这种流行语并不是重点。持续交付只是一套实践的标签而已。而且,这些实践能够提供紧凑的反馈环,反馈环能够使得我们在提升速度的同时减少风险。

这样做有一个很好的理由。我们所建立软件的环境不仅麻烦而且复杂,一个麻烦的系统有许多部分,实则让一个专家都要好好理解这么多的部分是如何结合在一起的。但是一个复杂的系统不仅仅有许多部分,而且所有的部分都彼此连接,相互作用。所以,当你改变了一小部分后,那么整个系统可能都会因而发生变化。

在复杂的系统中,很难预测一次给定改变所可能产生的影响,这是因为做两次相同的改变可能产生截然不同的结果,第一次改变能引起一定的系统反应,在下一次中会完全不同。这样会导致非本意的结果,使计划和预估出现问题。

那么我们在一个复杂的环境中如何设法去完成每件事?专家建议“探索、感知并且回应。”换句话说,创造紧凑的反馈环去评估哪些事能成或不能成。然后我们尽快重复此动作,保持小变化、短周期。因此,与失败关联的风险也控制到很小,恢复的成本也更低。我们要做很多小实验,保留工作正常的,恢复工作失败的。

结论

我们不能仅靠“最佳实践”建立一支高水平开发团队。不幸的是,软件开发中几乎没有捷径,但是当我们能够谦卑地承认我们并非无所不知时,总能利用一些方式能干得很好。

让开发者直面客户痛苦缩小了反馈环,这使得我们确信如果我们加快开发速度,那么我们一定在正确的方向上加快速度。一旦达成了这一点,我们便能够以一种适应给定情况的方式进行持续的改进了。

作者:dimple11

来源:伯乐在线

【免责声明】本文转载自网络,著作权属原创作者所有。经检索无法确定原创作者,故未标明作者。我们分享此文出于传播更多资讯之目的。如涉著作权事宜请联系小编更正!

上一篇:人工智能技术与人脑相结合之后会引发哪些变化
下一篇:无法学以致用的开发技术真的是不如不学

太原android编程技术如何设计软件内核程序

服务器维护的例行工作都有哪些

太原android培训关于SQL语言的识别方法

使用框架协议搭建网站有何利弊

选择城市和中心
贵州省

广西省

海南省