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

У меня есть хобби. Больше 15-ти лет я изучаю большие группы людей. Племена, этносы, народы, нации, как они между собой взаимодействуют. Почему одни существуют долго, как китайцы, а другие достаточно быстро уходят в историю. Но больше всего меня занимала демография, а точнее события связанные с переходом к современному типу воспроизводства. Человечество впервые за свою историю столкнулось с такой массовой естественной депопуляцией.

С первого взгляда кажется, что эта тема очень узкая и уж точно не имеет отношения к IT. Но уменьшение населения, а что ещё более важно, изменение его возрастной и национальной структуры затрагивает все стороны жизни. Экономику - как пример длительная рецессия в Японии или поднятие пенсионного возраста в разных странах, общество - беспорядки на национальной почве как во Франции, право - обсуждение запретов абортов в России. Представьте, ваша девушка (или вы сами, если вы девушка) беременна, в стране аборты запрещены, а улететь можно только сдав кровь на ХГЧ, и если тест положительный за границу не пускают. Сейчас выглядит как бред, но в 2019 году наша реальность тоже показалась бы бредом.

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

Jobs to Be Done дает хорошую базу, но в полной мере не покрывает детали для проектирования интерфейсов. Расскажу, как я адаптировал подход для разработки цифровых продуктов, используя Desired Outcomes.​ С ними становится понятнее, что делать в продукте, они дают ответ на вопрос "чтобы что", и генерация идей перестает быть изнуряющим процессом.

Целью данной статьи является защита точки зрения того, что Системный аналитик с бизнес-навыками или наоборот Бизнес-аналитик с навыками системного анализа это то, что сейчас востребовано бизнесом, хотя открыто это и не прокламируется. Данное мнение базируется только на личном опыте.

Всем привет! Я Евгений Степченко, деливери-менеджер в Тинькофф. Расскажу про подход к анализу и улучшению процессов, который называется STATIK, System Thinking Approach To Introducing Kanban — применение системного мышления при анализе и проектировании канбан-систем. Поговорим о том, как устроен этот подход и как он помогает запускать эволюционные изменения.

Статья будет полезна тем, кто вовлечен в управление процессами и изменениями на основе канбан-метода. Если вы плохо знакомы с методом, советую сначала изучить официальное руководство. В конце статьи я поделюсь другими полезными ссылками по теме.

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

В этой статье речь пойдет о специальных тегах, которые вы можете использовать для сборки динамических шаблонов в MastermindCMS2.

За свою карьеру программиста я видел множество разных технологий и фреймворков от гигантов индустрии, таких как Oracle, Microsoft, IBM и т. п. Но в каждом из них было какое-то неудобство. А конкретнее у них у всех было одно общее, это необходимость реализовывать серверную логику чтобы можно было использовать ее в шаблонах. И это мне сильно не нравилось, приходилось делать одну и ту же работу из проекта в проект.

Один из таких подходов разнесения логики был паттерн программирования MVVM(Model-View-ViewModel). Его активно продвигали во фреймворках для C#. Структурно с точки зрения разнесения логики, я считаю этот паттерн самым удобным.

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

Это пилотная статья. Будем благодарны за обратную связь. Если тема вызовет интерес, мы возможно примем решение выложить на GitHub наши исходники(python) и входные данные.

Случилось мне поучаствовать в марте 2021 г. в хакатоне с задачей на комбинаторику и оптимизацию. Команду решил собрать свежую, из одиночек, дрейфующих в пуле самого хака. Довольно быстро нашлись front и back, и втроем мы принялись старательно размышлять, как потратим деньги, когда выиграем. Надо сказать, что в хаках я не так давно, но уже успел поучаствовать и в ЛЦТ(Лидеры Цифровой Трансформации), и в Цифровом Прорыве. В последнем даже нам удалось занять бронзу в финале. Роль всегда у меня была project+product+ppt. Так вот этот мартовский хакатон меня заинтересовал живостью и насущностью бизнес проблем, которые там решались. Так как часто в хакатонских кейсах проблемы немного надуманы, решения этих проблем немного фееричны и не несут практического смысла, а побеждает профессиональная преза и поставленный питч. Опытные хакантощики, читающие эти строки, поймут. Но полно про хакатоны и про то, какие они бывают, а то собьемся с курса.

В этам хаке преза и даже front мало интересовали кейсодержателей. Это был натуральный бизнес хакатон с абсолютно живыми дата сетами и с натуральной бизнес болью. К слову сказать, наша команда не выиграла, а заняла третье место (всего до защиты дошло 5 команд). Теперь наконец к условию:

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

Введение

В статье перечислены и дано краткое описание сайтов для размещения контента с целью продвижения бизнеса и личного бренда, где можно опубликовать материал бесплатно или получить за него денежное вознаграждение

• 31,1% от всех ИТ-проектов остановлены и не завершены;
• 52,7% от всех ИТ-проектов завершены со срывом сроков, значительным увеличением первоначально запланированного бюджета или кардинальным изменением изначально запланированных целей;
• только 16,2% от всех ИТ-проектов оправдали ожидания.

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

Как превратить условно-работающую ERP в реальный инструмент управления производством и поставками?
1 часть (здесь): проблемы использования для планирования внедренных "учетных" ERP
2 часть (по ссылке): 2я жизнь — постановка Планирования и Мониторинга производства и поставок с внешним планировщиком. Концепция и реализация.

Питеркин Сергей, Меркулов Михаил, «Райтстеп»

За последние годы, количество производственных предприятий, заявляющих о внедренных ERPсистемах, значительно возросло. И составляет уже не десятки, а сотни. Говорим мы прежде всего о дискретном производстве, а под «производственной ERP» подразумеваем любую систему, претендующую на это гордое название. По частоте наших «столкновений», наиболее распространенными «работающими в производстве» ERP являются — BaaN/InforLN, InforERPSyteLine, постоянно-растущая «армия» заводов с 1С, и в небольшом количестве SAPERP и прочая экзотика.

Данная статься будет интересна прежде всего «продвинутым» пользователям ERP, в большей степени с позаказным типом производства («вытягивание» под заказ или на склад, в т.ч. и «вытягивание» под прогноз спроса), тем, кто автоматизировал (возможно – «как есть») процессы учета хода производства, т.е. формирования производственных заданий (далее по тексту – ПЗ. В разных системах: SFC-заказы, Job-Orders, JOBs, Заказы на Производство, Производственные заказы и т.п.) и их отслеживания, но так и не смог уверенно производство (и поставки – МТО (Материально-Техническое Обеспечение)) планировать, как и не смог поставить мониторинг производства, в т.ч. и позаказный. С непрекращающимися попытками все-же запустить планирование, и/или с попытками обеспечить планирование с использованием волшебных алгоритмов и/или систем типа APS, MES.