Bear's Rambles | МЕДВЕДЬ ГОВОРИТ...

Проектирование интерфейсов
Серия 03. Работа с пользователями

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

Но тем не менее, небольшой чек-лист в свободной форме.

▪️После описания пользовательских сценариев проследите как именно они проходят в текущей реализации.

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

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

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

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

▪️Не верю, что пишу это, но: всегда проводите демонстрацию функционала самостоятельно.

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

▪️Будьте готовы объяснять

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

▪️Как минимум первое время после внедрения отслеживайте действия пользователей.

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

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

#медведьразмышляет #проектированиеинтерфейсов

Проектирование интерфейсов
Серия 02. (Не)важность визуальных форм.

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

Из мира бизнес-приложений на законы UX/UI открывается одна очевидная проблема — на них всем (почти) похрену. Функциональность всегда будет превалировать над красотой или удобством. Интерфейс будет иметь значение только если возможности системы не уступают конкурентам. Да и ПО зачастую выбирают не те люди, которые будут им потом чаще всех пользоваться. С наиболее жёсткими требованиями к интерфейсу команда разработки будет сталкиваться в инхаус-формате, когда заказчик имеет непосредственное влияние на конечный продукт.

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

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

➡️Минимизация визуального шума. Раскрашивать интерфейс во все известные цвета - плохо. Красный/жёлтый/зелёный идеально подходит для выделения важности, степени проёбанности или указания куда нажать, чтобы случилась магия. Если уж надо что-то прям разукрасить — мягкие цвета, максимально близкие к общей цветовой гамме. Много пиктограмм - плохо, особенно если понимание их смысла требует лупы.

➡️Концертировать пользовательское внимание в привычных областях и в привычном порядке. Человек уж так устроен, что ему удобно смотреть в центр чего-либо, в данном случае - монитора. Именно там следует фокусировать наиболее частые пользовательские действия. Место по краям - преимущественно для информации или навигации. Вверху или слева - для важной, внизу и справа - для второстепенной (может отличаться для культур, где принят иной порядок письма, или маководов).

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

➡️Подчинение сценариям. Связанные действия должны располагаться рядом. Вариации объединяться в группы. Порядок выполнения тоже имеет значение: неправильно размещать поле подбора контрагента после кнопки "Выставить счёт".

В некотором смысле создание интерфейса бизнес-приложения всегда война с пользователем. К примеру, в топе частых фраз, которые слышат 1Сники за последние несколько лет, прочно обосновалась "а вот в SAPе..." Стремление заказчика к привычному иногда может доходить до фактического бойкота, а требования добавить "ещё колонку" со временем превращают лаконичный список достаточной информации в простыню из данных, которую необходимо крутить во всех направлениях. И это опять понижает удовлетворённость пользователя от продукта по вине самого же пользователя. Этакий замкнутый круг. Работать с этим сложно, но можно. Как — в следующих сериях.

#медведьразмышляет #проектированиеинтерфейсов

Проектирование интерфейсов
Серия 01. Определяем сценарии.

Способов, методов и прочих подходов к созданию use cases на самом деле хватает, я не буду грузить пересказами условного JTBD или CustDev один-в-один — тем более, что Вы можете это прочитать сами. В гораздо более авторитетных источниках. Тем более, что я-то и не очень хорошо их помню.

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

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

Главное — соблюдать атомарность: не пробрасывать утверждение от точки входа в один сценарий к точке выхода из другого

Определение подходящего утверждения даёт понимание сразу двух свойств

▪️Назначение. Информация или функция. Характеристика точки входа в сценарий
▪️Залог. Почему залог? Потому что активный или пассивный. Это не совсем идентично грамматике, но я уже как-то писал: мы, разработчики, обожаем пиздить чужие слова, чтобы понемногу менять их смысл в своих целях. Активный подразумевает активацию функциональности внутри используемой системы, пассивный — пользователь просто оценивает или переиспользует вне системы некую информацию

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

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

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

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

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

Еще очень важная характеристика сценариев — связность. Это когда точка выхода из одного сценария означает точку входа в другой. Я выделяю два вида

