Возможно, вы уже умеете писать отличный код. И может, у вас уже есть реальное представление, как работает платформа, виртуализация и сеть с безопасностью. Но что, если вы не хотите углубляться ни в одну из этих областей? А может, вы уже думали о переходе в DevOps, где требуется много знаний и со стороны dev, и со стороны ops, но не нужно становиться хардкорным разработчиком? Тогда у нас хорошая новость начинать в DevOps можно в любом возрасте и с любой технической специализацией.

Тому пример Александр Шуляк, который нашел себя именно в Девопсе. Накануне конференции DevOps 2021 мы встретились с Сашей и поговорили о том, как и с чего начался его DevOps, а также к чему он пришел в этой карьере.

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

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

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

Как ты узнал про DevOps?

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

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

Какие твои навыки тебе тогда потребовались на практике?

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

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

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

Что именно нужно уметь кодить DevOps-инженеру?

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

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

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

Shell-скрипты это ведь часть работы в терминале. Что-то еще там нужно уметь?

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

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

Основные инструменты для сбора метрик сейчас это Prometheus и Grafana. Prometheus это метрик-коллектор (формально time-series database). Как альтернатива мне ещё очень нравится TICK стек на базе InfluxDB. Grafana, в свою очередь, используется для отрисовки красивой инфографики и отправки оповещений.

Для сбора логов в одном месте можно посмотреть Elastic Stack. Он довольно сложный, но дает отличное представление о работе с логами. У него есть бесплатная версия, и этого достаточно, чтобы поиграться с системой и понять, как она работает, из каких компонентов состоит. Альтернативы Elastic Stack Splunk, Datadog. Но это больше enterprise-инструменты, изучать их достаточно сложно.

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

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

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

У Linux Professional Institute (LPI) есть статьи по работе linux и базовым манипуляциям с системой. Это открытые курсы/уроки, и они хорошо помогут разобраться с работой Linux. А у Роберта Лава (Robert Love) есть отличная, хоть и немного скучная книга Ядро Linux: описание процесса разработки. Помогает быстро уснуть :)

Ещё в изучении Linux вам может сильно помочь Youtube-канал Кирилла Семаева.

Поговорим про сетевую сторону operations. Что нужно уметь делать здесь?

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

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

Расскажи про принципы DevOps. Это что-то as Code. Как они работают?

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

Наверное, самый популярный инструмент управления инфраструктурой (Infrastructure as Code) это Terraform. Его довольно просто изучать, там великолепная документация. И буквально в этом году вышло новое издание книги Евгения Брикмана Terraform. Инфраструктура на уровне кода, которая тоже отлично объясняет, как работать с этим инструментом.

Есть ещё принцип Configuration as Code, который описывает состояние операционной системы. Тут я советую для изучения Ansible. Можно Chef, но выбрать можно любой, так как поняв основной принцип работы одного, переходить на другие инструменты будет несложно.

А Pipeline as Code вообще очень интересная вещь. Так как синтаксис и предоставляемые возможности инструментов очень схожи, то можно спокойно выучить один и пользоваться всеми. С другой стороны, практически всегда построение пайплайнов приводит к shell-скриптам, потому что основного инструмента без его кастомизации в любом случае будет недостаточно.

Оркестрация это тоже необходимый навык?

Да, примерно по тем же причинам, почему мы используем всё as Code. Когда у вас контейнеров больше одного, ими сложно управлять. Для этого и существуют оркестраторы вроде Mesos, Nomad, Openshift, Kubernetes и так далее. Самый популярный, конечно, Kubernetes. Он достаточно сложный для изучения с точки зрения архитектуры и управления, но базовые понятия выучить не проблема. На первых порах этого должно быть достаточно, а остальное придёт с опытом и интересом.

Какие есть особенности у специализации DevOps-инженеров?

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

На практике список обязанностей сильно зависит от размера компании. Где-то могут быть большие команды и несколько DevOps-инженеров, которые отвечают за build продукта, релиз, платформу или безопасность и governance облака.

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

Так я оказался в Лондоне. Сейчас, после полутора лет в Gearset, я Senior SRE в финтех-стартапе Divido. И мой опыт показывает, что в Англии больше верят в узкую специализацию, чем у нас. То есть вам надо знать некоторые предметные области в вашем техническом стеке намного лучше, чем другие. Допустим, если вы Cloud Ops инженер, то у вас будет сильный упор на бизнес-инструменты именно в облаках.

У нас же чаще подразумевается, что человек умеет делать всё.

Твой доклад как раз по этой теме?

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

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

Что ты предпочитаешь, офлайн или онлайн?

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

Какие темы из программы для тебя наиболее актуальны и какие доклады хочешь послушать сам?

Разумеется доклад Дмитрия Столярова, я его большой фанат! :) У него всегда можно узнать что-то новое про кубер, с которым я последние два года очень плотно работаю. А также о теоретической части SRE/DevOps, поскольку мне очень интересно, как выстроены процессы в разных компаниях и как они скрещивают методологии с реальной жизнью.

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

Ну и конечно, нас ждет извечно актуальная и холиварная для меня тема про SRE человек-оркестр, потому что никто не знает как обозвать человека со специфичным набором навыков и вообще надо ли :)

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

Спасибо и до встречи!

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

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

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

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

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

2. DNS-запросы. Каждый раз, когда Ваш браузер хочет получить доступ к определенной службе, например Google, обратившись к www.google.com, Ваш браузер запросит службу DNS, чтобы найти IP-адреса веб-серверов Google. Таким образом, интернет-провайдер DNS-записей сможет рассказать обо всем, что Вы делали в сети, просто просмотрев те журналы, которые, в свою очередь, могут быть предоставлены злоумышленнику.

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

