[思辯] 專案管理

看板ask-why作者 (校長阿貓)時間14年前 (2010/06/08 09:16), 編輯推噓2(2推 0噓 8→)
留言10則, 1人參與, 最新討論串1/1
推
06/07 21:40,
那倒不;這篇我覺得很切題.其實在專案分析時 top-down 或
06/07 21:40
→
06/07 21:41,
down-top 是會爭論不休的;爭論是因為根本做不出來在搶資源
06/07 21:41
→
06/07 21:41,
如果有一個強者能拍胸脯:我知道花多少錢多少時間保證做好
06/07 21:41
→
06/07 21:42,
那不管任何一種分析他都能用,也都會充滿說服力.
06/07 21:42
→
06/07 21:42,
top-down:從PM角度,想做多少東西開始切割功能,凡自己做不
06/07 21:42
→
06/07 21:43,
到的就發包出去;down-top:工程師就自己做得到的提出報告,
06/07 21:43
→
06/07 21:43,
並且要求PM不要提出太強大的產品需求.從以上兩者的比較來
06/07 21:43
→
06/07 21:44,
說,使用者反正什麼都不知道,連要花多少錢都不知道,比較像
06/07 21:44
→
06/07 21:44,
PM,需求丟出去在等別人喊價錢.
06/07 21:44
→
06/07 21:45,
我是屬於工程端,所以我會說我能做到什麼,超出的不談
06/07 21:45
→
06/07 21:46,
而做得到的是能力所及,代價能預估,才能夠詳談.就以架一個
06/07 21:46
→
06/07 21:46,
SQL Server 來說,我已經架過,我就可以談了;也就是我常說的
06/07 21:46
→
06/07 21:47,
"要縮小題目";其實原PO一直擔心的"服務公司倒閉則服務不存
06/07 21:47
→
06/07 21:47,
在",那也是他一直以為這些全是網際服務.其實自己架Server
06/07 21:47
→
06/07 21:48,
弄成自家的桌上服務,那根本就沒有倒閉的問題,那是他自己一
06/07 21:48
→
06/07 21:48,
直沒去看通的.如果我現在還有八位元的蘋果電腦,我當然必需
06/07 21:48
→
06/07 21:49,
保留 MarketPlan(八位元的excel),那是當然的啊!
06/07 21:49
→
06/07 21:50,
難道原PO必需學會寫程式,自己寫一套試算表嗎?
06/07 21:50
→
06/07 21:51,
把已經做好,能用的提出就已經夠了;至於圖書館學,或我說的
06/07 21:51
→
06/07 21:51,
資料庫如何規劃,那流派多,有專版,他得自己想法子.基本上如
06/07 21:51
→
06/07 21:52,
果我用編年,找封情書應該不必三秒.
06/07 21:52
老實說...我無法體認H大所謂很切題~是怎麼個切題... 不過針對PM的議題，可以來聊一下 一個專案進行規劃時，down < - > top 本來就沒有標準答案 去爭哪種比較好根本沒意義，一切端看你面臨的情境是怎樣 如果時間緊急、領域熟悉、你本身又掌握大量資源調派權 那top-down 是較佳解，高層說了算數~ 趕快去做先 當然缺點也是有：容易出錯、容易把事情想太簡單....但是既然前提說了: 這是你熟悉的領域、過去經驗比較能支援，同時又有資源做為後盾 評估錯了大不了繼續砸投資就是 反過來 若一個案子很陌生、資源不多、你的資源調配權很低、時間允許 當然要請底層的資深工程人員一一評估 整匯來自基層的經驗，down2top 去擬定範疇和工作包，當然能比較不出錯 專案本來就是拳頭與舌頭的戰場 你愛說大承諾不拘小節，就要有相當風險應變資源...這有啥好爭的? 實務上爛人很多，也不損此原則正確性 -- 至於圖書館學，根本跟啥程式軟體無關，在沒有計算機的年代 人家還是可以用紙卡管理的服服貼貼 基本架構早已確立，資訊化只是降低人工作業、加快速度 我認同你說的舊系統包袱，不然現在大家也不會瘋web service 雲端運算其中一目的，也是要解決資料儲存的問題 除非今天世界末日~~全世界的server全死 不然總是有一地方data center活著，復原就有希望 年代編排只是最基本索引方法 編碼、拆號、索引邏輯....都還有很多有趣的前人智慧 如果要問個資訊人管理 我只問你手上有什麼搜尋工具~~例如Windows自己的檔案索引功能 要善用此功能，當初在資料夾分類、檔案摘要等資料 就要以此搜尋引擎為中心去建立註解 ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 203.65.106.8 ※ 編輯: Ycat1911 來自: 203.65.106.8 (06/08 09:42)
推
06/08 13:06, , 1F
我把專案形容成惡水,down & top 為水的兩端要搭橋,不管哪
06/08 13:06, 1F
→
06/08 13:06, , 2F
種方法,只要沒接到對岸,都是失敗的,橋都要垮!但我們也可以
06/08 13:06, 2F
→
06/08 13:07, , 3F
在河中立橋墩,先搭到橋墩就好,這樣就不會垮;這個墩就是
06/08 13:07, 3F
→
06/08 13:08, , 4F
milestone,它必需能做到中程成本回收,就像預售屋一樣,邊蓋
06/08 13:08, 4F
→
06/08 13:09, , 5F
邊賣.如果一個里程碑達到了卻不能賣,主管還要說"繼續努力
06/08 13:09, 5F
→
06/08 13:09, , 6F
中間產品很棒,但仍是0分",那就沒有用,你就要繼續撐住投資
06/08 13:09, 6F
→
06/08 13:10, , 7F
中間產品如果能有五十分,做不到也開賣,那大家才真能鬆口氣
06/08 13:10, 7F
→
06/08 13:11, , 8F
被引用那篇我覺得切題是因為,它是個我認同的橋墩!
06/08 13:11, 8F
→
06/08 13:11, , 9F
橋墩在方向上也必需在兩端的中間;方向正確,成本回收
06/08 13:11, 9F
你所論的里程碑，和風險控制中的小規模試作意思一樣嗎? 里程碑定義上沒有包含成本回收吧 ※ 編輯: Ycat1911 來自: 203.65.106.8 (06/08 15:03)
推
06/08 15:05, , 10F
定義上沒有啊,但實務上這樣才能讓股東喘口氣,不然你錢多啊
06/08 15:05, 10F
XD ※ 編輯: Ycat1911 來自: 203.65.106.8 (06/08 15:19)
‣ 更多 Ycat1911 的文章
文章代碼(AID): #1C3PdOcj (ask-why)