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

"Развёртывание ЛВС здания - начинается с СКС" #2

В продолжение https://habr.com/ru/posts/803943/

Подписывается договор с ген.проектировщиком.
Положения ТЗ, согласованные с Заказчиком, отстаиваются перед очами ген.проектировщика (например, традиционная фишка - помещений на всех не хватает, а тут какие-то непонятные "кроссовые" на каждом этаже. Какие нафиг кроссовые, когда нам швабры хранить негде?! Ибо помещения для хранения уборочного инвентаря - штука обязательная и экспертиза к ним прицепится. А вот по кроссовым - не всё так однозначно. Приходится вести разъяснительную работу :)

Разрабатываются тома проектной документации. Потом ещё несколько раз переделываются вслед за изменениями архитектуры/планировок.

Всё это идёт на гос.экспертизу. Устраняются замечания в проектной документации. Ген.проектировщиком - получается положительное заключение экспертизы.

Ген.подрядчик - получает разрешение на строительство.

С ним заключается договор на монтаж (и, возможно - и поставку оборудования ЛВС).

Делается рабочая документация. Получается штамп "в производство работ".

Можно выходить на Объект.

«Развёртывание ЛВС здания — начинается с проектирования и строительства СКС» #1

По мотивам обдумывания проблем, затронутых в публикации https://habr.com/ru/companies/k2tech/articles/803 585/ у меня накидались данные заметки

Я, как руководитель системного интегратора — ОЧЕНЬ люблю, когда мы можем придти в белых перчатках на законченную стройку, где проведёна финишная уборка, и расставить сервера с коммутаторами...

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

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

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

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

Вначале согласуется с ИТ департаментом заказчика Тех.Задание.
Потом оно же согласуется с хоз.отделом (или ОКС'ом) заказчика.

Подписывается договор с ген.проектировщиком.

И начинается этап проектирования :)

Финансовые и нефинансовые системы мотивации

Это главные тезисы доклада Андрея Рыжкина, консультанта AGIMA, с митапа «TeamLead: Как управлять командой разработки и качеством на проекте». Мы подготовили серию таких постов, и сегодня делимся первым.

Профессиональная мотивация соотносится с уровнями пирамиды потребностей Маслоу, известной нам еще со школы:

Для мотивации на каждом уровне можно использовать финансовые и нефинансовые инструменты. И вот какие.

1. Физиологические потребности

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

?Нефинансовые инструменты: нет переработок и проблем с рабочим местом. Если работать приходится 24/7 — нет времени на сон и остальную жизнь. Мотивация падает.

2. Защищенность

? Стабильная зарплата. Не придется брать в долг, волноваться о регулярных платежах, и в итоге — поменять работу.
? Заботливый руководитель, отсутствие постоянного стресса, вежливые коллеги и комфортный офис.

3. Принадлежность

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

4. Уважение

? Индивидуальные премии.
? Авторитет в компании, карьерный рост, корпоративные подарки.

5. Самоактуализация

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

Фонд развития интернет-инициатив (ФРИИ) совместно с Минцифры запустил новую акселерационную программу «Драйвер».

«Драйвер» — это интенсивный курс развития продуктовых команд, работающих в приоритетных технологических направлениях, прежде всего, в сфере замещения зарубежного ПО и развития прорывных технологий. Участие в проекте бесплатное.

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

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

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

Для участия в программе проекту нужна рекомендация от ИЦК или ЦКР и (или) наличие сведений о проекте в перечне особо значимых проектов, дорожных картах нового общесистемного программного обеспечения и индустриального программного обеспечения. Заявки на участие в проекте «Драйвер» принимаются до 21 апреля.

В ответ на изменение лицензии на СУБД Redis создан форк, который будет распространяться под именем Redict и продолжит развитие кодовой базы, соответствующей выпуску Redis 7.2.4, последнему под лицензией BSD.

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

Форк основал Дрю ДеВолт (Drew DeVault), автор пользовательского окружения Sway, языка программирования Hare, почтового клиента Aerc и платформы совместной разработки SourceHut.

