Nexus что это за программа

В двух словах о NEXUS

Весной этого года команда наших разработчиков побывала на тренинге по многокомандному скраму с использованием фреймворка Nexus. Это оказался очень интересный инструмент, и мы хотим поделиться с вами впечатлениями от его возможностей.

Nexus — это фреймворк Кена Швабера, являющийся органичным и эволюционным расширением классического скрама для крупных проектов с многокомандной разработкой. Он базируется на тех же привычных scrum-основах: ролях, артефактах и ивентах, дополняя их аналогичными ивентами и артефактами для выявления и управления зависимостями, своевременного обмена информацией и доменными знаниями между командами и удержания фокуса на конечном продукте, а не индивидуальных инкрементах.

Роли

К стандартным scrum-ролям добавляется новая — Nexus Integration Team, отвечающая за успешную интеграцию всех сделанных инкрементов и решение технических и нетехнических ограничений между командами.

Эта группа участников состоит из выбранных представителей команд, которые озвучивают интересы команды. Если рабочее время участников делится между NIT и командой разработчиков, то более приоритетна работа в Nexus Integration Team.

Состав интеграционной команды может меняться по необходимости.

События

С камнем преткновения многокомандного скрама — перекрёстными зависимостями между фичами и командами, — в процесс официально добавляются refinement sessions, время проведения которых жёстко не задано и выбирается в любой удобный момент спринта.

Событие проходит в несколько этапов: сперва NIT разбивает содержимое бэклога на мелкие и независимые части до уровня, когда одна команда может закончить фичу за один спринт.

Затем выявляются и визуализируются все зависимости между фичами и командами. На этом этапе NIT определяет своеобразную «дорожную карту» фич и зависимостей: что и какой командой будет сделано, в каком спринте.

Дальше фичи спускаются на уровень команд и пересматриваются более подробно с помощью того же подхода: разделить на более мелкие части, выделить и визуализировать зависимости.

Планирование в Nexus также проходит этапами:

1. На начальном этапе, где присутствуют все команды, Product Owner озвучивает и поясняет общие приоритеты спринта, цель общего инкремента. Представители команд еще раз корректируют распределение работы исходя из найденных зависимостей. Также на этом этапе формулируется общая цель спринта.
2. Дальше команды продолжают планирование в индивидуальном порядке, и результаты планирования по всем командам вносятся в Nexus Sprint Backlog.

Классические три вопроса скрама для интеграционной команды трансформируются в:

• Что было успешно интегрировано до сегодняшнего Daily Scrum?
• Какие новые зависимости обнаружили?
• Какую информацию нужно распространить среди команд сегодня?

Nexus Retrospective состоит из трёх частей:

• NIT определяет проблемы, затронувшие более одной команды, и передает их как дополнительную входную информацию для командной ретроспективы.
• Командная ретроспектива, на которой обязательно принимаются во внимание общие проблемы, определённые на первом этапе
• Финальная часть ретроспективы, где формируется общее видение, как визуализировать и отслеживать сформулированные пункты.

Артефакты

Чтобы видеть целостную картину по продукту, Product Backlog всегда сохраняется в единственном числе, как и инкремент. В Nexus нет командных Sprint Review, и результатом спринта является сумма всего, сделанного командами — Integrated Increment по продукту. Помимо Sprint Backlog, добавляется новый артефакт — Nexus Sprint Backlog, который является набором фич для всех команд с указанными между ними зависимостями — своеобразным общим планом спринта, — и используется для отслеживания прогресса и ежедневного перепланирования по общему инкременту.

Definition of Done формируется NIT, пересматривается и поддерживается в актуальном состоянии после каждой ретроспективы. Команды могут дополнительно создавать свои DoD, но правила должны быть строже, чем у общего.

Масштабирование

Масштабирование начинается с хорошо настроенного скрама в рамках одной команды — те же основы и опыт фрактально переносятся на многокомандный уровень. Постепенно исходная команда делится на две-три команды и итеративно и инкрементально добавляются новые разработчики. Нужно следить, чтобы общий инкремент оставался устойчивым и предсказуемым. В ином случае количество потраченных усилий будет несравнимо выше, и сложность зависимостей, интеграционных и коммуникационных проблем будет расти в геометрической прогрессии при добавлении каждой следующей команды.

Nexus предполагает работу над одним продуктом 3-9 команд. Существует еще Nexus+, представляющий собой следующий уровень надстройки над фреймворком (Nexus для Nexus-а), но стоит трижды подумать, прежде чем его применять. В какой-то момент количество времени, уходящее на менеджмент зависимостей, перевешивает пользу от добавления новых команд.

