Примеры разработки стратегии компании на 2024 год
Дмитрий Торшин провел семинар по стратегированию на реальных кейсах своих учеников. В роликах представлены фрагменты семинара:
Рассмотрено 3 примера стратегий IT-компаний, на основе шаблона, заранее предоставленного автором вебинара.
Первые 2 примера подготовлены новичками, и демонстрируют типовые ошибки:
- слишком обобщённые цели;
- отсутствие привязки целевых показателей к реалиям функционирования компании (в некоторых случаях непонятно чем заявленные достижения помогут компании, в других случаях заявлены слишком заниженные или слишком завышенные критерии);
- недостаточная проработка маркетинговых аспектов (выхода на рынок, расширения доли рынка, завоевания нового сегмента рынка).
Третий пример подготовлен опытным предпринимателем, прошедшим курс обучения и разработавшим стратегию уже не для первого своего бизнеса. Помимо содержания стратегии, третий пример интересен элементами оптимизации шаблона разработки стратегии, ранее предоставленного автором вебинара.
Ссылка на ролики - https://drive.google.com/drive/folders/1tHguJgBXJbdQUNvSR75D1Hmp83e4g572?usp=sharing
#стратегирование #торшин
Дмитрий Торшин провел семинар по стратегированию на реальных кейсах своих учеников. В роликах представлены фрагменты семинара:
Рассмотрено 3 примера стратегий IT-компаний, на основе шаблона, заранее предоставленного автором вебинара.
Первые 2 примера подготовлены новичками, и демонстрируют типовые ошибки:
- слишком обобщённые цели;
- отсутствие привязки целевых показателей к реалиям функционирования компании (в некоторых случаях непонятно чем заявленные достижения помогут компании, в других случаях заявлены слишком заниженные или слишком завышенные критерии);
- недостаточная проработка маркетинговых аспектов (выхода на рынок, расширения доли рынка, завоевания нового сегмента рынка).
Третий пример подготовлен опытным предпринимателем, прошедшим курс обучения и разработавшим стратегию уже не для первого своего бизнеса. Помимо содержания стратегии, третий пример интересен элементами оптимизации шаблона разработки стратегии, ранее предоставленного автором вебинара.
Ссылка на ролики - https://drive.google.com/drive/folders/1tHguJgBXJbdQUNvSR75D1Hmp83e4g572?usp=sharing
#стратегирование #торшин
👍4
Творчество: человек и ИИ
Распространено мнение, что ИИ никогда не сможет превзойти человека в интеллектуальных способностях, поскольку человек способен к творчеству, а ИИ – это только комбинаторика из существующих знаний.
Так ли это? Не знаю. Но есть повод попытаться разобраться что такое творчество.
1. Творчество – это придумывание чего-то качественно нового, доселе неизвестного (не важно всем или только творцу).
2. Творчество может быть мыслительным (моделирование себя или окружающего мира), инженерным (изменение окружающего мира – создание новых физических объектов) и фантазийным (искусство).
3. Творчество часто связано с «озарениями» – ищешь одно, а находишь неожиданное новое другое, которое привносит новые качества в результат. Для этой способности придумали даже специальный термин «серендипность» – способность, делая глубокие выводы из случайных наблюдений, находить то, чего не искал намеренно.
4. Творчество – это не любое изменение, а изменение, имеющее ценность (не важно только для самого творца или для всего человечества). В связи с этим придумали понятие «умной мутации» (smart mutation) – творческая мутация идеи ведет к улучшению эволюционной приспособленности к среде, в которой эта идея будет использоваться.
5. Творческое озарение, догадка возникает из хаоса (шума, случайности) ассоциаций, идей, эмоций.
6. Умные мутации и то, что возникает на их основе, проходят «эволюционный фильтр», селекцию как внутри автора, так и со стороны других людей, окружающей реальности. Не всякая безумная догадка оказывается «умной» и ведет к творческому результату. За счет этого эволюционного механизма отсеивается большое количество бесполезных идей.
Разработчики ИИ сейчас пытаются научить его творчеству. Например, Карелов описывает как это работает в системе FanSearch:
«
1. Сначала предварительно обученная LLM генерирует первоначальные творческие решения в виде компьютерного кода.
2. Потом вступает в дела «автоматический оценщик», задача которого отсеять из множества первоначальных решений любые подозрения на конфабуляции модели (кстати, использование применительно к LLM термина «галлюцинация» - это сильное огрубление смысла, ведущее к его ограниченной трактовке; верный термин – именно конфабуляция), т.е. возникновение ложного опыта из-за появления фрагментов памяти с описанием того, чего, на самом деле, не было в реальных данных обучения).
3. В результате объединения 1 и 2, первоначальные решения эволюционным путем «превращаются» в новые знания, т.е., по сути, происходит «автоматизация открытий», о которой вот уже несколько десятков лет мечтают разработчики ИИ - вычисления превращаются в оригинальные инсайты.
».
Этот подход позволил системе FanSearch от Google DeepMind сделать математическое открытие, которое сейчас широко обсуждается в сети (решение центральной задачи экстремальной комбинаторики – о наборе предельных значений).
Таким образом, ИИ в настоящее время способен генерировать умные мутации и на основе их цепочек даже делать научные открытие. Однако, что касается серендипности – это свойство в современных теориях интеллекта считается недоступным для ИИ. Хотя, LLM вроде как способны уже усматривать признаки провидческих (серендипных) идей в человеческих текстах. И кто знает, что будет уже через несколько лет…
Литература:
1. Об открытии FanSearch - https://deepmind.google/discover/blog/funsearch-making-new-discoveries-in-mathematical-sciences-using-large-language-models/?utm_source=twitter&utm_medium=social
2. Лекция Карелова о Теории интеллекта Роли-Йегера-Кауффмана - https://www.youtube.com/watch?v=hADqkxkQF2o&ab_channel=%D0%9C%D0%B0%D0%BB%D0%BE%D0%B8%D0%B7%D0%B2%D0%B5%D1%81%D1%82%D0%BD%D0%BE%D0%B5%D0%B8%D0%BD%D1%82%D0%B5%D1%80%D0%B5%D1%81%D0%BD%D0%BE%D0%B5
3. Об умных мутациях - https://arxiv.org/abs/2206.08896
#сознание #карелов #ИИ
Распространено мнение, что ИИ никогда не сможет превзойти человека в интеллектуальных способностях, поскольку человек способен к творчеству, а ИИ – это только комбинаторика из существующих знаний.
Так ли это? Не знаю. Но есть повод попытаться разобраться что такое творчество.
1. Творчество – это придумывание чего-то качественно нового, доселе неизвестного (не важно всем или только творцу).
2. Творчество может быть мыслительным (моделирование себя или окружающего мира), инженерным (изменение окружающего мира – создание новых физических объектов) и фантазийным (искусство).
3. Творчество часто связано с «озарениями» – ищешь одно, а находишь неожиданное новое другое, которое привносит новые качества в результат. Для этой способности придумали даже специальный термин «серендипность» – способность, делая глубокие выводы из случайных наблюдений, находить то, чего не искал намеренно.
4. Творчество – это не любое изменение, а изменение, имеющее ценность (не важно только для самого творца или для всего человечества). В связи с этим придумали понятие «умной мутации» (smart mutation) – творческая мутация идеи ведет к улучшению эволюционной приспособленности к среде, в которой эта идея будет использоваться.
5. Творческое озарение, догадка возникает из хаоса (шума, случайности) ассоциаций, идей, эмоций.
6. Умные мутации и то, что возникает на их основе, проходят «эволюционный фильтр», селекцию как внутри автора, так и со стороны других людей, окружающей реальности. Не всякая безумная догадка оказывается «умной» и ведет к творческому результату. За счет этого эволюционного механизма отсеивается большое количество бесполезных идей.
Разработчики ИИ сейчас пытаются научить его творчеству. Например, Карелов описывает как это работает в системе FanSearch:
«
1. Сначала предварительно обученная LLM генерирует первоначальные творческие решения в виде компьютерного кода.
2. Потом вступает в дела «автоматический оценщик», задача которого отсеять из множества первоначальных решений любые подозрения на конфабуляции модели (кстати, использование применительно к LLM термина «галлюцинация» - это сильное огрубление смысла, ведущее к его ограниченной трактовке; верный термин – именно конфабуляция), т.е. возникновение ложного опыта из-за появления фрагментов памяти с описанием того, чего, на самом деле, не было в реальных данных обучения).
3. В результате объединения 1 и 2, первоначальные решения эволюционным путем «превращаются» в новые знания, т.е., по сути, происходит «автоматизация открытий», о которой вот уже несколько десятков лет мечтают разработчики ИИ - вычисления превращаются в оригинальные инсайты.
».
Этот подход позволил системе FanSearch от Google DeepMind сделать математическое открытие, которое сейчас широко обсуждается в сети (решение центральной задачи экстремальной комбинаторики – о наборе предельных значений).
Таким образом, ИИ в настоящее время способен генерировать умные мутации и на основе их цепочек даже делать научные открытие. Однако, что касается серендипности – это свойство в современных теориях интеллекта считается недоступным для ИИ. Хотя, LLM вроде как способны уже усматривать признаки провидческих (серендипных) идей в человеческих текстах. И кто знает, что будет уже через несколько лет…
Литература:
1. Об открытии FanSearch - https://deepmind.google/discover/blog/funsearch-making-new-discoveries-in-mathematical-sciences-using-large-language-models/?utm_source=twitter&utm_medium=social
2. Лекция Карелова о Теории интеллекта Роли-Йегера-Кауффмана - https://www.youtube.com/watch?v=hADqkxkQF2o&ab_channel=%D0%9C%D0%B0%D0%BB%D0%BE%D0%B8%D0%B7%D0%B2%D0%B5%D1%81%D1%82%D0%BD%D0%BE%D0%B5%D0%B8%D0%BD%D1%82%D0%B5%D1%80%D0%B5%D1%81%D0%BD%D0%BE%D0%B5
3. Об умных мутациях - https://arxiv.org/abs/2206.08896
#сознание #карелов #ИИ
🤔1
Об уличную эпистемологию
Приходит ко мне товарищ и говорит: «Свинину есть грех». С товарищем в свое время не одним килограммом свиного шашлыка был заеден не один литр вина. Что сказать товарищу? «Ты, друг, тронулся на старости лет?»
Можно так, а можно по-другому. Например:
1. Хочешь мы обсудим твоё духовное прозрение?
2. Что такое грех в твоей системе мировоззренческих координат?
3. Какова она теперь – твоя новая система координат?
4. Причем здесь свинина?
5. Каким теперь блюдом ты будешь сопровождать свои алко-духовные опыты вместо свинины? Почему?
6. Насколько ты убежден в твоем новом духовном прозрении относительно связи свинины с греховностью?
7. Ты сам до этого дошел или тебе кто-то об этом сказал?
8. Действительно ли твои новые источники знаний (люди или книги) настолько надежны что имеет смысл менять свои убеждения и жизнь в соответствии с ними?
9. И т.д.
Приведенные вопросы – это широко известная в узких кругах «уличная эпистемология» – способ ведения диалога, который заключается в том, чтобы не спорить с услышанным тезисом, а попытаться:
1. Понять его содержимое.
2. Понять насколько человек убежден в тезисе.
3. Понять как человек к этому пришел.
Цель метода – научиться вести вежливые неконфронтационные диалоги на «опасные» мировоззренческие темы: научиться понимать людей и, главное, понимать откуда и почему в головах людей появляются и приживаются непонятные нам идеи.
Зачем уметь вести такие диалоги?
Во-первых, может быть человек со странным тезисом прав, а я нет – нужно его услышать.
Во-вторых, может быть он не прав, но для того чтобы ему помочь (если оно надо), человека для начала нужно понять.
В-третьих, может быть с моей точки зрения человек глубоко неправ, но переубедить его невозможно (или не нужно), тогда хорошо бы просто его понять, чтобы научиться мирно сосуществовать.
Умное слово «эпистемология» обозначает философскую дисциплину о природе, структуре, происхождении и т.д. знания. Честно говоря, уличная эпистемология – это банальное умение выслушать и понять человека, с которым ты, возможно, не согласен. Для этого нужен, как мне кажется, всего лишь базовый уровень общей культуры, доброжелательность и любопытства. Но американцы не были бы американцами, если бы не умели общеизвестные вещи красиво обернуть и дорого продать. Так, Питер Богоссян и Энтони Маньябоско, придумали название «уличная эпистемология» для маскировки своего желания вести умную пропаганду атеизма, но так, чтобы это не выглядело примитивной пропагандой, а работало через открытие неискушенным собеседникам мало кем осознаваемой "тайны": убеждения большинства людей как правило случайны и малообоснованны. Да-да. И если умело людям это показывать, то можно деликатно разубеждать в чем угодно, а потом опять убеждать в чем угодно. А по ходу процесса писать об этом книги и снимать ролики для ютуба.
Когда я впервые услышал термин «уличная эпистемология», то подумал: вот, наверное, хороший способ понять мировоззрение человека и его источники. Но, увы, нет. Мировоззрение (даже если, как у большинства людей, его в системном стройном виде нет) – это сложная и объемная совокупность взглядов, идей, понятий, которую, чтобы понять у одного человека, нужно затратить много времени. Кто проводил глубинные интервью даже по узким вопросам может представить – насколько это долго, сложно и дорого. Поэтому уличная эпистемология – это лишь способ относительно быстро понять крошечный фрагмент мировоззрения. Что само по себе неплохо и замечательно – можно не спорить и ругаться на чувствительные темы, а узнавать, понимать и учиться терпеть друг друга.
Есть, конечно, кроме уличной и «лабораторная» эпистемология. Например, психиатры глубоко изучают своих пациентов: их взгляды, сны, отношения и т.д. Или следователи-психологи по вопросам идейного экстремизма… Но об этом в другой раз.
Дисклеймер: любые совпадения по поводу свинины, алкоголя, греха и товарища считать случайными и выдуманными!
#уличнаяэпистемология #мышление #богоссян #маньябоско
Приходит ко мне товарищ и говорит: «Свинину есть грех». С товарищем в свое время не одним килограммом свиного шашлыка был заеден не один литр вина. Что сказать товарищу? «Ты, друг, тронулся на старости лет?»
Можно так, а можно по-другому. Например:
1. Хочешь мы обсудим твоё духовное прозрение?
2. Что такое грех в твоей системе мировоззренческих координат?
3. Какова она теперь – твоя новая система координат?
4. Причем здесь свинина?
5. Каким теперь блюдом ты будешь сопровождать свои алко-духовные опыты вместо свинины? Почему?
6. Насколько ты убежден в твоем новом духовном прозрении относительно связи свинины с греховностью?
7. Ты сам до этого дошел или тебе кто-то об этом сказал?
8. Действительно ли твои новые источники знаний (люди или книги) настолько надежны что имеет смысл менять свои убеждения и жизнь в соответствии с ними?
9. И т.д.
Приведенные вопросы – это широко известная в узких кругах «уличная эпистемология» – способ ведения диалога, который заключается в том, чтобы не спорить с услышанным тезисом, а попытаться:
1. Понять его содержимое.
2. Понять насколько человек убежден в тезисе.
3. Понять как человек к этому пришел.
Цель метода – научиться вести вежливые неконфронтационные диалоги на «опасные» мировоззренческие темы: научиться понимать людей и, главное, понимать откуда и почему в головах людей появляются и приживаются непонятные нам идеи.
Зачем уметь вести такие диалоги?
Во-первых, может быть человек со странным тезисом прав, а я нет – нужно его услышать.
Во-вторых, может быть он не прав, но для того чтобы ему помочь (если оно надо), человека для начала нужно понять.
В-третьих, может быть с моей точки зрения человек глубоко неправ, но переубедить его невозможно (или не нужно), тогда хорошо бы просто его понять, чтобы научиться мирно сосуществовать.
Умное слово «эпистемология» обозначает философскую дисциплину о природе, структуре, происхождении и т.д. знания. Честно говоря, уличная эпистемология – это банальное умение выслушать и понять человека, с которым ты, возможно, не согласен. Для этого нужен, как мне кажется, всего лишь базовый уровень общей культуры, доброжелательность и любопытства. Но американцы не были бы американцами, если бы не умели общеизвестные вещи красиво обернуть и дорого продать. Так, Питер Богоссян и Энтони Маньябоско, придумали название «уличная эпистемология» для маскировки своего желания вести умную пропаганду атеизма, но так, чтобы это не выглядело примитивной пропагандой, а работало через открытие неискушенным собеседникам мало кем осознаваемой "тайны": убеждения большинства людей как правило случайны и малообоснованны. Да-да. И если умело людям это показывать, то можно деликатно разубеждать в чем угодно, а потом опять убеждать в чем угодно. А по ходу процесса писать об этом книги и снимать ролики для ютуба.
Когда я впервые услышал термин «уличная эпистемология», то подумал: вот, наверное, хороший способ понять мировоззрение человека и его источники. Но, увы, нет. Мировоззрение (даже если, как у большинства людей, его в системном стройном виде нет) – это сложная и объемная совокупность взглядов, идей, понятий, которую, чтобы понять у одного человека, нужно затратить много времени. Кто проводил глубинные интервью даже по узким вопросам может представить – насколько это долго, сложно и дорого. Поэтому уличная эпистемология – это лишь способ относительно быстро понять крошечный фрагмент мировоззрения. Что само по себе неплохо и замечательно – можно не спорить и ругаться на чувствительные темы, а узнавать, понимать и учиться терпеть друг друга.
Есть, конечно, кроме уличной и «лабораторная» эпистемология. Например, психиатры глубоко изучают своих пациентов: их взгляды, сны, отношения и т.д. Или следователи-психологи по вопросам идейного экстремизма… Но об этом в другой раз.
Дисклеймер: любые совпадения по поводу свинины, алкоголя, греха и товарища считать случайными и выдуманными!
#уличнаяэпистемология #мышление #богоссян #маньябоско
👍9🔥3
Несколько книг о государственном стратегировании
Для порядка собрал в кучку ссылки на несколько давно пролистанных книг по региональным, государственным и цивилизационным стратегиям:
1. Форсайт-сессия от 10-13 сентября 2009 г. под началом С.Переслегина на тему развития новосибирского региона. Мне были наиболее интересны первые 20 страниц на тему культуры форсайтов в разных странах (США, Европа, Япония, Россия, Китай, Индия и другие страны). Также интересны раскиданные по книги общетеоретические вещи по стратегированию, типа «сценирование», «дикие карты» и т.д. В целом книга интересна как пример игрового стратегирования по региону в контексте стратегий более высокого порядка.
2. Summa strategia – С.Переслегин и др. (2013) Как справедливо замечает автор в предыдущей книге – с онтологией часто в стратегировании плохо (например, в США и Европе). Видимо, в связи с этим Переслегин сотоварищи решили собрать воедино различные аспекты государственного военного и мирного стратегирования и сделать какую-никакую целостную онтологию для данной предметной области. Этой попыткой обобщить всё книга и интересна, и тем, что ее можно использовать как справочник для задачи освоения науки управления вселенной без привлечения внимания санитаров.
3. Стратегия: логика войны и мира (2001) – Эдвард Люттвак. Автор интересен тем, что кроме теории и исторических штудий имел отношение к практической политической деятельности – был советником в Госдепартаменте США, в Совете по национальной безопасности, у президента США Рональда Рейгана. Книга, якобы, изучается в военных училищах по всему миру.
4. Большая стратегия Византийской Империи – Эдвард Люттвак. Очень интересное историческое политологическое исследование в попытке ответить на вопрос почему восточная часть римской империи, не обладая географическими или военными преимуществами перед западной, просуществовала тысячу лет – в два раза дольше чем западная.
5. Большая стратегия Российской Империи (1650-1831) – Джон Ледонн. Гарвардский историк явно под влиянием Люттвака анализирует российскую стратегия в 17-19 вв. Официального русского перевода нет, пару лет назад я сделал неофициальный, но он так и остался несвёрстанным.
6. Российская Империя и мир (1700-1917): геополитика экспансии и сдерживания – Джон Ледонн. Более ранняя книга примерно на ту же тему, что и предыдущая. С переводом такая же история.
#стратегирование #политология #переслегин #люттвак #ледонн
Для порядка собрал в кучку ссылки на несколько давно пролистанных книг по региональным, государственным и цивилизационным стратегиям:
1. Форсайт-сессия от 10-13 сентября 2009 г. под началом С.Переслегина на тему развития новосибирского региона. Мне были наиболее интересны первые 20 страниц на тему культуры форсайтов в разных странах (США, Европа, Япония, Россия, Китай, Индия и другие страны). Также интересны раскиданные по книги общетеоретические вещи по стратегированию, типа «сценирование», «дикие карты» и т.д. В целом книга интересна как пример игрового стратегирования по региону в контексте стратегий более высокого порядка.
2. Summa strategia – С.Переслегин и др. (2013) Как справедливо замечает автор в предыдущей книге – с онтологией часто в стратегировании плохо (например, в США и Европе). Видимо, в связи с этим Переслегин сотоварищи решили собрать воедино различные аспекты государственного военного и мирного стратегирования и сделать какую-никакую целостную онтологию для данной предметной области. Этой попыткой обобщить всё книга и интересна, и тем, что ее можно использовать как справочник для задачи освоения науки управления вселенной без привлечения внимания санитаров.
3. Стратегия: логика войны и мира (2001) – Эдвард Люттвак. Автор интересен тем, что кроме теории и исторических штудий имел отношение к практической политической деятельности – был советником в Госдепартаменте США, в Совете по национальной безопасности, у президента США Рональда Рейгана. Книга, якобы, изучается в военных училищах по всему миру.
4. Большая стратегия Византийской Империи – Эдвард Люттвак. Очень интересное историческое политологическое исследование в попытке ответить на вопрос почему восточная часть римской империи, не обладая географическими или военными преимуществами перед западной, просуществовала тысячу лет – в два раза дольше чем западная.
5. Большая стратегия Российской Империи (1650-1831) – Джон Ледонн. Гарвардский историк явно под влиянием Люттвака анализирует российскую стратегия в 17-19 вв. Официального русского перевода нет, пару лет назад я сделал неофициальный, но он так и остался несвёрстанным.
6. Российская Империя и мир (1700-1917): геополитика экспансии и сдерживания – Джон Ледонн. Более ранняя книга примерно на ту же тему, что и предыдущая. С переводом такая же история.
#стратегирование #политология #переслегин #люттвак #ледонн
Google Docs
Переслегин Сценирование ФОРСАЙТ-ИГРА 2009.doc
ФОРСАЙТ-ИГРА к форсайт-семинару Новосибирск 10-13 сентября 2009 г. СТРАТЕГИЯ РАЗВИТИЯ РЕГИОНА ИННОВАЦИЙ: ОТ ЧЕЛОВЕЧЕСКИХ РЕСУРСОВ К ЧЕЛОВЕЧЕСКОМУ КАПИТАЛУ Составители: © Группа «Квантовый Мёд» …
🔥2👍1
Какие бывают модели данных
Всех (многих) системных аналитиков когда-то учили, что модели данных бывают:
1. Концептуальные.
2. Логические.
3. Физические.
Но при внимательном рассмотрении (Matthew West - Developing high quality data models, глава 3) можно увидеть, что модели данных бывают:
1. Физические.
2. Логические.
3. Концептуальные.
4. Канонические.
5. Модели данных приложения.
6. Модели данных бизнес-требований.
7. Интеграционные.
8. Модели данных предприятия.
9. Бизнес-информационные.
10. Использования данных.
На рисунке ниже показано как они между собой соотносятся с точки зрения Уэста.
Много интересного об этих моделях, как из разрабатывать и как их использовать Уэст пишет в упомянутой книге.
И вообще есть у меня гипотеза: если заставить проектировщиков освоить две книги: Криса Партриджа «BORO…» и Мэтью Уэста «Разработка высококачественных моделей данных», - то проектировщики стали бы умнее не только в профессиональной деятельности.
#уэст #партридж #boro #моделированиеданных
Всех (многих) системных аналитиков когда-то учили, что модели данных бывают:
1. Концептуальные.
2. Логические.
3. Физические.
Но при внимательном рассмотрении (Matthew West - Developing high quality data models, глава 3) можно увидеть, что модели данных бывают:
1. Физические.
2. Логические.
3. Концептуальные.
4. Канонические.
5. Модели данных приложения.
6. Модели данных бизнес-требований.
7. Интеграционные.
8. Модели данных предприятия.
9. Бизнес-информационные.
10. Использования данных.
На рисунке ниже показано как они между собой соотносятся с точки зрения Уэста.
Много интересного об этих моделях, как из разрабатывать и как их использовать Уэст пишет в упомянутой книге.
И вообще есть у меня гипотеза: если заставить проектировщиков освоить две книги: Криса Партриджа «BORO…» и Мэтью Уэста «Разработка высококачественных моделей данных», - то проектировщики стали бы умнее не только в профессиональной деятельности.
#уэст #партридж #boro #моделированиеданных
🔥3👍2
Итерации, гипотезы и адаптивность при разработке государственных ИС
Если чиновников, ответственных за цифровизацию, заставить освоить, сдать экзамен и реализовать хотя бы один проект в соответствии с методическими рекомендациями по ссылке в конце поста – страна начнет стремительно прогрессировать в области цифровизации.
Я неоднократно писал о причинах неизбежного отставания государственных цифровых проектов от частных:
1. Системная инженерия последнее десятилетие эволюционирует в сторону всё более высокой адаптивности и стремительности внедрения изменений: «требования» всё больше заменяются «гипотезами», описания проектируемых функций меняют модус от «система должна категорически и бесповоротно во веки вечные» в сторону «предполагается, что данная функция системы будет наиболее оптимальна для потребностей пользователей, а если нет, то по ходу дела мы ее улучшим».
2. Государственный процесс цифровизации – косный и неповоротливый в силу длительности согласований, выделения бюджета, карательной политики относительно неточности реализации проектируемых систем. А также потому что чиновники делают системы не на свои деньги, не для себя и ничем, как правило, не рискуют.
Однако, как оказывается, государственные организации не оставляют попыток угнаться за техническим прогрессом в цифровизации. Мне прислали замечательный документ Минцифры России под названием «Методические рекомендации по организации производственного процесса разработки государственных информационных систем с учетом применения итерационного подхода к разработке». И там, фантастика (!), они пишут (стр.19-20):
«Независимо от того, насколько хорошо Система изначально определена и спроектирована, реальные потребности клиентов и выбор технологический решений являются неопределенными и, соответственно, развивающимися. Поэтому понимание того, как Система должна быть реализована, должно адаптироваться с течением времени. Исходя из этого при разработке Технического проекта рекомендуется придерживаться следующих правил:
1. Проектирование осуществляется на основе требований к Системе, исходящих от заинтересованных сторон, в том числе – клиентов, эксплуатирующего систему персонала, должностных лиц Ведомства.
2. В ходе проектирования рекомендуется использование практик, сохраняющих как можно дольше рассмотрение возможных вариантов реализации Системы (гипотез) в процессе её создания и принятие обоснованных (например, с точки зрения лучших экономических результатов) технических решений только после проверки гипотез.
3. И т.д.».
Рекомендуется системы внедрять итерациями, причем на каждой итерации проводить работы по проектированию, реализации, оценке и корректировке требований (гипотез) для следующей итерации. В рамках одной итерации разработка может вестись ежеквартальными инкрементами. Бюджет может быть независимый для каждой отдельной итерации. И много еще чего из современного ИТ-менеджмента, что является тайным знанием для многих госслужащих, предлагается использовать для успешного создания ИС ГО.
Сложно сходу глубоко оценить ценность и адекватность конкретных рекомендаций – нужно глубоко анализировать документ, а лучше испытать предлагаемые методики в реальном проекте. Но в любом случае есть что нам перенять для усовершенствования нашего законодательства в сфере создания ИС ГО.
Ссылка на документ: МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ
ПО ОРГАНИЗАЦИИ ПРОИЗВОДСТВЕННОГО
ПРОЦЕССА РАЗРАБОТКИ ГОСУДАРСТВЕННЫХ
ИНФОРМАЦИОННЫХ СИСТЕМ С УЧЕТОМ
ПРИМЕНЕНИЯ ИТЕРАЦИОННОГО ПОДХОДА К
РАЗРАБОТКЕ
#егов #менеджмент #мцриап #минцифры
Если чиновников, ответственных за цифровизацию, заставить освоить, сдать экзамен и реализовать хотя бы один проект в соответствии с методическими рекомендациями по ссылке в конце поста – страна начнет стремительно прогрессировать в области цифровизации.
Я неоднократно писал о причинах неизбежного отставания государственных цифровых проектов от частных:
1. Системная инженерия последнее десятилетие эволюционирует в сторону всё более высокой адаптивности и стремительности внедрения изменений: «требования» всё больше заменяются «гипотезами», описания проектируемых функций меняют модус от «система должна категорически и бесповоротно во веки вечные» в сторону «предполагается, что данная функция системы будет наиболее оптимальна для потребностей пользователей, а если нет, то по ходу дела мы ее улучшим».
2. Государственный процесс цифровизации – косный и неповоротливый в силу длительности согласований, выделения бюджета, карательной политики относительно неточности реализации проектируемых систем. А также потому что чиновники делают системы не на свои деньги, не для себя и ничем, как правило, не рискуют.
Однако, как оказывается, государственные организации не оставляют попыток угнаться за техническим прогрессом в цифровизации. Мне прислали замечательный документ Минцифры России под названием «Методические рекомендации по организации производственного процесса разработки государственных информационных систем с учетом применения итерационного подхода к разработке». И там, фантастика (!), они пишут (стр.19-20):
«Независимо от того, насколько хорошо Система изначально определена и спроектирована, реальные потребности клиентов и выбор технологический решений являются неопределенными и, соответственно, развивающимися. Поэтому понимание того, как Система должна быть реализована, должно адаптироваться с течением времени. Исходя из этого при разработке Технического проекта рекомендуется придерживаться следующих правил:
1. Проектирование осуществляется на основе требований к Системе, исходящих от заинтересованных сторон, в том числе – клиентов, эксплуатирующего систему персонала, должностных лиц Ведомства.
2. В ходе проектирования рекомендуется использование практик, сохраняющих как можно дольше рассмотрение возможных вариантов реализации Системы (гипотез) в процессе её создания и принятие обоснованных (например, с точки зрения лучших экономических результатов) технических решений только после проверки гипотез.
3. И т.д.».
Рекомендуется системы внедрять итерациями, причем на каждой итерации проводить работы по проектированию, реализации, оценке и корректировке требований (гипотез) для следующей итерации. В рамках одной итерации разработка может вестись ежеквартальными инкрементами. Бюджет может быть независимый для каждой отдельной итерации. И много еще чего из современного ИТ-менеджмента, что является тайным знанием для многих госслужащих, предлагается использовать для успешного создания ИС ГО.
Сложно сходу глубоко оценить ценность и адекватность конкретных рекомендаций – нужно глубоко анализировать документ, а лучше испытать предлагаемые методики в реальном проекте. Но в любом случае есть что нам перенять для усовершенствования нашего законодательства в сфере создания ИС ГО.
Ссылка на документ: МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ
ПО ОРГАНИЗАЦИИ ПРОИЗВОДСТВЕННОГО
ПРОЦЕССА РАЗРАБОТКИ ГОСУДАРСТВЕННЫХ
ИНФОРМАЦИОННЫХ СИСТЕМ С УЧЕТОМ
ПРИМЕНЕНИЯ ИТЕРАЦИОННОГО ПОДХОДА К
РАЗРАБОТКЕ
#егов #менеджмент #мцриап #минцифры
🔥5👍3
Вот мы тут капаем желчью, глядя на системы егов, а между прочим на днях правительство опубликовало концепцию развития ИИ до 2029 года. Которая в числе прочих задач поедусматривает использование ИИ в госуслугах. И уже в текущем году на реализацию заложили 2 млрд. тг.
Идея стартапа: напишите кто-нибудь на нейросетке и натренируйте бота по госуслугам - можно назвать его "Нить Ариадны". Слоган: "Получи услугу - убей Минотавра".
УПД. Можно еще в форме игры сделать: битва с монстрами-госслужащими в лабиринте, квест по поиску выхода и т.д. На последнем этапе игры нужно будет последовательно выиграть поединок с чудовищами: мцриаптерами, нитозаврами и колдунами гтсекты...
УПД2. Кстати, хорошая идея для пополнения бюджета: покупать скины и вооружение для ускоренного прохождения уровней. можно еще интеллектуальную песочницу сделать: смоделируй деятельность ГО и получи годовой абонемент на егов без глюков...
УПД3. Чувствую наведут на меня порчу сотрудники ГО без чувства юмора...
Ссылка - https://www.gov.kz/memleket/entities/mdai/documents/details/606493?lang=ru
#егов #ИИ
Идея стартапа: напишите кто-нибудь на нейросетке и натренируйте бота по госуслугам - можно назвать его "Нить Ариадны". Слоган: "Получи услугу - убей Минотавра".
УПД. Можно еще в форме игры сделать: битва с монстрами-госслужащими в лабиринте, квест по поиску выхода и т.д. На последнем этапе игры нужно будет последовательно выиграть поединок с чудовищами: мцриаптерами, нитозаврами и колдунами гтсекты...
УПД2. Кстати, хорошая идея для пополнения бюджета: покупать скины и вооружение для ускоренного прохождения уровней. можно еще интеллектуальную песочницу сделать: смоделируй деятельность ГО и получи годовой абонемент на егов без глюков...
УПД3. Чувствую наведут на меня порчу сотрудники ГО без чувства юмора...
Ссылка - https://www.gov.kz/memleket/entities/mdai/documents/details/606493?lang=ru
#егов #ИИ
😁6
Еще о моделировании данных и мышлении
Читаю Matthew West - Developing High Quality Data Models.
Коротко об авторе:
По образованию химик, работал в Shell, с 1987 года стал айтишником со специализацией в управлении данными. Внес ключевой вклад в разработку стандартов ISO 15926 и ISO 1887. Эти стандарты (кто не знает) разрабатывались для задач обмена информацией между промышленными предприятиями – там, где предприятий сотни и тысячи, номенклатура объектов – много-много миллионов и надо как-то интегрироваться, обмениваться данными в длинных производственных цепочках.
Чем хороша книга:
1. По ходу раскрывает не только приемы моделирования данных, но и поневоле показывает принципы человеческого мышления относительно выделения понятий, отношений между понятиями.
2. Дает много практических советов относительно разработки моделей данных. В частности, много рассказывает о типовых проблемах моделирования исторических данных, четырехмерных объектов, событий и состояний и т.д. и т.п.
3. В приложении дает обширный набор шаблонов данных из ISO 15926.
4. Возникает соблазн использовать книгу как хрестоматию для обучения а) мышления, б) моделирования данных (наряду с книгой Партриджа).
Недостатки:
1. Для совсем незнакомых с принципами реляционных БД многое будет непонятно.
2. Для тех, у кого сложности с понятийным мышлением, желательно для начала прочитать учебник логики.
Ссылку на английский текст книги я давал пару постов выше (можно найти поиском либо по тэгам). На русский перевожу по ходу чтения – так проще читать не торопясь – готово уже 9 глав (всего теоретических глав – 16, полкниги занимают шаблоны данных).
Ссылка на русский перевод – https://docs.google.com/document/d/1kvqJ4aI6Hr2gcNbNB96QFNCJWuDIW-Ri5JTDHn6X_ek/edit?usp=sharing
#уэст #моделированиеданных #перевод
Читаю Matthew West - Developing High Quality Data Models.
Коротко об авторе:
По образованию химик, работал в Shell, с 1987 года стал айтишником со специализацией в управлении данными. Внес ключевой вклад в разработку стандартов ISO 15926 и ISO 1887. Эти стандарты (кто не знает) разрабатывались для задач обмена информацией между промышленными предприятиями – там, где предприятий сотни и тысячи, номенклатура объектов – много-много миллионов и надо как-то интегрироваться, обмениваться данными в длинных производственных цепочках.
Чем хороша книга:
1. По ходу раскрывает не только приемы моделирования данных, но и поневоле показывает принципы человеческого мышления относительно выделения понятий, отношений между понятиями.
2. Дает много практических советов относительно разработки моделей данных. В частности, много рассказывает о типовых проблемах моделирования исторических данных, четырехмерных объектов, событий и состояний и т.д. и т.п.
3. В приложении дает обширный набор шаблонов данных из ISO 15926.
4. Возникает соблазн использовать книгу как хрестоматию для обучения а) мышления, б) моделирования данных (наряду с книгой Партриджа).
Недостатки:
1. Для совсем незнакомых с принципами реляционных БД многое будет непонятно.
2. Для тех, у кого сложности с понятийным мышлением, желательно для начала прочитать учебник логики.
Ссылку на английский текст книги я давал пару постов выше (можно найти поиском либо по тэгам). На русский перевожу по ходу чтения – так проще читать не торопясь – готово уже 9 глав (всего теоретических глав – 16, полкниги занимают шаблоны данных).
Ссылка на русский перевод – https://docs.google.com/document/d/1kvqJ4aI6Hr2gcNbNB96QFNCJWuDIW-Ri5JTDHn6X_ek/edit?usp=sharing
#уэст #моделированиеданных #перевод
👍8🔥1
Об архитектуре требований, viewpoint’ах, view (1/2)
Сегодня Денис Гобов рассказывал для Казахстанского чаптера IIBA про Анализ требований и определение дизайна, и вкратце среди прочего про архитектуру требований, viewpoint’ы и view.
Судя по вопросам про архитектуру тема для слушателей непростая. Есть повод повторить и сравнить подходы к определению архитектуры из BABOK Guide и ISO 42010 (Systems and software engineering. Architecture description).
BABOK Guide:
• Архитектура требований — это структура всех требований изменения.
• Точка зрения (viewpoint) — это набор соглашений, определяющих как представляются требования, как эти представления организуются, и как они будут связаны. Точки зрения дают шаблоны для учета интересов конкретных групп заинтересованных сторон.
• Представление (view) - фактические требования и дизайны для конкретного решения с выбранной точки зрения. Набор представлений образует архитектуру требований конкретного решения.
Обратите внимание, что определение архитектуры требований в BABOK Guide противоречиво: с одной стороны, это «структура требований», в другом месте это «набор представлений», т.е. архитектура включает в себя содержание требований. Возникает неизбежный вопрос, всё-таки «архитектура требований» - это «набор представлений (описаний, view)» или «структура всех требований»?
ISO 42010:
• Архитектура – основные понятия или свойства системы в окружающей среде, воплощенной в ее элементах, отношениях и конкретных принципах ее проекта и развития.
• Описание архитектуры (architecture description) – рабочий продукт, используемый для выражения архитектуры.
• Точка зрения (viewpoint) – рабочий продукт, устанавливающий условности конструирования, интерпретации и использования архитектурного представления для структуризации определенных системных интересов.
• Представление (view) – рабочий продукт, выражающий архитектуру некоторой системы с точки зрения определенных системных интересов.
Для сравнения терминологии BABOK Guide и ISO 42010 необходимо учитывать, что ISO 42010 рассматривает архитектуру «системы», а BABOK Guide рассматривает архитектуру «требований», которые по сути являются описанием «системы», т.е. «архитектуру описания системы». Если толкователи BABOK Guide будут держать в голове подход, выраженный ISO 42010, то они будут считать, что архитектура требований - это основные свойства набора требований, выраженные во представлениях (view), но а) это не простая сумма всех view, б) это не просто «структура» требований. Dixi.
Однако, на самом деле, начиная пост, я просто хотел привлечь внимание к двум важным понятиям:
• Viewpoint.
• View.
Для системной инженерии и бизнес-анализа это очень важные понятия. Viewpoint переводят на русский по-разному: аспект, точка зрения, способ описания. View – представление, описание.
#системнаяинженерия #бизнесанализ
Сегодня Денис Гобов рассказывал для Казахстанского чаптера IIBA про Анализ требований и определение дизайна, и вкратце среди прочего про архитектуру требований, viewpoint’ы и view.
Судя по вопросам про архитектуру тема для слушателей непростая. Есть повод повторить и сравнить подходы к определению архитектуры из BABOK Guide и ISO 42010 (Systems and software engineering. Architecture description).
BABOK Guide:
• Архитектура требований — это структура всех требований изменения.
• Точка зрения (viewpoint) — это набор соглашений, определяющих как представляются требования, как эти представления организуются, и как они будут связаны. Точки зрения дают шаблоны для учета интересов конкретных групп заинтересованных сторон.
• Представление (view) - фактические требования и дизайны для конкретного решения с выбранной точки зрения. Набор представлений образует архитектуру требований конкретного решения.
Обратите внимание, что определение архитектуры требований в BABOK Guide противоречиво: с одной стороны, это «структура требований», в другом месте это «набор представлений», т.е. архитектура включает в себя содержание требований. Возникает неизбежный вопрос, всё-таки «архитектура требований» - это «набор представлений (описаний, view)» или «структура всех требований»?
ISO 42010:
• Архитектура – основные понятия или свойства системы в окружающей среде, воплощенной в ее элементах, отношениях и конкретных принципах ее проекта и развития.
• Описание архитектуры (architecture description) – рабочий продукт, используемый для выражения архитектуры.
• Точка зрения (viewpoint) – рабочий продукт, устанавливающий условности конструирования, интерпретации и использования архитектурного представления для структуризации определенных системных интересов.
• Представление (view) – рабочий продукт, выражающий архитектуру некоторой системы с точки зрения определенных системных интересов.
Для сравнения терминологии BABOK Guide и ISO 42010 необходимо учитывать, что ISO 42010 рассматривает архитектуру «системы», а BABOK Guide рассматривает архитектуру «требований», которые по сути являются описанием «системы», т.е. «архитектуру описания системы». Если толкователи BABOK Guide будут держать в голове подход, выраженный ISO 42010, то они будут считать, что архитектура требований - это основные свойства набора требований, выраженные во представлениях (view), но а) это не простая сумма всех view, б) это не просто «структура» требований. Dixi.
Однако, на самом деле, начиная пост, я просто хотел привлечь внимание к двум важным понятиям:
• Viewpoint.
• View.
Для системной инженерии и бизнес-анализа это очень важные понятия. Viewpoint переводят на русский по-разному: аспект, точка зрения, способ описания. View – представление, описание.
#системнаяинженерия #бизнесанализ
❤3🔥1
Об архитектуре требований, viewpoint’ах, view (2/2)
Viewpoint – это о том, что у разных сторон есть различные интересы (concern) относительно системы, и им не нужны все возможные описания системы. Собственника бизнеса интересуют одни аспекты, и он хочет видеть описания своего бизнеса и своей инфраструктуры со стороны своих интересов – под его интересы формируется один или несколько viewpoint, а под каждый viewpoint формируются свои view. В физическом мире мы видим как аналитики, архитекторы и разработчики для владельца делают специальные документы: концепцию, business requirement specification и т.д.
У финансового директора, соответственно свои интересы, свои viewpoint и ему нужны свои view. У технического директора – третье. У архитектора – четвертое. У руководителя службы безопасности – пятое. И так далее.
Концепция viewpoint-view позволяет очень детально и очень гибко описывать даже очень сложные системы, при этом сохранять различные уровни абстрактности для описания архитектуры. Инструментально это реализовано, например, в стандарте описания архитектуры archimate и редакторах поддерживающих стандарт: вы можете для каждой диаграммы устанавливать небходимые viewpoint’ы.
Если усвоить в работе с системами, архитектурой, требованиями этот подход деления на viewpoint’ы-view, то работать становится проще: при взаимодействии с различными стейкхолдерами вы сразу анализируете их интересы (concerns) относительно системы, выясняете их viewpoint’ы и планируете какие view вы для них должно готовить.
Диаграмма связи этих архитектурных понятий на картинке ниже.
Ссылки:
1. Стандарт ISO 42010 – https://docs.cntd.ru/document/1200139542
2. Стандарт Archimate – https://pubs.opengroup.org/architecture/archimate3-doc/ch-Stakeholders-Architecture-Views-and-Viewpoints.html
3. Вебинар по анализу требований и определению дизайна –
https://youtu.be/3HMgHd_N_7o?si=bSY-n65YOBXJUwnz
#системнаяинженерия #бизнесанализ
Viewpoint – это о том, что у разных сторон есть различные интересы (concern) относительно системы, и им не нужны все возможные описания системы. Собственника бизнеса интересуют одни аспекты, и он хочет видеть описания своего бизнеса и своей инфраструктуры со стороны своих интересов – под его интересы формируется один или несколько viewpoint, а под каждый viewpoint формируются свои view. В физическом мире мы видим как аналитики, архитекторы и разработчики для владельца делают специальные документы: концепцию, business requirement specification и т.д.
У финансового директора, соответственно свои интересы, свои viewpoint и ему нужны свои view. У технического директора – третье. У архитектора – четвертое. У руководителя службы безопасности – пятое. И так далее.
Концепция viewpoint-view позволяет очень детально и очень гибко описывать даже очень сложные системы, при этом сохранять различные уровни абстрактности для описания архитектуры. Инструментально это реализовано, например, в стандарте описания архитектуры archimate и редакторах поддерживающих стандарт: вы можете для каждой диаграммы устанавливать небходимые viewpoint’ы.
Если усвоить в работе с системами, архитектурой, требованиями этот подход деления на viewpoint’ы-view, то работать становится проще: при взаимодействии с различными стейкхолдерами вы сразу анализируете их интересы (concerns) относительно системы, выясняете их viewpoint’ы и планируете какие view вы для них должно готовить.
Диаграмма связи этих архитектурных понятий на картинке ниже.
Ссылки:
1. Стандарт ISO 42010 – https://docs.cntd.ru/document/1200139542
2. Стандарт Archimate – https://pubs.opengroup.org/architecture/archimate3-doc/ch-Stakeholders-Architecture-Views-and-Viewpoints.html
3. Вебинар по анализу требований и определению дизайна –
https://youtu.be/3HMgHd_N_7o?si=bSY-n65YOBXJUwnz
#системнаяинженерия #бизнесанализ
🔥5
Принципы технического экспресс-перевода
Есть важные книги, для которых нет русского перевода, и которые нужно читать медленно, перечитывая несколько раз. Читать не за 1-2 дня, но, минимум, 1-2 недели. Перечитывая не потому что слабо владеешь языком оригинала, а потому что темы сложные и за одно прочтение не разберешься. Очевидно, что если делаешь заметки по прочитанному, то понимаешь и запоминаешь лучше. Но можно не просто делать заметки, но сразу делать и перевод на русский – при этом а) ты и внимательно прочитываешь каждое слово, б) пишешь, формулируешь мысли автора на родном языке, в) на выходе после чтения остается русский текст, которым можно поделиться с теми, кто не может читать свободно по-английски.
Вчера закончил перевод для такой книги – Matthew West «Developing High Quality Data Models». Понял для себя несколько особенностей такого перевода в процессе чтения:
1. Невозможно книгу из 400 страниц перевести качественно за неделю. Для качественного перевода нужны не 1-2 недели, но 1-2 месяца полной занятости минимум.
2. Однако, можно за неделю перевести книгу так, чтобы она была доступной и understandable для людей, слабо владеющих английским.
3. Системы машинного перевода за последние несколько лет очень сильно эволюционировали – можно смело ими пользоваться с тем, чтобы не переписывать за них каждое предложение. Однако каждое предложение за ними нужно проверять.
4. Много времени занимает перевод диаграмм и рисунков – поэтому я их не перевожу.
5. Если машинный перевод отдельного предложения грамматически правильный и понятный, хотя стилистически не очень (типа, русские обычно так не говорят), то я оставляю машинный вариант.
6. Если машинный перевод предложения звучит по-русски непонятно, то начинаем разбираться почему: непонятно по причине плохого машинного перевода или по причине сложности темы или по причине туманности авторской мысли? При любом варианте приходится переводить предложение «вручную»: если причиной непонятности была слабость машинного перевода то предложение становится понятным, если сложность темы или авторский стиль – тут уж извините…
7. Копипаста через систему машинного перевода, форматирование текста и вставка иллюстраций занимает по времени 1-2 дня работы. Внимательное чтение и редактирование текста – 5-6 дней работы.
Мэтью Уэст хорош, большой молодец, я много открыл для себя в моделировании данных – но об этом в другой раз…
#перевод #мышлениеписьмом #уэст
Есть важные книги, для которых нет русского перевода, и которые нужно читать медленно, перечитывая несколько раз. Читать не за 1-2 дня, но, минимум, 1-2 недели. Перечитывая не потому что слабо владеешь языком оригинала, а потому что темы сложные и за одно прочтение не разберешься. Очевидно, что если делаешь заметки по прочитанному, то понимаешь и запоминаешь лучше. Но можно не просто делать заметки, но сразу делать и перевод на русский – при этом а) ты и внимательно прочитываешь каждое слово, б) пишешь, формулируешь мысли автора на родном языке, в) на выходе после чтения остается русский текст, которым можно поделиться с теми, кто не может читать свободно по-английски.
Вчера закончил перевод для такой книги – Matthew West «Developing High Quality Data Models». Понял для себя несколько особенностей такого перевода в процессе чтения:
1. Невозможно книгу из 400 страниц перевести качественно за неделю. Для качественного перевода нужны не 1-2 недели, но 1-2 месяца полной занятости минимум.
2. Однако, можно за неделю перевести книгу так, чтобы она была доступной и understandable для людей, слабо владеющих английским.
3. Системы машинного перевода за последние несколько лет очень сильно эволюционировали – можно смело ими пользоваться с тем, чтобы не переписывать за них каждое предложение. Однако каждое предложение за ними нужно проверять.
4. Много времени занимает перевод диаграмм и рисунков – поэтому я их не перевожу.
5. Если машинный перевод отдельного предложения грамматически правильный и понятный, хотя стилистически не очень (типа, русские обычно так не говорят), то я оставляю машинный вариант.
6. Если машинный перевод предложения звучит по-русски непонятно, то начинаем разбираться почему: непонятно по причине плохого машинного перевода или по причине сложности темы или по причине туманности авторской мысли? При любом варианте приходится переводить предложение «вручную»: если причиной непонятности была слабость машинного перевода то предложение становится понятным, если сложность темы или авторский стиль – тут уж извините…
7. Копипаста через систему машинного перевода, форматирование текста и вставка иллюстраций занимает по времени 1-2 дня работы. Внимательное чтение и редактирование текста – 5-6 дней работы.
Мэтью Уэст хорош, большой молодец, я много открыл для себя в моделировании данных – но об этом в другой раз…
#перевод #мышлениеписьмом #уэст
🔥5👍4
Развитие и модернизация ИС
Задали вопрос чем отличается развитие от модернизации в контексте разработки ПО – для использования в официальной документации. Спрашивали – отвечаем:
1. В обыденном русском языке развитие и модернизация – синонимы. Тексты по социологии выделяют оттенки этих понятий: развитие – органичный рост системы (в данном случае социальной), реализация присущего системе потенциала изменений; модернизация – изменения в строго заданном направлении, перенимание и внедрение уже существующих в других местах образцов.
2. В казахстанском законе «Об информатизации» модернизация – часть развития, не касающаяся изменений в функциональности: «Ст.1 п. 6-1) развитие объекта информатизации - этап жизненного цикла объекта информатизации, на протяжении которого осуществляется комплекс мероприятий по реализации дополнительных функциональных требований, а также модернизации объекта информатизации».
3. В международных стандартах термин развитие для ПО, кажется, не используется. Вероятно, потому что за термином «development» закреплено понятие, которое в русском языке передается термином «разработка». Вместо этого используются термины «адаптивная модернизация» и «полная модернизация». Причем, разделение между ними проходит не по основанию «добавляем или нет новую функциональность», а по основанию цели изменений. Адаптивная модернизация выполняется в рамках адаптивного сопровождения программного средства для обеспечения работоспособности в изменяющейся операционной среде. Полная модернизация выполняется в рамках полного сопровождения в интересах пользователя. Т.е. и адаптивная и полная модернизация может затрагивать функциональность ПО, различие между ними – в объеме и цели изменений (См. ИСО/МЭК 14764-2002).
4. Российская нормативная практика, если смотреть на официальные комментарии Минцифры, ориентируется на ИСО/МЭК 14764-2002.
5. Можно также посмотреть эти термины в ШСМ А.Левенчука – там есть понятие метода работы/практики. Метод работы включает в себя а) технологии/инструменты; б) дисциплину/методику. Если меняются только технологии – то это модернизация, т.е. меняются только инструменты: писали тексты в одном приложении, потом поставили более современное, но задачи и способы написания текстов не изменились. Если изменили методы работы, дисциплину (например, тексты перестали писать копирайтеры, а стал генерировать ИИ на основе спецификаций требований, ну или вообще перешли на видео вместо текстов) – то это развитие.
Резюме: Если вы пишете спецификацию или договор, то лучше в тексте полностью раскрывать понятия, давать четкие определения. Иначе вы можете понимать под модернизацией обновление версий ОС, а заказчик – разработку дополнительной функциональности любого объема. Или наоборот.
Ссылки:
• ИСО/МЭК 14764-2002 "Информационная технология. Сопровождение программных средств" – https://files.stroyinf.ru/Data2/1/4294817/4294817040.pdf
• «Об информатизации» Закон Республики Казахстан от 24 ноября 2015 года № 418-V ЗРК – https://adilet.zan.kz/rus/docs/Z1500000418
#развитие #модернизация
Задали вопрос чем отличается развитие от модернизации в контексте разработки ПО – для использования в официальной документации. Спрашивали – отвечаем:
1. В обыденном русском языке развитие и модернизация – синонимы. Тексты по социологии выделяют оттенки этих понятий: развитие – органичный рост системы (в данном случае социальной), реализация присущего системе потенциала изменений; модернизация – изменения в строго заданном направлении, перенимание и внедрение уже существующих в других местах образцов.
2. В казахстанском законе «Об информатизации» модернизация – часть развития, не касающаяся изменений в функциональности: «Ст.1 п. 6-1) развитие объекта информатизации - этап жизненного цикла объекта информатизации, на протяжении которого осуществляется комплекс мероприятий по реализации дополнительных функциональных требований, а также модернизации объекта информатизации».
3. В международных стандартах термин развитие для ПО, кажется, не используется. Вероятно, потому что за термином «development» закреплено понятие, которое в русском языке передается термином «разработка». Вместо этого используются термины «адаптивная модернизация» и «полная модернизация». Причем, разделение между ними проходит не по основанию «добавляем или нет новую функциональность», а по основанию цели изменений. Адаптивная модернизация выполняется в рамках адаптивного сопровождения программного средства для обеспечения работоспособности в изменяющейся операционной среде. Полная модернизация выполняется в рамках полного сопровождения в интересах пользователя. Т.е. и адаптивная и полная модернизация может затрагивать функциональность ПО, различие между ними – в объеме и цели изменений (См. ИСО/МЭК 14764-2002).
4. Российская нормативная практика, если смотреть на официальные комментарии Минцифры, ориентируется на ИСО/МЭК 14764-2002.
5. Можно также посмотреть эти термины в ШСМ А.Левенчука – там есть понятие метода работы/практики. Метод работы включает в себя а) технологии/инструменты; б) дисциплину/методику. Если меняются только технологии – то это модернизация, т.е. меняются только инструменты: писали тексты в одном приложении, потом поставили более современное, но задачи и способы написания текстов не изменились. Если изменили методы работы, дисциплину (например, тексты перестали писать копирайтеры, а стал генерировать ИИ на основе спецификаций требований, ну или вообще перешли на видео вместо текстов) – то это развитие.
Резюме: Если вы пишете спецификацию или договор, то лучше в тексте полностью раскрывать понятия, давать четкие определения. Иначе вы можете понимать под модернизацией обновление версий ОС, а заказчик – разработку дополнительной функциональности любого объема. Или наоборот.
Ссылки:
• ИСО/МЭК 14764-2002 "Информационная технология. Сопровождение программных средств" – https://files.stroyinf.ru/Data2/1/4294817/4294817040.pdf
• «Об информатизации» Закон Республики Казахстан от 24 ноября 2015 года № 418-V ЗРК – https://adilet.zan.kz/rus/docs/Z1500000418
#развитие #модернизация
👍8🔥2
Кто такой аналитик бизнес-данных
Закончил перевод стандарта от IIBA Руководство по аналитике бизнес-данных. Стандарт выстроен примерно по той же схеме что и другие стандарты:
• Введение
• Области знаний (домены).
• Типовые задачи, которые решают аналитики.
• Техники (методы работы), которые используются для решения задач.
Кроме того, в отличие от BABOK Guide, здесь присутствуют в количестве практические примеры из реальной жизни – как та или иная компания решали свои проблемы с помощью аналитики данных, а также по каждому домену приводится разбор учебного кейса – в этом Руководство по аналитике бизнес-данных легче использовать как учебник, чем BABOK Guide.
Роль аналитика бизнес-данных в данном стандарте занимает примерно такое же место как роль бизнес-аналитика в BABOK Guide.
В BABOK Guide цепочка ролей от бизнес к технологиям выглядит примерно так: Эксперт предметной области – Бизнес-аналитик – Технический специалист. На реальном рынке это может быть даже Эксперт предметной области – Бизнес-аналитик – Системный аналитик – Технический специалист (разработчик). Понятно, что на практике иногда сотрудник может в одном лице исполнять некоторые смежные роли.
В руководстве по аналитике бизнес-данных цепочка ролей получается примерно следующая: Эксперт предметной области – Аналитик бизнес-данных – Специалист по обработке данных (data scientist) – Технический специалист (data engineer, разработчик).
Аналитик бизнес-данных – это не просто специалист по данным, которые умеет работать с данными знает технические инструменты и статистические методы (за этим лучше идти к дата-сайентистам), но это тот кто:
1. Может понять проблемы бизнеса и поставить правильные вопросы для решения с помощью данных: сформулировать гипотезы и спланировать исследование.
2. Может найти, изучить источники данных, получить из них релевантные данные.
3. Может выполнить анализ полученных данных.
4. Может выполнить правильную интерпретацию данных и подготовить отчеты по данным.
5. Может выполнить задачи по использованию результатов исследования для влияния на принятие бизнес-решений.
6. Может участвовать в управлении стратегией организации в области аналитики бизнес-данных.
О задачах, которые необходимо решать, чтобы всё это делать, в общих чертах и рассказывает стандарт на 200 страницах.
Ссылка на страницу IIBA с официальной информацией о стандарте и сертификации - https://www.iiba.org/business-analysis-certifications/business-data-analytics-certification/
#бизнесанализ #датаналитика #iiba #babok #cdba
Закончил перевод стандарта от IIBA Руководство по аналитике бизнес-данных. Стандарт выстроен примерно по той же схеме что и другие стандарты:
• Введение
• Области знаний (домены).
• Типовые задачи, которые решают аналитики.
• Техники (методы работы), которые используются для решения задач.
Кроме того, в отличие от BABOK Guide, здесь присутствуют в количестве практические примеры из реальной жизни – как та или иная компания решали свои проблемы с помощью аналитики данных, а также по каждому домену приводится разбор учебного кейса – в этом Руководство по аналитике бизнес-данных легче использовать как учебник, чем BABOK Guide.
Роль аналитика бизнес-данных в данном стандарте занимает примерно такое же место как роль бизнес-аналитика в BABOK Guide.
В BABOK Guide цепочка ролей от бизнес к технологиям выглядит примерно так: Эксперт предметной области – Бизнес-аналитик – Технический специалист. На реальном рынке это может быть даже Эксперт предметной области – Бизнес-аналитик – Системный аналитик – Технический специалист (разработчик). Понятно, что на практике иногда сотрудник может в одном лице исполнять некоторые смежные роли.
В руководстве по аналитике бизнес-данных цепочка ролей получается примерно следующая: Эксперт предметной области – Аналитик бизнес-данных – Специалист по обработке данных (data scientist) – Технический специалист (data engineer, разработчик).
Аналитик бизнес-данных – это не просто специалист по данным, которые умеет работать с данными знает технические инструменты и статистические методы (за этим лучше идти к дата-сайентистам), но это тот кто:
1. Может понять проблемы бизнеса и поставить правильные вопросы для решения с помощью данных: сформулировать гипотезы и спланировать исследование.
2. Может найти, изучить источники данных, получить из них релевантные данные.
3. Может выполнить анализ полученных данных.
4. Может выполнить правильную интерпретацию данных и подготовить отчеты по данным.
5. Может выполнить задачи по использованию результатов исследования для влияния на принятие бизнес-решений.
6. Может участвовать в управлении стратегией организации в области аналитики бизнес-данных.
О задачах, которые необходимо решать, чтобы всё это делать, в общих чертах и рассказывает стандарт на 200 страницах.
Ссылка на страницу IIBA с официальной информацией о стандарте и сертификации - https://www.iiba.org/business-analysis-certifications/business-data-analytics-certification/
#бизнесанализ #датаналитика #iiba #babok #cdba
🔥4
Моделирование данных: нормализация vs. онтология (1/2)
Нормализация – это подход к моделированию данных, при котором проектировщики стремятся устранить избыточность данных. Если вы ведете учет товаров на складе, то вам не важно вы храните насосы или хрустальную посуду – вам нужны только название, маркировка, размер. Поэтому, скорее всего вы будете хранить данные по товарам в одной таблице – вся нужная информация по объектам хранения вполне может быть описана несколькими полями реляционной таблицы. При проектировании с точки зрения нормализации борьба идет за форму хранения – чтобы данные хранились компактно, а что там за объекты реального мира кроются за данными – не важно. Правда, у нормального подхода есть недостаток: как только возникает необходимость по хрустальной посуде хранить дополнительную информацию, то нормальную модель нужно переделывать, и, соответственно, информационную систему.
Онтологический подход – это подход, при котором проектировщики стремятся к тому, чтобы их модель по возможности адекватно отражала реальный мир. Если вы проектируете модель данных для процессов производства, использования и обслуживания насосного оборудования, то вам неудобно будет использовать одинаковое описание для насосов и для хрустальной посуды – вы проектируете различные типы насосов (их сотни), которые имеют различное устройство, изготавливаются из различных материалов и по-разному используются. У каждого насоса может быть собственный жизненный цикл, от момента начала проектирования до утилизации. Каждый насос может фигурировать в большом количестве информационных систем, в которых его проектируют, производят, хранят, используют, и эти информационные системы могут обмениваться между собой данными о конструкциях насосов и о конкретных изделиях, их состоянии. Для того чтобы такой обмен данным был возможен, информационная модель насоса должна как можно точнее отображать реальный мир, «жизнь» насоса – тогда с большой вероятностью этой моделью смогут пользоваться и проектировщики, и производственники, и пользователи оборудования.
Все проектировщики моделей данных знают интересное свойство сего занятия: попроси двух проектировщиков построить модель одной и той же предметной области – получится две совершенно разных и, часто, несовместимых модели. Причем несовместимых не из-за разных названий, но и по существу. Отсюда рождается предположение: если мир проектировать исходя не из удобства и компактности хранения данных, а из его физических свойств, то модели у разных проектировщиков должны получаться более-менее одинаковые. Правда, о способах «правильного» онтологического описания реального мира тоже нужно договориться – а то на примере истории философии мы можем увидеть, что философские онтологии могут быть абсолютно несовместимыми. Технические онтологии должны быть универсальными, упрощать взаимопонимание насколько это возможно и в то же время точно отражать физические свойства моделируемых объектов.
К чему привели попытки договориться о правилах онтологического моделирования?
#моделирование #моделированиеданных #boro #hqdm #gellish
Нормализация – это подход к моделированию данных, при котором проектировщики стремятся устранить избыточность данных. Если вы ведете учет товаров на складе, то вам не важно вы храните насосы или хрустальную посуду – вам нужны только название, маркировка, размер. Поэтому, скорее всего вы будете хранить данные по товарам в одной таблице – вся нужная информация по объектам хранения вполне может быть описана несколькими полями реляционной таблицы. При проектировании с точки зрения нормализации борьба идет за форму хранения – чтобы данные хранились компактно, а что там за объекты реального мира кроются за данными – не важно. Правда, у нормального подхода есть недостаток: как только возникает необходимость по хрустальной посуде хранить дополнительную информацию, то нормальную модель нужно переделывать, и, соответственно, информационную систему.
Онтологический подход – это подход, при котором проектировщики стремятся к тому, чтобы их модель по возможности адекватно отражала реальный мир. Если вы проектируете модель данных для процессов производства, использования и обслуживания насосного оборудования, то вам неудобно будет использовать одинаковое описание для насосов и для хрустальной посуды – вы проектируете различные типы насосов (их сотни), которые имеют различное устройство, изготавливаются из различных материалов и по-разному используются. У каждого насоса может быть собственный жизненный цикл, от момента начала проектирования до утилизации. Каждый насос может фигурировать в большом количестве информационных систем, в которых его проектируют, производят, хранят, используют, и эти информационные системы могут обмениваться между собой данными о конструкциях насосов и о конкретных изделиях, их состоянии. Для того чтобы такой обмен данным был возможен, информационная модель насоса должна как можно точнее отображать реальный мир, «жизнь» насоса – тогда с большой вероятностью этой моделью смогут пользоваться и проектировщики, и производственники, и пользователи оборудования.
Все проектировщики моделей данных знают интересное свойство сего занятия: попроси двух проектировщиков построить модель одной и той же предметной области – получится две совершенно разных и, часто, несовместимых модели. Причем несовместимых не из-за разных названий, но и по существу. Отсюда рождается предположение: если мир проектировать исходя не из удобства и компактности хранения данных, а из его физических свойств, то модели у разных проектировщиков должны получаться более-менее одинаковые. Правда, о способах «правильного» онтологического описания реального мира тоже нужно договориться – а то на примере истории философии мы можем увидеть, что философские онтологии могут быть абсолютно несовместимыми. Технические онтологии должны быть универсальными, упрощать взаимопонимание насколько это возможно и в то же время точно отражать физические свойства моделируемых объектов.
К чему привели попытки договориться о правилах онтологического моделирования?
#моделирование #моделированиеданных #boro #hqdm #gellish
🔥4
Моделирование данных: нормализация vs. онтология (2/2)
1. Крис Партридж популярно объяснил о сложностях разработки правильных онтологий, выделил базовые сущности моделирования, обосновал необходимость думать о физических объектах, как о 4D – пространственно-временных протяженностях.
2. Группа специалистов разработала набор стандартов ISO 15926, как лингва франка обмена данными между независимыми информационными системами. По некоторым сведениям использование подхода, описанного в данном стандарте позволяет многократно сократить затраты на интеграционные проекты.
3. Некоторые соавторы ISO 15926 продолжили работу над улучшением решений, предложенных в стандарте. Мэтью Вест предложил свой вариант – HQDM (High Quality Data Modelling), Андрис ван Ренссен – Gellish (он с середины 90-х годов начал разрабатывать свой «Общий инженерный язык», как универсальный язык инженерного проектирования, который в итоги превратился в язык концептуального моделирования данных).
4. Параллельно с подачи Э.Эванса возникла идеология DDD – domain-driven design, которая не про интеграции, а про адаптивность в рамках одной системы: если мы спроектируем программные объекты системы по возможности отражающими реальный мир, то систему будет легче развивать.
В чем проблема онтологического подхода к данным?
1. Мышление людей сильно привязано к объект-атрибутной парадигме, корни которой уходят еще к Аристотелю (об этом много пишет Партридж).
2. Проектируя сложные системы и интеграции, люди теряются в сложности, как правило, плохо понимая, что многие сложности возникают не только из-за сложности предметной области, но и из-за подхода к проектированию.
3. Пока не созданы популярные и надежные решения, позволяющие реализовать онтологический подход к проектированию.
4. Другое)
Мораль: без рационального и осознанного онтологического проектирования тяжело жить даже на уровне создания отдельных сложных систем, а когда дело доходит до уровня крупного холдинга, отрасли или егов – разработка экосистемы превращается в непрерывный эпикфэйл.
О базовых объектах онтологий и прочих приятных вещах – в следующих постах.
#моделирование #моделированиеданных #boro #hqdm #gellish
1. Крис Партридж популярно объяснил о сложностях разработки правильных онтологий, выделил базовые сущности моделирования, обосновал необходимость думать о физических объектах, как о 4D – пространственно-временных протяженностях.
2. Группа специалистов разработала набор стандартов ISO 15926, как лингва франка обмена данными между независимыми информационными системами. По некоторым сведениям использование подхода, описанного в данном стандарте позволяет многократно сократить затраты на интеграционные проекты.
3. Некоторые соавторы ISO 15926 продолжили работу над улучшением решений, предложенных в стандарте. Мэтью Вест предложил свой вариант – HQDM (High Quality Data Modelling), Андрис ван Ренссен – Gellish (он с середины 90-х годов начал разрабатывать свой «Общий инженерный язык», как универсальный язык инженерного проектирования, который в итоги превратился в язык концептуального моделирования данных).
4. Параллельно с подачи Э.Эванса возникла идеология DDD – domain-driven design, которая не про интеграции, а про адаптивность в рамках одной системы: если мы спроектируем программные объекты системы по возможности отражающими реальный мир, то систему будет легче развивать.
В чем проблема онтологического подхода к данным?
1. Мышление людей сильно привязано к объект-атрибутной парадигме, корни которой уходят еще к Аристотелю (об этом много пишет Партридж).
2. Проектируя сложные системы и интеграции, люди теряются в сложности, как правило, плохо понимая, что многие сложности возникают не только из-за сложности предметной области, но и из-за подхода к проектированию.
3. Пока не созданы популярные и надежные решения, позволяющие реализовать онтологический подход к проектированию.
4. Другое)
Мораль: без рационального и осознанного онтологического проектирования тяжело жить даже на уровне создания отдельных сложных систем, а когда дело доходит до уровня крупного холдинга, отрасли или егов – разработка экосистемы превращается в непрерывный эпикфэйл.
О базовых объектах онтологий и прочих приятных вещах – в следующих постах.
#моделирование #моделированиеданных #boro #hqdm #gellish
👍5🔥1
Предел Ходжсона по Переслегину
Слушал лекцию Переслегина о проблемах оснований в математике и физике. Показаны проблемы взаимодействия онтологий, возникающих на различных предметных областях: теории чисел, теории множеств, геометрии, классической механики, термодинамики, электродинамики, теории излучения. В результате попыток создания Единой Теории Всего возникает квантовая механика и квантовая теория поля. Однако, новая теория «нефизична». В итоге, по мнению автора, в 20 веке в науке возникает кризис, который он называет «пределом Ходжсона» (термин придумал Сергей Шилов по аналогии с пределом Лейбница).
Предел Лейбница – это невозможность в одной голове уместить все науки – он был достигнут в 18 веке. Это «не травмирующий» предел – люди (ученые) легко смиряются с тем, что всего понять нельзя. Предел Ходжсона – травмирующий: это невозможность логически объединить в рамках одной науки разные направления исследований, при этом любые попытки объединить приводят к неприемлемым для мышления результатам. Предел Ходжсона достигается либо когда в рамках науки необходимо создать обобщающую теорию, а это не получается, либо когда по результатам рефлексии о созданной Теории Всего нужно вернуться к осмыслению оснований и всё заново перестроить стройно и логично в непротиворечивую теорию. Физика столкнулась с пределом понимания, математика столкнулась с пределом рефлексии.
В результате достижения этого предела ученые прилагают усилия, чтобы остановить парадигмальное развитие своей науки (им страшно), при этом локальное развитие возможно (иди и считай – это не страшно). В физике заставили поверить в существование промежуточного бозона Хикса (чтобы скрыть страх непонимания), в математике произошел переход к модели Цермело-Френкеля, которая не позволяет рефлексировать её основания.
На очереди подход к пределу Ходжсона экономики, эволюционной биологии и антропологии.
Почему предел назвали в честь Ходжсона – был такой фантаст в начале 20 в., с которого западная фантастика свернула с позитивного направления в хоррор, в ощущение онтологического трансцендентного зла (за ним Лавкрафт, Стивен Кинг и прочие). Отдельно можно поговорить как предел познания сказывается на состоянии культуры и политики – всеобщее ощущения конца истории, либо, наоборот, грядущих катастроф – откуда-то оттуда.
Кроме пределов Лейбница и Ходжсона Переслегин говорит еще о двух пределах познания, которые он именует пределами Ницше и Хокинга – об этом в другой раз (или никогда – и прекрасному есть предел, однако).
Ссылки:
1. 4-й предел познания. Почему наука не будет прежней. С. Переслегин, Д. Перетолчин. - https://dzen.ru/video/watch/61b0b998261b1a2ac63d64c9
2. Сергей Переслегин. Лекция №8. Предел Ходжсона и возникновение квантового подхода. Ч.1 - https://www.youtube.com/watch?v=IeoyODhBspA&ab_channel=%D0%A1%D0%9E%D0%A6%D0%98%D0%9E%D0%A1%D0%9E%D0%A4%D0%A2.%D0%A2%D0%92
3. Сергей Переслегин. Лекция №8. Предел Ходжсона и возникновение квантового подхода. Ч.2 https://www.youtube.com/watch?v=JgKhC2-SnSI&list=PLVJKvxv2YVRKQC07WZpmcQ8_xSpAo2lgA&index=12&ab_channel=%D0%A1%D0%9E%D0%A6%D0%98%D0%9E%D0%A1%D0%9E%D0%A4%D0%A2.%D0%A2%D0%92
#философиянауки #переслегин
Слушал лекцию Переслегина о проблемах оснований в математике и физике. Показаны проблемы взаимодействия онтологий, возникающих на различных предметных областях: теории чисел, теории множеств, геометрии, классической механики, термодинамики, электродинамики, теории излучения. В результате попыток создания Единой Теории Всего возникает квантовая механика и квантовая теория поля. Однако, новая теория «нефизична». В итоге, по мнению автора, в 20 веке в науке возникает кризис, который он называет «пределом Ходжсона» (термин придумал Сергей Шилов по аналогии с пределом Лейбница).
Предел Лейбница – это невозможность в одной голове уместить все науки – он был достигнут в 18 веке. Это «не травмирующий» предел – люди (ученые) легко смиряются с тем, что всего понять нельзя. Предел Ходжсона – травмирующий: это невозможность логически объединить в рамках одной науки разные направления исследований, при этом любые попытки объединить приводят к неприемлемым для мышления результатам. Предел Ходжсона достигается либо когда в рамках науки необходимо создать обобщающую теорию, а это не получается, либо когда по результатам рефлексии о созданной Теории Всего нужно вернуться к осмыслению оснований и всё заново перестроить стройно и логично в непротиворечивую теорию. Физика столкнулась с пределом понимания, математика столкнулась с пределом рефлексии.
В результате достижения этого предела ученые прилагают усилия, чтобы остановить парадигмальное развитие своей науки (им страшно), при этом локальное развитие возможно (иди и считай – это не страшно). В физике заставили поверить в существование промежуточного бозона Хикса (чтобы скрыть страх непонимания), в математике произошел переход к модели Цермело-Френкеля, которая не позволяет рефлексировать её основания.
На очереди подход к пределу Ходжсона экономики, эволюционной биологии и антропологии.
Почему предел назвали в честь Ходжсона – был такой фантаст в начале 20 в., с которого западная фантастика свернула с позитивного направления в хоррор, в ощущение онтологического трансцендентного зла (за ним Лавкрафт, Стивен Кинг и прочие). Отдельно можно поговорить как предел познания сказывается на состоянии культуры и политики – всеобщее ощущения конца истории, либо, наоборот, грядущих катастроф – откуда-то оттуда.
Кроме пределов Лейбница и Ходжсона Переслегин говорит еще о двух пределах познания, которые он именует пределами Ницше и Хокинга – об этом в другой раз (или никогда – и прекрасному есть предел, однако).
Ссылки:
1. 4-й предел познания. Почему наука не будет прежней. С. Переслегин, Д. Перетолчин. - https://dzen.ru/video/watch/61b0b998261b1a2ac63d64c9
2. Сергей Переслегин. Лекция №8. Предел Ходжсона и возникновение квантового подхода. Ч.1 - https://www.youtube.com/watch?v=IeoyODhBspA&ab_channel=%D0%A1%D0%9E%D0%A6%D0%98%D0%9E%D0%A1%D0%9E%D0%A4%D0%A2.%D0%A2%D0%92
3. Сергей Переслегин. Лекция №8. Предел Ходжсона и возникновение квантового подхода. Ч.2 https://www.youtube.com/watch?v=JgKhC2-SnSI&list=PLVJKvxv2YVRKQC07WZpmcQ8_xSpAo2lgA&index=12&ab_channel=%D0%A1%D0%9E%D0%A6%D0%98%D0%9E%D0%A1%D0%9E%D0%A4%D0%A2.%D0%A2%D0%92
#философиянауки #переслегин
👍5🔥3
Пет-проекты для аналитиков – насколько реально?
Сегодня с коллегой (Даурен Айтенов) коснулись вопроса о системных аналитиках: «Проводя много собеседований, часто удивляюсь отсутствию желания расти самостоятельно у БА и СА, знают практически нифига... Единицы, например спецы: НИТ, РЦЭЗ, ЦРТР, внедряли системы и в целом и этапность и доки через себя пропускали и как говорится вспоминая свой опыт - отвечают на часть вопросов, но остальные крайний ахтунг...». Даурен предлагает придумать удобную форму для пет-проектов аналитиков, с помощью которых они могли бы учиться и которые можно было бы показывать на собеседованиях.
Итак, pet-проекты – это личные проекты, над которыми специалист работает в тренировочных целях. Зачем они нужны:
1. Для самообучения.
2. Для демонстрации своего профессионализма.
В какой форме аналитики могли бы делать свои пет-проекты:
1. Концепция системы.
2. Концепция + прототип.
3. Бизнес-канвас + cjm + бэклог для продукта.
4. BRD + SRS + план работ.
5. Любой набор концептуального описания, логического и технического проектирования.
Пет-проект по анализу должен по возможности касаться всех аспектов гипотетического проекта, акценты могут быть разные: у аналитика на продуктовой разработке может быть акцент на анализе рынка и рыночных гипотезах, у системного аналитика – на проработке технических решений, интеграций, моделей данных и т.д. – кто на что учился (хочет научиться).
Личный пет-проект удобен еще и тем, что под него проще находить менторов и учебные материалы: проработка под руководством ментора сильно ускорит процесс обучения и позволит перенять у ментора рабочие практики и подходы.
Ну и про перспективы найма можно сказать точно – когда специалист на собеседовании рассказывает про конкретный проект, для которого он сам придумывал решения, может обосновать свои подходы, методы и объяснить почему он выбрал те или иные решения – это производит чрезвычайно выгодное впечатление. Обычно это могут делать только высококвалифицированные специалисты с многолетним опытом – те, которые работали ведущими аналитиками на серьезных проектах. Джуны и мидлы обычно «пилят» отдельные «куски» систем и не несут серьезной ответственности за успех проекта в целом – поэтому на концептуальные вопросы касательно проекта в целом и способов его реализации внятно ответить не могут – они с этой стороны и не думали. Точкой роста здесь может стать личный пет-проект – это хороший способ научиться продемонстрировать своё системное мышление и специфические навыки, в которых вы сильны.
В связи с этим возникают вопросы:
1. Насколько реально создать моду на пет-проекты по анализу?
2. Не нужно ли для этого создать ряд рекомендуемых шаблонов?
3. Не нужно ли создать моду на менторство по разработке пет-проектов?
4. Не нужно ли создать моду на «если ты закончил курс по БА и у тебя нет личного пет-проекта – ты отучился зря»?
Предлагаю обсудить.
Примечание: я знаю про хорошую практику личных проектов в некоторых школах и курсах по БА/СА – речь не о счастливых исключениях, а о широкой практике и потоке тех кандидатов, которые приходят к нам на собеседование.
#бизнесанализ #системныйанализ
Сегодня с коллегой (Даурен Айтенов) коснулись вопроса о системных аналитиках: «Проводя много собеседований, часто удивляюсь отсутствию желания расти самостоятельно у БА и СА, знают практически нифига... Единицы, например спецы: НИТ, РЦЭЗ, ЦРТР, внедряли системы и в целом и этапность и доки через себя пропускали и как говорится вспоминая свой опыт - отвечают на часть вопросов, но остальные крайний ахтунг...». Даурен предлагает придумать удобную форму для пет-проектов аналитиков, с помощью которых они могли бы учиться и которые можно было бы показывать на собеседованиях.
Итак, pet-проекты – это личные проекты, над которыми специалист работает в тренировочных целях. Зачем они нужны:
1. Для самообучения.
2. Для демонстрации своего профессионализма.
В какой форме аналитики могли бы делать свои пет-проекты:
1. Концепция системы.
2. Концепция + прототип.
3. Бизнес-канвас + cjm + бэклог для продукта.
4. BRD + SRS + план работ.
5. Любой набор концептуального описания, логического и технического проектирования.
Пет-проект по анализу должен по возможности касаться всех аспектов гипотетического проекта, акценты могут быть разные: у аналитика на продуктовой разработке может быть акцент на анализе рынка и рыночных гипотезах, у системного аналитика – на проработке технических решений, интеграций, моделей данных и т.д. – кто на что учился (хочет научиться).
Личный пет-проект удобен еще и тем, что под него проще находить менторов и учебные материалы: проработка под руководством ментора сильно ускорит процесс обучения и позволит перенять у ментора рабочие практики и подходы.
Ну и про перспективы найма можно сказать точно – когда специалист на собеседовании рассказывает про конкретный проект, для которого он сам придумывал решения, может обосновать свои подходы, методы и объяснить почему он выбрал те или иные решения – это производит чрезвычайно выгодное впечатление. Обычно это могут делать только высококвалифицированные специалисты с многолетним опытом – те, которые работали ведущими аналитиками на серьезных проектах. Джуны и мидлы обычно «пилят» отдельные «куски» систем и не несут серьезной ответственности за успех проекта в целом – поэтому на концептуальные вопросы касательно проекта в целом и способов его реализации внятно ответить не могут – они с этой стороны и не думали. Точкой роста здесь может стать личный пет-проект – это хороший способ научиться продемонстрировать своё системное мышление и специфические навыки, в которых вы сильны.
В связи с этим возникают вопросы:
1. Насколько реально создать моду на пет-проекты по анализу?
2. Не нужно ли для этого создать ряд рекомендуемых шаблонов?
3. Не нужно ли создать моду на менторство по разработке пет-проектов?
4. Не нужно ли создать моду на «если ты закончил курс по БА и у тебя нет личного пет-проекта – ты отучился зря»?
Предлагаю обсудить.
Примечание: я знаю про хорошую практику личных проектов в некоторых школах и курсах по БА/СА – речь не о счастливых исключениях, а о широкой практике и потоке тех кандидатов, которые приходят к нам на собеседование.
#бизнесанализ #системныйанализ
👍9🔥3❤1
Рациональность, войны и Левенчук 🙂 (1/2)
Встрял в сети в дискуссию по поводу свежего поста Анатолия Левенчука на тему, что если делать людей умнее, то войн будет меньше.
Левенчук начал свою просветительскую деятельность с обучения магистрантов системной инженерии. Несмотря на то, что его ученики были сравнительно подготовлены (например, это могла быть магистратура МФТИ), практика показала, что большинство учеников имеют проблемы с понятийным мышлением и с системностью мышления. В связи с этим появилось несколько подготовительных курсов: моделирование, системное мышление, системное саморазвитие.
На практике было выявлено, что если обучать группу людей (профессиональных инженеров с высшим образованием), то нормальное понятийное мышление доступно примерно 10% учеников, которые имеют большие проблемы с усвоением системной инженерии. Если “ставить” мышление предварительными курсами то системная инженерия становится доступной почти всем ученикам. Вокруг курсов и книг Левенчука образовалась ШСМ - школа системного менеджмента - своеобразная инженерно-менеджерская школа, которую прошли уже тысячи людей. Обучение, кстати, доступное: все материалы в свободном доступе, если нужна возможность выполнять домашние задание и тесты, то стоимость - 700 р. в месяц, если нужны специальные занятия с преподавателем - тогда гораздо дороже. Сейчас в ШСМ опубликовано 12 курсов, рассчитанных на 3 года вдумчивого изучения. Впрочем, самостоятельно курсы можно проходить в произвольном порядке в собственном темпе. Что мне больше всего нравится в текстах Левенчука - его стремление быть “на фронтире” научного знания и пользоваться последними достижениями в изучаемых дисциплинах, т.н. SOTA - state of the art, т.е. тексты курсов и книги непрерывно обновляются и изменяются, вплоть до корректировки междисциплинарной онтологии, благодаря этому удобно следить что происходит нового в междисциплинарном мире и как взаимодействуют между собой идеи ведущих специалистов в физике, математике, инженерии, философии науки, этике, экономике.
Краткий перечень идеологических предпочтений Левенчука:
1. Атеизм.
2. Либертарианство.
3. Австрийская экономическая школа.
4. Космополитизм.
Впрочем, учебные материалы не являются пропагандой идеологии - предлагается предельно рациональный подход на основе идеи: чтобы договариваться нужно прежде всего уметь понимать чужие картины мира, чужую этику, чужое мировоззрение. Не говоря уже о том, что нужно уметь моделировать и разбираться с собственной картиной мира.
Так, панегирик завершу, теперь о войне.
#мышление #война #левенчук #шсм #пинкер #дойч
Встрял в сети в дискуссию по поводу свежего поста Анатолия Левенчука на тему, что если делать людей умнее, то войн будет меньше.
Левенчук начал свою просветительскую деятельность с обучения магистрантов системной инженерии. Несмотря на то, что его ученики были сравнительно подготовлены (например, это могла быть магистратура МФТИ), практика показала, что большинство учеников имеют проблемы с понятийным мышлением и с системностью мышления. В связи с этим появилось несколько подготовительных курсов: моделирование, системное мышление, системное саморазвитие.
На практике было выявлено, что если обучать группу людей (профессиональных инженеров с высшим образованием), то нормальное понятийное мышление доступно примерно 10% учеников, которые имеют большие проблемы с усвоением системной инженерии. Если “ставить” мышление предварительными курсами то системная инженерия становится доступной почти всем ученикам. Вокруг курсов и книг Левенчука образовалась ШСМ - школа системного менеджмента - своеобразная инженерно-менеджерская школа, которую прошли уже тысячи людей. Обучение, кстати, доступное: все материалы в свободном доступе, если нужна возможность выполнять домашние задание и тесты, то стоимость - 700 р. в месяц, если нужны специальные занятия с преподавателем - тогда гораздо дороже. Сейчас в ШСМ опубликовано 12 курсов, рассчитанных на 3 года вдумчивого изучения. Впрочем, самостоятельно курсы можно проходить в произвольном порядке в собственном темпе. Что мне больше всего нравится в текстах Левенчука - его стремление быть “на фронтире” научного знания и пользоваться последними достижениями в изучаемых дисциплинах, т.н. SOTA - state of the art, т.е. тексты курсов и книги непрерывно обновляются и изменяются, вплоть до корректировки междисциплинарной онтологии, благодаря этому удобно следить что происходит нового в междисциплинарном мире и как взаимодействуют между собой идеи ведущих специалистов в физике, математике, инженерии, философии науки, этике, экономике.
Краткий перечень идеологических предпочтений Левенчука:
1. Атеизм.
2. Либертарианство.
3. Австрийская экономическая школа.
4. Космополитизм.
Впрочем, учебные материалы не являются пропагандой идеологии - предлагается предельно рациональный подход на основе идеи: чтобы договариваться нужно прежде всего уметь понимать чужие картины мира, чужую этику, чужое мировоззрение. Не говоря уже о том, что нужно уметь моделировать и разбираться с собственной картиной мира.
Так, панегирик завершу, теперь о войне.
#мышление #война #левенчук #шсм #пинкер #дойч
👍6🔥1
Рациональность, войны и Левенчук 🙂 (2/2)
В отношении к различным войнам Левенчук обычно нейтрален: воюющие стороны стоят друг друга и ничем друг друга не лучше. Политика и идеология всех государств - порочна. В посте повторяется мысль о том, что войны - от неумности, и что главное - просвещать людей: “Без … массового образования будут продолжаться все проблемы (войны, локдауны для победы над ковидом, религиозная промывка мозгов, допотопное образование, очень плохая наука, феномены типа биг фармы в медицине, несть этим бедам числа), которые вроде как требуют немедленной с ними борьбы, хотя эта борьба оказывается вполне тщетной. Я считаю, что не хватает знаний (оптимизм по Дойчу), чтобы прорваться, для знаний нужны просто неглупые люди, а их можно взять -- и научить. Надо только (возвращаюсь к предыдущему пункту из трёх шагов):
-- знать, чему учить
-- иметь материалы курсов,
-- развернуть инфраструктуру дешёвого качественного обучения”.
В целом мне нравится направление мыслей Левенчука, на мой взгляд оно беспроигрышное, даже если ничего не получится - качественное образование это всегда хорошо. Единственно я сделал несколько замечаний по теме:
Гипотеза 1. Если политиков, военных и инженеров из ОПК провести через курсы ШСМ, то воевать они от этого меньше не станут.
Гипотеза 2. Если какая-то из сторон массово обучит своих политиков, инженеров и военных на курсах ШСМ, то получит некоторое военное преимущество.
Гипотеза 3. Гуманизм, как и приемлемость войн, связаны с эволюцией сознания. Способность к эмпатии, готовность делиться пищей с неродственными особями, как и готовность жертвовать своей жизнью или жизнью части собственной популяции ради выживания популяции в целом - эволюционные биологические явления, для изменения которых курсов ШСМ будет недостаточно, если только курсы не вырастут в систему эволюционного отбора в "правильном" направлении (с точки зрения создателей системы).
Гипотеза 4. Если люди становятся умнее, то им проще понимать и свою этику и этику других, а также они будут видеть больше вариантов решений, и, если есть склонность к гуманности, то легче будет находить взаимоприемлемые решения, не связанные со смертоубийством или грубым насилием.
Гипотеза 5. Есть общий исторический тренд в сторону гуманизации, который как-то связан с просвещением - это пытаются доказывать Д.Дойч и С.Пинкер. Если смотреть на периоде в несколько сот лет, то можно видеть несомненную гуманизацию человечества - предположительно это связано с просвещением и образованием. Утверждение, конечно, спорное, но хочется ему верить.
Мораль: безусловно нужно учиться самому и учить других. Учеба должна идти в сторону прагматизма и рационализма - это поможет договариваться людям разных культур и рас (учеба шаманским практикам, нумерологии и гаданию по картам Таро не об этом).
Ссылки:
Пост А.Левенчука “Работать с причиной, а не следствиями: массово делать людей и AI умнее” на сайте клуба ШСМ - https://systemsworld.club/t/rabotat-s-prichinoj-a-ne-sledstviyami-massovo-delat-lyudej-i-ai-umnee/11437
Пост А.Левенчука в ЖЖ - https://ailev.livejournal.com/1719578.html
Собственно сайт ШСМ - https://aisystant.system-school.ru/
Стивен Пинкер. Просвещение продолжается - https://ozon.kz/product/prosveshchenie-prodolzhaetsya-v-zashchitu-razuma-nauki-gumanizma-i-progressa-nauchno-299227090/
#мышление #война #левенчук #шсм #пинкер #дойч
В отношении к различным войнам Левенчук обычно нейтрален: воюющие стороны стоят друг друга и ничем друг друга не лучше. Политика и идеология всех государств - порочна. В посте повторяется мысль о том, что войны - от неумности, и что главное - просвещать людей: “Без … массового образования будут продолжаться все проблемы (войны, локдауны для победы над ковидом, религиозная промывка мозгов, допотопное образование, очень плохая наука, феномены типа биг фармы в медицине, несть этим бедам числа), которые вроде как требуют немедленной с ними борьбы, хотя эта борьба оказывается вполне тщетной. Я считаю, что не хватает знаний (оптимизм по Дойчу), чтобы прорваться, для знаний нужны просто неглупые люди, а их можно взять -- и научить. Надо только (возвращаюсь к предыдущему пункту из трёх шагов):
-- знать, чему учить
-- иметь материалы курсов,
-- развернуть инфраструктуру дешёвого качественного обучения”.
В целом мне нравится направление мыслей Левенчука, на мой взгляд оно беспроигрышное, даже если ничего не получится - качественное образование это всегда хорошо. Единственно я сделал несколько замечаний по теме:
Гипотеза 1. Если политиков, военных и инженеров из ОПК провести через курсы ШСМ, то воевать они от этого меньше не станут.
Гипотеза 2. Если какая-то из сторон массово обучит своих политиков, инженеров и военных на курсах ШСМ, то получит некоторое военное преимущество.
Гипотеза 3. Гуманизм, как и приемлемость войн, связаны с эволюцией сознания. Способность к эмпатии, готовность делиться пищей с неродственными особями, как и готовность жертвовать своей жизнью или жизнью части собственной популяции ради выживания популяции в целом - эволюционные биологические явления, для изменения которых курсов ШСМ будет недостаточно, если только курсы не вырастут в систему эволюционного отбора в "правильном" направлении (с точки зрения создателей системы).
Гипотеза 4. Если люди становятся умнее, то им проще понимать и свою этику и этику других, а также они будут видеть больше вариантов решений, и, если есть склонность к гуманности, то легче будет находить взаимоприемлемые решения, не связанные со смертоубийством или грубым насилием.
Гипотеза 5. Есть общий исторический тренд в сторону гуманизации, который как-то связан с просвещением - это пытаются доказывать Д.Дойч и С.Пинкер. Если смотреть на периоде в несколько сот лет, то можно видеть несомненную гуманизацию человечества - предположительно это связано с просвещением и образованием. Утверждение, конечно, спорное, но хочется ему верить.
Мораль: безусловно нужно учиться самому и учить других. Учеба должна идти в сторону прагматизма и рационализма - это поможет договариваться людям разных культур и рас (учеба шаманским практикам, нумерологии и гаданию по картам Таро не об этом).
Ссылки:
Пост А.Левенчука “Работать с причиной, а не следствиями: массово делать людей и AI умнее” на сайте клуба ШСМ - https://systemsworld.club/t/rabotat-s-prichinoj-a-ne-sledstviyami-massovo-delat-lyudej-i-ai-umnee/11437
Пост А.Левенчука в ЖЖ - https://ailev.livejournal.com/1719578.html
Собственно сайт ШСМ - https://aisystant.system-school.ru/
Стивен Пинкер. Просвещение продолжается - https://ozon.kz/product/prosveshchenie-prodolzhaetsya-v-zashchitu-razuma-nauki-gumanizma-i-progressa-nauchno-299227090/
#мышление #война #левенчук #шсм #пинкер #дойч
SystemsWorld Club
Работать с причиной, а не следствиями: массово делать людей и AI умнее
Войны – следствия незнания, незнание – следствие неумности. Надо массово делать людей и AI умнее Пока в мире идёт ползучая мировая война, я продолжаю работать: я уже довольно много провёл времени (десятки лет) в разных проектах в попытках изменить мир к…
👍5🔥2