Проект

В первой части статьи мы рассказали, как расширяли лор игры Vikings: War of Clans, чем вдохновлялись и какие приемы использовали, когда создавали концепцию Хельхейма, истории персонажей Уннара и Вивы, а также имена Воинов и Порождений Мглы. Для второй части мы приберегли еще много всего интересного. Итак, поехали.

Материалы из Хельхейма

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

Концепция для сета 1

• Нейминг: название материала + прилагательное.

• Идея: материалы попали в Хельхейм из Мидгарда во время погребальных обрядов (вместе с умершим у викингов было принято хоронить предметы быта, оружие, одежду, любимые личные вещи). Эти предметы остались прежними по форме, но приобрели потусторонние черты.

Концепция для сета 2

• Нейминг: название минерала + прилагательное.

• Идея: Хельхейм скалистый и бесплодный мир, а основная активность в нем происходит под землей в Катакомбах. Поэтому логично, что вместо травы и деревьев в этом мире растут минералы, которые напоминают мидгардские.

Концепция для сета 3

• Нейминг: название предмета + прилагательное.

• Идея: во многих древних культурах считалось, что вещь попадает в потусторонний мир вместе с умершим, если перед захоронением ее ритуально убить сломать, разбить, сжечь (да, ладьи, в которых хоронили северян, сжигали именно поэтому). Сломанные или испорченные вещи символизируют связь с миром мертвых и могут применяться в изготовлении новых вещей (перековка, украшения и т. д.).

Концепция для сета 4

• Нейминг: животный материал.

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

Концепция для сета 5

• Нейминг: священный мифологический компонент.

• Идея: Хельхейм это очень необычный мир, и вещи в нем тоже необычные. Но нельзя создать вещь с удивительными свойствами, не применив никакого священного компонента. Это подтверждают многочисленные северные легенды: в Беовульфе и Саге о Ньяле, например, упоминается закалка меча в крови, а в Старшей Эдде при создании одного из мечей используется яд. Чтобы сохранить сеттинг игры и не уйти в фэнтези, мы предложили взять персонажей, сюжеты и предметы из скандинавской мифологии.

Вещи Воителей

Названия вещей Воителей (Уннара и Вивы) это комбинации реалистичных и фантастических явлений. Так как Хельхейм это другой мир, полный загадок и тайн, то и экипировка, создаваемая в нем, должна отличаться от привычной из мира людей. Общая стилистика на границе между средневековым гротескным реализмом и темным фэнтези. В названиях вещей для Хельхейма мы допускаем аллегории, метафоры и мистическую составляющую.

Формулы нейминга:

• Прилагательное + существительное. Причем прилагательное должно быть эпичным, мистическим, фэнтезийным, а существительное обозначением оружия, брони, какого-то действия или объекта (для создания метафоры). Например: Туманная кираса, Сокрушающий молот, Пламенный страж, Небесный удар.

• Существительное + существительное. Здесь одно из них указывает на тип предмета (головной убор, броня, оружие и т. д.), а второе добавляет художественности и фэнтезийности. Например: Капюшон охотника, Круг стихий, Перевязь тьмы.

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

Хольмганг

Предыстория

Как и в случае с фичей Хельхейм, идею для нового события мы подцепили из истории викингов. Что же такое Хольмганг? Это поединок двух викингов, в котором они заранее договариваются о правилах. Наш Хольмганг адаптирован под условия игры Vikings: War of Clans. Это эпическое Соревнование, которое представляет собой подобие поединка, но между Кланами. В нем участники должны по очереди защищать свои Форты и атаковать чужие.

Действие происходит на Островах Испытаний, заселенных NPC-войсками, которые помогают защищать Форты. Прообразом локации стала средневековая Исландия и жившие там свободолюбивые и суровые люди.

Название Хольмганг непривычное, однако у него есть свои плюсы:

- оно достаточно простое всего 2 слога;
- емкое по смыслу: означает дуэль (в нашем случае командную) и переводится как прогулка по острову;
- запоминающееся, его сложно с чем-то перепутать;
- легко сокращается (игроки уже называют его Хольм или ХГ).

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

Концепция

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

Соревнование назвали Хольмганг как древний поединок чести у викингов. В качестве площадки выбрали Острова Испытаний, населенные Стражами Островов, которые когда-то покинули Королевства Севера ради свободной жизни. Эти люди не хотят служить Ярлам, но готовы тренироваться вместе с ними, так как знают об опасности Мглы.

Чтобы принять участие в Хольмганге, Вождю или Старейшине нужно подать заявку. Кланы-участники распределяются по особым Лигам (самая младшая Первая, самая старшая Седьмая).

На Островах Испытаний есть Форты укрепления для обороны и нападения, окруженные Мрачными топями. Цель Кланов разрушить чужие Форты и защитить свои.

Желание викингов усилить оборону укреплений привело к тому, что в Цитадели Клана появилось новое здание Мастерская Ловушек. Там изобретатели придумывают разные способы сделать ловушки эффективнее.

Лорные статьи

Чтобы поддерживать лор Vikings: War of Clans, углублять его и погружать игроков в мир скандинавской мифологии, мы периодически пишем лорные статьи. Вот, например, две из них.

Статья Путь в Хельхейм

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

Все части статьи написаны в разных стилях, каждая повествует об отдельном персонаже. В итоге у нас получился большой познавательный текст, состоящий из четырех глав: Хель. Царица мертвых, Уннар. Упрямство цвергов, Вива. Любящее сердце и Ярл. Покоритель миров.

Особенности статьи

• В повествовании мы опирались на скандинавскую мифологию. Использовали яркую, экспрессивную и метафорическую лексику.

За пределами мира людей и мира богов, у самых корней ясеня Иггдрасиля лежит окруженная ледяными потоками реки Гьелль земля мертвых Хельхейм. Каждый, кто погиб не на поле брани и без оружия в руках, отправляется в этот холодный, укрытый туманом край.

• А еще мы экспериментировали с разными формами повествования.

Вот часть письма, которое Уннар пишет правителям мира цвергов скандинавских гномов.

Королю и королеве цвергов от Уннара-исследователя

ПРОШЕНИЕ

Ваши величества! Я не привык общаться с особами столь высокого положения, поэтому скажу прямо: отправьте меня в Мидгард.

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

А вот диалог между альвийкой Вивой и мудрецом из ее племени.

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

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

Вы думали, это все? Ан нет! Стихи. Да не простые, а стилизованные под Старшую Эдду поэтический сборник древнеисландских песен о богах и героях скандинавской мифологии.

Уннар и Вива
нам указали
место, где ткани
миров истончились.

Модгуд и Гарм
нам путь не заступят
сразу в Хельхейме
окажутся воины.

Помимо этой статьи, мы еще подготовили небольшой текст, в котором кратко рассказали о Хельхейме. Так что если времени у вас немного, но окунуться в мир мрачных подземелий хочется, то добро пожаловать.

Статья Как воевали боги и что из этого вышло

А в этом тексте мы рассказали о войне асов и ванов.

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

Особенности статьи

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

Сначала всей семьей они решили противостоять искушениям, тыкая Гулльвейг копьями и сжигая на костре. (Спойлер ничего не вышло, она же персонификация!)

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