▪️Туннель — когда действия пользователя удобнее и возможно выстроить таким образом, чтобы он не покидал одного слоя доступности. Как правило связаны с многоступенчатым получением разнородной информации (поиск контрагента, его данные, открытые сделки, приоритетные товары/услуги, доступность товаров, информация по аналогам) и последующим выполнением небольшого количества тесно связанных по смыслу, но архитектурно с точки зрения системы обособленных действий (выставление счёта, заказ недостающего объёма товаров, бронирование товаров в наличии)

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

#медведьразмышляет #проектированиеинтерфейсов

Проектирование интерфейсов.

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

Лучший способ дать понять окружающим, что Вы нихрена не шарите в разработке интерфейсов — сказать UI/UX.

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

UX - это User Experience - пользовательский опыт. В широком понимании те самые Use Case, влияющие на систему целиком: её архитектуру и логику.

Это не значит, что UI не важен - конечная удовлетворённость пользователя зависит именно от него, но UX - всегда первичнее. Поэтому только UX/UI.

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

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

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

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

Внедрение интерфейса - это про борьбу привычного и нового.

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

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

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

#медведьразмышляет #проектированиеинтерфейсов

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

На самом деле Паук-Нуар — это сериал-противоречие.

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

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

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

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

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

Как итог - 9 медведей из 10. На волне свежести, логичности почти всего, что происходит на экране, выдержанной атмосферы и отличного исполнения от Николаса Кейджа.

#медведьрекомендует #посмотреть

Пытаемся сохранить команду в условиях финансовых ограничений

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

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

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

В случае сокращения есть два традиционных пути, позволяющих сбросить градус накала
➡️Найти функциональность, от которой можно отказаться или обеспечиваемую излишним количеством людей. Вариант хорош наличием очевидной связи: команда уменьшается вместе с нагрузкой
➡️Найти добровольцев. Можно объявить конкурс на выход и на общем собрании, или предложить на ТаТ людям, чей уход назрел давно. Главное - чтобы не захотели свалить слишком многие😂

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

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

Да, не все ответы могут команде понравится - и это нормально. Клише: горькая правда лучше, чем сладкая (полу)ложь. Также это относится и к тому, что некоторые руководители пытаются выставить себя в лучшем свете, мол граждане, стараюсь, делаю всё что могу, думаю, всё будет заебись🤦🏻‍♂️

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

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

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

А вот при самовольном бегстве реинвестирование может оказаться действенным заградительным механизмом от дальнейшей текучки: повышением уровеня дохода затрудняется поиск более выгодных условий. Реинвестирование по своей природе финансово более приемлемо, чем попытка остановить уходящего человека повторением оффера - деньги не берутся из воздуха, да и экономия ещё возможна — никто не заставляет реинвестировать 100%. В общем, это хорошее промежуточное решение, если компания не хочет или не может заместить ушедших с рынка.

#медведьразмышляет #управление

Онбординг. День первый

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

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

Должно сделать сильно заранее (и это вообще-то не только про онбординг)

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

Заблаговременно - то есть за время, необходимое для реализации, озаботиться следующим

➡️Создать корпоративную учётку. Не забудьте проверить доступы.
➡️Определить проекты, на которые будет направлен сотрудник
➡️Реализовать доступ к проектам. Добавить пользователей в базы и репозитории.
➡️Реализовать доступ к вспомогательным инструментам. Если есть.
➡️Подготовьте рабочую технику и место. Если надо.

Тут можно возразить — а что если новичок не выйдет в свой первый рабочий день? Ну что ж, бывает. Работа проделана зря. Придётся удалять пользователей и всё прочее. Примерно в 1% случаев, если не реже. Беда, блять, невероятная.

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

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

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

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

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

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

Сразу добавьте сотрудника во все периодические общекомандные встречи, которые у Вас есть.

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

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

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

#медведьразмышляет #управление

ТаТ
Серия 04.

04.1. Взгляд с обратной стороны.

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

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

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

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