Single source control, continuous integration/build/test/deploy, use of SOLID principles, API’s, DevOps concepts и т.п. — чем больше масштабирование, тем большее количество техник и подходов необходимо использовать.

Product Owner отвечает за верхнеуровневое видение продукта, за стратегию, приоритезацию и определение ценности. В независимости от масштаба проекта, существует только один бэклог и один PO на продукт. Он или она может иметь помощников по ежедневными задачами: описывать критерии истории, разъяснять командам детали, обращаться за помощью к экспертам в какой-то доменной области. Но финальное слово по приоритезации остаётся за Product Owner.

• Блог компании NIX
• Управление разработкой
• Управление проектами

Как Nexus и здравый смысл вытаскивают проекты

Что делать, если от вас зависит релиз, нужно сделать интеграцию с 15 системами, работы на 9 месяцев, но дедлайн через 4? История Deutsche Telekom IT Solutions: как с помощью Nexus и здравого смысла ускорить поставку, успешно сделать все интеграции и спасти безнадежный проект.

Доклад на конференции Enterprise Agile Russia 30 ноября 2020 года.

Артемий Анцупов (ведущий конференции): Андрей нам расскажет о том, как фреймворк Nexus и здравый смысл совместно позволяют нам вытаскивать проекты. Андрей в эфире, пожалуйста.

Андрей Булов: Добрый день, дамы и господа. Меня зовут Андрей Булов, я работаю в компании Deutsche Telecom IT Solutions, ранее известной как T-Systems. Я из Петербурга. Сегодня я расскажу про то, как мы придумали Nexus, не зная, что это Nexus, и вытащили практически безнадежный проект.

Собственно, давайте пару слов обо мне, кто я такой. Я работаю в DT IT. Вообще, изначально я разработчик, Java, Python, Kotlin, пишу на всем, что пишется. В 2012 году увлекся Agile, и с тех пор прошел все, что только можно, попробовал все возможные фреймворки в Agile и Scrum, и поработал Scrum-мастером и product owner, и до сих пор веду тренинги по Scrum для Scrum-мастеров, иногда для product owners и, в принципе, для всех людей. Такой некий инжиниринг-менеджер.

Сегодня я расскажу про кейс, это такой скучный кейсовый доклад, без мемасиков, на корп-шаблоне, что-то немножко общо, потому что NDA, но я думаю, вы без труда узнаете любой Enterprise. В общем-то, 85% энтерпрайза узнаваемы здесь. Пишите в комментарии, я, к сожалению, их читать не могу, но потом мы это обсудим все.

Собственно кейс. Мы получили классный новый суперский проект с нуля от одного известного очень большого зарубежного производителя. Суть системы была в том, что это была единая точка правды для всех цен на продукты этой компании. В любой точке мира на продукт в любом временном промежутке мы должны отдать цену, то есть в будущем, в прошлом и в настоящем. Под этим была кучерявая бизнес-логика, в общем, оно должно работать очень быстро, надежно и классно.

Команда у нас была четыре человека, четыре «космонавта», на нашей стороне, я был одним из них, и, соответственно, на стороне Германии были Scrum-мастер, product owner и архитектор. Ну, и РМ, куда же без РМ, так как мы все-таки работаем в Enterprise.

Мы решили использовать некий Enterprise Agile Scrum, как я это назвал, это был скрамоподобный процесс. Несмотря на то, что мы работали в комплексном домене, для любителей Cynefin Framework, мы не изобретали чего-то нового на рынок – мы должны были сделать функциональность, которую уже делали до нас, но сделать хорошо и быстро.

Мы начали это писать. Собственно, стек был довольно распространенный, Java, маленькое внутреннее облако, Angular. Но была вишенка на тортике, Enterprise, во-первых, много, очень много корпоративных стандартов. Это безопасность, это работа с персональными данными, работа с коммерческой тайной и, наконец, работа с деньгами. Если мы ошибаемся положением точки в числе, то компания попадает на большие деньги.

Самое интересное, это 15 партнерских систем, которые льют данные в нас, это всякие-разные клиенты, это курсы валют, всякое такое, то есть такой хороший, классический Enterprise BackBone. И, конечно, работать должно быстро, потому что никто не будет ждать свою цену на веб-сайте 10 минут.

