各位： 我自己開發了很多的應用程式，老板叫我做個報表，市場價格與自己開發成本相比較，我怎麼樣估計我開發的程式的價格呢。。

引言: 各位： 我自己開發了很多的應用程式，老板叫我做個報表，市場價格與自己開發成本相比較，我怎麼樣估計我開發的程式的價格呢。。

抱歉,小弟靈感來了,以下提的可能有點偏題了,還請包涵 這是個很好的策略管理題目,外包與自製的差異,在達成同樣目的的前提下,自製與外包的差異何在? 一.外包的效率與溝通成本 就效率來看,若外包商的能力可行且交件速度快,那麼外包的時程可以有一個可靠的評估標準,然而額外衍生的負面因素可能是需求確認溝通的成本,包括文件的製作等,畢竟同一家公司內管理者總是與員工有著日久生情的默契在,也很可能是糟糠妻總是不需要太過甜言蜜語,例如: "叫你做你就去做,問東問西,確認這個確認那個,我是老闆你領我薪水,生不出來你給我滾蛋" 如果是外包人員呢? "林先生這樣的需求您清楚嗎?不清楚的話我請我們家的艾蜜莉把需求以一個制式化的文件製作與您並請她密切與您配合協助您" 二.自製的大鍋飯人性因素與管理成本 如果自製,那麼負責的員工如果怎麼做都是固定一個月二萬八,做得好沒人鼓掌做得不好眾人唾棄,那麼大鍋飯的心態就不得避免了,因為環境造成的人性因素在自製時很難去避免,除此之外為了要破解這個自製所衍生的盾勢必得製作一支矛來與之對抗,那就是管理成本,主管必須花費額外的時間心力去進行監控拿著皮鞭在後面抽打 "那個給我跑最後一個的等一下就倒大楣了,我就讓你再多跑

不管怎麼算，自己開發的一定要比外面便宜，否則老闆要砍人囉。 除非是管理上軌道的公司，軟體外包才能降低成本，也才能用套裝軟體。因為外包的風險也是很高的。

引言: 不管怎麼算，自己開發的一定要比外面便宜，否則老闆要砍人囉。 除非是管理上軌道的公司，軟體外包才能降低成本，也才能用套裝軟體。因為外包的風險也是很高的。

自製一定比外包便宜,那麼使用3-party元件來設計系統的公司不就都是經費充沛且老闆不會砍人? 核心能力放在商業邏輯上的MIS軟體公司是否就必須一定要有設計所有配套的元件?諸如Grid,Chart,Report等component都自行研發,well,假設該公司有個超人,那麼超人的薪水該給多少,超人是否會不會可遇不可求? 超人花了五年的時間把工具做好把component設計完全,那麼這五年的收入怎麼來呢?如果公司沒有其他產品線來support,那麼這五年如何度得過呢? 管理上軌道?那麼什麼樣的管理是所謂的上軌道,評斷的標準如何? 管理上軌道才能降低外包成本?管理是指內部的管理?外包的公司也需要去進行管理?何必設定驗收日期?何必設定交貨時間呢?何必訂合約? 套裝軟體,因為管理上軌道所以外包才能降低成本,那麼與套裝軟體的因素有何關聯?又套裝軟體,完全不客製化叫做套裝軟體?那麼目前來看完全不客製化的套裝軟體的產品生命週期與外包,與管理又有什麼關聯呢? 外包的確有風險,那麼風險很高,是否可以避免,以及風險到底高到多少,如何評估? 用三言兩語眉批式下註解談個人看法,不可避免的還請具體說明,不然這樣的討論是沒有意義的. 發表人 - hahalin 於 2005/07/24 13:25:05

