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 价值观
我们是不直接盈利的，不直接对外的，比起淘宝网主站，我们缺少外界的直接关注，缺少丰富外部资源支持，可以说是小众的开发团队。那我们的价值是什么？
或许我们并不仅仅希望我们只是叫做工作流平台，信息系统是否是值得考究的方向呢，如果我们做的足够好，是否能上升到实践企业信息化架构的层面。技术上是不是也可以向业界拿出有价值的实践呢。
我这么说，其实意思是，你可以做很多，在于你做不做，你做好了，价值就出来了。
