一次项目经历[4] 博客分类: 项目管理 研发管理
推荐阅读:
另外一些收获
虽然这个项目最终没有达成合同,形成收入。但项目还是为公司带来了另外一些收获。 首先,对于不良图片检测方面,我们在技术上坚持做了一年左右的时间,推出了两个商用版本,拥有了领先于国内同行的检测精度,形成了技术优势。
其次,这个模型被包装后,先后销售给多家系统集成商;形成了一定技术优势后,我们还采用与服务器进行绑定销售等多种方式进行系统的定制和附加服务器的捆绑。也算是借助电信的初始需求摸入了这块市场。
再次,通过这一次的项目,团队的成员得到了锻炼。
当然,这次项目带给我个人的影响也是比较大的,我几乎是跟随这个项目全过程,一步一步有所成长,接下来我会谈一点我个人的体会。
体会
需求!需求!需求永远是第一位的。
无论是*项目也好,企业项目也罢,抑或是面向终端用户的大中型产品,需求永远是第一位的。理清了需求,等于项目成功了一半。然而,对于这个项目而言,我们做的还是挺失败的。只是一味的听信电信高层提出的需求,虽然团队内部对这个需求有所怀疑,公司也没有安排对需求去实际的去落实确定,而一味的以“内部有关系”,“跟他们的高层有旧”等藉口自我蒙蔽。也因为是我们第一次与这种*部门打交道,又怕失去了那次机会,所以一直没能在签合同这事上提出自己的要求。正像h819在一次项目经历[3]中的评论那样:
往往是一个领导的想法,下边就去忙活。强调签合同,怕活就不给了;不签合同,往往拖到最后不了了之。
事情完全取决于甲方的某个领导,要知道,这种单位的领导吹牛忽悠的居多,干净利索办事的少。
结论是乙方的公关吧,早点找恰当的方式,明确合同,该得的项目不差几句话就飞了,得不到的也不拖沓。
所以,如何在项目的初期,确立项目需求的真实性,这在跟这些单位打交道的最为首要的任务。
确立了大的需求任务后,需求的具体化是接下来需要面对的问题。需求的具体化,要面对最终用户,来做调研。而不是满足于电信单方面提供的说词。当然,在这个项目的初期,系统的用户即是电信的监管人员,那时听他们谈需求是对的,而到了后来,电信转变了系统模式时,我们虽然几次提出:要求电信的主机托管客户来参与我们的需求讨论,但是电信一直以产品还没有出来,还需要进行商业包装,测试客户还没有联系好等等来拖延,而我们也没有进一步坚持。
我们越是怕失去这个机会,在讨论中越发怯不敢言,越是离这个机会(或者说离戳破这个机会)愈行愈远。讨论中经常有这样的场面:电信的人员问:……这样的功能能做吗?我们说:没问题……于是接下来做,然后再进入循环。(中午整理了点,待续)
推荐阅读
-
一次项目经历[4] 博客分类: 项目管理 研发管理
-
一次项目经历[3] 博客分类: 项目管理 研发管理创业心得
-
一次项目经历[4] 博客分类: 项目管理 研发管理
-
一次项目经历[2] 博客分类: 项目管理 研发管理
-
IVO Report System的第一次总结 博客分类: Data旅行 iBATISjfreechartSpring项目管理Struts
-
软件工程中的经济行为与软件架构师的工作 博客分类: 架构乱弹 工作软件测试敏捷开发项目管理编程
-
出色的开源项目管理软件——Redmine 博客分类: Ruby 项目管理配置管理RailsRubyPython
-
基于业务模块组件的系统架构 博客分类: 架构乱弹 OSGI设计模式项目管理框架数据结构
-
用“看板图”实现敏捷项目的可视化 博客分类: Software Process 敏捷 项目管理 agile
-
软件工程中的经济行为与软件架构师的工作 博客分类: 架构乱弹 工作软件测试敏捷开发项目管理编程