聊天活動到場10位嘉賓,他們分別是(從左往右):潘加宇(UMLChina)、殷志梅(東方通科技)、張皖秋(東方通科技)、Kristian Persson(Telelogic)、任群力(Telelogic)、于波(賽柏科技)、青潤(豐元信)、李峻(西門子)、林治宇(天融信)、吳浩剛(天融信)?,F場討論氣氛熱烈。
嘉賓介紹
主持人:首先歡迎各位參加CSDN和Telelogic共同舉辦的需求管理在線沙龍活動,我們這次活動的主題是“探索需求”,活動分為三個環節,分別就需求的啟發、需求的定義和需求的管理進行討論,活動采用圓桌論壇和在線直播的方式,網友可以進入聊天室與現場互動,活動還邀請到了來自Telelogic、天融信、北京東方通科技有限公司、西門子等十位需求管理專家以及來自各行各業需求管理的工程師,下面有請各位嘉賓做一下自我介紹。
任群力:很榮幸今天來到CSDN來參加需求管理沙龍活動,也很高興和業內的朋友見面。作為需求管理的領先方案的提供商,很愿意提供給客戶解決方案。我是Telelogic的北方區負責人,負責Telelogic 中國公司在北方地區運作的所有事宜,包括人員規劃、市場開發、銷售和客戶技術支持工作。希望有機會與大家交流,謝謝。
Kristian Persson:我叫Kristian Persson,中文名叫佩爾森,我在北京工作,是Telelogic需求管理DOORS的產品經理,主要是負責亞太地區,主要是東亞部分,比如韓國、日本、中國。我還負責Telelogic需求管理解決方案的教育、培訓工作。在過去的6年中,我一直致力于軟件行業從需求捕獲、分析、設計、實現直到測試的軟件生命周期所有階段的工作,對系統和軟件分析、設計和測試的多種過程、方法及工具有著一定的經驗。
于波:大家好,我是于波,是北京賽柏科技公司高級咨詢師,北京理工大學軟件學院客座教授,今年年底或明年年初會成為賽柏科技CMMI準主任評估師。我們公司主要為中國軟件和IT企業做軟件工程CMMI參考項目的過程改進,負責CMM、CMMI等模型與標準、軟件工程、質量管理和項目管理等方面的培訓、咨詢和評估工作,為中國軟件在世界上的崛起貢獻出我們的微薄之力。
白慧冬:我手上拿的這本書叫《需求工程》,和我寫的那本書《軟件工程之全程建?!返牡谝徽旅忠惨粯?,也叫“需求工程”。需求是整個軟件開發過程的源頭,所以我把需求看得很重要。我目前是豐元信科技咨詢公司首席顧問,主要面向國內軟件企業提供工程開發方面的咨詢服務。我還是CSDN軟工版大版主,一個在不斷摸索實踐的國內軟件工程方法和技術的親歷者。
李峻:大家好,我是李峻,我是代替我的同事——西門子智能手機研發中心需求管理經理黃謙來參加這次活動的。我是西門子手機研發中心硬件驅動部門、需求管理DOORS數據庫的管理員,我也是我們研發中心軟件流程管理項目組需求管理的其中一名Topic owner,負責相關的流程定義、文檔模板等等。我們公司用了Telelogic公司的DOORS工具來做目前的需求管理。我們產品開發的管理,也在使用Telelogic公司的DOORS工具。很想和大家分享一下項目和管理中遇到的問題。
林治宇:大家好,我叫林治宇,來自北京天融信。天融信是一家做網絡安全產品的公司。我是天融信公司CMMI過程改進和QA主管,主要負責CMMI的組織推廣和策劃工作,并曾組織多家企業實施并通過CMM2級、3級,CMMI2級評估。很高興與大家交流,謝謝大家。
吳浩剛:大家好,我是天融信公司質量部經理,曾主持過多家企業的ISO9000/CMM/CMMI實施和評估。需求在產品開發階段非常重要,今天有機會參加這樣的活動感到非常的高興,謝謝!
張皖秋:大家好,我叫張皖秋,來自于北京東方通科技有限公司,目前擔任SEPG組長、SQA經理,主要負責軟件質量的改進的工作。今天非常高興參加這樣的座談會議,希望在這里跟大家交流和探討,需求非常重要,以需求為驅動,使項目改進能夠得到一個更好的提升。
殷志梅:大家好,我是北京東方通科技有限公司產品經理殷志梅,主要是負責使用Telelogic DOORS進行需求收集與整理、需求分析,參與產品的設計,跟蹤需求的實現以及需求方案與測試之間的映射。我們公司采用Telelogic的DOORS工具來做需求管理。有些困惑,希望和大家進行交流。
潘加宇:我是UMLChina的潘加宇。一直從事一些軟件技術難題的研究,也為不少軟件企業提供過上門的咨詢和培訓服務,在座的西門子移動和北京東方通科技有限公司都是我們服務過的客戶,希望今天在這里得到需求方面的寶貴經驗。
你對需求工作是否重視?
主持人:談到需求,我想了解一下大家對需求的態度是怎樣的,所以現場做一個小的調查。我這里有一個調查問題:下面哪一句話比較符合您的情況,我按照A、B、C、D說一下,然后大家舉一下手。A項,我認為需求不重要;B項,我知道需求重要,但不知道為什么重要;C項,我知道需求為什么重要,但不知道怎么去做;D項,我知道需求為什么重要,也知道怎么去做。我想知道大家選哪項。
看來大家選D項的比較多。
我們這個問題同樣在網上做了調查,我們可以看一下網上調查的結果。選擇“我知道需求為什么重要,但不知道怎么去做”,也就是選C項最多。大家可以就這個結果做一個大致的分析。
潘加宇:我覺得這很正常,知道需求為什么重要,他不知道也得知道,因為事實非常的簡單,他要搞不定這個需求,將來客戶那里馬上就得返工,所以知道需求重要。
我們現在很多團隊知道需要重要,也想改進,但實際上很多時候改進不了,就是因為不知道怎么去改進,不知道怎么去做。比如我們經常說一定要做好需求,各個團隊都有這樣的想法,很可能在整個工作量當中也為安排了時間,實際上真正去做的時候,不知道怎么去做,去客戶那里找誰,問什么問題,怎樣做調查,這些技能都沒有掌握,去了以后不知道怎么去做,結果就不了了之了,干脆這個時間就去編代碼。
為什么很多開發急于馬上進入設計和熟悉的階段,因為是他熟悉的,也是會做的。因為做熟的東西,做的時候很舒服。有些需求沒有掌握,知道重要,不知道怎么做,最終做需求的時間很容易虛度掉,或者急急忙忙做開發和設計。所以,現狀是非常的符合我們現在開發的情況。
需求工作流占你的整個項目工作量的比例有多大?
主持人:選擇D項的也很多,就是“我知道需求,為什么重要,也知道怎么去做”。就像李峻所提到的一樣,有很多人知道怎么去做,但做的情況下未必按照正確的方法做,所以選這一項也很多。但盡管選擇這一項,在實際的需求工作當中,也會經常面臨很多問題。我們下面進入第一個話題,需求是怎么來啟發的,怎樣來從你的客戶那里獲得需求?
主持人: 首先請問大家一個問題,各位在做需求工作的時候,你的需求工作流在你整個項目中所占的比例大概有多少?
林治宇:我舉一下我們一個產品的例子,我們是根據市場行業和用戶對手的信息總結的一些產品。我們最后統計了一個數字,需求工作占到我們項目的8%-10%。
Kristian Persson:剛才聽到8%-10%的需求,應該說這是非常合理的數字,這是國際上大多數公司大概也是這樣的數字,無論是做軟件還是做什么的,都是這樣的。
李峻:我想問一下Kristian Persson,還有壓縮的可能性?如果有好的一些工具的話,能否再縮短工作量嗎?
Kristian Persson:10%一般是比較正常的數字,如果再壓縮的話,可能比較困難。我指的10%并不是一開始需求的階段,而是與整個活動相關的需求都包括。有的項目需求花的時間更多,就是因為在有問題的時候,有時候不能確定需求,工作量達到了40%-50%。
李峻:我認為其實和客戶的交流也很重要,在第一步需求搜集這一塊。如果你的客戶很清楚他自己的需求,可以縮短很多時間和工作量,達到大家一致需求的起點。
誰負責捕獲需求?
主持人:我們再做一個調查:在各位的公司里,都是由誰來做捕獲需求?A.有專門的需求工程師負責捕獲需求。B.由面向客戶的市場部人員;C.負責設計和實現的人員同時也做需求;D.沒有人。
主持人:我們同時再看一下網上調查的情況,選擇C項的占大多數,將近有60%。請大家分析一下產生這個現狀的原因是什么?
白慧冬:對這個結果需要指出的是,負責設計和實現的人員同時做需求,并不是所有做編碼的人都去捕獲需求,而是有一部分人在一段時間做,而并不是全部的編碼團隊都去做捕獲需求。所以會出現這個結果,負責編碼的人同時做需求比較常見。
潘加宇:現在做項目的公司,單獨設立需求工程師職位的,比較少。更多的情況是,部門經理帶著骨干做調研需求,其他人做開發。對兩種人的思維要求是不一樣的。做需求的要有集成思維,把問題集成起來去思考;而程序員要有分解的思維,問題已經給出來了,要分解成對象,分解為模塊,就可以搞定它。所以一個公司做設計的人專門做需求或者做調研,我認為這是非常有必要的。如果對產品有更高的要求,對自己軟件有更高要求的話,這應該是一個比較好的方向。
于波:剛才白慧冬和潘加宇提到這個問題,跟目前國內軟件業管理流程上還不算很規范是相關的,這個調查結果是很正常的。因為項目管理也不是做純管理,需要有技術的背景,核心工程師和客戶溝通需求,然后他們項目里面逐步把這些需求做實現。由于管理規范了,肯定會有一些專職人員,專門設了這樣的職位以做需求為主。潘加宇說得也有道理,需求工程師需要在整體上把握客戶的需求,無論產品也好還是功能開發也好,完全由做設計和編碼的人來做,他們是很難站在項目整體的高度來考慮客戶所有相關人員的需要、需求、期望以及對未來還要需要什么,這樣也會對未來的需求變更帶來一些潛在的影響。
林治宇:對剛才的60%這樣的結果,我有一個看法:并不是公司實力特別強才有資源設立專門的需求工程師的人員,而是公司要認識到這個資源對產品的重要性,才會設這個職位。
原文轉自:http://www.anti-gravitydesign.com