Добавил:

ivanov666 Опубликованный материал нарушает ваши авторские права? Сообщите нам.

Вуз:

Башкирский Государственный Аграрный Университет

Предмет:

[НЕСОРТИРОВАННОЕ]

Файл:

Анализ контекста деятельности в управлении высокотехнологичными проектами. Учебное пособие

.pdf

Скачиваний:

Добавлен:

06.09.2026

Размер:

1 Мб

Скачать

☆

<<< < Предыдущая 1 2 3 4 56 / 116 7 8 9 10 11 > Следующая >>>

концепции разработки продукта проекта в целом. Связь концепции про-

дукта и границ выпусков показана на рис. 17.

Концепция продукта

ИТ-проекта

Границы проекта

для выпуска 1

Развитие проекта при гибком управлении проектом

Границы проекта

для выпуска 2

Границы проекта

для выпуска N

Рис. 17. Концепция продукта и границ выпусков

Следует обратить внимание на изменение роли аналитика в проектах гибкой разработки (Agile) [26]. При этом в проекте будут важны как функции бизнес-аналитика, так и функции владельца продукта (product owner), но в команде проекта должен доминировать сотрудник, выполняющий роль владельца продукта. Иногда на него дополнительно возлагается исполнение роли аналитика. В рамках

своей роли он должен создавать концепции продукта, доводить ограничения до исполнителей, определять приоритеты резерва (backlog) проекта и принимать конечные решения по продукту. Совмещение двух ролей создаст очень сложную роль для исполнения, поэтому в проектах роли бизнес-аналитика и владельца продукта следует разделять. Сложно найти сотрудника, который мог бы

обладать всеми навыками бизнес-аналитика и владельца продукта, а также временем для выполнения всех необходимых действий этих ролей.

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

пользователей во время разработки проекта, очень ценна для проекта.

Следует помнить, что задачи роли бизнес-аналитика должны выпол-

няться независимо от способа реализации проекта. Наличие

в команде бизнес-аналитика или людей, обладающих навыками бизнес-аналитика, существенно снизит риски в реализации проекта. При переходе на гибкую разработку бизнес-аналитик должен приспособить свою деятельность к среде гибкой разработки, прежде всего ориентированной на использовании продукта в деятельности пользователя. Главное – поддерживать постоянную обратную связь с

пользователями для определения

направления дальнейшей разработки проекта.

В новых условиях в рамках его компетенции будут следующие за-

дачи.

1.  Определение облегченного гибкого процесса работы с требовани-

ями. Следует видоизменять процесс, как того требует проект.

2.  Приведение объема документации требований в соответствие с требованием используемого метода. Не следует документировать все требования в спецификации вплоть до самого нижнего уровня, но нельзя также полностью отказываться от документирования требований.

3.  Определение подхода к документированию резерва. Задача – создание комфортных условий общения, чтобы обеспечить частое обсуждение заинтересованными лицами потребностей, вопросов и сложностей, связанных с управлением требованиями.

4.  Содействие менеджеру проекта и исполнителю роли владельца продукта в правильном отражении в резерве продукта потребностей клиента.

Организация необходимых взаимодействий для назначения

приоритетов требований в резерве.

5.  Помощь владельцу продукта во взаимодействии с клиентами, которые изменяют свое мнение о требованиях и приоритетах. Фиксация согласованных с клиентами изменений.

6.  Взаимодействие с членами команды проекта для определения влияния вносимых изменений на текущую итерацию и планы выпуска.

2.4. СТАРТАПЫ КАК РАЗНОВИДНОСТЬ

ИТ-ПРОЕКТОВ

К отдельной разновидности ИТ-проектов относят стартапы (от англ.

startup) в сфере информационных технологий – технологические

стартапы в области искусственного интеллекта, интернета вещей и др. Стартап понимается как проект создания эффективного нового бизнеса в ИТ-сфере. Он всегда создается как структура, существующая для поиска воспроизводимой, масштабируемой и рентабельной бизнес-модели [21, 27, 29, 45]. Иногда этим термином в организациях обозначают проекты создания инновационных продуктов или услуг в условиях высокой неопределенности. В отличие от проектов, выполняемых в проектно-ориентированных и проектно-зависимых организациях, для рассматриваемой разновидности проектов не предполагается установления сроков их исполнения.

