设计解决方案：按规则行事

众所周知，软件项目越大，其成功就越取决于分析师的工作结果，尤其取决于对制定和同意设计决策的正确策略的选择。但是，您如何组织这些创意合作者的工作呢？以及如何使客户代表和程序员都清楚地了解其活动结果？如何评估可能的时间表和这项工作对项目的重要性？在本文中，我试图制定配方，以优化政府客户对软件项目的分析工作的管理。任何批评表示赞赏。



来源

研究框架

, .



.

由于目前在IT劳动力市场上有超过二十种“分析师”职位空缺，因此我将立即提出保留意见，以谈论有关创建定制软件的国家项目的分析工作。正如我的经验所表明的那样，不了解业务流程自动化机制的业务分析师无法准备充分的问题陈述。就像不了解自动化业务目标的系统分析师一样，这是不够的。因此，从我的角度来看，从事定制软件项目的分析师应将业务分析师，系统分析师和用户体验设计师的能力相结合。此外，通常，此类项目的首席分析师必须履行产品负责人的职能（如果客户允许）。关于这种“通用士兵”活动的组织，将进一步讨论。



在为政府组织的利益创建软件时，分析师的主要活动与解决以下问题有关：

• 需求管理；
• 为程序员形成任务说明，执行计划以及对这些任务执行的控制；
• 准备项目文件。

在上一篇文章中详细讨论了管理定制软件需求的细节，其初始优化的过程以及负责其实施的分析师的关键角色。



但是，客户愿望的特殊性并不能保证他会喜欢最终结果。在我的项目过程中，“识别”了以下模式：在所有类型的测试期间记录的客户的所有功能注释（不要与所识别的错误混淆！），与未事先与客户达成一致的设计解决方案的需求有关。在这方面，娜塔莉亚·鲁科尔（Natalya Rukol）给出的统计数据具有指示性。当分析一个项目的结果时，发现交付阶段暴露的“错误”中有将近70％是由于开发人员缺乏对初始要求的理解所致。 



在明确了软件产品的要求之后，似乎有必要按照GOST RD 50-34.698形成一揽子设计文档，与客户进行协调，然后完全根据批准的项目开发软件。经常是从昨天的优秀学生那里听到的这一系列动作（通常，C级学生根本不知道此类文件的存在），还有许多“经验丰富”的高级官员，他们从未亲自对软件开发的最终结果负责。 



根据我的经验，项目文档的形成只是分析师工作的最后一部分。打个比方，可以引用一项研究工作，作为结果，应根据GOST 7.32生成报告或撰写论文。但是，这些文件只是形式化所获得的科学结果的一种形式。进行毫无结果的实验​​，对“白噪声”进行统计处理，在大量伪科学废纸中寻找所需信息的颗粒-所有这些科学工作的不可或缺的部分始终处于幕后。项目文档也是如此。一方面，它是软件产品的组成部分...另一方面，它仅包含分析工作的最终结果。  





资料来源，



我认为，这是根据政府对软件项目合同的要求，“愚蠢”的客户计划在初步测试阶段（即，在设计文档中）就设计文档达成一致的众多原因之一。在实际完成软件开发时。



因此，在JIRA的软件项目中形成了两种不同类型的任务，这使我们能够将分析工作与准备项目文档的活动直接区分开。令人高兴的是，我不是唯一得出这样结论的人... 那么，分析师在指定需求之后并草拟项目文档之前，应该对软件项目进行哪些工作？

设计解决方案VS设计文档？

它在纸上多么美丽

，跟随单词多么容易。

使您无懈可击是多么容易。



格列本斯基科夫

尽管事实上在GOST 34.003-90中给出了“设计解决方案”概念的定义，但在我的案例中，在痛苦而徒劳的尝试与客户代表达成一致的过程中“发现”了该概念的含义，尽管客户只是忽略了提议的几个相互关联但模棱两可的要求我们描述了严格按照RD 50-34.698-90制定的目标设定（TMP）。在意识到直到测试开始之前不会做出客户方面的决定后，进行以下操作：将我们的设计解决方案发送给客户（即，他没有正式同意的解决方案）。 



仪式属性保留在设计解决方案中，但与托管的HMO相比，对该文档进行了重大调整。在设计解决方案中补充了自动化业务流程的示意图，其中包括简要说明，用户界面布局，已接收的打印报告形式，访问权限分配建议以及交付此设计解决方案的简短方案。根据模棱两可和相互矛盾的要求，进行了模棱两可和详细的描述。但是，以各种可能的方式将文本的其余部分最小化。根本没有描述平凡的算法，就像没有描述屏幕形式的字段一样，从给定的UI布局可以清楚地了解其目的和验证规则。  



