«Русская модель управления» Прохоров А.П.

Это не книга, а Книга. Даже КНИГА. Для меня по крайней мере.

Так уж вышло, что это – первая книга про управление, которую я прочитал. Года 22 мне тогда было. Зашёл, помню, в книжный магазин, глянул на полку – она на меня смотрит и молчит. Как-то вообще без вопросов взял и купил.

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

Книга совершенно уникальна. Она вообще ничему не учит. Там нет ни одной рекомендации – где-то в послесловии пара слов написана в стиле «вот если бы наши менеджеры делали то-то», и на этом всё. В книге нет ничего, названного Стивеном Кови «аспирин» - «бери и пользуйся».

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

Если вы читали книги по управлению – а они, в основном, западные – то понимаете, что Прохоров перевернул повозку лошадью вперёд. Он не рассказывает, что надо сделать для достижения результата – т.е. сначала процесс, потом результат. Он разбирает результаты и анализирует их причины. Да простят меня возможные любители Джима Коллинза – тот написал в схожем стиле свою «От хорошего к великому», только объект исследования разный: у Коллинза – лучшие компании, у Прохорова – тысячелетняя история целого народа.

Важно не противопоставлять написанное Прохоровым тому, что пишут другие авторы (особенно зарубежные). А то, знаете, есть любители – «всё, теперь только по-русски управлять будем, нахрен зарубежное всё». Или наоборот – «я продвинутые западные книжки читал, а тут чушь какая-то про кластеризацию систем управления». Всё это прекрасно сочетается. Более того – оно словно создано для синергии (будьте здоровы).

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

Вот для чего нужен Прохоров и его русская модель управления.

Из моего Книжного стека.

Про книжки, из Книжного стека.

«Хватит мечтать, займись делом! Почему важнее хорошо работать, чем искать хорошую работу» Кэл Ньюпорт

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

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

Автор книги выразил ту же мысль лучше, даже показатель придумал — «карьерный капитал». Который, собственно, и надо копить. И на его увеличении сосредоточиться. Глаз немного цепляется за слово «карьерный», как будто речь о должности или положении — не обращайте на это внимания, просто слово не очень удачное выбрано. Или переводчики не нашли более подходящего.

Короче, книга прекрасная. Помогает расставить приоритеты, сосредоточиться на том, что точно важно и не пропадёт даром.

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

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

Мы с Кэлом Ньюпортом утверждаем 😊: рынок труда будет постоянно меняться, а вечные ценности остаются.

Про книжки, из канала "Книжный стек"

«Искусство спора. Как читать книги» Поварнин С.И.

Книга состоит из двух несвязанных половин. Первая – про ведение споров, вторая – как читать книги.

Первая часть, про споры – максимально практичная, с конкретными приёмами, видами споров, стратегиями их ведения, прекращения, выхода из спора и т.д. Книга написана в начале 20 века, но по сути, ничего с тех пор не изменилось, поэтому всё – актуально. Разве что письменные споры стали быстрее, чем 100 лет назад.

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

Я эту книгу прочитал недавно, но очень порадовался – она сильно попала в подходы, которые я сформулировал сам для себя, но автор сформулировал три потока тем для чтения более чётко, конкретно и объяснил, зачем и почему.

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

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

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

Первая часть книги, про ведение споров, мне помогла убедиться в некоторых собственных установках. Например, в том, что в большинстве споров вообще не надо участвовать. Если спроецировать методы начала 20 века на сегодня, то я уверен: автор добавил бы «не спорьте в интернете, кроме случаев, когда знаете собеседника лично».

Раньше, до прочтения этой книги, я называл это правилом Ральфа (т.к. видел его в мультфильме «Ральф против интернета»). Там сказали: «Первое правило интернета – никогда не читать комментарии». Я трансформировал в «никогда не вступать в дискуссии в комментариях».

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

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

Книгу рекомендую. Хорошая, старая, добротная, для читателя.

Пришла ко мне соц.сеть под названием "Сетка" и предложила там публиковаться.

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

Почему бы и нет, подумал я. Вдруг из этого что-то интересное получится.

Подписывайтесь, если интересно. Я подпишусь на вас в ответ.

https://setka.ru/users/019d2bf2-cd96-76f1-ab5e-5cb83851c514

