Автор не указал размер бизнеса и его профиль. Без них эту статью читать и обсуждать бессмысленно.
Если речь идёт об оптимизации затрат на ИТ в лавчонке из трёх эникейщиков - то это может иметь какой-то смысл. Но только в случае, если эти эникейщики изначально тупанули и зачем-то купили себе каналы по тарифам для крупного бизнеса.
Если мы говорим про компанию с сотнями или тысячами сотрудников, где цена отказа или потери бэкапа многократно превышает переплату за "неиспользуемые гигабайты" - то это глупо обсуждать. Бизнес скорее купит второй резервный канал за полную стоимость, чем будет экономить копейки на первом
Такие статьи надо авторским правом защищать и продавать, как консалтинговое решение. Потому что все, кто внедряет подобные решения, проходят через аналогичные проблемы. И не всегда вендор ЭДО предусматривает их решение в своем продукте - и крайне грустно становится, когда, купив и развернув систему за десятки миллионов, обнаруживаешь, что в ней какую-то абсолютную, но критичную, мелочь нельзя настроить - и приходится сбоку городить костыль ещё за эти же десятки миллионов. Потому вовремя не сделан аудит 😬
Юзабилити привязано к пользовательскому сценарию. Нельзя пускать бухгалтера в админку сапа. Для бухгалтера надо делать экран, удобный ему. И нельзя пускать маркетолога в экран бухгалтера - там будут сотни статей и внутренних счетов, понятных и удобных бухгалтеру, нужных ему постоянно. А маркетологу нужно три поля для заведения РО и кнопочка аппрувала.
А если вы делаете одну базу, в которой все сотрудники и РО заводят, и аккруалы считают и бюджет планируют - то конечно будет каша. Но это проблема не разработки интерфейса, а понимания того, как системой будут пользоваться реальные люди.
А что, если интеллекта вообще не существует? И мышление - это просто хаотичное суммирование хаотичных сигналов, которое по центральной предельной теореме, рано или поздно приведет к какому-то выбросу, который мы и считаем решением?
Вспомните, как работает тот же Stable Diffusion. Он же не рисует котика там, ножки, ручки или титьки. Вместо этого он берет просто белый шум и смотрит на него и видит в нем на 12% титьки (т.к. до этого посмотрел на тысячу картинок с титьками и сформировал миллиард рандомных цифирок в модели, которые вовсе ничего не значат). Дальше он просто решает диффур для уменьшения шума и смотрит ещё раз - теперь похоже титьки на 16%. И т.п.
Но он при этом не думает, не принимает каких-то там осмысленных решений. Он просто сложным и случайным образом тасует пиксели - но на выходе получается вполне осмысленная, на наш взгляд, картинка.
Может и в мозгу так же? И нет смысла искать источник интеллекта в неокортексе, гиппокампе или там в черной субстанции - это всё просто те или иные наборы нейронов, выполняющие какие-то сугубо технические функции, которые лишь в случайной сумме дают результат, который мы привыкли считать осмысленным.
А что, если интеллекта вообще не существует? И мышление - это просто хаотичное суммирование хаотичных сигналов, которое по центральной предельной теореме, рано или поздно приведет к какому-то выбросу, который мы и считаем решением?
Вспомните, как работает тот же Stable Diffusion. Он же не рисует котика там, ножки, ручки или титьки. Вместо этого он берет просто белый шум и смотрит на него и видит в нем на 12% титьки (т.к. до этого посмотрел на тысячу картинок с титьками и сформировал миллиард рандомных цифирок в модели, которые вовсе ничего не значат). Дальше он просто решает диффур для уменьшения шума и смотрит ещё раз - теперь похоже титьки на 16%. И т.п.
Но он при этом не думает, не принимает каких-то там осмысленных решений. Он просто сложным и случайным образом тасует пиксели - но на выходе получается вполне осмысленная, на наш взгляд, картинка.
Может и в мозгу так же? И нет смысла искать источник интеллекта в неокортексе, гиппокампе или там в черной субстанции - это всё просто те или иные наборы нейронов, выполняющие какие-то сугубо технические функции, которые лишь в случайной сумме дают результат, который мы привыкли считать осмысленным.
Когда-то давно услышал у кого-то из крупных банков термин "опер.день“ - операционный день, по закрытию которого все транзакции сливаются в DWH и она пересчитывается за ночь, чтобы утром все могли работать с новыми данными.
Понятное дело, что для ИТ этот момент был самым чудовищно нервным.
Поэтому с моей лёгкой руки термин "опердень" вошёл в традиционную практику наших датаварехаусников. Когда утром ни у кого ничего не грузится из-за того, что ночью что-то грохнулось и хранилище пересчитывается заново. Произошел опердень 😁
Это придумали на Реддите семь лет назад. Позволили любому человеку поставить на картинке один любой пиксель. Погуглите, это очень интересная история, как люди объединялись в партии по тысячи человек и боролись друг с другом.
Вот есть полный видос того, как менялась картинка на протяжении всей жизни проекта:
Замените в вашей статье слово "электроника" на слова "медицина", "педагогика", "пищевая промышленность", "станкостроение", "фармакология" - и ничего не изменится.
В нашей стране давно нет ни образования, ни науки, ни каких-то самостоятельных, коммерчески успешных отраслей.
Есть или штучные гении, которые рано или поздно всё равно уедут - или какие-то идеалисты, работающие за копейки...которые или тоже уедут - или ничего ценного, в одиночку, привнести не смогут.
К сожалению, похоже, с этим придется смириться. Вернее, в современном мире, по-другому и не получится - пока есть возможность купить что-то в Китае, то оно будет покупаться в Китае и не будет смысла не покупать это в Китае. А значит вам придется заниматься чем-то другим - например, добавлять добавленную стоимость китайским компонентам. Это вполне себе отличное дело. Эппл вон тоже свои айфоны вовсе не в Америке производит.
Так что выход есть - просто он не такой, как вы его себе представляете.
Эх, молодежь ;-) Вообще-то в самых первых языках программирования, начиная с фортрана, было именно "**". Символ "^" стап использоваться заметно позже, и до сих пор уступает варианту "**" по количеству выбравших его "языков" (статья там длинная, см. подраздел "В языках программирования"):
Эх, молодежь! 😁
Вапще-то эти символы одновременно появились - в Фортране и Алголе. Но Фортран был разработан IBM и использовал символы их клавиатуры - поэтому там был **.
А Алгол разработали в Швейцарии научным консорциумом - и там в качестве возведения в степень использовали стрелочку ↑. И у них из-за этого даже был конфликт с IBM, когда учёные его просили включить Алгол в их системы OS/2, потому что на клаве их компа не хватало символов для Алгола. Поэтому Америка осталась на айбиэмовском Фортране, а в Европе больше стал распространен Алгол.
Дальше уже дядя Кнут подобрал эту стрелочку и придумал из неё гипероператоры, типа тетрации. И те, кто читали Кнута, стали юзать стрелочки в степенях. А те, кто не читали - звёздочки 😁
Эх, молодежь ;-) Вообще-то в самых первых языках программирования, начиная с фортрана, было именно "**". Символ "^" стап использоваться заметно позже, и до сих пор уступает варианту "**" по количеству выбравших его "языков" (статья там длинная, см. подраздел "В языках программирования"):
Эх, молодежь! 😁
Вапще-то эти символы одновременно появились - в Фортране и Алголе. Но Фортран был разработан IBM и использовал символы их клавиатуры - поэтому там был **.
А Алгол разработали в Швейцарии научным консорциумом - и там в качестве возведения в степень использовали стрелочку ↑. И у них из-за этого даже был конфликт с IBM, когда учёные его просили включить Алгол в их системы OS/2, потому что на клаве их компа не хватало символов для Алгола. Поэтому Америка осталась на айбиэмовском Фортране, а в Европе больше стал распространен Алгол.
Дальше уже дядя Кнут подобрал эту стрелочку и придумал из неё гипероператоры, типа тетрации. И те, кто читали Кнута, стали юзать стрелочки в степенях. А те, кто не читали - звёздочки 😁
Так что для меня вопрос како ПО более сложное, написаное на фремворках алфавитным язком СРМ или ПО для управления ядерным реактором с турбиной.
Вы всё время аппелируете к абстрактным категориям, типа сложности или чувства прекрасного 😀 Но красота и сложнота - они исключительно в глазах смотрящего.
Вам вот, наверное, китайские иероглифы тоже кажутся жутко сложными - а меж тем ими прекрасно пользуются полтора миллиарда человек, которые, в основной массе, значительно моложе и глупее вас. Но для любого китайца будет пыткой попытка переложить его жуткие иероглифы на прекрасные и понятные буквы, которыми пользуется весь мир. И для всех это будет пыткой - просто потому, что китайский язык органически приспособлен к иероглифам, а не к буквами.
И потому никто до сих пор и не смог внятно записывать китайский язык латинскими буквами. Да, есть субституты, решающие узкой задачи - для облегчения быстрого взаимодействия с европейцами или компьютерами. То есть для локальной оптимизации. Но никто не пишет книги на таких субститутах. Вернее даже и пишут - но это, скорее, proof-of-concept или шедевр для тех, кто шарит - но не для всех.
Сложное - это то, чего ты не знаешь. Но для того, кто знает, оно будет простым.
Я вот не увидел ни грамма сложности в ваших схемах ПИДов. Они ОБЪЕКТИВНО НЕ СЛОЖНЫЕ - несколько однотипных блоков, простые операции да соединения. Пройтись по ним с карандашиком и прикинуть логику работы сможет и школьник. Но при этом я совершенно не могу найти в них потенциальные ошибки: например - бесконечные циклы без выхода или блоки, которые никогда не сработают. Такие вещи МНЕ ЛИЧНО гораздо быстрее и понятнее было бы искать в текстовом коде. Но вам, возможно, наоборот они виднее именно в таком виде - потому что вы привыкли читать такие диаграммы и анализировать их.
То есть каждому будет простым то, что он знает. Я на ассемблере могу читать быстрее, чем на родном языке. Но какой-нибудь там Лисп или Эрланг заставят мой глаз дергаться. Ваши картинки напугают беременную женщину или студента SkillFactory - но тот, кто хоть раз в жизни пробовал починить советский телевизор по схеме, будут надменнно над ними насмехаться.
И кстати - сложность схемы вовсе не говорит о её крутости, важности и применимости исключительно для АЭС и космических кораблей.
Наоборот - сложные схемы тяжело отлаживать и проверять на ошибки. Погуглите 10 принципов разработки mission-critical систем от NASA, которые они придумали ровно для того, чтобы строить и отлаживать максимально критичные и важные системы. Так вот эти принципы как раз про максимальное упрощение - никаких сложных потоковых конструкций, четкие границы блоков, один функциональный модуль на одну страницу и т.п.
Ровно для того, чтобы инженеры, с тонким чувством прекрасного и причастности к великому не нагромождали одним им понятную красоту, которая взорвется при первом же старте из-за того, что две стрелочки перепутались местами 😀
В отличии от алфавитных языков улучшение графической программы требует не соблюдения от разработчика набора жестких рекомендаций и правил, а скорее наличия чувства прекрасного
Когда программу пишут сотни людей - и все разных возрастов, разных компетенций, разной культуры и уровня образования и даже разного языка - то невозможно гарантировать одинаковое чувство прекрасного у всех. Кроме того, то, что прекрасно для вас, будет уродливо и непонятно для других.
Именно для этого придумывают жёсткие правила и рекомендации. Потому что программу надо эффективно писать, а читать. Ине наслаждаться её красотой - а иметь возможность эффективно её модифицировать.
Графические схемы подходят для небольших линейных моделей, типа тех, которые вы показали. Попробуйте нарисовать на графической диаграмме, скажем, регулярное выражение. Или там - виртуальные конструкторы какие-нибудь. А после того, как нарисовали - попробуйте туда ещё правки вносить регулярно... Не уверен, что вы долго продержитесь 😁
Да, хорошие и удобно читаемые схемы нужны, это факт. Но они нужны там, где они подходят. Программисту проще прочитать страницу кода, чем карандашиком тыкать в блок-схемы. А вот директору по маркетингу, который хочет понимать логику работы CRM, вряд ли поможет её код - а вот схема всё объяснит.
Так что не красота спасет мир, а здравый смысл и использование правильных инструментов там, где они необходимы.
Дополнительные хотелки - это дополнительные затраты. Затраты - это снижение маржи проекта. А изменение маржи проекта - это изменение его коммерческой составляющей, которой должны заниматься люди, ответственные за коммерцию. Задача РП - держать проект в рамках маржи. А переторговывать маржу должен сейлз, аккаунт или кто он у вас там. Это совершенно другая компетенция и другой уровень полномочий, которыми РП не обладает.
Так что не путайте тёплое с мягким. Заказчик хочет много новых фич, которых не было в ТЗ? Соберите их в документ и несите на проектный комитет - и пусть коммерсы переуиверждают с заказчиком цену, сроки, скоуп и т.д. Иначе будете бесконечно работать в минус на долгосроке - из-за чего и помирает большинство молодых проектных компаний.
Отличное расписание для выгорания через пару недель следования ему 😁 человек - не робот. Расписание нужно подстраивать под индивидуальные особенности биоритмов, восприятия погоды, производительности, обмен веществ и гибкость скелетной мускулатуры. Не каждому позвоночнику дано целый день сидеть и заниматься саморазвитием - иногда боль в спине может заставить поменять самый строгий график.
Автор не указал размер бизнеса и его профиль. Без них эту статью читать и обсуждать бессмысленно.
Если речь идёт об оптимизации затрат на ИТ в лавчонке из трёх эникейщиков - то это может иметь какой-то смысл. Но только в случае, если эти эникейщики изначально тупанули и зачем-то купили себе каналы по тарифам для крупного бизнеса.
Если мы говорим про компанию с сотнями или тысячами сотрудников, где цена отказа или потери бэкапа многократно превышает переплату за "неиспользуемые гигабайты" - то это глупо обсуждать. Бизнес скорее купит второй резервный канал за полную стоимость, чем будет экономить копейки на первом
Передавайте привет Дэвиду!
Однажды у них что-то перепуталось с графиком и они, по дружбе, выступили у нас в хостеле - очень уютно пели под гитару свежую песню про любовницу 😎
Были же времена....
Браво! Уникальнейший материал!
Такие статьи надо авторским правом защищать и продавать, как консалтинговое решение. Потому что все, кто внедряет подобные решения, проходят через аналогичные проблемы. И не всегда вендор ЭДО предусматривает их решение в своем продукте - и крайне грустно становится, когда, купив и развернув систему за десятки миллионов, обнаруживаешь, что в ней какую-то абсолютную, но критичную, мелочь нельзя настроить - и приходится сбоку городить костыль ещё за эти же десятки миллионов. Потому вовремя не сделан аудит 😬
Юзабилити привязано к пользовательскому сценарию. Нельзя пускать бухгалтера в админку сапа. Для бухгалтера надо делать экран, удобный ему. И нельзя пускать маркетолога в экран бухгалтера - там будут сотни статей и внутренних счетов, понятных и удобных бухгалтеру, нужных ему постоянно. А маркетологу нужно три поля для заведения РО и кнопочка аппрувала.
А если вы делаете одну базу, в которой все сотрудники и РО заводят, и аккруалы считают и бюджет планируют - то конечно будет каша. Но это проблема не разработки интерфейса, а понимания того, как системой будут пользоваться реальные люди.
Я ваш коммент сохранил отдельно себе в заметки, спасибо!
Очень зашло, напишите пожалуйста! Ведь это именно то, что вы написали в эпиграфе "как бы я хотел, чтобы мне это рассказали ещё в универе"
А что, если интеллекта вообще не существует? И мышление - это просто хаотичное суммирование хаотичных сигналов, которое по центральной предельной теореме, рано или поздно приведет к какому-то выбросу, который мы и считаем решением?
Вспомните, как работает тот же Stable Diffusion. Он же не рисует котика там, ножки, ручки или титьки. Вместо этого он берет просто белый шум и смотрит на него и видит в нем на 12% титьки (т.к. до этого посмотрел на тысячу картинок с титьками и сформировал миллиард рандомных цифирок в модели, которые вовсе ничего не значат). Дальше он просто решает диффур для уменьшения шума и смотрит ещё раз - теперь похоже титьки на 16%. И т.п.
Но он при этом не думает, не принимает каких-то там осмысленных решений. Он просто сложным и случайным образом тасует пиксели - но на выходе получается вполне осмысленная, на наш взгляд, картинка.
Может и в мозгу так же? И нет смысла искать источник интеллекта в неокортексе, гиппокампе или там в черной субстанции - это всё просто те или иные наборы нейронов, выполняющие какие-то сугубо технические функции, которые лишь в случайной сумме дают результат, который мы привыкли считать осмысленным.
А что, если интеллекта вообще не существует? И мышление - это просто хаотичное суммирование хаотичных сигналов, которое по центральной предельной теореме, рано или поздно приведет к какому-то выбросу, который мы и считаем решением?
Вспомните, как работает тот же Stable Diffusion. Он же не рисует котика там, ножки, ручки или титьки. Вместо этого он берет просто белый шум и смотрит на него и видит в нем на 12% титьки (т.к. до этого посмотрел на тысячу картинок с титьками и сформировал миллиард рандомных цифирок в модели, которые вовсе ничего не значат). Дальше он просто решает диффур для уменьшения шума и смотрит ещё раз - теперь похоже титьки на 16%. И т.п.
Но он при этом не думает, не принимает каких-то там осмысленных решений. Он просто сложным и случайным образом тасует пиксели - но на выходе получается вполне осмысленная, на наш взгляд, картинка.
Может и в мозгу так же? И нет смысла искать источник интеллекта в неокортексе, гиппокампе или там в черной субстанции - это всё просто те или иные наборы нейронов, выполняющие какие-то сугубо технические функции, которые лишь в случайной сумме дают результат, который мы привыкли считать осмысленным.
Когда-то давно услышал у кого-то из крупных банков термин "опер.день“ - операционный день, по закрытию которого все транзакции сливаются в DWH и она пересчитывается за ночь, чтобы утром все могли работать с новыми данными.
Понятное дело, что для ИТ этот момент был самым чудовищно нервным.
Поэтому с моей лёгкой руки термин "опердень" вошёл в традиционную практику наших датаварехаусников. Когда утром ни у кого ничего не грузится из-за того, что ночью что-то грохнулось и хранилище пересчитывается заново. Произошел опердень 😁
Это придумали на Реддите семь лет назад. Позволили любому человеку поставить на картинке один любой пиксель. Погуглите, это очень интересная история, как люди объединялись в партии по тысячи человек и боролись друг с другом.
Вот есть полный видос того, как менялась картинка на протяжении всей жизни проекта:
One pixel at time
Замените в вашей статье слово "электроника" на слова "медицина", "педагогика", "пищевая промышленность", "станкостроение", "фармакология" - и ничего не изменится.
В нашей стране давно нет ни образования, ни науки, ни каких-то самостоятельных, коммерчески успешных отраслей.
Есть или штучные гении, которые рано или поздно всё равно уедут - или какие-то идеалисты, работающие за копейки...которые или тоже уедут - или ничего ценного, в одиночку, привнести не смогут.
К сожалению, похоже, с этим придется смириться. Вернее, в современном мире, по-другому и не получится - пока есть возможность купить что-то в Китае, то оно будет покупаться в Китае и не будет смысла не покупать это в Китае. А значит вам придется заниматься чем-то другим - например, добавлять добавленную стоимость китайским компонентам. Это вполне себе отличное дело. Эппл вон тоже свои айфоны вовсе не в Америке производит.
Так что выход есть - просто он не такой, как вы его себе представляете.
Эх, молодежь! 😁
Вапще-то эти символы одновременно появились - в Фортране и Алголе. Но Фортран был разработан IBM и использовал символы их клавиатуры - поэтому там был **.
А Алгол разработали в Швейцарии научным консорциумом - и там в качестве возведения в степень использовали стрелочку ↑. И у них из-за этого даже был конфликт с IBM, когда учёные его просили включить Алгол в их системы OS/2, потому что на клаве их компа не хватало символов для Алгола. Поэтому Америка осталась на айбиэмовском Фортране, а в Европе больше стал распространен Алгол.
Дальше уже дядя Кнут подобрал эту стрелочку и придумал из неё гипероператоры, типа тетрации. И те, кто читали Кнута, стали юзать стрелочки в степенях. А те, кто не читали - звёздочки 😁
Эх, молодежь! 😁
Вапще-то эти символы одновременно появились - в Фортране и Алголе. Но Фортран был разработан IBM и использовал символы их клавиатуры - поэтому там был **.
А Алгол разработали в Швейцарии научным консорциумом - и там в качестве возведения в степень использовали стрелочку ↑. И у них из-за этого даже был конфликт с IBM, когда учёные его просили включить Алгол в их системы OS/2, потому что на клаве их компа не хватало символов для Алгола. Поэтому Америка осталась на айбиэмовском Фортране, а в Европе больше стал распространен Алгол.
Дальше уже дядя Кнут подобрал эту стрелочку и придумал из неё гипероператоры, типа тетрации. И те, кто читали Кнута, стали юзать стрелочки в степенях. А те, кто не читали - звёздочки 😁
Вы всё время аппелируете к абстрактным категориям, типа сложности или чувства прекрасного 😀 Но красота и сложнота - они исключительно в глазах смотрящего.
Вам вот, наверное, китайские иероглифы тоже кажутся жутко сложными - а меж тем ими прекрасно пользуются полтора миллиарда человек, которые, в основной массе, значительно моложе и глупее вас. Но для любого китайца будет пыткой попытка переложить его жуткие иероглифы на прекрасные и понятные буквы, которыми пользуется весь мир. И для всех это будет пыткой - просто потому, что китайский язык органически приспособлен к иероглифам, а не к буквами.
И потому никто до сих пор и не смог внятно записывать китайский язык латинскими буквами. Да, есть субституты, решающие узкой задачи - для облегчения быстрого взаимодействия с европейцами или компьютерами. То есть для локальной оптимизации. Но никто не пишет книги на таких субститутах. Вернее даже и пишут - но это, скорее, proof-of-concept или шедевр для тех, кто шарит - но не для всех.
Сложное - это то, чего ты не знаешь. Но для того, кто знает, оно будет простым.
Я вот не увидел ни грамма сложности в ваших схемах ПИДов. Они ОБЪЕКТИВНО НЕ СЛОЖНЫЕ - несколько однотипных блоков, простые операции да соединения. Пройтись по ним с карандашиком и прикинуть логику работы сможет и школьник. Но при этом я совершенно не могу найти в них потенциальные ошибки: например - бесконечные циклы без выхода или блоки, которые никогда не сработают. Такие вещи МНЕ ЛИЧНО гораздо быстрее и понятнее было бы искать в текстовом коде. Но вам, возможно, наоборот они виднее именно в таком виде - потому что вы привыкли читать такие диаграммы и анализировать их.
То есть каждому будет простым то, что он знает. Я на ассемблере могу читать быстрее, чем на родном языке. Но какой-нибудь там Лисп или Эрланг заставят мой глаз дергаться. Ваши картинки напугают беременную женщину или студента SkillFactory - но тот, кто хоть раз в жизни пробовал починить советский телевизор по схеме, будут надменнно над ними насмехаться.
И кстати - сложность схемы вовсе не говорит о её крутости, важности и применимости исключительно для АЭС и космических кораблей.
Наоборот - сложные схемы тяжело отлаживать и проверять на ошибки. Погуглите 10 принципов разработки mission-critical систем от NASA, которые они придумали ровно для того, чтобы строить и отлаживать максимально критичные и важные системы. Так вот эти принципы как раз про максимальное упрощение - никаких сложных потоковых конструкций, четкие границы блоков, один функциональный модуль на одну страницу и т.п.
Ровно для того, чтобы инженеры, с тонким чувством прекрасного и причастности к великому не нагромождали одним им понятную красоту, которая взорвется при первом же старте из-за того, что две стрелочки перепутались местами 😀
Когда программу пишут сотни людей - и все разных возрастов, разных компетенций, разной культуры и уровня образования и даже разного языка - то невозможно гарантировать одинаковое чувство прекрасного у всех. Кроме того, то, что прекрасно для вас, будет уродливо и непонятно для других.
Именно для этого придумывают жёсткие правила и рекомендации. Потому что программу надо эффективно писать, а читать. Ине наслаждаться её красотой - а иметь возможность эффективно её модифицировать.
Графические схемы подходят для небольших линейных моделей, типа тех, которые вы показали. Попробуйте нарисовать на графической диаграмме, скажем, регулярное выражение. Или там - виртуальные конструкторы какие-нибудь. А после того, как нарисовали - попробуйте туда ещё правки вносить регулярно... Не уверен, что вы долго продержитесь 😁
Да, хорошие и удобно читаемые схемы нужны, это факт. Но они нужны там, где они подходят. Программисту проще прочитать страницу кода, чем карандашиком тыкать в блок-схемы. А вот директору по маркетингу, который хочет понимать логику работы CRM, вряд ли поможет её код - а вот схема всё объяснит.
Так что не красота спасет мир, а здравый смысл и использование правильных инструментов там, где они необходимы.
А объясните на пальцах для чайника - что такое тензор? Это типа многомерная матрица с какими-то доп.прикольчиками внутри?
Дополнительные хотелки - это дополнительные затраты. Затраты - это снижение маржи проекта. А изменение маржи проекта - это изменение его коммерческой составляющей, которой должны заниматься люди, ответственные за коммерцию. Задача РП - держать проект в рамках маржи. А переторговывать маржу должен сейлз, аккаунт или кто он у вас там. Это совершенно другая компетенция и другой уровень полномочий, которыми РП не обладает.
Так что не путайте тёплое с мягким. Заказчик хочет много новых фич, которых не было в ТЗ? Соберите их в документ и несите на проектный комитет - и пусть коммерсы переуиверждают с заказчиком цену, сроки, скоуп и т.д. Иначе будете бесконечно работать в минус на долгосроке - из-за чего и помирает большинство молодых проектных компаний.
Где-то далеко сейчас всплакнул Глеб Архангельский и утёр слезу стратегической картонкой 😁
Отличное расписание для выгорания через пару недель следования ему 😁 человек - не робот. Расписание нужно подстраивать под индивидуальные особенности биоритмов, восприятия погоды, производительности, обмен веществ и гибкость скелетной мускулатуры. Не каждому позвоночнику дано целый день сидеть и заниматься саморазвитием - иногда боль в спине может заставить поменять самый строгий график.
Ну какие картинки - аспиранту просто публикации нужны ? Июнь месяц на дворе, надо первую часть диссера показать, чтобы в армию не забрали!