Мы разрабатывали, и разрабатывали мы довольно успешно, то есть обычная, нормальная жизнь, потихонечку пилим, все довольны, все готовятся к грядущим интеграциям. Конечно, сложно, успеваем, все здорово, но у всех есть такое знакомое чувство, что скоро должно что-то случиться, потому что мы смотрим на наш бэклог, на наш план работы, и понимаем, что некоторый функционал написан слишком широко, слишком общо, и что-то должно быть.

Конечно, это происходит. К нам приходит бизнес со стороны заказчик и говорит: «Ребята, так и так, нам нужно еще сделать столько и еще пол-столько», то есть полтора бэклога сверху. В общем-то, никто не виноват, все понимают, что это произошло из-за наших коллег слева, справа по нашему хребту, так сказать, энтерпрайзному, то есть мы будем писать их функционал, но нам от этого никуда не деться. Самое интересное, что мы это должны сделать в тот же срок, и если мы не успеваем, то мы еще ждем полгода запуска всего этого хребта, это убытки, это недополученная прибыль и…

Мы просто должны это сделать.

Менеджмент говорит: «О’кей, давайте увеличим команду на 14 человек, так получается, почти в три раза, в три-четыре раза, и мы это сделаем». Мы увеличиваем команду до 18+ человек по факту. Логично, что они не могут нормально работать в Agile-like процессе, то есть Scrum тут будет работать с трудом. У нас была мысль, конечно, сразу перейти на подобие Waterfall, на подобие PMI, составить план работы и все спокойно завершить, потому что более-менее уже понятно, что делать, scope был понятен. Но мы очень сильно привыкли к таким штукам в Agile, как transparency inspection, и не могли это потерять. Мы не могли понять в самом конце, что мы на самом деле это не успели.

Поэтому мы решили использовать, как потом выяснилось, хорошую практику Nexus, как взять людей из изначальной корневой команды, четырех человек, и поделить их на три команды. Мы получили три команды, которые независимо друг от друга пишут функционал, они самоорганизующиеся, у них есть внутри эксперты и, в общем-то, мы восхитительны. Все команды льют свой функционал на интеграционный сервер, мы прекрасны, мы практически изобрели LeSS.

Если бы все так было, конечно, доклада бы не было. По факту то, что каждая из команд написала свой функционал, залила его на интеграционный сервер и выполнила свой DoD (Definition of Done. – прим.ред.) на какую-то конкретную user story, это, к сожалению, не значит, что все работает со всем.

Какие у нас возникли проблемы? Первое, оказывается, что две истории, два куска функционала иногда могут не стыковаться. Даже если они написаны одним архитектором, но либо в разное время, либо каким-то витиеватым образом, они могут не работать вместе. Они прекрасно работают по отдельности, они написаны корректно, но не интегрируются, вот так вот мимо происходит.

Частый случай был, когда к нам приходила партнерская система, говорила: «Так и так, да, у нас есть согласованный контракт, но давайте вы у себя что-нибудь поменяете, допустим, мы вам шлем теперь не timestamp, а UTS DateTime, у вас это сделать проще, нам придется все переписывать». Или, например, интеграция в моке (mock. – прим.ред.), это самое любимое. Вроде как проверили интеграцию, все здорово, но мы интегрировались в мок, и по факту мы не знаем, работает у нас система или нет. Что делать? Вроде как работает, но не работает. Что мы попробовали с этим сделать?

Во-первых, классическое решение, дополнить Definition of Done. У нас не просто сторя сделана, закачана на интеграционный сервер, она должна работать, условно, в проде, то есть быть проверена с партнерской системой, должна работать, и прекрасно, хорошо работать под нагрузкой. К сожалению, это не сработало, потому что такое расширение Definition of Done блокирует разработку, и мы теряем начисто прозрачность, или его просто никто не будет соблюдать. Наверняка, вы такое пробовали, писать Definition of Done, где много-много-много-много всяких пунктов, но их в конце никто уже не читает.

Второе, пробовали решить проблему процесса, возвращаем на доделку. К сожалению, тоже не работает, потому что если мы фиксим задачу как багу, то мы получаем задачу на от одного часа до пяти дней в середине спринта на разработчика, и либо у нас будет бардак, либо задолбанный разработчик, либо мы просто продолбаем текущей спринт, текущий функционал в нем.

Наконец, такой более процессный подход, мы пробовали создавать задачи на интеграцию и заводить их в начало цикла, но это тоже не работает, потому что это очень долго, дорого и не очень эффективно. Оно сильно затягивает интеграции и не решает локальную проблему, то есть, по сути, тот же PMI.

