Интереснейший текст социолога Сергея Белановского про работу советских производственных начальников на этапе загнивания совка. Пара цитат:

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

[…] привело к резкому увеличению числа предприятий, на которых наблюдалось абсолютное снижение численности работников. Плановые задания по объему производства на таких заводах, как правило, не корректировались, а выделяемые капитальные вложения не всегда оказывались достаточными для компенсации убыли рабочей силы. Рост производительности труда обеспечивается в этом случае за счет искажения отчетности, т.е. все более становился фиктивным.

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

И вдогонку к предыдущему:

Сильно затрудняет работу то, что у нас посокращали вспомогательных рабочих, занятых под землей. Сокращение вспомогательных рабочих ухудшает качество ремонта и затрудняет поддержание порядка в нашем хозяйстве. Это очень серьезно, в перспективе это грозит авариями, жертвами. Соблюдение даже самых необходимых правил безопасности дается нам сейчас с очень большим трудом (начальник участка шахты «Капитальная» ПО «Южкузбассуголь», 1981г.).

Дефицит работников сказывается на моей работе самым непосредственным образом. Сейчас я вынужден брать на работу таких людей, которых я раньше ни за что бы не взял. Как-никак у нас работа ответственная, мы ремонтируем оборудование. И если ко мне приходит человек, которого уже дважды увольняли за прогул, то он и у меня будет пьянствовать и прогуливать. За таким работником нужен глаз да глаз, за ним всю работу нужно проверять. А еще, не дай бог, свалится откуда-нибудь, отвечай за него потом (мастер ремонтного цеха Волжского завода синтетического каучука, 1984г.).

Сейчас у меня рабочих сократили настолько, что некому стало заниматься снабжением участка. Резину привезти, пресс-форму, деталь какую-нибудь — все это теперь я делаю сам. Еще десять лет назад такого у нас не было (мастер завода резинотехнических изделий ПО «Днепрошина», 1983г.).
Из-за отсутствия рабочих нередко бывает, что я сама вынуждена садиться за конвейер. О мастерах я не говорю, они работают на конвейере почти каждый день (начальник участка Ленинградского производственного объединения «Красный треугольник», 1984г.).

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

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

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

Но одного учебника мало, в упомянутой книге Левенчука даётся куча ссылок на дополнительные тексты, из которых собственно и сформирован курс: книги и международные стандарты. Всё на английском, актуальных русскоязычных источников нет, а официальные переводы (ГОСТ ИСО) международных стандартов разрозненные и неконсистентные.

И если вы не боитесь концептуальной сложности, очень рекомендую прочитать и понять книгу «Системное мышление 2019». У меня это заняло несколько месяцев вдумчивого изучения, да и даже сейчас не могу с уверенностью сказать, что действительно всё понимаю. Но в одном моменте уверен точно — процесс мышления радикально изменяется и мне этот новый процесс нравится.

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

Так что привыкайте к мысли, что ИТ — это сфера услуг, а не производство.

Продолжим с очевидными фактами.

У любой компании есть декларируемые ценности, а есть истинные ценности. Чаще всего они или совсем не совпадают, или же истинные более приоритетны. Декларируемые ценности не имеют никакой практической пользы для окружающего мира, поэтому их нужно сразу отбросить и сосредоточиться на истинных. И тут начинаются сложности, так как истинные ценности часто выглядят слишком откровенно с точки зрения массовой морали: больше денег, больше влияния, уничтожить конкурентов, приручить конкурентов, поглотить конкурентов — всё как в дикой природе. Из-за такой откровенности в массовых СМИ пишут очень мало текстов, затрагивающих суть компаний. И даже если пишут, оборачивают в двусмысленные (но пристойно выглядящие) конструкции, поэтому массовые СМИ нужно априори воспринимать с осторожностью и уметь читать между строк.

В прошлой конторе однажды наступили на эпичные грабли.

Пришло письмо от админов зарубежной компании с текстом типа: ПЕРЕСТАНЬТЕ ЛОМАТЬ НАШУ СЕТЬ! Начали разбираться и выяснилось, что разработчики и тестировщики при заполнении конфигов вбивали IP-адреса сервисов типа 1.2.3.4. Сервис прилежно этот адрес принимал и начинал на него честно что-нибудь отправлять…

Поэтому совет, если нужно вбить при тестировании куда-нибудь IP-адрес, не пишите 1.1.1.1 или 1.2.3.4, это чревато в том числе утечкой данных. Конечно, админы должны настроить фаервол так, чтобы из тестового окружения ничего не уходило, но так бывает не всегда.

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

