前言：承续之前未完的（五），关于敏捷实践的相关内容暂且分享到此，本系列完结。
一、组织文化
你的公司首先要了解敏捷并支持敏捷方法的实施，否则上述所说的一切都只是空谈。
二、合同
在实施敏捷方法时，团队一直强调的是价值驱动，并通过频繁交付不断去刺探用户的实际需求。诸君试想一下：在需求不明确、范围可能随时发生变动之时，对于项目的工作量、资源该怎么评估？这便会产生了一个很棘手的问题：合同该怎签订？
诸君应该都有接触过合同的订立过程：根据项目需求评估工作量、投入资源、各种成本核算、利润核算、然后输出总价价格。。。这是我们传统的方式。但在敏捷中认为“客户协作高于合同协商”，这‘协作’必须建立在双方共赢的前提之下，即主机厂、供应商提倡共担项目风险和共享项目奖励，很明显，在现阶段的汽车行业要达成这一目标并不太容易。所以，在汽车行业中建议扮演供应商角色的小伙伴可以考虑如下做法：
1）分层/分文件签署。 将基本的条款以商务合同的形式签订，然后项目尽量不要以总价合同方式签署，而是转化为技术服务明细（即开口合同）。虽然敏捷项目变化快，但是对于企业而言要完成这些工作的技术内容肯定是在自己的范围之内的（超过技术范围的就别接了），如此便将不确定转变为了确定内容。以服务为合同附件，在每一次的迭代/增量开始前，对服务内容进行双方确认即可，如此便不用太过担心项目范围变化导致的频繁变更而产生额外的成本了。对于突发的资源，如突然产生的第三方试验等费用，可以再以应急资金方式纳入（事实上，对于这些内容主机厂也是有预算的）。
2、分项目签署。这做法就是麻烦点。在每一次交付完成之后，下一次迭代/增量开始前，双方重新签订商务合同，说白了就是将大项目分解为已知的小项目，每次以小项目洽谈，以少量多次的方式完成整个项目开发过程。
注意：对于敏捷项目，供应商尽量不要签总价合同，除非自己非常有自信不会范围蔓延。其他类似总价 激励/奖励等合同方式，在汽车行业中就没见过。
三、变更
当在混合或敏捷方法中项目开发遇到变更时，常用的方式是将变更过程视作一个敏捷项目，团队可以引入变更待办事项列表。每一个变更可视为一个实验，其将进行短时间测试以确定变更的适应性以及进一步细化需求。
注：敏捷对于文件的要求落后于实际工作，但变更在项目开发中特别重要，尤其是在软件的追溯性方面，因此建议将变更记录及时完善。
变更进行时，可以使用看板对变更进行跟踪，如下：
图1 变更初始待办事项到过程进行
通过上述可视化的方式对实施的方法进行跟踪，将提高项目成功的可能性。
公众号文章链接：汽车项目管理之敏捷方法（六）——合同及变更
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。