那我們就鼓足勇氣，走出來，從我們的設計模式、oo、軟體工程、虛擬介面、反射、持久化、框架中走出來。開發經理來承擔起客戶行業研究來：
1、 客戶行業這個群體有多大？大中小規模各有多少家，各分布在什麼省？我們面對的最佳客戶是什麼規模什麼資訊化程度的？我們的次佳客戶是什麼規模什麼資訊化程度的？
2、 我們的上層競爭對手、本層的競爭對手、下層競爭對手目前的產品怎麼樣？他們各自的優點是什麼？他們各自的缺點是什麼？我們應該突出的優點是什麼？我們的缺點是什麼？
3、 客戶行業的過去5年，現在2年，未來3年的發展歷史和趨勢是什麼？他們面臨哪些挑戰和機遇？
4、 我們現在所做的典型客戶，他們的組織結構，人員規模，每個崗位每日業務流程、每個崗位每日每週每月每季每年的異常處理業務流程，每個崗位每日每週每月季每年的輸入**，每個崗位每日每週每月季每年的常用資料查詢，每個崗位每日每週每月季每年的統計報表
5、 針對以上的了解，客戶面對未來挑戰和機遇，未來應該如何變更他們的崗位和職責和流程，盡量流程少，效率高，運轉快？
其實，開發經理就相當於業務架構師（因為我們還是游擊隊，不可能有專職的業務架構師），公共**開發員就相當於技術架構師。
柳傳志說的非常好：搭班子，定戰略，帶隊伍。你班子不行，上什麼需求管理軟體、版本管理軟體、專案進度管理軟體、自動測試、自動整合軟體，都是無法落地執行的。
有了夯實的業務+技術，功能實用、功能符合客戶操作、功能穩定。這是軟體最基本的要求，就都能滿足了。這時候再招測試人員，就能把質量再夯實了。
而且，測試人員由於熟知產品，他們還能做技術支援呢，這樣可以有更多的開發人員來專職開發，開發的專業性就能越來越提高了。
好的產品，還需要有好的文件和培訓，否則其他部門還是不會接開發部的產品的。
好了，開發部的四套馬車終於起來了，這就是我要講的開發模式：從游擊隊轉變為兄弟連，從軟體作坊走向
記住：業務架構、技術架構、測試兼技術支援、文案兼培訓，四套馬車。
我們一直用它，效果很好，搭建團隊容易，循序漸進不革命。
有了這麼好的團隊，就能比過去產出更好的軟體，軟體的質量，軟體的進度，軟體的競爭力就都上來了，再上各種管理軟體：如專案管理軟體、版本管理軟體、bug管理軟體、自動測試軟體，就水到渠成了。
其他部門也願意接軟體了，軟體的實施和培訓和技術支援都被其他部門接過去了。開發部門也終於專職專業起來了，整個公司都很協調了，部門間也不互相陷害抱怨了。公司發展速度蹭蹭的。
老闆看著形式這麼好，也不摳門了。獎金福利隨之而來。老闆看著公司產品銷售這麼好，也不用再為公司生存發愁了，不用隨處找單子養活了，給開發部門更帶來了專業理順的計
劃發展。老闆也開始重視研發部門了，研發部門在公司的地位高多了，給與研發部門的資源和支援也更多了。
oh，my god!
研發部門的Kick Off Meeting
公司每年各個bu一直有開kick off meeting的慣例，在研發中心卻沒有這樣的習慣。去年我第一次在我負責的測試部門召開了一次kick off meeting，算是試行，今年我希望推廣到研發中心的所有部門中，讓kick off meeting成為研發中心每個部門每年度1月份的例會。下面是我根據...
在IT部門和研發部門的工作差別
最初尋找程式設計工作的時候，我並沒有意識到在一家非軟體公司的it部門工作和在一家軟體公司的研發或者產品開發部門工作有什麼不同。對於我來說，都是工作而已。我會看看公司的口碑，使用的技術或者額外津貼，試著權衡一下會不會有很多機會。事實上，這兩種工作截然不同，人們很可能會在其中的某乙個快樂並更成功。it部...
技術研發部部門結構及分工
2018年11月 公司成立2年多了，技術部門一直作為公司的輔助性角色存在，領導也提出了準備擴充套件部門的意圖。和部門領導交流了下意見，以下是個人根據交流意見及個人想法簡要整理的乙份部門組織結構及分工設想。一 部門結構 技術研發部 技術總監 a 產品組 新 調研 產品策劃 b 研發組 前端開發 後端開...