Если Вы часто "подчищаете" за кем-то из коллег — обратите внимание на это. Подчеркните, что до 1-1 у Вас уже был разговор с коллегой, но ошибки продолжаются.

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

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

У всего перечисленного есть одно общее — оно всё не срочное. Практически всегда это терпит один-два месяца. Но если у Вас какие-то проблемы, не терпящие отлагательств, запрашивайте 1-1 самостоятельно.

04.2 Краткий итог.

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

Если на 1-1 Вы встретились с критикой, то есть 3 пути
▪️объяснить свою точку зрения
▪️аргументировано отстоять свою позицию
▪️согласится с критикой, сделать выводы и использовать эти выводы в дальнейшем.

Да, в списке нет "убежать поплакать" или "обидеться на крысу, которая меня сдала".

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

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

THE END.

Ну и в конце маленький перечень-напоминание предыдущих серий.

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

#медведьразмышляет #управление #ТаТ

ТаТ.
Серия 03. Памятка руководителю

03.1 Как подготовить команду к встречам?

Что ж, Вы - руководитель. И Вы решили: ТаТу быть! Как настроить команду на нужный лад и не посеять паничку? Что нужно донести?

1️⃣ТаТ — способ сделать работу более продуктивной малой ценой. Если Вы никогда раньше не проводили 1-1, то сразу скажите, что будете рады полноценной обратной связи после, чтобы улучшить навыки. Добавьте сомнения "это хорошая практика, давайте посмотрим как пойдёт и к чему приведёт"

2️⃣Обозначьте вопросы
➡️фидбэк по всем рабочим моментам, не только сверху-вниз, но и в обратном, а ещё и в горизонтальном направлении
➡️обсуждение курса развития сотрудников: карьерного, профессионального.

3️⃣Сформулируйте условия
➡️Откровенность
➡️Конфиденциальность

4️⃣Дайте понять, что если нет обратной связи - это не проблема, не надо её высасывать из пальца.

03.2 Как построить встречу?

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

И вот что я Вам скажу - это всё херня, которая с большой вероятностью вызывает две реакции:
➡️раздражение "ты прям серьезно думаешь, что я не вижу что ты делаешь?"
➡️удивление "тебе реально блять интересно сколько котят у меня кошка родила пятнистых, а сколько — монохромных?"

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

Знаете, какая охуительная стратегия? Старкрафт Есть ход намного сильнее: сначала обсуждаете рабочие вопросы, а в конце встречи, если у Вас осталось время - а если нет, то планировщик Вы так себе - толкаем речь в духе "слушай, нам надо было обсудить много важных вопросов, я не был уверен, что успеем, поэтому начал с них, но мы продуктивные молодцы, а времени у нас из запланированного еще осталось, как у тебя дела?" - и вот тут уже можете или взять готовые подсказки по из серии "как показаться подчинённому чутким и внимательным", ну или придумать свои, из предыдущего опыта слушай, у тебя же в прошлом году рак вырезали, чё, не вернулся?

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

Ну а взамен вот Вам пара идей

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

▪️Дайте положительный фидбэк от коллег/заказчиков/руководителей выше/тупо от себя — ничего так не настраивает на позитивный лад, как похвала. Тем более, будет простой переход к негативу, если он есть: "ты красавчик, но блять..."

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

Миксуйте по обстоятельствам.

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

03.03 ТаТ в процессе онбординга

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

1️⃣Две недели. Новичок более-менее вкатился в процессы и немного поработал, очевидно есть какие-то мнения, вопросы

2️⃣Два месяца. Сотрудник — уже сотрудник. Въехал в проекты, круг задач. На этом этапе логично узнать, какие задачи ему нравятся, какие - нет. Возможно, уже что-то провисает. И ещё есть возможность что-то исправить

#медведьразмышляет #управление

ТаТ.
Серия 02. Подсказка руководителю: как подготовится самому.

Секрет подготовки к 1-1 достаточно прост: большая часть - это фоновая работа. И начинаться эта работа должна с самого первого дня, когда руководитель таковым стал.

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

