¶ Понятие проекта
¶ Контекст
Как показала практика, проектом можно назвать почти что угодно и при желании притянуть названное к любому из определений проекта.
- Когда аргументов не хватает, можно вспомнить про основную задачу вуза -- учить студентов и другие бесспорные утверждения.
- Игрушечность задач также можно объяснить невозможностью выполнения настоящих проектов (в полном их цикле) за "срок жизни" студента в вузе и с имеющимися у студентов пререквизитами.
- Невозможно брать сколько-нибудь ответственные проекты, если каждый раз команду приходится собирать с нуля и невозможно предсказать, будут ли с виду годные к работе студенты работать через 2-3 месяца. Нет никакой подстраховки и никаких серьезных стимулов или санкций.
- В настоящее время нет механизмов страховки проекта дублирующей разработкой. Простое дублирование разработки могло бы повысить шанс получения результата, но выглядит топорным решением. Как вариант -- проведение технологического конкурса на решение проектной задачи
- Проектов полного цикла много может быть только в начале и в основном за счет игрушечных задач. Проектная модель должна предусматривать работу с длительными и крупными проектами, в которых командам выделяются свои зоны ответственности и этапы разработки.
Пример
В атомарном проекте "запуск веб-сервиса на основе готового движка" есть фазы выбора движка, запуска, интеграции и передачи в эксплуатацию. И это конец проекта, но дальше начинается жизнь сервиса и она требует не меньше вложений от разработчиков и интеграторов, просто вложения эти растянуты во времени и распределяются между разработкой и поддержкой.Следующие поколения студентов будут привлекаться на эти задачи, а в них проектные фазы не так выражены, хотя атомарно это множество отдельных циклов разработки ПО по частным задачам развития проекта.
Настоящие проектные и рабочие задачи мы будем отделять от регистрируемых в учебном процессе проектов. Но нужен механизм, связывающий их. И нужны критерии, по которым проектные задачи будут отделяться от чисто сервисных.
Пример
Задача 1. В Цифровых сервисах МИЭМ потребовалось запустить новый сервис, провести соответствующую интеграцию. Это проектная задача.Задача 2. В этом сервисе понадобилось вести поддержку пользователей. Это сервисная задача.
¶ Термины
Словарь используемых терминов Проектная модель v.2¶ Проекты их "проекция" на учебную среду
¶ Отличия от действующей модели
¶ База для проектной деятельности
В действующей проектной модели учебные проекты атомарны. Нет связанных проектов, длительные проекты не выделены, понятия о разделении труда между проектными командами тоже нет. Этого достаточно для ряда задач, но при попытке применить такие проекты к реальным заказам или инфраструктурной разработке и поддержке, а не учебным начинаниям, возникают системные проблемы:
- Нет стимулов к закреплению задела и развитию следующими разработками сделанных ранее. Не формируется инженерная и научная среда. Атомарный формат работ позволяет поверх сложившейся среды делать небольшие проекты, не предполагающие длительную поддержку, но не может сформировать эту среду.
- Вопреки атомарному подходу, свойственному текущей модели, в расширенной проектной модели проекты преимущественно строятся на
компетенциях команд, а не команды подбираются под проект с нуля. Это реализуемо на базе ресурсных и научных центров (лаборатории, научные группы и т.д.), и тогда проекты могут выполняться "поверх" уже имеющихсяколлективов(то есть, сработанных групп, решающих задачи в близких областях) с точечным привлечением дополнительных участников с новыми компетенциями.
- Регенерация состава проектных групп в таком случае происходит не внутри проектов, а в лабораториях или иных центрах компетенций.
- Ресурсное обеспечение исследований и разработок в таком случае также базируется на лабораториях, а не разделяется по проектам, как действующей модели.
¶ Заказы и проекты
Термины "заказы" и "проекты" разделяют соответственно "рабочее" и "академическое" представления работы в проектной модели: поступающие заказы инициируют создание учебных проектов на базе ресурсных центров, но не обязательно каждому заказу соответствует отдельный проект и вообще для выполнения заказа не обязательно формируется учебный проект.
Заказ может быть как внешним, так и внутренним.
¶ Сроки проведения проектов
Текущий подход не определяет сроки жестко, но предполагает, что проекты начинаются в сентябре и заканчиваются в апреле, пройдя семь четырехнедельных циклов и три публичных представления.
Практика показывает, что из этого правила находится множество исключений.
О сроках проектов и соотнесении выполнения реальных задач и учебного графика -- по ссылке ниже.
¶ Ресурсное обеспечение
У заказа может быть или не быть финансирование.
¶ Адресат финансирования
- Персонально: гранты (например, УМНИК), договор ГПХ, и т.д.
- Учебный проект: по смете на проект
- Заказ, как бы он ни распределялся по учебным проектам
- Лаборатория или иной ресурсный центр
¶ Источник финансирования
- От внешнего заказчика напрямую через МИЭМ/ВШЭ
- По конкурсу Проектных групп ВШЭ из средств МИЭМ (на оплату труда и расходные материалы)
- Финансирование проектов МИЭМ по смете проекта (на расходные материалы)
¶ Ресурсы
- Коллектив
- Оплата труда
- Оборудование
- Расходные материалы