Управление рисками проекта

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

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

РИСКИ ПРОЕКТА НА ЭТАПАХ ЖИЗНЕННОГО ЦИКЛА

Жизненный цикл проекта по внедрению программ 1С состоит из нескольких этапов, на каждом из которых присутствуют свои риски. Также существуют общие риски всего проекта.

К общим проектным рискам обычно относятся:

  • риски в виде отсутствия поддержки со стороны руководства заказчика;

  • отсутствие четкого разделения ответственности между проектными командами заказчика и исполнителя, а также внутри самой проектной команды;

  • недостаток времени у проектной команды заказчика в связи с выполнением текущих функциональных обязанностей;

  • отсутствие соответствующей компетенции у персонала;

  • предоставление неполноценной или несогласованной информации;

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

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

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

На этапе проектирования и разработки осуществляется проработка архитектуры системы в целом, а также некоторых её модулей. На этом этапе велики технологические риски, связанные с ошибкой решения в части архитектуры информационной системы или неполной проработкой отдельных модулей и/или взаимосвязей между ними, неучтенными нефункциональными требованиями, такими как отклик системы на действия пользователя, надежность данных, их масштаб и технические возможности оборудования заказчика и т.п. Критичным является то, что выявление этих рисков происходит в достаточно поздние сроки, например на стадии опытной эксплуатации или эксплуатации на реальных данных реальными пользователями 1С. Это приводит к необходимости экстренного выполнения доработок или даже возможного срыва проекта в целом в силу непригодности системы к реальной и полноценной эксплуатации.

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

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

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

РИСК-МЕНЕДЖМЕНТ ПРОЕКТА

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

А риски в итоге возникают (это неизбежно) и приходится их в суете решать. Но ведь можно это сделать заранее и спокойно, до старта проекта.

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

Управление рисками проекта можно разделить на 3 части:

  1. Идентификация, анализ и оценка рисков проекта

  2. Определение мероприятий по управлению рисками

  3. Контроль и мониторинг рисков проекта

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

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

Перед стартом проекта проводится работа по идентификации возможных и существующих рисков. Процесс идентификации представляет собой поиск всех возможных рисков, по итогам которого мы должны найти ответы на вопрос: «Что может пойти не так?» (для негативных рисков). Но при поиске ответов на вопрос: «Что может пойти не по плану?» можно найти и позитивные риски.

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

Оценка рисков проекта и идентификация проводится для составления плана реагирования на риски. Оптимально управлять одновременно не более 10 рисками.

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

 

Такое ограничение говорит о том, что, как и у треугольника, нельзя изменить одну сторону, не задев как минимум ещё одну. Изменение одного параметра управления проектом влияет и на другие параметры.

Поэтому процесс контроля и мониторинга рисков ориентирован на оценку текущей ситуации по проекту: управление рисками, анализ возникших отклонений, контроль изменений и их влияния на все параметры проекта.

При выборе стратегии управления рисками проекта необходимо учитывать понятие о риске проекта. Риск проекта – это неопределенное событие, которое в случае его возникновения имеет негативное или позитивное воздействие как минимум на один из параметров проекта (например, срок или бюджет проекта).

Исходя из логики определения риска проектов можно выделить следующее:

  1. Риск имеет как негативную, так и позитивную сторону. Дело в том, что при переводе с английского слово «риск» имеет значение «шанс».

  2. Риск – это неопределенное событие, то есть событие, которое может произойти или нет с некоторой вероятностью. Таким образом мы должны понимать, что событие не считается риском, если мы точно знаем, произойдет оно или нет.

  3. Риск влияет на проект. То есть если какое-то событие (например, засуха на другом материке) не влияет на цели и параметры проекта, то это не является риском.

  4. Любой риск имеет два обязательных параметра: влияние и вероятность возникновения.

При расчетах величины риска значения влияния и вероятности возникновения определяются по шкале от 0 до 1:

0 – известно, что событие определенно не произойдет

1 – известно, что событие определенно произойдет.

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

В процессе расчета величин риска определяются стратегии ликвидации рисков. При этом можно использовать следующие мероприятия по реагированию на риски:

  • Уклонение от риска предполагает корректировку плана управления проектом так, чтобы максимально исключить угрозу негативного риска, а также снизить последствия риска для целей проекта (например, пересмотреть график проекта или изменить объемы путем исключения некритичных модификаций). Важно заметить, что некоторых рисков можно избежать, если на ранних стадиях проекта детализировано собирать требования заказчика, налаживать более приятные коммуникации.

  • Передача риска осуществляется путем переложения негативных последствий риска под ответственность третьей стороны. При этом необходимо понимать, что при передаче управления риском третьей стороне сам риск не снимается. Такая стратегия управления риском эффективна в части финансовых рисков. Например, страхование, гарантии выполнения контракта, выдача гарантийных обязательств и т.п. Естественно, что условия передачи рисков третьей стороне несут в себе обязательства по выплате премии за риск третьей стороне. Если проект подразумевает оплату фактических издержек заказчиком, то бремя выплаты премии может быть переложено на заказчика, а вот с фиксированной ценой контракта это бремя обычно ложится уже на исполнителя.

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

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

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

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

В данном реестре рисков кроме перечня возможных рисков определяется, как данный риск влияет на проект, учитывается величина риска по вероятности наступления и степени его влияния и определяются мероприятия (стратегия) по управлению этим риском.

Пример реестра рисков:

Описание риска 

Потенц. воздействие на проект

Вероятн. возн-ия

Влияние на проект

Уровень риска

Вариант решения 

1

Недостаточное внимание к проекту со стороны бизнес-экспертов (например вследствии их занятости текущей работой или участия в других проектах). Возможно, риск проявится на интеграционном тесте

— Эксперты не выдают ответную реакции и тормозят проект или ведет к сдвигу сроков старта— Недостаток ресурсов от Заказчика

0,4

0,9

0,36

1) Заранее оговорить возможность подключения доп. экспертов в случае занятости основных участников2) заложить в бюджет проекта (заказчику) доп. мотивацию экспертов на резульатты проекта (премирование по завершению проекта)3) Привлечение спонсора проекта к решению конфликта ресурсов4) Замена бизнес-эксперта на менее занятого специалиста

2

Отставание в разработке скриптов или модификаций

0,3

0,5

0,15

1) Позиционирование задач по проекту как задач 1 приоритета2) Заложить резервы в плане работ между модификациями и началом интеграционного теста3) Для модификаций: приостановка всех остальных модификаций4) Для скриптов: определение приоритетных и необходимых к старту