• Арты для этой статьи (как и для статьи про Хельхейм) совместная работа отдела копирайтеров и отдела художников. Мы, как авторы текста, давали рекомендации, а иллюстраторы воплощали идеи в жизнь. К примеру, для рисунка ниже мы просили с одной стороны нарисовать ванов (зеленые цвета, символизирующие плодородие), а с другой асов (агрессивные цвета и атрибуты войны).

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

Вместо вывода

Возможно, вы спросите: зачем вообще все это нужно Vikings: War of Clans? Почему мы так обеспокоены поддержанием и расширением лора? Ответим так: в этом плане нет разницы между компьютерной, мобильной и даже настольной игрой.

История, которая повествуется как внутри, так и за пределами игры, персонажи и их проблемы, мелочи вроде названий предметов, отсылающих к разным мифам, все это складывается в красивую общую картину в сознании пользователя, помогает сильнее заинтересовать его и погрузить в мир Vikings: War of Clans. А погруженному человеку намного проще получать удовольствие от игры, и для нас, как для разработчиков, это самое важное. Этот эффект не всегда может быть явным, но он безусловно есть, и общий положительный фидбек от наших игроков это подтверждает.

А в какие игры вы погружаетесь с головой и как этому помогает нарратив?

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

И как следствие, писать обработку ошибок - прямая обязанность любого ответственного программиста. Некоторые считают, что если вы не предусмотрели все варианты поведения - вы не программист, и диплом вам не дадут (если речь о студентах).

Но с другой стороны, обрабатывать ошибки всегда лениво и напряжно. Поэтому существует много инструментов для облегчения этой задачи. Стандартный механизм обработки ошибок в Java - Exceptions. Я не буду сейчас расписывать скучные описания, как бы отвечая на скучные вопросы со многих собеседований. Скажу лишь, что Исключение - это на мой взгляд, неправильный перевод понятия Exception. Я считаю, что исключение, то есть исключительная ситуация - это про другого представителя летающих монстров, java.lang.Error.

А Exception - это не исключение, это часть правила. Это всегда один из возможных исходов. Я бы перевёл этот класс не иначе как Отклонение. В смысле отклонение от прямого курса. Потому как перехватив это отклонение, можно курс выправить и продолжить работу. А Исключение - это для безответственных разработчиков.

Так вот. Давайте теперь перехватывать эти отклонения. Как можно это сделать?

В современной разработке существует тенденция наследовать все Exception от непроверяемых исключений. Это позволяет не заботиться о написании кода обработки ошибок. Я считаю этот подход расхлябанным и безответственным. И сам всегда пропагандирую использование явно заданных и объявленных отклонений с жёсткой обязанностью их обработать, т.е. настаиваю на использовании только проверяемых исключений/отклонений в любом бизнес-коде.

Это вносит неудобства, да. Надо их везде ловить. Как упростить задачу? Обычно советуют тупо оборачивать исключение в java.lang.RuntimeException. Но такой подход чреват тяжёлыми последствиями, когда приложение выходит в релиз и на бой. Я как человек, имеющий ещё и плюсовый бэкграунд, прекрасно знаю, что некоторые ситуации невозможно предугадать даже очень внимательно вглядываясь в код. А потом искать их причины днями, неделями, иногда месяцами. Потому что кто-то в самом начале, в месте возникновения ошибки не объявил о возможности их возникновения.

Ну да ладно. Не будем о грустном. Лучше попробует сделать нашу жизнь проще, написав утилитку, которая с одной стороны, позволяет обрабатывать ошибки. А с другой стороны не привносит глобальных неудобств и не захламляет код бесконечными (часто вложенными друг в друга) блоками try-catch-finally.

Что предлагается?

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

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

3. Во-вторых, надо бы упростить синтаксис обработки ошибок. Тут я поймал себя на мысли, что необходимость в этом возникает, так как мэйнстрим постепенно, медленно, но всё-таки верно потихоньку уползает от практик процедурного программирования. А блоки try-catch, по-моему, являются наследием именно этой парадигмы. И ООП , и тем более функциональщина и даже стримы Java-8 как-то плохо сочетаются с этими блоками, фигурными скобками.

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

Здесь я попробовал сразу около трёх подходов реализовать.

Первый - просто статичная обёртка над небезопасным кодом, которая напечатает в лог и в случае чего прокинет ошибку своего местного разлива. Это метод errorToWarn.

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

И затем я решил пойти ещё дальше и сделать описание ошибок в удобном формате, одновременно предлагая ленивую логику и флюент (как по-русски это?) интерфейс. Это вылилось в вызов, который уже возвращает своеобразный билдер, который затем можно настраивать по типу jmock или spring security api. Выглядеть это стало примерно как табличка состояний, примерно вот так:

К слову первый подход вылился во что-то наподобие

Надеюсь мои лирические рассуждения покажутся вам полезными. Возможно вам понравится использованный мной подход и вы захотите развить утилиту советом / личным вкладом.

Привет, Хабр! Хочу вам рассказать о своём исследовательском проекте, в котором я создал игрового ботеца для ВКонтакте.

Ахтунг!

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

Эта статья не является пошаговым руководством по созданию бота для ВКонтакте - их достаточно и на Хабре, и за его пределами.

Что за проект?

Я, как администратор немаленькой беседы во ВКонтакте (на тот момент это было ~670 человек), столкнулся с проблемой ужасной активности. Ну серьёзно, человек много, а не пишет никто, очень много незаинтересованных молчунов, которые лишь цифру создают для беседы. Подавляющее большинство пользователей из тех 670 человек просто входили и не появлялись в списке сообщений ни разу.

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

С ботом и своей темой я отправился прямиком на конкурс "Большие вызовы", съездил в лагерь, где с экспертами (а с одним из них мы общаемся до сих пор) я допиливал презентацию, чутка сменил цель, всё подкорректировал, успешно защитился. Сейчас меня ждёт только последний тур заключительного этапа, но это уже совсем другая история.

Что же за системы есть в боте?

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

У меня бот намного проще, но подошёл для проекта в школе и для проекта в конкурсе. Основными характеристиками пользователя являются игровая валюта и опыт. Фактически, всё сводится к фарму опыта и денег ради фарма опыта и денег. За опыт можно устроиться на работу, каждая последующая работа будет давать всё больше денег в 24 часа (без фарма, получение зарплаты только командой раз в сутки), в свою очередь за деньги можно купить машину получше, которая будет давать больший множитель к опыту. Опыт даётся за каждое сообщение кроме команд посимвольно, затем умножается на множитель от автомобиля. Это самое основное, чего я стал требовать от бота. Также есть выдача предупреждений (максимальное их количество - 4).

Да, такого бота я делал около 6 месяцев, постоянно что-то изменяя, добавляя и удаляя.

Давай о реализации уже!

Делал я бота на языке программирования Python с использованием асинхронной библиотеки для написания ботов vkbottle. Работает на CallBack API, в качестве сервера использую aiohttp.

Во входном файле bot.py происходит инициализация сервера, прописаны все роуты (их всего 4 и они очень маленькие), к основному боту добавляются blueprint'ы, о которых пойдёт речь позже.

