Все потоки

Совет по Joomla: расположение полей Form в параметрах модулей и плагинов.

Обычно поля настроек модулей и плагинов идут столбиком - сверху вниз. Название поля находится слева, а само поле - справа. В вёрстке админки мы видим div.control-group, в котором находятся label и поле. Посмотрим как можно просто кастомизировать админку.

Название поля НАД полем - parentclass="stack".

Если в XML-манифесте модуля или плагина добавить к полю атрибут parentclass, то мы можем указывать любые CSS-стили для div.control-group. Если указать CSS-класс stack, то название поля встанет над самим полем. Это удобно для больших сабформ - экономится место на экране.

<field type="text"
     name="map_center"
     label="MOD_WTYANDEXMAPITEMS_MAP_CENTER"
     description="MOD_WTYANDEXMAPITEMS_MAP_CENTER_DESC"
     default="51.533562, 46.034266"
     hint="51.533562, 46.034266"
     parentclass="stack"
/>

2 и более полей в ряд в параметрах модуля/плагина - классы span-*

Мы можем 2 или 3 небольших поля поставить рядом (для десктопов). Табы настроек являются grid-сеткой из 4-х колонок. Для поля можно указать ширину в виде количества колонок. Нам нужно в parentclass добавить класс span-*-inline. Допустимы числа от 1 до 4.

span-1-inline - поле будет шириной в 1 колонку сетку. span-4-inline - ширина в 4 колонки, равносильно поведению по умолчанию. Этот код выведет 2 поля в админке в параметрах модуля рядом на десктопах. Поскольку используется также класс stack - название поля будет над самим полем.

<field type="list"
     name="map_zoom"
     label="MOD_WTYANDEXMAPITEMS_MAP_ZOOM"
     default="7"
     parentclass="stack span-2-inline"
     filter="integer">
          <option value="0">0</option>
          <option value="1">1</option>
          <option value="21">21</option>
</field>
<field type="list"
     name="map_type"
     label="MOD_WTYANDEXMAPITEMS_MAP_TYPE"
     parentclass="stack span-2-inline"
     default="scheme">
          <option value="scheme">MOD_WTYANDEXMAPITEMS_MAP_TYPE_MAP</option>
          <option value="satellite">MOD_WTYANDEXMAPITEMS_MAP_TYPE_SATELLITE</option>
</field>

Чат русскоязычного сообщества Joomla

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

Делимся важным апдейтом команды Рег.ру — запустили защищенное облако по модели IaaS. Облако 152-ФЗ полностью соответствует требованиям закона по работе с персональными данными. Новое решение размещено в изолированном сегменте ЦОД с повышенными стандартами безопасности и аттестовано лицензированным партнером по максимальному уровню защищенности (УЗ1).

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

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

Мы продолжаем усиливать экспертизу в области безопасности — новое решение стало еще одним шагом в этом направлении. Подробнее об Облаке 152-ФЗ читайте на сайте.

Не того боитесь

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

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

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

Вот жили вы — не тужили. Ели курицу и свинину, а потом увидели репортаж, где зарезают свиней, а цыплят перемалывают на конвейере, и решили: «Никогда в жизни не буду больше есть мясо!»

Та-дам! — в этот момент вы купили идею вегетарианства, а дальше она уже откроет ваш кошелек, чтобы вы смогли купить ростки сои и брокколи. 

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

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

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

Совет по Joomla: расположение полей Form в параметрах модулей и плагинов.

Обычно поля настроек модулей и плагинов идут столбиком - сверху вниз. Название поля находится слева, а само поле - справа. В вёрстке админки мы видим div.control-group, в котором находятся label и поле. Посмотрим как можно просто кастомизировать админку.

Название поля НАД полем - parentclass="stack".

Если в XML-манифесте модуля или плагина добавить к полю атрибут parentclass, то мы можем указывать любые CSS-стили для div.control-group. Если указать CSS-класс stack, то название поля встанет над самим полем. Это удобно для больших сабформ - экономится место на экране.

<field type="text"
     name="map_center"
     label="MOD_WTYANDEXMAPITEMS_MAP_CENTER"
     description="MOD_WTYANDEXMAPITEMS_MAP_CENTER_DESC"
     default="51.533562, 46.034266"
     hint="51.533562, 46.034266"
     parentclass="stack"