Мы придумали такую штуку – слушайте, а давайте мы продумаем немножко зависимости заранее, ведь можно же как-то попробовать побить эти пользовательские истории, построить зависимости и так далее. Мы подумали-подумали, и решили – да, это хорошо. Кто это будет делать? Делать это будут, конечно, люди, которые этим и так занимаются.

Вместо трех команд у нас появилась четвертая виртуальная команда, состоящая из людей, которые занимаются интеграцией, из product owner, архитектора и, конечно же, нашего любимого менеджмента. Они и так общались до этого, менеджер ходил к каждому разработчику, спрашивал, что происходит, менеджер ходил к лидам, РО к ним ходил, QA к ним ходил, то есть было такое броуновское движение. Тут мы это сделали более официально, мы сделали виртуальную команду, которая каждое утро собирается и обсуждает проблемы интеграции и то, что нам нужно решить в течение дня. Все это началось с такого чудесного предложения.

Мы это назвали Leadership Team. Про то, что это NIT, мы узнали потом, и про то, что мы собирались на NIT Daily, мы тоже узнали сильно потом.

Что у нас из этого получилось? Получилось так, что мы изобрели Dependency Board. Мы взяли наши истории, мы поставили зависимость друг от друга, нарисовали зависимость от внешних систем, и начали это все делать на product backlog refinement с помощью этой самой команды. Там мы распиливали все предварительно между командами. Команды у нас были не полностью кроссфункциональные, это были больше такие ребята, специализирующиеся на конкретных модулях, то есть полу-модульные команды. Мы разделяли истории между ними, делали зависимости, и отдавали в команды, а потом они уже били их между собой и делали конкретные задачи, конкретные таски. Грубо говоря, для команд не поменялось практически ничего. Внутри разработчики как спокойно себе работали, так и работали, просто у них стало меньше головной боли, не нужно теперь было бегать в середине спринта, разбираться, что же происходит.

Помогло ли нам это? Да, помогло. Почти. Когда вы продумываете зависимости заранее, вы фиксите это все в процессе спринта, это работает, вы выкатываете вместе с интегрированной историей на интеграционный сервер. Но когда к вам приходит реальная нагрузка, реальные данные, либо приходят затейники в виде PO и end user, которые говорят: «О, а как же вот этот кейс, который мы не описали в истории, но он очень важен? Слушайте, мы про него забыли, если бы не посмотрел, я бы это не вспомнил». Либо ребята, которые нам присылают тестовый JSON-интерфейс, например, размером 1 мегабайт, и говорят: «Вот это мы будем слать» и вы отлаживаетесь на нем, а на реальном сервере к вам приходит 10 гигабайт, это реальный кейс. Вы думаете – ну, круто. Собственно, это можно было узнать только постфактум. Несмотря на решение части проблем в начале, мы все равно огребали в конце.

Что же делать? У нас наша структура стала выглядеть вот так, то есть у нас команда, наша Leadership-команда, которая занималась этим предварительным планированием, команда, которая занималась интеграцией, теперь стала выглядеть вот так. У нас NIT-команда, Leadership-команда стала заниматься и предварительным распилом историй, и решением проблем в самом спринте, то есть они бегали между разработчиками, разработчики бегали к ним. Наконец, они взяли на себя кусок работы, за который, по идее, команды отвечать были не должны, то есть это какая-то тонкая конечная интеграция, это связаться с какой-то партнерской системой во вторник вечером, попробовать нагрузку, это посидеть вместе в debug и так далее. Но выгружать это в команды смысла не было. С таким чудесным паттерном, когда у нас команда спокойно себе работает в агилизированном процессе, практически в Scrum, есть команда, состоящая из всех участников, которые участвуют в интеграции, помогает на каждом этапе всем командам вместе сынтегрироваться.

По большому счету, у нас получилось примерно такая картинка, как мы потом узнали, очень похоже было. Да и, собственно, все, мы сделали этот проект, мы установили такой процесс, и он у нас заработал. С помощью него мы вытащили этот проект, мы сдались вовремя, мы вышли в прод, мы были молодцы, это дело отпраздновали. Потом мы начали думать, почему у нас сработало. Что мы нарефлексировали?

