项目开发中碰到4个问题!

[小老板老工程师]

1。为什么我们明明知道只要多检查一下就能查出的问题却要心安理得的等别人发现？
2。为什么我们的版本这么难发布(至少要一至二个月)?
3。为什么我们知道需求不明确，却不过问就执行？
4。为什么我们接收意见的速度这么慢，一般情况要说两至三遍？

有做成项目管理的人,一般都会有这些问题,大家是怎样解决的,一起讨论!

[zxl_l]

版本更新发布至少要一至二个月是正确的，一是收集、核实新的需求需时间，二是让用户短时间多次更新，会让用户认为你的系统不行。

[椅子]

1。为什么我们明明知道只要多检查一下就能查出的问题却要心安理得的等别人发现？
加强测试，另外我觉得员工责任心有问题，真的，这样的混日子的人很多。
2。为什么我们的版本这么难发布(至少要一至二个月)?
我并不觉得版本发布得快是好事，除非程序里可以自动更新。发布新版本是谨慎的。
3。为什么我们知道需求不明确，却不过问就执行？
需求不明确，原因很多，首先是用户不知道计算机能实现什么，不能实现什么；其次，项目经理应和甲方沟通，把一些事情确定下来，哪些不做要讲明原因，会吹牛骗人这时候用得上；第三，从我的经验上看，变更最多的就是报表，打印格式（以oa为例），为了在开发和使用过程中避免这些风险，在做设计的时候应该给出一个方便维护和更改的方案，比如脱离程序的word模版调用。
4。为什么我们接收意见的速度这么慢，一般情况要说两至三遍？
如果每周都有计划和总结，如果每月都有考评，考评以周计划和总结（还包括项目经理的质量审查结果）为基础，而考评成绩与当月效益工资挂钩，那么项目经理所拥有这些权利后是可以少说几遍话的。

[许野平]

四个问题归根结底就一个答案,项目负责人太懒!

[zhf_karen]

1。为什么我们明明知道只要多检查一下就能查出的问题却要心安理得的等别人发现？
2。为什么我们的版本这么难发布(至少要一至二个月)?
3。为什么我们知道需求不明确，却不过问就执行？
4。为什么我们接收意见的速度这么慢，一般情况要说两至三遍？

1、大家对于团队没有归属感，任何人都会偷懒；
2、没有发布计划，没有明确发布的意义，没有把发布落实下来，团队时间观念不强；
3、需求不明确，那么需求评审如何通过的？如果通过了需求评审，为什么要过问？这是需求和项目经理的事情，要团队成员为此负责？
4、任何人改变都很难，说两到三遍不稀奇，如果一遍不听，就说第二遍，第三遍，如果还不听，就考虑考虑自己的推行方式是否存在问题，如果存在问题，就改改推行方式，如果不是，就再说，并且提拔改正的人，大家自然会改变。

顺便说一句，你的口吻很象学校的老师，而不是管理者。你总是希望使用你的下属，象你使用手臂一样方便，但是这不是通过制定一个严格的规则，然后大家跟着改变，然后一切都完美了，如果是这样，我请一个秘书执行就可以了，要你干什么？

[jb2008]

以做项目为例

1。为什么我们明明知道只要多检查一下就能查出的问题却要心安理得的等别人发现？
--这样的员工不称责，不负责任，做事不细致。开会的时候应该适当批评。

2。为什么我们的版本这么难发布(至少要一至二个月)?
--在我的经历中主要是因为需求问题，需求变化太大，多与客户沟通。

3。为什么我们知道需求不明确，却不过问就执行？
--为了完成这个月的任务，混日子，项目经理应该从整体考虑，你的最终目的是完成这个项目，拿到客户的钱！

4。为什么我们接收意见的速度这么慢，一般情况要说两至三遍？
--程序员天性不易接受人家的意见，固执，清高，多花些时间，从多方面说服，或在会议上讨论。

[1981david]

交流感情。交流项目，例会。

需求不确定，质量目标不确定。做什么（总体/分解）+怎么做（方案）+计划时间资源（谁/什么时间/需要什么资源）+跟踪检查

如果是这样，一般是老板的问题。如果你是老板，来找我帮你。

如果你的意见高明，给人帮助，自然会接受。否则，程序员才不diao你呢。

[erlengzi1982]

我觉得项目之所以能够走到这一步，是因为团队机中缺乏能人。至少应该要有两个以上在做架构方面很老练的人。

[小老板老工程师]

应该来说,架构设计问题不是特别突出，到现在产品也卖了一些，运行基本稳定。

[小老板老工程师]

产品做出来了，但市场上失败了。

[prowastrel]

项目经理级人物要主动并带头解决：
1、人的惰性，需要有规范来约束。
2、这个问题比较大。要了解时间拖在哪里，并针对性解决。
3、需求经过评审了吗？
4、意见纳入变更，并经过确认了吗？

