Не каждый разработчик мечтает стать руководителем. И это нормально.
У меня есть старый друг Семён. Он толковый разработчик и работает в одном из крупнейших финтехов страны с основным стеком Java. Большой финтех, море возможностей, и логично было бы предположить, что он давно метит в тимлиды или руководителем отдела. Мы как-то разговорились об этом.
Ответ меня не то чтобы удивил, но заставил в очередной раз задуматься. Семён спокойно сказал: «Виталик, мне это не нужно. Я люблю писать код, решать сложные задачи. Мне не нужны вот эти вот созвоны, бюджеты, отчеты и чужие проблемы. Да, зарплата ниже. Зато нервы целее, и я занимаюсь тем, что мне действительно нравится».
И ведь он абсолютно прав. В IT-сфере почему-то принято считать, что единственный путь развития для хорошего специалиста — это вертикальный рост в менеджмент. Если ты крутой спец и не хочешь становиться руководителем, на тебя смотрят с подозрением. Словно ты без амбиций или просто ленивый.
Это опасное заблуждение.
Самая частая и дорогая ошибка в бизнесе — сделать из лучшего инженера худшего менеджера. Компания теряет сильного технического специалиста и приобретает слабого, выгоревшего управленца, который страдает сам и мучает команду.
Кодить и управлять людьми — это две разные профессии. Хороший руководитель — это не тот, кто пишет самый изящный код. Это тот, кто:
Берет на себя ответственность. Не ищет виноватых, а ищет решение.
Умеет говорить с людьми. Может и задачу поставить, и конфликт разрулить, и просто услышать человека.
Создает климат в коллективе. Понимает, что токсичная атмосфера убивает продуктивность быстрее, чем любая техническая проблема.
Это отдельный, сложный набор навыков. И он никак не связан с умением виртуозно настраивать CI/CD или оптимизировать запросы к базе данных.
Поэтому, прежде чем гнаться за должностью тимлида или начальника отдела, просто честно спросите себя: «А мне это точно надо?». Может, ваш путь — это горизонтальное развитие? Стать незаменимым экспертом в своей области, менторить новичков, заниматься самыми сложными проектами. Это не менее достойный и уважаемый путь.
Интересно, а как у вас в компаниях? Сталкивались с ситуацией, когда отличного спеца «повышали» до плохого менеджера? Или, может, вы сами сделали такой же осознанный выбор, как мой товарищ?
Код ИТ-директора
#Истории_КИД
У меня есть старый друг Семён. Он толковый разработчик и работает в одном из крупнейших финтехов страны с основным стеком Java. Большой финтех, море возможностей, и логично было бы предположить, что он давно метит в тимлиды или руководителем отдела. Мы как-то разговорились об этом.
Ответ меня не то чтобы удивил, но заставил в очередной раз задуматься. Семён спокойно сказал: «Виталик, мне это не нужно. Я люблю писать код, решать сложные задачи. Мне не нужны вот эти вот созвоны, бюджеты, отчеты и чужие проблемы. Да, зарплата ниже. Зато нервы целее, и я занимаюсь тем, что мне действительно нравится».
И ведь он абсолютно прав. В IT-сфере почему-то принято считать, что единственный путь развития для хорошего специалиста — это вертикальный рост в менеджмент. Если ты крутой спец и не хочешь становиться руководителем, на тебя смотрят с подозрением. Словно ты без амбиций или просто ленивый.
Это опасное заблуждение.
Самая частая и дорогая ошибка в бизнесе — сделать из лучшего инженера худшего менеджера. Компания теряет сильного технического специалиста и приобретает слабого, выгоревшего управленца, который страдает сам и мучает команду.
Кодить и управлять людьми — это две разные профессии. Хороший руководитель — это не тот, кто пишет самый изящный код. Это тот, кто:
Берет на себя ответственность. Не ищет виноватых, а ищет решение.
Умеет говорить с людьми. Может и задачу поставить, и конфликт разрулить, и просто услышать человека.
Создает климат в коллективе. Понимает, что токсичная атмосфера убивает продуктивность быстрее, чем любая техническая проблема.
Это отдельный, сложный набор навыков. И он никак не связан с умением виртуозно настраивать CI/CD или оптимизировать запросы к базе данных.
Поэтому, прежде чем гнаться за должностью тимлида или начальника отдела, просто честно спросите себя: «А мне это точно надо?». Может, ваш путь — это горизонтальное развитие? Стать незаменимым экспертом в своей области, менторить новичков, заниматься самыми сложными проектами. Это не менее достойный и уважаемый путь.
Интересно, а как у вас в компаниях? Сталкивались с ситуацией, когда отличного спеца «повышали» до плохого менеджера? Или, может, вы сами сделали такой же осознанный выбор, как мой товарищ?
Код ИТ-директора
#Истории_КИД
❤2👍1🔥1👏1🌭1
Нашел интересный сервис энтузиаста-разработчика, который создал сервис для обработки фото. В частности поддерживается создание цветных фотографий из черно-белых, реставрация старых фотоснимков, удаление фона, улучшение качества фотографий (апскейл). Но я бы не приводил этот сервис, если бы не одно НО: сервис абсолютно БЕСПЛАТНЫЙ.
Пользуйтесь: https://photomagics.ru?utm_source=Telegram&utm_medium=social&utm_campaign=26088681
Код ИТ-директора
Пользуйтесь: https://photomagics.ru?utm_source=Telegram&utm_medium=social&utm_campaign=26088681
Код ИТ-директора
Фотомагия
Сделать фото лучше онлайн бесплатно
Бесплатное улучшение фотографий онлайн
👍1🤬1
История про Вову и необжатые коннекторы за которые отвечал я
Иногда одна короткая история из прошлого говорит об ответственности больше, чем толстая книга по управлению. Недавно как раз вспомнил один случай из далекого 2007 года, который отлично иллюстрирует, почему некоторые специалисты навсегда остаются просто исполнителями с которыми никто не хочет работать.
История одного факапа
В тот момент я работал в компании, которая обслуживала клиентов по 1С. Один из них, бюджетная организация, попросил нас вдобавок к основной работе подключить к локальной сети пару компьютеров. Не наш основной профиль, но директор решила, что это не проблема. В штате как раз был админ, назовем его Вова.
У нас в компании тогда даже ходила шутка и директор говорила что однажды его выпорет. Шутка, конечно. Но поводы для неё были совсем не смешные.
И вот мы с Вовой едем к клиенту за 50 км от города. Он тянет сеть, я занимаюсь 1С. Вечером уезжаем, вроде все довольны. Я в его часть работы особо не вникал, и, как оказалось, зря.
На следующей неделе я снова приезжаю к ним. Идем с бухом клиента в другой кабинет и прямо на моих глазах бухгалтер, милая женщина, зацепилась ногами за провода на полу и чуть не упала. Я смотрю, а у них по всему этому кабинету лежат кабели, ничем не закрепленные. Просто скопом лежат на проходе в перемешку.
Спрашиваю: «Что же у вас провода на полу валяются? Так ведь и убиться недолго». А она мне отвечает: «Так это же ваша фирма на той неделе сеть тянула к этому кабинету. Кстати, эти два компьютера так и не подключили к сети, но зато теперь тут везде провода».
И тут меня, что называется, бомбануло. 🔥
Претензию за чужую работу выслушиваю я. Начинаю распутывать этот клубок и вижу апогей картины: на полу лежит пару кабелей, причем размера больше чем нужна, а на конце этих проводов просто голые жилы. Провод даже не обжат. Вроде бы всего два кабеля, но ощущение что их больше.
Вернувшись в офис, я рассказал всё директору. Она в очередной раз пообещала Вове ремень, а меня попросила проконтролировать, чтобы он всё доделал.
Я пошёл к Вове с одним вопросом: «Почему?» Ответ был гениален в своей простоте: «А я коннекторы забыл».
То есть, человек приехал за 50 км, протянул провод, понял, что обжать его нечем, и решил, что лучший выход — это просто всё бросить и молча уехать. Ни слова не сказав ни клиенту, ни мне, ни директору. Он просто сделал вид, что работа выполнена.
Естественно, мы поехали снова. Я, хоть это и не мой профиль, помогал ему всё доделывать, потому что смотреть на эту бухгалтершу было жалко. Под моим контролем он всё закрепил к стене, обжал и все подключил.
Почему это не просто косяк, а диагноз
Таких «Вов» на самом деле полно. Сейчас модно кивать на зумеров, которые могут договориться о выходе на работу и просто не прийти. Но эта история, напомню, из 2007-го. Тогда зумеры только рождались. Так что проблема не в поколении. Проблема в ответственности.
Я до сих пор не понимаю мотивы таких людей.
• Сделать и бросить. Протянуть кабель, закрепить его в кабель-канал и обжать — это не сверхзадача. Это рутина.
• Солгать молчанием. Ну забыл ты коннекторы, бывает. Подойди к клиенту, извинись, скажи: «Мой косяк, не взял инструмент, приеду завтра и всё доделаю за час». Клиент бы понял. Но вместо этого он выбрал трусливое молчание, подставив и меня, и репутацию компании.
Такое поведение — маркер, который проявляется не только в работе. Уверен, что и в личной жизни у таких людей всё строится по тому же принципу: избежать ответственности, сделать вид, что проблемы не существует, и надеяться, что «само рассосётся».
Вывод: «Вова» — это бомба замедленного действия для бизнеса
В конце поста логично встают два вопроса: нужны ли такие «Вовы» компании и что с ними делать?
Мой ответ: категорически не нужны. И дело здесь не в морали, а в чистой математике и управлении рисками.
Давайте просто посчитаем ущерб от забытых коннекторов:
Иногда одна короткая история из прошлого говорит об ответственности больше, чем толстая книга по управлению. Недавно как раз вспомнил один случай из далекого 2007 года, который отлично иллюстрирует, почему некоторые специалисты навсегда остаются просто исполнителями с которыми никто не хочет работать.
История одного факапа
В тот момент я работал в компании, которая обслуживала клиентов по 1С. Один из них, бюджетная организация, попросил нас вдобавок к основной работе подключить к локальной сети пару компьютеров. Не наш основной профиль, но директор решила, что это не проблема. В штате как раз был админ, назовем его Вова.
У нас в компании тогда даже ходила шутка и директор говорила что однажды его выпорет. Шутка, конечно. Но поводы для неё были совсем не смешные.
И вот мы с Вовой едем к клиенту за 50 км от города. Он тянет сеть, я занимаюсь 1С. Вечером уезжаем, вроде все довольны. Я в его часть работы особо не вникал, и, как оказалось, зря.
На следующей неделе я снова приезжаю к ним. Идем с бухом клиента в другой кабинет и прямо на моих глазах бухгалтер, милая женщина, зацепилась ногами за провода на полу и чуть не упала. Я смотрю, а у них по всему этому кабинету лежат кабели, ничем не закрепленные. Просто скопом лежат на проходе в перемешку.
Спрашиваю: «Что же у вас провода на полу валяются? Так ведь и убиться недолго». А она мне отвечает: «Так это же ваша фирма на той неделе сеть тянула к этому кабинету. Кстати, эти два компьютера так и не подключили к сети, но зато теперь тут везде провода».
И тут меня, что называется, бомбануло. 🔥
Претензию за чужую работу выслушиваю я. Начинаю распутывать этот клубок и вижу апогей картины: на полу лежит пару кабелей, причем размера больше чем нужна, а на конце этих проводов просто голые жилы. Провод даже не обжат. Вроде бы всего два кабеля, но ощущение что их больше.
Вернувшись в офис, я рассказал всё директору. Она в очередной раз пообещала Вове ремень, а меня попросила проконтролировать, чтобы он всё доделал.
Я пошёл к Вове с одним вопросом: «Почему?» Ответ был гениален в своей простоте: «А я коннекторы забыл».
То есть, человек приехал за 50 км, протянул провод, понял, что обжать его нечем, и решил, что лучший выход — это просто всё бросить и молча уехать. Ни слова не сказав ни клиенту, ни мне, ни директору. Он просто сделал вид, что работа выполнена.
Естественно, мы поехали снова. Я, хоть это и не мой профиль, помогал ему всё доделывать, потому что смотреть на эту бухгалтершу было жалко. Под моим контролем он всё закрепил к стене, обжал и все подключил.
Почему это не просто косяк, а диагноз
Таких «Вов» на самом деле полно. Сейчас модно кивать на зумеров, которые могут договориться о выходе на работу и просто не прийти. Но эта история, напомню, из 2007-го. Тогда зумеры только рождались. Так что проблема не в поколении. Проблема в ответственности.
Я до сих пор не понимаю мотивы таких людей.
• Сделать и бросить. Протянуть кабель, закрепить его в кабель-канал и обжать — это не сверхзадача. Это рутина.
• Солгать молчанием. Ну забыл ты коннекторы, бывает. Подойди к клиенту, извинись, скажи: «Мой косяк, не взял инструмент, приеду завтра и всё доделаю за час». Клиент бы понял. Но вместо этого он выбрал трусливое молчание, подставив и меня, и репутацию компании.
Такое поведение — маркер, который проявляется не только в работе. Уверен, что и в личной жизни у таких людей всё строится по тому же принципу: избежать ответственности, сделать вид, что проблемы не существует, и надеяться, что «само рассосётся».
Вывод: «Вова» — это бомба замедленного действия для бизнеса
В конце поста логично встают два вопроса: нужны ли такие «Вовы» компании и что с ними делать?
Мой ответ: категорически не нужны. И дело здесь не в морали, а в чистой математике и управлении рисками.
Давайте просто посчитаем ущерб от забытых коннекторов:
• Две поездки вместо одной (+100 км).
• Моё время, потраченное на выяснение и контроль.
• Его время, потраченное на повторную работу.
• Самое главное — удар по лояльности клиента, который столкнулся с бардаком и неработающим решением.
Финансовые потери это мелочь против главного ущерба от «Вовы». А главный ущерб - это создание непредсказуемости.
Ответственный сотрудник может ошибиться. Он может даже сжечь сервер. Но он тут же придёт и скажет: «Я накосячил. Вот здесь. План действий такой». Его ошибка — это управляемый процесс. Вы знаете о проблеме и можете на неё реагировать.
«Вова» — это неуправляемый хаос. Он молчит. Он создаёт в ваших бизнес-процессах чёрные дыры, о существовании которых вы узнаете, только когда туда свалится клиент или проект. Такой сотрудник — это ходячий баг в вашей системе управления. Вы никогда не знаете, что у него на самом деле сделано, а что «сделано на словах».
Именно поэтому ошибка простительна, а трусливое молчание — нет. Ошибка — это рабочий момент. Молчание — это саботаж, осознанный или нет.
Привычка доводить дело до конца и не подставлять команду это фундамент, без которого любой опыт и знания бесполезны.
А вы встречались с такими «Вовами» и что, на ваш взгляд, страшнее: сделать ошибку и признаться, или молча уйти в закат и никому ничего не сказать?
• Моё время, потраченное на выяснение и контроль.
• Его время, потраченное на повторную работу.
• Самое главное — удар по лояльности клиента, который столкнулся с бардаком и неработающим решением.
Финансовые потери это мелочь против главного ущерба от «Вовы». А главный ущерб - это создание непредсказуемости.
Ответственный сотрудник может ошибиться. Он может даже сжечь сервер. Но он тут же придёт и скажет: «Я накосячил. Вот здесь. План действий такой». Его ошибка — это управляемый процесс. Вы знаете о проблеме и можете на неё реагировать.
«Вова» — это неуправляемый хаос. Он молчит. Он создаёт в ваших бизнес-процессах чёрные дыры, о существовании которых вы узнаете, только когда туда свалится клиент или проект. Такой сотрудник — это ходячий баг в вашей системе управления. Вы никогда не знаете, что у него на самом деле сделано, а что «сделано на словах».
Именно поэтому ошибка простительна, а трусливое молчание — нет. Ошибка — это рабочий момент. Молчание — это саботаж, осознанный или нет.
Привычка доводить дело до конца и не подставлять команду это фундамент, без которого любой опыт и знания бесполезны.
А вы встречались с такими «Вовами» и что, на ваш взгляд, страшнее: сделать ошибку и признаться, или молча уйти в закат и никому ничего не сказать?
🔥1
Автоматическая сборка PDF-документации из Markdown в GitLab CI
Готовили релиз нашего нового решения для 1С по отправке СМС-подтверждений и столкнулись с классической задачей. Документацию мы ведем в Markdown. Это удобно для нас, но не для конечного клиента.
Клиенту нужен привычный PDF. Простой и надежный.
Главный вопрос: как автоматически собирать несколько
Решение нашлось в связке Docker и Pandoc. Вот пошаговый план:
Основа: Берем готовый Docker-образ с Pandoc.
Подготовка: Внутрь контейнера копируем нашу папку
Сборка: Запускаем Pandoc, который конвертирует все файлы в единый PDF.
Выгрузка: Копируем готовый PDF из контейнера и сохраняем его как артефакт в GitLab.
Подход универсален, неважно, где запущен Docker. Вся логика инкапсулирована в контейнере.
Подробно описал как все это настроить в Gitlab CI и выложи ссылки на github 👉 здесь
Получилось неплохо
Готовили релиз нашего нового решения для 1С по отправке СМС-подтверждений и столкнулись с классической задачей. Документацию мы ведем в Markdown. Это удобно для нас, но не для конечного клиента.
Клиенту нужен привычный PDF. Простой и надежный.
Главный вопрос: как автоматически собирать несколько
.md файлов с картинками в один PDF-файл прямо в пайплайне GitLab CI? Особенно когда твои раннеры работают на PowerShell под Windows, как у нас.Решение нашлось в связке Docker и Pandoc. Вот пошаговый план:
Основа: Берем готовый Docker-образ с Pandoc.
Подготовка: Внутрь контейнера копируем нашу папку
docs с Markdown-файлами.Сборка: Запускаем Pandoc, который конвертирует все файлы в единый PDF.
Выгрузка: Копируем готовый PDF из контейнера и сохраняем его как артефакт в GitLab.
Подход универсален, неважно, где запущен Docker. Вся логика инкапсулирована в контейнере.
Подробно описал как все это настроить в Gitlab CI и выложи ссылки на github 👉 здесь
Получилось неплохо
softonit.ru
Подтверждение дисконтной карты по SMS в 1С
Каталог программ и услуг
🔥2
Про любимый браузер
До сих пор не понимаю людей, которые используют Google Chrome или Edge. Понятно, что это вопрос холивара, какой инструмент лучше или хуже — большой вопрос.
Лично я использую Яндекс Браузер и уже очень давно. Самое главное, что меня подкупило — это кнопка с озвучкой на русском языке в YouTube :)
Часто смотрю зарубежные каналы и мне этого очень не хватало.
Ну круто же!
Еще тоже фича, когда смотришь видео на вкладке и переключаешься на другую вкладку в браузере, видео выносится в другое маленькое окошко и можно продолжать его смотреть.
Что есть такого в Chrome, что нужно использовать его? В Яндекс Браузере есть всё что в Chrome, и даже больше. Расширения ставятся такие же как и в Хром, а еще есть нейроредактор, который позволяет быстро править тексты, есть пересказ на каждой странице в браузере, есть возможность использовать Яндекс Музыку прямо в браузере. Просто нажал и тебе всё пересказал браузер кратко или не очень.
Ставьте себе Яндекс Браузер и пользуйтесь.
До сих пор не понимаю людей, которые используют Google Chrome или Edge. Понятно, что это вопрос холивара, какой инструмент лучше или хуже — большой вопрос.
Лично я использую Яндекс Браузер и уже очень давно. Самое главное, что меня подкупило — это кнопка с озвучкой на русском языке в YouTube :)
Часто смотрю зарубежные каналы и мне этого очень не хватало.
Ну круто же!
Еще тоже фича, когда смотришь видео на вкладке и переключаешься на другую вкладку в браузере, видео выносится в другое маленькое окошко и можно продолжать его смотреть.
Что есть такого в Chrome, что нужно использовать его? В Яндекс Браузере есть всё что в Chrome, и даже больше. Расширения ставятся такие же как и в Хром, а еще есть нейроредактор, который позволяет быстро править тексты, есть пересказ на каждой странице в браузере, есть возможность использовать Яндекс Музыку прямо в браузере. Просто нажал и тебе всё пересказал браузер кратко или не очень.
Ставьте себе Яндекс Браузер и пользуйтесь.
🔥1🤔1💩1🤝1
Две больших коллекции бесплатных SVG-иконок
В мобильном приложении сейчас активно используем библиотеку SVG-иконок Lucide (лицензия ISC License — похожа на MIT):
https://lucide.dev/icons/?utm_source=Telegram&utm_medium=social&utm_campaign=26209753
Можно задать размер, толщину и цвет.
Еще, мне нравится коллекция Heroicons (MIT License):
https://heroicons.com/?utm_source=Telegram&utm_medium=social&utm_campaign=26209753
Она поменьше, но иконки тоже неплохие. Эту коллекцию используем на сайте Софтонит.
Сохраняйте, чтобы не забыть.
Код ИТ-директора
В мобильном приложении сейчас активно используем библиотеку SVG-иконок Lucide (лицензия ISC License — похожа на MIT):
https://lucide.dev/icons/?utm_source=Telegram&utm_medium=social&utm_campaign=26209753
Можно задать размер, толщину и цвет.
Еще, мне нравится коллекция Heroicons (MIT License):
https://heroicons.com/?utm_source=Telegram&utm_medium=social&utm_campaign=26209753
Она поменьше, но иконки тоже неплохие. Эту коллекцию используем на сайте Софтонит.
Сохраняйте, чтобы не забыть.
Код ИТ-директора
Lucide
Lucide Icons
Beautiful & consistent icon toolkit made by the community.
👍1🔥1
Как проверять качество кода в 1С? Готовая сборка SonarQube для 1С в Docker
Качество кода в 1С — тема вечная и часто недооцененная. Кривой код сложнее поддерживать, в нем чаще возникают ошибки, а ввод нового разработчика в проект превращается в пытку (как и добавление новых фич в таком коде).
Чтобы систематизировать борьбу с техническим долгом, мы у себя в CI/CD давно используем статический анализатор SonarQube Community. Это мощный (и бесплатный) инструмент, который помогает отлавливать ошибки, уязвимости и просто неудачные решения в коде до того, как они нанесут реальный ущерб.
Подготовил для вас инструкцию по быстрой настройке
➡️ https://codeitdir.ru/tools/sonarqube1c/?utm_source=Telegram&utm_medium=social&utm_campaign=26238670
Качество кода в 1С — тема вечная и часто недооцененная. Кривой код сложнее поддерживать, в нем чаще возникают ошибки, а ввод нового разработчика в проект превращается в пытку (как и добавление новых фич в таком коде).
Чтобы систематизировать борьбу с техническим долгом, мы у себя в CI/CD давно используем статический анализатор SonarQube Community. Это мощный (и бесплатный) инструмент, который помогает отлавливать ошибки, уязвимости и просто неудачные решения в коде до того, как они нанесут реальный ущерб.
Подготовил для вас инструкцию по быстрой настройке
➡️ https://codeitdir.ru/tools/sonarqube1c/?utm_source=Telegram&utm_medium=social&utm_campaign=26238670
Нейронки конечно могут… Взял ради прикола текст предыдущего поста и добавил в промпт:
Вставил это сначала в бесплатный Qwen, а потом в ChatGPT 5
Получились прям продающие страницы 🙂
Взгляните-ка на скриншот. Вот так выглядит оформление от ChatGPT. Qwen тоже получилось не плохо, ниже скину ссылка для того, чтобы поглядеть.
Что это дает обычному пользователю?
Мы можем красиво и абсолютно бесплатно преобразовать любой скучный текст в красивый HTML-документ, сохранить его потом в PDF и отправлять клиентам. Или прям так отправлять. Таким же образом можно делать:
- Коммерческие предложения
- Презентации
- Портфолио
- Гайды, уроки, инструкции
И все это можно сделать бесплатно в Qwen. В ChatGPT у меня подписка, но думаю и там можно на бесплатном тарифе что-то подобное сделать.
На всякий случай прилагаю оформление в виде архивов с HTML, которые можно скачать и посмотреть:
ChatGPT
Qwen
Преобразуй этот документ в красивую HTML-страницу с современным дизайном:
[ВСТАВЬ СВОЙ ТЕКСТ/ДОКУМЕНТ]
Требования к дизайну:
- Современный стиль с градиентами и тенями
- Плавные анимации при скролле
- Адаптивный дизайн для мобильных
- Красивая типографика с контрастом
- Интерактивные элементы (hover-эффекты)
- Используй карточки для блоков информации
- Добавь цветовые акценты и иконки
Создай полный HTML файл с встроенным CSS и JavaScript.
Вставил это сначала в бесплатный Qwen, а потом в ChatGPT 5
Получились прям продающие страницы 🙂
Взгляните-ка на скриншот. Вот так выглядит оформление от ChatGPT. Qwen тоже получилось не плохо, ниже скину ссылка для того, чтобы поглядеть.
Что это дает обычному пользователю?
Мы можем красиво и абсолютно бесплатно преобразовать любой скучный текст в красивый HTML-документ, сохранить его потом в PDF и отправлять клиентам. Или прям так отправлять. Таким же образом можно делать:
- Коммерческие предложения
- Презентации
- Портфолио
- Гайды, уроки, инструкции
И все это можно сделать бесплатно в Qwen. В ChatGPT у меня подписка, но думаю и там можно на бесплатном тарифе что-то подобное сделать.
На всякий случай прилагаю оформление в виде архивов с HTML, которые можно скачать и посмотреть:
ChatGPT
Qwen
🔥3👍1👏1
Я решил убить старую базу знаний на Битрикс с документацией по нашим продуктам. Часть 1
Меня беспокоит наша база знаний с документацией по нашему ПО на сайте. Она выглядит не особо и содержит ряд фундаментальных проблем, которые портят жизнь как разработчикам, так и пользователям.
Сайт Софтонит сделан на Битрикс, и изначально мы выбрали встроенный в эту платформу механизм для создания базы знаний. Это было в 2016 году, и на тот момент казалось, что всё выглядит хорошо и в целом всё удобно и классно.
Надо зайти и изменить статью? Открываешь админку сайта, заливаешь картинки, добавляешь текст статьи на сайте, и она сразу же отображается для клиентов. Удобненько (как тогда казалось).
Время идет, всё меняется, и вот уже ты видишь проблемы со старым подходом:
- В Битрикс оказывается неудобный встроенный редактор статей. Редактируешь статью, сохраняешь, в админке она выглядит так, а для пользователей верстка едет. Переключаешь в режим HTML, а там левые теги. Приходится их вычищать.
- Понимаешь, что есть проблемы с добавлением и изменением изображений. Нельзя вставлять изображения в статью из буфера обмена. Также изображение добавляется в медиабиблиотеку, а стандартный редактор использует уже изображение оттуда. В целом это работает не очень быстро. Процесс обновления одного скриншота превращается в квест из девяти кругов ада: сделай скриншот, сохрани файл, зайди в админку, открой медиабиблиотеку, загрузи файл, скопируй ссылку, вернись в статью, вставь ссылку… Хочется просто перетащить картинку в редактор, а вместо этого ты тратишь 10 минут на рутину. А если нужно поменять 20 картинок? Это просто воровство времени у команды разработки. Жесть.
- Плохой поиск. Прям очень. Было пару раз, что поиск отваливался в базе знаний после обновления Битрикс, и за мной ходила менеджер по продажам и говорила, как ей показывать какие-то фичи клиентам и отвечать на их вопросы, если она не может ничего найти в базе знаний. А изменить ты особенно ничего не можешь. Не будешь же править Битрикс и искать, в чём косяк. Потом это, конечно, всё восстанавливалось со следующими обновлениями, но осадочек от этого остался.
- Но всё это мелочи по сравнению с главной проблемой, которая меня бесит: документация живёт своей жизнью, отдельно от кода. Разработчик выкатил фикс, а документация осталась старой. В итоге клиент читает одно, а в программе видит другое. Это прямой путь к потере доверия. И именно этот разрыв стал для меня последней каплей.
Я задумал на сайте Софтонит заменить старую документацию и использовать концепцию Docs-as-Code. Что это вообще за концепция?
Всё просто — работаем с документацией так же, как и с исходным кодом программы. Заводим папочку «docs», и все скриншоты и файлы в текстовом формате (обычно это markdown) пишем и изменяем тут же, а потом пушим всё в Git. При пушах срабатывает линия сборки, которая автоматически разместит документацию на нашем сайте. При таком подходе мы получим:
- Версионирование документации. Удобно видеть версии документации.
- Документация соответствует коду, который изменяется, и она обновится тогда, когда мы выпустим релиз. Т.е. документация следует за кодом (но тут всё зависит от того, как вы настроите линию сборки).
- Можно использовать любимые markdown-редакторы. Лично мне нравится редактор Visual Studio Code и плагин для Markdown. Оно умеет и из буфера файлы вставлять в текст, и даже есть свой линтер для формата Markdown (подчеркивает желтым, если ты что-то не так делаешь в оформлении текста).
- Мы отделяем текст документации от оформления этого текста на сайте. Есть куча генераторов статических сайтов, которые потом используют нашу доку, это всё сопрягается вместе, и мы получаем красивые мини-сайты с нашими markdown-файлами. Всё это работает очень быстро и выглядит очень круто. Там и встроенный поиск, и красивые стили, и адаптивность и т.п.
Но это всё теория! 🙂 Легко всё на бумаге, но вот внедрить всё это будет непросто. У меня пока нет готового решения.
Меня беспокоит наша база знаний с документацией по нашему ПО на сайте. Она выглядит не особо и содержит ряд фундаментальных проблем, которые портят жизнь как разработчикам, так и пользователям.
Сайт Софтонит сделан на Битрикс, и изначально мы выбрали встроенный в эту платформу механизм для создания базы знаний. Это было в 2016 году, и на тот момент казалось, что всё выглядит хорошо и в целом всё удобно и классно.
Надо зайти и изменить статью? Открываешь админку сайта, заливаешь картинки, добавляешь текст статьи на сайте, и она сразу же отображается для клиентов. Удобненько (как тогда казалось).
Время идет, всё меняется, и вот уже ты видишь проблемы со старым подходом:
- В Битрикс оказывается неудобный встроенный редактор статей. Редактируешь статью, сохраняешь, в админке она выглядит так, а для пользователей верстка едет. Переключаешь в режим HTML, а там левые теги. Приходится их вычищать.
- Понимаешь, что есть проблемы с добавлением и изменением изображений. Нельзя вставлять изображения в статью из буфера обмена. Также изображение добавляется в медиабиблиотеку, а стандартный редактор использует уже изображение оттуда. В целом это работает не очень быстро. Процесс обновления одного скриншота превращается в квест из девяти кругов ада: сделай скриншот, сохрани файл, зайди в админку, открой медиабиблиотеку, загрузи файл, скопируй ссылку, вернись в статью, вставь ссылку… Хочется просто перетащить картинку в редактор, а вместо этого ты тратишь 10 минут на рутину. А если нужно поменять 20 картинок? Это просто воровство времени у команды разработки. Жесть.
- Плохой поиск. Прям очень. Было пару раз, что поиск отваливался в базе знаний после обновления Битрикс, и за мной ходила менеджер по продажам и говорила, как ей показывать какие-то фичи клиентам и отвечать на их вопросы, если она не может ничего найти в базе знаний. А изменить ты особенно ничего не можешь. Не будешь же править Битрикс и искать, в чём косяк. Потом это, конечно, всё восстанавливалось со следующими обновлениями, но осадочек от этого остался.
- Но всё это мелочи по сравнению с главной проблемой, которая меня бесит: документация живёт своей жизнью, отдельно от кода. Разработчик выкатил фикс, а документация осталась старой. В итоге клиент читает одно, а в программе видит другое. Это прямой путь к потере доверия. И именно этот разрыв стал для меня последней каплей.
Я задумал на сайте Софтонит заменить старую документацию и использовать концепцию Docs-as-Code. Что это вообще за концепция?
Всё просто — работаем с документацией так же, как и с исходным кодом программы. Заводим папочку «docs», и все скриншоты и файлы в текстовом формате (обычно это markdown) пишем и изменяем тут же, а потом пушим всё в Git. При пушах срабатывает линия сборки, которая автоматически разместит документацию на нашем сайте. При таком подходе мы получим:
- Версионирование документации. Удобно видеть версии документации.
- Документация соответствует коду, который изменяется, и она обновится тогда, когда мы выпустим релиз. Т.е. документация следует за кодом (но тут всё зависит от того, как вы настроите линию сборки).
- Можно использовать любимые markdown-редакторы. Лично мне нравится редактор Visual Studio Code и плагин для Markdown. Оно умеет и из буфера файлы вставлять в текст, и даже есть свой линтер для формата Markdown (подчеркивает желтым, если ты что-то не так делаешь в оформлении текста).
- Мы отделяем текст документации от оформления этого текста на сайте. Есть куча генераторов статических сайтов, которые потом используют нашу доку, это всё сопрягается вместе, и мы получаем красивые мини-сайты с нашими markdown-файлами. Всё это работает очень быстро и выглядит очень круто. Там и встроенный поиск, и красивые стили, и адаптивность и т.п.
Но это всё теория! 🙂 Легко всё на бумаге, но вот внедрить всё это будет непросто. У меня пока нет готового решения.
👍1
Я пока не определился, что использовать в качестве генератора статических сайтов и как организовать сборку для всего нашего ПО. Есть такие инструменты, как Diplodoc, Docusaurus, Hugo, MkDocs или Gatsby, и они часто применяются для таких целей. Но на каком остановиться, пока не ясно.
В общем, начинается эпопея под названием «Убираем старое и ставим новое» 🙂
Это первая часть серии статей по разворачиванию новой базы знаний и изменению старых механизмов. Буду держать в курсе, что выберу и как это потом настрою.
А на чём живёт ваша документация? Тоже страдаете, как мы сейчас, или уже нашли самый лучший инструмент для документации?
PS: Продолжение следует…
PPS: Скриншоты можно посмотреть в оригинале статьи
В общем, начинается эпопея под названием «Убираем старое и ставим новое» 🙂
Это первая часть серии статей по разворачиванию новой базы знаний и изменению старых механизмов. Буду держать в курсе, что выберу и как это потом настрою.
А на чём живёт ваша документация? Тоже страдаете, как мы сейчас, или уже нашли самый лучший инструмент для документации?
PS: Продолжение следует…
PPS: Скриншоты можно посмотреть в оригинале статьи
От Битрикс к Git. Муки выбора и почему победил Docusaurus. Часть 2
В прошлом посте я написал почему наша старая база знаний на Битриксе — это боль. Редактор кривой, поиск отваливается, а документация живет отдельно от кода. Надоело.
Решил перевезти всю документацию на новый генератор статических сайтов по принципу Docs-as-Code. Но какой выбрать? Hugo, MkDocs, Diplodoc от Яндекса?..
Подсказка пришла, откуда не ждал — посмотрел, на чем сделаны базы знаний Сбера и Т-Банка 😉. Оказалось, гиганты используют один и тот же инструмент.
Мой шорт-лист и финальный выбор:
❗ Задача: Найти быстрый движок с крутым поиском, чтобы не страдали ни клиенты, ни сотрудники.
🔥 Ключевые критерии: Скорость сборки, поиск Algolia, плагины и живое комьюнити.
💡 Победитель: Docusaurus.
Рассказал в новой статье, почему именно он, как сэкономил кучу времени на анализе и интересные выводы со скриншотами по другим движкам.
➡️ Читать полную статью: https://codeitdir.ru/products/kb-2/?utm_source=Telegram&utm_medium=social&utm_campaign=26292908
В прошлом посте я написал почему наша старая база знаний на Битриксе — это боль. Редактор кривой, поиск отваливается, а документация живет отдельно от кода. Надоело.
Решил перевезти всю документацию на новый генератор статических сайтов по принципу Docs-as-Code. Но какой выбрать? Hugo, MkDocs, Diplodoc от Яндекса?..
Подсказка пришла, откуда не ждал — посмотрел, на чем сделаны базы знаний Сбера и Т-Банка 😉. Оказалось, гиганты используют один и тот же инструмент.
Мой шорт-лист и финальный выбор:
❗ Задача: Найти быстрый движок с крутым поиском, чтобы не страдали ни клиенты, ни сотрудники.
🔥 Ключевые критерии: Скорость сборки, поиск Algolia, плагины и живое комьюнити.
💡 Победитель: Docusaurus.
Рассказал в новой статье, почему именно он, как сэкономил кучу времени на анализе и интересные выводы со скриншотами по другим движкам.
➡️ Читать полную статью: https://codeitdir.ru/products/kb-2/?utm_source=Telegram&utm_medium=social&utm_campaign=26292908
Telegram
Код ИТ-директора
Я решил убить старую базу знаний на Битрикс с документацией по нашим продуктам. Часть 1
Меня беспокоит наша база знаний с документацией по нашему ПО на сайте. Она выглядит не особо и содержит ряд фундаментальных проблем, которые портят жизнь как разработчикам…
Меня беспокоит наша база знаний с документацией по нашему ПО на сайте. Она выглядит не особо и содержит ряд фундаментальных проблем, которые портят жизнь как разработчикам…
🔥2
Ваш главный проект — это вы. Как управлять своей жизнью
Мы деплоим новые фичи, управляем сложными архитектурами и выстраиваем процессы. А что с нашим главным проектом — собственной жизнью, карьерой, семьей и отношениями? Если честно, мой личный бэклог когда-то был полон техдолга. 😬
Я внедрил проектный подход к своей жизни, превратив её в систему: с целями-«эпиками», месячными «спринтами» и обязательными «ретроспективами» каждую неделю. Мой опыт показал, что это работает.
В статье подробно рассказываю:
Почему системность в личных делах напрямую влияет на вашу продуктивность и снижает риск выгорания.
Какие IT-аналогии помогают мне структурировать личные задачи (от Kanban до Git).
Когда проектный подход к жизни может превратиться в паранойю и как этого избежать.
Мой личный опыт и примеры.
Хватит плыть по течению, пора взять управление в свои руки! 👇
Читать подробнее
Мы деплоим новые фичи, управляем сложными архитектурами и выстраиваем процессы. А что с нашим главным проектом — собственной жизнью, карьерой, семьей и отношениями? Если честно, мой личный бэклог когда-то был полон техдолга. 😬
Я внедрил проектный подход к своей жизни, превратив её в систему: с целями-«эпиками», месячными «спринтами» и обязательными «ретроспективами» каждую неделю. Мой опыт показал, что это работает.
В статье подробно рассказываю:
Почему системность в личных делах напрямую влияет на вашу продуктивность и снижает риск выгорания.
Какие IT-аналогии помогают мне структурировать личные задачи (от Kanban до Git).
Когда проектный подход к жизни может превратиться в паранойю и как этого избежать.
Мой личный опыт и примеры.
Хватит плыть по течению, пора взять управление в свои руки! 👇
Читать подробнее
🔥1
1С и искусственный интеллект. Почему «1C:Напарник» — это только начало большого отставания?
Недавно поймал себя на мысли, что AI-ассистент в 1C:EDT, 1C:Напарник, заметно уступает тому же Cursor. Да, он помогает и автодополнение кода — это лучше, чем ничего. Но разница в качестве подсказок колоссальная.
И это не просто вопрос удобства. Этот маленький пример обнажил большую проблему: похоже, 1С, главный поставщик софта для российского бизнеса, серьёзно буксует в гонке искусственного интеллекта. Пока Сбер и Яндекс давно развивают свои модели, 1С только делает первые шаги.
Возможно я не прав и работа ведется давно, но 1С в этом плане не публичная компания. Что она развивает мы узнаем только по факту, когда выйдет первый релиз того, над чем работают.
Я вижу три фундаментальные проблемы, которые мешают 1С быстро сократить разрыв в ИИ:
Проблема №1: Архитектура и контекстное окно. Любая серьёзная конфигурация 1С — это гигантский объём метаданных и тысячи модулей. Даже топовые нейросети сегодня упираются в лимит контекстного окна. Как «объяснить» модели всю логику огромной ERP-системы, чтобы она писала качественный код, а не галлюцинировала? Архитектурно это очень сложная задача.
Проблема №2: Поздний старт. Компания, на мой взгляд, слишком долго не инвестировала в ИИ. Сейчас, когда на рынке уже есть модели, способные заменить джунов в популярных языках, 1С находится в позиции догоняющего. А в технологиях такой отрыв преодолеть крайне тяжело и дорого.
Проблема №3: Локальный язык. Модели вроде GPT обучаются на триллионах токенов кода с GitHub и всего интернета. А сколько в открытом доступе качественного кода на 1С? Язык — локальный, для рынка СНГ. Этого объёма данных катастрофически мало для обучения действительно мощной модели, которая будет понимать всю специфику платформы.
Что у 1С есть сейчас в арсенале ИИ? Если честно, немного:
- 1С:Напарник: Помощник с автодополнением кода.
- Распознавание документов: Полезно, но это уже стандарт индустрии, а не прорыв.
- Таймлист 1С: Расшифровка встреч. Тоже полезная утилита.
И, кажется, всё.
Я очень люблю платформу 1С и хочу видеть её на острие технологий. Но пока картина выглядит тревожно. Время покажет, сможет ли компания совершить технологический рывок.
Коллеги, а что вы думаете? Есть у 1С шансы догнать тренды? Или её нишевость в итоге станет её же ловушкой в мире повсеместного AI? Делитесь мыслями в комментариях.
Недавно поймал себя на мысли, что AI-ассистент в 1C:EDT, 1C:Напарник, заметно уступает тому же Cursor. Да, он помогает и автодополнение кода — это лучше, чем ничего. Но разница в качестве подсказок колоссальная.
И это не просто вопрос удобства. Этот маленький пример обнажил большую проблему: похоже, 1С, главный поставщик софта для российского бизнеса, серьёзно буксует в гонке искусственного интеллекта. Пока Сбер и Яндекс давно развивают свои модели, 1С только делает первые шаги.
Возможно я не прав и работа ведется давно, но 1С в этом плане не публичная компания. Что она развивает мы узнаем только по факту, когда выйдет первый релиз того, над чем работают.
Я вижу три фундаментальные проблемы, которые мешают 1С быстро сократить разрыв в ИИ:
Проблема №1: Архитектура и контекстное окно. Любая серьёзная конфигурация 1С — это гигантский объём метаданных и тысячи модулей. Даже топовые нейросети сегодня упираются в лимит контекстного окна. Как «объяснить» модели всю логику огромной ERP-системы, чтобы она писала качественный код, а не галлюцинировала? Архитектурно это очень сложная задача.
Проблема №2: Поздний старт. Компания, на мой взгляд, слишком долго не инвестировала в ИИ. Сейчас, когда на рынке уже есть модели, способные заменить джунов в популярных языках, 1С находится в позиции догоняющего. А в технологиях такой отрыв преодолеть крайне тяжело и дорого.
Проблема №3: Локальный язык. Модели вроде GPT обучаются на триллионах токенов кода с GitHub и всего интернета. А сколько в открытом доступе качественного кода на 1С? Язык — локальный, для рынка СНГ. Этого объёма данных катастрофически мало для обучения действительно мощной модели, которая будет понимать всю специфику платформы.
Что у 1С есть сейчас в арсенале ИИ? Если честно, немного:
- 1С:Напарник: Помощник с автодополнением кода.
- Распознавание документов: Полезно, но это уже стандарт индустрии, а не прорыв.
- Таймлист 1С: Расшифровка встреч. Тоже полезная утилита.
И, кажется, всё.
Я очень люблю платформу 1С и хочу видеть её на острие технологий. Но пока картина выглядит тревожно. Время покажет, сможет ли компания совершить технологический рывок.
Коллеги, а что вы думаете? Есть у 1С шансы догнать тренды? Или её нишевость в итоге станет её же ловушкой в мире повсеместного AI? Делитесь мыслями в комментариях.
👍3💯1
Как мой начальник «победил» юристов без единого скандала. Урок корпоративного Win-Win
Мне повезло. В самом начале своей карьеры я был под руководством толкового руководителя. Он был на несколько лет старше, но гораздо более опытнее в плане руководства в ИТ. Много фишек по управлению я подсмотрел именно у него.
Особенно в память врезалась одна история.
Ситуация: Пат
Представьте крупную компанию. IT-отдел постоянно что-то закупает. Юридический отдел — «любимчики» руководства, чувствуют свою власть и могут завернуть любой договор, прикрываясь «интересами компании». Даже там, где можно было легко договориться.
Нам срочно нужно оборудование. Оно есть только у одного поставщика в РФ. Поставщик дает свой типовой договор. Наши юристы — свое решительное «нет», требуют переделать всё под наш шаблон. Поставщик, устав от правок, вежливо посылает нас.
Тупик. Оборудование нужно как воздух. Юристы договор не пропускают. Без их визы никто ничего не оплатит.
Развязка: Картридж как рычаг давления
Иван не стал ругаться и писать докладные. Он взял паузу на пару дней.
Через некоторое время в наш кабинет заходит та самая сотрудница юротдела, которая курировала наш договор, и просит: «Вань, у нас картридж в МФУ закончился, а мне нужно срочно печатать кучу документов для суда. Заправьте, пожалуйста».
И тут Иван спокойно, без наезда, раскладывает пасьянс: «У меня тут ваш договор от единственного поставщика лежит. Оборудование купить не можем, всё стоит. Поставщик нашу редакцию не принимает».
Юрист всё поняла и улыбнулась.
Иван продолжил, уже улыбаясь в ответ: «Я, конечно, могу, как и вы, долго и скрупулезно искать поставщика картриджей и тонера, соблюдая все процедуры. У нас их как раз нехватка. И тогда, боюсь, по шапке прилетит нам обоим. А могу решить ваш вопрос прямо сейчас».
Они помолчали, глядя друг на друга. Затем она встала, дошла до двери, обернулась и сказала: «Приносите ваш договор…»
Когда она ушла, Ваня рассмеялся. Ни грамма грубости, никакого хамства. Просто два человека поняли интересы друг друга и договорились. Классический Win-Win.
Уроки, которые я извлек тогда и использую до сих пор
1. Ищите неформальные рычаги. Когда формальные процедуры заходят в тупик, ищите точки пересечения интересов в операционной плоскости. IT-отдел, как сервисная служба, имеет массу таких рычагов: от скорости реакции на заявку до приоритета в закупках.
2. Пауза — это стратегический ресурс. Мгновенная эскалация конфликта — признак слабости. Иногда нужно просто подождать, пока у оппонента не появится проблема, которую вы можете решить.
3. Авторитет зарабатывается решением проблем, а не криком. Иван не просто «прогнул» юристов. Он показал, что с ним можно и нужно договариваться. В следующий раз они дважды подумают, прежде чем бездумно блокировать его инициативу.
Некоторые скажут, что из таких компаний надо бежать. Возможно. Но корпоративные войны — неотъемлемая часть любой крупной организации. И если вы руководитель, вам придется научиться в них побеждать. Не криком и скандалами, а умом и пониманием чужих интересов.
Вспоминаю Ивана с огромной благодарностью. Он многому меня научил.
А как у вас выстроены отношения с юристами и бухгалтерией? Часто приходится «воевать» или находить нестандартные решения? Делитесь в комментариях!
Мне повезло. В самом начале своей карьеры я был под руководством толкового руководителя. Он был на несколько лет старше, но гораздо более опытнее в плане руководства в ИТ. Много фишек по управлению я подсмотрел именно у него.
Особенно в память врезалась одна история.
Ситуация: Пат
Представьте крупную компанию. IT-отдел постоянно что-то закупает. Юридический отдел — «любимчики» руководства, чувствуют свою власть и могут завернуть любой договор, прикрываясь «интересами компании». Даже там, где можно было легко договориться.
Нам срочно нужно оборудование. Оно есть только у одного поставщика в РФ. Поставщик дает свой типовой договор. Наши юристы — свое решительное «нет», требуют переделать всё под наш шаблон. Поставщик, устав от правок, вежливо посылает нас.
Тупик. Оборудование нужно как воздух. Юристы договор не пропускают. Без их визы никто ничего не оплатит.
Развязка: Картридж как рычаг давления
Иван не стал ругаться и писать докладные. Он взял паузу на пару дней.
Через некоторое время в наш кабинет заходит та самая сотрудница юротдела, которая курировала наш договор, и просит: «Вань, у нас картридж в МФУ закончился, а мне нужно срочно печатать кучу документов для суда. Заправьте, пожалуйста».
И тут Иван спокойно, без наезда, раскладывает пасьянс: «У меня тут ваш договор от единственного поставщика лежит. Оборудование купить не можем, всё стоит. Поставщик нашу редакцию не принимает».
Юрист всё поняла и улыбнулась.
Иван продолжил, уже улыбаясь в ответ: «Я, конечно, могу, как и вы, долго и скрупулезно искать поставщика картриджей и тонера, соблюдая все процедуры. У нас их как раз нехватка. И тогда, боюсь, по шапке прилетит нам обоим. А могу решить ваш вопрос прямо сейчас».
Они помолчали, глядя друг на друга. Затем она встала, дошла до двери, обернулась и сказала: «Приносите ваш договор…»
Когда она ушла, Ваня рассмеялся. Ни грамма грубости, никакого хамства. Просто два человека поняли интересы друг друга и договорились. Классический Win-Win.
Уроки, которые я извлек тогда и использую до сих пор
1. Ищите неформальные рычаги. Когда формальные процедуры заходят в тупик, ищите точки пересечения интересов в операционной плоскости. IT-отдел, как сервисная служба, имеет массу таких рычагов: от скорости реакции на заявку до приоритета в закупках.
2. Пауза — это стратегический ресурс. Мгновенная эскалация конфликта — признак слабости. Иногда нужно просто подождать, пока у оппонента не появится проблема, которую вы можете решить.
3. Авторитет зарабатывается решением проблем, а не криком. Иван не просто «прогнул» юристов. Он показал, что с ним можно и нужно договариваться. В следующий раз они дважды подумают, прежде чем бездумно блокировать его инициативу.
Некоторые скажут, что из таких компаний надо бежать. Возможно. Но корпоративные войны — неотъемлемая часть любой крупной организации. И если вы руководитель, вам придется научиться в них побеждать. Не криком и скандалами, а умом и пониманием чужих интересов.
Вспоминаю Ивана с огромной благодарностью. Он многому меня научил.
А как у вас выстроены отношения с юристами и бухгалтерией? Часто приходится «воевать» или находить нестандартные решения? Делитесь в комментариях!
Политика нулевой терпимости к багам в разработке ПО. Ловушка для перфекциониста или отличная штука?
Столкнулся недавно с идеей «Zero Bug Policy» (ZBP). Речь про политику нулевой терпимости к багам. Концепция простая: увидел баг — бросай всё и чини. Звучит как мечта: ошибки все исправлены, клиенты счастливы, а техподдержка пьет смузи.
Но мой опыт показывает, что такие лозунги часто ведут в ад переработок и демотивации. Давайте разберемся, почему ZBP — это чаще всего утопия, которая может навредить бизнесу больше, чем помочь.
На бумаге все выглядит классно:
- Нашли баг? Все бросаем и чиним. Никаких новых фич, пока в бэклоге есть хоть одна ошибка.
- Результат? Код всегда в идеальном состоянии. Качество продукта стремится к 100%.
Звучит как мечта любого IT-директора. Но дьявол, как всегда, в деталях.
Почему это почти никогда не работает
1. Экономика против. Представьте, что вы делаете уборку в квартире. Убрать 95% грязи можно быстро и легко. А вот вычистить оставшиеся 5% проблемно. Пыль за шкафом, налет на кране займет столько же времени, сколько вся предыдущая уборка. В разработке тот же принцип Парето, только в кубе. Исправление 80% багов занимает 20% времени. А вот охота за последними, редкими и трудновоспроизводимыми ошибками — это колоссальные затраты. Стоит ли неделя работы разработчика исправления бага, который возникает у одного пользователя из тысячи при специфическом стечении обстоятельств? С точки зрения бизнеса, думаю почти никогда.
2. Что вообще считать «багом»? Вот тут и начинается самое интересное.
- Опечатка на кнопке это баг?
- Неидеальное выравнивание элемента на странице при разрешении экрана 1366×768 тоже баг?
- Отсутствие валидации на редко используемом поле точно баг?
Если команда обязана исправлять всё, она утонет в мелочах. Разработчики будут тратить время на косметику, вместо того чтобы пилить фичи, которые приносят деньги. Бизнес за это спасибо точно не скажет.
3. Цена промедления. Пока ваша команда гоняется за съехавшей кнопкой, конкуренты выкатывают новые функции и захватывают рынок. Бизнес теряет не только деньги на зарплатах разработчиков-перфекционистов, но и упущенную выгоду.
Здравый смысл вместо утопии. Сортируем баги
Вместо лозунга «ноль багов» зрелые компании используют прагматичный подход — систему приоритетов и оценку критичности. Можно использовать что-то типа матрицы Эйзенхауэра но для багов:
Матрица багов:
- Критический: Ошибка, блокирующая основную функциональность. Пользователь не может выполнить ключевой сценарий (например, оплатить заказ). Реакция: Бросаем всё, чиним немедленно. Релиз без исправления невозможен.
- Серьезный: Серьезная ошибка, которая нарушает некритичную функциональность или не имеющая простого обходного пути. Реакция: Должна быть исправлена в ближайшем релизе.
- Незначительный: незначительная проблема, которая не мешает работе, но создает неудобство. Есть обходной путь. Реакция: Исправляется, когда есть свободные ресурсы.
- Косметический: Косметическая ошибка: опечатка, съехавший элемент интерфейса. Реакция: Попадают в бэклог и исправляются «пачкой» раз в квартал или когда совсем нечем заняться.
Такой подход позволяет принимать экономически взвешенные решения. Мы не игнорируем баги, мы управляем ими.
Когда ZBP имеет смысл?
Но не все так однозначно. Есть области, где цена ошибки — это человеческая жизнь или миллионные финансовые потери. Софт для больниц, автопилоты, системы управления АЭС и т.п. Там ZBP жизненная необходимость, подкрепленная бюджетами и сроками (например, многоуровневым тестированием).
Но давайте будем честны, большинство из нас не пишет софт для NASA. Наша задача создавать ценность для бизнеса, а не стремиться к недостижимому идеалу.
Вывод: Zero Bug Policy красивая, но опасная идея для большинства компаний. Она подменяет цель (создание работающего и прибыльного продукта) средством (достижение стерильного кода). Гораздо эффективнее внедрить четкую систему классификации багов и принимать решения, основанные на здравом смысле и экономике.
А как у вас в компаниях работают с багами? Делитесь опытом в комментариях.
Столкнулся недавно с идеей «Zero Bug Policy» (ZBP). Речь про политику нулевой терпимости к багам. Концепция простая: увидел баг — бросай всё и чини. Звучит как мечта: ошибки все исправлены, клиенты счастливы, а техподдержка пьет смузи.
Но мой опыт показывает, что такие лозунги часто ведут в ад переработок и демотивации. Давайте разберемся, почему ZBP — это чаще всего утопия, которая может навредить бизнесу больше, чем помочь.
На бумаге все выглядит классно:
- Нашли баг? Все бросаем и чиним. Никаких новых фич, пока в бэклоге есть хоть одна ошибка.
- Результат? Код всегда в идеальном состоянии. Качество продукта стремится к 100%.
Звучит как мечта любого IT-директора. Но дьявол, как всегда, в деталях.
Почему это почти никогда не работает
1. Экономика против. Представьте, что вы делаете уборку в квартире. Убрать 95% грязи можно быстро и легко. А вот вычистить оставшиеся 5% проблемно. Пыль за шкафом, налет на кране займет столько же времени, сколько вся предыдущая уборка. В разработке тот же принцип Парето, только в кубе. Исправление 80% багов занимает 20% времени. А вот охота за последними, редкими и трудновоспроизводимыми ошибками — это колоссальные затраты. Стоит ли неделя работы разработчика исправления бага, который возникает у одного пользователя из тысячи при специфическом стечении обстоятельств? С точки зрения бизнеса, думаю почти никогда.
2. Что вообще считать «багом»? Вот тут и начинается самое интересное.
- Опечатка на кнопке это баг?
- Неидеальное выравнивание элемента на странице при разрешении экрана 1366×768 тоже баг?
- Отсутствие валидации на редко используемом поле точно баг?
Если команда обязана исправлять всё, она утонет в мелочах. Разработчики будут тратить время на косметику, вместо того чтобы пилить фичи, которые приносят деньги. Бизнес за это спасибо точно не скажет.
3. Цена промедления. Пока ваша команда гоняется за съехавшей кнопкой, конкуренты выкатывают новые функции и захватывают рынок. Бизнес теряет не только деньги на зарплатах разработчиков-перфекционистов, но и упущенную выгоду.
Здравый смысл вместо утопии. Сортируем баги
Вместо лозунга «ноль багов» зрелые компании используют прагматичный подход — систему приоритетов и оценку критичности. Можно использовать что-то типа матрицы Эйзенхауэра но для багов:
Матрица багов:
- Критический: Ошибка, блокирующая основную функциональность. Пользователь не может выполнить ключевой сценарий (например, оплатить заказ). Реакция: Бросаем всё, чиним немедленно. Релиз без исправления невозможен.
- Серьезный: Серьезная ошибка, которая нарушает некритичную функциональность или не имеющая простого обходного пути. Реакция: Должна быть исправлена в ближайшем релизе.
- Незначительный: незначительная проблема, которая не мешает работе, но создает неудобство. Есть обходной путь. Реакция: Исправляется, когда есть свободные ресурсы.
- Косметический: Косметическая ошибка: опечатка, съехавший элемент интерфейса. Реакция: Попадают в бэклог и исправляются «пачкой» раз в квартал или когда совсем нечем заняться.
Такой подход позволяет принимать экономически взвешенные решения. Мы не игнорируем баги, мы управляем ими.
Когда ZBP имеет смысл?
Но не все так однозначно. Есть области, где цена ошибки — это человеческая жизнь или миллионные финансовые потери. Софт для больниц, автопилоты, системы управления АЭС и т.п. Там ZBP жизненная необходимость, подкрепленная бюджетами и сроками (например, многоуровневым тестированием).
Но давайте будем честны, большинство из нас не пишет софт для NASA. Наша задача создавать ценность для бизнеса, а не стремиться к недостижимому идеалу.
Вывод: Zero Bug Policy красивая, но опасная идея для большинства компаний. Она подменяет цель (создание работающего и прибыльного продукта) средством (достижение стерильного кода). Гораздо эффективнее внедрить четкую систему классификации багов и принимать решения, основанные на здравом смысле и экономике.
А как у вас в компаниях работают с багами? Делитесь опытом в комментариях.
Неожиданная встреча с клиентом и мой фейл
В пятницу на прошлой неделе к нам в гости заехал Сергей Владимирович, представитель нашего клиента, они в своей работе используют Управление IT-отделом 8. Для меня это необычный кейс. Наш офис находится в маленьком городе в Краснодарском крае, и сюда ехать не ближний свет. Основные клиенты — это крупные компании, которые находятся совсем не близко. Клиент хотел поближе познакомиться, так как был проездом рядом и у него недалеко живут родственники.
После новости, что к нам едет клиент, сразу подумал: «Что? Зачем? Почему?» 😁
А потом понял. Это уникальный шанс «помучать клиента» и задать острые вопросы, узнать кейс нестандартного использования и т. д. Но и клиент может сделать ровно то же самое по нашему ПО: задать неудобные вопросы и узнать планы на будущее.
На мой взгляд, я плохо подготовился. Самый главный фейл — это то, что оказалось у нас два клиента с одинаковой фамилией, и когда я готовился к встрече, я посмотрел на данные другого клиента, на имя и отчество не обратил внимание. 🤦 Из-за этого и вопросы подготовил чутка не те… В общем, вы поняли.
Потом постарался исправиться и импровизировал уже в процессе беседы. Не уверен, что хорошо подготовился. А для себя понял, что в будущем так делать нельзя. К таким интервью надо готовиться хорошо и долго. Надо стараться использовать такие встречи по максимуму.
Конечно, это приятно. Все же не каждый день вживую общаешься с клиентами.
Чуть позже отдельно выложу, что из этого получилось в виде кейса клиента.
В связи с этим у меня к вам пара вопросов:
- Про фейлы: было такое, что при важной встрече всё шло, мягко говоря, не по плану?
- Про продукты: сталкивались с тем, что ваш или чужой софт использовали совсем не так, как задумывали разработчики? Расскажите в комментариях, это же самое интересное!
В пятницу на прошлой неделе к нам в гости заехал Сергей Владимирович, представитель нашего клиента, они в своей работе используют Управление IT-отделом 8. Для меня это необычный кейс. Наш офис находится в маленьком городе в Краснодарском крае, и сюда ехать не ближний свет. Основные клиенты — это крупные компании, которые находятся совсем не близко. Клиент хотел поближе познакомиться, так как был проездом рядом и у него недалеко живут родственники.
После новости, что к нам едет клиент, сразу подумал: «Что? Зачем? Почему?» 😁
А потом понял. Это уникальный шанс «помучать клиента» и задать острые вопросы, узнать кейс нестандартного использования и т. д. Но и клиент может сделать ровно то же самое по нашему ПО: задать неудобные вопросы и узнать планы на будущее.
На мой взгляд, я плохо подготовился. Самый главный фейл — это то, что оказалось у нас два клиента с одинаковой фамилией, и когда я готовился к встрече, я посмотрел на данные другого клиента, на имя и отчество не обратил внимание. 🤦 Из-за этого и вопросы подготовил чутка не те… В общем, вы поняли.
Потом постарался исправиться и импровизировал уже в процессе беседы. Не уверен, что хорошо подготовился. А для себя понял, что в будущем так делать нельзя. К таким интервью надо готовиться хорошо и долго. Надо стараться использовать такие встречи по максимуму.
Конечно, это приятно. Все же не каждый день вживую общаешься с клиентами.
Чуть позже отдельно выложу, что из этого получилось в виде кейса клиента.
В связи с этим у меня к вам пара вопросов:
- Про фейлы: было такое, что при важной встрече всё шло, мягко говоря, не по плану?
- Про продукты: сталкивались с тем, что ваш или чужой софт использовали совсем не так, как задумывали разработчики? Расскажите в комментариях, это же самое интересное!
👍2
Налоги для IT с 2026 года: закручивают гайки?
Не дает мне покоя тема с налогами. Повышение ставки НДС с 20% до 22% — это ещё полбеды. Куда больше беспокоит снижение порога для УСН, после которого придётся платить НДС. Его хотят урезать с 60 млн до 10 млн рублей. Если это примут, а всё к тому идёт, то наша компания тоже попадёт на НДС.
Есть в экономике такая штука, кривая Лаффера. Она просто и наглядно показывает: если налоги 0%, то в бюджет ничего не поступает. А если 100%, то бизнесом заниматься нет смысла — весь доход уйдет на налоги. Где-то посередине есть точка, в которой государство собирает максимум. Если ставку задрать выше этой точки, сборы начнут падать, потому что предприниматели просто не вывозят нагрузку. Бизнес перестаёт развиваться, теряет позиции, а потом и вовсе работает в убыток. В итоге он либо закрывается, либо уходит в тень.
Мне всё это, мягко говоря, не нравится.
А с IT-компаниями вообще история весёлая.
Как менялись льготы для IT-компаний
Давайте посмотрим на динамику налоговых условий для аккредитованных IT-компаний, в том числе тех, кто на УСН. Собрал тут для себя и вас изменения (если что-то забыл, напишите поправлю):
- Налог на прибыль:
2022-2024: 0%
2025-2026: 5% (планируется до 2030 года)
- Страховые взносы:
2022-2024: 7,6%
2025: 7,6%
2026: 15% (на доходы до предельной базы) и 7,6% (сверх базы)
- НДС для разработчиков ПО:
2022-2026: 0% при продаже софта из реестра Минцифры. Но есть нюанс: условия для попадания в реестр могут ужесточить.
- Льготы на УСН:
2022-2025: Регионы сами устанавливали пониженные ставки (от 1% до 6%).
2026: Ставки сохраняются, но порог для освобождения от НДС падает с 60 до 10 млн рублей годового дохода.
- Проверки:
2022-2025: Действовал мораторий на большинство проверок.
2026: Условия, скорее всего, пересмотрят.
Что нас ждёт в 2026 году?
Прогнозы — дело неблагодарное, но вот основные изменения, которые маячат на горизонте.
1. Страховые взносы вырастут почти вдвое. Льготный тариф поднимут с 7,6% до 15%. Это, конечно, не стандартные 30%, но рост ощутимый.
2. Главный удар для малого бизнеса на УСН. Порог для освобождения от НДС рухнет с 60 до 10 млн рублей. Это значит, что даже небольшие IT-компании с оборотом чуть выше 10 млн в год заставят платить НДС, который тоже может вырасти до 22%.
3. Льгота по НДС на софт пока остаётся. Ставка 0% на продажу программ из реестра Минцифры сохранится. Правда, есть подозрение, что на фоне общего повышения налогов попасть в этот самый реестр станет намного сложнее.
Получается, что золотые времена для IT с почти нулевыми налогами заканчиваются. С 2025 года гайки начали закручивать, а в 2026, похоже, закрутят ещё сильнее. Льготы всё ещё есть, и они заметны по сравнению с другими отраслями, но уже не такие щедрые.
Интересно, что вы думаете об этом? Как готовитесь к изменениям? Делитесь мыслями в комментариях.
Не дает мне покоя тема с налогами. Повышение ставки НДС с 20% до 22% — это ещё полбеды. Куда больше беспокоит снижение порога для УСН, после которого придётся платить НДС. Его хотят урезать с 60 млн до 10 млн рублей. Если это примут, а всё к тому идёт, то наша компания тоже попадёт на НДС.
Есть в экономике такая штука, кривая Лаффера. Она просто и наглядно показывает: если налоги 0%, то в бюджет ничего не поступает. А если 100%, то бизнесом заниматься нет смысла — весь доход уйдет на налоги. Где-то посередине есть точка, в которой государство собирает максимум. Если ставку задрать выше этой точки, сборы начнут падать, потому что предприниматели просто не вывозят нагрузку. Бизнес перестаёт развиваться, теряет позиции, а потом и вовсе работает в убыток. В итоге он либо закрывается, либо уходит в тень.
Мне всё это, мягко говоря, не нравится.
А с IT-компаниями вообще история весёлая.
Как менялись льготы для IT-компаний
Давайте посмотрим на динамику налоговых условий для аккредитованных IT-компаний, в том числе тех, кто на УСН. Собрал тут для себя и вас изменения (если что-то забыл, напишите поправлю):
- Налог на прибыль:
2022-2024: 0%
2025-2026: 5% (планируется до 2030 года)
- Страховые взносы:
2022-2024: 7,6%
2025: 7,6%
2026: 15% (на доходы до предельной базы) и 7,6% (сверх базы)
- НДС для разработчиков ПО:
2022-2026: 0% при продаже софта из реестра Минцифры. Но есть нюанс: условия для попадания в реестр могут ужесточить.
- Льготы на УСН:
2022-2025: Регионы сами устанавливали пониженные ставки (от 1% до 6%).
2026: Ставки сохраняются, но порог для освобождения от НДС падает с 60 до 10 млн рублей годового дохода.
- Проверки:
2022-2025: Действовал мораторий на большинство проверок.
2026: Условия, скорее всего, пересмотрят.
Что нас ждёт в 2026 году?
Прогнозы — дело неблагодарное, но вот основные изменения, которые маячат на горизонте.
1. Страховые взносы вырастут почти вдвое. Льготный тариф поднимут с 7,6% до 15%. Это, конечно, не стандартные 30%, но рост ощутимый.
2. Главный удар для малого бизнеса на УСН. Порог для освобождения от НДС рухнет с 60 до 10 млн рублей. Это значит, что даже небольшие IT-компании с оборотом чуть выше 10 млн в год заставят платить НДС, который тоже может вырасти до 22%.
3. Льгота по НДС на софт пока остаётся. Ставка 0% на продажу программ из реестра Минцифры сохранится. Правда, есть подозрение, что на фоне общего повышения налогов попасть в этот самый реестр станет намного сложнее.
Получается, что золотые времена для IT с почти нулевыми налогами заканчиваются. С 2025 года гайки начали закручивать, а в 2026, похоже, закрутят ещё сильнее. Льготы всё ещё есть, и они заметны по сравнению с другими отраслями, но уже не такие щедрые.
Интересно, что вы думаете об этом? Как готовитесь к изменениям? Делитесь мыслями в комментариях.
IT и бухгалтерия: как прекратить споры за каждую мышку. Пример из жизни.
Недавно я писал про встречу с клиентом и свою ошибку в подготовке. Эта встреча принесла пользу. Мы записали наш разговор и сделали из него подробный отчет. Сегодня я расскажу о самом важном из этого отчета — как IT-отдел и бухгалтерия могут прекратить споры.
Полный отчет вы можете найти на сайте SoftOnIT: ccылка на полный кейс
В чем проблема: два разных взгляда
Споры между IT и бухгалтерией почти всегда касаются учета оборудования.
Как видит бухгалтерия: Любая вещь, будь то ноутбук или мышь, — это актив компании. Его надо записать, дать ему номер и назначить ответственного. Обычно это тот, кто вещью пользуется. Каждое движение техники требует бумажного документа. Чтобы что-то выбросить, нужна своя процедура.
Как видит IT-отдел: Оборудование постоянно двигается. Сегодня ноутбук у одного человека, завтра — у другого. Мышь меняется за минуту. Диск в сервере сломался — его выкинули. Если для каждого такого шага готовить документы для бухгалтерии, IT-специалисты будут заниматься только бумагами.
Результат: все недовольны, а в учете беспорядок.
Как клиент решил задачу: разделить ответственность
Наш клиент — компания, у которой есть заводы и офисы в разных местах. Они придумали простой способ. Главная идея: ясно поделить, кто за что отвечает, и закрепить это официальным документом.
Как это у них устроено:
1. Вся ответственность на IT-отделе. По внутреннему приказу, вся компьютерная техника находится в ведении IT-отдела. Руководитель IT отвечает за все оборудование в компании.
2. Бухгалтерия общается только с IT. Когда поступает новая техника, бухгалтеры ставят ее на учет и сразу передают IT-отделу по акту. На этом их работа с конкретной вещью закончена до момента списания. Они работают с общими цифрами и документами от IT.
3. IT-отдел ведет свой учет. В нашей программе (Управление IT-отделом 8) специалисты следят, где находится каждая единица техники. Они отмечают, что ноутбук выдан такому-то человеку, но это их внутренняя запись. Для бухгалтерии этот ноутбук все еще числится за IT-отделом.
4. Ответственность сотрудника. Получая технику, работник подписывает документ о передаче с IT-отделом. Если он что-то потеряет, отвечать будет перед IT. Руководство компании знает и поддерживает этот порядок.
5. Простое списание. IT-отдел готовит документ о техническом состоянии и отправляет бухгалтерам записку: «Просим списать 5 единиц оргтехники на такую-то сумму». Этого бухгалтерии хватает, чтобы провести операцию.
6. Минусы тоже есть. Куда ж без них. За удобство приходится платить тем, что за все отвечает ИТ-подразделение. Но если контакт с бухгалтерией найден, то это, наверное, не такая уж и проблема.
Что это дает?
- Бухгалтеры довольны. Им больше не нужно отслеживать сотни мелких вещей. Они общаются с IT при помощи понятных им документов и цифр.
- IT-отдел получает больше времени на работу. Специалисты могут быстро управлять оборудованием и не тратят время на лишние бумаги.
- В учете все ясно. Деньги считает бухгалтерия. Фактическим наличием техники управляет IT. Путаницы нет.
Это показывает, как один официальный документ и подходящая программа для учета убирают почти все споры.
А как у вас построена работа с бухгалтерией? Удалось договориться или вы спорите из-за каждого старого жесткого диска? Напишите в комментариях!
Недавно я писал про встречу с клиентом и свою ошибку в подготовке. Эта встреча принесла пользу. Мы записали наш разговор и сделали из него подробный отчет. Сегодня я расскажу о самом важном из этого отчета — как IT-отдел и бухгалтерия могут прекратить споры.
Полный отчет вы можете найти на сайте SoftOnIT: ccылка на полный кейс
В чем проблема: два разных взгляда
Споры между IT и бухгалтерией почти всегда касаются учета оборудования.
Как видит бухгалтерия: Любая вещь, будь то ноутбук или мышь, — это актив компании. Его надо записать, дать ему номер и назначить ответственного. Обычно это тот, кто вещью пользуется. Каждое движение техники требует бумажного документа. Чтобы что-то выбросить, нужна своя процедура.
Как видит IT-отдел: Оборудование постоянно двигается. Сегодня ноутбук у одного человека, завтра — у другого. Мышь меняется за минуту. Диск в сервере сломался — его выкинули. Если для каждого такого шага готовить документы для бухгалтерии, IT-специалисты будут заниматься только бумагами.
Результат: все недовольны, а в учете беспорядок.
Как клиент решил задачу: разделить ответственность
Наш клиент — компания, у которой есть заводы и офисы в разных местах. Они придумали простой способ. Главная идея: ясно поделить, кто за что отвечает, и закрепить это официальным документом.
Как это у них устроено:
1. Вся ответственность на IT-отделе. По внутреннему приказу, вся компьютерная техника находится в ведении IT-отдела. Руководитель IT отвечает за все оборудование в компании.
2. Бухгалтерия общается только с IT. Когда поступает новая техника, бухгалтеры ставят ее на учет и сразу передают IT-отделу по акту. На этом их работа с конкретной вещью закончена до момента списания. Они работают с общими цифрами и документами от IT.
3. IT-отдел ведет свой учет. В нашей программе (Управление IT-отделом 8) специалисты следят, где находится каждая единица техники. Они отмечают, что ноутбук выдан такому-то человеку, но это их внутренняя запись. Для бухгалтерии этот ноутбук все еще числится за IT-отделом.
4. Ответственность сотрудника. Получая технику, работник подписывает документ о передаче с IT-отделом. Если он что-то потеряет, отвечать будет перед IT. Руководство компании знает и поддерживает этот порядок.
5. Простое списание. IT-отдел готовит документ о техническом состоянии и отправляет бухгалтерам записку: «Просим списать 5 единиц оргтехники на такую-то сумму». Этого бухгалтерии хватает, чтобы провести операцию.
6. Минусы тоже есть. Куда ж без них. За удобство приходится платить тем, что за все отвечает ИТ-подразделение. Но если контакт с бухгалтерией найден, то это, наверное, не такая уж и проблема.
Что это дает?
- Бухгалтеры довольны. Им больше не нужно отслеживать сотни мелких вещей. Они общаются с IT при помощи понятных им документов и цифр.
- IT-отдел получает больше времени на работу. Специалисты могут быстро управлять оборудованием и не тратят время на лишние бумаги.
- В учете все ясно. Деньги считает бухгалтерия. Фактическим наличием техники управляет IT. Путаницы нет.
Это показывает, как один официальный документ и подходящая программа для учета убирают почти все споры.
А как у вас построена работа с бухгалтерией? Удалось договориться или вы спорите из-за каждого старого жесткого диска? Напишите в комментариях!
🔥1