3

Смена заказчика

0,2

0,6

0,12

вести документацию, встретится с новым заказчиком сразу после смены

4

Смена требований 

0,8

0,9

0,72

дизайн решения, хорошая документация, записи, протоколы

5

Производительность системы, блокировки

Низкая производительность системы может привести к простоям при работе ключевых процессов (приемка/отгрузка)

0,5

0,5

0,25

замеры при большом объеме, можно риски оптимизации взять на себя,увеличение мощности серверов, добавление памяти и т.д.1) Разводим сервер приложений и SQL сервер на разное «железо» — Трилайн2) Планирование железа с резервом относительно рекомендаций вендора

6

Фин. Стабильность заказчика или изменчивость заказчика

часто меняющиеся приоритеты и взгляды заказчика

0,4

0,9

0,36

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

7

Смена проектной команды – мониторить состояние людей и искать замену если кто-то уходит

0,7

0,7

0,49

мониторить состояние людей и искать замену если кто-то уходит

8

Предварительная оценка трудоемкости по задачам проекта не соответствует оценке, уточняемой сейчас по факту написания ФД, т.к.ФД отсутстовали момент подготовки первоначальной оценки

Неверная (оптимистичная) оценка сроков разработки может повлечь срыв сроков по подготовке к старту

0,8

0,9

0,72

1. Упрощение функционала, отказ от неприоритетных требований2. сдвиг сроков проекта, расширение бюджета проекта1) Закладывание в план резервов по времени относительно оценки трудоемкости — ФТО2) Разделение модификаций на критичные для старта и некритичные — и выполнение в соответствии с приоритетами (некритичные модификации, не готовые на момент начала интеграционного теста не участвуют в нем) — ФТО

9

Работа во время нового года — 1) недоступность компетентных людей на филиалах. Если потребуется оперативно поменять БП, то это не с кем будет обсудить. Например, решение по включению в работу доп. операторов никто не сможет исполнить2) недоступность экспертов. Пример — до старта принято решение о сохранении кредитного лимита, после старта выявляется, что необходимо отключить кр. лимит. Этот вопрос будет не с кем согласовать

срыв сроков запуска, старта системы

0,5

0,8

0,4

Письмо от РП на директора:1) на каждом филиале должно быть выделено ответственное лицо (нач. ООЗ или операторов выписки), который будет доступен 01.01.хх гг. С ними предварительно обсудить возможные сложности при старте2) Получить контакты всех экспертов проекта3) Получить полномочия на принятие решений своими силами (В случае если связаться с экспертами не удается — принятие решений производить самостоятельно)

10

Возникновение проблем с каналом в Омске/Москве в новый год. Работы выполнены не будут, так как провайдер оперативно проблему не решит

срыв сроков запуска, старта системы

0,4

0,8

0,32

В Омске: Есть два магистральных канала в офисе. Если даже закрыть риск сбоя в обоих, то необходимо протестировать работу каналов на дому у одного из специалистов, осуществляющих перенос остатковВ ЦО: риска нет

11

Есть изменения в алгоритмах работы пользователей. Это может повлечь человеческие ошибки

0,8

0,8

0,64

Информирование специалистов на филиалах по двум каналам — через лидеров на филиале и через функциональных руководителей (Координация действий осуществляется через службу поддержки, с использованием ленты сообщений в аксапте, телефона, e-mail)

12

Риск падения производительности в первые 5 дней после старта новой базы (из-за быстрого роста базы)

падение производительности и блокировки из-за одновременной работы многих пользователей и нагрузка по загрузке остатков

0,8

0,9

0,72

1) Периодический пересчет статистики2) Продумать вариант подключения доп. оборудования для нужд статистики и периндексации — например, узел от архивной и офлайна.3) Анализ и выявление таблиц, по которым может потребоваться переиндексация (а также выяснение времени, необходимого  на переиндексацию).В случае возникновения проблемы проводить переиндексацию по необходимым индексам (возможно, потребуется останов), временное увеличение мощности серверов

13

Для запуска новой базы будет необходим длительный останов (более суток)

0,9

0,9

0,81

1) Тест производительности2) В случае, если тест производительности покажет, что времени впритык — подготовка алгоритма действий для возврата к работе в старой базе (например, перенос заказов на 2007 год из новой базы в старую, ярлыки)Возврат на старую базу до 12:00ч 01 января. Проведение повторно работ с 31 января на 01 февраля

14

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

0,5

0,5

0,25

Необходимо заранее договориться какие члены в команде должны быть взаимозаменяемыми, как со стороны ФТО, так и со стороны Заказчика. Перед новым годом провести «передачу знаний»

15

Служба поддержки (при текущем графике работы) не будет справляться с поступающими вопросами от пользователей.

0,8

0,9

0,72

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

16

Закрытие декабря и текущего года, а также января следующего года не будет выполнено во время

в момент старта новой системы еще не буде закрыт период в старой системе и не будет реалных данных по остаткам

0,5

0,9

0,45

1) Требуется заранее согласовать с руководством ЮМ возможное отставание2) На помощь в закрытии выделить двух квалифицированных специалистов службы поддержки3) перенос временных остатков по тем данным что есть в старой базе. После закрытия периода доперенос остатков

17

С 27.12 будет действовать две базы — старая и новая для ввода заказов на следующий год. При этом в старой базе могут изменить настройки и справочники, которые не попадут в новую (случайно, т.к. права должны быть закрыты по плану)Либо пользователи будут выполнять операции не в той базе

0,7

0,9

0,63

1. Выслать на всех пользователей аксапты, и ежедневно дублировать, требование не изменять справочники и настройки в старой базе с 27.12 по 31.122. Программные запреты на выполнение операций в неправильной базе3. Вручную откорректировать справочники в старой базе в случае расхождения. Операции сторнировать и вводить в правильную базу

18

Объем ручной работы бухгалтеров по переносу остатков может сдвинуть срок закрытия

0,5

0,7

0,35

1. По результатам сформированного дизайн-решения удалось добиться минимальной ручной работы. Есть подтверждение, что доп.ресурс не нужен2. В случае тотального кризиса подключение поддержки к выполнению сверок

19

Сжатые сроки выполнения работ

0,5

0,9

0,45

Подневное планирование работ руководителями проектных группПодготовка и тщательное соблюдение процедуры для согласования документов, как наиболее рисковой в части подготовки Концептуального проекта.Сформировать временной резерв в части даты запуска проекта в продуктивную эксплуатацию.

