|
•不应把过去的错误或者功能记在今天的账上，要持续的跟进大家的变化，持续的保持对大家的新认识。不以固有的眼光看人项目管理培训
•也应通过积极的引导，帮助同事改掉自己的不足。而不是听之任之，由其自生自灭。只有这样，团队才能进步，这也是一个leader最应该做好的事情，我在这方面差的还太远bbs.mypm.net
3.因事定人不可取项目管理者联盟
•某D之前由于某次技术预研的工作，让我认定他一般。但在这次的项目中，他却成了最稳定输出的一环项目管理者联盟文章
•由此可见，不能因为某人一时做的好或者不好，就给这个人定了型，先入为主的下定论。要客观的评价一下个人，需要了解他的全部历史和全部工作。也就是第一条说的，要有全面的考核反馈机制bbs.mypm.net
错误二：低估项目难度项目管理者联盟
1.项目共计4个，每个项目(只支持IE)都需要和额外的客户自研中间件、插件(ActiveX)、多种硬件设备对接。此前未做过和硬件对接的设备，低估了对接的难度项目管理培训
2.中间件、插件、硬件设备的对接我万万没想到，什么文档都没有。只能去搜历史代码学习测试，或者到相关部门去问问。而此前沟通过程中，我心中默认对接是有文档或专人指导的，没有问清楚service.mypm.net
3.前端使用框架(2006年的框架和版本)过于老旧，由于对前端了解不足，错误的估计了学习曲线，团队前端同事开发前期非常吃力，进度在这块也拖延了一大段项目经理博客
4.跨部门沟通的难度远超我的想象，此前沟通过程中，明确好跨部门沟通有专人负责，但到了实际工作中，都变成了我们自己去对接。各个部门互相踢皮球，一个摄像头到底是什么型号的问题(测试需要特定型号的摄像头，对接人不清楚借来的是什么型号)，我能花3个小时跑遍五层楼才得到答案。更不用说代码层面的指导了项目经理博客
5.没有了解到客户方框架的真实情况，心中以为是在spring上封装的脚手架。没想到框架中包含了快2000张表，数百万的历史代码。光用户模块就有不同的三套(该框架会在各个定制的基础上，定期的把定制内容合到框架主干上，导致了各种没有用的历史遗留代码)，找想要使用的功能搜索难度大增项目管理者联盟
反思：项目管理者联盟
1.经验很重要，但经验也很致命blog.mypm.net
在此次前期沟通中，很多我以为，我认为都是经验主义所害。比如对接文档的问题，多问一句，可能情况就很不一样项目管理者联盟
经验也可能成为风险之一，需要警惕项目管理者联盟
2.想法设法获取更多信息www.mypm.net
四个项目的对接人了解的信息都不全面，到我这的信息就缺失更多，而我当时以为这就是全部的情况。信息的缺失是会让判断失去方向项目管理者联盟
•在现有信息中，要去挖掘出更多的问题和信息，并找对接人确认。越多的信息越能为判断提供更准确的方向项目管理者联盟
•对接人也不清晰的情况，需要推动对接人去找相应人员获取，得到相对准确和完善的信息项目管理者联盟
3.锁定项目核心重难点项目管理者联盟
•在这几个项目中，有的项目没有在一开始就抓住项目核心重难点。比如甲项目中核心功能是存储，且需要使用客户自研存储设备，项目初期未锁定该重点问题，导致后期项目核心功能全部返工pmp.mypm.net
•一般采取排除法来锁定核心重难点。把所有的页面可见功能点和隐含功能点列上，以排除法排除独立的关联少的模块。留下的就是重难点的核心要素blog.mypm.net
•针对每个核心要素搞清楚联系关系，得到最终的功能关系图(业务架构图)www.mypm.net
错误三：战术错误，同时面对过多的项目项目管理者联盟
1.回过头来看，人手不足的情况同时接了过多的项目是错误的。但这的确是一个两难的问题，不能简单的用错或者对来概述转自项目管理者联盟
|
