#проекты — Public Fediverse posts

AI-native компания: почему пора перестать делать продукты

На первый взгляд AI-native звучит как очередной красивый ярлык для компаний, где всем выдали ChatGPT, Claude Code, Cursor и пару внутренних ботов. Но если смотреть не на инструменты, а на то, как реально работает компания, картина становится интереснее. Оказывается, значительная часть нашей работы — это не создание продукта и даже не принятие решений. Это перенос контекста. Клиент что-то сказал. Аналитик понял и оформил. РП пересказал. Разработчик уточнил. QA нашёл неоднозначность. Архитектор вспомнил, что три года назад похожее решение уже ломалось. Новичок спросил, где это описано. Все снова собрались на встречу, потому что в Jira непонятно, в Confluence устарело, а “без Пети никто этот модуль не понимает”. Снаружи это выглядит как привычная разработка продукта. Внутри — как огромный информационный конвейер, где клиентские сигналы превращаются в требования, требования — в дизайн, дизайн — в код, код — в тесты, релизы, эксплуатацию и новую обратную связь. И чем больше проект, тем дороже становится не сам код, а движение смысла через людей, документы, задачи, переписки и решения. И что с этим делать?

https://habr.com/ru/articles/1035898/

#aiагенты #бизнеспроцессы #проекты #продуктовая_разработка #менеджмент

Отчетность для совета директоров: какие метрики показывают реальное состояние проектов

Привет, Хабр! Меня зовут Константин Капошко, я развиваю систему управления проектами Directum Projects и по работе часто встречаюсь с представителями разных российских компаний, чтобы понять их запросы и боли. Вот что я заметил: в компаниях проектная отчетность может выглядеть убедительно — есть статусы, светофор, регулярные встречи, презентации для руководства. На верхнем уровне создается ощущение, что ситуация под контролем. А потом один из стабильно зеленых проектов «внезапно» срывает сроки, выходит за бюджет и требует срочного вмешательства. В этот момент возникает неприятный, но правильный вопрос: что вообще мы смотрели все это время?

https://habr.com/ru/companies/directum/articles/1035572/

#управление_проектами #отчетность #дорожная_карта #дашборд #аналитика #проекты

Отчетность для совета директоров: какие метрики показывают реальное состояние проектов

Привет, Хабр! Меня зовут Константин Капошко, я развиваю систему управления проектами Directum Projects и по работе часто встречаюсь с представителями разных российских компаний, чтобы понять их запросы и боли. Вот что я заметил: в компаниях проектная отчетность может выглядеть убедительно — есть статусы, светофор, регулярные встречи, презентации для руководства. На верхнем уровне создается ощущение, что ситуация под контролем. А потом один из стабильно зеленых проектов «внезапно» срывает сроки, выходит за бюджет и требует срочного вмешательства. В этот момент возникает неприятный, но правильный вопрос: что вообще мы смотрели все это время?

https://habr.com/ru/companies/directum/articles/1035572/

#управление_проектами #отчетность #дорожная_карта #дашборд #аналитика #проекты

Отчетность для совета директоров: какие метрики показывают реальное состояние проектов

Привет, Хабр! Меня зовут Константин Капошко, я развиваю систему управления проектами Directum Projects и по работе часто встречаюсь с представителями разных российских компаний, чтобы понять их запросы и боли. Вот что я заметил: в компаниях проектная отчетность может выглядеть убедительно — есть статусы, светофор, регулярные встречи, презентации для руководства. На верхнем уровне создается ощущение, что ситуация под контролем. А потом один из стабильно зеленых проектов «внезапно» срывает сроки, выходит за бюджет и требует срочного вмешательства. В этот момент возникает неприятный, но правильный вопрос: что вообще мы смотрели все это время?

https://habr.com/ru/companies/directum/articles/1035572/

#управление_проектами #отчетность #дорожная_карта #дашборд #аналитика #проекты

Отчетность для совета директоров: какие метрики показывают реальное состояние проектов

Привет, Хабр! Меня зовут Константин Капошко, я развиваю систему управления проектами Directum Projects и по работе часто встречаюсь с представителями разных российских компаний, чтобы понять их запросы и боли. Вот что я заметил: в компаниях проектная отчетность может выглядеть убедительно — есть статусы, светофор, регулярные встречи, презентации для руководства. На верхнем уровне создается ощущение, что ситуация под контролем. А потом один из стабильно зеленых проектов «внезапно» срывает сроки, выходит за бюджет и требует срочного вмешательства. В этот момент возникает неприятный, но правильный вопрос: что вообще мы смотрели все это время?

https://habr.com/ru/companies/directum/articles/1035572/

#управление_проектами #отчетность #дорожная_карта #дашборд #аналитика #проекты

Топ Open Source проектов СНГ: кто взлетел на сотни звёзд и как ваш проект может стать следующим

⭐️ Каждый месяц мы собираем топ open source проектов СНГ по приросту звёзд! Публикуем самые быстрорастущие проекты сообщества разбираем, почему они получают внимание, и делимся практическими советами, которые помогают авторам развивать свои проекты и привлекать контрибьюторов. Если вы тоже развиваете Open Source проект, возможно следующий топ будет уже с вашим репозиторием :)

https://habr.com/ru/articles/1034036/

#open_source #проекты #опенсорс #github #вебразработа #серверная_разработка #системное_программирование #python #djangomodernrest #гитхаб

Сегодня день Радио, поздравляю всех причастных 😀

Жутко хочу освободить время и вкатиться в эту тему, это интереснейшее занятие (как мне видится со стороны)

Недавно решил поковырять RDS

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

Через RDS станция может передавать:

• PS - короткое имя станции
• RT - радиотекст
• PI - код станции
• CT - время станции

Для исследовательского или радиолюбительского проекта это уже набор наблюдаемых цифровых признаков:

• на какой частоте что реально вещает
• как называется станция
• какой у неё PI-код
• передаёт ли она радиотекст
• насколько корректно у неё выставлено RDS-время
• как это всё меняется в разных местах

Что значит я сделал

1. rds.2big.cc - это веб-приложение для отображения таких наблюдений

Идея простая:

1. Устройство сканирует FM-диапазон
2. Ловит станции и читает RDS
3. Прикладывает к observation своё местоположение в виде QTH/Maidenhead
4. Отправляет observation в backend
5. Backend складывает всё в PostgreSQL
6. Frontend показывает локаторы на карте и даёт посмотреть последние приёмы и историю

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

Почему здесь именно QTH/Maidenhead

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

Это даёт несколько практических преимуществ:

• визуализация на карте остаётся простой
• можно легко сравнивать районы, а не отдельные GPS-точки
• locator хорошо знаком радиолюбителям
• анонимность++

Как устроен сканер

Железная часть проекта - это устройство на ESP8266 + SI4703, которое последовательно сканирует FM-частоты и читает RDS

Что делает устройство:

• проходит по диапазону FM
• измеряет RSSI
• ждёт стабилизации RDS-данных
• собирает лучшие кандидаты для PI, PS, RT, CT
• формирует observation
• отправляет его в backend (mqtt/rest)

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

