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

It-компании

Как безопасники боролись с мамонтами, или ИТ- и ИБ 25 лет назад и сейчас

28.07.2020 10:08:24 | Автор: admin
В июне нашей команде и компании исполнилось 25 лет. В юбилей принято вспоминать былое, делать выводы и строить планы на будущее. Но делать стандартное интервью нам не хотелось. Хотелось, чтобы получился разговор двух людей, которые знают сферу ИТ, могут вспомнить олдскульные ИБ-истории и поспорить на тему а вот если бы ось пополам обогнала в свое время майкрософт

Захотели сделали. Алексей Дрозд (aka @Labyrinth) поговорил с Львом Матвеевым, инженером-программистом в прошлом, основателем и владельцем компании СёрчИнформ в настоящем. Разговор получился о том, как зарождалась ИТ-отрасль на постсоветском пространстве, чем нынешние программисты отличаются от вчерашних, о поводах для гордости и уроках неудач.

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

Зарплату на машинное время


image


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

Лев: Да. Чтобы описать, насколько программисты были небожителями, опишу, как мы работали. Компьютер я впервые увидел на первом курсе института в 86-м году. Это был ЕС 1036 с большим зеленым монитором.

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

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

Общались в т.н. бибиэсках. 64 килобита считались очень большой скоростью. Dial-up был страшно дорогой.

Алексей: На чем ты тогда писал?

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

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

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

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

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

Алексей: Не думаю, что все так просто. Как ты заметил, развитие идёт по спирали. Те же гуру остались, но они сейчас работают на другом уровне, уровне собственных баз данных Яндекса, Фейсбука или Гугла

Лев: Да, эти люди остались, но ушло главное. В 92-93-м у нас был свой круг общения, каналы Fido, где сидели профи. Так как нас было мало, мы все друг друга знали, пусть не визуально, не лично, но по бибиэскам, по бибиэсовским конфам.

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

Лев: Не совсем. Бибиэска это компьютер с одним или несколькими модемами, на нем стоит специальный софт. Это по сути сервер, который имеет структуру каталогов. Он передает все на твой компьютер, ты это просматриваешь, потом загружаешь назад.

image


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

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

Не было ни айти, ни ибэ



image


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

Лев: Не было такого названия ИТ вообще! Оно появилось, наверное, во второй половине 90-х, даже к концу 90-х началу 2000-х. Не было и понятия начальник ИТ, не было деления на системного администратора и программиста. Оно появилось позже.
Любой программист, по определению, был грамотным сисадмином, который может все настроить, проложить локальную сеть на 10 мегабит. Сейчас же процентов 80 программистов не знают, как кабель обжать

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

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

Конкурентные программы тогда стоили дорого и были малоэффективными. Их использовали только крупные компании, которые готовы были выделить человека, чтобы тот занимался поиском документов по несколько часов. Для обычного предпринимателя со штатом в 20 человек, которому нужно получить ответ на вопрос за 5-10 минут, это, конечно, не годилось.
Поэтому, наш поисковый движок произвел впечатление на рынок. У тогдашнего главного нашего конкурента компании Регистр было 150 клиентов, в целом рынок оценивали на 300. Моя оценка была совершенно другой 1000-2000 клиентов. А потом в первый же год работы мы получили 500 заказчиков, отобрав еще и половину клиентов у Регистра.

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

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

Он был, условно говоря, вкусной конфетой на развес без достойной упаковки. Так вот инфобез стал для нас этой упаковкой. Разрабатывая DLP, мы снова не стали делать что-то похожее на то, что было на рынке. Если ты предлагаешь еще один велосипед, который может развивать скорость не 25, а 30 км/ч, то это круто, конечно, но капитально не решает задачи человека, которому нужно проезжать быстро по 100 км в день. Ему потребуется машина.
Все игроки рынка работали тогда по принципам царской охранки главное перехватить. Образовывалась огромная мусорка из алертов. Что с ней делать? Только просматривать вручную.

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

Алексей: Получается решили задачу кардинально по-новому?

Лев: Да. На что еще всегда ставили это на оптимизацию по двум направлениям: чтобы DLP была нетребовательной к оборудованию, и чтобы скорость поиска была высокой. Это критично, потому что, если тебе надо раз в день запустить поиск, подождать минуту-три может и нестрашно. А если тебе нужно 50 запросов за день сделать, из минут сложится 2-3 часа. Сейчас движок в 2-3 раза быстрее, чем на старте.

Алексей: А почему все-таки сфокусировался на ИБ в контексте защиты от инсайдерства? Потому что делать очередной антивирус было бы глупо?

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

Алексей: Мы же не были первопроходцами?

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

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

image

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

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

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

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

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

Лев: Честно говоря, не помню. Никогда не было представительства в США, но какой-то номер, наверное, брали. Думали, сейчас выйдем на весь мир. И слава богу, что не стали этого делать. Зайдя на рынок ИБ, увидели, что он необъятен и в России. Я принял решение пока за рубеж не рваться. Это было правильное решение нужно стать 1 дома.

Мы пошли на Запад только три года назад. Главное это первое впечатление, его за деньги не купишь, продукт краеугольный камень. Нужно было отточить наше ПО, ведь в корпоративном секторе ты можешь работать на сотне ПК, но не факт, что развернешься на 500. Сейчас у нас максимальное внедрение на 70 тысяч станций в одной компании. Но до такого результата дошли, что называется, step by step. Многие наши конкуренты из подобных историй уроки не извлекают. У них при внедрении на 100-200 ПК все работает, а ставят на 5 тыс. и все падает. В том числе и репутация. Но это не наш путь.

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

Где поскользнулись


Алексей: Всегда приятнее вспоминать про победы, выстрелившие технологии, а провалы не принято афишировать. Но не верится, что при развитии все было идеально. Может есть примеры того, что не взлетело?

Лев: Самый крупный провал это TimeInformer как отдельный продукт. Мы потратили около 15 млн на разработку, наняли 60 сейлов, которые отработали полгода. Развили активность, потратили ресурсы программистов.

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

Алексей: А были ли провалы по части не маркетинга, а технологий?

Лев: Прямо провалов и крахов не было. Технологии не все одинаково успешно внедряются, но все большую пользу приносят. Например, FTPController не забойный продукт, он для клиентов менее важен, чем MailController. Но это не значит, что его не нужно было разрабатывать, просто приступили к нему позже. Это как при добыче нефти вначале добываешь с поверхности, а потом буришь скважину. Конечно, приятно вспоминать 2007-й год, когда мы перехватили неперехватываемый Skype, но, когда продукт зрелый, каждая новая фича не будет вызывать такой же взрывной эффект.

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

Лев: Если говорить о промахах, вспоминается, как 3 года назад стали писать на Angular. В итоге уперлись в ряд неудобств: высокий порог вхождения, сложная система модулей, от версии к версии они ломают API. Сейчас перешли на Vue.

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

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

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

Но я к этим промахам отношусь философски это опыт, это понимание, куда идти, а куда не стоит.

Откуда деньги


Алексей: Где ты тогда искал деньги на свои проекты? Привлекал от инвесторов?

Лев: На первый бизнес я брал взаймы, потому что денег вообще не было, а нужно было платить рыночную зарплату 5-6 разработчикам. Тогда это было 20 тысяч долларов.

А в СёрчИнформ мы вообще не собирались привлекать деньги, развивались сами. Без крутой прибыли, но детские болезни преодолели, не ломали голову над тем, из каких денег выплатить зарплату. Получилось так, что на нас вышла серьезная питерская компания из финансового сектора, написали, что было бы интересно в нас инвестировать. Это было в июне 2008-го. Я решил: почему не съездить.

Мы начали переговоры, инвестиционный менеджер был достаточно грамотный. Говорит, мы видим, что вы перспективная компания, но вы возитесь в песочнице, вам офисы нужно открывать в разных регионах. Я отвечал, мол, планируем в ближайшие полгода собрать деньги и открыть офис в Питере. Они: чего ждать? Вот деньги и вперед! Сумма и условия предполагались комфортные.

У нас слюнки потекли, что откроем офис там и там, наймем колл-центр, направим деньги на рекламу, на серию конференций Road Show. Все распланировали, я приехал в Питер на финальные переговоры был тот самый черный вторник в августе 1998-го. Говорят: Извините, мы все.

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

Алексей: Сильно отличались условия, которые были до чёрного вторника?

Лев: Да, конечно, потому что после денег на рынке не было. У Альянс РОСНО на тот момент оставалось 42 млн рублей, которые они могли в нас вложить. Это были не лучшие условия, но тогда вливания пошли на пользу компании. Через 4 года в фонде сменился управляющий, и мы выкупили долю за большие деньги, чем рассчитывали. Но в бизнесе спорить и ругаться надо на берегу, а потом соблюдать договоренности, даже если они уже для тебя невыгодны. Мы плодотворно поработали и расстались друзьями.

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

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

Алексей: Может инвесторы просто хотят надуть пузырь, чтобы вернуть свое?

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

Настоящее, или Как не упустить хороший кризис


Алексей: Сейчас говорят, что после пандемии мир никогда не будет прежним. С точки зрения ИБ есть прогноз, что будет? Черчилль же говорил: никогда нельзя упускать хороший кризис. С точки зрения ИБ этот кризис будет хорошим?

Лев: Однозначно хорошим.

Алексей: В чем это проявится?

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

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

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

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

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

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

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

Интервью из мира хостинга Антон Сверщевский из VDSina

03.08.2020 00:21:10 | Автор: admin
В очередной раз с вами Леонид из Поиск VPS. Поздравляю всех с прошедшим днем сисадмина. Сегодня без долгих предисловий проведём интервью с Антоном Сверщевским (vdsina) владельцем хостинга VDSina, одним из основателей Макхост и Евробайт.



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

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

Могли бы вы вкратце рассказать пути развития Макхост и Евробайт?
Макхост отлично себя чувствовал до 2010 года, пока не случился спор с соучредителем. В результате разногласий серверы Макхоста были отключены от электричества, что повлекло за собой уход большей части клиентов и поставило под сомнение дальнейшую судьбу Макхоста. В этот момент был создан отдельный проект Евробайт как запасной аэродром. Макхост смог выбраться из сложной ситуации благодаря качественным услугам. Евробайт тоже чувствовал себя вполне неплохо. В 2014 году стартовала VDSina, и все силы были направлены на её развитие. К тому времени Макхост и Евробайт были выведены на хороший уровень качества, клиентов было достаточно, и я больше не видел дальнейшей надобности своего присутствия в этих проектах, поэтому появилась идея продажи. Сначала Евробайт, затем Макхост были проданы, и мы все силы направили на развитие услуги виртуальных серверов под брендом VDSina.

У VDSina не так давно поменялся формат, и теперь вы позиционируете свои услуги как VPS/VDS для разработчиков?
VDSina предоставляет виртуальные серверы под любые потребности, от тестирования ПО для разработчиков до размещения крупных проектов, одним из наших клиентов является Сбербанк. Совсем недавно мы запустили новую линейку тарифов на серверах последнего поколения с процессорами AMD EPYC 7742.



Клиент может заказать виртуальный сервер с характеристиками вплоть до 128 ядер частотой 3.4 GHz, 512 GB RAM, 4000 GB NVMe, на скорости подключения к интернету 500 Mbit/s и с защитой от DDoS. Данные мы храним на сетевом хранилище с тройной репликацией, состоящем из NVMe дисков Intel.



Крупный клиент может заказать любое количество серверов и организовать внутреннюю сеть между серверами на скорости до 10 Gbit/s.

Как вы выбираете дата-центры, в которых размещаете серверы? Есть ли планы расширить количество локаций?
Выбор дата-центров это основа бизнеса для любого хостинга. Какими бы качественными ни были серверы и команда специалистов, с плохим дата-центром всё будет бессмысленно, поэтому мы выбираем лучшие дата-центры из доступных. В Москве размещаем наше оборудование в DataPro, в Нидерландах в Serverius.



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

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

Как обстоят дела с IP-адресами? Покупаете или берете в аренду?
В своё время мы получили достаточное количество IP-адресов, когда они еще не были в таком дефиците. Но в последнее время приходится покупать с этим тоже проблем нет, если не обращать внимания на цену :)

Что думаете про IPv6? Многим ли нужны такие IP-адреса?
На данный момент IPv6 не так пользуются спросом, как IPv4. Но однажды настанет момент (и желательно, чтобы это случилось побыстрее), когда запасы адресов v4 закончатся, и выбора не будет.

У вас есть API. Насколько этот факт является конкурентным преимуществом? Сложно было разрабатывать такое решение? Многие ли пользуются этим?
API есть у многих серьёзных хостеров. Дело в том, что большинство хостеров сидят на готовых решениях, среди которых самое популярное продукты ISPsystem. VDSina стартовала на ПО от ISPsystem, но мы сразу понимали, что это путь в никуда. Продукты ISPsystem не рассчитаны на большой рост и не позволяют гибко реализовать функционал, который необходим для развития. Мы с самого начала приняли решение создавать своё ПО для виртуальных серверов, и в одну ночь мигрировали все серверы клиентов с продуктов ISPsystem на свою систему (об этом наша первая статья на Хабре). Миграцию удалось провести почти без простоя клиентских серверов, чем мы очень гордимся. API это дополнительная возможность не зависеть от интерфейса панели VDSina. Клиенты используют API для автоматического создания большого количества серверов и управления ими. Некоторые энтузиасты даже пишут боты для Telegram. К слову, в Telegram у нас есть чат, где происходит неформальное общение наших айтишников и всех желающих.

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

