Здравствуйте!
Данный материал, который я предоставляю Вам, является стремлением улучшить свои способности в сфере принятия решений и логического анализа.
Предыстория создания данной статьи и вообще моего интереса к данной теме следующая: 4 года назад я окончательно ушел из защиты информации, где я отработал 15 лет + преподавание в университете, в программирование, которым увлекался с детства (да, и так бывает).
Сфера моей деятельности - 1С ЗУП и все, что связано с данным вопросом - кадровый, налоговый учеты и т.д. Пришел я туда, имея базу в программировании вообще и в 1С в частности.
Скажем так: программировать в 1С я более-менее умел, знал и понимал концепции регистров, умел писать запросы на начально-среднем уровне, использовал в работе расширения конфигурации...
Это, конечно, далеко-далеко не все, что нужно - так я не использовал СКД и не владел им (просто негде было его применять), так как все потребности в отчетах на тот момент закрывали макеты в той или иной форме.
Самая большая проблема - в полном отсутствии навыков работы с бухгалтерским, а так же, что самое главное, налоговым учетом.
Среди прочих проблем, с которыми мне пришлось столкнуться, самой болезненной для меня оказалась проблема того, что плохо получалось выстраивать цепочки логических размышлений, касающихся зарплаты и налогов.
Что бы было понятно - смотришь на проблемы, решить которую нужно срочно, прошу прощения, "бараньим" взглядом и не понимаешь - а что делать то, с чего начать!?
Старший коллега, который помогает (спасибо ему) решить данную задачу - начинает объяснять, что делал, как рассуждал и ты с горечью осознаешь: а почему я то не смог???
Вроде бы ничего незнакомого нет, материалом достаточным для решения владею, а выстроить цепочку рассуждения не получается.
Может, тут психологический аспект...
Может, и годы работы в защите информации сказываются - там данные навыки если и развиваются, то несколько в иной реализации...
Но проблема есть, и она довела меня буквально до белого каления.
Решать ее я начал, читаю умные книги. Вы, наверняка, все их знаете, перечислять смысла нет. И вот тут я с удивлением обнаружил занятный факт: или я какой-то не такой (что возможно), или подходящей мне литературы просто нет.
Дело вот в чем: все книги, с которыми я столкнулся, можно поделить на следующие категории:
1. Литература из разряда "хочешь быть счастливым - будь им" - мусор, по сути
2. Серьезная академическая литература на сотни листов, которые нужно не только прочитать, но и понять, а также еще и понять, как применить...
3. Книги, написанные умными, без сомнения, людьми, профессионалами, простым языком. Но объем, обилие информации просто запредельное
4. Небольшие книжки типа "Логика" Кузьмина, Виноградова - отличная книга, но применить ее в жизни нужно уметь.
Я искал и ищу брошюру, методичку (до 10 листов), а не "талмуд" на 600 страниц
Так вот я и подошел к идее сделать такую брошюру самому - скомпилировать рецепты, изложенные в различных источниках максимально кратко, емко и понятно.
Хочу оговориться - я не являюсь профессиональным писателем, каким-то супер-специалистом, нет...
Так же не беру на себя смелость заявлять о какой-то глобальное пользе - опять-таки нет...
Писалось для себя и под себя.
Основная переработка с примерно 50 изначально до 10 страниц велась собственноручно.
На последнем этапе подключил ИИ - для проверки и анализа.
В итоге получилась методичка на 7 листов.
===================================================================
Тема: рецепты логического мышления и анализа
Проблема со сложными задачами кроется не в нехватке таланта или ума. Проблема — в избыточной спешке мозга. Наш мозг устроен из двух систем:
• Система 1 (Интуитивная): Быстрая, мгновенно выдает готовые ответы, но в сложных системах (1С, налоги, Linux и.т.д.) почти всегда ошибается.
• Система 2 (Логическая): Медленная, ленивая, требует усилий, но именно она строит строгие цепочки рассуждений.
Цель — задать жесткие рельсы и барьеры, которые будут принудительно тормозить быструю Систему 1 и заставлять включаться глубокую Систему 2.
ЧАСТЬ 1: УПРАВЛЕНИЕ МЫШЛЕНИЕМ (КАК ЗАМЕДЛИТЬ МОЗГ И ВКЛЮЧИТЬ ЛОГИКУ)
1. Правило «Искусственной паузы» (Защита от первого импульса) - не торопиться использовать интуицию
Первое решение, которое выдает мозг при виде проблемы или задачи — это интуитивный импульс Системы 1. Задача правила — заблокировать его, чтобы дать время включиться анализу.
• Алгоритм: Как только прилетела задача, поймай свою первую догадку и запиши её на листок. Запрети себе проверять эту гипотезу или лезть в код/консоль/интернет в течение следующих 2 минут. Скажи себе: «ОК, это гипотеза А. Теперь я обязан письменно сформулировать гипотезы Б и В, даже если они кажутся маловероятными». Только после того, как на бумаге появятся три альтернативных варианта, приступай к их методичной проверке.
2. Переформулирование задачи - заземление текста
Интуитивное мышление скользит по поверхности эмоциональных слов пользователя («У меня всё поплыло!», «НДФЛ не идет!»). Чтобы включить анализ, переведи размытый запрос на строгий технический язык.
Алгоритм действий:
Прежде чем открывать Конфигуратор или лезть в модули, перепиши задачу своими словами в блокнот так, как будто ты объясняешь её стажеру:
• Было (запрос бухгалтера): «У Сидорова в расчетном листке застрял какой-то долг с прошлого месяца, убери его!».
• Стало (твое переформулирование): «Документ "Начисление зарплаты" за текущий месяц формирует начальное сальдо на основании регистра накопления "Взаиморасчеты с сотрудниками". Нужно проверить остаток по этому регистру на дату 01 числа текущего месяца с отбором по сотруднику Сидорову и найти документ-регистратор, который этот остаток сформировал».
Как только задача переведена в плоскость конкретных объектов и регистров 1С, магия исчезает и начинается чистая, понятная логика.
3. Метод «Логического трассировщика» - записывать ход своих мыслей
Запрети(!) себе решать сложные задачи «в уме». Рабочая память перегружается, возникает паника, и нить рассуждений теряется. Выноси ход мыслей на бумагу или в .txt файл точно так же, как программа пишет логи.
• Алгоритм: Запиши конечную аномалию.
Сделай Шаг 1: Проверь самый первый элемент в цепочке данных, запиши результат (Совпало / Не совпало).
Сделай Шаг 2: На основе Шага 1 переходи к следующему регистру/объекту, который является источником данных для предыдущего шага, запиши результат. Если логика завела в тупик — вернись на один шаг назад по своим записям и найди развилку, где можно было пойти по другому пути.
Пример ведения лога при ошибке в ЗУП:
• Проблема: У сотрудника Иванова неверно рассчитался НДФЛ за ноябрь.
• Шаг 1: Проверяю совокупный доход за месяц. Сумма = 100 000 руб. (Верно, по расчетному листку сходится).
• Шаг 2: Проверяю право на вычеты. У него один ребенок, вычет 1 400 руб. Применился? (Смотрю регистр «Предоставленные стандартные вычеты по НДФЛ» — да, применился. Верно).
• Шаг 3: Какова налоговая база? Должна быть 100 000 - 1 400 = 98 600 руб. (Смотрю документ начисления — база стоит 150 000 руб. Стоп! Откуда лишние 50 000?).
• Шаг 4: Копаю базу. Ищу, какой документ начислил эти 50 000. Нахожу межрасчетную премию.
• Шаг 5: Проверяю дату выплаты премии. В документе стоит 02.12 (декабрь), а начислена в ноябре. Из-за учета НДФЛ по дате выплаты доход улетел в другой период.
• Итог: Цепочка зафиксирована, причина найдена.
4. Правило одного изменения – делать изменения строго по одному шагу
Запрети себе делать несколько правок одновременно в надежде, что «что-то из этого точно сработает».
• Алгоритм: За один раз ты имеешь право внести только одно изменение (в код, настройки или документ). Сделай тест. Зафиксируй результат. Если изменение не решило проблему, ОБЯЗАТЕЛЬНО верни систему в исходное состояние (отмени правку), и только после этого переходи к проверке следующей гипотезы.
• Исключение по тайм-ауту: Если проверка одной гипотезы из-за объемов данных занимает более 20–30 минут, не делай изменения «вслепую». Сначала смоделируй результат на микро-выборке данных
5. Метод авиации - работа строго по чек-листу (если задача может быть решена по чек-листу)
Пилоты не полагаются на интуицию, они механически читают чек-лист перед взлетом. Чек-лист работает как рельсы: он забирает управление у импульсивного мышления и передает его строгой логике.
Алгоритм действий:
Создай себе текстовый файл «Базовый чек-лист» и заставь себя проходить по нему ДО того, как начнешь хаотично менять код или данные:
• Пункт 0: Прежде чем анализировать, нужно механически убедиться, что это та самая база, она не копия, документ проведен и у пользователя есть права. Там ли я смотрю, то ли я смотрю.
• Пункт 1: Проверить движения документа по регистрам (что именно он записал в базу, а не просто что горит на экране).
• Пункт 2: Проверить хронологию и время проведения документов (не затесался ли документ расчета позже документа выплаты в пределах одной секунды).
• Пункт 3: Проверить актуальность границ учета и последовательностей перерасчетов.
• Пункт 4: Проверить карточку субконто / аналитику (нет ли там дублей или пустых значений).
Пока все 4 пункта не проверены и результаты не зафиксированы — вносить правки запрещено.
ЧАСТЬ 2: ЛОГИЧЕСКИЕ ИНСТРУМЕНТЫ (ОРУЖИЕ АНАЛИЗА)
1. Декомпозиция (Метод утёнка и чистые функции) – разбить большую задачу на мелкие подзадачи
Когда задача кажется огромной, мозг паникует. Логический подход требует разбить её на изолированные элементы, где у каждого есть чёткий вход (входные данные) и предсказуемый выход (результат).
• Алгоритм: Сформулируй конечную цель в одно предложение. Разбей её на 3-5 подзадач. Если подзадача занимает больше 15 строк кода или 10 минут размышлений, декомпозируй её ещё раз. Проговаривай логику вслух воображаемому утёнку на столе. Если не можешь объяснить механику утёнку — ты сам её ещё не понял.
2. Дифференциальная диагностика - сужение зоны поиска
Часто Система 1 паникует, потому что задача кажется огромной. Нужно добавить микро-алгоритм сужения зоны поиска.
Суть: Если система (код, база, сеть) не работает, последовательно отсекай по 50% системы, чтобы понять, где именно сбой.
Ошибка на стороне платформы/сервера или в коде? Если в коде — она в типовом механизме или в доработке? Если в доработке — она в запросе или в обработке результата? Зафиксируй точку, где всё ЕЩЕ работает правильно, и точку, где уже НЕ работает. Ищи проблему строго между ними.
Когда система сломалась, не пытайся угадать ответ. Изолируй проблему, отсекая лишнее с помощью трех жестких фильтров:
Пошаговый алгоритм:
Задай системе (или пользователю) три вопроса для деления задачи пополам:
Фильтр 1: «Где это ЕСТЬ, а где этого НЕТ?»
• Ошибка воспроизводится только у этого сотрудника (проблема в его личных данных, кадровых переводах, вычетах)?
• Или у всей организации (проблема в общих настройках учетной политики, сломался общий алгоритм, обновился релиз)?
Фильтр 2: «Что ИЗМЕНИЛОСЬ прямо перед тем, как всё сломалось?»
• Если еще вчера всё считалось правильно, а сегодня нет, то что произошло в этот промежуток?
• Был обновлен релиз 1С?
• Бухгалтер ввела новый (нетипичный) документ?
• Поменялись настройки какого-то начисления или признак «Является доходом в натуральной форме»?
Фильтр 3: «Каковы ГРАНИЦЫ проблемы?»
• Ошибка только в этом месяце или в прошлых периодах тоже «поплыло»?
• Ошибка только при проведении конкретного документа (например, «Увольнение») или в общем «Начислении зарплаты» тоже?
Собрав ответы на эти три фильтра, ты сузишь зону поиска с огромной конфигурации до одной конкретной настройки или одного документа.
Так же можно использовать метод Input -> Process -> Output
Не пытайся понять сложную систему (Linux, 1С, налоги) как неделимый монолит. Любая система в мире — это просто конвейер, который принимает что-то на входе, как-то это преобразует и выдает на выходе.
Алгоритм действий:
Когда ты сталкиваешься с непонятным процессом, мысленно (или на бумаге) раздели его на три коробки:
• Вход (Input): Какие данные, файлы, сигналы или документы заходят в этот узел? Откуда они берутся? Они валидны?
• Процесс (Process): Какое именно математическое, логическое или программное преобразование происходит внутри этой «черной коробки»? (Какая функция вызывается, какой демон обрабатывает запрос?).
• Выход (Output): Что получается на выходе? Куда этот результат передается дальше?
Если система выдает ошибку, твоя логика механически проверяет эти коробки по очереди:
1. Если Input кривой — чинить Process бесполезно.
2. Если Input идеальный, а Output сломан — проблема строго внутри коробки Process.
Этот фокус мгновенно убирает кашу из головы и сужает зону поиска до одного конкретного шага.
3. Поиск первопричины (5 Почему и Бритва Оккама)
Отделяй корреляцию (вещи происходят одновременно) от причинно-следственной связи и отсекай лишние сущности.
• Бритва Оккама: Самое простое объяснение из возможных, скорее всего, является верным. Не усложняй архитектуру кода или выводы, пока не опроверг простые гипотезы.
• Техника «5 Почему»: Столкнувшись с багом, задай вопрос «Почему это произошло?» 5 раз подряд, продвигаясь вглубь системы, а не оставаясь на поверхности, пока не дойдешь до системного решения.
4. Матрица Декарта (Принятие критических решений)
Классический квадрат «Плюсы и минусы» плохо работает, потому что мозг фокусируется только на очевидном. Матрица Декарта заставляет посмотреть на последствия решения с четырех разных сторон.
Перед сложным выбором ответь на 4 вопроса:
а. Что БУДЕТ, если это ПРОИЗОЙДЕТ? (Плюсы сценария).
б. Что БУДЕТ, если это НЕ ПРОИЗОЙДЕТ? (Плюсы сохранения текущего положения).
в. Чего НЕ БУДЕТ, если это ПРОИЗОЙДЕТ? (Минусы и потери от изменения).
г. Чего НЕ БУДЕТ, если это НЕ ПРОИЗОЙДЕТ? (Минусы сохранения текущего положения — самый сложный вопрос, ломающий шаблоны).
5. Борьба с когнитивными искажениями (Инверсия и Фальсификация)
Наш мозг склонен искать подтверждения своей правоты (Confirmation Bias). Логика требует обратного — попытайся себя опровергнуть.
а. Метод Поппера (Фальсифицируемость): Спроси себя: «Какое событие или какой результат теста докажет, что я полностью неправ?». Если такого условия нет, твоя логика ущербна.
б. Инверсия: Вместо «Как сделать этот алгоритм эффективным?», спроси себя: «Что гарантированно поломает этот алгоритм или сделает его максимально медленным?». Понимание уязвимостей даст ключ к сильному решению.
6. Метод граничных условий (Тестирование стрессом)
Суть метода:
Быстрое мышление проверяет систему только в «идеальном состоянии» (когда всё идет по плану). Логическое мышление всегда ищет экстремальные точки, в которых система гарантированно испытает стресс. Это применимо и к коду, и к администрированию, и к бизнес-процессам.
Алгоритм действий:
Перед тем как запустить процесс, сдать задачу или написать алгоритм, проверь его в 4 граничных точках:
1. Точка «Ноль / Пустота»: Что произойдет, если на вход не придет вообще ничего? (Пустая строка в коде, нулевой баланс, пустой файл конфигурации, сотрудник без единого дня явки). Система упадет или корректно обработает пустоту?
2. Точка «Избыток / Бесконечность»: Что будет, если данных придет в 10000 раз больше нормы? (Огромный лог-файл, который забьет диск; расчет зарплаты по холдингу из 50 000 человек). Где узкое место, которое заклинит?
3. Точка «Отрицание / Инверсия»: Что будет, если ввести данные с противоположным знаком или смыслом? (Отрицательная сумма налога, увольнение сотрудника задним числом, дата из будущего).
4. Точка «Одновременность»: Что будет, если два процесса попытаются сделать это одновременно? (Два бухгалтера одновременно проводят расчет по одному человеку, два сервиса пишут в один файл).
ТРЕНИРОВКИ
Тренировка «Черный ящик»
Возьми любой привычный процесс (например, покупка билета на поезд или отправка сообщения в мессенджере). Распиши его в виде блок-схемы. Выдели строгие условия «Если/То» (IF/THEN). Найди в этой схеме три места, где система может выдать ошибку, и пропиши логику поведения для этих сбоев.
Тренировка «Поиск первопричины»
Выпиши реальную проблему из своей практики (например: «База данных стала отвечать медленнее»). Раскрути её через 5 уровней «Почему».
Пример:
1. Почему? Увеличилось время выполнения запросов.
2. Почему? Запросы ищут данные по неиндексированным полям.
3. Почему? Новая фича добавила поиск по новому параметру.
4. Почему? При разработке фичи не создали нужный индекс.
5. Почему? В чек-листе деплоя нет пункта проверки индексов.
Решение найдено: дело не в «плохой базе», а в системном чек-листе.
Тренировка «Квадрат решений»
Возьми актуальный для тебя выбор (например: «Стоит ли переходить на новый фреймворк/язык в проекте?»). Черти квадрат 2х2 и честно выпиши минимум по 3 пункта в каждый из четырех секторов Матрицы Декарта.
Тренировка «Разрушитель гипотез»
Посмотри на свой последний написанный модуль кода или аналитический вывод. Напиши три сценария (граничные условия, экстремальные объемы данных, невалидный ввод пользователя), при которых твоя логика полностью сломается. Измени систему так, чтобы учесть эти три фактора.
