软件工程这一领域非常广阔，之前作为一枚螺丝钉，我一直尝试提高自己的姿势水平，不要太naive。现在突然有个比较大的工作需要团队合作，习惯了跟着别人的方向修修补补的我，突然要去做指引方向的工作，内心真的是诚惶诚恐。
说句实在的，从螺丝钉到平面，并不是说走就能走过来的。看过了无数的自以为很好的项目设计和管理，真的是被坑的很惨，尤其是在学校里，不再赘述。总之，暂时不去想技术能力的细枝末节，现在看看有关软件管理的教科书看一看了。让一切从头开始！
项目管理知识体系
项目管理分为十个不同的知识领域，然后在5个过程组中负有不同的任务和责任，可以在表中进行查询
项目确立
首先，对项目进行确立时，需要考虑可行性。这个可行性评估，之前建模的时候经常需要去做的，其中，方案众多，量化指标各不相同。最后的结果也是各不一样，总之是想要出什么样的结果就是用不同的模型对应着变更。至于说，变更的合理性有效性从来都是不管的，所以，看到这个我心里还是很慌的。
不过，书上给的方案是使用SWOT分析法。对于这个方法影响最深的是在《硅谷》中，两个人的各种神奇的脑洞，至于让我来进行这样的分析也是相当困难的。
在获得了对应的可行性分析之后，就是决策部分。在决策部分的时候，更多的就是使用加权的方式衡量不同的指标，判断最终的执行方案。
随后就是招投标的东西了，看的离我实在太远就暂且不说。横向的来看一次项目的确立过程，最大的不同就在于可行性分析和决策两个让我有着对应的感觉。为什么最终的需求方案会一次又一次的进行更改，客户对他们的需求不能正确描述？我觉得很有可能就是他们自己本身在可行性和决策的过程中，进行了省略和臆想。
市场的预期和自身的能力往往决定着产品最终的成败，对于整个项目而言，不再是说软件开发的技术能力完全决定着商业的成功与否，所以，跳出了之前的身份再来看，在一开始的分析中，需要的是相关领域的专业知识，在宏观上判断对应趋势，放弃细枝末节的部分。
生存期模型
不得不说，这个部分我还是有着对应的经验的，但是再看书上的定义我真的不懂为什么会有这么多事。然后，敏捷开发的模型主要讲了三个。
- Scrum
- XP
- OpenUP
都有迭代开发，增量更新和干系人沟通负责的组成。可以清楚的是，持续集成和速度恒定都是三个模型都有关注的部分，在固定的微增量的情况下，可以得到比较好的进度控制。
其中，我最为感兴趣的是燃尽图（burndown chart），感觉这个和任务报表结合会有比较好的激励效果，带来的认知效果和我第一次知道 TODO list 的感觉是一样一样的。
需求管理
软件需求是软件开发过程的基础，往往软件开发的成败也在于需求分析。对需求的把握成都就是项目成败的关键因素，这个明显应该需要单独开一个进行描写的，但是好吧，我认了。
总之，一入外包深似海，从此健康是路人。很久没有好好地去锻炼了，体重也在疯狂的增长，真有点中年危机的感觉了。