Критерии приемки продукта

Видео:Acceptance Criteria / Критерии приемки в ScrumСкачать

Документирование объёмов работ проекта

Итак, мы формально и документально запустили проект. Теперь нужно разобраться, как выявить все объёмы работ нашего проекта и правильно их оформить. В классике проектного управления это называется «Планирование содержания проекта». Я же расскажу, как это «содержание» документировать.

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

Выяснить и оформить требования

Требования бывают двух типов:

1. Требования к проекту – т.е. как мы должны управлять проектом.
2. Требования к продукту – т.е. что мы должны получить в итоге проекта.

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

Все требования нужно дискретно выразить в Реестре требований и в Документации по требованиям. Что это за документы и чем они отличаются?

Реестр требований — это таблица с перечнем и ключевыми характеристиками всех требований к проекту и продукту.

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

Более того, Реестр требований позволяет организовать грамотное управление изменениями в проекте.

Нужно понимать, что изменения в проекте неизбежны.

О документировании изменений я подробно расскажу в статье по документированию проекта в процессе контроля, а сейчас просто отмечу, что основным источником изменений в проекте являются меняющиеся хотелки и новые пожелания основных стейкхолдеров проекта (заказчика, спонсора и ключевых пользователей продукта). Конечно, изменения в проекте неизбежны, но они и крайне важны для успеха проекта. Всё дело в том, что в начале проекта пожелания стейкхолдеров могут быть не внятными, а по мере «взросления» самого проекта и требования к проекту и продукту становятся всё более зрелыми. Именно грамотное внесение изменений в проект и обеспечивает успешность проекта. Как уже отмечалось в прошлой статье, мы живём в VUCA-мире и то, что заказчик хочет в начале проекта не равно тому, что ему будет нужно в конце.

Следовательно – требования будут меняться, а Реестр требований позволяет отследить эти изменяющиеся требования на всём протяжении проекта. Идеальным вариантом оформления и ведения этого документа – использование специального ПО для отслеживания требований, типа Redmine или того же MS Project Server, только немного «доработанного напильником».

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

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

Формат Документа по требованиям может варьироваться от простого документа, перечисляющего все требования, разделенные на категории по заинтересованным сторонам и приоритетам, до некой папки-скоросшивателя или электронной папки на портале проекта, которая включает в себя все документы и файлы, связанные с требованиями из Реестра требований. Например, в Реестре сказано, что документирование некой автоматизированной системы должно быть произведено в соответствии с ГОСТ 34.201. Соответственно в Документации по требованиям сам этот ГОСТ должен быть в бумажном или электронном виде, чтоб любой разработчик мог получить к нему доступ и выяснить все делали данного ГОСТа.

https://www.youtube.com/watch?v=RNF14CwbFqw

Если есть требования, то можно легко описать, какие объёмы работ нужно выполнить, чтоб все утверждённые требования удовлетворить.

Описать объёмы работ

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

Итогом действа будет документ, который ПМ-ы называют Описание содержания проекта.

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

Описание содержания включает в себя:

• Описание продукта, описанного в Уставе проекта и в Документации по требованиям.
• Критерии приемки, т.е. условия, которые должны быть выполнены для того, продукт и результаты проекта были приняты заказчиком.
• Исключения из проекта — явная формулировка того, что именно в проекте точно не будет выполняться, чтоб не раздувать объёмы работ проекта.
• Ограничения, т.е. пределы или ограничивающие условия, которые оказывают влияние на исполнение проекта, например, предопределенный бюджет.
• Допущения — факторы, которые считаются верными, реальными или определенными без предоставления доказательств и без демонстрации. Допущения могут оказаться ошибочными и как правило являются источником рисков в проекте, но они позволяют запустить планирование проекта без долгих исследований. Одним из ярчайших примеров допущения в истории управления проектами является допущение, что луна твёрдая. Слышал о таком допущении? Нет? Я расскажу:Середина 60-х годов XX-го века. Советская лунная программа разрабатывается полным ходом. И тут возникает вопрос: каким делать шасси посадочной станции? Ведь невозможно проектировать его, не зная, хотя бы приблизительно, куда станция будет садиться. А что представляет собой грунт лунной поверхности, никто ещё точно сказать не мог. Одна группа астрономов утверждала, что на Луне почва твердая, а вторая столь же убедительно доказывала, что за многовековую историю Луны из-за постоянной бомбардировки метеоритами там образовался слой пыли, причем его толщина достигает 50-ти метров в кратерах, а на ровных участках – десяти… Королёв собрал совещание, пригласив всех заинтересованных в лунной программе специалистов. За два часа совещания все переругались друг с другом, и только сам Королев не произнес ни слова. Смотрел и слушал. Словно ждал чего-то. Наконец, взял слово. – Луна – твердая! – сказал он резко и, как обычно, безапелляционно. Кто-то из астрономов все-таки возразил: – Это еще доказать надо! Никто из учёных не берёт на себя смелость написать — на Луне, мол, такой-то грунт… и подписаться под этим! Королев посмотрел усталыми глазами на сидящих за столом: — Ах, вот чего вам не хватает… Взял блокнот, крупным почерком написал на его листке: «ЛУНА — ТВЕРДАЯ». Подписался: «С. КОРОЛЁВ». Поставил дату, вырвал листок из блокнота и передал сотруднику, которому предстояло непосредственно руководить проектированием станции.

