<<  北京-上海-深圳小聚 | 首 页 | 启发式评估（Heuristic Evaluation）  >>

  • 近期项目管理的教训总结 - [三人同行--交流切磋的感悟]

    2008年07月27日

    分类: 三人同行--交流切磋的感悟

    版权声明：转载时请以超链接形式标明文章原始出处和作者信息及本声明
    http://buyantang.blogbus.com/logs/25719561.html

    没有大项目组管理经验，对项目组人员状况、项目状况以及可能面临的困难估计不足，都有可能导致项目延期或者不得不经常加班。总结下过去一段时间的经验和教训，以便有类似状况的同学共勉。

    教训一：认真对待产品MRD，不要有依赖心理。一个产品的MRD，无论多长，要自己仔细认真地读完。不要想着其他同学会仔细读，因为那几乎是不可能发生的事情 ==！ 产品的MRD面向UE，RD，QA，因此读起来很痛苦，要在几十页，甚至上百页的文字描述中找到给自己的那一部分，根本就是体力和脑力的共同消耗，且没有任何情趣可言。再加上，不同的产品经理习惯不同，刚适应了一种思维和描述方式，有要时空转换，努力理解另一个人的语言……现在回忆起来都痛苦  @@!  然而，依赖或者偷懒导致的后果，比那一时的痛苦长久得多。我的教训是被人投诉：项目组发出的文件错误多，返工率高。也许有同学会说，检查错误本来就是PM的职责之一，上百页的大系统描述，只有PM自己最了解。我想，道理也没错，但是自己不仔细阅读，发出的文件错误多，的确会导致项目延期、赶工，或者本部应该的加班。最糟糕的是，对方会认为我们不够专业，甚至不够敬业。这远比一时的痛苦糟糕的多。

    教训二：时时督促，经常了解进度。项目多了，脑子会乱，制作一张大表，不仅注明起始，还要注明关键点，以及要检查的文件。提前向相关同学了解进度，到关键点要检查、督促。UE在多数情况下，属于项目上游，即提供设计稿，前端展示等内容的部门，一个环节出错就会导致其他部门的同学延误。因此，团队内部的进度一定要把握好。老人一般比较自信，不喜欢用项目跟进表监督自己的工作，但是项目多了，难免记性不好，有遗漏也是不可避免的。所以，要养成习惯，天天更新项目组的项目进度表，督促和跟进各个环节的直接执行人。

    教训三：建立快速有效的沟通机制，以及及时通报机制。项目周期长，合作部门多的情况下沟通、通报机制的建立显得特别重要。ue作为上游，前端结果的提供者，既要考虑产品功能，有要考虑与后台的接口问题，因此不能只是蒙头做事。但有时候，个别部门习惯了通过第三方解决问题，而不是直接找ue沟通。这样做会导致信息在传递过程中的曲解和损失，给后续开发埋下“地雷”……我们能做的是抓住机会，扭转这种局面，有一个被动的需求接受方，转变为一个积极沟通者。当然也要注意机会和力度的把握。合作过程中，项目经理习惯不同，沟通方式也就不同；有人习惯电话联系，有人习惯直接到执行人的工位上交流，有的人喜欢邮件或者聊天工具……无论何种贯通方式，只要能及时解决问题都是可以的。问题是，这种快速沟通后的通报由谁完成以及如何让组内其他同学周知，往往被沟通的双方遗忘。例如，ue前段花了很多时间实现的一个功能，是另外两个核心部门已确定取消的；又例如，ue提交的前端交互是与产品经理协商国的，但是另两个部门不知道，转而质疑ue的工作质量……这些都是没有及时通报沟通成果导致的。

    教训四：建立有效的文档管理。一个项目在开发做成中会产生很多文档：产品mrd，线框图，设计稿，流程图，交互细节图，前端设计文档……每个文件都可能有不同的版本，或者是修改稿，文件编号必须有相对统一的规范，不能每个人都有不一样的命名方式。同时，要定期更新服务器上的文件，做到项目组内进度一直，所有人拿到的都是新文件。


    随机文章：

    使用体验-百度HI-1 2008年04月15日
    网站注册与用户信任 2008年03月22日

    收藏到：Del.icio.us




    Tag：
    引用地址：
    维尼 发表于17:46:56 | 编辑 | 继续话题 | 转发 | 分享　0