IT项目管理心得读后感

需求阶段，首先要确定项目的目标和范围，确定需求，时间的范围；一般而言是确定需求的在致方向，通过滚动规划，渐进式的细化需求，使得需求的细节尽量在预期的需求范围之内。如果时间允许的话，可以构造项目原型，更好的把握项目的需求和面临的风险，找到真实的需求不是一件简单的事，你要想成自己正与火星人进行交流，否则你会吃大亏，真正的需求几乎永远没有一单就谈定的。

技术框架，一家软件研发的公司或多或少的都有一套自己的开发框架，这些框架都经历的时间的考验，它的目标就是加强公司抗风险的系数，使程序员真正能够工厂流水化(这涉及到公司的管理文化，是把软件公司整成“电影公司”，还是”大工厂“)，理论上框架模型的运用会造成性能的影响，但是便于管理，可读性要高点。

团队建设，项目经理的主要任务之一就是合理拆解工作任务，全理分配个人；当然实现方式多种多样，有项目经理单人完成，这要求他的个人能力极高，要求他充分了解接手任务的开发人员的能力等等。有项目经理喜欢和组内成员一同协商，商量，最终确定任务的分解。这要求项目经理必须要有大的方向或主意，要求他有很强的现场决策能力和人格魅力，否则很影响士气和效率。原文讲到开发模式，我也比较喜欢敏捷开发，它响应快，实用性强，避免在文档上浪费太多的时间。说到团队建设，我认为需要一种文化，一种向心力，真正的项目经理他不是领导，不是朋友，而是领袖，是组内成员甘于追随的人，这在公司面临困难的时候，最能体现。

应对风险，在项目之初，就要有评估风险，包括技术可实现性，人员的变动，项目时间变更的可能性，甚至项目夭折的情况。尽管不想去想，也要勇敢面对，还要学好项目开发进程的控制。如果时间允许的话，最好做出简单的原型，验证各种风险，当然如果你是一位真水平的大师，可以不做，我之小辈定要学习之。当然实际开发项目中，原文也说到扯皮的事情，尤其是你负责的只是大项目中的一个组成部分时，组与组之间的沟通要有一定的备份，以防自己做了冤大头。