Шаг 2.
Фоновое отслеживание перфоманса. Мы привыкли, что подобные ревью если и проводятся, то с определённой периодичностью и привязаны либо к окончанию ИПР, либо к окончанию календарного/карьерного года/полугодия. Но умение отслеживать проблемы в реальном времени - это очень важный скилл. Да и корректировка навыков между ревью полезна не только в разрезе развития сотрудника, но и вообще для эффективного управления.

Шаг 3.
Составление профайла сотрудника. В него заносим обратную связь от заказчиков и коллег. Наблюдения за взаимодействиями. Именно ещё и поэтому заменять ТаТами командные встречи на постоянной основе - плохая идея. Руководитель не может наблюдать той самой химии или её отсутствия между подчинёнными, кто с кем удачно взаимодействует, а с кем вообще предпочитает не разговаривать Это помогает не надеяться на то, что кто-то признается сам, а составлять картину самому.

При этом всё таки надо держать в уме: есть триггеры, которые еще не триггеры, а есть те, которые уже набатный звон.

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

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

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

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

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

P.S.
В планах еще как минимум две серии

03. Памятка руководителю: как подготовить команду и чек-лист как стоит и не стоит вести ТаТ
04. Памятка подчинённому

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

#медведьразмышляет #управление

ТаТ
Серия 01. Какие могут быть варианты?
Контекст - в посте выше

1-1 могут инициироваться разными способами и с разной периодичностью

1️⃣Регулярные частые встречи

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

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

Но куда ж без минусов
▪️Время. На команду из 10-15 человек можно обойтись двумя еженедельными встречами: суммарно часа на полтора. Даже короткие 15 минутные встречи займут от 2.5 часов до почти 4 часов.
▪️Потеря экспертизы. Когда задачи обсуждаются 1-1, а не общим кругом - нет возможности переиспользовать чей-то опыт. И если в случае опыта на текущем месте руководитель может быть в курсе и подсказать, что кто-то уже решал такую задачу, то о предыдущем опыте в курсе только сам сотрудник.

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

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

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

2️⃣Нерегулярные встречи

Зачастую есть люди, которым ТаТ не нужен как таковой: человек работает в своей колее, у него есть план и он его придерживается. В таком случае 1-1 назначаются "по запросу", когда есть что обсудить. Из минусов - для подчинённого подобный внезапный ТаТ всегда будет каким-то дополнительным стрессом: гадай ещё, чё это там этому от меня понадобилось?

Совет➡️как бы руководителю не казалось, что сотрудник хорошо справляется без него - всё равно назначайте 1-1 с определённой периодичностью, не создавайте у подчинённого впечатление, что его забыли

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

3️⃣Регулярные встречи с низкой частотой

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

Совет➡️дождитесь и почитайте следующую серию

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

#медведьразмышляет #управление

Бывает так, что ты ищешь тему. А бывает так, что тема находит тебя.

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

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

Поскольку тема объёмная, то я буду использовать обозначения 1-1, ТаТ просто для экономии символов.

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

Итак, ловите сериал. Да, это будет несколько серий.

Серия 01. Какие могут быть варианты? Немного о том, с какой периодичностью и регулярностью их стоит проводить и почему. Выйдет сегодня минут через 30. Если предложка ничего не напутает

Серия 02. Учимся извлекать пользу, а не превращать в раз-на-раз. Рекомендации, как провести встречу эффективно, а не тупо попиздеть о погоде. Выйдет завтра.

Возможно, вторая часть выйдет в разбивке отдельно для руководителей и подчинённых. Это я решу попозже: досконально промерить её размер и весь материал не успелось. Футбольный матч идёт 90+15 минут, а винишко имеет свойство заканчиваться.

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

ТаТ - это определённо то искусство, которому стоит учится. А ещё - софт-скилл руководителя. То есть умение их проводить качественно влияет на выполнение прямой функции - эффективно управлять людьми.

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

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

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

Такой подход требует от руководителя определенных навыков
▪️умение держать много информации в голове
▪️умение быстро реагировать на сигналы вне зависимости от обстоятельств: если на сигнал от одного сотрудника реакция идёт быстрее, чем от другого - это залёт, воин

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