Что касается ограничений проекта, то тут нужно учитывать, что ограничения часто конкурентны и влияют друг на друга. Как правило, выделяют шесть основных ограничений: бюджет, срок, ресурсы, качество, риски, ну, и сами объёмы работ.

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

Все подобные конкурентные взаимозависимости ограничений представлены на рисунке:

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

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

Разбить на составляющие

Разбиение объёмов работ проекта на более мелкие и, следовательно, легче управляемые части позволяет получить WBS — структурированное видение того, что необходимо достичь.
WBS, т.е. work breakdown structure или иерархическая структура работ может быть организована по разному, к примеру, по этапам проекта, по основным конструктивам, по подпроектам или микс из этих элементов.

• Этапы характеризуются тем, что их выполняет сама команда проекта, а их итог невозможно чётко измерить. Например, этап планирования. Хорошо или плохо спланирован график проекта, команда поймёт только когда по этому графику реализует большинство работ.
• Конструктивы характеризуются тем, что они достаточно чётко измеримы, т.е. существуют возможности однозначно проверить, что созданный результат полностью соответствует требованиям. Выполнять этот элемент WBS может как команда, так и некий подрядчик.
• Подпроеткты характеризуются тем, что их выполняет только подрядчик, а вернее внешняя по отношению к команде проекта организационная структура. Итог подпроектов, может быть, как измерим, так и нет.

Визуализация на схеме:

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

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

https://www.youtube.com/watch?v=w4EPL6S8aKI

Для чего структурируем?

1. Для разбивки проекта на управляемые блоки
2. Для перехода от общих описаний к конкретным заданиям
3. Для распределения ответственности и определения комплексов работ/подрядов
4. Для более точной оценки затрат

Наиболее подробно методика разработки WBS описана в Practice Standard for Work Breakdown Structures – Second Edition.

Итого

В конце процесса планирования объёмов работ проекта, Описание содержания и WBS должны быть собраны в один Базовый план по содержанию, который согласовывается со спонсором или заказчиком.

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

В следующей статье я расскажу, как документировать команду проекта.

Видео:Критерии приемки проекта? Как их создать?Скачать

Управление содержанием проекта

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

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

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

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

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

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

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

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

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

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

проекта включает в себя:

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

Описание содержания проекта

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

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

Например, если вы внедряете новую информационную систему, в содержание проекта будет входить:

1. Сама система (тут же приводится список ее компонентов).
2. Права в системе, настроенные в соответствии с утвержденным бизнес-процессом.
3. Техническое обеспечение системы (сервера, подключение на машины пользователей).
4. Комплект документации (тут перечень) для поддержки и развития решения.
5. Обученные пользователи.
6. Обученные специалисты службы поддержки, которые все это добро будут поддерживать.
7. Обновленные нормативные документы компании (например, процедура по работе с дебиторами).

Критерии приемки результата проекта

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

https://www.youtube.com/watch?v=Lc-QRZE5mXA

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

Например, для элемента “Обученные пользователи” (подкатегория “Обученные бухгалтера по работе с дебиторами”) критерием приемки может быть “Бухгалтер может выполнить следующие операции: ввод акта сверки, согласование счета и т.д. самостоятельно не более чем за 1 минуту”.

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

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

На рисунке ниже схематично изображено определение границ проекта.

Определение границ проекта

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

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

Управление содержанием целесообразно еще и потому, что позволяет контролировать объем усилий и средств, направленных на получение результата. Что, если на выполнение проекта потрачено огромное количество ресурсов, усилий, времени – а результат, мягко говоря, того не стоит?

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

На кофе и новые материалы для читателей блога 🙂

Видео:Критерии готовности и Критерии приемки - объяснение на примереСкачать

6 критериев оценки продукта

Для начала приведем сами принцип:

1. Неприводимость к простоте.
2. Интуитивность использования.
3. Функционал под красотой.
4. Доступные инновации.
5. Внешнее представление.
6. Методология развития.

Неприводимость к простоте

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

Стив Джобс сказал: «Решить, что не надо делать так же важно, как решить, что делать». При создании продукта ставится его главная цель. На самом деле целей может быть много, но главная всегда одна.

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

Второе делает путь приятным, но не более.

Чтобы понять, что можно убрать, нужно оценить каждую функцию в отдельности: что можно убрать без ущерба для главного? Создав редактор, мы оценили его интерфейс с этой точки зрения. Все ли нужно пользователю одновременно? Что используется реже всего? Что можно спрятать?

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

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

Интуитивность использования

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

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

Принципы интуитивного использования:

1. Инструкции не нужны.
2. Сломать трудно.
3. Даже ребенок справится.
4. Не надо напрягать мозг.

При анализе редактора с точки зрения интуитивности использования следует дать ответы на следующие вопросы:

• Как уменьшить стресс от использования?
• Сколько времени потребуется, чтобы полностью понять его?
• Каким образом его можно улучшить?

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

https://www.youtube.com/watch?v=uLh3SJEFLmo

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

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

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

Функционал, спрятанный за красотой

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

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

С красивой девушкой интересно поговорить, а в Макдоналдсе есть бесплатный wi-fi или розетка для зарядки телефона прямо около вашего стола.

Плохой продукт – это продукт, который позволяет достичь только главной цели его использования. В каждом продукте должны быть свои бонусы. Когда пользователь продукта неожиданно обнаруживает за красотой еще и дополнительный функционал, нужный ему именно в этот момент, он продолжает его использовать. Хороший продукт делает именно то, что он говорит, а потом добавляет «бонус».

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

• Есть ли какие-то полезные функции, которые не сразу бросаются в глаза?
• Что скрывается за первым слоем моего главного предложения?
• Какова цена?

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

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

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

Цена всего этого невелика – 1230 р./месяц за 15 сайтов, 2180р./месяц за 30 + командный доступ и 6760 р./месяц за безлимит со всеми возможными функциями, включая персонального менеджера, который всегда на связи.

Инновации должны быть доступны пользователю

Почему некоторые новинки сразу приобретают популярность, а некоторые так и остаются непонятыми? Мы все являемся участником социальных сетей – от одноклассников до . Но кто помнит одну из первых – FRIENDSTER? Она была запущена в 2002 году и поначалу имела популярность. Однако люди еще не были готовы так активно общаться через сеть. Это пример, когда что-то новое появилось слишком рано.

Оценим редактор с этой точки зрения:

• Чем он отличается от других таких же?
• Когда мы рассказываем о нем другим, они сразу понимают, о чем идет речь?
• Будут ли пользователи знакомы с хотя бы некоторыми элементами продукта?

Ответ на первый вопрос мы дали в предыдущем пункте. Главное отличие от других редакторов в дополнительном функционале. Еще одно отличие от большинства редакторов – наличие триггеров.

Триггеры – это функционал, который позволяет элементам реагировать на события на странице. Триггер позволяет изменить свойство элемента.

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

Внешнее представление

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

Чтобы понять, насколько внешнее представление редактора PIXLI отвечает его целям, поставим вопросы:

• Чего мы хотим достичь, предлагая свой редактор?
• Насколько форма представления наших целей согласуется с самим целями?

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

https://www.youtube.com/watch?v=_QRHVr6vLII

Так как речь идет о верстке, терминология должна состоять из CSS-понятий. Большей частью мы перевели ее на русский язык, но оставили базовые понятия margin и padding. Во-первых, они знакомы любому верстальщику. Никто не говорит «Внешний отступ», а говорит «маргины».

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

Так что форма представления наших целей вполне с ними согласована.

Методология развития

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

Из-за чего это произошло? Они остановились в развитии и не успели вовремя переключиться на новые технологии – цифровую съемку.

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

Мы считаем этот принцип самым важным из всех перечисленных. Проанализируем редактор с точки зрения следующих вопросов:

• Продукт будет продолжать удовлетворять потребность в течение трех — пяти лет?
• Будут ли создаваться несколько поколений продукта?

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

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

______________________________________________________________________

Материал создан агентством контент-маркетинга Текстотека.

Хотите самостоятельно внедрить контент-маркетинг в свой бизнес? Подписывайтесь на наше сообщество ВКонтакте, там много бесплатного обучающего материала.

📺 Видео

Госзакупки – 2024. Ответы на вопросы по проведению процедурСкачать

Денис Тучин - Мастер-класс про Пользовательские истории и критерии приёмки (приёмочные критерии)Скачать

Что такое User Story за 3 минутыСкачать

Озон НЕ ПРИМЕТ вашу поставку, если этикетка будет такой! Всё про маркировку на FBO OZON.Скачать

Тестировщик с нуля / Урок 26. Как тестировать требования? Тестирование требованийСкачать

Приемка товара при наличии претензий по количеству и качеству товара.Скачать

Как декомпозировать USER STORY, чтобы релизиться КАЖДЫЙ СПРИНТ? – Держите "Pop-it декомпозиции"Скачать

Вебинар: Приемка продукции: правила, ошибки заказчиков и судебная практика от 20.09.2017Скачать

Как принять перевозку на ПВЗ Озон. Прием отправлений. Пункт выдачи OZON.Скачать

Требования в Agile: живой User Story Mapping. Юрий Куприянов #системныйаналитик #agileСкачать

Как писать требования так, чтобы команда хотела их читать / Александр Войтехович / ISsoftСкачать

2. Начало работы: товары и остаткиСкачать

ОБУЧЕНИЕ: приемка товара на WILDBERRIESСкачать

Приемочный контроль, хранение ЛС и первичный учетСкачать

Начинающий руководитель: что важно сделать первым делом? / Александр ВысоцкийСкачать

Тестировщик с нуля / Урок 3. Что такое тестирование, QA, QC? Верификация и валидацияСкачать

Размещение товаров на складе. Топология складаСкачать