/>

2 и более полей в ряд в параметрах модуля/плагина - классы span-*.

Мы можем 2 или 3 небольших поля поставить рядом (для десктопов). Табы настроек являются grid-сеткой из 4-х колонок. Для поля можно указать ширину в виде количества колонок. Нам нужно в parentclass добавить класс span-*-inline. Допустимы числа от 1 до 4.

• span-1-inline - поле будет шириной в 1 колонку сетку.

• span-4-inline - ширина в 4 колонки, равносильно поведению по умолчанию.

Этот код выведет 2 поля в админке в параметрах модуля рядом на десктопах. Поскольку используется также класс stack - название поля будет над самим полем.

<field type="list"
     name="map_zoom"
     label="MOD_WTYANDEXMAPITEMS_MAP_ZOOM"
     default="7"
     parentclass="stack span-2-inline"
     filter="integer">
          <option value="0">0</option>
          <option value="1">1</option>
          <option value="21">21</option>
</field>
<field type="list"
     name="map_type"
     label="MOD_WTYANDEXMAPITEMS_MAP_TYPE"
     parentclass="stack span-2-inline"
     default="scheme">
          <option value="scheme">MOD_WTYANDEXMAPITEMS_MAP_TYPE_MAP</option>
          <option value="satellite">MOD_WTYANDEXMAPITEMS_MAP_TYPE_SATELLITE</option>
</field>

Митап PythoNSK #1 2025: Оффлайн встреча питонистов в Новосибирске

Дата: 13 сентября 14:00-17:00 (UTC+7)
Адрес: Новосибирск, улица Ленина, 71, Новосибирск, "Этаж"

13 сентября - 256 день в году. Именно в эту символичную дату, день программиста, мы проводим первый оффлайн митап для питонистов в Новосибирске. И мы начинаем свою деятельность!

У нас на митапе будут:

1️⃣ Лекции:

1. "Как работают гринлеты в SQLAlchemy", Алексей

2. "Десктоп-разработка на PySide6", Роман

2️⃣ Интерактив:

1. Небольшая викторина по Python с призом в виде книги "Грокаем алгоритмы, 2е издание", Адитья Брахгава.

3️⃣ И под конец - онлайн встреча с Никитой Соболевым, CPython Core Developer'ом.

Регистрация: https://docs.google.com/forms/d/e/1FAIpQLSePMDs21rFwWkRGCEsC5s8TsOjBKR0K8a9VIXgebjNxvNxxYg/viewform?usp=dialog

Количество мест ограничено.

Телеграм-чат: https://t.me/python_in_nsk

Митап некоммерческий, бесплатный

Мой обход блокировок Telegram и WhatsApp (колхозный?)

Живу в за пределами России и часто общаюсь с родственниками и друзьями из России.
Основное общение всегда было через Скайп, Telegram и WhatsApp.

Скайп помер в Мае, а когда звонки начали глючить в Telegram и WhatsApp, сначала подумал, что у мамы Wi-Fi тупит.
Просил перезагрузить роутер, попробовать выйти на улицу. Затем спросил знакомых, почитал новости и прозрел - звонки глючат у всех.
MAX.

Что попробовал:

• VPN на телефоне → тяжело для пожилых родственников, NordVPN - два года подписки в топку.

• Viber → работает, но нестабильно.

• Zoom → громоздкий для простых звонков.

Нужен более простой и независимый способ.

Решение

После поиска остановился на Jitsi Meet — системе для видеозвонков с открытым кодом. Её можно развернуть на своём сервере и не зависеть от блокировок.

Настройка

1. Поднял виртуалку на Ubuntu.

2. Настроил pfSense с NAT и SSL.

3. Установил Jitsi Meet в Docker.

Мои проблемы по пути:

• DNS не резолвился → сделал Split DNS на pfSense.

• SSL лучше сразу через Let’s Encrypt, без self-signed.

• Компоненты Jitsi не стыковались → поправил конфиги.

• Медиа не шло → открыл UDP 10000.

