这里我们不妨从两个角度来看待这种方法。在项目管理中，一直有两个相互不同的视角在影响着项目。一个是管理本身的需要，那就是可以精确控制，我们姑且称之为管控视角。另外一个是项目的工作本身需要，我们不妨称之为业务视角。

管理者有个本能，那就是希望知道项目中发生的每件事情，例如工作效率怎么样，有什么错误产生，如果有可能，他们一定喜欢知道你现在心情怎么样，昨天睡觉睡得好吗？现在工作的“战斗力”是多少？成为管理者这个事实意味着他们心里永远有那种一切事情我都想知道，一切事情我都可以控制这样的冲动。所以，当管理者站在管理的角度上来看的时候，他们会认为所有那些报告文档都很重要，所有详细的计划都必不可少。例如质量计划、风险计划、沟通计划、评审报告和项目进展情况报告等。在那些控制要求比较高的领域，这种现象就会变得更为严重，例如，ISO9000。当管理者觉得需要在某个环节加一个控制点，来检验这个节点的状态，进行管理控制的时候，这里往往就会产生一个管理文档。作者曾经和许多公司高层管理者讨论过一套国家软件开发文档标准指南里面提到的文档需不需要在公司中采用，这套文档有72个。我惊讶地发现，凡是关于管控的文档他们的回答出奇地一致，那就是如果这个不需花费很多力气的话，那么最好还是采用这个文档。这就是管理者最本能的冲动。而传统的重量级的体系，往往就是站在这样的一种管控视角。因此，让广大技术开发人员深受其害。

业务视角则不同，这个视角完全是站在实际工作需要的角度上进行。例如项目的设计方案和需求分析无论是不是以文档的方式表现出来，如果没有这些工件是不可能完成项目的。这些文档就成为业务视角上的文档。而技术开发人员最反感的往往就是那些管控文档。业务视角文档，因为是工作必需的，所以他们不会产生多大的抵触情绪。

这两种视角之间的矛盾也会体现在某个具体的文档中，管控要求的文档要面面俱到，业务的角度要求满足业务要求即可。所以在公司中，大量的技术人员在填写文档的时候往往就会出现为了填写文档而到处复制。或者把原来的文档进行修改交付了事。

知道了这两种视角的差别，也就深刻地理解了在实施这种自适应开发方法过程中，不同的人所持的心理。(www.daowen.com)

管理者们总有管控的需求，因此永远希望过程可视化。技术开发人员则更希望抛弃这些影响，只做和业务直接相关的文档编写。以下的几个心理学技巧，可以根据情况参考使用。

（1）在实施的时候，为了避免一味地关注小块功能的开发而失去了整体的协调，可以在开发空间悬挂一个整个模块的逻辑图形，把不同模块按照完成程度画上不同的颜色。

（2）团队中完全可以照搬团队软件开发过程（TSP）方法，建立公共角色，鼓励共享，形成“人人为我，我为人人”的文化氛围。要注意这种文化氛围的建立关键点在于第一步，就是如何让每个人感觉到他收到了其他人的帮助。这一步需要管理者人为的设计。

（3）和语言口号相比，图形更有说服力。如果你想让项目小组成员更关注用户的需求和体验。你可以借鉴用户中心设计（UCD）的一些方法。