行业经验

丰富的行业经验,让您少趟坑

软件项目的若干种死法

时间:2019-11-19   访问量:462

        每天都有不计其数的新项目在互联网上线,每个人都想凭借自己超凡的智慧、绝妙的idea在互联网上淘一桶金。然而,每天又有不计其数的创业者败下阵来,看着一波波的后来者不断涌上来。如大浪淘沙,而每个人都想做留下来的金子。

        这其中,很多付出了超凡的努力和智慧零结而成的项目,死的都比较冤,或者未死的幸运者,伤得也很冤。如果各单位执行到位,本可以成功,或者本可以获取更多的价值。导致这种情况的原因,其实很早就出现了。总结了这么多项目,最核心的风险,都存在于团队的信息和认知的不对称上面。信息不对称可以让人谋利,这是永恒的道理。但这个是相对于团队外部的。如果团队内部的信息和认知的不对称,那这就不是一个好的团队,就很有可能把项目做死。

        

        项目失败,首先应该反思的是项目发起者(老板或职业经理人)。其实很多的失败,我们原本可以避免,只要我们遵循某些基本原则。而犯了某些错,可能就需要更大的成本来弥补,甚至于不能弥补,而直接消亡。


        下面,我将分析软件项目因为开发问题而致死的若干种死法,以及如何规避这些问题:

1、需求不明确

        需求不明确是软件项目中经常遇到的问题,其表现包括需求范围未界定、需求没有细化、需求表述不清晰、需求遗漏等多个方面。发起者最开始只有一个简单的idea,一个相对狭窄的需求范围。随着沟通的进行,会不断的去调整和补充这个范围。至于一些未曾考虑到的因素,往往是需要从专业的人那里获取的。即便如此,你也不可能把什么到考虑到位。你以为你已经把一切都跟团队交代清楚了,剩下的就是他们的事情了。直到项目上线的那一刻,你才发现有些部分完全偏离了最初的想法,而这时再调整可能为时已晚。

        这是比较早期的风险,却直接导致了后期的项目失败。在软件开发过程的各阶段,需求不明所造成的浪费是最大的,必须尽早解决,而且必须持续解决,不要想着万事大吉,否则就是做多错多,做到最后毫无意义。下面这些建议,也许有助于你从这个层面上降低风险:

(1)化整为零,分期迭代

        也许你想要造一艘航母,但以目前团队的实力、项目的进度,只能给你一艘小船。那么你应该从你的层面来合理规划,如何能够持续迭代,一步步交付可用产品模型,最终把航母造出来。不克制自己,不分阶段限定项目范围,单靠喊口号和人力的投入,就会有意想不到的潜在的巨大风险。按照精益生产的理念,敏捷开发的原则,化整为零,分期迭代,持续交付,这是对项目负责,也是最理性的开发方式。让需求的偏离尽早的暴露出来,尽早调整,让持续变更的需求,与项目的周期契合,不能说就成功了,但至少最大程度绕过了坑、淌过了暗流。

(2)信息同步,持续沟通

        你看到了全局,掌握了该有的信息,但是你的团队成员会像你一样吗?你应该尽早让他们获得必要的信息,持续进行沟通。认知盲区,会导致他们不能理解你的想法,最终做出来的产品偏离了初衷。经验丰富的成员,考虑更加周全,但你也不要仅仅寄希望于此,因为一块短板、一个纰漏,就可能满盘皆输。

(3)早期评审,定期回顾

        一定要参与早期的需求评审,确定项目的整体方向。不仅如此,你也需要定期的与团队一起回顾过往的需求,从整体上确认和保证逻辑的准确性。 

2、项目无法提前呈现

        即便明确了需求,项目发展到最后,依然可能出现偏离。直到上线那一天,发现用户界面丑陋不堪、功能缺失、核心需求错误,这种情况也是数不胜数的。

        一个最有效的方式,就是让项目尽早呈现。结合上文提到的持续迭代,其目标应该明确,让每一次迭代都能看到真实效果