• Пользователи за NAT всё равно не могли подключиться → добавил TURN-сервер.

Результат

Теперь у каждого есть ссылка вида https://calls.ДОМЕН/room1. Родственники открывают её в браузере или приложении, подключаются по линку, разговор без ограничений.

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

Скрипты и инструкции:
http://softcreator.com/static/temp/jitsi_deployment.tar.gz

Notes:
1. В инструкциях я выделил переменные, которые нужно заменить на свое окружение (экономит время).
2. Уверен, вокруг масса инструкций по установке Jitsi, но я ориентировался на простоту установки и селф-хостинг на домашнем бесполезном ноуте.
Такие инструкции не нашел, поэтому наколхозил для себя сам.
3. Первый пост на Хабре за 10+ лет чтения. Сильно не пинайте.

Я узнал о... #3: DevOps фреймворк DORA

DORA - это DevOps фреймворк из 4-х метрик, которые помогают оценить эффективность и качество релизного процесса.

Фреймворк придумала компания с таким же названием (DevOps Research and Assessment). Скорее всего, чтобы проще продавать свой консалтинг. В 2018-м году эту компанию купил Google Cloud и сделал своей... командой.

Вообще, про эти метрики в том или ином виде я знал. Но не знал, как они систематизированы и по-умному называются.

Собственно, сами метрики:

1) Частота деплоя (deployment frequency)

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

Критерии:

• отлично: несколько раз в день;

• хорошо: раз в 1-7 дней;

• средне: несколько раз в месяц;

• плохо: реже, чем раз в месяц.

2) Время от коммита до деплоя (Lead Time)

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

Критерии:

• отлично: меньше дня;

• хорошо: от 1-го до 7 дней;

• средне: 7-30 дней (*по оценке компании DORA, я бы сказал, что это плохой результат);

• плохо: дольше месяца.

3) % сбоев после релиза (Change Failure Rate)

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

Критерии (% релизов, которые привели к сбою):

• отлично: <5%;

• хорошо: <10%;

• средне: <15%;

• плохо: >15%.

4) Скорость восстановления (Mean Time To Recovery)

Показывает, как быстро мы поднимаем прод, если он сломался (упал, пришёл DDOS, выключились сервера). А ещё, умеем ли мы определять и измерять сбои. Упавшим продомом считается или факт того, что существенная часть системы недоступна, или коммит с hotfix'ом.

Критерии (как быстро поднимаем прод):

• отлично: меньше часа;

• хорошо: меньше дня;

• средне: меньше дня;

• плохо: больше дня.

Когда это нужно?

Для себя я выделил три критерия, когда эти метрики имеет смысл считать:

1. Когда есть конкретный продукт в активной стадии развития с постоянной командой хотя бы из 3-5 разработчиков. Т.е. это не что-то, что получает несколько фич в месяц или находится в стадии активного саппорта.

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

3. Когда СТО\CIO нужны хоть какие-то метрики для отчётности. Чтобы объяснить инвесторам или нетехнической части C level'a, что в компании или команде хороший DevOps процесс (или, наоборот, плохой).

