Русский
Русский
English
Статистика
Реклама

Управление продуктом

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

01.06.2021 16:23:51 | Автор: admin
Проект гораздо богаче, чем кажется.



Некоммерческая организация Wikimedia Foundation (WMF), которая владеет Википедией и другими сайтами UGC, вот-вот достигнет десятилетней цели: собрать $100 млн в долгосрочном резерве Wikimedia Endowment. Это произойдёт на пять лет раньше, чем планировалось. Объём чистых активов (net assets) составляет около $200млн по состоянию на июнь прошлого года. Сейчас уже около $300млн. Доходы непрерывно растут. Согласно внутренним документам, за первые девять месяцев текущего финансового года фонд собрал пожертвований на $142 млн и уже побил рекорд прошлого года.

Эта информация может удивить доноров и пользователей по всему миру, которые видели баннеры для сбора средств в Википедии. Их показывают в разное время в разных странах. В прошлом году их впервые начали крутить в Индии. В настоящее время эти баннеры показывают жителям охваченной пандемией Латинской Америки. Они создают впечатление, что WMF с огромным трудом поддерживает Википедию в рабочем состоянии Послания жалобные: В этот четверг Википедия действительно нуждается в вас. Это уже десятое обращение, которое мы вам показали. 98% наших читателей не жертвуют, они отворачиваются Мы просим вас, пожалуйста, не надо скроллить от нас (We ask you, humbly, dont scroll away).

Согласно примерной оценке вице-президента по разработке WMF Эрика Меллера, в 2013 году для поддержки Википедии вполне хватило бы $10 млн. Что же делает WMF с остальной суммой? Средства идут на зарплату сотням сотрудников и в резерв на чёрный день. У фонда есть амбициозные планы стать инфраструктурой экосистемы свободных знаний. Поэтому он говорит читателям Википедии, что их деньги действительно нужны. Хотя организация сейчас богаче, чем когда-либо в своей истории.

В 2016 году WMF объявил о создании резервного фонда Wikimedia Endowment совместно с Tides Foundation. Это было в день 15-летия Википедии. Цель накопить $100млн в течение десяти лет в качестве постоянного источника финансирования для процветания Википедии в будущих поколениях.

Всего через пять лет фонд собрал более $90 млн, а начальной цели в $100 млн достигнет в этом году благодаря крупным пожертвованиям от Amazon, Google, Facebook и других компаний вкупе с традиционными пожертвованиями, а также $25 млн от самого WMF.

Примечательно, что пожертвования в резервный фонд не включены в отчётность по чистым активам WMF ($180 млн по состоянию на июнь 2020 года) или годовой доход ($130 млн). Однако деньги, которые WMF перечисляет в этот фонд, отражаются в статье расходов (Премии и гранты). Эти два факта скрывают, что WMF в течение последних пяти лет де-факто работает с гораздо большим профицитом, чем указано в финансовых отчётах. Отчёты показывают увеличение чистых активов за данный период всего на $100 млн. На самом деле общий объём средств WMF увеличился вдвое.

Wikimedia Endowment не единственные деньги, которые Wikimedia направляет в Tides Foundation. В прошлом году, когда у WMF буквально не знала, как распорядиться огромным объёмом финансовых поступлений, а общественные мероприятия были отменены из-за пандемии, она дополнительно перевела $8,7 млн в новый фонд Tides Advocacy.

Кроме того, WMF открывает коммерческую фирму под названием Wikimedia, LLC. Она будет продавать API-сервисы крупным технологическим компаниям, облегчая им обработку контента Wikimedia, включая контент для голосовых помощников, такие как Siri от Apple и Alexa от Amazon, а также инфобоксы в поисковой выдаче Google. Все эти умные устройства Интернета вещей сейчас используют контент из Википедии, чтобы создать впечатление всезнаек.

Проект Wikimedia LLC тревожит многих редакторов-добровольцев Википедии. Они рассматривают прибыль как потенциально развращающее влияние. И существует явное неравенство в том, что штатным сотрудникам WMF платят, в то время как волонтёры работают бесплатно. Википедия составлена из примерно трёх миллиардов индивидуальных правок. Средняя правка в настоящее время приносит WMF около 4,3 цента в годовом доходе, и гораздо больше прибыли крупным технологическим компаниям. Википедисты с сотнями тысяч правок могут почувствовать, что кто-то другой наслаждается плодами их труда.

Наличие огромного богатства WMF особо не повлияло на внешний вид Википедии для читателя. Путешественник из 2007 года, когда Википедия вошла в топ-10 сайтов интернета, не заметит особой разницы. Но сам WMF изменился до неузнаваемости. В 2007 году в организации работало 11 сотрудников, а расходы составили $2млн.

Перенесёмся в 2021-й. В апреле из WMF ушла CEO Кэтрин Махер, так что фонд разместил вакансию. Там указана численность сотрудников WMF более 500 человек. Топ-менеджеры зарабатывают от $300000 до $400000 в год. Более 40 человек занимаются исключительно сбором средств. Современные баннеры учитывают количество показов каждому человеку (Привет, канадский читатель, похоже, вы часто используете Википедию; это здорово! Нам неловко, но в этот вторник нужна ваша помощь. Это десятое обращение, которое мы вам показали...) и умоляют: Пожалуйста, не надо скроллить от нас (dont scroll away) фраза показала удивительно высокую эффективность в A/B-тестировании. В декабре прошлого года читателям, отклонившим баннер, демонстрировали плакучий смайлик.



WMF снова и снова подчёркивает, что Википедия ничего не продаёт. Но собственные объявления для сбора средств описаны как баннеры, говорящие Мы никогда не будем показывать рекламу.

Это важный аспект пиара WMF. За несколько дней до ухода из WMF Кэтрин Махер выступила в ежедневном шоу Тревора Ноа (жена PR-консультанта WMF Крейга Минассиана из Clinton Foundation является продюсером шоу).

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

В бодром ответе Махер никак не упомянула огромные денежные резервы WMF. Зато подчёркнула, что отсутствие рекламы причина, по которой Википедии настолько доверяют, см. видео с отметки 4:30:


Это видео опубликовано на YouTube в комплекте с кнопкой для пожертвований: Помогите Википедии оставаться свободной, независимой и живой в онлайне (Help Wikipedia Stay Free, Independent & Online). (кнопка доступна не во всех странах прим. пер.).

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

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


Чёрный: чистые активы (без учёта резерва Wikimedia Endowment, в настоящее время на уровне $90+ млн)
Зелёный: доход (за исключением пожертвований третьих лиц в резерв Wikimedia Endowment)
Красный: расходы (включая выплаты в Wikimedia Endowment)


Этот год не стал исключением. В течение первых трёх кварталов годовая цель WMF и Wikimedia Endowment на текущий финансовый год оказалась превышена. Её пришлось увеличить со $108 млн до $125 млн. Но эту цель также к концу марта превысили на $17 млн. Тем не менее, несколько недель спустя фонд WMF начал сбор средств в охваченной пандемией Южной Америке. Читателей просят смиренно пожертвовать деньги, чтобы защитить независимость Википедии и показать редакторам-волонтёрам, что их работа имеет значение (некоторых из волонтёров это совсем не радует).

Финансовая независимость WMF явно в полной безопасности. Так что же происходит? Официальный ответ WMF: денег на чёрный день не бывает слишком много. Кроме того, у WMF амбициозные планы к 2030 году стать глобальной инфраструктурой для экосистемы свободных знаний. Организация хочет создать справедливый мир знаний (knowledge equity), в котором люди будут иметь такой же доступ к информации на родном языке, как и граждане первого мира на своём языке. Поэтому требуется постоянное увеличение бюджета. Для этих целей и предназначен денежный краник из Википедии, который можно открыть в любой момент.

В разгар пандемии жители Аргентины и Уругвая опасаются за свои жизни и источники средств к существованию, а WMF слёзно просит пожертвовать на независимость Википедии.

Возможно, людям лучше не видеть эти призывы.
Подробнее..

Википедия купается в деньгах? Обратная сторона вопроса

01.06.2021 18:16:36 | Автор: admin

Сегодня мы прочли статью Википедия купается в деньгах и были очарованы. Там рассказано, как фонд Wikimedia собирает пожертвования по всему миру, и как развивается его целевой капитал. Да, всё в статье правда: в США и фонд есть, и активы есть, и доход есть. Однако in Soviet Russia дело обстоит совсем иначе. Поистине тревожит российских редакторов-добровольцев Википедии совсем иное.

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

Вот, убедитесь своими глазами.

