🧨 Ответственности за изменения пост

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

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

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

Фигня в том, что просто указание на проблему порой ничего не стоит. Особенно — если таких проблем десятки и сотни (и это нормально! Значит есть куда расти!).
Чтобы изменение произошло — неизбежно нужно пройти этап аналитики, "приземления" идеи на существующую реальность. И в процессе приземления идея может развернуться на 180 градусов, а то и в нескольких плоскостях!
Часы вместо сторипойнтов используются неспроста. У оценщиков есть свои выработанные привычки и мотивы оставить всё как есть. Плюс смена должна тянуть за собой переписывание кучи отчётного софта. Просто потому что.

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

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

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

😇 Открытости пост

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

"как я уже не раз говорил, надо сделать НОРМАЛЬНО"
"наши партнёры занимаются полной хуйнёй вместо того, чтобы работать как мы"
"он ничего в жизни не добьётся с таким подходом!"
"это решение — днище"
"наши сотрудники как курицы, их надо пиздить"

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

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

💥 работа по созданию изменений

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

Сейчас я ищу человека, который поможет мне с организацией изменений https://telegra.ph/fyvfv-07-19 и заботой о сотрудниках.
Если вам близко то, о чём я пишу или вы, возможно знаете такого человека — пишите!

🍻 преодоления стен пост

И они такие сначала: давайте сделаем отдел дизайна, отдел тестирования и отдел разработчиков.
А потом "чото они начали требовать постановки задач строго по форме и как будто противопоставлять себя менеджменту? Мы так-то хотим вовлечения в результат от исполнителей!" — и эта боль очень понятна!
Ок, перестраиваем, делаем продуктовые команды. Люди больше вовлечены в то, что они делают. Теперь у нас гора велосипедов, зоопарк технологий и разрозненность специалистов. Всяк фронтэндер свой фреймворк пилит.

Ладно фреймворк, а если у вас реальный сектор где переделка изделий стоит самую малость капитально дороже?

C рассинхроном призваны бороться гильдии (они же проф сообщества, они же community of practice и много других страшных слов) и внутренние митапы. Но, блин, сложно. Сложно найти лидеров, выбить ресурсы на всю эту движуху и направить это в конструктивное русло.
К чему я это.
Мы в knowledgeconf готовим митап про гильдии. Спикеры опытные, ведущая - огонь.
Если у вас болит эта тема как у меня - приходите!

♦️ У меня есть бесценный опыт!

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

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

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

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

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

IDE для markdown/XML

А тем временем JetBrains что-то готовит:
https://lp.jetbrains.com/stardust-landing/
На лендинге есть ссылка для того, чтобы подписаться на Early Access Program. Верим, надеемся, ждём 😌

🧳 Онбординг, оффбординг и, внезапно, отпуска

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

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

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

https://unigraph.dev/
Смотрите, какая интересная пепяка заявлена для организации личной базы знаний.
Join waiting list, однозначно!