没有项目计划后面的一切都是徒劳的
这和大小公司没关系，和工作任务紧不紧也没有关系，作什么事情都需要三思而后行，这个事情一定要做，只是结合每个公司的情况我们可以把项目计划的周期时间缩短，或者太多的形式化的东西去掉，做一切有利于我们工作的计划，然后再进行下面的工作，否则后续的工作中将会产生一系列的问题，否则项目负责人将对整个项目进度很难把握，工作质量也无法保障！[ 本帖最后由 fyjfyjsmile 于 2009-6-12 17:42 编辑 ]
其实我对这个命题感觉是二者都不全赞同,也不全反对
原因:对应一个小公司来说,的确存在上面所提到的问题,变化短,变动周期大,这样一来就给测试人员造成了非常大的麻烦,要想进行好的测试时间上不允许,而且没有计划就不能好好的进行测试.但是,我想这样的问题在一些大的公司也有可能存在,(由于开发条件比如时间的限制等)所以,不能马上确定是先进行项目计划还是先开发赶进度.而是应根据具体情况进行具体分析,如果时间上允许就先进行项目计划.反之,先开发赶进度也无可厚非,毕竟现在是经济时代,皮之不存,毛之焉附.
另外,正如楼上的人员所讲的,如果你的人员对某一类系统非常有经验的话,先计划也不一定是必须的,一类系统有一个比较完整的计划就可以.现在相似的系统难道还小吗?
支持反方
首先要解决温饱问题，然后才是吃好计划是不可缺少的
我所在的公司算是一个小公司吧，可是也会有一个计划，没有计划，就像无头苍蝇一样乱撞。即使开发出来了也是不成熟的版本。与其到时意识到问题存在后不停的弥补缺陷甚至推翻重来，还不如刚开始的时候就计划周全一点，这样才是一种节省成本的方式。首先，计划应该尽可能的考虑的周全一点，把能想到的问题全部考虑进去，不仅如此，也要考虑一下以后的发展趋势，这样就可以把以后可能需要往这方面发展的一些东西也考虑进去，这是我们项目经理经常跟我们说的。
但是在实施的时候可以从大处着眼，可能把项目的主干提取出来，当主干搭好以后，其它一些也就可以做一些功能使项目变得饱满，这样也可以不用担心不能迟迟上线的问题了。
当然在开发过程中不免会有一些改变，当然这些变动不会动及主干，所以在开发过程中可以开个小会讨论一下，并且可以时时跟踪改进的情况，避免功能全部做好以后才发现那不是想要的效果，这样也可以省很多不必要的成本。
计划----改进-----确认-----实施,我认为这几个步骤是非常关键的。
这只是鄙人的想法，如果有说的不对的地方欢迎指出。:)
你是老总么 ？
各位一定要明白，老总成立公司的目的是什么？赚钱！所以为什么很多小公司不走项目计划流程而直接进行开发，因为项目没有计划部分的资金，一般都是客户扔个项目过来，只说给多少钱，什么时间完成，而且对项目的质量要求不高。如果正方觉得凡是项目都应该进行项目计划，是否可以极致地说凡是项目，都应该按照cmmi5级标准进行？如果真是这样，我相信现在市面上的绝大部分公司都会倒闭了（吃皇粮的不算）。
一个软件的开发生命周期现在都研究得很透彻了，说得土一点，只要有足够的时间和资源，一定可以做出质量很高的软件；而问题就在于任何一家公司都不可能用有限的资源投入到无限的提高质量的过程中去，即项目周期中的任何一个环节都有可能会被裁剪。
回到话题，是先计划还是先赶开发进度不是我们说得算，而是根据项目具体情况而定，一般小公司做法就是先赶进度，后期补计划。
----
题外话：这种做法对不对呢 ？理论上讲是不对的，但是很无奈，正如各位人手一张身份证一样，习惯就好了。
项目不预则废
再小的公司在做项目之前也是需要项目计划的。1. 把握需求，项目启动之前一定是会有需求的。做计划可以肢解需求，让项目组的成员对需求有更深刻的了解，本来小公司人就很少，如果大家对需求把握不了就麻烦了。
2. 做好计划有利于明确各自的职责。
3. 提高员工的效率减少项目的无故拖延。在实际情况中，如果项目组的紧迫感不强的话会造成员工效率的底下，如果在做计划时能按照时间来要求进度，做好里程碑点的控制的话会很大程度提高项目的效率。
小公司的项目不一定小
就拿我的公司来说，公司的确很小，但做的是产品，项目历时1年了（还在进行中），过去的一年只是完成了整个大项目的一部分，这一小部分就计划。项目无论大小都是一个个小部分组成的，每一个小部分就是计划 敏捷开发,敏捷测试计划是一切的开始
没有计划，后面的好多工作可能就白做了，可能这对于小公司来说是浪费时间的事情，但是，如果没有计划是很危险的 磨刀不负砍柴功项目结束时拿不出成果，一切都是扯谈
正方大多都是想当然了，老板的目的都是追求利益最大化，不管长期还是短期。如果人力、物力资源足够，制定详细的项目计划，包括开发计划、测试计划，合理的安排资源、有效的风险控制等可能都会起到事半功倍的效果。作为公司方，肯定希望项目有足够的时间去完成，项目周期越长，项目经费也越多，公司利益也就越大，在项目确定时，公司与客户应该就项目没有足够的时间所造成的后果进行交流。如果没有客户催促，项目启动会安排充分的时间。
我认为在项目周期时间短的时候应该先赶进度开发，项目结束时拿不出成果一切都是扯谈，客户不会因为你由于制定详细的项目计划导致项目延迟而支付你全部的项目经费。
测试根据需求来，开发根据计划来
:)老大，发布的话题，涵盖的不深
首先，根据不同公司的运作方式，采用的软件开发模型都不一样，按您说的，貌似和V模型很像，
实际中，我知道的公司，基本都还在螺旋，迭代模型，如果说小点的公司，我认为更是如此
测试的标准来自需求，这个在我的经验中，不属于项目计划的份额，客户需求出来后 ，我们的做法一般都是
确定一个demo,然后客户确认，OK 了 ，项目就可以开始了，
测试根据需求完成测试计划及部分测试用例，开发根据计划完成开发进度
迭代过程，会产生很多 不成熟的版本，有质量控制 ，一般都是 MD5值
提交送测
产生下次迭代，直到项目结束
里面老总肯定是有想法或者人员变更的，但是 在迭代中，这个又不影响
我认为，这才是比较适合小公司的运作:victory:
[ 本帖最后由 love_yebin 于 2009-6-19 13:41 编辑 ] 怎么感觉这个命题有点问题呢，小公司不代表流程不完善，也不能说明所承接项目就一定都是小项目，见过N多小公司承接大的项目了。 这个其实就是质量进度成本三角关系中的质量和进度的关系，没有太多问题，只是一个权衡而已 这跟公司大小有啥关系
发觉最近这边的话题越来越扯了。。。
可以用敏捷的方法来解决
平均一个月的开发周期，3天做计划足够了。如果超过3天，那就说明计划的东西太多了，十有八九在开发周期里面完不成。仔细看看你的计划，起码里面有一半的东西都是可做可不做的。毫不犹豫砍掉吧。我这里说的一个月时间，实际是22个工作日，每天写代码时间不超过6小时。测试的问题很容易解决，只要测试人员和开发人员坐在一起工作。以团队的形式来约束。比如说一个测试人员配两到三个开发人员作为一个团队。任务分配以团队为单位。团队中不管是开发还是测试的任务，都可以大家一起做。
需求的问题么，必须让需求人员和开发测试人员一起工作。只要开发人员能够根据需求做出东西，那测试肯定能感觉需求测试。有问题直接问定需求的人。文档不是很重要。
需求变更没问题，只要定需求的人知道，加一个新需求，就意味着多半要砍掉一个计划内的需求。让他自己去衡量利弊。 看看大家的见解 只要项目成功了，还在乎那么多？？
不管是为了写计划，还是为了赶进度，都是为了项目成功，最后Give me money，完事。 要不要做计划，答案是肯定的。理由上面已经讲得比较全面了
难的是，项目很紧张的时候，没有时间去做计划。或是经验不够丰富的时候，计划做的没有水准，没能体现计划的优点来。
那么，如果是上面的情况怎么办呢?
时间紧张：
先跟着有经验的同志领导下工作先展开来。期间的变化，或者小的计划，负责人要及时沟通记录好。等到中间有空闲的时候，计划再慢慢跟上。
经验不丰富：
请个高手（基本不太现实）
一边集体商榷，一遍摸索，一边执行，一边及时总结。
本次经验累计下来，下次同样的问题，不可以这么杂乱无章了
