討論區快速選單
知識庫快速選單
掌握Salesforce雲端管理秘訣 程式設計俱樂部Facebook粉絲團 傑米的攝影旅遊筆記
[ 回上頁 ] [ 討論區發言規則 ]
你在公司工作, 參加過內部的專案開工會議嗎 ?
更改我的閱讀文章字型大小
作者 : fcwang(fortran) 程式設計甘苦談優秀好手貼文超過200則
[ 貼文 231 | 人氣 2831 | 評價 2440 | 評價/貼文 10.56 | 送出評價 6 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2011/11/21 下午 03:22:29
依個人過去的工作經驗, 當公司接獲一個軟體開發案, 在工作開始時, 會與客戶舉行開工會議(Kick-Off Meeting), 在與客戶舉行開工會議之前. 相關的專案成員應先舉行公司內部的開工會議(Internal Kick-Off Meeting).

公司內部的開工會議之目的當然是讓專案成員在開工前就能建立共識與默契, 期能書同文, 車同軌,

此項會議由專案負責人(PM)主持, 就下列各項目作說明,

    1. 專案背景
    2. 專案合約要點與工作範圍 (SOW -- Scope of Work)
    3. 專案組織 (含客戶端的專案組織與對口人員)與各個成員職務分配
    4. 內部專案時程 (與客戶所要求可能有差異)說明
    5. 專案特殊需求或可能的風險
    6. 專案策略
    7. 特殊或新技術的說明
    8. 應注意事項
    9. 回答專案成員的提問 (Q & A)

必要時, 高階主管也會列席加持, 以示公司重視的態度, 當然要辦個餐會(或下午茶)給專案小組鼓勵.
如果這個專案是毛利比較好的 (Profitable), 一般開會氣氛都是相當 High 的.

你在公司工作, 分派到新的軟體開發專案的工作, 參加過或主持過類似的會議嗎 ? 說說您的經驗與感受與大家分享.
作者 : jasper(Jasper)討論區板主 程式設計甘苦談頂尖高手上班族的哈拉園地優秀好手貼文超過1000則人氣指數超過70000點
[ 貼文 1408 | 人氣 96053 | 評價 6990 | 評價/貼文 4.96 | 送出評價 42 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人fcwang註記此篇回應為很有道理 2011/11/23 上午 10:37:29
開工會議中有一項最重要的議題就是進度的安排,必須確保每個人在該進度點上能及時的產出,否則一定無法如期完工。

每個人都幻想專職一個專案,別身兼數職,然而事與願違,腳踏兩條船算是最輕鬆的工作了。在這種狀況下,PM 有時得提出備胎方案。

承接專案之前,通常會有核心技術人員評估過,但核心技術人員未必會參與專案的開發,所以此時必須完整的交代技術架構。

檔案的統一管理、命名規則、格式的統一等等在此會議都必須明確的規定。曾經在一個 256 色的遊戲中,只因講了一句〝黑色當透明色〞,但程式與美術的認知就不同,程式認為的黑色是 RGB = 0,但 RGB = 1 在美術中看起來也是黑的,就這樣的誤差,很多圖都得修改。
作者 : jammy98(Jammy)討論區板主 站務優秀好手貼文超過3000則人氣指數超過300000點
[ 貼文 3524 | 人氣 316866 | 評價 3440 | 評價/貼文 0.98 | 送出評價 3493 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人fcwang註記此篇回應為很有道理 2011/11/23 下午 09:18:22
Kick off meeting 重點有幾個, 主要是時程, R&R.
會議中最開心的應該是Sponsor了, 因為火車終於要開動,
錢, 人, 資源都到位, 是該好好地慶祝一番,

雖然是開工典禮, 但真的很不容易呀..

公司內部的委外專案, 光是選商, 議價, 簽呈, 大概就要半年.
專案人力, 資源能一次到位的狀況, 還真少見.
把全部的資源都弄到了, 才會Call這個啟動會議.
那是一種天氣放晴的感覺吧, 雖然複雜的問題才正要開始.
作者 : fcwang(fortran) 程式設計甘苦談優秀好手貼文超過200則
[ 貼文 231 | 人氣 2831 | 評價 2440 | 評價/貼文 10.56 | 送出評價 6 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2011/11/24 下午 07:08:40

>開工會議中有一項最重要的議題就是進度的安排,必須確保每個人在該進度點上能及時的產出,否則一定無法如期完工。
>
>每個人都幻想專職一個專案,別身兼數職,然而事與願違,腳踏兩條船算是最輕鬆的工作了。在這種狀況下,PM 有時得提出備胎方案。
>
>承接專案之前,通常會有核心技術人員評估過,但核心技術人員未必會參與專案的開發,所以此時必須完整的交代技術架構。
>
>檔案的統一管理、命名規則、格式的統一等等在此會議都必須明確的規定。曾經在一個 256 色的遊戲中,只因講了一句〝黑色當透明色〞,但程式與美術的認知就不同,程式認為的黑色是 RGB = 0,但 RGB = 1 在美術中看起來也是黑的,就這樣的誤差,很多圖都得修改。
>

對於比較大的專案而言, 小組成員應該都是從一專案而終, 不可能參與兩, 三個專案或是客串參與( Part-time). 這是 PM 掌握專案進度的必要條件. PM 必須能掌握所需要的資源, 才能完成任務, 也無法對失敗找藉口.

對技術規格應以書面為之, 並且要能精準, 避免爭議. 在與客戶商討需求與技術規範, 都是錙銖必較, 因為一時疏忽, 就像 Jasper 兄所說 要花許多人力才能補救, 有時甚至無法補救.
作者 : fcwang(fortran) 程式設計甘苦談優秀好手貼文超過200則
[ 貼文 231 | 人氣 2831 | 評價 2440 | 評價/貼文 10.56 | 送出評價 6 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2011/11/24 下午 07:36:11

>Kick off meeting 重點有幾個, 主要是時程, R&R.
>會議中最開心的應該是Sponsor了, 因為火車終於要開動,
>錢, 人, 資源都到位, 是該好好地慶祝一番,
>
>雖然是開工典禮, 但真的很不容易呀..
>
>公司內部的委外專案, 光是選商, 議價, 簽呈, 大概就要半年.
>專案人力, 資源能一次到位的狀況, 還真少見.
>把全部的資源都弄到了, 才會Call這個啟動會議.
>那是一種天氣放晴的感覺吧, 雖然複雜的問題才正要開始.

開工典禮就是業務代表工作完成, PM 正式接管專案一切責任的開始. 不過兩造要交接專案, 恐怕要費一番功夫.
PM 若無經驗與膽識, 被業務單位吃定的案例比比皆是.

專案人力, 資源能一次到位的狀況, 的確少見. 但是主要的幹部必須到位, 否則風險增加.
因為遇到如果錢也解決不了的困境, PM 恐怕會鬱卒(憂鬱症).
PM 必須保有一些人脈關係, 才能解決此項困境.
作者 : jasper(Jasper)討論區板主 程式設計甘苦談頂尖高手上班族的哈拉園地優秀好手貼文超過1000則人氣指數超過70000點
[ 貼文 1408 | 人氣 96053 | 評價 6990 | 評價/貼文 4.96 | 送出評價 42 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2011/11/25 上午 11:21:24
或許是性質不同,我參與的專案有主打的,也有支援的。基本上都是說從一而終,但往往是前案未結,後案就動了,公司不可能等到所有人都有空之後才開始動工,因為等待的這一段空窗期,公司也得支付工資。

曾經有個專案,美國客戶都飛來台灣了,但該組人員卻卡在一個 bug 上一直無法解決,最後高層只好把一個精英的手上工作先暫停,讓他先搞定這個問題,這種臨危受命的狀況雖是不多見,但也避免不了。

>>技術規格應以書面為之, 並且要能精準, 避免爭議. 在與客戶商討需求與技術規範, 都是錙銖必較。

這就像在簽合約一樣,法律條文總是寫得模模糊糊的,那種似懂非懂的感覺,在簽之前總是毛毛的,深怕藏有文字玄機在,最後都不知道該簽與不簽。技術規格書也一樣,總期望能有一個完整的規格書,但這規格書可不是容易書寫的。我自己寫過,所以知道箇中滋味。
 
三個月前剛從國內一家遊戲公司的 Facebook Game 外包案脫身,案子不是我接的,我只是幫忙處理 facebook 送禮及邀請的部份,在 MSN 上簡單的描述,然後給個畫面,其他什麼都沒?我得自己去想、去規劃這一切的流程及畫面、用詞,最後再送上一個後台管理。

完工後,我告訴我朋友,以後這種沒明文規定的案子就別接了,別再陷害台灣的軟體界了。該公司的老闆就是以前我部門的主管,十年未曾見面,沒想到竟是如此的沉淪,唉!無言。
作者 : fcwang(fortran) 程式設計甘苦談優秀好手貼文超過200則
[ 貼文 231 | 人氣 2831 | 評價 2440 | 評價/貼文 10.56 | 送出評價 6 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2011/12/10 下午 03:11:41
>
>這就像在簽合約一樣,法律條文總是寫得模模糊糊的,那種似懂非懂的感覺,在簽之前總是毛毛的,深怕藏有文字玄機在,最後都不知道該簽與不簽。技術規格書也一樣,總期望能有一個完整的規格書,但這規格書可不是容易書寫的。我自己寫過,所以知道箇中滋味。
>
>三個月前剛從國內一家遊戲公司的 Facebook Game 外包案脫身,案子不是我接的,我只是幫忙處理 facebook 送禮及邀請的部份,在 MSN 上簡單的描述,然後給個畫面,其他什麼都沒?我得自己去想、去規劃這一切的流程及畫面、用詞,最後再送上一個後台管理。
>
>完工後,我告訴我朋友,以後這種沒明文規定的案子就別接了,別再陷害台灣的軟體界了。該公司的老闆就是以前我部門的主管,十年未曾見面,沒想到竟是如此的沉淪,唉!無言。
>
法律條文應該由法務人員去審閱, 甚至由法務人員與客戶端法務人員直接商議, 非吾等非專業人員可處理.
公司老闆若有風險觀念, 應該顧用法務人員或與律師事務所簽法律顧問服務, 以降低合約風險.

技術規格書的範圍應以建議書(Proposal)對客戶的需求規格所回應(Response)的內容為基礎(Baseline),
管理學上強調 先做"對的事", 才考慮做有效率的事(Do the right thing, then do the thing right.).
雖然規格書不是容易書寫的, 但是它是屬於"對的事", 不管多困難都必須去做.
作者 : ozzy123(ozzy) VC++優秀好手資訊類作業求救卓越專家C++卓越專家貼文超過4000則人氣指數超過30000點
[ 貼文 4499 | 人氣 37262 | 評價 11100 | 評價/貼文 2.47 | 送出評價 49 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2011/12/10 下午 10:11:57
IEEE-830 SRS
作者 : jammy98(Jammy)討論區板主 站務優秀好手貼文超過3000則人氣指數超過300000點
[ 貼文 3524 | 人氣 316866 | 評價 3440 | 評價/貼文 0.98 | 送出評價 3493 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人fcwang註記此篇回應為很有道理 2012/2/7 下午 10:20:21
>三個月前剛從國內一家遊戲公司的 Facebook Game 外包案脫身,案子不是我接的,我只是幫忙處理 facebook 送禮及邀請的部份,在 MSN 上簡單的描述,然後給個畫面,其他什麼都沒?我得自己去想、去規劃這一切的流程及畫面、用詞,最後再送上一個後台管理。
>
>完工後,我告訴我朋友,以後這種沒明文規定的案子就別接了,別再陷害台灣的軟體界了。該公司的老闆就是以前我部門的主管,十年未曾見面,沒想到竟是如此的沉淪,唉!無言。
>

Yes, 這種案子千萬別碰. 接這種案子, 對公司來說是成本的耗損, 很慘.
品質也難控制, 走一步算一步.

而且, 若是User沒需求, 對於做好的東西卻有太多想法.
那麼, 就會有一堆Change. Change對於專案來說, 時程, 品質, 成本都會有負面的影響.
而專案, 三大目標不就是如質, 如時, 如預算嗎 ?
作者 : fcwang(fortran) 程式設計甘苦談優秀好手貼文超過200則
[ 貼文 231 | 人氣 2831 | 評價 2440 | 評價/貼文 10.56 | 送出評價 6 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2012/2/18 下午 09:27:31

>那麼, 就會有一堆Change. Change對於專案來說, 時程, 品質, 成本都會有負面的影響.
>而專案, 三大目標不就是如質, 如時, 如預算嗎 ?

一般的習慣, 變更(Change) 會影響成本和時程, 但品質不該被影響. 除非業主自己同意以犧牲品質換取時間 或 業主不願吸收變更的額外成本(拗客).

變更對於專案來說, 時程, 成本會有影響. 但不見得都是負面的影響. 也可能有正面的影響.

過去我的經驗有客戶因為製程有了新技術的發展, 在開發的過程當中, 決定增加新的功能配合新的製程, 以免坐失商機.
 板主 : Jammy , Jasper
 > 程式設計甘苦談 - 討論區
 - 最近熱門問答精華集
 - 全部歷史問答精華集
 - 程式設計甘苦談 - 知識庫
  ■ 全站最新Post列表
  ■ 我的文章收藏
  ■ 我最愛的作者
  ■ 全站文章收藏排行榜
  ■ 全站最愛作者排行榜
  ■  月熱門主題
  ■  季熱門主題
  ■  熱門主題Top 20
  ■  本區Post排行榜
  ■  本區評價排行榜
  ■  全站專家名人榜
  ■  全站Post排行榜
  ■  全站評價排行榜
  ■  全站人氣排行榜
 請輸入關鍵字 
  開始搜尋
 
Top 10
評價排行
程式設計甘苦談
1 Jasper 3700 
2 長長 1520 
3 青衫 1300 
4 fortran 1220 
5 weber 1080 
6 HKLN.net 950 
7 冷眼 690 
8 臭蟲 610 
9 Peter.huang 600 
10 Clier 570 
程式設計甘苦談
  專家等級 評價  
  一代宗師 10000  
  曠世奇才 5000  
  頂尖高手 3000  
  卓越專家 1500  
  優秀好手 750  
Microsoft Internet Explorer 6.0. Screen 1024x768 pixel. High Color (16 bit).
2000-2019 程式設計俱樂部 http://www.programmer-club.com.tw/
0.0625