Сколько у Вас сейчас работает сотрудников? Расширяется ли штат?
На данный момент у нас работает около 20 сотрудников, большая часть на удалёнке. Команда очень сплочённая и вообще нет текучки. Штат расширяется по мере роста. Недавно мы сделали предварительную поддержку в чате, и теперь требуется больше сотрудников поддержки.

Верифицируете ли вы клиентов? Часто попадаются спамеры? Как от них защищаетесь?
На VDSina максимально простая регистрация и создание виртуального сервера требуется указать только email.



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

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


А как в целом оцениваете рост клиентской базы? Большая текучка клиентов?
Рост клиентской базы и соответственно виртуальных серверов нас, конечно, не устраивает. Но мы стараемся привлекать клиентов интересными предложениями. В этом году запустили линейку Вечных серверов, совсем недавно появилась линейка Эпичных серверов (с процессорами AMD EPYC). В ближайшее время сможем предложить Эпичные серверы в Нидерландах. В начале осени клиентам будет предоставлена возможность гибко сконфигурировать свой сервер выбрать количество ядер, памяти и диска это будет аналог Яндекс.Облака, только более понятный и простой для пользователей. Если говорить про текучку, то многие клиенты пользуются услугами с начала нашего существования, пережили переход с продуктов ISPsystem, и сейчас наращивают количество виртуальных серверов.

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

Лицензия Windows у Вас также включена во все тарифы, кроме самых дешёвых. Переплачивают ли те пользователи, которым не нужна эта лицензия?
Большинство хостеров берут дополнительную плату за лицензию Windows мы же берём это на свой счет. Из-за больших объемов для нас лицензии обходятся дешевле, поэтому в тарифы их стоимость не включаем.

Какие у вас самые популярные способы оплаты?
На первом месте безналичная оплата, затем банковские карты и Bitcoin. Баланс можно пополнить практически любым способом. Значительная часть наших клиентов из Китая, специально для них мы подключили WeChat, а вот PayPal убрали совсем и навсегда, так как данная платёжная система без причин и объяснений заблокировала наш аккаунт с деньгами на счете.

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

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

Напоследок пара неформальных вопросов. Чем занимаетесь, кроме работы, есть ли у вас хобби? Путешествуете? Когда уезжаете в отпуск, получается полностью отдохнуть или стараетесь не отрываться от работы?
Я очень увлечённый человек, хобби занимают большую часть моего времени, но основные компьютерное железо и хостинг. Путешествую много. Обожаю вкусную еду посещаю мишленовские рестораны во Франции, Гонконге, Нидерландах. Работа в интернете никак не мешает путешествиям, сегодня ты можешь работать в Москве, а через 5 часов точно так же в Дубае. В прошлом году купил апартаменты в Дубае, но, по понятным причинам, не получается часто туда летать. Обожаю RC (радиоуправляемые модели) до мавиков летал на Align T-Rex 600. А на чердаке у меня железная дорога, но на неё не хватает времени :)

Какой совет могли бы вы дать пользователям, которые заняты поисками виртуального сервера?
Ищите виртуальный сервер на сайте Поиск VPS, читайте наш блог и блоги других хостеров на Хабре!
Подробнее..

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

07.08.2020 14:13:35 | Автор: admin
image
Хакатон соревнование среди разработчиков для создания цифровых решений в интересах заказчика. Хотя мероприятия такого типа очень популярны в IT-среде, многие талантливые специалисты опасаются участвовать в них. Одна из причин стереотип о гарантированной потере прав на разработанное решение. Развеивает этот миф, а также рассказывает о преимуществах и перспективах состязаний программистов один из победителей масштабного хакатона Евгений Маврин.

Евгений молодой перспективный разработчик. Приняв участие в треке Мегапопис Москва, организованном столичным Агентством инноваций в рамках онлайн-хакатона VirusHack, он в составе команды EGD BAG (вместе с Алексеем Айрапетовым и Анной Коваленко) выполнил лучше остальных задачу по созданию информационного бота для мессенджера ICQ New, который сообщал пользователям о распространении коронавирусной инфекции.

image

Евгений, чем Вы и члены Вашей команды занимались до участия в хакатоне? Где учились, где работали, какие проекты вели? Занимались ли бизнесом?
Мы команда одногруппников. Закончили магистратуру МГТУ имени Н. Э. Баумана по программе Информационные системы и технологии в 2019 году. Все занимаемся программированием, но в разных направлениях. У меня, например, основной стек это С++/Qt, а у Леши (Алексей Айрапетов прим. автора) Java. Помимо основной работы каждый из нас имел свои pet-проекты в разной стадии завершенности (читать заброшенности). В общем, до релиза мало чего дошло. Бизнесом никто из нашей команды ранее не занимался. Но мы участвовали, скажем так, в дружественном фрилансе, когда просто требуется IT-помощь кому-то из знакомых. Благодаря образованию и общим интересам в сфере IT нам не составляет особого труда предложить и реализовать работающее решение практически к любой проблеме.