4. Устройства Wi-Fi и Bluetooth вокруг Вас. Производители смартфонов заложили функции поиска Вашего местонахождения без использования GPS-функций. Достаточно сканировать Wi-Fi сети вокруг устройства. Данные о Вашем местоположении отправляются на сервера третьих компаний.

5. Использование Wi-Fi на смартфоне. Чтобы получить Ваши данные хакеры могут использовать специальные устройства, которые будут мешать работе wi-fi точек доступа и вынуждать Ваш смартфон подключиться к их устройству вместо публичной wi-fi точки доступа. В этом случае все Ваши данные становятся доступными для злоумышленника. В данном случае используются технологии MITM (Man-In-The-Middle) или человек посередине.

6. Использование Tor/VPN. За прошедшие годы было разработано и изучено множество передовых методов деанонимизации зашифрованного трафика Tor. Атака по корреляционным отпечаткам пальцев: эта атака будет отпечатывать ваш зашифрованный трафик (например, веб-сайты, которые вы посещали) только на основе анализа вашего зашифрованного трафика (без его расшифровки). Он может сделать это с колоссальным успехом в 96%. Такие отпечатки пальцев могут использоваться злоумышленником, имеющим доступ к вашей исходной сети (например, Ваш интернет-провайдер), для выяснения некоторых ваших зашифрованных действий (например, какие веб-сайты вы посещали).

7. Современные смартфоны на Android, IOS.
После выключения такого устройства оно будет продолжать передавать идентификационную информацию на близлежащие устройства даже в автономном режиме с использованием Bluetooth Low-Energy. Это дает способ найти Вас даже если Ваш телефон выключен, но имеет подключенный аккумулятор.

8. IMEI идентификатор Вашего оборудования. IMEI привязан непосредственно к телефону, который вы используете. Этот номер известен и отслеживается операторами мобильной связи, а также известен производителями. Каждый раз, когда ваш телефон подключается к мобильной сети, он регистрирует IMEI в сети. Он также используется многими приложениями (например, банковскими приложениями, злоупотребляющими разрешением телефона на Android) и операционными системами смартфонов (Android/IOS) для идентификации устройства. Сегодня предоставление вашего реального номера телефона в основном то же самое или лучше, чем предоставление вашего паспорта. Журналы антенн оператора мобильной связи также хранят некоторые данные о подключении. Они знают и регистрируют, например, что телефон с IMEI, подключен к набору мобильных антенн, и насколько мощный сигнал каждой из этих антенн. Это позволяет легко выполнять триангуляцию/геолокацию сигнала. Они также знают, какие другие телефоны (например, ваш настоящий) подключены в одно и то же время к тем же антеннам с тем же сигналом, что позволит точно знать, что этот телефон всегда был подключен в том же месте и в то же время, что и этот другой телефон, который появляется каждый раз, когда используется записывающий телефон. Эта информация может использоваться различными третьими сторонами для точного определения вашего местоположения/отслеживания.

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

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

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

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

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

• пол;

• возраст;

• семейное положение;

• политические, религиозные взгляды;

• финансовое состояние;

• интересы;

• привычки;

• и многие другие.

Согласно результатам исследования EFF (Electronic Frontier Foundation), уникальность отпечатка браузера очень высока и он содержит в себе ниже описанные данные:

• User-agent (включая не только браузер, но и версию ОС, тип устройства, языковые настройки, панели инструментов и т.п.);

• Часовой пояс;

• Разрешение экрана и глубину цвета;

• Supercookies;

• Настройки куки;

• Системные шрифты;

• Плагины к браузеру и их версии;

• Журнал посещений;

• И другие данные.

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

Согласно исследованию Browser Fingerprinting via OS and Hardware Level Features, точность идентификации пользователя при помощи отпечатка браузера составляет 99,24%.

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

Статья написана в соавторстве:
1. Меньшиков Ярослав
2. Беляев Дмитрий

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

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

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

Зачем нужен контейнер работодателям и их сотрудникам?

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

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

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

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

Особенность контейнеров для iOS

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

С точки зрения контейнеризации в iOS есть встроенный механизм разделения корпоративного и личного. Apple называет корпоративное управляемым (managed), а личное неуправляемым (unmanaged).

Управляемыми в iOS могут быть приложения, учётные записи и URL в Safari. С помощью встроенных политик можно запретить передачу данных между управляемым и неуправляемым, но только случайную. Это значит, что сотрудник не может передать вложение из корпоративной почты в личную почту или в WhatsApp, но может скопировать текст вложения и вставить его куда угодно!

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

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

Разнообразие Android - контейнеров

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

Первой компанией, которая сделала возможным создание контейнеров на Android, стала компания Samsung. В 2012 году на смартфоне Samsung Galaxy S3 впервые стали доступны функции корпоративной платформы безопасности Samsung Knox. В частности, Knox контейнеры. Большинство современных устройств Samsung также их поддерживают. Многие функции платформы Samsung Knox бесплатны, но функции Knox контейнеров были платной опцией. Позже Google анонсировал свою бесплатную корпоративную платформу Android for Enterprise c меньшим набором функций.

С годами число функций управления контейнерами, которые были эксклюзивно доступны на устройствах Samsung, сокращалось, потому что они появлялись у Google. В результате, начиная с
1 июля 2021 года, Samsung принял решение о бесплатном предоставлении возможностей Knox-контейнеризации. В составе платформы Samsung Knox ещё остаются платные опции, которых нет у Google. Например, корпоративных сервис обновления прошивок мобильных устройств E-FOTA One, о котором мы рассказывали в одной из прошлых статей.