import pathlibimport aiohttpimport aiohttp_jinja2import jinja2from aiohttp import webimport utils.constsfrom config import SECRET, WEBHOOK_ACCEPT, CONFIRMATION_TOKENfrom routes import actions, admin_realize, global_admin_realize, users_realize, economic_realizefrom utils.db_methods import init_databasefrom middlewares import ExpMiddleware # dead import for include middlewareINDEX_DIR = str(pathlib.Path(__file__).resolve().parent) + '/index_page'utils.consts.BOT.loop.run_until_complete(init_database())utils.consts.BOT.set_blueprints(    actions.bp, admin_realize.bp, global_admin_realize.bp,    users_realize.bp, economic_realize.bp)APP = aiohttp.web.Application()ROUTES = aiohttp.web.RouteTableDef()if not WEBHOOK_ACCEPT:    aiohttp_jinja2.setup(APP, loader=jinja2.FileSystemLoader(str(INDEX_DIR)))    APP.router.add_static('/static/',                          path=str('./index_page/'),                          name='static')@ROUTES.get("/")@aiohttp_jinja2.template('index.html')async def hello(request):    """Root site response"""    return {}@ROUTES.get("/when_update")@aiohttp_jinja2.template('whenupdate.html')async def whenupdate(request):    """When update site response"""    return {}

Все конфиги хранятся в config.py, точнее, там инициализируются константы. Сами значения хранятся в файле .env и с помощью библиотеки dotenv берутся из виртуального окружения по ключу.

import osfrom dotenv import load_dotenvdotenv_path = os.path.join(os.path.dirname(__file__), '.env')if os.path.exists(dotenv_path):    load_dotenv(dotenv_path)# Loading token from .envACCESS_TOKEN = os.getenv("ACCESS_TOKEN")SECRET = os.getenv("SECRET")USER_ACCESS_TOKEN = os.getenv("USER_ACCESS_TOKEN")WEBHOOK_ACCEPT = bool(int(os.getenv("WEBHOOK_ACCEPT", 0)))CONFIRMATION_TOKEN = os.getenv("CONFIRMATION_TOKEN")NEW_START = bool(int(os.getenv("NEW_START", 0)))ADMINS_IN_CONV = list(map(int, os.getenv("ADMINS_IN_CONV").split(',')))

Теперь о том, где хранятся все обработчики команд.

Я их разделил логически на 5 видов: обработчик событий (пользователь вошел в беседу), обработчик сообщений для всех (например, команда /profile), для администраторов беседы (например, /пред чтобы выдать предупреждение пользователю), для администраторов и модераторов бота (например, /бд добавить, чтобы добавить, как ни странно, новый экземпляр какой-то модельки, например, создать новую машину, не взаимодействуя напрямую с БД), и реализация системы экономики (купить или продать машину, поступить на работу и пр.).

Всё это хранится в пяти разных файлах в папке routes:

Вот пример команды покупки машины:

@bp.on.message_handler(AccessForAllRule(), Registered(), text="/купить_машину <c_id>")async def buy_car(message: Message, user: User, c_id: str = None):    if c_id.isdigit():        c_id = int(c_id)        car = await Car.get(id=c_id)        buy_car_user_status = status_on_buy_car(user, car)        if buy_car_user_status == BuyCarUserStatuses.APPROVED:            chat = await Conversation.get(peer_id=message.peer_id)            await User.get(user_id=message.from_id, chat=chat).update(                coins=user.coins - car.cost, car=car            )            await message(f"Машина {car} куплена!")        elif buy_car_user_status == BuyCarUserStatuses.NOT_ENOUGH_MONEY:            await message("У тебя недостаточно денег!")        elif buy_car_user_status == BuyCarUserStatuses.NOT_ENOUGH_EXP:            await message("У тебя недостаточно опыта!")        else:            await message("У тебя уже есть машина!")    else:        await message("Введите цифру-ID машины!")

Все обработчики в пределах одного файла объединяются blueprint'ом, а все "чертежи" подключаются к боту во входном файле.

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

Все подобные функции хранятся в отдельно в папке utils в файле main.py. В этой же папке лежат файлы с константами, функциями для работы с БД, правила и ошибки, которые функции могут raise'ить иногда.

def status_on_buy_car(user: User, car: Car) -> BuyCarUserStatuses:    if user.coins >= car.cost and user.exp >= car.exp_need and user.car is None:        return BuyCarUserStatuses.APPROVED    elif user.coins < car.cost:        return BuyCarUserStatuses.NOT_ENOUGH_MONEY    elif user.exp < car.exp_need:        return BuyCarUserStatuses.NOT_ENOUGH_EXP    else:        return BuyCarUserStatuses.NOW_HAVE_CAR

В качестве ОРМки я использую Tortoise ORM, потому что асинхронно (а смысл в асинхронности фреймворка, если вся работа с БД синхронная?), потому что удобно лично для меня.

Что по итогу?

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

Конечно, в беседе, где бот был, наблюдалось больше сообщений, чем в беседе, где его не было, было больше активности (пусть и не сильно). Это я и записал в вывод.

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

Постскриптум

Я открыт к критике в комментариях, за неё отдельное спасибо, ведь именно критика, может даже очень жёсткая, может даже с заминусованной статьёй поможет развиваться мне как разработчику и создателю статей на Хабре.

Бот на GitHub

В основе многих наших действий или бездействий лежат неразрешенные конфликты.

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

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

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

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

Многие практики Теории Ограничений утверждают, что Грозовая туча работает.

Давайте проверим и попробуем применить разработанный Голдратом алгоритм к нескольким типичным конфликтам из области ИТ. Посмотрим, как это может нам помочь.

Конфликт: Подрядчик не начинает разработку до тех пор, пока не составит полное ТЗ

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

Ровно такое же опасение возникает и у аккаунтов-менеджеров при миллионных заказах. Фрилансер может и потерпит какое-то количество времени без денег, а вот компании-подрядчику придется все это время платить зарплату сотрудникам из своих средств, что иногда может быть очень разорительным.

Часто подрядчики делают ТЗ для того, чтобы не вкладывать в разработку кратное количество ресурсов, N раз переписывая код. Т.е. у подрядчиков зачастую есть уверенность в том, что им заплатят деньги, но при этом есть и четкое понимание, что полученные средства окупят лишь маленькую долю от фактических затрат в отсутствие ТЗ.

Как быть? Ведь заказчик хочет начать работу прямо сейчас и готов бросить всё, если Вы не начнете, и уйти к другому исполнителю. Конечно, ему нет никакого смысла ждать пока подрядчик напишет ТЗ (если вообще напишет). Это потеря его времени и, на самом деле, упущенной выгоды.

Какое же решение принять подрядчику?

Уже сейчас, из самой формулировки конфликта очевидно, что действие Начать работу только после составления ТЗ вызвано отсутствием гарантии получения денег от заказчика.

Т.е. причиной действия Начать работу только после составления ТЗ является необходимость Обеспечить гарантию получения денег.

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

Очевидно, что он не хочет затягивать создание своего продукта. Он хочет получить его как можно быстрее и считает, что составление ТЗ только всё затянет.

Т.е. причиной действия Начать работу прямо сейчас, без ТЗ является необходимость Быстрее создать продукт.