В русской (=советской) культуре отсутствует понимание слова «сертификат». Я специально нашёл картинку, которая сразу же имеет смысл для американца (америка — двигатель айти), для советского человека это просто какая-то бумажка с какой-то нашлёпкой, почётная грамота, может. А сертификат — это документ, подтверждающий что-нибудь: учёное звание, образование, полученный скилл, короче — какое-то достижение или приобретение. У нас самое близкое по смыслу слово — «удостоверение», но оно больше ассоциируется с бюрократией и турникетом с вахтёром. Тем не менее, в официальной бюрократии в России используется именно слово «удостоверение» и оно гораздо понятнее для нас, чем «сертификат». Крупные западные корпорации это прекрасно понимают и тоже используют слово «удостоверение». Например, Adobe, Microsoft, Autodesk и ещё куча.

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

Сертификат (как и удостоверение) имеет два главных свойства: кем выдан и кому или чему выдан, и дополнительные детали. Выдаёт сертификаты обычно некоторая организация, в русскоязычной терминологии называется «удостоверяющий центр» (issuer). Получает сертификат субъект (subject), это может быть человек, сайт, программа. В бумажном виде сертификат имеет печать, подпись или ещё какое подтверждение, что это именно удостоверяющий орган его выдал, на картинке это красивая печать снизу. Считается, что подтверждение (печать, подпись) подделать сложно и только удостоверяющий центр может её сделать. В случае цифрового сертификата таким подтверждением служит цифровая подпись, её тоже сложно подделать, если нет секретного ключа, который есть только в удостоверяющем центре.

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

И вот здесь как раз возникает главный вопрос: А откуда вообще возьмутся у проверяющего эти вот программы для проверки цифровой подписи? И это отдельная печальная история для отдельного поста.

Когда видим любую официальную статистику по заболеваниям, нужно чётко понимать степень достоверности этих данных. Если пишут «смертность от нового рыбьего гриппа составляет 14%», нужно это понимать так: из всех обратившихся в больницы, которым был поставлен диагноз рыбий грипп, умерло 14%. При этом за пределами наблюдений остаются люди, у которых заболевание протекло бессимптомно или которые перенесли болезнь на ногах. Выделенная фраза — это отдельный момент, далеко не всегда диагноз ставится правильно. Например, российский терапевт не может просто так написать диагноз «грипп», так как у него свои KPI есть, а за эпидемию гриппа его в том числе могут наказать. Так и получается, что гриппом болеют миллионы, а в статистику они не попадают. Аналогично и с этим рыбьим гриппом (который и не грипп вовсе), хер знает, что там вообще на самом деле происходит. Статистика, конечно, пытается эти нюансы учитывать и корректировать значения, но ГРОМКИЕ ЗАГОЛОВКИ уже всё решили, СМЕРТНОСТЬ 14%!!11

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

Как же хочется себе забрать контракт от государства на 10 млрд баксов! Частный бизнес, никак не зависит от государства!

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

https://ailev.livejournal.com/1502692.html

Agile — место проклятое. Его манифест явно декларирует:

* Individuals and interactions over processes and tools
* Working software over comprehensive documentation
* Customer collaboration over contract negotiation
* Responding to change over following a plan

А по факту реализации всегда превращается в бюрократию и ритуалы over всё остальное.

ИТ-инженер должен уметь находить и читать стандарты: RFC, ISO, IEEE и прочие. Это отдельный скилл, который нужно специально прокачивать.

Читать стандарты имеет смысл только когда у вас есть в этом необходимость. Концентрация информации в них очень высокая и вы гарантированно пропустите очень важные нюансы, если нет цели изучить досконально. А такая цель будет, если вам этот стандарт нужно использовать в работе.

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

Если стандарт не в виде PDF, то советую конвертировать и дальше работать именно с PDF. Сейчас по факту это единственный универсальный способ аннотирования текстового документа. PDF-комментарии поддерживает официальный клиент Acrobat Reader DC (windows/macos) и неофициальный Okular (linux), заметки созданные в одном, можно читать и править в другом.

После вводной части внимательно разбираемся с терминологией и принятой нотацией. Используемая нотация может полностью раскрываться в самом тексте либо в документе будет ссылка на внешний текст. Например, в RFC активно используются стандартные модальные глаголы/фразы вида SHOULD, MUST, MAY и прочие. Их смысл однозначно определён в собственных стандартах RFC 2119 и RFC 8174 и вам их нужно буквально вызубрить, чтобы эффективно работать с остальными текстами. Вся необходимая терминология как правило приводится либо в этом же стандарте, либо в каком-то другом, в этом случае даётся ссылка на него и нужно пойти и там её прочитать.