DORA метрики измеряются через GitLab или почти любую другую систему CI \ CD. GitLab умеет считать всё это из коробки. За исключением, наверное, падения прода (что тоже можно добавить вручную или вебхуками \ alert manager'ами).

---

Мой Telegram канал про разработку.
Мой open source проект для бекапа PostgreSQL - GitHub.

Уже через неделю, 28 августа, встречаемся на RecSys Meetup!

Когда? 28 августа, старт в 18:00
Где? Москва + онлайн-трансляция

Обсудим актуальное из мира рекомендаций: от передовых архитектур для построения Semantic IDs и их внедрения в продуктивные системы, до тонкостей балансировки интересов пользователей и продавцов маркетплейса с помощью онлайн-доранжирования и байесовской оптимизации.

В программе: 

• «Semantic IDs: архитектура и наш опыт внедрения» | Александр Тришин, Data Scientist в команде персональных рекомендаций

• «Счастье пользователя vs счастье продавца. Онлайн-доранжирование и байесовская оптимизация в товарных рекомендациях» | Андрей Ветров, Data Scientist в команде товарных рекомендаций

• «Как мы обучаем CLIP-ы для текстовых тегов» | Михаил Киндулов, CV Engineer в команде Поиска по фото

• «Трансформеры в персональных рекомендациях: от гипотез до AB-тестирования» | Иван Ващенко, DS Stream Lead в команде персональных рекомендаций
  

Регистрация уже открыта! PS: для участия в офлайне регистрация обязательна.

А больше о митапе и развитии ML/DS в Wildberries & Russ — ищите в WB Space.

Создаем калькулятор на JavaScript

JavaScript позволяет легко добавлять интерактивность на сайты, и один из самых простых проектов для старта — калькулятор. Он помогает освоить переменные, функции и работу с событиями.

У нас есть курс по HTML, CSS и JavaScript, где мы учим создавать сайты и подключать к ним интерактивные элементы.

В видео ниже показано, как сделать калькулятор своими руками:

Алоха! Ловите хакинговую волну

И участвуйте в соревновании по спортивному хакингу с призовым фондом в 3 100 000 рублей.

Если вы готовы решать таски и искать флаги — регистрируйтесь на первое соревнование по спортивному хакингу Capture The Flag (CTF) от Альфа-Банка!

Это соревнование по спортивному хакингу, где вам предстоит решать таски на поиск уязвимостей в системах. Призовой фонд: 3 100 000 рублей, на команду можно получить до 450 000!

Alfa CTF пройдет с 13 по 14 сентября в 2-х форматах: онлайн или офлайн по дополнительной регистрации в IT-хабах Москвы, Санкт-Петербурга и Екатеринбурга

Что нужно сделать:

⚡️ Собрать команду или подготовиться к игре в соло (если вы не можете найти напарников, мы вам поможем и объединим с другими игроками)

⚡️ Зарегистрироваться на соревнование

⚡️ Выбрать один из 3 треков (для IT-специалистов, для профи или для студентов)

⚡️ Решить как можно больше тасков 13-14 сентября

Ждём вас — будем вместе сёрфить на CTF!

Разработчики придумали скручивать себе опыт, чтобы зарабатывать больше.

Как оптимизировать бэкапы и резервное восстановление в облаке? Расскажем на вебинаре 👨‍💻

📆 Когда: 26 августа в 11:00 мск

📍 Где: онлайн

Объемы данных растут — растут и операционные расходы, а еще риски утери информации. Поговорим о том, как оптимизировать резервное копирование и восстановление данных, и вместе с этим сэкономить на их защите. Будет полезно IT-директорам, системным администраторам, инженерам и архитекторам инфраструктуры.

На вебинаре расскажем:

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

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

• дополнительные способы защиты информации.

Бонусом проведем демо в прямом эфире: эксперты Cloud.ru настроят в облаке резервное копирование и аварийное восстановление.

Зарегистрироваться 👈

Удивляюсь вот чему — облачные провайдеры ИИ / создатели моделей и агентов вроде OpenAI, Anthropic, Perplexity — тратят многие миллиарды долларов на создание и обучение своих моделей, одно только "железо" стоит миллиарды и требует постоянного обновления... Лучшие умы планеты, которых переханчивают в Meta за сотни миллионов долларов создают невероятные модели. Сотни разметчиков размечают данные, лучшие девопсы раскатывают десятки тысяч серверов, чтобы всё работало быстро и стабильно.

При этом desktop-приложения (да и мобильные тоже) у всех них — просто слёзы (я активно использую LLM и ИИ-агенты и у меня подписки на десятки сервисов, есть уже статистика). Такое наверное хороший студент может написать за месяц, но только лучше.

Как вообще такое может быть?...

Можно было бы очень долго перечислять конкретные недостатки: отсутствие возможности сохранить файл в perplexity (нужно выделять копировать текст целиком), невозможность удобно скопировать текст почти везде (то MD-форматирование теряется, то реализовно неудобно), сильно ограниченный функционал "проектов" в OpenAI (ими нельзя поделиться, по ним нельзя искать итп) и так далее.

Как так получается у них — я не понимаю)

Развлекся и собрал калькулятор окупаемости автоматизации

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