Но при это оба, и заказчик и подрядчик хотят создать это продукт. Т.е. у них общая цель Создать продукт

Каждому пункту конфликта принято давать буквенное название: A, B, C, D, D.

Итак, конфликт полностью сформулирован. Это так называемая диаграмма Грозовая туча.

Проведём быструю проверку. Условие C должно конфликтовать с действием D, а условие B должно конфликтовать с действием D. Всё верно, они конфликтуют, значит формулировка конфликта составлена правильно.

Для того, чтобы разогнать эту грозовую тучу необходимо разобраться в причинах конфликта. Пропишем причины (предпосылки), почему действия D и D необходимы для обеспечения условий B и C.

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

Было: Быстрее создать продукт. Обратная формулировка: Старт разработки бесконечно затягивается.

Было: Обеспечить гарантию получения денег. Обратная: Деньги за сделанную работу не оплачивают

B-D (при каких условиях старт разработки бесконечно затягивается?):

- Составление ТЗ занимает много времени

- Согласование ТЗ занимает еще больше времени в разы больше. Это огромные простои

- Есть понимание, что конечный продукт не будет в итоге таким как в ТЗ, его всё равно придется менять, т.к. люди не провидцы и не предсказатели

- ТЗ часто используют в качестве давления на заказчика и есть риск не получить продукт, который я хочу

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

C-D (причины, почему деньги за сделанную работу не выплачиваются):

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

- Подрядчик вынужден выплачивать зарплату разработчикам из своих средств, чтобы они доделывали продукт. Это выводит проект в минус.

- Обычно разработка сильно затягивается из-за все новых и новых требований заказчика. Он никак не может остановиться

- Объем работ должен быть ограничен, чтобы заказ окупился

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

Э.Голдрат говорит, что суть конфликта скрывается в деталях. Его причиной может быть либо неправильная (ложная) предпосылка, либо непонимание предпосылок, на которых основывает своё видение противоположная сторона.

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

Давайте подумаем За предпосылки сомневаться не приходится это то, что в действительности часто происходит в реальности. Значит надо придумывать что-то иное.

Очевидно, что подрядчик прав в том, что объем работ должен быть ограничен, чтобы заказ окупился. Заказ ведь заключается на фиксированную сумму, в которую включен ограниченный объем работ.

Каким образом можно совместить ограниченный объем работ и быстрый старт разработки? Очевидно, что чем меньше объем работы, тем точнее его предсказать и тем быстрее начать и проще сделать.

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

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

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

Давайте посмотрим, что случится с предпосылками конфликта, если применить найденное решение.

Опасение заказчика

- Составление ТЗ занимает много времени

На короткую итерацию ТЗ составить быстро, а то и вовсе можно обойтись без него заменив макетами экранов.

- Согласование ТЗ занимает еще больше времени в разы больше. Это огромные простои

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

- Есть понимание, что конечный продукт в итоге будет не таким как в ТЗ, его всё равно придется менять, т.к. люди не провидцы и не предсказатели

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

- ТЗ часто используют в качестве давления на заказчика и есть риск не получить продукт, который я хочу

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

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

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

Бонус для заказчика теперь можно смело нанимать разработчиков давая им небольшой объем работ для проверки и рискуя только небольшой суммой.

Опасения подрядчика

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

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

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

При оплате за небольшие итерации деньги будут на счете подрядчика не дожидаясь полного завершения проекта. Это в разы выгоднее.

- Обычно разработка сильно затягивается из-за все новых и новых требований заказчика. Он никак не может остановиться

Новые требования заказчика становятся даже выгодными. Подрядчику выгодно, чтобы они появлялись.

- Объем работ должен быть ограничен, чтобы заказ окупился

Он однозначно ограничен.

Да! Решение полностью исключает все опасения! Грозовая туча работает!

Внесём дополнительные осложнения для подрядчика

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

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

Как закрыть опасения? Как сделать так, чтобы оплата осуществлялась по небольшим итерациям в проекте, котором УЖЕ чётко прописано, что оплата только в конце?

Давайте составим грозовую тучу и посмотрим на неё внимательно.

Причиной возникновения конфликта часто становятся неверные (ложные) предпосылки. Для их определения Голдрат в своих выступлениях (можно найти на Youtube) рекомендует задавать предельно простой вопрос: Really?! (Да ну?!)

Действительно ли внутреннему аудиту большой компании нужно показывать работающий продукт? Точно?! Вы действительно уверены, что нужно доводить готовый продукт до приёмо-сдаточных испытаний? Вы уверены?!

По умолчанию да, но что, если пойти и объяснить сотрудникам внутреннего аудита чем хорош подход с короткими итерациями?

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

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

Конечно, есть шанс, что ничего не случится, но тогда ситуация не будет отличаться от текущей и подрядчик ничего не теряет. Ну а что, если внутренний аудит пойдет навстречу?..

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

Переход разработки на короткие итерации действительно помогает. Помогает и заказчикам и подрядчикам. К сожалению, далеко не всегда им пользуются. И даже там, где уже вовсю работает Scrum (разработка короткими итерациями) внутри компании, для работы с внешними подрядчиками часто применяют стандартные контракты водопадной разработки.

Но это отдельная история.

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

Вероятно, изложенный в статье способ применения диаграммы Грозовая туча покажется Вам полезным. Было бы очень интересно увидеть Ваши примеры её использования.

На Ваши комментарии автор с удовольствием ответит и примет к сведению Ваши замечания.

P.S. История, рассказанная одним из рецензентов после прочтения статьи.

Просишь пример? Пожалуйста.

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

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

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

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

Такой вариант заказчика устроил, т.к. он мог контролировать объем и нужность работ, а также видеть справедливость траты его денег. В таком режиме он продолжает работать уже несколько лет

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

Метрики

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

Наша самая главная метрика Lead Time: это характерное время, за которое задача доходит от одной из четырех контрольных точек (появление идеи, ТПР, Х и ТПО) до установки на продуктив.

Как видим, они образуют иерархию вложенности. Мы используем величины Lead Time, выраженные в рабочих, а не календарных днях. Если над одним продуктом работает больше одной команды, то TTM, Customer Lead Time и Х Lead Time относятся к продукту в целом, а Lead Time для потока у каждой команды может быть свой.

Устоявшейся терминологии для разных Lead Time пока нет, поэтому аналогичные по смыслу показатели у других авторов можно встретить под другими названиями, например, для потокового Lead Time (тот, который самый короткий) часто используется термин Cycle Time. Здесь буду придерживаться нашего варианта жаргона, извините, если что.

Также часто используются метрики потока количество задач, входящих и выходящих из области за период времени, и количество задач, находящихся в области на определенный момент. Эти показатели можно видеть на CFD-диаграмме или на диаграмме потока задач (которая, на наш взгляд, легче читается).Например, для области Поток диаграмма потока задач с шагом в неделю выглядит так:

Еще эту диаграмму называют Бассейн, так как она построена по принципу втекает-вытекает-оставшийся уровень. Inflow поток задач, которые взяты в поток за неделю, Done количество успешно выполненных задач, Discarded количество отбракованных из потока задач, Unfinished количество задач, оставшихся в потоке на конец недели (другое название - WiP Work in Progress).