К работе над форком Redis присоединился Хельвенн Моннье (Haelwenn Monnier), автор браузера BadWolf (на базе WebKitGTK) и платформы Pleroma для развёртывания федеративных социальных сетей.

Лицензия на код Redict изменена с BSD на GPLv3. Проект Redict сможет переносить исправления, публикуемые для старых версий Redis под лицензией BSD, но исправления и изменения, созданные для Redict под лицензией GPLv3, не получится перенести в Redis.

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

Источник: OpenNET.

Новый руководитель команды Williams «Формулы-1» Джеймс Воулз обнаружил, что руководители различных служб несколько лет использовали файл Excel с таблицей из более чем 20 тыс. строк, в которых указаны все необходимые для проектирования и сборки болида автомобильные запчасти и детали.

«Невозможно ориентироваться и невозможно что-то обновить. В этом колоссальном файле Excel не было информации о том, сколько стоит каждая из этих деталей и сколько времени потребовалось на их производство, а также о том, были ли эти детали уже заказаны. Определение приоритета одной секции автомобиля над другой, от производства до проверки, было невозможным», — пояснил Воулз.

В итоге он решил перейти на новые процессы и системы управления, избавившись от Microsoft Excel.

«Когда вы сейчас начинаете отслеживать сотни тысяч компонентов, перемещающихся по вашей организации, таблица Excel становится бесполезной. Из-за множества состояний, в которых каждая деталь может быть заказана, отложена в заказе, проверена, возвращена, людям часто приходится прорабатывать детали. И как только вы начнёте повышать этот уровень сложности, на котором находится современная "Формула-1", электронная таблица Excel рушится, и проекты падают. И это именно то, где мы находились некоторое время, так как РП доводили себя до абсолютных пределов и ломались», — добавил Воулз.

В 2017 году электронная таблица Excel для проектирования и сборки Renault Sport Formula One имела 77 тыс. строк. В компании также ушли от этого решения.

Вы наверняка знаете про HADI-циклы — фреймворк базовый и много где применяется. Есть альтернатива: бесполезный для продукта, но очень весёлый DDDD-цикл.

В DDDD-цикл легко попасть во время первого HADI-цикла: в начале («нам недостаточно данных, чтобы выдвинуть первые гипотезы») или в конце («нам недостаточно данных, чтобы сделать однозначные выводы по гипотезам»).

Некоторые команды могут жить в DDDD-цикле годами, потому что совершать ошибки страшно, а исследования обещают уверенность. В англоязычных интернетах это состояние называют analysis paralysis. Справедливости ради, существует обратное и не менее опасное состояние — extinct by instinct. Но такие команды в DDDD-циклы не попадают, поэтому сегодня не о них.

Как я сам оказывался в DDDD-циклах:

• Начинал первый HADI-цикл с D. Когда проводил свои первые исследования, часто выходил на кастдевы без чётко сформулированных предположений, просто пообщаться. Без контроля со стороны это тоже прямой путь в DDDD-цикл. Безопаснее начинать с гипотез — данные нам нужны только для их проверки.

• Не ограничивал время на исследование. В итоге они длились бесконечно. Поставьте любой срок: день, два, неделя. Главное, быть честным с собой и принять решение вовремя.

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

Главные навыки управленца: решайте кейсы, чтобы узнать свой уровень

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

У теста есть три варианта, которые отличаются по времени и количеству проверяемых навыков: 

→ Тимлид — 36 минут: критическое мышление, стратегическое мышление, аргументация, управление командой

→ Продакт-менеджер — 45 минут: управление продуктом, принятие решений на основе данных, критическое мышление, аргументация, юнит-экономика

→ Мегалид — 1 час: проектное управление, юнит-экономика, критическое мышление, стратегическое мышление, аргументация, управление продуктом, принятие решений на основе данных, управление командой

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

→ Пройти тест

МТС внедрила новую систему мониторинга качества работы сетевой инфраструктуры, которая отличается от прошлой версии автоматизированным функционалом, большей производительностью и масштабом. Эта система собирает в режиме реального времени информацию о состоянии оборудования и обрабатывает данные с помощью ИИ, повышая стабильность и надёжность работы IT-инфраструктуры компании.

