☀️Пятничный дайджест историй
Иногда вместо экспертных статей пишу истории "около IT" . Обычно эти тексты занимают у меня больше времени, чтобы личный опыт превратить в слова. Собрала здесь несколько текстов, вдруг вы пропустили что-то из этого?
📌История про детство и компьютер (который в детстве мне казался магическим и даже вредным, хотя у него было собственное имя)
📌 Аналитик с опытом может быть новичком! (о нюансах онбординга, зонтике в шкафу и ностальгии)
📌 Давний пост о мотивации и ориентире на результат (с цитатами из мультика и семейными историями)
📌 Как из меня не получилось звезды учебного ролика (и вообще не удалось быть собой)
📌 Учебный год и офферы (о фото в семейном архиве, пишущей машинке и опыте преподавания)
Может, у вас было что-то похожее? Делитесь!
#истории
Иногда вместо экспертных статей пишу истории "около IT" . Обычно эти тексты занимают у меня больше времени, чтобы личный опыт превратить в слова. Собрала здесь несколько текстов, вдруг вы пропустили что-то из этого?
📌История про детство и компьютер (который в детстве мне казался магическим и даже вредным, хотя у него было собственное имя)
📌 Аналитик с опытом может быть новичком! (о нюансах онбординга, зонтике в шкафу и ностальгии)
📌 Давний пост о мотивации и ориентире на результат (с цитатами из мультика и семейными историями)
📌 Как из меня не получилось звезды учебного ролика (и вообще не удалось быть собой)
📌 Учебный год и офферы (о фото в семейном архиве, пишущей машинке и опыте преподавания)
Может, у вас было что-то похожее? Делитесь!
#истории
❤1👍1
Здесь должен быть текст. Профессиональный UX-райтинг
Майкл Дж. Меттс, Энди Уэлфл, 2024
Эту книгу я привезла в начале года с одной из конференций, тогда мне хотелось подрастить в себе UX-писателя. Вышло так: талант писателя прорастал сам как чертополох, а книга несколько месяцев лежала в упаковке. Так и лежала бы пока в июне я не оказалась на несколько часов в поезде вместе с этой книгой. Теперь в ней есть пометки и выпадающие из переплета листы, а у меня – новые ответы на вопросы о пользовательском опыте.
Книга о том, как создавать тексты в интерфейсах от создания стратегии до вопросов взаимодействия с командой разработки. Написано ясно, легко читается. В тексте есть примеры, отсылки к конкретным приложениям и историям. Один из авторов приводит примеры из написания текстов, которыми чат-бот общается с пользователями, есть интересные моменты: несложные, но такие, что не замечаешь пока кто-то не покажет. Для меня минус книги в том, что мысли объясняются много раз, разными словами и еще обобщаются в конце разделов. Если у вас уже есть опыт в UX, то может выглядеть раздражающе.
Перевод вышел через 4 года после оригинального издания в 2020 году и это заметно по некоторым отсылкам к статистике 2018-2019 гг. и примерам. Немного странно читать что-то капитанское вроде: "теперь не нужно выходить из дома, чтобы пополнить банковский счет" 😉
Что может быть полезно?
Особенно меня подкупило с каким уважением к работе с текстом пишут авторы. Одна из первых глав называется "Не извиняйтесь за себя" и в ней говорится о фокусе и значимости разных ролей при проектировании пользовательского опыта. И в том числе о важности текста.
Есть простые и рабочие практические советы по изучению контекста, в котором нужны слова и подсказки, по составлению ясных текстов, которые бы отвечали на запрос пользователя так как его понимает сам пользователь, а не как диктует ваш собственный опыт (что часто замечаю за аналитиками в подобных задачах). Похожие общие тезисы записывала когда-то в посте о конференции UX-редакторов.
Для меня особенно ценны примеры из практики. Меня давно занимала история с Playstation, у которой пульт общается с пользователями крестиком, кружочком и треугольником. Японский дизайнер полагал, что в принятии решений люди всегда понимают кружочек как "да" и крестик как "нет", но оказалось, что это однозначно работает только в японской культуре, а при выходе на другие рынки началась путаница.
Интересно было почитать об инклюзивности и доступности. Каким должен быть текст и как расположен, чтобы он работал при использовании скринридеров, которые превращают текст на странице в аудио?
Если вы уже знаете, что такое голос продукта и тон этого голоса, то вы просто обобщите свои навыки (в очередной раз) и часть книги просто пролистаете. Если эти термины для вас новые, то в этой книге можно с ними познакомиться.
Кому может быть полезно?
В начале книги написано, что она для технических и UX-писателей с оговоркой, что кем бы вы себя ни называли: дизайнером, UX-писателем или специалистом по контент-стратегии, "если вы пишете текст, с которым взаимодействуют пользователи, книга поможет применить к этому процессу дизайн-методики".
Думаю, будет интересно всем, кто хоть раз задумывался почему его сообщения в интерфейсе всё ещё раздражают пользователей? 😊
#книжки
Майкл Дж. Меттс, Энди Уэлфл, 2024
Эту книгу я привезла в начале года с одной из конференций, тогда мне хотелось подрастить в себе UX-писателя. Вышло так: талант писателя прорастал сам как чертополох, а книга несколько месяцев лежала в упаковке. Так и лежала бы пока в июне я не оказалась на несколько часов в поезде вместе с этой книгой. Теперь в ней есть пометки и выпадающие из переплета листы, а у меня – новые ответы на вопросы о пользовательском опыте.
Книга о том, как создавать тексты в интерфейсах от создания стратегии до вопросов взаимодействия с командой разработки. Написано ясно, легко читается. В тексте есть примеры, отсылки к конкретным приложениям и историям. Один из авторов приводит примеры из написания текстов, которыми чат-бот общается с пользователями, есть интересные моменты: несложные, но такие, что не замечаешь пока кто-то не покажет. Для меня минус книги в том, что мысли объясняются много раз, разными словами и еще обобщаются в конце разделов. Если у вас уже есть опыт в UX, то может выглядеть раздражающе.
Перевод вышел через 4 года после оригинального издания в 2020 году и это заметно по некоторым отсылкам к статистике 2018-2019 гг. и примерам. Немного странно читать что-то капитанское вроде: "теперь не нужно выходить из дома, чтобы пополнить банковский счет" 😉
Что может быть полезно?
Особенно меня подкупило с каким уважением к работе с текстом пишут авторы. Одна из первых глав называется "Не извиняйтесь за себя" и в ней говорится о фокусе и значимости разных ролей при проектировании пользовательского опыта. И в том числе о важности текста.
Объяснение смысла вашей работы и того, почему она важна, — это вовсе не проявление самолюбования и эгоцентризма. Делая это, вы помогаете всем участникам процесса понять, как слова вписываются в пользовательский опыт, который вы создаете.
Когда вы принимаете решение, оказывающее влияние на чей-то опыт, вы занимаетесь проектированием.
Есть простые и рабочие практические советы по изучению контекста, в котором нужны слова и подсказки, по составлению ясных текстов, которые бы отвечали на запрос пользователя так как его понимает сам пользователь, а не как диктует ваш собственный опыт (что часто замечаю за аналитиками в подобных задачах). Похожие общие тезисы записывала когда-то в посте о конференции UX-редакторов.
Для меня особенно ценны примеры из практики. Меня давно занимала история с Playstation, у которой пульт общается с пользователями крестиком, кружочком и треугольником. Японский дизайнер полагал, что в принятии решений люди всегда понимают кружочек как "да" и крестик как "нет", но оказалось, что это однозначно работает только в японской культуре, а при выходе на другие рынки началась путаница.
Интересно было почитать об инклюзивности и доступности. Каким должен быть текст и как расположен, чтобы он работал при использовании скринридеров, которые превращают текст на странице в аудио?
Если вы уже знаете, что такое голос продукта и тон этого голоса, то вы просто обобщите свои навыки (в очередной раз) и часть книги просто пролистаете. Если эти термины для вас новые, то в этой книге можно с ними познакомиться.
Кому может быть полезно?
В начале книги написано, что она для технических и UX-писателей с оговоркой, что кем бы вы себя ни называли: дизайнером, UX-писателем или специалистом по контент-стратегии, "если вы пишете текст, с которым взаимодействуют пользователи, книга поможет применить к этому процессу дизайн-методики".
Думаю, будет интересно всем, кто хоть раз задумывался почему его сообщения в интерфейсе всё ещё раздражают пользователей? 😊
#книжки
👍3🔥1🤔1
Подборка про UX, теория и рабочие инструменты
У вас тоже есть папка "почитать", которая растет быстрее, чем свободное время? В выходные заглянула в свои запасы и выбрала статьи про UX. Здесь и простые советы, которые работают на практике, и история в лицах, и неочевидные лайфхаки на примере кошек 😉
📍Что должен знать продакт о машинном переводе интерфейса: кейс с результатами Автор делится опытом внедрения ИИ для локализации интерфейсов. Написано продактом и для продактов, но как всегда интересно заглянуть в чей-то опыт.
📍UX-проектирование на кошке Осторожно, в статье много фото одной трехцветной кошки! Статья о построении интерфейса для кошки-пользователя дверного проема. Мне очень понравился пример работы UX-специалиста с отсылкой к теории. Рекомендую заглянуть и в комментарии к статье об ответственности и бенефициарах такого проектирования, вдруг вы об этом еще не думали ?
📍Как системный аналитик может улучшить юзабилити проекта В этой статье автор привел примеры аудита экранов, на которых заметил недочеты. Мне здесь было интересно разглядывать примеры интерфейсов приложений для китайских абитуриентов.
📍Дорогая, что-то пошло не так. Гид по пустым состояниям и ошибкам + шаблоны на все случаи Руководитель группы UX-редактуры рассказала о текстах сообщений с примерами в картинках. Хотя статье уже почти два года, она точно будет полезна, если вы работаете с текстом.
📍Как появился графический интерфейс пользователя: история в лицах, деталях, фактах и курсорах Большая статья о развития пользовательских интерфейсов с 1945 года и до наших дней. На иллюстрациях можно увидеть первые иконки, изображения первых курсоров, первые версии компьютерной мыши и не только.
📍UX-манипуляции: уроки обольщения пользователей Из названия статьи ожидала что-то о темных паттернах, которые заманивают пользователя в невыгодные ему действия. Оказалось, статья как раз наоборот о хороших приемах построения интерфейсов. Думаю, мало нового для опытных проектировщиков интерфейсов, а как памятка начинающим может пригодиться.
#что_почитать
У вас тоже есть папка "почитать", которая растет быстрее, чем свободное время? В выходные заглянула в свои запасы и выбрала статьи про UX. Здесь и простые советы, которые работают на практике, и история в лицах, и неочевидные лайфхаки на примере кошек 😉
📍Что должен знать продакт о машинном переводе интерфейса: кейс с результатами Автор делится опытом внедрения ИИ для локализации интерфейсов. Написано продактом и для продактов, но как всегда интересно заглянуть в чей-то опыт.
📍UX-проектирование на кошке Осторожно, в статье много фото одной трехцветной кошки! Статья о построении интерфейса для кошки-пользователя дверного проема. Мне очень понравился пример работы UX-специалиста с отсылкой к теории. Рекомендую заглянуть и в комментарии к статье об ответственности и бенефициарах такого проектирования, вдруг вы об этом еще не думали ?
📍Как системный аналитик может улучшить юзабилити проекта В этой статье автор привел примеры аудита экранов, на которых заметил недочеты. Мне здесь было интересно разглядывать примеры интерфейсов приложений для китайских абитуриентов.
📍Дорогая, что-то пошло не так. Гид по пустым состояниям и ошибкам + шаблоны на все случаи Руководитель группы UX-редактуры рассказала о текстах сообщений с примерами в картинках. Хотя статье уже почти два года, она точно будет полезна, если вы работаете с текстом.
📍Как появился графический интерфейс пользователя: история в лицах, деталях, фактах и курсорах Большая статья о развития пользовательских интерфейсов с 1945 года и до наших дней. На иллюстрациях можно увидеть первые иконки, изображения первых курсоров, первые версии компьютерной мыши и не только.
📍UX-манипуляции: уроки обольщения пользователей Из названия статьи ожидала что-то о темных паттернах, которые заманивают пользователя в невыгодные ему действия. Оказалось, статья как раз наоборот о хороших приемах построения интерфейсов. Думаю, мало нового для опытных проектировщиков интерфейсов, а как памятка начинающим может пригодиться.
#что_почитать
👍2
5 ошибок декомпозиции User Story и как их избежать
В блоге Майка Кона, наткнулась на полезную статью о декомпозиции историй и решила пересказать основные идеи. Вот как видит автор пять самых распространённых ошибок и способы их исправить. Если тема актуальна, то стоит заглянуть и в оригинал.
Ошибка №1: Разделение историй — задача только Product Owner’а
🚨 PO без технического бэкграунда может разделить историю так, что:
• Из нескольких подзадач, 99% работы окажется в одной подзадаче.
• Появятся зависимости между подзадачами, мешающие завершению любой из них в рамках одной итерации.
⚙️Решение:
• Разделение историй — командная работа. PO + команда. Это не означает, что вся команда должна делить каждую историю в полном составе, но деление истории не должно производиться только одним или парой человек для каждой истории. PO и несколько представителей команды делят сначала одну или несколько историй, затем PO и несколько других участников делят следующую и т.д.
• Обсуждение на Daily Scrum. Например, на Daily Scrum PO объявляет: «Нужно разбить 3 истории в следующие пару дней для подготовки к следующему спринту». Несколько человек из команды выражают готовность помочь и определяются с подходящим временем.
Ошибка №2: Разделение по техническим границам
🚨 Истории делятся не по функциональным, а по техническим границам, т.е. только с точки зрения команды, а не пользователя или стейкхолдера. Истории типа:
• «Как пользователь, я хочу бэкенд который делает X».
• «Как пользователь, я хочу фронтенд который делает тот же Х».
Таким образом получаются истории, не имеющие для пользователя никакой ценности сами по себе. (Фронтэнд, например, веб-интерфейс, не несет пользы без бэкэнда и\или базы данных)
⚙️Решение:
• Делите по «путям» через историю.
• По путям с точки зрения команды: обычно есть путь, определяющий что происходит, когда все идет правильно, и пути для возможных ошибок.
• По путям с точки зрения пользователя: например, при заказе товаров из корзины пользователь может выбрать варианты доставки. В первой версии можно предположить, что все пользователи получают только один из вариантов, а остальные добавить позднее. Это упростит интерфейс и потребует меньше тестирования.
Ошибка №3: Указание решения истории в самой истории
🚨 В самой истории описано как решать эту историю (Если нужно повесить картину на стену, сразу прописывается какой крепеж использовать, вместо простого «Нужно повесить картину на стену»).
⚙️Решение:
• Фокусируйтесь на «что», а не «как».
• Если команда включает в истории слишком много конкретики, то возможно вы делите истории на слишком маленькие под-истории.
Ошибка №4: Спайки для каждой истории
🚨 Команды создают спайки (исследовательские задачи) даже для простых историй, чтобы «убрать все риски».
Решение:
• Спайки нужны только при высокой неопределённости. Некоторая неопределенность присуща каждой истории, и спайки должны быть использованы лишь в особых случаях с действительно высокой неопределенностью.
Ошибка №5: сразу внедрять все бизнес-правила
🚨 Команда пытается реализовать все правила сразу, даже если это значительно усложняет разработку.
Пример, мобильное приложение для банка:
• Правило: «Не выдавать кредиты общей суммой > $10 млн».
• Вместо полной проверки в первой версии можно:
1. Сделать базовую заявку без проверки существующих кредитов.
2. Добавить проверку в последующих итерациях.
⚙️Решение:
• Постепенное усложнение. Сначала разрабатывается более простой вариант, потом внедряются бизнес-правила, если это упрощает работу.
• Важно: Не выпускать в эксплуатацию версию без критичных правил!
Моя "любимая ошибка" здесь под номером 3 🌱
#инструменты #agile
В блоге Майка Кона, наткнулась на полезную статью о декомпозиции историй и решила пересказать основные идеи. Вот как видит автор пять самых распространённых ошибок и способы их исправить. Если тема актуальна, то стоит заглянуть и в оригинал.
Ошибка №1: Разделение историй — задача только Product Owner’а
• Из нескольких подзадач, 99% работы окажется в одной подзадаче.
• Появятся зависимости между подзадачами, мешающие завершению любой из них в рамках одной итерации.
⚙️Решение:
• Разделение историй — командная работа. PO + команда. Это не означает, что вся команда должна делить каждую историю в полном составе, но деление истории не должно производиться только одним или парой человек для каждой истории. PO и несколько представителей команды делят сначала одну или несколько историй, затем PO и несколько других участников делят следующую и т.д.
• Обсуждение на Daily Scrum. Например, на Daily Scrum PO объявляет: «Нужно разбить 3 истории в следующие пару дней для подготовки к следующему спринту». Несколько человек из команды выражают готовность помочь и определяются с подходящим временем.
Ошибка №2: Разделение по техническим границам
• «Как пользователь, я хочу бэкенд который делает X».
• «Как пользователь, я хочу фронтенд который делает тот же Х».
Таким образом получаются истории, не имеющие для пользователя никакой ценности сами по себе. (Фронтэнд, например, веб-интерфейс, не несет пользы без бэкэнда и\или базы данных)
⚙️Решение:
• Делите по «путям» через историю.
• По путям с точки зрения команды: обычно есть путь, определяющий что происходит, когда все идет правильно, и пути для возможных ошибок.
• По путям с точки зрения пользователя: например, при заказе товаров из корзины пользователь может выбрать варианты доставки. В первой версии можно предположить, что все пользователи получают только один из вариантов, а остальные добавить позднее. Это упростит интерфейс и потребует меньше тестирования.
Ошибка №3: Указание решения истории в самой истории
⚙️Решение:
• Фокусируйтесь на «что», а не «как».
• Если команда включает в истории слишком много конкретики, то возможно вы делите истории на слишком маленькие под-истории.
Ошибка №4: Спайки для каждой истории
Решение:
• Спайки нужны только при высокой неопределённости. Некоторая неопределенность присуща каждой истории, и спайки должны быть использованы лишь в особых случаях с действительно высокой неопределенностью.
Ошибка №5: сразу внедрять все бизнес-правила
Пример, мобильное приложение для банка:
• Правило: «Не выдавать кредиты общей суммой > $10 млн».
• Вместо полной проверки в первой версии можно:
1. Сделать базовую заявку без проверки существующих кредитов.
2. Добавить проверку в последующих итерациях.
⚙️Решение:
• Постепенное усложнение. Сначала разрабатывается более простой вариант, потом внедряются бизнес-правила, если это упрощает работу.
• Важно: Не выпускать в эксплуатацию версию без критичных правил!
Моя "любимая ошибка" здесь под номером 3 🌱
#инструменты #agile
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
ИИ-шный перевод текста vs человеческий
Предыдущий пост я начала готовить с того, что «скормила» текст статьи DeepSeek и вежливо попросила «Переведи, пожалуйста, статью». Можете крутить пальцем у виска, но я правда написала «пожалуйста», сработала привычка. Мы уже некоторое время общаемся, а приказывать приятелям как-то неуместно. Потом взяла и отнесла результат на валидацию лингвисту-переводчику. Вот что мы поняли.
Получился не перевод, а пересказ с искажениями от рассказчика. Искажения местами очень заметные. Например, в первом пункте про декомпозицию руками РО в оригинале написано, что нужно на дейли поискать желающих помочь с декомпозицией и договориться о времени встречи. В пересказе так: «На Daily Scrum PO объявляет: «Нужно разбить 3 истории к следующему спринту». Добровольцы из команды помогают.» Получается – сели дружно на дейли и начали декомпозировать, но в тексте же не об этом. Так мне однажды ученик 5го класса «Гарри Поттера» пересказал – в целом может и верно, но непонятно кто куда на метле летел, причем тут снитч и нимбус?
Рассказчик подбирает смыслы и слова откуда-то из своего опыта. Там же в первом пункте про РО, в оригинале написано, что нужно привлекать команду, а в пересказе я нашла что декомпозируют «PO + разработчики + тестировщики». Упоминание тестировщиков тут вполне уместно по сути, но вот найдете ли в оригинале хоть одного тестировщика во всем тексте? Его тут дорисовала нейро-фантазия (вполне удачно, но не по тексту).
В переводе слово «итерация» местами оказалась словом «спринт». В нашем контексте это смысла не меняет, но если важен именно построчный детальный перевод, то может подвести. Так временами действуют пожилые опытные родственники – «делай, дочка, как я сказала, не ошибешься», иногда срабатывает, а иногда....больно вспоминать 🙈
Никакая вежливость не спасла от подведения итогов. ИИ-шная тяга делать выводы сработала и в переводе, где я с изумлением обнаружила раздел «Итоги», которого нет в оригинале. Решила поправить промпт и попросила «сделай точный перевод текста», но все равно обнаружила раздел «Итоги». Попросила «убери итоги», получила пересказ с абзацем «ключевые выводы». Слово «пожалуйста» не помогает, в подведении итогов DeepSeek неумолим как бухгалтерия в отчетный период.
Здесь напрашивается подзаголовок «выводы», но будет очень похоже, что этот текст DeepSeek написал без меня😉 Так что ни итогов, ни ключевых выводов не будет. Просто мои наблюдения на случай, если вы решите что-то быстренько перевести.
#истории #опыт
Предыдущий пост я начала готовить с того, что «скормила» текст статьи DeepSeek и вежливо попросила «Переведи, пожалуйста, статью». Можете крутить пальцем у виска, но я правда написала «пожалуйста», сработала привычка. Мы уже некоторое время общаемся, а приказывать приятелям как-то неуместно. Потом взяла и отнесла результат на валидацию лингвисту-переводчику. Вот что мы поняли.
Получился не перевод, а пересказ с искажениями от рассказчика. Искажения местами очень заметные. Например, в первом пункте про декомпозицию руками РО в оригинале написано, что нужно на дейли поискать желающих помочь с декомпозицией и договориться о времени встречи. В пересказе так: «На Daily Scrum PO объявляет: «Нужно разбить 3 истории к следующему спринту». Добровольцы из команды помогают.» Получается – сели дружно на дейли и начали декомпозировать, но в тексте же не об этом. Так мне однажды ученик 5го класса «Гарри Поттера» пересказал – в целом может и верно, но непонятно кто куда на метле летел, причем тут снитч и нимбус?
Рассказчик подбирает смыслы и слова откуда-то из своего опыта. Там же в первом пункте про РО, в оригинале написано, что нужно привлекать команду, а в пересказе я нашла что декомпозируют «PO + разработчики + тестировщики». Упоминание тестировщиков тут вполне уместно по сути, но вот найдете ли в оригинале хоть одного тестировщика во всем тексте? Его тут дорисовала нейро-фантазия (вполне удачно, но не по тексту).
В переводе слово «итерация» местами оказалась словом «спринт». В нашем контексте это смысла не меняет, но если важен именно построчный детальный перевод, то может подвести. Так временами действуют пожилые опытные родственники – «делай, дочка, как я сказала, не ошибешься», иногда срабатывает, а иногда....больно вспоминать 🙈
Никакая вежливость не спасла от подведения итогов. ИИ-шная тяга делать выводы сработала и в переводе, где я с изумлением обнаружила раздел «Итоги», которого нет в оригинале. Решила поправить промпт и попросила «сделай точный перевод текста», но все равно обнаружила раздел «Итоги». Попросила «убери итоги», получила пересказ с абзацем «ключевые выводы». Слово «пожалуйста» не помогает, в подведении итогов DeepSeek неумолим как бухгалтерия в отчетный период.
Здесь напрашивается подзаголовок «выводы», но будет очень похоже, что этот текст DeepSeek написал без меня😉 Так что ни итогов, ни ключевых выводов не будет. Просто мои наблюдения на случай, если вы решите что-то быстренько перевести.
#истории #опыт
😁3❤1🔥1
Почти все о прототипах в одной подборке
Признаюсь, мне нравится та часть работы аналитика, где нужно визуально моделировать экранные формы. В моем списке для чтения часто находится что-то об этом. Здесь получилась подборка, где можно найти и как сделать прототип, и в чем сделать, и как согласовать с заказчиком ✍️
📍Как правильно разработать интерактивный прототип? В эту статью интересно заглянуть, если вы еще не видели как выглядит в графическом редакторе набор макетов, связанных переходами. Такой вариант прототипа часто называют "интерактивным". Еще в статье рассказ о выборе сценариев для прототипа, его разработке и представлении пользователям.
📍Сила прототипирования: что сработало, а чего следует избегать. Большая статья с картинками-примерами и рассказом, в чем картинки помогли, а в чем помешали в конкретных кейсах. В работе с прототипами много рисков и здесь меня привлекли не только картинки, но и комментарии о недостатках их использования.
📍Каркасное проектирование или wireframes В этом тексте я когда-то рассказала о вайрфреймах и даже придумала к тексту карточки с примерами и советами
📍Здесь 13 лайфхаков взаимодействия с заказчиками с точки зрения дизайнера-проектировщика. Каждый имеет пример-иллюстрацию из процессов создания прототипов. На самом деле получился универсальный подход, полезный в любом деле: выясните терминологию, договоритесь об ожиданиях, получили 20 комментариев – дайте 20 ответов...не буду пересказывать, лучше загляните сами🔅
📍Моделирование интерфейсов пользователя, инструменты Пост в этом канале, где я поделилась, чем пользуюсь для создания прототипов и собрала материалы, где авторы проанализировали другие приложения.
#что_почитать #прототипы
Признаюсь, мне нравится та часть работы аналитика, где нужно визуально моделировать экранные формы. В моем списке для чтения часто находится что-то об этом. Здесь получилась подборка, где можно найти и как сделать прототип, и в чем сделать, и как согласовать с заказчиком ✍️
📍Как правильно разработать интерактивный прототип? В эту статью интересно заглянуть, если вы еще не видели как выглядит в графическом редакторе набор макетов, связанных переходами. Такой вариант прототипа часто называют "интерактивным". Еще в статье рассказ о выборе сценариев для прототипа, его разработке и представлении пользователям.
📍Сила прототипирования: что сработало, а чего следует избегать. Большая статья с картинками-примерами и рассказом, в чем картинки помогли, а в чем помешали в конкретных кейсах. В работе с прототипами много рисков и здесь меня привлекли не только картинки, но и комментарии о недостатках их использования.
📍Каркасное проектирование или wireframes В этом тексте я когда-то рассказала о вайрфреймах и даже придумала к тексту карточки с примерами и советами
📍Здесь 13 лайфхаков взаимодействия с заказчиками с точки зрения дизайнера-проектировщика. Каждый имеет пример-иллюстрацию из процессов создания прототипов. На самом деле получился универсальный подход, полезный в любом деле: выясните терминологию, договоритесь об ожиданиях, получили 20 комментариев – дайте 20 ответов...не буду пересказывать, лучше загляните сами🔅
📍Моделирование интерфейсов пользователя, инструменты Пост в этом канале, где я поделилась, чем пользуюсь для создания прототипов и собрала материалы, где авторы проанализировали другие приложения.
#что_почитать #прототипы
👍2
Про приоритеты, которые берегут наше время
Когда-то я обнаружила, что подписана штук на 500+ экспертных каналов в ТГ. Не то чтобы я их пересчитывала, а просто поняла, что могу часами перелистывать тонны постов, пытаясь ухватить что-то ценное.
У этого явления есть название - синдром упущенных возможностей (он еще называется FOMO). Это когда человек думает, что все вокруг узнают что-то интересное, а он – нет. Говорят, придумали еще много синдромов, но мне и этого хватило , чтобы понять, что такое – приоритеты 😉
Правда в том, что при расстановке приоритетов приходится признавать свою личную ответственность за выбор того, как поведешь время и что именно почитаешь. Когда листаешь все, что прилетело, будто снимаешь с себя ответственность – оно же прилетело и нужно прочитать, что я могу сделать?
В случае с экспертной информацией нужно еще смириться, что польза измеряется не количеством прочитанного, а качеством усвоенного.
В итоге я пришла к такой схеме приоритетов:
📍Жесткий отбор. Разделила на папки по сферам знаний (вот они на скриншоте). Внизу списка папка "Почитать", там в паре каналов (где один подписчик - я) дожидаются своей очереди статьи и посты, которые при первом взгляде показались полезными. Обычно в выходные разбираю. С этими списками как с покупками в магазине, через неделю смотришь и не понимаешь зачем купил? Когда видела заголовок впервые может показаться интересным, а при ближайшем рассмотрении удаляется без сожалений. А вот полезности из этой папки попадают в мои подборки 🌱
📍Четкий фокус. Выбираю для чтения 1-2 ключевые темы и каналы в соответствующей папке, исходя из интересов в момент времени, а не по факту выхода нового контента.
📍Осознанный пропуск. Если в канале накопилось много постов – читаю только пару последних. По крайней мере последнее-актуальное не пропущу, а если что-то прошло мимо — значит, так надо ☀️
Если у вас есть свои лайфхаки, делитесь!
#мысливслух #опыт
Когда-то я обнаружила, что подписана штук на 500+ экспертных каналов в ТГ. Не то чтобы я их пересчитывала, а просто поняла, что могу часами перелистывать тонны постов, пытаясь ухватить что-то ценное.
У этого явления есть название - синдром упущенных возможностей (он еще называется FOMO). Это когда человек думает, что все вокруг узнают что-то интересное, а он – нет. Говорят, придумали еще много синдромов, но мне и этого хватило , чтобы понять, что такое – приоритеты 😉
Правда в том, что при расстановке приоритетов приходится признавать свою личную ответственность за выбор того, как поведешь время и что именно почитаешь. Когда листаешь все, что прилетело, будто снимаешь с себя ответственность – оно же прилетело и нужно прочитать, что я могу сделать?
В случае с экспертной информацией нужно еще смириться, что польза измеряется не количеством прочитанного, а качеством усвоенного.
В итоге я пришла к такой схеме приоритетов:
📍Жесткий отбор. Разделила на папки по сферам знаний (вот они на скриншоте). Внизу списка папка "Почитать", там в паре каналов (где один подписчик - я) дожидаются своей очереди статьи и посты, которые при первом взгляде показались полезными. Обычно в выходные разбираю. С этими списками как с покупками в магазине, через неделю смотришь и не понимаешь зачем купил? Когда видела заголовок впервые может показаться интересным, а при ближайшем рассмотрении удаляется без сожалений. А вот полезности из этой папки попадают в мои подборки 🌱
📍Четкий фокус. Выбираю для чтения 1-2 ключевые темы и каналы в соответствующей папке, исходя из интересов в момент времени, а не по факту выхода нового контента.
📍Осознанный пропуск. Если в канале накопилось много постов – читаю только пару последних. По крайней мере последнее-актуальное не пропущу, а если что-то прошло мимо — значит, так надо ☀️
Если у вас есть свои лайфхаки, делитесь!
#мысливслух #опыт
👍3❤2
Искренне восхищаюсь людьми, которые создают по-настоящему полезные вещи. Для этого нужно невероятное терпение, настойчивость и вера в результат 🚀
Недавно через несколько «рукопожатий» я познакомилась с командой, которая решила разработать плагин и превратить VSCode в удобную IDE для аналитиков. Их цель - охватить все этапы работы с требованиями, сократив время на документирование.
Ребята предложили мне поучаствовать. К сожалению, сейчас не смогу уделить этому достаточно времени. Поэтому лучшее, что могу сделать — рассказать о них здесь.
Как раз сегодня 18.07 в 18:00 пройдет сессия для аналитиков, где планируется разбор разбор US по созданию агентов. Если вам близка тема, подробнее в канале разработчиков IDE BAS.
Недавно через несколько «рукопожатий» я познакомилась с командой, которая решила разработать плагин и превратить VSCode в удобную IDE для аналитиков. Их цель - охватить все этапы работы с требованиями, сократив время на документирование.
Ребята предложили мне поучаствовать. К сожалению, сейчас не смогу уделить этому достаточно времени. Поэтому лучшее, что могу сделать — рассказать о них здесь.
Как раз сегодня 18.07 в 18:00 пройдет сессия для аналитиков, где планируется разбор разбор US по созданию агентов. Если вам близка тема, подробнее в канале разработчиков IDE BAS.
❤3👍1
Нефункциональное
В выходные снова заглянула в отложенные статьи. Выбрала несколько статей о нефункциональных требованиях (НФТ). Уверена, что многие здесь сталкивались с формулированием требований к безопасности, производительности, совместимости, доступности и не только. Здесь несколько статей как раз об этом.
Требования безопасности: пособие для аналитика Эта статья пролежала в моем списке почти год, но от этого нисколько не потеряла в качестве 😉 Речь о том как формируются требования к безопасности информации, какие разные интересы при этом могут быть затронуты и как разные виды НФТ могут конфликтовать с требованиями безопасности. Понравилось, что разобран пример, рассказано о модели угроз и выставлении приоритетов требованиям безопасности.
НФТ к производительности: расчет нагрузки в rps на практическом примере Требования к производительности системы в большей степени влияют на выбор архитектурных решений. Как видно из названия – речь о том как рассчитать нагрузку в количестве запросов в секунду. Статья меня покорила детальностью и тем, что в ней не просто приведены схемы, но и их код в PlantUML.
(EN) Concept for the successful handling of integral NFRs in Scaled Agile Environments Статья о том, как обеспечивать выполнение нефункциональных требований, особенно требований безопасности, в agile-среде. Как согласовать работу множества команд (архитекторы, разработчики, тестировщики), когда нужно соблюсти НФТ и ничего не потерять в частых релизах? Речь снова о критериях приемки, DoR и DoD, может быть интересно, если вы неравнодушны к вопросам производственного процесса.
#что_почитать
В выходные снова заглянула в отложенные статьи. Выбрала несколько статей о нефункциональных требованиях (НФТ). Уверена, что многие здесь сталкивались с формулированием требований к безопасности, производительности, совместимости, доступности и не только. Здесь несколько статей как раз об этом.
Требования безопасности: пособие для аналитика Эта статья пролежала в моем списке почти год, но от этого нисколько не потеряла в качестве 😉 Речь о том как формируются требования к безопасности информации, какие разные интересы при этом могут быть затронуты и как разные виды НФТ могут конфликтовать с требованиями безопасности. Понравилось, что разобран пример, рассказано о модели угроз и выставлении приоритетов требованиям безопасности.
НФТ к производительности: расчет нагрузки в rps на практическом примере Требования к производительности системы в большей степени влияют на выбор архитектурных решений. Как видно из названия – речь о том как рассчитать нагрузку в количестве запросов в секунду. Статья меня покорила детальностью и тем, что в ней не просто приведены схемы, но и их код в PlantUML.
(EN) Concept for the successful handling of integral NFRs in Scaled Agile Environments Статья о том, как обеспечивать выполнение нефункциональных требований, особенно требований безопасности, в agile-среде. Как согласовать работу множества команд (архитекторы, разработчики, тестировщики), когда нужно соблюсти НФТ и ничего не потерять в частых релизах? Речь снова о критериях приемки, DoR и DoD, может быть интересно, если вы неравнодушны к вопросам производственного процесса.
#что_почитать
👍3🙏1
Трассировка требований. От хаоса к управляемости
Недавно мне пришлось обсуждать такой вопрос: есть 83 тест-кейса, видимо, уже неактуальных. Как в таком объеме понять откуда они взялись и оценить актуальность?
Чтобы понять как отвечать на такие вопросы, нужно вспомнить, что такое трассировка (traceability). Многие помнят, что это – систематическое отслеживание связей между артефактами. За этим прослеживается груда теории и скучной рутины, но непонятно как это работает. Почему так?
📍Трассировка важна для команды, но не интересна заказчикам. Обычно за этим забывают, что документация будет разрастаться и рано или поздно придется искать ее корни.
📍Часто связывают все подряд артефакты и получается нечитаемый набор непонятных ссылок всего на все. Об этом напишу дальше.
📍Нужна дисциплина в течении продолжительного времени, чтобы увидеть результат. Требуется терпение и время, чтобы найти связанные артефакты, и часто этим шагом пренебрегают. Можно сберечь много часов рутинной работы, если в текущей работе оставить пару ссылок на связанные статьи или задачи. Очень дорого и бесполезно привязывать артефакты друг к другу, когда их уже накопились сотни.
📍Нет системности во всей базе знаний. Если даже вы и связали свой документ с исходной постановкой, описанием целей или реализации, эта информация может не сработать, когда связанное описание получает новую версию как отдельный документ. Просто остается связь с чем-то неактуальным.
В BABOK есть хорошая классификация связей (в новый BAST перекочевало только общее описание). Выбирайте, что важно трассировать именно вам, чтобы не получать сумбурный набор ссылок.
🔅Следование - одно требование является производным от другого. Например, функциональное требование следует из бизнес-требования.
🔅Зависимость – одно требование зависит от другого. Например, невозможно реализовать поиск по списку, если не реализован сам список.
🔅Реализация/удовлетворение - связь между элементом реализации и требованиями, которым он удовлетворяет. Например, связь между функциональным требованием и компонентом решения, реализующим это требование.
🔅Проверка – определяет удовлетворяет ли решение требованию. Например, тест-кейс проверяет удовлетворяет ли решение функциональному требованию.
Как хорошо, что уже давно не нужно делать никаких таблиц с матрицами трассировки! Достаточно оставить ссылку в статье. Главное, сделать это вовремя и по заранее выбранным типам связей😎
В моих списках полезностей нашлась статья Что такое трассировка требований в проекте и почему она важна? Оставлю здесь ссылку, наверняка и вам пригодится 🌱
#инструменты
Недавно мне пришлось обсуждать такой вопрос: есть 83 тест-кейса, видимо, уже неактуальных. Как в таком объеме понять откуда они взялись и оценить актуальность?
Чтобы понять как отвечать на такие вопросы, нужно вспомнить, что такое трассировка (traceability). Многие помнят, что это – систематическое отслеживание связей между артефактами. За этим прослеживается груда теории и скучной рутины, но непонятно как это работает. Почему так?
📍Трассировка важна для команды, но не интересна заказчикам. Обычно за этим забывают, что документация будет разрастаться и рано или поздно придется искать ее корни.
📍Часто связывают все подряд артефакты и получается нечитаемый набор непонятных ссылок всего на все. Об этом напишу дальше.
📍Нужна дисциплина в течении продолжительного времени, чтобы увидеть результат. Требуется терпение и время, чтобы найти связанные артефакты, и часто этим шагом пренебрегают. Можно сберечь много часов рутинной работы, если в текущей работе оставить пару ссылок на связанные статьи или задачи. Очень дорого и бесполезно привязывать артефакты друг к другу, когда их уже накопились сотни.
📍Нет системности во всей базе знаний. Если даже вы и связали свой документ с исходной постановкой, описанием целей или реализации, эта информация может не сработать, когда связанное описание получает новую версию как отдельный документ. Просто остается связь с чем-то неактуальным.
В BABOK есть хорошая классификация связей (в новый BAST перекочевало только общее описание). Выбирайте, что важно трассировать именно вам, чтобы не получать сумбурный набор ссылок.
🔅Следование - одно требование является производным от другого. Например, функциональное требование следует из бизнес-требования.
🔅Зависимость – одно требование зависит от другого. Например, невозможно реализовать поиск по списку, если не реализован сам список.
🔅Реализация/удовлетворение - связь между элементом реализации и требованиями, которым он удовлетворяет. Например, связь между функциональным требованием и компонентом решения, реализующим это требование.
🔅Проверка – определяет удовлетворяет ли решение требованию. Например, тест-кейс проверяет удовлетворяет ли решение функциональному требованию.
Как хорошо, что уже давно не нужно делать никаких таблиц с матрицами трассировки! Достаточно оставить ссылку в статье. Главное, сделать это вовремя и по заранее выбранным типам связей
В моих списках полезностей нашлась статья Что такое трассировка требований в проекте и почему она важна? Оставлю здесь ссылку, наверняка и вам пригодится 🌱
#инструменты
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4👍1
Подборка о том, как аналитику договариваться с ИИ
Можно подумать, что тема ИИ обошла стороной мои подборки. Как бы не так!
Самое утомительное в общении с ИИ – наши попытки объяснить ему, что мы, собственно, хотим. Промпты приходится разбирать по кусочкам, проверяя каждый шаг, будто объясняешь дорогу марсианину и тот в любую секунду может улететь в открытый космос. Я покопалась в своей "библиотеке" и попробовала выбрать публикации, где авторы поделились наработками.
Я устала писать документацию — и научила AI делать это за меня Автор этой статьи – QA. Документация здесь – чек-листы и тест-кейсы, которые бывает скучно составлять. В статье честный рассказ о нескольких итерациях запросов к DeepSeek c определением правил и контекста для генерации более точного ответа. Есть высказывание, с которым я не согласилась. Говорят, результат будет лучше, если все запросы вести в одном окне чата. Это спорный момент. Не закрывайте чат, если ваш вопрос всегда в одном и том же контексте и стиле, но если сначала речь об окне регистрации в мобильном приложении, а потом о генерации отчета в pdf, то я бы начала разговор заново. Иначе на основании прежнего контекста можно получить неожиданный совет о генерации отчета в окне регистрации пользователя мобильного приложения.
AI Prompt Engineering for Business Analysts (EN) Пост в англоязычном блоге. Здесь о том как и для чего можно составить промпты для помощи БА. Как – итеративно, для чего – ускорить работу над рутиной и освободить время для более творческих задач. Здесь интереснее посмотреть примеры промптов.
Промт-инжиниринг для аналитиков по фреймворку КОМПОЗИТОР Авторский подход к составлению промптов, основанный на метафорах
Каталог ИИ-промтов по анализу и проектированию ИС Подборка промптов в базе знаний Школы Системного Анализа собрана в формате страничек в notion, к которым можно пройти по ссылке с основного лендинга
#что_почитать #инструменты
Можно подумать, что тема ИИ обошла стороной мои подборки. Как бы не так!
Самое утомительное в общении с ИИ – наши попытки объяснить ему, что мы, собственно, хотим. Промпты приходится разбирать по кусочкам, проверяя каждый шаг, будто объясняешь дорогу марсианину и тот в любую секунду может улететь в открытый космос. Я покопалась в своей "библиотеке" и попробовала выбрать публикации, где авторы поделились наработками.
Я устала писать документацию — и научила AI делать это за меня Автор этой статьи – QA. Документация здесь – чек-листы и тест-кейсы, которые бывает скучно составлять. В статье честный рассказ о нескольких итерациях запросов к DeepSeek c определением правил и контекста для генерации более точного ответа. Есть высказывание, с которым я не согласилась. Говорят, результат будет лучше, если все запросы вести в одном окне чата. Это спорный момент. Не закрывайте чат, если ваш вопрос всегда в одном и том же контексте и стиле, но если сначала речь об окне регистрации в мобильном приложении, а потом о генерации отчета в pdf, то я бы начала разговор заново. Иначе на основании прежнего контекста можно получить неожиданный совет о генерации отчета в окне регистрации пользователя мобильного приложения.
AI Prompt Engineering for Business Analysts (EN) Пост в англоязычном блоге. Здесь о том как и для чего можно составить промпты для помощи БА. Как – итеративно, для чего – ускорить работу над рутиной и освободить время для более творческих задач. Здесь интереснее посмотреть примеры промптов.
Промт-инжиниринг для аналитиков по фреймворку КОМПОЗИТОР Авторский подход к составлению промптов, основанный на метафорах
Каталог ИИ-промтов по анализу и проектированию ИС Подборка промптов в базе знаний Школы Системного Анализа собрана в формате страничек в notion, к которым можно пройти по ссылке с основного лендинга
#что_почитать #инструменты
🔥4👍2✍1
Не рычите на собаку
Карен Прайор, 1999
Эта книга попала в мой список чтения после нескольких семинаров по soft skills. Наконец я ее прочла. Где? Конечно, в поездке.
Мне встретился перевод 2014 года, но оригинал еще старше. О возрасте книги напомнила фраза "выпустили видеокассету".
Автор – биолог и дрессировщица животных. В книге исследования из зоопсихологии показаны на примере дрессировки животных и перенесены на людей. Главный посыл: наказывать неэффективно, работает вознаграждение за правильное поведение. Не нравится поведение? Игнорируйте, замещайте или привяжите к поведенческому маркеру, который постепенно перестанет поступать. Встретили желательное поведение? Подкрепляйте положительно – похвалой, едой, чем-то приятным. Это работает и с начальником, и с занудными родственниками, и с кошкой, считает автор.
Вспомнила как действовали мои бабушки. Одна из них как-то учила меня тактичному молчанию: "Ты не говори деду, что арбуз невкусный, а то больше не пойдет на рынок за арбузом". Так мы вместе игнорировали нежелательное поведение. Другая моя бабушка действовала хитрее, когда сначала моделировала желаемое поведение, а потом за него хвалила. Заметит, как я сорвалась в крик на своего ребенка и скажет: "Какая ты молодец, что не повышаешь голос на сына!" Бабушки понимали и применяли положительное подкрепление.
Что может быть полезно?
🔅Познакомиться с бихевиоризмом – направлением психологии, которое изучает поведение, а не только мысли и чувства. Закрепить или устранить можно только то поведение, которое проявляется. Не видите как ребенок моет руки, и похвалить за это не получится.
🔅Подумать, что не работает при наказаниях. Интересно наблюдать за ходом мысли автора, когда приводятся аргументы для объяснения почему плохо работает наказание за нежелательные поступки. Как наказание и факт поведения сложно связать друг с другом в понимании животного. Как чтобы решить вопрос, нужно разобраться в мотивации. Например, если собака грызёт мебель, важно выяснить причину (скука, стресс, недостаток физической активности), а не наказывать животное.
🔅Научиться поощрять себя за успехи. Когда учитесь чему-то сами хвалите себя за удачи, а не наказывайте за промахи очередными угрызениями совести. Если не получается какой-то прием (например, в теннисе), лучше переключиться на другой и, когда освоите, попробуйте вернуться к изучению прежнего.
🔅Подумать о природе творчества. Понравился пример, когда дельфинов поощряли за неожиданные выдумки и те стали креативными, но неуправляемыми – придумывали неожиданные прыжки или игры с предметами в расчете на поощрение. Вы без труда считаете похожее поведение у кого-то из коллег, которые всех раздражают 😊
Тем не менее ждала большего за подзаголовком "Книга о дрессировке людей, животных и самого себя". 80% примеров из жизни животных. Выглядят случайными отсылки к воспитанию детей, лечению больных, влиянию на мужей.
Кому может быть полезно?
Начинающим тим-лидам, руководителям и преподавателям. Можно познакомиться с полезными идеями или просто убедиться, что ваша бабушка была права, когда не ругала деда за неудачную покупку😎
#книжки
Карен Прайор, 1999
Эта книга попала в мой список чтения после нескольких семинаров по soft skills. Наконец я ее прочла. Где? Конечно, в поездке.
Мне встретился перевод 2014 года, но оригинал еще старше. О возрасте книги напомнила фраза "выпустили видеокассету".
Автор – биолог и дрессировщица животных. В книге исследования из зоопсихологии показаны на примере дрессировки животных и перенесены на людей. Главный посыл: наказывать неэффективно, работает вознаграждение за правильное поведение. Не нравится поведение? Игнорируйте, замещайте или привяжите к поведенческому маркеру, который постепенно перестанет поступать. Встретили желательное поведение? Подкрепляйте положительно – похвалой, едой, чем-то приятным. Это работает и с начальником, и с занудными родственниками, и с кошкой, считает автор.
Вспомнила как действовали мои бабушки. Одна из них как-то учила меня тактичному молчанию: "Ты не говори деду, что арбуз невкусный, а то больше не пойдет на рынок за арбузом". Так мы вместе игнорировали нежелательное поведение. Другая моя бабушка действовала хитрее, когда сначала моделировала желаемое поведение, а потом за него хвалила. Заметит, как я сорвалась в крик на своего ребенка и скажет: "Какая ты молодец, что не повышаешь голос на сына!" Бабушки понимали и применяли положительное подкрепление.
Что может быть полезно?
🔅Познакомиться с бихевиоризмом – направлением психологии, которое изучает поведение, а не только мысли и чувства. Закрепить или устранить можно только то поведение, которое проявляется. Не видите как ребенок моет руки, и похвалить за это не получится.
🔅Подумать, что не работает при наказаниях. Интересно наблюдать за ходом мысли автора, когда приводятся аргументы для объяснения почему плохо работает наказание за нежелательные поступки. Как наказание и факт поведения сложно связать друг с другом в понимании животного. Как чтобы решить вопрос, нужно разобраться в мотивации. Например, если собака грызёт мебель, важно выяснить причину (скука, стресс, недостаток физической активности), а не наказывать животное.
🔅Научиться поощрять себя за успехи. Когда учитесь чему-то сами хвалите себя за удачи, а не наказывайте за промахи очередными угрызениями совести. Если не получается какой-то прием (например, в теннисе), лучше переключиться на другой и, когда освоите, попробуйте вернуться к изучению прежнего.
🔅Подумать о природе творчества. Понравился пример, когда дельфинов поощряли за неожиданные выдумки и те стали креативными, но неуправляемыми – придумывали неожиданные прыжки или игры с предметами в расчете на поощрение. Вы без труда считаете похожее поведение у кого-то из коллег, которые всех раздражают 😊
Тем не менее ждала большего за подзаголовком "Книга о дрессировке людей, животных и самого себя". 80% примеров из жизни животных. Выглядят случайными отсылки к воспитанию детей, лечению больных, влиянию на мужей.
Кому может быть полезно?
Начинающим тим-лидам, руководителям и преподавателям. Можно познакомиться с полезными идеями или просто убедиться, что ваша бабушка была права, когда не ругала деда за неудачную покупку
#книжки
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3💯1
Сколько техник BABOK используете? В этой подборке их 19
Решила провести аудит своих постов про #инструменты и сравнить с BABOK. Результат: 19 техник из 50 в этом канале упоминались. Кое-что полезное уже есть. Собрала все в один список. Буду рада, если пригодится! ☀️
📍Критерии приемки: Чем отличаются критерии приемки и DOD?
📍Управление бэклогом: Бэклог не может содержать все подряд
📍Бенчмаркинг: Как посмотреть, что делают другие?
📍Мозговой штурм: Мозговой штурм (brainstorm) работает или нет?
📍Decision Analysis: Как можно выбрать одно из двух зол?
📍Анализ процессов: Подборка примеров моделирования в BPMN
📍Оценка задач: Техники оценки задач
📍Фокус-группа: Для чего не годятся фокус-группы?
📍Функциональная декомпозиция: Функциональная декомпозиция
📍Глоссарий: Как это понимать?
📍Интервью: Про ошибки при проведении интервью с пользователями и Интервью на удаленке
📍Item Tracking: Трассировка требований. От хаоса к управляемости
📍Анализ нефункциональных требований: Нефункциональное
📍Приоритизация: Подборка про приоритеты
📍Прототипирование: Что такое прототипы и какими они бывают?
📍Опрос: Мифы о применении опросов при выявлении требований
📍Пользовательские истории: Может ли Agile-коуч писать плохие пользовательские истории?
📍Варианты использования: Подборка про варианты использования
📍Список и карта заинтересованных сторон: С кем важно говорить о требованиях на самом деле?
#что_почитать #инструменты #навигация
Решила провести аудит своих постов про #инструменты и сравнить с BABOK. Результат: 19 техник из 50 в этом канале упоминались. Кое-что полезное уже есть. Собрала все в один список. Буду рада, если пригодится! ☀️
📍Критерии приемки: Чем отличаются критерии приемки и DOD?
📍Управление бэклогом: Бэклог не может содержать все подряд
📍Бенчмаркинг: Как посмотреть, что делают другие?
📍Мозговой штурм: Мозговой штурм (brainstorm) работает или нет?
📍Decision Analysis: Как можно выбрать одно из двух зол?
📍Анализ процессов: Подборка примеров моделирования в BPMN
📍Оценка задач: Техники оценки задач
📍Фокус-группа: Для чего не годятся фокус-группы?
📍Функциональная декомпозиция: Функциональная декомпозиция
📍Глоссарий: Как это понимать?
📍Интервью: Про ошибки при проведении интервью с пользователями и Интервью на удаленке
📍Item Tracking: Трассировка требований. От хаоса к управляемости
📍Анализ нефункциональных требований: Нефункциональное
📍Приоритизация: Подборка про приоритеты
📍Прототипирование: Что такое прототипы и какими они бывают?
📍Опрос: Мифы о применении опросов при выявлении требований
📍Пользовательские истории: Может ли Agile-коуч писать плохие пользовательские истории?
📍Варианты использования: Подборка про варианты использования
📍Список и карта заинтересованных сторон: С кем важно говорить о требованиях на самом деле?
#что_почитать #инструменты #навигация
👍5❤2
Языковой барьер, шпинат и другие риски бизнес-анализа
Когда-то я бодро говорила, что аналитик переводит с языка бизнеса на язык ИТ. Теперь считаю, что сбор и систематизация информации, выявление потребностей, моделирование предметной области – это точно не про дословный перевод. Хотя, как выяснилось, иногда приходится заниматься и им.
В начале карьеры я работала на проекте для солидной немецкой корпорации. Там я, собственно, и училась быть аналитиком. В духе лучших традиций проект время от времени горел: требования пропускались, решения не соответствовали ожиданиям, сроки срывались. В какой-то момент менеджмент решил, что во всем виноват языковой барьер.
Логично же предположить, что когда на стороне заказчика все пишут по-немецки, на стороне исполнителя явно что-то не понимают. Решили организовать перевод исходного документа БТ с немецкого на английский, с последующим утверждением перевода на стороне заказчика. Тогда еще было не очень с машинным переводом. Я вызвалась на роль сервиса по переводу. Зря что ли три года учила немецкий? Интересный вызов. Заодно узнаю, что там на самом деле написано в этих требованиях.
Позже добавились командировки, чтобы мы улучшили контакт со стейкхолдерами. Хотя на немецком многие знали только "Хенде хох!"😊 Наша рабочая группа из менеджеров и аналитиков пару раз съездила в офис заказчика, где нас ждали не только требования, но и культурный шок от непривычного тогда формата офиса и еды.
В офисной столовой мы очень скучали по мясным блюдам. И когда один из коллег обнаружил на раздаче нечто котлетоподобное, мы дружно протянули тарелки, демонстрируя выдающиеся навыки невербальной коммуникации. Никто не удосужился прочитать табличку со словом "Spinat" (шпинат). Оказалось, мы сами не читаем ТЗ, а если не читаешь требования – получаешь не то, что ожидаешь.
Перевод с немецкого на английский я выполнила успешно, работала с энтузиазмом. Заказчик одобрил английский вариант...и проект продолжил идти своим ходом. Требования были "верхнеуровневые", объемные, но не качественные (помните про целостность, непротиворечивость, корректность и прочие критерии). Минимум схем, максимум абстрактных фраз. Даже если бы я вписала туда "Spinat", вряд ли бы кто-то заметил.
С тех пор я не перевожу требования, хотя это и правда интересный вызов ☀️
#истории
Когда-то я бодро говорила, что аналитик переводит с языка бизнеса на язык ИТ. Теперь считаю, что сбор и систематизация информации, выявление потребностей, моделирование предметной области – это точно не про дословный перевод. Хотя, как выяснилось, иногда приходится заниматься и им.
В начале карьеры я работала на проекте для солидной немецкой корпорации. Там я, собственно, и училась быть аналитиком. В духе лучших традиций проект время от времени горел: требования пропускались, решения не соответствовали ожиданиям, сроки срывались. В какой-то момент менеджмент решил, что во всем виноват языковой барьер.
Логично же предположить, что когда на стороне заказчика все пишут по-немецки, на стороне исполнителя явно что-то не понимают. Решили организовать перевод исходного документа БТ с немецкого на английский, с последующим утверждением перевода на стороне заказчика. Тогда еще было не очень с машинным переводом. Я вызвалась на роль сервиса по переводу. Зря что ли три года учила немецкий? Интересный вызов. Заодно узнаю, что там на самом деле написано в этих требованиях.
Позже добавились командировки, чтобы мы улучшили контакт со стейкхолдерами. Хотя на немецком многие знали только "Хенде хох!"😊 Наша рабочая группа из менеджеров и аналитиков пару раз съездила в офис заказчика, где нас ждали не только требования, но и культурный шок от непривычного тогда формата офиса и еды.
В офисной столовой мы очень скучали по мясным блюдам. И когда один из коллег обнаружил на раздаче нечто котлетоподобное, мы дружно протянули тарелки, демонстрируя выдающиеся навыки невербальной коммуникации. Никто не удосужился прочитать табличку со словом "Spinat" (шпинат). Оказалось, мы сами не читаем ТЗ, а если не читаешь требования – получаешь не то, что ожидаешь.
Перевод с немецкого на английский я выполнила успешно, работала с энтузиазмом. Заказчик одобрил английский вариант...и проект продолжил идти своим ходом. Требования были "верхнеуровневые", объемные, но не качественные (помните про целостность, непротиворечивость, корректность и прочие критерии). Минимум схем, максимум абстрактных фраз. Даже если бы я вписала туда "Spinat", вряд ли бы кто-то заметил.
С тех пор я не перевожу требования, хотя это и правда интересный вызов ☀️
#истории
❤2🔥2🥰1
Карта потоков создания ценности (Value Stream Mapping)
Value Stream Mapping (VSM) - инструмент визуализации и оптимизации процессов. Хотя он разработан в рамках бережливого производства и чаще ассоциируется с продуктовым менеджментом, его применяют и аналитики, что подтверждается, например, Agile Extension к BABOK (откуда взята картинка к этому посту).
Карта потоков создания ценности - это графическое представление шагов процесса по созданию и доставке продукта или услуги клиенту. Карта фиксирует не только последовательность операций, а еще информационные потоки и ключевые метрики: время, затрачиваемое на добавление ценности и время простоев.
Главная цель карты - выявить потери и «узкие места». Например, анализируя процесс подготовки требований, можно определить, какой процент времени уходит на согласования и реакцию на входящие вопросы. Важно помнить, что сама по себе карта - только инструмент. Для реальных улучшений необходима мотивация команды и желание оптимизировать процесс.
Используются два основных типа таких карт:
- Карта текущего состояния: изображает поток в том виде, в каком он применяется.
- Карта целевого состояния: показывает, как будет выглядеть поток создания ценности после внедрения улучшений.
Шаги для построения VSM:
📌Фокусировка и определение команды
▫️Выберите продукт, семейство продуктов или услугу и определите область действия карты потока создания ценности.
▫️Определите получаемую заказчиком ценность, чтобы можно было проследить её истоки.
▫️Соберите кросс-функциональную команду из людей со знаниями бизнес-домена и технических членов команды
▫️Определите владельца карты потока создания ценности из тех, кто имеет глубокое понимание текущего процесса.
📌Создание карты текущего состояния
▫️Определите производственный поток. Наблюдайте за потоком создания ценности или смоделируйте его. Agile Extention к BABOK советует проследить путь продукта, начав с шага, ближайшего к заказчику, и записать, двигаясь в обратном направлении к началу. Ход мысли может развиваться и от первой точки входа в процесс. Можно показать основные и вспомогательные операции двумя связанными последовательностями.
▫️Зафиксируйте поток информации, который жизненно важен для функционирования потока создания ценности. Поток информации включает такие вещи, как заказы, графики, время запасов, время переналадки, время цикла и количество задействованных операторов. Так получится коммуникационный поток в верхней части карты.
▫️Замерьте время. Для каждого шага запишите время обработки (Value-Added Time) и время ожидания (Non-Value-Added Time). Это позволит построить «временную линию» и увидеть общую продолжительность цикла.
📌Создание карты будущего состояния
▫️Определите области для улучшений. Шаги, не добавляющие ценности, являются источником потерь.
▫️Определите метрики улучшений. Основные метрики: полное время цикла(Lead Time, LT) – общее время выполнения шагов процесса, включая согласование, операции возврата, ожидание данных, материалов, объектов, исполнителей и прочих ресурсов; время обработки (Process Time, PT) – время непосредственного выполнения работы, дающей результат процесса, ценный для потребителя; доля работ, выполненных без ошибок (Percent Complete and Accurate, %C/A) - показывает, какой процент работы выполняется без ошибок и доработок.
VSM имеет свои ограничения:
▫️Без общего понимания и желания меняться карта останется просто красивой схемой.
▫️Может выглядеть пугающе из-за большого объема информации.
▫️Не подходит для исследовательских или нелинейных процессов.
▫️Легко увлечься созданием полной и идеальной карты вместо перехода к улучшениям.
📚Статьи о Value Stream Mapping
▫️Value Stream Mapping — инструкция к применению
▫️Value stream mapping как инструмент запуска изменений
▫️BABOK и Lean: строим карту потоков создания ценности для анализа бизнес-процессов
▫️Создание Value Stream Mapping
#инструменты #что_почитать
Value Stream Mapping (VSM) - инструмент визуализации и оптимизации процессов. Хотя он разработан в рамках бережливого производства и чаще ассоциируется с продуктовым менеджментом, его применяют и аналитики, что подтверждается, например, Agile Extension к BABOK (откуда взята картинка к этому посту).
Карта потоков создания ценности - это графическое представление шагов процесса по созданию и доставке продукта или услуги клиенту. Карта фиксирует не только последовательность операций, а еще информационные потоки и ключевые метрики: время, затрачиваемое на добавление ценности и время простоев.
Главная цель карты - выявить потери и «узкие места». Например, анализируя процесс подготовки требований, можно определить, какой процент времени уходит на согласования и реакцию на входящие вопросы. Важно помнить, что сама по себе карта - только инструмент. Для реальных улучшений необходима мотивация команды и желание оптимизировать процесс.
Используются два основных типа таких карт:
- Карта текущего состояния: изображает поток в том виде, в каком он применяется.
- Карта целевого состояния: показывает, как будет выглядеть поток создания ценности после внедрения улучшений.
Шаги для построения VSM:
📌Фокусировка и определение команды
▫️Выберите продукт, семейство продуктов или услугу и определите область действия карты потока создания ценности.
▫️Определите получаемую заказчиком ценность, чтобы можно было проследить её истоки.
▫️Соберите кросс-функциональную команду из людей со знаниями бизнес-домена и технических членов команды
▫️Определите владельца карты потока создания ценности из тех, кто имеет глубокое понимание текущего процесса.
📌Создание карты текущего состояния
▫️Определите производственный поток. Наблюдайте за потоком создания ценности или смоделируйте его. Agile Extention к BABOK советует проследить путь продукта, начав с шага, ближайшего к заказчику, и записать, двигаясь в обратном направлении к началу. Ход мысли может развиваться и от первой точки входа в процесс. Можно показать основные и вспомогательные операции двумя связанными последовательностями.
▫️Зафиксируйте поток информации, который жизненно важен для функционирования потока создания ценности. Поток информации включает такие вещи, как заказы, графики, время запасов, время переналадки, время цикла и количество задействованных операторов. Так получится коммуникационный поток в верхней части карты.
▫️Замерьте время. Для каждого шага запишите время обработки (Value-Added Time) и время ожидания (Non-Value-Added Time). Это позволит построить «временную линию» и увидеть общую продолжительность цикла.
📌Создание карты будущего состояния
▫️Определите области для улучшений. Шаги, не добавляющие ценности, являются источником потерь.
▫️Определите метрики улучшений. Основные метрики: полное время цикла(Lead Time, LT) – общее время выполнения шагов процесса, включая согласование, операции возврата, ожидание данных, материалов, объектов, исполнителей и прочих ресурсов; время обработки (Process Time, PT) – время непосредственного выполнения работы, дающей результат процесса, ценный для потребителя; доля работ, выполненных без ошибок (Percent Complete and Accurate, %C/A) - показывает, какой процент работы выполняется без ошибок и доработок.
VSM имеет свои ограничения:
▫️Без общего понимания и желания меняться карта останется просто красивой схемой.
▫️Может выглядеть пугающе из-за большого объема информации.
▫️Не подходит для исследовательских или нелинейных процессов.
▫️Легко увлечься созданием полной и идеальной карты вместо перехода к улучшениям.
📚Статьи о Value Stream Mapping
▫️Value Stream Mapping — инструкция к применению
▫️Value stream mapping как инструмент запуска изменений
▫️BABOK и Lean: строим карту потоков создания ценности для анализа бизнес-процессов
▫️Создание Value Stream Mapping
#инструменты #что_почитать
👍3
Искусство говорить «нет» в работе аналитика
Знакомый диалог?
- Задач на 24 часа в сутках, а тут еще одна срочная!
- Заказчик подкинул новую фичу. Когда, простите, этим заниматься?
Нужно магическое слово «Нет». Не истеричное «Нет, я и это должен делать по-вашему?» или «Cил нет!». Обоснованное «Нет», за которым стоит стратегия, не просто эмоция.
Впервые человек учится говорить «нет» в возрасте 2-3 лет, когда осознает себя чем-то отдельным от папы и мамы. Тогда речь идет о прогулках, каше с комочками и игрушках. Когда игрушки сменяются дедлайнами и ответственность больше, приходится заново учиться говорить «нет». Вдруг обидится заказчик или начальник подумает, что я не командный игрок? Не проще ли согласиться?
Спокойный мотивированный отказ – суперсила взрослого профессионала, который осознает свои интересы. Как и всякая суперсила, она может сделать вас сложным игроком в команде, приходится выбирать 💁♀️
Формула подготовки:
🔸Просчитайте риски. В три года ребенок говорит «нет» и смотрит, что будет. Задача взрослого – смоделировать последствия. Что будет, если согласиться? А что будет, если отказать? Самое сложное – ваши эмоции, ведь и надежда, и отчаяние обманывают одинаково.
🔸Поймите интересы других участников. Мы часто пытаемся общаться, исходя только из своего понимания задачи. У заказчика, у продакта и у начальника отдела свои интересы. Важная задача – собрать общую картину целей и интересов до того как придется работать с изменениями.
🔸Сформулируйте свою стратегию. Вам именно сейчас нужно сказать «нет», «да» или «может быть»? Что вы от этого выиграете? Какое альтернативное решение можете предложить? Что еще вам нужно понять?
Представьте: вы - сотрудник отдела снабжения, вы уже почти закупили провизию для научной морской экспедиции. 163 человека, 30 дней в плавании. Осталось только подписать контракты с поставщиками. Вдруг начальник экспедиции требует добавить в план закупки еще два ящика консервированных ананасов. Как быть? Оценим ситуацию и смоделируем несколько вариантов диалога, в реальности их могут быть десятки. Здесь разбор заинтересованных сторон для этого примера.
Новое требование может привести к необходимости пересогласовать бюджет и план закупок. Начальник экспедиции не является единственным владельцем бюджета. Его интересы могут пересекаться с интересами других участников. Например, судового кока, который уже придумал меню на весь период экспедиции. Не хватает информации о причине запроса. «Нет» или «Может быть» оставят вопрос нерешенным и, если причина запроса веская, она может стать барьером для всей задачи.
❓ Вариант 1. Отказ с опорой на регламент
Вы: У меня уже согласован план закупок, выбран поставщик, я не могу вносить изменения. Придется обратиться к руководству.
Начальник: То есть просто пойти к директору НИИ? (он пойдет к директору разбираться в ананасах. Этот вариант лучше оставить на случай, если без эскалации никак)
✅ Вариант 2. Находим причину запроса и альтернативное решение
Начальник: Нужны ананасы!
Вы: Почему на ваш взгляд это важно? (открытый вопрос для выяснения причин)
Начальник: Это для нашего профессора, ему врач вчера рекомендовал есть больше фруктов и исключить жирное.
Вы: Ясно! Давайте тогда не ломать весь план, а заменим часть сливочного масла в рационе на эти фрукты?
✅ Вариант 3. Выясняем контекст и находим «хотелку»
Начальник: Нужны ананасы!
Вы: Почему на ваш взгляд это важно?
Начальник: Ну это же очевидно! Все хотят ананасы! (подозрительная расплывчатость)
Вы: Мне будет проще предложить решение, если мы сможем обсудить контекст такой потребности. (не сдаемся)
Начальник: Моя тёща, она повар с 40-летним стажем, дала рецепт салата! Вы что, спорите с моей тёщей?!
Вы: Мне одинаково сложно спорить и с мнением опытного повара, и с уже согласованным планом закупок. Давайте посмотрим, какое меню согласовал судовой кок? (уклоняетесь от запроса и пытаетесь найти союзников со схожими интересами)
Что если завтра придет таможенник и прикажет вычеркнуть всю свежую рыбу из списка продуктов на борту? Поделитесь в комментариях своими идеями!
#софты #инструменты
Знакомый диалог?
- Задач на 24 часа в сутках, а тут еще одна срочная!
- Заказчик подкинул новую фичу. Когда, простите, этим заниматься?
Нужно магическое слово «Нет». Не истеричное «Нет, я и это должен делать по-вашему?» или «Cил нет!». Обоснованное «Нет», за которым стоит стратегия, не просто эмоция.
Впервые человек учится говорить «нет» в возрасте 2-3 лет, когда осознает себя чем-то отдельным от папы и мамы. Тогда речь идет о прогулках, каше с комочками и игрушках. Когда игрушки сменяются дедлайнами и ответственность больше, приходится заново учиться говорить «нет». Вдруг обидится заказчик или начальник подумает, что я не командный игрок? Не проще ли согласиться?
Спокойный мотивированный отказ – суперсила взрослого профессионала, который осознает свои интересы. Как и всякая суперсила, она может сделать вас сложным игроком в команде, приходится выбирать 💁♀️
Формула подготовки:
🔸Просчитайте риски. В три года ребенок говорит «нет» и смотрит, что будет. Задача взрослого – смоделировать последствия. Что будет, если согласиться? А что будет, если отказать? Самое сложное – ваши эмоции, ведь и надежда, и отчаяние обманывают одинаково.
🔸Поймите интересы других участников. Мы часто пытаемся общаться, исходя только из своего понимания задачи. У заказчика, у продакта и у начальника отдела свои интересы. Важная задача – собрать общую картину целей и интересов до того как придется работать с изменениями.
🔸Сформулируйте свою стратегию. Вам именно сейчас нужно сказать «нет», «да» или «может быть»? Что вы от этого выиграете? Какое альтернативное решение можете предложить? Что еще вам нужно понять?
Представьте: вы - сотрудник отдела снабжения, вы уже почти закупили провизию для научной морской экспедиции. 163 человека, 30 дней в плавании. Осталось только подписать контракты с поставщиками. Вдруг начальник экспедиции требует добавить в план закупки еще два ящика консервированных ананасов. Как быть? Оценим ситуацию и смоделируем несколько вариантов диалога, в реальности их могут быть десятки. Здесь разбор заинтересованных сторон для этого примера.
Новое требование может привести к необходимости пересогласовать бюджет и план закупок. Начальник экспедиции не является единственным владельцем бюджета. Его интересы могут пересекаться с интересами других участников. Например, судового кока, который уже придумал меню на весь период экспедиции. Не хватает информации о причине запроса. «Нет» или «Может быть» оставят вопрос нерешенным и, если причина запроса веская, она может стать барьером для всей задачи.
Вы: У меня уже согласован план закупок, выбран поставщик, я не могу вносить изменения. Придется обратиться к руководству.
Начальник: То есть просто пойти к директору НИИ? (он пойдет к директору разбираться в ананасах. Этот вариант лучше оставить на случай, если без эскалации никак)
Начальник: Нужны ананасы!
Вы: Почему на ваш взгляд это важно? (открытый вопрос для выяснения причин)
Начальник: Это для нашего профессора, ему врач вчера рекомендовал есть больше фруктов и исключить жирное.
Вы: Ясно! Давайте тогда не ломать весь план, а заменим часть сливочного масла в рационе на эти фрукты?
Начальник: Нужны ананасы!
Вы: Почему на ваш взгляд это важно?
Начальник: Ну это же очевидно! Все хотят ананасы! (подозрительная расплывчатость)
Вы: Мне будет проще предложить решение, если мы сможем обсудить контекст такой потребности. (не сдаемся)
Начальник: Моя тёща, она повар с 40-летним стажем, дала рецепт салата! Вы что, спорите с моей тёщей?!
Вы: Мне одинаково сложно спорить и с мнением опытного повара, и с уже согласованным планом закупок. Давайте посмотрим, какое меню согласовал судовой кок? (уклоняетесь от запроса и пытаетесь найти союзников со схожими интересами)
Что если завтра придет таможенник и прикажет вычеркнуть всю свежую рыбу из списка продуктов на борту? Поделитесь в комментариях своими идеями!
#софты #инструменты
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3👍1
Помните первый букварь?
Почему-то в День знаний больше тянет делиться эмоциями, чем знаниями. Я даже попросила родителей отсканировать мое первое школьное фото.
Здесь модели 6 лет, и она вся еще в летнем настроении. Воротничок съехал, челку пришлось заколоть, волосы выгорели на солнце - вообще непонятно, как там бант держится.
По тогдашней моде начальных классов прийти на линейку без белого банта было почти так же неприлично, как чиновнику явиться на совещание без галстука. К тому же это был обязательный атрибут праздника, для будних дней у нас были черные и коричневые ленты.
А манжеты? А фартук? Я запомнила это всё довольно неудобным, но важным атрибутом ответственного, состоявшегося человечка. Уже в конце сентября я с гордой усталостью труженика говорила приятелям по двору: «Некогда мне тут с вами, мне ещё дневник заполнять, манжеты пришивать и фартук гладить».
Обратите внимание: на обложке букваря тоже персонаж в почти таком же белом фартуке. Уверена, что не только у меня сохранилось фото с этой обложкой, где большая буква «А» на синем фоне 🙂 Это учебник под редакцией А. Горецкого, по которому все учились в конце 80-х. В нём были яркие картинки, ребусы и разбор по слогам «Ма-ма мы-ла ра-му».
К нему прилагались прописи с красной обложкой, в которых нужно было писать буквы красиво и с правильным наклоном.
Когда я пошла в школу, я уже умела читать, на уроках слегка скучала. Вот только первыми оценками были двойки. Потому что читать и писать нужно было не как хочешь, а по строгим правилам.
А мои поделки на уроках труда редко получали выше тройки. До сих пор помню перепуганного кота - аппликацию на кошельке с торчащими нитками, созданного из остатков ткани от маминой юбки.
Кто-то хранит до сих пор свои шедевры с уроков труда?
Я так и не научилась писать каллиграфически, как в прописях с красной обложкой, и шить котов по-прежнему сложно. Пожалуй, именно первый опыт проб и ошибок оказался самым познавательным в итоге. Вспоминаю первую двойку за диктант, каждый раз, когда задача кажется слишком легкой. А вдруг я чего-то не вижу и это работа на двойку?
Если вы сегодня как-то причастны к празднику — я вас искренне поздравляю и даже немного завидую 🙂
А всем нам, непричастным, пожелаю новых учебных целей на ближайший год. Когда ещё планировать учебу, как не в понедельник 1 сентября?
#мысливслух #истории
Почему-то в День знаний больше тянет делиться эмоциями, чем знаниями. Я даже попросила родителей отсканировать мое первое школьное фото.
Здесь модели 6 лет, и она вся еще в летнем настроении. Воротничок съехал, челку пришлось заколоть, волосы выгорели на солнце - вообще непонятно, как там бант держится.
По тогдашней моде начальных классов прийти на линейку без белого банта было почти так же неприлично, как чиновнику явиться на совещание без галстука. К тому же это был обязательный атрибут праздника, для будних дней у нас были черные и коричневые ленты.
А манжеты? А фартук? Я запомнила это всё довольно неудобным, но важным атрибутом ответственного, состоявшегося человечка. Уже в конце сентября я с гордой усталостью труженика говорила приятелям по двору: «Некогда мне тут с вами, мне ещё дневник заполнять, манжеты пришивать и фартук гладить».
Обратите внимание: на обложке букваря тоже персонаж в почти таком же белом фартуке. Уверена, что не только у меня сохранилось фото с этой обложкой, где большая буква «А» на синем фоне 🙂 Это учебник под редакцией А. Горецкого, по которому все учились в конце 80-х. В нём были яркие картинки, ребусы и разбор по слогам «Ма-ма мы-ла ра-му».
К нему прилагались прописи с красной обложкой, в которых нужно было писать буквы красиво и с правильным наклоном.
Когда я пошла в школу, я уже умела читать, на уроках слегка скучала. Вот только первыми оценками были двойки. Потому что читать и писать нужно было не как хочешь, а по строгим правилам.
А мои поделки на уроках труда редко получали выше тройки. До сих пор помню перепуганного кота - аппликацию на кошельке с торчащими нитками, созданного из остатков ткани от маминой юбки.
Кто-то хранит до сих пор свои шедевры с уроков труда?
Я так и не научилась писать каллиграфически, как в прописях с красной обложкой, и шить котов по-прежнему сложно. Пожалуй, именно первый опыт проб и ошибок оказался самым познавательным в итоге. Вспоминаю первую двойку за диктант, каждый раз, когда задача кажется слишком легкой. А вдруг я чего-то не вижу и это работа на двойку?
Если вы сегодня как-то причастны к празднику — я вас искренне поздравляю и даже немного завидую 🙂
А всем нам, непричастным, пожелаю новых учебных целей на ближайший год. Когда ещё планировать учебу, как не в понедельник 1 сентября?
#мысливслух #истории
❤4😁2👍1
Нотации моделирования бизнес-процессов
В своих списках для чтения подобрала несколько статей о нотациях моделирования. Здесь оказались детальные статьи и обзоры о разных нотациях:
▫️VAD (value added chain diagram),
▫️EPC (event-driven process chain),
▫️BPMN (Business Process Model and Notation 2.0),
▫️Flow Charting,
▫️IDEF (Integrated Definition Language),
▫️VSM (Value Stream Mapping),
▫️SIPOC (Supplier, Input, Process, Output, Customer)
📍Моделирование бизнес-процессов – обзор нотаций Обзор восьми нотаций: VAD, EPC, BPMN, Flow Charting, IDEF, VSM, SIPOC
🎥Нотация BPMN: как оптимизировать процесс подбора сотрудников Видео, где моделирование и выявление точек оптимизации показывает Алексей Коптелов, вице-президент ассоциации процессных аналитиков
📍Один пример и три нотации: сравниваем BPMN, EPC и DMN Эта статья в базе знаний Systems.Education интересна четкой структурой, примерами и развернутым резюме по выбору нотаций
📍Карта потоков создания ценности (Value Stream Mapping) Пост в этом канале с рекомендациями по созданию VSM
📍IDEF, EPC и BPMN: как выбрать нотацию для моделирования бизнес-процессов Еще один обзор трех нотаций с примерами
📍5 ошибок при проектировании бизнес-процессов и как их избежать В статье перечислены типовые промахи при работе с процессом. Если честно, то сначала хотела пройти мимо этой статьи, но решила, что статья может пригодиться начинающим
📍Основные нотации моделирования бизнес процессов и их применение Обзорная статья по нескольким нотациям, формат ознакомительный "обо всем понемногу"
📍Подборка примеров моделирования в BPMN Подборка полезностей для тех, кто моделирует в BPMN. Пост в этом канале, где я выбрала статьи с примерами применения BPMN от известных авторов и добавила ссылки на пару своих
#что_почитать
В своих списках для чтения подобрала несколько статей о нотациях моделирования. Здесь оказались детальные статьи и обзоры о разных нотациях:
▫️VAD (value added chain diagram),
▫️EPC (event-driven process chain),
▫️BPMN (Business Process Model and Notation 2.0),
▫️Flow Charting,
▫️IDEF (Integrated Definition Language),
▫️VSM (Value Stream Mapping),
▫️SIPOC (Supplier, Input, Process, Output, Customer)
📍Моделирование бизнес-процессов – обзор нотаций Обзор восьми нотаций: VAD, EPC, BPMN, Flow Charting, IDEF, VSM, SIPOC
🎥Нотация BPMN: как оптимизировать процесс подбора сотрудников Видео, где моделирование и выявление точек оптимизации показывает Алексей Коптелов, вице-президент ассоциации процессных аналитиков
📍Один пример и три нотации: сравниваем BPMN, EPC и DMN Эта статья в базе знаний Systems.Education интересна четкой структурой, примерами и развернутым резюме по выбору нотаций
📍Карта потоков создания ценности (Value Stream Mapping) Пост в этом канале с рекомендациями по созданию VSM
📍IDEF, EPC и BPMN: как выбрать нотацию для моделирования бизнес-процессов Еще один обзор трех нотаций с примерами
📍5 ошибок при проектировании бизнес-процессов и как их избежать В статье перечислены типовые промахи при работе с процессом. Если честно, то сначала хотела пройти мимо этой статьи, но решила, что статья может пригодиться начинающим
📍Основные нотации моделирования бизнес процессов и их применение Обзорная статья по нескольким нотациям, формат ознакомительный "обо всем понемногу"
📍Подборка примеров моделирования в BPMN Подборка полезностей для тех, кто моделирует в BPMN. Пост в этом канале, где я выбрала статьи с примерами применения BPMN от известных авторов и добавила ссылки на пару своих
#что_почитать
👍5❤2
Big Tech Night или как найти вход под надписью «Входа нет»
Побывала на Big Tech Night. Представьте себе «Ночь музеев», но вместо картин — офисы с бесплатным кофе. Формат и правда занятный: с 17:30 до 22:30 в офисах компаний-организаторов шли доклады, а потом афтерпати до полуночи.
Первый офис в маршруте
Первым на моем пути значился офис Т-Банка. Чтобы попасть внутрь, нужно было сначала найти правильный вход, он оказался под светящейся надписью «Входа нет». Без сопровождающих в черно-желтой униформе я бы, наверное, до сих пор ходила кругами 😊
Внутри кипела жизнь: кофе, маффины и доклады. Особенно тронула табличка: «Дорогие гости, перед вами офисное пространство, там нет ничего интересного!». Видимо, кто-то в пятницу вечером пытался доделывать задачи под гул активного нетворкинга.
Понравились форматы общения. Кроме классических докладов был «квартирник» для тех, кто любит обсудить тимлидов в обстановке, похожей на посиделки в гостиной. Или сессии 1-to-1 с IT-менеджерами напоминавшие одновременную игру в шахматы.
На участие моих сил не хватило и я выбрала тактическое отступление. В следующий офис, Lamoda.
Следующий офис и что делать с «потеряшками»?
В офисе Lamoda я послушала доклад о «сотрудниках-потеряшках». То есть тех, кто вечно не доволен и плохо перформит от того, что не может определится нравится ли ему в тех задачах, где он оказался. Обсуждался системный подход помощи таким людям с точки зрения руководителя и самого сотрудника. Если помочь человеку "найтись", есть шанс получить образцового и лояльного сотрудника, который оценит, что к нему отнеслись как к человеку, а не к функции.
Рассказ развивался от простого к сложному:
🔸Уровень 1: Проверить базовые вещи: подходит ли сотруднику сфера, проекты, ценности команды? Дать четкую обратную связь, акцентируя его сильные стороны.
🔸Уровень 2: Если состояние затянулось, причина, скорее всего, глубже. Часто человек настолько сфокусирован на ожиданиях других, что напрочь заглушил собственные «хочу» и «нравится».
🔸Важное предупреждение: Прежде чем бросаться на помощь, установите границы помощи и критерии результата. Ваша цель — не стать личным психологом, а вернуть ценного сотрудника в рабочий режим. Даже если человек «найдется», он не обязательно станет образцовым сотрудником.
Вот такие заметки я привезла из двух офисов. В моем билете был еще офис Яндекса, но я туда так и не доехала. Если удастся еще раз попасть на что-то подобное – постараюсь пройти все точки маршрута😎
#конференции
Побывала на Big Tech Night. Представьте себе «Ночь музеев», но вместо картин — офисы с бесплатным кофе. Формат и правда занятный: с 17:30 до 22:30 в офисах компаний-организаторов шли доклады, а потом афтерпати до полуночи.
Первый офис в маршруте
Первым на моем пути значился офис Т-Банка. Чтобы попасть внутрь, нужно было сначала найти правильный вход, он оказался под светящейся надписью «Входа нет». Без сопровождающих в черно-желтой униформе я бы, наверное, до сих пор ходила кругами 😊
Внутри кипела жизнь: кофе, маффины и доклады. Особенно тронула табличка: «Дорогие гости, перед вами офисное пространство, там нет ничего интересного!». Видимо, кто-то в пятницу вечером пытался доделывать задачи под гул активного нетворкинга.
Понравились форматы общения. Кроме классических докладов был «квартирник» для тех, кто любит обсудить тимлидов в обстановке, похожей на посиделки в гостиной. Или сессии 1-to-1 с IT-менеджерами напоминавшие одновременную игру в шахматы.
На участие моих сил не хватило и я выбрала тактическое отступление. В следующий офис, Lamoda.
Следующий офис и что делать с «потеряшками»?
В офисе Lamoda я послушала доклад о «сотрудниках-потеряшках». То есть тех, кто вечно не доволен и плохо перформит от того, что не может определится нравится ли ему в тех задачах, где он оказался. Обсуждался системный подход помощи таким людям с точки зрения руководителя и самого сотрудника. Если помочь человеку "найтись", есть шанс получить образцового и лояльного сотрудника, который оценит, что к нему отнеслись как к человеку, а не к функции.
Рассказ развивался от простого к сложному:
🔸Уровень 1: Проверить базовые вещи: подходит ли сотруднику сфера, проекты, ценности команды? Дать четкую обратную связь, акцентируя его сильные стороны.
🔸Уровень 2: Если состояние затянулось, причина, скорее всего, глубже. Часто человек настолько сфокусирован на ожиданиях других, что напрочь заглушил собственные «хочу» и «нравится».
🔸Важное предупреждение: Прежде чем бросаться на помощь, установите границы помощи и критерии результата. Ваша цель — не стать личным психологом, а вернуть ценного сотрудника в рабочий режим. Даже если человек «найдется», он не обязательно станет образцовым сотрудником.
Вот такие заметки я привезла из двух офисов. В моем билете был еще офис Яндекса, но я туда так и не доехала. Если удастся еще раз попасть на что-то подобное – постараюсь пройти все точки маршрута
#конференции
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7🔥3❤2
5 статей, которые помогут прокачать навыки коммуникации
Проблемы в коммуникации - частая причина потерь времени, недопонимания и срыва дедлайнов. Собрала подборку материалов, которые могут помочь аналитику выстроить коммуникацию в команде. Добавила к находкам и свой личный опыт.
📌«Что? Где? Когда?» и эмоциональный интеллект в бизнес-команде здесь автор описал инструменты, важные для проведения командных встреч. Описал с иллюстрациями из своего хобби – капитанства в «Что? Где? Когда?». Разговор здесь о проведении командных встреч, а фото команды во время игр и тренировок очень хорошо дополняют рассказ. А сам рассказ о создании безопасной среды, активное вовлечение участников встречи, управление групповой динамикой, отделении эмоций от решений, эмпатия при конфликтах и не только.
📌Повод больше общаться или ужас? Пост в этом канале о сложностях передачи идей через документацию и проблемах несоответствия реализации изначальной постановке. Одни только идеально написанные документы не гарантируют понимания, на их восприятие влияют мотивация команды и когнитивные искажения. Решением видится активное личное взаимодействие: обсуждения, ответы на вопросы и совместные встречи
📌The Hidden Cost of Side Quests: How BAs Can Protect Their Time (EN) Бизнес-аналитики часто отвлекаются на побочные задачи (поддержка, тестирование), которые мешают их основной работе. Чтобы защитить свои приоритеты, вместо прямого отказа «нет» стоит использовать стратегию «да, но», предлагая варианты и озвучивая последствия для основных проектов. В крайних случаях необходимо твердо, но вежливо сказать «нет», чтобы избежать перегруза и выгорания.
📌Слушать активно, а говорить короче Когда-то в этом канале делилась статьями и историями о том как корректное общение внутри команды критически важно для продуктивной работы. Грубость или путаница в коммуникации приводят к потерям времени, недопониманию и рискам для проекта. Ключевые навыки для улучшения взаимодействия включают активное слушание, использование местоимения «мы» для сплочения команды и умение четко и кратко доносить свои идеи.
📌Как аналитику избежать когнитивных искажений? В прошлом году написала несколько постов о когнитивных искажениях и это один из них. Здесь мой список топ-3 проявлений "ловушек сознания" в работе аналитика и мысли о том, как их компенсировать.
#что_почитать #софты
Проблемы в коммуникации - частая причина потерь времени, недопонимания и срыва дедлайнов. Собрала подборку материалов, которые могут помочь аналитику выстроить коммуникацию в команде. Добавила к находкам и свой личный опыт.
📌«Что? Где? Когда?» и эмоциональный интеллект в бизнес-команде здесь автор описал инструменты, важные для проведения командных встреч. Описал с иллюстрациями из своего хобби – капитанства в «Что? Где? Когда?». Разговор здесь о проведении командных встреч, а фото команды во время игр и тренировок очень хорошо дополняют рассказ. А сам рассказ о создании безопасной среды, активное вовлечение участников встречи, управление групповой динамикой, отделении эмоций от решений, эмпатия при конфликтах и не только.
📌Повод больше общаться или ужас? Пост в этом канале о сложностях передачи идей через документацию и проблемах несоответствия реализации изначальной постановке. Одни только идеально написанные документы не гарантируют понимания, на их восприятие влияют мотивация команды и когнитивные искажения. Решением видится активное личное взаимодействие: обсуждения, ответы на вопросы и совместные встречи
📌The Hidden Cost of Side Quests: How BAs Can Protect Their Time (EN) Бизнес-аналитики часто отвлекаются на побочные задачи (поддержка, тестирование), которые мешают их основной работе. Чтобы защитить свои приоритеты, вместо прямого отказа «нет» стоит использовать стратегию «да, но», предлагая варианты и озвучивая последствия для основных проектов. В крайних случаях необходимо твердо, но вежливо сказать «нет», чтобы избежать перегруза и выгорания.
📌Слушать активно, а говорить короче Когда-то в этом канале делилась статьями и историями о том как корректное общение внутри команды критически важно для продуктивной работы. Грубость или путаница в коммуникации приводят к потерям времени, недопониманию и рискам для проекта. Ключевые навыки для улучшения взаимодействия включают активное слушание, использование местоимения «мы» для сплочения команды и умение четко и кратко доносить свои идеи.
📌Как аналитику избежать когнитивных искажений? В прошлом году написала несколько постов о когнитивных искажениях и это один из них. Здесь мой список топ-3 проявлений "ловушек сознания" в работе аналитика и мысли о том, как их компенсировать.
#что_почитать #софты
👍3🔥1