Первое. Во-первых, появилась сущность, куда могут прийти люди и сообщить о нестыковке или блокере. Так разработчик должен бежать либо к соседу, либо к product owner, либо, не дай Бог, вообще куда-нибудь в Enterprise, к бизнесу, находить каких-то совершенно безумных людей, которые этим занимаются. Естественно, обычный middle или не очень опытный разработчик это делать либо не будет, либо его один раз проигнорируют, он забьет на это. Во-вторых, не всегда в команде понятно, что эта задача реально важна. Поэтому появилась эта команда, в которую все ходят и говорят: «Блокер, проблема, ахтунг, помогите».

Второе. Человеческая проблема общения, когда возникают зависимости, разработчик Василий идет к разработчику Петру, говорит: «Слушай, сделай это, пожалуйста». Петр говорит: «О’кей, сделаю, но потом, у меня сейчас свои задачи». Если Василий будет ходить к Петру в режиме дятла каждый день каждые десять минут, естественно, они разругаются, кто-то кого-то рано или поздно пошлет. Если есть специальная команда, которая решает приоритеты, и скажет Петру: «Слушай, забей на свои задачи, делай задачу Василия», все будет хорошо.

Наконец, в NIT у нас были менеджеры, это не по канонам, может быть, самого истинного Nexus, но это нам очень сильно помогло, потому что менеджмент видит наш прогресс, они смотрят, что мы стараемся, они видят наши проблемы, смотрят наши обсуждения и проникаются этой болью, и помогают нам гораздо лучше, чем если бы мы им докладывали просто какой-то статус как команды, либо они ходили бы к девелоперам.

Наконец, с точки зрения техники, на полностью проде всплывает гораздо больше, чем на простой интеграции, даже если вот оно всё заранее подготовлено.

Дальше была рефлексия. Собственно, мы начали этот процесс, мы подумали, что мы изобрели что-то крутое, мы начали его обкатывать на других процессах в командах. Собственно, какие же выводы все это показало?

Во-первых, Nexus и подобный процесс отлично себя показывает в комплексном домене. Там, где вам нужно сделать что-то, что вы уже сделали на большом масштабе, отлично заходит. Отлично работает на молодых командах, то есть когда команда ваша не сбита, она не втянулась еще в Scrum-процесс, она низкого уровня, но вам надо работать в масштабированном Agile. Понятно, что LeSS у вас там не зайдет, потому что команда слишком молода, но Nexus зайдет прекрасно, потому что вроде как есть Scrum и есть какой-то орган, который… там сидят вроде наши ребята, которые могут помочь.

Пробовали несколько раз в кризисе, работает. Самое главное, не требует орг-изменений после выхода из кризиса, просто становится спокойнее, просто из NIT могут уйти некоторые люди, и оно будет работать дальше.

Nexus можно внедрить, как мы это сделали, не говоря, что это Nexus, не зная, что это Nexus, и это можно внедрить и обосновать вообще без объяснения того, что вы делаете.

Наконец, для фанатов Meta-Scrum/Emergent, по-моему, они очень прекрасно вместе работают, мы это попробовали, оно завелось, всем советуем.

Немножко фантазий на тему, что если бы мы тогда придумали не свой нексусообразный процесс, а что-то другое. SAFe – очень тяжело. Наверное, взлетело бы, но запускать SAFe на три команды в условиях довольно жесткого давления сроков – это как ездить, простите, на карьерном экскаваторе километр в магазин: долго, дорого и тяжело.

Waterfall, Command and Control будет работать по определению медленнее. Почему-то если у людей есть сверху менеджер, который решает, и архитектор, который думает, у них немножко выключается голова, и мы получаем кучу бутылочных горлышек в виде этих людей, и оно перестает работать.

Наконец, Kanban. Kanban работает, в принципе, отлично со всем. Если бы мы использовали вместо этого процесса Kanban, нам бы не хватило вот этого чудесного ингредиента NIT или Leadership Team, без которого, в общем-то, этот успех был бы, наверное, невозможен.

В общем-то, с тех пор мы, я лично часто использую эти элементы, часто использую этот процесс и, в общем-то, всем советую этот крайне недооцененный фреймворк, который прекрасно работает в Enterprise, вне Enterprise, и вообще работает. Спасибо.

Вопрос-ответ

Артемий Анцупов (ведущий конференции): Спасибо огромное Андрею. Поступили вопросы. Спасибо, во-первых, вам огромное за выступление, спасибо огромное личное, персонально от меня, потому что я работал с фреймворком Nexus, мне он тоже понравился. Его недостаток, скажем так, в информационном поле меня тоже немножко удручает. Спасибо огромное.