Система мониторинга Network Performance Monitoring (NPM) собственной разработки МТС позволяет целостно в интервале от 1 секунды до 5 минут оценить работоспособность различных компонентов инфраструктуры: транспортной, региональной и магистральной, сетей, коммутаторов, ЦОДов, сервиса контроля качества IP-ТВ, систем электропитания оборудования и датчиков температуры.

Автоматизированный сбор показателей с сайтов МТС по всей стране и анализ многочисленных метрик на основе технологии машинного обучения даёт возможность NPM оперативно выявлять и предупреждать возможные сбои в работе сети, которые способны повлиять на качество услуг и сервисов экосистемы оператора связи.

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

Сервис «МТС Линк» предложил специальные условия для российских компаний, которые ранее использовали платформу Microsoft Teams и могут с 20 марта потерять доступ к этому решению. В «МТС Линк» обещают, что переход на российскую цифровую экосистему может пройти бесшовно и с минимальными затратами.

Пользователи, которые переведут бизнес-коммуникации с MS Teams на «МТС Линк» до конца апреля, получат следующие возможности:

• бесплатный доступ к новому корпоративному мессенджеру «МТС Линк Чаты» до конца 2024 года. Возможности сервиса позволяют общаться с коллегами в группах, каналах и один на один, делиться файлами, проводить индивидуальные и групповые звонки;

• бесплатный доступ к сервису «Доски» от «МТС Линк», который подойдёт для мозговых штурмов в онлайн‑ и гибридном формате, встреч по планированию, создания диаграмм и таблиц;

• при подключении годового тарифа клиенты MS Teams — дополнительные три месяца использования сервисов «МТС Линк» (видеоконференции с подключением до 200 человек и вебинары с 5000 участников);

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

«Переход на новое ПО — это сложный процесс, особенно в крупных компаниях, которые продолжают пользоваться сервисами Microsoft Teams, даже несмотря на риск отключения. Сейчас, когда отказ от привычных приложений станет вынужденной мерой, мы готовы оказать бизнесу всю необходимую поддержку для сохранения непрерывности бизнес‑процессов», — пояснил Хабру исполнительный директор «МТС Линк» Павел Потехин.

Что такое матрица компетенций и зачем она нужна

Матрица компетенций (МК) — инструмент управления рисками. Она помогает распределять ресурсы, определять грейды спецов и мотивировать команду.

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

Например, у вас работают три человека. Каждый должен уметь верстать (навык 1), дизайнить (навык 2) и вести переговоры (навык 3). Судя по МК из нашего примера, Дарья не очень хорошая верстальщица, зато хороший дизайнер и менеджер. Михаил тоже поможет с дизайном, но в нашем случае ему мы доверим верстку. Таким образом МК показывает реальную расстановку сил в коллективе.

Как использовать МК:

• МК помогает сбалансировать навыки в команде. По таблице вы поймете, что ваша команда делает хорошо, а что плохо. В соответствии с этим вы будете выбирать проекты, набирать команду или обучать коллег.

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

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

Как оценивать навыки для МК, как ее составлять и как с ее помощью распределять ресурсы внутри компании, рассказываем в отдельной статье. А больше про управление командой разработки — в телеграм-канале для тимлидов.

Идеальная продуктовая команда

Пост про идеальный состав продуктовой команды. Но сперва давайте выясним, а нужна ли вам она вообще?

Мы считаем команду продуктовой, если:

• она работает над одним продуктом/его частью;

• можно прогнозировать работу команды;

• она имеет необходимые компетенции для запуска продукта и его развития;

• она стремится к самоорганизации.

Такая команда вам не нужна, если:

• Ваша компания бюрократизирована. Согласовать изменения — это как пройти через все круги ада. А задачи появляются и приоритизируются, потому что «так сказали сделать наверху».

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

• Ваш продукт — это пока неподтвержденная гипотеза. Только ПОСЛЕ ее валидации стоит собирать Product-команду, ДО — рановато.

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

Вот базис продуктовой команды:

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

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

