俄罗斯是非理性的。 有正确的做法，有一百次耙耙的感觉，但仍然有令人羡慕的持续性史诗般的事情发生。 有时是出于以下原因：“嗯，这肯定会让我大吃一惊”，有时是：“总是做到了，而且一直在努力”，有时只是因为错误。 也许在基因上。
令人难以置信的游戏的第一个生动的例子（在保安人员的要求下，细节有所改变）。 客户从事基本建设。 几年前，我从承包商处订购了一个系统来管理所有这些工作（特别是估计的工作量）。 该系统安装在十二个相当大的对象上，并进行了介绍。 突然，客户决定要求他提供源代码。 事实证明，他们现有的承包商计划让他们开发软件，然后将其作为SaaS出售给市场。 合同没有说明代码。 我们吵架了
当他们打电话给我们了解时，大约有10种不同的软件版本（版本从0.9到2.4）。 有1.5个来源，此版本是从他们那里收集到的。 没有文档。 并且该系统需要开发。 他们考虑“再次重写所有内容”并“最终确定1.5”，并选择了第二个-TtM，比去年同期多了三到四个月。 他们教我们如何收集支持专家，更正源代码，减少代码库，构建基础结构，组织一次“广播”，在那里接收，收集和分发源代码。 这使我们和客户花费了很多痔疮。
进来，我将向您展示更多有关如何在开发过程中犯错误的信息，以及由此带来的有趣结果。
另一个例子
客户-也是一个相当大的公司-推出ERP版本。 开玩笑的是，该系统是如此健康，以至于没有地方可以对其进行全面测试或类似测试。 根本没有基础设施。 更准确地说，存在，但是不可能进行负载测试，仅检查小的局部物体。 释放上升-而且没人知道他在实践中将如何表现。 曾经，一切都明显下降，因此，当发行版本无法正常运行时。 最后，他们邀请我们观看可以做什么。 我们讨论过，他们希望看到HP Performance Center，进行试点，然后进行集成，培训和交付。 现在通过它发布。 这些标准化的操作经过测试，是操作SLA的摘要。
或者，国家客户已经开始进口替代产品。 业务来了，对我们说：我们的IT专家告诉我们，用Postgress取代Oracle数据库非常困难。 我们不相信他们，请教。 两周的诉讼程序-结果是：“嗯，是的，更改基准很容易。 此时，您必须重写整个应用程序级别。 一点点。 大约90％。 您拥有庞大的程序包，您需要转移业务逻辑层-来吧。 由于该系统已有八年历史，因此不再能够找到编写内核的开发人员。” 他们相信IT团队。 原来，他们只是争论不够清楚。
我们在某个地方看安全，
这是一个史诗般的例子 。 幸运的是，这仍然很简单，五年来没有人做过任何事，而且这项业务还没有联邦制。
下面的例子。 我们接受了发布的故事。 理想情况：第三方承包商编写代码，将其传递给测试，将其通过测试，然后将其全部放入存储库，然后从那里收集并分发该代码。 漂亮吗 真好 我们在公司工作了三年，无一例外（在此之前，并不是所有部门和团队都可以）。 但是客户拥有“算法和程序资金”。 那里，每个艺术家都附带空白或源代码列表。 他们在那儿闷烧。 在审核过程中发现，动漫通常录制在一张光盘上。 即使基金中存在事实上的代码，也没有任何意义。
另一个类似的客户。 他们有一个典型的痛苦-许多承包商。 他们创建了一个行业内集成商，他们检查承包商是否带来了正确的软件。 问题在于存在第三方的权利（例如，具有病毒式开放许可的开放源代码库）-不道德的承包商可以在没有顺序许可的情况下提供所有这些权利。 在开源的情况下，您仍然可以解决该问题，但是有时会遇到商业图书馆。 有罪的人-猜三遍。 然后他们的一名承包商破产了，客户使用了该代码。 必须尽早发现这种情况。 我们帮助正确设置了流程。 我们有一个解决方案，例如自动化一系列算法和程序。 技术文档，版本，源代码，合同以及所有招标链接。 CIO的平均寿命为两到三年，这确实有助于下一任CIO立即解决这一问题。
我们还在俄罗斯引入敏捷。 我现在不笑马戏团。 几乎每一次它都是关于业务数字化的时尚故事。 最主要的是，每个人都试图理解这些词是什么。 但是没人知道。 概念秩序，雇用陌生人。 他们说“似乎”，“假设”，邀请初创公司，加速陷入泥泞，喝冰沙喝醉的词-通常，它们都有某种低谷的外在迹象。 然后，敏捷开始适用，但没有成功。 如果您的系统很认真，则需要检查很长时间。 如果不设置流程，则冲刺将很长（一个月或两个月）。如果设置了流程，则需要从测试基础架构，开发，构建交付管道，团队之间以及团队内部的工作流程开始。 所有这些通常都被遗忘了。 如果“老信徒”的工作过程达到98％，则该项目将无法完成。 最后，我们进行耙跑。 总的来说，我们不抱怨：面包也一样。 但是有时候我只是想以某种方式解释一下，或者说什么，IT首先是基础架构，然后是快速的TtM。 而并非相反。
通常会出什么问题？ 范例集
我和我的同事们在这里聚集了这样一系列悬而未决的问题，这些问题不是很客观，但却能很好地描述情况。 当然，我们只会去那些不好的地方，也没有必要将其推断出行业状况。 但我仍然相信您会从您的公司中学到一些东西。 一小部分。 通常，所有内容都用以下词语来描述：“流程效率低下，员工缺乏动力，工具不良或工具使用不当。” 好吧，现在-例子。
1.对开发人员提供的软件错误的处罚。我什至不知道如何理性地描述它。 对于已发现的错误来说只是一个好选择。 现在就掌握这些知识。 自然地，任何发行版（甚至很小）的发行速度都比其发行速度慢十倍。
2.从早上到晚上开会。开发人员必须参加。 他保持沉默，向电话点头。 当需要整个项目团队参加会议时，这些会议是相同的会议，加上部门负责人进行控制。 不可能不来。 但是参与几乎没有意义。 这是项目经理的传统错误，称为“过度控制”。
3.货物崇拜。 我们采用灵活的方法并严格执行它们。我见过的最好的东西：实现敏捷，但是像以前一样工作。 他们只是让开发人员站起来。 他们建立起来并告诉：我什么也没做。 它每天都在发生。
4.工具：我们实施以报告实施情况。“我们有一个Continuous Integration服务器，只有管理员可以添加任务。” “我们已经实现了一个二进制程序集存储库，并且有一个很小的磁盘，您需要删除旧的磁盘，并且只有最后三个版本。” 或在这里：共享磁盘上ex文件中的任务管理系统。 因此，尽管有Jira，但积压订单甚至在大型公司中也很常见。 在这种情况下，直到任务落入该文件中为止，没有人会做。 他是官员。
另一家公司有内部知识库，但是所有内容都直接存储在版本控制系统中：对于管理员而言，这更加方便。 操作系统发行版甚至添加在那里。 当没有人负责版本控制系统时，管理人员可以放入千兆字节的文件以将其传输到交易对手，因为在Dropbox中，该地方已经用完了。
5.编码标准：书写不理解或十年未更新。仅举几个例子：我们要求100％覆盖测试和文档的代码。 特别是所有第三方库。 缺点是缺乏标准测试。 最近，我看到工程师是如何部署系统的，并且用户无法登录，因为从测试到产品的密钥没有更改。
我再次看到领导者如何在Notepad.exe中编写代码，然后将其毫无错误地扔到编译器中。 他仍在学习打孔卡。 这样的技能当然值得尊重。 但是直到这种专业的变形开始影响其余开发部门的标准。
6.规定错误。例如，固定的午餐时间已完全步行。 这是一个症状。 我问为什么。 他们解释：如果您在午餐时间坐在工作场所，那么您就是目标。 必须在五分钟内回复信件，依此类推。
过度的官僚化：经常遵循记录在案的程序，导致产生大量文件。 每次打喷嚏都使用相同的测试计划。 这是对每个过滤器的描述，包括每个接口字段中的数据类型，字段长度等。 这通常是通过示例而不是全部细节解决的。
在一家公司中，没有人负责当前版本的发布，有时会推迟两个星期发布产品的截止日期。
通讯：邮件中的某些内容来自客户。 而且，他写信给最后与他交谈的人。 即使您要执行此操作，对任务的注释也可能位于不同的位置，包括即时通讯程序。 然后有人离开了，有人来了，有人删除了邮件-仅此而已。
7.与保安人员战斗。这包括对所有系统的手动更新（并且您需要自动将其溢出，这样可以节省大量时间），通过网络节点上的闪存驱动器的物理变通办法，三周的端口分配等等。
8.开发人员与分析人员之间的通讯尚未建立。这样的门槛在每五个项目上都会重复一次。 只是分析师写了所需的东西，开发人员开发了它，一个月后证明它已经准备好了。 这位分析师感到震惊，因为他不是这个意思。 尽管他可以展示项目的一部分内容，但分析师可能会询问进展情况，所以本月三周，开发人员徒劳无功。 有一些方法可以简单地解决这个问题，但是问题是，在这种情况下，双方都不了解为什么需要该项目以及该项目如何进行。
9.会议驱动的开发。主持人在会议上看到了很酷的东西，他们毫无保留地介绍了它。 三个月后重复。 结果，报告很漂亮，但是值得这么做。
通过内部会议，仍然有可能根据“始终准备就绪80％”的方案得出结果。 在公开报道中-“快完成了”，而且它是无止境的。 达到100％永远不会发生。 怎么了 好吧，例如，参见第1点。
另外，我注意到对第三方系统的审查不足。 您阅读了这篇文章-哇，太酷了，让我们使用它，然后学习如何使用。 您会遇到很多限制，因为供应商仅在前两次会议上才将蜂蜜倒入他的耳朵。 我们自己踩着耙子。 有一个内部实施的系统，用于在线存储有关基础设施设计的文档，包括。 数据中心中非常有趣的对象。 发现了一个限制商品成本1亿美元的案例。 诀窍在于，在主题区域中，文档的单价更高。 在那里，系统不得不铲开索引进行搜索，并且我们在文档中投资了1 GB。 预期的索引编制时间为一个月。 供应商对此没有发出警告。
10.害怕做出改变。项目的状态如此：您需要重构，一个月后回来。 但是没有测试，没有文件，什么都没有。 开发人员坐在那里：“我们害怕做出改变，我们害怕破坏一切。”
我还看到了一家公司如何开发与无法部署在开发人员一方的系统的集成，因为这非常困难。 测试人员（尽可能）对服务进行的数据传输进行测试。 交货之前，请先退到客户的展位，然后再进行两周的改进，因为交易模型有误。 最好为此系统创建存根以返回某种答案。 结果，他们这样做了，变得更容易测试和接受。
另一位客户可以用惯用的语言写经济描述。 在该项目中，我们提供了某种伪语言构造函数（一组标准），然后将其转换为分析师数据。 本着“如果Vanya病假，那么他将无法投产”的精神。
和最后的和弦。 一家公司中的其他人正在对产品进行编码。 “有个小提琴，我知道我在做什么。” 谢谢你，亲爱的人，但是如果我找到你，我什至不知道该如何对待你。
一般来说，说出来。 如果发现问题，请写信给oeremeev@croc.ru。 对于大型企业，我们几乎免费提供带有快速诊断程序的飞行员（在3-5天内搜索瓶颈）。 如果需要向您的企业中的某人解释说不可能忍受技术债务，请写上同样的信，我们可以正常计算。