可以为Team Leader配置一位秘书(项目管理人员)，他的主要功能是辅助Team Leader做一些管理方便的工作。如人员招聘的准备工作、开发计划的监督等等。当团队合理的构建之后，下面的就进入了产品研发的核心流程了。
三、业务建模&需求分析
前面的过程更多的是由企业领导层决定的，当我们技术人员进入这个团队时，只能祈讨已经有了一个好的开始：公司下定决心要研发这个产品，有一个优秀的、明白自己职责的PM。现在已及下面的所有流程都和技术人员(包括需求人员)密切相关，是技术人员决定着产品成败与否的时候了。
无论做产品还是项目，第一步做需求分析，这一点无须置疑。几乎每一个做软件的都知道，需求的重要性。可是为什么那么多的产品或项目最后失败的主要原因是需求问题呢?在软件研发中，产品的业务需求比项目的业务需求更难以确定。产品一般面对的是某个行业的通用需求，涉及的客户面更广，合理的提取这些需求以形成更通用的产品本身就是一件很困难的工作。对于一些以前没有这些行业经验的软件公司来说，这就更困难了。很多公司真因为没有很好去做需求分析的工作而导致产品的失败。在我以前做物流的那家公司里，也是犯了这样严重的错误。
我们当时对物流行业并不熟悉，也不能很好的把握业务需求，产品研发在来回反复的过程中消耗了大量的时间与精力。对于这个问题的解决，几乎所有的软件工程方法都提出了好的方案：引入领域业务专家(Domain Expert)。我们的研发团队中，一定要有这样的角色，即使我们没有这样一个专职人员，但一定要有人扮演类似的角色(例如架构师)。业务专家可以和架构师一起进行业务建模的工作，而架构师则偏重于技术方面，把业务模型转化成系统需求，按照RUP的流程来说，就是最终变成一个个Use Case。而一个好的业务专家是非常难得的，这就是为什么很多公司有这个意识而没有做好需求工作的重要原因：由于资金、时间等各方面的限制，他们最终放弃了这一步，而把希望寄托在架构师或其他开发人员身上，而这其中的风险就可想而知了。也有很多公司没有业务专家，而把这个角色附加给架构师了。他们要求架构师既要精通业务，也要精通技术。而现实中，这样的人凤毛麟角，属于可遇而不可求的那一类。所以在这类角色没有很明确分开的产品研发中，得到的东西要么是需求方面做得不够好，要么在软件架构方面不令人满意。怎样最大程度保证需求的合理?我个人认为做一个产品的界面原型是一个好的方法。这一点在做一个基于browser的应用系统时更可行：根据业务需求做出整个的页面原型，这样的页面也许很粗糙，后台也不需要任何的程序运行，但可以根据这些页面元素及之间的流程来验证业务需求是否合理、正确。这种方法应用到项目开发(相对于产品)中，可以和客户一起验证需求，经过几次反复，可以比较准确的理解、把握客户的真实需求。这样的工作耗费时间不多，但却能起到很大的作用。
四、架构设计
如果需求做好的话，可以说这个产品基本上能够得以出笼，但是否称得上品质优秀，则看架构设计工作做的怎样了。一个好的产品除了满足客户的业务功能外，还要满足一些非功能性的需求：系统性能、可用性、可管理性、可靠性、可扩展性、安全性等等。正是因为面对这些众多问题，在这一过程中，架构师很容易走向极端。最常见的两种极端情况：
(1)过分追求完美。
(2)做出来就行，不考虑软件品质。
作为一个系统架构师，很多人具有完美主义的倾向。他们不断的考虑系统的性能、可扩展性、安全性，技术的先进性等等。他们最喜欢说的的词：组件性、通用性、扩展性等等。所以他们不断的修改架构，不断的冒出新的思想，采