引言: 自製一定比外包便宜,那麼使用3-party元件來設計系統的公司不就都是經費充沛且老闆不會砍人? 核心能力放在商業邏輯上的MIS軟體公司是否就必須一定要有設計所有配套的元件?諸如Grid,Chart,Report等component都自行研發,well,假設該公司有個超人,那麼超人的薪水該給多少,超人是否會不會可遇不可求? 超人花了五年的時間把工具做好把component設計完全,那麼這五年的收入怎麼來呢?如果公司沒有其他產品線來support,那麼這五年如何度得過呢?

舉 3rd-Party元件的例子, 似乎太過極端, 若依此說法, 自製則勢必還要自行開發作業系統及編譯器等環境, 甚至連硬體設備都要自已來, 這實在太過荒謬!

引言: 管理上軌道?那麼什麼樣的管理是所謂的上軌道,評斷的標準如何? 管理上軌道才能降低外包成本?管理是指內部的管理?外包的公司也需要去進行管理?何必設定驗收日期?何必設定交貨時間呢?何必訂合約?

什麼樣的管理是所謂的上軌道? 這問題值得深究; 管理除內部管理外, 委外的配合廠商當然也需管理, 駐廠品管實地監工就是為了能確保專案時程不會有太大的變動. 為何設定驗收日期及交貨時間? 這是為了避免影響專案時程, 且檢視外包商是否能如期完工的重要指標, 能愈早發現外包商能力不足無法完成專案, 也就能趁早更換廠商, 避免無謂的浪費. 至於為何訂合約? 不訂合約, 上述所說的都成了屁, 沒有合約怎約束外包商?

引言: 套裝軟體,因為管理上軌道所以外包才能降低成本,那麼與套裝軟體的因素有何關聯?又套裝軟體,完全不客製化叫做套裝軟體?那麼目前來看完全不客製化的套裝軟體的產品生命週期與外包,與管理又有什麼關聯呢?

使用外廠商提供的套裝軟體就算是外包了, 許多的 ERP 套裝軟體都有提供程式擴充介面, 可自行增加修改功能或委外交由廠商處理, 若企業的需求與套裝軟體提供的功能差距過大, 這時就會考慮委外開發專屬的系統(也是外包). 使用套裝軟體的企業在初期評估多半會遇到不合用的情形, 此時可採取的常見方案:

• 再找更合用的套裝軟體(怎知是否更合用? 合用程度多少?)
• 修改套裝軟體(委外修改? 自行修改? 要改哪些地方?)
• 調整內部流程(調整時間多長? 能否有效控制內部反彈?)
• 委外開發專屬系統(能具體描述表達需求並訂定合理的驗收目標嗎?)
• 企業內部自行開發(不想考慮上述問題的最後方案, 只需考慮人事成本)

上述哪項與管理無關?

引言: 外包的確有風險,那麼風險很高,是否可以避免,以及風險到底高到多少,如何評估?

風險評估, 這也是一個大題目. 凡事都有風險, 風險高低需進行評估才可得知. 某本書上提供一個最簡單的評估方式: 當遇到不知如何評估風險的事情時, 其風險最大.

引言: 舉 3rd-Party元件的例子, 似乎太過極端, 若依此說法, 自製則勢必還要自行開發作業系統及編譯器等環境, 甚至連硬體設備都要自已來, 這實在太過荒謬!

何以 3-party元件會是荒謬之說? 願聞其詳 用 > <>< face="Verdana, Arial, Helvetica">引言: 什麼樣的管理是所謂的上軌道? 這問題值得深究; 管理除內部管理外, 委外的配合廠商當然也需管理, 駐廠品管實地監工就是為了能確保專案時程不會有太大的變動. 為何設定驗收日期及交貨時間? 這是為了避免影響專案時程, 且檢視外包商是否能如期完工的重要指標, 能愈早發現外包商能力不足無法完成專案, 也就能趁早更換廠商, 避免無謂的浪費. 至於為何訂合約? 不訂合約, 上述所說的都成了屁, 沒有合約怎約束外包商? 駐地監工,請問這是蓋房子還是造捷運呢? 到了驗收階段才發覺外包能力不足,是否在尋找外包商的時候就過於草率,如果到了這樣的情況,那可以說已經是一個失敗的專案. 訂合約跟屁有什麼關係呢? 還請不吝說明

引言: 使用外廠商提供的套裝軟體就算是外包了, 許多的 ERP 套裝軟體都有提供程式擴充介面, 可自行增加修改功能或委外交由廠商處理, 若企業的需求與套裝軟體提供的功能差距過大, 這時就會考慮委外開發專屬的系統(也是外包). 使用套裝軟體的企業在初期評估多半會遇到不合用的情形, 此時可採取的常見方案:

• 再找更合用的套裝軟體(怎知是否更合用? 合用程度多少?)
• 修改套裝軟體(委外修改? 自行修改? 要改哪些地方?)
• 調整內部流程(調整時間多長? 能否有效控制內部反彈?)
• 委外開發專屬系統(能具體描述表達需求並訂定合理的驗收目標嗎?)
• 企業內部自行開發(不想考慮上述問題的最後方案, 只需考慮人事成本)

上述哪項與管理無關?

原問是完全不客製化的套裝軟體延伸的提問?您答非所問在先,提了ERP的例子,是否可以具體說明哪幾套ERP是如原問所說的套裝軟體也同時具備您所提的可以提供外擴程式的架構?相信很多朋友都很有興趣想要了解.

引言: 風險評估, 這也是一個大題目. 凡事都有風險, 風險高低需進行評估才可得知. 某本書上提供一個最簡單的評估方式: 當遇到不知如何評估風險的事情時, 其風險最大.

某本書?那本書呢? 不知如何評估的事情風險最大,用您的語言來說 不就是....... 屁話一句嗎? 發表人 -

引言: 各位： 我自己開發了很多的應用程式，老板叫我做個報表，市場價格與自己開發成本相比較，我怎麼樣估計我開發的程式的價格呢。。

有點火藥味 ! 題目是 : 我怎麼樣估計我開發的程式的價格呢 ? 我認為 : 單純以 (薪資 * 工時) 就好了. 比較難的是市場價格. 是你進度太慢 ? 還是工作太多, 作不完 ? 還是沒作好, 不好用 ? 否則, 評估的角度, 應該將風險的成本列入! ... 天呀 ! 怎樣估 ? 審計學都不見得有教. 你看, 是不是越來越複雜 從評估報告下手好了, 列出不同的專案開發模式,

覺得很奇怪 電腦資訊業 真的有這樣難理解嗎? 如果角色變換成餐廳的boss與主廚 vs 菜單,菜色,價格,等 要外包不是必要與不需要 是依客戶要求時間內是否可行為主 一家做海產的餐廳因與boss是朋友 所以喜宴朋友以川菜為主 boss為了理子與面子 當然是外包找同業卻不一樣專業的 川菜餐廳 來協助並監視 同一市場卻不同需求的產品 其實 此題的問題 另人好奇 1 我自己開發了很多的應用程式，老板叫我做個報表，市場價格與自己開發成本相比較 自己寫了很多程式卻不知價值性 是好還是壞 庵不能說 boss的心態延伸幾個 疑問 A boss也不知道你寫的東西 價值在那 那寫那些東西如何賣 B 一個公司不知道價值在那 那應該朝研究不該朝商業 因為包慘耶 所以最缺的是業務與PM C 公司都群龍無首了 唯有精忠報國 2 我怎麼樣估計我開發的程式的價格呢 工程師的專業不在於市場開發與市場規劃 所以上述 應該快找專業PM與 業務 不然你的報表 應該是紙上談兵永遠想的多做的多卻賣不多 有點火藥味 沒關係 討論中不乏 黑與白之顏色 激辨代表 雙方已有感覺 哈哈 順便加上 庵這味 燒焦味 來亂耶 哈哈

引言: 我認為 : 單純以 (薪資 * 工時) 就好了. 比較難的是市場價格.

人×月這是看似最有效且最直接的估計方式 不過喔,小弟有個朋友叫做大頭宏,因為他待的都是小公司,小公司就是一個人得當好幾個人用,有的時候老闆跑出去天馬行空,然後案子砍回來就是去寫...去寫...去給我寫... 曾經出現過這樣的對話,大頭宏拿著老闆大人用著比草書還要草的自加上鬼畫符丟過來就說就是這樣寫... 大頭宏:"啟稟老闆大人,請問一下這樣的資料轉入,客戶自己的excel檔案欄位有些對應不到產品基本檔跟bom表,這是否需要與客戶做規格確認" 英明不可一世的老闆一號,皺了皺眉頭:"這沒有你想像的那麼難啦,反正程式我不懂啦,客戶說要這樣就這樣" 基本上呢,大頭宏的老闆有好幾個,其中有的管程式,有的管業務,有的連table是什麼都不知道就可以背著notebook去談專案修改,然後聽不懂什麼叫做系統分析的編制,在他的腦袋裏面只有我去談案子收支票,你寫出來領固定薪水,如果寫得夠快分個兩千塊錢給你,還算是對你夠好. 然後呢?這位苦命的大頭宏得費盡千辛萬苦飽受責難繞過這個老闆一號去找老闆二號去請老闆一號把客戶的需求用講的講清楚,然後老闆二號再跟大頭宏口述,然後大頭宏偶爾會在汨羅江畔邊徘徊邊念 "獨孤臣孽子,其操心也危，其慮患也深，故達" 轉而提出建議 "臣啟奏,此項功能確認可否有制式文件,一來溝通有憑有據,二來日後也能賴以之維護" 老闆二號使出拖字訣:"先寫出來再說,這個已經拖延一段時間才到你手上,是我的錯沒能妥善安排,總之你先這樣寫,客戶有什麼變動再說再說" 大頭宏一邊吃著粽子一邊在汨羅江畔徘徊,唉 "悠悠我心悲,蒼天何有極!" 自此,就在大頭宏的很不吉利的神機妙算當中,這個因為需求不能確認,老闆一號一意估行,老闆二號拖字訣想著事緩則圓,不沾鍋是行事準則下,這個很簡單的資料轉入來來回回一共扯了兩個月才終至底定. 由此案例來看,若由人月來估計,假設大頭宏一個月的薪水是30k台幣, 估計需求確定的前提下,兩個禮拜可完成加上測試,那麼 30k × 0.5=15k 然而實際上呢?大頭宏有可能只需要負責這個小小的,老闆一號口中的你想得太難的一個轉入的程式模組嗎?答案當然是否定的,大頭宏本身還有一些雜七雜八的其他的需求變更,bug修改,報表撰寫... 偶爾還得聽到老闆一號仰天長嘯 "怎麼都找不到人才的啦,我這麼厲害這麼會砍案子怎麼沒有可以與我匹配的人才可用呢?" 如果真的用人月來估計 大頭宏完成這個excel轉入的程式總共花了 兩個月 30k × 2=60k 當然實際撰寫程式可能只有兩天,除此之外這兩個月的溝通時間可能會碰到 1.客戶因為颱風過後忙著出貨無法跟你規格確認 2.其他緊急的不能在緊急的專案修改或是非得去滅火不然會燒光光的查bug等事情插單進來. 3.老闆一號與老闆二號鬧情緒彼此冷戰了兩個星期 於是呢,原本兩個禮拜完成的變成兩個月,而交件給客戶後客戶發現哪裡那裡當初講錯了於是又再度來回修正,於這這兩個月可能又要再度延長,也許時間部會佔太多,但就是會影響到其他原本預定要安排的工作. 於是schudule delay,造成連鎖效應,南美洲的一隻蝴蝶拍動翅膀引起了南海大海嘯雖然不至於發生,但是骨牌效應也是有的. 各位看倌,您說,人月真的這麼精確嗎? 發表人 - hahalin 於 2005/07/26 00:02:52

引言:偶爾還得聽到老闆一號仰天長嘯 "怎麼都找不到人才的啦,我這麼厲害這麼會砍案子怎麼沒有可以與我匹配的人才可用呢?"

哈哈 標準ㄟ 高砲業務型 哈ㄏ h sir 真好玩 哈哈 你要不要出一版 delphi與香雞排 庵再買一本 哈哈 超真實有趣 奧客列傳 是否又要出 期待 哈哈 http://delphi.ktop.com.tw/topic.php?topic_id=26088 http://delphi.ktop.com.tw/topic.php?topic_id=25959 http://delphi.ktop.com.tw/topic.php?topic_id=25968 http://delphi.ktop.com.tw/topic.php?topic_id=25980 再來一次 哈哈

引言:

引言: 我認為 : 單純以 (薪資 * 工時) 就好了. 比較難的是市場價格.

人×月這是看似最有效且最直接的估計方式 .. 略 .. 各位看倌,您說,人月真的這麼精確嗎?

所以, 美式管理是要寫 Plan & Report , 周末交 plan , 周一交 Report 然後, 才能從多工處理過程中, 算出 Time Share 的時間 ps1. 我知道大家都不喜歡寫, 理由很多, 也不容易做到, but 這就是數據的來源, 也就是資訊人員常講的, [要先公司建立制度,然後電腦系統才能導入] 的根源 ps2. 神遊的時間, 要平均分攤在實際工作的時間裏 ! ... Sorry 太囉唆 ! > 回應一下

引言:你寫的程式到底有多少價值 ? 是否該換成 [對公司的貢獻度] 會比較好呢 ? 不過, 這就離題了.

cwc65536 你好 被人善意糾正美化 也是很好的啦 討論 離題對庵 沒關係 因為 有人感覺到庵就算是 盡力了 誰叫庵自己取conundrum這名稱 哈哈 目前3方車輪戰 各論一方 不K不相識 哈哈 發表人 - conundrum 於 2005/07/26 00:24:13

事隔多年,回來看當初這個其實加油添醋弄了很多有的沒的情節進去的奧客列傳,其實是搞笑居多,當中有百分之七十的情節都是杜撰而來,說實在的如果讓一些有志於從事MIS軟體設計的有志青年看了後很可能會有誤導觀念的隱憂在. 這也是策略管理的好題目,關鍵在於選擇,創業與上班 1.現金流 一人公司,要創業,是否有足夠的資金可以支持,光是靠技術,是否就是全部,是要作出一套基本型的進銷存 會計,然後鎖定某個行業來作? 那麼,光是這個基本型的架構就要設計多久呢? 是否投入足夠的時間? 投入足夠的時間是否能做出擴充容易,進可攻退可守的架構呢? 又,回歸最單純的是否這段投入的時間會無法兼顧需要填飽肚子的工作所需投入的心力呢? 2.競爭者 再來是競爭者的威脅,這樣的系統,就算是單純的不能在單純的會計系統好了,是要做單純的總帳會計,還是細部到能整合進出貨單,帳款,票據的功能呢? 是否市場上已經有老神在在運作很多年可以直接套用且價廉物美的套裝軟體呢? 似乎是偏題太多,喧賓奪主了,看來得開個new post來瞎扯淡一番了.

引言: 所以, 美式管理是要寫 Plan & Report , 周末交 plan , 周一交 Report

個人覺得,就像資料結構裡面的 prefix,infix,postfix 的差異,需求不清楚,要用以戰養戰,大家來打混仗,千錯萬錯絕對不是去接案子的人錯,是寫出不來的人的錯,或是來個哀兵之計: "公司要生存,所以不得不搞這些有的沒的讓客戶蹂躪的事情,你就多體諒,乖乖去寫程式吧"(之後的需求變更東改西改最好自己自覺一點記得今天所講的多"體諒"一點) 然後呢,偶爾老闆閱讀了什麼企管文摘或是偶爾聽到其他的老闆大談有效管理這些自以為是絕地武士,哈利波特的程式臭屁匠,就會來個工作日誌工作週誌或是工作月誌. 一個禮拜兩個禮拜,還有心思看,三個禮拜四個禮拜,大概看也看累了,因為呢原本只是 "將前人寫錯的錯誤sql修正,報表輸出的金額修正成與系統參數的小數位數設定值同步" 會因為寫太少會被扣上工作不認真因而演變成 "由於之前的需求確認有誤,經過與客戶有效的溝通後取得共識,並將需求確認更新,將傳遞至RDBMS的擷取資料命令加以修正並且最佳化後,經過驗證得到正確的結果,並且將報表顯示的金額使其小數位數的顯示位數,修正為取得客戶透過執行SYS08功能所設定的出貨單小數位數顯示位數後,將之顯示位數值透過設定報表上顯示欄位物件的format屬性後,完成此項連結系統參數的功能" 後,可能會讓程式人員的文筆越來越日益精進,而系統的進度仍然沒有改善!老闆呢,第三個禮拜可能就開始懶得看,於是第四個禮拜開始就有人忘記交了,到了第五個禮拜第六個禮拜可能就沒人記得這件事情,於是過了兩個月也許老闆想起或是系統又出槌了,於是又重新上演一次交周記的戲碼,更可能從週記變成日記. 原本應該是 prefix,很可能遇到現實的因素或是種種總是老闆要說服你要接受的因素會變成infix,或是 postfix後,這些額外增加的生活周記,就會變成要嘛 1.老油條不甩老闆,繼續埋頭苦幹,結果老闆老大不高興失去老闆的威風開始找碴,於是乎可能過了兩個月老油條被氣跑了,菜鳥臨時上陣.... 2.中鳥把持著不要爭第一也不要落隊跑最後的當兵明哲保身最高指導原則,把生活周記寫好,至於進度喔,過得去就好啦. 3.菜鳥戒慎恐懼,把生活周記寫得很好,幾乎是每日及時更新,到最後發現生活的重心變成生活周記,系統到底要怎麼做好像又不太清楚了 所以呢? 有效的管理應該立基於是否讓這個project一開始就是有效的被分析以及分配,並且訂定里程碑來定期檢驗,修正再出發,如果一開始就是混沌,那麼infix甚至是postfix的要求再要求,會得到什麼好處呢? 相對的,如果prefix的基本動作就好,馬步扎穩,出拳自然有力道,進彎點抓得精確,就不用擔心出彎會甩尾失控,有了這個做基礎,接下來要infix,或是postfix自然就能有效掌握,水到渠成了. 很多時候老闆或是主管會抓狂,然後來個大地震要求這要求那,不外乎是因為自己的決策失誤造成來自客戶,更高層主管的壓力,原本以為自己可以無為而治或是像NBA教練一般梳著大油頭穿著名牌西裝在鏡頭前擺擺姿勢就能夠讓手底下的明星球員攻無不克戰無不勝的優雅不復存在,轉變成鐵血教頭開始讓愛的教育轉變成鐵的紀律. 對了,我的好朋友大頭宏又來插花了,他說: "有誰希望案子結不了呢?案子結不了我會多幾塊肉嗎?不,多吃幾次麥當勞或是逢甲雞排才會多幾塊肉,而且喔,要我一整天呆在電腦前面裝模作樣不做事,說實在的這好像比專心coding還要來得累的呀!" 我說,古諺有云 "凡事豫則立 不豫則癈"

h sir 宏哥 哈哈 必竟任何東西 過與不過都很難拿捏 公司中如果團隊的種種 有如豆芽菜一般 就如現在的此篇 問者也不知道 我們這麼會離題 哈哈 阿甘電影 不是有個巧克力的說法 哈哈 “生活就像一盒巧克力：你永遠不知道你會得到什?” 哈哈 隨緣 就像這一篇㊣ 版主所po 讓庵笑了數分 http://delphi.ktop.com.tw/topic.php?TOPIC_ID=75610 發表人 - conundrum 於 2005/07/26 01:21:38

