2011IBMRational創新大會日記-規劃

xiaochouyu21發表於2011-09-13

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/,如需轉載,請註明出處,否則將追究法律責任。

相關文章