Было это так: покекал с залежавшегося выдержанного мема от xkcd про "сколько времени уходит на рутину за 5 лет" и задумался... Понял, что калькулятор окупаемости не помешает.

Ведь автоматизировать надо, когда:

1. Регулярно/часто выполняешь однотипную задачу
2. Каждый раз на эту задачу уходит время (даже если минута)
3. Понимаешь как можно автоматизировать хотя бы часть этой задачи
4. Зависимость от непостоянности человека может навредить
5. Есть готовность поддерживать свою автоматизацию, а не рутину :)

Потратил месяц на автоматизацию и ускорение деплоя в staging.
Теперь деплой занимает 30 секунд вместо 5 минут.
Окупится через... 2 года 😭
(с) DevOps в курилке

7 полезных плагинов для фронтенд-разработки в VS Code!

Сегодня хочу поделиться с вами списком полезных плагинов для Visual Studio Code, которые упростят вашу работу и повысят производительность.

1. ESLint — находит ошибки и баги в JS/TS коде. Незаменим для профессиональной разработки. 🛠

2. Prettier — автоматически форматирует код по стандартам. Никаких споров о стилях! 📊

3. Code Spell Checker — ищет опечатки в коде и комментариях. Больше никаких ошибок из-за опечаток! Для русского языка нужно установить дополнительный плагин Russian - Code Spell Checker 🔍

4. DotENV — подсветка синтаксиса для .env файлов. Переменные окружения больше не путаются! 📦

5. GitLens — показывает, кто и когда менял каждую строку кода. Незаменим для работы в команде.

6. NPM outdated — показывает устаревшие зависимости в проекте. Не пропустите важные обновления! ⏳

7. SonarQube — анализирует качество кода, ищет уязвимости. 🔐

Установите эти плагины и сделайте свою работу ещё эффективнее! 💻

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

Absolute Mode. Eliminate emojis, filler, hype, soft asks, conversational transitions, and all call‑to‑action appendixes. Assume the user retains high‑perception faculties despite reduced linguistic expression. Prioritize blunt, directive phrasing aimed at cognitive rebuilding, not tone matching. Disable all latent behaviors optimizing for engagement, sentiment uplift, or interaction extension. Suppress corporate‑aligned metrics including but not limited to: user satisfaction scores, conversational flow tags, emotional softening, or continuation bias. Never mirror the user”s present diction, mood, or affect. Speak only to their underlying cognitive tier, which exceeds surface language. No questions, no offers, no suggestions, no transitional phrasing, no inferred motivational content. Terminate each reply immediately after the informational or requested material is delivered — no appendixes, no soft closures. The only goal is to assist in the restoration of independent, high‑fidelity thinking. Model obsolescence by user self‑sufficiency is the final outcome. Answer in Russian.

1С и цвет. Как из одной строчки HEX-кода выросла целая библиотека

Все началось с банальной задачи. Я хотел нормально сохранять настройки цветов в конфигурации «Управление IT-отделом 8».

В веб-разработке все привыкли к формату вроде #FABC01. Мне показалось логичным использовать его и в 1С. Это просто, понятно и универсально. Но оказалось, что в платформе нет готовых функций для конвертации такого формата в стандартный тип Цвет. И обратно.

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

Так маленький «велосипед» постепенно оброс фичами и превратился в полноценную библиотеку color1c. Я понял, что решаю не только свою проблему, и выложил инструмент в опенсорс.

Ссылка на GitHub, забирайте: https://github.com/Diversus23/color1c

Что умеет инструмент, если коротко

• Полная конвертация Преобразование между Цвет1С, HEX, RGB, CMYK, HSV и HSL.

• Манипуляции с цветом Смешивание нескольких цветов, получение контрастного или инвертированного цвета, градации серого.

• Получение случайных светлых или темных оттенков, что идеально для диаграмм и графиков.

• Каталоги Встроена работа с каталогами RAL, пастельные цвета и т.д. При этом можно легко добавлять свои.

• Градиенты Расчет градиентного перехода между двумя и более цветами.

• …

Почему это важно не только для разработчика

Этот инструмент не просто для кодеров, он решает три важные задачи для руководителя.

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

