2012年工作心得总结

休假回来,终于可以静下心来总结一下2012年的工作心得。去年工作上最大的收获是比较深入地参与了几款互联网产品的开发工 作,其中既包括2C产品也包括2B产品,这大大拓展了我的产品阅历。我将从产品设计、技术开发、项目管理、团队建设这四个囊括了产品经理职责的方向来总结 去年的收获。

产品设计

1,产品设计一定要跑在技术开发前面。这点可谓是决定项目能否如期进行的关键,如果产品和技术处于同一起跑线,那么开发过程中必然会导致需求变更和沟通困难。理想的情况是产品跑在技术前面45天。

2,为某个行业开发特定的产品必须以对该行业的熟悉为首要基础。这点尤其针对2B产品,我在开发2B产品要注意哪些问题一文有更详细的阐述。

3,不能忽视产品开发过程中的知识积累和日志记录。优秀的程序员们都有积累和记录日志的好习惯,我认为产品经理同样需要做到这点,建立一个属于自己的知识数据库能够有效提高工作效率和探索新思路。

4,为UI设计制定一套规范文档。该文档的价值在于既统一了产品样式,也为将来可能出现的接手人留下一份清晰的UI指引,从而能保持产品样式风格的延续性。

5,在CRM/OA产品中,应该默认让用户进入一个概览页面,不同角色的用户在这里会见到与其业务相关的相应内容。这其实就是一个提供快速操作和查询的面板,其最终目的就是可以让用户不需离开该页面即可完成最常用的功能操作。

6,在CRM/OA等业务逻辑较为复杂的产品中,功能模块的导航栏设置在左侧可能是一个更好的选择。因为无论是从操作性还是扩展性上看,放在左侧效果都更好。不过,功能模块较少的话,放左侧没问题,但是功能模块多起来的话,左侧的树状目录会展开很长,这里会产生一个压力。

7,要记得浏览器适应性的问题。用数据说话:IE浏览器(含其内核扩展板)在中国的份额仍然在75%以上。如果产品没有能力兼容所有主流浏览器,至少要做到在IE浏览器中表现良好。

技术开发

1,要制定一套开发准则。这个工作可以由主程序或主管来做,必须规定所有程序员都要按这个准则来写代码,如此即能最大程度上约束程序员们的个性发挥有利于产品代码的统一性和提高开发效率。

2,要制作一些通用的模块便于为以后的开发奠定基础。将来用的时候直接拿这些通用模块来用或改即可,这些通用模块构成一个资源库。如此一来,无论以后有什么新人加入都能快速交接上手。

3,CRM/OA产品中应该做到业务逻辑动态化处理。每个功能模块之间的耦合度需要精确计算,不能出现改一发动全身的情况。最理想的状态是能实现功能模块和前端之间的“开关配置”。

4,应该为Bug分级。在时间有限的情况下,导致严重Bug的需要优先处理,小Bug可以暂时搁置。

5,旧有系统的数据导入新系统这个过程是一个麻烦频出的过程,要预留足够时间应对。

6,为了在有限时间内完成任务,可以简化需求,为将来的功能模块开发留下足够接口。

7,面对拥有相同样式的不同页面,设计师应把每个页面都做出来。从 长远来看这样其实是更省时间的。设计师有时可能会认为只需要做一个页面出来即可,其他的页面交给前端程序员去完成。如果这两位之间能够保持高质量沟通的话 这样问题不大,但如果做不到高效沟通,那么会带来大量隐性成本,程序员可能会不清楚究竟有多少个页面要做,设计师也不能完整表达PM的需求。

项目管理

1,在新团队处于一个新行业接手一个完全陌生的产品的开发时,应该在正式开发前组织该团队系统学习该产品所针对的业务和了解行业背景情况。俗话说磨刀不费砍柴功,对新接手团队的培训是绝对有利于他们提高对业务和开发对象的熟悉度,从而保证不会出现因认知偏差而带来的返工情况出现。

2,必须通过制定SOP来硬性约束团队成员的开发规范。SOP虽然刻板,但能大大提高效率,尤其在一个超过8人的团队中其功效会大于成本。

3,在CRM/OA的开发项目中,面对前任留下的系统或平台,新接手的团队往往更倾向于推倒重来,因为没人愿意面对那堆以前留下的代码。

团队建设

1,每周由一名团队成员分享与工作有关的观点,并通过PPT的形式为整个团队做演示。这个做法既能创造一种分享和交流的氛围,也能锻炼公众演说的能力。要注意的是活动不能流于形式,应该充分鼓励每个团队成员自发去做这件事。并且,整个过程要简洁简短。

2,每周技术开发组的同学聚集在一起分享各自的开发技巧和一些插件资源。

3,面对争议不需要尝试说服他人,只需要表达自己的观点,然后找出问题并解决即可。

4,同时也不应偏执维护自己的观点,观点不重要,结果才重要。

5,往往很多事情缘起于信息不对称,要记得每个人看待事物的方法和接收到的信息差异会导致行动上的差异。

 

发布在TMT那些事 已有标签 , . 将该链接存入书签发表评论或留个互链:互链地址.