转载分享----一线交付眼中的为何"项目总是迟迟无法交付”

当初博主在一线交付BOSS系统中承担过TC角色

交付的路途很艰辛,加班到10点多或1点多第二天8点上班,还有通宵的日子

还有无数个问题从开始到关闭的周期,各种催人,各种掐架拉会,各种被甲方嫌弃

看到这篇文章时觉得深有同感,故分享给同学们,在一线有苦有乐,加油!

--------------------------------------------------------------转载分享-------------------------------------------------------------------------------------

--------------------------------------------------------------转载分享-------------------------------------------------------------------------------------

作为一名业软一线交付与服务老兵,这些年来自己亲身经历了一些的项目,同时也听闻了不少项目。大家都有一个同样的体会:交付中所遇到的问题越来越多,按期交 付的项目越来越少。在此与大家共享一下我眼中所导致项目迟迟无法交付的一些原因,同时抛砖引玉,望大家一起分享自己的切身经历与经验。从个人角度为自己在 以后的项目中工作更加得心应手,少一些头痛类的问题。从公司角度为公司多贡献一些经验,多传递一些正能量。

1、 合同质量问题

杀伤力:★★★★★

合同中的问题基本上无法完全提前考虑周全,就像理论与实践总会存在差距。我们交付多少?怎么交付?都是完全依照于合同。前期不投入或投入少,合同签的漏洞百出,到最后还是得我们来擦屁股。磨刀不误砍柴工,在合同初期主动参于并负责合同条款评审(特别是一些关键字眼,如and so on、full、any等)。你提前发现一个问题,后续就会为你减少N个版本交付与夜活操作,同时也对项目的后期交付会起到事半功倍的效果。

2、 关键证书发放策略

杀伤力:★★★★★

其实这个属于合同的一部分,但为什么单独列出来,主要因为它是衡量一个项目是否交付的最关键信息。其实公司一直在推行先PAC后商用,但近几年来,却几乎很少看到上线前就可能拿到PAC证书。特别是现在的合同都是大的整体解决方案:一是涉及多个产品交付,二是很多功能都是在割接上线后陆续实现与交付。是分产品发证书?还是分多少功能上线后发放证书?等等。所以如何制订证书的发放策略对我们项目何时“关闭“有着举足轻重的作用。

3、 解决方案及功能描述过于简单

杀伤力:★★★★★

因业软项目的定制化越来越多。什么叫“定制化“,就是把局方所想的东西,我们要进行剖析与实现,而我们经常会遇到开始做出来的东西根本不是客户想要的,通过需要多次修改版本才能满足要求。主要原因是局方提出的功能需求后,我们所提供的FRS过于简单,没有细化到业务正常处理、特殊场景的处理、方案的limitation及对周边的要求等因素。对需求理解与分析不透彻,同时随着时间的推移,客户的想法也在不断地变化,导致后期客户无限放大与变更。如果前期多花些精力把FRS写详细,尽量考虑周全,可以对研发与一线交付节省大量成本与工期,这也是项目正确与规范交付一大利器。

4、 LLD不详细

杀伤力:★★★★★

项目中难免碰到因诸多对接、配合等问题而导致项目延期的现象。因为业软项目中所要对接的网元接口实在繁多,并且很多都是私有协议。如果项目前期不先白纸黑 字确认清楚,这样对接就很容易因前期没沟通不充分及准备不充分导致项目迟迟无法按节奏交付,而原因基本上都是双方纠缠不清。怎样尽量避免这样的事情发生? 只有在项目初期制订并与局方签署详细的LLD。一是告诉客户我们会怎么来做,二是让客户把LLD尽早发给对接所涉及的网元进行提前准备与配合。最终使大家把力往一个方向使,缩短项目交付周期。

5、 版本质量

杀伤力:★★★★☆

我想大家都有同样的感受:在交付功能中,通常要反反复复要发布好几个版本或补丁才能满足交付,每当一线拿到版本或补丁后,通常要花大量人力与时间对新老功能、新老问题做通篇测试。而对这些所谓解决的问题,如果在开发与测试过程中能尽量把关,我觉得版本及补丁至少可以减少50%。尽量一次性把事作对,对版本也做到从源端控制交付质量,这样可以为研发、一线及整个项目组都可以减少很多重复性的工作及时间。

6、 BOQ问题

杀伤力:★★★★☆

巧妇难为无米之炊,前期不对设备配置是否合理进行严格把关,不检查是否满足局方各部门的要求,后期在交付过程必然会发现不少BOQ上缺斤少两的问题,一是引起繁琐的补货流程,二是长时间的变更及运输周期,三是成本的增加,更重要的是导致工期因这样低级的疏忽而被拉长。所以前期仔细做好内部与外部BOQ评审与确认,对后续交付也启着至关重要的作用。

7、 ATP验收Case.

杀伤力:★★★☆☆