Первый ли раз Вы принимали участие в хакатоне? Как узнали о треке Мегаполис Москва?
Лично я уже участвовал в хакатоне Aramco Upstream Solutions Technathon 2019 в команде с товарищами из РГУ нефти и газа имени И.М. Губкина, но в тот раз нам не повезло. В команде не случился match среди участников.
О треке Мегаполис Москва узнали от друзей: просто кинули в чат рекламу из какого-то сообщества шарпистов (С# разработчиков). К участию в хакатоне VirusHack подошли ответственно: заранее определились с задачей и примерно распределили обязанности. И это реально помогло.

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

Расскажите о том решении, которое получилось в итоге? Какие инструменты были задействованы для его разработки?
В итоге получился информационный бот, который сообщал пользователям о распространении коронавирусной инфекции.
По геотегу люди могли получать сведения о новых и старых случаях заражения граждан, узнавать адреса ближайших медицинских учреждений и лабораторий для сдачи тестов на COVID-19 и адреса ближайших к ним аптек и магазинов. Также в бот был встроен упрощенный генератор SMS-сообщений для получения электронного пропуска.
Для регулировки вычислительных потоков при написании бота были использованы стандартные инструменты языка Java. Чтобы значительно упростить работу бота, была выбрана API-библиотека от ICQ. Также была решена задача по упрощению развертывания бота в продакшн-среде: зная, что стандартом в корпоративной разработке сейчас является Docker, мы подготовили Docker-образ.
В общем, получился продукт, простой в модернизации и приспособленный к масштабированию.

Что было сложнее всего?
Самым сложным, наверное, было причесать весь функционал бота, чтобы им было удобно пользоваться. Мы реализовали интерфейс таким образом, чтобы пользователь вводил данные текстом только в крайних случаях, как, например, для указания причины оформления разового пропуска (да, еще недавно это было актуально). Все взаимодействие с ботом сводилось к грамотному использованию инструментов самого мессенджера. Возможности ручного ввода команд мы отключили совсем. Вот, кстати, демо-видео бота: https://youtu.be/1xMXEq_Svj8

Вы стали победителем хакатона. Как дальше развивались события?
Мы узнали одну очень полезную вещь как оказалось, правообладателями бота остались мы сами, что меня несколько удивило даже. Я думал, что любой хакатон это, грубо говоря, обмен идеи, рожденной в командном брейншторме, на ценный приз. Но я перечитал соглашение и правила участия и ничего подобного не нашел. Так что другим участникам хакатонов, которые переживают за то, что придется передавать права на свои разработки, хочу сказать, что нет, далеко не факт, что вас обяжут это делать. На хакатоне VirusHack можно было даже код хранить в приватных репозиториях, а одному из членов жюри просто предоставить временный доступ для вынесения решения. В любом случае перед хакатоном всегда читайте документы об участие, чтобы в дальнейшем не было неожиданностей.
Кстати, наш код мы решили оставить открытым: https://github.com/airaketa/egdbag-bot. Форкайте на здоровье.
После хакатона уже по своей инициативе мы подготовили порт бота под API Telegram на случай второй волны пандемии коронавируса. Но лучше пусть этот проект навсегда останется в приватных репозиториях.
Сейчас мы думаем над тем, чтобы адаптировать функционал бота под текущую ситуацию, когда режим самоизоляции снят. Например, для поиска фитнес-центров, ресторанов и других городских объектов. Члены команды ICQ New не против захостить на своих мощностях и обновленную версию бота.

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

В августе стартует прием заявок на новый хакатон для решения задач города Лидеры цифровой трансформации. Его победители получат солидное вознаграждение. Будет ли Ваша команда участвовать в нем? Как будете готовиться? Если победите, на что потратите денежный приз?
Для меня, как и для остальных участников команды, главной целью участия в хакатоне является возможность разработать прототип продукта в рамках интересной для нас области.
Мы получаем опыт коллективной разработки и хороший проект в портфолио, сталкиваемся с интересными и сложными задачами. Конечно же, мы хотим выиграть. Однако мы не нацелены на получение именно денежного приза. Если проект будет приносить пользу это и будет нашей победой.
Для подготовки к конкурсу Лидеры цифровой трансформации мы попытаемся расширить состав команды: в предыдущем хакатоне нас было трое и, честно говоря, рук просто не хватало. Кроме того, мы решим вопрос с установленным ПО, чтобы у всех участников команды до начала соревнования был требуемый набор программ (как показал опыт, огромное количество времени уходит именно на разрешение проблем с синхронизацией ПО).
Если все же удастся получить приз, то потратим деньги на PS5 и засядем по домам на пару недель. Шутка! Конечно же, мы понимаем, что денежный приз это, прежде всего, финансовая помощь для дальнейшего развития проекта. Хостинг, виртуальные машины и так далее это часть того, на что будут распределены финансы.
Подробнее..

Свыше 350 000 серверов Microsoft Exchange уязвимы перед CVE-2020-0688

30.07.2020 10:07:11 | Автор: admin


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

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


В чём проблема


Ещё в феврале 2020 года Microsoft исправила уязвимость CVE-2020-0688, затрагивающую серверы Microsoft Exchange. Этот уязвимость безопасности присутствует в компоненте панели управления Exchange Control Panel (ECP) и позволяет злоумышленникам захватывать уязвимые серверы Microsoft Exchange, используя любые ранее украденные действительные учетные данные электронной почты. Чтобы подчеркнуть важность проблемы, компания добавила пометку уязвимости Exploitation More Likely Эксплуатация очень вероятна, намекая на то, что уязвимость является привлекательной целью для злоумышленников.

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

Непосредственно этап аутентификации, кстати, тоже не является проблемой. Злоумышленники могут пройти её с помощью инструментов сбора информации о сотрудниках компаний через LinkedIn. А затем использовать собранную информацию вкупе с credential stuffing, против Outlook Web Access (OWA) и ECP.

В феврале же специалисты по безопасности предупреждали активном сканировании сети в поисках уязвимых серверов Microsoft Exchange. Для осуществления атаки достаточно было обнаружить уязвимые серверы, найти адреса электронной почты, которые можно добыть через URL-адрес web-клиента OWA или собрать данные из предыдущих утечек. Если злоумышленнику удавалось перейти на сервер Exchange, он мог разглашать или подделывать корпоративные почтовые сообщения.

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

Побурлили и забыли


Но, как это часто бывает, на шумиху обратили внимание не только лишь все (с). Большинство компаний проигнорировали угрозу. Специалисты ИБ-компании Rapid7 спустя пару месяцев использовали свой web-инструмент Project Sonar, чтобы обнаружить все общедоступные серверы Exchange в интернете. И результаты оказались весьма печальными.

Им удалось установить, что по меньшей мере 357 629 (82,5%) из 433 464 серверов Exchange по-прежнему открыты для атак, эксплуатирующих уязвимость CVE-2020-0688.

Некоторые из серверов, помеченные Rapid7 как защищённые от атак, могли по-прежнему быть уязвимыми, поскольку патч Microsoft обновлял не все сборки ОС. Но и это ещё не всё. Исследователи обнаружили почти 11 тысяч серверов под Microsoft Exchange 2007, использовавших ПО End of Support (EoS), чья поддержка прекратилась в 2017 году, и 166 тысяч серверов под управлением ОС Microsoft Exchange 2010, поддержка которой прекратится в октябре 2020 года. Вишенкой на торте стала информация о том, что к интернету подключено почти 31 тыс. серверов Microsoft Exchange 2010, не обновлявшихся аж с 2012 года, а на 800 из них ни разу не устанавливали обновления.



Кто виноват, решим позже. Что делать?


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

Скомпрометированные учетные записи пользователей, которые использовались для атаки на серверы Exchange, можно обнаружить, проверив журналы событий Windows и IIS на наличие частей закодированных полезных данных, включая текст Invalid viewstate или строку __VIEWSTATE и __VIEWSTATEGENERATOR в запросах запросов в пути в каталоге /ecp.

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

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

Версия MS Exchange Статья Патч
Microsoft Exchange Server 2010 Service Pack 3 Update Rollup 30 4536989 Security Update
Microsoft Exchange Server 2013 Cumulative Update 23 4536988 Security Update
Microsoft Exchange Server 2016 Cumulative Update 14 4536987 Security Update
Microsoft Exchange Server 2016 Cumulative Update 15 4536987 Security Update
Microsoft Exchange Server 2019 Cumulative Update 3 4536987 Security Update
Microsoft Exchange Server 2019 Cumulative Update 4 4536987 Security Update

Не забывайте про безопасность. Отсутствие защиты спустя несколько месяцев после выпуска патча это крайне печально.

Что ещё полезного можно почитать в блоге Cloud4Y

Искусственный интеллект поёт о революции
Какова геометрия Вселенной?
Нужны ли облака в космосе
Пасхалки на топографических картах Швейцарии
Победители конкурса стартапов The Europas Awards 2020

Подписывайтесь на наш Telegram-канал, чтобы не пропустить очередную статью. Пишем не чаще двух раз в неделю и только по делу. Кстати, недавно мы провели вебинар на тему расчёта TCO для IT-проектов, где ответили на актуальные вопросы. Если вам интересно велком!
Подробнее..

Модель managed IT как альтернатива аутсорсингу и аутстаффингу. Опыт сервис-провайдера

27.07.2020 16:04:10 | Автор: admin
Мы 11 лет управляем ИТ-инфраструктурой клиентов разного калибра, от крупных компаний до стартапов. Опробовали и разные модели работы в формате time and materials, когда оплачивается не результат, а время исполнителя. Все эти модели, скажем так, неполноценны.




Год назад решили протестировать услугу, которая активно развивается на западе managed services, или managed IT. По-русски: комплексное управление ИТ-инфраструктурой. Компания, которая предоставляет такую услугу, называется Managed Services Provider (MSP).

MSP управляет серверным и сетевым оборудованием, системным и специальным ПО, облачными сервисами. Ещё координирует все ИТ-процессы клиента, включая взаимодействие между подрядчиками. Но лучше это объяснит картинка:

image

Сейчас мы применяем managed IT в трех пилотных проектах, с клиентами из разных сегментов рынка:

  • крупная сеть АЗС в составе нефтяной компании;
  • производитель и дистрибьютор одежды (4 самостоятельных бренда);
  • технологический стартап.


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

Главный вывод: managed IT единственная на сегодня модель предоставления ИТ-услуг, которая выгодна и клиенту, и поставщику, и даже сторонним подрядчикам.


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

Минусы аутсорсинга и аутстаффинга



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

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

Отсюда три характерных минуса аутсорсинга:

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


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

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

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

Managed IT: когда бизнес и айтишники начинают понимать друг друга



Managed IT, или managed services, популярная модель предоставления услуг на развитых ИТ-рынках. Если верить отчету аналитического портала Market Watch, мировой оборот managed services к 2022 году достигнет $250 млрд.

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

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

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


Год тестирования модели выявил и некоторые нюансы. Мы заметили, например, как непросто изменить сознание людей: все понимают, что такое аутсорсинг и аутстаффинг, но в тонкости managed IT вникать особо не стремятся. И это нормально.

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

Кейс 1: сеть АЗС



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

  • Большая инфраструктура: порядка 200 серверов внутри контура + 120 за его пределами. Установлено различное ПО, развернуты test-, prod-, dev-площадки.
  • Множество подрядчиков, которые предоставляют и обслуживают эту инфраструктуру. Подрядчики не очень-то хотят общаться и взаимодействовать друг с другом (да и не должны). Они выполняют свою роль, а технические требования адресуют клиенту, который пересылает запросы другим ответственным компаниям и командам. Так клиент превращается в подобие роутера, что сильно тормозит работу.
  • Разные модели предоставления услуг у подрядчиков: кто-то использует аутсорсинг, кто-то продает софт по фиксированной цене, предлагая поддержку на этот софт и пр. Этим сложным процессом тоже нужно дирижировать.
  • Нет квалифицированного координатора, или единого квалифицированного окна, в котором можно получить рекомендации по каждому типу ИТ-работ. То есть нет того, кто принимает финальное решение и выполняет функцию фасилитатора.


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

Решение



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

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

Трудности



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

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


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

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

Кейс 2: производитель и дистрибьютор одежды



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

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

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

Единая точка отказа



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

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

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

Не все SLA одинаково показательны



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

У нас SLA 99,9%, стандарт для сервис-провайдеров. Но мы предлагаем 99,9% по документам, хотя наш реальный SLA близок к 100%.

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


Меж тем существует немало ИТ-провайдеров, которые занимаются мнимой экономией: покупают железо подешевле например, серверы Supermicro. И это уже совсем другие три девятки.

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

Всё это клиент понял и принял.

Кейс 3: технологический стартап



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

Типичные ошибки стартапов



  • Стремясь сэкономить, стартапы поднимают один сервер и разворачивают на нем всё: веб-сервер, БД, среду разработки, приложения, логирование, мониторинг и так далее. А когда наступает момент роста, компания начинает просто повышать ресурсы сервера увеличивать число CPU и RAM. И этот вертикальный рост всегда больно бьет по кошельку. Если растешь не очень быстро, кривая затрат идет вверх плавно. Но если рост продолжается, эта кривая в какой-то момент резко меняет градус. Экономика перестает сходиться.

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

    Выход: передача функций по управлению и стратегическому развитию ИТ-инфраструктуры сервис-провайдеру.


Наш клиент



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

Что мы сделали:

  1. Предоставили виртуальную инфраструктуру на качественном железе, перенесли ПО на новую инфраструктуру. После этого показатели производительности заметно выросли.
  2. Настроили базы данных, организовали кластер Galera так, чтобы клиент мог масштабироваться и вертикально, и горизонтально.
  3. Предложили отказаться от идеи монолитной инфраструктуры и объяснили, почему важно расти в сторону микросервисов. Рассказали, как это делать.


Заключение



Чем хороша модель managed IT:

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


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

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

БРП с интеллектом

04.08.2020 16:15:07 | Автор: admin

Блоки распределения питания (PDU)


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

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

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

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



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

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

С точки зрения функциональности всю линейку БРП решений можно разделить на три вида:

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

Базовые модели


обычно выполняются в двух видах:

  • В горизонтальном исполнении, занимают 1U, поддерживают 1 или 2 типа разъемов, оснащены выключателями или термопредохранителями. Такие модели обычно востребованы компаниями из сегмента СМБ. Они обычно арендуют несколько юнитов в шкафу и не предъявляют повышенных требований к БРП.
  • В вертикальном исполнении (Zero U), имеют низкопрофильный дизайн корпуса и высокую плотность разъёмов, оснащены автоматами с защитой от случайного отключения и поддерживают разные типы разъемов. Для таких устройств главное это надежное питание для большого количества оборудования (до 42 розеток на борту).



Интеллектуальные БРП


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

Блоки распределения питания (БРП) с мониторингом С3 Solutions реализуют мониторинг потребляемой мощности и параметров окружающей среды. БРП позволяют подключать несколько датчиков разного типа: температуры, влажности, контроля доступа, дымообнаружения, утечки воды



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

Умные БРП могут обеспечивать групповое управление несколькими устройствами (управление такой группой осуществляется через единый WEB-интерфейс с одного IP-адреса) и осуществлять многопользовательский доступ с настройкой политик доступа.



Управляемые БРП поддерживают вышеперечисленные функции мониторинга, но кроме того:
Управляемые Блоки распределения питания С3 Solutions могут использовать несколько сценариев управления. Розетки могут включаться и выключаться по расписанию, в определённой последовательности или по специальному алгоритму. Например, включается розетка А, и только через 1015 секунд розетка Б. Еще один вариант управления с помощью функции Super Ping. В этом случае БРП с помощью своей системы мониторинга постоянно обращается (посылает команду Ping) к определенному сетевому устройству и ждет от него ответа. Если устройство перестает отвечать, то БРП может, например, перезагрузить конкретную розетку.



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

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

Боли стартапов как правильно развивать ИТ-инфраструктуру

14.08.2020 20:16:22 | Автор: admin
Если верить статистике, выживает только 1% стартапов. Рассуждать о причинах такого уровня смертности не будем, это не наше дело. Лучше расскажем, как повысить вероятность выживания с помощью грамотного управления ИТ-инфраструктурой.



В статье:

  • типичные ошибки стартапов в ИТ;
  • как managed IT-подход помогает избежать этих ошибок;
  • поучительные примеры из практики.

Что не так с ИТ у стартапов


Стоит уточнить, что под стартапами мы имеем в виду не кофейню или инсектарий в торговом центре. Мы про технологические стартапы про тех, кому не дает покоя успех GitHub, Uber, Slack, Miro и пр.

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

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

Люди в стартапе делают то, что не умеют


И не делают то, что требуется для развития стартапа. Поясним.

В каждом стартапе должны быть закрыты как минимум три роли:

  • айтишник (или технолог);
  • продавец (или маркетолог);
  • визионер (или предприниматель, который еще и нередко инвестор).

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

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



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

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

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


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

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

Как помогает managed IT


Для такого типа проектов у нас есть услуга класса managed services managed DevOps.

Заказчик получает из коробки:

  • подготовку необходимых сред для работы: dev, test, prod;
  • настроенные процессы CI/CD;
  • подготовленный инструментарий для командной работы: таск-трекеры, системы контроля версий, деплоя, тестирования и пр.

На уровне инфраструктуры и инструментов всем стартапам нужно примерно одно и то же. Если сравнить венчурный рынок с золотодобычей, Managed Services Provider (MSP) предоставляет новые, качественные инструменты: кирки и тележки, которые не ломаются, карты, которые не врут. Старателю остается только выбрать место, где копать.

Плюсы managed IT


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

  • На старте мы даем необходимые и настроенные ресурсы для работы, роста и проверки гипотез.
  • Точно можем сказать, как будет увеличиваться стоимость при масштабировании, потому что знаем, что ключевая метрика сходимость экономики стартапа.
  • Консультируем, чтобы сэкономить стартапу значительное количество человеко-часов. Также можем помочь с расчетами юнит-экономики проекта.
  • Делимся best practices рынка. Люди в ITGLOBAL.COM, работали с немалым количеством стартапов. Многие из этих стартапов на ежемесячном обслуживании. Это позволяет нам собрать воедино лучшие (и худшие) примеры и делиться опытом с клиентами.

Два случая из практики


По NDA мы не можем называть конкретные компании, но сферу и продукт да.

Сфера: финтех/ритейл

Продукт: маркетплейс

Проблемы:

  • В цепочке CI/CD отсутствовало тестирование. Добавление удаленных тестировщиков только усложнило процесс сборки.
  • Разработчики работали одновременно на одном dev-сервере без выделенных сред в контейнерах.
  • 70% времени разработчиков уходило на одни и те же действия из релиза в релиз. Скорость разработки была очень медленной.
  • Инфраструктура была развернута на лоукостер-хостинге в Германии (т. е. ни скорости, ни надежности).

Такое, к слову, наблюдается в каждом первом проекте.

Решение managed DevOps: внедрили процессы CI/CD, настроили корректное тестирование и мониторинг, вмешались в разработку на уровне бизнес-процессов, перенесли инфраструктуру на производительные серверы в дата-центр уровня Tier III.

Результат:

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

Сфера: веб-реклама

Продукт: ИИ-платформа для автоматизации рекламных кампаний

Проблемы:

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

Решение managed IT: перенесли инфраструктуру на топовое железо, настроили кластер Galera для горизонтального масштабирования, показали, как будет распределяться нагрузка на ВМ, настроили бэкапы и мониторинг. Сейчас, кроме обслуживания, активно консультируем, в том числе по DevOps.

Результат:

  • инфраструктура стала микросервисной: стоимость расширения значительно снизилась, а возможности по масштабированию, при тех же затратах, выросли;
  • увеличилась надежность и безопасность инфраструктуры;
  • разработчики перешли с каскадной модели сборки на CI/CD, что помогло снизить издержки;
  • финансовая выгода от managed IT, по данным клиента, стала очевидной сразу.

Заключение


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

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

Простые средства информирования внутри компании

14.08.2020 16:23:02 | Автор: admin
Всем снова привет!

Вроде бы еще не так давно я рассказывал, как выглядит обмен знаниями в Exness глазами новичка, и вот уже снова есть, что рассказать!

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

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

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

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



У нас в компании никто ничего вовремя не узнаёт...


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

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

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

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

Кому реально надо, тот и так узнает!


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

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

Более того, бывают такие ситуации, когда вы лучше знаете, кого аффектит планируемый апдейт. А если человек даже не подозревает, что вы готовите что-то, что может изменить его business as usual, как он должен предугадать ваши действия?

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

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

Это все долго и сложно. Лучше фичи быстрее пилить!


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

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

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

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

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

Куда писать? Чем пользоваться?


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

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

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

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

Так а сами-то вы что делаете?


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

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



Блог базы знаний и Blog Yellow Pages


Все знают, что в каждом спейсе Confluence есть такая сущность, как Блог? А кто из вас им пользуется?

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

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

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

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

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

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

Мы назвали этот ресурс Blog Yellow Pages, и теперь любой заинтересованный в конкретной теме сотрудник может зайти и посмотреть последние новости по интересующей сфере бизнеса или продукту.

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

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

Ежемесячный почтовый дайджест




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

В Exness почта использовалась мало. Вероятно, так сложилось исторически. Но никто не мешал (и не мешает сейчас) нам поработать над ее оживлением.

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

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

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

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

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

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

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

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

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

Онлайн-встречи с экспертами




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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В общем, добавляйте мероприятиям интерактива, и будет получаться не хуже, чем в офлайне!

А дальше что?


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

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

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

Не хотим knowledge managera! Что делать?


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

Итак, кто может заменить вам менеджера по управлению знаниями?

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

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

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

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

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

28.07.2020 18:07:12 | Автор: admin
image

Содержание


Введение. О чем эта статья
Цели и дисклеймеры
Часть 1. Хороший продукт
Часть 2. Пользовательский опыт (UX). Что это?
Часть 3. Архитектура выбора
Часть 4. Архитектор выбора
Часть 5. Когнитивные искажения и Пользовательский опыт
Ссылка на полную версию UX CORE (105 примеров использования когнитивных искажений в менеджменте команд и продуктов)
Часть 6. Наши дни
Часть 7. Не только искажения
Часть 8. Эпилог
Часть 9. Материал, качественно дополняющий эту статью

Введение. О чем эта статья


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

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

В какой-то момент своей жизни я перепрофилировался из технического специалиста в IT-сфере, коим я проработал около 6 лет (LAN/WAN/DevOps/InfoSec), в Product Manager-а. Моей основной деятельностью на этой должности является анализ ожиданий и принятых решений пользователей с целью создания более комфортного и желанного продукта.

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

Цели и дисклеймеры


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

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

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

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

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

Часть 1. Хороший продукт


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

Итак, чуть выше я убрал вопросы про рынки, конкурентов и целесообразность продукта, потому что я исхожу из того, что качественный продукт это, прежде всего, продукт без внутренних противоречий. Такой продукт идеально связан как идеологическими его составляющими (история создания, его миссия, все использованные изображения, текстовые и печатные материалы используемые для его разработки и продвижения и прочее), так и техническими (back end, пользовательский интерфейс, элементы взаимодействия и дизайн, бизнес цвета, инструкции для работы службы поддержки клиентов, tone of voice of the company и много другого).

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

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

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

Часть 2. Пользовательский Опыт (UX). Что это?


Так как на данный момент понятие UX гораздо чаще относят к UI дизайну, моим оппонентом в обсуждении данного вопроса будет Джо Натоли. Джо ветеран-дизайнер с опытом работы более 30 лет, один из самых популярных в мире IT экспертов по UXD (User Experience Design), автор ряда книг, а также самых популярных видео-курсов по UX на Udemy. Натоли провел более тридцати лет консультируя по вопросам дизайна пользовательского опыта (UXD) компании из списка Fortune 100, 500 и правительственные организации. На своем вебсайте он называет себя User Experience Evangelist, значит, я могу ссылаться на его утверждения, высказанные публично в его книгах и видеоуроках.

В одном из своих уроков, где господин Натоли объясняет понятие User Experience, он ссылается на Питера Мерхольца:

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

Другой UXD эксперт Билл ДэРушэ (Старший продакт менеджер / Workflow Experience Lead at Zendesk). В обсуждении UXD говорит следующее: Для UXD даже не нужен экран. UXD это любое взаимодействие с любым продуктом, любым элементом, любой системой .

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

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

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

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

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

Часть 3. Архитектура Выбора


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

Касс Санстейн со-автор теории подталкивания. После выхода книги Подталкивание президент Обама предложил Санстейну место в Отделе информации и регуляторной политики. Это дало исследователю широкие возможности внедрять идеи психологии и поведенческой экономики в работу правительственных учреждений. 10 сентября 2009 года Санстейн был назначен на пост главы OIRA, которое является частью Административно-бюджетного управления Администрации президента. OIRA осуществляет надзор за реализацией государственной политики и рассматривает проекты нормативных актов. Пост главы OIRA считается одним из наиболее влиятельных, учитывая его возможность влиять на тексты принимаемых законов. СМИ неофициально называют этот пост regulatory czar. OIRA Санстейн возглавлял до 21 августа 2012 года.

В августе 2013 года Санстейн вошел в состав комиссии по надзору за АНБ (англ. Review Group on Intelligence and Communications Technology). Кроме него в комиссии еще два бывших работника Белого Дома: крупейший специалист по контртерроризму и кибервойнам Ричард Алан Кларк и бывший заместитель директора ЦРУ.

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

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

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

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

image

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

Часть 4. Архитектор Выбора


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

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

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

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

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

Часть 5. Когнитивные Искажения и Пользовательский Опыт


Итак, мы дошли до основного материала статьи.

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

Для структурирования материала я использовал Кодекс когнитивных искажений, категоризированный и структурированный Бастером Бэнсоном в 2016м году (по ссылке выше дизайн Джона Манукяна III). Помимо новой формы презентации искажений, к каждому из них я добавил пример использования в разработке программного обеспечения, а в некоторых случаях- в управлении командой. Были учтены самые современные практики по управлению командами и компаниями (PMP, PMI ACP), а также разработке продукта.

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

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

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

  • Работа с большим объемом данных. Когда много информации;
  • Расплывчатость, недостаточность данных. Когда не хватает смысла;
  • Недостаточно времени. Когда быстро реагируем;
  • Разные приоритеты по информации. Когда запоминаем и вспоминаем.

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

#1 Эвристика доступности [P]
Процесс, при котором человек оценивает частоту или вероятность события по легкости, с которой примеры или случаи приходят на ум, т.е. легче вспоминаются.

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

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

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

#4 Эффект знакомства с объектом [P]
Психологический феномен выражения симпатии к объекту только на основании имеющегося знакомства с ним. Чем чаще человек видит кого-то, тем приятнее и привлекательнее ему кажется этот человек.

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

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

#6 Забывание без подсказок [P]
Является неспособностью вспомнить воспоминание из-за отсутствия стимулов или сигналов, которые присутствовали во время кодирования памяти.

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

Приведу простой пример на онлайн тотализаторе, где множество пользователей делают ставки. Очевидно, что средний пользователь как выигрывает, так и проигрывает. В интересах бизнеса правильно будет поддержать такого пользователя в тот сложный момент, когда он все проиграл. Так как в сознании игрока, который пережил серию поражений одни поражения, система может напомнить ему о целом ряде побед по некоему паттерну, оживив в нем всю ту серию хороших воспоминаний, которые он испытал. Это может быть сделано ненавязчиво, сообщением типа Уважаемый %username%, мы просто хотели напомнить вам о невероятно успешной серии ваших побед, продлившейся три дня подряд на играх %game_names%. Навязчиво? Возможно. Изменим сообщение на Вы попали в топ 20% наших игроков, благодаря вашей серии побед в %game_name%!. Уже не так навязчиво, это уже статистика . Конечно, делать это не этично с точки зрения морали. Поэтому букмекерские конторы и казино, работающие под лицензиями Malta Gaming Authority (MGA), Кюрасао и других, заранее соглашаются, что не будут подталкивать игроков к острым азартным действиям. В любом случае, приведенный пример наглядно иллюстрирует как можно извлечь пользу для бизнеса, зная о такой простой ошибке нашего мозга.

#11 Ошибка базового процента [P]
Это ошибка в мышлении, когда сталкиваясь с общей информацией о частоте некоторого события (базовый процент) и специфической информацией об этом событии, человек имеет склонность игнорировать первое и фокусироваться на втором. Например: люди верят показаниям теста, сигнализирующем о наличии редкой болезни, сразу, не принимая во внимание, что редкая болезнь, вообще говоря, редкая. Либо другой пример: страх террористов и полетов на самолете. Суть в том, что наш мозг склонен преувеличивать частный случай в ущерб статистике.

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

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

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

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

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

#13 Эффект юмора [P]
Смешные вещи легче запомнить, чем не юмористические, что может быть объяснено увеличенным временем когнитивной обработки, чтобы понять юмор, или эмоциональным возбуждением, вызванным юмором.

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

Здесь очень важно понять, что речь идет о запоминании юморных вещей, но не о позитивном отношении к ним. Так, если в процессе работы над важным действием (заполнение формы, сохранение данных), пользователь попадает на страницу ошибки (500 (Internal server error), 502 (Bad gateway), 503 (Service unavailable), 504 (Gateway timeout) ), то юмор типа Хо хо! Наши пираты работают над ошибкой и скоро все будет восстановлено! будет не к месту. В этом случае юмор будет замечен, запомнен, и, вероятнее всего, вызовет гнев пользователя так, что это событие запомнится лучше. Если подобное событие произойдет несколько раз за месяц, в соответствии с эвристикой доступности, в следующий раз подумав о качестве нашего продукта пользователь с высокой вероятностью даст негативную оценку. Даже если в 99% случаев приложение справлялось с задачей (ошибка базового процента).

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

#21 Ошибка различения [P]
Это тенденция рассматривать два варианта как более отличительные при оценке их одновременно, чем при оценке их отдельно.

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

#36 Пренебрежение вероятностью [P]
Когнитивное искажение, согласно которому человек склонен к игнорированию малых вероятностей при принятии решений в условиях неопределенности. Небольшие риски обычно либо полностью игнорируются, либо сильно недооцениваются. Континуум между крайностями игнорируется. Как объясняет Рольф Добелли, причина, по которой это происходит, заключается в том, что мы не обладаем интуитивным пониманием риска и поэтому плохо различаем разные угрозы. По сути, чем более серьезна угроза и эмоциональнее тема (напр. Радиоактивность), тем менее обнадеживающим представляется снижение риска.

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

К примеру, зная что наши пользователи игнорируют вероятность полной потери данных, мы можем подтолкнуть их к созданию бэкапов сообщением вида Уважаемый %user_name%, в последний раз вы создавали бэкап ваших данных 571 день назад. Мы настоятельно рекомендуем создать бэкап чтобы избежать риска полной безвозвратной потери ваших данных.. Здесь мы ничего не говорим о вероятности потери. Она могла постоянно быть равной 0.1%, но написав сообщение с призывом к эмоциям (полной безвозвратной потери ваших данных) и конвертируя условные 19 месяцев в 571 день, мы с большей вероятностью добьемся действия пользователя (бэкап системы).



Ссылка на полную версию UX CORE (105 примеров использования когнитивных искажений в менеджменте команд и продуктов)


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

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

В завершении, я бы хотел рассказать об ошибке GI JOE задокументированной профессором Лори Сантос буквально несколько лет назад. Ошибка касается широко распространенного утверждения, что знать это уже пол дела, что, однако, не имеет научных оснований и является ложным утверждением. На самом деле, одного лишь знания недостаточно, чтобы изменить модель нашего поведения. Настоящие перемены невозможны без наших целенаправленных действий. Вы можете выучить наизусть все когнитивные искажения и механизм их работы, но, если вы не меняете модель своего поведения под полученными знаниями, ценность ваших знаний снижается. Более того, подобное знание не будет крепким, вам придется регулярно возвращаться к таблице и повторять написанное, чтобы не забыть. Если же вы не только поймете, но и предпримите определенные действия для усвоения материала, изменения вашего образа мыслей, вашей жизни, тогда самые лучшие решения по продукту, удивительным образом станут для вас крайне очевидными.

Часть 6. Наши дни


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

На данный момент, взглянув на рынок и на требования к продакт менеджерам лучших компаний, можно обнаружить описания и опросники, на которые ответит почти каждый, кто прошел PMI-ACP. По сути, отсутствие четкого понимания роли Product Manager-а приводит к тому, что на них вваливаются обязанности Project Managerов, Scrum Master-ов, и других.

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

Полагаю, с США дела обстоят лучше, т.к. развитие продакт менеджмента идет именно оттуда.

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

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

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

Часть 7. Не только искажения


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

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

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

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

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

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

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

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

Без внимания к деталям, невозможно добиться высокого качества.

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

Часть 8. Эпилог


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

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

Попробую объяснить иначе. Вне зависимости от идеологической составляющей вашей жизни, вашего стиля и публичного образа, вы можете в любой момент записаться на курсы по SCRUM, изучить этот фреймворк, почитать о нескольких других, понять идеи Agile и устроиться работать проект менеджером в какую-то компанию. Вы также можете пройти пару онлайн курсов и подтянуть ваши знания по front-end и back-end программированию, понять принципы работы баз данных, и это займет у вас буквально месяц. Еще за месяц вы можете сами выучить HTML и CSS, поиграть с разметкой, собрать несколько макетов и понять общую идею работы Javascript.

По сути, вы можете месяца за три собрать достаточно знаний для понимания технической составляющей проекта, и этого более чем хватит для начинающего продакт менеджера. Для понимания трендов вы можете скачать самые последние приложения, пройти по списку самых популярных онлайн платформ, зарегистрироваться на producthunt, betalist, techcrunch и всегда быть в курсе происходящего. Новостной информационный пробел легко восполнить регулярно читая Google News и hackernoon.

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

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

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

Завершить статью я хочу провокационной мыслью.

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

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

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

Большое спасибо за проявленный интерес.

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

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

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

Часть 9. Материал, качественно дополняющий эту статью


  • Даниел Канеман Думай медленно Решай быстро;
  • Николас Нассим Талеб Черный Лебедь;
  • Касс Санстейн и Ричард Талер Подталкивание;
  • Ричард Дэвидсон Как эмоции управляют мозгом;
  • Михай Чиксентмихайи Поток;
  • Джим Коллинз От хорошего к великому;
  • Jesse James Garrett The Elements of User Experience (2nd Edition);
  • William Lidwell Universal Principles of Design;
  • James Clear Atomic Habits;
  • Erin Meyer The Culture Map;
  • Joe Natoli UX Design Fundamentals Udemy Video;
  • Joe Natoli UX & Web Design Master Course: Strategy, Design, Development Udemy Video;

Эта статья была написана в период объявленного карантина из-за пандемии коронавируса (COVID-19) в Армении, г. Ереван. Я очень рад, что статья оказалась полезна многим людям, которые успели ознакомиться с разными частями написанного материала в период моей работы над ней.

Оригинал статьи
Английская версия

По любым вопросам и предложениям пишите, буду рад помочь: alexanyanwolf@gmail.com / www.linkedin.com/in/alexanyan / www.facebook.com/AlexanyanWolf
Подробнее..

Госдепартамент США создаст свой великий файерволл

10.08.2020 18:20:12 | Автор: admin
Госсекретарь США Майк Помпео объявил план создания чистой сети, который предполагает комплексный подход к защите частной жизни граждан и наиболее конфиденциальной информации компаний от агрессивных вторжений злоумышленников. Документ предусматривает запрет китайских приложений, провайдеров и облачных сервисов, а также защиту подводных коммуникаций. Как программа будет реализована технически непонятно. Но сама идея очень похожа на китайский (Великий файервол) и российский (Чебурнет) аналоги.



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

Проект Чистая сеть включает шесть основных инициатив.

  1. Чистый оператор. Запретить подключение к американским телекоммуникационным сетям ненадёжным операторам из КНР. Они представляют угрозу национальной безопасности страны, а потому не имеют права предоставлять международные телекоммуникационные услуги в США и из США. Под угрозой оказывается крупнейший китайский мобильный оператор China Mobile, который может потерять доступ к американским сетям и не сможет предоставлять своим абонентам роуминг на территории Америки.
  2. Чистые магазины. Удалить из американских магазинов приложений ненадежных приложений, разработанных китайскими компаниями (привет TikTok). Приложения, созданные в КНР, угрожают конфиденциальности данных американцев, распространяют пропаганду и дезинформацию, содержат вирусы. Под угрозой китайские компании-разработчики популярных во всём мире приложений. Единственный выход для них продажа проекта американским владельцам, как это может произойти с детищем компании ByteDance. Опасность нависла не только над TikTok, но и над WeChat, Likee и Zynn, весьма популярных в США (да и в России) приложениях.
  3. Чистые приложения. Запретить ненадёжным производителям смартфонов из КНР предварительно устанавливать или делать доступными для загрузки американские приложения. А законопослушным компаниям следует удалить свои приложения из магазина приложений Huawei, чтобы быть уверенными в том, что они не сотрудничают с нарушителями прав человека. Это один из самых жёстких пунктов в плане мер, затрагивающий интересы Xiaomi, Oppo, Vivo и других китайских производителей смартфонов (а на их долю приходится около трети от общего объёма рынка).
  4. Чистое облако. Исключить хранение и обработку важной личной информации граждан США и наиболее ценной интеллектуальной собственности американского бизнеса, включая исследования по вакцинам против коронавируса, в облачных системах, работающих с Alibaba, Baidu и Tencent. Китайские облака в США имеют не очень сильные позиции, но многие работающие в США китайские компании работают именно с ними.
  5. Чистый кабель. Предотвратить использование подводных кабелей, соединяющих США с глобальным интернетом, для сбора разведывательной информации спецслужбами КНР. В целях защиты своих интересов США также намереваются сотрудничать с другими государствами, совместно контролируя подводные кабели по всему миру.
  6. Чистый путь. Этот пункт плана, анонсированный Помпео, не был раскрыт. Поэтому можно только догадываться, что имели в виду американские законотворцы. Но вряд ли что-то хорошее и доброе. Поэтому за дальнейшим развитием событием внимаьтельно следят далеко за пределами Америки слишком много интересов замешано в противостоянии США и Китая.

Мем, популярный сейчас в США


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

Что ещё интересного есть в блоге Cloud4Y

Искусственный интеллект поёт о революции
Какова геометрия Вселенной?
Свыше 350 000 серверов Microsoft Exchange уязвимы перед CVE-2020-0688
Пасхалки на топографических картах Швейцарии
Победители конкурса стартапов The Europas Awards 2020

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

Нишевые кейсы для телефонии с подключением Виртуальной АТС

05.08.2020 10:11:24 | Автор: admin

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

Кейс 1. Торговая компания с оптовым отделом и интернет-магазином


Задача:

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

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

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

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

На сайте компании установлен виджет обратного звонка, привязанный к ВАТС, клиенты заказывают обратный звонок, и менеджеры им перезванивают.

Кейс 2. Несколько разных бизнесов и филиальная структура


Задача:

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

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

При звонке на номер магазинов клиенту предлагают выбрать, с каким магазином соединить: Для соединения с магазином на проспекте Славы, 12 нажмите 1, для соединения с магазином на ул. Ленина, 28 нажмите 2.

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


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


Задача:

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

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

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

Кейс 4. Обработка заявок населения со стороны администрации города


Задача:

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

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

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


Задача:

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

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

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

Кейс 6. Небольшой салон красоты. Один секретарь принимает все звонки и записывает всех клиентов в CRM YCLIENTS


Задача:

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

Компания подключила ВАТС МегаФона с городским номером. На номере установлено приветствие: Здравствуйте, вы позвонили в лабораторию имиджа. После этого звонок попадает секретарю на телефон.

Так как настроена интеграция с YCLIENTS, при каждом звонке на экране компьютера секретаря всплывает карточка клиента с именем и прочими данными. Еще не сняв трубку, секретарь знает, кто звонит, а также может понимать, с каким вопросом. А если клиент звонит впервые, в CRM YCLIENTS автоматически создается карточка клиента и заказа.
Особенность звонков в салон красоты в том, что иногда за час нет ни одного звонка, а иногда сразу несколько одновременно. В настройках ВАТС секретарь заведен как единственный сотрудник в отделе, поэтому если секретарь разговаривает, клиенты встают в очередь ожидания ответа менеджера и слушают музыку. Если секретарь долго не отвечает, на 20-й секунде клиенту предлагается нажать 1 и заказать обратный звонок. Как только секретарь заканчивает разговор, ему автоматически поступает вызов. Сейчас вы будете соединены с абонентом, слышит он в трубке, после чего Виртуальная АТС дозванивается до клиента.

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

Кейс 7. Автосервис с магазином и автомойкой


Задача:

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

У компании много направлений деятельности: ремонт автомобилей, техническое обслуживание, магазин автозапчастей, мойка. Подключена Виртуальная АТС с городским номером. Позвонив на номер, клиент слышит приветствие, после чего попадает в голосовое IVR-меню, где ему предлагают выбрать, по какому именно вопросу он звонит: Для соединения с автосервисом нажмите 1, с автомойкой 2, для соединения с оператором оставайтесь на линии. Звонки попадают на мобильные телефоны соответствующих подразделений. Круглосуточно работает только автомойка, поэтому в нерабочее время звонки сразу направляются туда.

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

Кейс 8. Риелтерское агентство


Задача:

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

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

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

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

Кейс 9. Рекламное агентство на цокольном этаже


Задача:

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

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

Кейс 10. Использование SMS

Отдельно опишем несколько кейсов использования SMS-визиток и SMS-извинений.

Задача:

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

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

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

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


Перейдем к выводам


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

Больше информации о том, как работает Виртуальная АТС МегаФона, можно получить в Базе знаний.
Подробнее..

Топ самых важных функций Android для слепых мнение незрячих экспертов

05.08.2020 18:06:10 | Автор: admin


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

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

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

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

Как включить программу экранного доступа?


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

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

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

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

В смартфонах, работающих на операционной системе Android, по умолчанию их может быть две TalkBack (на большинстве устройствах) и VoiceOver (на смартфонах компании Samsung и некоторых других). Соответственно, команда Google Ассистенту будет звучать так: включи толк бэк. Или так: включи войс овер.

Есть ещё один способ для телефонов, производства Samsung. На смартфонах этой марки можно зажать кнопку питания на 5 секунд. Обычно эта кнопка расположена на правом или левом торце устройства и служит для включения и выключения дисплея и самого телефона. Через 5 секунд раздастся звук входящего сообщения. После этого приложите два пальца к экрану примерно на 2 см ниже динамика и удерживайте их в таком положении 7 секунд. При этом пальцы должны располагаться друг от друга на некотором расстоянии оставьте между ними хотя бы 1 см.

Как переозвучить непонятную фразу?


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

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

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

Как скопировать последнюю фразу в буфер обмена?


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

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

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

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


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

Как настроить озвучку текста?


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

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

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

Эта функция доступна только для операционной системы Android версии 6 и более новых.

Как отключить программу экранного доступа?


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

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

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

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

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

Рынок соискателя или работодателя VS возрастная дискриминация

05.08.2020 10:11:24 | Автор: admin
image


В продолжение моего разбора полётов по рекрутингу и обстановке в последние лет 5, я хочу затронуть две щекотливые темы:
чей же рынок нынче, кто правит балом работодатель или соискатель;
пресловутый возрастной ценз 45+, так ли всё плохо и безнадёжно.
Собственно, про эти вещи и пойдёт дальнейший разговор. Устраивайтесь поудобнее, будет много инсайда.
Две вышеуказанных темы очень близки друг другу и постоянно пересекаются в быту. Одно порождает другое.

Так кто же заказывает музыку нынче? Рассмотрим подробно основные сферы.

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

Рабочие специальности (строители, инженеры, разнорабочие) все, кто работают руками так сказать. Кто мог, уже давно скатали заграницу в поисках успешной жизни, но там не так всё гладко. Отношение скотское ибо те же поляки, немцы, чехи едут работать в более цивилизованные страны и на более комфортную работу. Наши живут в плохих условиях, лучшие должности и работа таки достаётся местным. Многие знакомые, разочаровавшись, возвращаются и зарабатывают почти те же деньги на стройках, только у себя дома.
Хороший строитель на вес золота, согласен. Я управлял HR отделом, где сотрудница занималась поиском сугубо рабочих на Польшу. Найти кого-то в той же Украине почти нереально. 90% откликающихся алкоголики. Все толковые уже давно сами уехали. Тут счёт сравнялся, 1 -1

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

Топ-менеджмент, СЕО и прочие важные дяди-директора.

image


Тут резкая просадка и гол в девятку работодателю. Ловля крупной рыбы это дорогие снасти, нетривиальные скиллы и все вот это.
На опыте, что бы отобрать того же директора компании или хотя бы зама приходиться разгребать тонну мусора ибо у нас все хотят руководить. Поэтому, только ручками, только точечный поиск. Процессы собеседований проходят необычно (мы еще вернёмся к этому особенно, когда будет речь про IT), приходиться выгуливать таких кандидатов, вести под прицелом. Иногда доводилось брать измором несколько месяцев, в этом и прелесть headhunting.
Тут работодатель сливает со свистом, какой крутой он бы ни был. Ситуация смешная: соискателей вроде бы много, а вот перцев 5%. Все подходящие на 90% нормально себя чувствуют и их приходиться буквально воровать у компаний. Опять ничья, 2 2!

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

image


Не буду повторяться о тупости и подкатах моих коллег, кто хочет, сможет прочитать это в моей предыдущей статье. Тут мы рассмотрим, кто сильнее и кто диктует условия. Правильно разработчики. Вы скажете, так чувак, ты прямо КО это же очевидно. Оно так, но тонкости, господа, тонкости.
Бум разработки захлестнул страны бывшего СНГ. Начался движ. Топов сразу похантили топы (Google, Amazon и прочие), остальных разобрали ребята поменьше. Спрос возрастает с каждым днём. Нет, с каждым часов. Многие кинулись на курсы и пофиг то, что Вася гуманитарий, он сможет стать королём Java, конечно.
Мы ранее обсуждали, почему же так стелятся эти бедные девочки-рекрутёры, умоляя вас выйти на связь и придти к ним на печеньки (поубивал бы за такие вакансии, но они есть).
Всё потому, что катастрофически мало свободных агентов. Даже джун найдёт САМ себе применение на 700$-1500$, я уже не говорю про мидлов и сеньоров. В век развития Интернета и мощного нетворкинга, он через час после того, как возьмёт диплом уже трудоустроен. Да, не в обиду будет сказано, и среди вашего брата есть не ахти какие спецы, но речь не об этом, они уходят в пайку транзисторов на Горбушку или радиорынок.
Поэтому, бедные рекрутёры и не знают, с какой стороны подойти, что бы завлечь разработчика. Были случаи (Украина), что рекрутёры приезжали под офис сами на собеседование к будущему кандидату, ибо тот был занят и не мог приехать. Есть и такое. Тут однозначно полный разнос работодателя и 3 2 в пользу соискателя!

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

Что же происходит в странах бывшего СНГ и почему 40 45+ ты уже старпёр и сбитый лётчик.

image


Наш шарик с каждым десятилетием крутится всё быстрее и я не про астрономию. Все бизнес-процессы, взаимодействия, принятия решений, технологии все летит. Современный бизнес требует специалиста-осьминога, ловкого и сообразительного. СССРовские стандарты мудрого инженера уже только в историях, рождённых в 60 70е. По моему мнению, в связи с этим и вырисовалась модель золотой возрастной вилки 21 35 лет. Совсем зелёными легко управлять, проще научить, чем переучить, человек вникает и растёт вместе с компанией и т.п. Но, увы и ах, вот эти самые молодые дарования не имеют того качества знаний, которое было во время отсутствия Интернета и вот этих всех Википедий. Сейчас доступность к граниту науки на поверхности, а желания к её познанию куда меньше. Вот вам пример и с рекрутёрами, которые вам выносят мозг. Это новое поколение, встречайте.
Да, несомненно, есть много талантливых молодых специалистов, но их куда меньше, чем еще каких-то 10-15 лет тому назад. Народ тупеет, как бы грубо и очевидно это не звучало.
И что же со старичками, с этими пенсионерами в 40-45 лет? Почему они уже неликвидные в большинстве своём? Все просто. Обычно, люди в этом возрасте уже знают себе цену. Их не мокнёшь в лужу как щенят. Ими сложнее руководить (ибо 70% уже были/есть руководителями). Переучить также тяжело, Но это не значит, что все, крест на человеке. Если мы возьмем западную модель, то там человек после 30-40 лет только начинает жить профессионально.
Кстати заметка про рекрутёров США. Индусов там 80% и они схожи с нашими рекрутёрами вредителями, а вот коренных 20% и они более креативны. Задают нешаблонные вопросы.

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

image


В нише IT все немного иначе. Опять история из личного опыта.
Есть одна известная украинская компания, более 20 лет на рынке. Так вот, у них в штате есть разработчики 50+ и с них сдувают пылинки. Почему? Да потому, что когда все начиналось в далёкие 2000е, они поднимали все на древней основе. Компания прогрессирует, развивается, но остались еще вещи, которые помнит и знает только Василий Петрович в куртке с квадратными карманами. Его ценят и уважают.
Да, в IT все течёт, развивается и меняется. Надо держать руку на пульсе, мозг 24/7. Но если ты нишевик, например, и работаешь в своём узком пространстве, получая комфортные деньги можешь работать хоть до 100 лет, пока сахар в крови ок.
Тенденция такова, что именно в нише IT сейчас наивысший голод и потребность специалистов. Поэтому, я думаю, возрастные рамки тут не имеют таких жестких критериев, как у обычного продажника сантехники или инженера-проектировщика, где Ревит для него в 50 это сродни сюрреализму. ITшников отслеживают с 1х курсов ВУЗов и до бесконечности. Многие мои коллеги складируют резюме джунов на будущее, ибо когда он станет мидлом или сеньором то уже искать будет не он, а его

image


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



На правах рекламы


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

Подробнее..

Перевод Apple может потерять множество разработчиков

12.08.2020 10:04:09 | Автор: admin
На июньской WWDC 2020 Apple объявила о том, что в течение следующих двух лет все компьютеры Mac перейдут на собственные чипы ARM компании. Об этом решении уже давно ходили слухи, но услышать эту новость от самой Apple совсем другое дело. Компания не только выполнит этот переход, но и стремится завершить его всего за пару лет.




Эта смена платформы напоминает событие, произошедшее в 2006 году, когда Apple перешла с PowerPC на Intel, но есть несколько отличий. Во-первых, когда компания переключилась с PowerPC на Intel, Windows уже по большей мере работала на архитектуре x86/x8664. Следовательно, благодаря этому Mac попал на ту же процессорную платформу, на которой находилась доминирующая ОС Windows. В этот раз Apple делает нечто противоположное переносит Mac на ARM, не имеющий большой доли в настольных компьютерах и ноутбуках. Отличается и ситуация с рынком сегодня доминирующим типом компьютеров являются смартфоны. Кроме того, значительно выросла рыночная доля Linux, который занимает более 2% (в основном его используют разработчики).

Что всё это будет значить для разработчиков под macOS и iOS?


Для разработчиков под iOS это довольно хорошая новость. Такой переход означает, что Mac теперь будет работать на той же архитектуре, что и iPhone с iPad, то есть создавать приложения с поддержкой macOS будет намного проще. Особенно справедливо это потому, что все приложения iOS теперь будут доступны на Mac с ARM с момента выпуска, если только разработчик приложения не откажется от этого. Мне кажется, что при этом и так уже замечательные симуляторы iPhone и iPad будут обеспечивать ещё более высокую производительность.

Однако автоматическая публикация приложений iOS на Mac это обоюдоострый меч. Приложения iPhone разрабатывались для оптимальной работы на iPhone. Это значит, что без дополнительных усилий со стороны разработчиков они могут выглядеть очень странно на гораздо большем экране с соотношением сторон 16:10. Чтобы приложение выглядело на Mac отлично, потребуется лишний труд разработчиков.

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

А что насчёт других разработчиков?


Для разработчиков, у которых экосистема Apple не является основной целевой платформой, изменения могут или остаться незаметными, или приведут к отказу от платформы. Многим кроссплатформенным разработчикам, вероятно, не придётся делать почти ничего лишнего, потому что всю работу по адаптации приложений под процессоры Apple, скорее всего, возьмут на себя фреймворки. В то же время, Bootcamp (ПО, используемое для запуска Windows на железе Apple) на новых Mac работать не будет. Для многих разработчиков это станет причиной отказа от платформы, потому что Windows на ARM лицензируется только для OEM, а значит, пока нет способов запуска Windows на Mac с ARM.

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

Объясню, что это значит, на примере: обычно я работаю с Mac, потому что на одной машине могу сразу протестировать свои приложения на всех основных платформах. Нужно протестировать ПО под Windows? Запускаем Parallels и загружаем Windows VM или выполняем dual boot с раздела Bootcamp. Требуется тестирование под Linux? Снова запускаем Parallels. Разрабатываем приложение для мобильных? Mac это единственный компьютер, на котором можно протестировать ПО для iOS и Android. В то же время, я пишу серверные скрипты в основном на Mac, потом тестирую их совместимость с помощью Parallels, а затем исправляю немногочисленные ошибки, которые могут возникать из-за того, что я работаю на Mac, а не под Linux, и уже после этого выполняю деплой на серверах. После перехода на процессоры Apple многие из перечисленных возможностей могут быть потеряны.

Вывод


Хотя в этой статье я в основном сосредоточился на негативных аспектах перехода на процессоры Apple, у него есть и множество плюсов. Представьте ноутбук, способный несколько дней работать от аккумулятора, и при этом более мощный, чем современные модели. Представьте, что можно написать приложение один раз и без проблем запускать его на iPhone, iPad и Mac. Представьте, что можно запускать самые новые игры с отличной частотой кадров без отдельного GPU и быстрого разряда аккумулятора. Вскоре всё это может стать реальностью.

С другой стороны, что если AMD и Intel по-прежнему будут доминировать на рынке мощных компьютеров, а чипы ARM компании Apple смогут конкурировать только в нижнем сегменте? Что если ставка на смену архитектур не оправдает себя, и Apple потеряет благосклонность разработчиков?



На правах рекламы


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

Подробнее..

Идеи и советы по производству мерча для сотрудников

29.07.2020 14:20:10 | Автор: admin


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

Зачем вообще нужен мерч


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

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

Дождевик


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


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

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

На что обратить внимание, если вы решили сделать брендированную верхнюю одежду:


  • Насколько ткань устойчива к влаге,
  • Насколько прочная ткань. Желательно устроить краш-тест: мять, тянуть, поливать водой и примерять на сотрудников,
  • Как смотрятся принты на ткани и как они ведут себя после стирки.




Для тестирования размеров мерча мы подобрали две типовые фигуры среди сотрудников. Так у лекал появились названия Женя и Полина. А Кристина была экстремальным пользователем, тестирующим пригодность размеров для миниатюрных фигур.

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


  • 57 дней делают лекало и образец,
  • 34 дня доставка и тестирование образца,
  • 30 дней запуск в производство,
  • 14 дней пошив изделия.

Носки


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


Но мы прошли Москву, МО, Питер, Нижний Новгород, сделали несколько тестовых образцов (стоимость одного от 1500 до 2500 рублей), и везде качество было не на высоте. Спасли Новосибирск и производство Stereo Socks.

На что обратить внимание при производстве трикотажа


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



Скотч


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

Что ещё интересного


Не все вещи доставались нам через такие приключения, как скотч и дождевик. Например, значки сделать достаточно легко, они просто отливаются в фиксированной форме. Хорошие металлические значки сделали в питерском Pinhead.



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

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



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

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

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


Материал для нашивок важен, так как от него зависит качество печати. Заказывали в ГалаПолиграфе

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

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

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

Факап с бутылкой для воды и что мы ещё не сделали


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

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

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

Опечатка, отправившаяся в производство


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


Если очень присмотреться, то можно заметить

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

Восемь советов, как выпустить хороший мерч


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

  • В основе всего идея. Придумайте крепкую коммуникационную идею, которую можно масштабировать под разные товары.Тогда у вас будут не просто брендированные вещи, а целая история. Продумайте, как мерч работает с культурным кодом компании и какие ценности несет.
  • Мерч для сотрудников. Привлекайте коллег из разных отделов к работе над проектом. Например, ребята из разработки придумывали с нами носки. И на съемку мы пригласили наших сотрудников, потому что они и есть носители продукции.
  • Принцип 80/20. Основная работа подготовка. Сядьте, представьте вашу цель, напишите план, потом делайте. Не бойтесь перед пошивом десять раз примерить к одежде распечатанные лекала, чтобы убедиться что всё на своем месте.
  • Точно распределите роли, кто и что делает. Работа над магазином проект, и четкий менеджмент важен. Группа собирается не просто повеселиться: у нее есть дедлайны и задачи.
  • Хороший поставщик половина успеха. Если не нашли поставщика в своем городе, смотрите другие регионы. В большинстве случаев стоимость регионального производства ниже, и доставка себя окупает.
  • Правило семь раз отмерь, один раз отрежь применяется не только к пошиву, но и к формулировкам ТЗ. Производственные лекала достаточно дорогие, например, лекало дождевика стоило семь тысяч, поэтому комментарии к образцам нужно давать подробные, и когда вся команда их обсудила и уверена в своих пожеланиях. Пишите техническое задание для производства (вплоть до мелочей), но будьте готовы к диалогу с исполнителями: иногда они лучше тебя знают, как правильно сделать.
  • Делайте тестовые образцы. Мы переделывали вещи по три-четыре раза и это нормально. Тестируйте ткань и нанесение. Не стесняйтесь устраивать краш-тесты образцам: стирайте, гладьте, рвите и т. д. Если не нравятся образцы, ищите качественные вещи в продаже и потом показывайте их в качестве образца производству. А также обязательно примеряйте мерч на людях с разным ростом, разными типами фигур и даже с разными привычками (например, кто-то носит сумку через плечо, а кто-то на поясе).


И последний совет запаситесь пространством для хранения

Контакты производств



А у вас есть мерч? Как он выглядит? Если нет, то планируете?
Подробнее..

Переправа, переправа! Берег левый, берег правый

29.07.2020 20:20:10 | Автор: admin

В общем, выскажу своё никому не нужное мнение по поводу того, что происходит с Яндекс.Диском в последние дни. И, мне кажется, что может сложится впечатление, особенно после прочтения этой статьи, что я состою в рядах так называемый "хейтеров" компании, но это совсем не правда. Я даже исправно плачу каждый месяц три копеечки из своего кармана за подписку ПЛЮС, хотя фактически ею не пользуюсь. Вполне очевидно, что такие компании-титаны как Яндекс, Сбер и Mail Ru Group двигают ИТ в нашей стране семимильными шагами и, что уж говорить, про то количество рабочих мест, которые они обеспечивают, часто на очень комфортных условиях, позволяя людям участвовать в технологически крутых продуктах. Далее по тексту Mail Ru буду называть MRG.


Итак, краткий пересказ недавних событий для тех, кто все проспал: вроде бы в июне Яндекс представил новый продукт, а именно Телемост. Это приложение для создания групповых телеконференций. Приложение работает поверх Electron и построено на базе проекта Jitsi с открытым исходным кодом. И в качестве приятного бонуса, по естественным причинам, приложение может работать как сервис из браузера, но из-за ряда ограничений реализации не работает под моим любимым Firefox. Зимой, когда начался массовый переход на удаленную работу, мне довелось вскользь попробовать работу с Jitsi и результат был не обнадеживающий странные UX решения соседствуют с не менее странной разработкой продукта. Что, в общем-то, в случае с опенсорсом явление не редкое и, возможно, вполне допустимое, но нам такой расклад дел явно не подходил. Когда же большая корпорация с огромными ресурсами берет в основу своего продукта такое решение, то сразу появляется неловкое ожидание какого-то качественного скачка, но вот в данном случае как будто бы такого не вышло. На момент запуска продукта, судя по скриншотам, Телемост от Jitsi отличался только немного внешне. Но, справедлвости ради, как обстоят дела сейчас я даже и не знаю пробовать особо не хочется, да и без надобности оно мне.


Очевидно, что поезд удаленки мчится вдаль и надо успевать в него запрыгнуть, тем более, что первенство средств телеконференций возглавил далеко не идеальный Zoom. А свое решение есть даже у MRG и, неожиданно, оно вроде даже как-то работает. Итак, к проблеме: вчера пользователи Яндекс.Диска для Windows обнаружили на своих рабочих столах ярлык для запуска приложения Телемост который, естественно, никто не ставил на свои компьютеры. История, в общем-то, стара как мир, и многие из нас помнят агрессивную стратегию продвижения своих продуктов от MRG когда на компьютер ставилось приложение "Mail Ru Guard" и оно, кроме того, что блокировало удаление из автозапуска своих програм, еще и на свое усмотрение скачивало и устанавливало пользователю софт и информационные панели в браузер. Негодующие пользователи сервисов Яндекса потянулись с вопросами к Яндексу и был получен абсолютно прекрасный ответ, из которого дали однозначно понять, что приложение Телемост удалить никак нельзя отдельно от Яндекс Диска. Ну ок, нельзя так нельзя, подумал я.


Я использую Диск по ряду причин и одна из них это размещениие на нем базы KeePass, а вторая поддержка доступа к файлам по протоколу webdav. Это прямо очень удобно, и делаю я так много лет. Использую я обычно MacOS, и потому сразу подумал о том, что эта история с Телемостом не про меня, а про пользователей Windows, сидящих по старой привычке под административными правами, и продолжающими наслаждаться вкусом кактуса. Но не тут-то было! Перейдя на сайт сервиса у меня запустилось приложение Телемост! Сказать, что я был удивлен это не сказать ничего. У меня дернулся глаз и я нервно потянулся к револьверу чашке кофе.


Кратое расследование показало, что приложение расположено в /Applications/Yandex.Disk.2.app/Contents/MacOS/Yandex.Telemost.app. Я сразу почувствовал себя зрителем телешоу "Тачку на прокачку", но только в качестве машины выступает мой ноутбук, а воображаемый Xzibit встроил не телевизор в подголовник, а одно приложение в другое. Это MacOS Карл, здесь так нельзя! У меня даже отдельный значок приложения появился в родном операционной системе файловом менеджере Finder.



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


Для тех кто пропустил или слишком молод:



Но постойте, приложения Диска вроде бы нативные, а Jitsi это Electron! Как тогда проходит интеграция одного в другое? Я честно потыкал приложение диска для MacOS на предмет поиска какого-либо намека на Телемост, но ничего не нашел. Ожидаемо, никакой интеграции части сервиса в основной сервис нет и в помине. На web странице Диска ссылка на Телемост располагается рядом с ссылкой на Почту и там тоже никаких интеграций.


У пользователей Windows папка с приложением Телемост располагается в папке Диска, по слухам её можно удалить, и приложение диска продолжит успешно работать. То есть выходит, что все-таки приложение Телемост использует Диск только чтоб пробраться на жесткий диск пользователя? К слову, если это так, то это поведение практически один в один поведение вирусов Trojan Downloader, которыми очень любят доставлять шифраторы злоумышленники.


Но самое обидное в этой истории то, что сегодня был официальный ответ в блоге Яндекса в котором жирным выделенно, что единственная ошибка компании это то, что пользователям вывели ярлык на рабочий стол. Все оказалось вот так просто :) Статья начинается со слов "Меня зовут Володя" и как-то не ясно зачем человек выступая от лица компании сразу подставяляется под удар, но зато мы теперь знаем в лицо ответственного. Ну как-то от Яндекса ожидаешь более честного поведения, а не откровенного манифеста о возврате к временам когда приложения от Яндекса и MRG нельзя ставить на диск из страха, что они замусорят всю операционную систему. Хотелось бы, все таки, чтоб в офицальных ответах от компании не было наплевательских отмашек, а текст объяснял действия и почему с этим нужно смириться рядовому пользователю. Про более изящное техническое решение уж и мечтать даже и не приходиться при таком раскладе. Кстати, в статье немного расходятся показания в начале говорится о том, что Телемост это часть Диска, а в конце, что у приложения будет отдельный клиент. Очевидно, конечно, что продукт надо быстро продвигать и ребята из Диска идут на сомнительные шаги. Но пользователя надо хотя бы любить и уважать, объясняя что даст тот или иной шаг и какое будущее у данного решения. Буду надеятся, что компания проведет хоть какую-нибудь работу над ошибками.


