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

It-компании

А ты точно senior? или ожидания продуктовых компаний

07.01.2021 14:19:53 | Автор: admin

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

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

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

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

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

Итак первое знакомство с кандидатом - резюме

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

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

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

Красным флагом могут быть:
частая смена проектов
большие количество проектов с CMS
пустое перечисление ключевых слов от CSS до IDE.

Если будет интересно к теме хорошего оформления резюме как-нибудь вернемся.

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

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

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

Под таблицей есть спойлер с картинкой если на вашем экране таблица поползла)

Junior

Middle

Senior

Архитектура приложений

Есть базовое понимание принципов ООП

Слышал про SOLID

Может придерживаться соглашений проекта и прослеживать аналогии

Знает пару паттернов

Хорошо понимает SOLID

Слышал про GRASP

Знает про модульную архитектуру

Знает какие есть паттерны, понимает когда нужно применять

Знает основные подходы к проектированию приложения(CQRS,ES,Modular,SOA)

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

Может рассуждать про метрики качества кода

Знает паттерны вне GOF

Код

Знает базовые конструкции языка

С помощью гугла может решить основные задачи

Знает основные возможности языка, ряд популярных дополнений/библиотек

Может решить сложные задачи и направить Junior разработчика

Может грамотно построить структуру проекта

Код понятен легко читаем без лишнего усложнения

Структуры данных/алгоритмы

Знает какие есть структуры данных

Может подобрать подходящую для простых случаев

Может написать простой алгоритм, посчитать его сложность

Хорошо понимает структуры данных, в каком случае какую выбрать

Может выбирать, создавать сложные алгоритмы

При выборе алгоритма и структуры данных размышляет про эффективность выбора в разрезе RAM/CPU

Реляционные базы данных

Может строить простые запросы(выборки, простые джоины)

Понимает что такое индексы

Может построить отношения между таблицами

Может строить сложные запросы(сложные джоины, подзапросы, агрегации)

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

Может профилировать запросы, знает explain

Может спроектировать простую структуру базы данных

Понимает как работать с большими таблицами

Знает про репликацию

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

Знает ограничения и возможности популярных баз данных

Понимает ограничения CAP, PACELC

Безопасность

Слышал основные уязвимости

Знает основные OWASP уязвимости и как их предотвращать

Знает ряд техник для мониторинга, предотвращения уязвимостей.

Понимает как действовать при атаке

Тестирование

Есть базовое понимание для чего и как писать юнит тесты

Понимает различия между разными видами тестов

Может эффективно их писать

Понимает как избегать хрупких тестов

Знает разные подходы к написанию тестов(TLD, TDD)

Может рассуждать о пирамиде тестирования

Знает что дает и как создать нагрузочное тестирование

Как плюс знает AB тестирования

API

Знает базовые методы HTTP

Слышал про RPC,REST

Хорошо понимает принципы проектирования API

Знает какие есть варианты авторизаций

Знает основные подходы стандартизации/версионирования API

Может выбрать тип авторизации для проекта

Очереди/ Шина сообщений

Понимает зачем они и как работать на уровне интерфейса языка/библиотек

Понимает разницу между очередью и шинной данных

Знает основные проблемы воркеров и как из предотвращать (утечки памяти, перезапуск, мониторинг)

Знает основные решения по настройке, мониторингу очередей

Может выбрать подходящий брокер

Спроектировать подход к обработке данных (очередь, пайплайн, асинхронный ответ)

Многопоточность/ Асинхронность
Если поддерживает язык

Владеет на уровне интерфейса языка

Знает как работать с многопоточностью
(блокировки, синхронизация)

Знает как работать с асинхронностью

Понимает что такое итоговая согласованность

Когда и как лучше распараллелить процесс

Кеширование

Может работать на уровне интерфейса языка/библиотеки

Догадывается когда использовать

Знает как организовать кеш, какие бывают проблемы

Хорошо знаком с проблемами нагруженного кеша(прогрев, волна запросов, конкурентный доступ)

Инфраструктура/Сети

Знание базовых команд операционной системы

Знает какие этапы проходит запрос перед тем как попасть в приложение

Знаком с одним из средств виртуализации

Понимает какие вещи и как нужно настроить для продакшн среды

Понимает виртуализацию и контейнеризацию

Знает базовые сетевые протоколы TCP, UDP, HTTP, HTTPS

Понимает как устроена сеть DNS, NAT, OSPF, BGP, RIP

Знает как балансировать нагрузку(включая необходимость попадания данных на тот-же сервер)

Хорошо понимает принципы работы CDN и как решать базовые проблемы

Знает ограничения текущей платформы, как их обойти

Метрики/логи

Знает зачем логи, как их писать

Знает варианты сбора логов

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

Может выбрать необходимые метрики

Знаком с рядом вариантов сбора метрик/логов

Способен настроить алертинг, сбор необходимых метрик

Желательно знакомство с TSDB

CVS/ Релиз процесс

Понимает зачем нужна CVS

Может выполнять базовые операции CVS

Может рассказать как сделать простой релиз через CVS и SSH руками

Хорошо знает команды CVS

Знает пару фреймворков построения процесса

Знает как работает CI

Может построить CI процесс, знает какие для этого есть инструменты

Хорошо знает подходы к ветвлению, может выбрать подходящий

PNG

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

Подробнее..

Социотехническое тестирование какое лучше выбрать в 2021 году?

29.12.2020 12:11:44 | Автор: admin


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

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

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

С чего начинается социотехническое тестирование?


Тестирование начинается с формулирования целей. Именно цель определяет остальные составляющие:

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

Для чего и как проводить такое тестирование?


Социотехническое тестирование может проводиться для установления:

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

Соотношение цели социотехнического тестирования (социальная инженерия или СИ) и других его составляющих представлено в таблице.
Определить уровень подготовленности сотрудников Определить эффективность функционирования СЗИ Определить уровень подготовленности сотрудников ИТ- и ИБ-отделов Компрометация инфраструктуры
Формат тестирования письма со ссылкой на поддельный ресурс (фишинг)

письма с исполняемым вложением (нагрузка)

телефонное взаимодействие (вишинг)
письма со ссылкой на поддельный ресурс (фишинг)

письма с исполняемым вложением (нагрузка)
письма со ссылкой на поддельный ресурс (фишинг)

письма с исполняемым вложением (нагрузка)

телефонное взаимодействие (вишинг)
письма со ссылкой на поддельный ресурс (фишинг)

письма с исполняемым вложением (нагрузка)
Начальные условия ФИО сотрудников и email-адреса

номера телефонов, ФИО и/или должности сотрудников, а также любая другая информация согласно легенде

добавление в белые списки
(email-адреса, домены, СЗИ и т.д.)
ФИО сотрудников и email-адреса ФИО сотрудников и email-адреса

номера телефонов, ФИО и/или должности сотрудников, а также любая другая информация согласно легенде

добавление в белые списки
(email-адреса, домены, СЗИ и т.д.)
входная информация не предоставляется
Время на подготовку Одна неделя Две недели Одна-две недели Три недели

Теория, теория Где же обещанные истории?


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

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

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

  • затягивание согласования легенды и предоставления адресов почты для рассылки
  • предоставление неактуального списка сотрудников
  • многократная отработка одной легенды на одних и тех же сотрудниках
  • загрузка подготовленной полезной нагрузки в используемое СЗИ (да-да, здесь речь про проверку осведомленности/подготовленности сотрудников, а не СЗИ...)
  • добавление сотрудников ИТ/ИБ-отделов в рабочую переписку (при том что их уровень осведомленности и проверялся)

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

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

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

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

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

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

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

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

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

Разбираем тренды уходящего года


Форматы социотехнического тестирования


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

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

  • рассылка фишинговых писем со ссылкой на поддельный ресурс 52%
  • рассылка фишинговых писем с исполняемым вложением 36%
  • телефонные звонки (вишинг) 12%

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

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

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

Высокая результативность вишинга объясняется следующими моментами:

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

    о сотрудниках: ФИО, номер мобильного телефона, добавочный номер, адрес корпоративной электронной почты, ник в телеграмме, отдел, в котором работает сотрудник, его должность, дата рождения и фото;

    о компании: наименования подразделений и имена руководителей ключевых подразделений; используемые внутренние системы.
  • В разговоре используется информация, которая указывает на осведомленность эксперта во внутренних процессах компании; отсылки на распоряжения, якобы полученные от начальников структурных подразделений компании. Например:
    Эксперт: Здравствуйте, Татьяна Игоревна! Звоню вам по просьбе руководителя Владимира Алексеевича Кузнецова. У нас произошел инцидент ИБ: по вашему пропуску сегодня через систему контроля управления доступом был зафиксирован проход в хранилище M.
  • Эксперт демонстрирует эмоциональную заинтересованность в сложившейся ситуации или схожие интересы, чтобы притупить внимание собеседника:
    Эксперт: Вы пользуетесь ноутбуком только как рабочим компьютером или по каким-то еще личным делам?
    Сотрудник: Ну, смотрю YouTube еще.
    Эксперт: Да-да, я понимаю. Не переживайте. Просто возможно, что ваша доменная учетная запись была скомпрометирована и с ее помощью смогли пройти через СКУД.

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

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

Кейс 1


Цель: получить информацию разной степени критичности (компания определила информацию, которую считала конфиденциальной).
Легенда: сотрудника уведомляют об инциденте ИБ его пропуск использовали для несанкционированного прохода через СКУД в хранилище М. Служба безопасности расследует инцидент и звонит, чтобы узнать текущее местоположение пропуска, где находился пропуск в рабочее время, существуют ли альтернативные способы для прохождения СКУД. Звонят в нерабочее время (выходной день). Эксперт должен убедить сотрудника проверить доменную учетную запись на факт компрометации сотрудника просят аутентифицироваться на резервном портале (фишинговый ресурс).

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

Вернемся к Татьяне Игоревне и информации, которую она предоставила за время разговора:

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

    02.03.2020 13:48:25#0.2.0.2#ida****:rsa****55#Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.121 YaBrowser/19.3.1.828 Yowser/2.5 Safari/537.36

Компания остановила тестирование сотрудников после того как:

  • 29 телефонных взаимодействий было нами произведено;
  • 23 сотрудника раскрыли конфиденциальную информацию различного уровня критичности.

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

Какие могут быть результаты


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

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

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



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

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

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

Кейс 2


Цель: оценить осведомленность сотрудников в вопросах информационной безопасности.
Легенда: ознакомиться с новой системой премирования. К письму прилагался документ Премии.xls.

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

За время тестирования удалось успешно подключиться к компьютерам 11 сотрудников (14% участников). Столкнувшись якобы с проблемой в работе документа, сотрудники вступали в переписку с экспертами в том числе и не заявленные в тестировании сотрудники.

Пример одной из таких переписок ниже:





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

Окей, возвращаемся к тенденциям


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

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

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

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

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

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



Легенды


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

Ниже представлены основные примеры легенд:

  • Изменение в графике работы
  • Изменение в IT-системах
  • Система премирования
  • Скидки и бонусы
  • События в компании

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

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

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

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

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

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

Кейс 3


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

Количество участников и инфраструктура под спойлером
Количество участников: 150 человек.
Инфраструктура: поддельный домен, поддельный почтовый адрес (якобы принадлежащий ИТ-отделу), поддельная страница входа на VPN-портал.

Пример письма для рассылки:


Мы получили следующие результаты:


Нужно больше тестирований или что будет в периоде


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

К примеру, проверять источник письма или путь, по которому ведет ссылка. В целом, разумная рекомендация, но на практике не всегда работает. Вот смотрите: сотрудник, который получает 15 писем в день (возможно, среди читателей найдутся те, кто мечтает получать *всего* 15 писем в день), а чтение и участие в переписке не его основной вид деятельности, не будет до буквы, до знака проверять адрес отправителя или сверять его ФИО с корпоративным списком контактов.

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

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

Кейс 4


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

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

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


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

Кейс 5


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

Цель: получить валидные учетные данные сотрудников.
Легенда: проверить наличие доступа к новому корпоративному порталу.

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

Активная фаза социотехнического тестирования началась 11 февраля 2020 года в 13:30 (МСК).

Первые учетные данные мы получили через 4 минуты:
Дата и время IP-адрес /
MAC-адрес
Введенные логин и пароль Общая информация о конфигурации рабочей станции
11.02.2020 13:34 0.0.0.1 ni*********a:V******v Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.121 Safari/537.36
11.02.2020 13:34 0.0.0.6 mi****a:2******aB3 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0.3 Safari/605.1.15
Примерно через 30 минут после начала тестирования получили данные, явно указывающие, что легенда раскрыта и сотрудники либо догадались о проводимом тестировании, либо заподозрили атаку: вместо учетных данных в логах собиралась ненормативная лексика.
Дата и время IP-адрес /
MAC-адрес
Введенные логин и пароль Общая информация о конфигурации рабочей станции
11.02.2020 14:02 0.0.0.71 Idi ** *** sobaka:ahahhahaha Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.75 Safari/537.36
Судя по полученным результатам (IP-адрес и информация о рабочей станции), мы подозревали, что это администратор. К этому моменту получили уже 37 учетных данных. Цель достигнута!

