Experience

Rich industry experience, let you less pit

软件项目的若干种死法

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

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

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

        

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


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

1、需求不明确

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

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

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

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

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

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

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

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

2、项目无法提前呈现

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

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

3、性能低下

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

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

(1) 提前进行性能规划

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

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

(2) 提前进行性能测试

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

4、上线仓促

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

(1) 应急预案

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

(2) 分步切换

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

(3) 交叉培训

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

5、缺少真实用户参与

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

        总结

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


上一篇:怎样降低软件项目风险?

下一篇:没有了!

相关资讯

最新资讯

Wechat scan and contact us

Tel: 0755-29171243

Email: service@sinanit.com

online consultation

Click here to send me a message Pre-sales consultant

online consultation

free call

all day long for free consultation

Please enter your contact number and add area number for the landline

free call

Wechat scan

Wechat contact
TOP