Ссылка с самым бессмысленным ответом на реакцию недовольных пользователей за всю историю человечества в эпоху развития IT решений: https://yandex.ru/blog/company/pochemu-mosty-inogda-luchshe-ne-navodit

Подробнее..

Переправа, переправа! Берег левый, берег правый или мысли вслух о Яндекс.Телемост

29.07.2020 22:04:59 | Автор: admin

В общем, выскажу своё никому не нужное мнение по поводу того, что происходит с Яндекс.Диском в последние дни. И, мне кажется, что может сложиться впечатление, особенно после прочтения этой статьи, что я состою в рядах так называемый "хейтеров" компании, но это совсем не правда. Я даже исправно плачу каждый месяц три копеечки из своего кармана за подписку ПЛЮС, хотя фактически ею не пользуюсь. Вполне очевидно, что такие компании-титаны как Яндекс, Сбер и Mail Ru Group двигают ИТ в нашей стране семимильными шагами и, что уж говорить, про то количество рабочих мест, которые они обеспечивают, часто на очень комфортных условиях, позволяя людям участвовать в технологически крутых продуктах. Далее по тексту Mail Ru буду называть MRG.


Итак, краткий пересказ недавних событий для тех, кто все проспал: вроде бы в июне Яндекс представил новый продукт, а именно Телемост. Это приложение для создания групповых телеконференций. Приложение работает поверх Electron и построено на базе проекта Jitsi с открытым исходным кодом. И в качестве приятного бонуса, по естественным причинам, приложение может работать как сервис из браузера, но из-за ряда ограничений реализации не работает под моим любимым Firefox. Зимой, когда начался массовый переход на удаленную работу, мне довелось вскользь попробовать работу с Jitsi и результат был не обнадеживающий странные UX решения соседствуют с не менее странной разработкой продукта. Что, в общем-то, в случае с опенсорсом явление не редкое и, возможно, вполне допустимое, но нам такой расклад дел явно не подходил. Когда же большая корпорация с огромными ресурсами берет в основу своего продукта такое решение, то сразу появляется неловкое ожидание какого-то качественного скачка, но вот в данном случае как будто бы такого не вышло. На момент запуска продукта, судя по скриншотам, Телемост от Jitsi отличался только немного внешне. Но, справедлвости ради, как обстоят дела сейчас я даже и не знаю пробовать особо не хочется, да и без надобности оно мне.