Случайно наткнулся в интернете на информацию о OMAD-диете (One Meal A Day — «один прием пищи в день»). Оказывается, популярная штука, особенно среди голливудских звёзд, т.к. сильно упрощает контроль за приёмами пищи, калориями и т.д. при высоконагруженном графике работы.

Кроме, собственно, снижения веса у OMAD есть положительные эффекты, связанные со здоровьем - снижение сахара, улучшение метаболизма. Связывают с явлением аутофагии, которая подключается из-за 23-часового интервала голодания. И вообще, само появление OMAD связывают с открытием и популяризацией аутофагии - Нобелевскую премию её открывателю выдали в 2016 году.

Почему пишу об этом… Я ж тоже раз в день питаюсь, как прям в OMAD-диете :) Начал, правда, сильно раньше 2016 года, когда не было информации ни про OMAD, ни про аутофагию.

Саму эту идею я узнал из двух старых книг. Одна была Галины Шаталовой, советского врача (вот только не помню, какую именно книгу читал). Вторая - Арнольда Эрета, который писал вообще в начале 20 века (название книги, увы, тоже не помню).

Что ж теперь получается? Во-первых, я (и вы) получил независимое подтверждение, верификацию действенности такого метода снижения и контроля веса. Ссылаться на OMAD - проще и авторитетнее, чем на себя несчастного. Во-вторых, могу служить объектом-доказательством, а то и объектом исследований как действенности OMAD, так и долговременного её влияния на здоровье (всё-таки опыт более 10 лет).

Такие вот дела.

https://t.me/bodymath

Аргумент растущей кучи

Полезные штуки можно встретить в самых неожиданных книгах. Читая очередную из серии «у меня много подписчиков, поэтому я решила книгу написать», наткнулся на прекраснейшую вещь: аргумент растущей кучи, взятый автором из книги Эразма Роттердамского «Похвала глупости».

Звучит аргумент растущей кучи так: «Если десяти монет недостаточно, чтобы сделать человека богатым, что будет, если добавить одну монету? А если добавить еще одну? Наконец, придется сказать, что никто не может быть богатым, поскольку его не может сделать богатым одна монета».

Не правда ли, каждый день подобный вопрос возникает? Что толку писать один пост в блог, если он не взорвёт интернет и не привлечёт массу подписчиков? Зачем мне садиться и делать одну задачу, если проект от этого не завершится? Ну что случится, если я сегодня не схожу на пробежку? Подумаешь, не поговорю сегодня с подчинённым – не убудет от него!

Вот это одно, любое, простое действие – та самая монета. Мозг говорит: от одной монеты куча не изменится, и что толку на неё время тратить. Нужно заниматься чем-то серьёзным! Думать, как сделать сразу 1000 монет! Только это имеет значение!

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

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

Потихоньку расскажу, как сильно ускорять тяжёлые обновления 1С. Сегодня - про ускорение отложенных обработчиков.

Чтобы понять, какие обработчики долго выполняются, достаточно обновить копию и посмотреть. В форме выполнения обработчиков прям время будет написано, в днях/часах, сколько выполнялся обработчик. А сколько ему надо было объектов промурыжить - видно в отчёте “Прогресс отложенного обновления”.

Например, у нас сильно тормозил обработчик регистра сведений “РеестрДокументов” - выполнялся больше суток. Ему надо было перезаписать 9 млн. записей (столько в базе было документов).

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

Дальше идём в три процедуры модуля менеджера обновляемого объекта:

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

2. Процедура регистрации (обычно ЗарегистрироватьДанныеКОбработке). В ней надо забрать запрос, который формирует данные к обработке. Обычно там всё несложно - запрос, выборка результата и его складывание в план обмена (ОбновлениеИнформационнойБазы.ОтметитьКОбработке). Нам нужен только запрос и выборка данных, в план обмена ничего писать не нужно.

3. Процедура выполнения обработчика (обычно ОбработатьДанныеДляПереходаНаНовуюВерсию). Там лежит код обработки. В нём много лишнего (обвес для типовых процедур обновления), но суть обычно понять несложно - читаются данные, сформированные п.2, и что-то с ними делается. Бывает, ещё один-два запроса делаются. Берём вот эту содержательную часть и забираем себе. Не забываем заменить ОбновлениеИнформационнойБазы.ОтметитьВыполнениеОбработки на обычную запись - нам не надо регистрировать обработку в плане обмена.