Во многих странах работают местные организации, созданные участниками Википедии. Конечно, головной фонд помогает им. С 2008 года в России тоже есть такой союз партнёрство Викимедиа РУ. И ему головной фонд не помогает никак, не перечисляет ничего.

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

Значит, надо совсем по-другому относиться к пожертвованиям. И как же? А вот как.

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

2) Если вы хотите поддержать конкретный проект, например, Викиновости или Викигид откройте форум того проекта, обратитесь к участникам, предложите им свою помощь.

3) Если вы хотите просто отдать деньги на Википедию обратитесь в Викимедиа РУ и отправьте деньги туда. Ваша помощь останется в России и перейдёт к тем, кто создаёт вики-материал на русском языке.

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

Пожалуйста, откройте им глаза. Зулейха Валиева не должна остаться в одиночестве.

Вот, собственно, и всё, что надо знать о пожертвованиях на Википедию в нынешней России.

Подробнее..

Зачем нужны непрерывная доставка и непрерывное развертывание?

01.06.2021 10:11:39 | Автор: admin

Недавно у нас на работе стихийно возник спор о том, стоит ли вводить непрерывную доставку. Не имея в виду сразу переделывать все наши процессы под непрерывную доставку, я, однако, отстаивал целесообразность такого подхода в общем. К сожалению, после начала спора я за приемлемые 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 несколько тысяч раз в день), и у них изменения быстрее проваливались по конвейеру от включения в исходный код до введения в промышленную эксплуатацию. Но только в таком случае лучше сразу сознаться, что прямой причинно-следственной связи здесь установить нельзя. Вероятнее всего, что непрерывное развертывание это только одно из свойств успешной компании.

Источники

  1. 1cloud.ru. Справочная: что такое Continuous Delivery (2019)

  2. Martin Fowler. ContinuousDelivery (2013)

  3. Jez Humble. The Case for Continuous Delivery (2014)

  4. B. Alanna, N. Forsgren, J. Humble et al. State of DevOps Report (2016)

  5. Chen, Lianping. Continuous Delivery: Huge Benefits, but Challenges Too (2015)

  6. 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)

  7. A. Hkli, D. Taibi, K. Syst. Towards Cloud Native Continuous Delivery: An Industrial Experience Report (2018)

  8. Г. А. Минашин. Переключатели функциональности (feature toggles): виды, преимущества и работа с ними в .NET (2019)

  9. Манифест просвещенного программиста

  10. Как продать технические задачи бизнесу (2021)

  11. Где находятся Вилларибо и Виллабаджо?

Подробнее..

Перевод 6 способов снизить когнитивную нагрузку от интерфейса

27.05.2021 12:14:32 | Автор: admin

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

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

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

В этой статье рассматриваются шесть способов снизить когнитивную нагрузку в UX-проекте.

1. Чем реже нужно делать выбор, тем лучше

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

Если у пользователя слишком много вариантов выбора, он легко сбивается с толку и раздражается. У продукта могут быть все необходимые функции, но если интерфейс чересчур запутан из-за чрезмерного количества возможностей, он становится неудобным. В опубликованном в журнале Journal of Personality and Social Psychology исследовании говорится, что такая ситуация часто вызывает паралич принятия решений и раздражение. [1]

Модель из статьи в Harvard Business ReviewМодель из статьи в Harvard Business Review

В погоне за повышением числа начальных (или повторных) продаж компании могут включать в свои продукты слишком много (или слишком мало) функций. Используя модель, предложенную в Harvard Business Review, можно найти золотую середину в зависимости от желаемого результата.

Фото Charles Deluvio, площадка UnsplashФото Charles Deluvio, площадка Unsplash

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

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

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

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

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

Amazon на главной странице дает пользователям много вариантовAmazon на главной странице дает пользователям много вариантов

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

Отличная иллюстрация информационного запаха от NN GroupОтличная иллюстрация информационного запаха от NN Group

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

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

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

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

Понятно, что все мы иногда делаем ошибки даже лучшие из нас! Но как организовать хороший интерфейс на случай ошибки пользователя?

Ответ прост: нужно дать возможность легко вернуться туда, откуда пользователь начал.

Да, иногда найти необходимое бывает не так уж и просто! Фото Daniel Mingook Kim, площадка UnsplashДа, иногда найти необходимое бывает не так уж и просто! Фото Daniel Mingook Kim, площадка Unsplash

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

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

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

Missguided использует эту возможность и помогает найти нужное или открыть для себя что-то новоеMissguided использует эту возможность и помогает найти нужное или открыть для себя что-то новоеVero Moda тоже хорошо справляется с задачей: заметное поле поиска и популярные категорииVero Moda тоже хорошо справляется с задачей: заметное поле поиска и популярные категорииBirchbox также помогает открыть что-то новое для себяBirchbox также помогает открыть что-то новое для себя

При разработке пути пользователей я использую следующие рекомендации:

  • Не нужно раздражать людей, забрасывая их ошибками.

  • Должно быть легко найти и исправить ошибку, а затем продолжить использование продукта.

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

  • Не показывайте сообщение на всю страницу укажите, в каких полях ошибка.

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

3. Визуальные подсказки для навигации

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

Фото Fab Lentz, площадка UnsplashФото Fab Lentz, площадка Unsplash

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

Правильно подобранное количество визуальных подсказок:

  • Упрощает обзор и чтение страницы.

  • Улучшает визуальную иерархию.

  • Улучшает навигацию по странице.

  • Существенно повышает коэффициент конверсии.

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

Все изображения принадлежат институту CXLВсе изображения принадлежат институту CXL

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

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

Изображение институт CXLИзображение институт CXLИзображение институт CXLИзображение институт CXL

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

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

4. Снижение когнитивной нагрузки посредством знакомых шаблонов и условностей

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

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

Согласованная цветовая схема.

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

Фото Balzs Ktyi, площадка UnsplashФото Balzs Ktyi, площадка Unsplash

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

Повторение в шаблонах проектирования и условностях.

Важно не только следовать принятым условностям, но и регулярно использовать их и тогда случится прекрасное:

  • вашим продуктом станет удобно пользоваться, потому что в нем не будет ничего нового (это снижает когнитивную нагрузку);

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

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

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

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

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

Фото Sebastian Herrmann, площадка UnsplashФото Sebastian Herrmann, площадка Unsplash

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

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

5. Делайте интерфейс для пользователей, а не для себя или своей компании

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

Фото Amlie Mourichon, площадка UnsplashФото Amlie Mourichon, площадка Unsplash

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

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

При этом можно задавать такие вопросы:

  • Что больше всего понравилось в нашем последнем продукте?

  • Как бы вы отнеслись к изменению функции X?

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

Есть несколько методов исследования UX, которые помогут держать пользователей в центре внимания:

  • Надлежащее исследование рынка.

  • Использование персонажей пользовательских ролей.

  • Макеты и прототипы для получения быстрой обратной связи.

  • Регулярное общение с собственной службой поддержки.

И этот список, конечно, далеко не полный

6. Стремитесь к простоте не перегружайте пользователей большим количеством вариантов и функций одновременно

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

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

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

Изображение UsabilityHubИзображение UsabilityHub

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

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

Заключение

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

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

Помогли ли вам приведенные в статье советы? Расскажите в комментариях ниже или напишите мне на почту alexander@radahl.no.


О переводчике

Перевод статьи выполнен в Alconost.

Alconost занимается локализацией игр, приложений и сайтов на 70 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаем рекламные и обучающие видеоролики для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

Подробнее..

Канбан-метод не грузите меня вашей теорией

21.05.2021 14:10:59 | Автор: admin

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

Начну, пожалуй, с подходов к обучению.

Обучение Канбану. Канон

Самыми полными и каноничными курсами по погружению в Канбан-Метод по праву считаются классы, которые разрабатывает Канбан Университет структура Дэвида Андерсона, автора метода.

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

Прямая линейка:

  • 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. Причем, проходить их не подряд, а с промежутком на применение полученных знаний на практике, так как сама текущая механика обучения подразумевает прохождение эволюции восприятия инструментов Метода.

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

Удачи всем в совершенствовании собственной работы!

Подробнее..

Гайд по сертификациям. Часть 1. Agile

24.05.2021 08:13:54 | Автор: admin

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

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

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

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

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

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

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

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

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

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

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

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

ICAgile

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

Карта треков
Agile DeliveryAgile DeliveryBusiness AgilityBusiness Agility

Agile Delivery и Business Agility.

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

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

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

Сертификат

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

Пример сертификата

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

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

Из плюсов:

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

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

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

Из минусов:

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

PMI

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

