l 從人員組成何為最優說開……
l 希望培養穩定的團隊組成還是成熟的團隊體系？
比如我們有10人左右的團隊，理想的情況，我們並不會刻意期望人員能力組成能非常平衡，也很難做到，企業應用比起網際網路應用（如**網）更為枯燥且往往由於深藏企業內部而鮮為人知，於是相比之下你可能比較難尋找到很優秀的並且願意長期從事這方面工作的人，更別說是讓這些人組成乙個10幾人的團隊。所以團隊模型應優先被定義為核心技術人員+普通開發人員，從流程平台的主業流程開發來講，基於成熟流程引擎或bpm套件（如k2），基礎設施搭建完善（如：資料訪問框架，流程引擎，基礎服務等），從面向表單的開發模式和簡單的程式設計模型來指導流程開發人員完成表單開發工作。我們傾向於讓開發人員關注表單細節和業務開發，這樣我們所需尋找的人員可以是普通層次開發人員、非穩定人員、熟練型人員。
綜上所述，我們可以認為：流程開發團隊可以拆解為核心開發人員2-4人，流動性人員n+。
當我們得出這個n的時候，我們可能會發現假設需要調整人員成本，這個n就是最容易出成效的點，大膽一點，是不是可以說n=外包人員即可？關於這個n，恐怕會越說越殘酷了，不妨先打住，回頭看看那個2-4的核心，這個地方同樣也會成為管理上風險，因為n的能力被削弱了，核心被過分突出，假設短期內不可替代，便可能成為今後某天乙個讓人頭痛的事情，不過這個地方還是比較好辦的，任何團隊都會有這個問題，做好知識和技能沉澱工作會減輕它的影響。
yy完畢，那實際是如何呢？
事實上我們並不希望得到的是這樣乙個畸形的團隊，任何乙個成員都不希望自己日復一日的無思考工作，特別是寫**。我們也渴望看到每乙個人都樂於學習和在不斷提公升，這是比成本更大的資源，既然普遍人員都具備這樣的素質，那麼就應該去挖掘，控制成本通常只是讓你賺了你省掉的那部分錢，要想產出更多成果，我們需要強力的團隊，而不是乙個核心。我們在做架構的時候總是說：不要讓單點成為瓶頸。所以最初的論斷被推翻了。
沒錯，我們有10+個人，每乙個人的增強才可以真正增強團隊和我們的產品。
既然這樣，我們覺得每個人都是有潛力和學習力的，那麼，我們上ddd吧，企業應用上ddd再合適不過了。幾乎每乙個需求都在對映著領域模型的影子，它們真的很複雜，於是我試著拿了乙個專案來實踐了一下，當然只是在編碼層面做了，結果我做得很不徹底，在我設計了一半的時候發現，原來整個流程僅僅需要乙個表來記錄使用者所提交的需求，整個流轉過程不再需要有更多的實體來描述，然後我發現流程設計、表單編碼時間和整合測試時間占去了很大的比例， 於是我花了很多的時間來編寫ui呈現邏輯上來達到表單的復用，而很小的一部分時間來處理實體邏輯。這個過程之後，我就不再提及ddd了，我轉而擔下了前端的改進工作。想必你也能看出原因了吧。
我想說，先入為主是很容易讓你蒙蔽在你自己固化的圈子裡的，不要總是拿著你以前做的東西在那說事，除非你之前做的真的很優秀而且你真的理解了你之前為什麼這麼做。在當前狀態下最快最好的把事完成才是價值的最直接體現。
再具體談及幾點：
開發協作現狀是單兵作戰，缺乏整體計畫安排，所以我們拆分了小團隊，動機很簡單，增強協作，強調計畫重要性和改變資源調配單位，集中管理。從執行者層面和管理者層面來說，這個動作是有價值的。對，我說有價值，你可能不信，那聽我說：你的組總共有5個專案，老大們總是找你來詢問專案的情況，質量等，bug來了也找到了你，你可能會說這個我們組某某開發的。ok，這是你說的，你們組，你也知道了這是你們組的東西，而你是負責人，你組的產品你就要負責，對吧。沒有人希望問題來的時候他要去遍歷10幾個人來找到負責的人，也很怕乙個需求被10幾個人看了一遍說沒有空接。
其實這個改變的結果很簡單，職責被明確了。
l 如何對待現在用的技術和期望加入的技術？
「因合適而使用」，這是我在實際專案中遵循的原則。對於新技術的追逐自然是普遍開發者都有的情結，但在實際專案中還是需要有原則的，有時候可能只是對於原有技術的運用方式的不同，但如果不合適或者諸如成本高等因素，我們就需要考慮是否使用，但是不管用還是不用，你都必須是把現有的事做好了，空談技術而無實際成效也只是徒勞。
l 價值觀
我們是不直接盈利的，不直接對外的，比起**網主站，我們缺少外界的直接關注，缺少豐富外部資源支援，可以說是小眾的開發團隊。那我們的價值是什麼？
或許我們並不僅僅希望我們只是叫做工作流平台，資訊系統是否是值得考究的方向呢，如果我們做的足夠好，是否能上公升到實踐企業資訊化架構的層面。技術上是不是也可以向業界拿出有價值的實踐呢。
我這麼說，其實意思是，你可以做很多，在於你做不做，你做好了，價值就出來了。
出處：
週末亂彈之「慎獨」
1.我沒有車，沒有房，人品三七開，優點三缺點七 對於乙個事實上的標準，我只能遵從 我挑戰常規但是我不挑戰標準 結婚等相關事宜 deferred 2.每一次讀書之後就發現又有更多的東西不知道，感覺越來越無知，所以多讀書，少說話吧 3.head first css xhtml 這本書看完了，被徹底的 了...
企業架構之應用控制器
在前端控制器中說到執行命令時，是用命令物件自己呼叫檢視，如果系統的規模較小，可以如此。但這並不是最佳的選擇，最好是盡可能地將命令和檢視分離開來。應用控制器負責對映請求到命令，並對映命令到檢視。這種分離意味著可以更加容易地改變檢視 即模板 而不用改動核心 同時，也可以改變應用程式的流程而不需要修改核心...
企業架構之應用控制器
在前端控制器中說到執行命令時，是用命令物件自己呼叫檢視，如果系統的規模較小，可以如此。但這並不是最佳的選擇，最好是盡可能地將命令和檢視分離開來。一 概念 應用控制器負責對映請求到命令，並對映命令到檢視。這種分離意味著可以更加容易地改變檢視 即模板 而不用改動核心 同時，也可以改變應用程式的流程而不需...