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

Я решил проанализировать рынок продажи и аренды гаражей и парковочных мест своего города. Квартиры – слишком дорогие объекты для инвестиций, а что касается гаражей и паркингов – тут «вход» гораздо меньше, и на аренду вроде бы всегда есть спрос.

Большой гайд по CJM — зачем, где и как его строить

Один из элементов создания качественного продукта — получить как можно больше информации о своем пользователе. Знать его потребности, проблемы, боли, барьеры и эмоции.

Один из полезных и крутых инструментов, который помогает мне улучшать продукт — это CJM 🤗

CJM или Customer Journey Map — это, если по простому, карта пути клиента. Инструмент визуализации, который лучше помогает представить путь пользователя — от возникшей у пользователя потребности и поиска им информации о продукте, до покупки и пользования продуктом.

Требования, конечно, меняются. Иногда. Но гораздо чаще случается, что мы не до конца выяснили у заказчика и стейкхолдеров все требования, оставив множество умолчаний.

В этой статье я опишу примеры подобных ситуаций и расскажу о техниках, позволяющих задать нужные вопросы, выявить максимальное количество требований на ранних этапах анализа, обсудить со стейкхолдерами нужность этих требований и их приоритеты. Как правило, после применения всех техник в 1,5−2 раза возрастает объём требований и юзкейсов для обсуждения — и это одна из основных задач аналитика: задать все вопросы и выяснить все детали до начала проектирования и разработки системы.

Возможно, многие подходы вы уже применяете, а о некоторых даже не слышали; я попробую свести их в единую систему.

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

Помните, как вы были студентами, и готовились к экзаменам по ночам?

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

Изучите теорию на примерах и закрепите на 13 практических задачах по SQL.

Этот материал для тех, кто хочет эффективно погружаться в проекты большого масштаба и следить за состоянием их здоровья. В статье расскажу, как максимально быстро разобраться в стандарте OMG Essence и начать применять его в работе.

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

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

Инструкция от разработчиков https://tesseract-ocr.github.io/tessdoc/Home.html не всегда сразу понятна и очевидна, поэтому и появилась мысль записать свой опыт в эту статью.

У меня на компьютере стоит Linux Mint 20.2 Cinnamon, поэтому все действия происходят в этой системе и я не могу гарантировать, что все получится точно так же в Windows или Mac.

Для начала необходимо установить бибилиотеку tesseract на компьютер. Делается это достаточно просто. Сначала проверю версию, которая уже установлена (как правило в комплекте с Linux уже есть пакет tesseract). В терминале набираем

Привет, Хабр. Меня зовут Ольга, я работаю в тестировании с 2013 года, специализируюсь на тест-анализе и тест-дизайне. Сегодня хочу рассказать, как при планировании тестирования сохранить фокус на пользователях и их потребностях.

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

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

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

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

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

Разработчику с проектированием и документированием решения задачи помогает аналитик.

“Аналитик, проанализируй мне эту задачу” - говорит бизнес-заказчик. Что он имеет в виду? Анализ - это всего лишь  метод исследования, характеризующийся выделением и изучением отдельных частей объектов исследования (по википедии), но бизнес в своих словах подразумевает нечто большее, чем просто анализ.

Что делает ИТ-аналитик и в чем ценность его работы для бизнеса? Пробуем разобраться. 

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

Представьте, что вам предстоит собеседование на позицию системного аналитика (СА). Что нужно знать для успешного прохождения интервью и какие вопросы могут задать? Эта статья может стать roadmap при подготовке к собеседованию.

Я проходил технические собеседования на системного аналитика в самых разных компаниях и каждый раз записывал все вопросы. У меня накопилось 120 вопросов. Список вопросов выкладываю в этой статье. Даю гарантию, что, подготовившись по этим вопросам, вы будете успешно проходить технические собеседования в большинстве, если не во всех, it-компаниях. Почему? Потому что большинство вопросов повторяются от собеседования к собеседованию. Очень высока вероятность того, что вопросы, которые вам будут задавать, будут из этого списка.

• Введение в процесс Running Lean
  • Три важнейших методологии
  • Roadmap
• Описание процесса Running Lean
  
  • Составьте «План А»
    
    • Определите кто клиенты
    • Создайте бизнес-модели
    • Ранжируйте бизнес-модели
  • Протестируйте и измените план
    
    • Подготовьтесь к проведению экспериментов
    • Категории рисков и четыре фазы тестирования плана
      
      • Фаза 1. Поймите проблему
      • Фаза 2. Найдите решение
      • Фаза 3. Валидируйте качественно
      • Фаза 4. Верифицируйте количественно
• Три стадии стартапа
  
  • Соотношение трех стадий стартапа и четырех фаз тестирования плана
  • Держите правильный фокус
  • Привлекайте финансирование вовремя
  • Масштабируйте правильно

1. Независимость от фреймворка. Архитектура не зависит от существования какой-либо библиотеки. Это позволяет использовать фреймворк в качестве инструмента, вместо того, чтобы втискивать свою систему в рамки его ограничений.
2. Тестируемость. Бизнес-правила могут быть протестированы без пользовательского интерфейса, базы данных, веб-сервера или любого другого внешнего компонента.
3. Независимоcть от UI. Пользовательский интерфейс можно легко изменить, не изменяя остальную систему. Например, веб-интерфейс может быть заменен на консольный, без изменения бизнес-правил.
4. Независимоcть от базы данных. Вы можете поменять Oracle или SQL Server на MongoDB, BigTable, CouchDB или что-то еще. Ваши бизнес-правила не связаны с базой данных.
5. Независимость от какого-либо внешнего сервиса. По факту ваши бизнес правила просто ничего не знают о внешнем мире.