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

Описал(а) свой AS IS, чтобы прийти к целевому TO BE и стать новой версией себя

Провел(а) сбор и выявление требований к своей жизни, чтобы найти себя

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

Как мы при помощи техник фасилитации и управления конфликтами смогли помыть полки в холодильнике

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

Видишь Hold? — Нет. — А он там есть!

В workflow задачи не должно быть статусов “Hold”, “In Review”, “Awaiting for approval”, "Требуется информация", “На согласовании” и других заморозок.

Работа либо выполнена, либо нет

Сбор информации, рецензирование и согласование результата — это часть работы над задачей, фрагмент, а не отдельная активность. Если требуется явно показать, что другой участник дает ревью и выполняет работу над задачей, то правильным будет изменить поле исполнителя на него (=перевесить!). Когда рецензент закончит, то он самостоятельно должен перевесить тикет на следующего исполнителя или обратно на предыдущего, если нужно продолжить работу и тикет не переведен в "Done".

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

🥺 Если нельзя перевешивать, потому что "KPI трекается по времени удержания на исполнителе” или “это затраты другой команды” и происходит мультитаскинг… нужно всё перепроверить. Аналитика данных, построенная на таких workflow, часто способ избежать санкций и претензий за неэффективность, а не довести до конца работу качественно для получения настоящей эффективности. Дашборды и презентации есть, но фокус целей смещен.

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

Задачи в “Hold” и "Требуется информация" протухают, надо идти выяснять в каком состоянии данные и договоренности... и 9/10 случаев задачи из этих статусов не будут выполнены никогда. Уже насыпались новые задачи, все ушли решать другие проблемы, а блокеры никто не траблшутил, чтобы снять заморозку. При таких workflow культуры чистить и закрывать зомби-задачи не вырабатывается, потому что нет единого центра принятия решений, нет прозрачности подхода в работе. Если случайно потерять доску с такими задачами, то ничего не произойдет. Специалисты и так ей не пользовались, а договаривались лично в чатах и на звонках.

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

Никуда не делалась, просто отсутствие постов это пара причин

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

Нет достойных рассуждений — нет постов

Причина 2: я тоже своего рода Scrum😁
Выдаю инкремент в лучшем случае раз в 2 недели. Постов много быть не может.

Причина 3: я работаю. Канал и учёба всегда в овертайм после рабочего дня или в выходные. Это надо держать в правильном смешении.

//Но вот есть гифка, где нашла уке в офисе Нижнего Новгорода, когда была в командировке 👋

Что делать со стрессом

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

Чуть более года назад мне было очень плохо от работы. Задачи не сходились, переговоры не удавались, изменения никак не внедрялись вообще нигде: ни в системах, ни в процессах.
Работа вытеснила остатки радости и заняла всё пространство. Мысли о предстоящих встречах и вопросах не заканчивались даже ночью. Устойчивость 0
Любая мелочь выводила из себя, будто в организме закончилась последняя нервная клетка.

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

Суть очень простая:

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

Это единственное настоящее применение нейросетей в моей работе😁
А оценить результат можно ниже👋

Зависимость от платформ и инфраструктуры — болезненная тема. Это сложный вопрос как для развития бизнеса в горизонте 2-5-10 лет, так и в пользовательском уровне привычек, когда хочется включить что-то на фон.

Большинство сервисов на рынке ужасны. Однообразный копипаст-контент, бесконечный поток рекламы, захламленные интерфейсы, а порой и вовсе темные паттерны с манипулятивными сценариями, такими как невозможность отписаться и накрутка платных опций. А еще проблемы с безопасностью, утечки данных, gambling и мошенничество.
Кажется, за 50+ лет мы с обычной-то разработкой еще не очень разобрались, а тут АI добавляет новые проблемы.

Могла бы понять, если бы приложения были неприятным только снаружи из-за KPI, бюджетов, сроков и всего такого. Было бы даже забавно узнать о конспирологическом триллере "Почему сервисы такие отстойные?".
Но его нет 😋
Для самих специалистов само IT внутри едва ли более приятно. Тяжелая поддержка и развитие, Enterprise с выжимающими сроками, бездонный техдолг и легаси, хаос в процессах, а ещё регулярно срабатывающий Bus Factor и риски, которые вешаются на конечных исполнителей.

Это, конечно, с чем сравнивать. Так, например, за последние пять лет стоимость Ubisoft упала на 80%. Убыточность или близость к банкротству атрибут не только такого гиганта.
У нас есть пример с увольнением всех топ-менеджеров из-за падения выручки в компании «МойОфис» . Про другие сокращения, такие как ABBYY, тоже было слышно.
Но я не о том, что всё плохо, всех уволят, а о том, что рынок...пустой! Всё такой же дефицит хороших идей и компетентных людей.

Не носи тяжелый кошелек с собой! Нет пыли на полках дисков, книг и альбомов! Больше не нужны фотоаппарат, магнитофон и DVD! 
Нет длинных очередей — получай всё онлайн!

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

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

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

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

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

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

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

📖 Цель требований — определить желаемое поведение системы, чтобы заинтересованные стороны интерпретировали его более или менее одинаково.

📕 Требование — это спецификация того, что должно быть реализовано.

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