Валерий Комсков – Введение в профессию бизнес-аналитика. Отправная точка для приобретения опыта (страница 3)
Level 1 support принимает входящие сообщения заказчиков, отвечает на звонки и письма клиента. Идентифицирует клиента, локализует проблему, обычно следует сценарию. Если может, помогает клиенту на своем уровне. Если отсутствуют даже обходные пути, вопрос передается на следующий уровень поддержки.
Level 2 support – это технические специалисты с более продвинутыми навыками общего или специализированного назначения. Тут происходит систематизация, анализ и решение проблем.
Обязанности специалистов второго уровня:
• контакт с персоналом первой линии и помощь ему;
• фиксация и последующий анализ инцидента;
• решение проблемы;
• передача данных по решенной проблеме на первый уровень.
Если проблема, делегированная специалистам второй линии поддержки, уникальна и квалификация персонала не позволяет ее решить, то в установленные регламентом сроки она должна быть передана дальше – на третий уровень.
Level 3 support – это обычно команда разработки, которая лучше всех знает продукт и может помочь в решении проблемы.
Жизненный цикл ПО
Жизненный цикл ПО (SDLC, Software Development Life Cycle) – период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации.
SDLC – это основные этапы, через которые проходит любой программный продукт. Плюс-минус всегда имеют место следующие этапы.
1. Фаза планирования.
2. Фаза сбора требований/анализа.
3. Фаза дизайна/проектирования.
4. Фаза разработки.
5. Фаза тестирования.
6. Фаза внедрения.
7. Фаза поддержки.
ЖЦ продукта начинается с идеи. После того как мы решили создавать новый продукт, мы приступаем к фазе планирования: прорабатываем идею, пишем бизнес-план, проводим анализ конкурентов, рассчитываем предполагаемую прибыль. Далее запускается сам проект по реализации продукта, если руководство решит, что оно того стоит.
После завершения проекта получается продукт, и начинается операционная деятельность по работе с этим продуктом. И далее, если продукт требует изменений, то строится новый бизнес-план и запускается новый проект.
В ЖЦ проекта начальная фаза заключается в переходе идеи в проект, а финальная фаза наступает после подписания актов приема-передачи, когда продукт передается в операционную деятельность. Поэтому можно сказать, что ЖЦ проекта лежит внутри ЖЦ продукта. Это не какие-то строгие правила, стадия планирования и ее содержимое могут быть пропущены: например, если продукт просто требует доработок или новой функциональности.
Поэтому хотелось бы отметить, что для продукта и проекта этапы ЖЦ могут отличаться. Это стоит понимать и учитывать.
Жизненный цикл проекта
Любой ЖЦ проекта включает в себя четыре фазы.
1. Начальная – фаза перехода идеи в проект. На этой стадии обычно пишется устав проекта, определяются первичные критерии успеха проекта. Также на этой фазе формируются ключевые роли в проекте: менеджер проекта, владелец, спонсор.
2. Подготовка и организация. На этом этапе выделяются ресурсы для проекта, создается команда, составляется план проекта, определяется бюджет, а также ищутся поставщики услуг, если они необходимы.
3. Выполнение работ. Это фаза создания проекта. Именно на этом этапе создается продукт. Менеджер проекта получает отчеты о ходе выполнения проекта и контролирует процесс. Далее происходит финальное одобрение продукта перед подписанием акта приема работ.
4. Финальная стадия. Основная суть этой фазы – подвести итоги после завершения проекта, подписать акт приема-передачи и передать продукт в операционную деятельность.
На графике показано, как в зависимости от стадии проекта меняются такие показатели, как:
• стоимость проекта и численность персоналом – вовлеченность ресурсов (кривая 1);
• влияние заинтересованных сторон, неопределенность проекта, возможность рисков (кривая 2);
• стоимость изменений по проекту (кривая 3).
1. Мы видим, что самая низкая стоимость изменений – в начале, на этом этапе легче всего повлиять на изменение проекта. Именно здесь определяются цели проекта. Под эти цели выбирается оптимальное решение. Если цели изменятся, то может оказаться, что выбранное решение им не соответствует, и у заказчиков начнутся проблемы.
Пример
Вы решили построить себе дом. Так как ваши первичные запросы были небольшими, вы выбрали простой вариант и начали строить каркасный дом на свайном фундаменте. Но под конец строительства вы вдруг решаете, что неплохо было бы сделать в доме камин. Каркасные дома на сваях не рассчитаны на большой вес, и камин там просто так сделать не получится. Для этого нужно залить под дом специальный фундамент. Следовательно, строителям необходимо разобрать пол. Они ползают под домом, чтобы вырыть яму под фундамент. А вы попадаете на деньги из-за сложности работ.
2. Максимальные затраты ресурсов в проекте наблюдаются в период его выполнения (ближе к концу). Это связано с тем, что к этому времени большинство спорных моментов проекта уже прояснилось, команда знает, что делать, и активно работает. Также именно на этих этапах во многих проектах возникает понимание того, что команда опаздывает, и подключаются все возможные ресурсы для работы.
Этап планирования
На этой стадии нужно максимально снизить неопределенность.
Фаза планирования – наиболее критичный этап в создании успешной системы. Во время нее вы точно решаете, что хотите сделать и какие проблемы решить. Для этого вам необходимо:
• определить проблемы, цели, задачи и ресурсы (такие, как персонал и издержки – важно заранее найти людей, которые в дальнейшем будут работать с проектом, и включить их в проектную команду; инфраструктурные ресурсы);
• рассмотреть варианты альтернативных решений на встречах с клиентами, поставщиками, консультантами и сотрудниками;
• понять, как сделать ваш продукт лучше, чем у конкурентов;
• провести анализ осуществимости (feasibility study), направленный на изучение возможности создания продукта в соответствии с заданными требованиями заказчика и выделенными ресурсами.
Ведущую роль в разработке концепции играет бизнес-аналитик (или Product Manager), занимающийся этим продуктом. Для определения потребностей заказчика/рынка в течение всего срока разработки концепции проводится интенсивная работа с инвестором проекта, чтобы выработать единое ви´дение будущего продукта. Если это заказной продукт, то инвестор – конечный заказчик. Если продукт предназначен для открытого рынка, то ответственны за него учредители компании или совет директоров. Далее на основе изученных и систематизированных требований аналитик вместе с командой экспертов создает образ будущего продукта. В конце аналитик и экспертная команда определяют границы проекта, которые должны содержать ориентировочные сроки реализации и бюджет продукта.
Результатом разработки концепции является Product Vision Document (если продукт разрабатывается под заказ) или Marketing Requirement Document (если продукт предназначен для открытого рынка). Эти документы содержат подробную информацию о требованиях заказчика, возможностях продукта, которые должны удовлетворять эти требования, а также ориентировочные сроки его реализации и бюджет. Различие между PVD и MRD состоит в том, что в MRD обычно более детально описаны целевые сегменты рынка и сделан детальный обзор конкурентов.
После разработки концепции продукта делается вывод о целесообразности создания продукта. Если принято положительное решение, пишется устав проекта по разработке продукта. PVD/MRD – входной документ устава проекта, описывающий содержание работ.
Входы: идея, концепция, экономическое обоснование.
Выходы: устав проекта, дорожная карта работ проекта, план управления рисками, список заинтересованных сторон, ресурсный план, план по тестированию.
Этап анализа требований
На этом этапе нужно четко определить и задокументировать требования к продукту и утвердить их.
Входы: реестр заинтересованных лиц, дорожная карта.
Выходы: техническое задание.
Этап проектирования
Эта фаза наступает после того, как вы хорошо поняли требования потребителя. На этом этапе определяются элементы системы, компоненты, уровень безопасности, модули, архитектура, различные интерфейсы и типы данных, которыми оперирует система. Определяется набор технологий, фреймворков, требования к хранению информации (в плане базы данных), а также конкретная архитектура с точки зрения компонентов, взаимосвязей между ними, потоков данных.
Входы: техническое задание.
Выходы: архитектурное решение, спецификация требований к ПО, дизайн-макеты, тест-кейсы.
Этап разработки
Это и есть собственно процесс разработки системы, когда ее дизайн уже полностью завершен и представлен наглядно. В жизненном цикле разработки системы именно на этом этапе пишется код.
Входы: архитектурное решение, спецификация требований к ПО, дизайн-макеты, тест-кейсы.
Выходы: работающая версия ПО, готовая к тестам.
Этап тестирования
На этом этапе проверяется работоспособность системы.
Важный момент: поиск дефектов, их регистрация, отслеживание, исправление и повторное тестирование продолжаются до тех пор, пока не будут исправлены все дефекты определенной критичности, уровень которой соответствует договоренностям или определяется менеджером. Либо пока продукт не достигнет стандартов качества, оговоренных на этапе анализа.