Как же хочется себе забрать контракт от государства на 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). Отталкиваясь от этого определения, можно погрузиться в обсуждение на много часов и мегабайтов текста, поэтому пока остановлюсь. Просто примеры систем: Бруклинский мост, портал «Госуслуги», Билл Клинтон.

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

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

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

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

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

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

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

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

— Ну, резюме у вас отличное. Пожалуй, мы вас примем. Напомните, что вы заканчивали?
— Новосибирский резюмейный.

Системная инженерия зародилась не в айти и сейчас эта дисциплина активнее всего используется неайтишными компаниями.

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

Начало шестидесятых было, как это сейчас принято говорить, хайповым временем для компьютеров. Идея всемогущества новых вычислительных машин стала очень популярной, однако вскоре оказалось, что одной только вычислительной мощности не хватит для решения сложной проблемы. Каноничный пример подобное фейла — попытка министра обороны Роберта МакНамары использовать ЭВМ для моделирования ситуации во Вьетнаме в начале шестидесятых. Компьютер «сказал», что победа гарантирована: на стороне США перевес в «десять к одному» в оружии, куча современной военной техники, которой нет у Вьетнама, корабли, разнообразная техника поддержки, вертолёты. Но всё окалось не так радужно, поскольку «компьютерная модель» рассматривала ситуацию как статичную и не была приспособлена для учёта изменений, в том числе потенциальных.

А вот модель лунного проекта изначально предполагала динамичность и постоянную изменчивость всей разрабатываемой системы, учитывала не только материальные ресурсы, но ещё и управленческие (=человеческие) нюансы, на чём модель МакНамары как раз и прогорела.

Тезисы к курсу MIT “Engineering Apollo: The Moon Project as a Complex System ”.

Подробный разбор истории и внутреннего устройства проекта Apollo.

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

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

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

Плохой программист занимается кодом, хороший программист — системой.

Мейлру забанил мой почтовик как спамерский. Написал в техподдержку. Разбанили.

Так дико приятно, когда процессы работают.

Последние 5% работы занимают 50% времени.

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

А потом проходит два месяца и снова надо доделать те же 5%, пара недель. Заказчик злится - он рассчитывал всё давно получить и продавать, разработчики расстроены - они рассчитывали давно всё сдать, премироваться и нырнуть в новое-интересное.

А всё дело в проклятом правиле Парето. Все знают его как 80-20. А на самом деле оно 80-20, 15-30 и 5-50.
80% работы делаются за 20% времени. Еще 15% делаются за 30% времени, а последние 5 - за 50.

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

Ну и просто любимый фрагмент из дневника за 1976 год, когда он приезжал в СССР:

I did my best to behave as one should in bugged rooms, but I found it difficult. I remember that, when I asked the IBM-er in Hursley whether the room in which he received me, was bugged, the IBM-er orally protested "No, of course not." while nodding affirmatively. Similar situation while I paid my compliments to the Dutch embassador in Moscow. I remembered never to comment on our Russian hosts but when, in Moscow my hotel room I started to explain to Tony the type of computer architecture I had been thinking about lately, better trained than I Tony immediately suggested a walk. It did not rain and we walked for nearly two hours. It took Tony a long time to grasp the idea, so it might be a little bit revolutionary. Eventually he got quite excited, but agreed that several critical issues have to be investigated rather carefully, before the idea can be proposed as a realistic one. Then we returned to the hotel and went to bed.

Один из ключевых стандартов системной инженерии называется так, что очень трудно поверить, что он хоть какое-то отношение к айти может иметь:

Industrial automation systems and integration — Integration of life-cycle data for process plants including oil and gas production facilities