Так же, была попытка запуститься на ESP32 + RDA5807M, но нет - похоже библиотека, которая работает с радио не очень хорошо обрабатывает RDS и часто получал пургу

Почему ESP8266 не использует отдельный GPS-модуль

Можно было бы поставить на сканер внешний GPS-модуль, но для такой задачи это часто избыточно:

• лишняя плата
• лишнее питание
• лишняя антенна
• лишняя сложность

Вместо этого проект использует компаньон на Android

Android-компаньон GPSCaster

ndroid-приложение на Kotlin. Оно работает как локальный GPS-ретранслятор для устройств в той же Wi-Fi сети

Что делает GPSCaster:

• получает положение телефона через FusedLocationProviderClient
• запускает foreground service
• держит в памяти последний валидный fix
• шлёт UDP broadcast в LAN
• слушает UDP-запросы GET_GPS
• шлёт GPS в BLE (тут кстати, отдельная идея - в принципе рассылать GPS через BLE advertisement)
• отвечает пакетом:

GPS,<unix_timestamp_seconds>,<lat>,<lon>,<accuracy_meters>

То есть телефон фактически выступает как "сетевой GPS и источник времени" для ESP8266

Это удобная идея:

• телефон и так уже знает точные координаты
• не нужно ставить отдельный GNSS-модуль на каждое устройство
• можно быстро развернуть систему в машине или в полевых условиях

Как связаны ESP8266 и GPSCaster

Связка работает так:

1. GPSCaster периодически рассылает в локальную сеть UDP-пакеты с координатами и временем
2. ESP8266 слушает порт 45454
3. Если свежих GPS-данных нет, ESP8266 может сам отправить GET_GPS,<device_id>
4. GPSCaster отвечает текущим fix
5. ESP8266 получает:
   
   • время
   • latitude
   • longitude
   • accuracy

   
   

6. По координатам прошивка вычисляет qth
7. По времени ставит ts

Если GPS-время не удалось получить:

• прошивка пробует NTP
• если NTP тоже не дал времени, идёт локальный счётчик от последней успешной синхронизации

Это не полноценный GPS-ресивер, но для задачи сбора подобной информации, более чем подходит

Будет желание - заходите

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

#проекты #деньрадио #esp8266 #rds

Сегодня день Радио, поздравляю всех причастных 😀

Жутко хочу освободить время и вкатиться в эту тему, это интереснейшее занятие (как мне видится со стороны)

Недавно решил поковырять RDS

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

Через RDS станция может передавать:

• PS - короткое имя станции
• RT - радиотекст
• PI - код станции
• CT - время станции

Для исследовательского или радиолюбительского проекта это уже набор наблюдаемых цифровых признаков:

• на какой частоте что реально вещает
• как называется станция
• какой у неё PI-код
• передаёт ли она радиотекст
• насколько корректно у неё выставлено RDS-время
• как это всё меняется в разных местах

Что значит я сделал

1. rds.2big.cc - это веб-приложение для отображения таких наблюдений

Идея простая:

1. Устройство сканирует FM-диапазон
2. Ловит станции и читает RDS
3. Прикладывает к observation своё местоположение в виде QTH/Maidenhead
4. Отправляет observation в backend
5. Backend складывает всё в PostgreSQL
6. Frontend показывает локаторы на карте и даёт посмотреть последние приёмы и историю

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

Почему здесь именно QTH/Maidenhead

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

Это даёт несколько практических преимуществ:

• визуализация на карте остаётся простой
• можно легко сравнивать районы, а не отдельные GPS-точки
• locator хорошо знаком радиолюбителям
• анонимность++

Как устроен сканер

Железная часть проекта - это устройство на ESP8266 + SI4703, которое последовательно сканирует FM-частоты и читает RDS

Что делает устройство:

• проходит по диапазону FM
• измеряет RSSI
• ждёт стабилизации RDS-данных
• собирает лучшие кандидаты для PI, PS, RT, CT
• формирует observation
• отправляет его в backend (mqtt/rest)

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

Так же, была попытка запуститься на ESP32 + RDA5807M, но нет - похоже библиотека, которая работает с радио не очень хорошо обрабатывает RDS и часто получал пургу

Почему ESP8266 не использует отдельный GPS-модуль

Можно было бы поставить на сканер внешний GPS-модуль, но для такой задачи это часто избыточно:

• лишняя плата
• лишнее питание
• лишняя антенна
• лишняя сложность

Вместо этого проект использует компаньон на Android

Android-компаньон GPSCaster

ndroid-приложение на Kotlin. Оно работает как локальный GPS-ретранслятор для устройств в той же Wi-Fi сети

Что делает GPSCaster:

• получает положение телефона через FusedLocationProviderClient
• запускает foreground service
• держит в памяти последний валидный fix
• шлёт UDP broadcast в LAN
• слушает UDP-запросы GET_GPS
• шлёт GPS в BLE (тут кстати, отдельная идея - в принципе рассылать GPS через BLE advertisement)
• отвечает пакетом:

GPS,<unix_timestamp_seconds>,<lat>,<lon>,<accuracy_meters>

То есть телефон фактически выступает как "сетевой GPS и источник времени" для ESP8266

Это удобная идея:

• телефон и так уже знает точные координаты
• не нужно ставить отдельный GNSS-модуль на каждое устройство
• можно быстро развернуть систему в машине или в полевых условиях

Как связаны ESP8266 и GPSCaster

Связка работает так:

1. GPSCaster периодически рассылает в локальную сеть UDP-пакеты с координатами и временем
2. ESP8266 слушает порт 45454
3. Если свежих GPS-данных нет, ESP8266 может сам отправить GET_GPS,<device_id>
4. GPSCaster отвечает текущим fix
5. ESP8266 получает:
   
   • время
   • latitude
   • longitude
   • accuracy

   
   

6. По координатам прошивка вычисляет qth
7. По времени ставит ts

Если GPS-время не удалось получить:

• прошивка пробует NTP
• если NTP тоже не дал времени, идёт локальный счётчик от последней успешной синхронизации

Это не полноценный GPS-ресивер, но для задачи сбора подобной информации, более чем подходит

Будет желание - заходите

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

#проекты #деньрадио #esp8266 #rds

Сегодня день Радио, поздравляю всех причастных 😀

Жутко хочу освободить время и вкатиться в эту тему, это интереснейшее занятие (как мне видится со стороны)

Недавно решил поковырять RDS

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

Через RDS станция может передавать:

• PS - короткое имя станции
• RT - радиотекст
• PI - код станции
• CT - время станции

Для исследовательского или радиолюбительского проекта это уже набор наблюдаемых цифровых признаков:

• на какой частоте что реально вещает
• как называется станция
• какой у неё PI-код
• передаёт ли она радиотекст
• насколько корректно у неё выставлено RDS-время
• как это всё меняется в разных местах

Что значит я сделал

1. rds.2big.cc - это веб-приложение для отображения таких наблюдений

Идея простая:

1. Устройство сканирует FM-диапазон
2. Ловит станции и читает RDS
3. Прикладывает к observation своё местоположение в виде QTH/Maidenhead
4. Отправляет observation в backend
5. Backend складывает всё в PostgreSQL
6. Frontend показывает локаторы на карте и даёт посмотреть последние приёмы и историю

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