Прогнозирование с использованием показателей Lead Time разных уровней

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

Если заглядывать сюда регулярно, то сможем отследить и их перемещение между областями.

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

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

Чтобы понять, сколько времени обычно нужно, чтобы провести задачу через поток, рассмотрим спектральную диаграмму Lead Time для потока этой команды за последние три месяца:

Для удобства рассчитываются и дополнительно выводятся на графике значения 50-го и 85-го перцентилей это количество рабочих дней, которое у команды занимает решение одной задачи для 50% и 85% всех задач соответственно. В данном случае это 2 и 4 дня. Значит, только для 15% задач Lead Time составляет больше 4-х рабочих дней. Вспомнив про типизацию задач, посмотрим на спектральные диаграммы разных типов задач по отдельности (слева направо - Дефект, Эксплуатация, Технические и Бизнес), и увидим, что для бизнес-задач 85 перцентиль составляет не четыре, а шесть рабочих дней:

Таким образом, мы получаем достаточно обоснованный прогноз, что с вероятностью немного менее 85% эта задача и, как следствие, весь эпик будут выполнены за шесть рабочих дней. Меньше 85% получается из-за того, что есть небольшая вероятность, что какая-то из двух задач в потоке застрянет там больше, чем на шесть дней.

Теперь посмотрим, как можно мониторить движение эпика на всем жизненном цикле, от идеи до реализации при помощи статистики Lead Time разных уровней:

Представим себе руководителя проекта (РП), у которого есть план, содержащий несколько задач для разных команд, которые нужно выполнить к определенным датам. РП не agile-роль, он может использовать дедлайны, более того, он не может их не использовать :). Вопрос в том, как он добьется выполнения этих сроков продуктовыми командами, которые не горят желанием брать на себя обязательства по достижению дедлайна.

Рассмотрим одну из таких задач. Плановую дату ее исполнения обозначим как день Д. Построим LeadTime-профиль продукта/команды, которая будет ее выполнять, в виде таблицы:

Дни рабочие, неделя соответствует 5 рабочим дням. 85% вероятность выполнения РП считает приемлемой.

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

1. РП приходит с новой задачей к Product Owner (PO) и договаривается о помещении ее в продуктовый бэклог с таким приоритетом, чтобы она, по предварительной экспертной оценке PO, была выполнена до дня Д. PO создает соответствующий эпик. РП ставит себе календарное напоминание на Д - 8 недель - это зеленая дата попадания эпика в следующую область Решили делать, и уходит заниматься другими делами.

2. При срабатывании напоминалки РП проверяет, что его эпик пересек ТПР. В этом случае он ничего не предпринимает и ставит себе следующую напоминалку на Д - 14 дней (дата перемещения в Готово к взятию в поток в зеленой зоне).

3. После очередной напоминалки РП видит, что эпик по-прежнему лежит в области Решили делать, не пересек точку Х и не декомпозирован на задачи. В этом случае он включает режим экспедирования: идет к Product Ownerу и договаривается о том, чтобы эпику подняли приоритет. Затем он ежедневно отслеживает ситуацию, пока эпик не оказывается в области Готово к взятию, декомпозированный на задачи. Предположим, что это случилось в дату Д - 8 дней.

4. Далее имеет смысл отслеживать задачи, входящие в эпик, по отдельности. Предположим, что их три, в области Готово к взятию они расположены на втором, пятом и шестом месте по приоритетам (см. рисунок ниже). Мы уже знаем, что если задача находится на самом верху области Готово к взятию, то с вероятностью 85% она будет выполнена не позже, чем через 6 дней. Остается понять, сколько нужно времени, чтобы все три задачи эпика попали в поток. Посмотрев на потоковую диаграмму, мы увидим, что команда берет в поток в среднем 15 задач в неделю, то есть примерно по три задачи в рабочий день. Шесть задач будут взяты в работу, скорее всего, не позднее, чем за два дня. Поскольку день Д близко, РП стоит проследить, чтобы в бэклог поверх его задач не были помещены дополнительные задачи. Не стоит забывать, что команда принимает обязательства выполнить задачу только в момент ее взятия в поток, а до этого возможны изменения приоритетов.

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

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

Важно: при движении эпика по жизненному циклу все виды Lead Time нужно измерять для той части эпика, которая дошла до продуктива.

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

Нужно ли автоматизировать прогнозирование сроков исполнения задач?

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

Можно ли спрогнозировать движение конкретной задачи от идеи к реализации, с учетом количества и характеристик задач, которые находятся выше нее по приоритетам и/или правее по ЖЦ? Получится ли в результате более точный прогноз, нежели мы можем получить из LeadTime-профиля продукта? Ведь пробабилистический прогноз с помощью LeadTime-профиля учитывает только в какой области находится задача , но не учитывает, сколько и каких задач команде предстоит сделать, прежде чем она приступит к интересующей нас задаче. Примерно как РП из предыдущей главы оценивал время, когда задачи 2, 5 и 6 будут взяты в поток, только автоматически, с учетом характеристик задач, подробных исторических данных.

Мы с командой портала метрик (особенная благодарность Диме Новикову!) попробовали сделать такой автоматический прогноз для задач в области Готово к взятию. Идея была в следующем: для каждой задачи, которая сейчас находится в бэклоге, рассмотрим количество и типы задач, расположенных в бэклоге выше нее. В исторических данных по работе этой команды ищем похожие ситуации когда выше некоторой задачи в бэклоге находился примерно такой же набор задач по количеству и типам. Смотрим, сколько времени у команды занимало выполнение такого набора задач в прошлом, получаем вероятностное распределение, из которого можно с разной степенью вероятности сделать прогноз дат, когда интересующая нас задача попадет на продуктив,

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

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

"Самосбывающийся прогноз"

Автоматизированное прогнозирование обычно применяют для тех событий, на которые потребитель прогноза повлиять не может погода, покупательский спрос, движение автобуса в пробках, etc А на движение продуктовых задач потребители прогноза (команда и заказчики) имеют большое влияние. Если прогноз не устраивает заказчика и/или команду, то есть как минимум три инструмента для исправления ситуации:

1. Договориться об изменении приоритета задачи.

2. Сократить скоуп и требования, реализовать сначала ту часть, которая дает наибольший эффект при меньших затратах.

3. Реализовать сначала менее трудоемкое, временное решение с образованием.

Достижение необходимого срока возможно без штурмовщины, если:

1. Изначальные сроки реалистичны - находятся в зеленой зоне LeadTime-профиля команды.

2. Задача действительно нужна, кто-то ждет ее выполнения и прилагает периодические усилия для поддержания ее приоритета.

3. Продуктовая команда работает в штатном режиме: осуществляет регулярное управление техническим долгом; большая часть задач команды не имеет жестких дедлайнов и их можно подвинуть в случае необходимости; команда не работает со 100% напряжением, у нее есть резерв для маневра.

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

Изменение зон ответственности при работе со сроками

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

В проектной парадигме базовый алгоритм работы со сроками следующий.

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

