小公司应先进行项目计划还是先行开发赶进度？（2009-5-22 ）获奖名单已公布

woza

一个项目不可能没有时间做计划。传统开始模式下，如果感觉做计划的时间不够，那其实是因为计划的范围太大了。还有一个问题是，做计划的人太少了。

如果一个PM管20个工程师。他要替20个人安排工作，估计时间，当然需要花很多时间。但是其他人又不能替他做决定，他当然要很多时间做计划。

在敏捷模式中，只要product owner告诉团队需求，工程师们会自己估计时间，分配任务。这样一来大家一起做计划，只需要很短的时间就可以完成。所以不会有计划和进度之间的矛盾。

Airoo

磨刀不误砍柴工，一开始可能会比较困难，几个项目下来就看到进行项目计划好处了

yuhong01

需要计划，否则天天变化开发测试都受不了。

[ 本帖最后由 yuhong01 于 2009-6-26 15:20 编辑 ]

mengpeng

我认为一个好的计划就是事情成功了一半，没有计划就无从下手。虽然是小公司，也应该有完整的计划，这样每个人才知道什么时间做什么事。做起事来有条有理，不至于盲目，更能事半功倍。试想在一个脏乱的仓库和一个整齐的仓库，那个仓库找东西更快？效率更高？小公司，时间紧.......这些只是借口罢了。

劳拉

如果不是新项目,而是作了好几年的项目增加功能,又是老手或高手,做后期版本的话,如果项目要求尽快完成,则可以做个简洁计划或省略计划;
如果是新项目,难度大,并且人手也是新的,或超过1/4是新人,项目交付时间要求再紧也要作好计划,并且越详细越好,否则将一团乱.

如果这个小公司的业务方向比较单一,集中,可以根据CMM流程相对裁减一些,制定符合自己公司业务的一套实用的流程,没必要一定要符合什么什么规范.目的是用最低的成本,在要求的时间内,最大化的保证项目质量.

huchao

背景描述：小公司开发设计全凭公司人员的想法和老总的想法为准，变动大且计划开发的周期时间短。
背景说的好，第一这个是个小公司，人员配备应该不是和全面的，所以所必要的人员和专业的技能应该没有的，
第二，背景里描述了这个公司的开发设计全是凭老板和开发的想法为准的，
第三，开发周期比较的短那么就没有充足的时间按留给作计划的人员了，那么没有时间做计划那做出来的计划就不是完整的计划了，那一个不是完整的计划的话那么就没有指导软件制作的全过程了，所以说在这样的一个小公司的这样的一个情况下我认为没有必要做计划了

movestar

我个人认为有计划比较好。虽然公司小，但是没有计划，后期改动量有可能会很大，而且开发人员没有充分的依据来证明他们的开发是按照上司原来的计划来实现的，所以有了计划就相当于有了一份可以思考、参考、证明的依据。
前期花一部分时间去计划项目，会给后期带来很大的方便，有不明白的地方就已计划书为依据。
易于软件的开发与测试。
没有计划的开发返工的几率是十分大的，对于开发、测试、公司来说，都是浪费。
因此我坚持，开发前一定要做好计划。

sundongzhi

在很多时候都会出现这样的情况，周期短没有时间写测试用例，这样可以写测试大纲！测试用例还是必须的！

DreamLink

1、從測試角度,我支持正方的觀點:没有完整的计划项目无法测试充分，出现问题大。
   因為有詳細的說明、明確的目標，才會會好的測試案例，才能有全面、多方位的測試。才能保証軟件產品的質量。如果內有這些做保証、產品需求會因時間、人事不斷變更。最終只有當是人才知道最終、真正的需求。
2、從開發及公司管理的角度來看，我支持反方觀點。
  需求需要占用大量人力、物力。如果在資源短缺、項目期短情況下，也只能暫時先舍棄一些。不然需求出來了，項目期已經到了，其它的都是無用功了。

項目要看大小，流程要考慮環境。

xiaonanzeng

我做的都是正规的项目，但我还是支持反方。
1、小公司是做不到量化这一步的，人员、技能、流程、制度都达不到标准。根本做不出一份可行的计划，如果要做，他们只会COPY
2、敏捷的思想是以人为本，不在乎其它
3、一个企业的发展历程：最初是创业文化，第二阶段是目标导向的文化，第三阶段是规则导向的文化，第四阶段是团队亲情文化。小公司只处在一二阶段

