前言
從事IT行業多年，一路從小雜兵成長為大團隊Leader，對於研發整個體系比較清楚，其實大多人都經歷過但是都忽略了的研發成本管控的一個關鍵的點就是研發過程中專案級和產品級的區別。
在IT行業飛速發展的今天，可以將IT公司分大體分為兩類：
- 一類是軟硬開發公司：多數定位是專案類公司，如某國際，某為外包，此型別也多是外包公司，小部分公司也做一些產品級的定製開發（一般是解決方案或者按照license出貨）。
- 一類是產品提供商（服務類公司）：有特定的產品，持續迭代，特定的時候，該類主體為產品類公司。同時，不乏產品類公司做一些專案定製開發。
其實以上兩者並不是一定區分那麼明顯，會根據市場發展需要進行轉變，大部分公司的路線都是專案級養活公司，逐漸走向產品級，最終轉為產品提供商並做一些產品相關的專案開發，如國內某GPU廠。
(PS：實際上稍微大一點的公司業務複雜程度，多樣化程度不亞於過年回家應付七大姑八婆，此處只粗略加以區分）
- 思考問題1：老闆1（你的老闆或者甲方客戶）希望做一個即時通訊軟體，能實現聊天功能，檔案傳輸功能，能檢視哪些人線上，能發表情等等，是否能做？多長週期？成本多少？
- 思考問題2：老闆2想要做一個三維引擎開發，希望將給的圖進行三維點雲渲染，能將其給的demo點雲進行展示和基本的三維場景功能，是否能做？多長週期？成本多少？
- 思考問題3：老闆3想要做一個白板軟體，希望擁有某大廠的白板基本功能，是否能做？多長週期？成本多少？
- 思考問題4：老闆4想要做一個物聯網伺服器平臺，實現mqtt通訊，從前端看即可，是否能做？多長週期？成本多少？
- 思考問題5：老闆5想要做一個資料處理平臺，實現給定的幾百檔案資料處理，達到功能，是否能做？多長週期？成本多少？
（請帶著以上問題，往下看）
做產品與做專案有哪些區別，大多數的人面對這個問題還是較為模糊的，甚至簡單認為兩者是沒有區別的，均是程式開發而已。但事實並非如此，做產品與做專案兩者之間既存在本質的區別。
做專案側重於時間驅動，因為時間就是成本，要壓縮成本就要壓縮時間，在功能上力求操作敏捷、易用、友好，如果在專案時間緊迫的情況下，至少要能保證每個功能都基本能用、主流程不出現bug，若有功能性bug會進行修復。
做專案是以客戶的需求為根本，按照客戶的商定的需求進行定製開發，不明確的需求要第一時間與客戶進行溝通，不在溝通內的將會存在後期扯皮現象。
做產品側重於功能體驗，做產品的時間相對來說比較充足，前期可採用帶產品型思維的專案型管控方式，達到專案要求之後，進而不斷迭代優化修復優化非功能性bug。（團隊管理上，可稱之為專案級Demo階段，即第一階段）
要開發出有競爭力、受廣大客戶歡迎的產品為原則，功能響應速度要相對體驗好，操作要簡便、介面要美觀，是多方努力的結果，而且週期往往以半年開始計算。（團隊管理上，可稱之為產品級Demo階段，即第二階段，該階段的週期為0.5~3倍時間於專案級Demo階段）
做產品是為了滿足某一應用市場而針對性進行一套裝軟體或一個產品的開發，對於產品的效能以及快速迭代擴充套件的要求更高，產品的需求也並不像軟體專案一樣完全明確，存在著後期根據需求、迭代升級的情況。（團隊管理上，可稱之為產品迭代升級階段，即第三階段）
做專案的第一準則是客戶的需求，專案的開發人員需要依據客戶的需求進行定製開發，並且專案需要保證功能適用於當前客戶的使用習慣，效能穩定，主功能流程不存在功能性bug；
專案的質量更加側重於某一客戶的具體需求，保證交付的軟體專案程式可執行、維護，實現基本功能即可。
簡單來說，專案的程式碼怎麼方便怎麼來，一般不會考慮耦合度、程式碼規範問題，研發儘快完成對應的任務即可，當然技術好的就算是專案型也會有統一的程式碼規範和較低的耦合度。
產品的質量要求更加側重於某一行業領域的應用場景，除主功能流程之外，對其他體驗細節等進行優化，對程式碼進行優化，最開始時就會進行整體的一個基本構架，包括編碼風格，模組劃分等等，同時具備較好的可讀性，可維護性和持續開發，使其所匹配的應用性更為廣泛，並且對產品邏輯、程式碼可運維的要求更高。
做產品的效能必須持續優化，因為產品為提升競爭力就必須比同類產品更好用，更敏捷，而且產品是一個不斷完善升級的過程，對程式碼的框架以及維護性都具有更高的要求。
簡單來說，產品的程式碼兼具考慮後期擴充和整體構架，各開發者統一的程式碼規範，較好的可讀性等等，程式碼也比較健壯，邏輯清楚。
做專案的時間投入一般是根據專案的需求，進行評估。通常是從專案啟動、需求調研、功能設計、業務開發、測試執行、驗收交付為一個週期。
專案有明確時間約束，什麼時候開始，什麼時候結束，每個節點都需要一目瞭然。通常以專案的驗收單作為分項的里程碑及整體驗收單作為專案的交付證明。
做產品的時間相對來說比較長，產品通常更加關注的是整個產品的規劃、開發、推廣、維護等。
產品時間一般來說可以明確開始時間卻不能明確真正的結束時間，因為產品是一直在進行迭代完善的過程，通常會通過不同的產品版本來區分維護、優化、升級。可以劃分為三階段時間：
- 專案Demo階段：考慮構架等時間會比純專案長
- 產品Demo階段：基於之前的功能開始第一版本的穩定性，體驗，各種非功能的bug和小優化
- 產品優化迭代需求升級階段：對已有的功能進行各種優化，如播放器優化編解碼效能，如原來使用的延時500ms，提升為400ms，看似小的優化，往往付出卻是比其Demo功能開發的週期更長。
老闆1（你的老闆或者甲方客戶）希望做一個即時通訊軟體，能實現聊天功能，檔案傳輸功能，能檢視哪些人線上，能發表情等等，是否能做？多長週期？成本多少？
該問題需要進一步的溝通需求細節，實現通訊軟體達到的具體功能點，以某種形式列出，並且列出類似的幾款產品類似的功能，具體確認其功能需要達到哪種程度。才能進一步明確是否可行，週期，成本等，以下列出幾種常見的情況：
-情況一：老闆1要求的及時通訊是滿足基本要求，為人相對好說話，公司內部使用，能基本聊天實現基本功能即可，完成驗收。
-情況二：老闆1要求的及時通訊是滿足飛Q要求，實現基本要求，要達到200人同時線上群聊溝通等，還需要表情文字，gif，檔案傳輸需要達到10MB/S，同時不影響聊天，基本很難驗收。
-情況三：老闆1使用後發現，QQ能做到多個群聊多人線上，你這個為什麼不行，QQ可以同時做螢幕互動，語音這都是基本功能，之前說的基本功能就包括這些，根本無法驗收。
-其他情況：只列舉三種相對結果好、中、差的情況（往後的問題都是）。
以上第一種情況一般是合作愉快，二就比較棘手，三最後一般是不歡而散，一方吃虧或者可能在法院上見。
老闆2想要做一個三維引擎開發，希望將給的圖進行三維點雲渲染，能將其給的demo點雲進行展示和基本的三維場景功能，是否能做？多長週期？成本多少？
-情況一：老闆2要求引擎後，能夠將其給的點雲打到展示的效果，評估時使用該點雲評估，完成驗收。
-情況二：老闆2要求引擎後，能夠將其給的點雲打到展示的效果，進一步測試時，發現幾千萬的點雲載入慢，上億的點雲面渲染卡頓，進一步探討可行的解決方案，看情況是否驗收。
-情況三：老闆2要求引擎後，能夠將其給的點雲打到展示的效果，進一步測試時，發現幾千萬的點雲載入慢，上億的點雲面渲染卡頓，當初要求就是點雲渲染不卡頓，拿行業較好的軟體對比，如用opengl只顯示不卡，為什麼用已有的開源引擎就卡，專案前的點雲給的幾千幾萬的點雲，評估自然也不同，包括費用，此種情況根本無法驗收。
老闆3想要做一個白板軟體，希望擁有某大廠的白板基本功能，是否能做？多長週期？成本多少？
-情況一：前期對標某大廠的白板，基本功能，按照專案評估費用週期，後期達到基本功能需求，完成驗收。
-情況二：前期對標某大廠的白板，基本功能，按照專案評估費用週期，驗收時，如某某白板書寫的比較順和自然，可以同時播放4個4K視訊，可以各種繪製操作帶各種資源，老闆3還是懂，一切商討，看情況是否驗收。
-情況三：前期對標某大廠的白板，基本功能，按照專案評估費用週期，驗收時，如某某白板書寫的比較順和自然，可以同時播放4個4K視訊，可以各種繪製操作帶各種資源，此種無法驗收，談的是專案，做的是產品，根本無法驗收。
老闆4想要做一個物聯網伺服器平臺，實現mqtt通訊，從前端看即可，是否能做？多長週期？成本多少？
-情況一：前期以單個感測器談，可以實現即可，mqtt自己可以撐幾千個，達到基本功能，mqtt是否能撐住不在負責範圍內，按照專案評估費用週期，完成驗收。
-情況二：前期以單個感測器談，可以實現即可，達到基本功能，按照專案評估費用週期，後續說mqtt可以承載幾萬，單實際無法承載，一口說就是之前談的這個方案行得通，是你程式碼問題，不然這個方案行不通，專案無意義，不付款，此種狗血劇情，只收了基本功能的錢，還讓承擔伺服器，基本無法驗收”。
-情況三：前期以單個感測器談，可以實現即可，達到基本功能，按照專案評估費用週期，後續說mqtt可以承載幾萬，單實際無法承載，一口說就是之前談的這個方案行得通，是你程式碼問題，不然這個方案行不通，專案無意義，不付款，與此同時，提供其他方案，讓乙方寫一個可以支撐幾萬人同時線上的互動伺服器，此種狗血劇情真實存在，只收了基本功能的錢（幾千），還讓承擔幾十萬專案無法實現的後果（其方案本身存在問題，非不積極解決），還要告乙方，基本無法驗收。
老闆5想要做一個資料處理平臺，實現給定的幾百檔案資料處理，達到功能，是否能做？多長週期？成本多少？
-情況一：前期以處理的資料作為理論依據，完成功能，基本滿足即可，完成驗收。
-情況二：前期以處理的資料作為理論依據，完成功能，回去測試以幾萬幾十萬的資料去測試，發現無法承載，雙方溝通，本身做的是基礎的錢，不可能對大資料專門做優化處理，看情況是否驗收。
-情況三：前期以處理的資料作為理論依據，完成功能，回去測試以幾萬幾十萬的資料去測試，發現無法承載，遂說未達到要求，必須達到要求才能給驗收，基本無法驗收。
很多東西看起來簡單，單功能較多，純工作量都較長，導致原先簡單的東西估算成本低於實際付出太多，導致虧本，企業虧本那怎麼可能做好。
比如計算器，windows的計算器用起來還不簡單嗎，但請您認真檢視他的功能，發現windows的計算器真不簡單，完全複製一個沒有十天半個月做不出，而且達到其優化程度，又要付出十天半個月，不信你就自己試試。
比如windows畫圖，windows的畫圖看似簡單，但請您認真檢視其填充的功能，填充功能是要基於演算法去做的，而不是簡單繪製一下。
所以功能要了解到具體的功能點，模糊的功能點跟甲方溝通好，可能存在的情況，雙方達成一致，儘可能對雙方有利，輸和贏其實並不重要，重要的是你合適我也合適，生意才能長久。
很多東西看起來簡單，如理論上mqtt可以承載幾萬，QChart可以承載幾萬點，nigix伺服器可以承載幾百人流媒體延遲500ms以內，這些都是理論上的，實際和理論多半都存在的差距都挺大的，也有確實是符合理論的情況。
比如nigix流媒體，在區域網可以達到500ms，但在多終端的時候，其延遲就會逐漸增大，比如放到公網上，其延遲遠遠大於3000ms，請不要懷疑，筆者深入研究過某為、某訊、某牛、某構、某家雲、某度各家的流媒體伺服器方案以及開源的方案，都做過具體的測試，結果其方案官方給出的是3-10s之間，實際根據網路狀況有時候啥都沒有，有時候5s左右，要500ms以內必須使用其rtc服務。而對應的延時優化，是需要大量的專業人士在伺服器、編解碼、播放器各端進行各種優化，甚至是私有協議，如某家雲的就基於rtc自己二次三年優化升級的，其延時比大廠的還低。
比如一些區域網同傳開發，軟體號稱區域網每秒幾十MB，1對60同傳，確實可以，忽略了網路條件，如無線情況下，P2P也好，傳送120MB的檔案同傳，實際時間將近2小時，包括某大廠飛屏，過來測試1對多也是直接看不到影子，最後研發了rtp+fec+組播的方案，120MB同傳檔案可以達到2分鐘傳完即可。這也有個問題，幾年後續因為外圍測試環境被拆，更換新環境（干擾比較大），導致5分鐘才能傳完。
這篇文章想寫很久了，以上的思考問題都是博主9年多以來親身經歷的，尤其最近五年對於專案、產品加上自身組建團隊0到1的成功經驗，一直想進行一定的歸納整理思考。