Пользовательское тестирование в инженерии требований
#что_почитать #статьи
В журнале IREB (International Requirements Engineering Board) встретилась статья, которая говорит, что работать над требованиями через пользовательский опыт — это хорошая практика. Делюсь обзором статьи The Potential of User Tests for Requirements Engineering
Тесты с пользователями можно проводить на разных этапах разработки и с разными целями:
• выявления требований на этапе работы с идеей,
• валидации требований на этапе разработки,
• перепроверки соответствия рынку (product market fit) перед внедрением.
Тестирование можно организовывать как с конечными (end-user) так и с внутренними (internal) пользователями.
🔅Конечные пользователи - это потенциальные клиенты еще не знакомые с приложением. Эта категория пользователей поможет увидеть упущенные варианты использования приложения. Можно понять как и какие задачи пользователи собираются решать с помощью приложения, увидеть за какие фичи они готовы платить больше, а чем вряд ли будут пользоваться.
Тесты с конечными пользователями могут быть в виде опроса, интервью, тестирования вайрфреймов (wireframes), тестирования прототипов. Важно, что они проводятся на этапе, когда изменения требований не требуют больших затрат.
🔅Внутренние пользователи набираются из тех, кто уже вовлечен в продукт: разработчики, тестировщики, менеджеры, дизайнеры, инвесторы… Тестирование их опыта может быть источником новых требований и средством валидации требований. Но есть нюанс. Эта категория пользователей не может «развидеть» все, что они уже знают о продукте, и только предполагают, что могут мыслить как конечный пользователь, хотя это не так. Поэтому позже лучше еще раз повести тестирование с конечными пользователями.
Тесты с внутренними пользователями могут быть в виде тестирования вайрфреймов или прототипов, а еще в виде проверки, что разрабатываемое покрывает все запланированные пользовательские истории. Это помогает выстроить общее понимание внутри продуктовой команды и валидировать приложение не только на предмет потребностей пользователей, но и с точки зрения технической реализации.
🔅MVP - minimum viable product (минимальный жизнеспособный продукт). Как только первая базовая жизнеспособная версия готова, то рекомендуется провести тестирование с конечными пользователями. Так можно понять насколько приложение понятно пользователям и отвечает их требованиям. На этом этапе еще есть возможность доработать приложение для лучшего соответствия рынку.
В целом результаты пользовательского тестирования могут послужить аргументацией в пользу тех или иных требований при разногласиях внутри команды. Без привлечения внутренних и конечных пользователей требования оказываются не полными.
От себя дополню, что уже комментировала кейс, где требования выявлялись через тестирование пользователей. В кейсе это был единственно возможный прием, потому что среди пользователей были служебные собаки. А еще рассказывала и свой кейс про пользовательское тестирование🗃
#что_почитать #статьи
В журнале IREB (International Requirements Engineering Board) встретилась статья, которая говорит, что работать над требованиями через пользовательский опыт — это хорошая практика. Делюсь обзором статьи The Potential of User Tests for Requirements Engineering
Тесты с пользователями можно проводить на разных этапах разработки и с разными целями:
• выявления требований на этапе работы с идеей,
• валидации требований на этапе разработки,
• перепроверки соответствия рынку (product market fit) перед внедрением.
Тестирование можно организовывать как с конечными (end-user) так и с внутренними (internal) пользователями.
🔅Конечные пользователи - это потенциальные клиенты еще не знакомые с приложением. Эта категория пользователей поможет увидеть упущенные варианты использования приложения. Можно понять как и какие задачи пользователи собираются решать с помощью приложения, увидеть за какие фичи они готовы платить больше, а чем вряд ли будут пользоваться.
Тесты с конечными пользователями могут быть в виде опроса, интервью, тестирования вайрфреймов (wireframes), тестирования прототипов. Важно, что они проводятся на этапе, когда изменения требований не требуют больших затрат.
🔅Внутренние пользователи набираются из тех, кто уже вовлечен в продукт: разработчики, тестировщики, менеджеры, дизайнеры, инвесторы… Тестирование их опыта может быть источником новых требований и средством валидации требований. Но есть нюанс. Эта категория пользователей не может «развидеть» все, что они уже знают о продукте, и только предполагают, что могут мыслить как конечный пользователь, хотя это не так. Поэтому позже лучше еще раз повести тестирование с конечными пользователями.
Тесты с внутренними пользователями могут быть в виде тестирования вайрфреймов или прототипов, а еще в виде проверки, что разрабатываемое покрывает все запланированные пользовательские истории. Это помогает выстроить общее понимание внутри продуктовой команды и валидировать приложение не только на предмет потребностей пользователей, но и с точки зрения технической реализации.
🔅MVP - minimum viable product (минимальный жизнеспособный продукт). Как только первая базовая жизнеспособная версия готова, то рекомендуется провести тестирование с конечными пользователями. Так можно понять насколько приложение понятно пользователям и отвечает их требованиям. На этом этапе еще есть возможность доработать приложение для лучшего соответствия рынку.
В целом результаты пользовательского тестирования могут послужить аргументацией в пользу тех или иных требований при разногласиях внутри команды. Без привлечения внутренних и конечных пользователей требования оказываются не полными.
От себя дополню, что уже комментировала кейс, где требования выявлялись через тестирование пользователей. В кейсе это был единственно возможный прием, потому что среди пользователей были служебные собаки. А еще рассказывала и свой кейс про пользовательское тестирование🗃
Источник требований — это не обязательно люди
#мысливслух #инструменты
В одной их команд моя работа началась с запроса: «Зачем тебе так много времени на функциональные требования? Вон тебе наши менеджеры — проговори с ними и все». Это запомнилось, видимо, от изрядной обиды за мою роль в команде. Спрашивается зачем вам БА, если есть такие чудесные менеджеры, которые уже все знают? Неужели только, чтобы спросить и записать? 🤷♀️
Во многих командах живет представление, что источником требований могут быть только люди. Причем эти люди обязаны обладать достаточными знаниями, чтобы однозначно и непротиворечиво выдать всю информацию, важную для успеха фичи или продукта. Из этой точки зрения формируется целый набор взаимных претензий между командами разработки и представителями бизнес-пользователей. «Сами не знают, чего хотят», «все меняют в последний момент» - это со стороны разработки. «Отвлекают своими вопросами», «делают вообще не то, не понятно как объяснять» - со стороны других заинтересованных сторон 🤽♀️
На самом деле при формировании функциональных требований и выборе решения можно опираться на разные источники: документы, системы, исследования, эксперименты… На одном из занятий с менти мы составили памятку с техниками выявления требований из стандарта BABOK. Поделюсь здесь 🎁
Напишите, какие из техник вы чаще всего применяете? Какие из них вызывают вопросы?
#мысливслух #инструменты
В одной их команд моя работа началась с запроса: «Зачем тебе так много времени на функциональные требования? Вон тебе наши менеджеры — проговори с ними и все». Это запомнилось, видимо, от изрядной обиды за мою роль в команде. Спрашивается зачем вам БА, если есть такие чудесные менеджеры, которые уже все знают? Неужели только, чтобы спросить и записать? 🤷♀️
Во многих командах живет представление, что источником требований могут быть только люди. Причем эти люди обязаны обладать достаточными знаниями, чтобы однозначно и непротиворечиво выдать всю информацию, важную для успеха фичи или продукта. Из этой точки зрения формируется целый набор взаимных претензий между командами разработки и представителями бизнес-пользователей. «Сами не знают, чего хотят», «все меняют в последний момент» - это со стороны разработки. «Отвлекают своими вопросами», «делают вообще не то, не понятно как объяснять» - со стороны других заинтересованных сторон 🤽♀️
На самом деле при формировании функциональных требований и выборе решения можно опираться на разные источники: документы, системы, исследования, эксперименты… На одном из занятий с менти мы составили памятку с техниками выявления требований из стандарта BABOK. Поделюсь здесь 🎁
Напишите, какие из техник вы чаще всего применяете? Какие из них вызывают вопросы?
👍2❤1
Сколько тонн клевера от каждой курицы несушки будет засыпано в инкубаторы после обмолота зяби?
#мысливслух
Мой папа любит вспоминать ту часть своего детства, которую он провел в деревне. Это было в начале 1960х, в одном их тех мест, где обувь носили только в холода, зимой забирали поросят в дом, а всяких базовых ценностей не то что не хватало, а вообще вряд ли кто-то знал об их существовании в пирамиде Маслоу 😉
Недавно мы рассуждали как мне сложно понять чувства человека, который в холодное время года сидит в своем теплом доме и понимает, что сам успел запастись дровами и теперь может топить печь. Печь он сложил тоже сам.
Могут аналитики похвастаться таким точным пониманием результата? Особенно сложно с этим в найме. Результат часто не зависит от ваших усилий. Бывает кто-то затеял заведомо провальный проект, вы построили клиентский путь как никогда в жизни, но ни один клиент по нему так и не прошел. Если проект удачный, то как измерить именно ваш вклад в этот общий командный успех? Сколько тонн клевера от каждой курицы-несушки будет засыпано в инкубаторы именно от вашей работы?
Этот канал, помогает мне делать тот вид задач, где почти мгновенно можно видеть результат. Есть реакции под текстом, значит удалось рассказать что-то полезное или эмоционально задеть чей-то опыт. И успех и неуспех всегда мои. От этого легко находить мотивацию для новых задач.
Менторство из того же сорта задач. Это не выглядит как на картинке из мультика "Возвращение блудного попугая", где попугай Кеша ловко забросал словами неподготовленную публику. Например, недавно помогала коллеге-аналитику составить резюме. Он больше 10 лет работал в одной и той же компании, подзабыл как делается резюме и расстраивался, что никто не зовет на собесы. Мы долго разбирались с текстами, через пару дней еще раз вычитывали результат. Когда я узнала, что его уже позвали на два собеса, — это ощущалось как те дрова в печке в начале моего текста☺️
А как у вас с мотивацией? Что вы делаете, чтобы понимать результаты своей работы в офисе или вне его?
#мысливслух
Мой папа любит вспоминать ту часть своего детства, которую он провел в деревне. Это было в начале 1960х, в одном их тех мест, где обувь носили только в холода, зимой забирали поросят в дом, а всяких базовых ценностей не то что не хватало, а вообще вряд ли кто-то знал об их существовании в пирамиде Маслоу 😉
Недавно мы рассуждали как мне сложно понять чувства человека, который в холодное время года сидит в своем теплом доме и понимает, что сам успел запастись дровами и теперь может топить печь. Печь он сложил тоже сам.
Могут аналитики похвастаться таким точным пониманием результата? Особенно сложно с этим в найме. Результат часто не зависит от ваших усилий. Бывает кто-то затеял заведомо провальный проект, вы построили клиентский путь как никогда в жизни, но ни один клиент по нему так и не прошел. Если проект удачный, то как измерить именно ваш вклад в этот общий командный успех? Сколько тонн клевера от каждой курицы-несушки будет засыпано в инкубаторы именно от вашей работы?
Этот канал, помогает мне делать тот вид задач, где почти мгновенно можно видеть результат. Есть реакции под текстом, значит удалось рассказать что-то полезное или эмоционально задеть чей-то опыт. И успех и неуспех всегда мои. От этого легко находить мотивацию для новых задач.
Менторство из того же сорта задач. Это не выглядит как на картинке из мультика "Возвращение блудного попугая", где попугай Кеша ловко забросал словами неподготовленную публику. Например, недавно помогала коллеге-аналитику составить резюме. Он больше 10 лет работал в одной и той же компании, подзабыл как делается резюме и расстраивался, что никто не зовет на собесы. Мы долго разбирались с текстами, через пару дней еще раз вычитывали результат. Когда я узнала, что его уже позвали на два собеса, — это ощущалось как те дрова в печке в начале моего текста
А как у вас с мотивацией? Что вы делаете, чтобы понимать результаты своей работы в офисе или вне его?
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4🔥2
Про текст в интерфейсе
#субботнее #мысливслух #конференции
Сегодня я слушаю он-лайн конференцию UX-Марафон #33. Основная тема - работа UX-редакторов. Я никогда не работала с такими специалистами и стало интересно послушать об их работе.
В моем опыте в основном приложения для внутренних операционных процессов компаний (например, управление поставщиками, CRM, системы учета оборудования). Обычно для таких систем не слишком большое значение придается голосу, каким они общаются со своими пользователями. Чаще всего этот голос — это голос аналитика. Вернее, уже давно стали собирать метрики клиентской удовлетворенности не только для клиентских (внешних) приложений, но и для операционных (внутренних), при этом вопросы этой удовлетворенности чаще всего в руках аналитиков, а не UX-специалистов.
UX-редакторы отвечают за понятные тексты на экране и, судя по докладам, речь может идти о любых текстах от FAQ до названий полей и кнопок. Работают в том числе над текстами для чат-ботов и голосовых ботов. Участвуют в вопросах локализации, когда нужно не просто перевести текст, но и вписать в контекст приложения. Кто-то из докладчиков говорил, что его работа только про понятность и удобство, а не про привлечение клиентов, а кто-то следом начинал расcказывать про свою роль в привлечении. Видимо, в любой роли есть свои нюансы 😉
Работа с текстом это про то, чтобы понимать свою аудиторию и контекст, а не просто поправить буквы. В тех докладах, что я послушала, внимание привлекли рекомендации из доклада "Как проверять тексты без исследований: ОКР-ный список редактора"
🔅Текст должен учитывать контекст и эмоции. В каком состоянии пользователь может прийти к тому шагу, где он читает текст. Нужно успокаивать или можно шутить? Например, если не прошла оплата товара, уместно ли в сообщении об ошибке написать что-то вроде «Упс, ваши деньги не ушли!»
🔅Текст должен быть универсальным, то есть учитывать все ситуации, которые могут привести пользователя к этому тексту. Например, не спешите писать «Деньги вернулись на карту» сразу после оформления возврата. Срок перевода в некоторых банках составляет до 5 дней и сразу после возврата пользователь денег на карте пользователь не увидит.
🔅Текст должен быть понятным. Из текста должно быть ясно, что произошло. В одном из докладов прозвучал критерий: «Текст должен быть понятен ученикам 7-8 класса средней школы». В моей практике однажды было сообщение, которое использовали как заглушку, забыли исправить и в итоге на ПРОМ пользователь увидел фразу: «Система не знает, что дальше делать». Слова простые, но ясности никакой.
🔅Текст должен учитывать тональность. В приложении и в компании в целом может быть принят формальный, дружелюбный, панибратский тон. Чаще всего приложения стараются общаться с нами в спокойно-дружелюбном тоне.
🔅Все элементы текста должны быть логически связаны. Заголовки, подзаголовки, элементы списка должны быть логически связаны. Например, в этом тексте я несколько раз поправила названия в списке, потому что некоторые оказались про важность чего-то в тексте, а некоторые про «делайте так». Пришлось выбирать между логикой перечисления рекомендаций и инструкции к действию.
🔅Текст должен быть грамотным. Оставлю этот пункт без комментариев 😊
В комментариях поделюсь примером. Добавляйте свои, если у вас есть «любимые» или «наболевшие» примеры😊
#субботнее #мысливслух #конференции
Сегодня я слушаю он-лайн конференцию UX-Марафон #33. Основная тема - работа UX-редакторов. Я никогда не работала с такими специалистами и стало интересно послушать об их работе.
В моем опыте в основном приложения для внутренних операционных процессов компаний (например, управление поставщиками, CRM, системы учета оборудования). Обычно для таких систем не слишком большое значение придается голосу, каким они общаются со своими пользователями. Чаще всего этот голос — это голос аналитика. Вернее, уже давно стали собирать метрики клиентской удовлетворенности не только для клиентских (внешних) приложений, но и для операционных (внутренних), при этом вопросы этой удовлетворенности чаще всего в руках аналитиков, а не UX-специалистов.
UX-редакторы отвечают за понятные тексты на экране и, судя по докладам, речь может идти о любых текстах от FAQ до названий полей и кнопок. Работают в том числе над текстами для чат-ботов и голосовых ботов. Участвуют в вопросах локализации, когда нужно не просто перевести текст, но и вписать в контекст приложения. Кто-то из докладчиков говорил, что его работа только про понятность и удобство, а не про привлечение клиентов, а кто-то следом начинал расcказывать про свою роль в привлечении. Видимо, в любой роли есть свои нюансы 😉
Работа с текстом это про то, чтобы понимать свою аудиторию и контекст, а не просто поправить буквы. В тех докладах, что я послушала, внимание привлекли рекомендации из доклада "Как проверять тексты без исследований: ОКР-ный список редактора"
🔅Текст должен учитывать контекст и эмоции. В каком состоянии пользователь может прийти к тому шагу, где он читает текст. Нужно успокаивать или можно шутить? Например, если не прошла оплата товара, уместно ли в сообщении об ошибке написать что-то вроде «Упс, ваши деньги не ушли!»
🔅Текст должен быть универсальным, то есть учитывать все ситуации, которые могут привести пользователя к этому тексту. Например, не спешите писать «Деньги вернулись на карту» сразу после оформления возврата. Срок перевода в некоторых банках составляет до 5 дней и сразу после возврата пользователь денег на карте пользователь не увидит.
🔅Текст должен быть понятным. Из текста должно быть ясно, что произошло. В одном из докладов прозвучал критерий: «Текст должен быть понятен ученикам 7-8 класса средней школы». В моей практике однажды было сообщение, которое использовали как заглушку, забыли исправить и в итоге на ПРОМ пользователь увидел фразу: «Система не знает, что дальше делать». Слова простые, но ясности никакой.
🔅Текст должен учитывать тональность. В приложении и в компании в целом может быть принят формальный, дружелюбный, панибратский тон. Чаще всего приложения стараются общаться с нами в спокойно-дружелюбном тоне.
🔅Все элементы текста должны быть логически связаны. Заголовки, подзаголовки, элементы списка должны быть логически связаны. Например, в этом тексте я несколько раз поправила названия в списке, потому что некоторые оказались про важность чего-то в тексте, а некоторые про «делайте так». Пришлось выбирать между логикой перечисления рекомендаций и инструкции к действию.
🔅Текст должен быть грамотным. Оставлю этот пункт без комментариев 😊
В комментариях поделюсь примером. Добавляйте свои, если у вас есть «любимые» или «наболевшие» примеры
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
Новые темы неплохо начинать именно с понедельника☕️ Стало интересно написать о мифах про работу бизнес-аналитика в ИТ. Каждый миф хочу разобрать отдельно. Чтобы это адекватно выглядело в формате Телеграмм, сделаю отдельный пост для каждого. Получится сериал из нескольких эпизодов.
👍2
#1 Миф о работе бизнес-аналитика. Не нужны знания о программировании
#мысливслух #мифы
Если полистать вакансии, то для роли БА даже без совмещения с системным анализом, наниматели часто ожидают как минимум понимание ИТ-архитектуры и процессов разработки. Зачем это?
📍Приходится разбираться в преимуществах и ограничениях систем, которые служат для автоматизации процессов. Невозможно предложить процессные и функциональные решения без понимания, на чем они строятся. Можно уточнить у разработчиков, но как много вопросов в день они готовы обработать?
📍Нужно обрисовать образ результата коллегам, которые применяют знания о системах и алгоритмах для решения любых задач. Их система аргументации и приоритетов построена на этих знаниях. Без минимальных знаний ИТ-архитектуры сложно понять, зачем вас просят изменить требование, потому что «у нас сервис отправки получает только мета-данные и не видит весь текст сообщения»
Из нужных знаний я бы выделила:
🔅Принципы работы с данными. Не нужно уметь создавать базы данных, но обязательно понимать как данные организуются и как хранятся. Уметь моделировать данные на концептуальном и логическом уровне. Этот навык поможет правильно выделять объекты предметной области и связи между ними
🔅Основы архитектуры. Нужно понимать какими способами системы могут взаимодействовать между собой. Это поможет сформулировать требования так, чтобы вас поняли, и читать документацию без переводчика. Еще такое знание помогает быстрее понимать ограничения для бизнес-процессов
🔅Процесс разработки. Речь именно о производстве: написании кода, контроле версии, сборке и установке релиза, тестировании и работе с багами. Так вы будете быстрее понимать, почему вчера можно было «быстренько изменить», а сегодня уже поздно; почему «у нас монолит, мы не можем ничего выпилить из релиза»
#мысливслух #мифы
Если полистать вакансии, то для роли БА даже без совмещения с системным анализом, наниматели часто ожидают как минимум понимание ИТ-архитектуры и процессов разработки. Зачем это?
📍Приходится разбираться в преимуществах и ограничениях систем, которые служат для автоматизации процессов. Невозможно предложить процессные и функциональные решения без понимания, на чем они строятся. Можно уточнить у разработчиков, но как много вопросов в день они готовы обработать?
📍Нужно обрисовать образ результата коллегам, которые применяют знания о системах и алгоритмах для решения любых задач. Их система аргументации и приоритетов построена на этих знаниях. Без минимальных знаний ИТ-архитектуры сложно понять, зачем вас просят изменить требование, потому что «у нас сервис отправки получает только мета-данные и не видит весь текст сообщения»
Из нужных знаний я бы выделила:
🔅Принципы работы с данными. Не нужно уметь создавать базы данных, но обязательно понимать как данные организуются и как хранятся. Уметь моделировать данные на концептуальном и логическом уровне. Этот навык поможет правильно выделять объекты предметной области и связи между ними
🔅Основы архитектуры. Нужно понимать какими способами системы могут взаимодействовать между собой. Это поможет сформулировать требования так, чтобы вас поняли, и читать документацию без переводчика. Еще такое знание помогает быстрее понимать ограничения для бизнес-процессов
🔅Процесс разработки. Речь именно о производстве: написании кода, контроле версии, сборке и установке релиза, тестировании и работе с багами. Так вы будете быстрее понимать, почему вчера можно было «быстренько изменить», а сегодня уже поздно; почему «у нас монолит, мы не можем ничего выпилить из релиза»
❤4🔥3
#2 Миф о работе бизнес-аналитика. Заказчик должен знать, чего хочет
#мысливслух #мифы
Ради красоты заголовка позволила себе немного рискованную формулировку. Плохо, если даже на уровне метрик продукта никто из заинтересованных сторон не понимает, к чему нужно прийти. Другая крайность - считать, что заинтересованные стороны должны уметь сформировать запрос на самом детальном уровне. При этом за термином «заказчик» может потеряться часть заинтересованных сторон, пара слов об этом в Дзене
В реальности сформировать запрос во всех деталях означает провести работу по оптимизации процессов и проектированию функциональности. Заказчик не обязан иметь навыки анализа предметной области, оптимизации процессов и проектирования систем. Кто-то признаётся в этом честно, а кто-то старается играть роль адепта технологий. Я однажды услышала: «Мне все понятно, у меня же муж айтишник!»
(Синди Альварес «Как создать продукт, который купят»)
Из своего опыта заметила:
📍Заказчик не знает чего хочет - значит вы, как БА, можете смело применять многие исследовательские инструменты, об этом пару слов писала в этом посте. Можно искать и предлагать свои варианты решения, есть шанс, что это примут с интересом и даже благодарностью (особенно, если заказчик не претендует на роль ИТ-эксперта)
📍Когда клиент слишком хорошо знает, чего хочет — будьте бдительны, может быть ему это не нужно, но обнаружите вы это уже после внедрения. Лучше проверить гипотезы заинтересованных сторон через прототип или модель процесса, на которой видны возможные сценарии
📍Переменчивость запросов заинтересованных сторон может быть связана с недоверием к вам или ко всей команде разработки. Для выстраивания доверия помогают открытость и управление ожиданиями сторон. Важно не создавать завышенных ожиданий заинтересованных сторон и по возможности объяснять шаги работы над задачей ⚙️
#мысливслух #мифы
Ради красоты заголовка позволила себе немного рискованную формулировку. Плохо, если даже на уровне метрик продукта никто из заинтересованных сторон не понимает, к чему нужно прийти. Другая крайность - считать, что заинтересованные стороны должны уметь сформировать запрос на самом детальном уровне. При этом за термином «заказчик» может потеряться часть заинтересованных сторон, пара слов об этом в Дзене
В реальности сформировать запрос во всех деталях означает провести работу по оптимизации процессов и проектированию функциональности. Заказчик не обязан иметь навыки анализа предметной области, оптимизации процессов и проектирования систем. Кто-то признаётся в этом честно, а кто-то старается играть роль адепта технологий. Я однажды услышала: «Мне все понятно, у меня же муж айтишник!»
Ваш потребитель лучше всех знает, что мешает ему в его собственном мире. Но это не значит, что он может облечь свое знание в слова.
(Синди Альварес «Как создать продукт, который купят»)
Из своего опыта заметила:
📍Заказчик не знает чего хочет - значит вы, как БА, можете смело применять многие исследовательские инструменты, об этом пару слов писала в этом посте. Можно искать и предлагать свои варианты решения, есть шанс, что это примут с интересом и даже благодарностью (особенно, если заказчик не претендует на роль ИТ-эксперта)
📍Когда клиент слишком хорошо знает, чего хочет — будьте бдительны, может быть ему это не нужно, но обнаружите вы это уже после внедрения. Лучше проверить гипотезы заинтересованных сторон через прототип или модель процесса, на которой видны возможные сценарии
📍Переменчивость запросов заинтересованных сторон может быть связана с недоверием к вам или ко всей команде разработки. Для выстраивания доверия помогают открытость и управление ожиданиями сторон. Важно не создавать завышенных ожиданий заинтересованных сторон и по возможности объяснять шаги работы над задачей ⚙️
👍2
#3 Миф о работе бизнес-аналитика. Цель работы — составить документ
#мысливслух #мифы
Постановка задачи БА часто выглядит как «написать требования» или «составить документ» и гораздо реже как «спроектировать процесс» или «предложить варианты решения». Может создаться впечатление, что смысл и основной результат работы именно в составлении документа.
Сложно спорить, что документ — это важный инструмент передачи информации, аналитик должен уметь составлять разные виды документов. Кроме того, немало проектов, где артефакты анализа — это важная часть поставки в рамках договора с внешним заказчиком. При этом
📍 Мир меняет не сам документ, а то решение, что в нем описано и ценно в первую очередь то, насколько успешно будут внедрены изменения, которые вы предлагаете.
📍Самого по себе документа в общем случае недостаточно, чтобы внедрить изменения. Приходится признать, что текст требований мало кто читает внимательно. Люди игнорируют элементы задачи, которые им кажутся не связанными с выполнением этой задачи или выглядят очевидными. Например, в описании экранной формы вы описали выпадающий список. Чаще всего дальше типа поля мало кто дочитает. Понятно же что это такое и как выглядит в дизайне! То, что в списке требуется множественный выбор и нужна зависимость между опциями, обнаружится уже при тестировании.
На мой взгляд нужно учитывать, что:
🔅Как любой другой проектный артефакт, документ — это часть того, что можно сдать/показать/продать в результате работы команды, пренебрегать этим нельзя. При этом фокус работы БА нужно сохранять именно на внедрении изменений.
🔅Не стоит приобретать наркотическую зависимость от документирования. Бывают случаи, когда кто-то пытается задокументировать функциональность, уже внедренную 3-5 лет назад, при этом доработка функционала не стоит на месте и текст устаревает быстрее, чем его пишут…
🔅Когда позволяет методология в вашей компании, имеет смысл комбинировать способы передачи информации и дополнять текст картами, прототипами, обсуждениями и видео-комментариями🌱
#мысливслух #мифы
Постановка задачи БА часто выглядит как «написать требования» или «составить документ» и гораздо реже как «спроектировать процесс» или «предложить варианты решения». Может создаться впечатление, что смысл и основной результат работы именно в составлении документа.
Сложно спорить, что документ — это важный инструмент передачи информации, аналитик должен уметь составлять разные виды документов. Кроме того, немало проектов, где артефакты анализа — это важная часть поставки в рамках договора с внешним заказчиком. При этом
📍 Мир меняет не сам документ, а то решение, что в нем описано и ценно в первую очередь то, насколько успешно будут внедрены изменения, которые вы предлагаете.
📍Самого по себе документа в общем случае недостаточно, чтобы внедрить изменения. Приходится признать, что текст требований мало кто читает внимательно. Люди игнорируют элементы задачи, которые им кажутся не связанными с выполнением этой задачи или выглядят очевидными. Например, в описании экранной формы вы описали выпадающий список. Чаще всего дальше типа поля мало кто дочитает. Понятно же что это такое и как выглядит в дизайне! То, что в списке требуется множественный выбор и нужна зависимость между опциями, обнаружится уже при тестировании.
На мой взгляд нужно учитывать, что:
🔅Как любой другой проектный артефакт, документ — это часть того, что можно сдать/показать/продать в результате работы команды, пренебрегать этим нельзя. При этом фокус работы БА нужно сохранять именно на внедрении изменений.
🔅Не стоит приобретать наркотическую зависимость от документирования. Бывают случаи, когда кто-то пытается задокументировать функциональность, уже внедренную 3-5 лет назад, при этом доработка функционала не стоит на месте и текст устаревает быстрее, чем его пишут…
🔅Когда позволяет методология в вашей компании, имеет смысл комбинировать способы передачи информации и дополнять текст картами, прототипами, обсуждениями и видео-комментариями🌱
🔥1
Кейс про новогоднюю елку
#кейс #субботнее
Этот пост сложился из новогоднего настроения и тестового задания для аналитиков. Сделала диаграмму состояний новогодней елки.
Вы наверняка помните, что диаграмма состояний (statechart diagram) показывает как объект переходит из одного состояния в другое. Состояние показывает ситуацию в жизненном цикле объекта, когда он удовлетворяет какому-то условию, выполняет некоторую деятельность или ожидает события. На такой диаграмме можно показать жизненный цикл только одного объекта. Так в моем примере не получится наглядно показать связанные статусы новогодних игрушек, когда их достали из коробки и повесили на елку.
🎄 В каком из состояний у вас сейчас новогодняя елка? Какие альтернативные состояния и переходы можно дополнить к ее жизненному циклу?
#кейс #субботнее
Этот пост сложился из новогоднего настроения и тестового задания для аналитиков. Сделала диаграмму состояний новогодней елки.
Вы наверняка помните, что диаграмма состояний (statechart diagram) показывает как объект переходит из одного состояния в другое. Состояние показывает ситуацию в жизненном цикле объекта, когда он удовлетворяет какому-то условию, выполняет некоторую деятельность или ожидает события. На такой диаграмме можно показать жизненный цикл только одного объекта. Так в моем примере не получится наглядно показать связанные статусы новогодних игрушек, когда их достали из коробки и повесили на елку.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1😍1
О кнопочных телефонах и об источниках требований
#что_почитать #мысливслух
На картинках варианты расположения кнопок телефона, исследованные в Bell Laboratories в 1960м году. Статья по итогам исследования называлась «Технические исследования человеческого фактора при проектировании и использовании кнопочных телефонных аппаратов» (оригинал тут). На тот момент важно было
📍понять, почему операторы часто ошибаются при наборе на двух рядах из пяти кнопок номеров вида 815 RE 4-0267?
📍перейти к индивидуальным телефонам с кнопочным набором для использования тонового набора
Были исследованы группы вариантов по параметрам «скорость набора», «доля ошибок» и оценкам респондентов, а затем варианты из «победивших» групп сравнили между собой по тем же параметрам. Исследования проводились среди сотрудников компании Bell Laboratories.
В таблице на картинке видно, что респонденты на первое место поставили вариант из двух рядов кнопок от 1 слева в первом ряду до 0 снизу справа. Вариант, к которому мы сейчас привыкли, оказался на третьем месте.
На самом деле скорость набора не слишком отличалась в зависимости от расположения кнопок. Вариант 3х3+1 был выбран, так как «имел определенные технологические преимущества».
Что делать, если никто не может рассказать что нужно? Искать варианты, ранжировать и учитывать перспективы разработки. Это может сработать 🌱
P.S. Если вам интересно почитать больше о кнопках и телефонах, то можно заглянуть в статью Краткая история развития клавиатуры с цифрами
#что_почитать #мысливслух
На картинках варианты расположения кнопок телефона, исследованные в Bell Laboratories в 1960м году. Статья по итогам исследования называлась «Технические исследования человеческого фактора при проектировании и использовании кнопочных телефонных аппаратов» (оригинал тут). На тот момент важно было
📍понять, почему операторы часто ошибаются при наборе на двух рядах из пяти кнопок номеров вида 815 RE 4-0267?
📍перейти к индивидуальным телефонам с кнопочным набором для использования тонового набора
Были исследованы группы вариантов по параметрам «скорость набора», «доля ошибок» и оценкам респондентов, а затем варианты из «победивших» групп сравнили между собой по тем же параметрам. Исследования проводились среди сотрудников компании Bell Laboratories.
В таблице на картинке видно, что респонденты на первое место поставили вариант из двух рядов кнопок от 1 слева в первом ряду до 0 снизу справа. Вариант, к которому мы сейчас привыкли, оказался на третьем месте.
На самом деле скорость набора не слишком отличалась в зависимости от расположения кнопок. Вариант 3х3+1 был выбран, так как «имел определенные технологические преимущества».
Что делать, если никто не может рассказать что нужно? Искать варианты, ранжировать и учитывать перспективы разработки. Это может сработать 🌱
P.S. Если вам интересно почитать больше о кнопках и телефонах, то можно заглянуть в статью Краткая история развития клавиатуры с цифрами
🔥5🤩1
Новогодние истории или мой первый корпоратив на работе
#мысливслух #что_почитать
До нового года и выходных совсем немного, пришло время рассказывать истории. Эта история о моей первой работе и опыте первого корпоративного НГ. Здесь хочется добавить что-то вроде “усаживайтесь поудобнее и слушайте”, я попробую рассказать…
Первая моя работа - инженер-программист в одном из конструкторских бюро. Там в начале нулевых была особая атмосфера и я часто ее вспоминаю. Атмосферу определяли совершенно уникальные люди. Тогда уже сложно было представить себе инженера, который 30-40 лет посвятил одному делу и одному работодателю, а мне повезло наблюдать целый коллектив. В этом коллективе работало много тех, кто хорошо помнил как это было в 70х, когда разработчик по записи попадал в машинный зал… И не вздумайте представить себе какую-то дряхлость! Во-первых многие из этих инженеров в свои годы знали и помнили то, что мы с вами забыли уже через час после получения диплома 👩🎓 Во-вторых я очень хочу передать атмосферу с точки зрения тогдашнего джуна и могу случайно перестараться.
“Вот вы векторное произведение неправильно рассчитали и мост у вас упал. Будете говорить как вы пойдете и доучите?”, - это я как-то услышала от преподавателя на экзамене. Вспомнила тоже к рассказу об атмосфере. Разработка в промышленном производстве отличается от разработки веб-приложения для офисной работы. Код в итоге управляет вполне реальным, а не виртуальным предметом. Можно видеть как буквы на твоем экране физически влияют на окружающий материальный мир. Отсюда особое отношение к качеству работы и пониманию командного результата (получилась отсылка к сегодняшнему дню, не уверена, что кому-то в голову эта фраза пришла бы двадцать лет назад).
🎄 Сотрудников 20-ти лет было мало, мы были новым впечатлением для старших. Как праздновать с нами корпоративный НГ было не очень понятно, каких-то больших мероприятий, квизов и розыгрышей никто не устраивал. Мой первый корпоративный НГ прошел в очень ламповой атмосфере, какую я видела только в старом кино. Готовились за неделю или две, распределяли задачи, салаты и покупки. В последний рабочий день года сдвигали столы, накрывали их перфорированной бумагой. Вместе что-то чистили, резали, раскладывали. Потом сидели за столом и рассказывали истории… Ходили с поздравлениями в соседние отделы… Звучит не очень зажигательно, но поверьте, что совместно нарезанный салат сближает ничуть не хуже удачного ретро 😊
А чем вам запомнилась первая работа? Как прошел ваш первый корпоративный НГ?
P.S. Если вам интересно как была устроена работа программиста 50-60 лет назад, можно заглянуть в статью Когда машины были большими.
#мысливслух #что_почитать
До нового года и выходных совсем немного, пришло время рассказывать истории. Эта история о моей первой работе и опыте первого корпоративного НГ. Здесь хочется добавить что-то вроде “усаживайтесь поудобнее и слушайте”, я попробую рассказать…
Первая моя работа - инженер-программист в одном из конструкторских бюро. Там в начале нулевых была особая атмосфера и я часто ее вспоминаю. Атмосферу определяли совершенно уникальные люди. Тогда уже сложно было представить себе инженера, который 30-40 лет посвятил одному делу и одному работодателю, а мне повезло наблюдать целый коллектив. В этом коллективе работало много тех, кто хорошо помнил как это было в 70х, когда разработчик по записи попадал в машинный зал… И не вздумайте представить себе какую-то дряхлость! Во-первых многие из этих инженеров в свои годы знали и помнили то, что мы с вами забыли уже через час после получения диплома 👩🎓 Во-вторых я очень хочу передать атмосферу с точки зрения тогдашнего джуна и могу случайно перестараться.
“Вот вы векторное произведение неправильно рассчитали и мост у вас упал. Будете говорить как вы пойдете и доучите?”, - это я как-то услышала от преподавателя на экзамене. Вспомнила тоже к рассказу об атмосфере. Разработка в промышленном производстве отличается от разработки веб-приложения для офисной работы. Код в итоге управляет вполне реальным, а не виртуальным предметом. Можно видеть как буквы на твоем экране физически влияют на окружающий материальный мир. Отсюда особое отношение к качеству работы и пониманию командного результата (получилась отсылка к сегодняшнему дню, не уверена, что кому-то в голову эта фраза пришла бы двадцать лет назад).
А чем вам запомнилась первая работа? Как прошел ваш первый корпоративный НГ?
P.S. Если вам интересно как была устроена работа программиста 50-60 лет назад, можно заглянуть в статью Когда машины были большими.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤6🥰3😍1
С Новым годом и отличных каникул!
#что_почитать
Я очень признательна уходящему году за то, что решилась делиться знаниями о своей работе и что собралось столько читателей! Вы же понимаете - синдром самозванца нужно еще заслужить!☺️
Канал отправляется на каникулы до 8го января. Вернусь с новыми статьями и историями. Прежде, чем наряжать елку, хочу пожелать всем нам, чтобы в новом году
✨заказчики были вовлеченными,
✨команды — дружными,
✨спроектированные решения — работающими,
✨процессы — понятными,
✨ТЗ — прочтенными и согласованными!
Если на каникулах будет время почитать, то вот тут
📍Навигация по статьям сентября-ноября
📍О трех мифах про БА (#мифы)
📍Памятка по источникам требований
📍О текстах в интерфейсе
📍О кнопочных телефонах и об источниках требований
🎄 🎄 🎄
#что_почитать
Я очень признательна уходящему году за то, что решилась делиться знаниями о своей работе и что собралось столько читателей! Вы же понимаете - синдром самозванца нужно еще заслужить!
Канал отправляется на каникулы до 8го января. Вернусь с новыми статьями и историями. Прежде, чем наряжать елку, хочу пожелать всем нам, чтобы в новом году
✨заказчики были вовлеченными,
✨команды — дружными,
✨спроектированные решения — работающими,
✨процессы — понятными,
✨ТЗ — прочтенными и согласованными!
Если на каникулах будет время почитать, то вот тут
📍Навигация по статьям сентября-ноября
📍О трех мифах про БА (#мифы)
📍Памятка по источникам требований
📍О текстах в интерфейсе
📍О кнопочных телефонах и об источниках требований
Please open Telegram to view this post
VIEW IN TELEGRAM
🍾15❤5☃4
☀️ Вернувшись с каникул рада видеть новых подписчиков! В начале нового рабочего года решила повторить и дополнить пост-приветствие.
Привет всем!
Меня зовут Анастасия. Проектирую функциональность информационных систем более 15 лет. Началось все с разработки на ассемблере в одном из конструкторских бюро. Через пару лет я поняла, что мне интереснее делать продукты для людей, поэтому ушла сначала в тестирование, а позже в системный и бизнес-анализ. Добралась и до продуктового управления. Сейчас продолжаю карьеру и активно делюсь опытом в роли наставника, преподавателя, автора публикаций для аналитиков.
Помогаю аналитикам
• разбираться в техниках бизнес-анализа,
• готовиться к собеседованиям,
• решать кейсы,
• готовиться к выступлениям на отраслевых конференциях\семинарах,
• планировать развитие в профессии.
Чтобы договориться о консультации или задать вопрос нажмите кнопку "Задать вопрос" в этом закрепленном посте. В сообщении укажите детали вашего запроса.
Этот канал - способ поделиться прочитанным и увиденным в сфере бизнес-анализа в ИТ. Мне интереснее всего делиться наблюдениями и мыслями, а еще опытом применения техник бизнес-анализа. Обзоров статей и книг здесь чуть меньше. Это заметно, если посмотреть публикации под тегами:
📍#кейс — здесь разбор кейсов и примеры применения разных техник
📍#мысливслух — под этим тегом публикации с историями и профессиональным опытом
📍#что_почитать — этим тэгом отмечены подборки, обзоры статей и посты со ссылками на статьи
📍#agile – то, что связано с инструментами гибких методологий: бэклог, DOD, DOR, USM и не только
📍#книжки — обзоры книг
Еще можно найти мой канал в ВК
На аватарке канала изображение от storyset на Freepik
Меня зовут Анастасия. Проектирую функциональность информационных систем более 15 лет. Началось все с разработки на ассемблере в одном из конструкторских бюро. Через пару лет я поняла, что мне интереснее делать продукты для людей, поэтому ушла сначала в тестирование, а позже в системный и бизнес-анализ. Добралась и до продуктового управления. Сейчас продолжаю карьеру и активно делюсь опытом в роли наставника, преподавателя, автора публикаций для аналитиков.
Помогаю аналитикам
• разбираться в техниках бизнес-анализа,
• готовиться к собеседованиям,
• решать кейсы,
• готовиться к выступлениям на отраслевых конференциях\семинарах,
• планировать развитие в профессии.
Чтобы договориться о консультации или задать вопрос нажмите кнопку "Задать вопрос" в этом закрепленном посте. В сообщении укажите детали вашего запроса.
Этот канал - способ поделиться прочитанным и увиденным в сфере бизнес-анализа в ИТ. Мне интереснее всего делиться наблюдениями и мыслями, а еще опытом применения техник бизнес-анализа. Обзоров статей и книг здесь чуть меньше. Это заметно, если посмотреть публикации под тегами:
📍#кейс — здесь разбор кейсов и примеры применения разных техник
📍#мысливслух — под этим тегом публикации с историями и профессиональным опытом
📍#что_почитать — этим тэгом отмечены подборки, обзоры статей и посты со ссылками на статьи
📍#agile – то, что связано с инструментами гибких методологий: бэклог, DOD, DOR, USM и не только
📍#книжки — обзоры книг
Еще можно найти мой канал в ВК
На аватарке канала изображение от storyset на Freepik
❤12👍8
Способы использования BPMN
#что_почитать
C BPMN (Business Process Modeling Notation) я впервые познакомилась, когда оказалась в продукте на PegaBPM — это платформа для автоматизации управления процессами. Исполняемая диаграмма процесса строится в ней в соответствии со стандартом BPMN. Когда я перешла в другую команду и получила задание составить диаграмму процесса в BPMN 2.0, то честнейшим образом использовала нотацию со всеми ее шлюзами и событиями. Следовало бы учесть, что диаграмма строится не для исполнения в каком-либо движке, а для предоставления заинтересованным сторонам. Заинтересованные стороны привыкли к упрощенной адаптированной версии и испытали шок от моих диаграмм :) Так я на собственном опыте столкнулась с преимуществами и недостатками моделирования процессов в BPMN. Диаграммы могут быть сложны для чтения неподготовленной аудиторией и это создает риск организовать непонимание вместо общей понятной картины процесса. Особенно, если применять нотацию там, где она не нужна. Хочу поделиться парой статей, которые очень бы мне пригодились тогда :)
🔅6 неправильных способов использовать BPMN и альтернативы BPMN. Статья от гуру нотации BPMN, в которой объясняется для каких задач не нужно ее использовать.
🔅 3 (and only 3) Reasons to Use BPMN (ENG) Если свести рекомендации к трем основным пунктам, то использовать BPMN нужно, если
• не получается увидеть детали процесса в другой нотации,
• в вашем продукте регламент или платформа требуют именно этой нотации,
• вы на собеседовании и требуется показать знание BPMN.
#что_почитать
C BPMN (Business Process Modeling Notation) я впервые познакомилась, когда оказалась в продукте на PegaBPM — это платформа для автоматизации управления процессами. Исполняемая диаграмма процесса строится в ней в соответствии со стандартом BPMN. Когда я перешла в другую команду и получила задание составить диаграмму процесса в BPMN 2.0, то честнейшим образом использовала нотацию со всеми ее шлюзами и событиями. Следовало бы учесть, что диаграмма строится не для исполнения в каком-либо движке, а для предоставления заинтересованным сторонам. Заинтересованные стороны привыкли к упрощенной адаптированной версии и испытали шок от моих диаграмм :) Так я на собственном опыте столкнулась с преимуществами и недостатками моделирования процессов в BPMN. Диаграммы могут быть сложны для чтения неподготовленной аудиторией и это создает риск организовать непонимание вместо общей понятной картины процесса. Особенно, если применять нотацию там, где она не нужна. Хочу поделиться парой статей, которые очень бы мне пригодились тогда :)
🔅6 неправильных способов использовать BPMN и альтернативы BPMN. Статья от гуру нотации BPMN, в которой объясняется для каких задач не нужно ее использовать.
🔅 3 (and only 3) Reasons to Use BPMN (ENG) Если свести рекомендации к трем основным пунктам, то использовать BPMN нужно, если
• не получается увидеть детали процесса в другой нотации,
• в вашем продукте регламент или платформа требуют именно этой нотации,
• вы на собеседовании и требуется показать знание BPMN.
👍1🤩1
Сколько нужно времени, чтобы проснуться и выпить кофе?
#кейс #bpmn
В продолжение темы BPMN хочу предложить небольшой кейс.Чтобы потренироваться в отображении времени на диаграмме, сделала пример с промежуточными событиями-таймерами, в том числе прикрепленными. Прерывающими и непрерывающими. Не придумала ничего лучше как изобразить на диаграмме свое собственное утро и борьбу не то со сном, не то с повторами будильника☺️
🔅Прерывающее событие-таймер (Timer Boundary Event (Interrupting) ) показывает дату, шаг цикла или время ожидания в процессе. Когда бы ни произошло такое событие, связанное действие прерывается.
🔅Непрерывающее событие-таймер (Timer Intermediate Catch Event) показывает дату, шаг цикла или время ожидания в процессе. Когда бы это событие ни произошло, процесс может продолжаться.
По диаграмме на картинке, сколько нужно времени, чтобы подняться утром и выпить кофе?
#кейс #bpmn
В продолжение темы BPMN хочу предложить небольшой кейс.Чтобы потренироваться в отображении времени на диаграмме, сделала пример с промежуточными событиями-таймерами, в том числе прикрепленными. Прерывающими и непрерывающими. Не придумала ничего лучше как изобразить на диаграмме свое собственное утро и борьбу не то со сном, не то с повторами будильника
🔅Прерывающее событие-таймер (Timer Boundary Event (Interrupting) ) показывает дату, шаг цикла или время ожидания в процессе. Когда бы ни произошло такое событие, связанное действие прерывается.
🔅Непрерывающее событие-таймер (Timer Intermediate Catch Event) показывает дату, шаг цикла или время ожидания в процессе. Когда бы это событие ни произошло, процесс может продолжаться.
По диаграмме на картинке, сколько нужно времени, чтобы подняться утром и выпить кофе?
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5
По диаграмме на картинке, сколько нужно времени, чтобы подняться утром и выпить кофе?
Anonymous Quiz
10%
Не менее 32 мин
24%
Не менее 7 мин
2%
Не менее 35 мин
64%
На диаграмме этого не указано
Можно ли войти в ИТ через калькулятор?
#мысливслух #что_почитать #истории
Недавно в одном из чатиков обменивались рассказами о том кто как «вошел в ИТ». Как обычно, я описала свои поиски, которые сегодня могут выглядеть неправильно смонтированными кадрами фильма о карьере. Трансформация там такая: разработчик — тестировщик — QA Lead — BA — BA Lead... Потом поняла, что могу рассказать историю поинтереснее. Расскажу здесь, чтобы немного скрасить утро понедельника ☀️
Впервые и неудачно я вошла в ИТ в первом или втором классе школы. Это совсем не о юных гениях, которые в первом классе выигрывают студенческие олимпиады. Это о двоечнице, которая решила потихоньку от родителей подсчитать примеры по математике на калькуляторе. В конце 80-х в нашей математической семье появился новый модный гаджет — программируемый калькулятор МК-61. Он бережно хранился в дермантиновом чехле и в коробке, подальше от детских глаз, и появлялся на столе только когда у кого-то из родителей находилось время на эксперименты в программировании. К тому же он стоил, как я сейчас понимаю, процентов 80 от зарплаты каждого из моих родителей 🙈
Разве можно что-то спрятать от ребенка в однокомнатной хрущевке? Сидеть одной и что-то там складывать и умножать было скучно и, пока никто не видит, бесценный агрегат был извлечен, включен, кнопки нажаты и полученные ответы записаны в тетрадку. На следующий день получила двойку. Первое знакомство с ИТ оказалось провальным, зато научило не жать кнопки, не разобравшись, что к чему☺️
Немного позже разобралась, что у МК-61 есть операционный стек из 4х регистров памяти, а есть 15 регистров общего назначения. Можно было писать программы до 105 шагов и энтузиасты публиковали статьи с алгоритмами для этих калькуляторов. Особенно популярно было писать на них игрушки. Ну и я, затаив дыхание от ощущения причастности к чему-то научному и технологичному, честно выписывала на листочке команды:
[50][X→П][2] — заносим в REG2 значение 50,
[32][X→П][3] — заносим в REG3 значение 32….
Если вам интересна история ИТ, то вот пара статей об этой серии калькуляторов МК-61: история, эмуляция, устройство и Карманный компьютер из 1985 года: программируемый калькулятор «Электроника МК-54»
А каким вам запомнился "вход в ИТ"? Есть у вас гаджеты, которые ассоциируются с первым знакомством с ИТ?
#мысливслух #что_почитать #истории
Недавно в одном из чатиков обменивались рассказами о том кто как «вошел в ИТ». Как обычно, я описала свои поиски, которые сегодня могут выглядеть неправильно смонтированными кадрами фильма о карьере. Трансформация там такая: разработчик — тестировщик — QA Lead — BA — BA Lead... Потом поняла, что могу рассказать историю поинтереснее. Расскажу здесь, чтобы немного скрасить утро понедельника ☀️
Впервые и неудачно я вошла в ИТ в первом или втором классе школы. Это совсем не о юных гениях, которые в первом классе выигрывают студенческие олимпиады. Это о двоечнице, которая решила потихоньку от родителей подсчитать примеры по математике на калькуляторе. В конце 80-х в нашей математической семье появился новый модный гаджет — программируемый калькулятор МК-61. Он бережно хранился в дермантиновом чехле и в коробке, подальше от детских глаз, и появлялся на столе только когда у кого-то из родителей находилось время на эксперименты в программировании. К тому же он стоил, как я сейчас понимаю, процентов 80 от зарплаты каждого из моих родителей 🙈
Разве можно что-то спрятать от ребенка в однокомнатной хрущевке? Сидеть одной и что-то там складывать и умножать было скучно и, пока никто не видит, бесценный агрегат был извлечен, включен, кнопки нажаты и полученные ответы записаны в тетрадку. На следующий день получила двойку. Первое знакомство с ИТ оказалось провальным, зато научило не жать кнопки, не разобравшись, что к чему
Немного позже разобралась, что у МК-61 есть операционный стек из 4х регистров памяти, а есть 15 регистров общего назначения. Можно было писать программы до 105 шагов и энтузиасты публиковали статьи с алгоритмами для этих калькуляторов. Особенно популярно было писать на них игрушки. Ну и я, затаив дыхание от ощущения причастности к чему-то научному и технологичному, честно выписывала на листочке команды:
[50][X→П][2] — заносим в REG2 значение 50,
[32][X→П][3] — заносим в REG3 значение 32….
Если вам интересна история ИТ, то вот пара статей об этой серии калькуляторов МК-61: история, эмуляция, устройство и Карманный компьютер из 1985 года: программируемый калькулятор «Электроника МК-54»
А каким вам запомнился "вход в ИТ"? Есть у вас гаджеты, которые ассоциируются с первым знакомством с ИТ?
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7👎1
Подборка статей про дизайн-мышление
#что_почитать
Наверняка вы часто слышите термин «дизайн-мышление». Определения встречаются очень разные - это и идеология, и процесс, и набор методик для решения задач. И то и другое опирается на принципы клиентоориентированности, эмпатии, сотрудничества и некоторые другие.
📍Применение дизайн-мышления при выявлении требований (ENG) Чтобы понимать потребности конечных пользователей и предлагать работающие решения, БА важно применять принципы дизайн-мышления. Поэтапно описано применение стенфордской модели дизайн-мышления. Эти этапы: Эмпатия,Определение, Идея, Прототип, Тест. Картинка к посту взята из этой статьи
📍Концепция Дизайн-мышления: что это такое, основные принципы, идеи и методики Подробное пошаговое описание известной модели дизайн-мышления Double Diamond. После статьи завершающей эту подборку, мне не очень зашли примеры применения дизайн-мышления
📍Карта эмпатии - первый шаг в дизайн-мышлении (ENG) В блоге Norman Nielsen Group о технике картирования знаний об отношении и поведении пользователей. Есть не только описание и пошаговые рекомендации, но и пример
📍Спорность дизайн-мышления Это перевод статьи автора Jon Kolko. Понравились рассуждения об истории дизайн-мышления и появлении его основных принципов. Приведена критика дизайн-мышления как процесса. По мнению автора невозможно разделить дизайн-мышление и создание вещей, а без понимания психологии решения задач и долгосрочного погружения в культуру дизайна, дизайн-мышление превращается в забавную разминку, но не в серьезную работу по созданию чего-либо
#что_почитать
Наверняка вы часто слышите термин «дизайн-мышление». Определения встречаются очень разные - это и идеология, и процесс, и набор методик для решения задач. И то и другое опирается на принципы клиентоориентированности, эмпатии, сотрудничества и некоторые другие.
Дизайн-мышление — противоположность группового мышления, однако, что парадоксально, оно протекает в группах. Обычный эффект «группового мышления», как объяснил Уильям Уайт читателям Fortune еще в 1952 году, заключается в подавлении креативности отдельных людей. Дизайн-мышление, в свою очередь, стремится к высвобождению такой креативности (из книги Тима Брауна «Дизайн-мышление в бизнесе: от разработки новых продуктов до проектирования бизнес-моделей»)
📍Применение дизайн-мышления при выявлении требований (ENG) Чтобы понимать потребности конечных пользователей и предлагать работающие решения, БА важно применять принципы дизайн-мышления. Поэтапно описано применение стенфордской модели дизайн-мышления. Эти этапы: Эмпатия,Определение, Идея, Прототип, Тест. Картинка к посту взята из этой статьи
📍Концепция Дизайн-мышления: что это такое, основные принципы, идеи и методики Подробное пошаговое описание известной модели дизайн-мышления Double Diamond. После статьи завершающей эту подборку, мне не очень зашли примеры применения дизайн-мышления
📍Карта эмпатии - первый шаг в дизайн-мышлении (ENG) В блоге Norman Nielsen Group о технике картирования знаний об отношении и поведении пользователей. Есть не только описание и пошаговые рекомендации, но и пример
📍Спорность дизайн-мышления Это перевод статьи автора Jon Kolko. Понравились рассуждения об истории дизайн-мышления и появлении его основных принципов. Приведена критика дизайн-мышления как процесса. По мнению автора невозможно разделить дизайн-мышление и создание вещей, а без понимания психологии решения задач и долгосрочного погружения в культуру дизайна, дизайн-мышление превращается в забавную разминку, но не в серьезную работу по созданию чего-либо