Но конкретно Knox контейнеры отныне бесплатны.

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

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

Вроде то, что нужно? Да, но не обошлось без важных особенностей.

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

Работает эта схема так:

1. На мобильное устройство устанавливается клиент управления.

2. Пользователь регистрирует устройство на сервере управления.

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

4. Можно доставить обновления настроек быстрее с помощью push-уведомлений от Google, но их использование необязательно.

Преимущество этой схемы в том, что её можно построить в локальной инфраструктуре заказчика (on-premise). Для крупного бизнеса в России это важно.

У платформы Android for Enterprise от Google тоже есть клиентские библиотеки и с их помощью можно управлять устройствами без контейнеров устанавливать приложения, настраивать ограничения и т.д. Даже можно создать контейнер, поместить в него встроенный Gmail или Google Chrome и запретить сотруднику копировать из контейнера файлы. Всё это будет работать on-premise.

Но клиентские библиотеки Google не помогут, если нужно разместить в контейнере приложение собственной разработки или какое-то приложение из Google Play. В этом случае необходимо использовать Android Management API, который работает по несложной схеме:

1. На мобильное устройство устанавливается клиент управления от Google Android Device Policy.

2. Администратор создаёт настройки контейнера какие приложения в него установить, какие политики ограничений применить и т.д.

3. Сервер передаёт настройки контейнера в Google с помощью Android Management API. Дальше Google обеспечивает их применение на устройстве самостоятельно. При этом все команды и все дистрибутивы корпоративных приложений нужно передать в Google.

   Источник: https://developers.google.com/android/management/introduction

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

Корпоративный Android в личном пользовании

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

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

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

Knox Separated Apps, как и Knox контейнеры, с 1 июля 2021 года также станет бесплатной.

Советы для топ-менеджеров

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

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

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

На каждом новом устройстве корпоративный софт не работает совершенно особенным образом. Каждая мажорная версия Android c 4 по 12 серьёзно отличаются. У каждого производителя своя сборка Android. У каждой сборки Android, особенно китайской, свои тараканы неуправляемые менеджеры памяти и батареи, которые так и норовят поскорее закрыть приложение или не дать ему вовремя получить данные от сервера, дополнительные разрешения, которые пользователь должен вручную дать приложению и которые он может в любой момент отобрать и т.п.

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

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

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

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

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

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

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

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

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

• Простой способ подключения чата к системе.
  - Реализована в виде бота

• Максимально удобный для Telegram команд UX
  - Есть распознавание речи основанное на нормализованных семантических представлениях

Где примеры использования?

Бот понимает в запросах и русский и английский язык в свободной форме. Используются сокращения: d - дни, h - часы, m - минуты, s - секунды. Все уведомления публичны, но исчезают через 15 секунд, чтобы не засорять общий чат.

Довольно слов, покажите мне код!

Для бекенда использовался язык Kotlin + JVM, в качестве базы данных используется Redis-кластер. Весь код продокументирован и доступен на GitHub: demidko/timecobot
Чтобы начать использовать бота в вашей телеграм-группе просто добавьте его с правами администратора: @timecbobot

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

Всем удачного дня!

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

Нужна ли шкафу дверь?

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

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

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

Какая несущая способность шкафа вам нужна?

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

Что такое оптимальная комплектация?

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

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

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

• Изоляцию переднего фронта шкафа по периметру (чтоб избежать утечек воздуха);

• Кабельные вводы в крыше со щеточным краем или другой защитой от утечки воздуха (в задней части для установки БРП, в передней или средней для слаботочной коммутации);

• Вертикальные монтажные панели (для установки БРП и аксессуаров);

• Комплект объединения в ряд;

• Поставку в сборе на паллете (чтобы не отнимать у заказчика время на сборку!).

Кастомизация и аксессуары

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

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

Хорошим тоном со стороны поставщика считается добавление к поставке крепежа и инструментов для установки оборудования.

Сервис

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

• разгрузка;

• распаковка;

• транспортировка до машзала;

• расстановка и сборка в ряды;

• утилизация упаковки;

• установка 19профилей на нужной глубине;

• монтаж аксессуаров на определённый юнит;

• закрепление блоков распределения питания и т. д.

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

"Неужели компании хотят так сильно экономить, что готовы терять в качестве и времени?"

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

Сразу прокомментирую, что в этой статье нет цели оклеветать или высказать своё негативное мнение о компаниях. Нет! Я опираюсь только на их опыт и на полученные результаты.

Я занимаюсь подбором IT-специалистов и для того, чтобы не быть "тем самым HR, который сливает , а не помогает, своими оценочными тестами и вопросами вне понимания специфики работы", мне приходится изучать гигабайты информации на habr и других ресурсах. И в первых рядах моего несогласия, есть такая профессия - Fullstack-разработчик.

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

С 2018 года я начал вникать в эту сферу более плотно. Освоил основы HTML/CSS, познакомился с Python, PHP, Swift. Естественно эти познания подтолкнули меня сменить компанию из обычной на IT. Мне повезло и меня взяли в достаточно перспективный на мой взгляд стартап (разглашать не буду его название из добрых побуждений). Первые месяца три, я работал на должности специалиста по работе с клиентами, но сейчас понимаю, что на самом деле выполнял функционал Project-manager и одновременно Product Owner. Ну и по совместительству еще продавец и support.

Мне реально нравился проект и я горел его улучшить. Хотите верьте, хотите нет, но в этом проекте я стал хуже спать. Я постоянно думал, что можно улучшить. Я стал предлагать идеи по улучшению своему непосредственному, а тот вообще не про IT и очень скоро я понял, что я ему говорю свои идеи, а он просто не правильно их "продает" генеральному. Я не хочу сказать, что этот руководитель плохой. Наоборот, он достаточно внимательно относился ко всем сотрудникам и реально хотел донести мои идеи генеральному, но просто не владея техническим восприятием, он не мог объяснить так, как это говорил ему я.

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

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

