小公司应先进行项目计划还是先行开发赶进度？（2009-5-22 ）获奖名单已公布
[size=3][i]背景描述：[/i][color=red]小公司开发设计全凭公司人员的想法和老总的想法为准，变动大且计划开发的周期时间短。[/color][color=red]那么小公司应先进行项目计划还是先行开发赶进度？[/color][/size]
[table=400][tr][td][b]奖项[/b][/td][td][b]获奖名单[/b][/td][td][b]奖励[/b][/td][td][b]答案连接[/b][/td][/tr][tr][td]最佳话题PK手[/td][td]蓝色水滴[/td][td][align=center]当当购物卡50元+最佳PK手勋章[/align][/td][td][url=http://bbs.51testing.com/viewthread.php?tid=149599&page=3#pid1283841]54#[/url][/td][/tr][/table]
[i][color=#ff0000][/color][/i]
[size=2]本期问题由[color=#000000][url=http://bbs.51testing.com/viewthread.php?tid=131215&page=3#pid1210885][size=2][color=red]huihuike[/color][/size][/url]会员提供！[/color][/size]
[size=2]如果你也有矛盾的问题想提出来和大家一起讨论，[/size][url=http://bbs.51testing.com/thread-131215-1-1.html][size=2][color=red]请点击此处>>[/color][/size][/url]
[size=3][size=2]说不定下期PK的话题就是由你提出的哦，请快快参与吧！[/size][/size]
计划是行动的妈妈
我认为计划是行动的妈妈，就像失败是成功子母一样计划是我们在初期估计我们的进度，成本，规模
这些的正确估计，有助于我们合力分配时间和人力资源。
虽然是小项目，如果项目经理经验丰富，计划也是有必要的。。不然，我们在行动的过程中常常很盲目，更容易导致到期不能按质按量的完成。
小的概念是什么.
这个问题要看小的概念是什么,小到何种程度.计划是一切的开始
其实文中的说的公司人员的想法和老总的想法，从一定程度上来说也是计划，只是没有书面化而已。没有笔头记下的东西不能保证以后没有遗漏，开发之间的任务和意思也有可能还留有一点没有相互理解。（我就遇到过赶项目的时间，2个开发做了同一个页面，漏了一个页面）后期在改也要花很多时间。还是一开始把计划写下来，当然进度很紧的话，不用写的那么充分，但是必要的流程，任务分工等还是要记录的，这要不了多少时间，还可以为以后维护留下资料，毕竟人脑不是电脑，不能记得做过的所有项目。 小公司赶进度的后果是，后面花费的维护时间更长。这个时候就能看到实现计划的重要性了。亲身体验。 我本身是中立的，但是看到反方投票太少，所以给投了一个反方票，其实哪个好，实践是检验真理的唯一标准，两个没有做出来前，可以说无从对比。其实我们不要追求形式上的，或者固定模式的哪种方法更好，只要本着得到最终好的结果（软件）即可。
变是绝对的，不变是相对的。 本人觉得项目计划的制定非常重要，它对整个项目期间每个阶段需要多长时间进行大概估算，使整个项目组成员在这个阶段有个明确的目标，不会像无头苍蝇，保证了效率，也保证了产品的质量。没有项目计划，就没有一个指路明灯，一天干多少活算多少，最后可能会导致项目延期。 不管是大公司还是小公司都应该有相应的项目计划，应先进行项目计划是肯定的，但就目前很多小公司来说却没有相应的项目计划，主要原因有两个：第一，公司不重视，只要出东西就行；第二，项目周期短，时间紧迫，开发人员急于赶进度。 如果这个问题问的是只分先后，而不是进行不进行的话。。。。。我觉得先进行项目计划还是先行开发赶进度,为什么不能同时并行呢？
计划是对整体的操作规划，对于小项目可先分析业务，确定在老板怎么拍脑袋都不会变的需求先由开发实现（这个过程应该不会花太多的时间吧？），那么我想计划的同时也可以开始开发，测试也可以同时开展
计划不如变化快，但我们应该保证计划要赶得上变化 [quote]原帖由 [i]Gray[/i] 于 2009-6-1 15:44 发表 [url=http://bbs.51testing.com/redirect.php?goto=findpost&pid=1237984&ptid=149599][img]http://bbs.51testing.com/images/common/back.gif[/img][/url]
如果这个问题问的是只分先后，而不是进行不进行的话。。。。。我觉得先进行项目计划还是先行开发赶进度,为什么不能同时并行呢？
计划是对整体的操作规划，对于小项目可先分析业务，确定在老板怎么拍脑袋都不会变的需 ... [/quote]
公司的计划变化太快，而且没有书面的一个确定需求，都是领导说今天要加这个功能就加这个功能，明天说那个功能不要了，又做了白工。开发人员做的很辛苦，测试人员做的也很辛苦，关键就是没有一个定论。 这个问题我也一直困扰哈！
小公司嘛，也不是很规范，按照一步一步规范流程来做，需要慢慢来。
什么也不明确，想到什么就做什么，想到什么就往里面加，原来所关联做的有些不合理又要删掉，真是浪费了不少劳动力，
开发人员和测试人员的劳动力，特别是测试人员，牵着鼻子走，本来测试人员就处于被动的状态，汗。。。。。。。。 需要不需要计划还得依具体的情况而定，在人手紧、时间紧的情况下一些流程上的东西我觉得还是可以删减的，不用非得去按正常的流程走，当然制定些简单的计划什么的还是必要的，千万别为了走流程最后把项目人员弄的整天加班去赶进度，时间挤到最后压缩的还不是项目测试的时间，没有经过充分测试的软件质量也就可想而知了（亲身体会啊）。所以制定项目计划，按照正常的项目开发流程是在人力资源、时间等条件相对充裕的情况进行会比较好。 视情况而定 没有先后之分。。。两手抓两手都要硬。。。::zilian:::
没有好的计划就没哟好的实施
首先要明确一点是否真的很小，如果半个月就可以搞定的事情，没有必要在搞一些噱头和一些没有必要的形式文档。
但是一个真正的项目，计划是最最重要的前期工作，需求如果不定好，没有办法定下来完成的时间，
需求的改变意味着无线的延期。
耽误时程。
RUP
小公司项目小可以采用RUP进行软件的开发，应该会比较有质量保证，不会浪费很多时间。计划做的周全了，需求明确了，可以节省很多变更需求造成的时间浪费，也同样为日后的开发节省下了时间。也可以先进行项目开发得到一个初期的模型，然后再扩展，即可以降低风险，也可以增加进度。但不管计划先进行还是开发先进行，都必须明确需求。并不冲突
还是觉得这些都是要兼顾的。项目计划是一个全局的东西，指导了整个的软件开发的过程。如果是紧急的项目，那就更加的应该有项目计划啊之类的了，因为，这样才可以更好对所要做的事情进行估计和计划，才能够避免盲目。假设一个紧急的项目没有项目计划等，恐怕开发进行到一半发现，哎呀，没有办法完成了，那才不得了。
计划是要做的
计划是肯定要做的 但是之所以叫做计划 就是说在实际执行过程中可以进行变动 计划是死的 人是活的 不管大小公司 项目开始前肯定要做计划（因为计划是根据项目性质来做的）完整的计划 小项目
完整的项目计划是个什么概念，对于一些项目时间特别紧急的项目可以之计划一些比较重大的里程碑，不用太细化，只要能充整体上把握项目进度就行，不必考虑1号设计几个功能点，2号测试几个功能点项目小，小又是个什么概念呢？无论大小，计划都是应该走的，但是应该根据项目的实际情况，考虑计划的制定方式和表现形式。
小公司也要通过分析它的组成来决断
从目前中国国情来说，投了正方一票。对于国内大多数小公司来说，人员少，具有丰富工作经验的高级人才也少，那么项目计划是必须制定好的。我们可以说计划是用来改的，但没有计划，我们连参考的标杆都没有，不光开发过程受影响，管理也混乱。
某些小公司，这种公司国外存在的情况较多，人员少而精，从上到下都是多年经验的牛人，而且共同共事多年，对于各种流程早已吃的透透的。我觉得这样的公司没有计划也可，难道你会认为他们会因此把项目搞砸？
多说一句，就像CMM的应用一样，国外一些公司已经觉得CMM流程制约项目开发，搞起了敏捷。国内目前还没有一家公司达到超越CMM的级别，自然还得老老实实按条条框框来的好。 好的计划，对项目开发进度和测试进度都有绝大关系的，自身经历，公司小，人员短缺，多个项目临时调动人员，如在提前不制定一个合理项目计划，再以后项目启动后，时间及人力资源上上有很大的浪费，效率提不上去
没有项目计划后面的一切都是徒劳的
这和大小公司没关系，和工作任务紧不紧也没有关系，作什么事情都需要三思而后行，这个事情一定要做，只是结合每个公司的情况我们可以把项目计划的周期时间缩短，或者太多的形式化的东西去掉，做一切有利于我们工作的计划，然后再进行下面的工作，否则后续的工作中将会产生一系列的问题，否则项目负责人将对整个项目进度很难把握，工作质量也无法保障！[[i] 本帖最后由 fyjfyjsmile 于 2009-6-12 17:42 编辑 [/i]]
其实我对这个命题感觉是二者都不全赞同,也不全反对
原因:对应一个小公司来说,的确存在上面所提到的问题,变化短,变动周期大,这样一来就给测试人员造成了非常大的麻烦,要想进行好的测试时间上不允许,而且没有计划就不能好好的进行测试.但是,我想这样的问题在一些大的公司也有可能存在,(由于开发条件比如时间的限制等)所以,不能马上确定是先进行项目计划还是先开发赶进度.而是应根据具体情况进行具体分析,如果时间上允许就先进行项目计划.反之,先开发赶进度也无可厚非,毕竟现在是经济时代,皮之不存,毛之焉附.
另外,正如楼上的人员所讲的,如果你的人员对某一类系统非常有经验的话,先计划也不一定是必须的,一类系统有一个比较完整的计划就可以.现在相似的系统难道还小吗?
支持反方
首先要解决温饱问题，然后才是吃好计划是不可缺少的
我所在的公司算是一个小公司吧，可是也会有一个计划，没有计划，就像无头苍蝇一样乱撞。即使开发出来了也是不成熟的版本。与其到时意识到问题存在后不停的弥补缺陷甚至推翻重来，还不如刚开始的时候就计划周全一点，这样才是一种节省成本的方式。首先，计划应该尽可能的考虑的周全一点，把能想到的问题全部考虑进去，不仅如此，也要考虑一下以后的发展趋势，这样就可以把以后可能需要往这方面发展的一些东西也考虑进去，这是我们项目经理经常跟我们说的。
但是在实施的时候可以从大处着眼，可能把项目的主干提取出来，当主干搭好以后，其它一些也就可以做一些功能使项目变得饱满，这样也可以不用担心不能迟迟上线的问题了。
当然在开发过程中不免会有一些改变，当然这些变动不会动及主干，所以在开发过程中可以开个小会讨论一下，并且可以时时跟踪改进的情况，避免功能全部做好以后才发现那不是想要的效果，这样也可以省很多不必要的成本。
计划----改进-----确认-----实施,我认为这几个步骤是非常关键的。
这只是鄙人的想法，如果有说的不对的地方欢迎指出。:)
你是老总么 ？
各位一定要明白，老总成立公司的目的是什么？赚钱！所以为什么很多小公司不走项目计划流程而直接进行开发，因为项目没有计划部分的资金，一般都是客户扔个项目过来，只说给多少钱，什么时间完成，而且对项目的质量要求不高。如果正方觉得凡是项目都应该进行项目计划，是否可以极致地说凡是项目，都应该按照cmmi5级标准进行？如果真是这样，我相信现在市面上的绝大部分公司都会倒闭了（吃皇粮的不算）。
一个软件的开发生命周期现在都研究得很透彻了，说得土一点，只要有足够的时间和资源，一定可以做出质量很高的软件；而问题就在于任何一家公司都不可能用有限的资源投入到无限的提高质量的过程中去，即项目周期中的任何一个环节都有可能会被裁剪。
回到话题，是先计划还是先赶开发进度不是我们说得算，而是根据项目具体情况而定，一般小公司做法就是先赶进度，后期补计划。
----
题外话：这种做法对不对呢 ？理论上讲是不对的，但是很无奈，正如各位人手一张身份证一样，习惯就好了。
项目不预则废
再小的公司在做项目之前也是需要项目计划的。1. 把握需求，项目启动之前一定是会有需求的。做计划可以肢解需求，让项目组的成员对需求有更深刻的了解，本来小公司人就很少，如果大家对需求把握不了就麻烦了。
2. 做好计划有利于明确各自的职责。
3. 提高员工的效率减少项目的无故拖延。在实际情况中，如果项目组的紧迫感不强的话会造成员工效率的底下，如果在做计划时能按照时间来要求进度，做好里程碑点的控制的话会很大程度提高项目的效率。
小公司的项目不一定小
就拿我的公司来说，公司的确很小，但做的是产品，项目历时1年了（还在进行中），过去的一年只是完成了整个大项目的一部分，这一小部分就计划。项目无论大小都是一个个小部分组成的，每一个小部分就是计划 敏捷开发,敏捷测试计划是一切的开始
没有计划，后面的好多工作可能就白做了，可能这对于小公司来说是浪费时间的事情，但是，如果没有计划是很危险的 磨刀不负砍柴功项目结束时拿不出成果，一切都是扯谈
正方大多都是想当然了，老板的目的都是追求利益最大化，不管长期还是短期。如果人力、物力资源足够，制定详细的项目计划，包括开发计划、测试计划，合理的安排资源、有效的风险控制等可能都会起到事半功倍的效果。作为公司方，肯定希望项目有足够的时间去完成，项目周期越长，项目经费也越多，公司利益也就越大，在项目确定时，公司与客户应该就项目没有足够的时间所造成的后果进行交流。如果没有客户催促，项目启动会安排充分的时间。
我认为在项目周期时间短的时候应该先赶进度开发，项目结束时拿不出成果一切都是扯谈，客户不会因为你由于制定详细的项目计划导致项目延迟而支付你全部的项目经费。
测试根据需求来，开发根据计划来
:)老大，发布的话题，涵盖的不深
首先，根据不同公司的运作方式，采用的软件开发模型都不一样，按您说的，貌似和V模型很像，
实际中，我知道的公司，基本都还在螺旋，迭代模型，如果说小点的公司，我认为更是如此
测试的标准来自需求，这个在我的经验中，不属于项目计划的份额，客户需求出来后 ，我们的做法一般都是
确定一个demo,然后客户确认，OK 了 ，项目就可以开始了，
测试根据需求完成测试计划及部分测试用例，开发根据计划完成开发进度
迭代过程，会产生很多 不成熟的版本，有质量控制 ，一般都是 MD5值
提交送测
产生下次迭代，直到项目结束
里面老总肯定是有想法或者人员变更的，但是 在迭代中，这个又不影响
我认为，这才是比较适合小公司的运作:victory:
[[i] 本帖最后由 love_yebin 于 2009-6-19 13:41 编辑 [/i]] 怎么感觉这个命题有点问题呢，小公司不代表流程不完善，也不能说明所承接项目就一定都是小项目，见过N多小公司承接大的项目了。 这个其实就是质量进度成本三角关系中的质量和进度的关系，没有太多问题，只是一个权衡而已 这跟公司大小有啥关系
发觉最近这边的话题越来越扯了。。。
可以用敏捷的方法来解决
平均一个月的开发周期，3天做计划足够了。如果超过3天，那就说明计划的东西太多了，十有八九在开发周期里面完不成。仔细看看你的计划，起码里面有一半的东西都是可做可不做的。毫不犹豫砍掉吧。我这里说的一个月时间，实际是22个工作日，每天写代码时间不超过6小时。测试的问题很容易解决，只要测试人员和开发人员坐在一起工作。以团队的形式来约束。比如说一个测试人员配两到三个开发人员作为一个团队。任务分配以团队为单位。团队中不管是开发还是测试的任务，都可以大家一起做。
需求的问题么，必须让需求人员和开发测试人员一起工作。只要开发人员能够根据需求做出东西，那测试肯定能感觉需求测试。有问题直接问定需求的人。文档不是很重要。
需求变更没问题，只要定需求的人知道，加一个新需求，就意味着多半要砍掉一个计划内的需求。让他自己去衡量利弊。 看看大家的见解 只要项目成功了，还在乎那么多？？
不管是为了写计划，还是为了赶进度，都是为了项目成功，最后Give me money，完事。 要不要做计划，答案是肯定的。理由上面已经讲得比较全面了
难的是，项目很紧张的时候，没有时间去做计划。或是经验不够丰富的时候，计划做的没有水准，没能体现计划的优点来。
那么，如果是上面的情况怎么办呢?
时间紧张：
先跟着有经验的同志领导下工作先展开来。期间的变化，或者小的计划，负责人要及时沟通记录好。等到中间有空闲的时候，计划再慢慢跟上。
经验不丰富：
请个高手（基本不太现实）
一边集体商榷，一遍摸索，一边执行，一边及时总结。
本次经验累计下来，下次同样的问题，不可以这么杂乱无章了
页:
[1]
2