Дальше нужно написать обработку, которая запустит энное количество ФЗ, каждому скормит массив данных к обработке (из п.2), и ФЗ выполнит адаптированный код из п.3. Мы делали расширение, в него складывали процедуру ФЗ, на входе - массив (обычно это массив ссылок). В процедуре - код из п.3. И обработку внешнюю, в которой мы указываем количество потоков, она выполняет большой запрос из п.2, делит результат на потоки, и запускает кучу ФЗ. И всё.

Контролировать прогресс выполнения можно разными способами. Первый, который я использовал - просто выполнял запрос из п.2. Подавляющее большинство запросов в обработчиках обновления написано так, что возвращают только необработанные данные. Соответственно, их в процессе выполнения становится всё меньше. Но этот запрос может выполняться сильно долго. Потом я сделал несложный регистр сведений, и в каждое ФЗ положил пару строк записи в этот РС - после обработки каждого объекта ФЗ “отчитывалось”, и в регистре было видно общий прогресс.

При наличии нормального объёма ОЗУ запускать такие обработчики можно и в 16, и в 32, и в 48, и даже в 100 потоков (проверено). Это количество ФЗ на один обработчик. А вообще мы в это распараллеливание вывели 22 обработчика из 4 редакций.

Ускорение получается очень существенное - тот, который выполнялся сутки, стал выполняться за 4 часа.

https://t.me/ywhite

Про типичный паттерн, который помогает решать задачи по производительности в 1С.

Оптимизировали как-то мы обмен (как начало сказки звучит 😁). Вообще, началось не с обмена, а с “иногда 1С внезапно начинает тормозить”. Посмотрели журнал регистрации, выполнение регламентных и фоновых - увидели, что обмен идёт.

Обмен самописанный, под конкретную задачу. В одной базе живут продажи, в другой - номенклатура, цены, штрихкоды и т.д. (некая база с мастер-данными). Когда цены меняют, они должны сразу попасть в базу с продажами (там Розница стоит). Вот этот обмен и тормозил. Провели установку цен - подвисли. Обмен обычный, универсальный, с правилами (на конвертации данных 2).

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

Второй подозреваемый - количество выгружаемых данных. Здесь важно понимать паттерн - он часто помогает при оптимизации даже типовых 1Сных решений. Паттерн такой: разработчик почти всегда тестирует на ограниченных данных и в идеальной среде (если не было задачи именно оптимизированный алгоритм написать). Если он пишет обмен, то проверяет на 1-2-10 объектах. И на идеальной среде - в которой нет никого, кроме него. Если разрабатывает планирование, то для 2-3 заказов. И там, где он один. И т.д.

Вообще, это всё ежу понятно. Но когда дело доходит до проблем с производительностью, то почему-то паттерн этот часто забывается. Забывание выражается в том, что все исходят из предпосылки “там всё правильно сделано”. А это не всегда так. Оно сделано правильно, но для небольшого объёма данных и для среды, где нет пользователей и другой нагрузки.

Вот и в нашем случае, первые мысли были - переписать весь обмен. Вообще уйти от XML и правил, написать сервис. Потом немного одумались, вспомнили паттерн, и пошли проверять файл с сообщением обмена.

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

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

https://t.me/another1C

Конечность силы воли (из серии «математика воли»)

Главное, фундаментальное, что я узнал о силе воли — она конечна, то есть умеет убывать, заканчиваться. Как деньги в кошельке, физические силы, заряд в батарее смартфона.

В любой момент времени — сейчас, например — у вас есть определённый запас силы воли. Которого лично вам хватит на выполнение каких‑то действий — дочитать этот текст, сходить почистить зубы, не съесть на ночь тортика, почитать книгу, сделать уроки. А на какие‑то действия этого запаса не хватит — тогда вы не дочитаете текст, не почистите зубы, съедите тортик (а то и два), отложите книгу, оставите уроки на завтра (или на «вдруг не спросят») и пойдёте в интернет.

Из всех аналогий наиболее близкой мне всегда казалась мана — запас магической энергии в компьютерных играх. Помните? Обычно есть красная колбочка — это здоровье, оно убывает, когда от кого‑то получаешь. И синяя — мана, запас энергии. Он убывает, если колдовать. Потом восстанавливается — или сам (если не тратить), или если зелья восстановления пить.

