领导安排要去维护和扩展一个系统，要求做学习计划，并做学习成果汇报和评审。这期间发生了一些值得总结和反思的故事.

计划

为什么涉及到计划，进度的情况，我总是出现问题，是我们的开发过程有问题，还是有自身在工作上有缺点? 认真，严肃的看待计划及工作。

有了需求，目标，面对一个系统如何做计划？尤其是时间上的分配，怎样和上司协调？

1. 目标
   明确目标，也就是PM要求你做这件事的期望是什么？如果目标不明确，将无所适从。

2. 调研
   考察该系统涉及的内容，询问相关人员大致花费的时间。

3. 计划
   制定计划时间表

4. 学习

• 相关知识
• 绘制类图(系统的静态结构)；
• 绘制顺序图(系统的动态行为)

1. 扩展
   Ok，当我们确信自己掌握了整个系统的架构及流程后，我们可以开始对新功能进行分析设计。

2. 总结

扩展

弄清楚事实后才下判断，评价，不轻易下断语。

在觉得有需要调整或改动的时候，不要盲目的做出决定，一时轻率可能造成自己的信誉损失；二是人家这样做可能出于某种考虑，而你在完全掌握此系统前是无法意识到这种考虑的。这时就需要小心谨慎，不要妄下结论，珍惜自己的羽毛。

掌握一个系统是一个迭代的过程，由模糊到逐渐熟悉，反复振荡的。

汇报

做报告讲大致的流程而不需要太过深入细节，细节可以自己理解，但不必都讲出来。

评审过程中，别人提出问题后，及时的记录下来，不要沉入该问题了，继续演讲过程。评审固然是为了审查学习的如何，但更重要的是一种手段，目的是促进更快，更全面的掌握系统。所以在学习过程中要积极主动的去沟通，请教，以掌握系统或完成任务为目的，动用一切可以利用的手段。不要害怕，勇敢的Face to face的交流和沟通。

严肃对待复审（正式的考察）因为是作为一个考核标准，至于私下如何的沟通，提问属于非正式的工作。所以当期限到来时，如果没有准备好，就提出延期，而不是仓促上阵，不然会适得其反，别人看重的是结果，至于过程，是自己努力的。

做汇报是以自己已经准备好作为前提条件的。做报告之前，确信自己已经通盘掌握，做好充分的准备。在时间进度内完成目标固然好，但如果超出进度，但结果令人满意，就可以一切不计较了，重要的是结果。做报告前，先梳理下整个流程，并列出简要的提纲，以做报告时的参考。不要小看任何事情，随便说出很容易之类的话来。

学习时将UML图和文字记录结合起来，使用的手段不重要，重要的是知道目标时掌握该系统。对于系统中感觉不如意的地方，先别忙着批评，先确定自己掌握了整个系统再说，否则给人一种不好的印象。

Never Change Is Change Itself !