项目管理与开发实战-优快云博客

本文链接：https://blog.youkuaiyun.com/kevinwhite/article/details/2570618

手上的这个项目已经做了一年了，当然也到头了，因为工作岗位要调整不再继续下去了。一年来的经历满多的，记下来吧～

记得一年前刚参加工作不久，老大突然找我谈话，说让我负责某项目，其实这个项目是满大的，自己从数据库设计到业务逻辑全部要负责，要命的是没有经验，技术也需要现学，捉襟见肘不说，还要常常加班。但更要命的一个问题在于自己的个性，因为我自己是那种比较内向的人，也是慢热的人，对很多东西要慢慢才能理解。你想一个不懂又不喜欢多问的人，会是什么状态。（当然也有个客观条件，大家都很忙，没人会给你那么耐心的指导。但是以这个条件为接口的人是好面子的人，我就是那种人，是做不好事情的）

根据项目组的需要，我们人员集中到了一起，去另一个BU那里办公。吼吼，热闹了～

一、需求评审

开始的日子，天天开会，干什么呢？当然是需求评审。人员也是相当的丰富，从开发到产品经理一个不落。当然对于我来说一片空白，因为没有那些概念，反正你们怎么说我们怎么做就行了呗。但那些所谓有经验的人呢？其实什么都没讲出来，开会其实就是在浪费时间。

因为后来的事实证明，当初的需求有根本性的错误和不足，这也是导致项目屡次出问题的原因之一。当然，可借鉴的经验几乎是没有了，但是教训也是有意义的，防止以后重犯。列举如下：

1、目标过高，不切实际。

大凡对待一个新生事物，人们都难免会产生一种美好的憧憬，好大喜功的情绪开始蔓延。但不要忘了那句话：为了面子和同情心做的事情是注定要失败的。

为什么说目标过高了呢？因为我们的定位是给Product Manager自助制作活动的平台，这其实就没有考虑到产品经理和开发人员之间的鸿沟，忽略了太多的细节性问题。如果从长远看，PM来DIY当然是最好的，同时如果PM可以DIY的话，那所有的配置必须是“傻瓜”型的，因为他们没有那么多时间和精力去做复杂的配置，更别提理解你那些后台的逻辑。但要做到这种“傻瓜”型的配置，必须是十分成熟的，相对固定的业务逻辑才可以。而现在的情况是我们在摸着石头过河，想一步跨过去，只会跌在河里。

2、用户定位错误

当然这是由于1引起的，因为他定位在PM那里，所以很多东西做的似乎是很“易用”，但实际上PM还是觉得麻烦。最后只好安排专门的运维人员来做这项工作，呵呵，运维人员觉得这太麻烦了，因为人家可以直接在后台搞定。用户定位错了，很多功能也就跟着出问题了，因为做的功能不一定是真正的用户所需要的。

二、一期开发

在一团和气的评审之后，终于进入了正题，开始开发了。一个项目的成败与一个人很有关系，这个人当然就是PM。很不幸，开始的PM也是主程，当然这本身并不是不幸的最大根源，最大的根源在于他不会沟通…..

最近收到他的一封邮件，签名很有意思：用心沟通，从PK走向Win/Win。呵呵，真的很滑稽，一个PM以一种PK的心态来和别人沟通，结果是什么？Of Course，争吵吧。我就记得那时很不愉快，因为整个项目组都在争吵，吵需求，吵前后台的不一致……应吵尽吵。更有趣的在于，PM大哥就不站在整个项目的立场考虑问题，而是站在他主程的位置上考虑，更要命的是这个主程还是那种小家子气，就知道守着自己的一亩三分地，生怕自己工作做多的人。常听他说：这我不管，你给我怎样怎样就符合我的要求了。靠，大哥，你是PM兼主程呀！就这种格局！这是立场的问题，至于沟通的技巧就更别提了……

这就是当时项目组内的情况，你想产品的质量能好吗？而且当时各方的需求来势汹汹，他又挡不住，出现了赶工的情况，质量的隐患就这样一个一个的埋了下来，等待爆发的一天。当然这天并不遥远，而且是周期性的，一次接着一次。其实项目组开始时遇到这种困难也是可以理解的，毕竟在摸着石头过河嘛。关键在于出了问题怎么办？一个又一个的昏招出现了，做流程，流程中的每一步都抄送领导……靠，现在回想起来真是觉得很滑稽，究竟在搞些什么东西～

而且这GG的RP值实在不敢恭维，反映在一次重大的事故中的表现。那次事故比较大，惊动了老大们，这GG背着我们去汇报，在没有确定BUG的情况下就认定是我们前台出问题了，把自己撇的干干净净。于是处罚通知下来了，连累一个运维的哥们也跟着挨罚，当然他被罚的更多，因为他PM嘛。当老大们倾巢而出研究相关问题时，我才有幸有机会阐述一下对这个问题的看法，你不重现BUG，怎么保证下次不出现同样的问题。于是老大下令必须定位出BUG来。当天，BUG定位出来了，他的程序有个漏洞……事后他笑嘻嘻的过来说：终于给你洗刷了冤屈了～

害我们被罚款，被全部门通告，莫须有的罪名给我们加过来，又轻描淡写的对我们说他帮我们洗刷了冤屈……这件事对我的伤害特别大，连我自己都很奇怪当时为什么会忍下来，靠，老子不干了还不行吗，你爱找谁就找谁去。可能当时还是专注在技术层面吧，就因为他一个又一个的昏招，给我造成了各种需求，让我有机会用到大量的技术，成长还是很快的。只可惜项目变得声名狼藉，让我一点都高兴不起来。

部门渐渐意识到这个问题的严重性，于是调来一个新的PM，那位GG专注做主程了。这下更不得了了，凡是别人的需求在他那里都简单，凡是他的需求推三阻四，困难重重。新的PM还是可以的，至少对项目组的凝聚力要强上N倍。但一艘偏了航向的大船，也不是一时可以转过来的，何况他也没找对正确的方向呢。

整个一起就像走在一个沼泽地里，艰难的爬行，还要不时的受点伤～

三、二期开发

主程GG可能太具有战斗力了，总之是离开了项目组。这时中心的老大亲自督导，记忆很深的一次务虚会议是讨论我们的项目到底是做什么的，要给出一个定义。很有意义，只有在这个时候我们的航向才开始向正确的方向偏移。

之后，监控、配置各方面都加强起来，成绩慢慢的出来了，事故频率振荡衰减。经验也要总结一下：

1、坚定项目的目标

坚定了我们自己的目标，就可以站稳自己的立场，明确自己的优先级顺序，于是基础性的东西慢慢搭建起来，系统自然就稳定，同时对需求也可以满足的很好。摆脱了那种被需求拖着跑，这搞一块儿那搞一块儿的窘境，终于有了一个框架性的东东。

2、掌握节奏

坚定了目标之后，对需求就有了足够的勇气和理由拒绝，于是开发节奏慢了下来，开始重视质量，这样大家做的还是比较开心的。

四、尾声

今天又完成了一次改版，感觉用户的易用性得到了一定的提升。呵呵，做了一年多到现在才真正明白什么叫从用户的角度看问题，而不是站在自己的立场上。也算是一个大的收获吧。

同时今天项目组又重新进行了合并，吸收了其他两个项目组。不过我要离开了，不再参与了，去做自己更喜欢的后台。