ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 2011IBMRational创新大会日记-规划

2011IBMRational创新大会日记-规划

原创 Linux操作系统 作者:xiaochouyu21 时间:2011-09-13 08:08:03 0 删除 编辑

8月30日去了IBM在上海举办的2011创新者大会,一阵激昂的音乐中,深蓝色的太空和白色的星星闪烁,出来了蓝白相间的创新的主题.


Software anywhere , software everywhere in future ,  market more competitive

we need new business model  and best way.

2020 will be 手机银行和数据中心的天下,新方向: Application Security , Complexity.

市场压力加剧,软件交付的复杂性, change Requirement , Time to market , entire product life cycle , short time frame. , 

一切都在变化和改变中. 我们不得不或者说以更积极的态度去拥抱变化.


开发 - 智慧 -创新


方针

整合                          协作                   优化 

连接流程和信息      统一团队              计划,范围和措施

软件数据和工具       项目和组织文化   简化流程


Program

加强Program的力量,Program在中国的公司中几乎都没有这个职位 ,这一点IBM和E还是很象的,估计是谁学谁的,非常讲究做计划和监控.讲究长远目标和短期任务的平衡.对业务及时进行计划和调整.

又扯远了,里面提到:

提高质量,加速面市.

降低风险和成本

利润更高和高优先级的业务保持一致.

到了项目级别

度量项目的业务效益/优化投资次序(Compromise),了解业务价值,管理风险和变更. 呵呵,也是Program的内容.


高层管理

强调共同的愿景,行业环境,成果 .


产品线管理

Life-cycle Collaboration ,帮助上下游的企业成功,这也是国内公司比较缺少的,可能也是现实吧.

强调产品组合管理,我感觉这也是E和H比A做得好的多的地方,各产品线互相协作,差异化竞争,以整体的Solution,开发新业务和发掘潜在需求,不断改进自己,面向客户和市场.而不是互相挤压,单以降低成本外包来占领市场.

运营和供应链优化,这个Topic会上谈得不多我的理解是外包和采购等管理,产品需求的澄清和验收工作是我对这部分理解到的要点.

Manage transformation,system external ,internal requirement ,effort, cost 这些都是产品管理中的要素和其他公司也差不多.

软件的成本,复杂性,地方差异,孤岛,变更等等太多成为了项目或产品失败的因素.很多时候我们得到了短暂的成功,却付出了更高的维护代价和成本,并且拘泥于各种指标的约束,不敢创新,害怕犯错,害怕风险,最后被竟争对手超过,导致市场分额不断下降,人员越来越少..


产品名称    优先级,类别  分配人

----------     ----

任务列表   问题,问题描述  需求,设计 ,系统设计图


工作效率

里面提到了一个重要的问题,人的工作效率取决与他能获得多少信息,

这点大公司和小公司很不一样,大公司尽可能给于你所有的信息,小的地方则倾向各种信息的封闭,不过可能也是怕泄密吧.大公司的思路是让老员工做更有 挑战的和新业务相关的项目,新员工去做维护以熟悉业务,以求把产品做强和做大,这一点IBM也是这样,下午的中国区老板就是研究Agile,云计算和复杂 系统建摸等新课题.

里面提到的需求关联到测试用例我觉得很不错,如果需求有更新时,负责此部分用例的人员会收到通知.

所以这个软件的协作管理做得还是很不错,只是和中国的现状还有些差距.

里面的自动化部署框架我很感兴趣,提到了通过UML部署视图可以直接把构件和应用部署到服务器上并重新启动.

里面还提到了一些其他的工具如影响分析工具,文挡自动生成工具 软件:Jazz管理软件的生命周期等.难怪他们能占领高端市场,的确解决了很多软件工程的问题.

包括下午提到的我最疑惑的大项目的敏捷管理的问题.


规划

1.实时规划  Real time planning


图片

这个图最复杂,其中很多公司里面的定义都不清楚,特别是象以前接触过的某个公司,里面的领导实际上并不懂技术和业务,但是特别喜欢做技术决策,结果 搞得一遍混乱,本来小公司人员兼任的角色多一点是正常的,但是有时候如果不注意听取下面的意见时就会出很大问题,这点上面感觉IBM和E都非常好,技术专 家和项目管理,业务专家,产品规划,产品线规划和高层领导各负起自己的责任,互相协作和牵制.当然,缺点也很明显,一个大的项目居然要十几二十几个人做决 策.特别是涉及到不同产品线的项目和产品的对齐,更加复杂和有挑战.

听下来感觉大项目,的确靠邮件是个很大问题,即时工具好点,但是也很难查询历史追踪和信息共享,特别是项目结束后给后面项目和人员留下的财富,所以 还是用软件管理好啊,只是很多公司不愿意花费这个Cost,其实其他方面维护或修复Bug带来的成本可能远大于这个花费, 呵呵,


2.生命周期可规划性. 客户 - 产品--构建工件 -环境 -支持系统 - 需求管理

概念阶段 --  Deep Insight -- 到Artifact (工件) ,到质量改进 到下面一个的循环.  持续改进 是很多人不愿意的,但是必须要做的.


提到几个指标:

交付速度.

质量

时间和价值

可预测性

成本 


强调方法和流程,工具是辅助的,是用来提高效率和进行共享的. 这个也是很多人不太愿意接受的.

Retrospective, encouragement and play show .

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/24478210/viewspace-707213/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2010-08-24

  • 博文量
    5
  • 访问量
    10731