快捷搜索:  2018  as  test  创意文化园  Bang  2019年5月BCI  2019年5月CBMI  2063

新二皇冠最新手机登录(www.hgw88888888.com):项目延期半年,我被软件外包坑惨了!

足球免费推介

www.zq68.vip)是国内最权威的足球赛事报道、预测平台。免费提供赛事直播,免费足球贴士,免费足球推介,免费专家贴士,免费足球推荐,最专业的足球心水网。

,

作者 | Rajiv Prabhakar

译者 | 平川

谋划 | 万佳

本文最初宣布于 Rajiv Prabhakar 的小我私人博客,经原作者授权由 InfoQ 中文站翻译并分享。

多年前,年轻且无邪的我决议与他人一起创业,但同时还要兼顾我们的全职事情。我认真手艺开发,另一个首创人认真营业。我们的 MVP 设计是宣布 iOS 和 Android App。

我在后端上有开发履历,但从未开发过 App。为此,我没有选择重新最先学习,而是决议雇佣外部软件开发职员来构建 App,而我则认真所有服务器端开发、P/SaaS 集成和基础设施。

互助委屈

这不是我第一次创业。想起来,由于有过这种履历,以是我太过自信了。

以前的创业中,我曾经雇佣过一位年轻的兼职自由职业者,他来自另一个国家。他是熟人推荐的。他不仅很好完成了事情,而且每小时收费不到 10 美元。

那时,我并没有意识到这一点,但思量到他的才气和责任心,他的报价异常廉价。现在,他在旧金山挣六位数的人为。

有点遗憾的是,他现在无法介入进来。我的团结首创人也想请一个更着名的组织来治理我们的前端开发。因此,我们决议寻找开发事情室,而非自由职业者。

固然,先要做一番观察。我们看了自力的第三方评审讲述,询问了评审依据,并与开发事情室之前的客户举行了攀谈,最终从多个事情室中选择了让我们最有信心的一家。该事情室收费尺度约为每小时 25 美元――显著高于同类的自由职业者。不外,我们以为,雇佣的是一个有履历的专业组织,而非随便一小我私人,这对我们来说更合适。

我的团结首创人是一名状师,与他们签署条约时,务求详尽。众所周知,软件项目异常容易超支,以是我们协商签署了一份牢靠价钱的条约,并对所有泛起的 bug 都“保修”。花了很长一段时间后,我们才敲定条约细节,并在条约里详细形貌他们应该构建的每个功效。然后,我们支付了第一笔款子并启动项目。

这里,我们犯下了致命错误!

凭证条约协议,这个项目分为三个部门。在完成任何事情之前,我们就要预付 40% 的用度。然后每一部脱离发完成时划分再付 30%,然则在我们收到刚完成部门的交付功效之前。由于我们是个初创公司,并提前支付了 5 位数的用度,而且在完成下一笔付款之前没有获得任何可交付的内容,以是我们在整个项目时代都被锁定了。

虽然知道会发生这种事,但我们以为没问题。由于他们有来自自力第三方机构的优越评价,优异的客户口碑,而我们没有发现什么危险信号。此外,我们知道,在一个由别人确立的项目中增添一名新的开发职员并不不容易――以是我们设计在整个项目中与他们并肩作战。

事后看来,那是我们做出的最糟糕的手艺决议,给了我们的初创公司一个繁重的袭击。

手艺挑战

根据我们的想法,这款 App 需要具备的一个要害功效是实时谈天。在条约谈判时,他们提出一些 SaaS 方面的建议来简化实时谈天功效的构建――其中之一是 Twilio Chat。在研究了他们提出的种种差异建议后,我们以为 Twilio 似乎是最好的选择,于是,我俩就赞成将其应用于我们的谈天功效。

遗憾的是,在最先构建时,他们遇到难题。他们不知道若何在 React Native 中使用 Twilio Chat,只管是他们最先推荐使用 Twilio Chat 和 React Native。

更糟糕的是,他们并没有坦率地告诉我们,他们陷入了逆境,而只是简朴地告诉我们“Twilio Chat 不适用于 React Native”。现在,他们想让我们切换到一个完全差其余谈天服务提供商(由一个我们从未听说过的公司提供),然后重新最先,而我们需要为此支付分外的用度(纵然这本是一个牢靠价钱的项目)。

最糟糕的是,他们从最先说的话就不是真的。Twilio Chat 用在 React Native 中完全没有问题――他们只是不知道怎么做。最终,作为一名没有任何 React Native 开发履历的开发者,我花了许多时间去研究解决方案,并教他们应该怎么做。纵然在我向他们做了演示之后,他们仍然需要我给他们提供文档链接,并向他们注释若何使用 Twilio API。

