Сегодня мы прочли статью Википедия купается в деньгах и были очарованы. Там рассказано, как фонд Wikimedia собирает пожертвования по всему миру, и как развивается его целевой капитал. Да, всё в статье правда: в США и фонд есть, и активы есть, и доход есть. Однако in Soviet Russia дело обстоит совсем иначе. Поистине тревожит российских редакторов-добровольцев Википедии совсем иное.
Вообще говоря, фонд Wikimedia очень хорошо поддерживает волонтёров. Он предлагает проектные гранты, гранты на оборудование, гранты на поездки. Он занимается дипломатией и помогает своим chapters местным союзным организациям. Однако из-за политических причин фонд никак не работает с жителями России, не принимает никаких пожертвований из России.
Вот, убедитесь своими глазами.
Во многих странах работают местные организации, созданные участниками Википедии. Конечно, головной фонд помогает им. С 2008 года в России тоже есть такой союз партнёрство Викимедиа РУ. И ему головной фонд не помогает никак, не перечисляет ничего.
Поэтому для нас, жителей России, пожертвования в Wikimedia Foundation напрочь бесполезны. Эти пожертвования никак не отразятся на русскоязычной Википедии, на российских участниках. Они останутся в заграничном обществе.
Значит, надо совсем по-другому относиться к пожертвованиям. И как же? А вот как.
1) Если вы хотите помочь Википедии помогите ей там, где вы живёте. Помогите участникам в вашей области, в вашем городе, в вашем селе. Свяжитесь с людьми, которые наполняют Википедию фотографиями и книгами (Викисклад), которые пишут статьи для неё. Спросите у них, какая помощь нужна. Отдайте деньги на конкретные местные задачи.
2) Если вы хотите поддержать конкретный проект, например, Викиновости или Викигид откройте форум того проекта, обратитесь к участникам, предложите им свою помощь.
3) Если вы хотите просто отдать деньги на Википедию обратитесь в Викимедиа РУ и отправьте деньги туда. Ваша помощь останется в России и перейдёт к тем, кто создаёт вики-материал на русском языке.
Впрочем, поддержать можно не только деньгами. Можно поддержать и дипломатией, и оцифровкой контента, и пропагандой. Вы знаете, как работает Википедия, а сотрудники местного вуза не знают. Вы знаете, как пополнять Википедию контентом, а сотрудники местной библиотеки не знают. Вы знаете, что такое свободная лицензия, а местная администрация и городская газета не знают. Вы знаете, что такое Викисклад, а ваши друзья-фотографы не знают.
Пожалуйста, откройте им глаза. Зулейха Валиева не должна остаться в одиночестве.
Вот, собственно, и всё, что надо знать о пожертвованиях на Википедию в нынешней России.
Недавно у нас на работе стихийно возник спор о том, стоит ли вводить непрерывную доставку. Не имея в виду сразу переделывать все наши процессы под непрерывную доставку, я, однако, отстаивал целесообразность такого подхода в общем. К сожалению, после начала спора я за приемлемые 510 минут так и не нашел в интернете подходящего текста, доходчиво объясняющего, зачем нужна непрерывная доставка, чтобы хорошенько подкрепить свою точку зрения. Материалов о том, как наладить непрерывную доставку, очень много, а вот статей (на русском языке) о том, зачем же это нужно, недостает.
Давайте исходить из того, что цель жизни нормального человека это написать побольше интересного кода и закинуть его на прод. С такой точки зрения, думаю, важность непрерывной доставки очевидна. Увы, оказалось, что есть и совершенно другие люди (вы можете узнать их по таким странными выражениям, как качество продукта, ресурсы, скорость исправления ошибок, трудозатраты), которым нормальные ценности чужды. Чтобы легче было достучаться до них и чтобы под рукой всегда была краткая памятка по отстаиванию единственно правильной точки зрения, я и написал этот текст.
Ладно, в некоторых довольно редких, надо сказать, ситуациях организовать непрерывную доставку действительно почти невозможно. Думаю, вы и сами поймете это, когда окажетесь в подобной ситуации. На всякий случай ближе к концу этого материала описаны случаи, в которых выгоды непрерывной доставки явно не окупят расходов на ее организацию.
В данном материале будем пользоваться следующими тремя определениями М. Фаулера.
Непрерывная интеграция (Continuous Integration) когда продукт регулярно (несколько раз в день) собирается из исходного кода и для него запускается существенная часть автоматических тестов, например все модульные тесты. Если автоматические тесты работают долго, то их можно запускать реже, например раз в сутки. Стандартный подход для организации непрерывной интеграции это запустить TeamCity или Jenkins, которые будут загружать исходный код из системы контроля версий, собирать его и запускать тесты. Другие известные решения: Travis CI, GitLab, Space, GitHub, BitBucket.
Непрерывная доставка (Continuous Delivery) продукт всегда находится в собранном состоянии и готов к передаче в промышленную эксплуатацию, даже с учетом последних изменений, внесённых разработчиками в код. Скорее всего, непрерывная доставка будет реализована на основе тех же технологий, что и непрерывная интеграция. В этой статье на Хабре приводятся еще несколько подходящих открытых инструментов. В другой работе подробно рассматривается разница между реализацией конвейера сборки в облаке и на земле.
Непрерывное развертывание (Continuous Deployment) когда обновления продукта регулярно (например, после каждого изменения, внесенного разработчиками) вводятся в промышленную эксплуатацию, и при этом все процессы предметной области продолжают работать без сбоя. В некотором роде непрерывное развертывание это хорошо автоматизированная и часто выполняющаяся непрерывная доставка.
Чтобы лучше осознать эти понятия, можно посмотреть на картинку, где приведена более-менее универсальная схема современного процесса разработки и доставки программного продукта. В каких-то компаниях используются дополнительные компоненты, а некоторые из указанных не используются.
Мне кажется, что в профессиональной среде чаще пользуются обобщающим все вышеперечисленное термином CI/CD с необходимыми уточнениями, чтобы не задумываться о том, какой из трех терминов включает регулярное автоматическое развертывание продукта в средах для разработки и тестирования.
Чтобы разобраться в произношении названий, предлагаю заинтересованным почитать Ответы Mail.ru, а я далее буду пользоваться латиницей. О чем это я? Конечно, о двух захолустных деревнях Villarriba и Villabajo: обе деревни живут типичным сельским трудом производят программное обеспечение. Жители первой деревни вводят обновления своего продукта в промышленную эксплуатацию каждый день, ну, может быть, кроме пятниц (то есть практикуют непрерывную доставку или развертывание), а жители второй каждые две недели. На их примере предлагаю рассмотреть несколько параметров стандартного процесса изготовления и сопровождения программных продуктов. Это поможет лучше понять, в чем заключаются рассматриваемые подходы.
Жители Villabajo выкатывают изменения раз в две недели. За две недели они делают много новой функциональности, поэтому, когда они ошибаются в одной из новинок, им приходится либо 1) откатывать сразу все изменения и, если надо, выковыривать из версии дефектное изменение, собирать версию заново и ставить ее (впопыхах, естественно), либо 2) ковыряться сразу во всех изменениях, которые они выкатили, пытаться понять, какое из этих изменений привело к ошибкам, и отлаживать это в бою.
Жители Villarriba готовы выкатывать изменения хоть несколько раз в день. Чем чаще они выкатывают обновления, тем меньше изменений у них накапливается. Чем меньше изменений одновременно вводится в промышленную эксплуатацию, тем легче откатить ошибочные изменения или, при возможности, исправить их прямо в работающем продукте, потому что изменения изолируются друг от друга и, значит, меньше друг на друга влияют.
Казалось бы, жители Villarriba ошибаются не реже жителей Villabajo, поэтому количество дефектов в промышленно эксплуатируемом продукте одинаковое! Однако жители Villarriba в среднем исправляют каждый дефект быстрее, чем жители Villabajo, потому что им легче разобраться в причинах ошибки, легче откатить ошибочные изменения и легче накатить исправленную версию.
Но и здесь не все так просто: жители Villabajo не хотят ставить обновления часто не потому, что они такие злые, а потому, что у них плохо автоматизирован процесс публикации своего продукта. В результате они, в отличие от жителей Villarriba, страдают еще и от ошибок в продукте, порожденных неправильной установкой версии. На эту тему есть интересное исследование (стр. 53).
Жители Villabajo выкатывают изменения раз в две недели. В отличие от серьезных b2b-контор из столицы 6-й экономики мира, у жителей Villabajo действительно четко запланирован объем каждого спринта, а еще они научились проверять, все ли нужное вошло в версию (и не попал ли туда мусор), в полуавтоматическом режиме.
Тем не менее каждый житель Villabajo регулярно тратит по несколько часов, чтобы:
1) проверить версию на полноту включенных изменений (да, в полуавтоматическом режиме), включить в версию то, что забыли, и выкинуть то, что попало по ошибке, договориться с остальными жителями деревни и с заказчиком о том, что пришло время ставить обновление;
2) выполнить то, что нужно сделать до установки версии, например, запустить скрипты, отладить и починить их, потому что они не были полностью готовы к запуску в бою;
3) выполнить то, что нужно сделать во время установки версии, например, запустить скрипты, отладить и починить их, потому что они опять не были полностью готовы к запуску в бою;
4) выполнить то, что нужно сделать после установки версии, например, запустить скрипты, отладить и починить их, потому что они в третий раз не были полностью готовы к запуску в бою.
Жители Villarriba готовы выкатывать изменения раз в день. Им приходится почти все время держать продукт готовым к введению в промышленную эксплуатацию с учетом самых последних обновлений. У них нет скриптов для выполнения перед установкой новой версии, во время и после нее. Они ведут разработку таким образом, чтобы можно было вводить новую функциональность постепенно, по одному небольшому контролируемому блоку за версию. Жителям Villabajo нет смысла так делать: у них же версии раз в две недели.
Что в итоге? Жители Villabajo каждые две недели тратят первую половину рабочего дня на то, чтобы установить версию, а вторую половину на просмотр YouTube (в лучшем случае чтение Хабра), потому что после стресса они не могут продуктивно работать (серьезно, см., например, вот эту публикацию, стр. 53). А жители Villarriba работают в обычном режиме, только иногда отвлекаются на то, чтобы откатить последние изменения с боевого сервера.
Рассматриваемый эффект уменьшение затрат на установку версии вполне очевиден и подтверждается реальными случаями. Например, непрерывная доставка помогла одной из команд Hewlett-Packard снизить общие затраты на разработку на 40%.
В одном исследовании (стр. 53) показывается, как непрерывная доставка избавила инженеров компании от необходимости тратить несколько дней (разумеется, в каждой компании это значение свое) на подготовку и установку версии. В этот же эффект, очевидно, включается и отмеченное там же уменьшение затрат на исправление ошибок именно в самом процессе подготовки и установки версии.
В другом исследовании (стр. 67) некоторые из опрошенных компаний в качестве существенного преимущества непрерывных подходов отметили уменьшение количества ручного труда, необходимого для управления всем циклом разработки и доставки.
Жители Villabajo выкатывают изменения раз в две недели. Если их заказчик хочет какую-то функциональность, то он вместе с жителями Villabajo согласует дату, когда он увидит эту функциональность, и жители Villabajo готовят ее точно к сроку. Более того, в некотором смысле заказчик не может отказаться от запланированной функциональности: сначала этой функциональности нет на боевом сервере, потом есть день установки версии, а потом эта функциональность отлита в граните.
Чтобы откатить эту функциональность (либо из-за того, что жители Villabajo ошиблись, либо из-за того, что сам заказчик или другие взаимодействующие с продуктом Villabajo системы не готовы), надо установить предыдущую версию, удалить из новой версии оказавшуюся ненужной функциональность и установить эту исправленную новую версию. Особенно жители Villabajo унывают в таких случаях, когда новая версия успела создать данные, которые не могут быть обработаны старой версией: приходится чистить или переформатировать эти данные.
Жители Villarriba готовы выкатывать изменения раз в день. Если их заказчик хочет какую-то функциональность, то, после того как она готова к публикации, он может в любой момент включить ее. Еще жители Villarriba сделали так, чтобы заказчик мог вернуться к предыдущей версии, пока полностью не убедится в том, что его устраивает новая функциональность. Такой подход выглядит наиболее естественным в случае, когда основная ветка исходного кода должна быть готова к публикации в любой момент.
В отличие от жителей Villabajo, жители Villarriba тратятся на поддержание кода в адекватном состоянии и, возможно, на переключатели функциональности, но 1) им не приходится тратиться на откатывание оказавшихся ненужными изменений и на докатывание исправленных версий; 2) их заказчикам не нужно согласовывать миг, в который новая функциональность становится неотъемлемой частью системы.
Заказчики жителей Villarriba довольны. Это и неудивительно: положительное влияние такого подхода на отношения между заказчиком и исполнителем подтверждают научные исследования (стр. 67).
Жители Villabajo выкатывают изменения раз в две недели. В большинстве случаев они не имеют возможности проверить, как поведет себя новая функциональность на боевом сервере. В отличие от серьезных b2b-контор из столицы 6-й экономики мира у них есть много сред развертывания, и одна из них по своим параметрам почти совпадает с боевой.
Но все же различия между боевой и почти боевой средой не позволяют жителям Villabajo точно предсказывать последствия публикации новой версии. Можно выкатывать новую функциональность по чуть-чуть, но кто же будет ждать, пока этих двухнедельных чуть-чуть наберется на заказанную функциональность? Тут и заказчик забудет, зачем она ему нужна, и разработчики будут каждые две недели после установки версии заново вспоминать, чем же они таким занимались и что там в готовящейся функциональности надо корректировать.
Жители Villarriba могут позволить себе выдавать новую функциональность небольшими порциями, попадающими в боевую среду каждый день. После публикации версии (а они даже и не особенно следят за этим, для них публикация версии это просто обычный рабочий день) жители Villarriba смотрят, как их небольшие изменения отразились на системе и ее пользователях, и в зависимости от этого корректируют готовящуюся функциональность, по необходимости информируя своего заказчика об изменениях.
Как видно, жители Villarriba наслаждаются коротким циклом разработка публикация корректировка, благодаря чему у них не бывает, как у жителей Villabajo, проблем с отгрузкой буквально не той функциональности, что было нужно.
Пример: положительное влияние быстрой обратной связи отмечено в исследовании (стр. 65); там же сказано, что сами разработчики при этом лучше понимают, что они делают, и больше вовлечены в рассмотрение процессов предметной области. В другом исследовании (стр. 21) указывают на прямую корреляцию между тем, 1) насколько полно компании учитывают обратную связь от клиентов для исправления своих продуктов, 2) насколько просто заинтересованные сотрудники могут увидеть и осознать жизненный цикл продукта, 3) насколько сотрудники удовлетворены работой в компании и 4) насколько сильно сотрудники ассоциируют себя с компанией.
А это немного особенный пункт, в котором рассматривается основная боль отдела обеспечения качества: функциональное и регрессионное тестирование вручную. Сначала посмотрим, зачем это нужно.
Очевидно, во время функционального тестирования проверяется, соответствует ли выполненная работа описанной и согласованной с клиентом постановке. В случае чего вносятся исправления.
В это время также может готовиться и приемочный сценарий для клиента.
Выявляются ошибки в тех местах, которые не покрыты автоматическими тестами.
Во время регрессионного тестирования проверяется функциональность, которая находится сбоку и напрямую не затрагивалась при разработке. Здесь же можно упомянуть и проверку того, как изменения, сделанные в рамках отдельных задач, дружат между собой: не появляется ли при соединении этих изменений неожиданных и нежелательных эффектов.
Возможно, требуется и проведение нагрузочного тестирования.
В компаниях, выпускающих новую версию раз в 23 недели, часто практикуется продолжительное ручное тестирование, к началу которого должны быть готовы все задачи, планирующиеся в предстоящую версию. После тестирования и разворачивания новой версии в боевой среде начинается новый цикл проработки технического задания, реализации и тестирования. Таким образом, если разработчики будут вливать готовые изменения в основную кодовую базу слишком часто, у отдела обеспечения качества не будет достаточного временного промежутка, когда набор внесенных изменений достаточно заморожен для того, чтобы можно было провести регрессионное тестирование.
Эту проблему решают переключатели функциональности. С их помощью можно держать внесенные изменения в спячке в тестовой среде (можно и в боевой, просто сейчас речь идет именно о тестовой среде) и включать их разом в тот момент, когда отдел собирается приступить к регрессионному тестированию. Во время тестирования разработчики вносят изменения, касающиеся других задач, например, для следующей версии. Эти изменения по умолчанию также пребывают в спячке и ждут, когда начнется тестирование следующей версии. Понятно, что переключатели функциональности помогают также и в приемочном тестировании.
Если вернуться к сюжету о двух деревнях, то скажем так: жители Villabajo заранее объединяют в одной тестовой среде все те и только те изменения, которые нужно протестировать за точно заданный временной промежуток, а жители Villarriba могут гибко менять объем тестируемых изменений и время проведения тестирования. Такое удобство досталось жителям Villarriba не бесплатно (они должны были по крайней мере внедрить переключатели функциональности), но ясно, что у нас тут вряд ли стоит искать преимущества, дающиеся без затрат.
Теперь давайте немного структурируем рассмотренную информацию. В следующем далее списке первыми идут те преимущества, которые дает непрерывная доставка, затем те, которые появляются и при внедрении непрерывной доставки, и при внедрении непрерывного развертывания (каждый раз новые), затем те, которые дает только непрерывное развертывание. То же и с затратами. В конце этого раздела основные идеи подытожены в виде технологического дерева компании, производящей программное обеспечение.
Установка обновлений почти полностью автоматизирована, поэтому перестают появляться ошибки из-за неправильной установки обновления.
Установка обновлений почти полностью автоматизирована, поэтому вы ничего не тратите на установку новой версии.
Изменения быстрее интегрируются и проверяются на фоне в общем стабильной системы. Заинтересованные сотрудники быстрее получают обратную связь и лучше понимают свою роль и задачи в контексте продукта в целом (как системы). Поэтому становится меньше проблем на стыке зон ответственности; исчезают симптомы вида об этом должен позаботиться кто-то другой. Качество рождается на местах, а не обеспечивается отдельным процессом (подробнее об этом здесь, на стр. 22).
Установка обновлений почти полностью автоматизирована, поэтому сотрудники не выгорают во время установки новой версии.
Установка обновлений почти полностью автоматизирована, а изменения устанавливаются небольшими порциями, поэтому вы быстрее устраняете ошибки и восстанавливаете штатную работу продукта.
Установка обновлений почти полностью автоматизирована, а изменения устанавливаются небольшими порциями, поэтому ошибки, которые вы допускаете, реже становятся катастрофическими.
Установка обновлений почти полностью автоматизирована (как и весь цикл разработки), поэтому от идеи до появления ее реализации в промышленной эксплуатации проходит очень мало времени. Благодаря этому, заказчик и исполнитель могут легко проверять свои гипотезы о новой функциональности на практике, быстрее реализовывать полезную и удалять невостребованную функциональность.
Обновления устанавливаются автоматически и непрерывно, поэтому вы меньше тратите на согласование установки новой версии и момента включения новой функциональности. При желании заказчик может делать это самостоятельно.
Обновления устанавливаются автоматически, непрерывно и небольшими порциями, поэтому вы с заказчиком начинаете лучше понимать друг друга; исчезают проблемы вида сделали не то, что хотели.
Обновления устанавливаются автоматически и непрерывно. Заинтересованные сотрудники быстрее получают обратную связь и лучше понимают свою роль и задачи в контексте находящегося в промышленной эксплуатации продукта. Поэтому сотрудники больше вовлечены в предприятие (и в процесс создания продукта, и в его предметную область). Они сильнее ассоциируют себя как с продуктом, так и вообще с компанией.
Чтобы наладить полуавтоматическую публикацию, вы должны купить и настроить соответствующее программное обеспечение. Если у вас уже есть непрерывная интеграция, то вы наверняка сможете переиспользовать ее инфраструктуру.
Чтобы наладить полуавтоматическую публикацию, вы должны провести организационные изменения. Например, если единственная команда владеет доступом к нужному серверу, нужно сделать так, чтобы к серверу имели доступ все заинтересованные сотрудники. Подробности в этой статье (стр. 53).
Чтобы держать основную ветку исходного кода в собранном состоянии, вы не должны включать в нее потенциально разрушающие изменения. Например, если для работы новой функциональности требуется хранить данные в новом формате, то ваш продукт должен продолжительное время иметь возможность работать с данными как в старом, так и в новом формате.
Если вы или заказчик вручную проводите регрессионное тестирование совокупности изменений в целом, то вам нужно будет настроить переключатели функциональности. Благодаря этому, вы сможете держать в боевой среде множество изменений в скрытом виде и включать их только после того, как проверите все в тестовой среде.
Чтобы вводить рассмотренные изменения, вам надо будет сломать консервативную корпоративную культуру у себя и у заказчика. Это, очевидно, означает, что между вами и заказчиком должно установиться доверие достаточно высокого уровня.
Чтобы иметь возможность публиковать обновления продукта несколько раз в день, вы должны поменять процессы таким образом, чтобы 1) установка новой версии не требовала отдельного согласования с заказчиком или чтобы 2) заказчик мог сам управлять включением и выключением новой функциональности.
Есть случаи, когда внедрить непрерывные доставку или развертывание почти невозможно.
Некоторые предметные области плохо поддерживают непрерывное развертывание (см. стр. 69 этого исследования), например, телекоммуникационное программное обеспечение и встраиваемое медицинское оборудование.
Еще проблемы могут возникнуть, когда речь идет о продукте большого объема, который не покрыт автоматическими тестами или который тяжело интегрируется с остальными системами.
В CUSTIS есть разные команды, так что и ситуация во всех них немного отличается. Есть команды, где налажено непрерывное развертывание, есть команды, где обновления ставятся вручную раз в несколько недель. Как было отмечено в самом начале, в моей команде как раз пока нет сильной спешки с переходом на непрерывную доставку.
Один из проповедников непрерывной доставки отмечал в 2014 году, что многие руководители не убеждены в преимуществах такого подхода. Надеюсь, что сегодня уменьшилось хотя бы относительное число таких руководителей и что данный материал поможет аргументированно и конструктивно убедить оставшихся. Кроме этого, не забывайте и о более общих методах работы с людьми.
Если будете вести свою зловещую пропаганду, можете ссылаться на отчет State of DevOps (стр. 13). В отчете утверждается, что в 2016 году успешные компании публиковали обновления намного чаще, чем остальные (экстремальные значения показали Amazon и Netflix несколько тысяч раз в день), и у них изменения быстрее проваливались по конвейеру от включения в исходный код до введения в промышленную эксплуатацию. Но только в таком случае лучше сразу сознаться, что прямой причинно-следственной связи здесь установить нельзя. Вероятнее всего, что непрерывное развертывание это только одно из свойств успешной компании.
1cloud.ru. Справочная: что такое Continuous Delivery (2019)
Martin Fowler. ContinuousDelivery (2013)
Jez Humble. The Case for Continuous Delivery (2014)
B. Alanna, N. Forsgren, J. Humble et al. State of DevOps Report (2016)
Chen, Lianping. Continuous Delivery: Huge Benefits, but Challenges Too (2015)
Leppnen, M.; Mkinen, S.; Pagels, M.; Eloranta, V. P.; Itkonen, J.; Mntyl, M. V.; Mnnist, T. The Highways and Country Roads to Continuous Deployment (2015)
A. Hkli, D. Taibi, K. Syst. Towards Cloud Native Continuous Delivery: An Industrial Experience Report (2018)
Г. А. Минашин. Переключатели функциональности (feature toggles): виды, преимущества и работа с ними в .NET (2019)
Усталость от принятия решений это популярный термин, описывающий случаи, когда человек за определенное время принимает слишком много решений. Исследования показывают, что причина этого явления в исчерпании когнитивных ресурсов именно поэтому после 30минут поисков на Нетфликсе чего-то нового вы в итоге смотрите давно знакомый Офис: ваша способность принимать решения снизилась, и мозг сдался (хотя это и неплохое шоу).
При разработке продуктов мы стараемся снизить количество решений, которые необходимо принимать пользователю. Предполагается, продукт используют для выполнения задачи, и чем проще и интуитивнее она будет выполняться, тем лучше. Чем больше мелких решений вынужден принимать человек в течение определенного времени, даже если они очень простые (например, какой сериал посмотреть), тем ниже будет качество принятия решений.
Если вы устали, это может значительно повлиять на способность принимать решения, поэтому UX-дизайнеры при разработке интерфейса должны понимать, как усталость влияет на пользователей. И это очень интересная тема, ведь есть множество причин, по которым пользователи могут испытывать когнитивную перегрузку при использовании вашего продукта.
В этой статье рассматриваются шесть способов снизить когнитивную нагрузку в UX-проекте.
Каждый день количество вариантов, которые есть у нас как пользователей, растет в геометрической прогрессии. Интернет открыл мгновенный доступ к знаниям всего мира чего никогда ранее не было. Такой широкий выбор может парализовать, снизить удовлетворенность и даже заставить отказаться от открывшихся возможностей вместо того, чтобы использовать их.
Если у пользователя слишком много вариантов выбора, он легко сбивается с толку и раздражается. У продукта могут быть все необходимые функции, но если интерфейс чересчур запутан из-за чрезмерного количества возможностей, он становится неудобным. В опубликованном в журнале Journal of Personality and Social Psychology исследовании говорится, что такая ситуация часто вызывает паралич принятия решений и раздражение. [1]
Модель из статьи в Harvard Business ReviewВ погоне за повышением числа начальных (или повторных) продаж компании могут включать в свои продукты слишком много (или слишком мало) функций. Используя модель, предложенную в Harvard Business Review, можно найти золотую середину в зависимости от желаемого результата.
Фото Charles Deluvio, площадка UnsplashИсследования показали, что человек с большей вероятностью делает покупку в условиях ограниченного числа вариантов, причем сделанный выбор в такой ситуации будет радовать больше, что даст более сильное чувство удовлетворенности.
Проблема в том, что компании предлагают пользователю слишком много вариантов, что оказывается бесполезной тратой ресурсов и может иметь неприятные последствия. Покупатель может тратить время, пробуя все возможные продукты, вместо того, чтобы купить хоть что-то. [2]
В сфере UX есть множество мифов о том, сколько кликов нужно использовать и как много информации человеческий мозг может воспринять за раз. Самая главная задача UX-дизайнеров найти баланс между простотой и функциональностью: чтобы, с одной стороны, облегчить пользователям работу, а с другой не заставлять слишком много обдумывать принимаемые решения.
Одна из самых неверно интерпретируемых теорий Магическое число семь Джорджа Миллера. Иногда можно услышать, что должно быть только семь вкладок меню или семь пунктов в списке, но это неверно. В некоторой степени я с этим мнением соглашусь, потому что придерживаться таких границ кажется естественным, однако необходимо учитывать, как информация и наш мозг менялись с течением времени. Веб-сайты и приложения представляют данные визуально, не задействуя память, как было раньше, поэтому листая контент на экране, мы продолжаем видеть все варианты, и запоминать их не нужно (и можно воспользоваться быстрым поиском).
В недавних исследованиях было показало, что людям нравятся меню со множеством вариантов: чем вариантов больше, тем лучше, поскольку не приходится искать нужную информацию во вложенных меню. Веб-сайты и приложения, которые представляют данные визуально, например, Amazon с почти 90категориями на главной странице, оказываются удобнее, чем те, что предлагают небольшое число вариантов (например, категории без подкатегорий).
Amazon на главной странице дает пользователям много вариантовТеперь опровергнем еще одну общепринятую, но совершенно не выдерживающую критики теорию правило трех кликов, или еще менее верное правило двух нажатий. Почитав материалы по этой теме и проверив эти правила, можно обнаружить, что пользователи не особо расстраиваются, если не могут найти нужное за три клика. Ни удовлетворенность пользователей, ни процент успеха не зависят от количества необходимых для поиска кликов.
Отличная иллюстрация информационного запаха от NN GroupВажно не столько количество вкладок меню и списков, сколько удобство работы для пользователя. Правильное визуальное размещение упрощает поиск и запоминание каждого варианта. Согласно теории информационного фуражирования, для пользователя имеет значение постоянное ощущение информационного запаха. Пользователи прогнозируют, насколько удовлетворительной может быть информация, с которой они столкнутся, и после работы с пользовательским интерфейсом решают, были ли прогноз точным.
Проблема в том, что людям в повседневной жизни и так слишком часто приходится делать выбор, поэтому чрезмерное количество вариантов может угнетать. Дело не в количестве вариантов, которые вы предлагаете, а в том, как они упорядочены. Необходимо снижать число вариантов, но самое важное хорошая информационная структура. Если информация плохо организована или в процессе принятия решения задействовано слишком много шагов, пользователи не будут пытаться найти нужное, поскольку им будет казаться, что это займет слишком много времени или потребует больше усилий, чем необходимо.
Чтобы принимаемые клиентами решения в случае веб-сайтов давали лучшие результаты, я бы посоветовал избавиться от всего ненужного: лишних вкладок и ссылок, которые отвлекают пользователей от поиска желаемого.
Понятно, что все мы иногда делаем ошибки даже лучшие из нас! Но как организовать хороший интерфейс на случай ошибки пользователя?
Ответ прост: нужно дать возможность легко вернуться туда, откуда пользователь начал.
Да, иногда найти необходимое бывает не так уж и просто! Фото Daniel Mingook Kim, площадка UnsplashПомогая пользователю не сбиться с пути, вы с большей вероятностью удержите его в качестве клиента и не создадите неприятную ситуацию, в результате которой он покинет ваш сайт или приложение.
Хороший пример страница с ошибкой 404: наверняка каждому из нас приходилось натыкаться на нее. Согласитесь, неприятно не найти то, что искали. Исправить ситуацию можно, добавив кнопку назад, которая вернет пользователя туда, где он был до того, как попытался перейти по ссылке, приведшей в никуда.
А еще страница 404 отличная возможность отправить пользователя исследовать продукт и открыть для себя то, о чем он не подозревал. Вот пару примеров хорошей реализации этих идей:
Missguided использует эту возможность и помогает найти нужное или открыть для себя что-то новоеVero Moda тоже хорошо справляется с задачей: заметное поле поиска и популярные категорииBirchbox также помогает открыть что-то новое для себяПри разработке пути пользователей я использую следующие рекомендации:
Не нужно раздражать людей, забрасывая их ошибками.
Должно быть легко найти и исправить ошибку, а затем продолжить использование продукта.
Предотвращайте неправильный ввод данных: сохраняйте их до того, как ошибка испортит пользователю впечатление.
Не показывайте сообщение на всю страницу укажите, в каких полях ошибка.
В сообщениях избегайте резких формулировок: они могут отпугнуть и даже разозлить некоторых пользователей.
Навигация основа любого веб-сайта или приложения. Именно она делает дизайн понятным и удобным для всех. Подобрать хорошую систему навигации для конкретного случая может быть сложно, но она имеет решающее значение для пользователя. Плохая будет раздражать и отвлекать и у пользователя останется отрицательное впечатление.
Фото Fab Lentz, площадка UnsplashИнтерфейс навигации должен быть интуитивно понятным и простым в использовании. Пользователь должен всегда понимать, где он находится, что он может использовать в данный момент и как это сделать. Хороший вариант добиться этого подсказки в окружении пользователя или на экране: смена цветовой гаммы при переходе в другой раздел и понятное информирование о том, какие функции в каком пункте меню можно найти. Такие штрихи помогут сделать навигацию по веб-сайту или приложению скорее приятной, чем сложной.
Правильно подобранное количество визуальных подсказок:
Упрощает обзор и чтение страницы.
Улучшает визуальную иерархию.
Улучшает навигацию по странице.
Существенно повышает коэффициент конверсии.
На эту тему институт CXL провел интересное исследование, в котором пользователям демонстрировали различные примеры целевой страницы. Всего было шесть вариантов с различными визуальными подсказками, которые призваны были помочь заполнить форму.
Все изображения принадлежат институту CXLИсследователи отмечали время, потраченное на поиск, а также на просмотр формы. Если участники заявляли, что заполнят форму связи с фирмой, визуальная подсказка направляла их внимание на форму и повышала вероятность запоминания.
Выяснилось, что вид подсказки существенно влиял на количество пользователей, заполнивших форму. Нарисованная от руки стрелка притягивала взгляд и оставляла впечатление творческого подхода, что привлекло внимание намного лучше остальных вариантов. А страница с человеком, смотревшим в сторону от экрана компьютера, получила вдвое меньший отклик, чем худший из остальных вариантов!
Изображение институт CXLИзображение институт CXLСогласно данным этого исследования, есть смысл протестировать на веб-сайте нарисованные от руки стрелки и другие направленные объекты для фокусировки внимания пользователя, особенно если они будут указывать на призыв к действию или другую важную функцию.
Единственно правильного варианта использования изображений людей в формах и призывах к действию нет, но, судя по всему, лучше, чтобы человек на картинке смотрел в сторону формы, а не наоборот.
При разработке нового интерфейса важно снизить когнитивную нагрузку на аудиторию. Сделать это можно в том числе с помощью знакомых им шаблонов и условностей но как узнать, что конкретно использовать?
Я покажу три примера распространенных в UX-дизайне условностей, благодаря которым пользователи будут чувствовать себя увереннее при взаимодействии с вашим продуктом или сервисом. Это поможет снизить когнитивную нагрузку и быстрее научить пользователей тому, что вам нужно.
Согласованность цветовой схемы может из хорошего дизайна сделать великолепный. Преимуществ у единообразной цветовой палитры множество, но одно из самых важных состоит в том, что она упрощает навигацию.
Фото Balzs Ktyi, площадка UnsplashЦвет привлекает внимание, поэтому если интерфейс построен на использовании одного цвета, в нем будет легче ориентироваться: не придется тратить много сил, чтобы понять, что где находится, или как вернуться назад после сделанной ошибки.
Важно не только следовать принятым условностям, но и регулярно использовать их и тогда случится прекрасное:
вашим продуктом станет удобно пользоваться, потому что в нем не будет ничего нового (это снижает когнитивную нагрузку);
на примере пользователи научатся быстрее, чем при помощи явных указаний (что тоже снижает когнитивную нагрузку).
Отличный пример использование строк навигации, которые дают пользователям понять, где они находятся и как вернуться назад благодаря этому простая ошибка не приведет к долгим попыткам найти выход самостоятельно.
Еще один хороший вариант оставлять панель меню вверху или внизу сайта, какая бы страница ни была открыта: это помогает лучше ориентироваться, поскольку снижается когнитивная нагрузка при принятии решения о том, какое действие должно произойти следующим (например, выбор пункта из списка).
Значки удобное средства указания на действие или объект в приложении. Их легко распознать, поэтому они идеально подходят для быстрого взаимодействия. Добавление привычных каждому значков и символов поможет упростить ориентирование в приложении.
Фото Sebastian Herrmann, площадка UnsplashПри этом нужно следить за тем, чтобы использовались широко известные значки например, дом обычно считается значком домашнего (начального) экрана. То же и с корзиной: она считается значком удаления элемента.
Многие компании пошли по пути использования значков, которые никто не понимает, что создает путаницу и раздражает пользователя. А чтобы значок был однозначно понятен, его обязательно нужно подписывать.
Все мы понимаем, что работаем для конечных пользователей, но не всегда это знание легко применить. Когда мы погружаемся в проектирование интерфейса и пытаемся понять, что нужно пользователю и как он отреагирует, нам бывает сложно поставить себя на его место.
Фото Amlie Mourichon, площадка UnsplashК счастью, не забывать о пользователе могут помочь несколько простых приемов. Некоторые, чтобы представить себя конечным пользователем, записывают собственные мысли от первого лица. Другим удобнее разбивать рабочий день на короткие отрезки, в которые можно сосредоточиться на работе с одной пользовательской ролью.
Но лучше всего в разработке дизайна с учетом интересов пользователей помогает их собственное мнение. Работая над новым проектом и думая о том, как с ним будут взаимодействовать пользователи, обязательно сначала пообщайтесь с ними напрямую, и только после этого переходите к созданию прототипа или окончательному принятию решения.
При этом можно задавать такие вопросы:
Что больше всего понравилось в нашем последнем продукте?
Как бы вы отнеслись к изменению функции X?
Некоторые полученные в результате такого опроса идеи могут вас удивить и даже изменить направление развития прототипа.
Есть несколько методов исследования UX, которые помогут держать пользователей в центре внимания:
Надлежащее исследование рынка.
Использование персонажей пользовательских ролей.
Макеты и прототипы для получения быстрой обратной связи.
Регулярное общение с собственной службой поддержки.
И этот список, конечно, далеко не полный
Помните, что клиент не глуп и хочет получить правильную информацию, которая поможет принять решение. Беда в том, что владельцы продуктов слишком часто настолько увлечены функциями своего продукта и тем, что он может дать пользователям, что забывают: новых пользователей обилие вариантов выбора и функций может отпугивать.
Если вы владелец продукта, то представьте, что может ощущать пользователь, увидев слишком большое количество возможностей или функций, лучше дайте ему самое интересное.
Например, на сайте магазина можно не давать пользователю 50тканей для обивки дивана, а сразу предложить три-четыре варианта, а при необходимости консультацию чтобы обеспечить индивидуальный подход. Кроме того, пока пользователь не найдет самое подходящее, некоторые варианты можно скрыть за визуальными подсказками (например, хорошо заметные кнопки Подробнее).
Изображение UsabilityHubОдин из способов обеспечить выдачу пользователю наиболее важной информации это спроектировать информационный поток в виде пирамиды, где важная информация будет представлена первой, а менее существенные данные останутся для второстепенных страниц.
Если вы подумываете о новом дизайне или макете для сайта, используйте онлайн-инструмент вроде опросов UsabilityHub, который поможет заранее протестировать дизайн на реальных пользователях и не упустить из виду варианты, которые можно было бы не заметить во время разработки, когда предугадать реакцию пользователя сложнее.
Усталость от принятия решений это популярный термин, описывающий случаи, когда человек за определенное время принимает слишком много решений. Исследования показывают, что причина этого явления в исчерпании когнитивных ресурсов. Усталость может возникать, когда необходимо рассмотреть слишком много вариантов или когда принимаемые решения кажутся несущественными и недостаточно важными, чтобы на них отвлекаться.
В статье было предложено шесть способов снижения усталости от принятия решений в продуктах и сервисах, которые помогут с большей вероятностью удержать пользователей на правильном пути, помочь им достичь поставленных целей, а вам получить нового довольного покупателя!
Помогли ли вам приведенные в статье советы? Расскажите в комментариях ниже или напишите мне на почту alexander@radahl.no.
Перевод статьи выполнен в Alconost.
Alconost занимается локализацией игр, приложений и сайтов на 70 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.
Мы также делаем рекламные и обучающие видеоролики для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.
Работая достаточно давно и плотно в области применения Канбан-метода, пройдя эволюцию его восприятия, копнув в глубь механики, в том числе, как коуч и как консультант, хочу поделиться с вами некоторыми выводами, которые помогут знатокам не грузить лишней информацией молодых, а новичкам не закапываться в теоретическом материале и брать только нужные им в работе, прикладные вещи.
Начну, пожалуй, с подходов к обучению.
Самыми полными и каноничными курсами по погружению в Канбан-Метод по праву считаются классы, которые разрабатывает Канбан Университет структура Дэвида Андерсона, автора метода.
У Университета сейчас в наличиичетыре(ну, хорошо, пять) больших теоретическихмодуля, постепенно погружающих в профессию,и два смежных, позволяющих еще шире взглянуть на работу и совершенствование сервиса.
Прямая линейка:
TeamKanbanPractitioner(можно пропустить, это популярная выжимка основных вещей для первичного погружения в тему)
Kanban System Design
Kanban System Improvement
Kanban Maturity Model
Kanban Coaching Practices
Смежная линейка:
FitforPurpose(раскрывает тему продуктового управления и работы с клиентом)
EnterpriseServicePlanning(стратегическое планирование и управление организацией)
Основной плюсобучения по этим программам вам, в конце концов, дадут все знания, наработанные на эту тему за более чем пятнадцать лет существования Канбан-метода.
Минус, как ни странно, это Эволюция.
Поясню. В ходе эволюции каждая новая конструкция не проектируется с нуля, а получается из старой за счет последовательности небольших улучшений.И то, что в итоге получается, далеко не всегда является оптимальным.
Проиллюстрирую это на картинке, которая меня в свое время поразила своей неэффективностью - как устроено расположение возвратного гортанного нерва у жирафа. Нерв идетот мозга к сердцу, огибает егои возвращается обратнок гортани. В результате сигналу нужно пройти 4 метра (!) чтобы преодолеть расстояние в несколько сантиметров.
Расположение возвратного гортанного нерва у жирафаТо же самое случилось и с подачей материала Канбан Университетом. Вначале, когда метод только развивался, всю имеющуюся информацию Дэвид Андерсон структурировал в небольшой доклад, с которым ездил по профильным конференциям. Когда информации стало больше, появился тренинг и книга Kanban: Successful Evolutionary Change for Your Technology Business (на русском перевели как Канбан. Альтернативный путь в Аджайл).
В дальнейшем, линейка тренингов пополнилась вторым классом. Потом третьим, четвертым, ответвлениями. Но структура подачи материала почти не пересматривалась на первом тренинге сейчас преподают то же самое, что и десять лет назад, хотяконтекст(любимое слово Канбан-практиков) многократно поменялся.
Поэтому, все неофиты проходят один и тот же путь последовательно наступают на те же самые грабли, на которые до них наступили уже отучившиеся десятки тысяч людей.
В итоге, грамотно оперировать материалом можно только отучившись на всех курсах, получив (и усвоив) всю имеющуюся информацию, набрав большое количество практики применения, и пройдя эволюцию восприятия метода.
Так как ни термин Канбан ни термин Канбан-метод не являются зарегистрированными торговыми марками, никто не мешает другим тренерам и консультантам построить свой лунный модуль (как называют этот процесс канонические тренеры и консультанты) для покорения этой области.
Одной из самых популярных баек на эту тему является история, как Хенрик Книберг краем глаза на конференции подсмотрел за лекцией Дэвида Андерсона, взял пару идей и выразил свое понимание в небольшой книге, которая у нас вышла под названием Скрам и Канбан. Выжимаем максимум. В этой книге Эрик сравнивает эти два фреймворка, радостно нацепив на себя первое из многих когнитивных искажений при восприятии Канбан-метода.
Существуют и другие адаптации идей, описанных Андерсоном, под локальные контексты тренеров и консультантов. Ихосновной минус часто неглубокое понимание авторами предметной области, выливающееся в догматы, которые работают только при определенных условиях, и искажающее обывательское представление о мощи и применимости инструмента.
Плюсамитаких подходов является простота подачи, что может дать пару идей под конкретный контекст. Правда, не более.
Третий тип обучения, о котором я хочу поговорить, это обучение на практике. Этим занимаются практикующие консультанты, индивидуально работающие с конкретным продуктом, сервисом, командой или организацией.
Консультанты, владеющие в достаточной мере инструментами Метода, вытаскивают из набора практик только те, которые решают конкретные проблемы в конкретном процессе поставки.
Плюсытакого подхода прикладная польза для решения конкретных проблем.
Минусы в будущем проблемы могут быть другими и текущие практики не сработают.
Как выбрать свой путь в постижении Канбана? Для этого я бы рекомендовал сначала определиться с целью. Рассмотрим две крайности получить академические знания и решить проблемы в производстве.
Заакадемическими знаниямия отправляю на штатные тренинги Канбан-Университета, оговорившись, что путь этот долгий, дорогой и содержит в себе эволюцию восприятия метода по классической модели Данинга-Крюгера. Но другого пути я пока не знаю Метод развивается очень широко, описание материала в литературе запаздывает на несколько лет, и актуальную информацию можно получить только на тренингах Канбан-Университета и на профильных конференциях от практикующих специалистов.
За решением жепрактических проблемрекомендую обратиться к экспертам из сообщества канбан-практиков, благо русскоязычное сообщество очень открытое, с удовольствием обсуждает кейсы, и дает рекомендации как решить проблемы.
Кроме того, чтобы задатьфокус с чего начатьизучение для решения конкретной проблемы, ниже я структурирую типовые случаи и инструменты, которые в этих контекстах хорошо работают. Надеюсь, что это даст вам представление, как задать вопрос специалисту, чтобы не утонуть в потоке поступивших рекомендаций.
Иногда интерес к Методу возникает, когда нет прямого запроса на оптимизацию чего-то большого, то можно попробовать принципы Канбана поприменять для повышения личной эффективности.
Для такого интереса я бы рекомендовал познакомиться с термином персональный Канбан и попробовать разобраться как визуализировать свою личную работу, ограничить количество одновременных задач и помедитировать над принципомлучше три задачи сделать, чем десять потрогать.
Персональная канбан-доскаТакже, можно посмотреть на практики категоризации и приоритизации потоковой работы.
Под понятием отдел я подразумеваю управление некоторой функцией, которую реализуют люди. И если функция работает с потоком однотипных задач, реализуемых сотрудниками отдела по принципу одна задача = один специалист, то некоторые практики Канбана могут помочь сделать такую работу достаточно эффективной.
На какие практики я бы рекомендовал обратить внимание при такой работе?
Основная это, конечно, визуализация. Визуализация жизненного цикла задачи отдела. Здесь есть разные варианты визуализации работы, для начала можно обратить внимание на такие практики как агрегированный персональный Канбан или командный Канбан.
Агрегированный персональный КанбанПерсональные ограничения незавершенной работы (персональныеWIP-лимиты) тоже неплохо работают в виде ограничений на дорожки при агрегированном командном канбане или в виде аватарок при командном канбане.
Также, при визуализации работы рядом появляется необходимость обсуждать эту работу с тему, кто ее делает, и тут можно обратить внимание на практики проведения планерок.
Команда, в том виде, в котором этот термин понимаю я, понятие более широкое, чем отдел. Задачи, которые реализует команда, это уже не работа одного специалиста под ключ, но совместная работа нескольких человек, чтобы поставить ценность.
Отличительная особенность команды:
Общий результат
Общая оценка результатов работы
Размытие зон ответственности в смежные области для уменьшения точек передачи информации (в отличие, например, от при передаче её через функциональные отделы, где эта самая информация часто теряется)
Что можно рекомендовать команде использовать при управлении своей работой? Для начала, если команда пока не воспринимает себя единым целям, а культура диктует разделить работу на куски и передать по специалистам по принципу одна работа = один исполнитель, то начать можно с практики визуализации работы команды при помощи командного канбана с аватарками.
Для более зрелой команды, когда в коллективе есть уже понимание общего результата, а объектом управления выступает уже не элементарная задача, а нечто, что понимает Заказчик, можно использовать практики разделения потоков работ и визуализации правил командной работы. В частном случае сделать попытку оценить количество задач в работе (смотря глазами Заказчика когда он считает, что задача уже в работе) и ограничить это число с точки зрения не должно быть в системе задач, до которых у нас руки не дошли в предыдущий отчетный период почитать, что такоеCONWIP-ограничение.
Командная канбан-доскаУ командной работы, также, появляется предрасположенность к совместному обсуждению проблем в процессе и возможность улучшить свою работу. Введение практики регулярных ретроспектив помогает выстроить процесс совершенствования производства. (Да, да, это не ошибка ретроспектива тоже используется в Методе как одна из практик.)
Еще один взгляд на работу взгляд человека, который отвечает за развитие и вывод на рынок продукта. В современном мире такого человека называют Владельцем продукта. Мышление этого уровня уже предполагает менеджерский подход к управлению. Его должны волновать взаимодействия с потребителем, ответы на вопросы что нужно делать уже сейчас, что потом?, кому нужен продукт?, а то ли это, что нужно клиентам?, а удобно ли пользователям получать продукт в то время, когда мы поставляем, и в том виде?.
Для ответа на эти вопросы Владельцу продукта уже мало инструментов, которые показывают всего лишь динамику работы тех команд, которые задействованы в процессе реализации продукта. Здесь помогут практики визуализации всей цепи поставки и управление рисками задержек между командами, работающими в рамках цепи поставки.
Для определения цепи поставки уже стоит провести воркшопSTATIK(systemthinkingapproachtointroduceKanban, описан в книге Майка Барроуза Канбан-метод: улучшение системы управления)
Визуализация всего потока поставкиМенеджеру для широкого применения Канбан-методу, я уже рекомендую посетить первые два тренинга из основной линейки Канбан Университета, а также ответвлениеFitforPurpose, на которых обратить особое внимание на следующие инструменты:
Объект управления чем именно нужно управлять Владельцу продукта, чтобы процесс поставки ценности был управляем и контролируем
Группировка сходных типов работ (Фильтры, Цветовая дифференциация, Дорожки, Колонки)
Фокус на поставке и Визуализация прогресса поставки - как именно изобразить процесс поставки, чтобы Канбан-визуализация служила системой раннего предупреждения о проблемах с поставкой?
Управление рисками поставки. Проблема в поставке проблема менеджера, Метод дает широкий инструментарий для управления риском: визуализация блокировок; визуализация буферов и очередей; выявление источников проблем; ретроспективы и обзоры поставки
Upstream-процесс. Процесс поставки начинается не с написания Технического задания, а с некоего предпроцесса, когда идея потихоньку оформляется в задачу. Проверка гипотез и воронка опций вполне себе процессы, которыми можно управлять, используя инструменты Канбан-метода.
Метрики прогресса: T2MиLeadTime метрики, помогающие прогнозировать сроки; Fit for Purpose criteria продуктовыеметрики; пропускная способностьпроизводственной системы
Для менеджеров проектов существует огромное количество инструментов и методик для комфортного отражения хода проекта и управления им. Из Канбан-метода тоже можно взять некоторые практики, которые помогут Менеджеру улучшить управляемость.
Я бы Канбан-практики использовал для управления рамками проекта при выборе определенных параметров, например при использовании декомпозиции по элементам продукта, правильно настроенная визуализация поможет наладить эффективное производство продукта проекта. Ключевым здесь станет правильный выбор объекта управления и визуализация жизненного цикла его производства.
В отличии от жизненного цикла проекта на управлении которым акцентированы популярные средства управления проектами, Канбан-визуализация должна фокусироваться на жизненном цикле производства элемента продукта и отвечать (например для ИТ-проекта) на вопрос Что нужно сделать, чтобы вывести этот кусок функциональности в Продуктив?
Развивая тему управления проектами, сожно отметить, что Канбан-визуализация по этапам жизненного цикла проекта очень наглядно показывает, что происходит у нас с портфелем проектов. И, внедрив соответствующую визуализацию, можно обогатить смыслом процесс управления портфелем.
Портфельному менеджеру я бы рекомендовал обратить внимание на практики визуализации, коих очень много, чтобы настроить удобную систему раннего предупреждения о рисках проектов.
Почти все случаи, которые я описал выше, для решения своих насущных проблем могут обойтись ограниченными практиками, в них не обязательно погружаться глубоко в механики Канбана. Однако, начиная с менеджерского состава, который вовлечен в производство результатов умственного труда, я бы всем рекомендовал пройти три из четырех модулей Канбан Университета (KSD,KSI,KMM) и ответвлениеFitforPurpose. Причем, проходить их не подряд, а с промежутком на применение полученных знаний на практике, так как сама текущая механика обучения подразумевает прохождение эволюции восприятия инструментов Метода.
В одной статье, к сожалению, тяжело полноценно раскрыть все аспекты, которые я хочу донести до аудитории, но, на описанных выше примерах, надеюсь, я показал, как Канбан-метод может подобрать для каждого собственный подход и комплект тех практик, которые помогут сделать работу удобной и эффективной.
Удачи всем в совершенствовании собственной работы!
По Agile доступно огромное количество курсов. Кроме специализированных курсов по проектному управлению есть ещё сертификации.
Зачем получать сертификаты по проектному управлению? Существуют несколько причин:
Систематизировать ранее полученные знания.
Получить новые знания. Во время подготовки к сертификации вы можете обнаружить, что у вас существуют пробелы в знаниях, которые необходимо восполнить.
Проверить свои силы. Сертификация даст ответ насколько ты хорош.
Переход на новую должность или роль. Вы хотите получить знания, необходимые для выполнения новых обязанностей.
Повышение. Сертификаты повышают вашу стоимость в глазах работодателя.
Сертификаты можно разделить на три типа:
Перед подготовкой к сертификации вам нужно ответить для себя на несколько вопросов:
Для чего вам нужен сертификат?
Какую методологию/фреймворк вы используете или хотите использовать?
Какая у вас текущая или желаемая роль в компании?
ICAgile. После прохождения обучения вы можете получить международный сертификат. Тренинги от ICAgile достаточно известны и популярны. Получить сертификат достаточно просто: прослушал курс получи сертификат.
Карта трековОбучение проходит по 8 трекам плюс 1 бизнесовый блок.
В каждом треке есть 2 уровня. Прошёл обучение по каждому уровню получаешь статус по всему треку.
Обучение на каждом уровне длится в течение 3-х дней, много практики.
Сертификат
Сертификат пришлют в течение 4 недель после курса. Сертификат выдаётся бессрочно, продлевать не нужно.
Пример сертификатаПроверить сертификат на действительность можно по ссылке.
Стоимость обучения варьируется в зависимости от трека от 35 до 90 тысяч рублей. Стоимость курса включает выдачу сертификата. Ничего доплачивать не нужно.
Из плюсов:
Международный сертификат.
Разнообразие, можно прослушать курсы по нескольким направлениям: Agile, DevOps, опер блок.
Сертификат выдаётся бессрочно.
Из минусов:
Отсутствует экзамен. Человек, который старался, слушал курс, и человек, который просто присутствовал, равны.
PMI. Одна из самых сложных сертификаций. На экзамене понадобятся знания широкого круга методологий и фреймворков.
Треков нет.
Сертификат
Это одна из немногих сертификаций, до которой ещё необходимо допуститься.
Для получения доступа к экзамену потребуется:
Не менее 12 месяцев опыта управления проектами за последние 5 лет;
Не менее 8 месяцев управления Agile проектами за последние 3 года;
21 час обучения на любом курсе Agile (не обязательно аккредитованом).
Описание требований для доступа к экзамену. Курсов по подготовке к экзамену не так много.
Нужно быть готовым подтвердить информацию в анкете. Ваша заявка может попасть под аудит.
Сам экзамен состоит из 120 вопросов, большая часть вопросов ситуационные, основаны на практических кейсах. На экзамен отводится 3 часа. Критерий успешной сдачи не раскрывается, но, по слухам, составляет примерно 70 правильных ответов. Русский язык на экзамене пока ещё недоступен придётся сдавать на английском.
Пример сертификатаПроверить сертификат на действительность можно по ссылке.
Сертификат необходимо продлевать каждые 3 года. Для этого достаточно пройти 30 часов обучения на сертифицированных курсах. Подробная информация по ссылке.
Стоимость аккредитованных курсов от 1 до 200 тысяч рублей. Зависит от количества часов, страны и жадности провайдера курсов.
Из плюсов:
Одна из самых именитых компаний.
Необходимо сдать экзамен.
Из минусов:
Одна из самых сложных сертификаций.
Необходимо допуститься до экзамена.
Высокая стоимость экзамена (495 USD).
Экзамен доступен только на английском языке.
Нужно продлевать сертификат.
IAPM. Малоизвестный провайдер IAMP. Сертификация основана на стандарте AgilePM Guide 2.0. Стандарт включает инструменты и техники из нескольких фреймворков: Agile, Scrum, Kanban и других.
Ссылка на сам стандарт.
Карта трековК сертификации доступно 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. Компания была основана в 2002 году авторами The Scrum guide Джеффом Сазерлендом и Кеном Швабером. Сертификат от Scrum Alliance один из двух самых известных в мире сертифицирующих организаций по Scrum. О второй позже.
Карта трековВ 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. Компания Scrum.org была основана в 2009 году Кеном Швабером.
Карта трековДля сертификации доступно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.
Количество вопросов |
Критерий сдачи |
Продолжительность экзамена |
Стоимость |
|
PSM1 |
80 вопросов |
85% |
60 минут |
150 USD |
PSM2 |
30 вопросов |
85% |
90 минут |
250 USD |
PSM3 |
30 вопросов + эссе |
85% |
150 минут |
500 USD |
Сдать экзамен и получить сертификат можно и без прохождения курсов.
Для получения любой ступени не требуется наличие предыдущей. Вы можете сразу получить сертификацию PSM3, минуя предыдущие ступени.
Стоимость обучения составляет порядка 50-80 тысяч рублей за 1 ступень, включая взнос за экзамен и 2 попытки.
На сайте scrum.org доступно бесплатное тестирование, которое может пройти любой желающий. Сертификата не дадут, но можно понять уровень подготовки.
Из плюсов:
Всемирно известная компания.
Необходимо сдать экзамен.
Сертификат не нужно продлевать.
Из минусов:
Экзамен доступен только на английском языке.
Kanban University. Сертификация проходит аналогично ICAgile, прослушал курс получи сертификат. Для сертификации доступно 5 треков.
Карта трековTeam Kanban Practitioner это однодневный курс для тех, кто хочет познакомиться с Kanban.
Чтобы получить Kanban Management Professionalнеобходимо пройти обе ступени KMP1 и KMP2.
Треки Management, Coaching, Consultant и Trainer подойдут для тех, кто планирует стать тренером или коучем по Kanban.
Сертификат
Пример сертификатаПроверить сертификат можно по ссылке.
Обучение проходит в течении 1-2 дней, зависит от трека. Стоимость составляет порядка 25-50 тысяч рублей за одну ступень.
Из плюсов:
Международный сертификат.
Сертификат выдаётся бессрочно.
Из минусов:
Отсутствует экзамен.
Фреймворки/ методологии/ итд |
Основные роли |
Сертифицированные тренинги |
Стоимость, руб |
Нужно ли продлять сертификат |
Язык сертификации |
|
Agile DevOps |
Product manager Project manager Team role Coach |
35-90 тыс руб |
нет |
Рус |
||
Agile |
Project manager |
От 1 тыс руб + 475 USD за экзамен |
175 USD 30 PDUs |
Англ |
||
Agile |
Project manager |
По запросу |
нет |
Англ |
||
Scrum |
Scrum master Product owner Developer Trainer Coach |
65 тыс руб |
50-250 USD 10-40 SEUs |
Англ |
||
Scrum Kanban |
Scrum master Product owner Developer Coach |
50-80 тыс руб (включая плату за экзамен) |
Нет |
Англ |
||
Kanban |
Team member Manager Consultant Trainer Coach |
25-50 тыс руб |
нет |
Рус |
Нет плохих или хороших сертификаций по проектному управлению. Сертификаты востребованы у работодателей т.к. позволяют отсеять людей при найме.
Кроме наличия необходимых знаний международный сертификат показывает работодателю что:
Ты целеустремлён и знаешь чего хочешь, т.к. потратил время на подготовку и получение сертификации.
Ты стремишься развиваться и получать новые знания.
Ты знаешь теорию достаточно, чтобы пройти все испытания.
Если есть опыт в получении сертификаций и желание поделиться им, напишите, пожалуйста, в ЛС.
А если я упустил какую-либо информацию, напиши в комментарии. Я обязательно её добавлю.
Привет, Хабр!
На связи команда JetBrains YouTrack, и у нас для вас новый релиз! Мы дополнили интеграцию с GitLab теперь YouTrack не только отслеживает коммиты и merge-реквесты, но и поддерживает интеграцию с GitLab CI/CD. А это значит, что задачи в YouTrack смогут обновляться автоматически по результатам автоматизированных сборок в GitLab CI/CD. Также мы дополнили релиз интересными улучшениями для работы с задачами. За подробностями добро пожаловать под кат!
Непрерывная интеграция и развертывание (CI/CD) были придуманы, чтобы упростить жизнь разработчикам. Благодаря CI/CD вы можете не беспокоиться о том, что ваш код навредит проекту или сломает его, а самое главное вам больше не нужно проверять это вручную.
Как это работает? CI/CD периодически забирает новый код из системы контроля версий (VCS), собирает проект, прогоняет автотесты и разворачивает собранную и протестированную версию, например на сервере, где тестировщики смогут провести остальные этапы тестирования. Если что-то упало, CI/CD сообщит об этом кому нужно, например техлиду проекта или разработчику, который сделал злосчастный коммит.
YouTrack уже давно позволяет интегрировать в процесс управления задачами TeamCity и Jenkins, а теперь к ним присоединился и GitLab CI/CD.
GitLab CI/CD работает с конвейерами (пайплайнами), каждый из которых состоит из ряда заданий (jobs). При появлении изменений в коде GitLab CI/CD выполняет соответствующие задания из пайплайна, чтобы убедиться, что новый код ничего не сломал. Если задание в пайплайне выполнено успешно, GitLab делится этой радостью с YouTrack, который в свою очередь обновляет нужные задачи.
Как именно обновляет? Как скажете! Например, YouTrack может автоматически помечать задачи, упомянутые в сообщении коммита, как завершенные и прописывать в задаче номер пайплайна и ссылку на него. Как обычно, вы можете завязать на интеграцию рабочие процессы (например, указать, чтобы при изменении значения поля Fixed build на странице задачи появлялся комментарий о том, что фикс доступен в продакшене).
Мы внесли ряд улучшений в YouTrack Lite и Classic. В YouTrack Lite появилась функция Похожие задачи, которая позволяет избежать дублирования задач. Когда при создании задачи вы вводите ее название, YouTrack ищет задачи со схожим названием и предлагает вам просмотреть их и убедиться, что новая задача их не дублирует. В YouTrack Classic мы добавили удобный текстовый редактор такой же, как в базе знаний и в YouTrack Lite. Теперь вы можете одним щелчком переключаться между режимом разметки и режимом WYSIWYG, встраивать мультимедийные объекты, создавать таблицы и контрольные списки.
Помимо этого, мы внесли небольшие изменения в текущую схему разрешений. Также напоминаем, что со следующей мажорной версии YouTrack перестанет поддерживать устаревший REST API.
Лучше один раз увидеть, чем сто раз прочитать. Напомню, что YouTrack со всеми его новшествами можно попробовать бесплатно. Мы будем рады вашей обратной связи!
Команда YouTrack
MES-системы, мониторинг оборудования, платформенные стратегии, программирование роботов, сложные производственные системы все это имеет ключевое значение для отрасли, для повышения эффективности производства, цифровизации промышленности. Это важно для профессионалов, которые не просто говорят о цифровизации, а делают ее своими руками.
Об одном из показательных примеров - о совместном решении Dassault Systemes и ГК Цифра - рассказал старший технический специалист компании Dassault Systemes Дмитрий Лопаткин. Группа компаний Цифра разрабатывает и внедряет платформенные решения на основе промышленного искусственного интеллекта и интернета вещей, а также развивает индустрию роботизированного промышленного транспорта.
"Допустим, обеспечена возможность подключения и сбора данных с промышленного оборудования и работы с этими данными. Какой необходимо сделать следующий шаг? спрашивает Дмитрий Лопаткин. ИТ - это всего лишь инструмент, который помогает решать задачи бизнеса, увеличивающий операционную эффективность.
Если говорить о программном продукте для оперативного управления производством компании Dassault Systemes - DELMIA Apriso и его архитектуре, то на его самом нижнем уровне лежит собственная, встроенная платформа управления бизнес-процессами Process Builder. И это единственный обязательный реквизит, необходимый для внедрения подобных систем. Именно здесь описываются все производственные процессы, входящие в контур цифровизации. Помимо самих процессов прописываются все интерфейсы подключения к оборудованию через системы автоматизации или непосредственно подключение бизнес-систем, таких как ERP. На эти бизнес-процессы наслаиваются функциональные модули, которые могут применяться на пользователями из различных производственных дисциплин: контроль качества, склады, ТОиР, декларация производства. Это те элементы, с которыми взаимодействует конечный пользователь оператор ЧПУ, плановик, сотрудники логистической или ремонтной службы и пр.".
Решение DELMIA Apriso способно полностью поддержать все производственные процессы, но это не всегда необходимо, так как есть существующие системы, есть задачи и цели каждого отдельного предприятия. Сначала оценивается зрелость производственных процессов, потом дается экспертное заключение о том, что можно в первую очередь автоматизировать, на что нужно обратить внимание, чтобы получить наибольший эффект. Этот эффект можно посчитать и оценить с точки зрения экономики.
Информация, которая обрабатывается различными функциональными приложениями, основывается на описанных ранее бизнес-процессах. Каким образом происходит работа с бизнес-процессами? Сначала описываются все бизнес-процессы, которые требуется автоматизировать. Они картируются и заносятся в программное обеспечение.
В ПО Process Builder бизнес-процессы описываются в графическом интерфейсе. Для каждой функциональной области используется набор стандартных бизнес-компонентов. В библиотечные каталожные компоненты в интерфейсе заносятся те значения, которые должны быть получены с оборудования они получаются автоматические или вводятся оператором вручную. Также описывается входная и выходная информация на каждом шаге процесса. Таким образом, описывается, как "живёт" предприятие, как оно функционирует.
Описывается не только информация в рамках производственных процессов, но и взаимодействия с вышестоящими и нижестоящими системами в архитектуре, то есть с уровнем автоматизации, либо с учетными системами. Одно из преимуществ такой системы моделирования бизнес-процессов - это поддержка всего жизненного цикла бизнес-процесса, от его разработки, внедрения и до масштабирования на предприятии.
Также можно моделировать, как себя будет вести процесс "в реальной жизни" - ещё до его запуска в производство. С точки зрения конечного пользователя эти изменения не видны, то есть, если в процесс внесены какие-то улучшения или усовершенствования в рамках BPM-платформы, то пользователь не увидит изменений, которые произошли в бизнес-процессах. Такая интеграция и возможность работы с процессами рамках инструмента Process Builder позволяет постоянно улучшать процессы, то есть можно сделать какое-то изменение, чтобы посмотреть, как это выглядит в реальной жизни, получить обратную связь от производства, оценить такие показатели как объем производства, выявить "узкие места" или внести изменения в процесс системы управления производством.
Изменение процесса позволяет моделировать процессы и изменять систему управления производством. Также в рамках инструмента Process Builder создается не только модель процесса, но и пользовательские интерфейсы, определяющие, как пользователи на каждом этапе процесса будут взаимодействовать с системой. Поддерживаются различные пользовательские интерфейсы: мобильные устройства, информационные киоски, персональные компьютеры, считыватели штрих-кодов и так далее. Всё зависит от того, какова роль пользователя, или какую функцию он выполняет в производственном процессе.
Ещё одно преимущество такого процессного подхода: с помощью BPM-платформы можно выделить наиболее эффективный для производства набор стандартных процессов и затем их масштабировать. Например, для распределенного производства - выделить процессное ядро (core), и быть уверенным в том, что любая производственная площадка, независимо от того, где она находится территориально, функционирует по стандартизированным и унифицированным бизнес-процессам.
Как и во многом другом, главное - найти баланс, "золотую" середину между уникальностью каждой производственной площадки и применяемыми лучшими стандартными корпоративными практиками. Если производственная площадка работает по своим уникальным процессам, не факт что применяется наиболее оптимальный/эффективный подход, но и при внедрении практик необходимо учитывать особенности производственной площадки: планировку, различные типы оборудования, логистику и прочее. Поэтому рекомендуется комбинировать процессы в соотношении 70/30: 70 стандартных и 30 локальных, или 80/20.
Помимо того, что все предприятия могут использовать стандартизированные процессы, такой подход с core-решением позволяет ещё и быстро масштабировать систему. То есть в рамках проекта разрабатываются core-решения, основные процессы, всё это тестируется, запускается первая пилотная площадка, и там делается несколько итераций это стандартный процесс внедрения любой системы. Идет обкатка с ключевыми пользователями.
После этого можно масштабировать систему на другую площадку или другое бизнес-подразделение. Для площадки устанавливаются 80% уже готовых процессов, после чего нужно только описать 20% уникальных для нее процессов, либо определить какие-то дополнительные интерфейсы, если там есть какое-то своё, нестандартизированное оборудование.
Что даёт такой подход с точки зрения информационных технологий? Во-первых, это высокая скорость внедрения. Обычно 60%-70% времени тратится на разработку основного решения (core), а дальнейшее внедрение требует уже незначительного времени. Например, на подключение новой производственной площадки уходит 2-3 недели, что по меркам систем управления производством очень малый срок.
Такой подход нашел отклик у заказчиков, особенно у глобальных и географически распределенных компаний. В рамках одной системы они могут контролировать и стандартизировать бизнес-процессы предприятия, получать информацию о каждой конкретной производственной единице, о том, что и как делается в конкретный момент времени.
Например, данный подход использовался для интеграции с решениями компании "Цифра". Изначально это был небольшой процесс, начинающийся с производственного заказа. В данном случае производственный заказ состоит из трех операций. Первая из них выполняется на оборудовании, имеющему свой АРМ.
Оператор данного обрабатывающего центра видит всю необходимую технологическую информацию, связанную с операцией, которую он должен сделать, и начинает выполнять эту операцию на своём станке. После выполнения операции это декларируется в системе, и информация отправляется в DELMIA Apriso - систему управления производством.
Зная, что данная операция выполнена, Apriso начинается "толкать" к выполнению следующей операции - далее по маршруту следующему обрабатывающему рабочему центру. Там оператор также получает уведомление о том, что он должен выполнить, заходит в свой рабочий интерфейс, декларирует начало операции, выполнение операции. Фактическое время её выполнения заносится в систему управления производством.
Третья операция - операция сборки. У оператора на сборке своя задача и свои потребности: он хочет видеть весь процесс детально. Он проходит обязательный контроль соблюдения мер безопасности. Эта информация в рамках системы контроля качества сохраняется в системе управления производством Apriso. Каждый индивидуальный использованный материал и полуфабрикаты также заносятся в систему управления производством и добавляются в генеалогию изделия.
Рабочие инструкции, созданные ранее, на этапе технологической подготовки производства становятся доступны оператору на его персональном АРМ -непосредственно на рабочем месте и в различных форматах: чертежи, отсканированные pdf-файлы, или в виде 3D модели, как представлено ниже.
Начальник цеха, начальник участка получают возможность мониторинга фактического состояния оборудования и хода выполнения производственных заказов, а также любого производственного показателя благодаря настроенному информационному окну (дашборду). Вся информация, доступная оператору станка, также доступна начальнику участка в рамках мониторинга состояния всего участка. В DELMIA Apriso видна информация с оборудования разного типа, а также информация по количеству дефектов, энергопотреблению, состоянию и так далее.
Если оператор, который изготавливает детали, понимает, что у него произошла нештатная ситуация, например, повредился режущий инструмент, то он переводит свое оборудование в состоянии простоя. Эта информация моментально отображается у других участников основного и вспомогательного производственного процесса, в нашем примере, - у начальника службы главного механика, который, в свою очередь, может её проанализировать и создать в наряд-заказ на проведение ремонтных работ, куда он заносит необходимую дополнительную информацию, срочность, даты выполнения этого наряд-заказа и прочее.
Вновь созданный наряд-заказ на проведение работ необходимо встроить в производственное расписание и оптимизировать его с учетом сложившейся ситуации.. Этим занимается цеховой диспетчер, который получил уведомление о новом наряд-заказе. Он включает новую информацию в существующий график производства и может использовать полноценный функционал оптимизации или пересчёта производственного расписания.
Такой достаточно простой сценарий демонстрирует пример того, как может происходить взаимодействие специалистов различных дисциплин в рамках одного бизнес-процесса. Таким же образом может осуществляться взаимодействие со складскими службами, службами по комплектованию, контролю качества и так далее, то есть охватываются все смежные процессы.
Преимущество такого решения в том, что оно позволяет собирать информацию c оборудования компании "Цифра". Есть система контроля процессов. Такой совместный подход дает большую синхронизированность работы всех производственных служб, увеличение эффективности использования оборудования и гибкости производства в целом. Всегда можно оперативно отреагировать на изменения, которые требует ситуация на рынке. Решение DELMIA Apriso обеспечивает глобальное управление процессами, контроль производительности, визуализацию и тщательный анализ влияния функциональных улучшений на всех производственных площадках в рамках предприятия.
Стоит отметить, что в одном из реализованных проектов внедрения системы управления производством Dassault Systemes ею пользуются 28 подключённых предприятий. Для реализации подобного проекта требуется от 9 месяцев. С учётом сложности процессов внедрения это очень хороший результат.
Заинтересовала данная тематика?
Смотрите запись технической онлайн-конференции для машиностроительной отрасли, в рамках которой участникам была предоставлена возможность ознакомиться с преимуществами использования ключевых решений компании для цифровой трансформации предприятий.
Познакомьтесь с материалом "Системы управления производством и производственными операциями и современные вызовы".
Узнайте больше о продуктах DELMIA на официальном сайте компании
TLDR: крохотные модельки обошли модные графовые
нейронки в предсказании свойств молекул.
Код:
здесь. Берегите Природу.
ФОТО: Андерс Хеллберг для Wikimedia Commons, модель Грета
Тунберг
Необученная графовая свёрточная нейронная сеть [1] (uGCN) со случайной инициализацией весов уже пару лет занимает первое место в моём списке алгоритмов для задач машинного обучения на графах из-за копеечной стоимости, простоты реализации, да вполне очевидной элегантности решения. В то же время, насколько мне известно, никто ещё не не проводил соревнований между этой простой моделью и её старшей сестрой полноценно обученной графовой свёрточной нейронной сетью (GCN) в режиме обучения с учителем. Вот я сделал.
Мотивация: показать, что uGCN выдаёт качественные представления, которые можно использовать в последующих задачах машинного обучения в индуктивном режиме, когда модели обобщаются к не виденным ранее данным (вдохновлено недавним отчётом [2] о производительности простых моделей в трансдуктивном случае).
Полученные результаты занимательны. В худшем случае простые модели (uGCN + degree kernel + random forest) показали счёт 54:90 против полноценно обученных GCN, в то время как реалистичный сценарий закончился разгромным реваншем 93:51, указывающим на то, что мы можем позволить себе почти бесплатные эмбеддинги, которые превосходят или показывают результаты на уровне полноценно обученных GCN в задаче предсказания свойств графа (например эффекта медикаментов: яд или лекарство) за долю стоимости. Простые модели обучались ~10 минут в то время как весь эксперимент продлился ~4 часа. Перейдём же к деталям и разберёмся с тем, что произошло!
Многие из важных наборов данных об окружающем нас мире имеют связный характер: социальные сети, графы знаний, взаимодействия белков, всемирная паутина WWW и т.д. (просто несколько примеров) [1].
Граф, обыкновенно записываемый как G=(V, E) это математическая модель, множество множеств, состоящее из набора вершин V и множества рёбер E попарных связей e(i, j) между вершинами i и j. Расширением Графа является модель Граф со Свойствами (Labeled Property Graph), позволяющий задать вектор признаков xi для вершины i (мы также можем определять свойства для рёбер, однако это выходит за рамки сегодняшнего эксперимента). Графовая нейронная сеть [3] (GNN) это модель машинного обучения (параметрическая функция, которая подбирает, другими словами выучивает, параметры из данных), расширяющая возможности хорошо известного семейства алгоритмов, вдохновлённых биологией, до работы с неструктурированными данными в виде графов. На мой взгляд, передача сообщений это самая простая интуиция для понимания механики работы GNN и вполне оправдано обратиться к мнемоническому правилу 'скажи мне, кто твой друг и я скажу тебе кто ты'. Графовые свёрточные нейронные сети (GCN) очень подробно описал их изобретатель здесь (https://tkipf.github.io/graph-convolutional-networks/) и мне, право, непросто что-то ещё добавить к этой замечательной истории.
Дабы не заниматься самоцитированием, предложу читателю ознакомиться с рассказом о том, где и как врубиться в эмбеддинги графов, а также с примером использования GCN в структурном моделировании организационных изменений и ощущениях стейкхолдеров во время кадровых перестановок, неизбежных при внедрении больших информационных систем, вроде SAP. Эти два текста стоит воспринимать как первые главы повествования о методах анализа связанных систем, также там в деталях рассматривается используемая форма математической записи.
Многослойная GCN с фильтрами первого порядка.
Проведём серию экспериментов на общедоступных данных. Мы обратимся к (i) коллекции TUDatasets [4] и (ii) ограничим наше упражнение задачей бинарной классификации (предсказанием свойств) небольших молекул. Ещё одним условием нашего мероприятия будет (iii) использование графов с признаками вершин.
Заданные ограничения оставляют нам несколько наборов данных, широко используемых для сравнения современных алгоритмов. Вот наш итоговый список: AIDS, BZR, COX2, DHFR, MUTAG и PROTEINS. Все обозначенные наборы данных доступны как часть Pytorch Geometric [5] (библиотека для глубокого обучения на графах) в двух версиях: оригинальной и очищенной от дубликатов [6]. Итого у нас будет 12 датасетов.
Результаты экспериментов по выявлению химических соединений, негативно влияющих на вирус иммунодефицита человека. Представляет собой результат тестирования и химическую структуру соединений не покрытых соглашениями о неразглашении. В оригинальном наборе содержится 2000 молекул, а очищенная версия оставляет нам 1110 точек данных, каждая из которых представляет собой граф, вершины которого описывают 37 признаков.
Оригинальный набор содержит 405 молекул, очищенная версия 276, по 35 признаков на вершину.
Оригинальный набор содержит 467 молекул, очищенная версия 237, по 35 признаков на вершину.
Оригинальный набор содержит 756 молекул, очищенная версия 578, 35 признаков на вершину.
В наборе содержится 188 химических соединений, разделённых на два класса согласно их мутагенному воздействию на бактерии. В очищенной версии 135 молекул, 7 признаков на вершину.
Энзимы и не-энзимы. В оригинальном наборе содержится 1113 молекул, по 3 признака на вершину. Очищенная версия 975 структур.
Мы устроим турнир!
Для каждого набора данных проведём 12 раундов обучения и тестирования.
В каждом раунде:
(1) псевдослучайным образом разделим данные в пропорции 80/20 в Pytorch Geometric (начиная со стартового параметра генератора random seed = 42 и увеличивая его на единицу в каждом последующем раунде), таким образом 80% точек данных (графов) будут использованы в качестве обучающей выборки, а оставшиеся 20% будут тестовой выборкой;
(2) обучим модели и оценим долю верных ответов (accuracy) на тесте.
Для простых моделей это значит предобработку для того, чтобы создать признаки, на которых будет обучен классификатор.
Для GCN мы проводим 200 эпох обучения и тестирования со
скоростью обучения learning rate = 0.01 и принимаем во
внимание:
(А) среднее значение доли верных ответов для 10 финальных эпох
обучения реалистичный сценарий;
(В) наибольшее значение доли верных ответов, достигнутое в процессе
обучения (как если бы мы сохраняли промежуточное состояние для
того, чтобы выбрать наилучшую модель впоследствии) наилучший
сценарий для GCN (и наихудший для простых моделей);
(3) лучшей модели присуждается 1 балл;
(4) в случае ничьей балл присуждается лёгкой модели.
Всего будет распределено 288 баллов: 12 датасетов 12 раундов 2 сценария.
Degree kernel (DK) или степенное ядро гистограмма степеней вершин (количество рёбер, соединённых с вершиной), нормированная к числу вершин в графе (таким образом вектор признаков для каждого графа состоит из размеров долей вершин с количеством связей, равным индексу признака, от всего множества вершин в сумме они дают единицу).
import networkx as nximport numpy as np from scipy.sparse import csgraph# g - граф формате популярной библиотеки NetworkXnumNodes = len(g.nodes)degreeHist = nx.degree_histogram(g)# нормализуемdegreeHist = [x/numNodes for x in degreeHist]
Необученная графовая свёрточная нейронная сеть (uGCN) со случайной инициализацией весов 3 слоя с промежуточной нелинейной активацией (ReLU, т.е. f(x) = max(x, 0)). Аггрегация усреднением полученных после прямого прохода 64-разрядных векторов (эмбеддинги вершин) позволяет получить компактное представление графа. Это на самом деле очень просто.
A = nx.convert_matrix.to_scipy_sparse_matrix(g)
Воспользуемся вариантом реализации одного слоя свёртки в три строки, который пару лет назад предложил iggisv9t :
# A - матрица связности графа# X - матрица признаков вершин (np.array)D = sparse.csgraph.laplacian(A, normed=True)shape1 = X.shape[1]X = np.hstack((X, (D @ X[:, -shape1:])))
(код здесь приводится чтобы подчеркнуть очаровательный минимализм реализации метода)
Разберём его на части и пересоберём заново.
Использованная реализация uGCN выглядит так:
# A - матрица связности графа# X - матрица признаков вершин (np.array)# W0, W1, W2 - случайным образом инициализированные весаD = sparse.csgraph.laplacian(A, normed=True)# слой 0Xc = D @ X @ W0# ReLUXc = Xc * (Xc>0)# конкатенация признаков вершин с аггрегированной информацией соседейXn = np.hstack((X, Xc))# слой 1Xc = D @ Xn @ W1# ReLUXc = Xc * (Xc>0)Xn = np.hstack((Xn, Xc))# слой 2 - эмбеддинги вершинXc = D @ Xn @ W2# аггрегация усреднением - эмбеддинг графаembedding = Xc.sum(axis=0) / Xc.shape[0]
Комбинация DK и uGCN (Mix) конкатенацией представлений графа, полученных с помощью моделей DK и uGCN.
mix = degreeHist + list(embedding)
Для каждой из первых трёх моделей обучаем классификатор случайный лес из 100 деревьев с максимальной глубиной в 17 ветвлений.
Графовая свёрточная нейронная сеть (GCN) полноценно обученный классификатор, состоящий из 3 свёрточных слоёв размерностью 64 с промежуточной нелинейной активацией (ReLU), агрегацией усреднением (до этого момента архитектура GCN очень похожа на uGCN), за которой следует слой регуляризации дропаутом (произвольным обнулением разрядов с вероятностью 50%) и линейный классификатор. Мы будем обозначать результаты модели, отобранные в наилучшем для GCN сценарии (B) как GCN-B, а модели в реалистичном сценарии (А) как GCN-A.
После 144 раундов (12 датасетов * 12 раундов) сравнения качества предсказаний на отложенной выборке между простыми моделями и полноценно обученными графовыми свёрточными сетями 288 баллов распределились как:
Доля верных ответов на тестовых выборках варьировалась между раундами и частенько случались ситуации, в которых простые модели доминировали над более сложными противниками.
Наборы данных, в которых простые модели побеждают: AIDS, DHFR(A) и MUTAG.
Например, DK собрала все 48 баллов для набора данных AIDS, демонстрируя отрыв более чем на 10% (абсолютное значение) от доли верных ответов полноценно обученной GCN.
Здесь побеждают GCN: BZR, COX2 и PROTEINS.
Индивидуальный зачёт:
90 GCN-B;
71 DK;
55 Mix (uGCN + DK);
51 GCN-A;
21 uGCN.
Достаточно подробный протокол соревнований приведён в блокнотике с кодом, таблица с результатами раундов здесь.
В целом, результаты стабильно варьировались между очищенными и оригинальными наборами данных. Это ещё раз напоминает о важности качества данных для проведения адекватных сравнений между моделями. Хорошая новость в том, что в исследовательском сообществе уже есть движение в данном направлении и значительные усилия лучших умов в области уже направлены на организацию честных турниров.
Как видим, проведенный эксперимент подтверждает предположение о том, что в задаче предсказания свойств молекул мы можем позволить себе использовать почти бесплатные эмбеддинги, которые превосходят или показывают результаты на уровне полноценно обученных нейронных сетей. Наблюдения согласуются с вдохновляющими этот эксперимент результатами [2] в том, что концептуально метод Label Propagation очень похож на передачу сообщений в графовой свёрточной нейронной сети. Объяснение эффективности скорее всего следует искать в том, что на самом деле мощнее подбирать параметры фильтров для того, чтобы внутренние представления, выученные сетью стали линейно разделимыми, либо же просто использовать классификатор помощнее, как это сделано в рассмотренном примере.
Дисперсия результатов между раундами соревнования напоминает о том, что всякое сравнение дело непростое. Здесь стоит упомянуть Free Lunch Theorem и напомнить о том, что использовать сразу несколько моделей в построении решения скорее хороший тон. Также важно отметить влияние разбиения на выборки в ходе сравнения на одном и том же наборе данных одна и та же модель может показывать очень разное качество. Поэтому сравнивая модели, убедитесь, что обучаете и тестируете их на идентичных выборках. К слову, фиксация параметров генератора псевдослучайных чисел не панацея
Дальнейшими шагами может быть сравнение производительности моделей в рамках наборов данных больших размеров. Также стоит проверить результаты и в других задачах, таких как: предсказание связи, классификация вершин, регрессия на графах, и прочих графовые нейронные сети (как обученные, так и просто так) на многое способны.
В лекции открытого курса по графам знаний GCN названа Королевской Лазейкой Через Пространство Фурье, этот ярлык приклеился с тех пор, когда впервые выступил на публике с рассказом о силе графов и провёл первые эксперименты с классификацией картинок (как графов) для того, чтобы продемонстрировать мощь спектральных фильтров одной юной леди, запускавшей стартап в милой моему сердцу аэрокосмической области. Данная заметка появилась в результате того, что пару недель назад в реальной задаче на закрытых данных uGCN, вместе с простенькими моделями показали результат, который полноценно обученные GCN смогли превзойти всего на 2% (96 против 98) и мне вздумалось проверить вопрос о том, кто кого заборет ещё на каких-нибудь данных.
В наши дни машинное обучение на графах превратилось в знаменитость, всё больше исследователей обращают внимание на эту область и новые архитектуры графовых нейронных сетей появляются каждую неделю. Однако на самом деле мы ещё не очень хорошо понимаем почему GNN так успешны и нужны ли они для хорошего качества решения [2].
Перед тем, как ступать на очаровательный путь машинного обучения на графах, пожалуйста ознакомьтесь с основами этого дела. Значительные усилия прилагаются к тому, чтобы сделать новейшие достижения (да и классические методы тоже) доступными широкой аудитории совершенно бесплатно. Упомяну лишь несколько из таких инициатив: материалы и лекции стенфордского cs224w, площадку для тестирования качества алгоритмов Open Graph Benchmark [14] и недавнюю работу об основах геометрического глубокого обучения [15] методологию разработки новых архитектур нейронных сетей. Напоследок, ещё раз напомню о том, что начинать проекты машинного обучения стоит с простых методов, вроде ядер и необученных графовых свёрточных сетей достаточно часто эти модельки показывают неприлично хороший уровень.
Берегите Природу, используйте алгоритмы эффективно. Порою неученье сила.
[1] Kipf & Welling, Semi-Supervised Classification with Graph
Convolutional Networks (2017), International Conference on Learning
Representations;
[2] Huang et al., Combining Label Propagation and Simple Models
out-performs Graph Neural Networks (2021), International Conference
on Learning Representations;
[3] Scarselli et al., The Graph Neural Network Model (2009), IEEE
Transactions on Neural Networks ( Volume: 20, Issue: 1, Jan.
2009);
[4] Morris et al.,TUDataset: A collection of benchmark datasets for
learning with graphs (2020), ICML 2020 Workshop on Graph
Representation Learning and Beyond;
[5] Fey & Lenssen, Fast Graph Representation Learning with PyTorch
Geometric (2019), ICLR Workshop on Representation Learning on
Graphs and Manifolds;
[6] Ivanov, Sviridov & Burnaev, Understanding isomorphism bias in
graph data sets (2019), arXiv preprint arXiv:1910.12091;
[7] Riesen & Bunke, IAM Graph Database Repository for Graph Based
Pattern Recognition and Machine Learning (2008), In: da Vitora
Lobo, N. et al. (Eds.), SSPR&SPR 2008, LNCS, vol. 5342, pp.
287-297;
[8] Sutherland et al., Spline-fitting with a genetic algorithm: a
method for developing classification structure-activity
relationships (2003), J. Chem. Inf. Comput. Sci., 43,
1906-1915;
[9] Debnath et al., Structure-activity relationship of mutagenic
aromatic and heteroaromatic nitro compounds (1991), J. Med. Chem.
34(2):786-797;
[10] Dobson & Doig, Distinguishing enzyme structures from
non-enzymes without alignments (2003), J. Mol. Biol.,
330(4):771783;
[11] Pedregosa et al., Scikit-learn: Machine Learning in Python
(2011), JMLR 12, pp. 2825-2830;
[12] Waskom, seaborn: statistical data visualization (2021),
Journal of Open Source Software, 6(60), 3021;
[13] Hunter, Matplotlib: A 2D Graphics Environment (2007),
Computing in Science & Engineering, vol. 9, no. 3, pp. 90-95;
[14] Hu et al., Open Graph Benchmark: Datasets for Machine Learning
on Graphs (2020), arXiv preprint arXiv:2005.00687;
[15] Bronstein et al., Geometric Deep Learning: Grids, Groups,
Graphs, Geodesics, and Gauges (2021), arXiv preprint
arXiv:2104.13478.
Привет Хабр!
В командах разработки трекеры задач и IDE редко существуют друг без друга. Поэтому мы решили существенно проапгрейдить плагин YouTrack для IDE на платформе IntelliJ. Плагин интегрируется с вашими любимыми IDE от JetBrains AppCode, CLion, DataGrip, GoLand, IntelliJ IDEA, PhpStorm, PyCharm, Rider, RubyMine и WebStorm, а также с Android Studio и дает вам доступ ко всем задачам и уведомлениям прямо из IDE. Также с помощью плагина стало удобнее вести учет времени. Для него появилось несколько режимов теперь вы сможете сосредоточиться на написании кода и не тратить время на отчетность. Ниже расскажу обо всем подробнее.
Командам, которые используют в работе баг-трекеры, часто нужен доступ к задачам прямо по ходу написания кода в IDE: например, чтобы добавить к текущей активной задаче поясняющий комментарий, изменить ее приоритет, и просто чтобы быть в курсе любых изменений. Плагин YouTrack не только решает эту проблему, но и заботится о процессе учета времени, помогая синхронизировать работу в IDE с записями о затраченном времени в задачах YouTrack.
Плагин отображает список задач, актуальных для вас прямо сейчас. Это может быть ваш личный бэклог, задачи к предстоящему релизу, технический долг. Список можно в любой момент изменить, выведя на первый план актуальные задачи. Вы можете обновлять задачи прямо из IDE: добавляйте комментарии, выполняйте команды и меняйте статус все это позволит держать команду в курсе прогресса. Кроме того, плагин позволяет получать в IDE уведомления об изменениях в задачах (те же, что вы получаете по почте) и наоборот создавать новые задачи в YouTrack всего за пару кликов, предварительно выделив нужный кусок кода в IDE.
Команда YouTrack придерживается простого правила: для каждого изменения в коде должна быть соответствующая задача в баг-трекере. Это помогает понять, кто чем занят, и обеспечивает прозрачность процесса разработки. Кодовая база со временем растет, но мы всегда знаем, почему был добавлен или изменен тот или иной кусок кода, какую проблему это позволило решить и насколько безопасно дальнейшее редактирование этого кода. Кроме того, соответствующую задачу мы упоминаем в сообщениях коммита: сами по себе сообщения коммита не всегда бывают информативными, зато упоминание соответствующей задачи существенно добавляет контекста. Кстати, интеграция YouTrack с VCS позволяет отслеживать коммиты с упоминанием задач и привязывать их к этим задачам. В результате страница задачи демонстрирует все этапы разработки зайдя на нее, вы получите всю необходимую информацию.
Получается, какой бы код мы ни писали, где-то в YouTrack есть задачка, которая поясняет, зачем нужен этот код и какую проблему он решает. Чтобы не приходилось синхронизировать код с задачами вручную, плагин YouTrack позволяет выбрать текущую активную задачу и привязать к ней все дальнейшие действия. Затраченное на код время будет также автоматически записываться в активную задачу.
Вообще, плагин позволяет вести учет затраченного времени несколькими способами об этом сейчас расскажу подробнее.
Включив автоматический режим, вы можете забыть о таймерах. Плагин зарегистрирует каждую минуту вашей работы, учтет время активности в IDE и автоматически зафиксирует затраченное время в YouTrack. Обратите внимание: чтобы использовать автоматический режим, нужно выбрать текущую задачу в баг-трекере только так плагин будет знать, над чем вы работаете и куда записывать время.
У автоматического режима есть несколько настроек. Например, он может вносить в систему затраченное время при каждом коммите, при закрытии проекта в IDE, по заданному вами графику (например, каждый день в 19:00) или по прошествии определенного периода неактивности в IDE.
Если вы хотите вести учет рабочего времени самостоятельно, то вам подойдет ручной режим. Он позволяет отслеживать время вручную попросту запуская и останавливая таймер. Когда работа будет окончена, вы сможете внести зарегистрированное время в YouTrack буквально в один клик.
Также вы можете отключить систему учета вообще и просто периодически вносить время в систему, вручную указывая задачу, продолжительность и тип работы и пр.
Лучше один раз увидеть, чем сто раз услышать. Плагин можно использовать с версией 2021.1 всех IDE JetBrains на платформе IntelliJ, включая AppCode, CLion, DataGrip, GoLand, IntelliJ IDEA, PhpStorm, PyCharm, Rider, RubyMine и WebStorm, а также с Android Studio. Чтобы установить плагин, откройте в IDE меню Settings -> Plugins и найдите там плагин YouTrack Integration.
Для настройки плагина вам понадобится YouTrack версии 2020.4.6808 или младше и постоянный токен.
Каких еще возможностей вы ждете от интеграции? Что позволило бы еще эффективнее использовать YouTrack вместе с IDE? Расскажите нам о своем опыте! Ваши отзывы помогут нам сделать плагин YouTrack еще лучше.
Ваша команда YouTrack
Я много исследую зарубежный опыт, прохожу обучения, слежу за тенденциями и в этом материале хочу поделиться с вами 3 лучшими практиками, которые используют компании из Штатов.
Вы можете посмотреть видеоверсию статьи, либо прочитать текстовый материал.
Знаете, мы с командой часто общаемся с собственниками компаний из России и СНГ на консультациях или при построении отделов маркетинга в их компаниях и очень часто видим такую ситуацию, в которой руководители ставят ключевым моментом мотивации уровень заработной платы. То есть они считают, что только от уровня зарплаты зависит: будет работать тот или иной сотрудник или нет. Это не везде так, но в подавляющем большинстве ситуация такова.
В штатах же, система мотивации выглядит иначе и строится на совершенно других базовых принципах, которые позволяют раскрывать потенциал каждого сотрудника и компании зарабатывают больше в пересчете на каждого члена команды.
Почему же американская система мотивации позволяет компаниям развиваться быстрее, чем наша привычная, система: я начальник-ты дурак? Все просто. Успехи американской модели мотивации объясняются ориентацией американцев на личный успех и достижение высокого уровня жизни и заработка.
В чем суть программы распределения прибыли? Если кратко, то суть в том, что компания мотивирует сотрудников работать и развивать компанию не только с помощью зарплаты, выплат отпускных и оплаты больничных, но еще и выделяя ежегодно или ежеквартально определенный объем опционов, которые распределяются среди самых эффективных и лояльных сотрудников.
Внедрение данного инструмента позволяет сотруднику ощущать себя не просто дойной коровой, которую подоят и заменят другой коровой, а совладельцем компании. Понимаете в чем суть? Человек начинает воспринимать себя как владельца бизнеса, что, как правило, сказывается на вовлеченности в деятельность компании, сказывается на генерации и внедрении новых идей и, соответственно, на выручке бизнеса.
И что очень важно: программы распределения прибыли позволяют повысить эффективность труда персонала без дополнительных затрат. Как показывают исследования, проведенные американцами: внедрение программы распределения прибыли позволяют компаниям увеличивать операционную продуктивность персонала до 50%. Т.е., условно, если раньше человек выполнял 10 задач в день, то с внедрением подобной системы у него растет мотивация и он делает уже порядка 13-15 задач в день. От чего, очевидно, растет общая прибыльность и капитализация компании.
Тем более в наше время, когда идет устойчивый тренд на развитие собственного дела и популяризацию фриланса. Люди перестают быть заинтересованы в развитии своего работодателя, который платит им зарплату и перемещают фокус внимания на развитие собственных проектов. А владение доли в бизнесе, хоть и не большой, но мотивирует человека прикладывать больше усилий, чтобы по итогу получить больше результата.
Давайте обратимся к зарубежным примерам. Так вот, в США это инструмент прекрасно работает и внедряется в огромном количестве компаний.
Возьмем, в качестве примера, компанию Tesla. В мае 2021 года стало известно, что Илон Маск по итогам своей работы получил право на акции Tesla стоимостью более 32 миллиардов долларов. Это вознаграждение он получил за достижение целевых показателей, которые установил совет директоров корпорации несколько лет назад. Благодаря этим опционам Илон теперь имеет возможность приобрести акции компании за 10% от их текущей рыночной стоимости.
И этот инструмент работает не только в Tesla. Сотни тысяч американских компаний работают по похожей методике и постоянно растут в своих показателях, т.к. их сотрудники заинтересованы в успехе бизнеса точно также, как и акционеры этих организаций.
Почасовая занятость это, наверное, один из ключевых моментов американского рынка. В чем его суть? Компания платит сотруднику только за те часы, которые человек потратил на выполнение задачи и не оплачивает ни минуты больше.
Т.е. бизнес, изначально, при построении продуктовой линейки и в расчетах финансовой модели закладывает количество часов, которое необходимо будет потратить внутреннему персоналу и получает сумму, которую выделяет на выплаты сотрудникам.
В США даже есть закон О минимальной заработной плате, которым работодатели обязаны руководствоваться и который устанавливает минимальную зарплату в США в размере 7 долларов 25 центов. Эта ставка не менялась с 2009 года. При этом существуют поправки на вид деятельности. Так минимальная ставка для персонала, который получает в ходе своей работы чаевые составляет уже 2 доллара и 13 центов. Также есть зависимость размера минимальной оплаты труда от штата. Так в Арканзасе работодатель обязан начислять сотрудникам заработную плату не менее 9 долларов и 25 центов за каждый час труда. А лидером среди всех штатов является штат Колумбия с минимальной ставкой в 14 долларов в час.
И, на самом деле, такая система оплаты труда является более оптимальной. Как думаете почему? Какие выгоды от ее внедрения видите? Напишите об этом в комментариях, обсудим.
Я же считаю, что минимизация постоянных затрат за счет проектной работы это прямой путь к повышению эффективности бизнеса и росту маржинальности. Объясню свою позицию. Когда мы перестаем платить сотрудникам оклад и переводим их, например, на проектную занятость, то мы снимаем с себя постоянную нагрузку выплаты ФОТа или, как его называют, фонда труда. Т.е. работа и заказы есть платим проектные зарплаты и работаем. Заказов нет нет и расходов на выплаты персоналу.
Ведь очень логично? Спрашивается, почему компания должна платить сотрудникам тогда, когда количество клиентов снижается? Скажите, чтобы удерживать квалифицированный персонал на своих позициях? Ведь, если людям не платить, то они быстро разбегутся. Но как показывает практика, уровень текучки в бизнесе с каждым годом растет. Уже ни у кого нет гарантии, что человек, в которого вы вкладывались несколько лет не возьмет и не уйдет к вашему конкуренту, который предложит больше. Или вообще откроет свою компанию и станет вашим прямым конкурентом. Это реалии нашего рынка и, я считаю, что пора менять систему мотивации и систему оплаты труда.
Подобные системы оплаты труда мы внедряем у наших клиентов при построении у них удаленных отделов маркетинга, а также аналогичная система работает и в нашей компании. Все сотрудники у нас работают на проектной основе и привлекаются исключительно под имеющиеся задачи. Такая система хорошо справляется с кризисными ситуациями, которые, как мы знаем, появляются в мире с завидным постоянством. Это значит, что т.к. мы практически не имеем постоянных затрат, то подстраиваться под все турбулентные ситуации нам гораздо проще, нежели чем компаниям с раздутым штатом, сидящим на окладах.
В чем его суть? Как мы знаем, в США система мотивации строится во многом вокруг личности сотрудника. Поэтому компании ищут нестандартные методы стимулирования персонала и предлагают своим работникам такие опции как: обширная медицинская страховка, оплачиваемая работодателем; курсы повышения квалификации; бесплатные обеды; корпоративные праздники; совместные поездки и многое другое.
Например, в компаниях IBM и AT&T существуют семейные программы. Что это означает? В этих компаниях средний возраст сотрудников составляет до 40 лет, очевидно, что бОльшая часть персонала является семейными людьми, у которых есть дети и домашние задачи. И в целях повышения эффективности их работы компания берет на себя решение части их домашних задач, таких как подбор няни или других помощников по дому, организует корпоративные ясли и детские сады, устраивает семейные праздники и многое другое. Ключевых задач несколько:
дать сотрудникам яркую причину работать в компании, которая за свой счет решает часть их жизненных проблем;
повысить эффективность персонала с помощью того, что сотруднику не нужно в рабочее время решать домашние вопросы и у него есть энергия заниматься своими непосредственными задачами.
Как вы видите, все в выигрыше.
К материальной системе мотивации относится сдельная или почасовая система оплаты. Но на этом американские компании не останавливаются и предлагают своим сотрудникам всевозможные бонусные программы, позволяющие человеку зарабатывать больше тогда, когда больше зарабатывает его компания.
То есть американцы не платят голый оклад, как это принято в русскоговорящих странах. Они очень любят привязывать оплату к результатам работы сотрудников, тем самым повышая операционную эффективность персонала и общую прибыльность своей компании.
Я считаю, что нам стоит поучиться у американских компаний, ведь, как показывают исследования, Штаты обладают самым большим количеством миллиардеров в мире, в несколько раз обгоняя Россию и Китай.
Примечание переводчика: перед началом чтения этого лонгрида
налейте себе кружку любимого напитка, потому что чтиво будет
непростым и, возможно, навсегда изменит ваше отношение к
сервису.
Наверняка вам приходилось слышать о нелёгкой работе модераторов
видеохостингов, вычищающих многие терабайты запрещённого контента,
но есть ещё одна категория сотрудников, службу которых вряд ли
можно назвать простой, это сотрудники секретной службы безопасности
Airbnb.
Журналисты Bloomberg выяснили, что компания постоянно сталкивается
с преступлениями в арендованных квартирах и разбирается с этими
случаями особая команда численностью в 100 человек, многие из
которых раньше служили в армии или работали в полиции. Когда во
время пребывания в арендованной квартире что-то идёт не так, как
надо, в дело вступают эти парни, чтобы убрать трупы
успокоить гостей и хозяев, замыть кровь помочь семьям и
предотвратить PR-катастрофу.
Квартира на первом этаже на 37-й Западной улице, в нескольких кварталах к югу от Таймс-сквер, была популярна среди туристов настолько, что ключи для арендаторов Airbnb оставляли на стойке соседнего винного магазина. Именно там 29-летняя австралийка и её друзья забрали их, не предъявляя никаких документов, когда приехали на Манхэттен провожать 2015 год. Квартира была размещена на Airbnb, несмотря на то, что краткосрочная аренда в Нью-Йорке в большинстве случаев вне закона. Город, подталкиваемый влиятельными профсоюзами отельеров, вёл войну с компанией, которая размещала тысячи объявлений о сдаче квартир в пяти районах, несмотря на одни из самых строгих законодательных предписаний об аренде в стране.
Вскоре после встречи Нового года женщина оставила своих друзей в баре, где они отмечали праздник, и вернулась в квартиру в одиночестве. Она не заметила ничего особенного и не увидела мужчину, стоявшего в тени, когда заходила в ванную. Когда она поняла, что не одна, мужчина направил на неё лезвие кухонного ножа. Он схватил её, толкнул на кровать и изнасиловал. Пьяные гуляки бродили по улицам, но женщина была слишком напугана, чтобы кричать.
Нападавший скрылся с её телефоном, но ей удалось дозвониться до друзей с iPad, и они выбежали на улицу, чтобы найти полицейского. Примерно через час, когда полицейские уже были в квартире, мужчина вернулся и заглянул в дверной проём. Они поймали его и вытряхнули всё из его рюкзака, обнаружив три улики: нож, одну из серёжек жертвы и связку ключей от квартиры.
О происшествии немедленно известили кризис-менеджера Airbnb Ника Шапиро. Шла вторая неделя его работы в этой должности, куда он перешёл с поста заместителя начальника штаба ЦРУ и советника в Совете национальной безопасности в Белом доме Обамы. Я помню, как думал, что снова оказался в гуще событий. вспоминает он. Происшествие вернуло меня к ощущениям, которые я испытывал, сталкиваясь с действительно ужасными вещами в Лэнгли и в ситуационной комнате Белого дома.
Даже видавший некоторое де**мо Ник Шапиро был в шоке.Шапиро, в свою очередь, уведомил других руководителей Airbnb, включая главного исполнительного директора Брайана Чески. Тем временем агенты из элитной команды компании по обеспечению доверия и безопасности начали действовать. Они переселили пострадавшую женщину в отель, оплатили перелёт ее матери из Австралии, доставили их обеих домой и предложили покрыть все расходы на лечение и консультации психолога.
Дубликаты ключей представляли собой особую проблему для компании и загадку для следователей. Откуда они у мужчины? У Airbnb нет правил, как хозяева (здесь и далее владельцы сдаваемых помещений) должны обмениваться ключами с гостями, и от ответа на этот вопрос зависела репутация компании в плане безопасности и, возможно, её юридическая ответственность. Шапиро (который на сегодня уже покинул компанию) помогал координировать расследование этого вопроса.
Тот самый дом на 37-й Западной улице.Через неделю один из сотрудников был отправлен в суд, чтобы проверить, не упоминался ли Airbnb в ходе судебного разбирательства. Местные СМИ также не сообщали о преступлении, несмотря на ужасающие подробности, и компания хотела, чтобы СМИ и дальше молчали. Эта история осталась не освещённой до сих пор, в немалой степени потому, что через два года после нападения Airbnb выписал женщине чек на 7 млн. долларов это одна из самых больших выплат, которые когда-либо делала компания. В обмен на деньги она подписала соглашение не говорить об урегулировании или подразумевать уголовную ответственность или обязательства со стороны Airbnb или хозяина дома.
Подробности преступления, реакция компании и факт урегулирования были реконструированы из полицейских и судебных протоколов и конфиденциальных документов, а также из интервью с людьми, которые знакомы с этим делом. Женщина, имя которой было изменено в судебных документах и которая через своего адвоката попросила не называть её имени, отказалась от комментариев. Так же поступил и её адвокат. Бен Брейт, представитель Airbnb, говорил, что у компании нет полномочий скрывать информацию от СМИ и что, несмотря на формулировку мирового соглашения, женщина может обсуждать, считает ли она кого-либо ответственным. Он добавил, что целью Airbnb после инцидента была поддержка выжившей после ужасного нападения и что местные политические вопросы не имеют никакого отношения к её реакции.
Этот случай в Нью-Йорке произошёл во время ожесточённой борьбы с регуляторами, и реакция Airbnb на него показывает, насколько важна была команда безопасности для роста компании. Бизнес-модель Airbnb основана на идее, что незнакомые люди могут доверять друг другу. Если идея будет развенчана, это может означать уменьшение числа пользователей и увеличение количества судебных исков, не говоря уже об ужесточении регулирования.
При всей своей важности команда безопасности остаётся секретной. Инсайдеры называют её чёрным ящиком. Но восемь бывших членов команды и 45 других сотрудников Airbnb (нынешних и бывших), знакомых с ролью команды, дали редкую возможность взглянуть на её операции и внутренние проблемы. Большинство из этих людей говорили на условиях анонимности, опасаясь нарушить соглашения о конфиденциальности. По словам бывших членов команды, это очень нервная работа балансировать между часто противоречивыми интересами гостей, хозяев и компании. У меня были ситуации, когда я говорил с клиентом после инцидента, вешал трубку и плакал, вспоминает один из бывших агентов. Это всё, что я мог сделать.
Airbnb была основана в 2008 году студентами-дизайнерами Брайаном Чески и Джо Геббиа вместе с инженером-программистом Натаном Блечарчиком. Из забавной альтернативы каучсёрфингу Airbnb выросла до одной из крупнейших гостиничных компаний в мире с 5,6 миллионами объявлений, а это больше, чем количество номеров в семи крупнейших гостиничных сетях, вместе взятых.
Светлые и прекрасные лица основателей Airbnb, слева направо: Джо Геббиа, Брайан Чески, Натан Блечарчик.Сейчас рыночная стоимость компании составляет 90 млрд. долларов цена акций удвоилась с момента выхода компании на биржу в декабре, и это свидетельствует о том, насколько основатели продвинулись в привлечении инвесторов с тех времён, когда они ели лапшу.
Одним из первых привлечённых ими венчурных капиталистов Кремниевой долины был Крис Сакка, один из первых инвесторов Instagram, Twitter и Uber. Позже Сакка вспоминал, что после их презентации он отвёл их в сторону и сказал: Ребята, это очень опасно. Кого-то изнасилуют или убьют, и кровь будет на ваших руках. Деньги вкладывать он не стал.
С самого начала Airbnb поощряла незнакомых людей общаться в Интернете, а затем встречаться в реальной жизни, часто ночуя под одной крышей. Компания находится где-то между технологической платформой и гостиничным оператором она не может снять с себя ответственность за безопасность своих пользователей, как некоторые технологические компании (вспоминаем известное у нас Мы не такси, мы просто агрегатор прим. перев.), или предоставить охрану и другой персонал на месте, как гостиница. Доверие и безопасность в Airbnb сложнее, чем в Apple или Facebook, потому что вы имеете дело с реальными людьми в домах реальных людей, рассказывает Тара Банч, руководитель глобальных операций Airbnb.
На первых порах соучредители отвечали на все жалобы клиентов по своим мобильным телефонам. Когда это стало неуправляемым, они наняли вспомогательный персонал для полевых вызовов. Только через три года, когда было сделано более 2 млн. бронирований, компания столкнулась с первым серьёзным кризисом безопасности. В 2011 году одна из хозяек в Сан-Франциско написала в блоге о том, как, вернувшись из рабочей поездки, обнаружила, что её дом разграблен. Её гости испортили её одежду, сожгли её вещи и пробили дыру в запертой двери шкафа, чтобы украсть её паспорт, кредитные карты, ноутбук и жёсткие диски, а также драгоценности её бабушки.
В следующем посте хозяйка написала, что с ней связался соучредитель Airbnb и, вместо того чтобы предложить поддержку, попросил её удалить историю из блога, сказав, что это может повредить предстоящему раунду финансирования. Вскоре #RansackGate стал трендом в Твиттере, и этот инцидент превратился в краткий курс по управлению кризисом. Результат публичные извинения Чески, гарантия хозяевам на возмещение ущерба в размере 50 000 долларов (с тех пор она увеличена до 1 млн. долларов), круглосуточная горячая линия поддержки клиентов и новый отдел доверия и безопасности.
Брайан Чески смотрит на вас как на помеху в привлечении инвестиций.По мере роста Airbnb росло и количество опасных инцидентов от выбрасывания хозяевами чемоданов из окон до установки скрытых камер, утечек газа и сексуальных посягательств.
Многие из этих преступлений, происходивших в рамках краткосрочной аренды квартир, размещённых на платформе компании, могли произойти в любой квартире или гостиничном номере. Но в некоторых случаях хозяева использовали платформу компании как инструмент для совершения преступлений. В октябре 2011 года хозяин квартиры в Барселоне, выставленной на Airbnb, угостил алкоголем двух американок, забронировавших проживание в его доме, а затем изнасиловал их. Когда на следующее утро женщины обратились в полицию, хозяин пригрозил выложить в Интернет видеозаписи нападения, если они не откажутся от претензий. Полиция обыскала его квартиру и нашла сотни подобных фотографий других жертв. Мужчина был приговорен к 12 годам тюрьмы. В Airbnb отказались комментировать эту историю, заплатив двум женщинам нераскрытую сумму и пожизненно забанив хозяина квартиры.
К 2016 году команда безопасности была перегружена звонками, многие из которых были незначительными по своему характеру, и Airbnb начала обучать подрядчиков в колл-центрах по всему миру, чтобы они справлялись с потоком жалоб. Airbnb утверждает, что менее 0,1% случаев проживания приводят к возникновению проблем с безопасностью, но при более чем 200 млн. бронирований в год это всё равно очень много поездок с плохим концом. В службу внутренней безопасности передаются только самые серьёзные проблемы.
Эта команда состоит примерно из 100 агентов в Дублине, Монреале, Сингапуре и других городах. Некоторые из них имеют опыт работы в аварийно-спасательных службах или в армии. Члены команды имеют право на любые расходы, чтобы жертва почувствовала поддержку, включая оплату авиабилетов, проживания, питания, консультаций, медицинских расходов и анализов на заболевания, передающиеся половым путем, для тех, кто пережил изнасилование. Бывший агент, проработавший в Airbnb пять лет, описывает этот подход как стрельбу из денежной пушки. Команда переселяла гостей в гостиничные номера по цене, в 10 раз превышающей стоимость их бронирования, оплачивала кругосветные отпуска и даже подписывала чеки на сеансы психологической помощи собакам. Мы делаем всё возможное, чтобы обо всех, кто пострадал на нашей платформе, позаботились, рассказывает Тара Банч. Мы не беспокоимся о бренде и имидже. Эта штука позаботится о себе сама, пока вы поступаете правильно.
Тара Банч, руководитель глобальных операций Airbnb и секретной команды безопасности делает вид, что имидж ничто.Бывшие агенты вспоминают случаи, когда им приходилось консультировать гостей, которые прятались в гардеробах или убегали из уединённых домиков после нападения хозяев. Иногда гости сами были преступниками, как в случае, когда одного из них нашли в постели голым с 7-летней дочерью хозяина. Агентам приходится нанимать бригады уборщиков для очистки ковров от крови, нанимать подрядчиков для замазывания пулевых отверстий в стенах и разбираться с хозяевами, обнаружившими расчленённые человеческие останки.
Работа может быть настолько напряжённой, что агенты имеют доступ к комнатам с приглушённым освещением, чтобы создать успокаивающую атмосферу для ответов на тревожные звонки. И это может привести к тяжёлым потерям. Некоторые бывшие агенты говорят, что страдают от викарной (или заместительной) травмы. На работе они старались помнить, что всё происходящее в жизни может произойти и в Airbnb. Эту точку зрения вдалбливали новобранцам во время 12-недельных тренингов: точно так же, как ночные клубы не могут исключить сексуальные посягательства, а отели не могут остановить торговлю людьми, Airbnb не может помешать злоумышленникам использовать свою платформу.
В компании отказались комментировать условия расчётов или бюджет службы безопасности. Но из конфиденциального документа, с которым ознакомился Bloomberg Businessweek, следует, что в последние годы Airbnb тратила в среднем около 50 млн. долларов в год на выплаты хозяевам и гостям, в том числе на судебные разбирательства и возмещение ущерба, нанесённого жилью. (Компания утверждает, что большинство её выплат связано с ущербом имуществу по программе страхования хозяев и что шестизначные суммы выплат исключительная редкость.)
Бывшие агенты по безопасности также рассказывают о напряжённых
отношениях с отделом доверия, чья работа заключается в разработке
политики по предотвращению плохих вещей, будь то клопы, заряжённое
оружие или похищения. Агенты по безопасности, которые наводят
порядок только после происшествий, говорят, что чувствовали себя
изгоями. Между отделами безопасности и продаж также существовала
напряжённость из-за профессиональных хозяев, управляющих
несколькими объектами недвижимости, удаление которых с платформы за
нарушение правил безопасности могло стоить Airbnb сотен
объявлений.
По словам бывших агентов, самым трудным в их работе было
примириться со своей ролью в замалчивании случаев и обеспечении
того, чтобы жертвы и их семьи не обвиняли компанию. Иногда агентам
предлагали уделять приоритетное внимание менее травматичным
ситуациям с участием звёзд реалити-шоу и других людей с большим
количеством подписчиков в социальных сетях, что, по словам агентов,
заставляло их чувствовать себя неловко. Однако Брейт, представитель
Airbnb, рассказывает, что все инциденты, связанные с безопасностью,
рассматриваются надлежащим образом и последовательно.
Как и многие другие компании Кремниевой долины, Airbnb поднялась
благодаря политике роста любой ценой: она проникала в города,
обходя правила, побеждала в народном голосовании и набирала
популярность так быстро, что к тому времени, когда чиновники
замечали происходящее, у них уже не оставалось шансов
контролировать ситуацию. По всему миру разгорелись нормативные
битвы, самая токсичная из которых разыгралась в Нью-Йорке в 2015
году. Городские власти проводили операции по выявлению незаконной
аренды жилья на срок менее 30 дней и обязали компанию предоставить
адреса своих объявлений, что вызвало многолетнюю судебную тяжбу.
Airbnb нанимала исследователей оппозиции, чтобы изучить биографии
своих критиков, и оплачивала атаки на них в прессе.
В начале 2016 года, после нападения в районе Таймс-сквер, агенты по безопасности сделали то, чему их учили: обеспечили комфорт и помощь жертве. Но возможность судебного разбирательства повысила ставки. Крис Лихэйн, бывший политический консультант президента Билла Клинтона, был принят на работу в Airbnb в качестве главы отдела глобальной политики и коммуникаций за несколько месяцев до инцидента. Инсайдеры компании говорят, что Лихэйн, автор книги 2014 года Masters of Disaster о чёрном искусстве контроля репутационного ущерба, боялся, что этот случай может быть использован оппонентами для изгнания Airbnb из города.
Крис Лихэйн как бы намекает, что даже с супружеской изменой президента можно работать.Проблема с ключами решалась нелегко. Такие схемы, как та, что использовал хозяин квартиры на 37-й Западной улице, распространены в экосистеме краткосрочной аренды магазин багажа по соседству со зданием рекламировал себя в Интернете как удобное место для получения ключей от сейфа Airbnb. Но такая практика может быть опасной, так как ключи проходят через неизвестное количество рук.
Уильям Делайно, много лет живущий в доме на 37-й Западной улице, вспоминает, что друзья этой женщины позвонили в его квартиру в тот вечер, не получив от неё ответа. В здании было довольно много квартир Airbnb, и я привык к подобным поступкам иностранных путешественников, говорит он. По его оценкам, в то время на Airbnb сдавались 4 из 12 квартир здания. Владеющая зданием компания Kano Real Estate Investors LLC отказалась от комментариев. Но после нападения, по словам жильцов, она внесла изменения в свои договоры аренды, запретив им размещать свои квартиры на Airbnb.
Детективам повезло, что предполагаемый насильник, Джуниор Ли, вернулся с ключами. Ему было предъявлено обвинение в хищническом сексуальном нападении, которое в штате Нью-Йорк предусматривает максимальное наказание в виде пожизненного заключения. Прокурор заявил судье, что 24-летний Ли закоренелый преступник, имеющий 40 судимостей за мелкие правонарушения. Ли не признал себя виновным, и залог был установлен в размере 250 000 долларов.
Компания Airbnb избежала упоминания в СМИ, в обвинительном заключении и даже в полицейском отчёте и жалобе, поданной прокурорами. В открытых источниках также нет информации о том, как Ли получил ключи. Его адвокат отказался комментировать это дело. Ли, признанный психически неполноценным, находится под стражей в ожидании дальнейшей экспертизы, но, даже если он предстанет перед судом, неясно, встанет ли вопрос о роли компании в этом деле и будет ли когда-нибудь раскрыта тайна ключей.
Потенциальная ответственность Airbnb за несоблюдение более строгой политики обмена ключей не будет проблемой благодаря урегулированию в размере 7 млн. долларов, которое было достигнуто после того, как адвокат пострадавшей женщины отправил письмо с угрозой судебного разбирательства. Хотя это соглашение не запрещает женщине сотрудничать с прокуратурой, оно не позволяет ей обвинять компанию или подавать на неё в суд. Это было особенно важно для Airbnb, потому что женщина не снимала квартиру и не подписывала соглашение об условиях предоставления услуг компании, состоящее из 10 000 слов еще один важный способ Airbnb не доводить инциденты от суда и не привлекать внимание общественности.
Каждый, кто регистрируется на сайте, обязан подписать соглашение, которое запрещает судебные иски за травмы или стресс, возникшие в результате проживания, и требует конфиденциального арбитража в случае спора. По оценкам бывших сотрудников службы безопасности, компания ежегодно рассматривает тысячи заявлений о сексуальном насилии, многие из которых связаны с изнасилованиями. Однако в американских судах против Airbnb было возбуждено только одно дело, связанное с сексуальным нападением, согласно обзору доступных в электронном виде судебных исков штатов и федеральных судов. Адвокаты жертв говорят, что важной причиной столь малого количества дел являются условия предоставления услуг.
То самое единственное дело, которое удалось довести до конца, было возбуждено в 2017 году, когда Лесли Лапайоукер, 51-летняя женщина, подала в суд на Airbnb после того, как якобы подверглась нападению со стороны хозяина в Лос-Анджелесе. Согласно судебным документам, Лапайоукер переезжала в город из Нью-Мексико и заказала 30-дневное проживание, пока искала постоянную квартиру. В иске говорится, что после того как она решила уехать из-за странного поведения хозяина, он последовал за ней в однокомнатную квартиру, которую она сняла, запер дверь, удерживал её на стуле против её воли, мастурбировал перед ней и кончил в мусорное ведро. Когда Лапайоукер убегала, согласно жалобе, хозяин сказал: Не забудьте оставить мне положительный отзыв на Airbnb. Мужчине, который заявил, что встреча произошла по обоюдному согласию, не было предъявлено никаких обвинений.
Фильм Американский психопат.Адвокат пострадавшей Тереза Ли говорит, что делу дали ход, несмотря на требования арбитража в условиях обслуживания Airbnb, потому что компания не провела тщательную проверку хозяина. Airbnb отмечает только предыдущие судимости, и, хотя хозяин ранее был обвинен в нанесении побоев, он не был осуждён.
В своём иске Ли утверждала, что Airbnb создаёт ложное чувство безопасности, используя на своём сайте слова доверие и безопасность. Компания пошла на мировое соглашение, предложив пострадавшей женщине нераскрытую сумму денег в обмен на прекращение дела. Она также запретила хозяину пользоваться своей платформой. Airbnb отказалась от комментариев, как и Лапайоукер. Ли говорит, что ей запрещено обсуждать переговоры и сумму, которую получил её клиент.
Этот же адвокат урегулировала ещё одно дело о нападении, возбуждённое гражданкой США, изнасилованной в Индии родственником хозяина, который был выпущен под залог после обвинения в убийстве.
Аналогичный процесс произошёл, когда семья Карлы Стефаниак, женщины из Флориды, убитой во время празднования своего 36-летия в Коста-Рике в 2018 году, подала иск против компании в том же году. Разлагающиеся останки Стефаниак были обнаружены полузарытыми и завёрнутыми в пластик примерно в 300 метрах от её квартиры на Airbnb. Охранник комплекса, где она остановилась, был признан виновным в её убийстве. В иске утверждалось, что Airbnb не проверила биографию охранника, который работал в стране нелегально. Компания урегулировала дело за нераскрытую сумму.
Результатом всех этих урегулирований в сочетании с условиями предоставления услуг, которые в первую очередь предотвращают судебные иски, является то, что суды так и не установили, в какой степени операторы краткосрочной аренды могут нести ответственность, если вообще несут, за преступления, совершённые в размещаемых на платформе помещениях. Закон вокруг этих платформ неясен, рассказывает Ли. Все дела передаются в арбитраж, поэтому никто ничего толком не знает.
Стремление Airbnb к секретности также затрудняет понимание того, какое влияние оказывает краткосрочная аренда на общую безопасность районов. Компания не публикует адреса объявлений, чтобы защитить безопасность и конфиденциальность своих пользователей. И, хотя некоторые города США требуют от хозяев вносить свои квартиры в реестры краткосрочной аренды, большинство из них не публикуют эти данные, ссылаясь на те же соображения конфиденциальности. Те, кто это делает, часто не раскрывают номера квартир, что делает практически невозможной проверку многих адресов по звонкам полиции или записям об арестах. Реестры также не включают квартиры, арендуемые незаконно.
Журналисты Bloomberg получил реестры для Остина, Майами-Бич и Лос-Анджелеса через запросы на публичные документы, попытались сопоставить их с публичными базами данных полицейских вызовов или преступлений. За последние два года полиция отреагировала на тысячи инцидентов, связанных с краткосрочной арендой жилья в этих трёх городах. В Майами-Бич реестр показал 1071 вызов полиции по адресам, указанным в 2019 году, включая 40 случаев насильственных преступлений. Однако в полицейских отчётах не указывается, на какой платформе находилась квартира и сдавалась ли она в аренду в тот момент, что затрудняет получение полезных выводов о взаимосвязи между индустрией краткосрочной аренды и преступностью. Научные исследователи говорят, что аналогичные ограничения помешали их усилиям изучить эту связь. Было проведено всего около полудюжины научных исследований по этому вопросу, и их результаты противоречивы.
Поскольку города и полиция не в состоянии собрать данные, а дела редко доходят до суда, громкие инциденты, как правило, определяют политические дискуссии вокруг краткосрочной аренды. Помня об этом, с 2018 года Airbnb передаёт подобные инциденты в свою глобальную группу кризисного управления, которая была сформирована Лихэйном и другими руководителями и первоначально возглавлялась Шапиро, бывшим сотрудником ЦРУ.
В 2018 и 2019 годах произошло несколько смертельных инцидентов, помимо убийства Стефаниак, когда компания готовилась к первичному размещению акций. Один из них произошёл в ноябре 2018 года, когда пара пенсионеров из Нового Орлеана умерла в Мексике, надышавшись токсичными испарениями, когда они спали в арендованной квартире Airbnb. После этого их сын выступил по телевидению, умоляя Airbnb сделать больше для защиты своих пользователей.
Брайан Чески как бы намекает, что устал от таких инцидентов.Брайан Чески, который отказался дать интервью для этой статьи, хотел знать, почему подобные случаи продолжают попадать к нему на стол и почему компания неправильно или несвоевременно реагирует на такие инциденты. Ответ на второй вопрос заключался в том, что у команды безопасности было недостаточно сотрудников. Когда руководители поняли это, последовала встряска. В начале 2019 года группа безопасности была отделена от группы доверия, передана в ведение отдела поддержки и получила дополнительные инженерные ресурсы и персонал.
Но трагедии продолжали происходить. В мае того же года шесть бразильских туристов, двое из которых были детьми, погибли от отравления угарным газом в арендованной квартире Airbnb в Сантьяго, Чили. Родственник погибших перед их смертью позвонил в компанию, но ответ задержался, потому что никто в колл-центре не говорил по-португальски. По словам бывших сотрудников, Чески был в ярости.
В Хэллоуин Airbnb столкнулась с одним из самых смертоносных инцидентов: перестрелка в доме с четырьмя спальнями стоимостью 1,2 млн. долларов в Оринде, штат Калифорния, примерно в 32 км к востоку от Сан-Франциско. Дом, на который было подано множество жалоб в полицию и городские власти, был забронирован на одну ночь. Гость, о котором Airbnb уже сообщили, что за несколько дней до этого он оставил пулю в другом арендованном доме, что было зафиксировано внутри компании, затем дал объявление о вечеринке в особняке в социальных сетях. На вечеринке было более 100 человек, когда гость-стрелок открыл огонь, убив пятерых.
Полиция расследует стрельбу в Оринде.Чески выразил свои соболезнования в Твиттере и объявил о новых мерах безопасности, включая запрет на дома для вечеринок и обещание проверять фотографии, удобства, чистоту и безопасность всех объявлений на Airbnb. Но компания не связывалась с матерью одной из жертв, 23-летнего Реймона Хилла, в течение недели, пока её адвокат, Джесси Данофф, не написал письмо и не выступил с заявлением, в котором раскритиковал Airbnb за то, что компания предоставляет лишь молитвы. Даже некоторые из собственных агентов компании по безопасности были расстроены. Они говорят, что дома для вечеринок были проблемой на протяжении многих лет.
Дом в Оринде, где были застрелены пять человек.Впоследствии Airbnb предложила оплатить похороны, но Данофф рассказывает, что, когда некоторые из семей прислали счета на сумму более 30 тыс. долларов, компания начала торговаться. Им уже всё равно, потому что новостной цикл пошёл дальше, рассказывает Данофф. Единственное, что их действительно мотивирует, это угроза или потенциальная угроза плохого пиара или кошмара в прессе. (Airbnb утверждает, что оплатила счета. Данофф говорит, что он всё ещё ведёт переговоры об урегулировании.)Они должны ответить за то, что произошло, говорит об Airbnb мать Хилла, Синтия Тейлор. У моего сына отняли жизнь в доме, который они разрешили продолжать сдавать в аренду на своём сервисе после многочисленных жалоб.
Синтия Тейлор со своим сыномВ декабре того же года Airbnb объявила о выделении 150 млн. долларов на дополнительные расходы, связанные с доверием и безопасностью. Компания ввела круглосуточную горячую линию, которая предоставляет арендаторам немедленный доступ к агенту по безопасности; создала систему, чтобы отмечать бронирования с высоким риском; запретила пользователям моложе 25 лет и не имеющим истории положительных отзывов бронировать Airbnb в районе, где они живут; и перестала разрешать останавливаться на одну ночь на Хэллоуин, 4 июля и Новый год. Многие из этих мер были введены в США их внедрение по всему миру оказалось непростой задачей, учитывая различия в культуре, обычаях и правилах в 191 стране, где работает Airbnb. Компания также обсуждала вопрос о том, нужно ли заставлять пользователей предоставлять удостоверения личности государственного образца, но решила не делать этого, чтобы не исключить хозяев и гостей в странах, где удостоверение личности трудно получить.
В начале 2020 года разразилась пандемия, которая свела на нет все путешествия, так как страны закрыли границы, и мир оказался под замком. Airbnb потерял 80 % своего бизнеса за восемь недель. Команда по безопасности была завалена звонками по поводу инфекции. Что ещё хуже, профессиональные организаторы вечеринок начали превращать арендуемые Airbnb квартиры и дома в ночные клубы. Сотни пьяных гуляк без масок разгуливали по пригородам США, напрягая ресурсы полиции, приводя в ярость чиновников здравоохранения и перегружая команду безопасности.
В мае прошлого года Чески плакал в веб-камеру во время общекорпоративного собрания, на котором он объявил о сокращении 25% персонала. Увольнения были ожидаемы, но для многих было шоком то, что вся команда безопасности в Портленде, штат Орегон, была уволена, включая 25 самых опытных агентов компании. Некоторым сказали, что они смогут сохранить работу, если пойдут на сокращение зарплаты и переедут в Монреаль, куда Airbnb переводит свои североамериканские подразделения безопасности, привлеченные выгодными налоговыми льготами и более низкими затратами на недвижимость и рабочую силу.
В своих электронных письмах и на встречах с сотрудниками в формате вопрос ответ Чески критиковали за предательство сообщества Airbnb и сотрудников службы безопасности, которые говорили, что поставили на карту свое психическое здоровье ради компании. Он признал свою ошибку и предложил нанять некоторых агентов на временную работу с оплатой в полтора раза больше, пока канадская команда не пройдёт полное обучение. Около 15 человек вернулись.
Из эпизода Южный парк Енот 2: Непредусмотрительность, в котором CEO BP в издевательской манере просит прощения за аварию в Мексиканском заливеВ то время об этом не сообщалось, и это не помешало IPO. После открытия торгов в декабре Airbnb продемонстрировала один из самых больших скачков (цены на акции) в первый же день, увеличив состояние каждого из основателей более чем на 10 млрд. долларов.
Крис Сакка, инвестор, который 13 лет назад отверг стартап, поздравил его в Твиттере. Я позволил худшему варианту помешать мне увидеть вероятный вариант, написал он. На каждой платформе есть плохие игроки, но большинство людей хорошие люди. Они это знали. Я не слушал.
Airbnb всё ещё приходится сталкиваться с кризисами безопасности, реагировать на нападения и бороться с регуляторами. 31 мая в рамках соглашения об урегулировании судебного процесса с Нью-Йорком компания начала передавать информацию о своих хозяевах, включая имена, адреса и информацию о том, сдают ли они всю квартиру. Эти данные облегчат отслеживание незаконных объявлений.
Спустя более пяти лет после нападения на 37-й Западной улице Airbnb всё ещё не установила чётких правил относительно ключей. Этот случай положил начало многолетним внутренним дебатам о бесключевом доступе. Если бы хозяев можно было заставить пользоваться цифровыми клавиатурами и менять код после каждого пребывания, то в будущем можно было бы избежать подобных ситуаций. Даже требование раскрывать информацию о том, есть ли у них вход с клавиатуры, может изменить ситуацию. Шапиро, бывший глава антикризисного управления, вспоминает, как настаивал на том, чтобы исключить обмен ключами. Я помню, как пытался поговорить о процессе обмена ключами и способах предотвращения того, чтобы хозяева оставляли их в магазинах, говорит он.
В итоге было сделано немного, кроме размещения информации о бесключевом доступе в Интернете и работы с несколькими производителями замков для снижения стоимости внедрения. Сделать больше было бы сложно, потому что Airbnb не может диктовать хозяевам, как входить в их собственные дома, и это могло бы отбить у них желание размещать объявления на платформе. В итоге победила экономическая целесообразность. Вы можете увидеть доказательства в городах по всему миру: небольшие ящики с замками висят на перилах ограждений, готовые к тому, что следующий гость Airbnb заберёт свой ключ, не зная о том, есть ли дубликат ключа у кого-то ещё...
Узнайте, как прокачаться и в других специальностях или освоить их с нуля:
Другие профессии и курсыПРОФЕССИИ
КУРС
Американским рабочим нужно всерьёз задуматься надо отладкой производственных процессов перенимайте опыт компании Тойота!
Рабочим следует итерировать совместно с клиентами, чтобы создавать автомобили наивысшего качества.
Рабочие на производстве автомобилей слишком много внимания уделяют деталям в ущерб пониманию причин.
Создание хорошего автомобиля не сводится к изготовлению и сборке деталей.
Прим. пер.: Очень интересно оглянуться назад и проверить на прочность высказывания создателя Gmail Пола Букхайта, которые он озвучил 14 лет назад (в 2007 году). Некоторые моменты сейчас кажутся немного наивными, но основной посыл актуален до сих пор.
Привет, хабровчане!
Сегодня постараюсь рассказать о технических особенностях продукта Максимум на первый месяц, первый вариант которого Yota запустила еще в 2020 году. Сейчас самое время поучаствовать во второй версии его реализации, когда по истечении trial-периода, проанализировав статистику потребления, Yota рекомендует не только набор минут и гигабайтов, но и безлимитные приложения, при использовании которых их трафик не учитывается в основном пакете ресурсов.
Оставив за скобками не менее интересную историю о том, как эта
идея прошла через жернова отбора продуктологов, сфокусируемся на
основных аспектах реализации решения.
Здесь необходимо сделать отступление для понимания картины мира.
Yota, являясь Full MVNO оператором, полностью контролирует BSS стек
технологий и выстраивает свой IT-ландшафт самостоятельно. То есть в
нашем ландшафте есть место как различным витринам взаимодействия с
клиентом, таким как мобильное приложение, сайт, цифровые и
голосовые каналы, так и бэкенд системам, обеспечивающим возможности
по регистрации клиентских данных, управления жизненным циклом
продуктов, тарификации и многие другие. Иначе говоря, IT-ландшафт
отлично соотносится с подходами доменно-ориентированного дизайна, а
значит, как только аналитикам и архитекторам поступили
бизнес-функциональные требования, их первоочередная задача была
определить IT-домены, которые будут затронуты предполагаемыми
изменениями.
Согласно условиям продукта новые клиенты в течение первого месяца практически не ограничены в использовании ресурсов (2000 минут и безлимитный интернет). По прошествии месяца необходимо проанализировать статистику потребления и предложить клиенту пакет ресурсов, соответствующий его тратам. Исходя из этих условий, выделяются следующие основные потоки информационного обмена между системами:
В сборе и анализе данных участвуют IT-домены, которые ближе всего находятся к сетевому оборудованию:
При подготовке рекомендованного предложения участвуют IT-домены, которые формируют предложение и обеспечивают его передачу в нужный канал:
Давайте рассмотрим каждый из информационных потоков более детально.
Как уже упоминалось, поток, связанный со сбором информации о потреблении, носит гораздо более технический и даже инфраструктурный окрас.
Самое обычное (но не самое простое) получить информацию об израсходованных минутах. Фактически у каждого оператора мобильной связи есть системы, производящие оценку звонка в онлайн режиме. При попытке установления соединения клиентский терминал осуществляет запрос на соединение в сеть, который поступает на Систему онлайн оценки разговоров (попросту говоря рейтер или оценщик). Задача оценщика получить информацию о стоимости соединения в биллинговой системе, информацию о текущем балансе клиента, информацию о состоянии накопителей минут и в итоге определить, насколько долго может длиться разговор. Информация о состоявшемся звонке (CDR) регистрируется в биллинговой системе, в состав которой входит, в том числе, и длительность разговора.
Описанная функциональность является стандартной для любого
оператора связи. Единственным допущением в нашем случае стало то,
что, предоставляя максимум минут и гигабайтов на первый месяц,
биллинговая система должна иметь конечный порог накопителя, так как
оценщик должен уметь посчитать конечную длительность разговора.
CDR-файлы выгружаются на файловый сервер для передачи в
корпоративное хранилище данных и дальнейшей подготовки/производства
продукта данных.
В случае контроля интернет-трафика, с точки зрения его сбора и
анализа, все оказалось несколько сложнее. Здесь есть четкая
привязка к оборудованию и его возможностям, а именно поддержке
протокола IPFIX. IPFIX расшифровывается как IP Flow Information
Export, то есть экспорт информации IP-потока. IPFIX позволяет
сетевым инженерам и администраторам собирать информацию о трафике с
коммутаторов, маршрутизаторов и любых других сетевых устройств,
поддерживающих протокол, и анализировать отправляемую информацию,
обрабатывая ее с помощью системы анализа трафика.
Именно система анализа трафика должна поддерживать данный протокол,
полученная информация по которому может быть использована при
расчете предложения, включающего соответствующие безлимитные
приложения для оптимизации затрат клиента на трафик. В связи с тем,
что нам потребовалось обновить программное обеспечение систем
анализа трафика в разных регионах, усовершенствованная версия
продукта Максимум на первый месяц с возможностью рекомендаций
безлимитных приложений была запущена уже по факту апгрейда этих
систем.
Объем потребленного трафика учитывается в накопителях PCRF
системы, контролирующей потребление трафика.
Информация о потоке трафика также в результате передается в
корпоративное хранилище данных для дальнейшей
подготовки/производства продукта данных.
Собранные данные приземляются как есть в хранилище данных,
производится очистка, проверка качества. В результате чего
подготовленные данные можно использовать для производства
специализированных продуктов данных, имеющих определенную
бизнес-ценность и произведенных для определенных конечных
потребителей. В нашем случае это продукт данных, который
используется движком бизнес-правил для формирования ответов о
выполнении клиентом тех или иных условий, связанных с потреблением
ресурсов.
Здесь нужно отметить, что на уровне домена Аналитики данных не принимается никаких решений. Домен отвечает за подготовку продукта данных и использует набор функций машинного обучения для обогащения продукта необходимой информацией для последующего принятия решения о рекомендованном предложении.
Можно предположить, что если бы у Yota было множество разнообразных тарифных линеек, то вряд ли бы была возможность однозначно определить какую из тарифных линеек рекомендовать. Причина банальна большинство линеек других операторов не отличаются друг от друга ничем, кроме как новыми правилами ценообразования за одинаковый набор услуг. Yota несколько лет назад перешла на единую линейку, определив единые правила ценообразования на всем множестве доступных услуг связи и ресурсов потребления.
Yota, используя эту концепцию, первой запустила гибкий конструктор услуг связи с возможностью выбора необходимого объема ресурсов потребления с точностью до минуты и гигабайта. В домене Управления продуктами определенное коммерческое предложение формируется на основании формулы, которая вычисляет цену в зависимости от выбранного количества минут и гигабайтов.
Нулевой фазой продукта Максимум на первый месяц можно считать
проект по реализации пресетов в продуктовом каталоге. Идея проекта
была в том, чтобы поддержать тех клиентов, которые не готовы к
тонкой настройке конструктора и предпочитают сделать выбор из
конечного набора предлагаемых пакетов. Пресет с точки зрения
каталога спецификация конкретного предложения, которая может быть
получена витриной (например, Мобильным приложением) и использована
для предложения пакета по умолчанию.
Идея получила свое развитие в акции, выраженная в том, что на
первый месяц клиент может подключить максимальный пресет (2000
минут и безлимитный интернет), а по истечении месяца компания будет
предлагать рекомендованный пресет ресурсов, рассчитанный на основе
статистики потребления и преднастроенных бизнес-правил.
Информационное взаимодействие по генерации предложения
инициируется в биллинговой системе.
Биллинговая система и PCRF система контроля потребления трафика в
нашем случае являются системами, в которых инстанцируются
продукты-накопители. Но именно биллинговая система определяет, на
каком этапе жизненного цикла находится тот или иной продукт у
определенного клиента, актуализируя состояние накопителя
интернет-трафика в PCRF через mediation device. Фактически домен
Управления продуктами определяет политики инстанцирования и
оркестрирует работу с продуктами на платформах, обеспечивающих
жизненный цикл продукта.
Биллинговая система знает, когда наступает момент для генерации
рекомендованного предложения и отправляет соответствующее событие,
на которое подписан диспетчер формирования рекомендованного
пресета.
Считаю, что движок бизнес-правил является неотъемлемой частью
событийно-ориентированного ландшафта любой продуктовой компании.
Это утилитарный (платформенный) высоконагруженный сервис, который
слушает события на входе и быстро возвращает ответ выполнен или нет
требуемый набор бизнес-правил, исходя из контекста состояния
клиента. Он также должен обладать возможностью предоставлять
изолированные репозитории для настройки самих правил всем
автономным продуктовым командам, таким как Смартфон, Модем, Финтех,
B2B и другим.
Движок используется для определения доступности коммерческих
предложений, определения выполнения клиентом условий маркетинговых
кампаний и во многих других сценариях использования, являясь одной
из центральных платформ IT-ландшафта.
Точность и своевременность предложений является в современном
мире основополагающим фактором, определяющим гибкость бизнес-модели
компании, укрепляющим лояльность клиентов, позволяющим
трансформироваться с точки зрения восприятия на рынке из
продуктовой в клиенто-ориентированную компанию с конвергентным
продуктовым предложением.
Этот фактор движет развитием доменов Управления продуктами и
Вычисления контекста состояния клиента высокими темпами в сторону
имплементации федеративного продуктового каталога и обеспечения
возможности подключения внешних продуктовых федераций, а также
обеспечения возможности сборки контекста состояния клиента и
отправки его на внешние движки бизнес-правил. В итоге это движение
позволяет с одной стороны расширить продуктовое портфолио, а с
другой предоставить собственные каналы для дистрибуции сторонних
продуктов, таких как подписки на онлайн-кинотеатры, стриминговые
музыкальные сервисы и другие продукты.
Продолжим тему генерации рекомендованного предложения.
Диспетчер, получая событие, сигнализирующее о необходимости расчета
предложения, отправляет запрос на движок бизнес-правил, получает
ответ о выполнении набора правил и формирует рекомендованный
пресет. Движок в нашем случае не только информирует об успешности
выполнения правил (true/false), но и сообщает вычисленные значения
ресурсов для формирования пресета, используя правила-формулы и
подготовленный продукт данных доменом Аналитики данных в качестве
базисных значений для расчета.
По факту формирования рекомендованного пресета диспетчер отправляет
событие, получаемое доменом Систем информирования. Основным
компонентом данного домена является процессор динамической сборки
сообщений. Процессор собирает сообщение для информирования и
отправляет его по каналам взаимодействия с клиентом, таким как
пуш-сообщение в Мобильном приложении и SMS.
Завершающее действие это подтверждение клиентом в Мобильном приложении, что он принимает рекомендованное предложение. В этом случае предлагаемый пакет ресурсов будет запланирован для изменения, начиная со следующего расчетного периода. Альтернативный сценарий, если клиент по каким-то причинам не согласен с предложением, переход в режим изменения условий, где он может самостоятельно выбрать необходимые значения пакета ресурсов. В обоих случаях выбранные значения пакета ресурсов передаются обратно в домен Управления продуктами, который обеспечивает планирование новых условий в биллинговой системе.
Резюмируем основные положения статьи:
Всем привет! Встречайте свежий дайджест ссамыми сочными статьями замай.
Вскобках возле заголовков уровень сложности статьи (Normal * Hard ** Expert ***) ипримерное время наизучение материала
Подкаст. MBA220: Thoughtless Design with Karl Wiegers(**, 32мин). Карл Вигерс продолжает радовать нас своим опытом. Вэтот раз онделится принципами иуроками, которые извлек изнекачественного дизайна, атакже рассказывает, чтоВы можете сделать, чтобы помочь всоздании дизайна.
Нужнали сертификация для бизнес-аналитика?(**, 10мин). Все осертификацииВА: список популярных, какие преимущества каждая даёт инужнали сертификация вообще.
Docs asCode: введение впредмет(**, 21мин). Автор делится многолетним опытом, приобретенным напути кDocs asCode, атакже рекомендациями повнедрению этого фреймворка.
Business Analyst: Tools and Principles for Professional Self-Development(*, 16мин). Структурированный набор материалов, который поможет обнаружить изаполнить пробелы всвоих навыках. Статью готовил аналитик с15+лет опыта, всоавторстве сдругими опытными БА.
Как проводить интервью сзаказчиком(*, 11мин). Кирилл Белявский делится секретом проведения успешных интервью.
User Experience inProduct(*, 8мин). Как исследования ианализ пользователей помогут увеличить значимость вашего продукта для конечных пользователей.
Моделирование данных: обзор(**, 6мин). Встатье автор раскрывает понятие моделирование данных, атакже делится оптимальной пошаговой инструкцией поприменению.
Цикл статей про бизнес-анализ напресейле. Статья первая, или почему всем нужен БА?(*, 5мин). Старт цикла статей ороли изадачах бизнес-аналитика напресейле. Впервой части: что такое пресейл, роль ивлияние бизнес-аналитика наэтом этапе, артефакты, которые могут понадобиться.
Этический антидизайн. Разработка продуктов, которые невызывают привыкания(*, 6мин). Оглавных принципах антидизайна, атакже когнитивных искажениях, которые располагают кзалипанию набесполезной/произвольной информации.
SCRUM: Гибкое управление продуктовыми направлениями(*, 9мин). Третья часть изцикла статей, окотором говорил впрошлом дайджесте. Вэтой части предложена система метрик для измерения ианализа процесса гибкого управления продуктовыми направлениями.
Frustrating Design Patterns That Need Fixing: Birthday Picker(*, 16мин). Подробный обзор неудачных шаблонов проектирования поля для выбора даты рождения.
Как работать сбэклогом иприоритизацией фич взрелом продукте(*, 8мин). CTO одной изпродуктовых компаний делится опытом приоритезации фич врамках канбан-процесса.
Three Levels ofPain Points inCustomer Experience(*, 8мин). Что такое болевые точки вклиентском опыте, накаких уровнях взаимодействия возникают ипонять какие наиболее критичны.
Left-Side Vertical Navigation onDesktop: Scalable, Responsive, and Easy toScan(*, 12мин). Статья овесьма непривычном подходе кпостроению навигации, когда она находится невшапке сайта, анаместе левой боковой панели: каким доменам подходит, преимущества ирекомендации поиспользованию.
Все, что выхотели знать про диалоговый UX/UIв проектировании чат-ботов(*, 9мин). Встатье покрыто определение диалогового UX/UI-дизайн, есть пошаговые рекомендации счего начать, атакже годные лайфхаки для проектирования сценариев для чат-бота.
Какие рефералки работают: сбонусами для себя, для того парня или для обоих? Исследование(*, 4мин). Саммари исследования видов рефералок.
The role ofpassword verification atsign up(*, 7мин). Анализ практик реализации поля ввода пароля.
UX-Roadmapping Workshops: Agenda + Activities(**, 16мин). Содержательная статья осоздании дорожных карт UX.
6способов снизить когнитивную нагрузку отинтерфейса(**, 12мин). Если вычувствуете, что ваш интерфейс перегружен, тоэта статья подкинет вам инсайтов отом, как сохранить нервные клетки ваших пользователей.
UI& UXmicro-tips: Volume five(*, 4мин). Коллекция небольших, нополезных подсказок поUI/UX.
Привет, самое хардовое IT комьюнити Рунета! Я Саша, главный архитектор в компании Quadcode. Мы пришли на Хабр для того, чтобы показать кухню Fintech варимся мы во всем этом 8 лет, поэтому уже можем поделиться опытом. В своем блоге будем рассказывать об архитектурах, технологиях, инструментах и лайфхаках.
Этот пост первый в списке, его можно считать знакомством. Под катом я расскажу про структуру нашей команды, про продукты Quadcode это платформа для трейдинга, банкинг и внутренние разработки, а также про наши первые шаги на пути к IPO.
Команда Quadcode уже 8 лет работает в финтехе. Цель компании создавать удобные финтех-инструменты для B2B клиентов со всего мира.
В разработке мы руководствуемся Agile принципами, да и в принципе склонны к гибким методологиям. Именно они позволяют достигать баланса в скорости и качестве разработки продуктов, поэтому разработка представляет из себя набор Scrum команд.
Во главе каждой команды стоит Team Lead. Сами команды сгруппированы в отделы, работающие над определенными предметными областями. Например, есть отдел Finance Development, в котором команды разрабатывают финансовые сервисы для платформы. Есть ветка, где располагаются владельцы продукта (product owners), задача которых развивать и улучшать наши продукты. Сейчас у нас в разработке 230+ опытных (реально опытных, у каждого много лет практики) специалистов. Это порядка 24 команд и 6 Product Owners. Джуниоров мы берем редко. Но с каждым годом искать опытных специалистов становится все сложнее, так что все больше в эту сторону смотрим.
Задачи по разработке выстраиваются на основе продуктовых Roadmap. Это план развития продукта с целью получения определенных бизнес-показателей. Роадмап выстраивается для каждого продукта и может быть составлен на разные временные промежутки: полгода, год, три года и т.д. Из готовых продуктовых роадмапов выстраивается общий план: когда, какие фичи и для каких продуктов должны быть сделаны.
Роадмап в нашем понимании это связующее звено между бизнесом, продуктом и разработкой.
Каждый квартал происходит важное событие в жизни компании квартальное планирование. Из общего таймлайна выделяются фичи, которые нужно реализовать в первую очередь. В итоге получается план того, что мы действительно можем сделать текущими ресурсами. Мы не приветствуем авральный стиль, поэтому учимся ловить дзен и находить оптимальный баланс между работой и личной жизнью. Каждый сотрудник может зайти и посмотреть роадмап компании, чтобы правильно спланировать и распределить свое время на важные и интересные задачи.
Работаем удаленно или в офисе в Санкт-Петербурге каждый выбирает самостоятельно. Я для себя выбрал работу из дома, но по офису тоже скучаю, он у нас классный с тренажерным залом, массажным кабинетом и прочими плюшками.
Наши основные языки для разработки Golang и C++. Из дополнительных технологий на бэкенде PHP, Python, NodeJS, на фронте JavaScript (ReactJS), в аналитике Python, Scala, а в автотестах Java.
Инфраструктура в компании гибридная. Мы арендуем собственные сервера в датацентрах. Все stateless приложения стараемся эксплуатировать в Kubernetes, если для этого нет ограничений, хотя бывает и такое. Kubernetes-кластера также преимущественно работают на наших серверах. То, что требует гарантированных ресурсов, например нагруженные базы данных, мы эксплуатируем на железе. Конечно, используем и облака там, где это приносит пользу. Например в задачах, где требуется обработать большое количество данных, чтобы предоставить отчет заказчику. Для таких задач нужно временно получить ресурсы для анализа, но после получения результата они не нужны.
Для точечных целей применяем технологии, которые позволяют решить специфические задачи. Например, наше Desktop приложение под Windows, Mac и Web написано на С++ и имеет единую кодовую базу. В данном случае С++ дает нам кроссплатформенность и отличную производительность при рендере графики. Однако мы практически не используем С++ для Backend разработки, потому что это дорого. Основной язык разработки для Backend у нас Go. В то же время мы не используем его как инструмент для тестирования. Для этих целей применяем Java, так как это намного удобнее и является уже практически промышленным стандартом в индустрии.
Наш флагманский продукт платформа для трейдинга. За 7 лет развития количество пользователей платформы выросло с 950 тысяч до 88 миллионов в 170+ странах.
Начиная с 2020 года развиваем трейдинговую платформу как SaaS решение, на базе которого любой желающий может организовать собственного брокера. И у нас уже есть первые клиенты в этой области.
Кроме того планируем расширять географический охват, выходить на новые рынки. Для этого обновляем платформу с учетом всех технических и юридических требований конкретных регионов. Все это поможет нам выйти на IPO.
А теперь кратко о наших продуктах:
Команда с нуля разработала платформу с аптаймом 99.5%, на базе которой более 7 лет успешно функционирует брокер.
Платформа предоставляет клиенты под Windows, MacOS, Anrdoid, iOS, а также WEB трейдрум.
На платформе можно торговать следующими инструментами:
Digital опционы
FX опционы
CFD
Forex
Crypto и др.
Основной язык для разработки платформы Golang. Платформа начала свое существование с монолитной архитектуры классического для своего времени стека: PHP+PostgreSQL+Redis+JS.
Через 3 года эксплуатации было решено перейти на микросервисную архитектуру, так как монолит уже не давал гибкости и не мог обеспечить необходимые темпы разработки. С миграцией на микросервисную архитектуру мы также ушли с PHP в сторону Go, о чем не жалеем.
Go отличный язык, обеспечивающий хорошую производительность с довольно небольшим порогом входа. Для разработки микросервисов просто идеальный кандидат.
С прошлого года наша платформа развивается как SaaS решение. На базе решения любой желающий может без больших усилий организовать своего собственного брокера, все есть в коробке под ключ: трейдинговый сервис, процедуры KYC, биллинг, support, crm. Словом, все, чтобы быстро стартануть бизнес. Любого нового брокера можно поднять за месяц. Чтобы обеспечить вариативность в функционале, мы разрабатываем гибкую систему модулей для SaaS-решения.
* Для того, чтобы наглядно объяснить, что такое SaaS, и показать, куда мы в итоге хотим прийти, приведем пример с пиццей. Это так называемая модель Pizza-as-a-service, вкусно и полезно.Команда Quadcode обеспечивает внутренний риск менеджмент, бэк офис и антифрод поэтому брокеру не нужно думать обо всем этом. В итоге клиент получает полностью работающее кросс-платформенное решение. Мы также решили вопрос с регистрацией и авторизацией. Вся IT поддержка лежит на наших плечах. Мы помогаем с построением лигал структуры и во многом другом.
Сейчас добиваемся того, чтобы в экосистеме платформы был максимально широкий спектр инструментов: Forex, СFD и инвестиционные продукты в удобной для пользователя форме. Идеальный вариант сделать платформу подходящей как для банков, так и для их клиентов. Мы собираем паззл продукта из мельчайших деталей. Процесс этот не такой быстрый, но пока все получается. Быстро и не получится ни в правовом плане, ни в плане технологий.
Примеры задач, которые стоят перед командой в этом году:
Конфигуратор платформы. В качестве примера возьмем конфигуратор сборки машин BMW. Вы можете зайти на сайт и собрать свой автомобиль, то есть выбрать цвет, диски, дополнительные возможности. Мы хотим сделать точно такой же функционал, только с возможностью сборки своего брокера прямо на сайте.
Также один из крупных проектов это разработка собственного движка Margin Forex & MCFD.
Проработка Prediction Churn. Фича основана на анализе данных и предсказывает момент, когда пользователь решит уйти. Сейчас результат Prediction Churn достоверен с вероятностью 82%. Когда система предсказывает, что пользователь готов уйти с платформы,в работу включаются менеджеры, чтобы создать удобные для трейдера условия работы на платформе. Это позволяет продлить срок работы с трейдером. Чем дальше, тем точнее будет работать Prediction Churn, и тем лучше мы сможем держать контакт с пользователем.
Это второй наш продукт. В основе направления находится собственный лицензированный провайдер финансовых услуг, который зарегистрирован в Великобритании. Продукт предоставляет следующие функции B2B и B2C клиентам:
Дистанционный онбординг для физических и юридических лиц.
Доступ к счету через мобильное приложение и онлайн-банкинг.
Мультивалютные счета в формате IBAN.
SEPA, TARGET2 и SWIFT переводы.
Выпуск пластиковых и виртуальных карт.
Технологический стек классический: ядро системы работает под управлением JAVA. А также применяется PHP+JS для реализации административных интерфейсов управления и web приложений.
В ближайших планах дополнить продукт новыми локальными и альтернативными методами платежей, встроить дополнительные банковские продукты, выстроить партнерские программы, включая программы вознаграждений и бонусов для существующих и потенциальных клиентов. Расширенный функционал позволит выстроить разветвленную сеть каналов для того, чтобы максимально упростить обработку трансграничных платежей по всему миру и оказывать клиентам наиболее полный спектр услуг.
Помимо проектов, напрямую завязанных на прибыль и клиентов, вкладываемся в разработку собственных решений, чтобы обеспечить удобную и гибкую профессиональную среду для работы сотрудников.
Из наиболее интересных можно выделить следующие:
Шина данных IQ Bus. Мы исповедуем микросервсиную архитектуру. В самом начале, когда возник вопрос, а что выбрать для обеспечения коммуникации между микросервисами, мы решили создать свое решение IQ Bus. Это шина, которая абстрагирует сервисы от транспортного уровня и предоставляет им простой унифицированный протокол для общения.
Sandbox. В сложных многокомпонентных, а в нашем случае системах с большим количеством сервисов, всегда возникает проблема с тестированием. Важно иметь возможность получать воспроизводимое окружение для тестирования, так называемые тестовые стенды. Еще в самом начале пути мы создали Sandbox систему, с помощью которой можно собирать копии платформы с различными конфигурациями. Это своего рода конструктор, куда можно зайти, выбрать какая функциональность нужна - будет создана сборка, запущены необходимые микросервисы и можно тестировать. Все это работает на базе Docker + Kubernetes.
Central Information System. Всегда возникает необходимость в инструменте, который может объединить в себе все системы компании. Речь не только про разработку, но и про КДП, HR, Финансовый отдел. Такая система должна помогать находить ответы на различные вопросы. Например, что за команда такая A, какие у нее сотрудники, кто руководитель, какой у нее ФОТ, что она сделала за прошедший квартал. И плюс еще много всяких индивидуальных хотелок. Найти такой продукт, имеющий в себе все, достаточно проблематично, да и выглядят такие системы довольно монструозно. Хороший пример SAP. Мы же вкладываемся в собственную разработку такой системы, которая реализует все потребности различных отделов и интегрируется с другими системами: Gitlab, таск трекер, финансовые системы (1C).
За 2020 мы проделали большой путь по разработке SAAS решения и внедрения нового банкинг продукта, сейчас появилось еще несколько важных целей. Компания использует стратегическое планирование, мы движемся в сторону присутствия на рынках всех стран, удвоения показателя EBITDA и выхода на IPO.
В будущих статьях на Хабре мы расскажем более подробно о нашем подходе к разработке, планированию и работе с командами. Вместо рекламной паузы ссылка на наши вакансии. Если остались вопросы, то пишите в ТГ @wolverinoid.
Важный момент этот пост является знакомством, о чем и говорилось выше, поэтому здесь так много мы, нам и т.п. Все будущие статьи, которые станем публиковать, готовятся с прицелом на то, чтобы поделиться опытом и знаниями, которые могут оказаться полезными всему сообществу. Ведь Хабр для этого и создан, верно?
Статья раскрывает тему прямых и косвенных механизмов развития сотрудников и продуктовых команд внутри компании. К прямым механизмам относятся коучинг, менторство, терапия, тренинг и консультация, спонсируемые и поддерживаемые на уровне руководства компании. К косвенным относятся такие механизмы, как культура фасилитации встреч и мероприятий, а также проявляемые стили управления в зависимости от ситуации. Проявление косвенных механизмов зависит от знаний и опыта сотрудников с руководящей функцией как лидера мнения.
В статье предложена система метрик для измерения и дальнейшего анализа атрибутов сложившейся системы развития сотрудников внутри организации.
Остальные части программы оценки готовности к
трансформации:
SCRUM: Понимание и применение
фреймворка
SCRUM: Разработка и поставка продукта
SCRUM: Гибкое управление продуктовыми направлениями
Способ и характер организации встреч внутри группы людей определяет возможность личностного и командного роста. Фасилитация - искусство направления групповой дискуссии в конструктивное и продуктивное русло. Фасилитатор отвечает за планирование и организацию необходимого процесса, когда как группа людей отвечает за предоставление содержания с учетом своей экспертизы. Фасилитация помогает организовать события ориентированные на достижение цели в рамках эффективного использования времени, а также вовлечения участников в дискуссию (предоставление возможности всем высказать свое мнение, создание атмосферы где можно быть услышанным, создание атмосферы где владеешь принятыми решениями).
Характеристика |
Метод исследования |
Метрика |
Роль фасилитатора |
Наблюдение за выделением роли фасилитатора в компании |
отсутствует выделение и признание роли на уровне компании - 0 баллов роль фасилитатора проявляется у сотрудников с не руководящими функциями - 1 балл сотрудники с руководящими функциями выполняют роль фасилитатора - 3 балла присутствует выделение и признание роли на уровне компании - 5 баллов |
Знания фасилитатора |
Наблюдение за проявлением знаний фасилитатора в рамках: - Цель события |
слабо развития система знаний фасилитатора - 0 баллов сильно развития система знаний фасилитатора - 5 баллов |
Навыки фасилитатора |
Наблюдение за проявлением навыков фасилитатора: - Ясное выражение мыслей |
слабо развития система навыков фасилитатора - 0 баллов сильно развития система навыков фасилитатора - 5 баллов |
Правила организации |
Наблюдение за проявлением правил организации и проведения событий: - Цель события и ожидаемый результат; |
Правила фасилитации не устанавливаются - 0 баллов Правила фасилитации устанавливаются для событий - 3 балла Для периодических событий , правила зафиксированы в едином месте (например confluence) - 5 баллов |
Техники фасилитации |
Наблюдение за проявлением различных техник при фасилитации событий: - Брейншторминг |
техники фасилитации не выделяются и не используются - 0 баллов ограниченное использование техник фасилитации - 3 балла проявление гибкости в использовании техник фасилитации в зависимости от ситуации - 5 баллов |
[ 0 - 19] - низкий результат, характеризующий слабо развитую культуру фасилитации событий в компании. При данном результате выделяется директивный способ организации, целью которого является трансляция задач от сотрудников с руководящими функциями без процессинга и обсуждения с исполнителями. Рекомендуется разработать программу в разрезе культивации философии фасилитации на уровне среднего менеджмента компании.
[20 - 25] - высокий результат, характеризующий устоявшуюся культуру фасилитации событий внутри компании, целью которой является создание удобных механизмов для владельцев содержания. Данный способ организации событий предоставляет модель встреча-развлечение, на которой у участников формируются доверительные отношения, целеполагание и вовлеченность в ожидаемый результат. При данном результате рекомендуется сделать акцент на развитие личностных характеристик сотрудника с функциями фасилитатора.
Наличие в компании гибкой системы практик личностного и командного роста позволяет сформировать и укрепить устойчивую позицию HR-бренда, в которой сотрудник видит горизонт своего развития в контексте развития компании. Можно выделить следующие методы развития продуктовых команд:
Коучинг - метод тренировки, в процессе которой, устанавливаются цели для достижения. В свою очередь, коуч-тренер помогает команде достигнуть данные цели, используя знания предметной области, навыки межличностного общения и фасилитации.
Менторство - метод тренировки, при которой, происходит трансляция шаблона знаний и опыта от спонсора-ментора для формирования необходимых паттернов профессионального поведения. Для успешной реализации данного метода, необходимо наличие у ментора ярко выраженной экспертизы в предметной области и лидерские качества.
Терапия - метод, позволяющий сотруднику или продуктовым командам снять с себя психологические или физические симптомы профессиональной нагрузки с помощью выстроенного доверия и возможностью быть услышанным.
Тренинг - метод, при котором эксперт в предметной области делиться своим знанием и опытом с применением разработанных методических материалов. Целью данного процесса является предоставление новых знаний и инструментов для группы сотрудников за короткий промежуток времени.
Консультация - метод, позволяющий функциональным подразделениям компании или продуктовым направлениям получить независимую оценку эксперта для решения бизнес проблемы в части организации работ производственных направлений.
Характеристика |
Метод исследования |
Метрика |
Коучинг |
Наблюдение за принципом целеполагания команд продуктовых направлений |
отсутствует роль, которая помогает команде ставить и достигать цели - 0 баллов команда проявляет принцип самоорганизации для установки цели - 1 балл выделяется роль коуча, которая помогает команде ставить и достигать цели - 3 балла выделяется роль коуча, признанная на уровне компании, которая помогает команде ставить и достигать цели - 5 баллов |
Менторcтво |
Наблюдение за проявлением данного метода при адаптации нового сотрудника или горизонтальном карьерном росте |
отсутствует роль, которая помогает адаптироваться сотрудникам - 0 баллов проявление принципа самоорганизации при адаптации - 1 балл выделяется роль ментора, которая помогает сотруднику с адаптацией - 3 балла выделяется роль ментора, признанная на уровне компании, которая помогает сотруднику с адаптацией - 5 баллов |
Терапия |
Наблюдение за существованием механизмов психологической разгрузки |
сотрудники не привыкли делиться переживаниями - 0 баллов у сотрудников есть неофициальные каналы, где они могут поделиться переживаниями - 1 балл у сотрудников есть официальные каналы, где они могут поделиться переживаниями с возможностью быть услышанными компанией - 3 балла выделяется роль сотрудника к которому можно обратиться за поддержкой и психологической разгрузкой - 5 баллов |
Тренинг |
Наблюдение за подходами обмена знаниями и опытом внутри компании |
внутри компании тренинги не проводятся - 0 баллов тренинги имеют несистемный характер проведения - 1 балл существует комьюнити экспертов для проведения тренингов - 3 баллов существует комьюнити экспертов, поддерживаемого компанией, для проведения тренингов - 5 баллов |
Консультация |
Наблюдение за подходами обмена знаниями и опытом снаружи компании |
компания замкнулась в себе и ограничивает общение с внешним миром в части развития собственных подходов - 0 баллов компания принимает активное участие в семинарах и воркшопах - 3 балла компания принимает активное участие в семинарах, существуют партнерские отношения с проверенными консультантами - 5 баллов |
[ 0 - 10] - низкий результат, характеризующий отсутствие у компании осмысленного подхода к развитию и адаптации кадров. В случае динамической среды стартапа, может наблюдаться эмоциональное выгорание сотрудников на горизонте испытательного срока; в случае умеренной корпоративной среды, наблюдается проявление низкой культуры развития сотрудников, как осознанный выбор компании для снижения затрат рынка низкотехнологичной продукции. При данном результате, целесообразность разработки программы обусловлена видением инвесторов в части долгосрочности нахождения компании на рынке, а также высокотехнологичностью продукции.
[11 - 20] - средний результат, характеризующий ограниченный набор методов развития продуктовых команд или не системность их использования. В случае динамической среды стартапа, может наблюдаться эмоциональное выгорание сотрудников на горизонте одного года; в случае умеренной корпоративной среды, может проявляться фрустрация и стагнация в развитии профессиональных навыков и знаний у сотрудников. В первую очередь, рекомендуется сделать акцент на развитие менторства и системы тренингов для сотрудников.
[21 - 25] - высокий результат, характеризующий зрелую систему развития и поддержки продуктовых команд. В арсенале компании имеются все доступные методы для формирования у сотрудников необходимого проактивного паттерна отношения к труду, новых навыков и знаний. При данном результате, компания осознаёт необходимость инвестицией в человеческий ресурс, так как он является потенциалом роста продуктовых направлений. Рекомендуется рассмотреть создание образовательного комплекса (аналоги GeekBrains, SkillFactory и т.д.) в периметре компании в целях становления и развития кадрового резерва.
Подходы и стили лидерства определяют развитие команд в сторону директивного и процедурного или кооперативного и творческого взаимодействия. В силу того, что лидеры являются агентами изменений, их особенности личности и темперамента будут проецироваться на выстраиваемые процессы в продуктовой команде. Компании необходимо тщательно относиться к подбору сотрудников с руководящими функциями с позиции ярко выраженных стилей лидерства.
Характеристика |
Метод исследования |
Стиль коуча |
Наблюдение за проявлением следующих особенностей у сотрудников с руководящей функцией: - оказывает поддержку сотрудникам |
Стиль идеолога |
Наблюдение за проявлением следующих особенностей у сотрудников с руководящей функцией: - настойчивый |
Стиль слуги |
Наблюдение за проявлением следующих особенностей у сотрудников с руководящей функцией: - мотивация команды |
Стиль автократа |
Наблюдение за проявлением следующих особенностей у сотрудников с руководящей функцией: - самоуверенность |
Стиль невмешательства |
Наблюдение за проявлением следующих особенностей у сотрудников с руководящей функцией: - проявление эффективного делегирования |
Стиль демократа |
Наблюдение за проявлением следующих особенностей у сотрудников с руководящей функцией: - ценит групповую дискуссию |
Стиль темпа |
Наблюдение за проявлением следующих особенностей у сотрудников с руководящей функцией: - устанавливает высокие стандарты профессионализма |
Стиль трансформатора |
Наблюдение за проявлением следующих особенностей у сотрудников с руководящей функцией: - имеет уважение со стороны команды |
Cтиль операционный |
Наблюдение за проявлением следующих особенностей у сотрудников с руководящей функцией: - ценит корпоративную структуру |
Cтиль бюрократа |
Наблюдение за проявлением следующих особенностей у сотрудников с руководящей функцией: - ориентированный на детали и задачи |
Определение интегральной шкалы оценки свойства стили лидерства не целесообразно, в связи с тем, что каждый стиль имеет место быть в зависимости от конъюнктуры и ниши рынка, которую занимает компания.
Стоит отметить, что для компаний-стартапов, специализирующихся на выпуске новых продуктов на рынок для поиска устойчивой бизнес модели необходимо иметь самоорганизующуюся рабочую среду с идеологией, креативностью и свободой мысли. Для создания и поддержки данной среды, отлично подойдут лидеры мнения со следующими стилями: стиль идеолога, стиль слуги, стиль трансформатора, стиль темпа.
В свою очередь, компании, нащупавшие устойчивую бизнес модель для своего продукта начинают искать возможности для его масштабирование на новые рынки и новых клиентов. Для осуществления данных целей, хорошо подойдут следующие стили лидерства: стиль коуча, стиль невмешательства, стиль демократа по отношению образованных продуктовых команд на этапе стартапа.
Для развития продуктовых команд, противопоказано иметь лидеров с ярко выраженными стилями: стиль автократа, стиль операционный, стиль бюрократа. Данные стили будут сдерживать развитие продуктового направления и развитие самоорганизующихся команд из-за особенностей внутренних качеств лидера.
MVP (minimum viable product) - это первая версия вашего продукта, с помощью которой вы, как создатель продукта:
подтверждаете гипотезу о необходимости конкретного решения, опираясь на поведение пользователей;
собираете обратную связь от ваших будущих пользователей;
пытаетесь продать (или уже продаёте) ваше решение пользователям.
Пройдёмся по этим пунктам.
Возьмём в качестве примера не сложный IT-продукт, а самый обычный, бытовой предмет: швейцарский нож.
Однажды люди нащупали гипотезу, которая могла явиться проблемой: что если я оказываюсь в диком лесу, и мне нужно срезать гриб и отметить это, выпив бутылку шампанского? Носить с собой штопор и нож - попросту неудобно (да и кто в здравом уме берёт с собой в лес штопор?). Что, если объединить эти инструменты в одно?
Эти люди (назовём их фаундерами) попробовали совместить штопор и нож в одном инструменте, создали первый прототип (получилось криво и неудобно, но годно), и попытались продать будущим клиентам.
Представим, что у них это получилось. Что им делать в таком случае?
продолжать продавать текущее решение, параллельно добавляя туда новые инструменты (функции), опираясь на обратную связь и пожелания покупателей;
совершенствовать текущее решение, делать его более удобным (работать над UX);
собирать обратную связь от пользователей и корректировать продукт.
Но всё получается с первого раза только у создателей швейцарских ножей. В реальной жизни 42% стартапов умирают от отсутствия спроса. Каждый раз фаундеры могут заходить на рынок с новым набором инструментов (пробовать разные гипотезы), либо, если всё идет наперекосяк - менять бизнес модель (сделать Pivot).
С каждой версией швейцарского ножа, нашим фаундерам нужно как можно быстрее выпустить образец на рынок, чтобы услышать обратную связь от покупателей.
Как это можно сделать?
Производить и пытаться продать совсем маленькие партии;
Экономить на качестве (но не так, чтобы получилось совсем плохо).
Именно такой подход: быстро создать решение, протестировать на пользователях, услышать обратную связь, и выйти на второй цикл улучшения продукта (или на смену бизнес-модели) и можно назвать MVP-подходом.
Гипотеза - это предположение о проблеме клиента.
В одной версии продукта стоит тестировать только одну гипотезу за раз. При этом гипотеза должна быть смелая. Хотят ли люди есть грибы? Определенно да! Готовы ли пить шампанское? О да! Но может ли кому-то внезапно понадобится и нож, и штопор одновременно? Это уже гипотеза, которую стоит протестировать!
Теперь перейдём к тому, что можно включить в первую версию продукта. Ответ прост: нужно включать те функции, которые:
1) работают на проверку ключевой гипотезы. Не добавлять в швейцарский нож сам нож - кощунство;
2) дают наибольшую ценность для пользователя. Да, в швейцарский нож можно напихать ещё и трекер шагов, и bluetooth колонку, но основную ценность в нашем примере имеет нож и штопор.
Все функции, которые не удовлетворяют этим требованиям, можно смело оставлять на будущее.
Можно ли подтвердить гипотезу относительно продукта, совсем не создавая никакого решения?
В IT-сфере - можно, если быть чуть хитрее и умнее, чем наши фаундеры из примера.
К примеру, они могли создать лендинг Чудо Швейцарские Ножи, повести на него трафик из социальных сетей, и посмотреть, оформляют ли люди предзаказ на этот товар. Если да - то его можно производить.
Примеров таких предзапусков в истории множество, но вот мой любимый:
Около 2-х лет создатели таск-менеджера Sunsama запустили на главной странице анкету, в которой опрашивали рабочие привычки будущих пользователей (сколько человек в команде, каким таск-менеджером пользуются сейчас, где хранят задачи и т.д.). Когда вышла первая версия продукта, доступ получили только те, кто подошёл в качестве целевой аудитории этого продукта. Таким образом создатели Sunsama убили трёх зайцев одним махом: исследовали аудиторию, получили первых последователей и подогрели интересы прочих, кто доступ не получил.
К слову, я даже пытался подобрать правильные ответы к анкете, чтобы получить доступ. И у меня это получилось! Но то, что оказалось внутри, мне уже было не интересно (не зря же я подбирал ответы).
Автор книги Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели Эрик Рис говорит, что MVP с первого дня должен продавать. И я с ним абсолютно согласен.
Мы создаем продукты не только для того, чтобы решать проблемы и делать мир лучше, но и чтобы зарабатывать деньги. Если у вас есть инвестиции и собственные запасы, чтобы оплатить работу дизайнеров и разработчиков на долгие годы вперёд (чтобы впоследствии монетизировать платформу), это прекрасно. Если нет продукт должен начать приносить вам деньги уже сегодня (за счёт подписки на сервис, рекламы или взимания платы за интеграцию).
MVP - это непаханное поле для больших ошибок и слитых бюджетов!
Вот какие ошибки вы можете совершить по ходу пьесы:
Включать слишком много необязательных функций. Представьте, что вы Роден (со швейцарским ножом в руке), и без сожаления выбрасывайте то, что не даёт ценности вашему продукту и не поддерживает его жизнеспособность;
Не слушать обратную связь от пользователей. Если вы не проводите тестирования и не слушаете обратную связь от пользователей, то вообще непонятно, зачем вы затеяли MVP. Возможно, вам стоит сразу пилить полноценный продукт и оказаться без миллиона в кармане?
Слишком стараться. Есть выражение, что если вы показываете первую версию продукта, и вам не стыдно - то вы уже перестарались. Поверьте, у вас будет бесконечно много шансов улучшить ваш продукт, и делать сразу идеально вовсе не обязательно!
Недостаточно стараться. Можно придумать отличную идею совместить нож со штопором, но если сделать это в стиле и таааак сойдёт!, то вы рискуете, что ваш пользователь окажется без руки, пользуясь вашим чудом техники. Перефразирую: в 21 веке уже недостаточно сделать косое и кривое приложение. Аппетиты и желания клиентов растут, поэтому постарайтесь, чтобы ваша первая версия выглядела хотя бы симпатично.
Влюбиться в продукт. Возможно, посреди разработки вам придется сменить концепцию. Возможно, вам придётся пожертвовать функциями, которые вам были так близки! А возможно, и весь продукт придётся прикрыть. Не влюбляйтесь в ваш продукт, иначе любые изменения будут даваться с трудом. Держите голову холодной, будьте гибкими, слушайте ваших пользователей. Помните, что подкидывать вам проблемы и задачи - это их основная работа.