Когда я высказал эту мысль своим коллегам, мне тут же возразили, что так не бывает. Роль руководителя проекта придумана как раз из-за того, что эта "пуля" сама по себе в цель не попадает почти никогда. Ее надо постоянно подруливать в полете, и кто-то должен этим заниматься. Но изначальный смысл именно в этом - после согласования плана ответственность за срок переносится на исполнителя, чтобы освободить заказчика для более важных дел.

В продуктовой парадигме:

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

Таким образом в продуктовой парадигме ответственность за достижение сроков в большей степени ложится на сторону заказчика. Рабочая гипотеза состоит в том, что в обмен повышается общая эффективность приложения усилий заказчиком: выше вероятность получить то, что нужно, к нужному сроку, меньше неактуальных задач, сделанных потому, что их забыли отменить. Проверкой этой гипотезы мы сейчас и занимаемся в SM Lab :).

Что может сделать команда для повышения своей прогнозируемости.

Для того чтобы работа команды была прогнозируемой, нужно чтобы у показателей Lead Time разброс (дисперсия распределения) был поменьше. Даже при небольшом разбросе не нужно забывать, что это вероятностный, а не детерминистический прогноз, отклонения всегда возможны, и ни одна команда не может быть на 100% предсказуемой. Но если распределение имеет большую дисперсию, то этот показатель полностью теряет предсказательную силу.

Вернемся к таблице LeadTime-профиля. По различию в 50-м и 85-м перцентилях легко понять, насколько силен разброс значений соответствующего Lead Time. Понятно, что по мере движения по жизненному циклу слева направо проработанность задач увеличивается, а степень неопределенности уменьшается. В нашем примере для Lead Time потока 85-й перцентиль больше 50-го в полтора раза (6 и 4 рабочих дня), а для Customer Lead Time - уже более чем в три раза (8 недель = 40 р.д. и 12 р.д.).

Для внешних интересантов интереснее всего предсказуемость задач как раз в левой части жизненного цикла, в областях идеи и решили делать. От этих прогнозов зависят решения, которые принимаются при формировании дорожных карт и бизнес-планов. Будет ли готова новая функциональность к началу новой коллекции, или надо сразу отложить ее внедрение на полгода, до следующей коллекции? На какой период планировать дополнительные ресурсы, связанные с этим? И множество других важных вопросов. В идеале, заказчик хочет знать, когда будет готово, сразу же, как только он высказал новую идею в наших терминах это значит, что дисперсия распределения Time to Market должна быть как можно меньше. К сожалению, обеспечить такую предсказуемость в области идей для команды очень сложно, так как эта область в наименьшей степени подвержена ее влиянию. Если каждую идею прорабатывать сразу до такой степени, чтобы по ней можно было дать обоснованный срок реализации, у команды не останется времени на полезную работу все уйдет на детальную проработку идей, которые никогда не будут реализованы.

Поэтому усилия по улучшению предсказуемости предлагается прилагать, начиная с области Решили делать, куда задачи (они же - эпики) переносятся через Точку Принятия Решения с участием представителей команды. Поэтому на разброс Customer Lead Time повлиять уже возможно, и для этого подходит то же средство, которые команды привыкли использовать для стабилизации работы своего потока - ограничение количества задач, находящихся в работе. На область Решили делать можно установить WiP-лимиты, так же, как это делается большинством продуктовых команд для этапов работы в потоке и для области Готово к взятию в поток.

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

Такой подход позволяет постоянно и предсказуемо работать с новыми идеями, не превращая область в свалку идей.

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

Выводы

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

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

Для контроля сроков применяются методы визуализации и прогнозирования. Управление осуществляется через динамическое изменение скоупа и приоритетов.

Условием применимости такого подхода является "антихрупкость" системы в целом, которая обеспечивается регулярным и превентивным применением технических и организационных практик, обязательных для продуктовых команд.

Это все. Спасибо, что дочитали! :)

По Agile доступно огромное количество курсов. Кроме специализированных курсов по проектному управлению есть ещё сертификации.

Зачем получать сертификаты по проектному управлению? Существуют несколько причин:

• Систематизировать ранее полученные знания.

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

• Проверить свои силы. Сертификация даст ответ насколько ты хорош.

• Переход на новую должность или роль. Вы хотите получить знания, необходимые для выполнения новых обязанностей.

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

Сертификаты можно разделить на три типа:

Перед подготовкой к сертификации вам нужно ответить для себя на несколько вопросов:

1. Для чего вам нужен сертификат?

2. Какую методологию/фреймворк вы используете или хотите использовать?

3. Какая у вас текущая или желаемая роль в компании?

ICAgile

ICAgile. После прохождения обучения вы можете получить международный сертификат. Тренинги от ICAgile достаточно известны и популярны. Получить сертификат достаточно просто: прослушал курс получи сертификат.

Agile DeliveryBusiness Agility

Agile Delivery и Business Agility.

Обучение проходит по 8 трекам плюс 1 бизнесовый блок.

В каждом треке есть 2 уровня. Прошёл обучение по каждому уровню получаешь статус по всему треку.

Обучение на каждом уровне длится в течение 3-х дней, много практики.

Сертификат

Сертификат пришлют в течение 4 недель после курса. Сертификат выдаётся бессрочно, продлевать не нужно.

Проверить сертификат на действительность можно по ссылке.

Стоимость обучения варьируется в зависимости от трека от 35 до 90 тысяч рублей. Стоимость курса включает выдачу сертификата. Ничего доплачивать не нужно.

Из плюсов:

• Международный сертификат.

• Разнообразие, можно прослушать курсы по нескольким направлениям: Agile, DevOps, опер блок.

• Сертификат выдаётся бессрочно.

Из минусов:

• Отсутствует экзамен. Человек, который старался, слушал курс, и человек, который просто присутствовал, равны.

PMI

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

Треков нет.

Сертификат

Это одна из немногих сертификаций, до которой ещё необходимо допуститься.

Для получения доступа к экзамену потребуется:

• Не менее 12 месяцев опыта управления проектами за последние 5 лет;

• Не менее 8 месяцев управления Agile проектами за последние 3 года;

• 21 час обучения на любом курсе Agile (не обязательно аккредитованом).

Описание требований для доступа к экзамену. Курсов по подготовке к экзамену не так много.

Нужно быть готовым подтвердить информацию в анкете. Ваша заявка может попасть под аудит.

Сам экзамен состоит из 120 вопросов, большая часть вопросов ситуационные, основаны на практических кейсах. На экзамен отводится 3 часа. Критерий успешной сдачи не раскрывается, но, по слухам, составляет примерно 70 правильных ответов. Русский язык на экзамене пока ещё недоступен придётся сдавать на английском.

Проверить сертификат на действительность можно по ссылке.

Сертификат необходимо продлевать каждые 3 года. Для этого достаточно пройти 30 часов обучения на сертифицированных курсах. Подробная информация по ссылке.

Стоимость аккредитованных курсов от 1 до 200 тысяч рублей. Зависит от количества часов, страны и жадности провайдера курсов.

Из плюсов:

• Одна из самых именитых компаний.

• Необходимо сдать экзамен.

Из минусов:

• Одна из самых сложных сертификаций.

• Необходимо допуститься до экзамена.

• Высокая стоимость экзамена (495 USD).

• Экзамен доступен только на английском языке.