若是我没有和他们在一起,或者没有替他们想出设施完成这项事情,那么我们可能就会接纳他们的建议。我们可能会完全甩掉 Twilio,转向一个完全差其余、低尺度的服务。这个决议可能会让项目推迟好几个月,并多花一大笔钱。

在平安上马纰漏虎

我希望关于 Twilio 的问题就此竣事,但这还没完。所有 Twilio 谈天信息都属于一个通道,而通道可以符号为“私有”或“公共”。顾名思义,私有通道属于通道中的特定用户,而公共通道可以“被非会员看到和加入。此外,公共通道及其成员和新闻对于给定服务中的每个客户端端点都是可见的。”

显而易见,所有的非公然新闻都应该使用私有通道来实现。但令人惊讶的是,他们都是用的公共通道――这是我在浏览 Twilio 控制台时看到的。若是我们已经上线了他们的实现,只要是有一点点开发履历的人,就能够窃听每一个 App 用户的私人谈话。若是我自己没有发现这个问题,开发公司一定不会放置任何渗透测试职员来发现这些平安问题。

这样的错误令人无法容忍。更令人震惊的是,他们非但没有为自己的严重疏忽而致歉,还不愿意更改。显然,使用公共通道实现谈天功效更简朴,因此,他们更愿意保持这种方式。只有在我们多次埋怨后,他们才最终赞成改变实现方式。

Bug 无处不在

我们之以是愿意雇佣开发事情室,而不是小我私人自由职业者,是由于他们答应给我们的其他支持。稀奇是 QA 团队,他们会在向我们展示应用前举行详尽的测试。

任何软件项目都市遇到 Bug,这是不能阻止的,以是我们明白他们不能做出任何答应。但我们信托了他们的话,他们说我们应该只会发现一些极端情形下的 Bug。

厥后我们发现,这完全是一派胡言。我们从他们那里收到的所有交付全是 Bug。甚至最基本的功效都不能事情――我甚至嫌疑,纵然他们测试过,他们也不是用真正的手机测试的。在整整一周的时间里,我和我的团结首创人天天都要花上几个小时,煞费苦心地测试,并纪录所有泛起的 Bug。

程序只求可运行

举例来说,我们发现的一个 Bug 是,若是用户的联系人跨越 50 个,就只有前 50 个会在 App 中显示,其他的都无法接见。事实是,我们的一个 SaaS 集成被分页了,开发职员只实现了获取第一页效果的代码。

由于这个 Bug 只有在一个用户有 51 个联系人时才会被触发,而且我们尚处于私人测试阶段,以是我们过了一段时间才发现这个 Bug。之后,我们向他们做了反馈,问题很快就获得了修复。我们测试了他们的修复效果,似乎一切正常。

但在审查他们的代码换取时,我发现,他们的修复方式是何等的歪路左道。他们没有用一个 while 循环来获取所有的效果页,而只是简朴地添加了一个 if 条件来获取第二页的内容。一旦用户的联系人数目跨越 100,我们就会再次遇到完全相同的错误。

我可以原谅第一个 Bug,把它看成是无意的。但第二个 Bug 就是有意失职了。他们一定知道,我们要过很长时间才气触发第二页查询效果,要过更长的时间才气触发第三页。他们清晰地知道自己在做什么,知道“修复”的局限性,但他们照样那样做了。若是没有人仔细检查他们的代码,这个 Bug 就会进入生产环境。

没有版本历史

作为一名开发职员,我亲自体会到版本控制历史是何等有用。它可以辅助未来的开发职员领会为什么要做出某些设计决议,特定的功效是若何构建的,以及若何构建其他类似的特征。

出于这个缘故原由,在条约谈判中,我稀奇坚持最后的交付物应该是一个 Git 存储库。他们欣然赞成,并说他们内部也普遍使用 Git。

遗憾的是,在交付源代码的时刻,他们只给我们发送了一个压缩文件,其中包罗所有源代码和天生的文件。

我提醒他们,凭证条约,他们应该给我们一个 Git 存储库。事实上,在他们发送的压缩文件中,我甚至看到了一个“.git”目录――解释他们在开发时确着实用 Git。

第二天,他们很快就给我们发送了一个 Git 存储库,其中只有一次提交,而内里的文件与前一天发送给我们的 zip 文件完全相同。

我抑制着自己的挫败感告诉他们,我们想要整个版本历史,而不只是一次提交,而且照样提交的统一个 zip 文件。他们回覆说,他们的 Git 存储库中有一些“敏感信息”,晦气便向外人提供。因此,他们不能分享给我们。“条约只划定交付 Git 存储库。但并没有说存储库中应该包罗所有的开发提交和历史“。

随意改变规则