20

Расширение объема проекта в ходе выполнения

0,6

0,9

0,54

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

21

Большое количество модификаций

0,8

0,9

0,72

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

22

Один руководитель возглавляет несколько проектных групп

0,5

0,8

0,4

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

23

Один сотрудник выступает в качестве эксперта в нескольких проектных группах

0,5

0,8

0,4

Основные негативные влияние риска: невозможность независимой работы групп, необходимость согласования загрузки бизнес-экспертами между различными проектными группами. Бизнес-эксперты перегружены информацией по различным функциональным модулям 1С, что затрудняет ее усвоение.Риск может быть минимизирован распределением бизнес-экспертов по отдельным группам (определение будущей специализации бизнес-эксперта), с возможностью привлечения другими проектными группами по договоренности между руководителями групп.

24

Перераспределение нагрузки в разнородных проектных группах

0,5

0,6

0,3

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

25

 Отсутствие у клиента на дату начала проекта подготовленной проектной команды и специалистов по 1С.

Основным негативным влиянием риска является затягивание сроков проекта в связи с необходимостью обучения новому решению, вероятность принятия некорректных решений в связи с недостатком знаний о 1С, сложности с поддержкой и тиражированием решения силами клиента и ФТО 

0,5

0,8

0,4

Для минимизации данного риска следует организовать обучение проектной команды согласно рекомендациям фирмы 1С. Руководители проектных групп отвечают за формирование 1С-экспертизы в своих группах и имеют право запросить проведение дополнительного обученияУчастники проектной команды клиента и ФТО приобретают практический опыт использования 1С при выполнении задач проекта.

26

Не полное понимание и принятие, бизнес-экспертами и сотрудниками проектных групп клиента стандартных бизнес-процессов и лучших практик 1С.

срыв сроков запуска проекта, сложности в реализации модификаций

0,7

0,7

0,49

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

27

Бизнес-процессы, разработанные в по головному предприятию, не будут приняты на пилотной площадке

0,3

0,8

0,24

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

28

Неработоспособность более 10% функционала после переноса модификаций

0

Добавление ресурса разработки ФТО

29

Невозможность полноценного переноса  функционала на внедряемую редакцию

0,5

0,6

0,3

Изменение функционала ПО

30

В период между полной готовностью ПО и стартом появятся изменения в законодательстве, требующие модификаций, и ПО на момент старта не будет соответствовать ему в полном объеме

0,6

0,7

0,42

Добавление ресурса разработкиСо стороны бизнес-эксперта заказчика — постоянный мониторинг изменения законодательства в части планируемой автоматизации бизнес-процессов

31

Не будет выделено достаточное время пользователей на обучение — пересечение с рабочим графиком

— Плохое качество обучения— Плохое понимание нового функционала, непривычность к интерфейсу -> ошибки в работе с новой системой -> возможные проблемы с отгрузкой

0,6

0,9

0,54

1) Минимум за неделю до старта обучения согласовать комфортный график обучения2) по результатам обучения провести аттестацию, тестирвоание3) Резервы времени по обучению людей, выполняющих бизнес-критичные операции — ФТООбучение будет проводиться по группам пользователей (склад — отдельно, заявки — отдельно и т.п.), вместе с группами обучаются непосредственные руководители4) со стороны заказчика — контроль и планирование текущей работы и графика работы сотрудников

32

Большой объем разработки -> ошибки в новом функционале -> возможны проблемы на старте (оперативного плана)

0,5

0,8

0,4

Выделение достаточного объема времени на интеграционный тест

33

Срыв сроков закрытия периода в старой системе, может привести к задержке закрытия месяца старта в новой

0,5

0,8

0,4

мер нет на заказчик должен быть к этому готов.

34

Большая загрузка бизнес-экспертов, может пострадать качество приемки разработанной системы (интеграционного теста)

0,7

0,9

0,63

Планирование интеграционного теста в период с наименьшей загрузкой экспертовПланирование замены бизнес-экспертов для приема функционала системы

35

Изменяются настройки кредитного лимита — могут быть проблемы с недоотгрузкой в первые дни работы

0,8

0,4

0,32

Проверка кредитных лимитов перед запуском системы (руководитель отдела)

36

Новый документооборот склада -> путаница в рядах операторов, бухгалтерия может потом «не собрать» нужные документы

0,8

0,6

0,48

Предварительное обучение людей (операторы) именно документооборотуОформление подробных инструкций пользователя со схемами документооборота

37

Коммуникационный риск («правая рука не знает что делает левая») между ФТО и субподрядчиком — системным администратором по тех. поддержке ТСД

0,4

0,7

0,28

с даты старта — еженедельные совещания  (Бухгалтерия + Склад + Продажи + Закупки + ИТ + ФТО) по ходу работ, в течение первой недели после старта — ежедневные — с субподрядчиком

38

Риск наложения ввода 2-х проектов одновременно работа с ТСД и ФТО. Риск некорректной работы ПО для ТСД, используется не тиражное решение

0,5

0,7

0,35

Предусмотреть в плане интеграционного теста этап проверки сопряжения с ТСД по всем функциям — ФТОПрогон по работе с ТСД всех кладовщиков на складе (еще до сопряжения с аксаптой) — субподрядчик

39

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

0,5

0,9

0,45

Предусмотреть в плане интеграционного теста этап проверки сопряжения кассами по всем функциям — ФТО

40

Расширение рамок проекта в плане функционального объема (на интеграционном тесте)

0,5

0,8

0,4

Анализ и распределение по степени критичности и необходимости внедрения к дате старта

41

Риск проявления ошибок в ходе согласования процессов (недостаточная полнота или точность информации), которые приведут к неработоспособности процессов по факту

0,5

0,8

0,4

Проведение интегротеста принимаемого функционала системы должно выполняться не только по выполненым модификациям, но и по стандартному функционалу ПО

42

Функциональный риск — новый функционал резервирования продукции под существующие заказы. Может привести к путанице и снижению контроля за товарным объемом

0,5

0,8

0,4

Предусмотреть в плане интеграционного теста детальную проверку функционала резервирования — ФТОПредоставить кейсы примеров по всем вариантам резервирования товаров — Заказчик

43

Отсутствие утвержденной учетной политики и плана счетов может привести к изменениям относительно согласованного дизайна

0,3

0,7

0,21

Детальное интервью со службой бухгалтерии