• Нужно продлевать сертификат.

IAPM

IAPM. Малоизвестный провайдер IAMP. Сертификация основана на стандарте AgilePM Guide 2.0. Стандарт включает инструменты и техники из нескольких фреймворков: Agile, Scrum, Kanban и других.

Ссылка на сам стандарт.

IAPM certifications

К сертификации доступно 4 уровня: Certified Junior Agile Project Manager, Certified Agile Project Manager, Certified Senior Agile Project Manager, и Certified International Project Manager.

Сертификат

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

Проверить сертификат на действительность можно только отправив запрос на почту support@iapm.net.

Экзамен состоит из 120 вопросов, на которые будет отведено 80 минут. Для успешной сдачи необходимо правильно ответить на 78 вопросов. Более подробно по ссылке.

Стоимость сдачи экзамена зависит от страны пребывания сдающего, составляет примерно 650USD. Сдать экзамен может любой желающий отсутствуют обязательные требования для допуска к экзамену.

Из плюсов:

• Международный сертификат.

• Необходимо сдать экзамен.

• Не нужно продлевать сертификат.

Из минусов:

• Малоизвестный провайдер в РФ.

• Экзамен доступен только на английском языке.

Scrum Alliance

Scrum Alliance. Компания была основана в 2002 году авторами The Scrum guide Джеффом Сазерлендом и Кеном Швабером. Сертификат от Scrum Alliance один из двух самых известных в мире сертифицирующих организаций по Scrum. О второй позже.

Certification Types & Tracks.

В Scrum Alliance есть три трека для сертификации по ролям: Scrum master, Product owner, Developer. У всех трёх ролей есть три ступени Certified, Advanced и Professional.

Также Scrum Alliance предлагает еще 4 дополнительных трека Agile Leadership, Team Coach, Enterprise Coach и Trainer.

Сертификат

Чтобы допуститься к экзамену, необходимо обязательно пройти аккредитованные курсы.

Курс длится 2 дня. После прохождения обучения у вас будет несколько попыток сдать экзамен на официальном сайте Scrum Alliance.

Проверить сертификат на действительность можно по ссылке.

Экзамен состоит из 50 вопросов, на решение которых будет отведён 1 час. Критерий прохождения - 37 правильных ответов.

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

Стоимость обучения составляет порядка 65 тысяч рублей за 1 ступень, включая взнос за экзамен и 2 попытки, далее $25 за каждую попытку.

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

Сертификацию нужно продлевать каждые 2 года. Для продления необходимо набрать достаточное количество баллов SEUs на аккредитованных курсах плюс заплатить взнос. К примеру, для продления самой популярной сертификации Product owner и Scrum Master потребуется 30 часов курсов и оплата взноса в размере 175 долларов.

Подробная информация о продлении по ссылке.

Из плюсов:

• Всемирно известная компания.

• Необходимо сдать экзамен.

Из минусов:

• Экзамен доступен только на английском языке.

• Нужно продлевать сертификат.

Scrum.org

Scrum.org. Вторая всемирноизвестная сертификация по Scrum. Компания Scrum.org была основана в 2009 году Кеном Швабером.

Professional SCRUM certifications

Для сертификации доступно8 треков, 3 из которых организованны по ролям: Scrum Master, Product Owner и Developer. Остальные пять Scaled Professional Scrum, Professional Scrum with Kanban, Professional Agile Leadership, Professional Agile Leadership-EBM, Professional Scrum with User experience.

Сертификат

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

Проверить сертификат можно по ссылке.

Количество вопросов и стоимость сертификации отличается от трека к треку.

На примере сертификации Scrum Master.

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

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

Стоимость обучения составляет порядка 50-80 тысяч рублей за 1 ступень, включая взнос за экзамен и 2 попытки.

На сайте scrum.org доступно бесплатное тестирование, которое может пройти любой желающий. Сертификата не дадут, но можно понять уровень подготовки.

Из плюсов:

• Всемирно известная компания.

• Необходимо сдать экзамен.

• Сертификат не нужно продлевать.

Из минусов:

• Экзамен доступен только на английском языке.

Kanban University

Kanban University. Сертификация проходит аналогично ICAgile, прослушал курс получи сертификат. Для сертификации доступно 5 треков.

Certified kanban.

Team Kanban Practitioner это однодневный курс для тех, кто хочет познакомиться с Kanban.

Чтобы получить Kanban Management Professionalнеобходимо пройти обе ступени KMP1 и KMP2.

Треки Management, Coaching, Consultant и Trainer подойдут для тех, кто планирует стать тренером или коучем по Kanban.

Сертификат

Проверить сертификат можно по ссылке.

Обучение проходит в течении 1-2 дней, зависит от трека. Стоимость составляет порядка 25-50 тысяч рублей за одну ступень.

Из плюсов:

• Международный сертификат.

• Сертификат выдаётся бессрочно.

Из минусов:

• Отсутствует экзамен.

Перечень провайдеров

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

Кроме наличия необходимых знаний международный сертификат показывает работодателю что:

• Ты целеустремлён и знаешь чего хочешь, т.к. потратил время на подготовку и получение сертификации.

• Ты стремишься развиваться и получать новые знания.

• Ты знаешь теорию достаточно, чтобы пройти все испытания.

Если есть опыт в получении сертификаций и желание поделиться им, напишите, пожалуйста, в ЛС.

А если я упустил какую-либо информацию, напиши в комментарии. Я обязательно её добавлю.

Известная всем простая истина гласит, что менеджер проекта всецело отвечает за достижение целей проекта (об этом говорит и PMBoK, и стандарты ISO). При этом в зависимости от масштаба и бюджета проекта различные группы навыков руководителей проектов выходят на разные уровни: маленький проект чаще всего предполагает сильные технические скиллы, крупные проекты лидерские и стратегические навыки взаимодействия со стейкхолдерами и заинтересованными лицами.

На основе личного опыта и проектных фреймворков выполнить проект успешно (сроки, качество, бюджет, удовлетворенность заказчика) можно только при постоянном проактивном управлении проектом, в рамках которого почти 80% времени должно уделяться прогнозированию. При этом любое планирование и прогнозирование необходимо производить методом набегающей волны, а успешным прогнозированием можно заниматься только при выстроенных и устоявшихся процессах. В противном случае менеджер проекта вместо прогнозов и планов в конечном итоге будет заниматься налаживанием процессов управления команды и создания продукта(ов) проекта. Процентное соотношение времени, затрачиваемое на управленческие процессы, очень хорошо отражает зрелость проектного менеджмента в команде/компании и в целом самого менеджера.

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

В странах со зрелым управленческим менеджментом давно применяются процессы управления по исключениям. Самое явное определение таким процессам дает стандарт PRINCE2: Руководство проектами следует осуществлять путем определения обязанностей и ответственности на каждом уровне проекта при помощи строгого делегирования полномочий. Допустимые отклонения должны быть определены для каждого уровня плана проекта.

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

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

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

Эскалация вопросов и проблем в проекте (ресурсных, межличностных, административных) не будет вызывать нездоровый негатив, если всегда пользоваться принципами честности и открытости. Шаги, которыми пользуюсь я в своей практике (и они правда приносят успех):

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