Погнали.

#медведьразмышляет #управление

Хороший способ сделать поход в кино приятнее

Итак, наступил май, приближается лето. Что это значит?

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

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

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

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

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

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

Из того, к чему надо быть готовым: свободное место, даже если на нём лежат куртки, всегда кто-то норовит отжать.

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

Но есть те люди, которые хотят за счет этого места улучшить собственные "жилищные условия":
▪️я сюда пересяду, здесь всё равно никто не сидит, а к центру ближе
▪️могут просто положить свою сумку/куртку к Вашим, а потом долго возмущаться: а чё такого, оно же никому не мешает?

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

Вот, пользуйтесь

#медвежьиинсинуации

Купить или строить?

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

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

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

1️⃣Посмотрите на команду. Если Вас два калеки - Вы и сисадмин - покупайте

2️⃣Оцените область и компетенции. Сейчас речь даже не о компетенциях команды разработки, я и про компетенции людей, обеспечивающих процессы. Если область жёстко регламентируемая, а компания не обладает достаточными ресурсами или экспертизой для отслеживания изменений, их оценки, составления задания на доработку и реализацию (вот это уже про ИТ-департамент) - покупайте

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

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

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

Это базовые моменты, но какие практические следствия из одного или другого варианта автоматизации?

Инхаус-разработка
➕Увеличивается скорость реакции на требуемые изменения за счёт
▪️меньшей кодовой базы и общей сложности кода - готовые решения (если мы говорим про бизнес-приложения) содержат значительный объем функциональности, зачастую реализованный таким образом, что внедрится в него сложно
▪️обладания полными знаниями о проекте командой разработки
➕Более точная настройка ПО под существующие бизнес-процессы, а не наоборот
➕Сохранение чувствительных данных внутри компании
➕Проще расширять и масштабировать
❌Необходимость чётко документировать все процессы, связанные с разработкой: в случае потери информации - будет не у кого узнать «а почему так?»
❌Долгое погружения в проект: новым сотрудникам потребуется больше времени, чтобы выйти на уровень своей привычной эффективности

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

Если попытаться как-то подытожить эту на самом деле непростую тему, то есть две лёгких точки принятия решения
1️⃣Денег - много. Процессы - стабильны и не новы для рынка. Область - зарегулирована и/или критична. Выбираем покупку с полной поддержкой. Проблемы с конфиденциальностью можно решить NDA и помещением софта в собственный контур безопасности
2️⃣Автоматизируемый процесс является вспомогательным для компании и на рынке не существует 100% устраивающего решения - можно дать команде разработки поиграться,

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

#медведьразмышляет

Спроси меня правильно.

Казалось бы, что может быть проще, чем задать НОРМАЛЬНЫЙ вопрос пользователю? А вот оказывается, что для некоторых это сродни ракетостроению

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

⚠️В поле введены некорректные данные.

Варианты продолжения диалога

Продолжить ввод - Отменить ввод

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

И что тут не так?

Ну для начала — неинформативно. Так же, как и в случае с простым оповещением, информация - ключ к пониманию. Почему данные некорректны? Добавьте пояснение: Вы ввели лярд в поле, в котором максимальное допустимое значение - 1. Уже понятно и пользователю будет проще сориентироваться, что ему надо сделать.

Второе. Неоднозначность трактовки. По мне так Продолжить ввод означает Если нельзя, но очень хочется - то можно. То есть вроде как не лезет, но если поплевать и надавить - войдёт. Но по факту - нет. Меня просто вернёт обратно в место ввода. Где я опять нажму Enter - и опять попаду на тот же вопрос. Он даже не поинтересуется у меня не идиот ли я, если упорно пытаюсь ввести тоже самое кривое значение дважды😔

Суть в том, что в этой ситуации вопрос (а это вопрос, мы уже разобрались) - тут не нужен совсем. Нужно оповестить пользователя

Вы ввели некорректное значение. Введите число в пределах от 0 до 1.

И один вариант