И вот мне все же пришлось упереться в стену, которую непроизвольно построили разработчики. Сейчас вы поймете о чем я. Проработав почти год в проекте и коммуницируя с Team Lead, я не знал, сколько в команде разработчиков. Мне пояснили, что проект новый на рынке (хотя я знал точно, что они не уникальны) и что не могут себе позволить разработчиков со стороны. Что есть команда, (как позже я все же выяснил, что она из 5 человек), в которой есть back&front и парочка как раз Fullstack-разработчиков. На них и держался весь проект.

Естественно они сильные специалисты и я и сейчас в шоке, как они все это стойко держали. Да, Scrum (Agile), Jira. Пользовались теми же инструментами, которые хвалил рынок. Но "бэклог" еженедельно рос. Спрос на продукт стремительно набирал обороты и я начал "кричать", пытаясь быть услышанным, что нам срочно нужно расширять команду разработчиков и причем принципиально , среди них не должны быть больше Fullstack. К тому моменту, когда негодование users начинало зашкаливать, из-за постоянных срывов обещанных дедлайнов, я явно видел, что для быстрого роста и своевременного исправления скопившихся багов, нужно брать людей на отдельные блоки. И вот тут-то мы и выяснили, что Fullstack-разработчики писали код так, что его нельзя пока что разделить на блоки. Что если пустить со стороны человека, то он будет видеть весь код. Увы, но такова была реальность. Приняли решение максимально срочно декомпозировать, но вы наверно знаете, что на практике это совсем не просто.

"Страсти" в этом проекте накалялись. Разработчики сутками пытались исправлять баги, про которые ежедневно менеджерам по работе с клиентами звонили клиенты. Все мы принимали еженедельно новые алгоритмы, которые полностью меняли структуру работы и максимально выводили из процесса разработчиков (я их нарисовал 5 в период 7 месяцев). Пытались максимально разгрузить разработчиков, сняли все, что можно получить временно внешними ресурсами (сайт на Битрикс, CRM и так далее). Но в итоге, это не дало нужных результатов. Спустя 2 года, я покинул проект.

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

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

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

Успешных вам проектов!

Данный пост содержит выдержки из одноименной статьи Дэниела Фагеллы, руководителя отдела исследований в компании Emerj от 26.02.2020. Дэниел является всемирно востребованным экспертом по последствиям ИИ по направлению конкурентных стратегий для лидеров бизнеса и государств; его услугами пользуются ООН, Всемирный банк, Интерпол и ведущие компании.

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

Главный тезис указанного поста звучал так:

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

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

Итак, вот перевод. Прошу отнестись с пониманием (с) ;-). Все очепятки мои

Набрав что такое machine learning? в поисковой строке Google, можно открыть ящик Пандоры форумов, научных исследований и ложной информации и цель этой статьи состоит в том, чтобы упростить определение и понимание термина машинное усвоение благодаря прямой помощи со стороны группы экспертов-исследователей.

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

Эта статья будет разбита на следующие ниже разделы:

• Что такое машинное усвоение?

• Как мы пришли к нашему определению (посредством разных точек зрения экспертов-исследователей)

• Базовые концепции машинного усвоения

• Визуальные представления моделей машинного усвоения

• Как мы обеспечиваем машины способностью усваивать знания

• Обзор трудностей и пределов машинного усвоения

• Краткое введение в глубокое усвоение знаний

• Цитируемые работы

• Интервью по данной теме

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

Что такое машинное усвоение?

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

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

Как мы пришли к нашему определению

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

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

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

3. Машинное усвоение основывается на алгоритмах, которые могут усваивать знания из данных, не опираясь в этом на программирование на основе правил -McKinsey & Co.

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

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

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

Д-р Иошуа Бенжио, Монреальский университет:

Термин не должен определяться использованием отрицаний (отсюда, пункты 2 и 3 исключаются). Вот мое определение:

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

Д-р Данко Николич, CSC и Институт Макса Планка:

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

Д-р Роман Ямпольский, Университет Луисвилла:

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

Доктор Эмили Фокс, Вашингтонский университет:

Мое любимое определение - пункт 5.

Базовые концепции машинного усвоения

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

• Представление (набор классификаторов или понятный компьютеру язык)

• Оценивание (aka целевая функция/функция оценивания)

• Оптимизация (метод поиска; нередко, например, классификатор с наивысшей оценкой; используются как готовые, так и конкретно-прикладные методы оптимизации)

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

Визуализации моделей машинного усвоения знаний

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

Модель на основе дерева решений:

Модель на основе гауссовой смеси:

Нейронная сеть с отсевом

Как мы обеспечиваем машины способностью усваивать знания

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

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

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

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

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

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

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

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

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

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

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

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

Глубокое усвоение и новейшие разработки в нейронных сетях

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

Международная конференция по машинному усвоению (International Conference on Machine Learning, аббр. ICML) широко считается одной из самых важных в мире. В 2019 году она проводилась в Нью-Йорке и собрала исследователей со всего мира, которые работают над решением текущих проблем в области глубокого усвоения знаний:

1. Неконтролируемое усвоение в малых наборах данных

2. Усвоение на основе симуляций и переносимость в реальный мир

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

Ключевые тезисы по применению машинного усвоения знаний

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

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

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

• Из простоты не следует точность (согласно Доминго) между числом модельных параметров и склонностью к переподгонке нет заданной связи

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

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

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