Сила воли похожа на ману. Делая что‑то, хоть немного трудное, мы расходуем силу воли. Если расходовать быстро, не давая восстановиться — уходим в ноль и идём тупить. Если некоторое время подождать — она восстановится.

Наверное, вы уже поняли мою мысль. Теперь осталось принять.

Телеграм

Съездил на прошлой неделе на конференцию Инфостарта, доклад читать.
Каждый раз, возвращаясь оттуда, думаю — больше не поеду. А через год забываю, почему так решил. Попробую тут записать, может тогда не забуду 😁 Или Инфостарт включит меня в чёрный список.

Всё, что пишу — рациональный взгляд со стороны старого докладчика. Я ездил на конференции Инфостарта с 2015 года.

Первое — я долго ездил туда по инерции, руководствуясь старыми причинами, которые не актуальны уже лет 10. Раньше Инфостарт (и сайт, и конференция) был главным местом тусовки 1Сников. Не единственным, но главным. Не было кучи блогеров, альтернативных каналов и ресурсов, где 1Сники тусуются, онлайн и вживую.

Соответственно, у выступлений на конференциях Инфостарта была высокая конверсия.
Выступить тогда на Инфостарте — всё равно, что попасть на Первый канал в 90-е. Тебя увидят и услышат все. И на выступлении всё не закончится — оно продолжится на сайте Инфостарта, так как сообщество и конференции синергично связаны.

Сейчас Инфостарт перестал быть главной тусовкой, а стал одной из. Возможно, на данный момент — самой крупной. Но точно не единственной. Дальше — простая неумолимая математика. Твой доклад увидит столько же людей, что и 10 лет назад — столько, сколько придёт в зал. Даже при битком набитом зале будет несколько сотен человек.
Если выложить своё выступление в блог или видеоканал — получишь больше просмотров, при несопоставимо более низких затратах.

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

Ну и третья часть конверсии — в узнаваемость в сообществе, то есть на сайте Инфостарта.
Она нивелировалась вслед за развитием других тусовок 1Сников — блогов, сообществ, конференций.

Вот такая математика. Из‑за неё каждый раз и собираюсь больше не ехать.

Но всё равно еду :)

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

Для тех, кто не выступает — конференции Инфостарта очень хороши. Это действительно так.

Для начинающих же докладчиков конференции Инфостарта — по‑прежнему лучшая точка старта, на мой взгляд.

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

А у Инфостарта продуктовая линейка докладчиков сейчас хорошо разделена. Есть хэдлайнеры и конкурсный отбор, через который прогоняют и новичков, и докладчиков с опытом (это некое «среднее звено»). Через конкурсный отбор точно можно пройти. И точно можно не пройти, даже будучи докладчиком с опытом (я однажды не прошёл 😂).

Короче, кто хочет попробовать себя в роли докладчика — вам точно на Инфостарт.
Кто хочет посмотреть/послушать/поучаствовать — вам точно на Инфостарт.
Кто старый прагматик, как я — тому дома на диване сидеть 😊.

Телеграм

Один хороший человек, зовут Руслан, в своём тг‑канале написал небольшой текст про мой «Универсальный механизм планирования» (УМП). Руслану можно верить — он несколько раз внедрял УМП. На практике знает, насколько сложно решать реальные задачи планирования в 1С.

Думаю, опубликовать его текст будет уместным. Тем более, что УМП я распространяю бесплатно (прям здесь). Кстати, Руслан когда‑то тоже скачал УМП бесплатно, внедрил, и только через несколько лет я об этом узнал:)

Итак, текст Руслана.

«Как же долго я тебя искал…»

Знакомьтесь — УМП, универсальный механизм планирования. Когда я впервые про него узнал, радости было ещё больше, чем от автозадач.

Почему? Потому что он умеет делать главное, что должно уметь любое планирование — распределять ограниченные ресурсы (деньги, товары, время работы оборудования и так далее) на потребности (планы оплат, заказы клиентов, планы производства…). И, что важнее всего, делать это гибко, по любым условиям.

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

Пример из практики
Производственное предприятие, которое работает в основном под заказ. Главный вопрос от менеджеров:

«Сможем ли сделать и отгрузить к нужной дате?»