所得鸡尾酒的形状与根据RD 50-34.698-90的要求草拟的文件同时相似，但实际上它不符合本GOST中给出的任何格式。同时，普通的，没有准备的客户代表会理解其中的内容。对于客户和承包商，本文档中指定的要求都非常清楚。确定了要求的界限，计划工作的要求范围以及应如何完成这些工作。



求职信中包含以下内容：



“我们提出了一种设计解决方案的变体，可以满足列出的要求。我们会通知您有关实施所提出的选项的工作的开始。如果您不同意建议的设计解决方案，请告知我们。”



在进一步讨论需求的情况下，未回复此类信函被解释为客户与提议的设计解决方案的正式协议。如果客户提出异议，在这种情况下，他被告知，该设计解决方案的实施工作已被暂停，只有得到批准，才能继续进行。通常，在这种情况下，进一步批准要快得多。



有趣的是，首先，在回信中，如果客户未发送必要的说明，我们会使用“工作暂停”这一短语。在几封这样的信之后，一位客户代表就“根据签定的合同，我们不能中止工作，而对要求的缺乏澄清不是终止开发的理由”这一事实引起了丑闻。但是，他对“工作无法继续”的说法没有异议。 



后来发现，尽管设计解决方案的形成的结构不符合GOST的要求，但是所提出的方法极大地促进了仪式体的运动，以形成和批准设计文档。该项目交付所必需的设计文档的内容是通过选择性复制设计解决方案的相关部分而形成的。同时，对于基于预防性“同意”设计决策而形成的文档部分，客户在验收期间未发表任何评论。

 大象的描述不符合GOST

事实是，客户不知道他们想要什么。通常，他们不知道需要回答什么问题，并且几乎从来没有考虑过应该在规范中指出的那么详细的问题。 



弗雷德里克·布鲁克斯

我认为，对问题陈述（设计解决方案）进行良好描述的主要标准不是满足GOST的正式要求，而是对成功完成满足客户要求的条件的明确描述。从这个角度来看，用于检查需求的测试项目的描述实际上是任何设计解决方案的组成部分。





应该注意的是，当与政府客户合作时，设计决策中的所有歧义和歧义将始终被解释为有利于政府。为了避免此类盲点，通过记录需求的反复试验，制定了设计质量评估清单，该清单列出了需要在设计解决方案中反映的主要部分。因此，应从以下位置检查任何设计解决方案。

1. 客户需求清单（将作为设计解决方案的一部分实现）。
2. 定义和缩写列表。
3. 规范自动化流程的规范性文件清单。
4. (use case), :
   
   
   
   
   • ( , BPMN – , : , ) ;
   • ;
   • ( ) — ;
   • ( , ).
5. :
   
   
   
   
   • , ;
   • (UI) ( , , ); 
   • () .
6. :
   
   
   
   
   • API;
   • () «» ( );
   • () «» .
   
   
   , « » ( 2011 ., 1). - , ().
7. :
   
   
   
   
   • , () , ;
   • , () .
8. () , , . ( ) . ( ), , () , . «» .

我重复一遍-这不是设计解决方案的固定结构，这是问题的正式列表（清单）），如果有必要，应在设计解决方案中以一种或另一种形式反映出答案。如实践所示，如果不期望与上述元素之一相关的开发，那么最好在设计解决方案中明确指出。或几乎是明确的（不要吓customer客户）。主要标准是明确的解释。重要的是不要过分执行，这样就不会解决所提出的要求，而是由于它的批准而产生了五个新要求。例如，短语“对象类型的引用应仅包含实际值”和短语“类型的引用不提供存储更改历史记录”的含义相同，但是第二个短语很可能导致必须描述和实现版本控制机制这本手册。在制定设计决策时，重要的是要了解其目的是确定规则，以确保您可以移交与这些决策相关的需求。

, , , .

项目的大部分（如果不是全部）取决于客户代表如何想象最终结果。因此，在初始阶段，设计用户界面布局是项目成功的关键。根据客户所理解的软件产品的外部描述，阐明并指定客户的要求。与讨论屏幕布局有关的与客户代表的对话被证明比讨论输入和输出数据格式及其转换算法（IPR的主要部分是根据GOST创建）的对话要有效得多。



在设计分配的框架内制定用户界面的所有元素，除了可以透明地理解实现边界之外，还可以解决以下问题：

