Чат поддержки

Практикум
Привет! Это поддержка Практикума 👋 Если что-то не получается — постараемся помочь. Пишите в чат или выберите другой способ связи

пт, 2 декабряв 17:21

Мы уже начали заниматься вашим вопросом, ответим в ближайшее время

Практикум

Здравствуйте!

Поддержка не сможет помочь с вопросами, связанными с теорией или задачам из курса «Системный аналитик» — в этой ситуации рекомендуем вам обратиться к вашему преподавателю в чате в Slack.

Если же у вас возникнут иные вопросы — обязательно пишите, будем рады помочь :)

17:24

Выбрать способ связи

Перейти в профиль Практикума

Поменять когорту

Выйти из профиля

Добавить аккаунт

Дополнительные материалы

спринт Дополнительные материалы

Как учиться на курсе

4/4

К проекту 2

0/1

К спринту "Реализация системы"

2/2

Техника BDD

CI/CD

К спринту "Поддержка, обслуживание и оценка результатов"

1/1

Оценка проекта

SQL и системы визуализации

11/11

SQL и Python

7/10

Мягкие навыки аналитика. Коммуникация и активное слушание

4/4

Мягкие навыки аналитика. Постановка задач

5/5

Мягкие навыки аналитика. Планирование

4/4

Пригласить друзей

Оценка проекта

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

Оценка проекта

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

Оценка проекта позволяет:

Понять, что было сделано хорошо, и что поспособствовало успеху.

Понять, что пошло не так и почему. Определить, что команда должна сделать, чтоб в будущем не повторять подобных ошибок.

Определить точки роста и дальнейшего развития команды.

Каждая организация и проектная команда выбирает свои способы провести оценку проекта. Формат сильно зависит от корпоративной политики.

Независимо от формата, оценка проекта сосредотачивается на двух направлениях:

Оценка работы проектной команды.

Оценка качества разработанного ПО.

Эти составляющие тесно соприкасаются друг с другом и позволяют оценить результаты проекта с разных сторон.

Оценка работы проектной команды

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

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

Если цель проекта не достигнута, то команда должна должна ответить себе на вопросы:

почему так произошло?

что можно исправить в работе команды, чтоб это больше не повторялось?

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

Команда будет чаще достигать целей проекта, если будет регулярно:

работать над ошибками: исправлять и не допускать повторения тех, что случились на прошлых проектах;

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

своевременно переходить к новым, более эффективным практикам ведения работ.

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

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

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

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

Роль системного аналитика в оценке работы проектной команды

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

Именно из-за своего уникального положения на проекте аналитик может:

выделить основные проблемы, возникающие при взаимодействии с заказчиком;

предложить улучшения для внутренних процессов работы команды;

определить прошлые удачные решения и переиспользовать их в новых условиях.

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

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

Чтобы определить причины возможных проблем в процессе разработки требований к ПО, системному аналитику следует провести анализ первопричин (от английского термина root cause analysis).

Анализ первопричин

Упражнение анализа первопричин помогает определить, какие факторы и события оказали влияние на ход проекта и привели к имеющимся проблемам. Это упражнение подразумевает вопросы «почему это произошло?» или +из-за чего это произошло?», заданные несколько раз. Анализ первопричин нужно проводить перед внедрением изменений в организации. Если этого не сделать, то проектная команда может столкнуться с ситуацией, когда новый процесс не устраняет существующую проблему.

Разберём два инструмент анализа первопричин:

техника «Пять почему»;

Диаграмма Ишикавы.

Техника «Пять почему»

Основная задача этой техники — поиск первопричины возникновения дефекта или проблемы с помощью повторения одного вопроса: «Почему?».

Пример

Цена слишком высокая → Почему? → Она не соответствует качеству товаров → Почему? → Товары сделаны из дешёвого материала → Почему? → Собственник магазина решил сэкономить на пробной партии товаров.

Команда решила определить первопричину ошибки с помощью техники «Пять почему». Участники команды последовательно задали пять вопросов. Перед вами пять ответов на вопрос «Почему?». В выпадающем списке выберите порядковый номер ответа.

Каждая задача по тестированию требовала в два раза больше времени, чем планировалось. Почему?

По умолчанию, время ожидания ответа сервера составляет 2 секунды. Но сервер отвечал дольше 2 секунд.

2

