Как разработчику 1С приручить «дракона привычек» и перестать тушить пожары в проектах

17.03.25

Саморазвитие - Личная эффективность

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

Почти полтора десятилетия назад Чарльз Дахигг, журналист The New York Times, начал исследовать одну из самых загадочных и одновременно повседневных тем — привычки. Почему люди делают одни и те же вещи снова и снова? Почему плохие привычки укореняются так быстро, а полезные требуют героических усилий? В поисках ответов он не только провел интервью с учеными и бизнесменами, но и изучил новейшие исследования в области нейробиологии.

Так появилась книга «Сила привычки» (The Power of Habit), которая стала международным бестселлером и изменила подход к продуктивности во многих сферах: от спорта до бизнеса. Компании вроде Starbucks и Alcoa использовали идеи Дахигга для повышения эффективности, спортсмены — для улучшения результатов, а маркетологи — чтобы заставить нас покупать больше товаров.

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

Задумайтесь:

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

Ответ прост: это петли привычек, и их можно изменить. В этой статье я разберу:

  • Как работает механизм Cue → Routine → Reward, и почему ваш код — это отражение ваших рабочих паттернов.
  • Почему «краеугольные привычки» могут навсегда изменить ваш подход к разработке.
  • Как даже самый жуткий легаси-код можно приручить, если применять правильные ритуалы.

Примените эти принципы — и вместо ночных авралов у вас появятся свободные вечера. А заказчики будут писать не в 3:00, а в 6:00. Прогресс, как говорится, налицо!

Привычка — это петля: Cue → Routine → Reward

В своей книге Дахигг объясняет, что любая привычка состоит из трех элементов:

  1. Триггер (cue) — событие, запускающее действие.
  2. Действие (routine) — сама привычка, автоматический ответ на триггер.
  3. Награда (reward) — то, что закрепляет привычку.

Разработчики 1С сталкиваются с этим каждый день, даже не осознавая:

  • Триггер: Заказчик пишет «СРОЧНО! Ничего не работает!!!»
  • Действие: В панике открываем конфигурацию, правим на лету, выкатываем патч без тестов.
  • Награда: Проблема (вроде бы) решена, заказчик доволен. Мы чувствуем облегчение, наливаем себе чай (или что покрепче).

Что не так?
Проблема в том, что такая привычка формирует технический долг. Быстрая правка спасает момент, но через месяц этот код превращается в минное поле, где одно исправление рождает три новых бага.

Как изменить петлю?

  • Триггер и награду оставляем: задача срочная, решение нужно.
  • Меняем действие: вместо хаотичного кодинга анализируем проблему. Возможно, ошибка не в вашем коде, а в конфигурации или данных. Используем отладку, журнал регистрации или тестовые сценарии, прежде чем вносить изменения.

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

«Краеугольные привычки» (Keystone Habits) — макросы для вашего мозга

Дахигг вводит понятие краеугольных привычек — это такие привычки, которые запускают цепную реакцию улучшений.

Пример из бизнеса: когда в компании Alcoa CEO Пол О’Нил начал борьбу за безопасность сотрудников, производительность выросла. Почему? Потому что эта привычка подтянула и другие аспекты работы.

Какие краеугольные привычки могут изменить разработку на 1С?

  • 15 минут анализа логов каждое утро. Позволяет выявлять потенциальные проблемы до того, как они станут пожарами.
  • Автоматизация повторяющихся задач. Написали запрос вручную три раза? Пора делать шаблон.
  • Документирование кода. Это кажется скучным, но через месяц коллеги (и вы сами) скажут вам спасибо.

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

Как изменить привычку: оставьте триггер и награду, замените действие

Допустим, после каждого релиза вас ждет ночной марафон исправления багов.

  • Триггер: Завершение проекта.
  • Действие: Срочный аврал, бессонная ночь, фиксы «на живую».
  • Награда: Проект запущен, вас хвалят.

Как переписать привычку?

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

Пример: В одной компании начали запускать тестирование на боевых данных перед выкладкой. Результат: число экстренных вызовов снизилось на 70%, а заказчики перестали удивляться «непонятным изменениям».

 «Золотое правило изменения привычек»

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

Как это применимо к 1С?

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

Как заменить привычку?

  • Старая петля:
    • Триггер: Завершение проекта.
    • Действие: Радость, желание побыстрее забыть о проекте.
    • Награда: Освобождение от «лишней» работы.
  • Новая петля:
    • Триггер: Завершение проекта.
    • Действие: Ведение документации как последний шаг перед закрытием задачи.
    • Награда: Команда может быстрее вникнуть в доработки, меньше экстренных вопросов.

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

«Социальные привычки» и сила окружения

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

Как это применимо к 1С?

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

Как внедрить?

  • Ввести код-ревью в команду, где старшие разработчики задают стандарты.
  • Использовать общие чаты и каналы для обсуждения багов и лучших практик.
  • Создать «правило 5 минут» — если баг воспроизводится 5+ минут, его надо анализировать, а не сразу фиксить.

Пример: В одной команде начали обсуждать ошибки не в формате «Кто опять сломал код?!», а как совместный разбор «Как можно было избежать этого бага?». Через полгода баги стали в 2 раза реже.

«Краеугольные привычки» в личной продуктивности

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

Как это применимо к 1С?

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

Как внедрить?

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

Пример: Один разработчик 1С жаловался, что часто пишет код, а потом понимает, что «пошёл не туда». Он попробовал перед каждым модулем делать 5-минутное «мысленное проектирование» — и это сократило его правки в 3 раза.

 «Привычка выигрывать» — эффект маленьких побед