Почему здесь именно QTH/Maidenhead

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

Это даёт несколько практических преимуществ:

• визуализация на карте остаётся простой
• можно легко сравнивать районы, а не отдельные GPS-точки
• locator хорошо знаком радиолюбителям
• анонимность++

Как устроен сканер

Железная часть проекта - это устройство на ESP8266 + SI4703, которое последовательно сканирует FM-частоты и читает RDS

Что делает устройство:

• проходит по диапазону FM
• измеряет RSSI
• ждёт стабилизации RDS-данных
• собирает лучшие кандидаты для PI, PS, RT, CT
• формирует observation
• отправляет его в backend (mqtt/rest)

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

Так же, была попытка запуститься на ESP32 + RDA5807M, но нет - похоже библиотека, которая работает с радио не очень хорошо обрабатывает RDS и часто получал пургу

Почему ESP8266 не использует отдельный GPS-модуль

Можно было бы поставить на сканер внешний GPS-модуль, но для такой задачи это часто избыточно:

• лишняя плата
• лишнее питание
• лишняя антенна
• лишняя сложность

Вместо этого проект использует компаньон на Android

Android-компаньон GPSCaster

ndroid-приложение на Kotlin. Оно работает как локальный GPS-ретранслятор для устройств в той же Wi-Fi сети

Что делает GPSCaster:

• получает положение телефона через FusedLocationProviderClient
• запускает foreground service
• держит в памяти последний валидный fix
• шлёт UDP broadcast в LAN
• слушает UDP-запросы GET_GPS
• шлёт GPS в BLE (тут кстати, отдельная идея - в принципе рассылать GPS через BLE advertisement)
• отвечает пакетом:

GPS,<unix_timestamp_seconds>,<lat>,<lon>,<accuracy_meters>

То есть телефон фактически выступает как "сетевой GPS и источник времени" для ESP8266

Это удобная идея:

• телефон и так уже знает точные координаты
• не нужно ставить отдельный GNSS-модуль на каждое устройство
• можно быстро развернуть систему в машине или в полевых условиях

Как связаны ESP8266 и GPSCaster

Связка работает так:

1. GPSCaster периодически рассылает в локальную сеть UDP-пакеты с координатами и временем
2. ESP8266 слушает порт 45454
3. Если свежих GPS-данных нет, ESP8266 может сам отправить GET_GPS,<device_id>
4. GPSCaster отвечает текущим fix
5. ESP8266 получает:
   
   • время
   • latitude
   • longitude
   • accuracy

   
   

6. По координатам прошивка вычисляет qth
7. По времени ставит ts

Если GPS-время не удалось получить:

• прошивка пробует NTP
• если NTP тоже не дал времени, идёт локальный счётчик от последней успешной синхронизации

Это не полноценный GPS-ресивер, но для задачи сбора подобной информации, более чем подходит

Будет желание - заходите

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

#проекты #деньрадио #esp8266 #rds

Сегодня день Радио, поздравляю всех причастных 😀

Жутко хочу освободить время и вкатиться в эту тему, это интереснейшее занятие (как мне видится со стороны)

Недавно решил поковырять RDS

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

Через RDS станция может передавать:

• PS - короткое имя станции
• RT - радиотекст
• PI - код станции
• CT - время станции

Для исследовательского или радиолюбительского проекта это уже набор наблюдаемых цифровых признаков:

• на какой частоте что реально вещает
• как называется станция
• какой у неё PI-код
• передаёт ли она радиотекст
• насколько корректно у неё выставлено RDS-время
• как это всё меняется в разных местах

Что значит я сделал

1. rds.2big.cc - это веб-приложение для отображения таких наблюдений

Идея простая:

1. Устройство сканирует FM-диапазон
2. Ловит станции и читает RDS
3. Прикладывает к observation своё местоположение в виде QTH/Maidenhead
4. Отправляет observation в backend
5. Backend складывает всё в PostgreSQL
6. Frontend показывает локаторы на карте и даёт посмотреть последние приёмы и историю

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

Почему здесь именно QTH/Maidenhead

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

Это даёт несколько практических преимуществ:

• визуализация на карте остаётся простой
• можно легко сравнивать районы, а не отдельные GPS-точки
• locator хорошо знаком радиолюбителям
• анонимность++

Как устроен сканер

Железная часть проекта - это устройство на ESP8266 + SI4703, которое последовательно сканирует FM-частоты и читает RDS

Что делает устройство:

• проходит по диапазону FM
• измеряет RSSI
• ждёт стабилизации RDS-данных
• собирает лучшие кандидаты для PI, PS, RT, CT
• формирует observation
• отправляет его в backend (mqtt/rest)

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

Так же, была попытка запуститься на ESP32 + RDA5807M, но нет - похоже библиотека, которая работает с радио не очень хорошо обрабатывает RDS и часто получал пургу

Почему ESP8266 не использует отдельный GPS-модуль

Можно было бы поставить на сканер внешний GPS-модуль, но для такой задачи это часто избыточно:

• лишняя плата
• лишнее питание
• лишняя антенна
• лишняя сложность

Вместо этого проект использует компаньон на Android

Android-компаньон GPSCaster

ndroid-приложение на Kotlin. Оно работает как локальный GPS-ретранслятор для устройств в той же Wi-Fi сети

Что делает GPSCaster:

• получает положение телефона через FusedLocationProviderClient
• запускает foreground service
• держит в памяти последний валидный fix
• шлёт UDP broadcast в LAN
• слушает UDP-запросы GET_GPS
• шлёт GPS в BLE (тут кстати, отдельная идея - в принципе рассылать GPS через BLE advertisement)
• отвечает пакетом:

GPS,<unix_timestamp_seconds>,<lat>,<lon>,<accuracy_meters>

То есть телефон фактически выступает как "сетевой GPS и источник времени" для ESP8266

Это удобная идея:

• телефон и так уже знает точные координаты
• не нужно ставить отдельный GNSS-модуль на каждое устройство
• можно быстро развернуть систему в машине или в полевых условиях

Как связаны ESP8266 и GPSCaster

Связка работает так:

1. GPSCaster периодически рассылает в локальную сеть UDP-пакеты с координатами и временем
2. ESP8266 слушает порт 45454
3. Если свежих GPS-данных нет, ESP8266 может сам отправить GET_GPS,<device_id>
4. GPSCaster отвечает текущим fix
5. ESP8266 получает:
   
   • время
   • latitude
   • longitude
   • accuracy

   
   

6. По координатам прошивка вычисляет qth
7. По времени ставит ts

Если GPS-время не удалось получить:

• прошивка пробует NTP
• если NTP тоже не дал времени, идёт локальный счётчик от последней успешной синхронизации

Это не полноценный GPS-ресивер, но для задачи сбора подобной информации, более чем подходит

Будет желание - заходите

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

#проекты #деньрадио #esp8266 #rds

Сегодня день Радио, поздравляю всех причастных 😀

Жутко хочу освободить время и вкатиться в эту тему, это интереснейшее занятие (как мне видится со стороны)

Недавно решил поковырять RDS

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

Через RDS станция может передавать:

• PS - короткое имя станции
• RT - радиотекст
• PI - код станции
• CT - время станции

Для исследовательского или радиолюбительского проекта это уже набор наблюдаемых цифровых признаков:

• на какой частоте что реально вещает
• как называется станция
• какой у неё PI-код
• передаёт ли она радиотекст
• насколько корректно у неё выставлено RDS-время
• как это всё меняется в разных местах

Что значит я сделал

1. rds.2big.cc - это веб-приложение для отображения таких наблюдений

Идея простая:

1. Устройство сканирует FM-диапазон
2. Ловит станции и читает RDS
3. Прикладывает к observation своё местоположение в виде QTH/Maidenhead
4. Отправляет observation в backend
5. Backend складывает всё в PostgreSQL
6. Frontend показывает локаторы на карте и даёт посмотреть последние приёмы и историю

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

Почему здесь именно QTH/Maidenhead

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

Это даёт несколько практических преимуществ:

• визуализация на карте остаётся простой
• можно легко сравнивать районы, а не отдельные GPS-точки
• locator хорошо знаком радиолюбителям
• анонимность++

Как устроен сканер

Железная часть проекта - это устройство на ESP8266 + SI4703, которое последовательно сканирует FM-частоты и читает RDS

Что делает устройство:

• проходит по диапазону FM
• измеряет RSSI
• ждёт стабилизации RDS-данных
• собирает лучшие кандидаты для PI, PS, RT, CT
• формирует observation
• отправляет его в backend (mqtt/rest)

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

Так же, была попытка запуститься на ESP32 + RDA5807M, но нет - похоже библиотека, которая работает с радио не очень хорошо обрабатывает RDS и часто получал пургу

Почему ESP8266 не использует отдельный GPS-модуль

Можно было бы поставить на сканер внешний GPS-модуль, но для такой задачи это часто избыточно:

• лишняя плата
• лишнее питание
• лишняя антенна
• лишняя сложность

Вместо этого проект использует компаньон на Android

Android-компаньон GPSCaster

ndroid-приложение на Kotlin. Оно работает как локальный GPS-ретранслятор для устройств в той же Wi-Fi сети

Что делает GPSCaster:

• получает положение телефона через FusedLocationProviderClient
• запускает foreground service
• держит в памяти последний валидный fix
• шлёт UDP broadcast в LAN
• слушает UDP-запросы GET_GPS
• шлёт GPS в BLE (тут кстати, отдельная идея - в принципе рассылать GPS через BLE advertisement)
• отвечает пакетом:

GPS,<unix_timestamp_seconds>,<lat>,<lon>,<accuracy_meters>

То есть телефон фактически выступает как "сетевой GPS и источник времени" для ESP8266

Это удобная идея:

• телефон и так уже знает точные координаты
• не нужно ставить отдельный GNSS-модуль на каждое устройство
• можно быстро развернуть систему в машине или в полевых условиях

Как связаны ESP8266 и GPSCaster

Связка работает так:

1. GPSCaster периодически рассылает в локальную сеть UDP-пакеты с координатами и временем
2. ESP8266 слушает порт 45454
3. Если свежих GPS-данных нет, ESP8266 может сам отправить GET_GPS,<device_id>
4. GPSCaster отвечает текущим fix
5. ESP8266 получает:
   
   • время
   • latitude
   • longitude
   • accuracy

   
   

6. По координатам прошивка вычисляет qth
7. По времени ставит ts

Если GPS-время не удалось получить:

• прошивка пробует NTP
• если NTP тоже не дал времени, идёт локальный счётчик от последней успешной синхронизации

Это не полноценный GPS-ресивер, но для задачи сбора подобной информации, более чем подходит

Будет желание - заходите

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

#проекты #деньрадио #esp8266 #rds

Нулевой этап проекта: как подготовить команду и не сорвать внедрение

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

https://habr.com/ru/companies/infostart/articles/1032094/

#управление_проектами #управление_людьми #управление_командой #менеджмент #проекты #1с #1с_внедрение

Почему проекты внедрения 1С выходят за бюджет: 7 ошибок, которые дорого обходятся бизнесу

На старте почти любой проект по внедрению 1С кажется вполне управляемым: есть бюджет, определены сроки, и команда уверена, что справится. Создается ощущение, что достаточно последовательно выполнить намеченный план – и через несколько месяцев компания получит новую систему, где все будет работать лучше, быстрее и прозрачнее. На практике все обычно оказывается не так гладко. Сначала недооценивают объем работ. Затем по ходу проекта решают «заодно» добавить еще несколько функций. Подготовку справочников откладывают до последнего, ключевые пользователи продолжают держаться за привычные процессы, а сам проект в результате запускают слишком рано – без полноценной подготовки ни системы, ни сотрудников. Из-за этого бюджет начинает постепенно выходить за рамки. Не одномоментно и не резко, а шаг за шагом. Еще один дополнительный блок, еще одна доработка, лишний этап согласования, новая интеграция – и проект уже обходится заметно дороже, чем планировалось в начале. Хорошая новость в том, что в большинстве случаев это не случайность и не «непредсказуемость внедрения». У перерасхода почти всегда есть вполне конкретные причины. Ниже – семь распространенных ошибок.

https://habr.com/ru/companies/infostart/articles/1031472/

#управление_проектами #проекты #внедрение_1с

Управление проектами: дайджест публикаций #54

Тонкости юзер-стори, устаревшие стори-пойнты, обманывающая команда, токсичность, гайд по дедлайнам, глава из руководства по P3.express и всё самое интересное, что писали за последние 2 недели про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!

https://habr.com/ru/articles/1030522/

#проекты

Релиз Ubuntu 26.04: пока, sudo; привет, Rust и постквантовый SSH — разбираем главные изменения в версии Resolute Raccoon

23 апреля британский разработчик Canonical выпустил Ubuntu 26.04 LTS — Resolute Raccoon. А мы в SpaceWeb добавили новую версию дистрибутива на все наши серверы — развернуть свежую систему можно уже сейчас. Релиз получился насыщенным: ядро 7.0, PostgreSQL 18 с трехкратным ускорением чтения, постквантовая криптография в OpenSSH по умолчанию, Rust-реализации sudo и coreutils , удаление cgroup v1 . Ниже — детальный разбор того, что изменилось и на что обратить внимание при миграции.

https://habr.com/ru/companies/runity/articles/1028402/

#spaceweb #linux #linuxсервер #ubuntu #ubuntu_2604 #canonical #сборки #сборки_ос #сборки_утилит #проекты

bladeRF 2.0 micro xA9: обзор реальных проектов, приложений и фреймворков

Я решил продолжить обзор bladeRF 2.0 micro xA9 через рассмотрение списка проектов, которые наиболее ярким образом демонстрируют возможности данного SDR в реальных применениях. Многие из этих вариантов прямо или косвенно базируются и обусловлены возможностями данного SDR. Перебирая все упоминания проектов с поддержкой bladeRF, я пришел к выводу, что bladeRF 2.0 micro xA9 лучше всего раскрывается там, где нужны не просто прием и декодирование, а широкий захват, передача, full duplex, MIMO, FPGA и кастомные GNU Radio/Soapy/libbladeRF сценарии. Самые сильные и практически ценные направления рассмотрим ниже. Но обо всем по порядку. Всем заинтересовавшимся - добро пожаловать под кат =)