ОК

Вообще у вопросов, которые мы задаём пользователю, есть два золотых правила

1️⃣Не используйте отрицание в вопросе. Тот самый недопарадокс

Вы не хотите?

Варианты ответа

Да, не хочу - Нет, не хочу

2️⃣Суммарно в вопросе и вариантах ответа слово "отмена" и однокоренные могут быть использованы ровно один раз.

Если Вы это сделаете, то есть вероятность: ногу Вам отгрызёт кровожадный лемминг. Отменить?

Варианты ответа

ОК-Отмена

Что произойдёт, если я нажму ОК? По идее — отмена. Но тогда зачем Отмена? Я отменяю отмену и ногу мне всё таки отгрызут? В общем, Отменить? + Отмена прям в топе неоднозначных трактовок.

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

Помним и про информативность - пользователь должен понимать, что именно поставило его перед столь сложным выбором.

Вы добавляете в геном лемминга безбашенность медоеда и клыки саблезубого тигра. Вырастить эту чудовищную тварь?

Варианты ответа

Да-Нет-Отмена

Вуаля! Пользователь сразу и однозначно понимает и какое критичное изменение происходит, и какая ветка процесса пойдет дальше в случае каждого из вариантов ответа
Да - изменение происходит, животное появляется
Нет - изменение происходит, животное не появляется, можно продолжить и добавить, предположим, ленивца - и хрен что эта тварь кому сделает, потому что лень
Отмена - изменение не происходит

Если действие уже выполнилось без возможности отката - не может быть и отмены.

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

Где завтра взойдёт солнце?
Нажмите Да, если считаете, что на востоке
Нажмите Нет, если считаете, что на западе
Нажмите Отмена, если считаете, что оно не взойдёт

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

#медвежийкодстайл

Информирование пользователей

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

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

Давайте посмотрим на простом примере

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

Некорректная дата платежа

«Чё ты доебался?» - спросит кто-то, ведь понятно же, что накосячили в дате платежа. Ну ок. А в чём именно? Как исправить? Каким должно быть значение, чтобы всё прошло на ура?

Сравните.

Указанная дата платежа - 22.04.2026 - не совпадает с установленными платёжными периодами для <Организации>/<Контрагента>/<Типа операции>. Измените дату платежа таким образом, чтобы она совпадала с платёжным периодом. Ближайший доступный период 27-30.04.2026. Или измените статус платежа на «срочный»

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

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

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

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

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

Не вводите пользователя в заблуждение - очищайте историю сообщений

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

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

При этом, если изменяемые по зависимости данные уже заполнены, пользователя лучше об этом информировать:
👉предупреждением до изменения, если данные объемные (таблицы)
👉если изменяемые по зависимости данные
▪️находятся в поле видения, но разнесены с изменяемыми пользователем — краткосрочным выделением цветом
▪️находятся вне видимости (на другой странице) —сообщением об изменении
👉сообщением о сбросе значений

Еще небольшой чек-лист:
▪️если сценарий подразумевает выполнение исчислимого количества операций в фоне - информируйте пользователя о ходе прогресс-баром
▪️если сценарий подразумевает выполнение в фоне — сообщайте об окончании процесса так, чтобы это было заметно из любой формы

ну наверное в
#медвежийкодстайл

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

Некоторое время назад я достал из своей памяти замечательные и недооцененные книги и сериал "Штамм". И одновременно с ней всплыла еще одна книга, у которой тоже есть экранизация - "Мировая война Z".

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

У книги Макса Брукса есть экранизация. Даже с Бредом Питтом. Ну как, экранизация... Скорее что-то, снятое по итогам игры в очень сильно испорченный телефон. Как говорится: в фильме использованы персонажи, разработанные Максом Бруксом. Оценки у фильма неплохие (я даже проверил, и Кинопоиск и IMDB дают ровно 7), но... Не знаю, наверное что-то подобное испытывали фанаты Стивена Кинга при просмотре "Тёмной башни" с Макконахью и Эльбой. Кино реально неплохое, но по сравнению с первоисточником - невероятно бледное.

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