在谈判历程中,我们多次提到服务器端 API 还没有完全实现,我们希望后端开发和前端开发同时举行。在项目最先时,我会把所有 API 端点提供应他们,其中一些会完全实现。这样,他们就可以使用这几个端点立刻最先开发对照简朴的特征。当他们完成这些功效时,用于下一批特征的 API 也就完成了。

我们的目的是阻止延期,同时开展这两项事情,可以更快地推出我们的 App。这是我们预先明确并频频声名的内容。我们总是被见告,没有问题。

遗憾的是,付完钱之后,我们最先听到一些完全差其余声音。他们直截了当地拒绝最先任何事情,直到整个项目中每一个特征用到的后端都 100% 完成开发并最终确定。

所幸,我们在条约谈判和设计事情上破费了大量时间,我险些已经完成了后端开发。以是这并没有成为一个问题。但令人震惊和痛心的是,他们没有推行销售职员早些时刻做出的答应。

唯我独尊

新二皇冠最新手机登录

新二皇冠最新手机登录(www.hgw88888888.com)实时更新发布最新最快最有效的新二皇冠最新手机登录网址,包括新2手机网址,新2备用网址,皇冠最新网址,新2足球网址,新2网址大全。

当我们把他们看成潜在客户来攀谈的时刻,他们为我们铺开了红地毯。但一谈到实诘责题,他们就坚持要按他们的方式来做。

例如,在研究了种种选项之后,我决议用 Swagger 来纪录所有 API 端点、它们的输入、模式、形貌和行为。这样,文档就嵌入到了代码中,能够自动天生,并保持更新。Swagger GUI 还提供了一种异常友好的方式让我们可以浏览所有 API 文档,甚至可以直接从 GUI 举行 API 挪用来做测试。

遗憾的是,这不是他们的做事方式。因此,他们拒绝使用 Swagger 作为文档源。取而代之,他们坚持让我们用电子邮件给他们发送一个 Word 文档,包罗所有在 Swagger 中能找到的内容,但要根据他们指定的花样填写。

我们花了好几天讨论这个问题,最后他们让步了。但在整个开发历程中,他们的态度一直没有改变。我们雇佣他们,是为了让他们使用我们的后端 API 来确立移动应用。但他们却对 API 的实现方式提出要求。每当在 API 设计上泛起意见分歧时,我们就不得不花好几天讨论,还要忍受他们的埋怨。

这种争论可能是源于他们对 API 最佳实践的热情,但我嫌疑,他们主要是想让自己的事情尽可能简朴。而且,他们经常弄不清晰若何行使现有的 API 实现所需的功效。

缺少直接相同

项目最先后另有一个很大的意外,就是缺乏相同。在我以前所有的工程项目中,在跨团队互助时,为了更好地领会息争决泛起的问题,我们都市直接与工程师攀谈。令我惊讶的是,这是他们明确阻止的事情。

根据他们的划定,我们只能与一个非手艺的项目司理单点联系。只管我们提了要求,但他们拒绝让我们与现实从事项目开发事情的开发职员联系。此外,他们的项目司理也拒绝通过实时谈天工具交流。他们坚持一切都通过电子邮件举行。

随着时间的推移,这带来了很大的相同问题。每当开发职员遇到问题,或者有什么想不明了,他们就会把问题发给项目司理。然后,她会把所有的问题汇总起来,在一天事情竣事时给我发一封大邮件。纵然我很快回复了邮件,他们照样要到下一个事情日才气看到。

因此,纵然是一个简朴的问答也需要 24 个小时的时间,对照庞大的讨论则需要好几天,而不是聊 30 分钟,然后问题就解决了。值得庆幸的是,在项目后期,他们终于意识到这个历程是何等低效,并允许我们与他们的开发职员直接联系。遗憾的是,到那时刻,一切都太晚了。

在项目刚最先时,我们就知道这会成为一个大问题。但他们向我们保证,这不成问题。可以一定的是,我们的担忧酿成了现实。事实证实,当你天天只能通过一封电子邮件举行相同时,很难做到迅速。

严重延期

很遗憾,上述所有问题体现到了项目时间表上。原本应该是一个为期 2 个月的项目,最后却用了 7 个月。对我们来说,这是一个重大挫折,由于我们错过了许多潜在的用户,他们决议不再等我们的 App 宣布。

现在回忆起来,这些延误一点也不新鲜,由于他们缺少手艺专家,坚持接纳瀑布式方式,并拒绝通过谈天或电话直接相同。但我嫌疑,这还不是问题的所有。

我嫌疑,在差异时段,他们有其他以为更有利可图的项目,并因此降低了我们项目的开发优先级。这也是其开发团队在项目中途泛起重大人事情动的缘故原由。

推卸责任

在他们所有的失败中,要说有什么器械稳固的话,那就是他们完全拒绝为任何事情认真。在执行任何义务之前,他们都市对自己的能力显示出百分之百的信心,并答应效果不会有任何差错。而当他们没能兑现自己的答应时,总是把责任推给其他人。