Это соответствует ответу на вопрос «Почему тестировщики регулярно получали ошибку HTTP 504 «Cервер не может получить ответ вовремя”?»

Потому что использовалась стандартная конфигурация сервера с небольшой пропускной способностью.

4

Это соответствует ответу на вопрос «Почему время ответа сервера увеличилось?»

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

5

Это соответствует ответу на вопрос «Почему использовалась стандартная конфигурация сервера с небольшой пропускной способностью?»

Потому что приходилось несколько раз проводить один и тот же тест, т.к. тестировщики регулярно получали ошибку HTTP 504 «Cервер не может получить ответ вовремя».

1

Это соответствует ответу на вопрос «Почему каждая задача по тестированию требовала в два раза больше времени, чем планировалось?»

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

3

Это соответствует ответу на вопрос «Почему сервер отвечал дольше, чем ожидалось?»

Начать заново

Диаграмма Ишикавы

Инструмент, представленный японским профессором менеджмента Каору Ишикава, позволяет графически исследовать и определить основные причинно-следственные связи между факторами и последствиями возникшей проблемы.

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

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

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

Так выглядит диаграмма Ишикавы:

Как пользоваться диаграммой Ишикавы

Для составления диаграммы Ишикавы нужно сделать 5 шагов:

Обозначить проблему. Нарисовать прямоугольник («голову рыбы») и указать в нём проблему. Например: проектная команда не выполнила обязательства по разработке ПО и не уложилась в плановые сроки:

Выявить категории причин, которые могли повлиять на возникновение проблемы.

Например: люди, процессы внутри команды, оборудование, рабочая обстановка, оснащение, методологии процессы работы компании. Чтобы выявить категории, можно задать вопрос: «Что могло повлиять на невыполнение сроков?».

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

Определить причины в каждой категории. Нужно к каждой категории задать вопрос: «Почему это произошло?». Например, рабочее оборудование, выданное команде, могло быть устаревшим или маломощным.

Определить наиболее вероятные причины. По возможности, такие причины можно объединить в группу. На рисунке наиболее вероятные причины выделены зелёным цветом, а причины из категорий «обстановка» и «оснащений» определена в одну группу.

Анализ приоритетных причин. Например, при помощи техники анализа первопричин «Пять почему», которая описана выше.

Расположите в верном порядке шаги создания диаграммы Ишикавы.

Выявить конкретные причины для каждой категории

Третий шаг

Генерация идей об истинных причинах возникновения проблемы — это третий шаг.

Выявить основные категории причин, повлиявших на возникновение проблемы

Второй шаг

Чтобы дойти до конкретных причин, нужно сперва обозначить области поиска — это второй шаг.

Приоритизировать причины и выделить ключевые

Четвёртый шаг

После генерации возможных причин их стоит приоритизировать — это четвёртый шаг.

Обозначить проблему

Первый шаг

Чтобы проанализировать проблему, нужно сперва сформулировать её — это первый шаг.

Более подробно проанализировать ключевые причины

Пятый шаг

Детальное рассмотрение ключевых причин — это последний, пятый шаг.

Начать заново

Потренируйтесь составлять диаграмму Ишикавы.

Перед вами стоит проблема: «Молоко прокисает в холодильнике». На диаграмме уже изображены некоторые категории проблем и несколько причин. Дополните диаграмму недостающими элементами:

Для создания диаграммы можно использовать уже знакомое вам приложение Draw IO https://www.diagrams.net/

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

Посмотреть решение

Принципы улучшения процесса

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

Проектной команде стоит руководствоваться следующими принципами улучшения процесса:

люди и организации меняются только когда есть стимул для изменений;

чтобы изменения помогали достигать целей, эти цели должны быть чётко определены;

улучшения процессов должны быть постепенными;

процессы нужно улучшать регулярно.

Оценка качества разработанного ПО

Качество ПО — совокупность требований к ПО, которые обеспечивают его пригодность и удовлетворяют потребности пользователей этого ПО.

Соответственно, качественное ПО — это такое ПО, которое соответствует заявленным требованиям, пригодно для использования и удовлетворяет потребности пользователей.

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

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

Критерии оценки качества ПО

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

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

Готовиться к оценке качества ПО нужно начинать ещё на ранних стадиях проекта, когда организация определяется с бизнес-требованиями и проводит анализ осуществимости доработок. То есть ещё до начала разработки нужно определиться, по каким критериям будет оцениваться качество внедрённого ПО.

