互联网研发人员如何进行项目管理?

陈浩然_北京 发布于 2013/09/20 14:13
阅读 1K+
收藏 4
本人是某互联网公司一名普通的研发人员(非技术经理,后端主程),最近做的几个项目基本都不顺利,导致心情不愉悦,郁闷得很啊。项目延期,追责当然是研发经理的,但作为主程,多少也难脱关系。俗话说错了不要紧,要知道错在哪,自己不知道,万能的OSC肯定知道。本着学习的态度,小弟我对最新的一个项目进行复盘,请大家帮我分析一下其中存在的问题,同时也引人一个比较大的话题:互联网研发人员如何进行项目管理?

(为公司保密考虑,叙述中会隐藏回避一些内容,咱也是讨论问题,其他内容不重要,请见谅,呵呵)

1. 上一个项目(简称项目A)正式立项是什么时间我倒是真不知道,咱一个小兵,一些细节的东西也不太清楚,但是我印象比较深刻的是项目启动会上,公司老大们基本都齐了,看样就是个挺重要的项目,而且很有可能是老大直接提议、指派或安排的项目。启动会上,可爱的PM已经出了一个非常粗糙的方案(据此我推测该项目立项应该有段时间了),启动会基本上就是一个第一版方案的说明会+讨论会。研发基本是打酱油的,唯一的感觉就是项目很大,优先级很高(老大特别说的),复杂度高。启动会结论就是从现在开始,投入必要的资源,一个月时间完成上线。

2. 启动会结束的当天,研发团队也开了个动员会,研发经理再次强调项目A优先级高,指派了我作为“负责人”(呵呵),并指示研发A、研发B都要投入到这个项目中来。我当时就被吓尿了,优先级这么高,这么重要的项目,那得好好干啊。第二天就对着产品的第一版方案就开始思考、设计。

3. 无奈这个产品方案确实、真的、就是第一版,说难听的就是连需求说明文档都不如,各种产品逻辑基本没有。最后没辙了,就自己猜了几个可能性最大的需求,先把存储结构等设计了,也不能总拖着啊,至少也是磨洋工。(再一次想到了这是个优先级高的项目,压力大啊)另一方面,产品也在方案的基础上开始设计模块A的产品,编写产品文档。

4. 研发的老大也着急了,早会的时候说:“怎么还没有启动啊,这是个优先级高的项目,中午我们一起碰一下需求吧”。于是4个人一起仔细阅读了一遍那个第一版方案,不得不说老大看问题和我这小兵犊子看问题的角度还是有区别的,我一上来就钻到实现细节上去,去琢磨一堆表结构之类的问题,研发老大则把方案过了一遍,把几个需求点列了一下,把不清楚的需求点标红,第二天去找产品碰需求了。(话又说回来,我位卑言轻,不够级别碰啊,这种事情就得经理去干,让小兵犊子来干,被骂一顿不说,结果估计也是呵呵)

5. 第二天去和产品碰需求,结果有点吃惊,产品同事觉着他写的文档很明白,问他有些设计为何不写下来记录在文档上,产品同事说他早就想到了,不知道研发不理解,他感觉没必要写,不理解应该在启动会上提出来,对于有异议的地方,产品同事说为何不在启动会上提出来。对于一些更高级的问题,产品同事说,我们走到他前面去了,他现在在设计的模块A的产品就有这部分内容。就这样产品研发面对面相互呵呵了几下,需求也算沟通完了。不过产品同事倒是漏了个尾巴,就是他的文档是旧的,之后的调整都没有更新上去(这说明他说的话是假的,呵呵)。回去后,研发们又碰了一下,结论是我来负责模块A,研发A来负责模块B,研发B来负责模块C。

6. 时间基本过了一周了,模块A的产品设计还没有出来,我也只能先建建表,写写架子,这期间还有好多别的事情(多项目并行),但是一想到,项目A的优先级最高,就没心思去干别的事情了,干也是挑一些简单的,立马能清的,生怕把项目A耽搁了。模块B、模块C就更别提了,影子都没有呢。