你们搞不清晰若何使用 twilio SDK?

在 React Native 中无法使用 Twilio 谈天软件

(事实是可以)

你们的谈天实现会露出所有的私人对话?

替换方案太庞大了

(这是我们雇佣你们的缘故原由)

为什么某个屏幕要花 30 秒来加载?

我们必须举行 5 次 API 挪用,这使它变慢了。

(这 5 个 API 挪用加起来不到 1 秒就完成了)

项目比答应的时间长 3 倍?服务器端 API 太差,Bug 太多。(我确信,这与你们设定的项目优先级、能力和相同方式不无关系)

令人沮丧的是,这种方式很有用!若是我自己不是一个开发职员,我就会信托他们告诉我的一切。他们阻止我们与开发职员直接相同是有缘故原由的――他们的项目司理是讨好人、转达信心以及转嫁责任的专家。愿天主辅助那些雇佣了他们但却没有手艺能力与他们争执的可怜人。

履历教训

面临上面泛起的所有问题,我很想说:"离岸开发者很糟糕。"然则,这样的结论既狭隘也过于局限。我与来自其他国家的优异工程师互助过,以为优异的开发职员只存在于美国,是异常愚蠢的。

我也很想说,永远不要把开发事情外包。若是你的公司像谷歌一样成熟,或者是由风险投资公司资助的初创公司,那么一切都要自己构建,而且使用人为六位数的开发职员。然则,对于一个首创团队规模不大的自给自足的初创公司来说,使用一些廉价的雇佣兵来辅助你完成 MVP 是有意义的。这是一个可以乐成应用于其他场所的方式。

我们不禁会想,既然看到了上面泛起的所有问题,那么应该可以通过谈判杀青详细的条约条款来预防。这种做法注定要失败。有太多的未知因素和太多的主观性,不能能把所有器械都席卷在一个执法文件中。更不用说通过诉讼依法执行条约,这自己就是一个伟大的工程。

归根结底,当你招聘自由职业者或开发事情室时,主要事的只有一件,那就是:若是他们做得欠好,你有能力脱离他们。我们遇到的所有问题,都是由于我们缺少制衡手段。由于我们预付了许多钱,以是我们没有能力脱离并雇佣其他人,纵然事情变得异常糟糕。

一种更好的方式

条约一竣事,我们就与他们断了联系,并大大地松了一口吻。我真得感应卸下了一个大肩负。往后之后,我们从基本上改变了与外部开发职员的互助方式:

针对我们想要构建的功效,制定一个顺序列表。

找几名开发职员,最好是自力的自由职业者,但若是赞成以下游程,开发事情室也没问题。

对于每名开发职员,挑选列表中最主要的功效,与他们讨论功效需求、预算和成本。让他们实现谁人特征并测试。

让一名内部职员审核他们的 PR,测试升级后的 App,并标出有问题的地方。

相符要求后,合并并部署该特征,这样,所有首创人 / 用户就可以继续审核该 App,并提供反馈或者凭证需要调整。

若是我们对他们所做的事情绪应知足,就挑选下一个我们希望他们实现的功效,然后再次重复这个历程。

若是我们对他们的事情不知足,就开除他们,并寻找替换者。

我们接纳了上面的渐进式方式,脱节了伟大的预付条约,开发历程就变得异常顺遂,异常令人愉快。一切都好极了。开发职员与我们相处得加倍愉快,也显示出了更大的天真性,与我们的相同也更坦诚,并在更短的时间内交付了更好的事情功效。

最主要的是,我们不会耐久绑定到一个开发事情室,这使我们脱节了风险,让我们感应无比放心。若是对事情的生长方式不知足,我们就可以在一周后脱离。这在一些情形下拯救了我们,并减轻了我们的肩负。

反过来,我信托开发职员也会喜欢这种天真性。我们连续互助的内容是双方每周协商一致的事情,他们不会以为是迫于先前的条约在做事。

若是你阻止了我们的错误并雇佣了合适的开发团队,那么“大瀑布项目”是否有可能获得乐成?固然有可能,然则,你真有信心自己不会遇到同样的问题?这一系列的问题让我对迅速有了新的熟悉,也明白了迅速泛起的缘故原由。

客户互助胜于条约谈判

个体和互动胜于流程

可运行的软件胜于详细的文档

响应转变胜于遵照设计

事实证实,许多开发事情室都拒绝接纳这种事情方式,而是坚持使用瀑布法,并签署大额的预付条约。但在往后所有的事情中,我会坚持我现在学到的器械。

发表评论
沃保资讯网声明:该文看法仅代表作者自己,与本平台无关。请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 验证码:点击我更换图片

您可能还会对下面的文章感兴趣: