這個專案開始到幾個月前基本暫停，總共差不多花費
100人月，總成本應該也差不多是
100w
吧。在幾個月收穫的產品只有一堆中間**。當然，參與成員對某些技術還是有進步的。
我稍微對專案作一些總結吧。要想不好了傷疤忘了疼，需要總結經驗，不管是成功還是失敗的經驗，成功是乙個模式，（失敗就是反模式）。
l沒有開始的開始
,乙個噩夢的開始
前期沒有任何固定的嚴格專案可行性分析
老闆指哪兒打哪兒，就算是老闆一種模糊的感覺，下屬只能全力以赴了。這在我們這類企業裡面應該算是很普遍的。當一次回頭看，這
100w
算是做了乙個可行性的**。
l風險管理，尤其當你使用乙個有新的/先進
/陌生的技術
使用乙個陌生技術，風險是很多的，不管宣稱它有多先進。
如果在專案初期沒有進行風險的管理**，最後，這些風險不會憑空消失，一部分會出來，
block
你的專案，毀了你前面做的工作，最後毀了你的專案。
l需求，沒有遠景，沒有邊界
當專案走了很遠的時候，當需求好像無窮無盡的時候。經驗豐富的領導總算想起要做乙個邊界定義了。
如果沒有乙個邊界，需求是做不完的，滿天的麻雀，都想要抓，團隊的人力物力是非常有限的，對於乙個產品來說，市場也是不會等人的，必須要在規定的時間內出來的軟體，才有可能成為乙個成功的軟體。
l需求，脫離使用者的需求
當需求只是憑空猜測的需求，自然會讓人覺得無窮盡，因為人類想象力總還是比我們能做到的要多的。但是，這帶來的可能不僅僅是沒有盡頭，脫離使用者的需求，彷彿就是在修煉屠龍絕技。修煉出來是沒有市場的。
l需求，隔靴搔癢的需求
如 果軟體的終端使用者是經過培訓、積極配合軟體開發過程的，這個軟體的成功機率大概可以提高好幾成。可惜的是，我所看到的很多一部分都不是這樣的。（專案自己 尚且對過程沒有什麼控制，談何對使用者代表做出要求呢）。我所見到的是，使用者代表往往彷彿一開始就是等著驗收軟體，不想參與詳細需求的制定，大部分都是靠需 求採集人員的猜想，猜想往往和實際有差距，往往只能像擠牙膏那樣從使用者那裡得到一些提示，或者片言隻語的判斷。往往是經過無數次的往返交流，需求還是霧裡 看花。需求採集人員在繁瑣中失去耐心，索性天馬行空猜測一番了事，不再去麻煩使用者。
l走到乙個陌生的行業
/領域，需要勇氣和資源
走到乙個陌生的行業
/領 域，有時候是必須的，就像眾多企業的多元化之路。非常不巧的是，也是眾多企業的多元化之路一樣，軟體要想進入乙個陌生的行業領域，也是一條艱辛之路。需要 的不僅僅是勇氣，還需要機遇，所謂東風是也。但是還需要資源作為支援。如果低估了艱辛程度，可能就低估裡所需的資源。沒有必要的資源，也許你走了
90%的路了，你要走不完剩下的路，也許你從沙漠**走到了離沙漠邊界只有數里之遙的邊界，沒有了那最後的補給，你還是出不了沙漠。任何風吹草動都可能成為壓垮你的最後稻草。
l沒有結束的結束
沒有人會承認失敗，尤其當沒有人要求你這麼多的時候。我們的專案也是，我們幾乎聽不到有人出來說專案失敗了，我們聽到的是延期、暫停、取消等等形容詞，但是其實，我們其實應該承認，我們有做了乙個失敗的專案。
l過程，沒有過程，沒有積累
從開始到結束，沒有開始的開始到沒有結束的結束，整個過程一切都在我們腦海中，剩下幾個殘缺的需求文件和無法投入使用的中間**。
或許過不了多久，一切的記憶都會從我們腦海消失，尤其像這種失敗的記憶，我們會自然選擇一種選擇性失憶。只不過，我們並沒有得到該有教訓，花了錢，還是沒有買到教訓。如果我們有過程記錄，也許我們可以知道，哪一條路徑是走不通的。我們不需要走一條失敗的老路。
讀後小感：就四個字：需求、風險
在100w個數中找最大的前100個數
1.演算法如下 根據快速排序劃分的思想 1 遞迴對所有資料分成 a,b b b,d 兩個區間，b,d 區間內的數都是大於 a,b 區間內的數 2 對 b,d 重複 1 操作，直到最右邊的區間個數小於100個。注意 a,b 區間不用劃分 3 返回上乙個區間，並返回此區間的數字數目。接著方法仍然是對上一...
乙個簡單的學生總成績第二的 sql查詢
create table stucores id int,學生id name varchar 11 學生姓名 course varchar 11 課程名稱 score int,單科分數 primary key id,course insert into stucores id,name,course...
對「溝通成本」模型的乙個重新假設
在專案成本管理上，我會把乙個軟體專案的成本主要劃分為 技術成本 和 溝通成本 兩大部分。根據實踐下來的經驗，再借助 二八定律 支撐分析，兩成技術成本，八成溝通成本。為了更好的實踐引導，在這八成的溝通成本中，我嘗試了進一步的細分。早在兩年前，我把溝通分為內部溝通和外部溝通，還是基於經驗值和 二八定律 ...