Самозапрет на подключение новых SIM-карт

На днях на Госуслугах появилась новая услуга - «Запрет на оформление договоров связи». С радостью воспользовался ей (для себя и близких) почти сразу же после появления.

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

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

Если, что запрет снимается в течение 1 дня при личном обращении в МФЦ.

Проверить список симок, которые на вас зарегистрированы - на Госуслугах в разделе «Профиль» - «Сим-карты». Спасибо Артему (@artemovskie_thoughts), что подсказал когда-то про эту услугу (у Артема в посте было еще полезное про самозапрет на кредиты и запрет действий с недвижимостью).

UPD: после того, как опубликовал пост - пошел подключать услугу еще на один аккаунт Госуслуг - а там буквально вчера пришли уведомления о заключении договора на 4 симки! Чуть-чуть не успел, придется снова идти в салон и разбираться. Пока сделаю блокировку этих номеров, там же на Госуслугах.

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

Примеры попадания в такие ситуации:
- Фраза в толпу. На встрече автор задачи безадресно говорит "надо сделать то-то". Он думает, что всем очевидно, что "тем-то" занимается именно Вася, а сам Вася так не считает или в этот момент листал ленту ВК. Либо автор задачи может даже сказать, что задача додстается Васе, но тот мог просто прослушать
- Письмо с кучей получателей. Как пункт выше, только Вася мог это письмо не прочитать или прочитать невнимательно.
- Даже при общении один-на-один текстом или голосом - все сценарии выше актуальны.
- И даже назначенный на человека тикет в таск-трекере - не гарантия. И меншн/тег/@ с уведомлением - тоже.
- ...

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

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

В книжке «Enterprise Ontology» (Ian Dietz и Hans Mulder) описывается методика координационных актов DEMO - большая, полезная, для кого-то душная. Не буду ее полостью пересказывать, просто перечислю типовые стадии для задачи/поручения/заказа (перевод и список взял у А. Левенчука из руководства "Системный менеджмент"):

- Осознание нужности инициатором автором/заказчиком/поручителем какой-то работы
- Поручение/заказ/просьба выполнения работы (предъявление потенциальному исполнителю). Работа тут поручена, но не взята!
- Обещание исполнителя выполнить работу (явный приём к исполнению)
- Выполнение работы
- Объявление о том, что работа выполнена (работа тут выполнена, но не принята)
- Объявление о принятии работы

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

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

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

На МЦК двери в вагонах открываются по требованию: нажал на кнопку - дверь откроется. Если не нажал - останется закрытой. Сделано, видимо, чтобы летом не впускать лишний тёплый воздух с улицы, а зимой - не переохлаждать вагоны (открываются те двери, где есть пассажиры, которые хотят войти/выйти).

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

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

Вот было бы круто, если на МЦК кнопку запроса на открытие двери можно было нажимать не после остановки поезда, а чуть заранее - сразу с момента начала движения поезда к следующей станции, либо с момента, когда люди обычно начинают готовиться к выходу и идут к двери. Это высвободит моё внимание, как "пользователя", чтобы я мог дальше спокойно витать в своих мыслях, о чем-то думать, писать что-то в телефоне и пр. Что повысит качество «опыта» (та самая X в аббревиатуре UX) :)

Уверен, в UX-культуре есть даже название такому паттерну.

Если бы мне лет 10 назад показали такое фото и сказали, что это Москва - не поверил бы

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

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

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

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

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

Что еще почитать по теме:
- Концепция ФФФ в Бюро Горбунова
- Моя статья на Хабре "7 способов лучше понимать потребности пользователей и доносить их до команды разработки" (там много ссылок)

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

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

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