Подробнее об этом поговорим на онлайн-митапе «Как разрабатывать продуктовую стратегию» 29 марта в 18:00. Детали и регистрация тут.

Выбираем продуктовые метрики на примере мобильного приложения для грузоперевозок

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

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

2. «Разбиваем» процесс взаимодействия с приложением на ключевые этапы: регистрация, размещение заказа, поиск перевозчика, выполнение заказа и т. д.

3. Определяем метрики на каждом этапе через призму эффективности каждого. Например:

• Регистрация и активация. Здесь смотрим на количество новых установок приложения, процент завершенных регистраций и активаций учеток и т. п.

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

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

Выбор метрик — процесс итеративный, и менять их — это норма ©. Если это поможет более эффективному измерению успеха продукта.

Больше об этом в нашем тг-канале.

Адаптация в новой бизнес-отрасли по Фейнману

Быстрое погружение в новую предметную область — необходимый скилл продакта в агентстве. Делимся классной методикой дип-дайва в контекст продукта. Ее автор — Ричард Фейнман.

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

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

3. Объясняем ребенку
   
   Представьте, что вам нужно рассказать про новую предметную область десятилетнему ребенку. Придется отбросить сложную терминологию и объяснить всё кратко — у детей невысокая концентрация внимания. Если гипотетический ребенок вас поймет, вы разобрались в теме.

4. Рассказываем историю
   
   Объединяем свои записи в одну историю, переходим от простого к более сложному и раскрываем основную идею. Помним про простоту и краткость, но метафоры и примеры тоже пригодятся. Можно сделать аудиозапись своего рассказа и прослушать ее. Стоит обратить внимание на неоднозначные формулировки и на эпизоды, где вы сбиваетесь. Это маркеры тех мест, которые нужно проработать.

Метод Фейнмана несложный, полезный и универсальный. Так что, рекомендуем.

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

В конце февраля 2024 года организация HDMI Forum отклонила запрос разработчиков из AMD по поводу поддержки драйверов HDMI 2.1+ с открытым исходным кодом.

Одним из ограничений графического драйвера AMD для Linux с открытым исходным кодом является невозможность реализовать функциональность спецификации HDMI 2.1+ на основании юридических требований HDMI Forum.

Инженеры AMD вместе с HDMI Forum продолжительное время работали над решением, которое позволило бы обеспечить возможности стандарта HDMI 2.1+ с помощью драйвера ядра Linux с открытым исходным кодом.

В течение трёх лет многие пользователи сталкивались с ошибкой, связанной с недоступностью разрешения 4K с частотой 120 Гц при подключении HDMI 2.1 в драйвере AMD Linux. Такие же проблемы были у пользователей при попытке работать с разрешением 5K при частоте 240 Гц.  

Инженеры из команды AMD совместно с юристами компании изучили и оценили все функции HDMI, чтобы определить, можно ли как‑то реализовать их в драйвере с открытым исходным кодом. Последние несколько месяцев AMD ждала одобрения от HDMI Forum. Потом пришёл ответ, что запрос отклонён.

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

Разработчики сообщества Open Source столкнулись с потоком спам-запросов Pull Request на их проекты с открытым исходным кодом от пользователей платформы tea.xyz.

В tea.xyz обещают пользователям, что они смогут «получить вознаграждение за их вклад в открытый исходный код». Эта платформа описывает свою цель, как «повысить устойчивость программного обеспечения с открытым исходным кодом».

Пока что tea.xyz удалось добиться прямо противоположного. Пообещав вознаградить участников с открытым исходным кодом криптотокенами, проект попросил пользователей подтвердить свой доступ к проектам с открытым исходным кодом, объединив файл YAML, содержащий адрес их криптокошелька. Это вызвало поток запросов на включение в известные, часто не связанные с криптовалютой проекты с открытым исходным кодом от пользователей, которые никогда не участвовали в проекте (или, часто, в каком-либо проекте с открытым исходным кодом), но которые хотели объединить их в файл с описанием, как «владелец кода».

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

Путь к успешному продукту: User-Centric Thinking

Подход User-Centric Thinking предполагает, что продукты создают и совершенствуют с учетом реальных потребностей и ожиданий пользователей.