Очевидно, что поезд удаленки мчится вдаль и надо успевать в него запрыгнуть, тем более, что первенство средств телеконференций возглавил далеко не идеальный Zoom. А свое решение есть даже у MRG и, неожиданно, оно вроде даже как-то работает. Итак, к проблеме: вчера пользователи Яндекс.Диска для Windows обнаружили на своих рабочих столах ярлык для запуска приложения Телемост который, естественно, никто не ставил на свои компьютеры. История, в общем-то, стара как мир, и многие из нас помнят агрессивную стратегию продвижения своих продуктов от MRG когда на компьютер ставилось приложение "Mail Ru Guard" и оно, кроме того, что блокировало удаление из автозапуска своих програм, еще и на свое усмотрение скачивало и устанавливало пользователю софт и информационные панели в браузер. Негодующие пользователи сервисов Яндекса потянулись с вопросами к Яндексу и был получен абсолютно прекрасный ответ, из которого дали однозначно понять, что приложение Телемост удалить никак нельзя отдельно от Яндекс Диска. Ну ок, нельзя так нельзя, подумал я.


Я использую Диск по ряду причин и одна из них это размещениие на нем базы KeePass, а вторая поддержка доступа к файлам по протоколу webdav. Это прямо очень удобно, и делаю я так много лет. Использую я обычно MacOS, и потому сразу подумал о том, что эта история с Телемостом не про меня, а про пользователей Windows, сидящих по старой привычке под административными правами, и продолжающими наслаждаться вкусом кактуса. Но не тут-то было! В тот момент, когда я перешел на сайт сервиса, у меня запустилось приложение Телемост! Сказать, что я был удивлен это не сказать ничего. У меня дернулся глаз и я нервно потянулся к револьверу чашке кофе.


