Как то одна из сотрудниц заявила мне, что монитор её не любит и выключается как только она подходит к нему. Помню свой шок когда убедился в этом воочию. Как только женшина подходила к своему большому ЭЛТ монитору он тут же выключался, когда отходила - включался. На меня и других сотрудников монитор так не реагировал. Прозрение наступило, когда я случайно коснулся сотрудницы и меня шибануло статическим разрядом. На женщине была синтетическая кофта и со временем на ней скапливался такой заряд, что при ее приближении срабатывала защитная автоматика внутри монитора, отключающая вывод изображения.
Решение чистой задачи очень сложно корректно оценить, так как не будет практической апробации решения, и критериев его приёмки. Слишком много будет допущений если задача будет чисто теоретическая, а для решения практической задачи, нужен плотный диалог и погружение в проблему и среду (это только Шерлок Холмс разгадывал преступления играя дома на скрипке)
Задача расследования..... вот в этом то и отличие ТРИЗ - это комплексная методология, позволяющая диагностировать проблему, и затем решить её. По этому и некорректно сравнивать ТРИЗ с методом отрицаний.
А вообще ТРИЗ хорошо дополняет методологию Деревьев поиска решений из Теории Ограничений Систем Э.Голдратта.
В общем я глубоко за то, что изучать нужно различные инструменты и учится применять их эффективно. И чем больше знаний в данной области, тем эффективнее используемые инструменты.
И еще то что сразу бросается в глаза:
"Нужно больше информации про сам технологический процесс. И подробное его описание его деталей. Какой металл. Какие подробности работы станка. " Это хорошо, вопросы правильные, они расширяют поле решение проблемы, но они случайные, большая их часть мало относится к проблеме. Это очень похоже на метод перебора. Попробовали то, это, пятое, десятое..... Триз же сконентрирован на другом подходе - ключевое это выделение проблемы. В процессе со станком режущем профили - проблема описана отклонение линейных размеров отверстий. Переход от исследовательской задачи к изобретательской чрезвычайно прост. От чего зависит положение отверстий? - от начальной точки отсчёта координат (так называемой технологической базы). Далее опредеяем, что нужно сделать, чтобы технологическая база устанавливалась неверно и раскручиваем цепочку рассуждений далее.... Вобщем мы целенаправленно ищем место возникновения проблемы, а не пытаемся расшевелить воображение, чтобы случайным образом угадать выигрышный вариант. В конце мы придем к четкому техническому противоречию, и уже потом будем искать способ его устранения. В этом и суть изобретения, не придумать как решить, а найти именно ту задачу, которую действительно нужно решать.
Поиск проблемы на практике, гораздо важнее, чем варианты ее решения, так как решая не ту проблему даже очень эффективно - результат можем получить весьма посредственный.
Согласен, условие задачи описано не полно, хотя это похоже на то, что в жизни. Правильно поставленная задача, это уже 90 процентов решения.
Интересный момент, я тоже прикидывал решение по ТРИЗ исходя из описания. ИКР в первом приближении получился такой: Банер в геолокационной точке есть, банера в геолокационной точке нет. Ну и так как мне сильно импонирует вепольный анализ, я наплевав на АРИЗ сразу прошелся по полям. Электромагнитное поле, сразу натолкнуло на идею с лазером. Можно было бы закрепить на сосне , обеспечить аккумулятор возможно солнечные батареи и проецировать на полотно дороги, но оставались проблемы с безопасностью и с дневной видимостью.
Еще была идея с рекламой в навигаторе, с геопривязкой, как раз для проезжающих мимо, или в онлайн картах. Из той же серии банер есть - банера нет.
С аэростатом идея хороша, при условии, хотя для регулирующих органов вроде как и полет авиамодели на торосе, это все равно полет со всеми вытекающими.
Метод отрицаний будет сильно зависеть от того, как мы изначально опишем задачу. Вот я сформулировал, что грузовик уперся, вы что у него слишком большая высота, а кто то скажет что у моста высота слишком маленькая. Фокус отрицания будет смещаться в зависимости от формулировки. Решение будет в каком то роде случайным, ТРИЗ направлен на четкую идентификацию проблемы и более системный подбор решений.
Вот еще кейс из жизни. На одном производстве регулярно случался брак деталей. Алюминиевые профили срезались под углом 45 градусов затем доставлялись на станок где в них сверлились отверстия и делались пазы. Периодически отверстия оказывались смещёнными на 1-2 мм. И здесь первоочередная задача выявить проблему (т.е. превратить исследовательскую задачу в изобретательскую), и только потом генерировать решения. Опять же в моей формулировке уже есть решение, поскольку я знаю ответ.
В оригинале формулировка выглядела так: На станке таком-то переодически возникает брак из за отклонения линейных допусков при сверлении отверстий в алюминиевых профилях.
Спойлер, проблема оказалась в транспортировочной тележке и производственной культуре, а решение в изменении технологического процесса изготовления детали.
Это, что называется простой случай, а есть в производстве случаи, корень проблемы которых выходит далеко за пределы формулировки задачи.
Вот такой например, детали из одного и того же листа металла режутся на лазере и затем поступают на гибочный станок. Детали одинаковые (в оригинале вообще то разной формы были), но после гибки на станке, часть деталей имеет отклонения линейных размеров, от назначенных допусков. Допуски менять нельзя, нужно разобраться почему часть деталей получаются бракованными. По ходу разбирательства выясняем, что температурные улсовия, управляющая программа, партия и даже конкретный лист материала, применяемые пуансоны все одинаковое.
Есть еще интересный вариант использования аналога метода отрицаний для поиска проблем в бизнесе. Вот кейс, наши велосипеды плохо продаются. Как поднять продажи? Фишка человеческой психики в том, что мы склонны придерживатся одной-двух успешных стратегий, и одновременно легко имеем в мозгу с десяток неуспешных. Эволюционно, выживали в основном тет кто не рисковал. По этому нам проще ответить на вопрос, чего не нужно делать? Итак переформулировал вопрос кейса, что нужно делать, чтобы продажи велосипедов упали? Вариантов море, теперь смотрим, какие проблемы нам наиболее близки и работаем с ними.
Метод отрицаний это метод генерации идей, ТРИЗ же заточен на решение проблемы. Так в чем тогда соревнование? В инструментарии триз есть раздел РТВ развитие творческого воображения, в том числе и метод отрицаний, как часть методологии. Даже в АРИЗ 85 есть шаг "Сделай наоборот". Просто в ТРИЗ много всего и нужно разбираться и учится применять, а метод отрицаний это единичный прием, который проще для осознания и применения. Известная в ТРИЗ задача, грузовик застрял под мостом уперевшись крышей в верхний свод моста. Как его вытащить? Метод отрицаний тут мало полезен. Не грузовик, не застрял, не уперся, не в свод, не моста. Из всего этого мы можем работать только с не уперся, очень сложно от этого перейти к формулировке основной проблемы, и вариантам решения. Да можно понять, что грузовик перестанет упираться, когда его крыша перестанет касаться свода моста, и отсюда уже понять что нужно уменьшить высоту грузовика.. В триз же мы будем сконцентрированы на поиске основного технического противоречия сформулировав его как: зазор есть-зазора нет. Ну и как следствие, доя увеличения зазора нужно уменьшить высоту. Это если речь про решение задач данными методами. Ну а если речь про пофантазировать и найти варианты, то приемов очень много, метод отрицаний не единственный рабочий. Взять те же войлочные стельки: если не войлочные то какие? Резиновые, паролоновые и т.п - метод отрицаний провоцирует на простой перебор материалов. Морфологический анализ, позволяет выйти за эти рамки: можно менять, материал, свойства (цвет, коэффициент упругости,память формы), агрегатное состояние(газовые, жидкостные), работать с полями(добавляя тепловые, магнитные, электрические). Вобщем много всего. И не нужно путать ТРИЗ (книга Альтшуллера, с изложением основ теории доступна бесплатно) и курсы, на которых учат ТРИЗ пользоваться. Мы же хорошо знаем, что не все йогурты одинаково полезны
Вот несколько кейсов для ChatGpt из моей практики: 1.,Напиши API в формате OpenApi. Далее описание требований к методам и форматам данных. 2. Создай описание в формате PlantUml диаграммы последовательности для следующего процесса: далее описание процесса. 3. Создай описание в формате plantuml для er-диаграммы для следующей модели данных. 4. Создай в формате yaml описание для следующей модели данных. 5. Напиши регулярное выражение для преобразования строки1 в строка2. 6. Опиши технические требования к .... может подать пару свежих идей.
Сразу оговорюсь я не программист, а бизнес аналитик. Да и мой комментарий скорее к коментам выше, чем к самой статье. Но мне как не программисту не вполне понятно, для чего программисты сначала создают себе проблемы, а потом героически их решают. Каждый год создаются новые библиотеки, фреймворки, языки программирования, но сама разработка не становится проще. Замыкание прекрасная концепция из функционального если не ошибаюсь программирования, но когда ее применяют для неявной модификации стейта, что способно взорвать мозг при последующей отладке, то в голове только один вопрос - зачем? Действительно хотелось бы видеть в статье адекватные примеры реализации. Скажем не просто счетчик, но и объяснение, почему другим образом его реализовывать не эффективно. Мне кажется такое объяснение позволит избежать применения той или иной технологии не к месту и не по назначению.
Что так сложно то, типы мышления и т.п. Вопрос то простой будет ли меняться поведение функции возвращающей значение или нет? Хорошая практика при написании любого кода определится с типами данных и их жизненным циклом. Разбить яйцо можно множеством способов, но не все из них подойдут для приготовления яичницы. Вот и вся разница в мышлении. P.S. изучение языков функционального программирования очень сильно прокачивает скил проектирования архитектуры кода на любом языке программирования. Вот там вот как раз и реализуется возможность пощупать другой тип мышления, даже не ради того чтобы на них программировать, а просто ради того, чтобы иметь возможность смотреть на свой код несколько шире чем привык.
Главная ценность аналитика, это широкий взгляд на проблемы бизнеса и проблемы ит-решений. Разделение ролей, на БА и СА это либо следствие дисбаланса компетенций аналитика, либо распределение аналитической нагрузки в большой команде. Аналитик не может и не должен в совершенстве владеть техническими скилами, или компетенциями бизнеса: для этого есть соответствующие профессионалы, задача аналитика выстроить эффективные коммуникации между бизнесом и ит. Сила аналитика, в умении находить решения выходящие за границы компетенции узкоспециализированых профессионалов. Аналитик нужен тогда, когда ИТ не может реализовать требования бизнеса, а бизнес не может адаптировать свои процессы под структуру ит. Вот оно поле боя аналитика, который может и бизнесу процесс подправить, и ит решение подходящее подобрать, которое поможет не наступить на грабли. И для бизнеса и для ИТ такие шаги порой кажутся радикальными (а что так можно было?)? Аналитики, часто выступают как таран для пролома жестких ограничений решаемой задачи. Ну а если разделять функции ба и са, то по сути получим недобизнес и недоразработчика которые вполне себе могут и недоговорится. Так что деление на СА и БА, имеет смысл либр внутри хорошо слаженой команды аналитиков доя распределения нагрузки, либо в тех случаях когда часть функций аналитика успешно взваливает на себя бизнес или ИТ.
Был не прав. Система у Вавилонян была позиционной - это сильно упрощает расчёты. Судя по источникам -изначально не было понятия 0, что вносило некоторую неоднозначность в цифровую запись. А вот известны ли были приёмы деления и умножения в столбик - я пока упоминаний не нашёл.
Не забывайте, что четыре тысячи лет назад не было позиционной системы счисления и сама система была 60ричная. Так что даже умножение было не тривиальной задачей.
Прокрастинация обычно тесно связана с неопределенностью.Когда нет четкого понимания задачи - появляются сомнения, беспокойство и жгучее желание отложить принятие трудных решений на потом. Чтобы снять неопределенность нужно : Описать исходное состояние как есть. Хорошо подойдут для этого средства графического моделирования. В приведенном примере, схема исходной базы данных. Здесь мы устраним первый род неопределенности: то что нам дано. Затем нужно промоделировать то, что нужно получить. И если в понимании того, чего нужно достичь есть пробелы, то никакое отстранение от проблемы и попытка дать ей устоятся в фоновом режиме не помогут. Следующий этап наиболее сложный нужно составить план перехода от того что есть, к тому что нужно получить. (Вообще данный процесс хорошо описан в книге про деревья решений Голдреда). На этом этапе нужно определить перечень проблем и конфликтов. И вот уже с этим списком можно брать паузу на подумать. Есть много имперических методов разрешения противоречий (от подбора паттернов до мозгового штурма), но наиболее формализованный подход можно найти в теории решения изобретательских задач. Такой подход более системный, чем описанные в статье лайфхаки, которые ценны как отдельные советы, но слишком многое в них остается на уровне подсознания, так что без соответствующего опыта просто не сработает у большинства джунов.
Далеко не каждая компания имеет в своем распоряжении модели, специально спроектированные или подготовленные для свободного обмена, а если такие модели и есть, то как правило требуют верификации на предмет актуальности. Слишком слабо в РФ распространены PDM системы, слишком мало компаний готовых вкладывать деньги в качественную интеграцию с неопределённым кругом мелких покупателей. Если вы производите "закрылки для космолетов" зачем вам это, если их и купят кто-то не из "Роскосмоса" то погоду это явно вам не сделает. А хорошую модель для интеграции нужно готовить, нужно понимать, как она будет отображается в различных CAD системах, а в идеале и тестировать ее в каждой из них? Следить опять-же за ее актуальностью при изменении КД и техпроцессов. Да что там говорить, даже загружая модель из импортных каталогов ведущих мировых производителей, порой приходится прогонять ее через инструментарий восстановления моделей одной или нескольких САД систем, иначе рискуем получить на чертежах непредсказуемые кривые, разрывы геометрии и пустотелые детали в разрезах.
Если говорить о пороге входа в отрасль, то нужен комплексный сервис, который будет решать проблемы поставщиков. Возможность опубликовать свою модель, для свободного доступа - это совсем не то же самое, что привлечение новых заказчиков и здесь большая часть отводится на маркетинговую работу, чем на сами технические возможности платформы. Само по себе наличие платформы, не решит имеющихся у производителей проблем.
По крупным производителям как правило есть специфика: Литьевые детали из пластмасс, изделия механообработки, пневмомеханизмы, метизы - разные характеристики и подходы к классификации, разные виды 3d моделей от формата файла, до способа 3д моделирования (поверхностное, твердотельное, механизмы и т.п.) Грамотно построить систему каталога хоть и решаемая, но далеко - не тривиальная задача.
По практике публикации каталогов: если каталоги у производителя уже есть хоть в каком-то виде, то есть определённый набор характеристик, есть формат файлов (картинок и моделей), есть критерии поиска и навигации. И производитель не заинтересован без веских основании, напрягаться, чтобы поддерживать и свой и еще какой то формат каталога.
В конце концов вопрос сводится к чему-то вроде: Сколько новых заказов принесёт размещение продукции на новой интернет площадке и сколько это займёт в трудочасах?
Если говорить про обмен инженерными данными, то как правило они являются интеллектуальной собственностью контрагента и обмен ими через какие либо незащищённые каналы чреват добровольному сливу своих конкурентных преимуществ. Что же касается сборки 3д модели из готовых элементов то это звучит слишком утопично. Насколько просто собрать автомобиль из разносортных деталей от сотни различных моделей? Это не лего, где все детали стандартизированы и как пазлики подходят друг к другу. Даже в мебельном производстве довольно сложно будет собрать шкаф из деталей от различных производителей. Если же речь о комплектующих, то более менее серьезные производители имеют собственные каталоги с документацией, 3д моделями и артикулами, необходимыми для заказа. Какое преимущество сподвигнет их нести затраты на перенос этих катологов в бесплатную базу, не учитывающую их специфику и сложившиеся бизнес практики?
Отличная статья для тех, кто только входит в эту непростую специальность. Из советов джуну добавил бы следующее: не доверяй своей памяти - она работает через призму имеющихся у тебя знаний. Записывай все, в блокнот на видео, пересматривай и ищи что пропустил. Очень часто оказывается, что ты понял кого - то с точностью до наоборот, только по тому , что человек в теме сто лет, а ты сам имеешь совсем далекое от реальности представление. Аналитик должен быть готов признавать свои ошибки и менять точку зрения, смотря на задачу глазами каждой из заинтересованных сторон. В этом помогают записи. Следующий необходимый скил - умение задавать вопросы, до тех пор пока не получишь удовлетворяющий тебя ответ. Не понял - уточняй. Думаешь, что понял - повтори то что ты понял тому кого ты спрашивал и получи подиверждение. Фраза "Правильно ли я понимаю, что ... " И далее по теме должна стать второй натурой. Третье - люди не понимают друг друга и не могут договорится, даже если сидят в одном кабинете за соседними столами. Не тешь себя иллюзией - тебе придется налаживать коммуникации между всеми участниками и доносить до членов команды не просто сообщения а их смысл. 90 процентов всех проблем в проекте - проблемы коммуникаций. И еще, хороший аналитик на самом деле очень разносторонний дилетант. Если тебе нравится узнавать что то новое и решать проблемы из серии как скрестить ужа с ежом, то профессия тебе зайдет.
Тут ведь нет ничего нового, все та же дилема как писать меньше кода и получить меньше ошибок в рантайме. Хорошо бы свалить все на компилятор, чтобы ошибок в принципе не возникало- добро пожаловать в Haskell, с его "маниакальной" строгой типизацией. Для языков с динамической типизацией тоже есть свои библиотеки описания и проверки типов. И если надоело, что код то и дело падает в рантайме, то без строгого контроля за типами данных не обойтись. Только ведь вот какое дело, работы это только добавит. Тут все как в поговорке: "семь раз отмерь ....".
Приобретение знания самостоятельно - один скил (Самоучка). Умение решать несвойственные и неинтересные задачи - другой (Вуз с его системой дисциплин). А дальше вопрос, насколько вы углубляетесь в свою стезю и сколько вам приходится заниматся тем, что не интересно. И еще. Вузовское образование принудительно расширяет кругозор, закладывая основы. Самоучка выбирает и исследует то что интересно. И у того и у другого есть пробелы в областях компетенций, в которые они не полезут за поиском решения, так как даже не подозревают о такой возможности. Хорошо если есть тот кто может охватить необъятное и указать конкурирующие варианты решения. Резюме. Как бы вы не учились отдуваться руководителю проекта :)
Как то одна из сотрудниц заявила мне, что монитор её не любит и выключается как только она подходит к нему. Помню свой шок когда убедился в этом воочию. Как только женшина подходила к своему большому ЭЛТ монитору он тут же выключался, когда отходила - включался. На меня и других сотрудников монитор так не реагировал. Прозрение наступило, когда я случайно коснулся сотрудницы и меня шибануло статическим разрядом. На женщине была синтетическая кофта и со временем на ней скапливался такой заряд, что при ее приближении срабатывала защитная автоматика внутри монитора, отключающая вывод изображения.
Решение чистой задачи очень сложно корректно оценить, так как не будет практической апробации решения, и критериев его приёмки. Слишком много будет допущений если задача будет чисто теоретическая, а для решения практической задачи, нужен плотный диалог и погружение в проблему и среду (это только Шерлок Холмс разгадывал преступления играя дома на скрипке)
Задача расследования..... вот в этом то и отличие ТРИЗ - это комплексная методология, позволяющая диагностировать проблему, и затем решить её. По этому и некорректно сравнивать ТРИЗ с методом отрицаний.
А вообще ТРИЗ хорошо дополняет методологию Деревьев поиска решений из Теории Ограничений Систем Э.Голдратта.
В общем я глубоко за то, что изучать нужно различные инструменты и учится применять их эффективно. И чем больше знаний в данной области, тем эффективнее используемые инструменты.
И еще то что сразу бросается в глаза:
"Нужно больше информации про сам технологический процесс. И подробное его описание его деталей. Какой металл. Какие подробности работы станка. " Это хорошо, вопросы правильные, они расширяют поле решение проблемы, но они случайные, большая их часть мало относится к проблеме. Это очень похоже на метод перебора. Попробовали то, это, пятое, десятое..... Триз же сконентрирован на другом подходе - ключевое это выделение проблемы. В процессе со станком режущем профили - проблема описана отклонение линейных размеров отверстий. Переход от исследовательской задачи к изобретательской чрезвычайно прост. От чего зависит положение отверстий? - от начальной точки отсчёта координат (так называемой технологической базы). Далее опредеяем, что нужно сделать, чтобы технологическая база устанавливалась неверно и раскручиваем цепочку рассуждений далее.... Вобщем мы целенаправленно ищем место возникновения проблемы, а не пытаемся расшевелить воображение, чтобы случайным образом угадать выигрышный вариант. В конце мы придем к четкому техническому противоречию, и уже потом будем искать способ его устранения. В этом и суть изобретения, не придумать как решить, а найти именно ту задачу, которую действительно нужно решать.
Поиск проблемы на практике, гораздо важнее, чем варианты ее решения, так как решая не ту проблему даже очень эффективно - результат можем получить весьма посредственный.
Как и в программировании, как и в фотографии. Да практически вокруг любых курсов такая история.
Согласен, условие задачи описано не полно, хотя это похоже на то, что в жизни. Правильно поставленная задача, это уже 90 процентов решения.
Интересный момент, я тоже прикидывал решение по ТРИЗ исходя из описания. ИКР в первом приближении получился такой: Банер в геолокационной точке есть, банера в геолокационной точке нет. Ну и так как мне сильно импонирует вепольный анализ, я наплевав на АРИЗ сразу прошелся по полям. Электромагнитное поле, сразу натолкнуло на идею с лазером. Можно было бы закрепить на сосне , обеспечить аккумулятор возможно солнечные батареи и проецировать на полотно дороги, но оставались проблемы с безопасностью и с дневной видимостью.
Еще была идея с рекламой в навигаторе, с геопривязкой, как раз для проезжающих мимо, или в онлайн картах. Из той же серии банер есть - банера нет.
С аэростатом идея хороша, при условии, хотя для регулирующих органов вроде как и полет авиамодели на торосе, это все равно полет со всеми вытекающими.
Метод отрицаний будет сильно зависеть от того, как мы изначально опишем задачу. Вот я сформулировал, что грузовик уперся, вы что у него слишком большая высота, а кто то скажет что у моста высота слишком маленькая. Фокус отрицания будет смещаться в зависимости от формулировки. Решение будет в каком то роде случайным, ТРИЗ направлен на четкую идентификацию проблемы и более системный подбор решений.
Вот еще кейс из жизни. На одном производстве регулярно случался брак деталей. Алюминиевые профили срезались под углом 45 градусов затем доставлялись на станок где в них сверлились отверстия и делались пазы. Периодически отверстия оказывались смещёнными на 1-2 мм. И здесь первоочередная задача выявить проблему (т.е. превратить исследовательскую задачу в изобретательскую), и только потом генерировать решения. Опять же в моей формулировке уже есть решение, поскольку я знаю ответ.
В оригинале формулировка выглядела так: На станке таком-то переодически возникает брак из за отклонения линейных допусков при сверлении отверстий в алюминиевых профилях.
Спойлер, проблема оказалась в транспортировочной тележке и производственной культуре, а решение в изменении технологического процесса изготовления детали.
Это, что называется простой случай, а есть в производстве случаи, корень проблемы которых выходит далеко за пределы формулировки задачи.
Вот такой например, детали из одного и того же листа металла режутся на лазере и затем поступают на гибочный станок. Детали одинаковые (в оригинале вообще то разной формы были), но после гибки на станке, часть деталей имеет отклонения линейных размеров, от назначенных допусков. Допуски менять нельзя, нужно разобраться почему часть деталей получаются бракованными. По ходу разбирательства выясняем, что температурные улсовия, управляющая программа, партия и даже конкретный лист материала, применяемые пуансоны все одинаковое.
Есть еще интересный вариант использования аналога метода отрицаний для поиска проблем в бизнесе. Вот кейс, наши велосипеды плохо продаются. Как поднять продажи? Фишка человеческой психики в том, что мы склонны придерживатся одной-двух успешных стратегий, и одновременно легко имеем в мозгу с десяток неуспешных. Эволюционно, выживали в основном тет кто не рисковал. По этому нам проще ответить на вопрос, чего не нужно делать? Итак переформулировал вопрос кейса, что нужно делать, чтобы продажи велосипедов упали? Вариантов море, теперь смотрим, какие проблемы нам наиболее близки и работаем с ними.
Метод отрицаний это метод генерации идей, ТРИЗ же заточен на решение проблемы. Так в чем тогда соревнование? В инструментарии триз есть раздел РТВ развитие творческого воображения, в том числе и метод отрицаний, как часть методологии. Даже в АРИЗ 85 есть шаг "Сделай наоборот". Просто в ТРИЗ много всего и нужно разбираться и учится применять, а метод отрицаний это единичный прием, который проще для осознания и применения. Известная в ТРИЗ задача, грузовик застрял под мостом уперевшись крышей в верхний свод моста. Как его вытащить? Метод отрицаний тут мало полезен. Не грузовик, не застрял, не уперся, не в свод, не моста. Из всего этого мы можем работать только с не уперся, очень сложно от этого перейти к формулировке основной проблемы, и вариантам решения. Да можно понять, что грузовик перестанет упираться, когда его крыша перестанет касаться свода моста, и отсюда уже понять что нужно уменьшить высоту грузовика.. В триз же мы будем сконцентрированы на поиске основного технического противоречия сформулировав его как: зазор есть-зазора нет. Ну и как следствие, доя увеличения зазора нужно уменьшить высоту. Это если речь про решение задач данными методами. Ну а если речь про пофантазировать и найти варианты, то приемов очень много, метод отрицаний не единственный рабочий. Взять те же войлочные стельки: если не войлочные то какие? Резиновые, паролоновые и т.п - метод отрицаний провоцирует на простой перебор материалов. Морфологический анализ, позволяет выйти за эти рамки: можно менять, материал, свойства (цвет, коэффициент упругости,память формы), агрегатное состояние(газовые, жидкостные), работать с полями(добавляя тепловые, магнитные, электрические). Вобщем много всего. И не нужно путать ТРИЗ (книга Альтшуллера, с изложением основ теории доступна бесплатно) и курсы, на которых учат ТРИЗ пользоваться. Мы же хорошо знаем, что не все йогурты одинаково полезны
Вот несколько кейсов для ChatGpt из моей практики: 1.,Напиши API в формате OpenApi. Далее описание требований к методам и форматам данных. 2. Создай описание в формате PlantUml диаграммы последовательности для следующего процесса: далее описание процесса. 3. Создай описание в формате plantuml для er-диаграммы для следующей модели данных. 4. Создай в формате yaml описание для следующей модели данных. 5. Напиши регулярное выражение для преобразования строки1 в строка2. 6. Опиши технические требования к .... может подать пару свежих идей.
Сразу оговорюсь я не программист, а бизнес аналитик. Да и мой комментарий скорее к коментам выше, чем к самой статье. Но мне как не программисту не вполне понятно, для чего программисты сначала создают себе проблемы, а потом героически их решают. Каждый год создаются новые библиотеки, фреймворки, языки программирования, но сама разработка не становится проще. Замыкание прекрасная концепция из функционального если не ошибаюсь программирования, но когда ее применяют для неявной модификации стейта, что способно взорвать мозг при последующей отладке, то в голове только один вопрос - зачем? Действительно хотелось бы видеть в статье адекватные примеры реализации. Скажем не просто счетчик, но и объяснение, почему другим образом его реализовывать не эффективно. Мне кажется такое объяснение позволит избежать применения той или иной технологии не к месту и не по назначению.
Что так сложно то, типы мышления и т.п. Вопрос то простой будет ли меняться поведение функции возвращающей значение или нет? Хорошая практика при написании любого кода определится с типами данных и их жизненным циклом. Разбить яйцо можно множеством способов, но не все из них подойдут для приготовления яичницы. Вот и вся разница в мышлении. P.S. изучение языков функционального программирования очень сильно прокачивает скил проектирования архитектуры кода на любом языке программирования. Вот там вот как раз и реализуется возможность пощупать другой тип мышления, даже не ради того чтобы на них программировать, а просто ради того, чтобы иметь возможность смотреть на свой код несколько шире чем привык.
Главная ценность аналитика, это широкий взгляд на проблемы бизнеса и проблемы ит-решений. Разделение ролей, на БА и СА это либо следствие дисбаланса компетенций аналитика, либо распределение аналитической нагрузки в большой команде. Аналитик не может и не должен в совершенстве владеть техническими скилами, или компетенциями бизнеса: для этого есть соответствующие профессионалы, задача аналитика выстроить эффективные коммуникации между бизнесом и ит. Сила аналитика, в умении находить решения выходящие за границы компетенции узкоспециализированых профессионалов. Аналитик нужен тогда, когда ИТ не может реализовать требования бизнеса, а бизнес не может адаптировать свои процессы под структуру ит. Вот оно поле боя аналитика, который может и бизнесу процесс подправить, и ит решение подходящее подобрать, которое поможет не наступить на грабли. И для бизнеса и для ИТ такие шаги порой кажутся радикальными (а что так можно было?)? Аналитики, часто выступают как таран для пролома жестких ограничений решаемой задачи. Ну а если разделять функции ба и са, то по сути получим недобизнес и недоразработчика которые вполне себе могут и недоговорится. Так что деление на СА и БА, имеет смысл либр внутри хорошо слаженой команды аналитиков доя распределения нагрузки, либо в тех случаях когда часть функций аналитика успешно взваливает на себя бизнес или ИТ.
Был не прав. Система у Вавилонян была позиционной - это сильно упрощает расчёты. Судя по источникам -изначально не было понятия 0, что вносило некоторую неоднозначность в цифровую запись. А вот известны ли были приёмы деления и умножения в столбик - я пока упоминаний не нашёл.
Не забывайте, что четыре тысячи лет назад не было позиционной системы счисления и сама система была 60ричная. Так что даже умножение было не тривиальной задачей.
Прокрастинация обычно тесно связана с неопределенностью.Когда нет четкого понимания задачи - появляются сомнения, беспокойство и жгучее желание отложить принятие трудных решений на потом. Чтобы снять неопределенность нужно : Описать исходное состояние как есть. Хорошо подойдут для этого средства графического моделирования. В приведенном примере, схема исходной базы данных. Здесь мы устраним первый род неопределенности: то что нам дано. Затем нужно промоделировать то, что нужно получить. И если в понимании того, чего нужно достичь есть пробелы, то никакое отстранение от проблемы и попытка дать ей устоятся в фоновом режиме не помогут. Следующий этап наиболее сложный нужно составить план перехода от того что есть, к тому что нужно получить. (Вообще данный процесс хорошо описан в книге про деревья решений Голдреда). На этом этапе нужно определить перечень проблем и конфликтов. И вот уже с этим списком можно брать паузу на подумать. Есть много имперических методов разрешения противоречий (от подбора паттернов до мозгового штурма), но наиболее формализованный подход можно найти в теории решения изобретательских задач. Такой подход более системный, чем описанные в статье лайфхаки, которые ценны как отдельные советы, но слишком многое в них остается на уровне подсознания, так что без соответствующего опыта просто не сработает у большинства джунов.
Далеко не каждая компания имеет в своем распоряжении модели, специально спроектированные или подготовленные для свободного обмена, а если такие модели и есть, то как правило требуют верификации на предмет актуальности. Слишком слабо в РФ распространены PDM системы, слишком мало компаний готовых вкладывать деньги в качественную интеграцию с неопределённым кругом мелких покупателей. Если вы производите "закрылки для космолетов" зачем вам это, если их и купят кто-то не из "Роскосмоса" то погоду это явно вам не сделает. А хорошую модель для интеграции нужно готовить, нужно понимать, как она будет отображается в различных CAD системах, а в идеале и тестировать ее в каждой из них? Следить опять-же за ее актуальностью при изменении КД и техпроцессов. Да что там говорить, даже загружая модель из импортных каталогов ведущих мировых производителей, порой приходится прогонять ее через инструментарий восстановления моделей одной или нескольких САД систем, иначе рискуем получить на чертежах непредсказуемые кривые, разрывы геометрии и пустотелые детали в разрезах.
Если говорить о пороге входа в отрасль, то нужен комплексный сервис, который будет решать проблемы поставщиков. Возможность опубликовать свою модель, для свободного доступа - это совсем не то же самое, что привлечение новых заказчиков и здесь большая часть отводится на маркетинговую работу, чем на сами технические возможности платформы. Само по себе наличие платформы, не решит имеющихся у производителей проблем.
По крупным производителям как правило есть специфика: Литьевые детали из пластмасс, изделия механообработки, пневмомеханизмы, метизы - разные характеристики и подходы к классификации, разные виды 3d моделей от формата файла, до способа 3д моделирования (поверхностное, твердотельное, механизмы и т.п.) Грамотно построить систему каталога хоть и решаемая, но далеко - не тривиальная задача.
По практике публикации каталогов: если каталоги у производителя уже есть хоть в каком-то виде, то есть определённый набор характеристик, есть формат файлов (картинок и моделей), есть критерии поиска и навигации. И производитель не заинтересован без веских основании, напрягаться, чтобы поддерживать и свой и еще какой то формат каталога.
В конце концов вопрос сводится к чему-то вроде: Сколько новых заказов принесёт размещение продукции на новой интернет площадке и сколько это займёт в трудочасах?
Если говорить про обмен инженерными данными, то как правило они являются интеллектуальной собственностью контрагента и обмен ими через какие либо незащищённые каналы чреват добровольному сливу своих конкурентных преимуществ. Что же касается сборки 3д модели из готовых элементов то это звучит слишком утопично. Насколько просто собрать автомобиль из разносортных деталей от сотни различных моделей? Это не лего, где все детали стандартизированы и как пазлики подходят друг к другу. Даже в мебельном производстве довольно сложно будет собрать шкаф из деталей от различных производителей. Если же речь о комплектующих, то более менее серьезные производители имеют собственные каталоги с документацией, 3д моделями и артикулами, необходимыми для заказа. Какое преимущество сподвигнет их нести затраты на перенос этих катологов в бесплатную базу, не учитывающую их специфику и сложившиеся бизнес практики?
Отличная статья для тех, кто только входит в эту непростую специальность. Из советов джуну добавил бы следующее: не доверяй своей памяти - она работает через призму имеющихся у тебя знаний. Записывай все, в блокнот на видео, пересматривай и ищи что пропустил. Очень часто оказывается, что ты понял кого - то с точностью до наоборот, только по тому , что человек в теме сто лет, а ты сам имеешь совсем далекое от реальности представление. Аналитик должен быть готов признавать свои ошибки и менять точку зрения, смотря на задачу глазами каждой из заинтересованных сторон. В этом помогают записи. Следующий необходимый скил - умение задавать вопросы, до тех пор пока не получишь удовлетворяющий тебя ответ. Не понял - уточняй. Думаешь, что понял - повтори то что ты понял тому кого ты спрашивал и получи подиверждение. Фраза "Правильно ли я понимаю, что ... " И далее по теме должна стать второй натурой. Третье - люди не понимают друг друга и не могут договорится, даже если сидят в одном кабинете за соседними столами. Не тешь себя иллюзией - тебе придется налаживать коммуникации между всеми участниками и доносить до членов команды не просто сообщения а их смысл. 90 процентов всех проблем в проекте - проблемы коммуникаций. И еще, хороший аналитик на самом деле очень разносторонний дилетант. Если тебе нравится узнавать что то новое и решать проблемы из серии как скрестить ужа с ежом, то профессия тебе зайдет.
Тут ведь нет ничего нового, все та же дилема как писать меньше кода и получить меньше ошибок в рантайме. Хорошо бы свалить все на компилятор, чтобы ошибок в принципе не возникало- добро пожаловать в Haskell, с его "маниакальной" строгой типизацией. Для языков с динамической типизацией тоже есть свои библиотеки описания и проверки типов. И если надоело, что код то и дело падает в рантайме, то без строгого контроля за типами данных не обойтись. Только ведь вот какое дело, работы это только добавит. Тут все как в поговорке: "семь раз отмерь ....".
Приобретение знания самостоятельно - один скил (Самоучка). Умение решать несвойственные и неинтересные задачи - другой (Вуз с его системой дисциплин). А дальше вопрос, насколько вы углубляетесь в свою стезю и сколько вам приходится заниматся тем, что не интересно. И еще. Вузовское образование принудительно расширяет кругозор, закладывая основы. Самоучка выбирает и исследует то что интересно. И у того и у другого есть пробелы в областях компетенций, в которые они не полезут за поиском решения, так как даже не подозревают о такой возможности. Хорошо если есть тот кто может охватить необъятное и указать конкурирующие варианты решения. Резюме. Как бы вы не учились отдуваться руководителю проекта :)