本来就很乖

当然是先项目计划了，要是开发一半才发现人员短缺，或其他问题 ，那么问题就大了

梧桐落叶

计划是要做的，只是不要搞的太过规范，制订有指导意义的计划，要切实可行的。
因为考虑到变动大的因素，可以测重在需求变动这里进行规范，不然做计划也是白做，
所以要慢慢规范起来，而不是直接就开发赶进度。
什么都是慢慢来的嘛

leafgemini

如果没有一个好的计划，测试工作很难充分展开！反而会影响到产品后期维护。

jsj1jsj

看项目小到什么程度了，很小的话 没有必要做计划 脑子就可以有个大致轮廓的当然可以忽略计划 稍大点就要有计划 防止前功尽弃

蓝色水滴

其实两者完全不冲突的啊，难道说写计划会延误项目的进度？不见得。再紧也不差个一天半会儿的吧，不是说所有的计划都得写在纸上，写得清清楚楚，谁做什么，在哪天前必须完成什么功能，还有意外延期处理等等。尤其是小公司，就3-5个开放人员，他们制度的灵活性非常高，用流行的话来说，就是完全具备敏捷的研发条件（但前提要开发人员的个人素质和开发技术要突出）。他们的计划在研发的过程中可以快速的更改，而不需要复杂的流程。一句话再小的公司也有计划，也许没有那么详细，也许没有纸质化。

cnmpdhy2009

计划是很重要，可是目前大部分中小公司都很难做到按计划来

buutterfly

小公司相当于激流中的独木船，在激流徘徊中依然前行，即使一路有着很多的风险，但在激流中依然沉稳，且不失为一种很好的解决办法。
大公司相当于茫茫大海中的一艘豪华游轮，稳重，即使有着较大的风浪，其自身的防备措施依然可以保证它成功起航，成功到达目的地。
如果将“独木桥”放于大海，就相当于将小公司至于大公司竞争的行列；
如果将“豪华游轮”放于小溪中，就有些发展环境过于狭小。

小公司应该找到适合自身发展的方式，因为其受到自己公司规模，项目大小等多因素的限制，机动灵活是其最大的特点，也是其最大的优点。太多的规划，因为其根本不具备这样的资源，或许会限制自身的发展。

大公司恰恰相反，在资源都相比更为充足的情况下，一个切实的详细的项目开发计划是必须的，否则如此之大的一个团队没有目录，会如何呢?不敢想！

基于以上观点，所以我反对！

流浪貓_遇上測試

雖然計劃是很重要的.但是就背景所說的"开发设计全凭公司人员的想法和老总的想法为准" 那就相當於計劃趕不上變化快了.
說變就變, 再好的計劃也會被一改再改, 不但在進度上減慢了,人力上也浪費了資源.

流浪貓_遇上測試

計劃,一般是就著公司現有的資源進行合理分配,進行統籌兼顧,儘量用最短的時間,最少的人力把project做好.
1.小公司不比大公司, 哪來那麼多的人力?物力資源?一但遇上突發事件(接到新的項目必須進行的), 就能將一開始的完美計劃給打亂.
2.對於一個說變就變的project, 在你更改新的計劃後的下一秒可能又會再次發生變化,那一個計劃要寫到什麼時候?此項目要何時才能開始?工作要到什麼時候才能交到客戶手上?
3.初建的小公司,在還沒有得到一定的信任時, 一般接到的project都不會很大, project不大,員工們幹起來也不會有太大的問題,
4.小的project一般分派的人手不會多,1-2個, 從了解需求到開發測試(簡單的檢查)提交,實施....,如遇上更改的,自己了解開發的過程, 更改起來也很簡單, 根本就談不上計劃, 更不需要了.
簡單的說: 種一棵薰衣草 和 種一片薰衣草, 兩者都需要計劃的嗎?
種一片:你要找一個大的地點, 而且還要有陽光的,再者在種的時候你還需要知道每一棵薰衣草之間的間隔...... .. . ..這些都要心裏有數,有計劃.
而種一棵,也許你在家的陽臺找個花盤就能種下了.

ningxin

小公司也要先计划好，只是赶进度的去做，很盲目。而且会导致后期的维护量很大，项目缺乏灵活下，难扩展。计划好了，开发起来也很快的，关键是后期维护量小，相应的耗费的人力成本等都会减少。