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