Кратое расследование показало, что приложение расположено в /Applications/Yandex.Disk.2.app/Contents/MacOS/Yandex.Telemost.app. Я сразу почувствовал себя зрителем телешоу "Тачку на прокачку", но только в качестве машины выступает мой ноутбук, а воображаемый Xzibit встроил не телевизор в подголовник, а одно приложение в другое. Это MacOS Карл, здесь такие решения не любят! У меня даже отдельный значок приложения появился в родном операционной системе файловом менеджере Finder.



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


Для тех кто пропустил или слишком молод:



Но постойте, приложения Диска вроде бы нативные, а Jitsi это Electron! Как тогда проходит интеграция одного в другое? Я честно потыкал приложение диска для MacOS на предмет поиска какого-либо намека на Телемост, но ничего не нашел. Ожидаемо, никакой интеграции части сервиса в основной сервис нет и в помине. На web странице Диска ссылка на Телемост располагается рядом с ссылкой на Почту и там тоже никаких интеграций.


У пользователей Windows папка с приложением Телемост располагается в папке Диска, по слухам её можно удалить, и приложение диска продолжит успешно работать. То есть выходит, что все-таки приложение Телемост использует Диск только чтоб пробраться на жесткий диск пользователя? К слову, если это так, то это поведение, практически один в один, поведение вирусов Trojan Downloader, которыми очень любят доставлять шифраторы злоумышленники.