Расскажи, пожалуйста, а вот сейчас сколько у вас команд, сколько вас человек живет по этому фреймворку, сколько проектов, может быть, или продуктов.

Андрей Булов: Сейчас в этом, подобном процессе живет как минимум четыре команды из тех, что я знаю, там, где я, так или иначе, принимал участие в этом, а остальные просто об этом, может быть, не знают, они используют какие-то элементы этого Nexus. Как минимум на 60 человек это работает.

Артемий Анцупов: Как минимум 60 человек, нифига себе. Слушайте, очень здорово. Скажи мне, пожалуйста, такой вопрос, ты уже ответил на еще один вопрос, да, почему не SAFe, почему не Command and Control. Ты, я помню, упоминал об этом, но все-таки поясни, пожалуйста, еще раз, а почему же не LeSS, почему у вас… Все-таки, когда такая ситуация возникает, первая мысль у многих – это именно «а давайте мы построим LeSS». С чем это было связано, какие были препятствия? Ты в what if про LeSS как-то не упомянул, можешь, пожалуйста, немножко про это рассказать?

Андрей Булов: What if про LeSS. LeSS – это очень классный фреймворк, который дает безусловные преимущества для опытных, матерых, хороших, сбитых команд. Но если у вас кризис, если у вас команды очень молодые, не сбитые либо неопытные, что часто бывает в Enterprise, мы не набираем команду «космонавтов», получается, что у вас просто он не взлетит как LeSS, не взлетит эта философия LeSS. Плюс это очень требовательно ко времени. Поэтому Nexus – это хорошее решение. Если бы у нас было больше времени, может быть, мы бы использовали LeSS, да.

Артемий Анцупов: Неопытные, ты имеешь в виду в плане инженерных практик каких-то, или в рамках самоорганизации именно?

Андрей Булов: В рамках самоорганизации, может быть, даже инженерных практик. В LeSS мы привыкли к фича-командам, мы говорим, что у нас фича-команды, которые делают все. Nexus прекрасно работает с модульными или полу-модульными командами. В некоторых случаях такой микс в Enterprise просто необходим, когда вы пишете какое-то сложное ядро.

Артемий Анцупов: Да, то же про SAFe когда говорят, да.

Андрей Булов: Да, все верно.

Артемий Анцупов: А у вас было так же, что у вас были команды полу-модульные, полу-компонентные, или у вас feature teams все-таки?

Андрей Булов: Да, были полу-модульные, полу-фича-тимы, то есть одна команда была более-менее универсальна, остальные были более специализированы.

Артемий Анцупов: Замечательно, спасибо огромное. Меня очень заинтриговал твой вопрос, внедрение без внедрения, запуск без запуска. А можешь рассказать буквально в двух словах для наших слушателей, как у вас это происходило? Может быть, кто-то захочет попробовать это после того, как услышит, насколько у вас это получилось легко и просто, или не легко и просто. Расскажи.

Андрей Булов: Все довольно прозаично. Первый этап, нужно сделать некое подобие NIT, которое вы можете назвать как угодно. Вы говорите: «Ребята, проблемы с коммуникацией, давайте общаться вместе. Но давайте это делать без девелоперов, которым это не всегда интересно, давайте это будут ключевые люди. Мы это будем делать каждый день, обсуждать наш статус». Все, вы сделали NIT.

Дальше у вас получается автоматический двухступенчатый Daily, потом у вас получается автоматически ретроспектива и, так или иначе, вы придете к двухступенчатому планированию, потому что у вас команда будет определять зависимости, если они у вас есть. Вот, вуаля, вы получили Nexus, хотите вы того или нет.

Артемий Анцупов: Действительно здорово, то есть вы просто начали с того, что вы собрали представителей, тех, кто владеет ключевой информацией, и стали ими просто ежедневно общаться на, по сути, дополнительном Daily.

Андрей Булов: Да.

Артемий Анцупов: Потрясающе. Скажи, пожалуйста, а вы использовали ли что-то вроде, я помню, что мы в Nexus когда работали, мы использовали доски зависимостей, Dependency Boards, не прямо такие, как в SAFe, конечно, более простые. Пользовались ли вы чем-то таким, какими-то визуализациями, какими-то, может быть, артефактами, которые поддерживали эту вашу кросскомандную коммуникацию?

Андрей Булов: Да, безусловно. У нас была своя самодельная доска в Jira и, конечно, Excel, без него никуда. Мы делали, но не визуализировали это в офлайне, к сожалению, к этому мы пришли сильно позже.