https://habr.com/ru/companies/beget/articles/1018724/

#bladeRF #20 #xA9 #micro #sdr #ad9361 #проекты #gnu_radio #grosmosdr #soapysdr

У проекта шесть параметров и все важны. Проектный тетраэдр, а не треугольник

Если только кто сталкивался с управлением проектом, то первое на что они натыкались это знаменитый треугольник — сроков, объема и бюджету. А следующее усложнение, это вписанный круг в этот треугольник который означает качество. Что значит этот треугольник? Тут есть два ответа: 1) Его можно представить, как цель для руководителя проекта, а именно сделать нужное качество с установленным бюджетом и сроком. Так сказать выполнить проекцию треугольника во‑времени, и чтобы был он не подобным, а точным. 2) Также указывается взаимосвязь, что если у нас объем «поплыл» и начал увеличивается, то за этим самым начнет увеличиваться и например, сроки при сохранении бюджета, или бюджет при сохранении срока. И при этом что‑то будет происходить с качеством — и если ассоциация с качеством, как вписанным кругом прямая, то получается, при увеличении площади треугольника, оно будет увеличиваться? И если при увеличении сроков или бюджета, такое можно представить, то можно ли представить такое при увеличение объема? Если линейную связь между сроком и бюджетом с качеством представить легко, то с объемом сложнее. Уверен, что качество это отдельная категория, особенно в проектах ИТ, которая такая же самостоятельная и выступает и причиной и следствием с другими параметрами проект. Получается, не треугольник, а квадрат? И тут стоит вспомнить, что слово, которое рука об руку вспоминается с словом проект, а именно риски. Сделать быстро — рискованно, делать долго — менее рискованно. Сделать с большИм бюджетом один и тот‑же объем работ, также менее рискованно. Риски можно увеличивать, можно уменьшать. Более того, из житейского опыта, ясно, что чаще всего именно риски являются следствием соотношения выше рассмотренных параметров. Получается, еще один параметр? И проектный треугольник уже даже не квадрат.

https://habr.com/ru/articles/1019044/

#Управление_проектом #проект #проекты

Проект Terafab: как и зачем Илон Маск строит фабрику чипов за десятки миллиардов

Сейчас все, что связано с вычислениями, растет очень быстро. Искусственный интеллект, автопилоты в машинах, роботы — везде и всюду требуются специализированные чипы, и их нужно все больше. И здесь проблема: компании просто не успевают масштабировать производство, а полупроводниковые элементы в дефиците. Илон Маск решил не ждать, пока ситуация сама как-то выровняется. Недавно он объявил о проекте Terafab — совместной инициативе Tesla, SpaceX и xAI. Суть идеи — не только построить еще один завод, но и собрать весь процесс в одном месте: от разработки чипов до их финальной сборки и тестирования. Давайте посмотрим, что это такое и как Маск собирается воплощать свою задумку в жизнь.

https://habr.com/ru/companies/ru_mts/articles/1015378/

#маск #проекты #электроника

Управление проектами: дайджест публикаций #52

Канбан на практике, гайд по проектным метрикам, портфельное управление, хорошее и плохое ТЗ, обзор книги по P3. Express и всё интересное, что писали за последние 2 недели про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте! Расширенные дайджесты, новости, обзоры книг и курсов для РП и аналитиков — в моем канале «Проектный дайджест» , а теперь ещё и в удобной базе знаний , где я собрал уже почти 2000 статей по управлению проектами — с резюме, тегами и даже pdf‑ками.

https://habr.com/ru/articles/1013142/

#проекты #менеджмент

Застегните ширинки, мамкины киберпанки. Забудьте на хрен про ИИ

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

https://habr.com/ru/articles/1009544/

#управление_проектами #управление_людьми #управление_командой #проекты #управление_задачами #проектное_управление #прибыль #бизнес #бизнеспроцессы

Солнечный трекер на Arduino

Солнечный трекер – это устройство, которое может отслеживать положение солнца. На трекеры ставят солнечные панели, чтобы они могли аккумулировать больше энергии, благодаря изменению угла поворота в пространстве. Данная реализация является моделью для прототипа. Описание полной сборки и настройки, как и сборки многих других занимательных устройств я описал в своей книге " Умная робототехника для начинающих. Разработка на Arduino ". Для создания работающей модели нам понадобяться прочный, но лёгкий материал, на котором будет производиться монтаж электрокомпонентов и сам он будет использоваться в качестве несущей конструкции. Можно выбрать вспенённый пвх лист 3 мм или листовой прозрачный пластик 1,5-3 мм. Так же подойдёт корпус из под лазерных дисков. Нам нужны электрокомпоненты . Я возьму: arduino uno, два сервопривода- четыре фоторезистора, четыре резистора на 1 кОм, соединительные провода, плата для монтажа (можно беспаечную). Чтобы производить монтаж электроники, вырезать и собирать конструкцию трекера нам нужны инструменты. Я воспользуюсь: канцелярским ножом и ножницами, клеем для пластика или термоклеем, карандашом, линейкой или штангенциркулем, наждачной бумагой мелкой фракции, паяльной станцией с припоем и канифолью. Фоторезисторы в этом устройстве будут работать, как датчики света. Располагаться они должны по краям подвижной платформу. С какой стороны более яркий свет – в ту сторону и поворачивается устройство. Рассмотрим схему конструкции .

https://habr.com/ru/articles/995324/

#ардуино #трекер #проекты #проектирование #arduino #фотоны #фотоэлектрические #сборка_проекта #модель #прототип

Солнечный трекер на Arduino

Солнечный трекер – это устройство, которое может отслеживать положение солнца. На трекеры ставят солнечные панели, чтобы они могли аккумулировать больше энергии, благодаря изменению угла поворота в пространстве. Данная реализация является моделью для прототипа. Описание полной сборки и настройки, как и сборки многих других занимательных устройств я описал в своей книге " Умная робототехника для начинающих. Разработка на Arduino ". Для создания работающей модели нам понадобяться прочный, но лёгкий материал, на котором будет производиться монтаж электрокомпонентов и сам он будет использоваться в качестве несущей конструкции. Можно выбрать вспенённый пвх лист 3 мм или листовой прозрачный пластик 1,5-3 мм. Так же подойдёт корпус из под лазерных дисков. Нам нужны электрокомпоненты . Я возьму: arduino uno, два сервопривода- четыре фоторезистора, четыре резистора на 1 кОм, соединительные провода, плата для монтажа (можно беспаечную). Чтобы производить монтаж электроники, вырезать и собирать конструкцию трекера нам нужны инструменты. Я воспользуюсь: канцелярским ножом и ножницами, клеем для пластика или термоклеем, карандашом, линейкой или штангенциркулем, наждачной бумагой мелкой фракции, паяльной станцией с припоем и канифолью. Фоторезисторы в этом устройстве будут работать, как датчики света. Располагаться они должны по краям подвижной платформу. С какой стороны более яркий свет – в ту сторону и поворачивается устройство. Рассмотрим схему конструкции .