Хорошо освоенный скилл чтения стандартов автоматически развивает другой скилл — точного, однозначного и структурированного формулирования мыслей в виде текста. Я специально выделил слово, чтобы подчеркнуть важность текста. Вы обязательно заметите, что в стандартах очень довольно мало иллюстраций, а имеющиеся иллюстрации практически никогда не являются главными смысловыми носителями. К этом нужно привыкнуть и жить с этим, однозначно и формализованно объяснить в картинках не получится.

Можно часто встретить в документации API фразу типа “date format according to ISO 8601”. Обычно под этим подразумевается строка вида 2020-01-25T15:30:47, которая означает 15 часов 30 минут 47 секунд 25 января 2020 года. Вроде всё нормально, но нет.

Формат даты в соответствии с ISO 8601 — очень сложный. Текст стандарта состоит из сорока страниц очень насыщенной информации и если вы заявляете, что его поддерживаете, то я почти на 100% уверен, что это не так. Никто не может поддерживать ISO 8601 целиком, это безумная и абсолютно контрпродуктивная идея.

Конечно, приведённый выше пример (2020-01-25T15:30:47) выглядит понятно, однако стандарт позволяет задавать очень широкий класс обозначений даты и времени, которые ваша программа не способна переварить. Например, одну и ту же дату можно задавать так (все эти варианты валидные): 2020-01-25, 20200125, 2020W036, 2020-W046. Последние два варианта вряд ли какая программа переварит. Или как вам такое представление времени: 2020W046T2315Z?

Помимо «моментов» ISO 8601 также определяет правила описания интервалов, диапазонов дат и повторяющихся «моменов». Например, так: P00021015T103021 или P00010215T123000/20200412T232050, я даже не буду говорить, что это означает, всё равно шанс встретить их в реальном мире абсолютно нулевой.

Мораль: никогда не выпендривайтесь и не пишите, что поддерживаете ISO 8601, всё равно это не так. Выберите какой-нибудь фиксированный вариант и чётко ему следуйте.

Есть хорошее определение: Легаси — это код, который приносит деньги.

Источник.

Писать о системной инженерии чрезвычайно сложно. Частично из-за русского языка, где эта тема появилась сравнительно недавно и ещё не имеет устоявшейся общепринятой терминологии. А частично из-за очень сильной динамичности области, которая меняется быстрее, чем пишутся тексты по ней. Даже само название — системная инженерия — не является устоявшимся, можно встретить, например, «инженерию систем», «системотехнику» и другие. Книги по теме стремительно устаревают. То, что считалось самым фронтиром десять лет назад, уже раскритиковано и заброшено. Однако есть несколько вещей, которые остаются неизменными.

Во-первых, само понятие системы. Есть общее определение, которое выглядит примерно так: Система — это совокупность элементов произвольной природы, находящихся в отношениях и связях друг с другом, которая образует определённую целостность (link). Под него попадает огромное количество вещей, поэтому для системной инженерии используется более конкретное: Система — это совокупность частей или элементов, которая проявляет свойства или значения, не свойственные частям или элементам по отдельности (link). Отталкиваясь от этого определения, можно погрузиться в обсуждение на много часов и мегабайтов текста, поэтому пока остановлюсь. Просто примеры систем: Бруклинский мост, портал «Госуслуги», Билл Клинтон.

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

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

Для кого всё это нужно? Для всех, кто участвует в создании сложных систем. Я специально выделил слово «участвует», так как использовал его вместо менее точно слова «создают», смысл этого вы поймёте позже, когда будете разбираться в теме. А выделенное слово «всех» подразумевает, что для эффективной работы все должны в необходимом объёме системно-инженерно понимать свою деятельность в проекте.

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

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

Самым важным для меня элементом является начальный этап переформулирования задачи/системы, чтобы её упростить и уточнить, делается это вот такими вопросами:

* Из каких частей состоит система, как они взаимодействуют?
* Какие связи являются вредными, мешающими, какие — нейтральными, и какие — полезными?
* Какие части и связи можно изменять, и какие — нельзя?
* Какие изменения приводят к улучшению системы, и какие — к ухудшению?

Вопросы последовательно задаём и выписываем ответы, при необходимости возвращаемся и повторяем.