44

Нарушение товародвижения (расхождения фактических остатков и движений по складу с операциями в системе)

0,5

0,8

0,4

Только интеграционный тест, других вариантов нет. ФТО (качественный план) + Субподрядчик (выделение времени)

45

Не укомплектован штат пользователей. Предварительно определено, что должно быть 2 человека в ночь, днём 1 + 1 по возвратам, + хотя бы один маршрутизаторщик

0,4

0,7

0,28

Планирование человеческих ресурсов со стороны заказчика с учетом предварительных оценок по численности необходимого штата

46

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

0,5

0,5

0,25

Проверить корректность вводом документа каждого вида перед стартом

47

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

0,5

0,8

0,4

1) Делаем сравнительный анализ серверов (например, с наиболее загруженным филиалом) — ФТО2) Разводим сервер приложений и SQL сервер на разное «железо» — ИТ-служба заказчика3) В течение 2 месяцев после запуска запланирована покупка нового сервера — ИТ-служба заказчика

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

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

Ещё одной предупредительной мерой может быть наличие плана «С». Так или иначе при стратегии реагирования на риск всегда имеется как минимум план «А», а если что-то пошло не так, то выполняется план «В». Но в некоторых случаях можно предусмотреть также план «С», когда количество векторов развития событий высоко, и когда и план «А», и план «В» могут не так пойти или реакция на эти риски окажется не той, которую ожидали.

Заключение

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

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


ссылка на оригинал статьи https://habr.com/ru/post/647099/

Ситуация: все больше музыкальных компаний выходит на IPO — зачем они это делают

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

Фотография: Nick Hillier. Источник: Unsplash.com
Фотография: Nick Hillier. Источник: Unsplash.com

Ловят волну

За последние годы на фоне популярности стриминговых сервисов резко возросла стоимость лейблов. Компании «большой тройки» — Universal, Warner Music и Sony Music — контролируют 80% музыкального рынка, который преодолеет планку в $45 млрд к 2030 году. Неудивительно, что студии звукозаписи желают извлечь еще большую выгоду из своего доминирующего положения. Одним из инструментов в этом контексте становится IPO — первичное размещение акций.

Выход на биржу открывает доступ к капиталу для дальнейшего развития. Так, за прошедшие пару лет IPO провели сразу два лейбла — Warner Music и Universal Music Group. В первый день торгов их акции выросли на 20 и 39% соответственно.

При этом нужно понимать, что экономическую основу музыкальной индустрии составляют права на треки. Это — главный предмет торговли, вокруг которого выстраиваются доходы студий и самих исполнителей. Можно ожидать, что лейблы направят деньги инвесторов на расширение собственных музыкальных библиотек, чтобы получать больше роялти от стриминговых сервисов. Например, в прошлом году Universal уже приобрели полную дискографию Боба Дилана — точная сумма сделки неизвестна, но аналитики оценили её в сотни миллионов долларов.

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

Плывут против течения

Муз. рынок поделен между тремя лейблами, ниша стриминговых платформ также переполнена. Это понимают многие компании, поэтому они выходят на IPO, чтобы продолжить развитие в смежных областях. Так, сервис для распознавания музыки SoundHound после размещения акций в этом году планирует развивать собственного голосового помощника Houndify. В компании считают, что к 2026-му рынок виртуальных ассистентов перешагнет планку в $160 млрд. Сервис уже интегрировали в приложение стриминг-площадки Pandora. Но технологию продвигают и за пределами индустрии — например, в автомобилестроении.

Также в планах компании — запуск единой голосовой экосистемы, объединяющей музыкальные платформы и бытовые устройства. В достижении этой цели помогут деньги инвесторов. На IPO компания планирует выручить $244 млн.

Переживают кризис

Пандемия нанесла достаточно ощутимый урон музыкальной индустрии. «Зацепило» даже стриминговые площадки — число прослушиваний хитов сократилось на 11%. Но сильнее других пострадала розница. Продажи ряда музыкальных магазинов упали на 20%, а некоторые объявили о банкротстве.

Фотография: Simon Weisser. Источник: Unsplash.com
Фотография: Simon Weisser. Источник: Unsplash.com

Но для магазинов музыкальных инструментов пандемия, наоборот, стала драйвером продаж. Люди, скучавшие во время локдауна, стали массово скупать муз. инструменты. Гитарный ретейлер Guitar Center решил уцепиться за эту возможность и подал заявку на проведение IPO, чтобы привлечь дополнительные средства.

К слову, одной из причин первичного размещения акций Warner Music также стало желание снизить негативное влияние пандемии. Доходы компании от продажи физических носителей во втором квартале 2020 года упали на 27%. Чтобы стабилизировать ситуацию и привлечь ресурсы, лейбл решился на IPO.

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

Не все идет гладко

Акции Warner Music торговались на бирже с 2005 по 2011 год. На рубеже десятилетий прибыль компании начала падать из-за распространения стриминговых сервисов. Общая стоимость акций снизилась на 78%, и в итоге лейбл выкупила Access Industries за $3,3 млрд. Получится ли Warner Music избежать аналогичной судьбы на этот раз — предстоит увидеть в будущем.

Фотография: Melanie van Leeuwen. Источник: Unsplash.com
Фотография: Melanie van Leeuwen. Источник: Unsplash.com

Неудачные IPO есть и в портфолио стриминговых площадок. В 2015 году заявку на размещение акций подавал французский сервис потоковой передачи музыки Deezer. Компания планировала выручить $343 млн и направить деньги на привлечение клиентов и партнеров. Но от идеи пришлось отказаться — инвесторы посчитали оценку компании слишком завышенной. Вероятно, они находились под впечатлением от падения стоимости акций другого сервиса потоковой музыки — Pandora. Компания не могла конкурировать со Spotify и Apple.

На биржу выходили не только стриминговые сервисы и лейблы, но и отдельные исполнители. Например, пять лет назад на биржу должны были попасть «акции» Эминема. Онлайн-платформа Royalty Exchange выкупила у лейбла музыканта 15% от выручки, поступающей в рамках выплат роялти за коммерческое использование треков Маршалла. Эти активы планировали предложить инвесторам. Однако поторговать акциям Эминема никому не удалось. Тогда биржа NASDAQ по неизвестной причине (скорее всего, из-за нюансов регулирования) отозвала разрешение на размещение.

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


О чем еще мы пишем в «Мире Hi-Fi»:



ссылка на оригинал статьи https://habr.com/ru/company/audiomania/blog/647041/

Шпионаж за пользователями через Wi-Fi сеть или почему не стоит доверять общественным сетям

Доброго времени суток. Статья не станет откровением для тех, кто работает / работал сетевиком, но будет полезна и интересна людям, не связанных с этой сферой.

Целью статьи будет получить максимальное количество информации о деятельности людей в личной сети.

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

Для начала действий нам понадобится:

  • Компьютер (вероятно, ноутбук) с сетевой картой и установленным Debian (подойдет любой другой дистрибутив Linux, либо вовсе другое семейство ОС, но тогда инструкции в статье могут не совпадать).

  • Wireshark.

  • Nmcli.

  • Источник, обеспечивающий компьютеру доступ в Интернет, отличный от Wi-Fi (подойдет проводное соединение, либо банальный USB-модем на телефоне).

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

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

Для начала, отключаем компьютер от Wi-Fi сети.

Далее нужно получить имя сетевого интерфейса. В Debian получить это имя можно следующей командой:

ifconfig

Если /usr/sbin не добавлен в переменную PATH, то необходимо выполнить следующую команду вместо первой:

/usr/sbin/ifconfig

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

Далее необходимо создать саму сеть. У нас есть достаточное количество данных для этого процесса. Выполняем, предварительно заменив wlp2s0 на название своего сетевого интерфейса, а wifi — на название своей сети. Обратите внимание, что название сети должно кодироваться не более, чем 32-я байтами. Если Вы используете только английские символы, то 1 символ кодируется 1 байтом и можно использовать длину сети до 32-х символов. Если Вы используете символы иного алфавита, то 1 символ кодируется 2 байтами и можно использовать длину сети до 16-и символов.

INTERFACE="wlp2s0" NAME="wifi" nmcli con add type wifi ifname $INTERFACE con-name $NAME autoconnect yes ssid $NAME nmcli con modify $NAME 802-11-wireless.mode ap 802-11-wireless.band bg ipv4.method share nmcli con up $NAME

Команды выше поднимут сеть без шифрования, если же нам потребуется создать сеть с шифрованием, то следует выполнить следующие команды, предварительно, по аналогии с первым вариантом, заменив переменные INTERFACE и NAME, а также указать в переменную PASSWORD Ваш пароль. Обратите внимание, что длина пароля должна быть от 8-и символов.

INTERFACE="wlp2s0" NAME="wifi" PASSWORD="12345678" nmcli con add type wifi ifname $INTERFACE con-name $NAME autoconnect yes ssid $NAME nmcli con modify $NAME 802-11-wireless.mode ap 802-11-wireless.band bg ipv4.method share nmcli con modify $NAME wifi-sec.key-mgmt wpa-psk nmcli con modify $NAME wifi-sec.psk $PASSWORD nmcli con up $NAME

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

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

Поздравляем! Мы создали рабочую сеть! В любой момент ее можно отключить и удалить этой командой, заменив wifi на имя Вашей сети.

nmcli connection delete id "wifi"

Теперь, допустим, что кто-то подключился к этой сети. Запустим Wireshark, указав наш сетевой интерфейс. Далее надо сделать небольшую настройку. Переходим в «Редактирование» — «Параметры» — «Name Resolution». Далее надо поставить галочки на: «Resolve MAC addresses», «Resolve transport names», «Resolve network (IP) addresses» и «Use an external network name resolver».

Теперь наш компьютер захватывает все пакеты. Параллельно этому процессу будем настраивать фильтры.

В поле фильтра введем tcp. Если кто-то подключен к нашей сети, то пойдет много пакетов. И отправитель и получатель будет представлен в виде IP адреса, но IP сайтов Wireshark будет превращать в читабельные имена (например, google.com), а IP тех, кто подключен к сети будут, как правило, похожи на Ваш (Ваш можно узнать через тот же ifconfig). Если нас заинтересует какой-то конкретный клиент сети, то фильтр стоит изменить на tcp and ip.src == x.x.x.x, где x.x.x.x — заинтересовавший нас клиент. Таким образом, можно полностью просматривать с какими сайтами общаются клиенты сети.

Помимо этого, в Wireshark есть еще очень много функционала, но к счастью большая часть этого функционала (среди них воровство логинов и паролей, просмотр медиа и т.д.) работает только на устаревшем http, когда почти весь Интернет перешел уже на шифрованный https, где получить данные пакетов, практически, невозможно.

В качестве защиты можно использовать привычные средства вроде Tor или VPN.

Спасибо за чтение.


ссылка на оригинал статьи https://habr.com/ru/post/647103/

Гость из прошлого


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

Давным-давно, в 2005 году я купил себе Abbyy Lingvo CE. В то время я был заядлым Windows Mobile пользователем. Я сменил Qtek 2020i на самый первый HTC Touch, а чуть позже, ввиду получения новой работы решил побаловать себя абсолютно безобразно крутым телефоном и купил себе HTC Touch Pro. В лингву были залиты разношёрстные словари, и она долго была моим компаньоном в изучении языка. Но к 2010 году стало ясно, что платформе не быть, и, несмотря на все мои попытки сего факта не признать, я пересел на iPhone, а потом и на Android.

Пару лет назад я искал что-то на eBay и абсолютно случайно напоролся на это чудо. При цене в 3000 рублей, девайс казался прекрасной игрушкой, которую я и купил. И вот так, в 2022 году я стал владельцем одного из последних Windows Mobile 6 устройств.

Добро пожаловать под кат, где мы сравним HTC Touch Pro 2 и Samsung Galaxy S21 Ultra, померяемся камерами и проведём конкурс “Кто запустит лучший порт Героев”.

И так, для начала немного истории. Давным-давно, практически за бесценок, в 2002 году я выменял у друга Palm IIIxe.

Девайс хоть и был немного туповатым (Процессор на 16 мегагерц, 8 мегабайт памяти и чёрно-белый экран 160х160 пикселей), но, несмотря на свою простоту, доставлял кудосы гигабайтами. Помимо бесполезных организаторов и записных книжек, я научился устанавливать на него нужный софт. Читалка книжек стала просто must-have, и я коротал поездки в метро, зачитываясь старыми выпусками издательства МИР.

Кстати, сказать по-честному, я купил Kindle Paperwhite только потому, что он чувствовался так же, как Palm IIIxe. Было что-то неимоверно приятное, что маленький монохромный дисплей мог доставить бессчётные часы удовольствия.

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