Цитируемые работы

1 http://homes.cs.washington.edu/~pedrod/papers/cacm12.pd

2 http://videolectures.net/deeplearning2016_precup_machine_learning/

3 http://www.aaai.org/ojs/index.php/aimagazine/article/view/2367/2272

4 https://research.facebook.com/blog/facebook-researchers-focus-on-the-most-challenging-machine-learning-questions-at-icml-2016/

5 https://sites.google.com/site/dataefficientml/

6 http://www.cl.uni-heidelberg.de/courses/ws14/deepl/BengioETAL12.pdf

Интервью в Emerj по темам, связанным с машинным усвоением знаний

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

• Наука машинного усвоения знаний с д-ром Иошуа Бенжио(один из ведущих мировых экспертов в области МУ)

• Д-р Лайл Унгар из UPENN oб использовании машинного усвоения знаний для выявления шаблонов и смысла в социальных медиа

• Консультант по ИИ Лорьен Пратт из Кремниевой долины о деловых вариантах использования технологии машинного усвоения знаний

Выводы

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

Вот пример для проверки:

#include <iostream>int main(){    std::cout << "-3/3u*3 = " << int(-3/3u*3) << "\n";}

Посмотреть результат можно тут.

Или попробуйте поиграться с этим примером здесь или здесь.

Вообще-то мне не удалось найти хоть какой-то компилятор С++, который бы выдавал результат отличный от -4. Даже старый GCC-4.1.2, clang-3.0.0 или Borland C 1992 года. Так же заметил, что результат одинаковый и для константы, вычисляемой в момент компиляции и для времени выполнения.

Предлагаю внимательно рассмотреть результат выражения -3/3u*3.

Если убрать приведение к типу intв примере выше, то получим 4294967292 или 0xFFFFFFFС(-4). Получается, что компилятор на самом деле считает результат беззнаковым и равным 4294967292. До этого момента я был свято уверен, что если в выражении используется знаковый тип, то и результат будет знаковым. Логично же это.

Если посмотреть откуда берется -4 вместо -3, посмотрим внимательней на ассемблерный код примера, например здесь.

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

int main(){    volatile unsigned B = 3;    int A = -3/B*3;}

Для x86-64 clang 12.0.0 видим, что используется беззнаковое деление, хотя числитель откровенно отрицательное -3:

        mov     dword ptr [rbp - 4], 3    // B = 3        mov     ecx, dword ptr [rbp - 4]        mov     eax, 4294967293        xor     edx, edx        div     ecx                       // беззнаковое деление !!        imul    eax, eax, 3               // знаковое умножение        mov     dword ptr [rbp - 8], eax

Для x64 msvc v19.28 тот же подход к делению:

        mov     DWORD PTR B$[rsp], 3      // B = 3        mov     eax, DWORD PTR B$[rsp]        mov     DWORD PTR tv64[rsp], eax        xor     edx, edx        mov     eax, -3                             ; fffffffdH        mov     ecx, DWORD PTR tv64[rsp]        div     ecx        imul    eax, eax, 3        mov     DWORD PTR A$[rsp], eax

Получается, что для деления беззнакового числа на знаковое используется БЕЗЗНАКОВАЯ операция деления процессора div. Кстати, следующая команда процессора, это правильное знаковое умножение imul. Ну явный баг компилятора. Банальная логика же подсказывает, что знаковый тип выиграет в приведении типа результата выражения если оба знаковый и беззнаковый типы используются в выражении. И для знакового деления требуется знаковая команда деления процессора idiv, чтоб получить правильный результат со знаком.

Проблема еще и в том, что число 4294967293 не делится на 3 без остатка:4294967293 = 1431655764 * 3 + 1и при умножении 1431655764 обратно на 3, получаем 4294967292 или -4. Так что прикинуться веником и считать, что 4294967293 это то же -3, только вид сбоку, для операции деления не прокатит.

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

Действительно, стандарт говорит об этом прямо:

Otherwise, if the unsigned operand's conversion rank is greater or equal to the conversion rank of" "the signed operand, the signed operand is converted to the unsigned operand's type.

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

Вот где оказывается собака зарыта: "the signed operand is converted to the unsigned operand's type"!! Ну почему, почему, Карл!! Логичнее наоборот: "the unsigned operand is converted to the signed operand's type", разумеется при соблюдении ранга преобразования. Ну вот как -3 представить без-знаковым числом?? Наоборот кстати можно.

Интересная получается сегрегация по знаковому признаку!

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

Проверим на ассемблере здесь этот пример:

int main(){    volatile unsigned B = 3;    int C = -3*B;}

Стандарт ничего не говорит о неприменимости этого правила для операции умножения. И деление и умножение должны быть БЕЗЗНАКОВМИ.

Я подумал, что что-то в стандарте сломалось и надо срочно это исправить. Написал письмо напрямую в поддержку Стандарта со всеми моими выкладками и предложением поправить это странное правило стандарта пока еще не поздно.

Ага! Наивный!

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

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

• Как я не натыкался на это раньше? Не один десяток лет интенсивно кодирую на С и С++ с погружением в ассемблер, но только сейчас споткнулся на неё. Хотя может и натыкался ранее, но не мог поверить что причина именно в этом.

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

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