1. . , , UI, , .
   
   
   
   
   
   : . . ISBN: 978-5-91180-090-1
2. UX- . , , ( ).
3. «» . UI , , – , ( « » ).
4. , «» . UX- . , 80% . , . ( ) : « ?». , , ( ) , , . , « ». «» . , , « ».

资料来源



我想谈一谈自动控制系统的用户界面设计原理。尽管移动设备的使用呈爆炸式增长，但台式计算机和笔记本电脑仍无法与政府机构使用的自动控制系统（以及解决编程和系统管理问题）竞争。当前，已经出现了用于接口原型设计的各种工具。但是，为移动设备的利益解释使用Figma或Axure的细节会丢失10％的原始方法，这些原始方法允许您设计90％的用户界面。ACS。



以我的经验，要大大减少软件开发问题，在设计用户界面时需要遵循一些简单的规则。



首先，您需要确定一种通用的导航方案，在该方案上，就像圣诞树一样，您可以轻松地悬挂越来越多的新界面元素。在这方面，对于我实践中的自动化控制系统而言，最有效的方案已得到证明，该方案已广泛用于各种IDE中。 



我不会在此处提供IntelliJ IDEA或PhpStorm接口的示例但是，从自动化控制系统的分析师的角度来看，我将尝试将此类UI的主要组件分解为各个组成部分。



根据此方案构建的界面在左侧包含一个可折叠的垂直面板，该面板可提供整个系统的导航。带有包含分层菜单的部分的垂直面板的存在实际上确保了“三击”规则的实施。





主导航栏的每个菜单选项都可以访问对象的表单列表。对象（目录）列表和显示这些对象的表格（卡片）构成了用户界面的绝大部分。在项目框架内将这两种类型的表单统一起来并在其基础上形成导航结构可以显着减少与用户文档不足有关的用户请求数量。



在任何列表形式的描述框架内，设计必须确定：

• 显示的属性字段列表；
• 列表视图模式的要求（默认显示，分组，排序）；
• 与列表项相关联的下级表单的要求（快速查看卡（表））；
• 筛选器面板的要求（根据给定的属性列表选择记录）；
• 组操作的描述（对多个列表项的同时操作，例如：比较列表项，更改多个列表项的属性，更改多个列表项的访问权限）；
• 根据列表选择的结果，描述运营统计报告（监视）的形式（面板）；
• 描述打印报告的要求以及生成报告的算法；
• 对象更改时通知用户（外部系统）的要求。

在设计列表表单时，以下规则非常有效：

1. — , «» , .   (ribbon). 
2. , , :
   
   
   • — , CRUD: , , , ;
   • ( , );
   • ;
   • ( , , ).
   
   
   
3. ( .. ) . , . .

  :

•   ;
•   , (CRUD, , ..) ;
• /;
• 可能的信息消息列表；
• 查看对象更改历史的方法。

关于工具包的几句话。由于在执行各种政府项目过程中反复试验，事实证明，以下三种界面设计方法是最有效的。

1. 万一在开发过程中需要更改现有接口，则不应重新发明轮子。在这里Paint.NET展示了自己的所有优点（顺便说一下，借助这些帮助，本文的图片已经准备好了）。再次重画表单没有意义，更改完成的屏幕截图更容易。
2. , — « »,   MS Visio . , , , , MS Visio, , , Windows. 
3. , -  , . , , . DHTMLX. XML-, , . (view), , . , , MS Visio. , , , « ».

反复地，将所有这些论据都交给高级开发人员，而不是客户的问题，我看到了他们的退缩视线，并听取了他们对拟议UI的烦恼和超载的专家评估。但是，随着时间的流逝，在分析了几个项目的经验之后，我注意到了一个惊人的模式：如果程序员热衷于批评已开发用户界面的落后性和复杂性，这肯定表明客户会欣喜若狂。

脚手架和模板

通常人们会思考很多。但是麻烦在于他们只考虑问题，而不是解决这些问题。



大卫·艾伦

在房屋建造过程中，使用了许多辅助结构，这些辅助结构在建造完成之后是完全不需要的。这些是脚手架和模板。值得注意的是，即使是非专业人士也不会试图质疑购买和维护这些结构的必要性。相比之下，在IT行业中，您经常会看到一名“经验丰富”的分析师在努力创建符合所有要求的项目文档。