Таким образом, стартап – это новый коммерческий проект, который

характеризуется следующими особенностями:

 наличием уникальной идеи;

 ориентацией команды проекта на инновации;  отсутствием на рынке аналогов готового продукта.

Стартап – это также новый бизнес и всегда весьма рискованное предприятие, которое очень часто терпит неудачу. Риск связан с тем, что немногие его инициаторы четко понимают, что и зачем они собираются делать; владеют технологией запуска нового бизнеса; ходимые компетенции в вопросах управления; могут контролировать финансовые потоки в создаваемом бизнесе и способны планировать свои действия. Однако практика показала, что стартапы зачастую решают глобальные проблемы и создают новые рынки.

Следует обратить внимание на тот факт, что для стартапа важную роль играет наличие экосистемы для такого рода проектов стартапа:

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

 сообщество единомышленников – специалистов, готовых помочь с организацией бизнеса, инвесторов и различных организаций, готовых поддерживать стартапы.

Чтобы запустить стартап, необходимо иметь:

 новаторскую бизнес-модель;

 источники финансирования;

имеют необ-

. Экосистема

 эффективную маркетинговую стратегию и каналы продвижения;

команду энтузиастов, реализующих проект.



Стартап обычно инициируется одним лицом или группой предпринимателей. Цель – создать новый продукт или услугу с высоким спросом. Все стартапы на определенных этапах своего жизненного цикла должны пониматься и управляться так же, как инновационные ИТ-проекты.

Сравним стартап с созданием традиционного бизнеса. Особенности стартапа как проекта создания нового бизнеса в ИТ-сфере – бизнеса, которого нет на рынке, или бизнеса, сильно отличающегося от существующего, – представлены в табл. 1. Приведено сравнение стартапа с созданием традиционного бизнеса, где традиционный – это бизнес, аналоги которого существуют на рынке

В 2010 году была переработана модель канвы Остервальдера (см. рис. 4) в модель Lean Canvas (шаблон стартапа) на основе принципов подхода Lean Startup. Предложенный шаблон – это гибкий инструмент, позволяющий визуализировать идею, фокусируясь на

продуктов или услуг.

потребностях клиента. На рис. 18 показан состав модели Lean Canvas [16, 27].

Таблица 1

Сравнение стартапа с организацией традиционного бизнеса

Стартапы в ИТ-сфере Традиционный бизнес в ИТ-сфере

Инновационность. Начинается из инновационной идеи или нового подхода к решению проблемы. Фокусируется на создании новых продуктов, услуг или бизнес-модели

Высокий риск, связанный с большой неопределенностью продукта и контекста проекта

Проблема финансирования. Венчурный капитал и другие источники

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

Команда энтузиастов. Различные навыки, гибкость (быстрая адаптация к изменениям)

Гибкость. Быстро адаптируется и меняет направление (пивот)

Культура. Неформальная, динамичная культура

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

Большая стабильность и предсказуемость

Консервативные источники финансирования

Стратегия постепенного роста и получения стабильной прибыли

Команда опытных профессионалов в конкретной сфере бизнеса

Консервативен в своих изменениях

Структурированная корпоративная культура

Выход из проектной модели управления.

На определенном этапе стремление к продаже созданного бизнеса или выход на IPO

Нацеленность на долгосрочное развитие и управление

LEAN CANVAS

2. Проблема

и существующие

альтернативы

ее решения

7. Структура издержек 6. Источники доходов

4. Решение 3. Уникальная ценность

8. Ключевые метрики

Рис. 18. Состав модели Lean Canvas

9. Скрытое

преимущество

5. Каналы

1. Сегменты

клиентов

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

Фокусировка на клиенте означает, что не следует пытаться охватить слишком большой сегмент целевой аудитории. Если идея стартапа охватывает несколько сегментов целевой аудитории, то лучше создать шаблон

для каждого сегмента. У каждого сегмента клиентов должна быть выделена объединяющая их проблема, которая им мешает, раздражает их, расстраивает и т. п. Идея стартапа заключается в решении этой проблемы.

Всегда помните, что если у пользователя нет проблемы – значит, ему не нужен ваш продукт.

Формулирование уникального ценностного предложения поможет определить,

для какого сегмента целевой аудитории предназначен про-

дукт. Здесь следует ответить на следующие вопросы.

