目前而言，專案多如狗，創業公司多如雞。
大部分只是一夥人，而不是乙個team。
首先，99%公司沿用的模式：
1，需求（可能綜合看其他同行的功能實現自認優化下前端效果）效果圖後，直接丟給程式設計師...不管程式設計師用啥手段、方式，總之能完美解決，寫出成品即可。
2，成品。
需求-直接到成品的模式。
其次，對專案實現未做二八法則精力時間分配。
核心與非核心做必要區分，一般而言，專案進度卡住，多數是對核心實現受阻或專案架構溝通斷位。
如果管理開發，連核心與非核心實現都從來沒想過，或者不知從何下手——那這team的負責人——絕對是個菜鳥。
所以，有點技術底子的娃，進入這樣的公司，都會不服其約束的。
同樣，攤上這樣的上司，本身就跟掉坑里差不多。
多人參與的專案開發團隊，帶隊者的眼界與處理開發中難點機制，直接決定專案進度。
若所謂技術團隊負責人，自己直接上的...那就只能呵呵——大致可以認定，這大嘎屬於人肉堆碼成長起來的程式設計師。
技術團隊等級劃分（個人整理，如有不服，直接無視）:
初級：小型外包公司，沒自己核心框架，有幾百或上千個所謂的基於開源專案的成品。
開發只針對基於框架的功能模組做二次設計開發，而且開發人員通常，都是只給需求+前端美工，程式設計師只負責根據效果圖+前端html效果，完善出所有需要的功能實現**。
這模式，大部分小型創業公司也在沿用。
一遇上，開發難題，立馬——所謂技術團隊找不到北，最後會老闆逼著所謂cto自己上...科科
中級：通常都是從初級技術團隊衍生而來，這類所謂技術團隊，因玩研發也不少年份。
自認對程式比較理解，姑且這麼認可他們。
他們進過3-5年的時間，篩選出一些不錯的經典**實現，作為技術底蘊。
能把開源的框架做自我完善+有自己的功能成品範例庫，做二次開發時，直接在自己的**庫的基礎上，做**快速組拼。 好一點的皮包公司也就這個水準。
高階：專案開發，更進一步文件化。不單獨有前端需求文件、以及效果圖，還有功能設計流程等等，並且區分核心**。
阿里早年技術也不行，從大公司挖了技術高管，最終發現不太接地氣。
不接地氣的根源是，高管直接沿用別人的管理模式，直接開發文件化規範化，但是忽略了個體對技術認知差異。
如果號令9**都聽不懂，那就是瞎扯蛋。
到目前位置，我能確定甲骨文那公司是那麼幹的。至於國內的軟體研發公司，其實文件化不太良好的。
技術團隊隨想
融洽協作的團隊 技術人員給人留下的大致印象是不善溝通 喜歡鑽牛角尖，而這肯定不是天生的，一方面做好技術是需要耐住寂寞和打破沙鍋問到底的精神，另一方面需要融洽的溝通氛圍。乙個好的軟體產品不僅需要廣度還需要深度，不僅需要人性化的表現，還需要穩定 可靠 靈活的內在。技術人員在做設計或者寫 的時候，很容易忽...
技術團隊管理
李春志談到2345技術團隊主要從事導航 移動客戶端以及pc客戶端軟體三方面的內容，導航 主要是2345導航，目前 已比較成熟，同時擁有了較多的使用者 移動客戶端主要是安卓和蘋果的軟體 pc客戶端軟體是2345加速瀏覽器，它是基於谷歌瀏覽器開發的，主要目標就是把谷歌瀏覽器進行本土化。關於2345技術團...
技術團隊建設
技術團隊建設要以團隊在組織內部承擔的工作任務內容和任務量為準進行架構。如果工作內容所使用的技術組織內部是沒有積累的，那麼擁有相關技術經驗的人員是優先選擇物件，如果任務量再大了一些，那麼對人員的技術深度的掌握程度要求也要更加深入。在這種情境下，同等層次人員加入才能更好環境團隊任務量的緊張程度。所使用的...