但是，我认为，在没有预防性注册和批准设计决定的情况下，创建的设计文档仅适用于正式签订合同，并且将来对操作造成的伤害将超过其帮助范围。但是，上述设计解决方案和原型并不是分析工作中唯一的“辅助结构”。



资料来源



乍看之下，似乎一切都取决于分析师的经验，并且不可能规范这些辅助作品的使用。例如，如何考虑和规范分析人员的工作，他们整天拜访客户，第二天带来了3 GB的各种文档？还是分析师花了一个星期研究这些文件？这是好事还是坏事？如果您不知道根据项目的实现有意义的结果，那么您真的无法回答该问题。



因此，在我们的项目框架内，根据所取得的结果对所进行的分析工作进行了分类。除了设计解决方案之外，我必须参与的大多数软件项目都要求分析师开发以下类型的分析材料。

• 文件分析-关于客户监管文件或项目文件分析结果的报告。
• 分析审查-有关已出现问题的解决方案分析结果的报告（通常是对新技术或市场趋势的比较分析）。
• 信息调查-关于客户现有业务流程的研究结果的报告（按原样建立模型-“按原样”）。
• — ,   (use case).  legacy-.  
• — , ( ).  
• — , .

进行可预测设计的第二步是定义预期分析工作的特定要求。基于这些要求，为正在开发的每种类型的分析材料定义了JIRA问题描述模板。





分析材料开发任务的说明涉及所需结果的简短描述，而不是分析过程的描述。因此，例如，建议避免使用诸如“进行域分析...”或“研究文档”之类的短语。

艺术大师的计划 

一切都应尽可能简单地陈述，而不是简单。



艾尔伯特爱因斯坦

通常，在进行调度分析和编程工作时，在这种情况下，如何估算结果的时序存在很多争议。但是，以上对这种创造性活动的分析使我们可以做出一个假设，即在软件项目的框架内仍然可行。第一步是将系统设计工作分解成可以每周至少一次检查一次的部分。有必要努力确保分析师形成一个设计解决方案的人工成本不超过5个工作日（就数量而言，根据GOST R ISO / IEC 15910-2002，这种设计解决方案应占大约20至30页）。因此，根据相同的标准，程序员最多应花费3个小时来审查相同的设计解决方案。 



重要的是要理解，没有必要从设计解决方案中进行技术项目。设计解决方案应仅涵盖一小部分相互关联的需求，其结果可以呈现给客户。



同样重要的是避免在制定设计决策时落入Mary和Tom Poppendieck警告的陷阱。即，不要束手无策，因为事先制定的详细规范可以保证减少损失。通常，在就设计解决方案达成协议时，客户会尝试将他可以记住的所有内容塞入本文档中。因此，在就此达成共识时，重要的是要确保能够确保初步测试成功通过的必要最低限度。同时，成功的关键不仅在于质量，时间和成本的结合，还在于项目参与者对其结果的满意度。



通常，要获得完成分析任务的截止日期，对承包商本人进行专家评估就足够了，但是在发生争议时，可以采用务实的方法。...为了提高评估任务的劳动强度评估的客观性，可以使用在线计算器，该计算器可让您计划和估算进行分析工作的劳动力成本。使用此工具，您可以创建计划中的工作清单，并根据项目的具体情况澄清其措辞。对于每个计划的工作，均应考虑最低，最高和最可能的人工成本估算。计算的结果是，形成了预期的任务复杂性，并计算了最佳时间储备，必须将其留给保险。可以将生成的设置问题进行分析的描述直接复制到JIRA问题描述字段中。



除了文章“ JIRA：项目边界”中描述的常规属性外，对于JIRA中“分析”类型的每个问题，“”根据经验确定了以下一组附加（自定义）属性。





考虑到上述情况，让我们根据软件开发的需要，阐明分析人员先前为执行“分析”类型的任务而执行的操作顺序。



1.必要时，负责的分析师应安排JIRA中的任务，以便与客户代表进行信息调查（这些任务与相关要求相关联）。



建议在会议之前，首先近似形成用户界面的模型，可以与客户讨论。进行信息调查时，有必要从客户的角度与客户讨论主要业务流程（用户故事-用户故事）），以其他方式让客户看到最终结果。 



我经常遇到这样的观点，即信息调查的基础是采访一位称职的员工，该员工将向您详细介绍自动化流程的功能。但是，为了商业客户的利益而发展对政府可能产生最出乎意料的后果。我反复遇到一种情况，事实证明，基于白发退伍军人的故事而形成的过程描述与当前法规文件的关键要求相矛盾。这不是由分析师误解了事实，而是由资深人士“毕生付出”这一事实来解释的。



