техпред_мфти
Практика в образовании
Ресурсы образования - для решения реальных задач
13subscribers
136posts
0 of 200 paid subscribers
Создание сообщества профессионалов, способных выполнять реальные проекты, используя ресурс системы образования
About
Профессиональный канал по организации и управлению практико-ориентированной проектной деятельностью в образовании и использовании потенциала системы образования для решения задач реального сектора
Корнилов Алексей Вадимович — разработчик автоматизированных, робототехнических и интеллектуальных систем с более чем 35-летним стажем, в числе по заказу НИЦИАМТ НАМИ, ЦНИИ РТК, ФГУП НПЦАП им. Пилюгина и др., уже более 20 лет занимается выстраиванием связей между системой образования и практикой, обеспечивает трансфер в образование перспективных технологий и реализацию потенциала перспективной молодежи — организовывал первые в России олимпиады роботов, был руководителем общероссийской Программы «Робототехника: инженерно-технические кадры инновационной России» и организатором Всероссийских робототехнических фестивалей, первых в России соревнований «автомобилей-роботов» РобоКросс, национальный эксперт WorldSkills, автор учебных программ по организации проектной деятельности и разработке высокотехнологичных систем в МФТИ, еНано, Школе управления «Сколково», ЮРАЙТ.Академии, Британской высшая школа дизайна и пр., совместных программ с Microsoft, Autodesk, PTC и др., преподаватель и ментор кафедры технологического предпринимательства МФТИ, член консультативного совета Межвузовской программы по технологическому предпринимательству.
Эволюция проектирования и проекты интернета вещей
Приложение. Проблемные ситуации в разработке гибридных и IoT-систем
Проблемы можно разделить на три фундаментальных уровня, которые часто взаимосвязаны и усугубляют друг друга.
Уровень 1: Продуктово-архитектурный (ЧТО мы делаем?)
Эти проблемы возникают из-за ошибок в концепции, архитектуре и проектировании самого продукта, когда не учитывается синергия и противоречия между его физической и программной частями.
1. Антипаттерн: "Раздельная разработка компонентов"
- Суть: Аппаратная и программная части разрабатываются изолированно, как два независимых продукта.
- Типичные сценарии:«Железо сначала, софт потом»: Проектируется и производится "железный ящик", и только затем пытаются написать для него ПО. Результат — физические ограничения делают невозможной реализацию требуемой функциональности.«Параллельные вселенные»: Команды работают параллельно, но без постоянной синхронизации. Результат — две законченные, но несовместимые системы.
- «Железо сначала, софт потом»: Проектируется и производится "железный ящик", и только затем пытаются написать для него ПО. Результат — физические ограничения делают невозможной реализацию требуемой функциональности.
- «Параллельные вселенные»: Команды работают параллельно, но без постоянной синхронизации. Результат — две законченные, но несовместимые системы.
2. Антипаттерн: "Неправильная абстракция реальности"
- Суть: Использование моделей (макетов, эмуляторов, симуляторов), которые недостаточно точно отражают поведение системы в реальных условиях.
- Типичные сценарии:«Макетный обман» / «Эмуляторный тупик»: Датчики на макете имеют иную характеристику, эмулятор не учитывает EM-помехи, тепловые режимы или механические вибрации. Алгоритмы, идеальные в симуляции, в реальности работают плохо или опасно.
- «Макетный обман» / «Эмуляторный тупик»: Датчики на макете имеют иную характеристику, эмулятор не учитывает EM-помехи, тепловые режимы или механические вибрации. Алгоритмы, идеальные в симуляции, в реальности работают плохо или опасно.
3. Антипаттерн: "Нежизнеспособная архитектура системы"
- Суть: Продукт проектируется без учёта его места в более крупной экосистеме и реального жизненного цикла.
- Типичные сценарии:«Умное устройство без экосистемы»: Создание собственного, уникального протокола, что блокирует интеграцию с существующими системами.«Игнорирование жизненного цикла «вещи»»: Программная часть устаревает быстрее, чем физический объект (например, промышленный станок), что приводит к невозможности обновления и поддержки.«Ложная универсальность»: Попытка создать "универсальное" решение, которое в итоге плохо решает любую конкретную задачу.
- «Умное устройство без экосистемы»: Создание собственного, уникального протокола, что блокирует интеграцию с существующими системами.
- «Игнорирование жизненного цикла «вещи»»: Программная часть устаревает быстрее, чем физический объект (например, промышленный станок), что приводит к невозможности обновления и поддержки.
- «Ложная универсальность»: Попытка создать "универсальное" решение, которое в итоге плохо решает любую конкретную задачу.
Уровень 2: Процессуально-организационный (КАК мы работаем?)
Эти проблемы связаны с неэффективной организацией команд, процессов их взаимодействия и управления проектом.
1. Антипаттерн: "Водопадный разрыв между командами"
- Суть: Команды работают последовательно, передавая друг другу "результат" по принципу эстафеты. Это самая частая причина сбоев.
- Типичные сценарии:«Водопадная очередь»: Программисты месяцами ждут готовый макет от инженеров, и только тогда обнаруживаются фундаментальные несоответствия.«Фазовый разрыв»: Аппаратная команда считает свою работу завершённой и переходит на другой проект, оставляя программную команду без поддержки для внесения необходимых изменений в "железо".
- «Водопадная очередь»: Программисты месяцами ждут готовый макет от инженеров, и только тогда обнаруживаются фундаментальные несоответствия.
- «Фазовый разрыв»: Аппаратная команда считает свою работу завершённой и переходит на другой проект, оставляя программную команду без поддержки для внесения необходимых изменений в "железо".
2. Антипаттерн: "Организационный silo (Изолированные команды)"
- Суть: Команды работают в своих "башнях из слоновой кости", со своими целями, терминологией и процессами.
- Типичные сценарии:«Переводческий хаос»: Менеджер тратит всё время на "перевод" требований между командами, что приводит к искажениям.«Модульный разрыв»: Каждая команда оптимизирует свой модуль, но при интеграции они не стыкуются.«Изолированная экспертиза по вещам»: Эксперт предметной области (нефтяник, агроном) и IT-команда не понимают ограничений и возможностей друг друга.
- «Переводческий хаос»: Менеджер тратит всё время на "перевод" требований между командами, что приводит к искажениям.
- «Модульный разрыв»: Каждая команда оптимизирует свой модуль, но при интеграции они не стыкуются.
- «Изолированная экспертиза по вещам»: Эксперт предметной области (нефтяник, агроном) и IT-команда не понимают ограничений и возможностей друг друга.
3. Антипаттерн: "Методологический конфликт"
- Суть: Конфликт культур и подходов к разработке. "Железные" инженеры часто работают по классическим каскадным моделям (V-model), а программисты — по гибким (Agile).
- Типичные сценарии:«Методологическая война»: Две команды управляются по разным методологиям, их циклы и процессы несинхронизированы.«Параллельная разработка без синхронизации»: Команда ПО в каждом спринте меняет требования, а команда устройства не успевает за этими изменениями из-за долгого цикла перепроектирования.
- «Методологическая война»: Две команды управляются по разным методологиям, их циклы и процессы несинхронизированы.
- «Параллельная разработка без синхронизации»: Команда ПО в каждом спринте меняет требования, а команда устройства не успевает за этими изменениями из-за долгого цикла перепроектирования.
4. Антипаттерн: "Дисбаланс экспертиз"
техпред_мфти
Эволюция проектирования и проекты интернета вещей
Часть 5. Стратегические выводы для индустрии
IoT представляет собой не просто новый класс продуктов, а новую индустриальную парадигму, приводящую к трансформации цепочек создания ценности:
- От линейных цепочек «проектирование → производство → продажи».
- К сетевым экосистемам с множественными точками создания и потребления ценности.
Смещаются и конкурентные преимущества:
- От оптимизации отдельных компонентов — к оптимизации архитектур взаимодействия.
- От скорости разработки — к способности интеграции с существующими системами.
- От технического совершенства — к экосистемной совместимости.
Таким образом, IoT-разработка требует такого формата планирования, где:
- Планирование действий уступает место планированию взаимодействий.
- Проектирование продуктов трансформируется в проектирование экосистем.
- Управление процессами эволюционирует в управление архитектурами.
Фундаментальный вывод: IoT требует не выбора между «проектным» и «гибким» подходами, а создания мета-подхода, который интегрирует преимущества каждого на соответствующем уровне системы. А от специалиста требуется способность создавать архитектуры, которые позволяют разным парадигмам работать совместно, усиливая друг друга вместо конфликта.
Изменение роли разработчика
Возвращаясь к теме проектирования решений на технологиях интернета вещей, важно отметить, что ключевые решения принимаются на стадии архитектуры: уже есть запрос на то, что должно получиться, а задача состоит в понимании того, насколько хорошо и каким образом это реализуется на технологиях IoT. Из этого понимания:
- Формируются задания на разработку.
- Определяется структура работ.
- Формируются составы команд, поставщики, субподрядчики.
Здесь действительно становится не так важно, какими средствами и с использованием каких методологий субподрядчик или исполнитель добивается результата — планируя его, «гибко» или методом проб и ошибок. Более того, он может вообще представить решение, созданное нейросетью.
Для вот для системного разработчика ключевым становится именно общее видение, чтобы:
- Правильно поставить задачу.
- Оценить приемлемость решения.
- Быть способным интегрировать частные решения в единое целое.
Причем учитывая, что разные составляющие системного решения будут создаваться в рамках разных парадигм: что-то — с долгосрочным планированием, что-то — «гибко», при этом разными командами, поставщиками, подрядчиками, в рамках своих подходов к работе, своей терминологии и методологии, где даже один и тот же документ будет пониматься по-разному.
техпред_мфти
Эволюция проектирования и проекты интернета вещей
Часть 4. Интернет вещей как гибридная система особого рода
Итак, в современных системах программная часть перестает быть «довеском», а начинает определять другие компоненты решения. Если раньше было возможно, затратив время и ресурсы, сделать «механику», а под нее софт, то сейчас может оказаться, что нужное «софтовое» решение почему-то оказывается неработоспособным, и всю механику надо переделывать заново. Все это оказывается критично для организации разработки таких систем.
Посмотрим, как эти принципы сегодня реализуются в высоких и «умных» технологиях, в частности — при разработке решения на основе технологий интернета вещей (Internet of Things - IoT).
В русском языке «вещи» чаще ассоциируется с конкретными физическими объектами; английское things шире и может включать абстрактные понятия. В контексте IoT под «вещью» подразумевают любой объект физического или информационного мира, который можно идентифицировать и подключить к сети.
По определению МСЭ‑T Y.2060, интернет вещей — это инфраструктура и экосистема, в которой физические и виртуальные вещи идентифицируются, интегрируются и взаимодействуют в сетях связи. Суть перехода от «интернета людей» к «интернету всего» — любые объекты — как материальные, так и информационные — могут между собой взаимодействовать. Соответственно, можно строить не только иерархические системы или их цифровизировать, но и создавать горизонтальные и распределенные системы со всеми вытекающими выгодами.
Здесь важно, что, добавляя некой вещи — материальной или виртуальной, информационной — возможность коммуникаций, мы не просто добавляем новую функцию, а качественно меняем её возможную роль.
Здесь концепция интернета вещей прямо пересекается с концепцией умных вещей. Пусть мы оснастим, к примеру, счётчик электроэнергии устройством, передающим данные в интернет, а информационную систему учёта электроэнергии — доступом к данной информации. И вот у нас датчик становится уже «достаточно умным», чтобы отправлять эти данные, а информационная система — «достаточно умной», чтобы их использовать.
техпред_мфти
Эволюция проектирования и проекты интернета вещей
Часть 3. Контекст разработки гибридных продуктов
Итак, человек до недавнего времени существовал в материальном мире, создаваемом промышленным производством на основе проектного подхода. Сейчас параллельно формируется информационный мир, создаваемый IT-разработкой на основе итеративных и гибких подходов.
Причем интенсивно идет их слияние в одном изделии: все больше свойств продуктов производства формируются программными средствами. И если раньше их свойства и «поведение» определялись конструктивными решениями, то затем значительная часть стала реализовываться за счет электроники, а сейчас — за счет программного обеспечения.
Современный автомобиль — яркий пример такого слияния: большинство функций управляется программным кодом — от навигационных систем до двигателя и тормозов. Такой подход позволяет гибко настраивать функциональность продукта, обновлять её удалённо и адаптироваться к существующим или появляющимся требованиям без внесения изменений в физический конструктив.
Важно, что в современных системах изменяется и иерархия компонентов: программная часть перестает быть «довеском», а начинает определять другие компоненты решения. Если раньше было нормальным сделать сделать «механику», а уже под нее софт, то сейчас может оказаться, что нужное «софтовое» решение почему-то оказывается неработоспособным, и всю механику надо переделывать заново.
И вот нам нужно создать единую систему, но состоящую из нескольких сущностей, создаваемых принципиально разными способами на основе принципиально разных подходов. При этом мы в мире, где эффективность экономики обеспечивается разделением труда, это будут делать разные люди — с разным менталитетом, образованием, использующие разные системы понятий, терминологию, методологии и руководствующиеся разными стандартами.
Как же в этом случае организовать разработку, чтобы получить требуемое решение в заданные сроки при заданных условиях?
техпред_мфти
Эволюция проектирования и проекты интернета вещей
Часть 2. А что в IT? Возврат к ремесленной модели
Одновременно с развитием и совершенствованием классического проектного подхода в промышленности принципиально иная ситуация сложилась в области информационных технологий.
Важно, что в IT тиражируется не замысел, а сам продукт, поэтому неважно, каким способом он получен.
Кроме того, поправить код и посмотреть на результат кажется значительно проще, чем создать физическую конструкцию, чтобы посмотреть на результат.
При этом, очень часто реализацию замысла осуществляют те же люди или, по крайней мере, та же команда или структура, которой замысел принадлежит, поэтому нет явной необходимости в разделении труда.
Поэтому кажется, что «гибкий», а не «проектный» подход к разработке — причем даже на уровне «Code & Fix» («кодим — правим»), итерациями или «методом тыка» — является вполне естественным.
Тем не менее, на заре вычислительной техники превалировало полноценное проектирование и планирование разработки программного продукта. Представляется, что основанием для этого был расцвет и повсеместное использование проектного подхода во всех сферах человеческой деятельности как условие ее успешности, что, видимо еще более важно — крайне высокая стоимость ресурсов для создания продуктов на первом этапе, которая делала подход «попробовал-поправил» нерентабельным.
Так, опыт IBM по разработке OS/360: проект стоил IBM 5 миллиардов долларов — вторая по стоимости программа НИОКР 1960-х после программы «Аполлон». Время компиляции программ измерялось часами, отладка требовала записи на перфокарты и ожидания в очереди на доступ к мейнфрейму. Каждый час машинного времени стоил тысячи долларов, что делало любую ошибку критически дорогостоящей.
техпред_мфти
Эволюция проектирования и проекты интернета вещей
Часть 1. Эволюция проектной деятельности: от инстинктивного представления к осознанному
Человек — один из немногих видов на Земле, способный предвидеть будущее и представлять последствия действий, что дало ему огромное эволюционное преимущество. Однако сама такая способность первоначально развивалась как автоматический механизм мозга, работающий неосознанно. Наш мозг постоянно делает прогнозы «на автомате», и мы замечаем работу этого механизма часто лишь тогда, когда эти предсказания не сбываются.
Такое неосознанное прогнозирование и принятие решений на основе представления о целях лежит в основе большинства наших повседневных дел. Этот «автопилот» мозга экономит энергию и время — важнейший эволюционный механизм выживания.
При создании продукта — изготовлении инструментов, строительстве сооружений и создании функциональных объектов уже, как правило, появляется представление образа будущего результата, но пути его создания остаются на интуитивном уровне.
Даже в классической структуре деятельности из школьного учебника «цель → средства → действия → результат» есть цель как представление требуемого результата, но что за средства нужны и какие требуются действия — это как бы «само собой» или интуитивно понятно.
Соответственно, и в средневековой мастерской такое интуитивное представление путей достижения цели существовало, но было неотделимо от самого процесса работы. Мастер представлял и планировал нужные действия по ходу дела, опираясь на традиции и личный опыт. Это было скрытое знание, встроенное в его навыки и передававшееся через многолетнее ученичество.
Технология реализации замысла оставалась неотделимой от мастера. Поэтому мы традиционно говорим, что пирамиду Хеопса построил Хемиун, а храм Василия Блаженного — Барма и Постник: мастер, как автор замысла, был единственным носителем знания о том, КАК достичь цели, реализуя этот замысел.
техпред_мфти
Весь мир театр или роли в разработке
Студенческая команда разработала новый супервелосипед, а почтальон Печкин решает открыть в Простоквашино пункт по прокату велосипедов для приезжих туристов. Казалось бы, Печкину надо всего лишь заказать их изготовление команде, но все оказывается не так просто в наших реалиях: не факт, что разработчик нового продукта может стать его продавцом. Разбираемся.
Весь мир — театр.
В нём женщины, мужчины — все актеры.
У них свои есть выходы, уходы,
И каждый не одну играет роль.
(В.Шекспир)
Весь мир театр: социальные роли
Да, каждый играет множество ролей - он может быть "пешеходом" или "водителем", "гражданином своей страны" или "блоггером", "взрослым" или "ребенком". При этом "родитель" или "чужой дядя" - это будут разные роли. И конкретная роль определяет мотивы и форматы поведения, возможности, ограничения, ресурсы и права — как говорится, «Что дозволено Юпитеру, не дозволено быку»: вот назначат быка Юпитером, тогда и ему будет дозволено!
Роль по отношению к субъекту — это набор ожиданий, поведенческих моделей и социальных функций, которые общество или определенная социальная группа приписывает индивиду в определенном контексте. Роль определяет, как субъект должен действовать и взаимодействовать с другими в рамках своего статуса.
Некоторые роли человек принимает на себя по факту своей деятельности, к примеру, сел человек на велосипед — и он уже велосипедист!
При этом велосипед может быть “его”, и он хозяин велосипеда и его собственник, а может ему дали велосипед просто покататься.
Таким образом,
Утро без кофе или про риски в проекте
Стоит ли планировать, когда все идет не по плану?
Ты любишь начинать рабочий день с чашки кофе с любимым пирожным - это дает тонус, положительные эмоции, позволяет включиться в рабочий ритм. Переживания, получится ли попить кофе, влияют на настрой, в конечном счете - на собственную эффективность. Обдумывая ситуацию, ты понимаешь, что если сразу брать упаковку пирожных на неделю, это дает спокойствие, что дни будут начинаться правильно, да и упаковка позволяет существенно экономить. И ты в понедельник покупаешь упаковку пирожных, кладешь в холодильник, и наливаешь себе кофе, замечательно начиная день, и мысленно представляя, что такой же будет вся рабочая неделя. Во вторник ты наливаешь себе кофе и идешь к холодильнику, предвкушая новый чудесный день, и обнаруживаешь, что пирожные кто-то съел. И кофе, в удовольствие, уже не попьешь.
Планируемая последовательность действий, направленных на достижение конкретной цели - в данном случае, получение удовольствия от кофе для повышения своей производительности - это, по сути, проект.
Проектный подход позволяет быть эффективным, достигая заданных результатов, минимизируя риски. Но понять и спланировать необходимые действия, организовать соответствующие процессы и обеспечить их выполнение - все это требует существенных усилий. А еще надо знать, как это делать. В каком случае все эти усилия имеют смысл?
Проект, как говорится – задача с известным результатом: заранее как бы известно, что должно получиться и зачем. И что будет, если не получится. Причём мы будущее не знаем, мы его оцениваем.
Управление на результат: как все утроено и почему так работает
Из новостей: itSMF России (IT Service Management Forum), вместе с представителями ведущих российских компаний (Сбер, Норникель, Магнит, МТС-банк, Газпромнефть и др.), выступил с инициативой по созданию свода знаний под названием РИТМ (Российская ИТ-методология).
А что не так-то?
Как все устроено
Можно сказать человеку: возьми яйцо, немного масла, соль, и вон ту сковороду. Разогрей сковороду на среднем огне, добавь немного масла и дай ему расплавиться, покрыв всю поверхность сковороды. Бережно разбей яйцо, стараясь не повредить желток. Это можно сделать, разбив яйцо о плоскую поверхность, а затем аккуратно разделяя две половинки скорлупы, чтобы желток упал на сковороду. Когда яйцо будет готово, аккуратно сними его с помощью лопатки и подавай мне на тарелке. И это называется яичница-глазунья.
И так же можно дать инструкции как сделать, к примеру, кофе или приготовить тосты.
Тут важно, что человеку, который уже делал это, достаточно просто сказать, мол, сделай мне яичницу-глазунью, и других инструкций можно не давать.
И в этом смысл обучения: мы выносим процессы освоения понятий, терминологии, процедур, приобретения опыта из рабочего процесса, делая его более эффективным.
Но, даже для того, чтобы эти инструкции были поняты и исполнены, человек уже должен понимать язык, на котором они даются, знать, что такое “яйцо”, а что - “сковорода”, как ее “разогревать” и так далее.
Соответственно, есть обучение, необходимое для выполнения конкретных профессиональных или служебных функций - профессиональное, а есть общее - дающее знания, умения, навыки, компетенции, необходимые для повседневной жизни, а также для получения знаний, умений, навыков, компетенций профессиональных.
Subscription levels4
Проекты в образовании
$2.53 per month
Материалы по организации проектной деятельности учебном процессе для преподавателей, а также для родителей, которых интересуют перспективы своих детей.
Управление проектами
$6.6 per month
Материалы по управлению проектами для руководителей и менеджеров проектов, команд по управлению проектами
Организация проектной деятельности
$25.3 per month
Материалы по организации проектной деятельности для кураторов и директоров проектов, а также управленческих команд проектных офисов, центров и служб управления проектами и т.п., а также доступ ко всем материалам по управлению проектами.
Руководство проектной деятельностью
$66 per month
Материалы, связанные с руководством проектной деятельностью в образовательной организации - определение направлений развития, постановка целей, выбор стратегии их достижения, метрики и ключевые показатели эффективности, а также доступ ко всем материалам по организации проектной деятельности и управлению проектами.