История про Вову и необжатые коннекторы за которые отвечал я

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

История одного факапа

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

У нас в компании тогда даже ходила шутка и директор говорила что однажды его выпорет. Шутка, конечно. Но поводы для неё были совсем не смешные.

И вот мы с Вовой едем к клиенту за 50 км от города. Он тянет сеть, я занимаюсь 1С. Вечером уезжаем, вроде все довольны. Я в его часть работы особо не вникал, и, как оказалось, зря.

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

Спрашиваю: «Что же у вас провода на полу валяются? Так ведь и убиться недолго». А она мне отвечает: «Так это же ваша фирма на той неделе сеть тянула к этому кабинету. Кстати, эти два компьютера так и не подключили к сети, но зато теперь тут везде провода».

И тут меня, что называется, бомбануло. 🔥

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

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

Я пошёл к Вове с одним вопросом: «Почему?» Ответ был гениален в своей простоте: «А я коннекторы забыл».

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

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

Почему это не просто косяк, а диагноз

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

Я до сих пор не понимаю мотивы таких людей.

• Сделать и бросить. Протянуть кабель, закрепить его в кабель-канал и обжать — это не сверхзадача. Это рутина.

• Солгать молчанием. Ну забыл ты коннекторы, бывает. Подойди к клиенту, извинись, скажи: «Мой косяк, не взял инструмент, приеду завтра и всё доделаю за час». Клиент бы понял. Но вместо этого он выбрал трусливое молчание, подставив и меня, и репутацию компании.

Такое поведение — маркер, который проявляется не только в работе. Уверен, что и в личной жизни у таких людей всё строится по тому же принципу: избежать ответственности, сделать вид, что проблемы не существует, и надеяться, что «само рассосётся».

А вы встречались с такими «Вовами» и что, на ваш взгляд, страшнее: сделать ошибку и признаться, или молча уйти в закат и никому ничего не сказать?

Если статья показалась вам интересной и полезной, то буду благодарен за подписку на мой Телеграм-канал Код ИТ-директора, где я описываю случаи из своей жизни и публикую полезный контент по ИТ.

Как понять, какие AI-модели действительно работают? Используем openrouter.ai

Если вы не хотите «читать в новостях хайп», а видеть реальную статистику по тому, какие AI-модели сейчас используют разработчики и компании — рекомендую заглянуть на https://openrouter.ai/rankings?view=trending

Что это?

• По сути, универсальный роутер для нейросетей. Можно в режиме чата попробовать практически любую популярную модель (GPT-5, Claude, Gemini, LLaMA и т.п.);

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

• Дополнительно можно подсмотреть, какие инструменты и интеграции сейчас «в ходу» — многие сервисы и плагины работают именно через OpenRouter.

• Есть бесплатные модели, которые тоже можно попробовать.

Зачем это?

• Любому человеку, кто интересуется темой AI будет полезно, какие технологии стоит рассматривать для пилотов и прототипов, а какие пока «сырые»;

• Можно сравнить отклик разных моделей под свои задачи (от техподдержки до генерации кода) без сложной инфраструктуры;

• Это объективный индикатор «пика популярности» моделей, а не просто маркетинговые пресс-релизы от вендоров.

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

На скриншоте, отображено какие инструменты используют OpenRouter и в каком объеме. Это, кстати, позволяет узнать в том числе и о новых инструментах.

Минусы

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

Также статистика OpenRouter показывает популярность моделей только в рамках своей платформы. Это важный, но не исчерпывающий срез рынка. Крупные компании могут использовать API напрямую от OpenAI, Anthropic или Google, и этот трафик в статистике OpenRouter не отражается. Статистика — это индикатор, но не абсолютная истина. Тем не менее, она показывает тренды.

---

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

Many-Notes: Простые заметки в Markdown на своем сервере

Наткнулся на Reddit на небольшой, но очень интересный проект для тех, кто любит полный контроль над своими данными и ценит минимализм. Это self-hosted приложение для заметок Many-Notes.

TL;DR: Коротко о главном

• Что это? Опенсорсное web-приложение для работы с Markdown-записями, спроектированное с акцентом на минимализм и полный контроль над данными. Вы разворачиваете его у себя (self-hosted).

• Главная фишка: Использует базу данных (SQLite по умолчанию, но поддерживается MariaDB, MySQL и PostgreSQL) для продвинутых функций вроде многопользовательности и быстрого поиска, но при этом все заметки физически лежат в виде .md файлов. База нужна не для хранения текста заметок, а для метаданных, пользователей и индексации поиска.