因此，在与主题专家会面之前，有必要从规范预期自动化的过程的角度来分析规范文件。重要的是要理解监管文件也不是最终真理，通常，在公正的分析中，监管文件总是包含歧义和矛盾（通常，例外情况是“血腥的文件”）。以下是您应注意的一些最常见的分歧：

• 违反分类的基本原理，例如，在同一组中混合使用不同的符号（红色，绿色，温暖）时；
• 根据属性构建报告文档，但未提供这些属性；
• ;
• - ;
• — - , .

与客户代表会面时，解决这些法规冲突是关键问题之一。为了修正此决定，作为信息调查的结果，必须制定协议，并注明参与者，地点和时间。该协议将提供给客户以进行澄清（电子邮件附在相应的任务上）。之后，可以将信息调查任务转移到“已完成”状态。在收到客户关于协议批准的确认后，此JIRA任务将转换为“已关闭”状态。



2。  根据指定的要求和信息调查的结果，形成设计解决方案。负责的分析师必须与项目经理和程序员进行协调（为他们每个人创建适当的子任务）。如果设计解决方案在工作日内未通过内部批准，则任务将转移到“待处理”状态（向项目经理发送信号）。通过内部批准后，设计解决方案将发送给客户进行审查（如有必要，批准）。发送的所有详细信息都记录在任务注释中。当设计解决方案在客户方面时，任务将转移到“待处理”状态。



3。如果同意项目解决方案（或者很明显批准被延迟，并且截止日期已到），则负责任的分析师将在此基础上制定开发，测试和文档编制任务。在这种情况下，有必要对实施设计解决方案的人工成本进行初步评估（作为与该设计解决方案相关的开发任务的人工成本之和）。基于此评估，有必要弄清相关要求的实施时间。



4. 与客户达成协议（确认这一事实的信件已保存在JIRA中）之后，准备设计解决方案的任务可以转移到“已完成”状态。

未完待续 

当前，最经常根据GOST 34系列的要求来组织政府客户的软件设计。同时，提倡最终设计文档与该GOST完全一致，大多数客户代表经常“忘记”，除了提供用于测试开发的软件的文档外，客户还必须在草案和技术设计的批准框架内批准设计解决方案。甚至在草稿和技术设计都已达成共识的情况下，出于不切实际的截止日期而完全符合表格的形式，忽略内容的情况并不少见。对于与生命安全没有直接关系的系统的设计尤其如此。因此，在其中一个项目中，一位副校长“教过生活”谈论他如何在一个晚上使用Wikipedia建立一个500页的技术项目。通常，完全不同的人必须弄清这种“设计决策”的结果。



在这些困难的情况下，此处描述的方法使您可以组织软件功能的迭代构建，同时保持已实现解决方案的一致性，这与精益软件开发的原理相对应。另一方面，所描述的设计解决方案的目标设置使得可以以最小的成本在满足客户“ Procrustean”要求的基础上编译文档。



将分析工作划分为基本操作，还可以协调受过不同程度培训的几名员工的操作，因此，很自然地形成了LANIT项目分析师的能力矩阵，我计划在下一篇文章中进行讨论。



聚苯乙烯本文是一系列名为“及时准备好吃的软件的规则”的文章的一部分，我将其用作对自定义软件项目团队的非正式监管，以符合政府组织的利益。本系列包括以下文章：

-“ JIRA作为失眠和神经衰弱的补救方法”-使用JIRA组织项目工作的主要思想；

-“ JIRA：项目边界”-统一项目的主要规定以及所有JIRA类型任务的一般要求；

-“ JIRA：需求管理”-在建议的模型内注册，澄清和控制客户需求的实施的关键特征；

-“设计解决方案：按规则行事-分析工作管理的主要方面以及为开发人员形成问题陈述；

在这一周期的框架内，正在准备发布以下内容：

-“分析人员能力矩阵”-评估定制软件项目上分析人员成熟度的标准；

-“在项目中隐藏着麻烦的地方”-对软件项目的当前状态进行操作评估的标准（度量标准）。



本系列文章的主要标签是基于改进的管理效率来提供软件项目质量的演进改进。换句话说，在CMMI模型的层次上形成应用的增长方法。

如果您想出了如何在软件项目中更有效地使用JIRA，请分享您的想法。仅在描述这些想法时，请避免使用“以某种方式”和“以某种方式”。我邀请大家讨论。我正在等待评论中的评论/建议/疑问/愿望。