基本上每个项目的ATP验收总要与局方要做2~3轮以上。有版本问题,也有局方新增的Case,并且首轮之后的ATP基本都需要新的版本或补丁来支撑,而只要涉及到版本与补丁就会导致工期的延期,并且还影响着客户对项目的信心。怎么避免这样的事情发生,只有前期先与研发及客户沟通并确认好ATP Case详细信息,研发在做版本测试时也做为测试的一部分,这样才能保证与局方验收的一次性通过率。为项目节省时间,也让客户对项目进一步增强信心。

8、 站点勘测

杀伤力:★★★☆☆

这 个是项目中最简单、也是最重要的一部分。自己就经历与听闻过好几个项目因局方传输不具备、带宽不满足、电源不满足、空调不满足等原因导致项目延期长达几 月,甚至上年的现象。所以这个勘测一定要做到位,同时也要把对局方的端到端要求提出来。否则后期一旦发现问题就会引起项目长时间的拖延,并且我们还处于爱 莫能助。

9、 合理的项目PIP

杀伤力:★★★☆☆

很多项目因PIP制订的不合理或不具备可实施性导致项目无法按计划顺利开展,最终导致无法按计划完成。虽然计划总是赶不上变化,总的目标在一时也看不清摸不着,但可以把一个大目标分解为每天或每周的小目标。这样大家每天或每周都可以为一个看得见够得着的目标去努力去完成。所以PIP的规划一定要细、要接地气、要具有可实施性,并且一定要考虑周全,不然项目交付半路杀出一个程咬金,导致大家都乱了自己的步伐,更何谈如期交付。

10、 项目组的执行力。

杀伤力:★★★☆☆

项目的交付就是一个执行的过程,怎么如期交付,一个是前期的详细规划,一个就是后期的严格执行。前期规划时与每个任务的责任人提前沟通并认同,后期就要严格执行与监控起来,防止出现短木板现象。

11、  内外部沟通

杀伤力:★★★☆☆

项 目的交付基本上一半的时间在于沟通,如问题的处理、局方的配合、内外部的求助、日报周报等都是沟通问题,特别是现在客户很善用投诉。其主要原因都是沟通引 起的,一旦因沟通不畅就会引起投诉,问题处理被动,项目无法继续开展等问题。这时我们还要准备一堆材料、胶片及会议进行汇报与解释,使项目组陷入恶性循 环。

12、 项目中问题的处理

杀伤力:★★★☆☆

做项目就是发现问题与解决问题的 过程,只有把所有内部与外部问题都处理妥当了,这个项目也就基本完成了。很多项目无法按时完成,其很多时间都是处理问题不当所致,所以怎么处理内部与外部 问题的方式方法尤其重要,我的感受一是要梳理清理内部与外部问题的处理接口及上升渠道;二是要对问题敏感;三是一定要对问题有高度的责任心;四是要灵活运 用灰度与妥协进行妥善处理;五是在内部与外部建立良好的个人魅力。项目中出现问题并不可怕,可怕的是我们无法妥善处理这些问题,而使项目交付陷入如履薄冰 的困境。

虽然每个项目无法交付的原因不计其数,但只要我们每个人保持一个开放与学习的心态,最终转化为自身免疫力,这种项目普遍迟迟无法交付局面将会逐步改观。多项目因PIP制订的不合理或不具备可实施性导致项目无法按计划顺利开展,最终导致无法按计划完成。虽然计划总是赶不上变化,总的目标在一时也看不清摸不着,但可以把一个大目标分解为每天或每周的小目标。这样大家每天或每周都可以为一个看得见够得着的目标去努力去完成。所以PIP的规划一定要细、要接地气、要具有可实施性,并且一定要考虑周全,不然项目交付半路杀出一个程咬金,导致大家都乱了自己的步伐,更何谈如期交付。

时间: 2024-10-21 08:20:57

转载分享----一线交付眼中的为何"项目总是迟迟无法交付”的相关文章

PYTHON上海分享活动小记---SQUID日志分析项目开发

上周末有幸跑到上海为小伙伴们分享了<SQUID日志分析项目>,主要是带大家用PYTHON迅速实现一个SQUID日志分析平台的前后端开发,一天的课程太紧张,导致有些细节不能完全实现,但整体思路啥的基本都OK啦,可惜的是由于电脑没配置好,导致没法录像....,要不然就可以放到网上与大家一起分享了,现在只能上几张图了... 最后感谢 波波同学,无偿负责组织策划了这次分享活动,感谢柏林,提供场地支持. 感谢大家花周末时间参加这个活动,希望此次分享对各位有所帮助.. PYTHON上海分享活动小记---S

[转载] 分享D瓜哥最近攒的资料(架构方面)

原文: http://www.diguage.com/archives/41.html 扯扯蛋 以前见过零零散散地介绍一些知名网站架构的分析文章.最近D瓜哥也想研究一下各大知名网站的架构.所以,就搜集了一下这方面资料.限于时间问题,这篇文章分享的文章并没有都看完,所以不保证所有文章的质量.另外,如果有朋友发现更好的文章,欢迎留言告知.再补充进来. 知名网站架构分析 探索Google App Engine背后的奥秘(1)–Google的核心技术 探索Google App Engine背后的奥秘(2