• Технологии: Написано на PHP, рассчитано на простую установку через Docker.

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

Что под капотом? Ключевые возможности:

Это не просто минималистичный блокнот - внутри полноценные инструменты для командной работы. Функциональность здесь серьезная:

• Многопользовательский режим и совместная работа: Можно заводить отдельных пользователей и давать им доступ к «хранилищам» (vaults). Это выводит инструмент из категории «личный блокнот» в категорию «командная база знаний».

• OAuth-авторизация: Поддерживается вход через GitHub, Google, Keycloak и другие популярные сервисы.

• Продвинутый редактор: Markdown + визуальный интерфейс (WYSIWYG), со сплит-панелью предпросмотра. Есть шаблоны, теги, поиск по обратным ссылкам, автосохранение.

• Быстрый поиск: Используется typesense для быстрого и отказоустойчивого поиска по заметкам. Но это отдельный сервис, его тоже нужно поднять.

• PWA (Progressive Web App): Приложение можно установить на рабочий стол или смартфон для более удобного доступа.

Полезные ссылки:

• Репозиторий на GitHub: https://github.com/brufdev/many-notes

• Обсуждение на Reddit: Тред в /r/selfhosted

А вы чем пользуетесь для ведения заметок? Предпочитаете облачные сервисы или self-hosted решения? Делитесь в комментариях.

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

PS: Были шероховатости в тексте поста, в частности по базе данных и php. Поправил

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 горячо приветствуются.

---

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

Качество техподдержки падает из-за нейросетей

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

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

Честно говоря, это не только про вендоров. Та же тенденция есть в любой IT-техподдержке — от SaaS-сервисов до внутренних helpdesk, ну и Сбер тоже не исключение. На мой взгляд, причин несколько:

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

• Ставка на «среднего» специалиста, а не эксперта. Задумка хорошая, что средний спец + нейросеть = эксперт, но вот на практике это почти всегда не так.

• Увлечение автоматизацией и «ботизацией» без продуманной логики. Нейросети поумнели, и почему бы их не использовать на полную катушку?

После появления в техподдержке LLM многое поменялось. В теории отличная штука: нейросеть может за секунды найти ответ в базе знаний. На практике мы получаем красивый текст (или голос), который звучит как решение, но не решает проблему, а заставляет обратившегося клиента уточнять какие-то вопросы, повторять одно и тоже, как попугай, и каждый раз начинать диалог заново. Так происходит потому что:

• Модель не понимает контекст, если вопрос нестандартный.

• Она «галлюцинирует» там, где не знает ответа.

• Клиент тратит время на проверку, а не на решение.

Я думаю, что ситуация будет усугубляться: всё больше компаний будут пытаться экономить, заменяя первую линию поддержки на чат-бота с LLM. Это общий тренд. И вместо того, чтобы решить проблему за 10 минут с инженером, клиент будет три раза «объяснять заново», прежде чем добьётся связи с человеком.

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

Я думаю вот о чем:

1. LLM как ассистент, а не как фронт. Модель подсказывает оператору варианты решения, а не отвечает напрямую клиенту.

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

3. Контекст — главное. Не подсовывать LLM голый вопрос, а давать историю обращений, конфигурацию системы, логи.

4. Метрики качества. Замерять не скорость ответа, а количество обращений, которые закрыты «с первого раза».

Вопрос в том, когда и как компании это будут делать правильно? Потому что гонка «а сэкономим-ка ещё бюджет» легко превратит службу поддержки в чат, от которого клиент убегает к конкурентам.

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

Было бы интересно обсудить с теми, кто из ИТ, как это организовано у Вас с техподдержкой? Да и вообще, кто что думает по этому поводу?

---

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

Там — больше «живых» заметок из окопов управления IT-бизнесом и возможность напрямую задать вопрос.

Подписывайтесь, что бы получать больше инсайтов без воды Тыц

Переход 1С на PostgreSQL и прогнозы до 2031 года

Ни для кого не секрет, что клиент‑серверный вариант 1С изначально затачивался под MS SQL. Вспоминаю год 2017-й и точно помню, что в тот момент Postgres ставили в основном те компании, которые хотели сэкономить. Плевались, но использовали. Чуть более или менее серьезная нагрузка — и всё.