Университетские пары (особенно “философия”, которую непонятно зачем преподавали программистам) проходили намного быстрее, когда мы с друзьями сидели и пытались разобрать завал на парковке. К сожалению, я не смог вспомнить название оригинальной игры, и не смог найти её упоминания на гугле. Но вот это похоже на то, во что мы играли. Понятное дело, всё было чёрно-белым и умещалось на экране размером в 160 на 160. (Кстати, привет Lesatik и mayorova, помните? Сколько на это было убито часов?)

Да, Палм был удобным и весёлым дополнением к мобильному телефону. Мой самый первый Siеmens A35 сменил Siemens A50, а после этого я присоединился к клубу любителей неубиваемых телефонов. В связи с поступлением в университет, родители подарили мне Nokia 6610. Тогда Palm был отличным дополнением к простым телефонам с маленькими экранами. Кстати, замечу, что 6610 привнёс в жизнь мультиплеерных игрушек замечательную Змейку. Нет ничего более проработанного, чем Змейка на Нокиях. Самое удачное сочетание скорости рендеринга и реакции контролов. Опять игра на время и очки среди народа в институтской группе.

Но на втором курсе я стал счастливым обладателем Nokia 6600. Этот 122 граммовый монстр был оснащён экраном в 176 на 208 пикселей, камерой на 0.3 мегапикселя, 32 мегабайтами оперативной памяти и процессором на 108 мегагерц. По сравнению с Palm — этот девайс выигрывал во всём. Что самое главное, когда у него заканчивался заряд, то он, в отличие от монохромного цуцика, не сбрасывал содержимое памяти. Так что, можно сказать, это был большой прогресс.

Более того, в те стародавние времена, весь мир делился на несколько лагерей. Были Нокии, были Сони-Эриксоны и Моторолы. Был весьма актуальным вопрос, какую модель выбрать, чтобы зарядка совпадала с зарядками твоих лучших друзей. А эта Нокия питалась от стандартной “тоненькой” Нокиевой зарядки, которых повсюду было пруд пруди.

Но на этом достоинства Нокии не заканчивались. Она могла делать невероятные вещи. При наличии достаточного упорства, на ней можно было запускать 3D-игрушки. Ведь эта Нокия несла в себе точную копию начинки из Nokia NGage. Одного из первых игровых телефонов в мире.

Вот, например, прохождение Tomb Rider на NGage.

Основная разница у этих двух моделей заключалась в том, что в NGage был установлен D-Pad в качестве основного контрола, а в 6600 его заменили на джойстик. И играть на этом джойстике было более чем неудобно.

Посему я ограничился установкой кучи читалок для книг, аськи и невероятного в то время приложения “MP3 Плеер”. Я мог слушать один из пяти музыкальных альбомов на выбор! В невероятном качестве в 128 килобит в секунду.

Кстати, Аська. Кто из вас всё ещё помнит, сколько раз и какую надо было нажать клавишу телефона, чтобы получить букву Ш? Ага, вот вам и Т9.

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

Я был завсегдатаем www.xda-developers.com, 4pda.to и www.ladoshki.com. Что самое интересное, все три сайта всё ещё продолжают работать. И если Ladoshki не обновлялся с 2015 года (кстати, зайдите на него с 4к монитора, посмейтесь), то xda и 4pda сумели перейти на iPhone и Android. Но при этом сохранили старые ламповые посты о КПК на базе Windows Mobile.

Начитавшись обзоров и рассказов о новых коммуникаторах, я вбил себе в голову, что я просто обязан стать обладателем QTek 9090. Ввиду наступления Нового года, моя мама решила обречь меня на смертельную пытку. Я был взят консультантом в поход на Горбушку, с целью покупки подарков родственникам. Никак иначе, как издевательством, такое не назовёшь. Мне предстояло бродить по Горбушке и выбирать нужные версии DVD плееров или носить сумки с подарками. Горбушка, КАРЛ! Место, где я проводил часы, рассматривая телефонные павильоны или рыща по каталогам доступного программного обеспечения. Не очень помню, как мы пришли в один из таких “мобильных” павильонов, но я просто был в шоке, когда моя мама сказала мне “выбирай”.

И тут я с ужасом обнаружил, что 9090 на прилавках отсутствует. Но мой взгляд упал на QTek 2020i. Отсутствие встроенной клавиатуры компенсировалось немного более мощным процессором и удвоенным размером памяти.

Так в начале 2005 года я начал своё путешествие в мире Windows Mobile. И я знаю, что я уже опоздал. К тому времени ОС добралась до версии 5. Первопроходцы с HP iPaq уже сделали много тестов и написали бесконечное количество софта. Мне нужно было только идти и выбирать. Но Кутек был не просто наладонником. Хороший GSM модуль позволил мне пользоваться им как настоящим телефоном и получить доступ в прекрасный мир 3G.

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

Parking Lot был сменён на Bubble Braker. Каждый раз я неохотно отдавал свой девайс друзьям, потому что я боялся получить его обратно с побитым рекордом.

Я не знаю, почему эта игра была такой увлекательной. Как бы то ни было, десятки (если не сотни) часов моей жизни ушли на лопанье шариков.

Но и на этом игровая индустрия в мире Windows Mobile не заканчивалась. Отсутствие видеоускорителей и не особо внушительные параметры встроенной графики делали разработку 3D игр на девайсах достаточно занудным занятием. Более того, разные девайсы имели разное разрешение. Это дополнительно усложняло разработку. Одним из стандартных разрешений было 320×240. Некоторые девайсы радовали глаз удвоенным 640х480. А последние девайсы эпохи красовались с 480х800. И если первые два разрешения “лечились” удвоением размера элементов на экране, то последнее изменяло соотношение сторон и ломало приличное количество софта.

В те времена это было проблемой. Сегодня мобильные разработчики просто посмеются над подобными проблемами. Подумаешь, три разных разрешения экрана? Сейчас любой нормальный андроидщик без вопросов назовёт более дюжины “стандартных” разрешений.

Как бы то ни было, игры были.

Одной из самых увлекательных была портированная версия X-COM UFO

Умельцы с xda-developers запускали StarCraft и WarCraft.

Ну и в те прекрасные времена без Worms World Party девайс с собой можно было не таскать.

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

Эту программу вспомнят почти все, кто любил смотреть сериалы на наладонниках. (Кстати, именно так и тогда я посмотрел все 13 сезонов Симпсонов и всю Футураму на английском, с целью улучшить понимания языка и набрать словарный запас. Что самое интересное, это помогло)

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