В книге герой, ставший главным в фильме — вообще не герой. Он фон. В оригинальном издании у книги есть подзаголовок: An Oral History of the Zombie War - Устная история войны с зомби, который в российском издании пропустили.

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

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

Мой вердикт
👉книге: 9 из 10, читать обязательно
👉фильму: б/о, я не могу оценивать его в отрыве от бумажного первоисточника, поэтому так. Если Вы не читали, и не смотрели - сначала посмотрите, в целом фильм не плохой, он говно как экранизация, а так оценка агрегаторов - 7.0 - в целом оправдана.

#медведьрекомендует #почитать

Ну что ж, если кому показалось мало предыдущего функционала, то можно наметить ещё кучку немного требований:
▪️Быстрая навигация. Хотелось бы, чтобы получилось перемещаться между ближайшими связанными «узлами» в один клик.
▪️Шаблоны и проверка качества данных. Для удобства заполнения и чтобы пользователям было сложнее накосячить с вводимыми данными.

Это кроме очевидного: версионирование, поиск (полнотекстовый и фасетный) и прочих мелочей.

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

Ну и куда же мы видим развитие ЕАР в дальнейшем
⭐️Интеграции с какими-нибудь таск-треккерами. Куда же без них. Очень хочется не создавать каждую задачку лапками, а получать их просто так.
⭐️Контроль внутреннего SLA. Это когда каждое действие в системе по заполнению данных в сущностях должно быть выполнено не позже определённого срока.
⭐️Контроль здоровья системы. Чтобы не висели сущности без связей или к устаревшим сущностям не вели пути-дорожки.
❓Подключение генеративных моделей для расширения функционала. Ну хотя бы для написания ТЗ (мечта Романа, включил только ради него, может он всё таки что-то мне ответит)
❓Интеграции с репозиториями. Тут не очень бы хотелось заставлять разработчиков заходить и по каждой задаче что-то выкладывать, было бы здорово использовать подход Docs-as-Code.
❓Добавление «веб-морды» на 1С:Элементе. Не знаю, насколько вообще оно надо, мой интерес - просто пощупать в псевдобоевой обстановке.
❓Векторные или графовые БД. Ну поскольку ЕАР - поделка на 1С, то и использовать мы будем реляционную БД, но для подобных задач она не то, чтобы прям очень оптимальна. Поэтому раз уж предыдущим пунктом идёт фантазия про 1С:Элемент, почему бы не пофантазировать и на эту тему.

Ну и какой же проект может обойтись без рисков? Правильно, никакой.
⚠️Пока я чувствую себя идиотом и не очень хорошо представляю, как можно сделать подобную штуку БЫСТРОЙ в рамках1С+ SQL (не принципиально какой). Возможно, это легко. А может и нет. Надо начать думать плотнее.
⚠️Сроки. Вот вообще не понятно пока, что войдёт в MVP даже, не говоря уже про то, когда оно будет готово. Команда всё таки раз-два и обчёлся (в самом что ни есть прямом смысле), да и даже до двух не всегда получается посчитать, да Роман?

#МедведьДелаетЕАР

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

Вполне очевидно: ЕАР должен иметь два основных «хребта» связи информации: с метаданными и с бизнес-процессами.

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

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

Основной родительский слой обеспечивает связность всех остальных и использует описание цепочкой
Бизнес-роль ➡️ выполняет➡️ Бизнес-процесс➡️ поддерживается ➡️ IT-сервисом ➡️ реализуется➡️ Узлом инфраструктуры.

Слой бизнес-процесса должен поддерживать иерархическую декомпозицию Процесс➡️Подпроцесс➡️Шаг

Слой решения описывается моделью C4 Context➡️Container➡️Component➡️Code.
Уровень Context в этой модели совпадает с IT-сервис в родительском слое, и по сути, расширяет Узел архитектуры до конкретного решения.