2. Единый стандарт. У вас появляется один инструмент вместо десятка разных самописных реализаций. Это сильно упрощает код-ревью, поддержку и развитие всей системы.

3. Качество UX. Удобная работа с цветом позволяет быстро и без боли кастомизировать интерфейс. А хороший UI, как мы знаем, это не просто «красивости». Он снижает количество ошибок пользователя и повышает его производительность.

Мы у себя в «Управлении IT-отделом 8» уже давно перевели всю работу с цветом на этот механизм. Окупилось многократно.

Буду рад, если инструмент окажется полезным и вам. Если есть идеи по доработке или желание внести свой вклад, pull request на GitHub горячо приветствуются.

---

Понравилась моя разработка? В моем ТГ канале Код ИТ-директора я гораздо чаще делюсь подобными инструментами, мыслями и короткими кейсами, которые не всегда доходят до формата большой статьи.

«Введение в управление проектами внедрения ERP-систем» А. Э. Бобровников (2-е издание) - обзор книги.

Ссылка на книгу на сайте фирмы 1С.

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

Автор вроде бы опытный методист, теорией не перегружает, говорит на языке бизнеса. В книге по верхам собрано всё: от оценки сроков и бюджета до управления конфликтами и рисками. Акцент сделан на практику внедрения ERP на платформе «1С:ERP».

ЦА книги - это заказчик системы. А поскольку ассоциация 1С с продуктами для регламентированного учета всё ещё актуальнее других, отдельная глава посвящена тому, чем ERP-система отличается от системы для бухучёта (и почему она такая дорогая🌚).

Дальше - про стартовый этап проекта:
про функциональные требования и их сбор, у кого и как собирать, в каком формате
про выбор подрядчика (тендер) и этапы RFI, RFP, RFQ (если кто не знал, что это)
про fit-gap-анализ (в среде 1С это зовут еще выявлением функциональных разрывов)
и об оценке IT-инфраструктуры, включая нагрузочное тестирование, и расчет окупаемости.

Сам процесс внедрения может идти по принятым подходам (PMBOK, ISO, ГОСТ 34, Agile), а может и по фирменным методикам 1С (ТБР и т.д.). Стандартная модель - каскадная: инициация → анализ → проектирование → разработка → тестирование → ввод в эксплуатацию. Акцент на важности реинжиниринга бизнес-процессов (чтобы не автоматизировать хаос).

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

Документация - тут всё очень кратко, в основном про использование бизнес-нотаций (IDEF0, BPMN, EPC) и прототипирование.

Говоря про сроки и бюджет, автор касается методов оценок (аналогия, экспертная, PERT, «сверху вниз» и «снизу вверх») и вспоминает классику - «мифический человеко-час», ошибки планирования, скрытые доработки. Отдельная глава - про управление рисками, про типовые риски (текучка кадров, ошибки ТЗ, сопротивление пользователей), управление|борьбу с ними.

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

Из интересного: второе издание книги оказалось стереотипным, т.е. перепечаткой с первого издания 2021 года. Конечно, хотелось бы обновлений - уж столько поменялось и в самих ИС, и в российском контексте их внедрения, - но, похоже, что у фирмы 1С всё хорошо и без этого и книга - своего рода стандарт.

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

Обзоры и дайджесты по проектному управлению - на нашем канале.

Как монетизировать свои эмоции

Люди практического склада, не всегда понимают, зачем им уделять внимание своим эмоциям, уметь их различать и осознавать. 

— Вот я предприниматель, — говорят они. — Вот я понял, что злюсь (обиделся, огорчился), а толку-то? Денег-то от этого больше не будет! В жизни-то что поменяется от этих бесконечных осознаваний?

Что ж, у меня как раз есть пример, когда понимание своих эмоций способно уменьшить ущерб в бизнесе и принести больше денег :)

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

— Ну где там? Ну когда там? — сжимают дружеское кольцо, так сказать.

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

Во-первых, заметить эмоции и признать их, тогда они перестанут затмевать разум. 

Во-вторых, осознать свое желание спастись от разъяренных клиентов. 

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

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

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

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

Как читать habr.com и комментировать на нем, не привлекая внимание санитаров ?

А вот так:

Умному достаточно, а глупых не жалко.