В общем, рекомендую! Особенно, если смотреть через призму "фрактального" устройства мира и переносимости идей между разными контекстами и предметными областями (писал про это несколько месяцев назад https://news.1rj.ru/str/igabdullin_blog/17). То есть рассматривать сказанное не буквально (как автор - в контексте научных исследований), а чуть абстрагировавшись, на лёгком чиле (идти и сразу писать докторскую совсем не обязательно), но с мыслями о своей деятельности. Может быть, натолкнет на какие-то идеи!

Шуточный спойлер/краткое изложение с моими дополнениями и искажениями: сначала долгая напряжённая работа без гарантии результата (желательно с горящими глазами, но гнёт кнута экзистенциальных проблем тоже подойдёт!), а потом, может быть, за тебя всё сделает Эгрегор. Работает на 1000% и, знающие люди говорят, что проверено многими годами эволюции человеческого восприятия мира.

Если почувствуете, что материала по всем ссылкам выше мало, то, чтобы стало совсем хорошо, вот ещё немного:
- https://obrazovanie.by/sandakov/ob-iskustve-i-tvorchestve.html
- https://www.yburlan.ru/biblioteka/vosmimernost-i-golografichnost-realnosti
- https://www.ted.com/talks/elizabeth_gilbert_your_elusive_creative_genius?language=ru&subnoscript=ru

Хорошие люди поделились ссылкой на занятную статью на Хабре (https://habr.com/ru/articles/949874/) - про то, как на IT-рынке аналитикам становится тяжелее искать работу и что с них начинают требовать больше компетенций.

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

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

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

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

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

Не берусь утверждать, что на 100% согласен, что "аналитик" должен закрывать все компетенции, указанные в статье, но быть Т-shaped специалистом с широким кругозором (глубоко развитая основная компетенция плюс много других компетенций, в т.ч. связанных с умением общаться с людьми), особенно в сложных проектах и больших командах - обязан. А опыт отвечать за проект в целом — хорош как прививка от воздушных замков, так как приземляет фантазии и заставляет включать мозг, т.к. за твои воздушные замки в "требованиях" тебе же и отвечать.

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

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

UPD: оказывается, сегодня день системного аналитика. С праздником!)

Вкус еды и посуда

Мне как-то подарили вот такую пиалу (спасибо, Саша!) - ручная работа, делали где-то в Грузии в 70-80х.

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

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

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

От Госуслуг пришло такое интересное письмо.

Оно удивило следующим:
1. Не знал, что у нас в стране остались населённые пункты, где ещё нет мобильного интернета. Честно - думал, что это сказки из сериалов про глухие деревни. При том, что я был много в каких деревнях сильно дальше пары тысяч киллометров от МКАД и там все было на удивление хорошо с качеством мобильного интернета.
2. По моей прописке (которую ГУ знают) населённый пункт имеет шикарное покрытие мобильным интернетом. Как я стал ЦА этой рассылки?
3. Почему такие вещи (кому первым проведут интернет) должны решаться голосованием? Ведь если я живу в деревне с населением 100 человек, то какой смысл принимать в нем участие? Первыми в очереди будут населенные пункты, которые больше.

Пришлось даже провести небольшое исследование.

По п.1
Рандомно выбрал несколько населенных пунктов, которые принимают участие в голосовании и смотрел их на карте покрытия МТС.

В Московской области проверил 10 населенных пунктов - в 8 из них было вполне уверенное покрытие от 2G до 4G, отсутствовало только 5G. Да, куда же без 5G! Жалко, что нельзя проголосовать за Москву :)

Но потом выбрал республику Башкортостан и там в 3 населенных пунктах из 10 нет даже 2G! А у большинства - только 2G (то есть только звонки и СМС) с небольшими островками 4G. Оставлю в комментах скрины с пруфом.

По п.2
Родилось только одно предположение: так как голосовать можно за любой населенный пункт из региона моей прописки - то я могу проголосовать за деревню своего родственника/друга и помочь ему набрать голосов.

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

Кому интересно - лендинг с описанием подробностей этого голосования https://www.gosuslugi.ru/inet

Минутка контринтуитивных экспериментов - про тестирование шиворот-навыворот

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

В этом плане мне очень нравится пример про прыжки через планку «ножницами» (честно спёр отсюда). Все всю жизнь "подбегали и прыгали", а в 1968 году странный человек предложил абсурдный способ - поворачиваться к планке спиной и прыгать назад-вверх (Fosbury Flop). И взяли рекорд в 2 м 30 см, который не брался десятилетиями.

Другой пример - про то, как многие менеджеры считают, что важна 100% (а лучше 1000%) утилизация всех людей в команде и не дай бог, если кто-то вдруг окажется недогружен - это же катастрофа. Это с легкостью опровергает теория очередей (основной аргумент - в неспособности такой системы абсорбировать внезапную работу, кому интересно - есть целая книжка "Accelerate: The Science of Lean Software"). И про это много говорит Максим Дорофеев (вот, например, его старый доклад "Эффективность неэффективности" - ВК-Видео, Ютуб).

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

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

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

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

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

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

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

В софтовых системах (особенно когда "у нас же agile") это выглядит дико (контринтуитивно!), но у железячников - пока не поймёшь какие будешь проводить испытания - ни о какой «разработке» (изготовлении) и речи не идёт.

Не факт, что эксперимент получится. Но успешные истории с этой практикой есть. Например, в команде у Никиты Ульшина (см. его серию постов, там еще интересно про практический кейс применения Теории ограничений Голдратта)

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

Еще одна минутка про юзабилити

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

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

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

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

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

Идеально смаковать за завтраками.

https://vkvideo.ru/video-219069760_456239233

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

UPD: есть даже текстовая версия https://habr.com/ru/articles/957516/

Кто еще не проверил количество SIM-карт, которые на вас оформлены (см. наш кейс, когда мошенники зарегистрировали на нас штук 7 левых симок) и не оформил самозапрет на подключние новых SIM-карт — сейчас самое время.

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

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

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

Официальный пруф: https://digital.gov.ru/news/do-1-noyabrya-sokratite-kolichestvo-svoih-sim-kart-do-20