對於軟體專案和軟體產品，前期準備的內容有所不同，這也是由專案和產品的各自特性決定的。軟體專案的個性化內容更多一些，也就是要根據使用者的需求量身定做，需要完全契合某一使用者的需求特點。而軟體產品在開發時，研發團隊的自由度相對高一些，在考慮潛在使用者通用需求的前提下，可以適當的取捨一些個性化需求。
售前諮詢人員需要具備潛在專案所需的行業知識和一定的技術能力，在和使用者進行業務交流時，能夠基本掌握使用者所述的概要需求，並站在乙個更高的位置，通過分析概要需求，為使用者的系統建設提供更為**遠矚的建議和規劃，也就是通常我們所述的專案方案書。專案方案書中主要包括系統架構、技術方案、業務功能規劃、實施計畫等方面的內容，乙份好的方案書能大大調動使用者進行系統建設的興趣，又能為下面真正的專案實施提供重要的指導。所以，寫方案書的售前諮詢人員的邏輯分析能力和總結概括能力必須要強，在以往的工作中積累了對同類專案足夠的業務和技術知識，然後總結分析到每份方案中。同時，他還必須具備較強的溝通和快速反應能力，在配合銷售人員一起跟使用者溝通時，能夠引導使用者說出其真正的系統需求，在頭腦中快速分析之後，當時給出使用者清晰明確的建議。回到公司，在用於允許的時間範圍內，盡快編寫出更為規範的方案書文件。概要需求的交流可能不止一次，方案書也可能要經過反覆的修改，最終達到讓雙方都滿意的程度。需要注意的是，方案書階段的概要需求溝通通常不涉及太深的義務，但範圍要廣，以便於綜合所有相關的因素，分析出重點。
如果使用者對方案書持肯定態度，則表明該專案拿下的可能性非常大，剩餘的工作主要是合同額的確認。有人會說，具體需求還沒有完全確定下來，合同額如何計算出來？我想說的是，如果尚未簽訂合同，就開始進行需求，需求分析完成後再計算合同額，簽訂合同，那樣風險就太大了。其實大部分的軟體公司都是出方案書後就開始簽訂合同了，方案書中約定的內容基本可以作為合同額計算的依據，有經驗的軟體公司在這方面的估計出入不會太大。當合同簽訂之後，公司即可成立專門的專案組，組織相關的人力資源進行專案開發了，此時，專案的前期準備階段也就宣告結束。
總之，專案前期準備階段的主要工作就是銷售推進專案的成單，售前諮詢負責業務和技術的分析，並提交方案書。由於售前諮詢需要全力配合銷售的工作，與客戶進行溝通，分析總結，編寫方案書，因此，售前諮詢必須具備較強的溝通能力、業務能力和文件編寫能力。
產品的前期準備工作比專案要複雜，需要準備的內容也多，大致需要準備四方面的內容：業務分析、技術分析、市場調研、財務分析。
現在絕大多數的軟體產品都是針對某乙個行業，或是行業中更小的分支，在產品正式立項之前，有必要對行業的業務知識進行分析總結，也就是明確產品的業務定位。在研發軟體產品方面，公司應配備專門的產品經理，負責這部分的內容。產品經理不做技術層面的要求，但是他對產品面向的行業必須要熟悉，也就是具備較強的專業能力，能夠提煉出亟需的行業需求，並提煉成軟體功能，從而明確軟體產品的業務功能定位。也有些軟體公司受制於財力和人力，並無產品經理的崗位設定。在決策乙個新的軟體產品時，都是主管領導根據個人臆斷，拍腦而定。然後再成立專案組，由專案組的專案經理和程式設計師去做需求。這種完全把產品當專案來做的方式大部分時候會導致產品的失敗，或者大大延遲產品推出的時間，實在得不償失。也有的公司會考慮將某些具備一定潛質的專案經理或程式設計師培養成產品經理，這種方式對那些專業知識不強的軟體產品，如企業管理類軟體，存在一定的可行性。但對於專業深度較強的軟體，結果就不太樂觀。行業知識的積累非一朝一夕而成，專業人員必然要在其行業中浸淫多年，才能在產品的業務分析和功能定位上提出更可靠的思路。如果僅為了節省人力而不配備專門的產品經理，一味想讓程式設計師成為萬能人才，其結果還是那句話，不是把程式設計師累死，就是把公司累死，術業有專攻，誰都不是萬能的。
有了產品定位，有了功能定義，還要以此為目標作技術的可行性分析。有些軟體功能看上去是很好，而且也確實能解決使用者面臨的實際問題，但計算機技術不一定能實現。雖然這種情況很少，但是還是非常有必要在產品立項前好好做技術分析，即使都能用技術實現，也可以通過這種方式來分析出各部分功能實現的難度，為產品的技術設計提供成熟的思路。技術分析的內容包括技術的重點、難點、整體實現思路、開發語言、開發工具等。開發軟體產品不是搞學術研究，必須要盡快商業化，以快速實現產品的盈利為目的，所以選擇合適的開發技術和開發工具很重要。同樣的軟體產品，單從功能的角度來考慮，也許大部分開發語言都能實現，但是必須選擇最合適的。也就是，在保證軟體的執行效率前提下，開發語言的易讀性和開發效率必須要保證。經過多年的發展，什麼型別的軟體適合採用什麼樣的語言來開發，大部分已有了定論，但是技術分析階段還是要從多個角度好好對比一下。
軟體產品最終能不能為公司帶來盈利，還要看市場容量。不過，對於國內的軟體應用環境來說，市場容量一直不存在問題，因為還沒有哪個公司在自己所處的行業領域達到一枝獨秀的高度。而且由於國內軟體公司在管理方面的種種弊端，好多中小公司都是前赴後繼的生存方式，這也為後來者提供了不小的發展和競爭空間。早起的鳥兒有蟲吃，晚起的鳥兒也有蟲吃，無非是吃多吃少的問題。吃過幾次，就要看誰的產品好，誰的管理好了。往往是具備這種軟實力的公司發展的更為迅速，而且能夠一直吃飽，直到自己的公司經營出現一定的問題。另外，由於廣大使用者對軟體的服務要求越來越高，越來越在乎服務的及時性，軟體服務的本地化也就成為了乙個問題。公司在研發產品時，最起碼還是要好好調研一下軟體產品面向的最終地域，以便有針對性的定製合適的銷售策略。
軟體產品有一定的週期性，在推向市場之前，公司是沒有收入的，完全是支出。推向市場之後，還要經過一段時期的銷售，才能達到收支平衡，收支平衡之後才能談盈利的問題。比較壞的結果是，產品剛要盈利時，可能已到了被淘汰的地步，需要大規模公升級，公司面臨又一輪的投入。正因為如此，產品正式立項之前有必要做財務方面的分析，對支出和收入預期做一下研究，避免產品研發由於資金問題半途而廢。
由此可以看出，做產品比做專案更需要全面且規範化的管理，好的開始是成功的一半，這句話非常適合專案和產品的前期準備工作。
產品發布的那些事兒
產品發布需要注意的一些事項，由於自己目前的產品經驗還很少涉及產品發布的階段，所以這一塊就簡單記錄一下 首先是技術和流程上的相關方 業務部門和使用者的相關方 發布通知盡可能冷靜克制，發到合適的人就好了，別漏掉誰，也別什麼事兒都興師動眾給全公司發郵件。這個過程跟做產品設計時理解使用者場景的過程類似，我們...
和 的那些事兒
和 都可以用作邏輯與的運算子，表示邏輯與 and 當運算子兩邊的表示式的結果都為true時，整個運算結果才為true，否則，只要有一方為false，則結果為false。還具有短路的功能，即如果第乙個表示式為false，則不再計算第二個表示式，例如，對於if str null str.equals 表...
專案中的快取那些事兒
在高併發請求時，為何我們頻繁提到快取技術？最直接的原因是，目前磁碟io和網路io相對於記憶體io的成百上千倍的效能劣勢。做個簡單計算，如果我們需要某個資料，該資料從資料庫磁碟讀出來需要0.1s，從交換機傳過來需要0.05s，那麼每個請求完成最少0.15s 當然，事實上磁碟和網路io也沒有這麼慢，這裡...