思步网

标题: 第一次项目经历,碰到很多问题,麻烦前辈们指点 [打印本页]

作者: fqking 时间: 2008-8-13 14:02
标题: 第一次项目经历,碰到很多问题,麻烦前辈们指点
先简单介绍下公司情况吧.
公司的研发部门才成立一年,人数也只有20多个.我刚进公司那会,第一个项目就发现,在这里项目经理,系统设计师,开发都是一个人.整个项目从头到尾只有3个文档:1,一份MPP. 2.概要设计. 3,详细设计 . 然而即便是这3个文档,起到的左右也很微弱.MPP基本是摆设,因为开发过程中完全没鸟它.概要设计也是.只有详细设计偶尔看看,但是由于细节也不是很清楚.开发的时候沟通讨论,返工,出现没考虑到的问题占据了很大的时间.所以每次项目都延期,而且BUG漫天飞..

再介绍下自己的情况吧.
毕业快3年,彷徨了1年来,后来还是投身软件.然后进了一家外包公司,在华为做了一年人力外包.仅有的一点对软件工程的概念应该是在这里建立的吧.这也是为什么我刚进现在公司的时候觉得一下很不适应.

受命的原因.
由于长期项目延期+质量超烂.老大终于召开了一个研发部门的全体会议来总结讨论.那一次我就说了一下自己发现的一些诸如如上提到的问题.接着又新开一个项目,老大就问我愿不愿意做这个项目的PM.我承认我对这个相当有兴趣,也很想我真能做出点特别来,然后就答应了.当时也向老大申请,设计就换个人做了,因为想想要做些计划,自己没做过,找资料写文档啥的要花时间,没时间做设计,老大答应了.(我承认在做设计上也有点心虚,呵呵,毕竟在软件开发上能力还和公司其他几位差很多).PS:公司开发人员都是3年以上工作经验,而且比较优秀的人员,都是老大一个个挑的(老大是技术出身,9年开发经验.),所以开发能力还不算很差.老大也经常说,明明一个个挑出来的,干出来的东西却不是那么回事. 闲话先到这,下面就讲下第一次的经历和困惑.

1.项目计划
找了些模板,也看了些文档,首先明确一些必须有的要点.干劲十足.....
但是到写进度计划的时候就为难了,因为项目是全新设计开发,我写计划的时候都不知道这个东西准备怎么做,更别提搞清楚要花多少时间做了.不知道这种情况下,各位是怎么解决的?
最后我没办法,只好搁着了等详细设计出来了.因为没有QA啥的,搁着也没人管- -! 不知道我是不是第一个详细设计完了才把项目计划做完的"PM".需求出来一个星期后,详细设计完成了.
(其实所谓完成很牵强,最多只能说比概要设计详细一点点,很多细节都没确定,就连准备使用的部分开源代码都没仔细看过,但是没办法,这一个星期相比之前项目都算长了1/3了,我都顶着很大压力了.)

2.WBS
详细设计完成就要马上编码了.我把计划补完开始补WBS.在这里学习了点知识,决定将任务拆分为最长2天的单位块.这里又有个疑问:我不知道前辈们这个任务细化是怎么确定的?
我最后没办法,叫每个开发人员自己把任务按要求的规则细分后,然后给每个估计个时间交给我,最长不超过2天.然后我汇总了下,把自己觉得可能问题比较多的地方适当放宽了些时间交上去了.最后确定整个的项目时间大约2个月.(- -! 如果做的很幼稚,希望各位不要笑,因为我也没搞过,就靠找找资料,自己琢磨琢磨.)

3.里程碑报告
当初我将完成详细设计设为了第一个里程碑,于是,这时候我去找了个里程碑报告的模板,模板很不错,很详细.拿到的时候还是很高兴 - -! 因为至少有个葫芦了.可是仔细一填,又为难了.
什么文档规模和代码的估计值,当初根本就没做,而且要做也没法做啊.做设计也是一边找资料一边分析写的,不晓得要写多少.代码规模更是,即使是详细设计最多也只能知道我们大概要改些加些什么东西,至于怎么加怎么写完全没时间看,只能等到编码的时候去见招拆招=.= 请教:这种情况咋办啊??