Треков нет.

Сертификат

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

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

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

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

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

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

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

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

Пример сертификата

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

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

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

Из плюсов:

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

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

Из минусов:

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

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

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

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

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

IAPM

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

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

Карта треков

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

Сертификат

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

Пример сертификата

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

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

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

Из плюсов:

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

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

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

Из минусов:

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

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

Scrum Alliance

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

Карта треков

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

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

Сертификат

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

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

Пример сертификата

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

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

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

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

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

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

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

Из плюсов:

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

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

Из минусов:

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

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

Scrum.org

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

Карта треков

Для сертификации доступно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

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

Карта треков

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

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

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

Сертификат

Пример сертификата

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

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

Из плюсов:

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

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

Из минусов:

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

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

Таблица с гиперссылками

Фреймворки/

методологии/ итд

Основные роли

Сертифицированные тренинги

Стоимость, руб

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

Язык сертификации

ICAgile

Agile

DevOps

Product manager

Project manager

Team role

Coach

OnAgileAcademy

AgileLab

ScrumTrek

ProductLab

35-90 тыс руб

нет

Рус

PMI

Agile

Project manager

Udemy

PMI

От 1 тыс руб

+ 475 USD за экзамен

175 USD

30 PDUs

Англ

IAPM

Agile

Project manager

IAPM

По запросу

нет

Англ

Scrum Alliance

Scrum

Scrum master

Product owner

Developer

Trainer

Coach

Skillbox

ScrumTrek

ThinkAgile

65 тыс руб

50-250 USD

10-40 SEUs

Англ

Scrum.org

Scrum

Kanban

Scrum master

Product owner

Developer

Coach

Agile.live

50-80 тыс руб (включая плату за экзамен)

Нет

Англ

kanban.university

Kanban

Team member

Manager

Consultant

Trainer

Coach

ScrumTrek

25-50 тыс руб

нет

Рус


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

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

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

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

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

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

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

Подробнее..

Как начать думать про клиента на этапе разработки, а не адаптировать продукт после

28.05.2021 14:21:34 | Автор: admin
image
На рисунке прототип продукта для Сбербанк Онлайн.

Есть разные методики для исследования и улучшения клиентского опыта (Customer experience, CX). Сегодня расскажем про одну из них дизайн-мышление, и поможет в этом Ирина Баженова эксперт по исследованию клиентского опыта в Сбере.

До CX Ирина работала в розничном отделении ещё того самого Сбербанка, когда в ходу были сберкнижки, без которых не мог существовать вклад. Бумажную книжку клиент мог случайно испортить намочить, например, тогда её нужно было менять. Она могла просто закончиться, и тогда, если вдруг кто-то помнит, ставился штампик, и владельцу нужно было от руки писать прописью сумму, на которой закончилась его книжка, чтобы перенести всё до копеечки на новую. Конечно, кто-то ошибался, пенсионерам так вообще было очень сложно писать от руки. Главный вопрос, который возник тогда у Ирины: зачем я как специалист прошу сделать это нашего клиента? Ведь ему это сложно делать. И какая от этого практическая польза? Подобных ситуаций было довольно много. Но тогда и банк был другой, и законодательство.

В 2016 году в Сбере началась Agile-трансформация. Тогда же стали активно внедрять методологию дизайн-мышления для проектирования клиентского опыта. Первые годы почти все проекты были направлены не на исследование новых продуктов, а на исправление каких-то особенностей старых. Ну, знаете, типа той, что где карту открывали, в то отделение и идите.
Так что проверено на практике: чем раньше провести исследование и поговорить с клиентом, тем меньше затрат будет дальше на стадии разработки и запуска продукта. И, собственно, именно поэтому есть смысл встраивать процессы по изучению клиентского опыта в саму разработку. Если же задуматься о клиенте, только когда уже есть прототип, то это уже неэффективно потраченные ресурсы.

Немного про методику


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

image

Визуализируют методику так:

image

Разберём пример


Ирине пришёл запрос на помощь в модификации продукта Защита дома. Это страховка Сбера для квартиры, дачи или частного дома для физических лиц. На входе команда имела коробочный вариант продукта с тремя вариантами страховых сумм, цен и распределения страховых лимитов. На выходе команда хотела иметь онлайн-конструктор, который можно будет интегрировать в приложение Сбербанк Онлайн. Это позволило бы клиентам самостоятельно выбирать параметры страхования и тем самым улучшило бы дальнейший клиентский опыт при обращении за выплатой.

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

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

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

Шаг 1. Эмпатия


Команда провела шесть глубинных интервью в Москве и пять в других регионах с клиентами, у которых:

  • имущество застраховано / не застраховано;
  • был страховой случай / не было страхового случая и прочее.

В результате получили первые гипотезы.

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

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

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

Шаг 2. Анализ и синтез


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

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

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

Полина боится затопить соседей больше, чем саму себя.

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

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

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

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


Шаг 3. Генерация идей


Итак, описанным выше способом мы определили 10 ключевых потребностей клиентов, сгенерили примерно 180 идей и сделали две итерации прототипирования.

Шаг 4. Прототипирование


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

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

Кстати, в условиях удалёнки все эти этапы также возможно реализовать на интерактивной доске в Miro.com.

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

Шаг 5. Тестирование


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

На весь этот проект ушло около 50 часов совместной работы от интервью до создания и тестирования прототипа. За это время команда сформировала полное видение будущего продукта и проверила его с клиентами. Только после этого началась непосредственная реализация.

Что получилось?


image
Сбербанк Онлайн Каталог Защита дома.

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

image

После запуска этого продукта в таком виде в Сбербанк Онлайн количество договоров увеличилось на 41 % в июле 2020 года по сравнению с маем 2020-го.

Почему важно проводить исследования в кросс-функциональных командах?


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

Как правильно выбрать время и формат для CX-исследования?


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

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

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

Спасибо Ирине Баженовой, нейрокоучу, лидеру UX-исследований блока Корпоративно-инвестиционный бизнес в Сбере, сертифицированному тренеру и фасилитатору по дизайн-мышлению за интересную историю, материалы и помощь в подготовке статьи.
Подробнее..

Теперь YouTrack интегрируется с GitLab CICD

28.05.2021 14:21:34 | Автор: admin

Привет, Хабр!

На связи команда JetBrains YouTrack, и у нас для вас новый релиз! Мы дополнили интеграцию с GitLab теперь YouTrack не только отслеживает коммиты и merge-реквесты, но и поддерживает интеграцию с GitLab CI/CD. А это значит, что задачи в YouTrack смогут обновляться автоматически по результатам автоматизированных сборок в GitLab CI/CD. Также мы дополнили релиз интересными улучшениями для работы с задачами. За подробностями добро пожаловать под кат!

Об интеграции с 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

Подробнее..

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

01.06.2021 12:20:22 | Автор: admin

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 на официальном сайте компании

Подробнее..

Учиться, учиться, и ещё раз учиться?

01.06.2021 14:09:01 | Автор: admin

TLDR: крохотные модельки обошли модные графовые нейронки в предсказании свойств молекул.
Код: здесь. Берегите Природу.


image
ФОТО: Андерс Хеллберг для 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. Эти два текста стоит воспринимать как первые главы повествования о методах анализа связанных систем, также там в деталях рассматривается используемая форма математической записи.


image


Многослойная GCN с фильтрами первого порядка.


Данные


Проведём серию экспериментов на общедоступных данных. Мы обратимся к (i) коллекции TUDatasets [4] и (ii) ограничим наше упражнение задачей бинарной классификации (предсказанием свойств) небольших молекул. Ещё одним условием нашего мероприятия будет (iii) использование графов с признаками вершин.


Заданные ограничения оставляют нам несколько наборов данных, широко используемых для сравнения современных алгоритмов. Вот наш итоговый список: AIDS, BZR, COX2, DHFR, MUTAG и PROTEINS. Все обозначенные наборы данных доступны как часть Pytorch Geometric [5] (библиотека для глубокого обучения на графах) в двух версиях: оригинальной и очищенной от дубликатов [6]. Итого у нас будет 12 датасетов.


AIDS Antiviral Screen Data [7]


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


Benzodiazepine receptor (BZR) ligands [8]


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


Cyclooxygenase-2 (COX-2) inhibitors [8]


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


Dihydrofolate reductase (DHFR) inhibitors [8]


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


MUTAG [9]


В наборе содержится 188 химических соединений, разделённых на два класса согласно их мутагенному воздействию на бактерии. В очищенной версии 135 молекул, 7 признаков на вершину.


PROTEINS [10]