Но самое обидное в этой истории то, что сегодня был официальный ответ в блоге Яндекса в котором жирным выделенно, что единственная ошибка компании это то, что пользователям вывели ярлык на рабочий стол. Все оказалось вот так просто :) Статья начинается со слов "Меня зовут Володя" и как-то не ясно зачем человек выступая от лица компании сразу подставяляется под удар, но зато мы теперь знаем в лицо ответственного. Ну как-то от Яндекса ожидаешь более честного поведения, а не откровенного манифеста о возврате к временам когда приложения от Яндекса и MRG нельзя ставить на диск из страха, что они замусорят всю операционную систему. Хотелось бы, все таки, чтоб в офицальных ответах от компании не было наплевательских отмашек, а текст объяснял действия и почему с этим нужно смириться рядовому пользователю. Про более изящное техническое решение уж и мечтать даже и не приходиться при таком раскладе. Кстати, в статье немного расходятся показания в начале говорится о том, что Телемост это часть Диска, а в конце, что у приложения будет отдельный клиент. Очевидно, конечно, что продукт надо быстро продвигать и ребята из Диска идут на сомнительные шаги. Но пользователя надо хотя бы любить и уважать, объясняя что даст тот или иной шаг и какое будущее у данного решения. Буду надеяться, что компания проведет хоть какую-нибудь работу над ошибками.


Ссылка с самым бессмысленным ответом на реакцию недовольных пользователей за всю историю человечества в эпоху развития IT решений с каким-то нелепым заголовком: https://yandex.ru/blog/company/pochemu-mosty-inogda-luchshe-ne-navodit

Подробнее..

Это нужно знать каждому программисту (или ядреный кликбейт про кодерский сленг)

02.08.2020 04:18:04 | Автор: admin


YAGNI, KISS, DRY, WET, SLAP, ASAP, YOLO что все это вообще значит?

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

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

