不久前，我们有一个项目从岸上团队移交给我们的团队（离岸）。但是我们在移交过程中遇到了困难。
我们在设计演练过程中无法想到任何问题，因为我们被大量的信息所震撼。我们想问，但我们不知道该问什么。由于他们对我们毫无疑问，管理层认为移交过程已成功完成。
在参加移交演示之前，我们曾尝试浏览公司维基页面上的所有文档，但文档太多，我们甚至不知道从哪里开始。
我想知道，我们可以遵循任何规则或最佳做法，以确保项目成功移交，无论是我们还是我们。
感谢。
答案 0 :(得分：36)
在阅读文档方面，我个人会接受这个订单：
简要概述应用程序的基本功能 - 它的目的是什么。商业案例可能是已经存在的最佳文件。
然后是功能规范。在这一点上，你不是试图理解任何类型的技术或技术，只是应用程序的意图。如果它很庞大，请问他们关键业务流程是什么，并关注那些。
然后是高级技术概述。这应该包括架构图，所需的平台，版本，配置等。列出您的任何问题。
然后浏览任何其他有用的技术文档 - 如果有的话，肯定是FAQ，测试脚本也可以很好，因为它们概述了详细的“如何”类型的场景。也许只是我，但在我看到系统浪费之前，我发现阅读技术文档 - 这太过于学术化，而且通常会令人震惊。如果我不觉得自己在花费的时间里获得了合理的回报，那肯定是我花费的时间。
如果你们之间有几个人进行了结构化的评论，并且讨论了你们所阅读过的文件，那么确保你们已经掌握了所需要的内容。如果系统很大，那么每个人都会占用一个区域并向其他人展示 - 给自己一个尽可能多的学习理由，并且知道你将被提问，这是一个很好的激励因素。列出一些您不理解的问题。在您之间进行结构化评论将集中您的思想并使其更像是一个交互式任务，而不仅仅是一遍又一遍地浏览繁琐的文档。
一旦与他们面对面：
从完整的系统演示开始。当他们提出问题时，不要让他们用不清楚的答案让你离开 - 如果他们无法回答某些事情，请记下来并责成他们得到答案。
现在让代码签出并在您的计算机上运行。至少在两台机器上执行此操作 - 一台机器领先，一台领导机器。记录整个过程 - 这是最重要的一步。如果你无法运行代码，那就搞砸了。
完成构建过程。确保您可以构建应用程序（包括他们可能拥有的任何自动构建和单元测试）。请注意，所有单元测试都应该通过 - 如果他们没有，或者他们说“哦，那个总是失败”，那么他们需要在最终验收之前解决这个问题。
完成安装过程。一旦领导，至少两次，一次领导。确保记录在案。
现在提出一套与应用程序一起执行的常见业务功能。使用它来随身携带代码。代码库太大而无法覆盖整个事物，但请确保覆盖代表性样本。
如果有数据库或API做类似的练习。提出一些您可能需要提取的标准数据或者您可能需要使用API执行的一些基本任务，并花一些时间与它们一起完成这些工作。
询问他们是否有任何他们认为你应该知道的事情。
确保您在其他地方写下的任何问题都得到解答。
您可能认为值得通过错误列表（打开和关闭） - 从高优先级列表开始，并通过任何特别令人担忧的事情进行讨论。即使他们已修复它，也可能指向一些麻烦的代码。
最后如果存在机会 - 如果有任何未解决的错误或更改，请查看是否可以将一对夫妇配对。
除非您100％确定可以：
，否则不要最终接受该应用在他们拥有：
之前，不接受移交抓住他们的电子邮件地址和电话号码。即使它只是非正式的，如果狗屎真的击中粉丝，他们可能愿意帮忙......
祝你好运。答案 1 :(得分：11)
我接收移交的基本流程是：
如果文档太多（可能），只需确认它是最新的，并确保从中找到从哪里开始，如果不清楚的话。
尽可能多地提出问题;想到的任何事情，因为你可能没有机会了。
答案 2 :(得分：5)
大多数切换，或许所有切换都会导致大量信息丢失。我见过的唯一有效的切换方法是逐步完成。一种方法是允许第一阶段的一些关键人员继续保持项目进入第二阶段。
极端的解决方案是摆脱所有切换，并开始使用敏捷思维。
答案 3 :(得分：4)
首先，定义切换的退出条件。这应该与双方讨论，协商并达成一致，并确保高层管理人员知道这一点。然后写出一份清单，列出达到退出标准所需的所有事情并追逐它。
答案 4 :(得分：1)
查看"Software Requirements"和Software Requirement Patterns，了解有关在收集项目信息时要问的问题。我认为，正如他们为新开发工作一样，他们也会帮助您与现有项目达成协议。