Энзимы и не-энзимы. В оригинальном наборе содержится 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 баллов распределились как:


147:141


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


image


Наборы данных, в которых простые модели побеждают: AIDS, DHFR(A) и MUTAG.


Например, DK собрала все 48 баллов для набора данных AIDS, демонстрируя отрыв более чем на 10% (абсолютное значение) от доли верных ответов полноценно обученной GCN.


image


Здесь побеждают GCN: BZR, COX2 и PROTEINS.


Индивидуальный зачёт:
90 GCN-B;
71 DK;
55 Mix (uGCN + DK);
51 GCN-A;
21 uGCN.


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


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


Выводы


Как видим, проведенный эксперимент подтверждает предположение о том, что в задаче предсказания свойств молекул мы можем позволить себе использовать почти бесплатные эмбеддинги, которые превосходят или показывают результаты на уровне полноценно обученных нейронных сетей. Наблюдения согласуются с вдохновляющими этот эксперимент результатами [2] в том, что концептуально метод Label Propagation очень похож на передачу сообщений в графовой свёрточной нейронной сети. Объяснение эффективности скорее всего следует искать в том, что на самом деле мощнее подбирать параметры фильтров для того, чтобы внутренние представления, выученные сетью стали линейно разделимыми, либо же просто использовать классификатор помощнее, как это сделано в рассмотренном примере.


Дисперсия результатов между раундами соревнования напоминает о том, что всякое сравнение дело непростое. Здесь стоит упомянуть Free Lunch Theorem и напомнить о том, что использовать сразу несколько моделей в построении решения скорее хороший тон. Также важно отметить влияние разбиения на выборки в ходе сравнения на одном и том же наборе данных одна и та же модель может показывать очень разное качество. Поэтому сравнивая модели, убедитесь, что обучаете и тестируете их на идентичных выборках. К слову, фиксация параметров генератора псевдослучайных чисел не панацея


image


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


Послесловие


В лекции открытого курса по графам знаний GCN названа Королевской Лазейкой Через Пространство Фурье, этот ярлык приклеился с тех пор, когда впервые выступил на публике с рассказом о силе графов и провёл первые эксперименты с классификацией картинок (как графов) для того, чтобы продемонстрировать мощь спектральных фильтров одной юной леди, запускавшей стартап в милой моему сердцу аэрокосмической области. Данная заметка появилась в результате того, что пару недель назад в реальной задаче на закрытых данных uGCN, вместе с простенькими моделями показали результат, который полноценно обученные GCN смогли превзойти всего на 2% (96 против 98) и мне вздумалось проверить вопрос о том, кто кого заборет ещё на каких-нибудь данных.


В наши дни машинное обучение на графах превратилось в знаменитость, всё больше исследователей обращают внимание на эту область и новые архитектуры графовых нейронных сетей появляются каждую неделю. Однако на самом деле мы ещё не очень хорошо понимаем почему GNN так успешны и нужны ли они для хорошего качества решения [2].


Перед тем, как ступать на очаровательный путь машинного обучения на графах, пожалуйста ознакомьтесь с основами этого дела. Значительные усилия прилагаются к тому, чтобы сделать новейшие достижения (да и классические методы тоже) доступными широкой аудитории совершенно бесплатно. Упомяну лишь несколько из таких инициатив: материалы и лекции стенфордского cs224w, площадку для тестирования качества алгоритмов Open Graph Benchmark [14] и недавнюю работу об основах геометрического глубокого обучения [15] методологию разработки новых архитектур нейронных сетей. Напоследок, ещё раз напомню о том, что начинать проекты машинного обучения стоит с простых методов, вроде ядер и необученных графовых свёрточных сетей достаточно часто эти модельки показывают неприлично хороший уровень.


Берегите Природу, используйте алгоритмы эффективно. Порою неученье сила.


image


Литература