4.编码
终于编码了,果不其然当前考虑到的2个最要命的风险都出来了.
1.人力投入的问题,老实讲,即便我给项目适当预留了一些时间,但是大方针在那,我也没敢多要.但是在开发过程中,由于人员不足,项目成员不得不花时间去搞其他项目的事,最严重的时候一个星期有一半的时间再做别的.比如:主要是修改以前的一些紧急BUG,开会等.有一次产品经理主抓的一个项目到了测试阶段,他要求全体开发人员每个人都要测试一遍,然后填写一份他做的一个17页的测试报告. 当时,我也就比较郁闷,就提了意见.觉得大可以给测试部,甚至销售人员去测试一下,本来人力就不够,每个人要花3个来小时搞这个,不是更耽误进度.结果...... 给骂了,产品经理说:给你机会熟悉其他兄弟们做的产品,你不去搞,你私下会去熟悉吗?.. 偶当时无语..确实,我不会去,因为天天都在加班..我根本不可能有心思去.... 不知道,大家有没有碰到这种情况,有什么处理方式吗?
2.详细设计仓促,编码的时候老发现设计有问题不得不调整计划,或者返工.甚至出现很多计划没有考虑到的任务,无疑是给项目进度雪上加霜.

5.现状
现在编码还没结束,但是比计划已经延期了3天(这已经是天天加班的结果了),问题还是不断涌现,我头都大了,当初的激情很受打击.由于我的编码工作基本完成,现在闲下来回头想想整个项目觉得其实还是一滩烂泥.其实我写的计划也没有起到什么作用,与其说是人按早计划办事,还不如说计划在按人修改.. 看样子我的第一次确实很失败.想想也该总结一下了.但是自己毕竟没有经验,所以想到将我的这次经历发到这里给前辈们看看,指点批评一下,也许对我的反省作用更大.

作者: 思步 时间: 2008-8-13 17:46
mark 一下. 等会回去说说我的想法.