7. 第二周的周五,模块A的产品设计出来了,和产品同事简单碰了一下。产品设计总算是有了,虽然与我之前做的有点出入,有些工作算是废了,但是之后的工作应该是不会废了的,那就赶紧搞吧。产品部门又开始设计模块A的UI,没记错的话应该是第三周的周四给的,在此之前就找个bootstrap套了个壳,总算是把模块A的流程跑通了。

8. 这期间别的项目也有些需求,简单的,紧急的都支持了,复杂的只能积攒下来,还是那句话,项目A的优先级最高。但是积攒的需求在心理上也是压力,而且其他的项目的产品同事也向老大保证说他们的项目月底能上线,我去年买了个表,再次呵呵。有的需求推了3周了,他们压力也大,我压力更大,再次呵呵。

9. 第三周周五模块B的产品设计出来了,产品研发碰了一下,我去年买了个表,如果满足这个产品设计,研发方案上就要对模块A已有的设计要做翻天覆地的调整,当时研发经理不在,不敢擅作决定,只能到第四周周一大家再碰。结果可想而知,满足模块B的设计,调整模块A的实现。调吧,谁让项目A的优先级最高呢。

10. 随着月底的临近,其他项目的产品同事也着急,纷纷来碰需求,碰进度,都想多少能支持点,压力大啊。呵呵,我想说,我压力更大,我快死了。。。

第四周有个中秋佳节,看着白板上的需求池,想起项目A的优先级最高这句话,想着9月27日这个项目截止的日子,想起了当下流行的一副对联:
我已身陷牢狱,百感交集,也只剩余生。
夫妻缘尽至此,我还ok,你也保重。
横批:世事无常,生命有限

加载中
0
小B
小B
牛掰了。
0
黑狗
黑狗

1、你们的那个会议,作用并不大,首先你们不可能在会议上那么短短的时间就把项目整理清楚,最多整理一个大方向。所以,你可以建议上面的人,会议提前通知。我们每周都会开例会,每次例会涉及的项目我也大概知道。所以我起码会喂这个会议准备两天,最长的超过了一个月。所有参会人在会议之前就把该思考的问题思考了,你们的会议才会有效果,不然全部是拍脑子想出来的问题。等会议结束了,XX高层感觉有点不对——改!然后就是无止尽的改,你可以观察观察。

2、你们的PM或者说在上下级沟通的那个人上,出了问题,在团队本身看来,领导也是用户,领导是你们的第一个用户,所以,如何控制需求,就是PM的责任。同样PM也不应该在会议上就承诺项目周期。必须下来分析,并且预留缓冲时间,这样的计划才是有用的,明明2个月的项目你一定要他2个小时做出来?这个计划本身就是没用的。你做得还是很好的啊,千万不要在需求和时间上承诺任何人,这不是你的职责,你只能传达给做决定的人。

3、看起来你们是同时有好几个项目在手里?那么你们在会议上必须提出来,让领导做决策,并且你们的承诺肯定是“全力做这件事”的情况下,周期是XXX。如果,中途有人让你做其他事儿,你让他去找XX领导去说。如果,领导授权了其他的事情给你同时做,最后项目工期拖延,他没有处理你的理由。

4、模仿一个现有市场上的产品在这种情况下是非常好的,你不要以为别人做了2年多的项目让你1个月做你做不出来,人家2年多,大部分时间是设计和改来改去,其实现在那个产品上的东西,就只有1个月也说不定。模仿他,也就是说你跳过了设计的环节,你最多就考虑下数据结构,业务逻辑你已经基本上定了。

5、改需求这个,我自己的应对方案是,来需求了,说服他, 说服他的时候有点技巧,先说“对啊!这个真是太好了!下个版本我们一定要这样,我们先赶紧上到市场上去让用户知道我们,然后我们再一一修改”如果你可以说服他把需求推到下一个版本,那你就成功了,来了需求只要不是太重要并且很简单的,全部推到下个版本,因为你会不停的碰到需求。不然你预计2月份上线的产品,6月份应该还在叠加需求/修改需求/废除需求

