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

Однако такое положение коснулось далеко не всех. В конце марта Интернет-издание CMS Magazine опубликовало “Исследование текущей ситуации на digital-рынке Рунета и стран СНГ”, в котором показало, что более половины респондентов заявило об открытии новых вакансий, а общая оценка рынка и ситуации в отдельных компаниях в среднем близка к «умеренной».

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

Введение

Некоторое время назад я стал участником проекта по разработке программного продукта, предназначенного для анализа поступающих из медицинских организаций записей о пациентах и данных об их состоянии здоровья с целью формирования единой медицинской карты. Долгое время команда не могла выработать подход к объединению данных пациентов. Отправной точкой послужило изучение исходных кодов решения Open EMPI (Open Enterprise Master Patient Index), которые подтолкнули нас к алгоритмам анализа похожести строк. С этого момента началось более глубокое изучение материалов, позволившее создать сначала макет, а потом и рабочее решение.

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

Материал представляет собой перевод статьи wikipedia «Record linkage» с авторскими правками и дополнениями.

Введение

Некоторое время назад обратил свое внимание на артефакт Концепция продукта (product vision) методологии разработки программного обеcпечения RUP (Rational Unified Process) и обнаружил, что отправной точкой разработки программного продукта является выявление проблемы, на решение которой нацелен продукт.

Аналогичный подход существует и в отечественной практике – так в ГОСТ 34.601-90 говорится, что на стадии Формирование требований к АС (автоматизированной системе) производится «выявление проблем, решение которых возможно средствами автоматизации».

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

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

Работая над статьей о роли требований в процессе разработки программного обеспечения я обнаружил шкалу уровней зрелости процесса управления требованиями (requirements management maturity), предложенную в 2003 году одним из специалистов по работе с требованиями Rational Software Джимом Хьюманном (Jim Heumann).

Хочу поделиться с читателями habrahabr данной классификацией.

Введение

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

Ниже приведена шкала уровней зрелости процесса управления требованиями, построенная по аналогии с моделью CMMI. Эти модели никак не связаны между собой, но имеют некоторое пересечение. Так, достижение уровня 5 (Интеграция требований) зрелости процесса управления требованиями позволит получить как минимум уровень 3 (Процессы определены на уровне всей организации) по модели CMMI. Однако это не является прямым следствием, так как достижение высокого уровня зрелости в одном процессе не гарантирует общего повышения зрелости организации в целом.