作者: fqking 时间: 2008-8-14 10:52
.....还是没人回答? 点击和回复差好多哦~~~~~ :( :( :(

作者: jaedonger 时间: 2008-8-14 11:29
心有余力不足
我都是纯理论，没有实际经验哇。。。
不过我记得我发过项目管理方面的一些资料就是了。。

作者: jetor 时间: 2008-8-14 11:36
所有小公司或者小项目都会遇到的问题
计划不做，做了没用
需求应付
设计在大脑里面
代码随意写
测试可有可无

这是一个整体的问题，并非单独解决某一个方面能够解决掉的
建议找个人系统的给你们打理一下

如果你在北京，可以免费给你们打理一下流程

作者: fqking 时间: 2008-8-14 12:01

原帖由 jetor 于 2008-8-14 11:36 发表
所有小公司或者小项目都会遇到的问题
计划不做，做了没用
需求应付
设计在大脑里面
代码随意写
测试可有可无

这是一个整体的问题，并非单独解决某一个方面能够解决掉的
建议找个人系统的给你们打理一下

...

可惜我在深圳.其实即便是有人搭理也未必会实行.在这里我感受的是一种又觉得这样不好,又抵制革命的氛围.就像上面我说的,大家都不是刚毕业的,之前的工作或多或少都会接触一些软件工程.不乏有优秀的.大家心里明白不好,可是真要实施起来,却都没把握.作为领导,花了力气搞的东西他们总希望能见到立杆见影的效果.但是SPI一般都是满足J曲线.在开始的一段时间内很有可能有反效果,那时候上头问起责来..实在是很无语.就像上面我提到的那次和产品经理的争论,我说影响进度,他说:"给你足够的人力和足够的时间,你能保证你这个项目一定按时间按质量完成吗?" 这个设计都晃荡的项目,我根本没勇气做这个承诺,何况他们所说的给我足够的人力和足够的时间根本就是扯淡.

作者: iamredeye 时间: 2008-8-14 12:50
如果是想从根本上改变，可能象上面说的，需要很多时间和精力去建立或调整项目管理和软件工程的方方面面，短期效果未必有。

可否先着手找到最需要解决的问题，也就是什么东西最困扰你们？原因是什么？

比如你说“每次项目都延期,而且BUG漫天飞”，可能项目延期和bug太多就是你需要关注的两个最关键的问题。确定了这个，下一步要找到原因在哪里。

项目延期的原因是计划不合理？这个肯定有，但很难解决，先放放。变更管理没做好？我觉得也许值得研究一下，这个也相对好解决。

bug太多的原因是什么？也许是前期的review太假或测试介入太晚，甚至没有UT/IT/ST，只有explorary testing，等等，分析一下再相应采取措施。

不要“革命”。

作者: lee_huo 时间: 2008-8-14 12:57
你遇到的现象是国内软件开发的真实写照。对于一个项目经理来说，没有组织级标准过程做保障；没有历史经验教训做借鉴；没有组织度量库做指导；没有优秀案例库作为参照；没有公共组件库作为共享；没有风险数据库作为参考；完全凭借个人能力是很难做好的。其实你做的这些已经不错了。要想TEAM成员按照一致的规程去工作，在组织级一定要有规章制度来约束。要想解决你公司的这些问题，势必要有专职的人或部门来做这件事情。

一家之言，仅供参考；有理解不对的地方别扔鸡蛋。

作者: fqking 时间: 2008-8-14 14:59

原帖由 iamredeye 于 2008-8-14 12:50 发表
如果是想从根本上改变，可能象上面说的，需要很多时间和精力去建立或调整项目管理和软件工程的方方面面，短期效果未必有。

可否先着手找到最需要解决的问题，也就是什么东西最困扰你们？原因是什么？

比如你说 ...

嗯..要说项目延期,其实我觉得主要就是上面提到的2个问题:人力投入和设计缺陷. 我查看了工作日报统计过.对项目造成延迟的主要原因就是返工,技术瓶颈卡住,编码中反复修改设计,人力不能完全投入.可是这些我都无力改变.没人吧..我也没权利说去招.设计缺陷吧.一个星期从需求到详细设计搞个新东西,估计一般人都够呛.由于历史原因,大家都默认这种在编码中改设计的搞法了,老大也不支持花时间在设计上,或者说他即使同意花时间,他希望的是你私下花时间...

至于BUG,那更汗颜.. 需求-设计-编码-集成测试-测试部.这就是我们的开发过程了.没有任何测试文档OR评审,review等.我虽然知道缺少,却是无力引入.要么老大觉得费时间,要么就是反正给你2月,你爱搞啥搞啥.. 我也不敢保证这次加入这些元素是否还能按时完成,当初的想法是进度和质量至少要保一样=.=.所以最后还是没有引入,因为我自己对质量都没信心.

不过还是很感谢你的意见,让我的明白了自己一些观念上的错误.

作者: fqking 时间: 2008-8-14 15:12

原帖由 lee_huo 于 2008-8-14 12:57 发表
你遇到的现象是国内软件开发的真实写照。对于一个项目经理来说，没有组织级标准过程做保障；没有历史经验教训做借鉴；没有组织度量库做指导；没有优秀案例库作为参照；没有公共组件库作为共享；没有风险数据库作为参 ...

嗯..好像是这样..就是感觉做起来的时候什么都不可知,搞的计划不好找,做了也控制不住.你的意思是要想做好项目管理,必须先做好流程改进么?也就是说PM需要有一套完整适用的机制作为依靠来实施管理?

请教下应该怎么做呢?公司现在的状况在软件工程上来说可说是一无所有.但是,我觉得不管是多好的机制,总有个第一个吃蛋糕的人.现在开发都不足,更别提有专门的人或部门来干这些事.

:)不过说回来,我很兴趣搞这事,如果我能打破这个混沌将来肯定很有成就感!所以我想学习方法,学习各位的经验.

作者: lee_huo 时间: 2008-8-14 16:04
乱世出英雄。做过程改进、质量保证都得取得高层的支持。据你所说的现状，我觉得你们公司做的系统对质量要求不高，即使用户使用中出了问题，也没有多大的影响，这样对于推动规范化的开发过程和质量保证工作有一定的难度。不过你现在可以争得高层的支持，制定一个符合公司现状项目研发的研发流程；把你们要用的模板首先进行规范化，大家都用一样的模板去写文档；然后针对文档写些指南文件，在针对如何流转进行过程规范。
对于开发不足更别提有专门的人来做这件事我给你举个例子：
有一个伐木工一天能伐木100根，但是做了一段时间斧子有迟钝，每天伐木70根，又过了一段时间斧子已经迟钝的不行了，每天只能伐木30根。。。。。。，有人建议他为什么不停下来把斧子磨一磨，然后在去伐木。伐木者回答说时间紧呀，我没有时间磨斧头。。。。。。
希望你能理解我意思。

[ 本帖最后由 lee_huo 于 2008-8-14 16:09 编辑 ]

作者: fqking 时间: 2008-8-14 16:36

原帖由 lee_huo 于 2008-8-14 16:04 发表
乱世出英雄。做过程改进、质量保证都得取得高层的支持。据你所说的现状，我觉得你们公司做的系统对质量要求不高，即使用户使用中出了问题，也没有多大的影响，这样对于推动规范化的开发过程和质量保证工作有一定的难 ...

不是对质量要求不高,都已经制定谁引起的BUG造成了公司损失要赔钱的制度了(虽然我不赞成这个搞法).但是这个BUG真是..完全失控.主要原因..还是人力问题.项目A 赶着赶着完了,出现BUG若干.BUG还没搞干净.项目B又开始了,兼顾2个..一阵忙活.B的效果也不好..C又开始了...如此恶心循环.我来公司的时候不知道这样多久了.反正客户端的BUG是茫茫多了.小改是搞不定了,大搞又没精力(因为一个接一个项目).

另外你提的磨刀不误砍柴工的故事,其实我也清楚.这样说吧,如果我们给这个故事完善些数据.比如如果不磨刀,每天砍树递减10,磨刀需要花1天时间,但是能保证5天每天100棵树(为了好计算和理解,就不按每天花几个小时磨刀来,然后天天磨刀来比喻了.).这样我们很容易得出2者的交集在第5天,5天前,不磨产出更高,5天后磨了产出更高.是的..这样做起来的确有章法多了.可是我现在迷茫的是:我不知道我一天能砍多少,我也不知道我磨刀要花多少时间.我也不知道不磨刀每天能少砍多少..所以我没有办法去界定2种方案哪个更好...:( 所以我没办法去说服领导..

作者: iamredeye 时间: 2008-8-14 17:46

原帖由 fqking 于 2008-8-14 14:59 发表

嗯..要说项目延期,其实我觉得主要就是上面提到的2个问题:人力投入和设计缺陷. 我查看了工作日报统计过.对项目造成延迟的主要原因就是返工,技术瓶颈卡住,编码中反复修改设计,人力不能完全投入.可是这些我都无力改变 ...

pm的一个任务就是把project （not product！）scope以及相应的时间人力成本尽可能清晰的呈献给老板，这是讨价还价的砝码。否则无法说服老板为什么需要3个月而非2个月。这是pm可以控制的，老板和公司认不认可也许是pm不能控制的。

你提到了返工，反复，bug等问题，我个人感觉一个原因就是你们的纯waterfall，不妨尝试iterative。员工实际在行为上已经在呼吁iterative了，但管理层面上被套上了waterfall。这对进度和质量都有影响。

作者: fqking 时间: 2008-8-14 18:44

原帖由 iamredeye 于 2008-8-14 17:46 发表

pm的一个任务就是把project （not product！）scope以及相应的时间人力成本尽可能清晰的呈献给老板，这是讨价还价的砝码。否则无法说服老板为什么需要3个月而非2个月。这是pm可以控制的，老板和公司认不认可也 ...

在项目初期考虑过用迭代,可是怎么说呢..我们现在做的就是第一版,从宏观上讲就是迭代的第一次.功能是选取的经典短小的.开始准备使用迭代是根据设计来选择的,后来因为设计的更改,发现迭代失去了意义(因为功能是串联关系,实现一个其实就等于实现了全部),就选用了瀑布.

不过通过你的回答,我觉得我可能在某些原则性的问题上处理的不坚决.比如在要项目时间的时候,如果我要3个月,老大不同意 ,我就会让步了.其实本次项目,老大要给的只有一个月,我要了2个月,已经是很...,我不知道怎么去拿到这3个月?老大反对的话怎么办?即便我拿的出详细计划,可是老大比较是领导者的角度,他只要尽量短时间.也许这就是讨教还价,可是我还不会,可以透露些技巧吗?或者案例??谢谢

[ 本帖最后由 fqking 于 2008-8-14 18:45 编辑 ]

作者: jane 时间: 2008-8-14 21:19
好像这个问题在我们公司也比较多，好在我们有个售后维护部，可以缓解下源源不断反馈回来的BUG。
看到你的描述，以及不少专家的高见。问题和解决方案差不多都明了。在这里我还是想谈谈我的陋见。
上面你描述需求这一块的内容相当少，是不是说需求你们做得还不错，基本上不存在变更的问题。如果需求做好了，为什么设计会有问题？有点不理解。
在不明确需求时，可能项目计划只是比较粗的表述，但大概一个项目每个阶段所占的工作量有个大致的规律，主要确定几个大的点就OK了。当需求确定后，你可以用delphile方法，把那些所谓比较牛的开发人员招集起来，大家一起来评估各功能模块的规模，以及工作量。这样子可以为你做计划提供参考。也可以成为一部分反应项目进度安排的数据，跟领导讨价还价的法码。
整个过程看下来，好像觉得你做得事情挺多的，不过对于项目管理这一块好像涉及得不多。不知道你的团队凝聚力如何？有的时候大家的沟通，团队氛围也是非常重要的。在分配任务时，大家是不是有什么意见，或者说每个人是不是承担了一份自己最善长的功能模块。这对提高项目进度也非常重要。所以前期你是不是应该通过不同的渠道了解到你的项目成员素质。
还有你提到的一些什么评审，还有什么很正规的文档。我觉得小公司并不用这么严格的要求踏实做好每一步，就可以了。比如，需求确定时，尽量让参与的人一起来了解需求，一起分析需求，不明确的尽量在前期解决掉，技术实现有问题的也可以在这阶段处理。其实真正的编码并不需要太长时间，所以大可以放心，只要大家真正理解了需求，而且需求变动不是很大的话，问题都不大。而且一旦理解了需求，返工的现象也基本可以解决。
先谈这些吧，有选择的看看吧。嘿嘿

作者: fqking 时间: 2008-8-15 09:37

原帖由 jane 于 2008-8-14 21:19 发表
好像这个问题在我们公司也比较多，好在我们有个售后维护部，可以缓解下源源不断反馈回来的BUG。
看到你的描述，以及不少专家的高见。问题和解决方案差不多都明了。在这里我还是想谈谈我的陋见。
上面你描述需求这一 ...

需求在以前的项目中,是个大问题,老变.这次因为我在需求上卡的比较严,所以变更不大.而且设计初衷就是先做个东西出来,我只要主干需求就行,其他的能推后的都推后了.
可能我有点没说清楚,我们设计的变更不是由需求变更引起的.比如这个项目我们是要做一个网络硬盘集成到以前的产品中.项目时间有限,所以设计的时候就准备采用开源的FTP协议.但是设计的时间很短,只能找一个比较牛的开发来设计,设计的重点放在与原来系统的结合以及计费等方面,详细设计只是列出我们需要在FTP协议上扩展些什么功能.但是,在设计完成的时候,连采用哪个开源代码都不知道.所以,在编码的时候,我们要边分析代码边做,这里就容易出现一些技术瓶颈(而这些受代码框架引起的问题,我们在设计的时候完全没法知道,因为那时都不晓得将来用哪个代码).或者,发现一些逻辑有问题,这个应该跟评审有关,主要大家就是参加评审也因为各有各手头要紧的事,不是很投入,只想快点搞完回去搞自己的事.这个方面我应该去加强,不过不知道有什么办法能让他们能真正投入进来呢?

团队凝聚力绝对没问题,这个可能是我唯一有信心的地方:)

作者: iamredeye 时间: 2008-8-15 11:34
这样的话其实焦点问题越来越清晰了，项目的主要问题在于technical risk。设计之后要投入多一些精力去验证或评估feasibility。

作者: iamredeye 时间: 2008-8-15 11:41

原帖由 fqking 于 2008-8-14 18:44 发表

在项目初期考虑过用迭代,可是怎么说呢..我们现在做的就是第一版,从宏观上讲就是迭代的第一次.功能是选取的经典短小的.开始准备使用迭代是根据设计来选择的,后来因为设计的更改,发现迭代失去了意义(因为功能是串 ...

讨价还价的基础是项目管理环境。pm把pragmitic的plan拿出来，老板用懂项目管理的脑子思考一下哪里合理哪里不合理。所以项目管理受公司环境（即项目的环境）的影响很大，属于org的范畴。

这可能对你来说没啥用，等于是废话。。。sorry

作者: step365 时间: 2008-8-17 10:13
:victory:

欢迎光临思步网 (http://www.step365.com/)