2. Открыто оповестите противоположную сторону о необходимости/потребности в эскалации, тем самым вы избавитесь от подковёрных игр и наращивания негатива в проекте после эскалации.

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

4. Эскалируйте на вышестоящие уровни, это страшно только в первый раз. В рамках договорных отношений Заказчик Исполнитель эскалацию на уровни выше лучше переносить в разряд официальных писем (для юридической подстраховки от плохих людей и штрафных санкций).

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

Предостережение

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

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

Введение

Меня зовут Глеб (8 кл) и я задался целью сделать хорошую открывалку/закрывалку и немного говорилку для windows, вообщем голосового ассистента на python.

На момент написания поста ассистент имеет версию alfa 4.0 и непозицианирует себя как серьезный продукт или не дай бог конкурента Алисе или Siri.

Для ассистента был по-быстрому накидан сайт, где можно скачать exe или исходник на питоне, который вероятно вам и интересен. Гитхаб тоже в наличии.

КОД

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

РАСПОЗНОВАНИЕ РЕЧИ

Для работы разпозновалки я выбрал speech recognition и в итоге был реализован такой код(сборная солянка из видеоуроков):

import speech_recognition as sr#кортеж с предлжениями, каждую итерацию цикла ассистент дает рандомное предложение (Скажите что-нибудь например "открой браузер")recomend = ("Открой браузер", "Найди в интернете стихи А. Пушкина.", "Как дела?", "Что ты умеешь?", "Запомни код от домофона 495 544.", "Найди на ютубе котиков.")#распознование (и не просите, в функцию не добавлю так, как оно все-равно нужно только раз за итерацию цикла)    rec1 = len(recomend) - 1    rec2 = recomend[random.randint(0, rec1)]    print('-------------------')    r = sr.Recognizer()    with sr.Microphone() as source:    print("Скажите что нибудь, например:", rec2)    r.pause_threshold = 1    #r.adjust_for_ambient_noise(source, duration=1)    audio = r.listen(source)    try:    #разпознаное сохраняется в переменную an (answer)      an = r.recognize_google(audio, language="ru-RU").lower()    print("Вы сказали: " + an)    except sr.UnknownValueError:        t = "Я вас не слышу, говорите громче!"        print("Сбой системы распознования речи. ")

Очень прошу в комментарии покидать более качественные аналоги speech recognition.

СИНТЕЗ РЕЧИ

Для синтеза речи я выбрал голос vokolizer, а также библиотеку pyttsx3. В коде это выглядит так:

import pyttsx3#Настройка голоса, индекс голоса читаем из файла.f = open("tts.txt", "r")tts1 = int(f.read(1))f.close()text = ""tts = pyttsx3.init()speak_engine = pyttsx3.init()voices = speak_engine.getProperty('voices')speak_engine.setProperty('voice', voices[tts1].id)#функция синтезы речиdef run():    tts.say(t)    tts.runAndWait()    print("Виталий:", t)    #пример запросаt = "Привет мир"run()

ПОДБОР ФРАЗ ДЛЯ КРАСИВОГО SMALLTALK

Тут я решил сделать возможность быстрого изменения фраз, поэтому сделал такой алгоритм:

import os#читаем файл smalltalk и делаем 2 списка: 1 - с ключевыми словами, 2 - с ответами ассистентаf = open("smalltalk.txt", "r", encoding="utf-8")smalltalkdialog = f.read()asksmalltalk = smalltalkdialog[len("вопросы: "):smalltalkdialog.find(" | [конецстроки1]")].split(" | ")answersmalltalk = smalltalkdialog[smalltalkdialog.find("ответы: ") + len("ответы: "):smalltalkdialog.find(" | [конецстроки2]")].split(" | ")#подбор нужной фразыfor word in range(len(asksmalltalk)):    if asksmalltalk[word] in an:        t = answersmalltalk[word]        run()        break

Тут тоже нужен ваш совет: подскажите пожалуйста более эфективный способ искать фразы.

К Dialog Flove у меня непреязнь. Личная.

ОТКРТИЕ ПРОГРАММ, САЙТОВ И ПОИСК В ИНТЕРНЕТЕ

import webbrowser#переменная error сообщает о том, нашла-ли программа ответ на фразу пользователя, если да, то error = 0while условный True:    #поиск    elif "найди" in an:        error = 0        if "в интернете" in an:            t = "Начинаю поиск в интернете" + an[an.find("ете")+3:]            run()            sear = an[an.find("ете")+3:]            webbrowser.open("https://www.google.com/search?q=" + sear)        elif "youtube" in an:            sear = an[an.find("be")+2:]            t = "Начинаю поиск в ютубе " + sear            run()            webbrowser.open("https://www.youtube.com/results?search_query=" + sear)        else:            t = "Вы дали мало данных, скажите найди в интернете, либо найди в ютубе и ваш вопрос."            run()        continue    #функция на закрытие Тут мы берем 2 кортежа, в кортеже "listprogram" у нас ключевые слова, а в "listprogram2" команды.    elif "закрой" in an:        listprogram = ("steam", "skype", "браузер")        listprogram2 = ("TASKKILL /IM steam.exe", "TASKKILL /IM skype.exe", "TASKKILL /IM chrome.exe")        for net in range(len(listprogram)):            if listprogram[net] in an:                program = listprogram2[net]                os.system(program)                os.system('cls' if os.name == 'nt' else 'clear')                t = "Закрываю " + listprogram[net]                 run()                error = 0        continue    #синтезатор речи    elif "текст" in an:        error = 0        t = "Вставьте сюда текст, который надо синтезировать. в конце текста напишите команду стопсинтез"        run()        t = ""        while True:            t = t + " " + str(input("Вставьте сюда текст > "))            if "стопсинтез" in t:                break                t = t[:t.find("стопсинтез")]        run()             #интернет Тут мы берем 2 кортежа, в кортеже "fordefweb" у нас ключевые слова, а в "fordefweb" ссылки.    fordefweb = ("youtube", "вконтакте", "браузер", "google", "новости", "окко", "хабр", "facebook", "wifmedia", "свой сайт")    fordefweb2 = ("https://www.youtube.com/", "https:/vk.com", "https://www.google.ru/", "https://www.google.ru/", "https://lenta.ru/", "https://okko.tv/", "http://personeltest.ru/aways/habr.com/ru/feed/", "https://www.facebook.com/", "https://wifmedia.com/", "http://vitaliy.renderforestsites.com")    for net in range(len(fordefweb)):        if fordefweb[net] in an:            web = fordefweb2[net]            runweb()            error = 0    #программы Тут мы берем 2 кортежа, в кортеже "listprogram" у нас ключевые слова, а в "listprogram2" команды.    listprogram = ("проводник", "skype")    listprogram2 = ("explorer.exe", "start skype.exe")    for net in range(len(listprogram)):        if listprogram[net] in an:            program = listprogram2[net]            os.system(program)            t = "Открываю " + listprogram[net]             run()            error = 0

Опять-же не могу найти ничего действенее elif, но в этой версии и хотя-бы меньше.

ОСТАЛЬНОЕ

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

Материаллы

САЙТ (просто дешевая одностраничка на renderforest)

ГИТХАБ

демонстрационный ролик