Проектная школа -- это неформальная организация в МИЭМе, нацеленная на проектную подготовку студентов, в том числе -- на подготовку руководителей проектов.
Студенты проектной школы обучаются в предложенном организаторами формате, участвуют в работе лабораторий и проектов, получают задачи, успехи считаются по трекеру.
Сайт проектной школы
Проектная школа в настоящее время организуется при Лаборатории видеотехнологий и Медиацентре МИЭМ и практическая часть деятельности в ней нацелена на Цифровой МИЭМ, поекты Лаборатории и Медиацентра.
Проектная школа призвана поддерживать развитие проектной модели МИЭМ.
Читайте по этой теме:
- Для студентов младших курсов Проектная школа -- это подготовительный этап для работы в проектах МИЭМ.
Проходя обучение на первой ступени Проектной школы, студенты работают на базе лабораторий, выполняющих проекты, получают учебные, а позднее и рабочие задачи из проектов, консультируются с участниками проектов, с новичками работают ассистенты.
Основная цель первой ступени обучения -- подготовиться к эффективной работе в проектах МИЭМ и внешних проектах, показать себя как ценного участника, проявить свои навыки или освоить что-то новое для участия в интересующем проекте.
- Студенты, имеющие экспертизу в какой-либо области и готовые консультировать других студентов, в т. ч. для подготовки к работе в своих проектах, могут участвовать в работе Проектной школы в качестве инструкторов, в таком случае консультации, мастер-классы и другие формы совместной работы, в т.ч. дистанционной, становятся их учебной нагрузкой.
- Для студентов, прошедших и защитивших хотя бы один проект (ветеранов), доступна вторая ступень -- обучение руководству проектами. В него в частности входит работа с командой, с ресурсами, экономика проекта и бюджетирование, привлечение экспертизы, внешняя коммуникация, включая работу с заказчиком, продуктование, администрирование проекта в МИЭМ и подготовка защит.
- Поступить в проектную школу могут студенты всех курсов бакалавриата и магистратуры.
- Студенты могут зачисляться в Проектную школу для получения необходимых для успешной работы в проектах навыков. Набор в ряд проектов будет осуществляться в приоритетном порядке из числа студентов Проектной школы.
- Студенты, имеющие практические навыки в различных предметных областях (программирование, конструирование, ...), и показавшие эти навыки в работе могут стать экспертами и вести консультации.
- Студенты, имеющие опыт работы в проектах и защитившие не менее одного проекта (ветераны), могут получить опыт управления проектами и командами, опыт подготовки новичков к работе в проектах.
- Каждый студент может поступить в Проектную школу МИЭМ.
- Количество мест в Проектной школе ограничено и суммарно для всех курсов составляет 150 студентов, включая инструкторов.
На первом этапе набор будет ограничен 20-30 студентами первой ступени.
- Студент, желающий поступить в Проектную школу, помимо заявления в Учебный офис, пишет мотивационное письмо и проходит собеседование. В случае возникновения конкурса отбор проходит по итогам собеседования.
- Поступая в Проектную школу студент берет на себя обязательство соблюдать утвержденные правила и регламенты школы.
- В любое время студент может покинуть Проектную школу, уведомив своего куратора / руководителя.
- Успеваемость на первой ступени считается по рейтингу в трекере, а успешность -- по положению в иерархии С.С.С.Р.. В частности, если студент опускается ниже уровня "Студент", то он попадает в статус "Пролетарий", что означает его выход из проектной школы.
- Обучение в проектной школе -- это инициатива студента, возможность для развития.
- Занятия в традиционном представлении (лекции, лабораторные работы, семинары) заменены здесь на мастер-классы и консультации, общие встречи проводятся для организационных целей.
- Задачи могут быть индивидуальными и групповыми, группы как правило -- смешанные по курсам, требующие совместной работы с другими студентами, в т.ч. из проектов.
Обучение носит практико-ориентированный характер, но для выполнения задач часто требуется изучение дополнительных материалов, темы определяются руководителем/куратором индивидуально. Освоение материалов оценивается умением применить изученное на практике.
Оценок здесь не ставят.
Зато есть рейтинг и система иерархии "С.С.С.Р.", и он связан с работой в проектах.
- Проектная модель
- Структура и график проекта,
- Учет работы, инструменты
- Этапы представления, критерии оценки.
- Рабочая среда. Внутренняя и межпроектная коммуникация.
- Практики ведения программных и аппаратных проектов. Работа с кодом.
- Документация.
- Освоение предметной области в лабораториях и других ресурсных центрах МИЭМ, участвующих в Проектной школе.
- Материальная часть. Практическое освоение доступной техники и инфраструктуры, работа с серверами.
- Типовые задачи в проектах (по подгруппам).
- Учебные задачи из ведущихся проектов, переход к рабочим задачам в статусе стажеров.
Студенты с опытом работы по профильным темам, которые могут успешно консультировать других студентов по возникающим вопросам, получают статус эксперта в той или иной области и их консультации оцениваются в часах.
Успешным окончанием первой ступени Проектной школы считается
- Переход студента в статус эксперта
- Переход студента на вторую ступень в роли руководителя проекта
- Студент устраивается в роли сотрудника (не стажёра) в проект, ведущийся при проектной школе. При этом он остаётся в составе проектной школы, может доучиваться по интересующим его темам.
- Студент также может покинуть Проектную школу, полностью перейдя в проект вне проектной школы. Таким образом он достигает личной цели -- трудоустройства в интересующий его проект, даже если этот проект не относится к проектной школе.
Обучение в Проектной школе формирует цифровой след, который доступен всем пользователям цифровой среды МИЭМ. Достигнутые результаты, отзывы руководителей и сокурсников и другие материалы, собранные за время обучения, формируют детализированное цифровое Портфолио студента, на основании которого не только руководители проектов, но и работодатели могут сформировать представление о каждом выпускнике.
Студентам, попавшим на вторую ступень Проектной школы, предстоит освоить
- управление командой и её мотивацией,
- построение проектной инфраструктуры,
- планирование и управление проектом,
- оценку и управление рисками, ресурсами, экономику проекта,
- исследование рынка,
- коммуникацию с заказчиками.
Обучение по этим вопросам не входит ни в одну программу МИЭМ, но эти навыки важны для запуска и успешного проведения не-учебного проекта.
Освоение технологий и инструментов для ведения бизнеса (CRM, SMM-инструментарий, принципы продвижения, инструменты упрощения бухгалтерской рутины в ведении коммерческих проектов).
В ряде случаев могут понадобиться специфические технологии и инструменты, которые придется освоить, чтобы ввести их в оборот в проектах, поэтому такое освоение должно порождать методические материалы, которые будут использоваться для обучения на первой ступени в рамках академического трека.
Если студенты первой ступени отчитываются закрытыми задачами, то на второй ступени успех определяется выполнением проектных нормативов (KPI), определяемых на старте индивидуально для каждого проекта и руководителя. Здесь приоритет индивидуальным целям руководителя (что хочет развить) и целям конкретного проекта в терминах результатов. Не всегда главным результатом проекта является заявленный продукт, это может быть создание технологических наработок, платформы, апробация технологий и инструментов, проверка рыночной гипотезы и тд.
Оценка руководителя -- это работа команды. Безотносительно причин провалов, руководитель несет ответственность за вверенный ему проект и его результаты и сроки. Бонусом будет использование потенциала команды, ее рост, получение дополнительных результатов.
Не все задачи, возникающие в Проектной школе будут иметь проектный характер. Часть задач имеет инфраструктурную сервисную направленность. Создание и поддержание работоспособных групп поддержки инфраструктуры, в т.ч. сервисов цифровой среды МИЭМ -- это тоже задача руководителей как отдельных проектов, так и сформированных для этих целей специальных групп (техподдержка, сисадминская группа, медиацентр, бизнес-сопровождение и тд).
Выпускник второй ступени Проектной школы должен обладать подтвержденным на практике опытом руководства проектной группой, иметь необходимые навыки для самостоятельного ведения проекта в близкой ему области, иметь знания, достаточные для запуска и ведения малого предприятия или ИП.
За время обучения в Проектной школе он должен стать достаточно известной фигурой в МИЭМ и достаточно востребованным в коммерческих проектах, чтобы не заботиться о формальных документах, подтверждающих его вклад в академических единицах учета и ценность как сотрудника в проекте. Тем не менее, цифровое портфолио успешного выпускника Проектной школы должно стать весомым приложением к диплому и упоминании в нём о прохождении этого факультатива.
Проектная школа организуется в экспериментальном порядке на базе Лаборатории видеотехнологий (Учебная лаборатория распределенных систем сбора и хранения данных) и Медиацентра МИЭМ, на базе которых ведется значительная часть работ по развитию цифровой среды МИЭМ.
По мере получения опыта и формирования подтвержденных опытом практик обучения база может быть расширена по согласованию с руководством МИЭМ. Тем не менее, подготовленные в Проектной школе студенты вольны устраиваться в любые проекты, а руководители проектов из других лабораторий могут выстраивать различные формы взаимодействия с Проектной школой, в т.ч. на уровне консультаций -- для более адресной подготовки студентов для своих проектов.
На старте ресурсная база Проектной школы -- это Лаборатория видеотехнологий и Медиацентр МИЭМ. Возможно, структурная привязка в МИЭМ будет изменена.
Проектная школа относится к лаборатории Сетевых видеотехнологий и Медиацентру МИЭМ (435, 505).
Для разносторонней оценки и унификации представления проектов, они описываются через достижение различных верифицируемых успехов, к которым относятся:
Участники проекта делятся по статусам С.С.С.Р. на
- Штатных участников проекта (стажёры, сотрудники, руководители)
- Внештатных участников проекта (студентов, выполнявших задачи из проекта). Студенты получают кредиты в проекте, видны как "неактивные" в Кабинете, но не зачислены туда (их нет в приказе и списках Учебного офиса).
Одной из важнейших задач проектов, помимо создания заявленного продукта, является кадровая подготовка. Причем, не обязательно только для поддержки собственной команды: нередко выходцы из одних проектов успешно работают (в т.ч. руководят) другими проектами. Механизм отбора участников проектов в Проектной школе "выносит" отборочные действия за пределы проектной команды и становится возможным видеть фактический результат работы команды проекта с претендентами:
- Сколько было претендентов (студентов)?
- Конверсия студентов в стажёров и в пролетариев
- Конверсия стажёров в сотрудников
- В долгосрочной перспективе: конверсия участников проектов в руководителей (на следующий год).
В KPI фиксируется только динамика изменения статуса каждого причастного к проекту (от студента до руководителя). Но для анализа нужна более детальная информация с персональными и обобщенными данными по скорости движения по статусам, связи с задачами и поведенческими особенностями их выполнения, по метрикам работы лидеров с командами.
Успешный по этому показателю проект имеет высокую конверсию в сотрудников. Долгосрочный успех: сотрудники остались в проектах, при этом есть конверсия в руководителей или хотя бы экспертов.
Измеряемые в KPI величины, обновляются каждый цикл:
- Количество стажёров;
- Количество участников. Если руководитель также и участник проекта, то включая его.
Поскольку кабинет не отличает стажеров от сотрудников, проверка на корректность по сумме этих двух величин: она должна равняться количеству участников проекта в кабинете.
- Промо-ролик, описывающий итоговый продукт (результат текущего проектного года с позиции продукта)
URL 25%
- Презентация для комиссии, показывающая текущий задел, планируемый результат, команду и далее по требованиям проектного офиса.
URL 25%
- Задание в любом формате (wiki-страница, ГОСТовский документ, ...), содержащее качественное описание результата и количественные параметры, по которым можно судить о достижимости результатов.
URL 20%
- Заполнение кабинета: описание проекта должно быть актуальным, часы должны передаваться из трекера (иначе нужно связаться с техподдержкой), состав команды проекта соответствовать реальному (указываются стажеры, сотрудники и руководители, а студенты должны учитываться как "неактивные" в терминологии кабинета).
Да/Нет 10%
- Трекер должен вестись корректно, готовые к проверке задачи зачтены, задачи на видимый горизонт спланированы и разложены по циклам. К выполненным задачам должны быть прикреплены подтверждающие материалы. Структура задач должна соответствовать понятиям epic, user story, task в трекере.
Да/Нет 10%
- Gitlab: репозиторий должен вестись в Gitlab МИЭМ, быть актуальным, содержать документацию разработчика и администратора, где применимо (как минимум -- readme).
Да/Нет 10%
- Демонстрация в подходящем и доступном виде, показывающая созданный задел. Предполагается наличие действующего прототипа (для новых проектов) или внедрение разрабатываемого усовершенствования (для продолжающихся проектов), переход к стадии тестирования, отладки, устранения недостатков и внедрения по месту применения. Если предполагается демонстрация оффлайн или в прямом эфире, то крайне желательно иметь демо-ролик.
URL 35%
- Презентация для экспертов, показывающая актуальный уровень продуктовой готовности, полученный задел, фактически достигнутые результаты и план работ до конца проекта.
URL 35%
- Документация в установленном в данном проекте формате и составе (wiki-страница, ГОСТовский документ, ...),
URL 10%
- Заполнение кабинета: описание проекта должно быть актуальным, часы должны передаваться из трекера (иначе нужно связаться с техподдержкой), состав команды проекта соответствовать реальному (указываются стажеры, сотрудники и руководители, а студенты должны учитываться как "неактивные" в терминологии кабинета).
Да/Нет 10%
- Трекер должен вестись корректно, готовые к проверке задачи зачтены, задачи на видимый горизонт спланированы и разложены по циклам. К выполненным задачам должны быть прикреплены подтверждающие материалы. Структура задач должна соответствовать понятиям epic, user story, task в трекере.
Да/Нет 10%
- Gitlab: репозиторий должен вестись в Gitlab МИЭМ, быть актуальным, содержать документацию разработчика и администратора, где применимо (как минимум -- readme).
Да/Нет 10%
- Презентация для комиссии, в соответствии с требованиями Проектного офиса
URL 35%
- Документация в установленном в данном проекте формате и составе (wiki-страница, ГОСТовский документ, ...),
URL 10%
- Демонстрация в подходящем и доступном виде, показывающая созданный задел и его практическое применение, понимание граничных условий использования. Если предполагается демонстрация оффлайн или в прямом эфире, то крайне желательно иметь демо-ролик.
URL 20%
- Заполнение кабинета: описание проекта должно быть актуальным, часы должны передаваться из трекера (иначе нужно связаться с техподдержкой), состав команды проекта соответствовать реальному (указываются стажеры, сотрудники и руководители, а студенты должны учитываться как "неактивные" в терминологии кабинета).
Да/Нет 10%
- Трекер должен вестись корректно, готовые к проверке задачи зачтены, задачи на видимый горизонт спланированы и разложены по циклам. К выполненным задачам должны быть прикреплены подтверждающие материалы. Структура задач должна соответствовать понятиям epic, user story, task в трекере.
Да/Нет 10%
- Gitlab: репозиторий должен вестись в Gitlab МИЭМ, быть актуальным, содержать документацию разработчика и администратора, где применимо (как минимум -- readme).
Да/Нет 10%
Косвенные метрики результативности проекта -- различные появляющиеся в процессе работы артефакты. Они могут характеризовать не столько продукт, сколько окружение и сопровождающие материалы, создаваемые в процессе работы: РИДы, публикации в научных изданиях и блогах, различные формы внедрения -- "сухой остаток".
К РИДам относятся патенты на полезную модель или изобретение, регистрация ПО и БД, регистрация торгового знака.
В проектах МИЭМ мы имеем дело с регистрацией ПО (реже -- БД) и с патентами на полезную модель. Регистрация ПО и БД носит уведомительный характер, в патентный отдел отправляется набор заполненных форм, содержащих регистрируемый программный код (структуру БД), описание (реферат), служебное задание и данные авторов. Патент на полезную модель -- это обоснованное по новизне и описанное соответствующим образом по назначению представление придуманного устройства. То есть, в отличие от кода, здесь не требуется даже реализация, достаточно проработанного проекта, чтобы вы смогли описать в заявке устройство.
При этом, составное ПО и аппаратные комплексы могут порождать более одного РИДа (отдельные программные модули, отдельные устройства комплекса).
В KPI Проектной школы мы собираем сведения о существующих РИДах и поданных заявках. Указывается период, к которому относится РИД (например, код могли написать в прошлом уч. году, а заявку на РИД подавать в текущем -- такой РИД относится к прошлому уч. году, хотя дата будет в текущем.
Представление по этому измерению включает:
- Существующий задел (РИДы, полученные в предыдущие периоды, включая получаемые в текущем за наработки прошлых лет)
- Планируемый итог текущего периода (проектного года): в форме описываются предполагаемые РИДы и авторы.
- Текущее состояние: сколько из запланированного было фактически получено. К полученным относятся РИДы, по которым подана заявка (есть номер заявки, может не быть номера свидетельства, т.к. задержка в получении свидетельства составляет около 3 месяцев).
Заявленные в плане РИДы должны коррелировать с порождаемыми в проекте артефактами в виде внедрений. Не прямо, но желательно соотносить их.
Про РИДы указывается:
- Проект
- Исходный проект (в случае перепрофилирования проекта, для сохранения задела)
- Период
- Название
- Краткое описание
- Тип (ПО, БД, полезная модель)
- Номер заявки
- Дата заявки
- Номер свидетельства
- Дата свидетельства
- Владелец (по умолчанию НИУ ВШЭ)
- Ответственный автор
- Остальные авторы.
По умолчанию в авторов включается весь фактический состав проекта на момент создания объекта регистрации (стажёры, сотрудники, руководители). Для коммерческих РИД (не ВШЭ) решения принимаются индивидуально.
РИДы фиксируют итоги инженерной и программной разработки, а публикации -- итоги научно-исследовательской деятельности. Вполне возможно, что публикации могут не быть прямо связаны с задачами проекта, они связываются по авторам и общему направлению/тематике.
К публикациям относятся:
- Опубликованные тезисы и доклады на научных и научно-практических конференциях
- Статьи в научных журналах
Для публикации указывается период, к которому относится публикация (часто в текущем году публикации делаются по заделу прошлого года). Для планируемых публикаций указывается тематика (желательно иметь описание) и предполагаемые авторы. Опубликованные материалы должны содержать библиографическую ссылку по ГОСТ и URL публикации. Желательно иметь PDF с обложкой, оглавлением и выходными данными и страницами, где опубликована статья.
Численно публикации для каждого проекта представляются:
- Задел (опубликованные работы за прошлые периоды)
- План (планируемые публикации в текущем периоде, описания, авторы)
- Текущее состояние (что из запланированного было опубликовано).
К опубликованным могут относиться публикации, принятые изданием, если по ним получены выходные данные публикации. Такие публикации следует обновить по получении PDF версии издания.
Про публикации указываются:
- Проект
- Исходный проект (на случай перепрофилирования, для сохранения задела)
- Период
- Дата (месяц, год)
- Тип (тезисы, доклад, статья, ...)
- Название
- Издание
- URL издания
- URL публикации (по правилам ВШЭ, по возможности)
- Ответственный автор (включается в план)
- Остальные авторы.
- Статус (не написано / черновик / оформление / отправлено / рецензирование / верстка / издано)
ВШЭ регистрирует выступления в СМИ своих сотрудников. Это полезная практика, которую стоит перенять: если вы опубликовались на Хабре или выступили на радио или ТВ, то эти сведения вместе со ссылкой сохраняются и ассоциируются с проектом (если тематика выступления или публикации подходит).
По ряду проектов может быть составлен медиаплан. Это относится к проектам, выходящим в коммерческое или иное публичное применение, в таком случае составляется план публикаций и руководитель следит за его выполнением. Численные метрики включают:
- Задел (публикации за прошлые периоды)
- План (планируемые публикации)
- Текущее состояние: что из запланированного уже опубликовано.
Заполняемые данные:
- Проект
- Исходный (на случай перепрофилирования, чтобы не терять задел)
- Период
- Дата
- Название
- СМИ/Блог
- URL
- Ответственный автор (указывается в плане работ)
- Остальные авторы
Это самый неоднозначный пункт: внедрением в разных проектах можно считать очень разные по сложности и трудозатратам объекты, их может быть очень разное число. Но они должны быть.
Критерии внедрения:
- Этим объектом пользуются.
- Этот объект можно показать в любое время в пределах его функциональных задач.
Он не разобран, не выключен, не нужно готовить его демонстрацию толпой разработчиков.
Примеры:
- Устройство. Пусть даже в прототипной версии, но оно стоит там, где предполагается его применение и может быть задействовано по назначению в любой момент -- и выполнит свою задачу.
- Сервис. Запущен, отвечает по заданному адресу, выполняет свою функцию.
- Приложение. Запускается в тех условиях, для которых разработано, работает с ожидаемыми для него входными данными, стабильно выполняет свою функцию.
Объект внедрения может устареть: изменились процессы, интеграционное окружение и тд. В таком случае в таблице указывается, что он неактуален. То есть, он сохраняется в заделе, но не в активе.
Численное представление артефактов внедрения:
- Задел: актуальные объекты из прошлых периодов.
- План: планируемые объекты в текущем периоде.
- Текущее состояние: фактически достигнутый результат.
- Общее: задел+план+неактуальные. То есть, учитываются и те артефакты, которые потеряли свою актуальность.
Про каждый объект указываются:
- Проект
- Исходный проект: на случай перепрофилирования проектов, для прошлых периодов.
- Период
- Дата внедрения
- Клиент
- Место
- Название объекта
- Описание объекта
- Состояние (спроектирован / в запуске / пуско-наладка / работает / неисправен / неактуален)
- Ссылка на объект (для сервисов)
- Ссылка на демо про объект.
Маркетинговые материалы актуальны далеко не только проектам, выходящим на рынок. У них есть другой смысл: детально описанный завершенный продукт, показанный для конечных пользователей помогает прояснить для всех участников проекта детали, о которых они часто не задумываются. Лендинг с разбором сценариев использования продукта, примерная тарифная информация заставляет продумать экономическую модель, посчитать хотя бы себестоимость, и так далее.
Заполняемые данные по всем видам маркетинговых материалов:
- Проект
- Исходный (на случай перепрофилирования проекта, чтобы не терять задел)
- Период
- Дата
- Тип (веб, печатная, презентация, демо)
- Название
- URL
- Целевая аудитория
- Актуальность (да/нет)
- Описание
- Ответственный автор (указывается в плане, фактических авторов может быть больше одного, но здесь авторство не регистрируется).
В сводке для каждого проекта численно указываются только фактически существующие актуальные материалы по следующим категориям:
Создаётся правдоподобный лендинг продукта, содержащий его характеристики, пользовательские сценарии (в представлении покупателю), продумывается модель распространения и ценообразование. Лендинг снабжается изображениями готового продукта, сюда помещается промо-видео, которое готовится для проекта (возможно, и другие).
Для аппаратных проектов уместно иметь даташит с технической информацией о продукте, помимо этого могут быть раздатки "пользовательского" содержания, более близкого к лендингу.
Презентация продукта, а не проекта (не путать с презентациями на представлении проектов или инвестиционным выступлением).
Видеозапись с демонстрацией работающего продукта (или симуляция). Для программных сервисов -- демо-сайт.
Этот раздел может пугать большой и сложной таблицей, хотя, применительно к конкретным проектам количество измерений обычно значительно меньше, чем на общей схеме.
Здесь собраны и приведены к единообразному виду различные шкалы. Они применимы к определенным видам проектов: для одних это основные показатели, для других -- неприменимые, для третьих могут быть взяты отдельные уровни шкал или проект может использовать шкалу по желанию.
Проект оценивается по этим шкалам следующим образом:
- Какой уровень у проекта на старте (текущего этапа)?
- Какой уровень ожидается к защите?
Эти два значения для каждой шкалы фиксируются и задача проекта -- переместиться на запланированный уровень. Не обязательно это конец шкалы.
Каждый уровень должен иметь за собой подтверждение, которое может быть выражено в любой уместной форме, но главное -- быть содержательным. Шкала не оценивает качество материалов. Например, если для научно-исследовательской работы заявляется, что она находится на стадии "литобзора" (уровень 2), то должны быть материалы по постановке проблемы (уровень 1) и литобзор. Качество того и другого -- на совести автора.
Такие шкалы предлагаются проектам для самооценки, по ним же могут работать комиссии, оценивающие проекты. В таком случае защита становится конкретнее -- защищаются позиции, заявленные как готовые и оценивается качество выполнения этих позиций.
Предлагаются следующие шкалы оценки готовности:
- Постановка проблемы
- Литобзор
- Методика исследования
- Сбор материалов / постановка эксперимента
- Анализ материалов / результатов эксперимента
- Обобщение
- Публикация
Engineering Readiness Level (ERL)
- Требования к инженерным ресурсам
- Совместимость и влияние на окружение
- Интеграционные интерфейсы
- Пилотное производство
- Документация CAD/CAM
- Доработка моделей
- Рабочая документация
Technology Readiness Level (TRL)
- Концепция
- Области применения
- Макет
- Лабораторный образец
- Полнофункциональный образец
- Интеграция. Работа в составе системы на месте применения.
- Улучшение и эволюция.
Software Development Life Cycle (SDLC)
За один проектный год этот цикл может проходиться несколько раз.
Если проект составной, то для него может быть полезно сделать по отдельной шкале для каждой части.
- Сбор и анализ требований
- Документирование требований
- Проектирование, архитектура ПО
- Разработка ПО
- Тестирование
- Внедрение и документирование
- Поддержка
- Базовые бизнес-процессы
- Окружение и цепочки подрядчик-заказчик
- Требования к продукту
- Требования к поддержке
- Обученный персонал
- Подготовка сервиса/производства
- Сокрещение издержек, поддержка производства
Commercial Readiness Level (CRL)
- Оценка полезности
- Ценностное предложение, конкурентное окружение
- Поставщики, партнеры, ценовая политика
- Уточненная бизнес-модель
- Точные спецификации продукта
- Предварительный вывод на рынок
- Отработка замечаний, вывод на рынок
- RAT -- Riskiest Assumption Test
- PoC -- Proof of Concept
- Prototype
- MVP -- Minimal Viable Product
- MUP -- Minimal Usable Product
- MLP / MMP -- Minimal Loveable / Marketable Product
- MSP -- Minimal Sellable Product
- Первичный SWOT-анализ
- Патентный анализ, план снижения рисков
- Уточненные преимущества, лицензионная политика
- Стратегия защиты ИС. Регистрация РИД
- Лицензионные договоры
- Соглашения с партнерами
- Мониторинг конкурентов.
К каждому типу проекта описанные в этом разделе шкалы могут относиться полностью (2), не относиться совсем (0) или применимы отдельные уровни, целиком шкала -- по желанию (1).
| Тип проекта |
Научная |
Инженерная |
Технологическая |
Программная |
Операционная |
Рыночная |
Стадия продукта |
Преимущества/риски |
| НИР |
2 |
1 |
1 |
1 |
0 |
0 |
0 |
1 |
| Технология |
1 |
2 |
2 |
1 |
0 |
0 |
1 |
1 |
| АП |
1 |
1 |
2 |
1 |
1 |
1 |
1 |
1 |
| ПО |
1 |
0 |
1 |
2 |
1 |
1 |
2 |
1 |
| Эксплуатация |
0 |
1 |
1 |
1 |
2 |
1 |
0 |
0 |
| Стартап |
1 |
1 |
1 |
1 |
1 |
2 |
2 |
1 |