Помню, как мы для «Управления IT‑отделом 8» написали расчет SLA по графикам техподдержки. На файловой базе и в MS SQL все работало прекрасно. Выпустили обновление, но один клиент на Postgres начал жаловаться. Долго выясняли, в чем дело. В конечном итоге я подключился к нему на тестовый сервер, прошелся отладчиком и… бинго! Действительно наша ошибка: не указали сортировку в одном из вложенных запросов. На файловой и на MS SQL такой запрос, повторю, работал отлично. Postgres в этом деле оказался строже — сказано в документации, что выборка не гарантирует порядок? Будьте добры предусмотрите это.

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

Если коротко, то вот главные грабли, на которые наступают при миграции 1С на PostgreSQL:

Проблема № 1: Деградация производительности. Миграция «в лоб» почти всегда приводит к проблемам с блокировками и работой планировщика запросов. Приходится переписывать код и оптимизировать его под PostgreSQL. Возможно, даже менять что‑то в самой платформе.

Проблема № 2: Кадры. Найти опытного DBA по Postgres, который глубоко понимает специфику 1С, значительно сложнее и дороже. С MS SQL всё было проще: установил, клик, клик — готово. Даже без тонких настроек многое работало «из коробки».

Ну и самое главное: миграция — это не просто смена СУБД. Это полноценный проект, требующий тестирования, переписывания узких мест в коде и, возможно, обучения команды. Экономия на лицензиях может быть полностью съедена затратами на внедрение и поддержку (да и не сказал бы, что тот же Postgres Pro дешевый).

А теперь о том, почему этот разговор вообще имеет смысл.

Раньше мы всегда советовали клиентам MS SQL как надежную и проверенную СУБД. Да, в 2015-м появился платный Postgres Pro, но, честно сказать, мы его всерьез не рассматривали. Зачем, если есть деньги на проверенный MS SQL? А если хотелось сэкономить — был бесплатный Postgres со всеми его тогдашними особенностями.

Но потом пришел 2022-й год, санкции вендоров и постепенная миграция стала трендом. А сейчас это уже не вопрос выбора, а вопрос времени.

Это не просто ощущения, это подтверждают цифры из исследования ЦСР.

Уже в 2024 году на новые продажи зарубежного ПО пришлось всего ~10% рынка. Прогноз до 2031 года следующий: российские решения для работы с базами данных могут занять до 99% новых продаж (!) Процесс импортозамещения будет идти, а если мы берем 1С, то тут в выигрыше PostgreSQL/Postgres Pro. Причины понятны: уход западных вендоров, требования регуляторов и развитие отечественных продуктов.

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

У меня вопрос. Планируете переход на PostgreSQL или, как и мы, пока живете на старом софте?

‑-

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

30 лет без дизайна и миллиард в кассе

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

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

Для тех, кто не в курсе: Craigslist - это что-то типа Авито, но в США, т.е. такая гигантская доска объявлений. Ее дизайн застрял где-то в 1998 году: синие ссылки, простейшая верстка, ноль графики. По любым современным меркам UI/UX - это катастрофа. При этом компания с крошечной командой зарабатывает сотни миллионов (а по некоторым оценкам - более миллиарда) долларов в год. Работает там от силы 50 человек (!) Если пересчитаем выручку, то окажется, что на каждого сотрудника приходится 4 млн. долларов в год (!) Очень круто!

И тут я смотрю на Craigslist и понимаю: их «ужасный» сайт — это моя «неудобная» гостевая книга, только в масштабе всей Америки. Они поняли то, чего не понял я в 20 лет, и не стали «чинить» то, что не сломано.

Почему этот «примитивный» дизайн работает и приносит миллиарды?

1. Скорость. Сайт загружается мгновенно. Нет тяжелых фреймворков, мегабайтов JavaScript и аналитических скриптов. Чистая функция.

2. Плотность информации. Никаких баннеров, всплывающих окон и модных карточек. Только текст и ссылки. Вы видите максимум полезной информации на одном экране.

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

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

Мой «улучшенный» форум вводил трение: регистрация, создание тем, сложная структура. Я убил легкость и анонимность. Точно так же любой «современный» редизайн Craigslist с React, модными анимациями и персонализацией убьет его главное преимущество - скорость и простоту.

Вывод для любого IT-руководителя:

Это вечный соблазн для любого технаря — переписать старое, «кривое», но работающее легаси на новый, блестящий стек. Нам кажется, что мы сделаем «лучше». Но главный вопрос: «лучше» для кого? Для вас или для пользователя, который просто хочет за 3 секунды решить свою задачу?

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

А в вашей практике есть свой внутренний «Craigslist»? Старый, неудобный, но незаменимый сервис, который все мечтают переписать, но боятся трогать?

---

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