Визуалам сюда: youtu.be/ub0YtnSwqRA



KISS (Keep it simple, stupid )


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

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

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

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



DRY (Dont repeat yourself)


Принцип Не повторяй себя по своей природе очень похож на KISS. Это довольно просто и в то же время имеет широкое значение. Это довольно просто и в то же время имеет широкое значение поняли шутку?

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

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



WET (We enjoy typing)


Решения WET широко распространены в многоуровневых архитектурах, где разработчику может быть поручено, например, добавить поле комментария в форму в веб-приложении. Текстовая строка comment может повторяться в метке, HTML-теге, в имени функции чтения, закрытой переменной, DDL базы данных, запросах и т.д. Подход DRY устраняет эту избыточность за счет использования платформ, которые уменьшают или исключают все эти задачи редактирования, кроме самых важных, оставляя возможность добавления новых переменных в одном месте.



YAGNI (You aint gonna need it)


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

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

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

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



SLAP (Single level of abstraction principle)


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

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

Как говорил Роберт Мартин: функции должны делать только одну вещь, и они должны делать это хорошо.

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

Грубо говоря, твои функции должны делать только одно, или другими SLAP-словами, должны иметь только один уровень абстракции.

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



FOOBAR (F****d up beyond all recognition)


Если перефразировать по-русски: сломано так, что не восстановить.
Это чудесное выражение, пришедшее в IT из милитарного сленга, наряду с иными шедеврами, такими как, например, SNAFU Situation Normal all fucked up; это что-то вроде: ситуация вполне естественная, но все оказалось напрасно.
По легенде, C-программисты использовали для переменных имена foo и bar в качестве, так называемых, placeholder или заполнителей места, особенно в учебных примерах. Так, их светлые головушки освобождались от бремени придумывания новых названий и могли сконцентрироваться на решении задач.
Со временем, это стало традицией и перекочевало из C во многие уже не такие древние языки, поэтому примеры таких имен можно встретить в учебниках повсеместно, а само слово FooBar, применимое к проекту, означает, что можно начать подыскивать себе что-то другое.



ASAP (As soon as possible)


Так скоро, как только это возможно.
В последнее время стало трендом As soon as reasonably possible так скоро, как только это возможно, но в разумных пределах.
Вошло в обиход также из армейского сленга аж во время первой мировой. Активно используется по сей день, если данный акроним часто применяется в переписке с вышестоящими, то это может красноречиво указывать на уровень организации в компании или навыков управления и умения приоритизировать у начальства. Но бывают, конечно, и исключения, когда ситуация вышла из под контроля и вообще Foobar.



FYI (For your information)


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



TL;DR (Too long; didnt read)


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



DIY (Do it yourself)


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



YOLO (You only live once)


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

И помни YOLO, так что KISS. Это был Ви. До встречи на канале! Аве!
Подробнее..

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

11.08.2020 14:11:07 | Автор: admin
Самообслуживание стало привычным способом решать бытовые вопросы. Покупки, оплата счетов, поиск нужной информации всё это мы делаем через веб-приложения без помощи людей и не выходя из дома. Корпоративная среда не исключение.

Потребность в порталах самообслуживания (Self Service Portals) растёт с каждым годом. Например, в США 88% процентов пользователей считают, что у компаний и брендов должен быть такой портал. В исследовании Service Desk Institute на вопрос Что больше всего повлияет на ваш выбор Service Desk или ITSM-инструмента? 70% респондентов ответили: Возможность самообслуживания.

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




Что такое Self Service Portal


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

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

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



Основные функции корпоративного портала


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

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

Портал самообслуживания нашей компании на базе ESM-платформы SimpleOne

Для удобства пользователей услуги на портале группируются по сервисным подразделениям. К примеру, в разделе HR подаются только соответствующие заявки: на отгул, отпуск, командировку или увольнение. В разделе АХО сотрудники могут заказывать новое оборудование, мебель, канцелярию, пропуск в бизнес-центр.

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

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



Преимущества для компаний


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

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

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

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

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



Почему вашим порталом не пользуются?


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

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

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



Сделайте портал рабочим инструментом


Агентство Gartner даёт рекомендации для разработки портала самообслуживания в ИТ-компаниях, но они пригодятся любой сервисной компании или подразделению.

  • Выяснить экономические ожидания руководства от внедрения портала самообслуживания. (Добавим: и ориентироваться на эти ожидания как на одну из ключевых целей.)
  • Определить, в каких направлениях самообслуживание может принести максимальную пользу.
  • Использовать опыт традиционного обслуживания для разработки стратегии самообслуживания.
  • Объяснить клиентам и сотрудникам, в чём преимущества портала именно для них; мотивировать на то, чтобы активнее пользоваться порталом.

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

Простой и понятный интерфейс. Когда клиент сталкивается со сложным или запутанным интерфейсом портала самообслуживания, у него возникает естественное желание больше не пользоваться им. Уровень проработки UI/UX у портала должен быть таким же высоким, как и у любого другого качественного сервиса.
Мобильность. Клиенту должно быть одинаково удобно пользоваться полной и мобильной версией портала. Нередко отправить запрос и получить информацию на портале нужно, когда рядом нет компьютера.
Обратная связь. Учёт отзывов, советов и пожеланий клиентов один из действенных способов оптимизации портала. Важно, чтобы обратная связь была удобной для обеих сторон.
Отслеживание метрик. Чтобы лучше понять, как клиенты пользуются сервисом, как можно повысить его удобство и качество работы, следует анализировать действия пользователей на портале, в том числе их опыт взаимодействия с интерфейсом.
Быстрый отклик. По данным компании SuperOffice, самый важный показатель качества обслуживания быстрое время отклика. Это справедливо и для портала самообслуживания: клиенты, которые получают нужную информацию или помощь без задержек, лояльнее.



Заключение


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

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

Портал стал необходимостью, об этом говорит и статистика. По данным финской компании HappySignals, портал самообслуживания самый популярный в 2020 году канал обращения в техподдержку (31%). По этому показателю он опережает телефонные звонки (29%) и электронную почту (23%). Подсчёты сделаны на основе опроса более 800 тыс. респондентов из 130 стран. Самообслуживание, как показывает исследование, способствует также и росту уровня общей удовлетворённости качеством работы техподдержки: с февраля по май этот показатель вырос с 66 до 73.



Наши гайды и руководства по теме в корпоративном блоге ИТ Гильдии:




Подробнее..

Recovery mode Зачем айтишнику второй паспорт?

12.08.2020 16:20:14 | Автор: admin
И действительно, зачем? Попробуем разобраться, заодно отвечая на сопутствующие вопросы. Например, о том, почему люди пользуются паспортами, что дает альтернативное гражданство, как его получить (спойлер: есть целых 5 способов) и что с ним делать дальше.



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

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

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

Некоторые делают это удачно, заручившись поддержкой компетентных юристов. Например, сооснователь Facebook Эдуардо Саверин (обладатель бразильского паспорта и гражданин США до 2011 года), сэкономивший благодаря отказу от американского паспорта около US$700 млн. в виде налогов.

Другие рискуют и не пьют шампанское. Например, сооснователь Тинькофф банка Олег Тиньков (гражданин США с 1996 по 2013 гг., обладатель российского и кипрского паспортов) из-за махинаций может лишиться четверти активов или попасть за решетку в Штатах на 6 лет.

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

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

Почему люди пользуются паспортами?


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

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



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

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

Преимущества второго паспорта и статуса бипатрида


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

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

Как получить статус бипатрида


Вот пять способов получить эти и многие другие преимущества:

  1. Происхождение: Вариант для победителей генетической лотереи. Можете доказать родство с гражданами других стран? В некоторых случаях это дает право на второй паспорт на основании происхождения при минимуме усилий, денежных затрат и потраченного времени. Где такое возможно? Например, в Израиле, Италии, Ирландии или Польше.
  2. Натурализация: Вариант для самых терпеливых и легких на подъем, так как часто предполагает многолетнее проживание вдали от родины, изменение круга общения и образа жизни. Продолжительность процесса варьируется от трех до тридцати лет. Главный минус результат не гарантирован, и правила натурализации могут не единожды измениться после начала этого процесса. А еще есть экзамены на знание языка, культуры и истории, а также необходимость уплаты налогов и, в некоторых случаях, отказ от любого другого паспорта (подобное практикуют в Испании).
  3. Бракосочетание: Если жениться на иностранке / выйти замуж за иностранца, можно существенно ускорить натурализацию (такое возможно, например, во Франции и США) и получить статуса бипатрида без сдачи ряда тестов. В Кабо-Верде и вовсе можно сразу стать гражданином после брака. Но не спешите связывать себя священными узами ради второго паспорта. В некоторых местах за фиктивные браки предусмотрены реальные уголовные статьи.
  4. Особые заслуги: Маршрут хоть и быстрый, но самый непрозрачный. Четких правил нет. Решения принимаются по усмотрению главы принимавшего государства (например, премьера, президента или султан). Основанием для ускоренной натурализации могут быть выдающиеся заслуги в области спорта, культурной или научной деятельности. Обладателям премии Оскар, победителям Олимпиад и нобелевским лауреатам будут рады власти многих стран равно как и владельцам многомиллиардных корпораций, способных генерировать рабочие места, вроде Джеффа Безоса или Сергея Брина.
  5. Инвестиции: Самый быстрый, прозрачный и простой вариант. Претендент платит. Чиновники дают ему второй паспорт. Вкладываться можно в недвижимость, ценные бумаги, бизнес (с созданием рабочих мест). Также можно вносить безвозмездную дотацию. Скорость 1,5-12 месяцев. Переезжать за рубеж, менять круг общения и уклад жизни не нужно. Учить язык и культуру тоже. Иногда даже не требуется посещать новую родину (до, в момент и после получения ее паспорта) все происходит в удаленном режиме.

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


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

  • Антигуа и Барбуда US$ 0,1 млн.
  • Вануату US$ 0,145 млн.
  • Гренада US$ 0,15 млн.
  • Доминика US$ 0,1 млн.
  • Египет US$ 0,16 млн.
  • Иордания US$ 0,75 млн.
  • Кипр 2,15 млн.
  • Мальта 0,88 млн.
  • Сент-Китс и Невис US$ 0,15 млн.
  • Сент-Люсия US$ 0,1 млн.
  • Турция US$ 0,25 млн.
  • Черногория 0,35 млн.

Получили второй паспорт и статус бипатрида? Что дальше?


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

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



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

Альтернативное гражданство и мошеннические схемы


  1. Придерживаясь иммиграционных правил и расширяя паспортную коллекцию исключительно на законных основаниях, можно получать от нее максимальную отдачу, просто направляясь туда, где в данный момент лучше всего вести бизнес, жить, отдыхать и работать. Но часто возникает соблазн срезать углы, обратившись к мошенникам, предлагающим следующие схемы:
  2. Паспорт дипломата: Предложение обзавестись таким документом может поступить только от мошенников. Даже банановая республика вряд ли за деньги сделает иностранца частью своего дипкорпуса. Дипломатические работники должны соответствовать определенным признанным на мировом уровне стандартам. Дипломат лицо страны, формирующее ее имидж на международной политической арене. И страна вряд ли рискнет имиджем, выдавая диппаспорт за US$7k, как предлагают объявления в интернете (публикуемые, конечно же, мошенниками).
  3. Отмененная схема экономического гражданства: Все больше государств предлагают гражданство через инвестиции. Но также растет число юрисдикций, по тем или иным соображениям закрывших такие программы. Примеры: Ирландия, Коморские острова, Молдова. Мошенники могут воспользоваться недостаточной информированностью потенциальных мигрантов-инвесторов, чтобы продать им несуществующую услугу.
  4. Камуфляжный паспорт: Такие документы предлагается использовать для маскировки своего реального гражданства при посещении опасных мест. Речь о паспортах стран, которых больше нет. Например, Британского Гондураса или Родезии.
  5. Серый рынок: Суть схемы в том, что мошенники подкупают сотрудников иммиграционного ведомства / паспортного стола, чтобы коррумпированные чиновники внесли в легальную базу данных граждан сведения о клиентах злоумышленников. После этого можно получить паспорт, который, впрочем, может быть легко аннулирован, если коррупционеры сознаются в содеянном. В таком случае обладателю документа может грозить тюрьма.
  6. Черный рынок: Паспорт, купленный на черном рынке является незаконным при любом раскладе. Это плод фальсификации. Для создания таких документов мошенники используют легальные паспорта (украденные или потерянные), вырезая чужие фотографии и страницы с информацией и вставляя свои данные. Также есть возможность создания поддельного паспорта полностью с нуля.
  7. Банковский паспорт: Такие документы, как следует из названия, нужны для работы с банками. Продающие их мошенники не рекомендуют принять банковские паспорта для путешествий, поскольку фальсификация легко раскрывается сотрудниками иммиграционного департамента практически любой страны.

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

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

Остались вопросы? Задавайте их в комментариях!
Подробнее..

Категории

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

© 2006-2020, personeltest.ru