Почему это важно?

• Увеличение лояльности
  
  Логичная цепочка: у пользователей была проблема → ваш продукт ее решил → вы получили лояльных пользователей.

• Снижение рисков
  
  Чем больше мнений пользователей вы соберете, тем ниже риск создать невостребованный продукт.

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

Давайте проверим, насколько вы User-Centric :)

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

✔ Создание персон — подробное описание вашей целевой аудитории (персоны), включая их демографические данные, потребности, цели и проблемы. Такие персоны помогают команде продукта лучше понять своих пользователей.

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

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

Больше о разработке цифровых продуктов — в нашем телеграм-канале.

"Самые большие гранты: исследовательские проекты, изменяющие мир ".

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

1. Гранты Российского научного фонда (РНФ): РНФ финансирует фундаментальные научные исследования в России. Он представляет собой крупную грантовую программу, осуществляемую государственным фондом с целью финансирования фундаментальных исследований в России. Более подробную информацию о грантах РНФ можно найти на их ​​официальном сайте: https://rscf.ru/

2. Гранты Российского фонда фундаментальных исследований (РФФИ): РФФИ также финансирует фундаментальные научные исследования в России. Более подробная информация о грантах РФФИ доступна на их ​​официальном сайте: https://www.rfbr.ru/

3. Гранты Президента Российской Федерации для поддержки молодых ученых исследователей: Эта программа предоставляет гранты молодым ученым и исследователям на начальном этапе их карьеры. Подробности о грантах доступны на сайте: https://grants.rs.gov.ru

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

• Телеграм-канал

• Бот для скачивания статей

Российская компания EKF первой в стране разработала и внедрила собственную облачную платформу промышленного интернета вещей EKF Connect Industry.

По расчетам EKF, использование их сервиса помогает увеличить производительность технологического оборудования от 7% до 15%, снизить затраты на энергопотребление на 10-15% уже в первый год с последующим снижением этого показателя еще на 3-5%.

Платформа промышленного интернета вещей EKF Connect Industry работает в облаке «Яндекса». Сейчас новый сервис проходит опытную эксплуатацию на собственных производствах и более чем в десятке различных промышленных и инфраструктурных объектах компании. С апреля EKF запускает открытое бета‑тестирование и будет готова предложить свою разработку другим предприятиям.

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

К текущим математическим алгоритмам в EKF Connect Industry разработчики планирует в ближайшем будущем добавить инструменты искусственного интеллекта.

По его словам команды разработчиков проекта, решение EKF Connect Industry является аналогом системы Schneider Electric ECOStruxure.

Value Proposition: ключ к сердцу клиента

Value Proposition (VP) или ценностное предложение — это обещание ценности, которое мы даем клиенту. Это не просто список функций или характеристик продукта, а скорее ответ на вопрос о том, почему клиент должен выбрать именно наш продукт.

Мы все перегружены возможностями выбора, а четкое VP помогает выделиться. Это не только привлекает внимание клиентов, но и способствует их удержанию. Для создания крутого VP нужно:

• Понимать свою ЦА.
  Хорошо изучите тех, кому вы предлагаете свой продукт. Чем лучше вы понимаете потребности и боли конечных пользователей, тем точнее сможете формулировать предложение.

• Объяснить уникальность.
  Чем ваш продукт отличается от конкурентов? Определяем и подчеркиваем это.

• Обеспечить простоту и ясность.
  Предложение должно быть понятным и запоминающимся. 

• Сфокусироваться на пользе.
  Говорим не о продукте, а о том, как он решает проблемы или улучшает жизнь клиента.

Value Proposition — это не просто маркетинговый слоган, это основа стратегии продукта. VP должно отражаться в каждом аспекте продукта: от разработки до маркетинга.

Для формирования VP очень важно исследовать CX и UX, чтобы лучше понимать боли и желания клиентов. Это поможет сформулировать то самое VP, которое будет взывать к их сердцам и умам.

С удовольствием обсудим примеры удачных и неудачных VP в комментариях. А больше о цифровых продуктах — в нашем канале.