Там — больше «живых» заметок из окопов управления IT-бизнесом и возможность напрямую задать вопрос.

Подписывайтесь, что бы получать больше инсайтов без воды Тыц

Эффект «стены Дурова», который я открыл за 10 лет до самого Дурова

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

2004 год. Я на 3-м курсе факультета прикладной математики и информатики АГУ (г. Майкоп), параллельно работаю программистом в математической школе при университете. Моя вотчина — программа для подсчёта рейтингов учеников, набор текстов для методичек и небольшой сайт с гостевой книгой.

Кто не застал — гостевая книга тогда была чем-то вроде бесконечного чата без регистрации. У детей мат. школы в ней кипела жизнь: по 100–200 сообщений в день (иногда даже больше), свои шутки, обсуждения задачек, разговоры «за жизнь». Формат был простой и лёгкий — написал ник, сообщение, и готово.

А я молодой, амбициозный и несу людям счастье)))

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

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

Догадываетесь, что было дальше? )))

Правильно. Провал… Ученики не стали использовать новый форум!

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

Для меня это было потрясение. Как так вообще? Я же хотел сделать как лучше для пользователей! Почему они не стали использовать новый форум?

Рефлексия и мои мысли на эту тему прилагаются:

• Новый форум не взлетел, т. к. старый был ламповый, легкий. Можно добавить одну запись под ником «Препод такой-то», а следующую «Иванов Иван». Было интересно переписываться в таком легком формате. Был вайб от использования такого формата. Может, помните в VK знаменитое: «Дуров, верни стену!»? Этот косяк Павла из той же оперы.

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

• Этот студенческий урок 20-летней давности я вспоминаю до сих пор каждый раз, когда моя команда предлагает «быстро улучшить» какой-нибудь работающий модуль. Часто при взгляде на проблему задаю себе вопрос: «Какую настоящую работу выполняет для пользователя этот старый, неудобный, но привычный функционал? И не убьем ли мы ту самую "ламповость", просто заменив ее на "правильное" решение?»

Вот такая история.

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

---

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

Про сотрудника Игоря, или про того, кто ни в чем никогда не виноват

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

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

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

Причём если ошибка была в коде, который он написал. Игорь каким-то волшебным образом умудрялся всегда находить слова типа: «А вот помнишь, ты мне говорил вот это сделать, я так и сделал, и вот в результате появилась ошибка». Иногда доходило до смешного: на форме при разработке были какие-то орфографические ошибки, и он начинал юлить. )) Мне в какой-то момент даже стало интересно, а в принципе он может сказать: «Я сделал здесь ошибку». И знаете что? За 5 лет работы с ним я так и не добился такого признания.

Что еще было: был сон на рабочем месте в рабочее время, несколько жестких будунищ после выходных, и в таких случаях я всегда его отправлял домой, потому что толку от такого сотрудника нет никакого (это другая история). Но нет. Он никогда не виноват. )))

Минутка рефлексии и мои рассуждения по поводу таких сотрудников:

1. Сотрудник, не берущий на себя ответственность, обходится компании дороже, чем кажется. Его реальная стоимость — это не только его зарплата, но и десятки часов моего времени как руководителя, потраченные на микроменеджмент и исправление последствий и принятие решений там, где это должен был сделать он. Я, как руководитель, хочу платить деньги профессионалу, а не маленькому ребенку.

2. На собеседовании нужно всегда задавать вопрос об ошибках. Простой вопрос «Расскажите о своей самой серьезной ошибке и что вы сделали, чтобы ее исправить?» мгновенно выявляет «Игорей». Они либо не могут вспомнить ни одной ошибки, либо рассказывают историю, где виноваты были обстоятельства или коллеги. Так не бывает в реальной жизни. Мы все ошибаемся и это нужно уметь признавать.

3. Нужно вовремя принимать решение об увольнении. Моя ошибка была в том, что я держал Игоря 5 лет в надежде, что он изменится. Люди меняются крайне редко. Моя задача как руководителя — не быть психотерапевтом, а собирать эффективную команду. Я затянул с этим решением, и это стоило компании и денег, и нервов.

Такие дела…

А у вас в практике был такой коллега — Игорь, который никогда не берет на себя ответственность и пытается ее спихнуть на другого человека?

Больше полезной информации про ИТ-управление, спорные вопросы в найме, менеджменте и планировании — в блоге Код ИТ-директора в Telegram, VK, Дзен, Instagram*, FB*. Подпишитесь, чтобы не пропустить новые тексты!

_{*Признаны экстремистскими организациями и запрещены на территории РФ.}