在上周进行了一次“热”试飞之后，大脑显然放松了，陷入了一个问题：“为了使一切顺利进行而又没有这些烦恼，该怎么办？”
他生成的答案选项，我将尝试概述。
关于我自己
9年-IT顾问SAP ERP。职责：设计，团队建设，测试和调试，培训，试点。
适用性框架
他撰写的文章专注于从3-4个月到1年的复杂系统间集成项目。
决定不冒沉迷于实现完美主义的风险，失去了最初的写作导火索之后，我不得不放弃对结构，一致性和完整性的高度要求。出于同样的原因，我只写“来自个人经验”的文字，而在发表之前我没有阅读与该主题相符的文字。
因此，在某种程度上，我指望评论员编写第二版，其中上述标准已经处于适当水平。
词汇表
BA-业务分析师
BZ-项目知识库
BT-业务需求 IT-
项目团队的架构师和顾问
KP-
MC的关键用户-初级顾问，enikeist
PR-设计解决方案
产品-生产系统
开发人员
-CT 开发人员-测试方案
SC-高级顾问，
技术规范设计者-职责范围
IT项目成功的关键
一般信息是沟通顺畅
必须在感知业务需求，测试方案，设计解决方案及其在实现中的外观方面实现业务与IT之间的同步。
详尽周到的BT
英国电信必须在业务和IT之间具有完整而同步的理解。为此，应该是BA和KP（理想情况下，当BA是前KP时）。
完整的测试脚本集
在编写解决方案之前，应了解并制定出最详细方案的最大数量。脚本应该从最常见到最稀有开始编写。后者，在其昂贵的自动化情况下，必须进行周到的手动控制。
IT内部的分工
项目团队应根据工作的知识复杂性进行划分。如果设计人员能够熟练地在样式上准确地对文档进行样式设置，这是很好的。否则，最好是对具有初级职位的人进行“美容”指导。
这同样适用于当前状态下TK / PR的内容：
- 调查委员会将有关调整的情况写给开发商，并将MK复制到副本中
- MK使用版本控制收集并反映编辑模式下的更改
- SC接受编辑
- MK更新BZ中的文档
测试也应委托给MC。
我不很了解SAP之外的情况，但是这里经常使用顾问-收割者原则，它完成了所有工作（设计，测试，编写文档），
结果，质量，条款（和“金钱”）受到损害，并且由于一切都被捆绑在一起而带来风险1人
发布前测试脚本
- 测试应在接近产品环境的环境中进行（最好是在卖方的副本中）。
- 必须直接使用该功能的人员的参与（建议在此之前通过决定进行教育计划）。
集成系统团队的公共空间
当项目中存在复杂的集成时，必须创建项目上下文的公共字段并提供“贴近身体”的功能。理想情况下，整个项目团队应该在同一房间。否则，您需要单独的人员或方便的工具来确保团队之间的同步。
主持人技术上的充分性
企业的PR正式批准是项目的祸害。接收方必须充分详细地想象解决方案。如果项目涉及现有功能的深度现代化，那么企业应该完全了解它。
如果主持人是一个具有出色业务知识并具有一致且结构化逻辑的人，则是理想选择。
飞行员主持人
对于IT和业务人员而言，与仲裁员无关。制定试点计划，制定测试协议，跟踪评论及其更正。
如果有冲动，有一个想法来描述如果不遵循所描述的建议可能会出现的问题。