1.  В чем выгода вашего ценностного предложения?

2.  Почему пользователи должны выбрать ваш продукт, а не продукт

конкурентов?

3.  Готовы ли клиенты платить за этот продукт?

4.  Каким клиентам можно будет передать версию минимально жизне-

способного продукта (Minimum Viable Product, MVP) на

тестирование?

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

Существует сложившаяся на практике модель этапов развития успешного стартапа [21, 27, 45]. Каждый этап имеет свои особенности и цели. Их понимание важно для всех, кто вовлечен в экосистему конкретного проекта. Главное – формировать реалистичные ожидания, принимая стратегические решения о запуске проекта или решения о необходимости существенного изменения бизнес-модели.

В жизненном цикле

большинства успешных стартапов можно выде-

лить следующие основные этапы.

1.  Идея и ее первичное исследование. На этом этапе формулируется идея и проводится первичное исследование рынка. Цель – определить, есть ли у идеи потенциал и какую проблему она решает. Самое главное: здесь следует выдвигать и исследовать только четко проработанные и

продуманные предположения. Предположение (assumption) – это утверждение, которое предполагается верным в отсутствие знаний или доказательств иного [26]. Следует документировать все сделанные предположения. Данный документ будет определять начальное представление о концепции и границах проекта. Часто предположения одних лиц могут не разделять другие стороны.

Сделанные представления о важнейших зависимостях реализуемой

идеи проекта от внешних

факторов, т. е. факторах контекста проекта, также следует документировать. В этом документе фиксируют зависимость от изменения отраслевых стандартов или предписаний регулирующих органов, возможного появления других (конкурирующих) проектов, поведения сторонних поставщиков или предполагаемых партнеров по разработке и др. Заметим, что сделанные предположения и зафиксированные зависимости следует понимать как

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

Предлагаемая идея или выдвинутая гипотеза (предположение)

должны удовлетворять следующим требованиям.

1.  Точность и конкретность. Идея должна формулироваться четко,

с указанием временного промежутка на ее первичную

проверку.

2.  Измеримость. Следует указать, можно ли получить результат

проверки идеи и как это сделать.

3.  Достижимость. Следует убедиться, что идея достижима.

4.  Наличие составных частей. Не стоит за один раз исследовать гло-

бальные цели, проверять и тестировать предположения, которые требуют больших затрат времени и ресурсов. Следует разбивать идею или предположения

на удобные для проверки части.

5.  Соответствие цели. Не следует рассматривать предположения,

которые не приближают к достижению цели проекта в целом.

2.  Валидация. Стартап создает минимально жизнеспособный продукт и тестирует его на реальных пользователях. Это помогает подтвердить спрос и получить обратную связь для улучшения продукта.

3.  Ранний рост. Созданная в рамках проекта организация начинает активно

привлекать клиентов, получать обратную связь, оптимизировать предлагаемый продукт или услугу. На этом этапе важно выбрать правильную бизнес-модель и начать масштабирование бизнеса. Масштабирование в виде отдельного этапа может быть выделено после этапа раннего роста. На этом этапе организация активно расширяет свое присутствие на рынке.

4.  Расширение. Выход проекта на

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

  Зрелость. Организация, реализующая идею стартапа, становится стабильной, с устоявшимися процессами и доходами. На этом этапе организация перестает быть стартапом в классическом его понимании и должна переходить на одну из моделей управления традиционным бизнесом.

6.  Выход. Это может быть продажа сформировавшегося бизнеса, слияние с другим бизнесом или выход на IPO. Некоторые основатели стартапа могут выбрать путь самостоятельного долгосрочного независимого развития бизнеса.

Успех стартапа во многом зависит от способности команды адаптироваться к меняющимся условиям и эффективно преодолевать трудности на каждом этапе его развития, поэтому следует отметить следующее:

 на любой стадии стартап может осуществить значительное изме- нение бизнес-модели или продукта

в ответ на рыночные реалии;

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

Мир, всецело управляемый наукой, был бы адом на Земле. Верность рациональному мышлению вполне уместна в лаборатории.

Д. Чопра

3. КОНТЕКСТ ИТ-ПРОЕКТА