3、性能低下

        曾经有个朋友的项目在一波大力推广、用户数上来后,app使用卡顿,数据半天加载不出来,业务操作直接无法进行。于是不得不在客服群里各方安抚,通宵达旦的做补救工作,最终还是没有抓住那一波流量,白白损失了大量用户。更要命的是,因为并发问题,导致资金错误,原本应该有的漂亮的收益,转眼变成了尴尬的亏损。

        很多软件项目,由于先期设计不足,一段时间运作下来,性能翻车,导致不可用,直接造成损失或失败。为了避免这种风险,你需要这么做:

(1) 提前进行性能规划

        在系统设计之初,就应该做好性能规划,对可能出现性能问题的环节做到充足的估计。尤其是数据库和并发方面,虽然未必一开始就能做集群和分布式,但可以合理架构,一旦流量上来,能做到短时间内横向部署,通过增加机器或提高配置的方式,应对性能问题。

        如果软件架构设计不合理,优化就会需要大量的时间和精力,甚至伤筋动骨。在实际的生产环境中,市场怎么可能给你时间?

(2) 提前进行性能测试

        在合适的时间,提前做好性能测试,包括并发测试、压力测试等。需要一个明确的指标,什么样的架构和配置,应对什么量级的用户基数。如果不满足需要,还得有时间来进行调整。调整完再进行回归测试,避免调整引起了其他问题。

4、上线仓促

在项目实施过程中,系统切换上线环节最容易出纰漏。项目好不容易开发完成了,却在最后最后时刻功溃一匮。如果项目小,影响面窄倒不怎么重要;如果是影响面大的项目,则千万不可出现问题。在系统切换前,应充分考虑各种可能出现的问题,做好风险对策。

(1) 应急预案

面对各种不可预知的风险,要做好应急预案。正常运行的车站售票系统在春运、旅游黄金周,都会做好应急预案。新系统切换时,更应该做好应急预案。应急预案中应做好最坏的打算,售票系统不能正常工作时,准备手工票就是最坏的打算。

(2) 分步切换

为了减少风险的影响,可以做系统分步切换的方案。例如:售票系统在切换时,往往用新系统售预售票,或者是用新系统售长途车站,用旧系统暂时售短程票。待新系统运行稳定后,再全面切换到新系统。针对多个用户单位的系统切换,也可分单位进行。

(3) 交叉培训

新旧系统切换过程中,用户都存在适应过程。除了在切换前做好操作培训外,还要在新旧系统切换过程中做好交叉培训。让用户提前一些时间上班,让早班的用户在交班时培训中班的用户,中班的用户培训晚班的用户。做好交叉培训能够让系统平衡过渡。

5、缺少真实用户参与

软件的可用性包括软件的使用是不是高效、是否容易学习、是否容易记忆、是否令人愉快、是否不易出错等诸多因素。往往由于软件的可用性差,导致用户不满意,甚至被市场淘汰。在项目开发中应注意可用性问题,避免软件出现可用性方面的风险。

        总结

在信息系统集成项目中,风险是多种多样的,是无处不在的。在项目管理活动中,要积极面对风险,要培养。越早识别风险、越早管理风险,就越有可能规避风险,或者在风险发生时能够降低风险带来的影响。特别是在项目参与方多、涉及面广、影响面大、技术含量高的复杂项目,应加强风险管理。如果不主动驾驭风险,就会面临风险。


上一篇:你到底需要一个什么样的企业网站

下一篇:没有了!

相关资讯

最新资讯

长按/扫描右侧二维码+关注我们

电话:86 19176725355

邮箱:service@sinanit.com

在线咨询

点击这里给我发消息 售前咨询专员

在线咨询

免费通话

24小时免费咨询

请输入您的联系电话,座机请加区号

免费通话

微信扫一扫

微信联系
返回顶部