关于立项、结项遇到的管理问题，该如何解决？

yanhe100

[问题]：（这里主要是针对新项目是从老项目里分离出来的那种，因为完全全新的项目，以下问题都不存在）

我这边的情况是：一个项目快要结项的时候，通常方式是新立项然后再结本项目。这是因为新项目不立，老项目的人员无处可去。
于是就出现新项目迟迟无法立项，造成老项目完成后不能立刻关库，因为新项目的工作不得不做，无处可去，就放在老项目的库里。

——这就导致配置库内容混乱、或者经常出现白忙乎的项目（就是立项讨论后发现该项目不值得做，那么之前工作作废）。
      我们尝试在此间隙中，建立临时库（和正式库的目录一模一样），但后果是大家更不重视立项了。白忙乎的情况更无法杜绝。

不知道大家是否遇到这种问题？该如何管理好呢？


[奖励]
凡是参与交流、辩论的会员，都将有机会获得10－100金币的奖励。（注：顶、支持、路过……等恶意灌水，或者经管理员判断为灌水者，不在奖励的行列）


还等什么呢？开始吧！！！


上一篇：SQA如何规划自己的职业？
下一篇：管理故事:大船上的小窟窿

yanhe100

不过，目前有个初步的想法是：结项之后，立即关闭所有库，但是可以建立临时库，但是严格限制操作权限。例如只给项目经理操作权限。
——目的是让文档有去处，同时希望通过使用的不便，来促进项目组立项工作的跟进

毕竟立项工作涉及到高层审批领导、和项目组的投入的问题，通过意识的宣传太困难，而太狠又会被投诉影响项目进度，所以才想用点旁门左道，不知道各位是否能提供更有效的办法？

jiangly

我没有遇到过这样的问题。但我个人认为，老项目结束后应该立刻关库。新项目的工作不应该与老项目的放在一起，太混乱，不好管理。
不过，白忙乎  是什么意思呢？什么工作白做了？

nini

项目结束，项目人员无处可去是关键原因吧
这个要看部门的组织架构，如果是矩阵制架构的话，比如既有PM、又有开发经理、测试经理的，那项目结束后，成员就应该被释放到智能部门，安排其它工作；如果是项目制架构，只有PM，一个项目结束，而派生出新的项目（我理解是两种情况，一是新版本，1.0版本发布，又做2.0版本；二是重用，比如A客户项目结束，类似的用于B客户项目开发），这样的话，应该不会等一个项目结束之后再立一个项目。

因为每个项目大致都会有一个生命周期，比如先需求分析，再设计、开发、测试等，不是所有的人都会一起忙碌、一起完工的，所以第一个项目未结束已经可以立第二个项目的。

我们这边，新的客户需求，或者产品内部需求，就会立一个项目，有没有资源做不着急，做了一半的也可以暂时hold，但前提是尽可能早立项，可能一个工程师有三四个项目排队着，TeamLeader或PM会安排各自优先级，立项说白了是个挂号的过程而已，当然，每个公司对项目的颗粒和形成机制差异很大的。

还有一个实践，之前用过，在结项的时候提多提些要求，把知识积累的工作做好，比如缺陷分析、项目总结、设计文档和需求调整（总会和当时的有些变化）、备份等等。这不算旁门左道，因为大多数项目的目标是按时完成，质量还过得去，顾不上知识积累的。

junmily

立项和结项在公司层面都应该有一定的准则,这个工作也是核算项目成本的标准,所以立项和结项本身是由项目经理应该主动承担和负责的事情,如果没有清晰的准则,本身这个工作就没有意义,立项还是结项对项目组成员来说,都是被分配任务干活,干的活属于什么项目,代码放在哪里都不是他们关心的.建新的配置库也不一定要通过立项,内部管理统一,大家都遵守统一的原则,把新库和旧库的存放原则说清楚,定期配置审计,应该也问题不大.

tongtong

立项的目的应该不仅仅是为了新成立一个配置库这么简单。
这里‘白忙乎的项目’我理解的是高层当初在市场决策的时候出的问题，这种也是不可避免的。或者是代码产生了覆盖导致之前的代码白做了？不会吧，只要用了配置管理工具应该是可以找回历史版本的，只是这样相当于浪费了很多时间。

立项和结项都需要一个规程，如果建立了这个规程（公司内部都认可了），相信你的工作会好做很多。

findi

项目的立项工作在项目管理上很重要，立项表示项目正式开始，俗语说得好，有好的开始，才有好的结果，如果公司不重视项目立项，以为立项就是走场，那项目以后肯定也会做不好，因为项目组没有明确确的目标。所以楼主反映的情况，是公司内部对项目立项不是太重视造成的。

yanhe100