[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.

Подробнее..

Обновленный плагин YouTrack для IDE на платформе IntelliJ

03.06.2021 20:19:56 | Автор: admin

Привет Хабр!

В командах разработки трекеры задач и 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

Подробнее..

Recovery mode Система мотивации ТОП-3практики из США

04.06.2021 12:23:32 | Автор: admin

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

Вы можете посмотреть видеоверсию статьи, либо прочитать текстовый материал.

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

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

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

Первый инструмент: программы распределения прибыли

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

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

И что очень важно: программы распределения прибыли позволяют повысить эффективность труда персонала без дополнительных затрат. Как показывают исследования, проведенные американцами: внедрение программы распределения прибыли позволяют компаниям увеличивать операционную продуктивность персонала до 50%. Т.е., условно, если раньше человек выполнял 10 задач в день, то с внедрением подобной системы у него растет мотивация и он делает уже порядка 13-15 задач в день. От чего, очевидно, растет общая прибыльность и капитализация компании.

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

Давайте обратимся к зарубежным примерам. Так вот, в США это инструмент прекрасно работает и внедряется в огромном количестве компаний.

Возьмем, в качестве примера, компанию Tesla. В мае 2021 года стало известно, что Илон Маск по итогам своей работы получил право на акции Tesla стоимостью более 32 миллиардов долларов. Это вознаграждение он получил за достижение целевых показателей, которые установил совет директоров корпорации несколько лет назад. Благодаря этим опционам Илон теперь имеет возможность приобрести акции компании за 10% от их текущей рыночной стоимости.

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

Второй инструмент: проектная или почасовая занятость

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

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

В США даже есть закон О минимальной заработной плате, которым работодатели обязаны руководствоваться и который устанавливает минимальную зарплату в США в размере 7 долларов 25 центов. Эта ставка не менялась с 2009 года. При этом существуют поправки на вид деятельности. Так минимальная ставка для персонала, который получает в ходе своей работы чаевые составляет уже 2 доллара и 13 центов. Также есть зависимость размера минимальной оплаты труда от штата. Так в Арканзасе работодатель обязан начислять сотрудникам заработную плату не менее 9 долларов и 25 центов за каждый час труда. А лидером среди всех штатов является штат Колумбия с минимальной ставкой в 14 долларов в час.

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

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

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

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

В чем его суть? Как мы знаем, в США система мотивации строится во многом вокруг личности сотрудника. Поэтому компании ищут нестандартные методы стимулирования персонала и предлагают своим работникам такие опции как: обширная медицинская страховка, оплачиваемая работодателем; курсы повышения квалификации; бесплатные обеды; корпоративные праздники; совместные поездки и многое другое.

Например, в компаниях IBM и AT&T существуют семейные программы. Что это означает? В этих компаниях средний возраст сотрудников составляет до 40 лет, очевидно, что бОльшая часть персонала является семейными людьми, у которых есть дети и домашние задачи. И в целях повышения эффективности их работы компания берет на себя решение части их домашних задач, таких как подбор няни или других помощников по дому, организует корпоративные ясли и детские сады, устраивает семейные праздники и многое другое. Ключевых задач несколько:

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

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

Как вы видите, все в выигрыше.

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

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


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

Подробнее..

Перевод Как Airbnb скрывает кошмары при помощи тайной команды чистильщиков

16.06.2021 18:22:08 | Автор: admin

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

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

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


Инцидент на 37-й улице

Квартира на первом этаже на 37-й Западной улице, в нескольких кварталах к югу от Таймс-сквер, была популярна среди туристов настолько, что ключи для арендаторов Airbnb оставляли на стойке соседнего винного магазина. Именно там 29-летняя австралийка и её друзья забрали их, не предъявляя никаких документов, когда приехали на Манхэттен провожать 2015 год. Квартира была размещена на Airbnb, несмотря на то, что краткосрочная аренда в Нью-Йорке в большинстве случаев вне закона. Город, подталкиваемый влиятельными профсоюзами отельеров, вёл войну с компанией, которая размещала тысячи объявлений о сдаче квартир в пяти районах, несмотря на одни из самых строгих законодательных предписаний об аренде в стране.

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

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

О происшествии немедленно известили кризис-менеджера Airbnb Ника Шапиро. Шла вторая неделя его работы в этой должности, куда он перешёл с поста заместителя начальника штаба ЦРУ и советника в Совете национальной безопасности в Белом доме Обамы. Я помню, как думал, что снова оказался в гуще событий. вспоминает он. Происшествие вернуло меня к ощущениям, которые я испытывал, сталкиваясь с действительно ужасными вещами в Лэнгли и в ситуационной комнате Белого дома.

Даже видавший некоторое де**мо Ник Шапиро был в шоке.Даже видавший некоторое де**мо Ник Шапиро был в шоке.

Шапиро, в свою очередь, уведомил других руководителей Airbnb, включая главного исполнительного директора Брайана Чески. Тем временем агенты из элитной команды компании по обеспечению доверия и безопасности начали действовать. Они переселили пострадавшую женщину в отель, оплатили перелёт ее матери из Австралии, доставили их обеих домой и предложили покрыть все расходы на лечение и консультации психолога.

Дубликаты ключей представляли собой особую проблему для компании и загадку для следователей. Откуда они у мужчины? У Airbnb нет правил, как хозяева (здесь и далее владельцы сдаваемых помещений) должны обмениваться ключами с гостями, и от ответа на этот вопрос зависела репутация компании в плане безопасности и, возможно, её юридическая ответственность. Шапиро (который на сегодня уже покинул компанию) помогал координировать расследование этого вопроса.

Тот самый дом на 37-й Западной улице.Тот самый дом на 37-й Западной улице.

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

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

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

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

Рождение секретной службы Airbnb

Airbnb была основана в 2008 году студентами-дизайнерами Брайаном Чески и Джо Геббиа вместе с инженером-программистом Натаном Блечарчиком. Из забавной альтернативы каучсёрфингу Airbnb выросла до одной из крупнейших гостиничных компаний в мире с 5,6 миллионами объявлений, а это больше, чем количество номеров в семи крупнейших гостиничных сетях, вместе взятых.

Светлые и прекрасные лица основателей Airbnb, слева направо: Джо Геббиа, Брайан Чески, Натан Блечарчик.Светлые и прекрасные лица основателей 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 и секретной команды безопасности делает вид, что имидж ничто.Тара Банч, руководитель глобальных операций Airbnb и секретной команды безопасности делает вид, что имидж ничто.

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

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

В компании отказались комментировать условия расчётов или бюджет службы безопасности. Но из конфиденциального документа, с которым ознакомился Bloomberg Businessweek, следует, что в последние годы Airbnb тратила в среднем около 50 млн. долларов в год на выплаты хозяевам и гостям, в том числе на судебные разбирательства и возмещение ущерба, нанесённого жилью. (Компания утверждает, что большинство её выплат связано с ущербом имуществу по программе страхования хозяев и что шестизначные суммы выплат исключительная редкость.)

Бывшие агенты по безопасности также рассказывают о напряжённых отношениях с отделом доверия, чья работа заключается в разработке политики по предотвращению плохих вещей, будь то клопы, заряжённое оружие или похищения. Агенты по безопасности, которые наводят порядок только после происшествий, говорят, что чувствовали себя изгоями. Между отделами безопасности и продаж также существовала напряжённость из-за профессиональных хозяев, управляющих несколькими объектами недвижимости, удаление которых с платформы за нарушение правил безопасности могло стоить Airbnb сотен объявлений.

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

Представляем работу секретной команды Airbnb в российских реалиях.Представляем работу секретной команды Airbnb в российских реалиях.

Как и многие другие компании Кремниевой долины, Airbnb поднялась благодаря политике роста любой ценой: она проникала в города, обходя правила, побеждала в народном голосовании и набирала популярность так быстро, что к тому времени, когда чиновники замечали происходящее, у них уже не оставалось шансов контролировать ситуацию. По всему миру разгорелись нормативные битвы, самая токсичная из которых разыгралась в Нью-Йорке в 2015 году. Городские власти проводили операции по выявлению незаконной аренды жилья на срок менее 30 дней и обязали компанию предоставить адреса своих объявлений, что вызвало многолетнюю судебную тяжбу. Airbnb нанимала исследователей оппозиции, чтобы изучить биографии своих критиков, и оплачивала атаки на них в прессе.

Инцидент на 37-й улице. Расследование

В начале 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 в издевательской манере просит прощения за аварию в Мексиканском заливеИз эпизода Южный парк Енот 2: Непредусмотрительность, в котором CEO BP в издевательской манере просит прощения за аварию в Мексиканском заливе

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

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

Airbnb всё ещё приходится сталкиваться с кризисами безопасности, реагировать на нападения и бороться с регуляторами. 31 мая в рамках соглашения об урегулировании судебного процесса с Нью-Йорком компания начала передавать информацию о своих хозяевах, включая имена, адреса и информацию о том, сдают ли они всю квартиру. Эти данные облегчат отслеживание незаконных объявлений.

Спустя более пяти лет после нападения на 37-й Западной улице Airbnb всё ещё не установила чётких правил относительно ключей. Этот случай положил начало многолетним внутренним дебатам о бесключевом доступе. Если бы хозяев можно было заставить пользоваться цифровыми клавиатурами и менять код после каждого пребывания, то в будущем можно было бы избежать подобных ситуаций. Даже требование раскрывать информацию о том, есть ли у них вход с клавиатуры, может изменить ситуацию. Шапиро, бывший глава антикризисного управления, вспоминает, как настаивал на том, чтобы исключить обмен ключами. Я помню, как пытался поговорить о процессе обмена ключами и способах предотвращения того, чтобы хозяева оставляли их в магазинах, говорит он.

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

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

Другие профессии и курсы
Подробнее..

Перевод Разработчики не могут исправить ошибки управленцев

18.06.2021 12:04:53 | Автор: admin
Мне постоянно попадаются статьи, в которых разработчиков упрекают за нежелание вникать, зачем нужна их работа, и доказывают им, что это неправильно вслепую вносить изменения, не разбираясь, какая за этим стоит цель. Звучат призывы в духе оглянитесь вокруг, не уходите с головой в написание кода!. На мой взгляд, эти статьи обращены не к тем людям.

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

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

Организации, живущие по заветам университетских программ делового администрирования, избегают моделей с нефиксированными объемами работ. Им проще сосредоточиться на том, чтобы у технических команд было что-нибудь Готово к определенному сроку. Готово обычно бывает что-то никому не нужное, потому что вопрос об определении реальных потребностей аудитории замяли. Вдобавок в проекте обычно царит полный хаос, потому что команда раз за разом бросает силы на то, чтобы делать новый функционал, вместо того чтобы оценить свою работу и устранить тот самый хаос. Единственный плюс того, что проект довели до состояния Готово как правило, это событие отмечают пиццей и тортом. Если очень повезет, то еще и умеренным повышением кого-нибудь из команды, за то, что уложились в сроки. Правда, в реальности новым функционалом люди не пользуются, но это до поры до времени не имеет значения, пока в один прекрасный день кто-нибудь (как правило, финансовый директор) не посчитает KPI по формуле 4Х и не урежет команде финансирование.

В истории уже такое было


Для сложившейся ситуации в разработке ПО можно привести историческую параллель. Где-то в сороковых годах прошлого века Уильям Эдвардс Деминг предложил производителям автомобилей Детройта новую методику автомобилестроения. В Детройте в то время деньги гребли лопатой за счёт того, что успели захватить самый прибыльный рынок в мире, и, честно сказать, не видели смысла что-то менять в принципе. Получив отказ, Деминг перешел на другие виды деятельности, стал принимать участие в восстановлении японской экономики после войны. Там его методы показали себя хорошо, и понемногу машины японского производства стали теснить Детройт на рынке.

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

К 1981 году, когда Япония подтачивала позиции Форда на рынке уже десятки лет, руководство наконец сдалось и пригласило Деминга отладить производство. В их преставлении проблема заключалась в качестве изготовления деталей иными словами, в рабочих, которые изготавливали недостаточно качественные детали. Ведь не начальство же этим занимается. К большому их удивлению, Деминг заявил, что 85% проблем, негативно влияющих на качество продукции, происходят от неправильного руководства. Компании понадобилось шесть лет, чтобы перейти на новую модель, и результатом стала линейка автомобилей Taurus-Sable на голову выше того, что они делали до этого.

Основной ошибкой компании Форда было то, что, продумывая, как можно улучшить производство, руководство не обращалось к людям, которые занимались им непосредственно. Компании удалось значительно поднять качество продукции простым способом: менеджерам было поручено опросить рабочих на тему того, что и как можно делать лучше. Замечания выслушивались, а затем на их базе в процесс производства вводились новые практические усовершенствования. Раньше они использовали другой подход менеджеры сами придумывали абстрактные усовершенствования (зачастую с подачи начальства) и заставляли рабочих их внедрять. Сегодня мы наблюдаем тот же антипаттерн оптимизации сверху вниз в разработке ПО.

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

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

Авторы хотят как лучше и, на первый взгляд, вроде бы дают разумные советы. Но как именно эти самые работники автомобильной промышленности должны перекраивать рабочие процессы? Им предлагается переучивать начальство? В истории прецедентов особо не встречается, и я сильно сомневаюсь, что и сейчас это кому-то удастся. В подобной же ситуации оказываются и разработчики многих компаний. Большинство работает под игом выпускников по специализации делового администрирования. Каждый разработчик становится метафорическом винтиком в системе PMP/WBS всем по диаграмме Ганта, менеджеру проекта и индикатору типа задачи.

И даже когда компания, работающая по традиционной модели, решает переключиться на Agile, зачастую всё выливается во внедрение антипаттерна Date Scrum, который прекрасно уживается со стандартным подходом к руководству. Растущая популярность Date Scrum привела к тому, что у многих разработчиков сложилось неприязненное отношения к практикам Agile вообще. Их сложно винить: если до внедрения Agile им приходилось терпеть собрания с отчетом по текущим задачам раз в пару недель, то с Date Scrum приходится страдать ежедневно!

Что такое Date Scrum?
Это практика из сферы R&D, которая предписывает разработчикам оценивать проектные требования сразу для всей протяженности работ целиком. Когда проекту дают зелёный свет и утверждают бюджет на базе конечных оценок, команда каждый день собирается на встречах (скрамах), чтобы отчитаться по текущему положению и нейтрализовать рискованные моменты; таким образом решение итерируется по мере продвижения к дате релиза. Некоторые воспринимают этот подход как каскадную модель, только реализованную спринтами.

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

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

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

  • Разработчики, которые тратят вполне разумное количество дополнительного времени на то, чтобы проверить то, что сделано, и устранить хаос, считаются какими-то неспешными.
  • Разработчиков, которые замечают какое-либо несоответствие между продуктом и запросами рынка, мягко отправляют обратно за клавиатуру, строгать новый функционал. Всё, на что они могут рассчитывать обещание, что группа, генерирующая идеи, обо всём позаботится.
  • Разработчики, которые быстро выкатывают продукты на суд соответствующей сторонней группы, ценятся, потому что оперативно приводят всё в состояние Готово.
  • Разработчиков, которые ведут полевые наблюдения и видят, что пользователи испытывают трудности с продуктом, ненавязчиво возвращают в рамки общей программы.
  • Техлидов, которые пытаются вникнуть в Общую Картину (как продукт приспособлен к рынку, как определяются цены и состав пакетов услуг), похлопывают по плечу и отправляют обратно, мотивировать разработчиков на производство очередного функционала сомнительной полезности.
  • Разработчикам, которые пытаются держать ситуацию под контролем при помощи техник статистического управления хаосом, рекомендуют оставить всё это группе, ответственной за Качество как будто люди, которые не писали код, справятся с делом лучше!

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

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

Следует обратить внимание и на то, чего разработчики просят не делать:

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

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

  • Планирование по прогнозам, которое строится на дробной оценке сроков. Это годится для процессов, в которых точно известно время исполнения задач, разработка к ним не относится.
  • Дробная оценка сроков силами разработчиков.
  • Иерархическая структура работ опять же, хороша там, где точно известно время исполнения.
  • Определение дью исходя из некорректных оценок сроков.
  • Применение Agile Scrum, за исключением случаев, когда работа ведётся в связке с заказчиком, который в этом разбирается.
  • Некритическое принятие масштабов проекта, заявленных группой, которая генерирует идеи.

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

В команде iiSM.ORG бытует мнение, что ПО меняет в жизни, работе и развлечениях людей очень многое за счет оптимизации и автоматизации. Доля IT-предприятий среди мировых топ-компаний неуклонно растёт по экспоненте, и вскоре наш ждёт целый поток изменений, который вызовет переворот в бизнесе и видоизменит общество. Если мы правы (а я полагаю, что правы), то руководителям, работающим по старинке, придётся подстраиваться под реалии мира после цифровой трансформации. Поэтому давайте не пожалеем времени на то, чтобы донести: традиционные техники менеджмента попросту не работают применительно к разработке ПО и продержаться на них в долгосрочной перспективе невозможно.
Подробнее..

Перевод Пол Букхайт Три типа идей и почему плохие идеи часто оказываются лучшими

05.06.2021 14:06:41 | Автор: admin
image


Пол Букхайт 23-й сотрудник Google, автор слогана Dont be evil, создатель Gmail. Основатель стартапа FriendFeed. Инвестировал более чем в 150 стартапов (60 экзитов), партнер Y Combinator.

Прим. пер.: Очень интересно оглянуться назад и проверить на прочность высказывания создателя Gmail Пола Букхайта, которые он озвучил 14 лет назад (в 2007 году). Некоторые моменты сейчас кажутся немного наивными, но основной посыл актуален до сих пор.


Идеи новых продуктов можно разделить на три категории:

  1. Очевидно хорошие идеи, которые очень сложно реализовать. К этой группе относятся эффективный холодный ядерный синтез, летающие машины и множество других научно-фантастических идей.
  2. Очевидно хорошие идеи, которые кажутся возможными, но еще не реализованы. Видеотелефоны и HDTV долгое время находились в этой категории. Я думаю, это происходит, когда люди увлекаются технологиями и переоценивают их преимущества (и, возможно, недооценивают стоимость). Мне просто наплевать на видеотелефон.
  3. Плохие идеи. Многие из этих идей действительно плохи, но некоторые из них в ретроспективе окажутся очень хорошими идеями. Я помещаю их в ту же категорию, потому что их трудно отличить без оглядки в прошлое. Вот некоторые примеры: персональный компьютер (зачем кому-то компьютер?), Google (уже слишком много поисковых систем, и, кроме того, поисковые системы не зарабатывают деньги) и Blogger (разве ты не можешь? просто используйте Geocities, и, кроме того, действительно ли так много людей, у которых есть что рассказать? "). Более современные примеры (прим. пер.: 2007 год), Facebook и Twitter, которые все еще вызывают споры.

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

image


Например, я помню, когда впервые разрабатывалась версия Google Video сервис для загрузки видео в Интернет. Почти все внутри Google, включая меня, очень скептически относились к тому, что когда-либо будет загружено что-нибудь стоящее. Все предсказывали, что это будут фильмы и порно. Конечно, кое-что из этого было, но скептики скрьёзно ошибались, говоря об отсутствии полезного контента. Загруженное видео одно из самых важных событий последних нескольких лет. К сожалению, Google Video был обременен невероятно плохим процессом загрузки (он включал в себя установку клиента для Windows для выполнения загрузки!), И YouTube, который был запущен ПОСЛЕ запуска Google Video, взял на себя ввсе внимание. Я считаю, что эта ошибка частично была вызвана негативными ожиданиями.

Вот моя точка зрения: лучшие идеи продуктов часто находятся в категории плохих идей!

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

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

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


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

За перевод спасибо: Илья Горбунов (telegram: @gorilyad)

Еще переводы Пола Букхайта




Следите за свежими переводами и новостями YC Startup Library на русском в телеграм-канале или в фейсбуке.

Полезные материалы Y Combinator


Подробнее..

Расчет рекомендованных предложений для клиентов Yota что под капотом?

28.05.2021 04:14:05 | Автор: admin

Привет, хабровчане!


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


Оставив за скобками не менее интересную историю о том, как эта идея прошла через жернова отбора продуктологов, сфокусируемся на основных аспектах реализации решения.
Здесь необходимо сделать отступление для понимания картины мира. Yota, являясь Full MVNO оператором, полностью контролирует BSS стек технологий и выстраивает свой IT-ландшафт самостоятельно. То есть в нашем ландшафте есть место как различным витринам взаимодействия с клиентом, таким как мобильное приложение, сайт, цифровые и голосовые каналы, так и бэкенд системам, обеспечивающим возможности по регистрации клиентских данных, управления жизненным циклом продуктов, тарификации и многие другие. Иначе говоря, IT-ландшафт отлично соотносится с подходами доменно-ориентированного дизайна, а значит, как только аналитикам и архитекторам поступили бизнес-функциональные требования, их первоочередная задача была определить IT-домены, которые будут затронуты предполагаемыми изменениями.


Контекст решения


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


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

В сборе и анализе данных участвуют IT-домены, которые ближе всего находятся к сетевому оборудованию:


  • Домен Биллинга, а именно рейтер и биллинговая система, в которую рейтер регистрирует данные о звонке, включая его длительность
  • Домен Управления сетевым оборудованием и качеством передачи данных, а именно свитчи и роутеры, через которые проходит клиентский трафик, DPI системы анализа пакетов данных и применения политик, определяемых PCRF системой, которая обеспечивает контроль использования трафика, включая накопленный объем
  • Домен Аналитики данных, а именно системы сбора/регистрации данных из операционных систем, хранилище данных, а также системы, обеспечивающие поток обработки поступивших данных и подготовку продукта данных (data product) для его дальнейшего использования при генерации рекомендованного предложения

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


  • Домен Управления продуктами, а именно продуктовый каталог, системы, определяющие доступность предложений и инстанцирование продуктов в случае его принятия
  • Домен Вычисления контекста состояния клиента, а именно движок бизнес-правил и набор хэндлеров, позволяющих вычислить контекст состояния клиента и объектов, с ним связанных, таких как баланс, продукты, срок жизни и т.п.
  • Домен Сервисов информирования, а именно системы, обеспечивающие сборку сообщений и их отправку в нужный канал
  • Домены-витрины/каналы, такие, как Мобильное приложение, CRM и другие

Давайте рассмотрим каждый из информационных потоков более детально.


Получение и анализ статистики потребления


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


image

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


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


В случае контроля интернет-трафика, с точки зрения его сбора и анализа, все оказалось несколько сложнее. Здесь есть четкая привязка к оборудованию и его возможностям, а именно поддержке протокола IPFIX. IPFIX расшифровывается как IP Flow Information Export, то есть экспорт информации IP-потока. IPFIX позволяет сетевым инженерам и администраторам собирать информацию о трафике с коммутаторов, маршрутизаторов и любых других сетевых устройств, поддерживающих протокол, и анализировать отправляемую информацию, обрабатывая ее с помощью системы анализа трафика.
Именно система анализа трафика должна поддерживать данный протокол, полученная информация по которому может быть использована при расчете предложения, включающего соответствующие безлимитные приложения для оптимизации затрат клиента на трафик. В связи с тем, что нам потребовалось обновить программное обеспечение систем анализа трафика в разных регионах, усовершенствованная версия продукта Максимум на первый месяц с возможностью рекомендаций безлимитных приложений была запущена уже по факту апгрейда этих систем.


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


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


Генерация рекомендованного предложения


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


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


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


Информационное взаимодействие по генерации предложения инициируется в биллинговой системе.
Биллинговая система и PCRF система контроля потребления трафика в нашем случае являются системами, в которых инстанцируются продукты-накопители. Но именно биллинговая система определяет, на каком этапе жизненного цикла находится тот или иной продукт у определенного клиента, актуализируя состояние накопителя интернет-трафика в PCRF через mediation device. Фактически домен Управления продуктами определяет политики инстанцирования и оркестрирует работу с продуктами на платформах, обеспечивающих жизненный цикл продукта.
Биллинговая система знает, когда наступает момент для генерации рекомендованного предложения и отправляет соответствующее событие, на которое подписан диспетчер формирования рекомендованного пресета.


image

Считаю, что движок бизнес-правил является неотъемлемой частью событийно-ориентированного ландшафта любой продуктовой компании. Это утилитарный (платформенный) высоконагруженный сервис, который слушает события на входе и быстро возвращает ответ выполнен или нет требуемый набор бизнес-правил, исходя из контекста состояния клиента. Он также должен обладать возможностью предоставлять изолированные репозитории для настройки самих правил всем автономным продуктовым командам, таким как Смартфон, Модем, Финтех, B2B и другим.
Движок используется для определения доступности коммерческих предложений, определения выполнения клиентом условий маркетинговых кампаний и во многих других сценариях использования, являясь одной из центральных платформ IT-ландшафта.


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


Продолжим тему генерации рекомендованного предложения. Диспетчер, получая событие, сигнализирующее о необходимости расчета предложения, отправляет запрос на движок бизнес-правил, получает ответ о выполнении набора правил и формирует рекомендованный пресет. Движок в нашем случае не только информирует об успешности выполнения правил (true/false), но и сообщает вычисленные значения ресурсов для формирования пресета, используя правила-формулы и подготовленный продукт данных доменом Аналитики данных в качестве базисных значений для расчета.
По факту формирования рекомендованного пресета диспетчер отправляет событие, получаемое доменом Систем информирования. Основным компонентом данного домена является процессор динамической сборки сообщений. Процессор собирает сообщение для информирования и отправляет его по каналам взаимодействия с клиентом, таким как пуш-сообщение в Мобильном приложении и SMS.


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


Заключение


Резюмируем основные положения статьи:


  1. Следование принципам доменно-ориентированного дизайна позволяет точно определить задействованные системы и границы предполагаемых изменений в каждом домене, а также понять задействованные IT-команды и оценить их трудозатраты.
  2. Сбор статистики потребления зависит от технических возможностей каналов, обеспечивающих передачу голоса и цифры, а также систем анализа трафика.
  3. Решение базируется на основополагающем компоненте для определения доступности предложений движке бизнес-правил.
  4. Развитием доменов Управления продуктами и Вычисления контекста состояния клиентов движет запрос на расширение портфолио предлагаемых продуктов и связанное с этим запросом требование по обеспечению конвергентности механик управления продуктами.
  5. Продукт Максимум на первый месяц является частным случаем на основе универсального механизма генерации предложений, которые могут быть сформированы, исходя из правил, определяемых акцией. В дальнейшем правила могут быть легко изменены. Как один из предполагаемых вариантов развития, рассматривается возможность изменения правил, когда акция будет доступна не только новым, но и существующим клиентам.
Подробнее..

BAдайджест, май 2021 подкаст сКарлом Вигерсом, Docs asCode

18.06.2021 00:22:38 | Автор: admin

Всем привет! Встречайте свежий дайджест ссамыми сочными статьями замай.

Вскобках возле заголовков уровень сложности статьи (Normal * Hard ** Expert ***) ипримерное время наизучение материала

Business Analysis

Подкаст. 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.

Подробнее..

Fintech на практике как Quadcode технологии для трейдинга и банкинга разрабатывает

01.06.2021 12:20:22 | Автор: admin

Привет, самое хардовое 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, так как это намного удобнее и является уже практически промышленным стандартом в индустрии.

Какие продукты создает команда Quadcode

Наш флагманский продукт платформа для трейдинга. За 7 лет развития количество пользователей платформы выросло с 950 тысяч до 88 миллионов в 170+ странах.

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

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

А теперь кратко о наших продуктах:

SaaS Trading Platform

Команда с нуля разработала платформу с аптаймом 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, вкусно и полезно.* Для того, чтобы наглядно объяснить, что такое SaaS, и показать, куда мы в итоге хотим прийти, приведем пример с пиццей. Это так называемая модель Pizza-as-a-service, вкусно и полезно.

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

Сейчас добиваемся того, чтобы в экосистеме платформы был максимально широкий спектр инструментов: Forex, СFD и инвестиционные продукты в удобной для пользователя форме. Идеальный вариант сделать платформу подходящей как для банков, так и для их клиентов. Мы собираем паззл продукта из мельчайших деталей. Процесс этот не такой быстрый, но пока все получается. Быстро и не получится ни в правовом плане, ни в плане технологий.

Примеры задач, которые стоят перед командой в этом году:

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

  2. Также один из крупных проектов это разработка собственного движка Margin Forex & MCFD.

  3. Проработка Prediction Churn. Фича основана на анализе данных и предсказывает момент, когда пользователь решит уйти. Сейчас результат Prediction Churn достоверен с вероятностью 82%. Когда система предсказывает, что пользователь готов уйти с платформы,в работу включаются менеджеры, чтобы создать удобные для трейдера условия работы на платформе. Это позволяет продлить срок работы с трейдером. Чем дальше, тем точнее будет работать Prediction Churn, и тем лучше мы сможем держать контакт с пользователем.

Banking

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

  • Дистанционный онбординг для физических и юридических лиц.

  • Доступ к счету через мобильное приложение и онлайн-банкинг.

  • Мультивалютные счета в формате IBAN.

  • SEPA, TARGET2 и SWIFT переводы.

  • Выпуск пластиковых и виртуальных карт.

Технологический стек классический: ядро системы работает под управлением JAVA. А также применяется PHP+JS для реализации административных интерфейсов управления и web приложений.

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

Внутренние разработки

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

Из наиболее интересных можно выделить следующие:

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

  2. Sandbox. В сложных многокомпонентных, а в нашем случае системах с большим количеством сервисов, всегда возникает проблема с тестированием. Важно иметь возможность получать воспроизводимое окружение для тестирования, так называемые тестовые стенды. Еще в самом начале пути мы создали Sandbox систему, с помощью которой можно собирать копии платформы с различными конфигурациями. Это своего рода конструктор, куда можно зайти, выбрать какая функциональность нужна - будет создана сборка, запущены необходимые микросервисы и можно тестировать. Все это работает на базе Docker + Kubernetes.

  3. Central Information System. Всегда возникает необходимость в инструменте, который может объединить в себе все системы компании. Речь не только про разработку, но и про КДП, HR, Финансовый отдел. Такая система должна помогать находить ответы на различные вопросы. Например, что за команда такая A, какие у нее сотрудники, кто руководитель, какой у нее ФОТ, что она сделала за прошедший квартал. И плюс еще много всяких индивидуальных хотелок. Найти такой продукт, имеющий в себе все, достаточно проблематично, да и выглядят такие системы довольно монструозно. Хороший пример SAP. Мы же вкладываемся в собственную разработку такой системы, которая реализует все потребности различных отделов и интегрируется с другими системами: Gitlab, таск трекер, финансовые системы (1C).

Вместо заключения

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

В будущих статьях на Хабре мы расскажем более подробно о нашем подходе к разработке, планированию и работе с командами. Вместо рекламной паузы ссылка на наши вакансии. Если остались вопросы, то пишите в ТГ @wolverinoid.

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

Подробнее..

SCRUM Развитие сотрудников и продуктовых команд

27.05.2021 12:14:32 | Автор: admin

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

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

Остальные части программы оценки готовности к трансформации:
SCRUM: Понимание и применение фреймворка
SCRUM: Разработка и поставка продукта
SCRUM: Гибкое управление продуктовыми направлениями

Фасилитация встреч и мероприятий

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

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

Метод исследования

Метрика

Роль фасилитатора

Наблюдение за выделением роли фасилитатора в компании

отсутствует выделение и признание роли на уровне компании - 0 баллов

роль фасилитатора проявляется у сотрудников с не руководящими функциями - 1 балл

сотрудники с руководящими функциями выполняют роль фасилитатора - 3 балла

присутствует выделение и признание роли на уровне компании - 5 баллов

Знания фасилитатора

Наблюдение за проявлением знаний фасилитатора в рамках:

- Цель события
- Составные части темы для трансляции
- Бэкграунд и степень синхронизации участников
- Поведение участников в группах
- Набор используемых техник фасилитации

слабо развития система знаний фасилитатора - 0 баллов

сильно развития система знаний фасилитатора - 5 баллов

Навыки фасилитатора

Наблюдение за проявлением навыков фасилитатора:

- Ясное выражение мыслей
- Умение слушать, понимать быстро и фокусировать внимание на важном;
- Структурирование и ведение темы;
- Парафраз вклада участников
- Суммирование и визуализация основных моментов дискуссии
- Мотивация и подогрев участников
- Предоставление правил и инструкций события для участников
- Интеграция результатов смежных групп в общий процесс
- Управление таймингом
- Идентификация динамики группы и соответственная реакция
- Фиксация общего обзора события

слабо развития система навыков фасилитатора - 0 баллов

сильно развития система навыков фасилитатора - 5 баллов

Правила организации

Наблюдение за проявлением правил организации и проведения событий:

- Цель события и ожидаемый результат;
- Содержание и программа события;
- Участники и их роли;
- Время проведения, длительность и место;

Правила фасилитации не устанавливаются - 0 баллов

Правила фасилитации устанавливаются для событий - 3 балла

Для периодических событий , правила зафиксированы в едином месте (например confluence) - 5 баллов

Техники фасилитации

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

- Брейншторминг
- Консенсус
- Дискуссия
- Интервенция
- Фокус на повестку события
- Основные правила события

техники фасилитации не выделяются и не используются - 0 баллов

ограниченное использование техник фасилитации - 3 балла

проявление гибкости в использовании техник фасилитации в зависимости от ситуации - 5 баллов

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

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


Методы развития продуктовых команд

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

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

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

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

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

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

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

Метод исследования

Метрика

Коучинг

Наблюдение за принципом целеполагания команд продуктовых направлений

отсутствует роль, которая помогает команде ставить и достигать цели - 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 на примере швейцарского ножа

04.06.2021 14:18:19 | Автор: admin

MVP (minimum viable product) - это первая версия вашего продукта, с помощью которой вы, как создатель продукта:

  • подтверждаете гипотезу о необходимости конкретного решения, опираясь на поведение пользователей;

  • собираете обратную связь от ваших будущих пользователей;

  • пытаетесь продать (или уже продаёте) ваше решение пользователям.

Пройдёмся по этим пунктам.

Возьмём в качестве примера не сложный IT-продукт, а самый обычный, бытовой предмет: швейцарский нож.

Однажды люди нащупали гипотезу, которая могла явиться проблемой: что если я оказываюсь в диком лесу, и мне нужно срезать гриб и отметить это, выпив бутылку шампанского? Носить с собой штопор и нож - попросту неудобно (да и кто в здравом уме берёт с собой в лес штопор?). Что, если объединить эти инструменты в одно?

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

Представим, что у них это получилось. Что им делать в таком случае?

  1. продолжать продавать текущее решение, параллельно добавляя туда новые инструменты (функции), опираясь на обратную связь и пожелания покупателей;

  2. совершенствовать текущее решение, делать его более удобным (работать над UX);

  3. собирать обратную связь от пользователей и корректировать продукт.

Но всё получается с первого раза только у создателей швейцарских ножей. В реальной жизни 42% стартапов умирают от отсутствия спроса. Каждый раз фаундеры могут заходить на рынок с новым набором инструментов (пробовать разные гипотезы), либо, если всё идет наперекосяк - менять бизнес модель (сделать Pivot).

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

Как это можно сделать?

  1. Производить и пытаться продать совсем маленькие партии;

  2. Экономить на качестве (но не так, чтобы получилось совсем плохо).

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

Как отбирать гипотезы и функции

Гипотеза - это предположение о проблеме клиента.

В одной версии продукта стоит тестировать только одну гипотезу за раз. При этом гипотеза должна быть смелая. Хотят ли люди есть грибы? Определенно да! Готовы ли пить шампанское? О да! Но может ли кому-то внезапно понадобится и нож, и штопор одновременно? Это уже гипотеза, которую стоит протестировать!

Теперь перейдём к тому, что можно включить в первую версию продукта. Ответ прост: нужно включать те функции, которые:

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

2) дают наибольшую ценность для пользователя. Да, в швейцарский нож можно напихать ещё и трекер шагов, и bluetooth колонку, но основную ценность в нашем примере имеет нож и штопор.

Все функции, которые не удовлетворяют этим требованиям, можно смело оставлять на будущее.

Валидация без продукта

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

В IT-сфере - можно, если быть чуть хитрее и умнее, чем наши фаундеры из примера.

К примеру, они могли создать лендинг Чудо Швейцарские Ножи, повести на него трафик из социальных сетей, и посмотреть, оформляют ли люди предзаказ на этот товар. Если да - то его можно производить.

Примеров таких предзапусков в истории множество, но вот мой любимый:

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

К слову, я даже пытался подобрать правильные ответы к анкете, чтобы получить доступ. И у меня это получилось! Но то, что оказалось внутри, мне уже было не интересно (не зря же я подбирал ответы).

Продавать или нет?

Автор книги Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели Эрик Рис говорит, что MVP с первого дня должен продавать. И я с ним абсолютно согласен.

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

Ошибки при разработке MVP

MVP - это непаханное поле для больших ошибок и слитых бюджетов!

Вот какие ошибки вы можете совершить по ходу пьесы:

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

  • Не слушать обратную связь от пользователей. Если вы не проводите тестирования и не слушаете обратную связь от пользователей, то вообще непонятно, зачем вы затеяли MVP. Возможно, вам стоит сразу пилить полноценный продукт и оказаться без миллиона в кармане?

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

  • Недостаточно стараться. Можно придумать отличную идею совместить нож со штопором, но если сделать это в стиле и таааак сойдёт!, то вы рискуете, что ваш пользователь окажется без руки, пользуясь вашим чудом техники. Перефразирую: в 21 веке уже недостаточно сделать косое и кривое приложение. Аппетиты и желания клиентов растут, поэтому постарайтесь, чтобы ваша первая версия выглядела хотя бы симпатично.

  • Влюбиться в продукт. Возможно, посреди разработки вам придется сменить концепцию. Возможно, вам придётся пожертвовать функциями, которые вам были так близки! А возможно, и весь продукт придётся прикрыть. Не влюбляйтесь в ваш продукт, иначе любые изменения будут даваться с трудом. Держите голову холодной, будьте гибкими, слушайте ваших пользователей. Помните, что подкидывать вам проблемы и задачи - это их основная работа.

Подробнее..

Категории

Последние комментарии

© 2006-2021, personeltest.ru