Все организации действуют в определенной среде, как организации – исполнители проекта, так и организации, заказывающие проекты. На постановку целей и способность организации достигать поставленных целей влияют многочисленные факторы ее внешней и внутренней среды. Эти факторы могут как способствовать достижению поставленных целей ИТ-проекта, так и затруднять их реализацию.

3.1. УСЛОВИЯ ДОГОВОРА КАК ФАКТОРЫ КОНТЕКСТА

Анализ контекста проекта необходимо начинать с согласованного понимания условий будущего договора на разработку ИТ-проекта. Техническое задание конкретного проекта является результатом определенной деятельности и частью договора. Разработчикам проекта следует понимать, чьи интересы учтены в техническом задании, а также природу сделанных допущений и ром. Таким образом, условия договора на разработку ИТ-проекта, как показано на рис. 19, – это существенный фактор контекста деятельности команды проекта. Дадим краткую характеристику выделенных факторов контекста, указав на возможные риски появления дополнительной неопределенности в реализации проекта.

На этапах формирования согласованной концепции будущего проекта, в процессе ее

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

ограничений, предусмотренных догово-

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

Существенные факторы контекста деятельности команды проекта в условиях договора

Разработчик технического задания на проект и качество технического задания

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

на разработку ИТ-проекта

Работа с конфиденциальной информацией. Введение стороной договора режима

Особенности процессов сдачи-приемки результатов проекта, тестирования

Порядок несения сопутствующих разработке расходов на использование средств,

необходимых как для разработки продукта, так и для его эксплуатации

Дополнительные ситуации к предусмотренным законодательством ситуациям

Исключительные права на разработанное в проекте программное обеспечение –

Требования к использованию в разрабатываемом программном обеспечении

сторонних компонентов кода, на который необходимо иметь лицензию, и др.

тайны на используемую в проекте информацию

и устранения замечаний

одностороннего прекращения реализации проекта

передача прав заказчику или они остаются у разработчика

Рис. 19. Условия договора как существенные факторы контекста

Существуют различные стандарты на разработку технического задания (ТЗ) в сфере создания автоматизированных систем (АС) и их элементов. Есть стандарты на разработку ТЗ на создание автоматизированной системы (ГОСТ 34.602–2020) [53]; на «Виды, комплектность и обозначение документов при создании автоматизированных систем» (ГОСТ 34.201–2020) [54]; Единой системы конструкторской документации (ЕСКД) на «Виды

и комплектность конструкторских документов»

(ГОСТ 2.102–2023) [55]; Единой системы программной документации (ЕСПД) на программные средства (ГОСТ 19.201) [56].

ГОСТ 34.201–2020 определяет, что «В случае отсутствия выделения стадий (или деления на другие стадии) при создании АС перечень разрабатываемой документации и сроки ее представления определяются техническим заданием или совместным решением заказчика и разработчика» [54]. Такой подход к разработке ТЗ на проект на практике встречается чаще всего. Как было отмечено в разделе 2, сложным ИТпроектам присуща значительная неопределенность в управлении их разработкой. Для таких проектов необходимо использовать методологию гибкого управления, в рамках которой не предполагается разработка предельно детализированного технического задания.

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

для использования большим количеством пользователей без привязки к какой-либо организации. Поэтому если разрабатывается ТЗ и документация на ПО, создаваемое под конкретную организацию, то используется серия стандартов ГОСТ 34. Если разрабатывается документация на программу для массового применения, то используется серия ГОСТ 19. При этом пункты технического задания и требования

к документированию на ос-

нове ГОСТ 34 и ГОСТ 19 существенно отличаются.

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

Таким образом, ТЗ

и договор на разработку проекта должны составлять единое целое. Правило, которым следует руководствоваться сторонам при заключении договора: его следует составлять с таким расчетом, что он может попасть в суд, где судье будут представлены результаты экспертизы – результаты сравнения фактически выполненного объема работ и объема работ, предусмотренного договором и техническим

заданием. Экспертиза будет касаться оценки фактически выполненного объема работ по договору и его соответствия требованиям ТЗ. Если ТЗ некачественное, то любой результат работы исполнителя легко можно будет трактовать как соответствующий ТЗ.

Указанные на рис. 19 факторы должны быть прописаны в договоре

таким образом, чтобы судья (сторонний наблюдатель) мог однозначно

<<< < Предыдущая 1 2 3 4 56 / 116 7 8 9 10 11 > Следующая >>>

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]