Браузером по умолчанию всегда была Opera Mobile. Интернет по 3G (А для менее удачливых по 2G) был жутко дорогим, и платить приходилось за мегабайты. На моём билайновском плане мне полагались невероятные 50 мегабайт в месяц. За дополнительное использование приходилось доплачивать.

Самим браузером на телефоне приходилось пользоваться достаточно редко. В основном из-за цен на трафик. Плюс, в те времена не существовало mobile-first дизайна. И только-только люди начинали говорить об “эластичном дизайне”. На самых крутых сайтах вы получали автоматический редирект на мобильную версию. Менее крутые просто предлагали мобильную версию, на которую надо было ходить по ссылке. А так, приходилось сидеть и пытаться ткнуть стилусом в миниатюрную кнопку на экране. Браузинг был не особо удобным.

Кто мог себе представить жизнь в те времена без красивого асечного шестизнака? 996121. Как сейчас помню. Выиграл его в конкурсе на pcforum.ru ещё в 2004 году. Кажется, у меня его увели в 2009, но, к тому времени все пересели на мессенджеры, ВК и Скайп. Зато в ламповом 2005 году без QIP работать было нельзя. Аська не жрала много ресурсов и была очень экономной по сети. Была куплена раскладная блютус клавиатура, и чат был нескончаемым.

Зато мобильные платформы получили много читалок.

Без Haali Reader девайс был практически бесполезным. Читалка была запущена постоянно. (Только в моём случае это всегда был чёрный экран с буквами бежевого цвета).

Ну и, конечно же, читать можно было не только бесконечные коллекции FB2 книг.

RSS был очень востребованной технологией. В далёком 2005 году наличие Wi-Fi в доме позволяло синхронизировать фиды на девайс и читать их, путешествуя в метро.

И всё вышеописанное — это только часть огромного наследия Windows Mobile 6. Это были последние годы блистательного софта и уютной инфраструктуры. 29 июня 2007 года Стив Джобс представил миру три новых девайса. Новый айпод с тач-интерфейсом, телефон и персональный компьютер. Все три девайса были собраны в одном устройстве под названием iPhone.

Palm уже тогда перестал быть популярной платформой. А Windows Mobile получила серьёзный удар. Практически монополист в мире коммуникаторов сдал позиции новой платформе за 2 года.

Всё, что было выпущено после этой даты, было просто попыткой удержать рынок.

В Июне 2007 года на рынок вышел HTC Touch, который сменил для меня Qtek 2020i. Сам по себе девайс был размером с Motorola Razr. Несмотря на намного меньший экран, девайс обладал более шустрым процессором. Более того, это был первый Windows Mobile коммуникатор с экраном, не утопленным в корпус устройства. Стекло и диджитайзер были установлены вровень с корпусом. В то время устройство было достойным “ответом” iPhone. Ибо в те далёкие времена в iPhone не существовало магазина приложений, и девайс был просто красивой игрушкой. Зато Touch имел хорошую поддержку большого количества приложений и постепенно вводил Windows Mobile в мир Touch интерфейсов. Сама ОС была допилена для поддержки жестов пальцами.

Но, как бы то ни было, девайс был оснащён стилусом. Windows Mobile просто не могла делать полный Touch интерфейс. Старый софт и клавиатуры просто не работали хорошо. Более того, сама конструкция экранов в первую очередь была создана для работы со стилусом. Экраны на конденсаторах придумали немного позже.

Ещё через пару лет, когда iPhone обзавёлся AppStore, а Google решила не оставаться в стороне и выпустила первую версию Android, я, уже больше просто из упорства, купил себе HTC Touch Pro.

Девайс обладал экраном с разрешением 640×480 и поставлялся со встроенной оболочкой Touch Flo. Это была последняя попытка HTC остаться на рынке Windows Mobile устройств. Более того, в отличие от большинства Андроидов и всех iPhone, девайс обладал встроенной клавиатурой.

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

Последними коммуникаторами HTC на платформе Windows Mobile были HTC Touch Pro 2 и HTC HD2, выпущенные в 2009 году.

Оба девайса обладали экраном с разрешением 480х800, ибо меньше было бесполезно. К тому времени iPhone и Андроид уже задрали планку.

Более того, HTC HD2 был просто гигантским, в сравнении с любыми другим устройствами Windows Mobile. Экран в 4.3 дюйма чувствовался просто нереально огромным. (Да, конечно, они не могли тогда представить, что кто-то захочет взять в руки семидюймового гиганта, такого как iPhone 13 MAX или S21 Ultra)

Но, все эти попытки были бесполезными. В 2008 году свет увидели Apple App Store и Google Play Store. Именно они обосновали победу платформ. Для Windows Mobile централизованных магазинов просто не существовало.

Все попытки выпустить Windows Mobile 7, 8 и 10, а также попытки Стива Балмера совместить Windows для компьютеров и мобильников не увенчались успехом. Но то были другие времена и другая платформа.

А я в 2010 году сдал все свои позиции и перешёл на iPhone. Достаточно быстро я понял, что совершил ошибку, и к 2012 году я уже сидел на Samsung. А начиная с 2015 года я перепробовал практически все Samsung Galaxy S телефоны.

И вот недавно, я искал что-то на eBay. И внезапно увидел ужасно знакомую картинку. Всего лишь за 3000 рублей я мог купить абсолютно новый HTC Touch Pro 2. В своё время за его младшего брата в 2008 году я отдал 33000. It’s a deal, it’s a steal, it’s a sale of a f***ing century. Берём, заворачивайте! В итоге через неделю у меня в руках появилось вот это чудо:

Машина была залочена под уже несуществующего американского провайдера Sprint, но меня это интересовало мало. Главное, что железо работало, и всё запускалось. Более того, целую неделю девайс провалялся в столе, потому что пришлось покупать mini-usb кабель, которого нигде уже днём с огнём не сыщешь.

Экран раскладывался как полагается и всё отлично работало. Пора включать!

Никак не мог не порадовать тот факт, что девайс просто включился. В те далёкие времена 2009 года Bloatware только начинало набирать обороты. За исключением пары программ для мониторинга счёта провайдера, машинка не несла в себе бесконечных мегабайт ненужностей.

Встроенной памяти у нас на борту — невероятных полгигабайта! Этого хватало на очень большое количество всего, что только можно. Можно было таскать с собой аж 20 любимых альбомов с музыкой в MP3, несколько серий любимого сериала, пару игрушек и практически бесконечное количество книг.

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