https://habr.com/ru/articles/995324/

#ардуино #трекер #проекты #проектирование #arduino #фотоны #фотоэлектрические #сборка_проекта #модель #прототип

Солнечный трекер на Arduino

Солнечный трекер – это устройство, которое может отслеживать положение солнца. На трекеры ставят солнечные панели, чтобы они могли аккумулировать больше энергии, благодаря изменению угла поворота в пространстве. Данная реализация является моделью для прототипа. Описание полной сборки и настройки, как и сборки многих других занимательных устройств я описал в своей книге " Умная робототехника для начинающих. Разработка на Arduino ". Для создания работающей модели нам понадобяться прочный, но лёгкий материал, на котором будет производиться монтаж электрокомпонентов и сам он будет использоваться в качестве несущей конструкции. Можно выбрать вспенённый пвх лист 3 мм или листовой прозрачный пластик 1,5-3 мм. Так же подойдёт корпус из под лазерных дисков. Нам нужны электрокомпоненты . Я возьму: arduino uno, два сервопривода- четыре фоторезистора, четыре резистора на 1 кОм, соединительные провода, плата для монтажа (можно беспаечную). Чтобы производить монтаж электроники, вырезать и собирать конструкцию трекера нам нужны инструменты. Я воспользуюсь: канцелярским ножом и ножницами, клеем для пластика или термоклеем, карандашом, линейкой или штангенциркулем, наждачной бумагой мелкой фракции, паяльной станцией с припоем и канифолью. Фоторезисторы в этом устройстве будут работать, как датчики света. Располагаться они должны по краям подвижной платформу. С какой стороны более яркий свет – в ту сторону и поворачивается устройство. Рассмотрим схему конструкции .

https://habr.com/ru/articles/995324/

#ардуино #трекер #проекты #проектирование #arduino #фотоны #фотоэлектрические #сборка_проекта #модель #прототип

Солнечный трекер на Arduino

Солнечный трекер – это устройство, которое может отслеживать положение солнца. На трекеры ставят солнечные панели, чтобы они могли аккумулировать больше энергии, благодаря изменению угла поворота в пространстве. Данная реализация является моделью для прототипа. Описание полной сборки и настройки, как и сборки многих других занимательных устройств я описал в своей книге " Умная робототехника для начинающих. Разработка на Arduino ". Для создания работающей модели нам понадобяться прочный, но лёгкий материал, на котором будет производиться монтаж электрокомпонентов и сам он будет использоваться в качестве несущей конструкции. Можно выбрать вспенённый пвх лист 3 мм или листовой прозрачный пластик 1,5-3 мм. Так же подойдёт корпус из под лазерных дисков. Нам нужны электрокомпоненты . Я возьму: arduino uno, два сервопривода- четыре фоторезистора, четыре резистора на 1 кОм, соединительные провода, плата для монтажа (можно беспаечную). Чтобы производить монтаж электроники, вырезать и собирать конструкцию трекера нам нужны инструменты. Я воспользуюсь: канцелярским ножом и ножницами, клеем для пластика или термоклеем, карандашом, линейкой или штангенциркулем, наждачной бумагой мелкой фракции, паяльной станцией с припоем и канифолью. Фоторезисторы в этом устройстве будут работать, как датчики света. Располагаться они должны по краям подвижной платформу. С какой стороны более яркий свет – в ту сторону и поворачивается устройство. Рассмотрим схему конструкции .

https://habr.com/ru/articles/995324/

#ардуино #трекер #проекты #проектирование #arduino #фотоны #фотоэлектрические #сборка_проекта #модель #прототип

Обзор книги Дэвида Аллена «Как привести дела в порядок. Искусство продуктивности без стресса»

Закопаться в делах — это когда система планирования расходует когнитивные ресурсы быстрее, чем помогает их экономить. Планировать, делегировать и контролировать можно по-разному. Иногда это трудно назвать системой, что увеличивает расход энергии на решение тех же задач. Вопрос лишь в том, чем управлять: волевыми усилиями или вниманием. Что ж, попробуем в этом разобраться. Разобраться

https://habr.com/ru/articles/993184/

#gtd #продуктивность #самоорганизация #менеджмент #проекты #таймменеджмент

Как я оцениваю проекты перед использованием

В крипте легко попасть в ловушку: кажется, что главное - найти "правильный" проект. А по факту главное - не пропустить риск, который потом проявится разлоками, уязвимостью, слабой коммуникацией команды или отсутствием спроса. Я незрячий web3-программист, поэтому не опираюсь на визуальные подсказки и "красивые" графики. Мой подход проще: разложить проект на несколько блоков и последовательно проверить, где именно он может сломаться. Ниже - схема, которой я пользуюсь, когда решаю, стоит ли вообще тратить время и деньги на проект. Это не "как выбрать монету" и не прогноз цены. Это чеклист рисков: команда, концепт, коин (токеномика и капитал), код и практика (как всё работает в реальности). Тут всё важно:

https://habr.com/ru/articles/992960/

#Анализ #аналитика #проекты

Новый подход к внедрению: замена Большого Взрыва и Parallel Running

Каждый РП стоял перед выбором: запускаем методом "Большого Взрыва" или попробуем "Работать с двух системах" - Parallel Running. Кто не знаком с методологией: Большой взрыв. Останавливаем "старую" систему и запускаем новую. Старую - вот прям останавливаем, чтобы не было соблазна вернуться или вести часть бизнес-процессов в "старой" системе. Очень жесткий запуск: новая система непривычна, люди путаются, работа в системе кардинально замедляется, куча ошибок. Внедряющая команда на стрессе, полностью в полях: научить, подсказать, исправить и - главное - доработать! Увидите седого РП - попросите рассказать парочку примеров из его жизни.

https://habr.com/ru/articles/992798/

#проекты #интеграция #интеграция_систем #методология

5 мифов на старте ИТ-проекта

Продолжаем наш сериал про «успешный успех» в мире 1С. Если после прошлой статьи про выбор интегратора ты не передумал внедряться, поздравляю — у тебя либо стальные нервы, либо безграничный оптимизм. Сегодня разберем «священных коров» ИТ-проектов — мифы, в которые все верят, но о которые разбиваются бюджеты. Вера в «волшебную кнопку» — это национальный спорт. Ты думаешь: «Сейчас куплю ERP, и этот цифровой комбайн сам пережует мой хаос в стройную отчетность». Спойлер: автоматизация бардака дает автоматизированный бардак. Причем работать в нем будет в три раза дороже. Давай снимем розовые очки и посмотрим, на чем горят даже опытные боссы. 1. Сроки и бюджет: «Впишемся день в день, копейка в копейку» Это надо планировать, на этом надо держать фокус. И не всегда бюджет критичней сроков — иногда законотворцы подгоняют нас такими штрафами, что любой простой стоит дороже всей лицензии 1С. Но если ты прям БИЗНЕС и бюджет — это твои кровные, а не спущенные сверху «на реализацию», накидывай сразу от 20% до 50%. И молчи об этом. Не говори интегратору, не говори внутренней команде. Это твой НЗ, о котором знаешь только ты и твой психолог. Когда маленькая задачка за 150 тысяч вдруг вырастет в монстра за 1,5 миллиона (а в бэклоге таких соберется десяток), будет не так больно. Ладно, будет больно. Но ты будешь готов. Со сроками та же история. На моей практике из трех проектов, которые «с 1 января должны жить в новой реальности», запустились в срок только два. И то — выбрав штрафной круг и перенеся запуск на год. За это время отполировали всё, что можно. Клиенты были готовы, и эти 15% сверх бюджета не стали критичными. А вот третий кейс решил «взлететь» любой ценой. Итог: урезанный до состояния инвалидности MVP, бюджет раздулся на 60% в первый же год поддержки, а в списке потерь: главбух, финдир и куча нервных клеток с обеих сторон. Иногда пожертвовать сроком — значит спасти проект.