我这里说的“白忙乎”，就是说经过漫长的立项讨论后，发现该项目不值得做，那么之前提前做工作都作废了。——这就是我们想尽办法希望项目组能尽快立项的原因。

对于findi 说的公司对立项不重视的情况，您说得很正确，就是这个原因，我们部门才在想尽办法去提高大家的重视程度。——因为从“提高领导、项目组意识”方面着手目前没有什么有效办法。这才想在配置库上设置障碍的馊主意。
——我们当然也有规程，但是项目组连最基本的顺序要求都没执行～～～

不知道大家能否提供更有效的办法？

gracezheng

我们现在的做法是：在项目结项后，建立项目维护库，关闭并备份项目配置库。会将结项项目的发布基线（工程类文档和代码）存放入维护库中，结项后的维护或者预演性的开发在维护库中进行。然后根据后续规划，看是继续维护还是立项研发。如果是维护的话，继续使用维护库进行维护开发工作；如果是研发的话，那就进行立项研发。

jane

我个人的思路是这样子的，从问题出发。
贴主是担心经过漫长的讨论后，最后不需要做，然后发现之前的投入都浪费了。
一、利：其实我觉得，经过讨论不做了，这应该是好事，总比后面投入了更多的工作量，最后被废弃要好吧?
二、弊：看贴主的描述，MS这个讨论还是比较漫长的，所以对公司来说，这个效率应该是不能接受的。
就这个弊点，我想谈谈是不是可以从下面这些方面来解决：
1、项目立项前本身是不是就需要有立项准备这个环节，而这个环节的一些一工作，是可以在前一个项目没有结项就可以进行。在这个准备阶段要做的事情就是识别出新项目是不是要做，做哪些？而这些信息的确定基本上不会和上个项目的开发测试人员交叉。
2、再者就是，把历来漫长的讨论阶段的人员投入情况做个统计分析，让领导关注在这个环节的资源浪费情况。如果老板看了无动于衷，那我觉得我们改进人员也不需要太关注。（这种是吃力不讨好）

sungubbi

立项、结项的问题最近我们也遇到了，话说三十年河东三十年河西，两三年前公司立结项做得还相当有模有样，去年却遭遇滑铁泸，原因后面再说。

    分析一下yanhe100 描述的场景，问题大致是（如有遗漏，请大侠们补充）：
    1）存在一些继承关系时的新老项目的配置管理问题
    2）项目立项决策的问题

    对于配置管理的这个问题，我觉得封库、分库、分支管理都可行，只要最终的目的可以实现将两个项目的工作产物有效的进行识别，项目成员不至于在存取配置项时产生混乱，怎么方便怎么弄。如果新项目是在老项目的基础上增加一些模块或功能，我觉得这种完全可以不必封库、分库，通过适当的目录和权限控制就可以实现配置管理的目的;如果是两个完全不搭的产品就直接分库，至于要不要封库等项目结项了再封吧。yanhe100 所说的以前的工作都白做了，立项管理是一个方面的问题，从配置的角度我猜测楼主是不是还有一种情况是新项目在老项目的配置项上直接进行了新的开发，当决定不做时，此时大量代码白写并且还影响到了老项目的代码？不知道有没有猜错。如果是这样，一方面可能是“识别不同状态产品”工作未到位（现在较通用方法是的开发库、受控库、产品库），另一方面就是未建立有效的产品基线。

   关于立项的随意性，我们现在也很头难。虽然立项分析、评审、立项方案等工作都执行了，但还是不能阻止立项的随意性。起初大家兴致勃勃地按照标准过程来执行立项，在分析、评审中发现了很多的问题和风险，但始终拗不过主观的市场需要、舍眼前利益求未来大蛋糕的压力，即使评审结果是不能立项，但最后还是立项了。好吧，虽然这样，至少咱们把风险和问题识别了，好歹心中有个数。后果是久而久之，“立项只是走过场”越来越深得人心，连风险和问题都懒得去评估了。我也想不明白这是拜谁所赐，或者除了执行层，管理层才是这股歪风的始作俑，而最后项目失败时，他们又质问咱：你们的立项是怎么弄的？！
   关于立项再多说两句，不同的项目在立项管理时控制可稍有不同。例如一些不确定未来到底做不做，只是先派两三人先预研一下，弄个DEMO出来看看，你把配置库弄那么复杂干嘛呢？（哈哈，正好自己去年做了一个预研的项目，发现要套用正式项目的那一套可真别扭啊真别扭，可规则还是咱自己定的）。所以，适用＋够用，我觉得就可以了（如果咱这样做下去，公司西摸摸复评的时候，会不会洗具变杯具？哈哈）。

zhengminchao

痰盂

偶才疏学浅，保持中立吧~

漠河

偶才疏学浅，保持中立吧~

____贪多必失

期待楼主能发动更多人探讨啊。