Почему именно так? Ну это упрощенный набор базовых подходов - ArchiMate, BPMN и С4 - де-факто являющимися стандартами в IT-индустрии. Они чётко структурированы, позволяют легко проводить масштабирование и использовать навигацию zoom-in/zoom-out. Ну и обеспечивают должное понимание на необходимых уровнях заинтересованности и для бизнеса, и для ИТ.

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

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

Бизнес-роль BR-
▪️Описание выполняемых функций
▪️Положение в структуре компании
▪️Текущий исполнитель

Бизнес-процесс BP-
▪️Степень критичности Насколько процесс важен для компании. Достаточно относительной степени сравнения (обычный, важный, очень важный), но необходима опциональная возможность добавить SLA/RTO/RPO
▪️Триггеры События, запускающие процесс
▪️Описание входов/выходов процесса

Элемент архитектуры ARC-
▪️Tech owner Кто отвечает за разработку и поддержку.
▪️Точки интеграции Предоставляемые и получаемые.
▪️Этап жизненного цикла

Задача TASK-
▪️Приоритет
▪️Тип Новый функционал, техдолг, интеграция, аналитика.
▪️Контекст

Решение ADR-
▪️Процесс принятия решения Рассмотренные варианты, обоснование выбора, ответственный за принятие решений, дата принятия решения, автор/исполнитель принятого решения
▪️Известные последствия Техдолг, безопасность, производительность, нетипичная работа с данными
▪️Связь с замещающим решением

Точки интеграции INT-
▪️Компоненты
▪️Направленность
▪️Протокол/механизм
▪️Формат данных
▪️Ответственная команда
▪️Описание спусковых механизмов
▪️Описание контракта

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

Утверждён график выхода ближайших серий
10.04 - ЕАР. Концепция. Часть III. Точки роста и риски.

#МедведьДелаетЕАР

Я знаю, что Вы соскучились и заждались😂 Уже очень давно я и Роман Данилов анонсировали совместный пет-проект и вот — чудо, не иначе — первая серия этого реалити-шоу.

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

Встречайте! ЕДИНЫЙ АРХИТЕКТУРНЫЙ РЕПОЗИТОРИЙ и его концепция! если кто не понял, подсказываю: Вы в восхищении!

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

Ниже будет шпаргалка на случай если ты, мой дорогой читатель, ещё пытаешься понять, какие проблемы решаются с помощью ЕАР

➡️Фрагментация данных.
Информация о БП, задачах, архитектурных решениях, интеграциях хранится в разрозненных источниках: таск-трекерах, wiki-системах, переписках, головах ключевых сотрудников. Как результат — при ротации команд, увольнении сотрудников значительная часть контекста сваливает вместе с его хранителями.

➡️Отсутствие прослеживаемости.
Ответы на вопросы
▪️Какие IT-системы отвечают за определённый процесс?
▪️Какие процессы затронет планируемое изменение?
▪️и обычное человеческое "Нахрена мы это сделали?"
приходят не то, что долго, а могут не прийти вообще.

➡️Разрыв между бизнесом и IT.
Бизнес-заказчики и команда разработки использую разные инструменты для описания и оценки и не имеют единого взгляда на IT-ландшафт целиком

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

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

Бонусом к уже описанному и как следствие — всё увеличивающийся пиздец в виде
▪️нарастающего техдолга
▪️увеличения Time-to-Market новых фич
▪️рост стоимости поддержки и развития ПО
▪️системные ошибки при оценке изменений

Итак, фиксируем достижимую выгоду от нашего щеночка

➡️Стратегическую
▪️Снижение потери знаний при ротации команд, сокращение времени онбординга
▪️Повышение качества принимаемых решений
▪️Повышение прозрачности для бизнеса

➡️Операционную
▪️Повышение согласованности архитектурных решений
▪️Повышение уровня переиспользования архитектурных решений
▪️Упрощение доступа к историческим данным

➡️Техническую
▪️Непрерывное обогащение знаниями через интеграции с таск-трекерами

Утверждён график выхода ближайших серий
08.04. - ЕАР. Концепция. Часть II. Хоть какие-то требования
10.04 - ЕАР. Концепция. Часть III. Точки роста и риски.

#МедведьДелаетЕАР