https://habr.com/ru/articles/992294/

#1с #проекты #бизнес #бизнеспроцессы #консалтинг #проектные_технологии #аудит #автоматизация #цифровизация

Управление проектами: дайджест публикаций #50

Аналоги конфлюэнса, лучшие таск-трекеры, управление проектом в форс-мажоре, жизненный цикл ERP-проектов, спецификации, настройка скрамбана, как работать с зумерами и всё интересное, что писали за последние 3 недели про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!

https://habr.com/ru/articles/991568/

#проекты #скрам #менеджмент

Как выбрать систему управления проектами за 7 шагов: подробное руководство и обзор ИСУП

Рано или поздно любой руководитель задается вопросом: «Почему мы не достигаем целей на проекте?». Как правило, ответы размытые и сопровождаются презентацией из десяти файлов. После этого в компании появляется идея «оцифровать проектную деятельность». И начинается путь выбора системы, полный надежд, ожиданий и типовых ошибок. В этой статье разберемся, как подойти к выбору ИСУП без иллюзий и маркетингового тумана: на что действительно стоит смотреть, какие вопросы задать себе до покупки и как получить реальный эффект от внедрения. Спойлер: внутри — ссылка на полезный гайд со сравнительными таблицами и небольшой обзор популярных ИСУП.

https://habr.com/ru/companies/directum/articles/990974/

#проекты #исуп #управление_проектами #система_управления_проектами

Как гарантировано провалить проект 1С: 10 ошибок при выборе интегратора

Как это обычно бывает? Вот ты — руководитель, собственник или просто очень инициативный человек — в какой-то момент понимаешь: жить так дальше нельзя. Автоматизация и цифровизация не дают спать по ночам. От требований к опер/упр. учету зудит в мозгу. И идешь ты искать умных людей с опытом, которые посвятят тебя в тайны проектных технологий. А они, ну очень умные и очень специализированные, некоторые даже «экспертные» — уже на низком старте. Они спят и видят, как бы «нанести тебе пользу». Быстро, эффективно и подозрительно недорого. На первой же встрече тебе выкатят кейс-сказку: «Agile-внедрение ERP за полгода, самописная MES-система и аналитика в BI без потери данных, людей и здравого смысла». Цена — миллион рублей, оплата — когда-нибудь потом. И всё это на фоне сертов «Проект года». Мы молодцы, выбери нас! Каждая твоя встреча с интеграторами будет идти примерно по одному сценарию. Это не потому, что они хотят тебя обмануть. А потому что найти клиента, заключить договор, сделать проект и в идеале зайти с тобой в следующий – это тяжело, сложно и долго. Поэтому будут использовать любой прием лишь бы ты выбрал их. Еще есть «персонажи», у которых сценарий менее гуманный. Договор – оплата – работаем пока работается, главное акты подписывать, в идеале наперед – суд – возврат минимальной суммы. Таких мы обходим стороной, но именно у них будет самое вкусное КП. Давай рассмотрим основные и не самые очевидные ошибки при выборе интегратора, терять деньги и время никто не хочет.

https://habr.com/ru/articles/990602/

#1С #проекты #интегратор #erp #консалтинг #оценка

Обзор книги «Проектное управление. Как правильно делать правильные вещи», Павел Алферов

Почему на закрытии Олимпиады в Сочи не раскрылось одно кольцо? Вопрос интересный, но не концептуальный. Действительно интересно — что еще могло произойти и как сумели предотвратить. Хотя некоторых трагедий и даже смертей избежать не удалось, наши справились лучше большинства других оргкомитетов. В чем секрет и как его применить для бизнеса и карьеры? Что ж, попробуем в этом разобраться. Меня зовут Костя Дубровин. Я веду канал про книги. Разобраться

https://habr.com/ru/articles/988512/

#управление_проектами #проектное_управление #проекты #риски #сколково #РИМIII #Agile #проектный_офис #центр_компетенций

Управление проектами: дайджест публикаций #47

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

https://habr.com/ru/articles/976354/

#проекты #менеджмент #скрам #управление

Как я создал самое большое сообщество людей в Рунете занятых на FMCG рынке. Часть 1 «Прыжок веры»

Я Павел Мамонов, 40 лет, основатель крупнейшего сообщества в Рунете людей, занятых на FMCG рынке. Я хотел бы посвятить цикл статей одному из моих самых больших проектов который занял достаточно большой период моей жизни. Проект заслуживающий внимание и заслуживший право остаться в истории FMCG рынка, поскольку является типичным примером интернет - стартапа который рождается в гараже на колене в России (во времена, когда стоимость входа в интернет индустрию была очень низкой). Проект, который удерживал лидирующие позиции на протяжении почти 10 лет в своей ниши, являясь частью жизни FMCG B2B рынка того времени. Проект который может служить примером ошибок и надежд основателей слепо идущих к своей цели, не замечающих грань где заканчивается хобби и начинается бизнес, незамечающих фунтамента на котором должен строится бизнес. Для упрощения воспринятия материала читателям материал будет состоять из цикла статей котррое будут белить проект на этапы жизни соответствующими модели жизненого цикла компании по Адизису, пологаю так будет легче воспинимать материал и анализировать допущенные ошибки.

https://habr.com/ru/articles/976270/

#бизнес_с_нуля #стартап #сообщество #монетизация #проекты #построение_сообщества #большие_проекты

Как сделать индивидуальный проект с помощью нейросети: ТОП-10 ИИ для создания итоговых работ

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

https://habr.com/ru/companies/kemp_ai/articles/975484/

#школа #вуз #учеба #проекты

Вы до сих пор не пользуетесь Obsidian? Очень зря

Мой путь от простых телефонных заметок к системе персонального знания начался с боли: потеря данных при смене устройств, неудобная синхронизация, отсутствие контроля. Прорыв случился с Obsidian — приложением, которое, как и VS Code, строится вокруг открытого формата (Markdown), локального хранения и расширяемости через плагины. Именно этот принцип «я управляю инструментом, а не наоборот» стал ключевым: Obsidian — не блокнот, а операционная система для мышления.

https://habr.com/ru/articles/972574/

#obsidian #аналитика #аналитика_данных #проекты #плагины #plugin #makemd #markdown #маркдаун #git

От личной мечты до инструмента всей компании: как я строила сервис фасилитации в КОРУСе (и что об этом думают команды)