Естественно, первым делом мне захотелось запихнуть туда какие-нибудь из своих старых программ.

И Герои запустились прямо сразу. Русская версия этой программы всё ещё доступна на Ладошках (В отличие от английской версии, русская работает на халяву и не просит регистрации). Она запускается с полпинка и отлично работает на новомодном разрешении экрана. Конечно же, есть свои приколы. Программа развёрнута “вверх ногами” по отношению к клавиатуре. И если вы откроете клавиатуру, то девайс пошлёт ОС сигнал о необходимости развернуть экран, и герои крашнутся не хуже, чем Windows 95, у которой из-под рук забрали CD диск.

Но на самом деле, игрушка меня интересовала мало. (Я потратил на неё всего-то 100 часов. Фейспалм).

Конечно же, HTC Touch Pro и Pro 2 были одними из первых Windows Mobile телефонов с датчиком положения. Нельзя пропустить очень крутую и необычную по тем временам игрушку Teeter.

Я подключил девайс к вайфаю, и он заработал. Но толку от этого было мало. Все сертификаты давно устарели, и открыть ничего не получалось. Я залез на единственный не-HTTPS сайт, который я знаю. taco.com. Отобразился в Опере, как и полагается. Практически нечитаемый и очень маленький. Но, таков был он — 251 мобильных устройств 2009 года.

Ладно, баловаться бабл-брейкерами и героями — это так, фигня. На самом деле у меня была идея о том, что делать с этим аппаратом. Когда у меня ещё был Qtek 2020i, я купил себе лицензию на Abby Lingvo Mobile с поддержкой кучи словарей. Лицензионный ключ и словари были забыты в глубинах Google Drive на многие годы. Но они сохранились.

Я решил, что пришла пора расчехлить 15-ти летний файл с ключом и скачать Abby Lingvo Mobile. К сожалению, установщика на Ладошках не было, а сам сайт Abby ссылается на новомодные Android и iOS версии.

И тут я сделал что-то, чего Abby от меня не ожидали. Я им написал в техподдержку. И попросил помочь мне найти установщик к программе. Не знаю, как бы отреагировали ваши сотрудники техподдержки, если бы к ним пришли с запросом на ПО, которое уже лет как 15 не поддерживается, но Abbyy ответили достойно.

Уже неизвестный инженер посмотрел на мой ключ и выдал мне прямую ссылку на скачивание лицензионного файла. За что я ему благодарен. Мне наконец-то удалось установить свой любимый словарь.

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

Не мог обойти стороной камеру. Вот сравнение снимков моего Samsung Galaxy S21 Ultra и HTC Touch Pro.

Фотки с камер двух девайсов для сравнения

Фоткаем один девайс другим девайсом.

Фоткаем пальму в отдалении

Фоткаем каку на очень старой клавиатуре, в приближении

Фоткаем лампочку, чтобы показать, как хорошо девайс справляется с HDR

Кстати, отвечая на вопрос, какой девайс запустит лучший порт героев: HTC Touch Pro 2. Просто потому, что я предвзятый донельзя. Но если кто-то хочет похвастаться своими достижениями в комментах, то прошу.

Девайс приятно лежит в руке. Нажатие на физические кнопки вызывает неподдельный восторг, а народ вокруг тянется и просит поиграться.

Как я сказал ранее, Windows Mobile не смогла тягаться с Google и Apple. Но, HTC HD2 оставался в строю очень долго. Девайсы были не заблокированы и легко поддавались модификациям. Я запускал линукс ещё на Qtek 2020i. А на последнем флагмане умудрились запустить все Андроиды вплоть до версии 7. Это был последний вздох девайсов из уходящей эпохи.

Хотя последний из Windows Mobile нашёл своё место в гиковском 2022 году и всё ещё живёт. Он доставляет немало удовольствия и является поводом для весёлых разговоров и воспоминаний. А также очень удобен, когда мне надо заглянуть в словарь.

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


ссылка на оригинал статьи https://habr.com/ru/company/ruvds/blog/645905/

Кто трусы ребятам шьёт? Ну конечно, не пилот

Лётчик водит самолёты —
Это очень хорошо.

Повар делает компоты —
Это тоже хорошо.

Доктор лечит нас от кори,
Есть учительница в школе.

Ну а ваш покорный слуга сам не знает, чем он занимается и полезен ли он человечеству.

Есть профессии, как я бы сказал на нашем айтишном языке, с нулевым level of indirection. Тот же повар, который делает компоты, сразу и непосредственно делает людям хорошо. И может видеть их улыбки и иногда слышать слово ‘спасибо‘.

Давайте я попытаюсь изложить, чем занимаюсь я сам.

  1. На нулевом уровне кто-то шьет ребятам трусы

  2. Это бизнес, там есть бухгалтера, управляющие итд.

  3. На западе деньги скорее всего с рынка акций

  4. Частники, как правило, вкладываются в акции через прокладки из hedge funds

  5. Hedge funds используют хостинг и софт фирмы, где я работаю

  6. Если возникают performance problems, то зовут меня как гуру помогать

То есть я изолирован от пошива трусов пятью уровнями. Если bus factor — меня собьет автобус, то будет хуже на уровне 5, можно даже включить свое ЧСВ на максимум и представить, что из-за этого отвалится один из многочисленных hedge funds, но вот абсолютно точно можно быть уверенным, что количество пошитых для ребят трусов не уменьшится!

Но тогда что я вообще делаю?

Неудивительно, что я очень люблю смотреть передачу на Discovery ‘Золотая лихорадка’. Здоровые мужики на свежем воздухе добывают золото. Результат их труда можно пожамкать в потных ладошках, сжать его. А я при знакомстве на вопрос, чем занимаюсь, мычу что-то неопределенное.

А ваша деятельность отделена от людей сколькими уровнями?

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Как далеко вы от непосредственной пользы людям?
17.54% 0 — непосредственная польза 10
8.77% 1 5
10.53% 2 6
19.3% 3 11
8.77% 4 5
7.02% 5 4
28.07% больше 5 16
Проголосовали 57 пользователей. Воздержались 8 пользователей.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
И по этому поводу
21.15% Я парюсь 11
78.85% Я не парюсь 41
Проголосовали 52 пользователя. Воздержались 4 пользователя.

ссылка на оригинал статьи https://habr.com/ru/post/646957/