Тестирование можно сворачивать и садиться за отчет, но сотрудники продолжали вводить учетные данные. Последний ввод данных был зафиксирован 17 февраля. Следовательно, сотрудники, распознавшие тестирование (или атаку), не предупредили об этом своих коллег.
Дата и время IP-адрес /
MAC-адрес
Введенные логин и пароль Общая информация о конфигурации рабочей станции
17.02.2020 14:08 0.0.0.55 Ty********v:T**********rah Mozilla/5.0 (iPhone; CPU iPhone OS 12_1_4 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0 Mobile/15E148 Safari/604.1
Всего получили 76 уникальных учетных данных. Валидность каждой пары была подтверждена.

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

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

Итоги, проблемы и рекомендации


Наверное, уже пора заканчивать со всеми этими рассказами и историями.

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

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

Также не забывайте о простых правилах цифровой гигиены и рекомендациях по повышению осведомленности в ИБ.

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

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


Возвращаясь к основному вопросу: что же выбрать в 2021-м?

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

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

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

Recovery mode Хабрастыд-2020

04.01.2021 14:06:43 | Автор: admin
Привет, Хабр! В конце каждого года принято подводить различные итоги и Хабр не стал исключением. Лента наполняется темами типа топ ЯП по итогам 2020, топ 10 технологий, топ 20 работодателей, тысячи их. Но чего нет так это списка зашкваров года, которые подарили нам IT-компании и которые вызывают чувство испанского стыда. Надо сделать, подумал я и составил такой топ сам. Почему, зачем и собственно сами герои под катом. И прошу не судить строго, это мой первый, чисто развлекательный пост.

Каин после убийства своего брата Авеля Анри Видаль 1896 г.



Это уже было в Симпсонах


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

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

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

Зачем


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

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

Копирасты года Wargaming


Ещё 17 декабря 2019 года, картофельная танковая фабрика оскандалилась тем, что начала юридически преследовать своих бывших сотрудников в судах Беларуси, Кипра и США за работу над опенсорс проектом движка движка DAVA Framework/DAVA Engine, который она официально развивала до весны 2018 года. Поддержка проекта в качестве опенсорс официально декларировалась Wargaming на многих конференциях, в статьях, интервью и других источниках. Но потом, пять незадачливых выходцев из Wargaming, которые на данный момент работают в БлицТим, получили персональные иски и требование компенсации в виде $1 690 000.

Вышеупомянутые сотрудники ранее работали в минском центре разработки кипрской группы компаний Wargaming и принимали непосредственное участие в разработке игры World of Tanks Blitz и движка DAVA Framework/DAVA Engine, который потом использовали в собственном проекте Battle Prime. Когда проект (выглядящий, между прочим, очень годно) был представлен, картофельная фабрика золотых снарядов его тоже оценила и захотела поиметь свой гешефт.

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

Работники года ДИТ


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


Криво работающие Цифровые пропуска получающие разрешение на отправку рекламы на следующие 10 лет, забагованный Социальный мониторинг, наспех собранный из кода трекера мусоровозов и обязывающий людей раз в 3 часа делать селфи и отсылать на проверку, откровенно шпионское Госуслуги СТОП Коронавирус (это реальное название от богов нейминга) все это поделки этих ребят. При этом их бюджет в 2020 составил 80 млрд руб. Как говорится, делайте выводы господа. Что забавно, по собственной оценке бракоделов из ДИТ все это позволило Москве избежать самого опасного сценария, который был в Италии и других европейских странах. Ага, конечно, особенно если отчётность по заболевшим можно подкручивать.

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

Перевозчики года Яндекс.Такси


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

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

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

Связисты года Yota



Можно как угодно относиться к ФБК, их фюреру и их деятельности (мне, например, нравится их блог на YouTube), но в 2020 с их подачи в этом посте можно упомянуть компанию Yota, которая незаконно отключила связь одному из самых известных сотрудников ФБК Руслану Шаведдинову в момент, когда силовики ломали дверь в его квартиру, чтобы не дать ему возможности оповестить родных или адвоката о происходящем, и спустя несколько дней даже не удосужилась прокомментировать эту постыдную историю. Позже стало известно, что Yota ещё и установила особый режим для номера Шаведдинова, при звонке, на который сообщается, что абонент находится не в сети. Также к номеру прикреплена плашка с пометкой обо всех действиях по номеру сообщать в PR.


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

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

Карьерная возможность года Wildberries


Случай, который на Хабре не освещен был вообще. В конце сентября закрыли крупный проект из 30 человек, а от руководства поступило указание сократить на некоторых проектах 30% штата. Такое случается, конечно, но это было лишь начало.


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

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

Стыд года Рамблер


В этой номинации и не могло быть другой кампании, ведь инциденты подобные этому происходят чуть ли не раз в несколько лет. Данная история была широко освещена на самом Хабре и за его пределами, поэтому я не буду детально ее пересказывать. Кратко напомню, что в декабре 2019 Рамблер спустя 18 лет начал судебное преследование своих бывших сотрудников Игоря Сысоева и Максима Коновалова, пытаясь отжать у них права на самый популярный в мире веб-сервер Nginx, который был создан в 2002, когда Сысоев работал в Рамблере сисадмином. Незадолго до этого, Nginx был куплен американской корпорацией F5 Networks за $670 млн. Узнав об этом, в Рамблере жутко возбудились и посчитав, что Nginx был создан в служебное время, и заявили о своих правах на проект. Немедленно было возбуждено уголовное дело, а в офисе у Сысоева и Коновалова даже прошли обыски. Претензии предъявила компания Рамблер, хотя формально обвинителем стала Lynwood Investments CY Ltd, которой передали на это права. Последняя связана с совладельцем Rambler Group Александром Мамутом.

Реакция общественности не заставила себя долго ждать и IT-аудитория облила Рамблер таким потоком говна, что долетело даже до самого Германа Грефа, который через своего зампреда Льва Хасиса, который на тот момент был председателем совета директоров Рамблера, был вынужден вмешаться. В итоге в 2020 Рамблер попросил прекратить уголовное дело о правах на Nginx, исключив себя из числа потерпевших. Правда теперь истцом станет кипрская Lynwood, продолжив разбирательство уже в международном суде.

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

Что забавно, сам Хабр показал себя в этой истории довольно неоднозначно. Ситуация с Nginx сподвигла написать пост самого Денискина, редакция вела хронологию инцидента, а на главной была даже специальная ссылка, позволяющая держать руку на пульсе ситуации. Но это всё не помешало пригласить Рамблер в марафон удалёнки. Как говорится, вы не понимаете, это другое. В целом понятно желание быть IT-Швейцарией, но тут либо крестик снимите, или трусы наденьте.



Заключение


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

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

Минутка заботы от НЛО


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

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

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

Увидеть всё. Как и зачем мы создаём цифрового двойника посылки

29.12.2020 16:19:06 | Автор: admin

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

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

Зачем нужен цифровой двойник

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

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

Двойник собирает и анализирует данные всё то время, пока отслеживаемая посылка едет по адресу. А интерактивный анализ собранных больших данных позволяет:

  • получать точную информацию о производительности системы;

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

  • управлять объектами и процессами удалённо в режиме онлайн.

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

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

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

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

Учитывая специфику работы Почты, мы смотрим не только на цифровой след посылки, который та оставляет в наших IT-системах, но и на все офлайн-перемещения и влияние офлайн-процессов на онлайн. Сейчас путь посылки состоит из пяти основных процессов:

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

Service Blueprint первый этап создания двойника

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

Часть процессов уже происходит онлайн, а какие-то пока не оставляют за собой цифрового следа. А ведь чем больше информации мы будем получать о посылке, тем лучше сможем влиять на эффективность. Чтобы свести картину путешествия посылки воедино, мы используем Карту сервиса (Service Blueprint) схематическое изображение всего, что происходит на пути посылки. Карта включает в себя как путь клиента, так и всё закулисье сервиса. Service Blueprint первый этап в создании цифрового пути посылки. Для одной части процессов мы прорисовываем CJM (customer journey map путь клиента), для другой верхнеуровневые схемы взаимодействия процессов и систем.

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

Чтобы решить проблему пользователя или существующего процесса, надо понять, откуда она взялась. Для этого мы составляем Job story описание сценариев возникновения проблем и действий. Это особым образом структурированные гипотезы. Например: Я пришёл в отделение и мне нужно занять очередь, но зачем? Чтобы получить доступ к окну. А как ещё это можно сделать? Заранее записаться через мобильное приложение.

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

Что даёт карта?

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

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

Как работает цифровой двойник посылки

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

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

Информация поступает в основное хранилище всех операций Data Cloud Почты России. Облако не только сопровождает посылку, а ещё и хранит данные о её передвижениях. У нас есть не только оперативная информация о том, что пересылается прямо сейчас, а ещё и исторические данные по уже врученным отправлениям. Их мы используем, чтобы анализировать путь доставленных посылок.

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

Сдача посылки

Для присвоения трек-номера, с которого начинается путь двойника, не обязательно идти в отделение достаточно оформить посылку в мобильном приложении или на сайте. Там же можно получить расчёт стоимости доставки и подготовить ярлык для наклеивания на упаковку. Юридические лица тоже могут передавать данные об отправлениях до сдачи через API. Если не оформлять посылку заранее, то трек-номер ей присвоит оператор в отделении.

Логистика

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

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

Отслеживанием и исправлением проблем в дороге занимается ситуационный центр. Здесь сотрудники следят за отклонениями от контрольных сроков в режиме реального времени, используя данные из DataСloud.

Сортировка

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

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

Приём и выдача

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

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

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

Как будет развиваться двойник

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

Не только мы сами пользуемся данными двойника наши клиенты активно используют трекинг. За 2020 год страница отслеживания посылок на портале pochta.ru набрала 823 млн посещений, а трекинг в мобильном приложении больше миллиарда. Несмотря на хорошее покрытие процессов цифровым двойником, нам ещё предстоит решить задачи, связанные с использованием полученных от него данных. Например, пока что мы прогнозируем сроки доставки, опираясь на прошлую статистику, а хотим делать это с учётом оперативной обстановки. Засыпало рельсы в Сибири снегом мы моментально обновили сроки для посылок, застрявших в составе. Как только ситуационный центр решил проблему и посылки переложили из застрявшего вагона в автомобили снова скорректировали срок. Также в списке задач научиться оперативно дозагружать автомобили, чтобы использовать ресурсы на 100%, а также разработать мобильное приложение водителя для более точного учёта затрат.

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

Подробнее..

Рецепт дня готовим сообщество профессионалов, не выходя из своего отдела

14.01.2021 10:07:09 | Автор: admin

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

Доклад в виде пошагового рецепта QA-лидам, fullstack feature team-лидам, SM и всем тем, кто решает задачу эффективной настройки процессов команд, представила на конференции TeamLead Conf 2020 Head of Android QA одного из флагман-продуктов компании ЦФТ Надежда Потаенко.

Продукт ЦФТ Золотая Корона в 2016 году прочно стояла на позиции самой крупной системы денежных переводов без открытия счета на территории России и СНГ. В момент, о котором пойдет повествование, у пользователей появилась возможность начать отправлять переводы не только офлайн, но и через веб и мобильные фронты.

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

Стало понятно, что продукт взлетел, и его надо срочно развивать. Именно высокая востребованность продукта заставила ЦФТ очень быстро вырасти. За три года команда разработки продукта Денежные Переводы Online увеличилась с 7 до 200+ человек. В какой-то момент старые производственные процессы просто перестали работать. Сотрудники вынуждены были отправиться на поиски новых конфигураций.

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

Для кого готовим?

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

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

Что было в холодильнике?

Шел 2016 год, и в компании стал развиваться продукт, который начал активно зарабатывать деньги. Ранее этот продукт разрабатывала сравнительно небольшая команда из 20 человек (4 компонентные команды: Backend, Web, iOS, Android), все сидели в славном городе Томске и были экспертами в продукте. Казалось, все идет просто идеально!

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

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

Настал 2018, и боги провозгласили год найма и новых рук. Компания начала расти, причем не только в Томске, но параллельно в Новосибирске и в Питере. На графике видно, что в конце 2018 появилось 130 инженеров в 3 локациях, а в 2019 их стало больше 200. Это около 30 команд, которые сейчас совместно пилят один и тот же продукт: Денежные Переводы Online.

От такого роста ожидали увеличение скорости разработки и сокращение TTM, но получили совершенно иную картину.

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

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

  • Не успевали качественно онбордить

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

  • Разный уровень hard skills в разных локациях

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

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

Другой пример: в Новосибирске инженеры считали, что побегать за аналитиком и дожать из него недостающую информацию это ОК. В Питере ребята сказали: Ну нет! Должен быть четкий Definition of Ready. Мы ни за кем бегать не будем!

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

  • Релизила по-прежнему одна команда

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

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

В какой-то момент Надежда поняла, что надо спасать коллег по цеху.

Шаг 1: Перемешать и поставить на плиту

Первым шагом стало привлечение к процессу регрессионного тестирования и вообще к релиз-производству QA инженеров из фича-команд, которые раньше в этом процессе не участвовали, для того, чтобы:

  • Повысить степень причастности и ответственности;

  • Выровнять уровень понимания бизнес-логики продукта.

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

Шаг 2: Довести до кипения

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

Например, что-то тестили, попали на незнакомый flow, испугались, завели баг, кинули его в чат Android: кто-нибудь потом разберется. А на самом деле просто заехала новая фича, поменялся flow, а тест-кейсы еще не актуализировали.

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

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

Как тушить все это, было непонятно.

Шаг 3: Остудить, еще раз перемешать

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

  • Выработать единый подход к регрессу;

  • Найти способы ускорить регресс;

  • Восстановить качество релизов;

  • Делиться друг с другом экспертизой в продукте.

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

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

А еще ей хотелось сформулировать цель совместной работы.

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

Качественно и быстро это отсылки к желаемому сокращению ТТМ и к восстановлению уровня качества.

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

Мозговой штурм был построен на базе книги 5 пороков команды Патрика Ленсиони. И на него было потрачено около 8 часов.

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

Когда участники встречи разъезжались, заряд community был такой мощный, что все говорили: Эге-гей! Да мы следующий регресс вообще за день бахнем!.

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

Шаг 4: Выпекать до готовности

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

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

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

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

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

Канал коммуникации очень простой: QA-инженеры раз в две недели встречаются онлайн в Microsoft Teams.

За счет таких встреч им удалось выработать единый подход к регрессу и найти способы ускорить его.

Осторожно! Горячо!

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

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

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

Шаг 5: Сбрызнуть соком лимона

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

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

В команде появился такой wishlist:

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

Но проблемы начались с самого первого митапа.

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

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

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

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

Шаг 6: Дать отдохнуть

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

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

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

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

Профиты командировок:

  • Для продукта: быстрый шаринг экспертизы;

  • Для инженеров: сменить обстановку, пообщаться с иногородними коллегами.

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

Что дальше?

В 2020 году в ЦФТ появились новые цели саморазвития гильдии.

  • Коммуникация с QA-гильдиями других платформ продукта;

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

  • Ежемесячные публикации блога с обзором новостей платформы и сообщества.

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

Есть и продуктовые цели.

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

Выводы в цифрах и фактах

На картинках активности, которые пробовали применять в QA-сообществе ДП Online.

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

И немного статистики релизов продукта за 2018-2019 годы. Внизу красным подсвечены hot fixы. В 2018 году в ДП Online было нормой раз в 3-4 релиза выпустить hot fix. С 2019 года, когда начала собираться гильдия экспертов, hot fixов почти нет. За весь 2019 год выпустили всего 4. Причем речь не о клиентских, а о технических hotfixах, например, когда какое-то событие было потеряно в Google Analytics.

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

  • Тюнинг soft skills;

  • Единое информационное поле;

  • Здоровая конкуренция;

  • Новые лиды.

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

Программный комитет Saint TeamLead Conf 2021 ждет ваши доклады.

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

Присоединяйтесь!

Подробнее..

9 вещей, которые айтишники хотят в подарок на НГ

29.12.2020 10:06:55 | Автор: admin
Для большинства из нас по всему миру сезон отпусков не за горами. Многие уже купили все подарки. Но уверен, некоторые, как обычно, оставили все на последний момент.

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

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



1. Книга GitHub для чайников


Копия "GitHub для чайников", которая пригодится, если вы хотите узнать больше о GitHub или ищете полезный подарок, чтобы вдохновить нового разработчика!



GitHub крупнейшее open-source-сообщество, и благодаря знаниям о том, как использовать GitHub, книга открывает двери для людей, чтобы они могли вносить свой вклад в проекты с открытым исходным кодом, сотрудничать с людьми в их собственных проектах и учиться у других. Я участвовала в создании этой книги, потому что считаю, что у каждого должна быть возможность присоединиться к полезным сообществам. Мне нравится, что эта книга не только знакомит с функциями GitHub, но и знакомит с Git в командной строке, а также с тем, как продолжать участвовать в сообществах за пределами GitHub через конференции и мероприятия". Доктор Сара Гутхалс, @drguthals

2. Raspberry Pi 400

Независимо от того, новичок вы в программировании или опытный профессионал, Raspberry Pi 400 обязательно заинтересует вашего внутреннего гика!



Обзор: Raspberry Pi 400 должен быть в списке желаний каждого! Это Raspberry Pi с клавиатурой, похожей на комплектные к компьютерам, на которых я вырос, например ZX Spectrum. Просто подключите мышь и телевизор и вперед! Еще один бонус? Он запускает VS Code нативно! " Джим Беннет, @jimbobbennett

3. Instant Pot


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



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

4. Nintendo Switch Travel Pack


Рекомендация от Скотта Хансельмана: Nintendo Switch Travel Pack, который поможет вам отдохнуть и поиграть в дороге или на диване.



Обзор: Со дня запуска у меня был Nintendo Switch, и позвольте мне сказать вам, это весело. Радостно. Это маленькое устройство для радости. Я люблю 4k Xbox и грубую мощь, но Switch продолжает выпускать веселые игры. Инди-игры, игры Metroidvania, такие как Axiom Verge, Legend of Zelda: Breath of the Wild, а теперь и Super Mario Odyssey. Даже Doom и Wolfenstein 2 скоро появятся на Switch! Я уже путешествовал со своим Switch повсюду. Вот то, что я придумал для своих путешествий и мой домашний Switch Experience. Я должен и использую эти предметы лично и я ручаюсь за их крутость и полезность . Скотт Хансельман, @shanselman

5. Mezzaluna


Итальянский разделочный нож он же Mezzaluna чтобы приготовить что-нибудь вкусненькое после долгого дня программирования. Buon appetito!



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

6. Elgato Stream Deck


Elgato Stream Deck, который поможет начать стримить или делать это еще качественнее.



Обзор: Stream Deck это небольшая программируемая внешняя клавиатура с ЖК-кнопками, которая поставляется с начальной конфигурацией, чтобы помочь стримерам запускать свои трансляции без необходимости менять приложения, вводить текст или перемещать мышь. Это может помочь вам, автоматизируя взаимодействие с использованием Open Broadcaster Software (OBS) воспроизводить звуки, запускать приложения, управлять приложениями мультимедийного проигрывателя, отправлять нажатия клавиш и взаимодействовать с такими сервисами, как Twitter, Twitch и YouTube. Имеются встроенные инструменты для выполнения целой серии этих действий одним нажатием кнопки, и каждая кнопка может иметь собственный блок с текстом или изображением для представления ее функциональности. Разработчикам понравится stream deck, потому что его можно расширить с помощью WebSocket API с использованием JavaScript, HTML или даже C# для создания подключаемых модулей, которые позволят создавать анимацию, макросы и взаимодействовать с любимыми инструментами. Мы видели, как люди настраивали кнопки для запуска и остановки приложений, а также для автоматизации функций в их любимых инструментах разработки. " Джефф Фриц, @csharpfritz

7. Перьевая ручка


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



Обзор: Мне нравится, как прочная old-school-ручка заставляет меня записывать вещи. Поскольку мне так нравится писать пером, я начал планировать свои дни в Self Journal, даже расписывая, что хочу сделать на следующий день. Это даже было полутерапевтическим во время пандемии, когда все, кажется, странным образом складывалось вместе: это помогает мне видеть прогресс и помогает в достижении цели . Сет Хуарес, @sethjuarez

8. Портативный мини-вентилятор


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



Обзор: Этот вентилятор стал одной из моих любимых недавних покупок! Он не только помогает мне охлаждаться во время работы, но я также использую его дома! Недавно я обзавелась местом (для всех моих поделок, проектов Интернета вещей и т.д.), и этот вентилятор помог скорее высушивать краску/клей/другое. Холдер также позволяет легко закрепить вентилятор на любой поверхности (компьютер / стол / станция для дома), которая вам нужна! Хлоя Кондон, @ChloeCondon

9. Жилет с подогревом


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



Обзор: Давным-давно, когда я все еще часто путешествовал на самолете (до января 2020 года) я увидел женщину в светящемся жилете, ожидающую свой багаж, и мне захотелось спросить ее об этом. Я записал марку жилетки и заказал себе одну, пока ждал своей поездки до дома. Жилет милый, качественный, а главное теплый. Он имеет три различных уровня нагрева, а аккумулятора хватает на несколько часов без подзарядки (аккумулятор также можно использовать в качестве портативного зарядного устройства USB). Жилет выпускается как в мужском, так и в женском стиле, и компания производит и другие изделия с подогревом, такие как толстовки, парки, перчатки и даже носки. Так что, если вам постоянно холодно, как мне, или вы знаете кого-то, кто такой, я настоятельно рекомендую проверить это! Морган Митчелл Белл, @livelovegeek

Итак, это все! Что привлекло ваше внимание? Что бы вы добавили в этот список? Дайте нам знать в комментариях ниже!
Подробнее..

Перевод Заброшенный сайд-проект, который превратился в бизнес с доходом в 200 млн долларов в год

02.01.2021 20:04:09 | Автор: admin

20-летний путь Бена Честната, основателя MailChimp


Ему было 26 лет, когда его уволили и он основал студию веб-дизайна.

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

После увольнения в 2000 году Бен Честнат занялся тем, что знал лучше всего, разработкой веб-сайтов. За эти годы он создал около двух тысяч рекламных баннеров для своего бывшего работодателя, газеты Cox. Он точно знал, как создавать интерактивные объекты в Интернете.

И я подумал Что ж, это наш шанс открыть компанию. Мой деловой партнёр и я просто нашли клиентов. Мы пошли стучаться в двери по коридору от нашего офиса. И у нас появились оплачиваемые проекты. Мы получили проекты на 13 000 и 32 000$. Даже до получения лицензии на бизнес.

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





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

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

Родился Сhimp


В Rocket Science Group творческие умы уставали от многократного внедрения одной и той же функции на веб-сайты своих клиентов: инструмента для создания списков рассылки. Описанная работа была повторяющейся и созрела для творческой автоматизации. Чтобы избавиться от бремени, команда разработала универсальное решение с самообслуживанием и взимала с клиентов по 1 центу за каждое отправленное письмо.

Вместо того чтобы игнорировать проблему, Бен и Дэн определили это как возможность помочь своим клиентам решить её. Они взяли код из созданного ими неудавшегося продукта цифровой поздравительной открытки и настроили его, чтобы в 2001 году запустить MailChimp для клиентской базы своей веб-студии.


Слух распространялся медленно. Старые клиенты, которые больше не работали с Rocket Science Group, всё ещё использовали инструмент электронной почты. Владельцы малого бизнеса, которые никогда не были клиентами агентства, начали обращаться с запросами. В то время как Бен был сосредоточен на том, чтобы обеспечить студию, его инструмент электронной почты тихо вырастил своих собственных маленьких последователей.

Суммы по-прежнему были незначительными. Когда вы гонитесь за проектами веб-дизайна на 30 000$, несколько счетов на 50$ не требуют особого внимания. По иронии судьбы, именно всё более неэффективная задача выставления этих небольших счетов побудила Бена ввести модель ежемесячной подписки и создать функциональность, связанную с кредитной картой для MailChimp, что фактически породило один из первых продуктов SaaS.

Как фоновый инструмент, используемый внутри компании, без вложений превращается в гигантского промышленного гиганта стоимостью 4,2 млрд. долларов? Расскажем коротко используя партизанские приемы:

  1. Полувирусная модель freemium основная причина успеха Chimp, она способствовала его росту со 100 тыс. до 1 млн. пользователей всего за год. В то время было новшеством предоставить пользователям бесплатный доступ ко всей вашей платформе. Взрывной успех модели freemium был двояким: во-первых, каждое бесплатное электронное письмо содержало в сносках логотип MailChimp, создавая полувирусный цикл органических переходов; поскольку пользователям приходилось платить только после того, как они набирали определённое количество писем в своём списке, получение вашего первого платного плана MailChimp действовало как обряд, на который вы должны были заработать свой путь.
  2. Нишевые социальные платформы. Изначально компания называлась Code. Blog. Tweet. Repeat просто потому, что эта маркетинговая стратегия работала. В 2007 году Twitter был гораздо менее загружен, и MailChimp получил большую известность в сети. Точно так же они купили рекламу, которую будут воспроизводить в начале каждого нового эпизода криминального подкаста под названием Serial. Сегодня подкаст стал хитом он был первым, достигшим 5 млн. загрузок в истории подкастов, но покупка рекламы на нём была хипстерской вещью в то время, а следовательно, недорогой.
  3. Создатель маркетинговых кампаний. В 2014 году диктор одного из рекламных подкастов случайно неправильно произнёс MailChimp как MailKimp. Рекламу транслировали миллиону пользователей, но, по сути, компания решила превратить этот казус в целую маркетинговую кампанию. Вскоре появятся целые бренды MailShrimp, FailChips, VeilHymn и множество других спин-оффов Bumblesnuff-Crimpysnitch-esque были запущены вместе с удивительно креативными кампаниями. Странно? Вроде. Смешно? Просто посмотрите пародию на интервью с художником VeilHymn.
  4. The Chimp! Теории, стоящие за брендингом в качестве универсального продукта, часто бывают глупыми, но шимпанзе определённо сработали у Бена. Еще будучи веб-дизайнером, он узнал, что добавление обезьяны к любому маркетинговому дизайну повышает его эффективность. За прошедшие годы Chimp стал чемпионом бренда, отправляя глупые комментарии пользователям при входе в систему, отключив их в режиме вечеринки в настройках. Серьёзно, сколько ещё почтовых платформ вы сможете назвать?

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

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

Бен: Контент, который мы выпускаем, похож на Второй шанс в жизни Как узнать, когда нужно держаться, а когда сдаться С такой борьбой [малые] предприниматели сталкиваются постоянно. [ ] Мы хотим помочь им выбраться из кухни.

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

Заткнись и возьми наши деньги!


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

Главная причина, по которой Бен мог сделать это, заключается в том, что MailChimp с самого первого дня был приносящим доход программным обеспечением. Цены на продукт менялись на протяжении многих лет (за электронную почту > ежемесячную подписку > freemium), но, в отличие от таких продуктов, как WhatsApp, у него была очень чёткая модель дохода, не предполагавшая продажи данных пользователей. Кроме того, крайне важно учитывать, что MailChimp был побочным продуктом управляемой Беном студии, через которую MailChimp финансировался изначально.

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

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

Инвесторы не могли проверить доходность. Зачем обслуживать сильно фрагментированную, эмоциональную, малобюджетную аудиторию малого бизнеса, когда 30% выйдут из бизнеса через 2 года, а 50% в ближайшие 5 лет? Исходя из личного опыта Бен понимал, что, даже когда сольные проекты терпят неудачу, они сохраняют свои списки рассылки и большинство из них начинают что-то новое в будущем. Таким образом, MailChimp не обязательно теряет клиента, даже если он временно уходит из бизнеса.

Конечно, как только доходы начали расти, инвесторы выстроились в очередь за дверью MailChimp. За эти годы Бен видел, как десятки конкурентов взяли миллионы на финансирование в надежде перерасти компанию. Каждый участник, поддерживаемый VC, может означать, что Бен совершил ужасную ошибку, оставаясь самофинансируемым. Однако, по состоянию на 2020 год, MailChimp всё ещё находился в комфортном положении с 60%-ной долей в индустрии электронной почты.

Бен: Я в этом бизнесе уже 19 лет. Так что у меня были волны конкурентов, которые брали деньги инвесторов, и я прошёл через стадии, когда говорил: Господи, сейчас они меня убьют. Финансирование становится всё больше и больше и, кажется, ничего не происходит. Мы просто держим прицельный фокус [...] и всё в порядке.

Мог бы MailChimp расти ещё быстрее, если бы у проекта были деньги VC? Возможно. Но, скорее всего, и корпоративные инвесторы постепенно отщепили бы культуру творчества и инноваций MailChimp, что и сделало компанию особенной.

7 интересных фактов о Бене Честнате и MailChimp


  1. Для Бена смесь запахов сигаретного дыма и лака для волос это запах бизнеса. Его мама устроила парикмахерскую на их кухне, и именно так Бен в детстве познакомился с предпринимательством.
  2. При приёме на работу Бен ищет скромных преподавателей, которые настолько хороши, что просят критики. Ему нужны люди, которые достаточно уверены в своих силах, чтобы у них не было проблем с оспариванием их взглядов или с простым объяснением сложных понятий. Бен говорит, что, если человек не может рассказать что-то до глупости просто, он не подходит для MailChimp.
  3. Первый нанятый Беном человек и (предположительно технический) соучредитель Дэн Курциус на собеседовании солгал, что знает, как писать код. После того как он получил работу, он собрал прототип MailChimp, используя книги HTML для чайников. Дэн так старался, что фактически создал (или украл) чистый функциональный код, который поразил Бена. Только через 10 лет соучредитель рассказал Бену о своей импровизации.
  4. Бен подтвердил, что отклонил предложение о приобретении MailChimp за миллиард долларов от неуказанной компании. В свою защиту он говорит, что миллиард долларов не намного больше, чем несколько сотен миллионов.
  5. Держащийся в тени соучредитель Дэн Курциус регулярно и анонимно посещает предприятия малого бизнеса, использующие MailChimp, от студий йоги до складов. Таким образом, компания получает бесценную обратную связь, например, так компания узнала о факте, что многие компании используют MailChimp как CRM, а не как инструмент электронной почты. Это действительно немного странно, когда на мероприятиях MailChimp крупнейшие критики позже узнают, что они разговаривали с соучредителем.
  6. Одна из любимых книг Бена Человек в поисках смысла Виктора Франкла. Франкл психиатр, переживший концентрационный лагерь во время Холокоста. В книге он документирует, как заключённые находят смысл и цель даже в самых бесчеловечных условиях.
  7. Девиз Бена: люби то, что делаешь, а не традиционное делай то, что любишь. Он говоритСо временем все страсти угаснут, если вы превратите их в профессию, и единственный способ сохранить чувство цели научиться любить ремесло, в котором вы хорошо разбираетесь.

Ребята, никто не придёт


В качестве эпилога я бы хотел оставить тебе одну из моих любимых цитат Бена Честнета:

Когда тучи сгущаются и становится тяжело что часто бывает, когда ты предприниматель, я вспоминаю кое-что, что я понял, когда вырос в Апсоне, в Джорджии. Это то, что я сказал друзьям, когда мы заблудились, бродили по лесу. Я сказал: Ребята, никто не придёт. [Бен смеётся] Это звучит не очень позитивно или как-то так, простите, но это то, что вы должны понять: никто не придёт! Всё зависит от нас! Когда ты предприниматель, никто не придёт тебе на помощь. Тебе решать, что нужно делать, чтобы выбраться из этого бардака. Но если ты выберешься из него, к тебе присоединится много людей. [...] Я постоянно говорю это себе.


image



Подробнее..

Перевод Заброшенный сайд-проект, который превратился в бизнес с доходом в 700 млн долларов в год

02.01.2021 22:16:45 | Автор: admin

20-летний путь Бена Честната, основателя MailChimp


Ему было 26 лет, когда его уволили и он основал студию веб-дизайна.

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

После увольнения в 2000 году Бен Честнат занялся тем, что знал лучше всего, разработкой веб-сайтов. За эти годы он создал около двух тысяч рекламных баннеров для своего бывшего работодателя, газеты Cox. Он точно знал, как создавать интерактивные объекты в Интернете.

И я подумал Что ж, это наш шанс открыть компанию. Мой деловой партнёр и я просто нашли клиентов. Мы пошли стучаться в двери по коридору от нашего офиса. И у нас появились оплачиваемые проекты. Мы получили проекты на 13 000 и 32 000$. Даже до получения лицензии на бизнес.

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





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

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

Родился Сhimp


В Rocket Science Group творческие умы уставали от многократного внедрения одной и той же функции на веб-сайты своих клиентов: инструмента для создания списков рассылки. Описанная работа была повторяющейся и созрела для творческой автоматизации. Чтобы избавиться от бремени, команда разработала универсальное решение с самообслуживанием и взимала с клиентов по 1 центу за каждое отправленное письмо.

Вместо того чтобы игнорировать проблему, Бен и Дэн определили это как возможность помочь своим клиентам решить её. Они взяли код из созданного ими неудавшегося продукта цифровой поздравительной открытки и настроили его, чтобы в 2001 году запустить MailChimp для клиентской базы своей веб-студии.


Слух распространялся медленно. Старые клиенты, которые больше не работали с Rocket Science Group, всё ещё использовали инструмент электронной почты. Владельцы малого бизнеса, которые никогда не были клиентами агентства, начали обращаться с запросами. В то время как Бен был сосредоточен на том, чтобы обеспечить студию, его инструмент электронной почты тихо вырастил своих собственных маленьких последователей.

Суммы по-прежнему были незначительными. Когда вы гонитесь за проектами веб-дизайна на 30 000$, несколько счетов на 50$ не требуют особого внимания. По иронии судьбы, именно всё более неэффективная задача выставления этих небольших счетов побудила Бена ввести модель ежемесячной подписки и создать функциональность, связанную с кредитной картой для MailChimp, что фактически породило один из первых продуктов SaaS.

Как фоновый инструмент, используемый внутри компании, без вложений превращается в гигантского промышленного гиганта стоимостью 4,2 млрд. долларов? Расскажем коротко используя партизанские приемы:

  1. Полувирусная модель freemium основная причина успеха Chimp, она способствовала его росту со 100 тыс. до 1 млн. пользователей всего за год. В то время было новшеством предоставить пользователям бесплатный доступ ко всей вашей платформе. Взрывной успех модели freemium был двояким: во-первых, каждое бесплатное электронное письмо содержало в сносках логотип MailChimp, создавая полувирусный цикл органических переходов; поскольку пользователям приходилось платить только после того, как они набирали определённое количество писем в своём списке, получение вашего первого платного плана MailChimp действовало как обряд, на который вы должны были заработать свой путь.
  2. Нишевые социальные платформы. Изначально компания называлась Code. Blog. Tweet. Repeat просто потому, что эта маркетинговая стратегия работала. В 2007 году Twitter был гораздо менее загружен, и MailChimp получил большую известность в сети. Точно так же они купили рекламу, которую будут воспроизводить в начале каждого нового эпизода криминального подкаста под названием Serial. Сегодня подкаст стал хитом он был первым, достигшим 5 млн. загрузок в истории подкастов, но покупка рекламы на нём была хипстерской вещью в то время, а следовательно, недорогой.
  3. Создатель маркетинговых кампаний. В 2014 году диктор одного из рекламных подкастов случайно неправильно произнёс MailChimp как MailKimp. Рекламу транслировали миллиону пользователей, но, по сути, компания решила превратить этот казус в целую маркетинговую кампанию. Вскоре появятся целые бренды MailShrimp, FailChips, VeilHymn и множество других спин-оффов Bumblesnuff-Crimpysnitch-esque были запущены вместе с удивительно креативными кампаниями. Странно? Вроде. Смешно? Просто посмотрите пародию на интервью с художником VeilHymn.
  4. The Chimp! Теории, стоящие за брендингом в качестве универсального продукта, часто бывают глупыми, но шимпанзе определённо сработали у Бена. Еще будучи веб-дизайнером, он узнал, что добавление обезьяны к любому маркетинговому дизайну повышает его эффективность. За прошедшие годы Chimp стал чемпионом бренда, отправляя глупые комментарии пользователям при входе в систему, отключив их в режиме вечеринки в настройках. Серьёзно, сколько ещё почтовых платформ вы сможете назвать?

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

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

Бен: Контент, который мы выпускаем, похож на Второй шанс в жизни Как узнать, когда нужно держаться, а когда сдаться С такой борьбой [малые] предприниматели сталкиваются постоянно. [ ] Мы хотим помочь им выбраться из кухни.

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

Заткнись и возьми наши деньги!


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

Главная причина, по которой Бен мог сделать это, заключается в том, что MailChimp с самого первого дня был приносящим доход программным обеспечением. Цены на продукт менялись на протяжении многих лет (за электронную почту > ежемесячную подписку > freemium), но, в отличие от таких продуктов, как WhatsApp, у него была очень чёткая модель дохода, не предполагавшая продажи данных пользователей. Кроме того, крайне важно учитывать, что MailChimp был побочным продуктом управляемой Беном студии, через которую MailChimp финансировался изначально.

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

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

Инвесторы не могли проверить доходность. Зачем обслуживать сильно фрагментированную, эмоциональную, малобюджетную аудиторию малого бизнеса, когда 30% выйдут из бизнеса через 2 года, а 50% в ближайшие 5 лет? Исходя из личного опыта Бен понимал, что, даже когда сольные проекты терпят неудачу, они сохраняют свои списки рассылки и большинство из них начинают что-то новое в будущем. Таким образом, MailChimp не обязательно теряет клиента, даже если он временно уходит из бизнеса.

Конечно, как только доходы начали расти, инвесторы выстроились в очередь за дверью MailChimp. За эти годы Бен видел, как десятки конкурентов взяли миллионы на финансирование в надежде перерасти компанию. Каждый участник, поддерживаемый VC, может означать, что Бен совершил ужасную ошибку, оставаясь самофинансируемым. Однако, по состоянию на 2020 год, MailChimp всё ещё находился в комфортном положении с 60%-ной долей в индустрии электронной почты.

Бен: Я в этом бизнесе уже 19 лет. Так что у меня были волны конкурентов, которые брали деньги инвесторов, и я прошёл через стадии, когда говорил: Господи, сейчас они меня убьют. Финансирование становится всё больше и больше и, кажется, ничего не происходит. Мы просто держим прицельный фокус [...] и всё в порядке.

Мог бы MailChimp расти ещё быстрее, если бы у проекта были деньги VC? Возможно. Но, скорее всего, и корпоративные инвесторы постепенно отщепили бы культуру творчества и инноваций MailChimp, что и сделало компанию особенной.

7 интересных фактов о Бене Честнате и MailChimp


  1. Для Бена смесь запахов сигаретного дыма и лака для волос это запах бизнеса. Его мама устроила парикмахерскую на их кухне, и именно так Бен в детстве познакомился с предпринимательством.
  2. При приёме на работу Бен ищет скромных преподавателей, которые настолько хороши, что просят критики. Ему нужны люди, которые достаточно уверены в своих силах, чтобы у них не было проблем с оспариванием их взглядов или с простым объяснением сложных понятий. Бен говорит, что, если человек не может рассказать что-то до глупости просто, он не подходит для MailChimp.
  3. Первый нанятый Беном человек и (предположительно технический) соучредитель Дэн Курциус на собеседовании солгал, что знает, как писать код. После того как он получил работу, он собрал прототип MailChimp, используя книги HTML для чайников. Дэн так старался, что фактически создал (или украл) чистый функциональный код, который поразил Бена. Только через 10 лет соучредитель рассказал Бену о своей импровизации.
  4. Бен подтвердил, что отклонил предложение о приобретении MailChimp за миллиард долларов от неуказанной компании. В свою защиту он говорит, что миллиард долларов не намного больше, чем несколько сотен миллионов.
  5. Держащийся в тени соучредитель Дэн Курциус регулярно и анонимно посещает предприятия малого бизнеса, использующие MailChimp, от студий йоги до складов. Таким образом, компания получает бесценную обратную связь, например, так компания узнала о факте, что многие компании используют MailChimp как CRM, а не как инструмент электронной почты. Это действительно немного странно, когда на мероприятиях MailChimp крупнейшие критики позже узнают, что они разговаривали с соучредителем.
  6. Одна из любимых книг Бена Человек в поисках смысла Виктора Франкла. Франкл психиатр, переживший концентрационный лагерь во время Холокоста. В книге он документирует, как заключённые находят смысл и цель даже в самых бесчеловечных условиях.
  7. Девиз Бена: люби то, что делаешь, а не традиционное делай то, что любишь. Он говоритСо временем все страсти угаснут, если вы превратите их в профессию, и единственный способ сохранить чувство цели научиться любить ремесло, в котором вы хорошо разбираетесь.

Ребята, никто не придёт


В качестве эпилога я бы хотел оставить тебе одну из моих любимых цитат Бена Честнета:

Когда тучи сгущаются и становится тяжело что часто бывает, когда ты предприниматель, я вспоминаю кое-что, что я понял, когда вырос в Апсоне, в Джорджии. Это то, что я сказал друзьям, когда мы заблудились, бродили по лесу. Я сказал: Ребята, никто не придёт. [Бен смеётся] Это звучит не очень позитивно или как-то так, простите, но это то, что вы должны понять: никто не придёт! Всё зависит от нас! Когда ты предприниматель, никто не придёт тебе на помощь. Тебе решать, что нужно делать, чтобы выбраться из этого бардака. Но если ты выберешься из него, к тебе присоединится много людей. [...] Я постоянно говорю это себе.


image



Подробнее..

Нейротипология и нейромаркетинг будущего

04.01.2021 16:19:24 | Автор: admin

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

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

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

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

Вы знаете историю о том, как остров Манхеттен , исторический центр Нью-Йорка был куплен за 24 доллара у местных абориген капиталистами-американцами (привет дядя Сем). Это метафора моего сообщения. Но это пост не о том, какие американцы козлы или молодцы.

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

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

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

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

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

Жители стран СНГ последние десятилетия наблюдают, как после краха плановой экономики на территорию наших стран начала приходить рыночная экономика.

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

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

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

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

Мы видим, как последние 20 лет происходит постепенный захват всех рынков, где мы не были достаточно компетентны.

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

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

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

Теперь мы подходим к основной теме моего сообщения.

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

Менделеев сказал "знания без нравственности-меч в руках сумасшедшего".

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

Корочка нужна была раньше, сейчас нужна компетентность.

Что же будет с обществом людей?

Я не буду кричать ИЛИТА правит миром! Нет. Это не мое дело , я уже сказал вам- я верю в силу компетентности.

Если ты купил у туземца остров за всего ничего, может ты знаешь что-то, чего не знает он?

В моем представлении миром будущего правят корпорации. Да не просто правят. Господствуют.

Самое ближайшее сравнение- матрица, где люди плавают в розовой жиже.

Вместо жижи- мастерское знание вашего мозга.

Мы видим как ютуб или соц сети угадывают ваши предпочтения. И это ТОЛЬКО начало.

Розовые комнатки- ваши аккаунты в Тик-ТокеРозовые комнатки- ваши аккаунты в Тик-Токе

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

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

Нас же не могут кормить сахаром за лайки? Или за выложенный пост?

Или могут?

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

Такая вот цепочка получается- гипоталамус-гипофиз- железа.

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

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

Так вот - о чем весь рассказ

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

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

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

Теперь представим, что гипоталамус это распределительная коробка, которая НЕ УНИКАЛЬНА для каждого человека, что есть эволюционно так сложилось, что наша личность - это продукт неокортекса, коры головного мозга. А гипоталамус- это нечто, данное нам с рождения. Это то, что остается практически неизменным с 9 месяцев и даже после обширного инсульта в 93.

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

Назовем это типологией гипоталамусов.

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

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

Однако ни одна из них не встанет в один ряд с той, которая позволяет создавать наркоманию из своего контента.

И нас с вами это ждет.

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

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

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

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

Подробнее..

Как разрабатывать сотни AB экспериментов

12.01.2021 10:14:24 | Автор: admin
А/Б-тестирование это способ измерить эффективность нового функционала путем сравнения. Вы создаете новый заголовок, кнопку или изображение и показываете их только части аудитории сайта. В течение нескольких недель собираете статистику об использовании нового функционала и на основании этого принимаете решение об открытии новой фичи для 100% пользователей.

Senior Frontend Developer ЦИАН Иван Бабков, который разрабатывал приложения для регистрации доменов, интернет-банкинга и поиска по жилой недвижимости в своем докладе на конференции Frontend Conf рассказал об инфраструктуре компании для работы с А/Б-экспериментами, проблемах и путях их решения.

image

Что такое A/B тестирование


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

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

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

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

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

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

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



Спустя какое-то время, когда накоплены данные, которые отправлялись с разных вариантов интерфейса, можно сделать вывод, что конверсия в клики по первому варианту интерфейса 17%, по второму 25%. Логично, что на сайте предпочли оставить второй вариант. Это поможет в дальнейшем улучшить user experience.

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

Пример разработки frontend A/B эксперимента в ЦИАН


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

В какой-то момент продакт-менеджер ЦИАН совместно с дизайнером и аналитиком создали задачу следующего вида:



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

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



Дизайнер рисует два варианта макета:



А. Старый вариант, где есть один блок акций.

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

Первое, что необходимо сделать: перенести описание эксперимента в код. В ЦИАН есть админка, позволяющая добавлять и редактировать новые эксперименты:



В ней нужно заполнить форму следующего содержания:

  • Название эксперимента;
  • Время, когда он начнется;
  • Количество A/B групп;
  • Процентное соотношение в A/B группах.

При нажатии кнопки СГЕНЕРИРОВАТЬ, вся информация попадает в базу данных, откуда бэкенд может ее запрашивать.

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

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



Вариант ответа это список, в котором есть объекты с именем эксперимента и A/B группа, в которую попадает пользователь в этом отдельном эксперименте.

Нужно внести полученную с бэкенда информацию об эксперименте в Redux store и проверить в компонентах, какой вариант интерфейса в коде нужно отрисовывать в A/B группе.

В проекте есть всего две директории:



  1. GKCard это директория, в которой лежит компонент жилого комплекса, который вы видели на скриншоте;
  2. PromoLabel компонент акции (в примере: скидка на квартиры до 7%).

В компоненте GKCard отрисовывается PromoLabel.

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



Добавляем директорию ab, в нее директорию с названием эксперимента (в нашем примере: newbuilding_promos), а туда все файлы.

В компоненте жилого комплекса добавляем всего несколько строк:



  • connect, чтобы получать данные из store;
  • PromoLabel с новой версткой, где будет 3 акции;
  • Флаг isABEnabled для того, чтобы отрисовывать либо старый, либо новый вариант акции.

В connect берем список всех экспериментов, ищем в них эксперимент под именем newbuilding_promos, проверяем, есть ли такой эксперимент, и в этом объекте находим поле A/B групп, которое получили с бэкенда.



Если его значение 1, то отрисовываем новый вариант акции. Если нет, то старый:



То есть пользователь попадает в группу 1, если он получает новый вариант интерфейса.

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



Для отправки в примере использована библиотека ReactGA, но можно использовать множество других библиотек в NPM. В ЦИАН используют библиотеку собственной разработки, дублируя туда отправку:





Мы зарелизили задачу, все хорошо. Спустя две недели приходит новая.

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



В задаче были данные, что 13% пользователей кликают на блок акций в старом варианте, 21% в новом. Стейкхолдер вместе с аналитиками попросили Ивана раскатать вариант В на 100% пользователей. Это повысит конверсию в клике: пользователи видят эти акции, все хорошо.

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



Нужно перекинуть пользователей в БД в группу В. Теперь пользователи с ID от 0 до 99 увидят второй вариант интерфейса. Первый вариант не увидит никто.



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



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

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



Все! Следы эксперимента остались лишь в git log и в БД.

Немного про инфраструктуру


Есть запрос. Он пришел из браузера на наш внешний Nginx:



На Nginx мы запускаем скрипт, который генерирует ID от 0 до 99. Есть функция примерно следующего вида:



Функция возвращает число от 0 до 99. Она принимает строчку в виде уникального идентификатора пользователя. В нашем примере это будет:

uid = abfd-4843

Эта строчка передается функции md5 для генерации хэша:



Хэш получается шестнадцатеричный:

hash = FD029AAD2251AD74F8223B4F4A80B6EA

Мы преобразуем его в десятичное число и делим на 100:



parseInt(hash, 16)=3.363082047354731e+38

Остатком от этого деления будет число от 0 до 99. В нашем примере 68:

parseInt(hash, 16) % 100 = 68

График, который иллюстрирует равномерность распределения сгенерированных ID на 10 млн уникальных идентификаторов пользователя:



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

Мы запрашиваем страницу с ID, который только что сгенерировали, и передаем его как HTTP заголовок:



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



Request body


Запрос выглядит примерно так:



Мы передаем ID, только что нами сгенерированный на Nginx, и список экспериментов (их имен, которые фронтенд хочет получить от бэкенда). Бэкенд должен запросить этот список из БД, что он и делает:



Мы получили информацию из БД и должны вернуть приложение в наш фронтовый микросервис.



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



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

Это мы делаем следующим образом: берем сгенерированный ID (например, 50) и информацию, которую храним в БД.



Среди прочей информации (название эксперимента, время его начала, насколько эксперимент актуален, идет ли он сейчас, номер задачи) есть два важных элемента. Это списки, которые были сгенерированы при создании. Они содержат числа от 0 до 99. Числа уникальны, то есть в первом и втором списке не может быть числа 0.

Почему их два? Потому что при создании эксперимента мы создавали две A/B группы.
Берем наше число (в примере AB_ID = 50) и ищем в каждом из списков. Находим во втором:



Это говорит нам о том, что пользователь с ID = 50 попадает во вторую A/B группу и увидит второй вариант интерфейса.

Но одновременно у нас идет множество экспериментов:



В одном из них пользователь может попасть в третью группу, в другом во вторую, в третьем в первую.



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

Ответ выглядит следующим образом:



Это список, в котором есть объекты следующего содержания: имя эксперимента и A/B группа, в которую попадает пользователь.

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



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



Озвученный подход к проведению A/B экспериментов не единственный. Можно проводить их не только в приложениях сервера рендерингом, но и исключительно на клиенте. Например, делать это на бэкенде, подмешивая дополнительные результаты в поисковую выдачу только для определенной группы пользователей. И даже на Nginx (но мы так не поступаем, так как считаем его неподходящим инструментом для бизнес-логики).

Как принудительно попасть в определенную A/B группу?


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

В ЦИАН ею является нулевая группа. То есть пользователи при делении попадают, допустим, в две группы, и нулевая всегда избавлена от интерфейсов.

Чтобы автотесты или ручное тестирование, когда тестировщик проверяет задачу, могли попасть в определенную группу, передаем с фронта HTTP заголовок с ID.



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

Когда Nginx проигнорировал генерацию нового ID, он передает запрос на фронтовый микросервис.

Планы


Система ЦИАН не идеальна. И есть некоторые моменты, которые Иван планирует улучшить:

  • Таргетировать эксперименты по определенным параметрам (пол, геопозиция, дата регистрации и т.п.).
    В компании хотят научиться проводить эксперименты, например, для 17% мужчин из Петербурга, которые зарегистрировались у нас не ранее года назад.
  • Добавить возможность таргетировать по дополнительным параметрам в админку, чтобы не делать этого руками.
  • Разрабатывать больше экспериментов.

Но уже сегодня A/B эксперименты приносят свои плоды.

ЦИАН это крупнейший сервис по поиску недвижимости в России и один из самых больших в мире. Компания входит в мировой ТОП-10 крупнейших сайтов по недвижимости по версии Similar Web.

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

Frontend Conf 2021 пройдет 29 и 30 апреля. Но билеты на нее по самой выгодной цене вы можете приобрести уже сегодня.
Подробнее..

Войны лоббистов и развитие BIM. Часть 3 Отцы BIM технологий. Кто стоит за успехом Autodesk и openBIM?

29.12.2020 10:06:55 | Автор: admin

В этой статье мы осветим работу всех основных отцов BIM технологий, которые в 80-е и 90-е разрабатывали инструменты для автоматизированного проектирования. Разберём также, кто стоит за успехом организации buildingSMART и таких корпораций, как Nemetschek Group и Autodesk и почему старые программисты Autodesk не любили разработчиков Revit, а компания Nemetschek отказывалась от разработки IFC формата.

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

Как университет Мюнхена создал IFC формат.

К первой части этой темы - мне часто задавали вопрос, почему программное обеспечение, производимое в Европе, является более открытым и совместимым, чем ПО из других стран мира. Почему именно Европа является хорошим примером в разностороннем применении BIM ПО (openBIM)?Эта открытость связана с активным использованием формата IFC и openBIM программ. Чтобы понять, откуда появилась такая диверсификация или, точнее, раздробленность в подходах к BIM проектированию, посмотрим на историю возникновения openBIM движения.

Общеизвестно: всё, что связано с BIM, openBIM, IFC, Revit, - всё это придумала дальновидная и прогрессивная компания Autodesk.

Но всё-таки история openBIM начинается не с Autodesk, a с международных проектов, которыми занималось немецкое проектное бюро Obermeyer GmbH. Проектное бюро под руководством Leonard Obermeyer успешно работало над реализацией как крупных проектов на территории Германии, так и международных проектов в Европе. Поскольку Obermeyer зависел от международных проектов, глава бюро - Leonard Obermeyer - активно сотрудничал с руководителями американских корпораций, таких как: Patrick MacLeamy (CEO of HOK) и John Walker (Autodesk, Inc.).

Мюнхенский коллега Leonard Obermeyer, Georg Nemetschek, в это же время был категорически против сотрудничества немецких компаний с Autodesk и другими иностранными фирмами, так как такие партнерства открывали рынок Германии для создателей CAD программ из других стран. Georg Nemetschek разрабатывал узкоспециализированные программы (в основном для расчета статики), которые он продавал с 1977 г. Он считал, что местные производители ПО ещё не готовы бороться за рынок CAD планирования в Европе с такими стартапами начала 90-х, как Autodesk, Graphisoft и PTC.

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

На счастье строителей, как раз к этому времени, задачу по стандартизации геометрических элементов уже решила более богатая военная промышленность стран НАТО, которые в конце 1970-х годов пришли к необходимости стандартизации в области обмена данными при производстве военной техники. В связи с этим, в кругах специалистов и учёных, занимающихся в основном машинной графикой и геометрическим моделированием, возникла соответствующая инициатива, которая была поддержана фирмами США и Западной Европы, занятыми разработками сложной военной техники для стран НАТО. И уже в 1985 году министерство обороны США объявило о планах создания глобальной автоматизированной системы электронного описания всех этапов проектирования, производства и эксплуатации продукции военного назначения.

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

Но после окончания холодный войны, к концу 80-х, интерес к производству военной техники и разработке формата STEP резко падает. Наработки военных, добытые во времена холодной войны, начинают просачиваться в гражданский сектор. ISO стандарты из военной отрасли по формату STEP доходят до технического университета Мюнхена, где Richard Junge и его команда студентов, в числе которых был Thomas Liebich, видя успехи проектировщиков военной техники, пробует создать похожий формат передачи данных для строительной отрасли. Не изобретая новое колесо, Richard Junge берёт за основу военный формат STEP, чтобы не создавать новое геометрическое ядро и разработать формат, который станет независимым от производителей САПР.

Цитата Richard Junge в 2000 году:

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

Obermeyer (к этому времени ему 60 лет) патронирует свой бывший факультет и, находясь в тесном контакте с командой Richard Junge, обращается к своему знакомому Patrick MacLeamy (CEO of HOK) с идеей создать мировой формат для обмена строительными данными.

Patrick MacLeamy, видя перспективы и масштабы проекта, переносит всю тему с сертификацией и созданием (картельной) организации для написания правил и использования нового формата в Соединённые Штаты. Дальнейшая разработка формата IFC передается фирме Autodesk, которая, перенимая мюнхенские наработки, дополнительно пытается перестроить формат под своим нужды. Через несколько лет, в 1994 году, Autodesk регистрирует всю разработку формата IFC на своё имя. Patrick MacLeamy, вытеснив немецкий корни из всей истории, создаёт вместе с Autodesk картель (International Alliance for Interoperability - IAI) из американских консалтинговых и телекоммуникационных фирм, которые пишут стандарты и правила использования этого нового формата IFC в соответствии со своими требованиями.

Организация IAI официально регистрируется в торговой палате Чикаго в 1994 году. Инициативу по дальнейшему развитию формата и написанию стандартов американцы полностью берут в свои руки. А в 2005 году организации с непонятной аббревиатурой IAI дают более хайповое и понятное название - buildingSMART. С этого момента buildingSMART ставит целью устанавливать свои правила игры в строительном проектировании на всей планете Земля.

А Patrick MacLeamy, создатель buildingSMART, становится знаменитым, утверждая, что первым разработал концепцию кривой Маклими в 2004 г. Однако позже становится известно, что основа этих идей и подобных кривых впервые появилась в статье, написанной профессором Бойдом Полсоном в 1976 г. примерно за 28 лет до разработанной MacLeamy Кривой.

Отец БИМ - создатель SONATA или RADAR CH?

Если формат для (open) BIM моделирования был один - STEP/IFC, то в отношении первой настоящей программы для BIM (3D) моделирования всё намного сложнее. Это RUCAPS, Sonata, Reflex и RADAR CH. Но какая программа стала первой по-настоящему применяться для BIM моделирования?

Программа RUCAPS стала первой программой, которая в комплексе с единой рабочей станцией использовалась для реального проектирования зданий. Разработанная английскими инженерами Dr John Davison и John Watts, которые работали над проектом для Университета Эр-Рияда, RUCAPS стала одним из прообразов и ориентиров для многих последующих программ в BIM моделировании. В RUCAPS впервые была заложена концепция строительства по фазам, что очень помогло при возведении третьего терминала аэропорта Хитроу в Лондоне. Эти и ещё более ранние наработки, возможно, позже легли в основу программ, ставших настоящими прообразами уже современных программ - Sonata и Radar CH. Но что же появилось раньше: Sonata от Jonathan Ingram или Radar CH от Bojr Gbor и Ulrich Zimmer? Кого можно считать отцом BIM?

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

Dr Jonathan Ingram, в свою очередь, утверждает, что первым BIM программным обеспечением является написанная им программа Sonata, опубликованная в 1985 году. В подтверждение своих слов он ссылается (в личной переписке со мной, к сожалению, не могу проверить их подлинность) на открытые письма от создателя ArchiCAD, в которых Gabor Bojar признается, что на создание RADAR CH также повлияла Sonatа.

Цитата Gabor Bojar:

Кроме того, мы согласны с тем, что с технической точки зрения Sonata была в 1986 году был более продвинутой, чем ArchiCAD того времени. Однако мы по-прежнему считаем, что первый выпуск ArchiCAD в 1984 году (названный RadarCH на Apple Lisa) с его возможностями трехмерного моделирования зданий, параметрическими и интеллектуальными трехмерными объектами, можно рассматривать как новаторского предшественника BIM. При этом мы (Graphisoft - авт.) согласны с тем, что в 1986 году Sonata превзошла уже сформировавшееся определение BIM, уточненное лишь примерно через полтора десятилетия спустя. Что касается влияния Sonata на развитие ArchiCAD, то это, естественно, повлияло на нас, не нарушая никаких IP Sonata или T2. Конкуренты всегда учатся и влияют друг на друга, это стандартная и честная деловая практика до тех пор, пока конкуренты воздерживаются от посягательства друг на друга

На просторах интернета также можно найти изображение (справа) от Graphisoft (RadarCH), которое считается доказательством первой визуализации в 1984 году.

В общем, в этой истории больше вопросов, чем ответов. К первой визуализации Radar CH есть вопрос, так как компьютеры Mac с поддержкой цвета появились только в 1987 году. Но почему Steve Jobs сделал ставку на венгерско-советский стартап, находящийся за железным занавесом и не стал договариваться с близкими стартапами, которые разрабатывали ПО в силиконовой долине (скорее всего, Gabor Bojar нелегально смог импортировать несколько Mac компьютеров в Венгрию и переписал свой софт с медленных советских компьютеров на быстрый Mac). А на вопрос, откуда Gabor Bojar получил доступ к наработкам Sonata, Jonathan Ingram предпочёл не отвечать в письменной форме.

Словом, запутанная история, в которой только Интерпол, ЦРУ и КГБ может помочь нам разобраться: кто, когда и у кого взял идеи. Или всё-таки эти две программы имели общую теоретическую основу.

Предположу, что обе - ПО Radar CH и Sonata - начали с общей теоретической базы (RUCAPS или его подобие). Но при этом венгерская Radar CH была только трехмерной системой, с ограниченными параметрическими компонентами, в то время как у Sonata уже появились некоторые преимущества в создании рабочих чертежей, например, планов высот. В итоге, после публикации обеих систем, эти программы, возможно, позже черпали вдохновение друг у друга. Как сказал Gabor Bojar: "Конкуренты всегда учатся и влияют друг на друга, это стандартная и честная деловая практика".

B это же самое время на другом, более успешном, материке начинается новая эра CAD и MCAD ПО, которую открыла компания PTC (Nasdaq: PMTC) cо своим инновационным продуктом Pro/ENGINEER.

Создание Pro/ENGINEER и появление Solidworks и Revit

В 1974 году русский математик Самуил Гайзберг, профессор математики Ленинградского университета (сегодня Санкт-Петербург), эмигрирует сначала в Израиль, а затем в США (жена Гайзберга, работавшая над военными проектами в Ленинграде, эмигрировала в США несколькими годами позже).

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

Таким образом, в мае 1985 года Samuel P. Гайзберг основавывет Parametric Technology Corporation (PTC Inc.). И уже в 1988 году компания представляет свой первый коммерческий продукт на основе Unix под названием Pro/ENGINEER, сразу привлекая John Deere в качестве своего первого заказчика. Так Pro/ENGINEER стал первым программным обеспечением CAD для параметрического моделирования твердых тел.

Цитата Гейзенберга:

Цель состоит в том, чтобы создать систему, которая была бы достаточно гибкой, чтобы побудить инженера легко рассматривать различные конструкции. А затраты на внесение изменений в проект должны быть как можно ближе к нулю. Кроме того, традиционные CAD / CAM программное обеспечение того времени нереально ограничивало внесение недорогих изменений только в самый начальный этап процесса проектирования

Что отличало PTC от других производителей ПО, так это общая полнота всего цикла планирования. Pro/ENGINEER первой разработала !концепцию единой модели данных для всего проекта!. Эта концепция была позже успешно реализована в Revit Леонидом Райцем, бывшим выпускником того же Ленинградского университета (и скорее всего, бывшим учеником Гайзберга) и бывшим работником PTC..

Pro / ENGINEER произвела революцию на рынке MCAD (программное обеспечение для автоматизированного проектирования механических устройств). Параметрическое моделирование на основе элементов, взятое за основу в Pro/ENGINEER, будет доминировать в отрасли на протяжении четверти века, и все ведущие системы MCAD (CATIA, NX, SolidWorks, Inventor и Solid Edge) станут идейными преемниками Pro/Engineer.

В 1995 году Jon Hirschtick создаёт новый стартап - SolidWorks и переманивает большое количество разработчиков PTC вместе с вице-президентом и директором по развитию PTC - Michael Payne. PTC подаёт в суд на Solidworks за переманивание сотрудников, но обеим компаниям удалось уладить дело до того, как был нанесен слишком большой ущерб. Solidworks сразу становится главным конкурентом Pro/Engineer и уже в 1997 году французская компания Dassault, наиболее известная своим программным обеспечением CATIA CAD, приобретает SolidWorks за 310 миллионов долларов.

Выручка PTC с её основным продуктом Pro/Engineer резко выросла: со 163 миллионов долларов в 1993 году до 809 миллионов долларов в 1997 финансовом году. В этом же 1997 году выручка всей корпорации Autodesk была в два раза меньше, чем у PTC и составляла 497 миллионов долларов.В то время как AutoCAD мог похвастаться функционалом ограниченного 2D-моделирования, PTC стала программой настоящего 3D проектирования для всей машиностроительной промышленности. К середине 90-х клиентами компании были BMW, Fiat, Ferrari, Toyota, Hyundai, PSA и Volkswagen, Caterpillar, John Deere и остальные крупные игроки мировой промышленности.

К середине 90-х на рынке конструкторского планирования Pro/Engineer становится глобальным лидером. Теперь, чтобы перехватить инициативу в менее прибыльной строительной отрасли, в 1996 г. PTC покупает за 32 миллиона долларов программу Sonata у разработчиков Jonathan Ingram и Gerard Gartside. К этому времени Sonata уже переродилась в Reflex и реально была применена только на нескольких проектах в Англии. Но PTC полагала, что Reflex может стать основой новой линейки продуктов для комплексного проектирования зданий.

PTC дорого заплатила за относительно незрелое программное обеспечение Reflex и сильно недооценила усилия, которые потребовались бы для создания конкурентоспособной архитектурной программы для проектирования зданий. В итоге PTC не смогла выпустить достойный продукт для строительной отрасли и продала технологии Reflex техасской компании The Beck Group.

Успех команды SOLIDWORKS, которая построила продукт на разработках PTC и продала свой продукт за 311 миллионов Dassault Systems, видимо, повлиял еще на двоих работников PTC. Обладая знаниями о работе с Pro/ENGINEER и Reflex, два лучших разработчика компании PTC - Леонид Райц и, годом позже, Ирвин Юнгрейс - отделяются от PTC и в 1996 г. основывают собственную компанию по разработке программного обеспечения под названием Charles River Software (в Кембридже, Массачусетс, где уже были офисы PTC и Solidworks). Леонид Райц видел перспективы связки Pro/ENGINEER и Reflex, а также, видимо, был не согласен с продажей продукта техасской компании. Поэтому он ставит задачу создать версию программного обеспечения, которая могла бы обрабатывать более сложные проекты, чем ArchiCAD, но при этом использовать идеи общей модели и параметрического проектирования, которые он получил при работе над Pro/ENGINEER и Reflex. Код для новой программы командой Леонида Райца был написан с нуля, чтобы не нарушать патенты PTC и Reflex. Но сколько времени было у стартапа Revit до того, как инвесторы захотели вернуть свои деньги в 2001 году? Проблема с моделью ежемесячной подписки у Revit заключалась в том, что деньги поступали медленно и к концу каждого отчетного квартала компания подходила с кассовым разрывом.

Если взять 60 сотрудников Revit, которые зарабатывали в среднем 100 000 долларов США в год, и если при этом Revit получал 100 долларов в месяц за подписку, то получается, что компании нужно было 5 000 подписок, чтобы окупать вложения инвесторов каждый месяц. Сколько времени потребуется Revit, чтобы увеличить количество подписок до 5 000 и просто окупать текущие расходы?

Именно этот вопрос, скорее всего, заставил Leonid Reiz продать компанию за 133 миллионов долларов Autodesk.

Как развивались BIM стартапы. Слияния, поглощения и отношение к истории.

В 2002 году Leonid Raiz продает свой стартап Revit компании Autodesk. Продажи лицензий Revit дают взрывной рост корпорации Autodesk, и уже через 3 года после покупки, в 2005 году, Autodesk продаёт по 60 000 лицензий Revit в год, а начиная с 2019 года, Autodesk делает на продукте Revit - миллиардную выручку каждый год. Таким образом, небольшой корпорации Autodesk, выросшей на дрожжах инвестиций в Силиконовой Долине, с её единственным успешным продуктом 2D AutoCAD, разработчики RUCAPS - SONATA - Pro/ENGINEER подарили возможность стать мировым лидером в 3D проектировании.

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

Samuel Butler

Как же развивались остальные BIM стартапы из 90-х?

ArchiCAD, который изначально задумывался как CAD программа для проектирования трубопроводов, стал успешным венгерским стартапом на европейском рынке. После опубликования формата IFC - Graphisoft обнаруживает, что программа ArchiCAD идеально подходит для работы с этим форматом и начинает активно внедрять применение IFC формата в свои продукты, что позволяет программе ArchiCAD выйти на мировой рынок ПО и к началу 2000-х годов стать лидером в строительном проектировании. Возможно, формат IFC хорошо подходил к Radar CH, так как некоторые смыслы созданного STEP пересекались конкретно с RUCAPS, или с другой подобной программой, которую взял за основу Gabor Bojar для своего Radar CH.

Nemetschek Group - тихий и уверенный игрок на европейском рынке CAD ПО со своими небольшими специализированными продуктами для проектирования. Он в своё время отказался от международного сотрудничества и от разработки формата IFC, но в 2006 году, от страха перед резкой экспансией Revit, покупает Graphisoft и становится главным соперником Revit. С покупкой Archicad Nemetschek Group наконец-то открывает для себя тему openBIM c ее мировой миссией и вместе с картельными схемами buildingSMART вступает в битву за рынок планирования в Европе.

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

BuildingSMART не будут упоминать про немецкие корни в создании формата IFC и самой организации buildingSMART, поставив перед собой цель стать мировым интернетом в мире строительства и превращаясь в Советский Союз с членскими карточками, своей идеологией по использованию IFC и паспортами - сертификатами buildingSMART Certification.

Graphisoft и Gabor не любят вспоминать свои коммунистические корни, вспоминают лишь про свою успешную героическую борьбу с советским режимом и про установку первого в мире памятника Стиву Джобсу.

Autodesk не любит вспоминать про IFC и buildingSMART, после того как разработчики в 1996 году не смогли скрестить свои 2D продукты с форматом IFC (как и сегодня, ни один разработчик не может нормально подружить формат IFC c программами от Autodesk).

Также можно только представить, насколько тысячи программистов Autodesk в Силиконовой долине - создатели программы, которая не имела значимых изменений от года в года, - в начале 2000-х на дух не переносили десяток наглых выскочек с восточного побережья (с русским бэкграундом), которые с чистого листа за несколько лет написали улучшенную копию программы Pro/ENGINEER. А глава компании Autodesk в это время, Carol Ann Bartz, не ожидая от этого стартапа значимой прибыли, после покупки в 2002 году охарактеризовала Revit как небольшую экспериментальную базу пользователей (кстати о предсказательных возможностях глав компаний).

В заключение

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

У победы тысяча отцов, а поражение всегда сирота

Джон Кеннеди, 1946

Можно сказать, что реальный отец BIM - это идеи советских и английских математиков и программистов, которые смогли прорасти на плодородной денежной почве инвестиций в США.

А Samuel Geisberg помог своим бывшим сотрудникам PTC создать стартапы, которые, после продажи корпорациям, сегодня задают направление во всём мире CAD и MCAD планирования.

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

Но и Charles Eastman, и Samuel Geisberg, и Robert Aish, и Georg Nemetschek, и Jonathan Ingram, и Bojr Gbor и Leonid Raiz - я думаю, согласятся с тем, что они не придумывали ничего сверхнового. Они брали разработки своих более старших коллег и учителей и давали этим старым идеям новый смысл и новый дизайн.

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

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

А Autodesk, PTC Inc. и Nemetschek Group хочется пожелать, чтобы вместо многомиллионных бонусов своим менеджерам, они перевели пару миллионов евро на благотворительные счета в технический университет Мюнхена, Санкт-Петербурга и Ливерпуля.

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


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

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

Подробнее..

Войны лоббистов и развитие BIM. Часть 4 Борьба CAD и BIM. Монополии и лоббисты в строительной отрасли

15.01.2021 10:11:34 | Автор: admin

В прошлой статье: часть 3: Отцы BIM технологий. Кто стоит за успехом Autodesk и openBIM было показано, насколько все команды разработчиков BIM инструментов связаны друг с другом и как каждая команда разработчиков, заимствовав идеи друг у друга, пыталась сделать свою уникальную BIM программу. При этом почти все значительные идеи или разработки не были созданы большими корпорациями: Autodesk, Nemetschek Group, или Hexagon просто вовремя покупали стартапы у недовольных бывших сотрудников своих конкурентов.

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

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

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

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

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

В этой части мы поговорим о борьбе CAD и BIM, о монополизации строительного проектирования корпорацией Autodesk и организацией buildingSMART, а также о лоббировании концепции openBIM на государственном уровне в некоторых странах.

Начало борьбы CAD и BIM. Пролог.

Все, что сегодня связано с BIM технологиями, пришло к нам из CAD мира 80-х годов, когда в конструировании использовались исключительно CAD технологии. Самые крупные производители CAD ПО в 80-е годы создавали медленное и неуклюжее ПО на устаревших языках программирования - Фортране и ассемблере: IBM / Dassault (CADAM и CATIA), Computervision (CADDS), SDRC (I-DEAS и Intergraph (IGDS и InterAct). Все эти корпорации в начале 90-х отклонили идеи Самуила Гайзберга по разработке новых инструментов в проектировании как малоинтересные и не имеющие будущего технологии. Подробнее об этом в третьей части.

Но за несколько лет, с 1988 по 1990, команде PTC под руководством Гайзберга удаётся полностью изменить подход к конструированию и проектированию во всём мире на несколько десятилетий вперёд. Используя твердотельное параметрическое моделирование с концепцией единой модели, Pro/Engineer от PTC становится первой программой 3D CAD/MCAD, которая почти полностью (кроме рисования пером) реализовала идеи, впервые продемонстрированные Sketchpad Ивана Сазерленда в 1962 году. И уже к середине 90-х Pro/Engineer безвозвратно изменяет представление пользователей CAD программ об интерфейсах, простоте использования программ и быстроте твердотельного проектирования.

Такую же революцию на рынке проектирования в строительной отрасли, которая позже получит имя BIM, осуществил через 10 лет ученик Гайзберга, выпускник Ленинградского университета - Леонид Райц, которого через 10 лет после эмиграции из Советского Союза его бывший учитель математики - Гайзберг - в 1986 году устраивает одним из первых сотрудников в свою новую компанию PTC. За несколько лет, к 1988 году, под руководством Гайзберга Райц создаёт геометрическое ядро для программы Pro/Engineer.

Автодеск открывает для себя BIM

2002 год считается годом рождения новой идеологии, придуманной корпорацией Autodesk - Building Information Modeling - BIM.

В википедии на странице BIM:

In 2002, Autodesk released a white paper entitled "Building Information Modeling, and other software vendors also started to assert their involvement in the field.

До 2002 года сам Autodesk без значимых успехов (как это часто случается с большими бюрократическими организациями) силами своих внутренних разработчиков пытался создать 3D CAD замену своему единственному успешному продукту AutoCAD, который был куплен в 1982 году у Mike Riddle и на котором John Walker (будущий первый CEO Autodesk) смог выстроить успешную бизнес-модель по продаже лицензий - фирму Autodesk.

В 1992 году John Walker передаёт управление компанией новому CEO - Carol Bartz, получает пакет акций Autodesk на 42 mln.$ и эмигрирует в Швейцарию. Сэтого момента, если смотреть на годовые отчеты корпорации Autodesk c 1992 по 2002, складывается впечатление, что после ухода из компании Mike Riddle (создателя AutoCAD) единственным продуктом, кроме AutoCAD, которым занимались разработчики Autodesk и который сегодня ещё остался на рынке проектирования, был AutoCAD Architectural Desktop (о котором сегодня сама корпорация уже старается не упоминать).

Также в этот период Autodesk пытался убрать с рынка своих потенциальных конкурентов, таких как VersaCAD, IntelliCAD, AutoSketch, перекупая стартапы и борясь в судах за патенты и лицензии, чтобы не дать возможности этим стартапам продаться конкурентам.

Но что же обнаружил Autodesk, что в 2002 году резко становится лидером 3D BIM проектирования, опубликовав white paper про BIM, который даст начало новой эпохе в мире проектирования?

Конкретно в 2002 году Autodesk покупает стартап Revit Леонида Райца и именно в предпродажных презентациях Леонида Райца, которые были созданы для переговоров с Autodesk логично искать источник white paper BIM, выпущенного через год после продажи.

За 6 лет команда разработчиков Revit с нуля создала радикально новый подход для программного обеспечения САПР для строительства: с параметрическим моделированием и концепцией единой модели данных для всего проекта, разработанных Самуилом Гайзбергом и Леонидом Райцем ещё в 1988 году для программы Pro/Engineer.

После несостоявшейся попытки Autodesk купить Solidworks (копия программы Pro/Engineer), после неудачного преследования разработчиков IntelliCADD, в 2001 году - уже после покупки Revit - CEO Autodesk Carol Ann Bartz, не ожидая от этого очередного стартапа значимой прибыли, охарактеризовывает Revit как небольшую экспериментальную базу пользователей.

В то время она ещё не подозревает, какой продукт получил Autodesk всего за 130 mln $ и что за Леонидом Райцем стоят не только наработки PTC, но и собственно Самуил Гайзберг, который подарил жизнь таким программам, как Solidworks и Digital Project (для сравнения в 2018 году Autodesk заплатил за Plangrid: стартап-приложения для планшета - $875 mln. Одним из главных учередителей этого стартапа стала бывший CEO Autodesk - Carol Ann Bartz).

В 2000-е новую программу Digital Project, смесь разработки SolidWorks, Catia и Франка Гери, в своей работе использовали многие архитекторы и лауреаты прицкеровской премии, в том числе Заха Хадид с её знаменитыми изгибами и космическими формами зданий, которые после 2005 года стали больше походить на машиностроительные проекты.

Таким образом, технологии, используемые в Revit и доступные машиностроительной отрасли уже с начала 90-х,только через 10 лет, к началу 2000-х, доходят наконец до крупнейшей экосистемы в мире - строительной отрасли.

Экспансия идеологии BIM и программы Revit

В 2002 году, после покупки Revit, Autodesk открывает наконец для себя мир параметрического твердотельного 3D моделирования - технологии, которые ускользнули от Autodesk в конце 90-х из-за отказа разработчиков Solidworks продавать свою компанию по жёсткой цене Autodesk (в 1997 Solidworks за 310 mln $ всё же уходит французской корпорации Dassault Systemes).

И уже через год два вице-президента Autodesk - Phil Bernstein и Jim Lynch - выпускают White Paper - Building Information Modeling (которая была скорее всего в большей части скопирована из презентаций разработчиков Revit) и открывают BIM-идеологию для всего мира.

С этого момента, с 2003 года, начинается отсчет для новой идеологии, захватившей весь мир строительства на следующие двадцать лет, - BIM.

Как же проходила борьба CAD и BIM с того момента, как Autodesk провозгласил приход новой эпохи BIM, или, точнее, как проходила с 2003 года экспансия Revit-технологий в строительное проектирование во всём мире?

Благодаря открытым поисковым данным Google сегодня мы можем проследить этот процесс соперничества CAD и BIM по годам. Посмотрим на развитие популярности CAD и BIM проектирования в странах G20 (The Group of Twenty, major advanced and emerging economies) с 2004 по 2020 год.

Я выделил 4 основных, самых популярных, поисковых запросов, которые были важны в сфере проектирования и планирования, начиная с 2003 года:

  • AutoCAD - основная программа для проектирования и создания 2D чертежей

  • Revit - молодая программа из машиностроения с новым параметрическим моделированием и единой моделью проекта

  • Archicad - основной представитель концепции openBIM, в 2000 году единственный достойный представитель 3D проектирования с визуализацией

  • BIM - запрос по этой фразе показывает интерес к теме BIM относительно других запросов, которые волновали проектировщиков в период с 2003 по 2020 год

Открытые данные по поисковым запросам и реальный интерес к тому или иному продукту или товару могут быть часто не связаны друг с другом, например, в том случае, если этот продукт продается в основном оффлайн (без использования интернета). Но если речь идет о программах и цифровых продуктах, то, конечно, по интересу к продукту в поиске можно относительно судить по общему интересу к продукту и его продажам. Объективные показатели Google Trends по каждому запросу показывают относительную популярность запроса: 100 баллов означают максимальный интерес к теме, а 0 недостаточное количество информации по ней.

В следующем видео я собрал данные по интересу к запросам: Autocad, Revit, Archicad, BIM в каждой из стран, входящих в G20 с 2004 по 2020 год.

По данным, представленным в видео, видно, что с момента начала продаж Revit, который ознаменовал White Paper BIM, интерес к устаревшим технологиям CAD в мире начинает падать. Основные выводы, которые можно сделать из полученных данных:

  • В англоязычных странах (USA, Canada, Australia, UK, South Africa) интерес к теме BIM (точнее, к технологиям и идеям BIM, которые используются в программе Revit) к началу 2021 побеждает технологию 2D проектирования с использованием AutoCAD

  • Европейские страны активно интересуются BIM темой, но, в отличие от англоязычных стран, не хотят полностью попадать под зависимость от корпорации Autodesk, стремясь поддерживать местных локальных производителей САПР ПО, которые пытаются работать по концепту openBIM

  • Южная Америка (за исключением Бразилии) и Азия (за исключением Китая) только начинают проявлять интерес к использованию BIM технологий и начинают инвестировать своё время в эти новые хайповые технологии.

Дополнительный insight по этим данным: в большие национальные праздники, такие как Рождество и Новый год (на видео декабрь 2020 - праздники и lockdown ) во многих странах, запросы по продукту AutoCAD на один месяц уступают интересу по теме BIM и Revit. Люди в праздники, отключившись от рабочих процессов, охотно осваивают новую тему - BIM и Revit.

По поисковым данным можно сказать, что интерес к AutoCAD, то есть к 2D проектированию будет снижаться и дальше. Большинство компаний, занятых проектированием, будут переходить на более прогрессивный Revit, так же как в 90-е все основные машиностроительные компании мира массово переводили свое конструирование на PRO/Engineer.

Но, к сожалению, Revit является не локомотивом корпорации Autodesk, а скорее, тупиковым путем её развития.

Revit - это тупиковый путь развития Autodesk

Как показывают 40 лет существования компании Autodesk, разработчики из силиконовой долины за это время не смогли самостоятельно сделать новых прорывных продуктов ни в одном из направлений CAD и BIM. Почти все программы Autodesk были куплены на рынке стартапов в 90-е и 2000-е годы. А через несколько лет после покупки этих стартапов по жёсткой цене создатели и основные разработчики покидали Autodesk.

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

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

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

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

История (подробнее в части 3: Отцы BIM технологий. Кто стоит за успехом Autodesk и openBIM) показывает, что за новыми технологиями бесполезно обращаться к сытым и богатым корпорациям. Все прорывные технологии и стартапы двигают вперед только недовольные и голодные разработчики.

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

  • те, кто не готов подстраиваться под Autodesk, подвергаются ценовым репрессиям;

  • основная масса проектировщиков полностью зависит от продукции Autodesk и практически не может пользоваться (или с трудом, через костыли IFC) другими программами;

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

  • основные силы и инвестиции корпорации идут на поддержку продукта, массовую скупку технологий и экспансию идеологии в другие страны;

  • Autodesk собирает под своим крылом разработчиков стартапов, которые, получив денежную свободу, сразу же бегут из корпорации;

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

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

Но всё же какой-то небольшой стимул к развитию у Autodesk остался. Это небольшое противостояние идеологии closedBIM c openBIM на востоке - в некоторых странах Европы и Азии.

Этот искусственный конфликт идеологий нечаянно подарила себе сама корпорация Autodesk, создав (просто зарегистрировав на своё имя) в середине 90-х для выхода из 2D проектирования мировой 3D формат IFC и картельную организацию IAI.

Может быть, openBIM - это та спасительная альтернатива, которая сможет дать отпор каждый год повышающей свои цены Autodesk?!

openBIM - достойная альтернатива Revit?

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

По представленным во второй части открытым поисковым данным видно, что во всём мире выделяется только несколько стран (Кения, Румыния, Австрия, Швейцария и Германия), которые используют в своей строительной отрасли для проектирования концепт openBIM.

В основном это немецкоговорящие страны. И главным предводителем всего движения openBIM в Европе логично является Nemetschek Group с двумя продуктами: Allplan и Archicad. Они, возможно, уже были бы на грани исчезновения, если бы не формат IFC, который сейчас на время спасает бизнес-модель европейской корпорации.

Формат IFC - это продукт разработки команды мюнхенского университета (и позже зарегистрированный корпорацией Autodesk). Он контролируется с 1997 картелем производителей программ САПР и других корпораций, заинтересованных в установлении своих стандартов во всём мире. Во главе всей этой организации в стоит главный комитет этой социалистической идеологии - buildingSMART International.

Что же такое формат IFC, на котором построен весь концепт openBIM? (про создание IFC подробнее в третьей части):

  1. IFC - это обыкновенный формат PDF, только немного более интеллектуальный

  2. Формат IFC не является форматом обмена данными для дальнейшего редактирования

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

  4. Сама модель проекта или любого элемента в формате IFC не подходят для продолжения работы над ними

То есть после импорта IFC файла в любую BIM программу его нельзя будет отредактировать или дополнить. А если вы всё-таки захотите это сделать (а вы захотите это сделать), то оптимальным выходом будет полное воссоздание геометрии в той программе, в которой вы работаете, при этом эта работа будет похожа на копирование рисунка (модели IFC) при помощи светового стола по жирным линиям рисунка оригинала.

Для чего же тогда нужен IFC? Этот формат может понадобиться вам только в том случае, если совместная работа по разделам проекта с другими фирмами, которые предпочитают использовать местные программы, невозможна в одной программе Revit или Archicad. Также вам придётся экспортировать модель в формат IFC, если вашему заказчику понадобится весь проект в формате IFC. Но проблемой в случае экспорте/импорте из разных программ является то, что при импорте IFC вы часто получаете продукт невысокого качества.

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

Хорошим доказательством этого является опрос, проведенный федеральным министерством транспорта, строительства и городского развития Германии (Bundesministerium fr Verkehr, Bau und Stadtentwicklung) среди BIM специалистов в 2013 году.

На вопрос Соответствует ли формат обмена IFC содержанию и вашим формальным требованиям для обмена модельными данными? больше половины опрошенных BIM специалистов ответили, что формат IFC соответствует их требованиям меньше чем на 25%.

Поэтому передовые компании, которые сегодня считаются в Германии ведущими в развитии технологий BIM, такие как Max Bgl, Goldbeck, Hochtief после своего неудачного опыта работы с разными форматами и проблемами импорта/экспорта - переходят на проектирование полного цикла по концепту closedBIM в программу Revit.

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

Почему немецкоговорящие страны выбрали путь openBIM?

Чтобы понять эту логику, для этого уже в который раз обратимся к истории создания концепции openBIM. В 1995 Autodesk берёт разработку мюнхенского университета формат IFC и создает на его основе новое направление для своей бизнес-модели, под которую создается картельная организация IAI - Индустриальный Альянс за Совместимость. Через два года, уже в 1997 году, Autodesk переводит тему с американского континента в международный масштаб и переименовывает Индустриальный Альянс за Совместимость в Международный Альянс за Совместимость (где опять в названии начинает мелькать попытка создания новой мировой идеологии).

Но, как обычно, у Autodesk ничего не получилось придумать с форматом IFC (до сих пор продукты Autodesk, по невнимательности или по умыслу - с трудом работают с форматом IFC) и к началу 2000-х общий интерес к организации IAI начинает падать. Сам же Autodesk, наконец удачно купивший настоящую BIM программу Revit и окончательно потеряв интерес к социалистической идее Альянса за Совместимость, переключается на создание новой продающей идеологии - BIM.

Европейским же производителям САПР программ не остается ничего, как в начале 2000-х, видя стремительный успех программы Revit, с её закрытым подходом к обмену файлов, открывать заново теряющую популярность и оставленную Autodesk организацию IAI.

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

Также удачной маркетинговой находкой стало создание выражения openBIM - аналога выражения open Source - к которому openBIM не имеет никакого отношения. OpenBIM подразумевает под собой противопоставление концепции closedBIM, которое было притянуто в большей степени самой buildingSMART к корпорации Autodesk. Жаль только, что по факту никакого отношения к open выражение openBIM не имеет и что на практике концепция openBIM оказалась простым средством соединения небольших европейских и азиатских производителей closedBIM программ друг с другом.

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

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

Таким образом, если у вас нет нескольких десятков лишних тысяч, то вы не сможете, к сожалению, участвовать в обсуждении этой мировой открытой технологии openBIM. No money, no honey.

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

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

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

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

Палочку эстафеты в этом направлении теперь подхватили немецкие производители софта. Производители программ с устаревшими интерфейсами и know-how из 80-х, как и Autodesk, не способны сегодня (благодаря созданию отличной инфраструктуры в 90-е годы) создавать новые технологии и программы. Но, чтобы не потерять место на миллиардном рынке САПР в Европе, через лоббирование своих интересов и законодательных инициатив они предлагают европейским правительствам открыть новую эру проектирования в Европе под эгидой openBIM.

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

Как на практике происходит лоббирование концепции openBIM?

Как лоббирование происходит на практике

Возьмём для примера инфраструктурное строительство Германии. Одним из главных игроков на этом рынке является акционерная компания со стопроцентным государственным участием - Немецкие железные дороги (Deutsche Bahn). Deutsche Bahn, один из крупнейших строительных подрядчиков Германии в середине 2000-х, замечает новые эпохальные технологии от Autodesk и создает инструменты и библиотеки элементов для быстрого проектирования, что приводит компанию за короткое время в новый мир BIM технологий и инструментов, которые используются в новых продуктах Autodesk.

Но производители местных программ САПР в таком быстром развитии уровня проектирования видят видят угрозу для своего бизнеса. Ещё 20 лет назад, до начала эры интернета (а в некоторых регионах ещё и сегодня) они доводили до людей информацию о новых технологиях и новых CAD программах через книги, журналы, газеты и продавцов ПО, которые гастролировали от компании к компании, рассказывая про новые технологии за процент от продаж.

Таким образом,к концу 90-х из-за отсутствия современных продуктов от Autodesk и вследствие отсутствия прозрачности в доступе к информации, производители местных САПР чувствовали себя уютно на рынке Европе и мало заботились о конкуренции.

Но с приходом новых технологий от Revit и BIM идей, европейским производителям приходится искать новые пути, чтобы оставаться на рынке программ САПР. Для этого воскрешается организация IAI, которая после 2005 года становится более европейской. Теперь благодаря пролоббированным законодательным инициативам при поддержке министерств, большие немецкие компании с государственным участием разворачиваются в сторону совместной работы по методикам buildingSMART. И вся ситуация с развитием строительства теперь встаёт на рельсы концепции openBIM.

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

В итоге компании вынуждены посылать своих специалистов и менеджеров на двухдневный вебинар для получения важного сертификата buildingSMART, без которого компании не получить необходимый заказ. На этом чисто теоретическом вебинаре за 2 тысячи евро объясняется идеология openBIM и важность работы с проектами через обмен данных в формате IFC при помощи многообразия программ и аббревиатур (BAP, PIM, LIM, PIA, LIA, OIA), а также аккуратно указывается на преимущества некоторых программ в проектировании по данному методу. После чего следует экзамен, где проверяются основные понятия, которые нужны для работы с зоопарком программ по концепции openBIM.

В итоге эта стратегия лоббирования интересов openBIM и бюрократизация процессов приводит сегодня Германию в конкретной отрасли к плановой экономике и к тому, что в Германии процент строительных проектов, в которых применяется BIM, находится на самом низком уровне в Европе, составляя в 2019 году всего 20%. При этом в северных странах Европы количество проектов с применением BIM - больше 60%.

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

Дополнительно я сравнил данные по распространению технологии BIM в Европе c популярностью поискового запроса по слову Revit в период с 2004 по 2020 год.

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

Самым проблемным из них стал столичный аэропорт в Берлине (BER), проектирование которого велось в начале 2000-х и строительство которого планировалось провести за 3 года. Изначальная сдача объекта была запланирована на 2011 год, но в итоге строительство длилось 14 лет и объект был сдан в эксплуатацию только в октябре 2020 года. В начале проектирования проекта BER технологии BIM только зарождались, но можно логично предположить, что до ввода в эксплуатацию в 2020 году единая модель проекта по концепции openBIM всё же была сформирована.

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

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

Тему с лоббированием отдельных интересов хорошо дополняет цитата из интервью (в газете Handelsblatt) с иконой немецкой промышленности - Martin Herrenknecht (создатель тоннелепроходческих щитов), который на вопрос по поводу развития инфраструктурных проектов в Германии ответил:

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

В заключение

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

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

А кто из нас сегодня добровольно готов будет отказаться от спекуляции цен и откатов?

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

Монополии buildingSMART и Autodesk сегодня являются прямым отражением интересов своих подопечных - строительного сообщества. Именно поэтому строительная отрасль в целом и проектировочные бюро в частности не могут жаловаться на своих правителей-диктаторов (корпорацию Autodesk & co.), если сами они, на своём уровне, сегодня не готовы перейти в социализм и согласиться на прозрачную работу через стандартизированные классификаторы и прозрачные расценки по работам и материалам.

Какие низы, такие и верхи. Народ стоит своего правителя.

Шарль Морис де Талейран-Перигор

Должно ли государство заниматься вопросами контроля и установления правил? Конечно, нет. Строительная отрасль должна начать меняться снизу.

Хочется добавить, что,благодаря дешевым деньгам пенсионных и государственных фондов, сила корпораций и организаций, лоббирующих конкретные интересы, растёт в параболической прогрессии не только в отдельных странах, но и в мире. Пятёрка основных корпораций находятся под управление одних и тех же инвестиционных фондов: Warburg, BNP, Blackrock (см. карту схему: BIM development map) и они перестают конфликтовать и бороться за выживание. На счетах этих корпораций скапливается огромное количество дешевых денег: они в состоянии поглотить любой стартап и технологии в любой стране мира и на любых услових.

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

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

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

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

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

Буду рад вашим комментариям, уточнениям и критике.

Подробнее..

Оплачиваемое время как считать его правильно

11.01.2021 18:14:50 | Автор: admin

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

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

Вот несколько примеров отраслей с этой моделью:

  • Консультирование и PR;

  • IT;

  • Юридические консультации;

  • Креативная сфера (копирайтинг, дизайн, и т.д.);

  • Сбор и обработка данных;

  • Административные услуги;

  • Бухгалтерский учет, и т.д.

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

  • Разные ставки для разных клиентов;

  • Разные почасовые ставки для разных работников;

  • Необходимость связать оплачиваемое время с дополнительными выплатами (бонусами, премиями, и т.п.).

Отличный пример расчета вознаграждения сотрудника с почасовой оплатой можно взять здесь (и скачать калькулятор на основе Excel) или здесь (имеются разные типы калькуляторов).

Вопросы для самопроверки

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

  • Легко ли клиентам получить подробный счет и понять, за что берется оплата?

  • Хорошо ли оптимизирован процесс расчета?

  • Могут ли быть ошибки из-за человеческого фактора?

  • Правильно ли сбалансированы оплачиваемые и неоплачиваемые часы?

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

Общее руководство по учету оплачиваемых часов

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

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

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

  1. Определить цели взимания оплаты.

  2. Соотнести эти цели с затрачиваемым временем и ресурсами.

  3. Вести учет рабочих часов в реальном времени.

  4. Регулярно пересматривать данные.

  5. Определить аспекты, нуждающиеся в улучшении.

  6. Проверять и переоценивать запланированные затраты времени.

  7. Повторять циклы обновления.

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

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

Коммуникация: считать или не считать?

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

  • Переписка по email;

  • Видеоконференции;

  • Совещания всех типов;

  • Регулярное общение по телефону.

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

Повышайте ставки

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

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

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

Используйте счетчик времени в полную силу

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

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

  • Оплачиваемые часы, непосредственно относящиеся к работе над проектом;

  • Административная рутина;

  • Нерабочее время (отпуска, больничные, и т.п.)

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

Выводы

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

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

  • Биллинг на основе стоимости также важен для определения политики компаний в плане компенсаций и карьерного роста.

  • Чтобы повысить конкурентоспособность, нужно постоянно отслеживать соотношение оплачиваемых и неоплачиваемых часов.

  • Автоматический учет времени при помощи специального программного обеспечения позволяет считать оплачиваемые часы точнее и опираться на объемы именно потраченного, а не только заявленного времени.

  • При правильном балансе оплачиваемого и неоплачиваемого времени прибыль будет расти.

Подробнее..

Технологические итоги 2020 года от всеобщей удаленки до запуска Spotify в России

30.12.2020 16:07:24 | Автор: admin
В 2020 году люди не покидали свои дома без серьезных причин и большинство важных событий, в том числе ИТ-индустрии, произошло в онлайне. Вспоминаем самые важные в мире и в России.



В мире


Все на удаленке. Из-за пандемии коронавируса удаленная работа оказалась востребована, как никогда прежде. По данным Gartner, 88 % компаний по всему миру ввели удаленную работу в том или ином виде, 97 % организаций отменили рабочие поездки, а 32 % внедрили сервисы для виртуальных встреч. В течение всего года ИТ-компании по всему миру создавали и развивали соответствующие инструменты: Zoom решал проблемы с приватностью и преодолевал болезнь взрывного роста, Google Meet стал доступен для всех, а Telegram пообещал ввести групповые видеозвонки.

Стриминг рекордно востребован. С началом пандемии многие сервисы начали предлагать бесплатные продолжительные подписки на свои услуги. Это был одновременно и жест помощи запертым по домам людям, и способ прорекламировать свои продукты. Стратегия дала результат: по итогам года сервисы по всему миру отмечают рост числа платных подписок на десятки процентов. С началом пандемии объем трафика в среднем увеличился на 70 %, трафик же стриминга вырос на 12 %.

IPO Airbnb. Travel-сервис для аренды частного жилья по всему миру с началом пандемии начал испытывать серьезные проблемы. Убыток компании во II квартале составил $576 млн почти вдвое выше, чем годом ранее. Основатели заявляли, что не были уверены, выживет ли бизнес.

Но помогло необычное решение Airbnb начала предлагать варианты размещения недалеко от местоположения пользователей, позиционируя их в рекламе, как путешествия рядом. Это помогло перед IPO 9 декабря компания получила оценку в 47 млрд долл., а через несколько минут после торгов акции выросли на 140%. В конечном итоге сервис привлек по результатам размещения 3,5 млрд долл. вместо запланированных 2,75.

Власти США против техногигантов. Конгресс в октябре завершил 16-месячное расследование работы Google, Amazon, Facebook и Apple, оформив его в виде доклада на 450 страницах. Для него же летом на слушаниях в Конгрессе выступали руководители компаний Сундар Пичаи, Марк Цукерберг, Джефф Безос и Тим Кук.

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

Ответ Google, Amazon, Facebook и Apple был предсказуем: они заявили, что работают исключительно рыночными методами, постоянно конкурируют друг с другом и никаких монополий нет. Результаты доклада все компании назвали устаревшими, неточными и ошибочными.

В России


Запуск Free TON. Весной начала работу блокчейн-платформа Free TON, которая ранее разрабатывалась командой Павла Дурова в рамках проекта Telegram Open Network. На старте во Free TON было зарегистрировано более 20 тысяч участников. Валюта здесь называется TON Crystal, или сокращенно TON. Главное ее отличие от множества других распределение токенов через конкурсы, а не продажи. Также в планах нет ICO.

К проекту проявляют интерес не только разработчики, но и инвесткомпании, криптобиржи и технологические стартапы. Все они видят в платформе потенциал для разработки и широкого внедрения технологий и продуктов на основе блокчейна. У части сообщества есть вопросы касательно легальности запуска платформы из-за противостояния Павла Дурова с американской Комиссией по ценным бумагам и биржам, которая фактически запретила запуск Telegram Open Network. По словам представителей Free TON, новая блокчейн-платформа не имеет отношения к проекту Павла Дурова, а следовательно и к судебным спорам Telegram и SEC.

Сорванная покупка Тинькофф Яндексом. Потенциальная сделка года в российском ИТ сорвалась в последний момент. О планируемой сделке стороны сообщали в конце сентября, назвав сумму продажи $5,47 млрд. Основатель банка Олег Тиньков настаивал на сохранении контроля за компанией по итогам сделки, в Яндексе же рассматривали процесс именно как продажу. 16 октября Тинькофф заявил о выходе из сделки, а в СМИ появилось эмоциональное письмо Олега Тинькова сотрудникам, где он негативно отзывался о Яндексе.

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

IPO Ozon. По итогам размещения акций интернет-магазина Ozon на NASDAQ в конце ноября компания привлекла 1,27 млрд долл. вместо планируемых 950 млн долл. По мнению агентства Bloomberg, это лучшее размещение на бирже со времен Яндекса среди российских компаний. В первый же день акции выросли в цене на 34 % и стали стоить 40,18 долл. при стартовой цене в 30 долл. По данным Forbes, размещение вызвало дикий спрос. В настоящее время сеть Ozon включает порядка 30 сортировочных центров, восемь фулфилмент-фабрик и более 16 тыс. точек выдачи заказов на территории России. На сайте ритейлера представлено свыше 6 млн товаров, рассортированных по 24 категориям.

Запуск Spotify в России. Запуска шведского музыкального сервиса ждали несколько лет. Многие поклонники рекомендательных алгоритмов Spotify слушали его через сложные схемы с VPN. 15 июля он стал официально доступен в России. Компания при этом заявила, что этот проект стал для нее самым крупным и принес в третьем квартале 2020 года основную часть подписчиков. Исследовательская компания Mediascope отмечает, что за за время работы в России Spotify по степени популярности стал шестым музыкальным сервисом, а в августе его хотя бы один раз открыло более 2,2 млн пользователей из России старше 12 лет.



Блог ITGLOBAL.COM Managed IT, частные облака, IaaS, услуги ИБ для бизнеса:

Подробнее..

WorkBoy, клавиатуру для GameBoy, превращающую его в КПК, нашли и протестировали спустя 28 лет после анонса

30.12.2020 00:08:02 | Автор: admin

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

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

На прошлых выходных Лайам Робертсон, специалист по видеоиграм, опубликовал видео, в котором он рассказал подробности своей находки. Ему удалось найти прототип, часть очень небольшой партии увидевших свет WorkBoy.


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

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


Робертсон заявил, что впервые прототип клавиатуры для GameBoy был представлен на CES electronics в 1992 году, в мае. Эта выставка была удачной для компании, которая представила целый ряд новых продуктов, но вот клавиатура осталась почти незамеченной журналистами. Скорее всего, просто потому, что она никак не относилась к игровому миру, поэтому игровые СМИ о таком девайсе писать не захотели. Более того, одно из изданий, все же упомянувших о девайсе, назвало его нелепым.

Робертсон связался с представителем компании, которая разработала девайс для Nintendo, и тот поделился рядом подробностей. Так, например, стало известно, что стоимость клавиатуры $79-$89, что было немало. Высокая цена одна из причин, которые помешали выходу аксессуара на рынок.

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

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

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

Подробнее..

Не нравится свой интернет-провайдер? Стань им сам опыт американца по имени Джаред Мауч

14.01.2021 00:13:39 | Автор: admin

Качество работы некоторых интернет-провайдеров не выдерживает никакой критики. Подобные компании можно найти в любой стране. Чаще всего проблема в том, что организация является монополистом в своем регионе, поэтому делает, что хочет. Есть на эту тему отличная серия из South Park, которая называется Informative Murder Porn. И хотя в ней показан провайдер кабельного ТВ, сюжет актуален и для интернет-отрасли.

Так вот, в пригороде Мичигана один из клиентов провайдера интернет-услуг остался настолько недоволен сервисом, что сам стал интернет компанией. Он пробросил оптоволокно, сделал разводку, зарегистрировал предприятие и получил скоростной интернет не только для себя, но и стал обеспечивать связью соседей. Имя этого человека Джаред Мауч.

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

С чего все началось?


Мауч перебрался в новый дом в пригороде Мичигана в 2002 году. На то время он получит от местного провайдера канал T1 со скоростью в 1,5 Мбит/с, чего было вполне достаточно. Но по мере того, как совершенствовались сетевые технологии, Мауч ожидал, что и сеть в регионе будет модернизироваться. Но нет.

В итоге он переключился на провайдера, предоставляющего услуги беспроводной интернет-связи на скорости в 50 Мбит/с. Также он связался с Comcast, крупнейшей ИТ-компанией из США, спросив, во что обойдется продолжить оптоволокно к его дому. Компания сообщила, что в этом случае придется выложить $50 000. Мауч, как человек небедный, был готов потратить $10 000, но не полсотни тысяч долларов. Как он сам говорил позже, суммы в $50 000 не ожидал, и такую кучу денег непонятно за что платить не хотел.


Пять лет назад еще один крупный провайдер, AT&T, предложил DSL-линию. Но в этом случае скорость обещали ту же, что у него уже была раньше 1,5 Мбит/с. Смысла менять шило на мыло просто не было. Ну а потом провайдер и вовсе отказался от DSL, забросив и планы по модернизации своей инфраструктуры в ряде регионов.


Маучу все это надоело, и четыре года назад он решить стать интернет-провайдером сам. Несколько месяцев назад план удалось реализовать сетевой архитектор продолжил около 10 км оптоволокна и выполил все необходимые для проведения ШПД-интернета в своей дом работы. Более того, 70% его соседей стали его же клиентами. Раньше они использовали мобильные гаджеты для подключения к интернету.

Что за компания?


Американец назвал ее Washtenaw Fiber Properties LLC, зарегистрировав в качестве провайдера телефонной связи (в США только так можно предоставлять интернет клиентам). Правда, телефонных услуг он не предоставляет, равно как не проводит и кабельное.

На все про все Мауч потратил $145 000, что, конечно, немало даже для небедного человека. Но эти деньги он может постепенно вернуть, предоставляя услуги связи все большему количеству клиентов в своем регионе.


$95 000 ушло на прокладку двух интернет-каналов. Один из них сейчас используется для проведения оптоволокна, второй свободен, так что Мауч надеется в недалеком будущем сдать в аренду какой-либо IT-компании, которая придет в этот регион. Протяженность линии от точки подключения до дома Мауча 10 км. Обе магистрали находятся на глубине около 2 м, правда, в некоторых случаях углубляются до 5м, чтобы обойти трубопроводы разного назначения.


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

В домах клиентов Mauch устанавливает медиаконвертер Mikrotik RBFTC11 с модулем Ubiquiti PON-to-Ethernet. Клиенты могут использовать свои собственные беспроводные маршрутизаторы или покупать их у Mauch по себестоимости. Он решил не сдавать оборудование в аренду, поскольку это не выгодно для клиентов.

Кстати, некоторые из них добровольно потратили по несколько тысяч долларов США, чтобы снизить затраты Мауча. За это они получили скидки и премиум-обслуживание (бесплатное пиво по субботам?). Выше уже говорилось о том, что потратить пришлось много. Но американец планирует выйти в ноль уже через 3,5 года он продумал бизнес-модель, так что особой проблемы с возвратом денег нет.


Что касается тарифов, то за канал с пропускной способность в 50 Мбит/с американец просит $65 (для США это вполне нормально), $75 за канал в 250 Мбит/с и $99 за 500 Мбит/с. Если дом клиента удален от магистрали, то клиенту приходится платить за прокладку оптоволокна.


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

А что насчет жалоб клиентов?


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

Официально Мауч не предоставляет каналов связи с пропускной способностью выше 500 Мбит/с. Но в реальности, поскольку клиенты не выбирают всю скорость, зачастую показатель достигает 1 Гбит/с.

Кстати, соседям американца повезло. Жителям пригородов и удаленных от городов регионов приходится туго. Около 17,3% населения в таких локациях не имеют возможности подключиться к ШПД. В крайнем случае это дорогая связь по мобильной сети.

Планы на будущее



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


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

Подробнее..

Как с помощью UiPath внедрить process mining в компании

31.12.2020 18:20:33 | Автор: admin

Вызовы цифровой трансформации


image

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

  1. Обнаружить проблему
  2. Внедрить изменения
  3. Отслеживать решение
  4. Реагировать на отклонения

На данный момент популярным решением для внедрения изменений является инструмент RPA, который позволяет автоматизировать рутинные действия пользователей. Что касается трех остальных пунктов для этого понадобится process mining или интеллектуальный анализ бизнес-процессов.

Интеллектуальный анализ бизнес-процессов (Process Mining) фокусируется на обнаружении, анализе и оптимизации бизнес-процессов на основе данных из журналов событий (англ. event logs), представляя недостающее звено между классическим анализом бизнес-процессов с использованием их моделей и интеллектуальным анализом данных.

Инструмент process mining позволяет захватить реальные данные из популярных ERP-, CRM-систем и баз данных сквозных бизнес-процессов в закупках, финансах, управлении претензиями, контакт-центрах и т.д. (SAP, Oracle, Salesforce, ServiceNow), визуализировать их для обнаружения узких мест, неэффективности использования ресурсов и исключений; и, наконец, мониторить изменения в процессе после его оптимизации, в том числе с помощью автоматизации.

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

image
Фото с ресурса: http://personeltest.ru/aways/habr.com/ru/post/257563/

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

Кейсы process mining и автоматизации


Аудит и улучшение существующих метрик


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

На основе инсайтов UiPath Process Mining компания скорректировала автоматизацию контакт-центра. Это повысило качество и скорость связи с клиентами, а также позволило сильно сократить время ожидания клиентом оператора. В целом оказалось, что 80% всех работ можно было стандартизировать, и за счет этого снизить затраты контакт-центров на 568 тыс. евро.

Поддержка оперативных решений


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

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

Data mining и глубокое понимание процессов


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

Крупной телеком-компании из Нидерландов требовалось повысить прозрачность своих корпоративных закупок. Имея 6,3 миллиона абонентов фиксированной телефонной связи, более 33 миллионов абонентов мобильной связи и более 2 миллионов интернет-клиентов в пяти странах, они хотели найти решение для контроля рисков и определения путей снижения затрат.

Оператор развернул UiPath Process Mining для получения информации
и устранения интуитивной оценки процессов, а также ручной передачи данных. Он использовал UiPath Process Mining для оценки более чем 200 000 различных позиций, в том числе заказов на покупку и счета-фактуры.

В результате удалось сократить на 20% трудовые затраты, на 29% уменьшить время на обработку счетов-фактур, а также повысить предсказуемость затрат и улучшить отношения с поставщиками.

Опыт заказчиков


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

Екатерина Сабельникова, консультант по инновациям Philips рассказывает в своем блоге на LinkedIn о главных уроках, извлеченных при использовании process mining в компании.

Сфокусироваться на главном

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

Определить заинтересованных лиц

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

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

Обеспечить поддержку и одобрение высшего руководства

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

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

Наконец, руководство может позиционировать process mining как инструмент, помогающий достигать целевых показателей KPI. Стимулировать вовлечение в изменения всех уровней организации и использование интеллектуального анализа процессов в качестве ежедневного инструмента управления.

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

Как и у любой системы, у process mining существует ряд ограничений:

  • Адекватность отображения хода реального бизнес-процесса данными логов информационной системы;
  • Необходимость интерпретации результатов анализа.

С этими ограничениями мы столкнемся на практике, когда далее на примере UiPath Process Mining будем разбирать весь процесс внедрения аналитики бизнес процессов в организацию.

image
UiPath process mining помогает принимать основанные на фактах рекомендации для улучшения критических процессов

Гайд по развертыванию UiPath Process Mining


Формируем журнал событий

Для создания журнала событий необходимо определить источники данных для него, как правило их бывает не более 2-3. Даже если у компании есть SAP в UiPath и свой ETL, в реальном мире этим не даст воспользоваться принятая в компании стратегия интеграции и наличие КХД/КШД/DataLake или иных решений, которые управляют потоками данных.

Исходные данные получаем из хранилища данных или реплик БД и принятыми в компании средствами ETL, затем собираем/упрощаем их и помещаем в staging area для UiPath. UIPath может брать данные из любой реляционной БД, у которой есть ODBC драйвер. Затем уже из staging таблиц мы собираем журнал событий, с которым будут работать сами алгоритмы UiPath.

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

Проводим сборку журнала событий

Технически сборка журнала событий это просто select/insert из кучи таблиц в одну или две (две, когда есть атрибуты, которые не меняются от шага к шагу процесса). Неочевидная часть, связанная с проектированием структуры такого журнала: как преобразовывать смену статусов объекта или факт изменения значения какого-то атрибута в конкретный шаг. Это задача бизнес-аналитика, тут нет универсальной методики, есть шаблон вендора и ноу-хау у интегратора.

Важно понимать, что некорректно выбранный состав шагов и уровень детализации процесса не даст решить задачи анализа или поддержки решений. И еще 100% цифровизации процесса нет нигде. Значит часть шагов, которые в процессе есть, вы не отразите в журнале. Если помнить, что вы решаете задачи увеличения показателей, а не получения красивой картинки это не страшно. А если не помнить, то можно решить, что process mining бесполезное внедрение.

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

Конфигурируем Process Mining UiPath

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

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

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

Проводим аналитику отчетов

Анализировать отчеты технически легко, а вот интерпретировать их результаты совсем не просто это сфера ответственности аналитика. Методика drag-and-drop UiPath значительно упрощает его работу: вытащил виджет, настроил и смотришь данные. Что именно и как анализировать зависит от целей анализа. С технической точки зрения важно, что визуализацию для аналитика готовит дизайнер отчетов, а дальше уже начинается его работа.


Создаем дашборды

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

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

Настраиваем оперативный контроль

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

Результат работы функции можно использовать в дашбордах чтобы метить подозрительные случаи или отсылать в UiPath Action Center, чтобы там записать процедуру по ее устранению. Кстати, так же работает и интеграция с ML можно вызывать программы на R или Python, передавая им на вход данные и записывая результаты работы.

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

Здесь есть техническая проблема как организовать верстанный контроль. Тут у UiPath с самого начала все правильно: конфигурация настроек и дашбордов живет в git. Можно в локальном, можно в корпоративном, можно хоть на gituhub. В других решениях где-то версионности вообще нет (например, конфигурация модели данных), а где-то она достигается старым добрым способом допиши дату или номер версии в название файла. Технически очень много головной боли при наличии верстанного контроля уходит и длительность спринта сокращается.

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

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

Корпорация Everest Group ежегодно оценивает вендоров технологий process mining на основе их влияния на рынок, видения и возможностей их продуктов. В последнем исследовании 2020 года UiPath признали лидером в сфере process mining среди других крупнейших вендоров.

image

Выводы


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

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

Перевод Первая сторонняя покупка на Amazon какой она была и кто её совершил

06.01.2021 12:20:45 | Автор: admin


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

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

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

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

Путь к первой продаже


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



И тут на сцену выходит Джон Уэйнрайт. Он был программистом из области залива Сан-Франциско и давним другом Шела Кафана. Оба работали над совместным проектом Apple и IBM под названием Kaleida Labs. В 1994 году Шел сказал Джону: Я подумываю перебраться в Сиэтл и скооперироваться с одним парнем, Джефом Безосом. Будем продавать книги через Интернет.

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

Первая покупка со стороны


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

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

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

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

Неожиданные осложнения


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

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

На сегодняшний день Уэйнрайт технический директор компании Kollective. Книгу вместе с квитанцией о покупке он хранит до сих пор.



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



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



Впрочем, ладно, давайте обобщим сказанное: летом 1995 года один очень толковый программист, не имеющий отношения к Amazon, заказал у них солидных размеров книгу об искусственном интеллекте. Мистер Уэйнрайт, мы выражаем вам почтение за то, что сохранили эту книгу в целости. Жаль, что вас вынудили за неё заплатить. Но, если это утешит, я полагаю, что сейчас вы бы могли за неё выручить сумму побольше, чем уплаченные тогда 19,99 долларов.
Подробнее..

Курс на независимость китайский производитель флеш-чипов осуществляет запуск 192-слойной 3D NAND памяти

12.01.2021 20:07:52 | Автор: admin
Источник

Yangtze Memory Technologies Co. (YMTС), ведущий производитель микросхем памяти в Китае, удвоит масштабы выпуска стандартных NAND-чипов. Компания планирует начать конкуренцию с технологическими гигантами Samsung и Micron. Более того, этот же производитель запускает опытное производство 192-слойной 3D NAND памяти.

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

В планах у китайской компании довести объем ежемесячного производства флэш-памяти NAND до 100 тыс.пластин. Это составит примерно 7% от общего мирового производства.

Фото: YMTC

Предприятие YMTC находится в Ухане, но оно не останавливалось даже в разгар пандемии COVID-19, что говорит о стратегической важности предприятия для Поднебесной. Стоимость компании на данный момент составляет $24 млрд и продолжает увеличиваться. Летом прошлого года компания запустила строительство второй очереди производственных линий. После ввода в строй дополнительных мощностей YMTC будет способна выпускать дополнительно 200 тыс. пластин в месяц.

Любопытно, что Samsung и Micron только приступают к выпуску 176-слойных чипов. Тогда как YMTC планирует обогнать конкурентов с более продвинутой 192-слойной памятью.

Фото: YMTC

В конце прошлого года китайская компания освоила выпуск 128-слойных микросхем. Хотя анонс о завершении их разработки вышел в апреле 2020 года.

Среди крупных клиентов YMTC Lenovo Group и Huawei. Помимо чипов NAND, компания выпускает твердотельные SSD-накопители для массового потребителя под брендом Zhitai.

Начинания молодой китайской компании дали импульс созданию работающей местной системы полупроводниковой промышленности. YMTC стали первыми в стране производителем флэш-памяти 3D NAND. Курс на рост определился после успеха 2019 года, когда компания впервые вышла на рынок с 64-слойными микросхемами.

Правда, здесь не обошлось и без проблем. Дело в том, что в угоду скорости страдает качество. К последнему у экспертов есть немало вопросов, поскольку несмотря на амбиции YMTC, уровень выхода годных изделий среди 128-слойной 3D NAND на конвейере YMTC не превышает 70%.

YMT коммерческое предприятие, дочка Tsinghua Unigroup. YMTC активно поддерживается государственными организациями. Например, компания получила средства от так называемого Большого фонда (the China Integrated Circuit Industry Investment Fund) главной программы в стране по финансированию выпуска микросхем.

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

Подробнее..

Sci-Hub теперь находится в нецензурируемой сети

15.01.2021 16:07:39 | Автор: admin

После того, как популярный, но крайне нелюбимый правообладателями сайт Sci-Hub столкнулся с неоднократными отзывами доменных имен, а Твиттер и вовсе забанил аккаунт Sci-Hub, Александра Элбакян зарегистрировала его в сети распределенных доменных имен Handshake.

База данных научных работ теперь доступна напрямую черезпорталы службы,а такжечерез NextDNS, облачный преобразователь доменных имен, ориентированный на конфиденциальность, который преобразует IP-адреса в доменные имена. Разработчики NextDNSназываютсебя истинными сторонниками сетевого нейтралитета и конфиденциальности в интернете. Они считают, что незашифрованные DNS-резолверы, управляемые интернет-провайдерами, наносят ущерб этим двум принципам. Устойчивый к цензуре DNS поможет сохранить доступность Sci-Hub, даже если его снова попытаются закрыть, надеется основательница портала.

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

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

Как работает Handshake

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

Для обеспечения максимальной открытости, децентрализации, безопасности и, самое главное, устойчивости к цензуре, Handshake использует алгоритм proof-of-work. Такое решение позволяет разрешать имена со скоростью, превосходящей отправку запроса на DNS-резолверы Google. Это быстрее в том случае, если ваш узел имеет локальный кэш данных.

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

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

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

Что дальше

Децентрализованная система доменных имен (необязательно Handshake, успеха могут добиться и его последователи), может стать важным инструментом в борьбе за децентрализованный интернет. Этот проект является частью так называемых приложений Web 3.0, стремящихся создать менее централизованный, устойчивый к цензуре Интернет.В Handshake, например, естьдополнительный браузер,позволяющий вести поиск в интернете без цензуры. Также можно упомянуть Urbit, который находится в разработке более десяти лет и полагается на Ethereum для создания платформы для децентрализованных персональных серверов. Все эти решения очень пригодились бы Parler, столкнувшемуся с цензурой и давлением со стороны поставщиков облачных серверов, магазинов приложений и центров сертификации DNS.

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


Что ещё интересного есть в блогеCloud4Y

В тюрьму за приложение

2020 год всемирной мобильности (как бы иронично это ни звучало)

Виртуальные машины и тест Гилева

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

Как настроить SSH-Jump Server

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

Подробнее..

Категории

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

© 2006-2021, personeltest.ru