Привет! Меня зовут Анастасия Криулина, я специалист по обучению и фасилитатор в КОРУСе. Ранее в своих материалах я рассказывала о практике фасилитации, и о том, как она помогает работать с командами. А сегодня поделюсь ретроспективой и расскажу, как я запускала этот сервис и к чему пришла за 3 года. Материал будет полезен руководителям, лидерам или HR крупных командоцентричных компаний, которые рассматривают внедрение внутреннего сервиса фасилитации или ищут новые форматы для улучшения командного взаимодействия. А еще это очень личная история о том, что методичная работа воплощает мечты в реальность.

https://habr.com/ru/companies/korus_consulting/articles/972506/

#фасилитация #фасилитация_встреч #hr #команда #управление_командой #управление_командами #управление_проектами #проекты #управление_командами_и_проектами #управление_командой_ит

Компьютеры для избранных и DIY-бунт: кто реально правил советским ПК

Советская история ПК конца XX века — это несколько параллельных вселенных и почти что сны при температуре 39 градусов для зумеров. МИРы показали, что с машиной можно работать интерактивно. Радио-86РК и Орион научили паять, отлаживать и кодить с нуля. Клоны Спектрума открыли доступ к играм, утилитам и демосцене, а 16-битные БК и УК-НЦ давали школьникам пощупать Паскаль и Фортран. Компьютеры были редкостью, и именно это делало их особенно интересными. В этом посте окунёмся в ностальгию и вспомним часть моделей: как они были устроены, чем отличались и зачем были нужны.

https://habr.com/ru/companies/gazprombank/articles/965624/

#история #компьютеры #проекты #технологии

Align: находка для продакта

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

https://habr.com/ru/articles/964310/

#роадмап #гант #проекты #продактменеджмент #roadmap #gantt

Align: находка для продакта

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

https://habr.com/ru/articles/964310/

#роадмап #гант #проекты #продактменеджмент #roadmap #gantt

Align: находка для продакта

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

https://habr.com/ru/articles/964310/

#роадмап #гант #проекты #продактменеджмент #roadmap #gantt

Align: находка для продакта

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

https://habr.com/ru/articles/964310/

#роадмап #гант #проекты #продактменеджмент #roadmap #gantt

Как поженить разработку и управление продуктом

Привет! Меня зовут Мария Аркуша, я продакт-менеджер в Точка Банк. Сегодня хочу рассказать, как нам удалось ускорить и упростить процесс разработки и выкатывания новых фич в продукте.

https://habr.com/ru/companies/tochka/articles/967588/

#ускорение_разработки #фичи #продактменеджмент #проекты

Как поженить разработку и управление продуктом

Привет! Меня зовут Мария Аркуша, я продакт-менеджер в Точка Банк. Сегодня хочу рассказать, как нам удалось ускорить и упростить процесс разработки и выкатывания новых фич в продукте.

https://habr.com/ru/companies/tochka/articles/967588/

#ускорение_разработки #фичи #продактменеджмент #проекты

Как поженить разработку и управление продуктом

Привет! Меня зовут Мария Аркуша, я продакт-менеджер в Точка Банк. Сегодня хочу рассказать, как нам удалось ускорить и упростить процесс разработки и выкатывания новых фич в продукте.

https://habr.com/ru/companies/tochka/articles/967588/

#ускорение_разработки #фичи #продактменеджмент #проекты

Как поженить разработку и управление продуктом

Привет! Меня зовут Мария Аркуша, я продакт-менеджер в Точка Банк. Сегодня хочу рассказать, как нам удалось ускорить и упростить процесс разработки и выкатывания новых фич в продукте.

https://habr.com/ru/companies/tochka/articles/967588/

#ускорение_разработки #фичи #продактменеджмент #проекты

Управление проектами: дайджест публикаций #45

Методы Монте-Карло и швейцарского сыра, статистика в оценке сроков, замена Jira, вредные советы планирования, управление техдолгом, типология руководителей, борьба с микроменджментом, правильный онбординг и всё интересное, что писали за последние 2 недели про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!

https://habr.com/ru/articles/966782/

#проект #проекты #менеджмент #scrum #канбан

Кайдзен-подходы в проектах разработки и внедрения информационных систем

Человеческая история богата различными управленческими концепциями и практиками. Венцом управленческой мысли стала вторая половина ХХ века, когда проявилось «японское чудо», благодаря которому японские товары захватили мировые рынки. Немалую роль в «чуде» сыграли Кайдзен-принципы. В этой статье поговорим о применении некоторых из них для реализации ИТ-проектов.

https://habr.com/ru/articles/962448/

#Качество #проекты #внедрение_ис #управление_качеством #кайдзен

Мы тонем: как менеджер спасал свои проекты

Представьте: без выгорания и переработок вести несколько проектов одновременно. Как в шторм на сапборде, скажете вы — мы ответим, что с правильными инструментами это возможно. Если устали захлебываться в рутине, эта статья для вас. Привет, Хабр, на связи команда ITSM 365. Наш клиент Михаил пытался вести вручную несколько проектов, допустил типичные ошибки и обратился к автоматизации. Его опыт показал, как система управления проектами помогает не срывать сроки и навести порядок в коммуникации. С согласия клиента делимся его историей.

https://habr.com/ru/companies/itarena/articles/961202/

#проекты #управление_проектами #управление_командой #внедрение #servicedesk #service_desk #техническая_поддержка #техподдержка #helpdesk #подборка

Две книги о проблемах ИТ-команд

Проработав почти 25 лет в ИТ, у меня накопилось то, о чём хотелось бы рассказать. Я изучил множество технологий, участвовал в массе проектов. Работал как в мелких фирмах, так и у мировых гигантов. Общался с разными людьми из разных стран и континентов. Основным моим мотивом всегда был успех проекта. Я всегда пытался сделать работу на максимуме своих возможностей. Много читал и изучал, анализировал, писал на разных языках и платформах. Всегда было стремление сделать проект как можно лучше. Но далеко не всегда это получалось. Когда давали возможность, что-то выходило, хотя не всегда. Иногда возникали обстоятельства, которые ставили крест на проекте. Факторов, приведших проект к успеху или, наоборот, к провалу, всегда было много. Анализируя свой опыт, у меня возник вопрос: а почему так получалось? Почему один проект выстрелил, а другой нет? Почему с одной командой мы буквально горы свернули, а с другой так ничего и не добились? Вспомнив все эти ситуации и проанализировав их, я написал две книги, в которых рассказываю о том, что может негативно повлиять на команду разработчиков и в итоге привести к провалу проекта, над которым они работают, либо к её распаду. В книге «Лоу-перформеры в ИТ: кто тянет команду вниз» я рассказываю о сотрудниках, которые делают вид, что работают. С такими приходилось очень часто встречаться, и я пришёл к выводу, что они негативно влияют и на проект, в котором задействованы, и на команду, частью которой являются. Я описал шесть типов поведения таких людей и дал рекомендации, как с ними работать и минимизировать их негативное влияние. Также поделился собственным опытом и собрал рекомендации из различных публикаций, в которых описывается данная проблема.

https://habr.com/ru/articles/941438/

#иткоманда #руководитель_разработки #лоуперформеры #лоуперформеры #конфликты #проблемы #управление #опыт #проекты #ситуации