Артемий Анцупов: Все. Супер. Спасибо тебе огромное.

NEXUS

NEXUS — это совместная программа Агентства пограничных служб Канады и Службы таможенного и пограничного контроля США Trusted Traveler и ускоренная программа пограничного контроля, разработанная для предварительно утвержденных путешественников с низким уровнем риска. Члены программы могут избежать ожидания в пунктах пересечения границы, используя зарезервированные полосы на наземных пунктах пересечения границы в Канаду и США (в том числе из Мексики), используя киоски самообслуживания в аэропортах Канады, США и некоторых других стран, или Звонок пограничникам для входа в море. Членская карта NEXUS является действительным документом в рамках инициативы Western Hemisphere Travel Initiative (WHTI), поэтому ее можно использовать вместо паспорта, в том числе по воздуху, если вы летите между США и Канадой.

NEXUS был запущен в качестве пилотного проекта в 2000 году на пограничном переходе Порт-Гурон-Сарния с целью уменьшения транспортных заторов. В то время переход без задержек был доступен через две независимые программы — Port Pass для пересечения границы в США и CanPass для тех, кто въезжает в Канаду. Сотрудники таможни начали принимать заявки NEXUS в октябре 2000 года, а программа начала работу 28 ноября 2000 года с использованием выделенной полосы на мосту Голубой воды . Интерес к программе был очень высоким: за восьминедельный период, предшествовавший этому дню, было одобрено 550 заявителей и 2000 заявителей. Пилотная программа была рассчитана на шесть месяцев, после чего она будет подвергнута независимой оценке третьей стороной. [1] [2] В результате атак 11 сентября 2001 г. линии NEXUS были закрыты, а приложения приостановлены, пока были реализованы меры безопасности, связанные с Декларацией Smart Border . Полосы NEXUS на мосту Blue Water открылись в декабре 2001 года. [3] [4]

NEXUS официально был запущен в сентябре 2002 года вместе с программой свободной и безопасной торговли (FAST) в совместном заявлении президента Джорджа Буша и премьер-министра Жана Кретьена, сделанном на мосту посла . [5]

Чтобы претендовать на участие в программе, заявитель должен быть гражданином или постоянным жителем Канады или США или гражданином Мексики, имеющим членство Viajero Confiable. [6] Постоянным жителям США или Канады, возможно, потребуется прожить в своей стране в течение трех лет, прежде чем подавать заявку на членство в NEXUS. [7] Предыдущее требование проживать в любой стране в течение трех лет было отменено, чтобы позволить канадским и американским гражданам, проживающим за границей, а также тем, кто недавно вернулся, подавать заявление на NEXUS. [8] [9] Кандидаты также должны иметь законный допуск как в Канаду, так и в Соединенные Штаты, должны соблюдать иммиграционные и таможенные правила во время предыдущей поездки и должны пройти проверку на наличие судимости. Кроме того, если заявителю не исполнилось 18 лет, оба родителя должны предоставить свое письменное согласие или присутствовать на собеседовании. [10] [6]

NEXUS

Медицинская информационная система для больниц, госпиталей и поликлиник, которая позволяет управлять всеми финансами, бухгалтерией, кадрами и оборудованием учреждения.

Контакты

Характеристики

Стартовая стоимость

Бесплатная версия
Пробный период

Операционные системы

Cloud, SaaS, Web

Обучение

Документация
Персонально

Поддержка

Рабочее время

Возможности

Управление больницами

Амбулаторное управление
Интеграция бухгалтерского учета
Медицинский счет
Расписание встреч
Стационарное управление
Управление врачами
Управление записями пациентов
Управление инвентаризацией
Управление койками
Управление политикой
Управление претензиями

Пакетные решения с продуктом

19 продуктов

Оптимизировать работу медицинских учреждений и повысить эффективность работы персонала организации, а также наладить функционирование систем электронн.

Аналоги NEXUS

Клиентикс Здоровье

от Клиентикс

Клиентикс. Здоровье — медицинская версия облачной CRM-системы, со встроенной МИС, позволяющая контролировать деятельност.

HIS

от Promedart
Больничная информационная система, которой доверяют медицинские организации уже 20 лет.

Ezovion HMS

от QE Assure Services

Экосистема, которая интеллектуально управляет всем медицинскими задачами, начиная с операционной, IPD, EMR и заканчивая .

eMed

