首先声明，我不是产品经理，也不是项目经理，对做产品、项目，我也不怎么懂，我只是个程序员，现在我只是以“一个程序员”自己的领悟，对一个产品如何运作，说点流程问题：
5）此时，产品可能已经在开发之中了，开发中的“程序员”是有火花的。此时，不要压制他们，让他们提出心中的疑问、思想，因为这些很有价值。至于采不采取，当然需要商量，需要项目经理、产品经理自己去审度
1）产品前期，调研市场需求，确定此产品到底是不是适合做？产品的用户群？产品的定位？产品所属的行业？行业的背景？…..这些问题，我们必须要有个肯定的答案
2)确定做了。接下是不是就准备做的呢，我的理解肯定是“no”。因为需要拟一些“必须的”的文档，这些是总结，是可行性的总结，是需求的总结，是概要设计的总结，是详细设计的总结，这些文档绝不是形式，在团队内部是很有分量的，是前期工作的结晶，是为后期做准备的
3）此时，团队人员的心态如何，是否都认可，是否都有一致的目标，是否都了解了产品的需求，是否对将要开发的产品充满了信心，这些问题，我觉得是必须要知道的。项目经理，不就是管理、调度团队的资源的核心人物吗，但是如何能很好的调度呢，这些不需要知道吗？？
4）其实，还有很多问题，还有很多未知的问题，但是，是否还需要慢慢地去调查，慢慢地去探索，这就是看，我们自己规划的产品周期了。产品的一个目标，是尽快地抢占市场，这是急迫的
6）在规定的周期内，产品是否已经开发完毕。此时，谁都知道，需要严格的测试：单元测试、功能测试、压力测试等等。 没有经过严格测试过的产品，你就能拿出给客户用，你敢拿出去给客户用？对，抢占市场很迫切，但是测试永远很重要
7）销售人员在销售产品的时候，也会有想法，回来后，当然需要提出这些想法，但是此时产品经理，项目经理，又该如何去抉择？这也是个很重要的问题。新的需求，经过商讨，需要加，那就依然决然的加。但是加的时候，是否考虑到项目修改大不大，修改方不方便，当然易修改、易维护等等这些性质，在产品搭架构的时候，就应该去考虑
8）修改后的产品，是否需要测试，该怎么测试？全部进行测试一遍，我觉得这也不可能。那到底该如何测试，该有怎么样的一个测试方案呢，这些问题，当然应该交给“专业人士”——测试经理去考虑。在这里，我也说说，我自己的想法。我觉得一个合格的测试经理，必须了解，他将要测试的这个产品的需求，此时，那些“形式”的文档就起作用了。充分了解需求之后，是否可以将产品分为模块进行测试或者其他的方案。因为需求的变动频率是很高的，所以，我必须思考该如何应对？