Flowcon或Bottle-管理技术，包括任务。 流，项目，开发，例行功能，常规等
许多人在了解了基于该方法论的方法和解决方案后，会问一些问题-什么，如何，本质是什么，基于制定的“世界实践”，使用的度量标准，适用于谁，来自何处。 我分别回答了每个问题，但我决定-一切都停下来，厌倦了写一百次相同的事情。 我是程序员，还是谁？ 重用不仅可以用于代码，还可以用于信息。 我将写一次，我将尝试回答本文中的所有问题，无论发生什么情况。
在我看来，最重要的是，以故事的形式呈现，可以这么说，因为瓶子的诞生与我的职业生涯息息相关。 我会的 追。
PMBOK
我知道的第一个项目和任务管理技术称为PMBOK。 那是遥远的2006年。
那时，PMBOK几乎是项目管理的垄断者。 在简历和职位空缺中，只听说过PMBOK。 那时，没有灵活的方法论，尽管它们已经存在于某个地方。
那时PMBOK是一种纯粹的级联项目管理方法，即 假定阶段和任务，截止日期和依存关系从头到尾都是严格的结构。 因此，由于不断违反“预算-时间-内容”三角形的著名（当时）规则，它在当时的1C实施项目中迅速精美地粉碎了。
在那些日子里，客户和实施者都无法制定合理的技术规范，编写功能要求，模拟企业的工作。 是的，并且像SCP这样的配置不断地给他们带来惊喜-他们不断发展。 结果，在项目开始后的某天，已编译的作品清单就变得无关紧要了。
但是程序员的大脑很好奇，他们提出了PMBOK和当时未知的敏捷的某种组合。 我们称之为黄色边缘。 我也被迫成为他的辩护律师。
黄边
黄色边缘基于PMBOK创建的阶段，仅从根本上替代了每个目标。 PMBOK的目的是什么？ 完成阶段的所有任务。
Yellow Edge提出了另一个目标：
签署该法案 。 例如，有一个阶段-“实施仓库会计”。 在设计和起草传统知识的阶段，其中会出现某些作品，例如“材料报告”，“用户培训”，“设置访问权限”等。 -根据速成考试阶段的学习深度。
这份作品清单是从某种东西开始的入门套件。 程序员来到仓库的负责人，或者是店主或材料会计师，开始与他们交谈，结果……嗯，有很多东西要学习，以至于笔记本以可怕的力量结束了。
起初，被PMBOK宠坏的大脑说：不！ 不可能！ 只需要做TK中写的内容！ 项目经理与客户进行了漫长的负面谈判。 有人设法说服客户进行其他工作，其他技术任务等。 大多数不这样做。 客户说：该死，伙计们，我不知道什么是传统知识，需要对程序进行哪些改进才能使一切对我有用，但如果不起作用，
我将不会签署该法案 。
从根本上说，现实是成功的，而项目在两个方面都存在：计划和事实。 看来该计划可以被取消，但有一个陷阱-已根据预算制定了预算，该预算受客户方面的项目经理保护，您无法修改。 但是事实仍然存在-必须尽量减少客户想要签署的最大金额，否则将不付款或相应地支付薪水。
所以在我的脑海里有一个Edge的模型，尽管是黄色的。 该瓶子开始成型，并包含两种任务管理实践。 他们似乎互相矛盾，但生活相处融洽。
核心PM
所以，我要提到的是堆。 看到自己和同事之间项目管理的问题后，我开始在PMBOK之外选择理论，并在商店里找到了一本书，由四位Tate编写，标题为“ Project Management”。 他们将方法命名为CORE PM。
本质与PMBOK中的基本相同。 计划的不变性被称为主要计划。 发明了直接分开，庞大，复杂和官僚的程序，以及如何对计划进行更改。
到那时，我已经认识到了黄色的边缘，因此无法将这本书中的任何内容添加到我的瓶子中。 这非常好，因为我再次意识到世界上没有聪明叔叔。
聪明的叔叔
关于世界上没有聪明叔叔的事实，很久以前，当我练习时，我回到了研究所。 然后，我喜欢产品质量管理的统计方法，然后去了工厂，在那里我花了一个月的时间收集文凭数据。
起初，目标就是收集数据，然后我和老师就想用专业软件（Statistica？）来处理这些数据。 似乎是为了建立输送机生产的数学模型，以便了解不同阶段对最终产品质量的影响。
出差之前，老师给了我一些有关Shekhart地图，统计过程控制（SPC）和一般质量管理（TQM）的书。 显然，他本人并没有读过它们-否则，他将不愿意制造垫子。 生产模型。 例如，它们适用于压力传感器，其中模型构建和Draper回归分析是校准的基础，但不适用于汽车行业。
我看书。 那里的一切都很简单，令人叹为观止。 并且工厂在质量管理服务中也有Smart Uncles。 他们从这些书中了解了基本概念，但是令我惊讶的是，他们不仅没有使用提高质量的方法，甚至没有使用最简单的公式来评估技术过程的当前状态。
公式非常简单。 您需要处理一百个细节，进行度量，在Excel中输入数字，计算平均值，标准偏差（相同的sigma），并显示一个简单易懂的指标-适用性指数或可重复性指数（如果过程稳定）。 实际上，该指标清楚地表明了该过程是否一切正常。
当我计算这个数字时，他们感到震惊。 从他们终于看到了这个数字的事实，到事实证明它多么可怕。 他们要求数更多的零件和机器-但是我呢？
然后有很多有趣的事情，包括在我在场期间的一项简单工作，即可从根本上提高生产质量。 但这不是重点。
当时我想到了一个关键的想法：
聪明的叔叔了解很多，但不要做该死的事情 。
这些方法是完整的-在质量管理，任务/项目管理以及常规管理中都是如此。 问问任何有效的经理-我将为您讲授如何根据这种技术进行操作。 并简短地询问-他会按方法论编写吗？ 无花果。
瓶子里充满了非常有用的知识。 一切都必须由自己完成和检查，没有人可以信任，尤其是那些无法在实践中证明其结果的人。
俄罗斯管理模式
意识到自己必须理解所有内容之后，我决定阅读其他内容。 我不想学习新的现成技术，而是想了解更基本的东西。 亚历山大·普罗霍罗夫（Alexander Prokhorov）的《俄罗斯管理模式》一书引起了我的注意。
说这本书很棒，什么也没说。 如果您在俄罗斯工作，则必须阅读它。 幸运的是，那里没有现成的食谱，但是所有拥有如此精美涂料的根本原因都在于此。
我将不会作很长时间的绘画，我只会提及在本文中很重要的一些关键思想。
首先，必须衡量俄罗斯人民的工作，以免他们扭曲。 因为我们习惯于欺骗任何系统，所以我们在潜意识中会这么做。 我们不接受规则，限制和法律。 更准确地说，我们点头同意，并且我们自己已经在思考如何欺骗。
第二-俄国人在所谓的最佳状态下工作 集群单元 小团队不能控制得太紧。 开放空间不适合我们。 如您所知，scrum中规定了相同的原则。
第三，俄罗斯人民不会像他们所说的那样做该死的事情。 这是实施任何方法时的关键思想。 您提供有关如何采取行动，释放人员并等待结果的指示，但事实并非如此。 因为人们抛弃了您的指示并照常做。
这本书后面的瓶子非常丰富。 的确，必须独自寻求解决这些“俄罗斯”问题的方法。 我找到了控制。
控制性
控制是基于数字的控件。 我最喜欢的技术之一。 我强调最主要的一点：控制不是控制。 这是管理。
如果没有数字，则根据间接信息盲目进行控制。 当您处理任务时，尤其如此，因为 用于衡量任务的系统通常毫无价值。 通常，这是以小时为单位的人工成本，截止日期（以及达到该期限）以及实际上要解决的部分任务。 无法基于此数据进行有效管理。
制定信息要求的控制部分，即 数字，获取方法，可重复性，质量，研究深度等。
该图应该是高质量的，但是您很少看到这样的图。 我已经写了几篇关于此的文章，我不再重复。 相信我-您不会经常通过控制标准来找到高质量的数字。 可能是因为没有人阅读过Wikipedia上的Controlling文章。
因此，控制出现在瓶子中。 它是通用的，从此控制了任何技术所需的任何数字的形成。
边界管理
边界管理或边界管理是关于转换业务系统的鲜为人知的科学。 尽管现在也许已经有所改变-几年前，我根据关于埃里克·特里斯特（Eric Trist）和其他人的作品的文章进行了研究，但我不记得姓氏了。 现在互联网上说有一本与此主题有关的英语书-我什么也没说，我还没看过。
最简单的底线是：
边界 。 在业务系统内部，即使是一个人，也存在很多边界。 身体，情感，精力等
边界是有害的，也是有害的。 有些会干扰过程的正常过程，有些则会将混合流分为两部分，从而有助于更快地进行处理。 有些人将人与必要的信息隔离开来，使他们难以及时做出反应，而另一些人则使他免受不必要的信息的影响，从而不会分散您的注意力。
简而言之，边界及其管理非常酷。 要了解这一点，您需要尝试。 对于像您这样的聪明人，只要了解关键原理即可开始应用它。 其余的需要案例研究和特定的实践，实际上有很多。 只有它们不在Internet上，但我们必须自己发明它。
我从出版的《
冰山》和
泳道的
方法中得出了一些建议。
边界管理对瓶子及其几乎所有部分都有非常强烈的影响-对任务生命周期的管理，对优先事项的组织，对常规管理的影响。
自己动手做
他称此部分与同名
出版物相同。 这是基于积累的知识构建用于管理订单，备忘录，计划和项目的系统的第一次经验。
经验相当成功，尽管这篇文章听起来更加负面。 在构建系统时，主要使用了控制，边界管理和Iceberg（来自业务编程）的原理。 当然，事实证明它太过技术化了，但是从其实用性来看，经验是巨大的。
首先，它是整个公司的系统，而不是一小部分程序员的系统。 其次，该系统实现了其目标-将执行纪律提高到了前所未有的高度。
但是对我而言，主要的事情是大规模地实际使用瓶子的各个部分，而不是程序员，而是普通百姓。 根据结果，必须将某些方法排除在方法论之外，但事实证明某些方法是有效的。 当然，大多数情况下是控制。
系统思考
这不是给我的，而是关于一个称为系统思考的知识领域的。 它充满了书籍和案例，所以我不会复述。 我只注意到一个非常重要的原理，它极大地影响了瓶子的外观-出现或出现的特性。 这些是只能在打开状态下才能看到的系统的任何属性。
当您离开系统并幻想其工作原理时，看不到紧急属性。 您甚至可以在公共场所进行设计，绘制，编程，测试，但是当您在实际工作中启动系统时，紧急属性将开始起作用。
例如，您假设一个人提出一项任务，而另一人则承担执行这项任务。 好吧好吧 第二个人可能根本看不到任务。 如果他看到了，他将不会阅读。 如果他阅读，他会说他没有阅读。 还是不明白。 还是不是他的工作。 等等
或者您认为团队中的协调员是老板。 他们为他提供了一份AWP，并附有一份清单，他将分发给表演者。 启动系统，您会发现他没有分发该死的东西，而只是在会议和公司聚会上奔跑。 任务由一个坐在角落里的安静，外表朴实的家伙（一个隐藏的领导者）分配。 而且，由于未引起注意而冒犯了他，他也将开始破坏您系统的实施。
这些是紧急属性。 它们在推测性设计中不可见；它们在系统开始工作时出现。
显然，“紧急属性”只是一种抽象，以至于有人想出一种每个人都可以理解的现象-您需要启动系统，从体系结构设计错误到琐碎的错误，还会有其他结果。
但是在任务管理的情况下，我们总是处理一个复杂的系统，该系统包括自动化，管理，与他们有关系的人员以及团队，客户，经理等的目标。 任务管理的成功取决于所有组件，尽管程度不同，但其中任何一个都不能忽略。
例如，如果您是一个自动化任务管理的程序员，那么您不仅可以，而且会忽略很多东西。 更容易 因此，该系统可能并且将无法正常工作。 没有错误，也没有意义。
我希望它能正常工作。 因此，我在瓶子中添加了系统思考-既是基本原则之一，又是特定的口音和做法。
武士手抄本和五环书
听起来很奇怪，但是正是这些书使瓶子变成了瓶子。 我现在将简要解释。
生活中像样的武士做到了这一点。 一开始我和一些大师一起学习武术。 他学习直到超越。 在这里，我们有一个体面的武士，他拥有某所学校的技术（比喻为PMBOK）。
他离开学校，在古代日本走了，以寻找新的挑战。 我去了不同的学校，被称为当地大师的决斗，并根据结果做出了决定。 如果主人比武士还要弱-好吧，不是命运。 如果武士输了，那么他会跪下来，要求带他当学生。 然后他学习，直到他再次超越了大师。
这进行了几次。 在某个时刻，武士有自己的风格。
一般来说，他不是每个人都出生的，这很正常。 有些人“没有面子”，只是几所知名学校（这类MBA）的硕士。
有些人甚至在进入第一所学校之前就提出了自己的风格。 例如，日本的民族英雄之一宫本武藏（Miyamoto Musashi），是两把剑的风格的发明者，也是《五环书》的作者。 或是Kyokushinkai空手道学校的创建者，韩国国民Masutatsu Oyama。 一个人和另一个人在职业生涯初期就发明了他们的方法，然后进行了磨练。 两者以及另一种方式都遇到了更强大的大师，并且仍然需要向他们学习。
但是，双方都没有离开他们的设备，而是用一个在特定时刻看上去更强大的陌生人来代替它。 他们只是简单地丰富了他们的技术。
最终，一个击败世界上每个人的体面的武士开了自己的学校。 其他的武士来到他身边，有人获胜并离开，有人失落并留下来。 等等广告无限。 因此，大山增达（Masutatsu Oyama）出于某种原因开始杀死公牛队，但并未在人们中间找到对手。
因此，阅读本书后，我首先了解了自己在做什么。 我就像一个体面的武士一样，从步行距离之内的学校开始-有了PMBOK。 然后他开始增加其他学校。 没错，我经常犯一个不雅的像样的武士错误-我没有结合练习，而是用另一种方法代替了，以寻找银弹。 PMBOK不适合-我们将其扔掉，采取CORE PM，它无法解决-我们将其再次扔掉，将自己投入混乱之中，依此类推。 因此，我改变了策略-我开始将新的实践方法用作实验，看看会发生什么，并将最成功的解决方案留在瓶中。
商业程式设计
业务编程是用于改善业务的一组简单方法和实践。 至少整个，至少某个部分。
碰巧的是，与瓶子并行开发业务编程，除本地IT部门外，改进的目标是一切。
但是，在某个时刻，突然之间有了理解。 好吧，我不太正确。 我知道如何改进任何流程，并且用某些外来方法折磨我的本机流程。
总的来说，我应用了业务编程，这是我一生中第一次获得可观的程序员效率提升，并且立即提高了两倍。 更改涉及过程，动机，目标，管理系统和自动化。 通常，与业务编程一起使用的所有五个组件。 我们自己建立工作。
结果给我，激励器系统的程序员，管理人员和专家留下了深刻的印象。
但是我，不是一个像样的武士，把所有结果扔进了垃圾箱，因为在出售时我买了一本关于Scrum的书。Scrum
这个世界上有两种嘲笑-对与错。Jeff Sutherland在书中描述了正确的方法。错误的-所谓的 Scrum指南，作者仍然列出相同的Jeff Sutherland。正确的说法是：有可能而且有必要将工作加速4倍。错误的人什么也没说，只是给你一些规则。正确的Scrum诚实地提供了日本质量管理方法的参考，称它们为Scrum哲学的基础之一。他特别建议使用体面的武士规则-以Scrum为基础，并创建自己的技术。错误的scram说-按照我们在此处所做的操作。而且，如果您以不同的方式进行操作，则这不是混乱。总的来说，我读了本书，并按编写的方式做了所有的工作。董事会，贴纸，集会，回顾展等结果达到了所有期望-我们的速度提高了一倍，也就是说，我们开始每单位时间产生两倍的结果。但是，出于一种简单的原因，必须丢弃纯粹形式的混乱-程序员团队分散到不同的办公室，并且失去了使用一个板的机会。他们曾使用两个董事会受苦一段时间，但也有集会和回顾性活动，需要个人参与。因此，scrum被放弃了。但是最好的留在了瓶子里。什么是最好的Scrum？没错，任务评估系统就是扑克计划。评估我们这个世界中程序员的任务再合适不过了。以前使用的时钟系统要差得多，因为不断出现估计的膨胀或收缩。点要稳定得多。作为计划的选择之一，瓶中剩余的Scrum元素可能只剩下一个冲刺。与1C合作的人都知道sprint是最常见的空间日历计划，即 在一定时期内需要出售/购买/生产的一定数量的产品。因此，感谢scrum，感谢您为我们提供的所有知识，但您自己在Scrum指南中自己挖了坟墓。我们只选了最好的。流scrum
然后，我有执行公司战略的经验。对于程序员来说，这种体验是独一无二的-可以说我很幸运。有必要改变公司大多数部门的工作，并且要知道，有各种各样的方法。有问题的单位之一是供应。我仍然不明白为什么这么难-功能很简单。然后我仍然对scrum感兴趣，并决定将其用于采购。但是他立即遇到了方法上的矛盾。程序员是一回事-每个任务在那里都是唯一的，非常值得将其写在贴纸上并悬挂在黑板上。供应商的任务是什么？买一百个套管？而明天-再次购买一百个套管？而后天呢？简而言之，贴纸并非如此。燃烧图不是那样。 Scrum是为项目实施而设计的，什么是项目？这是某种活动，终有一天会结束。从这个意义上讲，这必须是目标。在这里-购买。购买会永远结束吗？好吧，只有与公司合作。那是什么呢？不是项目，而是过程。但是这个过程很一般，因为它也给出了一定的完整性，并且有一个开始和一个结束。在他们之间-抽烟，互联网和厨房通讯。总统先生谈到他在2008-2012年担任总理的工作时给出了答案。他说：成为总理-如何站在无休止的任务，问题和目标的瀑布下。工作永无止境。有多少人不尝试，总会有事情要做。什么是瀑布？这是一个流。因此出现了流动的想法。谢谢弗拉基米尔·弗拉基米罗维奇。由于当时我非常喜欢Scrum，所以我不想放弃这个名字，我将供应链的方法论称为“德国Scrum”（因为它参与了控制，德国人对此尤为重要），然后- “哈萨克语Scrum”（以示笑意），最后是“流式Scrum”。重点很简单。
供应商的任务始终来自外部-来自销售和生产的需求。这些任务的优先级系统非常简单。而且工作的本质甚至更简单-从栅栏到午餐。需要衬套-订购衬套。我们需要螺栓-好吧，您知道该怎么做。依此类推，直至无穷大。因为人流。长期牢牢地扎在瓶子里的控制提供了正确的指标和单独的指标。很快就变得很清楚，老牌，经验丰富的供应商的工作要比单纯接受和做事，而不是谈论“过去的样子”的“女孩”要糟糕得多。结果是质量和成就速度惊人-在一个月内，他们将寄售仓库装满了“普通”管理年以前无法达到的水平。好吧，到了某个时候，我突然意识到，内部自动化项目还没有，但是有很多。将内部自动化分解为项目是一种惯例，这是1Snikov对PMBOK的热爱的遗产。需要有资金，时间表，预算，手续和官僚主义的项目。如果所有这些都在内部自动化中，那么显然需要做些事情。总的来说，物流及其管理人员已牢牢地进入了瓶子。展望未来，我将说Flowcon这个名字是从词组flow control衍生而来的。系统约束理论（CBT）
Goldratt的系统约束理论是一个原理，它说在任何系统中都存在一个约束，即最慢的链接，它的速度决定了系统的整体速度。好吧，Goldratt本人和他的追随者都基于这种原理开发了许多方法。例如，“新目标”一书中描述的Velocity技术涉及TOC和Lean。当然，主要原则从CBT入瓶-了解限制的存在以及使用限制的方法。我不是有意识地写“取消限制”，因为CBT不仅涉及消除，而且包括对限制的保护，有时还包括人为创造。正是TOC使我不仅着眼于任务的阶段，而且也着眼于“工具包”-在直接执行者工作之前和之后发生的事情。众所周知，完成一项任务通常需要15分钟，而接受，协调和接受结果则需要几天的时间。而这几天，客户或任务的发起者都在等待。可以从不同角度分析任务生命周期内的这些官僚阶段。 TOC会说这些是局限性的，因为它们最大程度地降低了生成目标单位的速度。同样的边界管理人员会说，问题是在参与协调的人员之间存在额外的边界。花费大量时间来克服这些边界。观点不同，但结果是一个-任务解决的时间过长。对齐只是一个例子。当“通讯”过长时，如何选择程序员的任务呢？这不是限制吗？当执行类型相同的任务总是到达同一执行者并且在他面前建立了一条超长行时，如何错误地选择执行者呢？来自TOC的特定方法也已进入瓶中，例如，使用缓冲区来确定任务是否有截止日期何时开始工作。但是，CBT中最主要的当然是原理，而不是方法。Goldratt本人在“站在巨人的肩膀上”一文中对此进行了写道。站在巨人的肩膀上
这是Goldratt如此着名的文章，他在其中放置了所有内容，包括-用Goldratt的话，他告诉了这些正派武士是谁。我不会重述该文章，它可以在Internet上公开获得。我只给出一个关键的报价。“应用的解决方案（应用程序）与这些解决方案所基于的基本概念之间存在差异。概念是通用的，应用的解决方案是将概念适应特定环境的方法。正如我们已经看到的，这种适应并不简单，并且有必要开发解决方案的某些要素。我们必须记住-应用的解决方案基于关于特定环境的初始前提（有时是隐藏的）。您不应期望此应用程序解决方案可以在原始前提不正确的环境中工作。 “如果我们认真地制定这些初始前提，我们可以节省很多精力，避免失望。”如果用您自己的话说，那么戈德拉特说的与武士和系统思维相同：不需要幻想，不需要喊“永远的混乱”或“ TOS-废话”，因为您永远都是错误的。尝试一下，不要忘记没有一种纯方法适合您。同样，您必须观察，思考和调整。观察结果
在不同的团队中介绍瓶子时，我看了很多东西。事实证明，这不仅简单有趣，而且很有用。因此，这个瓶子丰富了我自己发明的方法，实践和生活技巧。老实说，我还没有发明任何新东西，可以肯定地描述了一些方法，但是没有足够的时间阅读所有书籍。例如，有关选择任务的破坏性的文章很多。而且，如果选择了任务，但是有必要决定如何执行任务，那么例如程序员可以花费大量时间直到合适的时机，并且他不会采用第一个可用选项。正如绝地技巧的作者马克西姆·多罗费耶夫（Maxim Dorofeev）在一张有趣的图画中写道，如果可以立即完成* opu，那么等待通过* opu完成截止日期有什么意义，但是否有时间修复所有问题？我在我自己和其他人中都反复看到，选择问题的解决方案可能需要几天的时间。而且，这些选项在性能，优化性和用户便利性方面可以完全相同。但是，某些事情并没有做出任何决定，就是这样。工作-15分钟，然后思考-就像在制造火箭一样。有很多这样的例子，它们都影响了瓶子。他们继续产生影响，因为 一旦理解了我自己的观察并不比书本差，我就再也不能停止-完美无止境。无情的自动化
有一次，我把所有的知识都堆积了起来，就制作了新版本的任务管理系统，开始运用瓶子的所有知识，并得到了意想不到的结果-程序员团队的生产率提高了4倍。也许只是懒惰没有看过的我对这个问题的报告视频- 时间和2。实际上，这种经验促使我将瓶子作为一种技术来分发。我开始系统化信息和方法，撰写有关瓶子及其方法的文章，并谈论我的实践。新系统的安排
在经历了这段经历之后，我转到了一家纯软件公司，并且当然继续了使用瓶子的实践。 但是我遇到了一个有趣的挑战-我没有一个任务管理系统，在该系统上我获得了4倍的加速。
首先，我在1-2天内坐下来做了一个简化的模拟。 知道了这项技术后，这就没问题了，尤其是在不必选择方便性，界面等的情况下。
但是我不必长时间使用此系统，因为我们公司通过GitHub与客户进行了交流。 如果您知道的话，还有一种称为“问题”的任务管理。
挑战变得更加有趣。 从头开始创建系统是一回事，而对现有系统进行适应以使其符合方法要求是另一回事。 尽管您无法更改其中的任何内容，但只有标准接口和API可用。
因此，我从API开始。 这并不是说它很时尚，但是它提供了足够的数据。 事实证明，第一个问题是不可能以数字形式表示对问题的评估。 我必须遍历标签（标签）-它们是字符串类型，但是可以通过外部脚本将其转换为数字。 我写了这个脚本，并用了几个月-他画了一个效果图。
但是有些问题我无法在GitHub上解决。 例如，优先级排序。 有标签，有里程碑，有项目。 从理论上讲，在他们的帮助下，可以确定哪个任务更重要，但是使用此信息极为不便-您无法按标签排序。 我将不得不制作另一个脚本，该脚本通过API提取任务，排序并显示正确的列表。
总的来说，分支最终是死路一条。 我通过其他在线任务管理系统翻遍-问题相似。 到处都可以输入和存储数据，但是很少有配置工具-即，配置将数据转换为控制系统。 到处都有一个API，通过它您可以构建您的系统，但是问题是-为什么要使用他们的系统？ 只是作为数据源？
这种困境困扰了我几个月。 做还是不做？ 通过自己制作斑点将技术应用于GitHub？ 还是到另一个系统？ 以其纯粹的形式，在合理的时间内没有人适合，但没有人可以适应。 是的，并使用已经受够的外部脚本。
但是，尽管有两难选择，但经验还是成功的。 该瓶子虽然在较短的站立系统上也能很好地工作，但它加速了工作-最初是4次，然后是6，达到了10。很明显，系数取决于参考点，但是我不再担心这个问题了很长时间-我瓶子已经证明了一切。
转移到另一个新系统
然后我想起了世界上有1C，以及1C：Workflow这样的出色产品。 如果没有人知道，这是您可以在其中配置任何进程的程序。 因此，它本身不包含任何方法论，仅包含一种技术，应该有人告诉它一种技术。
大家在这里参加下一次1Snu会议，我决定参加那里。 我准备了一个空的标准1C：文档流，并开始在瓶中建立自己的方法。 荣誉和称赞1C：文档管理-花费了几个小时才建立起来，我们得到了一个非常不错的，与瓶子高度对应的任务管理系统。
在他的会议上，人们喜欢它，许多人对该技术产生了兴趣。 没错，事实证明，很少有人使用1C：用于任务管理的文档管理-这让我感到惊讶。 他们采用一些在线系统，其中什么都无法正确配置，内部也没有可理解的方法论以及效率的概念。 哦好
结果仍然是积极的。 他与GitHub中任务的使用相结合，表明该瓶子可以完全集成到其他系统中。 因此，我们得到了咨询，还有几个项目来加速团队在自己系统上的运行。
自己的系统
咨询当然很有趣，但是又长又昂贵。 大多数人都不太后悔放弃旧的任务管理系统，该系统几乎没有用。 好吧，人们想要二合一-方法论和程序，其中“一切都取决于方法论”。
因此，我们坐下来编写了任务管理程序，清楚地将其磨碎了。 设置很少，因为这些设置可以将瓶子从程序中删除，这将是下一个任务管理系统，更像是笔记本。
有趣的是，该程序的开发立即开始为该方法提供反馈。 有些东西必须从瓶子里扔掉，有些-增加，有些-改变了。 当然，我们自己很快就从GitHub移至Flowcon。
并再次流动
我以前从未经营过公司。 实际上，我仍然不能说我要负责-这里有我们两个人，权利和责任大约分为一半。 但是，我们必须处理公司生命中的所有问题，而不仅仅是开发或实施。
我们开发软件和服务，确定旧产品，介绍新客户，不提供服务的净销售额，支持老客户，市场营销，谈判，举办研讨会的展览会，家庭问题（例如金钱）等。 简而言之，我们是一家小型公司。
这种状况使我们重新考虑了瓶子，并在其中引入了两个新实体-流量和平衡。
我要做的每种活动都是流。 例如，我需要对新产品进行编程，解决实施中的客户问题，并撰写文章。 与任何程序员一样，我是一个充满激情的人，所以这并不困难，但是我非常不愿意在这些线程之间切换。
例如，我想坐下来开发新产品，而不花一个星期的时间。 会发生什么？ 没有钱，因为魔鬼在开始销售时就知道新产品。 我们必须转而与客户合作。
如果您不愿与客户打交道，那么也会崩溃，因为在相同的服务上建立业务是非常冒险的。
好吧，参与撰写文章-通常只是吐口水。 但是，那时将没有产品，没有钱。 因此，您必须克制自己。 起初，他直觉地做到了，他经常被误认为，被带走并遭受失败。 然后我意识到这些都是流动的，一切都准备就绪。
有可以测量和计划的流量。 例如，每月100小时-用于服务，300点-用于开发新产品，在此期间-4篇文章。 每个流都有自己的度量单位和方法以及自己的目标。 而且瓶子应该平衡这些流量，以确保公司的统一发展。
当然，与我们和您同在的流量不是三者，而是三者。 对于那些需要可持续发展的人们，有必要在战略基础上平衡一切，而不是在当前环境和灭火基础上保持平衡。
因此，瓶子已经从任务管理技术演变为公司管理技术。 嗯，这还没有直截了当-这个过程仍在进行中，但结果令人印象深刻。
发展管理
以前，我不必处理大规模使用的软件产品，盒装产品或服务的开发。 因此，该药瓶不包含特定于这些活动类型的方法。
当我们遇到问题时，就会出现差距-我们工作很快，而且产品没有进入市场。 正如他们在对scrum的笑话中所说的那样，仍然有必要了解我们正在以这种速度进行哪种废话。
我不得不调整瓶子-引入发布的概念，并基于发布重新构建优先级系统。 毕竟，发布不是项目，也不是任务，而是发布要进行的其他任务的容器。 发行，尤其是第一个发行是进入市场。 在这种情况发生之前，没有人会看到该产品，因此，将不会有任何反馈或金钱。
还有谁忘记了？
我觉得是时候四舍五入了。 如果您读到这个地方，那您将受到很大的尊重。 我还没有写太多东西，但是主要的东西，例如，已经反映在该材料中。
仍然有很多影响瓶子的技术和实践，但我不会列出。 也许有一天，我会为那些极力尊重各种科学方法，引文索引和“依靠举世闻名的方法”的人编写词汇表或参考书目。
是的，亲爱的作者，我从中获取了一些有用的方法，但在本文中没有提及，对此我深表歉意。
结果如何？
结果，我们有了一个瓶子-最佳管理实践的爆炸性混合物，可以提高效率。 它的存在正是为了提高效率。
对我个人而言，重要的是混合，而不是顺序。 您可以应用所有方法，也可以-仅选择一种或一半。 任何方法本身都会提高效率。 多一点，少一点。
正如文章中已经提到的，经过多年的实践，我在不同的企业中尝试了瓶子的各个部分，更重要的是，在完全不同类型的人类活动中尝试了该瓶子的各个部分。 那里有程序员，设计工程师，优质服务，供应，销售，生产，会计师，经济学家和经理，还有谁知道谁。
显然，每个行业都需要一套自己的瓶装方法和自动化。 但是您可以为每个人选择合适的工具包。 但最重要的是-瓶子正在发展，并且步伐加快。 因为他超越了我的实践范围，并开始迅速吸收其他人，公司和专业人士的反馈。
甚至有些人从已出版的材料中采纳了一两个想法并将其付诸实践。 尤其有趣的是，他们没有写信给我，但是，如果他们不小心在某个论坛或会议上经过某个地方，他们会诚实地谈论自己的经历，而不会害羞地说他们是从瓶子中汲取灵感。
所以，一切都会好起来的。