от Mushroom Softech
eMed — это система управления больницей.

HMS Ultima

от KNK GLOBAL SOFT

Решение для управления больницей, включающее оптимизацию фронт-офиса, управление амбулаторными пациентами, аптечное прил.

MocDoc HMS

Система оцифровывает все записи в больницах и клиниках, устраняя бумажную работу, управляет назначениями и предоставляет.

Axpert HMS

от Agile Labs

Решение для предприятия здравоохранения. Повышает безопасность пациентов, операционную эффективность и прибыльность.

Optimus

от Optimus

Семейство продуктов на базе веб-технологий, которые управляют медицинскими, операционными и финансовыми данными организа.

Policy Manager Software

от PolicyStat

Программное обеспечение для управления политиками на веб-основе, позволяющее предприятиям здравоохранения и другим орган.

TigerConnect

от TigerConnect
TigerConnect -коммуникационная платформа в сфере здравоохранения.

Trillian

от Cerulean Studios

Trillian — это платформа для деловой и клинической коммуникации, используемая компаниями и системами здравоохранения все.

TheWorxHub

от Dude Solutions

TheWorxHub от Dude Solutions — это облачное решение для управления техническим обслуживанием, предназначенное для медици.

athenaOne

от athenahealth

Решение для выставления счетов за медицинские услуги и управления практикой, которое помогает управлять претензиями, зап.

Популярные сравнения с NEXUS

Популярные сравнения с NEXUS

от KNK GLOBAL SOFT

Решение для управления больницей, включающее оптимизацию фронт-офиса, управление амбулаторными пациентами, аптечное приложение, биллинг и многое другое.

от ForeSoft

Разрабатывайте веб-приложения для баз данных или используйте готовые решения для сбора, обмена и управления важной бизнес-информацией.

от athenahealth

Решение для выставления счетов за медицинские услуги и управления практикой, которое помогает управлять претензиями, записью на прием, регистрацией пациентов, отчетностью и многим другим.

от Hands On Technology

Сократите время на ведение документации до 80% с помощью TheraOffice, наиболее адаптируемого программного обеспечения EMR и управления практикой для реабилитации.

от Optimus

Семейство продуктов на базе веб-технологий, которые управляют медицинскими, операционными и финансовыми данными организаций здравоохранения.

от Agile Labs

Решение для предприятия здравоохранения. Повышает безопасность пациентов, операционную эффективность и прибыльность.

Система оцифровывает все записи в больницах и клиниках, устраняя бумажную работу, управляет назначениями и предоставляет подробные отчеты.

от QE Assure Services

Экосистема, которая интеллектуально управляет всем медицинскими задачами, начиная с операционной, IPD, EMR и заканчивая обслуживанием, выставлением счетов.

от Mushroom Softech
eMed — это система управления больницей.

NEXUS с HMS Ultima

NEXUS с TeamDesk

NEXUS с athenaOne

NEXUS с TheraOffice

NEXUS с Optimus

NEXUS с Axpert HMS

NEXUS с MocDoc HMS

NEXUS с Ezovion HMS

NEXUS с eMed

NEXUS с Azalea Health

NEXUS с HIS

NEXUS с Trillian

NEXUS с TigerConnect

NEXUS с Smartsheet

NEXUS с Клиентикс Здоровье

NEXUS с Waystar

NEXUS с Policy Manager Software

NEXUS с RLDatix

NEXUS с TheWorxHub

Отзывы NEXUS

Отзывов ещё нет — ваш может стать первым.

Смежные категории к Управление больницами

Сравнить 0 продуктов категории Управление больницами
О компании

• Наша история
• Юридические документы
• Для инвесторов

Пользователям

• Категории ПО
• IT-решения
• Системные интеграторы
• Оставить отзыв
• Блог и исследования

115419, г.Москва, ул.Шаболовка, д.34, стр.5
Все права защищены © pickTech 2023

Все сведения, содержащиеся на страницах сайта (информационные материалы, каталоги, статьи и пр.), носят ознакомительный характер. Информация не является исчерпывающей. Информация на сайте не является публичной офертой, определяемой положениями Статьи 437 Гражданского кодекса РФ. Все права интеллектуальной собственности принадлежат компаниям — производителям программного обеспечения, как и товарные знаки и логотипы. Все ссылки на дистрибутивы, а так же выложенные статьи, товарные знаки и логотипы носят в себе только ознакомительный характер и не претендуют на интеллектуальную собственность, а так же ее нарушение