В 90% случаев ответ упирается в одно — наличие сырья. А тут всё сложно:

• ассортимент продукции большой

• сырьё может лежать на складе

• а может быть «в пути» от поставщика

Посчитать это в типовой ERP — задачка не из простых. И тут на сцену выходит УМП.

Что мы сделали

1. Разузловали спецификации готовой продукции до конечных материалов и храним их в специальном регистре — это ускоряет расчёт.

2. В УМП распределили материалы на складе и «материалы в пути» (с учётом даты поступления и времени, необходимом на изготовление продукции) на заказы покупателей.

3. Каждый заказ получил статус:

• обеспечен

• обеспечен частично

• не обеспечен

4. В отчёте видно какого именно сырья не хватает и под какие изделия.

5. В журнале заказов добавили светофор, чтобы статус был виден сразу.

6. В АРМ «Формирование заказов по потребностям» диспетчер видит этот же статус и понимает — включать заказ в производство или нет.

В итоге

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

В следующей части расскажу про автоматизацию планирования в производстве.

Про отличия обучения зумеров. Ещё раз акцентирую внимание — текст не содержит оценочных суждений, не ищите тут скрытого смысла «зумеры плохие» или «с зумерами что‑то не так». Каждое поколение отличается от предыдущих. Бэби‑бумеры тоже много написали бы про особенности обучения миллениалов, но у них не было интернета.

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

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

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

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

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

Телеграм

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

Их трёх реакций (бей, беги, замри) любимая реакция зумеров — замри.
Вторая по частоте использования — беги.
И крайне, невероятно редко — бей.

Это немного непривычно для руководителя, который раньше с зумерами не работал. Они очень неконфликтные. Настолько неконфликтные, что с ними сложно разговаривать, если тема или тон разговора хоть немного попахивают агрессией, критикой и так далее
Зумер не защищается, не оправдывается, не спорит — он просто замолкает («замри»). И думает лишь о том, чтобы неприятный для него разговор побыстрее закончился («беги»).

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

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

Телеграм

На одном из проектов перехода с УПП на ЕРП возник неожиданный субподрядчик, который добавил приключений и нам, и заказчику.

Заказчик работает с сетями, а где сети — там какой‑нибудь хитровыдуманный электронный документооборот.

В основе — просто модуль/обработка, написанная какой‑нибудь известной компанией, но обязательно — доработанная на месте под требования сети.

И вроде бы — что может случиться, если мы переходим с УПП на ЕРП, и для обеих конфигураций есть версия модуля ЭДО?
Код модуля — открыт, доработки под сеть — известны. Что может пойти не так?

Первое, что пошло не так — разработчики модуля сказали, что ни нам, ни заказчику нельзя его дорабатывать. А кто там его доработал несколько лет назад для УПП — уже никто и не помнит. Ну, ладно, хозяин‑барин — нельзя так нельзя. Спрашиваем — так, а можете нашему заказчику‑то доработать? Хотя, чего нашему — он и ваш заказчик.

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

В декабре ребята честно что‑то дорабатывали, под конец года отдали результат, и все торжественно ушли Новый Год встречать. В январе, на каникулах, мы запускаем ЕРП, ну и... Доработанные ребятами модули, конечно, не работают. Ну ладно, думаем, ничего страшного = серьёзные штуки никогда с первого раза не работают. Сейчас напишем ребятам, они помогут.

Пишем ребятам, и оказывается... Тех.поддержка не работает (в первые дни каникул).
А заказчику уже отгружать надо — сети, они такие. Там нельзя не отгрузить.
Что делать? Или самим‑таки доработать (но разработчики ЭДО грозили штрафами), или из УПП отгрузки делать. Выбрали второе — сели несчастные люди и вбили реализации в УПП, просто чтобы выгрузить в ЭДО.

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

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

По окончании каникул подрядчик, конечно, всё быстренько починил.
Претензий нет, если что. Просто не знал, что так бывает :)
Теперь знаю. Придётся учитывать этот риск в следующих проектах.

Телеграм

Попалась на глаза статья статья (В чем плюсы использования интервальных регистров) на Инфостарте, про интервальные регистры сведений в ЗУПе. Вспомнил, что недавно использовал эту ЗУПовскую идею для совершенно другой задачи — интервального хранения цен. Но цель использования интервальных РС — та же, оптимизация скорости выполнения запросов и удобства их написания.