В конце проекта, когда ПО внедрено, организация возвращается к критериям оценки ПО и проводит анализ, достигнуты ли ожидаемые результаты.

Критерии оценки качества разработанного ПО можно разделить на две категории:

Соответствие бизнес-требованиям.

Ключевая идея — сравнить изначальные бизнес-требования, ожидаемую бизнес-выгоду от ПО с реальными бизнес-выгодами, которые организация получила от внедрения ПО. Дополнительно организация определяет для себя, соответствовали ли выгоды от внедрения затраченным ресурсам.

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

Характеристики, которым должно соответствовать качественное ПО:

Функциональность. ПО должно:

быть функционально исправным;

соответствовать отраслевым, технологическим стандартам, а также стандартам организации;

быть функционально совместимым с ИТ-окружением организации, где оно внедряется.

Надежность. ПО должно:

быть безопасным с точки зрения защиты персональных данных пользователей, коммерческих и бизнес-данных;

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

быть устойчивым к нагрузке и отказам.

Удобство использования. ПО должно быть:

удобным в работе;

понятным в изучении.

Удобство сопровождения. ПО должно быть:

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

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

Эффективность. ПО должно быть:

эффективным по времени — выполнять поставленные задачи с достаточной (для контекста проекта, организации или предметной области) скоростью;

эффективным по ресурсам — утилизировать релевантные (выполняемым задачам) аппаратные мощности;

эффективным по возможности расширения — способность и готовность ПО к быстрому горизонтальному масштабированию.

Роль системного аналитика в разработке качественного ПО

Оценка качества ПО связана с работой системного аналитика.

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

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

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

Распределите характеристики по их основным критериям, которые используются для оценки качества ПО

Приложение соответствует отраслевым, технологическим стандартам, а также стандартам организации

Функциональность

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

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

Надёжность

Если предусмотрены процедуры возврата работоспособности, то можно говорить о соответствии критерию надежности ПО

Интерфейс приложения интуитивно понятен. Есть подробное руководство пользователя.

Удобство пользования

Если ПО понятно в изучении, значит оно отвечает требованиям удобства пользования.

Настроены мониторинг и логирование работы приложения

Удобство сопровождения

Такое ПО удобно в сопровождении. Мониторинг ПО позволяет фиксировать все сбои, а логи помогут команде сопровождения анализировать возникшие проблемы.

Проведена качественная рекламная кампания нового приложения в социальных сетях

Не является характеристикой качества ПО

Рекламная компания может способствовать успеху приложения, но на его качество она не влияет

Начать заново

Подведём итоги

В этом уроке мы познакомились с примерами оценки работы проектной команды и оценки качества разработанного ПО.

Оценка проекта позволяет:

Понять, что поспособствовало успеху и сохранить эти практики.

Понять, что пошло не так и почему. Определить, что команда должна сделать, чтоб в будущем не повторять подобных ошибок.

Определить точки роста и дальнейшего развития команды.

Проектная команда работает качественно, если выполняет проект в полном объеме в рамках бюджета и в сроки, оговоренные с заказчиком на старте.

Оценку работы проектной команды можно выполнить с помощью анализа первопричин:

техники «Пять почему»;

диаграммы Ишикавы («рыбья кость»).

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

ПО считается качественным, если соответствует заявленным требованиям, пригодно для использования и удовлетворяет потребности пользователей.

Оценить качеств ПО можно по следующим критериям:

соответствие бизнес-требованиям и требованиям пользователей;

функциональность;

надёжность;

удобство пользования;

удобство сопровождения;

эффективность.

К следующей теме
Краткий пересказ урока
beta

Курсы

Вводный модуль

Понимание профессии системного аналитика

Разработка требований

Проект 1. Спецификация требований ко второму релизу Chatty

SQL для аналитиков

Моделирование данных

Проект 2. Моделирование данных и работа с базой данных интернет-магазина «Накарабине»

Моделирование процессов

Пользовательские интерфейсы

Agile-практики

Проект 3. Бэклог приложения для сети клиник «Вита»

Трудоустройство

Архитектура системы

Программные интерфейсы

Проект 4

Реализация системы

Поддержка, обслуживание и оценка результатов

Дипломный проект

Дополнительные материалы

x