Дахигг рассказывает, что люди быстрее привыкают к хорошим изменениям, если начинают с небольших побед. Например, если человек хочет начать бегать, но пробегает всего 5 минут в день, ему легче продолжить, чем если бы он сразу поставил планку «10 км за неделю».

Как это применимо к 1С?

Если вам кажется, что проект слишком сложный, разделите его на маленькие шаги. Например:

  1. Написать текст запроса.
  2. Сделать тестовый отчёт.
  3. Проверить данные.
  4. Добавить вывод в форму.
  5. Доработать интерфейс.

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

Пример: Один разработчик начал писать GIT-коммиты на каждый микро-шаг («Создал структуру», «Добавил обработчик»). Это помогло ему лучше понимать процесс и видеть прогресс.

Автоматизация решений — как убрать ненужный выбор

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

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

  • Стив Джобс носил только чёрную водолазку и джинсы, чтобы не думать о выборе одежды.
  • Илону Маску и Джеффу Безосу помощники планируют встречи так, чтобы не тратить время на координацию расписания.

Как это применимо к 1С?

В 1С-разработке мы часто тратим время на повторяющиеся мелкие решения, которые можно автоматизировать.

Как внедрить?

  • Готовые шаблоны кода → вместо того чтобы каждый раз вспоминать, как писать стандартные обработки, можно завести заготовки в 1С (например, код для загрузки данных, формирования отчётов, работы с JSON).
  • Автоматизация рутинных задач → написать обработку для очистки базы, экспорта данных, генерации тестовых записей.
  • Готовые скрипты для развертывания → если приходится вручную вносить изменения, лучше сделать BAT-файл или PowerShell-скрипт, который всё сделает за пару секунд.

Пример: Один разработчик каждый раз тратил 5 минут на настройку прав пользователей в новой базе. Он написал обработку, которая загружает роли из шаблона за 10 секунд. В итоге за год он сэкономил 15+ часов рабочего времени!

Привычки, которые спасут ваш проект (и нервы)

  1. «Не повторяй себя» (DRY): Три раза скопировали код? Пора вносить в общий модуль.
  2. «Баги любят тишину»: Пишите тесты, даже если заказчик говорит «и так сойдет».
  3. «Всегда проверяйте данные»: 80% багов связаны не с кодом, а с некорректными входными данными.

Ваш код — это отражение ваших привычек

Как писал Дахигг: «Привычки — это вода, которая точит камень».

Что это значит для 1С-разработчика?

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

Если после прочтения статьи вы задумались о своих привычках — это уже победа. А если еще и внедрили одно улучшение, вас ждет награда: новая задача с пометкой «СРОЧНО!». Но теперь-то вы готовы!

P.S. А если коллега снова зовет вас «тушить пожар», скажите: «Я не пожарный, я архитектор — строю систему, которая не горит». И добавьте автотест в его часть кода. Это будет ваша маленькая месть вселенной хаоса.

Удачи в переписывании привычек! И да пребудет с вами сила… логирования!

личная эффективность мотивация психология оптимизация работы

См. также

Личная эффективность Бесплатно (free)

В этой статье автор решил немного заделаться психологом и по-простому написать, что за зверь такой – «эмоциональное выгорание», почему ему сильно часто подвержены IT-шники и что с этим делать.

03.03.2025    666    0    kirillobskih    7    

6

Личная эффективность Бесплатно (free)

Я Костя, разработчик 1С и руководитель образовательного направления в компании. Живу в Казахстане, работаю удалённо. Прошёл путь от стажёра до руководителя отдела разработки, меняю позиции и роли, потому что всегда хочется задач посложнее. Расскажу о карьере и тех условиях, которые сыграли важную роль для роста.

25.11.2024    5249    0    PROSTO-1C    8    

11

Личная эффективность Продуктовый подход Работа с заинтересованными сторонами Бесплатно (free)

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

18.11.2024    469    0    Radio_Analyst    0    

2

Личная эффективность Бесплатно (free)

«Я знаю одно – во мне есть нечто, и я это скрываю. Я не говорю об этом. Но оно там всегда. Мой Темный попутчик. Когда он просыпается, я чувствую себя живым.» (сериал «Декстер»). «Жажда разработки» – это психологические проявление внутреннего «я», вызывающее острую необходимость программировать. Все, кто любит программировать, неоднократно испытывали такую жажду, и я не исключение. Расскажем о том, как утолить свою жажду и найти баланс между хобби, работой и другими аспектами жизни.

07.11.2024    4641    0    BlizD    89    

48

Личная эффективность Бесплатно (free)

В этом выпуске мы поговорили с ведущими подкаста "Аналитики у микрофона" Татьяной Рыловниковой и Анной Войкиной про цели и ценности создания, прослушивания и участия в подкастах.

09.09.2024    555    0    Radio_Analyst    2    

2

Личная эффективность Бесплатно (free)

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

23.08.2024    1522    0    user1947860    3    

5

Удаленная команда Личная эффективность Бесплатно (free)

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

20.08.2024    4801    0    PROSTO-1C    14    

23

Коммуникации Личная эффективность Обучение и наставничество Бесплатно (free)

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

23.07.2024    2447    0    SerjoginaMaria    6    

13
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. user-z99999 78 17.03.25 10:45 Сейчас в теме
Стив Джобс носил только чёрную водолазку и джинсы, чтобы не думать о выборе одежды.

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

Можно ещё шире смотреть на проблему:
1) пользователи обучены работать в программе?
2) тот кто ставит задачи, он понимает методологию создания программы?
3) а где-то здесь программист и его начальник (анализируют частые ошибки, ищут причину, устраняют)
Оставьте свое сообщение