У Андрея Степанова как всегда топ по полезности и актуальности контент.

А наличие вот таких фраз добавляет его словам веса:

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

Звучит лучше, чем посты непонятных «экспертов» из телеграма, которые прочитали и обобщили 10 статей, сделанных такими же экспертами 🙂

Сегодня узнал новый термин — servant leadership.

Как пишет Федор Борщев в методичке про проведение One-to-one встреч:

Тимлид не просто «проводит» 1:1. Он приходит, чтобы выяснить, чем ещё он может быть полезен сотруднику. Такой подход называют ещё servant leadership — ты не командуешь с высоты, а стоишь рядом и помогаешь. Не отчитываешь, не контролируешь, а разбираешься, как сделать, чтобы человек работал лучше и не сгорал. Это целый навык, который не дают в комплекте с ролью тимлида.

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

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

Из известных мне примеров, которые вспоминаются сходу:
- Максим Дорофеев — достаточно полистать его старые посты в ЖЖ и более свежие в клубе, многое - вошло в основу серии книг по Джедайским техникам.
- Анатолий Левенчук - в своем блоге "думает письмом" на разные темы. Потом многое просто копипастится как драфт книги и причесывается. Вот пример, как начиналась книга "Образование для образованных" (там ближе к концу список постов, которые легли в её основу).
- Александр Бындю — Антихрупкость в ИТ - почти вся книга - аккумуляция постов на хабре и в его блоге (пример статьи на хабре), которая в основе первой главы).
- Тим Урбан
- ... список можно продолжать

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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