[小老板老工程师]

非常谢谢大家的意见。

以下是我们产品开发的介绍:
整个产品有结构，硬件，嵌入式软件，服务器软件，信息管理软件，
我们开始是服务器系统的开发小组。
前期过程：
1。有一点吃饭的经费。
2。有需求测试开发流程，并有评审制度。
3。有单独的测试组和电子测试流程。
4。有周报和月报及月考评制度。
5。需求是相关标准，无客户交互


项目前期进行的很流畅，小组成员关系融洽,按时完成四期计划，并提出改进方案。
基本完成前期项目的全体功能。开发流程较正式。

由于提前完成任务，而上游系统的开发小组进度太慢，
上级领导决定两个小组合并。
中期过程：
1。上游系统重新设计。
2。客户需求多，并要求快速实现,发布版本多。
3。上游系统本身问题很多，没天没夜的改BUG。
4。因bug和需求交互太多，恶性循环开始，但基本能满足客户要求。
5。产品进入试用阶段，下游系统出现较多难解决的问题，客户意见增大。

因竞争对手已抢先占领市场，我们产品开发较晚并功能较弱，产品订单太幅下降。
部门裁人，人员重组，我们被合并到旧产品的开发组中，当然项目还是分开。
后期过程
1。人员离职，前期的采用的制度（共设计，共评审，共检视，交错修改BUG）好处得到体现。
2。小组成员情绪低落，开发速度放慢。
3。出现混日子的成员。
4。出现版本发布难。
5。出现代码的错误大大增加。

呵呵，这就是我们的项目！不知大家有什么碰到这种项目。有什么建议和意见请多多发言。

[程勉超]

沒有獎金, 沒有獎懲, 沒有管理

[小老板老工程师]

项目前期规划和管理都可很好到位,
但市场急需和上层领导会让开发后期的流程都乱套

[oldlionel]

这是做项目常遇到的风险之一，我们以前出现过类似的情况。现在要做的就是，明确目标，明确责任，严格执行奖罚制度。一定要想办法把大家团结起来，不然，剩下的人也会心不安，跳槽的可能性很大。

[stonespace]

不要对可户需求有求必应，宁肯丢掉一些可户，也要保持软件结构的质量。既定的架构之下，实现某些功能很容易，实现另外一些就很困难，所以架构不再能够修改的时候，应该要对功能有所取舍，保持有自己的特色，不要试图面面俱到，对手有的不一定要有。

其实也是项目决策者、开发人员和市场之间的沟通问题，项目决策者一般能够理解市场方面的考虑，但很少能够理解技术方面的问题，

[GHOSTSEA]

学习检讨中~~~~~~

[ClampHammer]

涨见识啊

[flyingdream123]

管理,责任,沟通

[zmflt]

up

[fita]

从yirui介绍的项目情况上来看，这个项目的问题我认为有以下几点：
1、项目用人不当，开发人员技术能力不够,上游系统设计失败，导致要重新设计，而且开发产生的BUG较多从而产生了恶性循环。产品进入试用阶段，下游系统出现较多难解决的问题，说明下游系统的设计开发中也出现了问题，而且开发期间没有人发现，这些都说明了产品设计、测试人员能力有问题。
2、项目管理也有问题，下游系统的问题一直到产品试用阶段才发现，说明前期的测试不到位。在上游系统出现BUG恶性循环，说明前期的设计和开发阶段没有抓好测试工作，导致开发问题没有及早控制，导致BUG大量蔓延。

现在国内的很多项目普遍有这样的毛病：就是重流程，不重结果。自以为搞个类似CMM的流程，就能够万事大吉，项目的早期阶段组内总是表面上一派祥和，事事井井有条，项目经理的周报月报总是一切正常，项目组员意气风发，殊不知恶果已经种下，只是任何人都没有察觉，到了项目后期，一切大白于天下，开发人员日夜加班修改错误，项目经理慌了手脚，客户怨气冲天，为什么？因为你没有及时去验证结果,我们要的是最终的结果，任何中间过程都是为结果服务的，项目经理任何时候都要把确保正确的结果放在第一位。评审会议,检视，聚餐活动，有助于软件开发成功才做，软件开发不好，一切活动都是走形式，都是浪费。

先在这个项目组我认为应该做到以下几点，如果做不到，尽早取消项目为好：
1、尽快换人，混日子的员工坚决炒掉，找到确保能够真正解决产品开发技术问题的开发人员来负责项目的开发工作。
2、项目管理风格上强调以结果为导向，制订明确的检查手段，能够明确地验证产品是否符合要求。实行短周期的版本，使项目组尽早摆脱失败的阴影，逐步走向成功。