黑狗
黑狗
回复 @陈浩然_北京 : 你们不是模仿么 模仿几乎不用设计吧 业务逻辑都是现成的 UI也不是你们弄啊 是美工啊 难道你们是程序猿兼美工兼测试??
陈浩然_北京
陈浩然_北京
时间的评估是算上了 产品设计+UI+研发的时间,产品和UI有挤占了大量的时间。
陈浩然_北京
陈浩然_北京
应该不是改需求,是并行的问题,模块B是后台,模块A是前台,最好是需求文档一次给齐,这样考虑全面一些,从这个项目来看,研发的上下文不多,一个一个的给设计上肯定会调整,浪费大量时间。
0
陈浩然_北京
陈浩然_北京

我先自我检讨一下,我感觉问题有几个:

1.  并行的问题:我猜测这个项目是老大直接指派的,因此产品同事也准备的仓促,随便拍定一个工期。从实际操作上看,产品、UI、研发将项目拆分为了模块A、模块B和模块C。产品、UI、研发并行来做。研发是下游,产品和UI会挤占研发大量的时间,而最后的结果很可能是产品、UI都完成了任务,而研发的时间被大量挤占,没完成任务。

项目进度管理中工期评估是否是等产品、UI全部都完成后,研发再开始评估工期。

2. 在制品上限的问题:精益软件开发中指出在制品的数量不能超过2个。本案中项目A由于背景特殊,从月初就作为在制品长期占据在制品的限额,而且其优先级高,导致其他项目需要为其让路,但是其准备工作实在是太差,导致基本是磨洋工,也延误了其他的项目。



0
mahone
mahone
感觉很蛋疼的样子。。。
0
你打球像那谁
你打球像那谁
任何不以实际情况说话,直接拍脑袋得出的工期都是耍流氓。
0
wiseach
wiseach

前戏:市场告诉老板,某个项目赚钱,老板觉得靠谱; 找产品和技术的头来合计,两个头要得出大致的估算,告诉老板要多少人、多少天才有可能完成,总共的成本要花多少;老板将市场说要能挣的钱 - 成本,觉得有搞头才开始搞。

酝酿:产品和技术成立项目,挑得力干将,组成队伍; 将市场的需求进行分解(越细越好估计),再做一次细的估算,得出更谱的项目工期和成本; 如果和最初头儿估算的有出入,要和老板确认,也就是谈判(如果要保工期或质量,就多投资源,要省成本就砍功能,总之就在项目的工期、成本和质量之间来回商量);

实操:产品+UI、技术一起工作,把需求细化成具体的功能点,每个page的要输入什么、显示什么、有哪些跳转、页面之间的跳转都要细化成文档,最好做成一个动画; 此时要和老板、产品和技术的头一起确认一下(演示说明会议,最次也要有个邮件确认); 技术人员按照文档开工,开始编码、测试;完成后和定义的文档和动画比对,有则改之,无则打包、部署、内测;最后再和老板、产品和技术的头碰下,没有问题就上线。

高潮:项目如期上线、挣了和预期一样甚至更多的钱,老板很高兴、后果很幸福; 老板想要留人、鼓舞士气,于是开庆功宴、论功行赏……

收尾:高潮过后肯定要清理一下,比如洗个澡什么的……  项目要整理一下每个环节的经验教训,做为下一次的参考,以便把活干得更好(单位时间内产出更多),让大家再多来几次高潮。个人当然也要做一个总结,反思一下TA为什么拿xK奖金,Ta有什么和我不一样。

所谓项目管理大致就这么回事,所以楼主家公司前戏、酝酿和实操的时候,大家都不入戏,各自为政,不互通有无。所以高潮就无从谈起——任何官僚化的机构,都无从谈起。

0
花间小酌
花间小酌

引用来自“包菜兄”的答案

任何不以实际情况说话,直接拍脑袋得出的工期都是耍流氓。
而且 你还不能跟他讲法律 这才是要命的
0
一只小桃子
一只小桃子
刚进公司的小程序员 也是各种没需求 改一改就出bug 背黑锅 烦死了
0
Lance-Yip
Lance-Yip
我也碰到同样的问题,项目的初期也是这样靠猜得到项目的具体需求,现在更惨。用户量上来了,以前因为需求不确定,经过数次修改导致系统架构承受不住了,没办法需要重构,说好给我2人的,但是现在说没人了,你自己干吧,我郁闷不!!!
0
jQer
jQer
这就是没有专职前端的恶果,你们都不画原型图的吗, 几张psd能说明什么
返回顶部
顶部