О чем говорят продуктовые аналитики?
Стало интересно заглянуть в смежную сферу знаний и это любопытство привело меня вчера на конференцию Aha!'24
Здесь было много рукопожатий, стендов от партнеров, пирожков, лаунж-зон, где шло общение, и не очень много людей в залах на докладах. Народ собрался общаться.
Я очень грустила без программы конференции в каком-то удобном виде. Одновременно шли три стрима докладов и еще два с воркшопами, консультациями и прочими штуками, не хватало удобной карты перед глазами. Но это мне не помешало послушать 8 докладов😎
Послушала доклад аналитика из 2ГИС с рассказом как пришли к лаконичному решению, чтобы заполнить снимками зданий карточки объектов на карте. Придумали игровую технику для активных пользователей, они могли получать задания в телеграм-боте и туда же отправлять фото. Дальше шел рассказ о модерации этого контента. Очень интересно было послушать. Для себя отметила в докладе, что процент конверсии подписок на бота в выполненные задания составил 5%, но и эти 5% решают поставленную задачу
Привлек доклад с названием "Как микро-командой аналитиков сопровождать сотни запусков фичей и не потерять фокус и скорость". Пока шел рассказ об организации задач, диаграммах в Jira и настройке инфраструктуры я совсем уже было разочаровалась. Потом началось интересное про эмуляцию изменения метрик на основании вычислительных методов. Вместо дорогого a/б – теста. А дальше предложение серьезнее выбирать гипотезы для исследований и вывод "Экономьте на пустых идеях, а не на аналитиках", то есть если не тратить время на заведомо ненужные задачи, то и с рабочими руками будет проще. Мне фраза так понравилось, что я ее тут же записала
Конечно, много говорили об a/б – тестах, ML и AI, метриках и гипотезах, продуктовых стратегиях и роли продакта. Я обогатилась новыми для меня терминами, например: Customer Effort Score (подобнее об этой метрике тут), Difference-in-difference (об этом статистическом методе нашлось тут).
Было забавно ходить с бейджиком, где написано Junior. Это не про возраст и не про знания, так назывался тариф моего билета. У меня давно этого слова не появляется на бейджах и было даже приятно, что так удачно заглянула к продуктовым аналитикам 🌱
#мысливслух #конференции
Стало интересно заглянуть в смежную сферу знаний и это любопытство привело меня вчера на конференцию Aha!'24
Здесь было много рукопожатий, стендов от партнеров, пирожков, лаунж-зон, где шло общение, и не очень много людей в залах на докладах. Народ собрался общаться.
Я очень грустила без программы конференции в каком-то удобном виде. Одновременно шли три стрима докладов и еще два с воркшопами, консультациями и прочими штуками, не хватало удобной карты перед глазами. Но это мне не помешало послушать 8 докладов
Послушала доклад аналитика из 2ГИС с рассказом как пришли к лаконичному решению, чтобы заполнить снимками зданий карточки объектов на карте. Придумали игровую технику для активных пользователей, они могли получать задания в телеграм-боте и туда же отправлять фото. Дальше шел рассказ о модерации этого контента. Очень интересно было послушать. Для себя отметила в докладе, что процент конверсии подписок на бота в выполненные задания составил 5%, но и эти 5% решают поставленную задачу
Привлек доклад с названием "Как микро-командой аналитиков сопровождать сотни запусков фичей и не потерять фокус и скорость". Пока шел рассказ об организации задач, диаграммах в Jira и настройке инфраструктуры я совсем уже было разочаровалась. Потом началось интересное про эмуляцию изменения метрик на основании вычислительных методов. Вместо дорогого a/б – теста. А дальше предложение серьезнее выбирать гипотезы для исследований и вывод "Экономьте на пустых идеях, а не на аналитиках", то есть если не тратить время на заведомо ненужные задачи, то и с рабочими руками будет проще. Мне фраза так понравилось, что я ее тут же записала
Конечно, много говорили об a/б – тестах, ML и AI, метриках и гипотезах, продуктовых стратегиях и роли продакта. Я обогатилась новыми для меня терминами, например: Customer Effort Score (подобнее об этой метрике тут), Difference-in-difference (об этом статистическом методе нашлось тут).
Было забавно ходить с бейджиком, где написано Junior. Это не про возраст и не про знания, так назывался тариф моего билета. У меня давно этого слова не появляется на бейджах и было даже приятно, что так удачно заглянула к продуктовым аналитикам 🌱
#мысливслух #конференции
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2❤1👍1
Документация и виды требований
На прошлой неделе организаторы Flow начали выкладывать доклады с весенней конференции и начали с Сожгите ваши системные требования. Пользовательские требования — ключ к успешному продукту. Когда-то я писала об этом докладе в посте с впечатлениями о Flow
Тема документирования завела меня в список недавно отмеченных статей на близкие темы. Делюсь статьями и мнением
📍Как писать требования и документацию к проекту. Полный гайд с шаблоном документации и примерами заполнения Автор поясняет, что это статья в помощь начинающим. Всегда интересно посмотреть примеры чьих-то задач, здесь это как раз есть: примеры документов и как они заполнены. К этой статье мне не хватило пояснения к процессу производства, на каких шагах и для какой аудитории рождаются эти документы. Если вы делаете первые шаги в анализе, то учитывайте, что в статье изложена не общая практика, а подход конкретной команды
📍Нужно ли писать документацию? Это в основном сторителлинг с описанием сценариев, когда даже не самая лучшая документация может сберечь время команды. Не думаю, что опытные аналитики найдут что-то новое, описаны известные боли
📍Технические задания и IT-системы: разбираемся, как ожидания мэтчить с реальностью Еще один пример опыта конкретной команды, где информацию оформляют в некоей смеси каркасного макета и слайдов презентации. Не советую считать такой формат гарантией полного понимания требований всеми участниками, тем не менее в индустрии такие варианты встречаются. Мне приходилось в таком участвовать и получать нечто похожее на согласование
📍Уж послала, так послала: словосочетания-паразиты в технических текстах и 17 вредных советов для тех, кто проверяет документацию и технические тексты Две статьи одного и того же автора о стиле высказываний в комментариях и текстах технической документации. Местами выглядит перфекционизмом, но мнение интересное
#что_почитать
На прошлой неделе организаторы Flow начали выкладывать доклады с весенней конференции и начали с Сожгите ваши системные требования. Пользовательские требования — ключ к успешному продукту. Когда-то я писала об этом докладе в посте с впечатлениями о Flow
Тема документирования завела меня в список недавно отмеченных статей на близкие темы. Делюсь статьями и мнением
📍Как писать требования и документацию к проекту. Полный гайд с шаблоном документации и примерами заполнения Автор поясняет, что это статья в помощь начинающим. Всегда интересно посмотреть примеры чьих-то задач, здесь это как раз есть: примеры документов и как они заполнены. К этой статье мне не хватило пояснения к процессу производства, на каких шагах и для какой аудитории рождаются эти документы. Если вы делаете первые шаги в анализе, то учитывайте, что в статье изложена не общая практика, а подход конкретной команды
📍Нужно ли писать документацию? Это в основном сторителлинг с описанием сценариев, когда даже не самая лучшая документация может сберечь время команды. Не думаю, что опытные аналитики найдут что-то новое, описаны известные боли
📍Технические задания и IT-системы: разбираемся, как ожидания мэтчить с реальностью Еще один пример опыта конкретной команды, где информацию оформляют в некоей смеси каркасного макета и слайдов презентации. Не советую считать такой формат гарантией полного понимания требований всеми участниками, тем не менее в индустрии такие варианты встречаются. Мне приходилось в таком участвовать и получать нечто похожее на согласование
📍Уж послала, так послала: словосочетания-паразиты в технических текстах и 17 вредных советов для тех, кто проверяет документацию и технические тексты Две статьи одного и того же автора о стиле высказываний в комментариях и текстах технической документации. Местами выглядит перфекционизмом, но мнение интересное
#что_почитать
👍2
Не будет второго шанса произвести первое впечатление
Эту фразу от Коко Шанель можно применить в многих историях, я решила ее применить к истории про резюме. В последнее время через мои руки прошло несколько резюме и друзья-коллеги тоже поделились впечатлениями из своего опыта. Не хочу отнимать хлеб у тех, кто постоянно работает в сфере найма и карьерных консультаций, но не могу не поделиться впечатлениями. Резюме и сопроводительное письмо – это как раз первое впечатление от вашего профессионализма.
Если в резюме неправильно назван рабочий инструмент или методика, это может выглядеть так, будто автор в глаза не видел, то о чем пишет. У нанимающих менеджеров опыт может быть разным. Коллеги в нанимающих командах по несколько часов в день проводят в собеседованиях и при этом никто не останавливает задачи, в которых они менеджеры или эксперты. Когда предыдущий кандидат с грубыми опечатками в резюме показал себя не лучшим образом, будет ли интересно еще раз дать кому-то шанс?
Кто участвует в найме, наверное, начинает сочувствовать своему учителю литературы. Учителю приходилось десятки раз в день читать про "луч света в темном царстве" или что мы там еще списывали друг у друга и у Добролюбова? Проверьте, на всякий случай нет ли у вас в резюме фразы "аналитический склад ума, ответственность и внимание к деталям"? Это клише содержится в таком количестве резюме, что ни одно из них уже не украсит. Особенно в сочетании с опечатками. Даже если у кандидата и правда аналитический склад ума😎
В общем, лучше не списывать фразы из резюме у коллег и внимательно проверять опечатки. Делюсь парой вариантов досадных неточностей:
📍кандидат сообщает, что три года работает в индустрии и знает Githab(Видимо, это Github)
📍работал с гибридной распределенной базой данных (Кafka)(Kafka меньше всего можно назвать базой данных)
📍интересуюсь Phyton (Лучше интересоваться Python)
📍Gif (система контроля версий) (Видимо, это про Git)
📍нотация описания процессов UML(UML- это универсальный язык моделирования, а не нотация для описания процессов)
📍BPMN-система(Системы управления процессами – это BPMS, BPMN – это обозначение нотации)
#мысливслух #карьера
Эту фразу от Коко Шанель можно применить в многих историях, я решила ее применить к истории про резюме. В последнее время через мои руки прошло несколько резюме и друзья-коллеги тоже поделились впечатлениями из своего опыта. Не хочу отнимать хлеб у тех, кто постоянно работает в сфере найма и карьерных консультаций, но не могу не поделиться впечатлениями. Резюме и сопроводительное письмо – это как раз первое впечатление от вашего профессионализма.
Если в резюме неправильно назван рабочий инструмент или методика, это может выглядеть так, будто автор в глаза не видел, то о чем пишет. У нанимающих менеджеров опыт может быть разным. Коллеги в нанимающих командах по несколько часов в день проводят в собеседованиях и при этом никто не останавливает задачи, в которых они менеджеры или эксперты. Когда предыдущий кандидат с грубыми опечатками в резюме показал себя не лучшим образом, будет ли интересно еще раз дать кому-то шанс?
Кто участвует в найме, наверное, начинает сочувствовать своему учителю литературы. Учителю приходилось десятки раз в день читать про "луч света в темном царстве" или что мы там еще списывали друг у друга и у Добролюбова? Проверьте, на всякий случай нет ли у вас в резюме фразы "аналитический склад ума, ответственность и внимание к деталям"? Это клише содержится в таком количестве резюме, что ни одно из них уже не украсит. Особенно в сочетании с опечатками. Даже если у кандидата и правда аналитический склад ума
В общем, лучше не списывать фразы из резюме у коллег и внимательно проверять опечатки. Делюсь парой вариантов досадных неточностей:
📍кандидат сообщает, что три года работает в индустрии и знает Githab
📍работал с гибридной распределенной базой данных (Кafka)
📍интересуюсь Phyton
📍Gif (система контроля версий)
📍нотация описания процессов UML
📍BPMN-система
#мысливслух #карьера
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7
Как работает шаблон документа?
"Какой взять шаблон?", - вопрос часто звучит, когда аналитик принимается за задачу. В инфопространстве коллеги активно делятся шаблонами. Только в одном из каналов с полезностями для СА и БА обнаружилось 73 ссылки на статьи с шаблонами документов. Когда в задаче не требуется следование конкретному стандарту, обращаются к шаблонам из открытых источников для экономии сил и времени. Вот только можно зря потратить много часов, если безусловно следовать шаблону без понимания теории и практики его применения.
Сам по себе шаблон не гарантирует качественный анализ. Лучше всего работают шаблоны, которые вы сами придумали в своей команде с учетом специфики именно ваших задач. Это похоже на шпаргалку, которую вы составили сами и хорошо понимаете где в ней искать ответ на конкретный вопрос экзамена. Шпаргалка другого студента не будет так хорошо работать в вашем случае, тем более, если она к какому-то другому экзамену.
Например, в одном из шаблонов мне встретился раздел с PESTEL-анализом. Если не понимать, что это за техника и для чего этот раздел, то заполнение потребует времени. Действительно ли будет важен анализ политических, социальных, экономических, экологических факторов в проекте по разработке нового отчета для вашего руководителя? Если формально заполнять разделы, то шаблон может превратиться в пожирателя времени
Шаблон полезен, когда у аналитика есть понимание, что он в нем ищет. Если на новом месте работы обнаружатся шаблоны документов – будет проще ориентироваться в ожиданиях от вашей работы. Когда есть простор в выборе структуры документа – шаблоны подскажут идеи из опыта разных команд. Если вы придумали шаблон сами – получится чек-лист для вашей работы в текущих задачах, но это не обязательно означает, что он выручит и любого другого аналитика.
Делюсь примерами, которые в последнее время попадали в поле зрения. В этом списке нет ни полноты, ни особой логики. Просто небольшая иллюстрация к теме поста.
📍Формат BRD и FSD (ENG)
📍Как писать требования и документацию к проекту. Полный гайд с шаблоном документации и примерами заполнения
📍Что такое бизнес-требования и как с ними не бороться (в последнем разделе статьи структура документа)
📍Артефакты аналитика: документы и техники
📍Как писать требования к проекту. Шаблон документации
📍Стандарты и шаблоны для ТЗ на разработку ПО (обзор форматов, соответственно разным стандартов, со ссылками на примеры)
#мысливслух #что_почитать #инструменты
"Какой взять шаблон?", - вопрос часто звучит, когда аналитик принимается за задачу. В инфопространстве коллеги активно делятся шаблонами. Только в одном из каналов с полезностями для СА и БА обнаружилось 73 ссылки на статьи с шаблонами документов. Когда в задаче не требуется следование конкретному стандарту, обращаются к шаблонам из открытых источников для экономии сил и времени. Вот только можно зря потратить много часов, если безусловно следовать шаблону без понимания теории и практики его применения.
Сам по себе шаблон не гарантирует качественный анализ. Лучше всего работают шаблоны, которые вы сами придумали в своей команде с учетом специфики именно ваших задач. Это похоже на шпаргалку, которую вы составили сами и хорошо понимаете где в ней искать ответ на конкретный вопрос экзамена. Шпаргалка другого студента не будет так хорошо работать в вашем случае, тем более, если она к какому-то другому экзамену.
Например, в одном из шаблонов мне встретился раздел с PESTEL-анализом. Если не понимать, что это за техника и для чего этот раздел, то заполнение потребует времени. Действительно ли будет важен анализ политических, социальных, экономических, экологических факторов в проекте по разработке нового отчета для вашего руководителя? Если формально заполнять разделы, то шаблон может превратиться в пожирателя времени
Шаблон полезен, когда у аналитика есть понимание, что он в нем ищет. Если на новом месте работы обнаружатся шаблоны документов – будет проще ориентироваться в ожиданиях от вашей работы. Когда есть простор в выборе структуры документа – шаблоны подскажут идеи из опыта разных команд. Если вы придумали шаблон сами – получится чек-лист для вашей работы в текущих задачах, но это не обязательно означает, что он выручит и любого другого аналитика.
Делюсь примерами, которые в последнее время попадали в поле зрения. В этом списке нет ни полноты, ни особой логики. Просто небольшая иллюстрация к теме поста.
📍Формат BRD и FSD (ENG)
📍Как писать требования и документацию к проекту. Полный гайд с шаблоном документации и примерами заполнения
📍Что такое бизнес-требования и как с ними не бороться (в последнем разделе статьи структура документа)
📍Артефакты аналитика: документы и техники
📍Как писать требования к проекту. Шаблон документации
📍Стандарты и шаблоны для ТЗ на разработку ПО (обзор форматов, соответственно разным стандартов, со ссылками на примеры)
#мысливслух #что_почитать #инструменты
👍8🔥1
9 месяцев
На этой неделе нашему уютному каналу исполнилось 9 месяцев, вполне солидный возраст для младенца. И вот что я заметила из "родительского" опыта...
В начале работы над каналом я почему-то наивно думала, что читатели приходят только за образовательным контентом и нужно его раздавать побольше. Понаблюдала за собой и за каналом, сходила на курс по написанию постов и поняла простую вещь. Мы читаем каналы и блоги не столько ради каких-то академических полезностей, а ради опыта конкретного автора. Интересно же какие он читает книги, что применяет для решения задач и как у него это получается. Такие посты у нас здесь собирают больше всего лайков. А подборки и книги – больше всего пересылок, видимо, их удобно "прикопать" в каком-то личном списке. Помните про цундоку?
Формат коротких постов оказался хорошей тренировкой в формулировании мыслей. Количество символов в 4096 (а если с фото, то 1024) обязывает учиться видеть слова и даже целые предложения, которые можно убрать из текста без потери смысла. Я стала справляться с этим заметно быстрее и замечаю как входит в привычку на любой свой текст смотреть с прищуром: "А эти слова тут точно нужны? Суть вопроса я передала?" Думаю, привычка не вредная, буду двигаться в этом направлении. То есть писать. Короткими предложениями.
Не очень сложно научиться коротко формулировать мысли и научиться не запихивать больше одной идеи в один пост, а вот раскрывать что-то про себя в формате даже небольшого канала – сложно. Без этого не получается искренний обмен опытом. Есть о чем подумать, а для начала прикрепила к этому посту фото из недавнего отпуска. Это там у меня было время почитать книги 🌱
За ближайшие пару месяцев больше всего просмотров набрали
📍Аналитик с опытом может быть новичком!
📍Мифы о применении опросов при выявлении требований
📍Нужно ли команде тратить время на ревью требований? (peer-to-peer review)
📍Что здесь есть о выявлении требований?
📍Быстрее, лучше, дешевле. Девять методов реинжиниринга бизнес-процессов
#мысливслух #навигация
На этой неделе нашему уютному каналу исполнилось 9 месяцев, вполне солидный возраст для младенца. И вот что я заметила из "родительского" опыта...
В начале работы над каналом я почему-то наивно думала, что читатели приходят только за образовательным контентом и нужно его раздавать побольше. Понаблюдала за собой и за каналом, сходила на курс по написанию постов и поняла простую вещь. Мы читаем каналы и блоги не столько ради каких-то академических полезностей, а ради опыта конкретного автора. Интересно же какие он читает книги, что применяет для решения задач и как у него это получается. Такие посты у нас здесь собирают больше всего лайков. А подборки и книги – больше всего пересылок, видимо, их удобно "прикопать" в каком-то личном списке. Помните про цундоку?
Формат коротких постов оказался хорошей тренировкой в формулировании мыслей. Количество символов в 4096 (а если с фото, то 1024) обязывает учиться видеть слова и даже целые предложения, которые можно убрать из текста без потери смысла. Я стала справляться с этим заметно быстрее и замечаю как входит в привычку на любой свой текст смотреть с прищуром: "А эти слова тут точно нужны? Суть вопроса я передала?" Думаю, привычка не вредная, буду двигаться в этом направлении. То есть писать. Короткими предложениями.
Не очень сложно научиться коротко формулировать мысли и научиться не запихивать больше одной идеи в один пост, а вот раскрывать что-то про себя в формате даже небольшого канала – сложно. Без этого не получается искренний обмен опытом. Есть о чем подумать, а для начала прикрепила к этому посту фото из недавнего отпуска. Это там у меня было время почитать книги 🌱
За ближайшие пару месяцев больше всего просмотров набрали
📍Аналитик с опытом может быть новичком!
📍Мифы о применении опросов при выявлении требований
📍Нужно ли команде тратить время на ревью требований? (peer-to-peer review)
📍Что здесь есть о выявлении требований?
📍Быстрее, лучше, дешевле. Девять методов реинжиниринга бизнес-процессов
#мысливслух #навигация
👍9❤4👏2🔥1🤡1
Гантт, Адамецкий и PlantUml
Поиск Яндекса по фразе "диаграмма Гантта" на первой странице выдает рекламу 4-5 инструментов, чтобы ее легко и быстро построить и столько же статей с названием "Топ-10 инструментов ...". Недавно вспомнила эту диаграмму в одной из задач и рисовала ее в PlantUml. Стало интересно насколько жизнеспособна на сегодняшний день штука, которая связана в наших головах с управлением сроками, жестким планированием и вообще бюрократией
Впервые чарт с соотношением задач к затраченному времени стали применять в 1896 году, это была гармонограмма Адамецкого. Польский ученый пришел к своей концепции изучая производительность труда в прокатном производстве и доказывая, что она невысока не из-за лени рабочих, а из-за несогласованности между операциями и простоев. Концепция называется концепцией гармонизации, так как состоит в совмещении (гармонии) графиков работы оборудования и людей. Адамецкий выделил контроль как функцию управления, определил его назначение, этапы и механизмы и предупредил, что «контроль является средством, а не целью…» (источник Концепция управления Кароля Адамецки//Менеджмент в России и за рубежом, 2011 №2)
Привычные нам горизонтальные "колбаски" были сформированы Генри Ганттом чуть позже, в 1910. Можно найти немало статей, где сравниваются техники Адамецкого и Гантта, например вот эта Первый человек менеджмента:история Кароля Адамецкого, здесь же приведен внешний вид гармонограммы и прибора для ее составления
Первая картинка к этому посту из статьи Гантта Organizing for work, 1919 и показывает стоимость бездействия оборудования на предприятии, результат неэффективного управления. Интересно, что диаграмма применялась в этой работе, чтобы визуально показать потери и их причины. Большая разница с теперешними попытками зафиксировать этапность и неукоснительно контролировать исполнение
Сама по себе диаграмма не может напрямую быть единственным и безотказным инструментом управления. Однажды зафиксированная картина не заставит реальность полностью ей соответствовать и не заставит сдвинуть задачу с места. Диаграмма задумывалась для визуальной иллюстрации текущего состояния дел на производстве, для планирования работ и оценки масштабов. "Диаграммы Гантта быстро устаревали, так как не учитывали нестабильность в работе оборудования, производительности труда, сбои в поставках ресурсов и пр. ...Составление диаграмм Гантта постоянно усложняется в связи с увеличением числа операций" (из статьи Marsh Ed.R. The garmonogram of Karol Adameicki, 1975 год)
У многих моих коллег диаграмма Гантта вызывает аллергию как один из атрибутов Waterfall, а еще хуже, как символ тотального контроля со стороны менеджеров. Я и сама, когда решила использовать этот инструмент, решила учесть риск, что это сработает против меня и превратится в инструмент манипуляции сроками. Тем не менее не вижу ничего плохо в том, чтобы спланировать для себя краткосрочную задачу и двигать сроки, если необходимо. При этом не нужно наделять этот инструмент магией, которой в нем на самом деле нет
На второй картинке – результат моих экспериментов в PlantUml. Стало скучно просто рисовать прямоугольники или проставлять цифры в MS Project, решила попробовать такой подход. Если делать в инструменте, где вы в соседнем окошке видите результат изменения кода, например в VS Code с плагином PlantUml, то получается очень удобно. Выводишь календарь с нужным шагом (год, квартал, неделя, день), проставляешь длительность и даты, исправляешь, если попал на выходной. В моем случае все просто, так как это задача одного исполнителя с малым количеством этапов, если зависимостей и ресурсов много, то будет сложнее
📌Статья об иллюзии контроля (EN)
📌Статья про диаграмму, могут быть полезны ссылки на онлайн инструменты для построения
📌Давняя, но зато короткая и простая инструкция для VS Code, если еще не пользуетесь
📌Спецификация PlantUml для диаграммы Гантта, там в первой строчке написано про инструмент управления проектами, но нас же этим уже не обманешь?
📌Файлик с моим примером PlantUml на Яндекс.Диске
#что_почитать #инструменты #кейс
Поиск Яндекса по фразе "диаграмма Гантта" на первой странице выдает рекламу 4-5 инструментов, чтобы ее легко и быстро построить и столько же статей с названием "Топ-10 инструментов ...". Недавно вспомнила эту диаграмму в одной из задач и рисовала ее в PlantUml. Стало интересно насколько жизнеспособна на сегодняшний день штука, которая связана в наших головах с управлением сроками, жестким планированием и вообще бюрократией
Впервые чарт с соотношением задач к затраченному времени стали применять в 1896 году, это была гармонограмма Адамецкого. Польский ученый пришел к своей концепции изучая производительность труда в прокатном производстве и доказывая, что она невысока не из-за лени рабочих, а из-за несогласованности между операциями и простоев. Концепция называется концепцией гармонизации, так как состоит в совмещении (гармонии) графиков работы оборудования и людей. Адамецкий выделил контроль как функцию управления, определил его назначение, этапы и механизмы и предупредил, что «контроль является средством, а не целью…» (источник Концепция управления Кароля Адамецки//Менеджмент в России и за рубежом, 2011 №2)
Привычные нам горизонтальные "колбаски" были сформированы Генри Ганттом чуть позже, в 1910. Можно найти немало статей, где сравниваются техники Адамецкого и Гантта, например вот эта Первый человек менеджмента:история Кароля Адамецкого, здесь же приведен внешний вид гармонограммы и прибора для ее составления
Первая картинка к этому посту из статьи Гантта Organizing for work, 1919 и показывает стоимость бездействия оборудования на предприятии, результат неэффективного управления. Интересно, что диаграмма применялась в этой работе, чтобы визуально показать потери и их причины. Большая разница с теперешними попытками зафиксировать этапность и неукоснительно контролировать исполнение
Сама по себе диаграмма не может напрямую быть единственным и безотказным инструментом управления. Однажды зафиксированная картина не заставит реальность полностью ей соответствовать и не заставит сдвинуть задачу с места. Диаграмма задумывалась для визуальной иллюстрации текущего состояния дел на производстве, для планирования работ и оценки масштабов. "Диаграммы Гантта быстро устаревали, так как не учитывали нестабильность в работе оборудования, производительности труда, сбои в поставках ресурсов и пр. ...Составление диаграмм Гантта постоянно усложняется в связи с увеличением числа операций" (из статьи Marsh Ed.R. The garmonogram of Karol Adameicki, 1975 год)
У многих моих коллег диаграмма Гантта вызывает аллергию как один из атрибутов Waterfall, а еще хуже, как символ тотального контроля со стороны менеджеров. Я и сама, когда решила использовать этот инструмент, решила учесть риск, что это сработает против меня и превратится в инструмент манипуляции сроками. Тем не менее не вижу ничего плохо в том, чтобы спланировать для себя краткосрочную задачу и двигать сроки, если необходимо. При этом не нужно наделять этот инструмент магией, которой в нем на самом деле нет
На второй картинке – результат моих экспериментов в PlantUml. Стало скучно просто рисовать прямоугольники или проставлять цифры в MS Project, решила попробовать такой подход. Если делать в инструменте, где вы в соседнем окошке видите результат изменения кода, например в VS Code с плагином PlantUml, то получается очень удобно. Выводишь календарь с нужным шагом (год, квартал, неделя, день), проставляешь длительность и даты, исправляешь, если попал на выходной. В моем случае все просто, так как это задача одного исполнителя с малым количеством этапов, если зависимостей и ресурсов много, то будет сложнее
📌Статья об иллюзии контроля (EN)
📌Статья про диаграмму, могут быть полезны ссылки на онлайн инструменты для построения
📌Давняя, но зато короткая и простая инструкция для VS Code, если еще не пользуетесь
📌Спецификация PlantUml для диаграммы Гантта, там в первой строчке написано про инструмент управления проектами, но нас же этим уже не обманешь?
📌Файлик с моим примером PlantUml на Яндекс.Диске
#что_почитать #инструменты #кейс
👍3🔥2
GigaConf
Вчера прошла GigaConf и я могу похвастаться бейджиком участника. Это был формат летней конференции, где можно было выбирать - посидеть в зале или посмотреть трансляцию на открытой площадке, сидя в шезлонге или "груше". На лендинге конференции уже опубликованы несколько фото
Было несколько направлений : ML/AI, DevOps, Системный анализ, Инструменты разработчика, Инженерия данных, Безопасность приложений. Я больше всего времени провела в треке системного анализа. Поделюсь тем, что для себя отметила
🔅Доклад "Искусственный интеллект на службе у системного аналитика". Речь шла об использовании ИИ системными аналитиками на примере GigaChat. Я из тех, кто очень редко пользуется ИИ-помощниками, поэтому с искренним любопытством наблюдала примеры составления User Story, критериев приемки, Use Case, диаграмм в PlantUml, JSON-схем и описания API.
Когда дошло до обсуждения вопросов, понравилась мысль, что человек не может быть одинаково продуктивным весь день, а машина всегда готова одинаково бодро составлять разные типовые штуки, которые можно подкорректировать под свою задачу и получить адекватный результат.
Автор уже поделилась списком промптов GigaChat в своем канале
🔅Доклад "Как находить неэффективности в процессах при помощи цифровых следов". Это был рассказ о технологии Process Mining, о возможностях таких систем, о построении графа процесса и построении майнеров – представлении обобщенной модели процесса, основанное на логических алгоритмах. Такие модели бывают разных видов: могут учитывать только однонаправленные связи между операциями, могут не учитывать зацикленности и пр.
В докладе меня заинтересовал пример, в котором аналитик отрисовал процесс обработки счетов из трех возможных путей, через наблюдения и опросы заметили 16 путей, а по цифровым следам их обнаружилось 400. Для рутинных операционных процессов это действительно интересное открытие. В коридорах потом обсудили с коллегами, как может выглядеть работа аналитика по цифровому следу и позволит ли это делать какие-то выводы о результате?
Пока ждем записей с конференции можно посмотреть доклад того же спикера с Flow прошлого года
#конференции
Вчера прошла GigaConf и я могу похвастаться бейджиком участника. Это был формат летней конференции, где можно было выбирать - посидеть в зале или посмотреть трансляцию на открытой площадке, сидя в шезлонге или "груше". На лендинге конференции уже опубликованы несколько фото
Было несколько направлений : ML/AI, DevOps, Системный анализ, Инструменты разработчика, Инженерия данных, Безопасность приложений. Я больше всего времени провела в треке системного анализа. Поделюсь тем, что для себя отметила
🔅Доклад "Искусственный интеллект на службе у системного аналитика". Речь шла об использовании ИИ системными аналитиками на примере GigaChat. Я из тех, кто очень редко пользуется ИИ-помощниками, поэтому с искренним любопытством наблюдала примеры составления User Story, критериев приемки, Use Case, диаграмм в PlantUml, JSON-схем и описания API.
Когда дошло до обсуждения вопросов, понравилась мысль, что человек не может быть одинаково продуктивным весь день, а машина всегда готова одинаково бодро составлять разные типовые штуки, которые можно подкорректировать под свою задачу и получить адекватный результат.
Автор уже поделилась списком промптов GigaChat в своем канале
🔅Доклад "Как находить неэффективности в процессах при помощи цифровых следов". Это был рассказ о технологии Process Mining, о возможностях таких систем, о построении графа процесса и построении майнеров – представлении обобщенной модели процесса, основанное на логических алгоритмах. Такие модели бывают разных видов: могут учитывать только однонаправленные связи между операциями, могут не учитывать зацикленности и пр.
В докладе меня заинтересовал пример, в котором аналитик отрисовал процесс обработки счетов из трех возможных путей, через наблюдения и опросы заметили 16 путей, а по цифровым следам их обнаружилось 400. Для рутинных операционных процессов это действительно интересное открытие. В коридорах потом обсудили с коллегами, как может выглядеть работа аналитика по цифровому следу и позволит ли это делать какие-то выводы о результате?
Пока ждем записей с конференции можно посмотреть доклад того же спикера с Flow прошлого года
#конференции
👍6🔥2
Подборка докладов с конференций 2024
Время от времени я пишу о конференциях, где побывала, и еще ни разу не вернулась со ссылками на записи докладов. Вот несколько конференций, о которых написала в этом году и где доступны записи докладов. Можно сверить свои впечатления с моими 🌱
🔅Системная практика управления бизнес-процессами. Прошла в январе и тут есть обзор. Записи докладов доступны на лендинге мероприятия
🔅 Flow 2024 Spring, о которой речь шла в марте. Доклады начали появляться в плей-листе на Youtube канале конференции. Есть и те, которые я выделила
▫️«Бизнес-анализ: Ремесло или искусство»
▫️«Сожгите ваши системные требования. Пользовательские требования — ключ к успешному продукту»
🔅GigaConf'24. Записи докладов доступны на лендинге мероприятия, нужно выбрать трансляцию стрима "Системный анализ" и ориентироваться по таймкодам. Доступны и те, что были в недавнем посте тут
▫️Искусственный интеллект на службе у системного аналитика (таймкод в трансляции 02:04:00)
▫️Как находить неэффективности в процессах при помощи цифровых следов (таймкод в трансляции 04:02:20)
P.S. Картинку придумала нейросеть Кандинский по запросу "подборка докладов с конференций в стиле мультфильма"
#что_почитать #конференции
Время от времени я пишу о конференциях, где побывала, и еще ни разу не вернулась со ссылками на записи докладов. Вот несколько конференций, о которых написала в этом году и где доступны записи докладов. Можно сверить свои впечатления с моими 🌱
🔅Системная практика управления бизнес-процессами. Прошла в январе и тут есть обзор. Записи докладов доступны на лендинге мероприятия
🔅 Flow 2024 Spring, о которой речь шла в марте. Доклады начали появляться в плей-листе на Youtube канале конференции. Есть и те, которые я выделила
▫️«Бизнес-анализ: Ремесло или искусство»
▫️«Сожгите ваши системные требования. Пользовательские требования — ключ к успешному продукту»
🔅GigaConf'24. Записи докладов доступны на лендинге мероприятия, нужно выбрать трансляцию стрима "Системный анализ" и ориентироваться по таймкодам. Доступны и те, что были в недавнем посте тут
▫️Искусственный интеллект на службе у системного аналитика (таймкод в трансляции 02:04:00)
▫️Как находить неэффективности в процессах при помощи цифровых следов (таймкод в трансляции 04:02:20)
P.S. Картинку придумала нейросеть Кандинский по запросу "подборка докладов с конференций в стиле мультфильма"
#что_почитать #конференции
🔥3👍1
Вкрученный гвоздь или вбитый шуруп?
Меня расстраивает, когда аналитики комментируют какие-то инструменты или термины, исходя из давности появления в индустрии или отдельного опыта в одной единственной сфере. Если аналитик подходит к решению задачи с какими-то стереотипными установками, он лишает себя и команду возможности ярких, качественных решений. Получается, что частное побеждает целое.
🔅Встретила на днях мнение "бизнес-требование – это старо и не модно". При таком подходе получается, что выбор инструмента или классификации требований зависит не от решаемой проблемы, а от предвзятой установки. Скажем, теорема Пифагора сформулирована более двух тысяч лет назад. Станет ли сумма квадратов катетов равняться чему-то новому, если мы назовем теорему старой или наоборот начнем цитировать на древнегреческом?
Не уверена шла ли речь о документе или о об уровне требований. Просто интересно наблюдать как зацикленность в отношении инструментов и терминов может повлиять на качество решения. Выбор подхода к документированию не должен диктоваться какой-то условной модой.
Есть сферы деятельности, где важен документ БТ. Например, при построении процессов в крупном промышленном производстве, где цена ошибки высока, где требуется тщательное проектирование процессов и их детальная валидация. Если же речь о бизнес-требовании как уровне информации, то его можно объявить немодным или иначе назвать, но он от этого существовать не перестанет.
🔅Встречаю мнения и в другую сторону. В чате одной уважаемой конференции недавно наблюдала дискуссию: "Детальное ТЗ гораздо лучше пользовательских историй". Тут уместен вопрос: "Для чего лучше?" Речь идет о разных инструментах, которые применяются для разных задач. Попытки подменить одно другим порождает примеры вида "Вкрученный гвоздь держался хуже, чем вбитый шуруп".
ТЗ может быть необходимо, если задача требует предварительного детального проектирования, а в основе лежат правила, которые редко меняются. Сложно представить себе историю: "Я, как пассажир самолета, хочу, чтобы он летел" 🤷♀️
Пользовательская история пригодится, если нужно верхнеуровнево зафиксировать ожидания от бизнес-приложения. В моем опыте была когда-то такая задача. Требовалась информация для предварительной оценки затрат на разработку нового приложения. Решение о разработке нужно было принять за 2-3 дня. В итоге за две большие встречи с заказчиками собрали карту историй. По этой карте была дана предварительная оценка. Для разработки приложения такой подход не годится, а для первых оценок этого оказалось вполне достаточно. Причем я не возьмусь утверждать, что это был единственно возможный вариант решения такой задачи.
Я это к тому, что аналитику важно уметь поставить под сомнение расхожие мнения и собственные предубеждения, а руководствоваться в первую очередь особенностями конкретной задачи. Чем больше разных инструментов вы научитесь использовать в разном контексте, тем больше разных задач сможете быстро решать. Иначе работа может превратиться в попытки подладить задачу под инструмент.
В дополнение делюсь списком книг, которые помогут развить критическое мышление. Некоторые принесла с тренинга по решению проблем (problem solving) и сама еще не читала☺️
📍"Шум. Несовершенство человеческих суждений", Даниэль Канеман, Оливье Сибони, Касс Р. Санстейн, 2021
📍"Метод McKinsey. Использование техник ведущих стратегических консультантов для решения личных и деловых задач", Итан Расиел, 2012 (есть обзор)
📍"Думай медленно...Решай быстро", Даниэль Канеман, 2011
📍"Решение проблем по методикам спецслужб. 14 мощных инструментов", Джонс Морган, 1998
📍"Искусство системного мышления. Необходимые знания о системах и творческом подходе к решению проблем", Джозеф О'Коннор, Иан Макдермотт, 1997
#мысливслух
Меня расстраивает, когда аналитики комментируют какие-то инструменты или термины, исходя из давности появления в индустрии или отдельного опыта в одной единственной сфере. Если аналитик подходит к решению задачи с какими-то стереотипными установками, он лишает себя и команду возможности ярких, качественных решений. Получается, что частное побеждает целое.
🔅Встретила на днях мнение "бизнес-требование – это старо и не модно". При таком подходе получается, что выбор инструмента или классификации требований зависит не от решаемой проблемы, а от предвзятой установки. Скажем, теорема Пифагора сформулирована более двух тысяч лет назад. Станет ли сумма квадратов катетов равняться чему-то новому, если мы назовем теорему старой или наоборот начнем цитировать на древнегреческом?
Не уверена шла ли речь о документе или о об уровне требований. Просто интересно наблюдать как зацикленность в отношении инструментов и терминов может повлиять на качество решения. Выбор подхода к документированию не должен диктоваться какой-то условной модой.
Есть сферы деятельности, где важен документ БТ. Например, при построении процессов в крупном промышленном производстве, где цена ошибки высока, где требуется тщательное проектирование процессов и их детальная валидация. Если же речь о бизнес-требовании как уровне информации, то его можно объявить немодным или иначе назвать, но он от этого существовать не перестанет.
🔅Встречаю мнения и в другую сторону. В чате одной уважаемой конференции недавно наблюдала дискуссию: "Детальное ТЗ гораздо лучше пользовательских историй". Тут уместен вопрос: "Для чего лучше?" Речь идет о разных инструментах, которые применяются для разных задач. Попытки подменить одно другим порождает примеры вида "Вкрученный гвоздь держался хуже, чем вбитый шуруп".
ТЗ может быть необходимо, если задача требует предварительного детального проектирования, а в основе лежат правила, которые редко меняются. Сложно представить себе историю: "Я, как пассажир самолета, хочу, чтобы он летел" 🤷♀️
Пользовательская история пригодится, если нужно верхнеуровнево зафиксировать ожидания от бизнес-приложения. В моем опыте была когда-то такая задача. Требовалась информация для предварительной оценки затрат на разработку нового приложения. Решение о разработке нужно было принять за 2-3 дня. В итоге за две большие встречи с заказчиками собрали карту историй. По этой карте была дана предварительная оценка. Для разработки приложения такой подход не годится, а для первых оценок этого оказалось вполне достаточно. Причем я не возьмусь утверждать, что это был единственно возможный вариант решения такой задачи.
Я это к тому, что аналитику важно уметь поставить под сомнение расхожие мнения и собственные предубеждения, а руководствоваться в первую очередь особенностями конкретной задачи. Чем больше разных инструментов вы научитесь использовать в разном контексте, тем больше разных задач сможете быстро решать. Иначе работа может превратиться в попытки подладить задачу под инструмент.
В дополнение делюсь списком книг, которые помогут развить критическое мышление. Некоторые принесла с тренинга по решению проблем (problem solving) и сама еще не читала
📍"Шум. Несовершенство человеческих суждений", Даниэль Канеман, Оливье Сибони, Касс Р. Санстейн, 2021
📍"Метод McKinsey. Использование техник ведущих стратегических консультантов для решения личных и деловых задач", Итан Расиел, 2012 (есть обзор)
📍"Думай медленно...Решай быстро", Даниэль Канеман, 2011
📍"Решение проблем по методикам спецслужб. 14 мощных инструментов", Джонс Морган, 1998
📍"Искусство системного мышления. Необходимые знания о системах и творческом подходе к решению проблем", Джозеф О'Коннор, Иан Макдермотт, 1997
#мысливслух
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4🔥2👏2❤1
Аналитик VS продакт, QA, дизайнер
Подборка состоит из нескольких высказываний о взаимодействии аналитиков с представителями других ролей
Команды с удовольствием эксплуатируют навыки аналитиков, чтобы подменить владельца продукта, архитектора, дизайнера, тестировщика и временами разработчика. Аналитики со временем обрастают навыками и привыкают использовать без спроса у тех, кто считает эти навыки своими. Это часто приводит к спорам о разграничении полномочий и адекватности ситуации, где аналитик заменяет кучу экспертов.
Часто захожу на территорию UX-исследователей, потому что получила навыки проведения пользовательских исследований. На территорию владельца продукта, потому что имею релевантный опыт. Мне приходится заходить еще на территории дизайнера, скрам-мастера и СА. Это возможно до тех пор пока туда пускают. Готова передать задачи смежных областей, тем, для кого они основные. А как у вас складываются отношения с другими ролями?
🎥ПРОДАКТ VS АНАЛИТИК: Зачем нужен аналитик? | Согласен / Не согласен
Чуть меньше 20 мин продакт и аналитик обсуждают взаимодействие своих ролей и стереотипы, которые с этим связаны: про зоны ответственности, кто виноват при провальном запуске и нужен ли аналитик. Мне понравились честные высказывания, которые вполне бьются и с моим опытом.
🗞Взгляд на бизнес-аналитиков со стороны QA
Давняя статья в формате интервью. Lead QA Engineer отвечает на довольно разрозненные вопросы о своей работе и в том числе на вопрос "Что при взаимодействии с бизнес-аналитиками тебя раздражает больше всего?"
🗞Аналитик VS разработчик: как делить задачи без конфликтов
Опыт системного аналитика, который зашел на территорию разработчика. Может быть полезно как одна из точек зрения
🎥Аналитики и тестировщики: что тестирование ожидает от аналитика
Блиц-доклад (20 мин) на Analyst Days #12. Спикер рассказывает о своем опыте временного перехода в роль аналитика и какие выводы из этого сделаны. Как это часто бывает, интересно послушать вопросы из зала
🎥Не убейте друг друга до конца спринта!
Секционный доклад на Analyst Days #16 (40 мин) о взаимодействии системного аналитика и UX дизайнера в одной из задач. Спикеров двое – аналитик и дизайнер. Понравилось описание взаимодействия от каждой из сторон. Аналитик по привычке проектирует полный интерфейс и ожидает от дизайнера, что тот просто "нарисует красиво". Дизайнер видит важную часть своей работы в сборе требований пользователей и проектировании пользовательского пути. Спикеры рассказали о своем опыте совместной работы
#что_почитать #карьера
Подборка состоит из нескольких высказываний о взаимодействии аналитиков с представителями других ролей
Команды с удовольствием эксплуатируют навыки аналитиков, чтобы подменить владельца продукта, архитектора, дизайнера, тестировщика и временами разработчика. Аналитики со временем обрастают навыками и привыкают использовать без спроса у тех, кто считает эти навыки своими. Это часто приводит к спорам о разграничении полномочий и адекватности ситуации, где аналитик заменяет кучу экспертов.
Часто захожу на территорию UX-исследователей, потому что получила навыки проведения пользовательских исследований. На территорию владельца продукта, потому что имею релевантный опыт. Мне приходится заходить еще на территории дизайнера, скрам-мастера и СА. Это возможно до тех пор пока туда пускают. Готова передать задачи смежных областей, тем, для кого они основные. А как у вас складываются отношения с другими ролями?
🎥ПРОДАКТ VS АНАЛИТИК: Зачем нужен аналитик? | Согласен / Не согласен
Чуть меньше 20 мин продакт и аналитик обсуждают взаимодействие своих ролей и стереотипы, которые с этим связаны: про зоны ответственности, кто виноват при провальном запуске и нужен ли аналитик. Мне понравились честные высказывания, которые вполне бьются и с моим опытом.
🗞Взгляд на бизнес-аналитиков со стороны QA
Давняя статья в формате интервью. Lead QA Engineer отвечает на довольно разрозненные вопросы о своей работе и в том числе на вопрос "Что при взаимодействии с бизнес-аналитиками тебя раздражает больше всего?"
🗞Аналитик VS разработчик: как делить задачи без конфликтов
Опыт системного аналитика, который зашел на территорию разработчика. Может быть полезно как одна из точек зрения
🎥Аналитики и тестировщики: что тестирование ожидает от аналитика
Блиц-доклад (20 мин) на Analyst Days #12. Спикер рассказывает о своем опыте временного перехода в роль аналитика и какие выводы из этого сделаны. Как это часто бывает, интересно послушать вопросы из зала
🎥Не убейте друг друга до конца спринта!
Секционный доклад на Analyst Days #16 (40 мин) о взаимодействии системного аналитика и UX дизайнера в одной из задач. Спикеров двое – аналитик и дизайнер. Понравилось описание взаимодействия от каждой из сторон. Аналитик по привычке проектирует полный интерфейс и ожидает от дизайнера, что тот просто "нарисует красиво". Дизайнер видит важную часть своей работы в сборе требований пользователей и проектировании пользовательского пути. Спикеры рассказали о своем опыте совместной работы
#что_почитать #карьера
👍5🔥2
Моделирование интерфейсов пользователя, инструменты
В этом посте расскажу об инструментах, которые использую для работы над прототипами. Описала свой сегодняшний опыт, но не список инструментов для рисования, таких много. Для несложных каркасных зарисовок подойдут доски для совместной работы и инструменты для презентаций. В завершении добавила ссылки на материалы, где авторы проанализировали приложения, там больше названий
📍Бумага Нет, это не название редактора. Иногда проще нарисовать маркером на листе, если вы проводите встречу в переговорке и несложная картинка нужна для обсуждения
📍Excel Встречала умельцев рисовать диаграммы через функционал фигур Excel и умельцев делать интерактивные фомы ввода, чтобы показать порядок полей и правила валидации. "По сути это среда, которая позволяет не только хранить данные, выполнять расчеты и строить пользовательский интерфейс, это также среда, которая позволяет программировать", цитата из книги И. Корнипаева "Требования для программного обеспечения: рекомендации по сбору и документированию". Я не делала прототипов на VBA, а просто показывала фомы ввода, задавая лейблы, границы ячеек и правила для данных в ячейках.
📍Draw.io В этой рисовалке из геометрических фигур можно собрать вайрфрейм. Использую время от времени этот инструмент, потому что всегда под рукой. С тем же результатом можно использовать Miro, Lucidchart, Balsamiq, Escalidraw, Arti или MS Visio
После знакомства с графическими редакторами использую их для задач по визуализации, потому что возможности покрывают все, что может понадобиться. Не посоветую аналитику делать сложный прототип в графическом редакторе, если результат нужен быстро, а у него ни редактора под рукой, ни навыков работы в нем. Об этом подробнее было тут
📍Figma Известный графический редактор, в котором можно построить что угодно. Если в вашем приложении принята открытая или собственная дизайн-система, то аналитик может искать идеи в готовых примерах или собирать мок-апы из готовых компонент. Вот, например, в Figma Community Material Design Kit, Figma UI kit
📍Pixso Почти полный клон Figma. Есть бесплатная версия, платные тарифы дешевле Figma. Из всеми замеченных минусов – проблемы с быстродействием. Использую для тех же целей и тем же образом, что и Figma
Еще об инструментах проектирования интерфейсов
🔅Выбираем инструмент проектирования интерфейсов для аналитика В статье сравнивается несколько популярных инструментов для создания вайрфреймов
🔅Игра «Что, где, когда» с вайрфреймами, мокапами и прототипами Доклад на Analyst Days-11 о том, с какими прототипами работают аналитики на проектах мобильной разработки
🔅Что делать если отключат Figma? Есть ли альтернативы? Статья, где автор сравнил несколько графических редакторов
#инструменты #что_почитать
В этом посте расскажу об инструментах, которые использую для работы над прототипами. Описала свой сегодняшний опыт, но не список инструментов для рисования, таких много. Для несложных каркасных зарисовок подойдут доски для совместной работы и инструменты для презентаций. В завершении добавила ссылки на материалы, где авторы проанализировали приложения, там больше названий
📍Бумага Нет, это не название редактора. Иногда проще нарисовать маркером на листе, если вы проводите встречу в переговорке и несложная картинка нужна для обсуждения
📍Excel Встречала умельцев рисовать диаграммы через функционал фигур Excel и умельцев делать интерактивные фомы ввода, чтобы показать порядок полей и правила валидации. "По сути это среда, которая позволяет не только хранить данные, выполнять расчеты и строить пользовательский интерфейс, это также среда, которая позволяет программировать", цитата из книги И. Корнипаева "Требования для программного обеспечения: рекомендации по сбору и документированию". Я не делала прототипов на VBA, а просто показывала фомы ввода, задавая лейблы, границы ячеек и правила для данных в ячейках.
📍Draw.io В этой рисовалке из геометрических фигур можно собрать вайрфрейм. Использую время от времени этот инструмент, потому что всегда под рукой. С тем же результатом можно использовать Miro, Lucidchart, Balsamiq, Escalidraw, Arti или MS Visio
После знакомства с графическими редакторами использую их для задач по визуализации, потому что возможности покрывают все, что может понадобиться. Не посоветую аналитику делать сложный прототип в графическом редакторе, если результат нужен быстро, а у него ни редактора под рукой, ни навыков работы в нем. Об этом подробнее было тут
📍Figma Известный графический редактор, в котором можно построить что угодно. Если в вашем приложении принята открытая или собственная дизайн-система, то аналитик может искать идеи в готовых примерах или собирать мок-апы из готовых компонент. Вот, например, в Figma Community Material Design Kit, Figma UI kit
📍Pixso Почти полный клон Figma. Есть бесплатная версия, платные тарифы дешевле Figma. Из всеми замеченных минусов – проблемы с быстродействием. Использую для тех же целей и тем же образом, что и Figma
Еще об инструментах проектирования интерфейсов
🔅Выбираем инструмент проектирования интерфейсов для аналитика В статье сравнивается несколько популярных инструментов для создания вайрфреймов
🔅Игра «Что, где, когда» с вайрфреймами, мокапами и прототипами Доклад на Analyst Days-11 о том, с какими прототипами работают аналитики на проектах мобильной разработки
🔅Что делать если отключат Figma? Есть ли альтернативы? Статья, где автор сравнил несколько графических редакторов
#инструменты #что_почитать
🔥5👍2
История про детство и компьютер
Есть два вычислительных устройства, которые в детстве мне казались магическими. О калькуляторах я уже писала. А еще было устройство с теплым именем "Микроша". Я долго думала, что имя сочинили мои родители, но оказалось, что такое название дали на Лианозовском электромеханическом заводе.
Микроша жил в шкафу и извлекался только по выходным. Он был, видимо, очень болезненным и очень важным, потому что без присмотра взрослых было запрещено подходить к нему на расстояние вытянутой руки. Иногда разрешалось нажать пару кнопок и посмотреть как по экрану прыгает схематический человечек из палочек и ловит нули по команде "вверх" или "вниз". Человечек был зеленый, а как игра называлась, не помню. Может быть, отец ее сам написал, а меня использовал как тестировщика.
Микроша был персональным компьютером. Он подключался к нашему пузатому телевизору и загружался с кассетного магнитофона. Было жутковато, когда магнитофон объявлял что-то вроде «Вдоль по Питерской» и начинал издавать совершенно инопланетные звуки. Это в 16 или 32 Кб оперативной памяти со скоростью 700 бит/c загружалась игра. Еще у Микроши была клавиатура из 68 кнопок, с нее было можно отдавать отдельные команды вроде «вверх»/ «вниз» и вводить шестнадцатеричные значения.
Было ощущение странной и недоброй магии, когда телевизор, где должны быть мультики, начинал показывать ряды букв и цифр. Я тогда очень переживала, что телевизор сломан и подлый Микроша больше никогда не вернет нормальное изображение. Человечки и нолики меня тогда не слишком увлекали и радовали. Взаимодействие с компьютером выглядело шаманством с какими-то неясными целями. Я бы очень удивилась, если бы кто-то тогда сказал, что через 20 лет это станет одним из основных моих занятий☺️
📚
Оказывается и сейчас любители исторических артефактов занимаются ПК 80х-90х
▫️Статья Знакомство с "Микрошей", где можно оценить тогдашние пользовательские и программные интерфейсы
▫️Статья ПК второй половины 1980-х годов источник картинки к этому посту
#истории
Есть два вычислительных устройства, которые в детстве мне казались магическими. О калькуляторах я уже писала. А еще было устройство с теплым именем "Микроша". Я долго думала, что имя сочинили мои родители, но оказалось, что такое название дали на Лианозовском электромеханическом заводе.
Микроша жил в шкафу и извлекался только по выходным. Он был, видимо, очень болезненным и очень важным, потому что без присмотра взрослых было запрещено подходить к нему на расстояние вытянутой руки. Иногда разрешалось нажать пару кнопок и посмотреть как по экрану прыгает схематический человечек из палочек и ловит нули по команде "вверх" или "вниз". Человечек был зеленый, а как игра называлась, не помню. Может быть, отец ее сам написал, а меня использовал как тестировщика.
Микроша был персональным компьютером. Он подключался к нашему пузатому телевизору и загружался с кассетного магнитофона. Было жутковато, когда магнитофон объявлял что-то вроде «Вдоль по Питерской» и начинал издавать совершенно инопланетные звуки. Это в 16 или 32 Кб оперативной памяти со скоростью 700 бит/c загружалась игра. Еще у Микроши была клавиатура из 68 кнопок, с нее было можно отдавать отдельные команды вроде «вверх»/ «вниз» и вводить шестнадцатеричные значения.
Было ощущение странной и недоброй магии, когда телевизор, где должны быть мультики, начинал показывать ряды букв и цифр. Я тогда очень переживала, что телевизор сломан и подлый Микроша больше никогда не вернет нормальное изображение. Человечки и нолики меня тогда не слишком увлекали и радовали. Взаимодействие с компьютером выглядело шаманством с какими-то неясными целями. Я бы очень удивилась, если бы кто-то тогда сказал, что через 20 лет это станет одним из основных моих занятий
📚
Оказывается и сейчас любители исторических артефактов занимаются ПК 80х-90х
▫️Статья Знакомство с "Микрошей", где можно оценить тогдашние пользовательские и программные интерфейсы
▫️Статья ПК второй половины 1980-х годов источник картинки к этому посту
#истории
Please open Telegram to view this post
VIEW IN TELEGRAM
😁4❤3👍1
Подборка про варианты использования
Вариант использования (Use Case) многие выбирают как инструмент описания функциональных требований. Аналитики его встроили в гибкие методологии, несмотря на появление пользовательских историй (User Story). Сложно отказаться от понятных пошаговых описаний, правда? Учитывая почтенный возраст и популярность этой техники, материалов много. В этой подборке несколько разных рекомендаций и точек зрения
📍Use Cases. Что это такое и зачем они нужны? В этой статье есть не только базовое описание, но и рассуждения о пользе вариантов использования для разных ролей: тестировщика, продакта, проджекта
📍Как сделать удобный продукт: на примерах разбираем критерии хорошего Use case в статье точка зрения дизайнеров и продактов на вариант использования и критерии его качества
🎥Use Cases / Варианты Использования. Разбор вопросов и примеров диаграмм и описания (YouTube) подкаст Александра Байкина с участием Михаила Максимова, Александра Белина и Вадима Кривенцова. Два часа интересного разговора, где затронуты очень разные вопросы от "что такое Use Case?" до "как из этого сделать Test Case?"
📍Use Cases and Scenarios - A Comprehensive Guide (ENG) в статье приведено базовое описание варианта использования как техники, перечисление атрибутов варианта использования и пример табличного оформления. Интересно посмотреть пример с точки зрения "как люди делают"
🎥Use case или User story? Хватит выбирать - даешь все и сразу (Дзен) Доклад Михаила Максимова на Analyst Days-13. Сорок минут рассказа о вариантах использования для описания функциональных требований. Доклад для тех, кто уже хорошо знаком с техникой Use Case
#инструменты #что_почитать
Вариант использования (Use Case) многие выбирают как инструмент описания функциональных требований. Аналитики его встроили в гибкие методологии, несмотря на появление пользовательских историй (User Story). Сложно отказаться от понятных пошаговых описаний, правда? Учитывая почтенный возраст и популярность этой техники, материалов много. В этой подборке несколько разных рекомендаций и точек зрения
📍Use Cases. Что это такое и зачем они нужны? В этой статье есть не только базовое описание, но и рассуждения о пользе вариантов использования для разных ролей: тестировщика, продакта, проджекта
📍Как сделать удобный продукт: на примерах разбираем критерии хорошего Use case в статье точка зрения дизайнеров и продактов на вариант использования и критерии его качества
🎥Use Cases / Варианты Использования. Разбор вопросов и примеров диаграмм и описания (YouTube) подкаст Александра Байкина с участием Михаила Максимова, Александра Белина и Вадима Кривенцова. Два часа интересного разговора, где затронуты очень разные вопросы от "что такое Use Case?" до "как из этого сделать Test Case?"
📍Use Cases and Scenarios - A Comprehensive Guide (ENG) в статье приведено базовое описание варианта использования как техники, перечисление атрибутов варианта использования и пример табличного оформления. Интересно посмотреть пример с точки зрения "как люди делают"
🎥Use case или User story? Хватит выбирать - даешь все и сразу (Дзен) Доклад Михаила Максимова на Analyst Days-13. Сорок минут рассказа о вариантах использования для описания функциональных требований. Доклад для тех, кто уже хорошо знаком с техникой Use Case
#инструменты #что_почитать
👍4🔥1
Техники оценки задач
Вам приходилось слышать, что аналитик любую задачу делает слишком долго? Часто это вопрос выравнивания ожиданий от скорости работы аналитика.
При вызове такси приложение пишет, что поездка займет 30 мин, а когда по факту получается 20, у клиента появляется ощущение удачно решенной задачи. До исполнения задачи клиенту показали маршрут и время выполнения, никто не обещал доехать за 10 мин. Аналитику тоже будет проще объяснить затраты, если показать маршрут и прогноз времени выполнения задачи.
В моем опыте вопрос "сколько нужно времени на анализ" часто даже не звучит, приходится слышать "надо побыстрее" или "мы оценили всю разработку в Х часов, неужели не хватит на анализ?". Поэтому в роли аналитика полезно оценивать задачи даже если никто об этом не просит. Это важно, чтобы управлять ожиданиями команды и не попасться на манипуляциях с оценками. Можно договориться об уменьшении объема всей задачи или отдельных задач аналитика, если оценку нельзя пересчитать. При этом вспоминается импульсивный стиль менеджмента, при котором сложно договориться, но это уже другая история🤷♀️
Выбор метода оценки зависит от имеющихся данных, готовности заинтересованных сторон к разговору, времени на оценку.
Оценка сверху-вниз Не уходя в детали, верхнеуровнево смотрим на компоненты задачи и оцениваем их на основании исторических данных, знаний о рисках и экспертного опыта. Предполагается, что можно будет уточнить оценку по мере раскапывания деталей задачи
Оценка снизу-вверх Разбираем задачу на детальные шаги, оцениваем каждый и все оценки суммируем. Для такой оценки нужно выделить время на детальную декомпозицию задачи, могут понадобиться уточнения и в этом недостаток метода, хотя он распространен и очень любим экспертами.
Экспертная оценка (Rough Order of Magnitude, ROM) На основании исторических данных в команде, внешних данных от других команд, экспертного опыта дается оценка задачи. Применяется часто, но здесь главный недостаток в субъективности такой оценки. Скорее всего будет оценен вариант решения, как его понял эксперт, с учетом производительности работы этого конкретного эксперта, для другого исполнителя это может не сработать. Хорошо работает, когда вы сами оцениваете свою же задачу и не забываете учесть возможные риски
Параметрическая оценка Метод предлагает выбрать единицу калибровки, например, вариант использования. Оценить эту единицу на основании опыта конкретной команды и использовать в оценке задач в зависимости от предполагаемого количества таких единиц в ней. Недостаток подхода в том, что калибровка и оценки одной команды аналитиков могут оказаться нерабочими для другой
Метод бегущей волны итеративная оценка работ аналитика от шага к шагу. Например, оценить предварительное уточнение требований, затем на основании уточненной информации оценить шаг по детализации требований и т.д.
PERT (Program Evaluation Review Technique) или техника трех точек Метод предлагает разделить три сценария выполнения задачи: оптимистичный (O), наиболее вероятный (R), пессимистичный (P). Оценить каждый сценарий в отдельности. Итоговую оценку подсчитать как (O+4*R+P)\6
📚
A Business Analyst's Guide to Estimation Techniques (ENG ) в этом тексте самое ценное – разбор примеров для каждой из техник, что я перечислила выше
Requirements Estimation: How to Create a Business Analyst Timeline (ENG) живой рассказ о том, какие шаги автор блога рекомендует, если к вам пришел менеджер с очередной срочной задачей и спрашивает сколько времени вам на не нужно
Как оценивать проектные задачи, чтобы не слить бюджет и не убить команду: советы QA-лида в этой статье много общих описаний, мое внимание привлекло описание методов оценки в завершающей части статьи. Описано с точки зрения проектного менеджера, но подходы применимы к любым задачам
#инструменты #что_почитать
Вам приходилось слышать, что аналитик любую задачу делает слишком долго? Часто это вопрос выравнивания ожиданий от скорости работы аналитика.
При вызове такси приложение пишет, что поездка займет 30 мин, а когда по факту получается 20, у клиента появляется ощущение удачно решенной задачи. До исполнения задачи клиенту показали маршрут и время выполнения, никто не обещал доехать за 10 мин. Аналитику тоже будет проще объяснить затраты, если показать маршрут и прогноз времени выполнения задачи.
В моем опыте вопрос "сколько нужно времени на анализ" часто даже не звучит, приходится слышать "надо побыстрее" или "мы оценили всю разработку в Х часов, неужели не хватит на анализ?". Поэтому в роли аналитика полезно оценивать задачи даже если никто об этом не просит. Это важно, чтобы управлять ожиданиями команды и не попасться на манипуляциях с оценками. Можно договориться об уменьшении объема всей задачи или отдельных задач аналитика, если оценку нельзя пересчитать. При этом вспоминается импульсивный стиль менеджмента, при котором сложно договориться, но это уже другая история🤷♀️
Выбор метода оценки зависит от имеющихся данных, готовности заинтересованных сторон к разговору, времени на оценку.
Оценка сверху-вниз Не уходя в детали, верхнеуровнево смотрим на компоненты задачи и оцениваем их на основании исторических данных, знаний о рисках и экспертного опыта. Предполагается, что можно будет уточнить оценку по мере раскапывания деталей задачи
Оценка снизу-вверх Разбираем задачу на детальные шаги, оцениваем каждый и все оценки суммируем. Для такой оценки нужно выделить время на детальную декомпозицию задачи, могут понадобиться уточнения и в этом недостаток метода, хотя он распространен и очень любим экспертами.
Экспертная оценка (Rough Order of Magnitude, ROM) На основании исторических данных в команде, внешних данных от других команд, экспертного опыта дается оценка задачи. Применяется часто, но здесь главный недостаток в субъективности такой оценки. Скорее всего будет оценен вариант решения, как его понял эксперт, с учетом производительности работы этого конкретного эксперта, для другого исполнителя это может не сработать. Хорошо работает, когда вы сами оцениваете свою же задачу и не забываете учесть возможные риски
Параметрическая оценка Метод предлагает выбрать единицу калибровки, например, вариант использования. Оценить эту единицу на основании опыта конкретной команды и использовать в оценке задач в зависимости от предполагаемого количества таких единиц в ней. Недостаток подхода в том, что калибровка и оценки одной команды аналитиков могут оказаться нерабочими для другой
Метод бегущей волны итеративная оценка работ аналитика от шага к шагу. Например, оценить предварительное уточнение требований, затем на основании уточненной информации оценить шаг по детализации требований и т.д.
PERT (Program Evaluation Review Technique) или техника трех точек Метод предлагает разделить три сценария выполнения задачи: оптимистичный (O), наиболее вероятный (R), пессимистичный (P). Оценить каждый сценарий в отдельности. Итоговую оценку подсчитать как (O+4*R+P)\6
📚
A Business Analyst's Guide to Estimation Techniques (ENG ) в этом тексте самое ценное – разбор примеров для каждой из техник, что я перечислила выше
Requirements Estimation: How to Create a Business Analyst Timeline (ENG) живой рассказ о том, какие шаги автор блога рекомендует, если к вам пришел менеджер с очередной срочной задачей и спрашивает сколько времени вам на не нужно
Как оценивать проектные задачи, чтобы не слить бюджет и не убить команду: советы QA-лида в этой статье много общих описаний, мое внимание привлекло описание методов оценки в завершающей части статьи. Описано с точки зрения проектного менеджера, но подходы применимы к любым задачам
#инструменты #что_почитать
👍4🔥3
Летние публикации на этом канале
Подсмотрела у другого автора подсчет оставшихся недель лета. Их оказалось всего две. Уверена, вы не скучали все предыдущие недели лета и оставшиеся две проведете с пользой☀️
Я немного выпадала из этого канала на работу и поездки. Впервые побывала в Нижнем и впервые в Петрозаводске. Тем не менее тут и на Дзен собралось несколько статей:
🔅Гантт, Адамецкий и PlantUml
🔅Подборка докладов с конференций 2024
🔅Аналитик VS продакт, QA, дизайнер
🔅Моделирование интерфейсов пользователя, инструменты
🔅История про детство и компьютер
По тегу #навигация можно найти подборки материалов этого канала. Я начинаю понимать преподавателей, которые советуют студентам свои собственные статьи и методички. По крайней мере я точно уверена, что там написано что-то с чем я согласна 🌱
Подсмотрела у другого автора подсчет оставшихся недель лета. Их оказалось всего две. Уверена, вы не скучали все предыдущие недели лета и оставшиеся две проведете с пользой☀️
Я немного выпадала из этого канала на работу и поездки. Впервые побывала в Нижнем и впервые в Петрозаводске. Тем не менее тут и на Дзен собралось несколько статей:
🔅Гантт, Адамецкий и PlantUml
🔅Подборка докладов с конференций 2024
🔅Аналитик VS продакт, QA, дизайнер
🔅Моделирование интерфейсов пользователя, инструменты
🔅История про детство и компьютер
По тегу #навигация можно найти подборки материалов этого канала. Я начинаю понимать преподавателей, которые советуют студентам свои собственные статьи и методички. По крайней мере я точно уверена, что там написано что-то с чем я согласна 🌱
🔥3❤2
Очереди и общение
Впервые побывала на семейном фестивале для опытных ИТ-специалистов. Так называется формат ИТ-Пикника на официальном сайте. Неплохой формат для летнего нетворкинга, но не каждому интроверту подойдет. Можно посидеть на зеленом газоне в Коломенском парке и уютно пообщаться с друзьями, семьей, коллегами, если не слишком обращать внимание на громкую музыку и толпу других участников, кто тоже общается😎 Пока ИТ-специалисты искали интересные площадки лектория, их семьи получали полезные знания от рисования Ми-ми-мишек до гвоздестояния.
Навигация по площадке фестиваля требовала опыта. Без точной карты и компаса не всегда получалось послушать именно то, что планировала. Обратила внимание в основном на доклады в секции "Эксперименты и исследования":
Пробуждение силы: как управлять экспериментами с LLM Доклад о создании внутренней корпоративной платформы с LLM инструментами для безопасного использования внутри компании. Используется аналитиками для составления документации, продактами - для расчета приоритетов фич, для транскрибирования аудио и пр. Шаги развития платформы включают 1) создание сообщества для выявления и обсуждения идей, 2) организацию разработки с возможностью делиться наработками и исправлять сделанное коллегами 3) формулирование гипотез и проведение экспериментов с учетом приоритетов для задач компании.
Перспективы квантового компьютера в обозримое время Обзор известных исследований квантовых компьютеров, составлен на основе научных публикаций. Спикер резюмировал, что технология пока еще на стадии фундаментальных исследований и они не проясняют действительных возможностей квантовых компьютеров, еще не решено ни одной полезной задачи. Остается продолжать следить за новыми находками.
Этот доклад был представлен на HighLoad++ в этом году, записи доступны только участникам, а презентацию можно скачать
Еще были секции
📌
📌
📌
📌
📌
📌
Организаторы обещают выкладывать записи докладов в течении года. Ждем.
Еще у самых опытных ИТ-специалистов был шанс вспомнить, что такое настоящая очередь, не из сообщений, а из людей. Если бы не очереди за едой и водой на фудкорте, могла бы больше рассказать о докладах 🤷♀️
#конференции
Впервые побывала на семейном фестивале для опытных ИТ-специалистов. Так называется формат ИТ-Пикника на официальном сайте. Неплохой формат для летнего нетворкинга, но не каждому интроверту подойдет. Можно посидеть на зеленом газоне в Коломенском парке и уютно пообщаться с друзьями, семьей, коллегами, если не слишком обращать внимание на громкую музыку и толпу других участников, кто тоже общается
Навигация по площадке фестиваля требовала опыта. Без точной карты и компаса не всегда получалось послушать именно то, что планировала. Обратила внимание в основном на доклады в секции "Эксперименты и исследования":
Пробуждение силы: как управлять экспериментами с LLM Доклад о создании внутренней корпоративной платформы с LLM инструментами для безопасного использования внутри компании. Используется аналитиками для составления документации, продактами - для расчета приоритетов фич, для транскрибирования аудио и пр. Шаги развития платформы включают 1) создание сообщества для выявления и обсуждения идей, 2) организацию разработки с возможностью делиться наработками и исправлять сделанное коллегами 3) формулирование гипотез и проведение экспериментов с учетом приоритетов для задач компании.
Перспективы квантового компьютера в обозримое время Обзор известных исследований квантовых компьютеров, составлен на основе научных публикаций. Спикер резюмировал, что технология пока еще на стадии фундаментальных исследований и они не проясняют действительных возможностей квантовых компьютеров, еще не решено ни одной полезной задачи. Остается продолжать следить за новыми находками.
Этот доклад был представлен на HighLoad++ в этом году, записи доступны только участникам, а презентацию можно скачать
Еще были секции
📌
Научпоп с рассказами о социальном познании, клиповом мышлении, работе памяти📌
Архитектура, надежность и качество с вопросами гарантированной доставки сообщений, SRE vs ITIL и технологического мониторинга📌
Кибер-безопасность с разговором об актуальных угрозах в эпоху искусственного интеллекта📌
Продуктовый менеджмент, где почти все доклады касались продуктов на основе ИИ📌
Управление командами, где обсуждались вопросы конфликтов и договоренностей, начинающие менеджеры и инструменты управления на основе данных📌
Управление процессами с докладами об оценке эффективности команд и динамике IT переменОрганизаторы обещают выкладывать записи докладов в течении года. Ждем.
Еще у самых опытных ИТ-специалистов был шанс вспомнить, что такое настоящая очередь, не из сообщений, а из людей. Если бы не очереди за едой и водой на фудкорте, могла бы больше рассказать о докладах 🤷♀️
#конференции
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4
Как же называется эта книга?
Рэймонд М. Смаллиан. Год издания 2021
Открыла вчера эту книгу. Оригинал относится к 1978му году, первый перевод вышел тремя годами позже, а мне попалось издание 2021 года. Это сборник логических задачек с вводными от автора и детальным разбором решений. Задачи идут от простых бытовых к более сложным логическим комбинациям. Каждый раздел в своем контексте и объединяет задачи на конкретную тему и конкретное логическое правило. Я прошла пока только часть:
📍"Головоломки и дурацкие штучки", где собраны логические заморочки на бытовом уровне. Например: Что произойдет, если всесокрушающее ядро попадет в несокрушимый столб?
📍"Рыцари и лжецы", где рыцари всегда говорят правду, а лжецы всегда врут
📍"Алиса в лесу Забывчивости", где живут львы и единороги, которые врут или говорят правду в конкретные дни недели
📍"Из записок инспектора Крэга" с задачками про расследование преступлений. Одну такую задачку напишу ниже, вы пока подумайте, а я дочитаю и завтра напишу ответ в комментариях 😉
Еще есть задачки про оборотней, зомби и других персонажей. По сложности фантазий напоминает книгу Льюиса Кэррола "Алиса в стране чудес"
Что может быть полезно?
Решать логические задачки само по себе не вредно. Есть задачки простые, а есть сложные, в которых можно закопаться надолго и с пользой для мозга провести время.
Я еще не добралась до последних глав, но с удовольствием залипла на задачках средней сложности. Узнала слово "импликация" – это зависимости вида "Если P, то Q".
Кому может быть полезно?
Думаю, что полезно всем, кому интересно потренировать логическое мышление.
#книжки
Рэймонд М. Смаллиан. Год издания 2021
Открыла вчера эту книгу. Оригинал относится к 1978му году, первый перевод вышел тремя годами позже, а мне попалось издание 2021 года. Это сборник логических задачек с вводными от автора и детальным разбором решений. Задачи идут от простых бытовых к более сложным логическим комбинациям. Каждый раздел в своем контексте и объединяет задачи на конкретную тему и конкретное логическое правило. Я прошла пока только часть:
📍"Головоломки и дурацкие штучки", где собраны логические заморочки на бытовом уровне. Например: Что произойдет, если всесокрушающее ядро попадет в несокрушимый столб?
📍"Рыцари и лжецы", где рыцари всегда говорят правду, а лжецы всегда врут
📍"Алиса в лесу Забывчивости", где живут львы и единороги, которые врут или говорят правду в конкретные дни недели
📍"Из записок инспектора Крэга" с задачками про расследование преступлений. Одну такую задачку напишу ниже, вы пока подумайте, а я дочитаю и завтра напишу ответ в комментариях 😉
Еще есть задачки про оборотней, зомби и других персонажей. По сложности фантазий напоминает книгу Льюиса Кэррола "Алиса в стране чудес"
Что может быть полезно?
Решать логические задачки само по себе не вредно. Есть задачки простые, а есть сложные, в которых можно закопаться надолго и с пользой для мозга провести время.
Я еще не добралась до последних глав, но с удовольствием залипла на задачках средней сложности. Узнала слово "импликация" – это зависимости вида "Если P, то Q".
Кому может быть полезно?
Думаю, что полезно всем, кому интересно потренировать логическое мышление.
#книжки
🔥3🤩2