int main(){    const unsigned a[] = {3,4,5,6,7};    unsigned p = (&a[0] - &a[3])/3u*3;    // -3    unsigned b = -3/3u*3;   // -4}

Хоть я и понимаю, что могу ошибаться в логике работы этого мира, но задумайтесь, в следующий раз садясь в современный, нашпигованный вычислительной логикой самолёт (или автомобиль), а не сработает ли вдруг не оттестированный кусок кода в какой-то редкой нештатной ситуации, и не выдаст ли он -4 вместо элементарных -3, и не постигнет ли его участь подобная Boeing 737 MAX?

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

Предвижу возражение, что есть рекомендация использовать преимущественно без-знаковый тип. Понимаю, с таким правилом Стандарта по другому никак. Но как -4 в беззнаковое перевести, и чтоб всё остальное работало? И почему на других языках и всех процессорах не надо этими танцами с бубном заниматься, а в С++ надо? И что делать с константными выражениями, вычисляемыми компилятором? Вместо элегантных выражений, в которых мы уверены, надо записывать их с оглядкой, чтоб у компилятора небыло изжоги!

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

Как хорошую подсказку познавательно добавить предупреждение в компилятор когда он применяет это правило из Стандарта:"Signed value is intentionally converted to unsigned value. Sorry for crashing one more airplane. Have a nice flight!" Вот удивимся тогда, как мало мы тестируем и как много нам открытий чудных приносит компилятор друг.

Можно еще исправить Стандарт, ограничив правило только операциями сложения и вычитания. Как компромис. Но это крайне маловероятно в этой Вселенной. Да и Боингов еще много летает.

Новые протоколы DNS-over-HTTPS и DNS-over-TLS стали настоящим яблоком раздора в ИТ-сообществе. Шифрование DNS-запросов внедряет во все большее число браузеров, но среди экспертов есть и те, кто критикует этот подход. Они считают, что новые протоколы не оказывают положительного влияния на степень защищенности и в лучшем случае бесполезны.

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

Возможность мониторинга остается

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

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

В то же время основатель PowerDNS Берт Хуберт (Bert Hubert) говорит, что DoH шифрует данные, которые можно без особого труда получить в открытом виде из других источников. Например, интернет-провайдеры могут определить сайты, которые посещает клиент через протокол OCSP (RFC 6960). Он служит для получения статуса отзыва цифрового сертификата X.509 (описывает процедуры распределения открытых ключей). Ответы OCSP содержат серийный номер TLS-сертификата на сайте, и по нему легко определить название ресурса.

Есть уязвимые места

Специалист по информационной безопасности и один из разработчиков открытого дистрибутива Whonix отмечает, что существуют и другие способы заполучить информацию о посещаемых сайтах. Один из вариантов анализ Server Name Indication (SNI). Это расширение протокола TLS, и через него клиенты сами сообщают имя хоста, к которому желают подключиться.

Информация транслируется в открытом виде, и при желании её можно перехватить. Справедливости ради стоит отметить, что уже есть инструменты, позволяющие шифровать SNI например, проект Encrypted Client Hello (ECH). Он скрывает метаданные, передающиеся во время рукопожатия, однако инструмент и его аналоги пока не получили широкого распространения.

Даже если шифровать DNS-запросы и использовать другие предосторожности, остается пусть и очевидный, но весомый момент, связанный с IP-адресом ресурса, к которому подключается клиент. По оценке специалистов регионального интернет-регистратора APNIC, его достаточно для точной идентификации более 95% сайтов. В оставшиеся 5% входят IP-адреса, связанные с несколькими ресурсами. Но и эту проблему при желании можно обойти.

Новые кибератаки

Еще в 2019 году специалисты по информационной безопасности из Netlabобнаружили вредонос Godlua. Программа злоупотребляет особенностями DNS-over-HTTPS для проведения DDoS-атак. С помощью протокола зловред маскирует обмен данными с управляющими серверами.

В итоге антивирусное ПО не может его обнаружить.

Эксперты опасались, что за Godlua последуют другие вредоносы, невидимые для систем пассивного антивирусного мониторинга. Так и получилось в конце 2020 года в Huntress Labs обнаружили новый вирус. С помощью DoH он получает IP-адреса хостов, входящих в состав вредоносной инфраструктуры. Остается надеяться, что в ближайшее время появятся инструменты, которые помогут выявлять вредоносную активность в зашифрованном трафике корпоративных сетей и предупреждать администраторов о потенциальных рисках.

Что дальше

Можно сделать вывод о том, что для повышения приватности необходимо использовать комплексный набор инструментов, в том числе и VPN. Одного лишь шифрования DNS недостаточно для полного сокрытия истории браузинга. Однако технологии DNS-over-HTTPS и DNS-over-TLS можно рассматривать как еще один важный шаг к безопасному интернету.

Что еще почитать по теме:

• Что лучше x86 или ARM?

• На что пересесть после ACCEL-PPP

• DNS over HTTPS безопасность или сложность в работе

• P2P-протокол Dat как работает и кем используется

• Технологии шифрования нового поколения: как они работают

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

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

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

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

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

1. Нет включения в командную работу.

2. Нет обратной связи.

3. Нет цели.

4. Нет контроля.

5. Нет ценности.

Заранее благодарю за комментарии и дополнения.

Причина 1. Нет включения в командную работу

Мы плывем в одной лодке. Слышали такое выражение у себя в команде? По-моему, это очень верное сравнение: работы команды над проектом в ИТ с работой экипажа корабля.

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

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

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

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

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

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

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

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

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

Причина 2. Нет обратной связи

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

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

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

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

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

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

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

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

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

Причина 3. Нет цели

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

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

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

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

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

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

Причина 4. Нет контроля

На первый взгляд отсутствие контроля за работой это вух-ху! как здорово.

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

Главное сдай документ вовремя. Всё. Шикарно же, разве нет? Нет.

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

Когда у тебя задач пять, отодвинуть их в сторону и взять шестую с, конечно же, самым высоким приоритетом не сложно. Но а что если у тебя таких задач штук 10-15? И пусть 2-3 из них, ну, не срочные, но чем быстрее, тем лучше?

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

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

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

Причина 5. Нет ценности

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

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

Первый: документация у вас будет, но качество ее будет сомнительным. Вашу команду такое устроит?

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

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

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

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

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

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

Удачи!

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

В чем суть?

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

(Лао-цзы)

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

Звучит интересно, в чем отличие от кармы?

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

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

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

4. Каждый может разбанить любого другого если у него достаточно валюты. Нет тотальной отмены с глубоким минусом, нет минуса которого нельзя отменить (как -100 на Хабре), нет лимитов прощения, было бы только желание подождать немного или попросить любого пользователя помочь вернуться сразу!

В чем цели эксперимента?

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

Как поучаствовать?

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

Исходный код чата

Эта статья о социальном эксперименте, однако она была бы не для Хабра без технических деталей. Поэтому для тех кому это интересно, подробные принципы работы валюты и UX описаны в этой статье: habr.com/ru/post/556292/
Исходный код системы доступен на GitHub: github.com/demidko/timecobot
Для бекенда использован один из лучших виданных мною языков - Kotlin, за что хочу сказать здесь спасибо его разработчикам.

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

Зачем нам p3express в наших IT-проектах

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

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

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

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

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

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

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

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

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

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

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

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

Второе его преимущество p3express сбалансирован по цене/срокам/скоупу.

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

Дальше я поэтапно рассмотрю шаги p3express и прокомментирую, как мы с этим живем.

Подготовка проекта

Начало в p3express вполне классическое:

• Шаг 01. Определить спонсора;

• Шаг 02. Подготовить резюме проекта;

• Шаг 03. Определить руководителя проекта;

• Шаг 04. Развернуть рабочее пространство;

• Шаг 05. Определить команду;

• Шаг 06. Планирование проекта;

• Шаг 07. Определить внешних исполнителей (если в проекте они есть) ;

• Шаг 08. Провести аудит подготовки;

• Шаг 09. Да/нет;

• Шаг 10. Провести стартовую встречу;

• Шаг 11. Фокусированная коммуникация.

У нас же получилось всё сильно сложнее, чем 11 шагов.

Шаг 01. Определить спонсора продукта

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

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

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

Шаг 02. Подготовить резюме проекта

Для нас это самое сложное перед запуском проекта. Взрослые методологии, тот же самый ISO 21500, предполагают, что на вход в проект придет бизнес-план или ТЭО, которые полностью описывают, что мы делаем и зачем, как на этом планируем зарабатывать и т.д., чтобы можно было прочитать и сказать: А, понятно!, и по нему уже запускать проект. Но у нас так не получается.

Поэтому перед стартом проекта мы обычно делаем очень много консалтинга. Эти работы мы даже выносим в отдельный контракт с фиксированной стоимостью. Обычно это относительно небольшое время от 2 до 6 недель при том, что проекты бывают от 2 до 12-24 месяцев.

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

Со стартапами мы обычно используем Lean Canvas. Это большая таблица, в которой грубо раскидано что, зачем, кому мы делаем, как нам за это будут платить и почему нам это выгодно. Это больше маркетинговая история, но на самом деле именно она определяет, что мы будем делать. Это некая канва бизнес-модели, и именно с ней мы сверяемся, когда хотим что-то в проекте поменять или выбрать альтернативный путь. Мы смотрим нашему продукту это ценности прибавит или, наоборот, убавит?

Из Lean Canvas вырастает MVP: мы видим, каким должен быть минимальный продукт, чтобы проверить, а правильно ли мы вообще напридумывали скетчи и прототипы, концепт дизайна, техническое задание? Это как раз тот пакет документов, который в больших методологиях называется бизнес-план, ТЭО или еще как-то.

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

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

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

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

Параметры проекта

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

Это есть во всех стандартах управления проектами, которые я знаю. Но мы используем очень простую методику Scope-Pak. Придумали ее не мы по ссылке в QR коде можно посмотреть первоисточник:

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

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

Рассмотрим кратко эти 8 шагов:

Шаг 1. Заинтересованные стороны:

• Чьи деньги участвуют в реализации проекта?

• Этот человек является спонсором проекта?

• Кто еще будет участвовать в проекте?

Шаг 2. Компоненты:

• Что предстоит сделать?

• Нужны какие-то вспомогательные работы?

• Нужны подготовительные работы?

• Завершающие работы?

• Если мы сделаем все это, мы завершим весь проект?

Когда мы читали оригинал, мы очень смеялись над советом: ОГРАНИЧЬТЕ СПИСОК 30 ПУНКТАМИ то есть не расписывайте подробнее, чем на 30 пунктов, что надо сделать. А на практике мы столкнулись с тем, что только первые 6 рождаются просто в бешеных муках, а потом сложно остановиться.

Шаг 3. Цели и результаты:

• Зачем мы все это делаем и как правильно это назвать?

• Что мы получим на выходе и как это измерить?

• Когда мы хотим это получить?

• То, что мы запланировали сделать даст нам эти результаты?

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

Шаг 4. Альтернативы

• Есть ли более эффективный способ достичь своих целей?

• То, что мы запланировали сделать единственный способ получить нужный нам результат?

• Как еще можно получить тот же результат?

• Что можно сделать лучше?

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

Шаг 5. Ресурсы и сложности

• Какова стратегия финансирования проекта?

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

• Какие ресурсы вам потребуются?

• С какими препятствиями вы столкнетесь?

• Кто спонсирует этот проект?

• Какие разрешения вы должны получить?

• Кто будет выполнять задания проекта?

• Каковы временные рамки?

• Каковы критические даты?

• Что может быть еще включено в проект?

• Что можно исключить из проекта?

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

Шаг 6. План наступления

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

Шаг 7. Риски:

• Какие предположения вы сделали?

• Какие предположения вы должны сделать?

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

• Как можно сократить риски или найти обходные пути?

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

Шаг 8. Ключевые индикаторы достижения цели:

• Кто 3-4 самые главные заинтересованные участники проекта?

• Какой результат их скорее всего удовлетворит?

• Как измерить каждый из них по завершении проекта?

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

Например, заказчик хочет оптимизировать логистику. Мы выясняем, что сейчас эффективность использования его автотранспорта 20%, а клиент хочет достигнуть 70%. Мы считаем на коленке и понимаем, что весь его процесс так устроен, что больше 30% просто не получится. Потому что хоть клиент и ожидает, что машина будет 70% в пути, ей на самом деле нужно больше времени для приезда, разгрузки, погрузки, отъезда и прочих факторов. И если мы соглашаемся на 70%, не оговаривая всё это сразу, то под конец приходим к тому, что проделали отличную работу, всё здорово, всё классно, все довольны, а клиент говорит: Ребята, ну не 70 же! Как минимум, это неприятно, а может закончиться и контрактными проблемами.

Шаг 9. Да / Нет

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

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

Поэтому я согласен с тем, что этап Да/Нет должен происходить как раз на этом шаге. Этим мне тоже очень понравился p3express, потому что это мало где применяется. По некоторым методологиям, люди посидели, подумали и ТЭО составили, а потом принесли на старт проект и сразу начали проектировать. А в жизни как раз получается наоборот. Когда назначен менеджер и решили да, наверное, будем делать проект, очень многое еще непонятно. И вот именно на этом этапе есть смысл сесть и подумать а вы уверены, что в это ввязываетесь? Да? Тогда поскакали, всё классно, и все друг друга хорошо понимают.

Планирование этапа

Тут у P3express всё по канонам:

• Шаг 12. Обновить планы;

• Шаг 13. Определить внешних исполнителей (если в проекте они есть);

• Шаг 14. Да/нет;

• Шаг 15. Провести стартовую встречу цикла;

• Шаг 16. Фокусированная коммуникация.

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

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

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

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

• какую ценность нам это принесет?

• что будет стоить по трудозатратам, по ресурсам, по времени, etc.?

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

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

Реализация этапа

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

Еженедельные действия p3express определяет так:

• Шаг 17. Оценить прогресс;

• Шаг 18. Работать с отклонениями;

• Шаг 19. Еженедельная встреча;

• Шаг 20. Провести еженедельный аудит;

• Шаг 21. Фокусированная коммуникация.

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

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

Два показателя особенно классные: плановый объем (PV) и освоенный объем (EV). Они помогают нам наглядно увидеть: отстаем ли мы, идем с опережением или что-то другое происходит.

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

Из-за этой неровности невозможно сопоставить сроки и объем. Вроде бы прошла половина срока, и мы должны получить половину планируемого результата но мы получили 63% или 48%. Возникает вопрос: Это хорошо или плохо?. А по методике соответствия планового/освоенного мы заранее расписываем: мы будем тратить ресурсы именно так, и именно так получать ценность. А потом легко сравнить, получились ли наши запланированные 63% и 48%.

Ежедневные действия

На этом этапе p3express в основном предлагает работать с рисками:

• Шаг 22. Зафиксировать RICs;

• Шаг 23. Реагировать на RICs;

• Шаг 24. Принять готовые продукты.

Мы их дополнили частью из SCRUMа, введя ежедневные митинги для обсуждения:

• Что сделал вчера;

• Что планируешь сегодня;

• Что может помешать.

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

Закрытие этапа

Вот так это в p3express:

• Шаг 25. Оценить удовлетворённость заказчика и команды;

• Шаг 26. Запланировать улучшения;

• Шаг 27. Фокусированная коммуникация.

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

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

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

Закрытие проекта

По p3express закрытие включает такие шаги:

• Шаг 28. Получить одобрение и передать продукт

• Шаг 29. Передать проект

• Шаг 30. Оценить удовлетворенность заказчика и команды

• Шаг 31. Провести аудит закрытия

• Шаг 32. Извлечь уроки и заархивировать проект

• Шаг 33. Объявить и отметить окончание проекта

• Шаг 34. Фокусированная коммуникация

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

Сессия Скажи спасибо

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

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

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

После проекта

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

• Шаг 35. Оценить полученные выгоды

• Шаг 36. Спланировать дополнительные действия

• Шаг 37. Фокусированная коммуникация

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

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

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

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

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

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

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

Неправильная абстракция

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

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

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

Нарушения связи

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

Проблема этого аргумента в том, что он фокусируется на разделении, но полностью игнорирует потребность в связи между определёнными структурами. Допуская, что все файлы и классы определённого типа в такой системе расположены вместе, справедливо ли будет сказать, что их взаимная связь, как структур одинакового назначения, но разного смысла, нас устраивает? Положено ли все же, к примеру, контроллерам, находиться отдельно от своих классов и репозиториев? Можем ли мы позволить, скажем, всем репозиториям быть сильно зависимыми друг от друга, но отделенными от уровня сервисов? Очевидный ответ - НЕТ! Такой код стал бы хрестоматийным куском г*вна. Рефакторинг такой системы на более мелкие решения был бы абсолютным кошмаром, потому что вам пришлось бы отделить друг от друга все классы на каждом уровне стека. Это убивает основную цель использования стиля MVC.

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

Трудно менять

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

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

Ограничивает выбор дизайна

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

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

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