转载——分享一个html+js+ashx+easyui+ado.net权限管理系统

EasyUI.权限管理 这是个都快被搞烂了的组合,但是easyui的确好用,权限管理在项目中的确实用.一直以来博客园里也不少朋友分享过,但是感觉好的要不没源码,要不就是过度设计写的太复杂看不懂,也懒得去看懂,还有一些不是在推广自己的代码生成器就是在卖权限组件,看着漂亮的UI和完善的功能就是没源码学习,真是恼人. 前段时间公司项目阶段性结束了,就抽空把权限控制的部分抽取出来写了个html+js+ashx+ado.net的权限管理系统分享给一些初学者,这个权限系统demo没有MVC.没有ORM.数据

我眼中的软件项目实施(转)

http://tech.it168.com/a2009/0331/270/000000270127.shtml 从大学毕业以来,笔者一致从事的就是软件项目实施工作.很长时间想写一个总结,谈谈工作几年以来的认识,这或许对于刚毕业的学子们是一个认识软件项目实施的窗口. 在ERP软件实施中有一句行话:“三分软件,七分实施.” 只有经历过才会明白这句话是什么意思,正如我的一位前辈说过,只要使用得当,Excel也是一个非常好的进销存管理工具.当然这样的软件使用方式也是要看,使用的对象.最终要告诉大家的是,

转载分享:Android APP二次打包操作步骤介绍

看到好的技术教程就想转载一下,不喜勿喷!谢谢配合,仅供菜鸟学习研究,不要做坏事哦\(^o^)/~ 关于Android APP 二次打包现象已经屡见不鲜,为何"打包党"就吃准了Android平台,二次打包的操作过程到底有多简单? 本文将从Android apk的结构.二次打包的工具.步骤等方面向移动开发者说明二次打包操作的简单性,从而引起开发者对APP安全的重视,并及时对APP进行代码混淆或加固 保护等安全措施. 安卓apk的文件结构首先来看一下Android apk的内部文件结构. 随

转载 分享探讨程序员的最后归宿!

    中学政治学科的课堂上,辩证唯物主义告诉我们,任何事物都包含着既对立又统一的两个方面.要如实的反映事物的本来面目,就必须坚持一分为二的矛盾分析法,对矛盾作全面的分析要运用两分法.两点论去认识事务的本质.简单的意思就是,万事万物都要看到它好的一面和不好的一面. IT也是如此,程序员的职业也是如此.“程序员的最后归宿是什么!”.“程序员为什么到了30或35就会想要转行”.“边缘化的IT人”等等诸如此类的话题漫天遍野,“程序员吃的就是口青春饭”如一根刺隐隐的扎在了程序员心头肉上.这已成为程序员们

【0】分享一个正在做的SSM项目

正在做一个外包项目,虽然老板百般让我复制别人写好的代码(普通jsp跟servlet做的,一个字:乱). 但是!!我怎么可能这么没有追求,学了一段时间的SSM框架后,果断用SSM改装了,当然咯,前端的版式和模样都一样,所以看着没区别.可以后期维护肯定不一样的.维护起来一定会越来越深刻.按照我想法,用jsp跟servlet直接干的,维护起来只能让自己的思路越来越乱,这样是做不了大项目的. 有需求项目经验,但是找不到合适项目的,我可以共享给你(一起交流,一起做,please留言),当然了,项目用的数据

分享》:关于阅读开源项目的源码思路方法

关于阅读开源项目的源码思路方法:<不喜勿喷> 一般开源项目, 如果这个项目你很熟悉经常用, 那么你直接从 main 入手没问题.. 如果你不熟悉或者代码量很大, 最好从代码的 example 代码 或者 client 的代码入手比较容易. 这些代码直接 gdb 进去就可以调试运行了, 客户端的功能搞清楚了,会用了, 恐惧感就降下去了, 再看服务端就容易了. 看 c 代码要 关注主体核心 struct , 整个server, client 可能都是围绕整个 struct 运行起来的, 这个str

【转载分享】总结过去10年的程序员生涯,给程序员小弟弟小妹妹们的一些总结性忠告

展望未来,总结过去10年的程序员生涯,给程序员小弟弟小妹妹们的一些总结性忠告 走过的路,回忆起来是那么曲折,把自己的一些心得体会分享给程序员兄弟姐妹们,虽然时代在变化,但是很可能你也会走我已经做过的10年的路程,有些心得体会你可以借鉴一下,觉得说得有道理的你就接纳,觉得说得没道理的,你就抛弃,以下是我发自内心的,给大家的忠告,特别是针对那些小弟弟妹妹们. 01. 自己的户口档案.养老保险.医疗保险.住房公积金一定要保管好.由于程序员行业每年跳槽一次,我不隐瞒大家,我至少换过5个以上的单位,这期间