先有鸡？先有蛋？
公司发展了已经有5年多，软件项目已经做了50余个，要想走好后面的路，技术还是个关键点。前几年，研发了一些支撑类的组件，比如统一的身份管理、数据字典、表单定义和工作流等等，但是都是撑着项目的间隙赶出来的，功能和质量都还不尽人意。好消息是，在各方面的努力下，现在公司打算独立出一个研发团队，来专门从事一些支撑类中间件的研发上，旨在不断提高开发团队的项目开发能力、效率和质量，同时也考虑在不远的将来将一部分中间件投入到市场中去。
现在问题来了，有2个方向：
- 研发团队的目标从长计议，将软件开发的生命周期仔细分析一遍，然后按着自己的步伐走；
- 研发团队的研发周期根据项目开发团队的实际情况作出一些调整，即先行确定研发产品将来的第一个用户。
前者是每个技术人员所向往的，拥有一片“净土”，但是风险是，产品与市场、需求脱钩，无法迅速的将成果应用到实际项目。后者的好处是可以立竿见影的检验产品，但是风险是产品研发进度可能会受项目进度打压，导致功能缩水，甚至质量降低。
这2者该如何权衡呢，考虑ing..
但是，值得欣慰的是，公司已经决定要独立出研发团队，并给予有力的支持，未来怎样还不敢说，但，值得一搏！
回头想想，其实还是更倾向于后者，同时结合一部分前者的优势。毕竟这样的研发团队对公司来说都是新生事物，其管理手段肯定会不同于项目管理中的CMMI，我想应更多的推崇“敏捷”，先从小产品着手，先行先试，通过短生命周期产品的研发把研发团队的管理制度梳理清楚，然后再逐个击破。
人员方面，因为是刚有这些想法，所以目前只有2名研发人员（包括我在内），团队怎么壮大也是个问题，方法有二：
- 从项目团队中物色。根据研发团队的特点和要求，到项目团队中去物色，并着力对何时的候选人做定点培养，一方面培养其研发能力，另外一方面要想办法尽快从项目脱身；
- 招聘。招研发人员不容易，想我公司这样的小企业要招到好的研发人员更不容易，好的人可能连面试都不回来，根本就没机会面谈，所以目前打算先找一些有2、3年中间件类软件开发经验，专注于技术领域的童鞋加入，毕竟，我还是打算打造一个有核心凝聚力的团队，花点时间培养还是可行的。再者，空降的有能力的研发人员虽然有很强的研发能力，但也可能会从内心里有一些根深蒂固的模式，不利于研发团队的创新性。
这几天要先把研发团队的管理规范和研发规范折腾出来，敏捷！敏捷！敏捷！