引言: 就像這一篇㊣ 版主所po 讓庵笑了數分 http://delphi.ktop.com.tw/topic.php?TOPIC_ID=75610

呵...小弟就是覺得它"有趣",才po上來跟大家分享分享

haha兄, 果然深思熟慮, 出口成章 小弟不才, 應對如下 : 現金流 : 看你的慾望有多少囉 ! 一人公司生產力有限, 服務客戶的能力有限, 所以沒辦法有相乘的效果, but 領個薪水,養家活口, 還是有的! 當他努力多年,累積相當的能量後, 為了突破現狀,達到相乘的境界,就該思考如何變通. 該投資還是得投資, 不然, 就混呗 ! 競爭者 : 既然是行業別, 重點就不在 會計 進銷存 but 沒有,則是行銷弱點, 也就是起碼要有, 不夠再客製化. 我不是要作套裝軟體! 這裏有兩個重點: 允許變成標準功能的把關能力 與 彈性方便的系統工具 老神在在的套裝軟體 : 怎樣與行業別系統整合 ? and 功能繁雜反而是導入的障礙. 況且, 知名品牌, 不見得便宜.

我的欲望: 嗯,一個30歲的已經算是不怎麼年輕的單身老男生,我的欲望,大概是一台跑得快的車,一段穩定的親密關係(當然是女的),可以存錢的薪水(註1),一個不算入錯行的職業,能夠在程式設計的學習與應用領域累積更多的成就與感動,我的慾望很多,隨著年齡的增長慢慢的會有所取捨.    產品與客製化: 其實喔,一個資料庫應用的系統,大部分解後,不外乎就是一些資料的輸入,查詢與搬動,至於是會計系統或是進銷存系統,是不是行業別套裝或是客製化,客戶用得著,系統設計出來可以合理好操作,那麼就會有行有市,換句話說如果這天平的兩端失衡了,那麼有需求沒有供給,或是有供給沒有需求,兩條線無法交會,那麼就無法得到一個價錢,以及估計出來的利潤.(這...不是屁話嗎?  ) 其實喔,混口飯吃活下去,不難,難的是資源有限而人的欲望無窮,又回到欲望兩個字. 註

聽大家講這麼多。 何不去看看很多很多很多年前就出版的一本書 人月神話。 它說明了專案管理的。。。。。。^_^ 去買去借去搶來看吧。 我桌上這本是跟客戶的員工凹來看的。^_^

引言: 聽大家講這麼多。 何不去看看很多很多很多年前就出版的一本書 人月神話。 它說明了專案管理的。。。。。。^_^ 去買去借去搶來看吧。 我桌上這本是跟客戶的員工凹來看的。^_^

暗黑破壞神兄說的這本很不錯, 已經出版20年以上了, 還適用於現在, 可見軟體專案管理(還成本計算, 風險評估 ....) 是很複雜的. 人月神話：軟體專案管理之道（20週年紀念版: http://www.books.com.tw/exep/prod/booksfile.php?item=0010254508 另外推薦二本書, 與熊共舞：軟體專案的風險管理 http://www.books.com.tw/exep/prod/booksfile.php?item=0010277845 最後期限：專案管理101個成功法則http://www.books.com.tw/exep/prod/booksfile.php?item=0010244407

引言: 聽大家講這麼多。 何不去看看很多很多很多年前就出版的一本書 人月神話。 它說明了專案管理的。。。。。。^_^ 去買去借去搶來看吧。 我桌上這本是跟客戶的員工凹來看的。^_^

看過的朋友可以提供一下讀書心得的呀!

一個軟件的價值還是要取決於市場的需求,工時*薪資好像不是太合理,又好像應該要這樣計算.還是要看看這方面的書,謝謝以上樓主的討論.