Проблема была такая. Есть КА1, в ней — дофигищща чеков. В чеке есть цена продажи, но нет себестоимости. Можно получать какую‑то себестоимость, если включить оценку стоимости списания при проведении документа (фифо, средняя), но это замедлит проведение документов (а их очень много).

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

У клиента уже было своё технико‑методическое решение — считать себестоимостью цену последнего закупа номенклатуры.

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

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

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

Хорошая штука эти интервальные регистры. Рекомендую.

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

В основном такие переходы - вынужденные, вроде отказа от УПП.
Заказчику всё нравится в его УПП, но так уж вышло, что её больше не поддерживают, и придётся переходить.
Поэтому хочется всё сделать с минимальными затратами. Это один из ключевых критериев.

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

На данный момент мы сделали 6 таких проектов:

1. Два перехода УПП - ЕРП;

2. Два перехода УПП - КА2;

3. Один переход УНФ - КА2;

4. Один переход УПП - Аренда (там БП внутри).

Ещё два проекта в процессе, их рано включать в статистику.

Средний чек проекта - 1274 часа.

https://t.me/another1C

P.S. Думаю, надо статью написать, предметную - как такие проекты делать, чтобы экономить на переходе.

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

Перевёл потому, что один потенциальный клиент попросил - хотел посмотреть, что за штука это управление задачами Flowcon.

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

Детальное описание всего Flowcon - https://infostart.ru/marketplace/976048/
В данном расширении - часть "Управление задачами". Ещё включил "Управление компетенциями", но пока не тестировал - сделаю это позже.

А вот на что точно стоит обратить внимание - на часть про регулярный менеджмент. Это штука, которой я сам пользуюсь каждый день. Что это, зачем, и как - описано в отдельной статье - https://infostart.ru/pm/998824/

Расширение можно скачать в тг-канале: t.me/another1C

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

В обновлениях больших и нагруженных баз есть такая проблема - пролезть в "окно" (ещё его называют технологическим окном).
Это время, на которое можно остановить базу 1С для обновления, без существенных потерь для бизнеса.
В нашем случае окно было размером в 40 часов.

Вообще, это не так уж и мало, но... Надо было обновить на 4 редакции - с УТ 11.4.14 до 11.5.22.
Кто помнит обновление на 11.5.8, в котором появились распределение запасов и объекты расчетов, понимают - там время обновления измерялось, скорее сутками.
Обращаю внимание - надо было обновить все 4 редакции в одно окно 40 часов.
Так сильно дешевле, чем накатывать по одному релизу и запускать пользователей. Причём, дешевле в разных всех смыслах - не надо адаптировать конфигурацию под каждый релиз (можно это сделать один раз в конце), не надо мучить людей (заставляя переживать 4 обновления, 4 смены некоторых интерфейсов и механизмов).

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

Короче, надо было сжать 300 часов времени обновления в 40, т.е. в 7-8 раз.

Ну и чё... Получилось 😁

Применили нестандартные методы предварительной подготовки конфигурации и данных, оптимизацию обработчиков, обрезку данных - и оно зашуршало сильно быстрее.
Модных режимов, вроде обновления через копию, не применяли. Никакого вмешательства в СУБД не было. ИИ не использовали :)

Как-нибудь соберусь, напишу статью - там есть, что рассказать.

https://t.me/another1C

Снял видео про один из способов применения расширения "Рабочий стол" - дашборды рисовать. Лично для меня, как пользователя, это главный способ применения рабочих столов. Эдакий дешманский BI, с очень быстрой настройкой и перенастройкой.

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

Правда, дашборды типа "отчёт" (о которых речь в видео) - не самое эффектное представление данных, есть ещё диаграммы. Но про них я отдельное видео сниму.

А пока вот:

https://vkvideo.ru/video-208482299_456239491
https://youtu.be/1rln84eMBwc

Расширение можно скачать тут - https://t.me/another1C/48

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

Также снял видео-знакомство с простейшими функциями рабочего стола (для тех, кто раньше не видел это расширение)
https://youtu.be/-SMc-Q2EOiw
https://vkvideo.ru/video-208482299_456239487

Скачать решение можно в тг-канале https://t.me/another1C