Рубрика «требования»

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

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

Облачный чек-лист, или как нас оценивал заказчик - 1

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

Переносили все системы: тестовые среды, тест + прод, препрод, все виртуальные машины, виртуальные сервера плюс все системы виртуальной инфраструктуры. Даже поддержка у них своя появилась в России. От нас — только аренда ресурсов.

Проверяли они нас знатно, по масштабам: почти полный аудит ЦОДа. Но они смотрели не железо и теххарактеристики в основном, а то, как выстроены процессы ИБ и как соблюдаются разные SLA. С их точки зрения, именно процессы по стабильности SLA указывают на качество работы компании. И мы им рассказывали про каждый из компонентов детально.

Я хочу поделиться списком критериев к проверке. Потому что появилась хоть какая-то методология, ведь до этого мало какой заказчик так системно подходил к вопросу.
Читать полностью »

Долгое время работая в разных сферах ИТ, мы с исследовательской командой наблюдали все возможные проблемы становления разработчиков и все причины-следствия их дефицита. Нас интересовало: почему программист развивается в senior-специалиста так долго или вовсе им не становится? Откуда неоправданные ожидания с обеих сторон? И главное — что делать разработчику на каждом уровне, чтобы войти в привилегированную касту senior-ов, архитекторов, тимлидов и руководителей?

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

Senior, who the f… is Alice Senior?

Анализ описания вакансий на hh и требований, которыми поделились руководители в очных беседах, показал — единого подхода к определению уровня senior нет. В одной компании это тот, кто способен сам спроектировать сложный модуль, в другой — подключиться к доработке отдельных решений, в третьей — тот, кто просто круче остальных. Читать полностью »

В РФ появился предварительный стандарт для мобильных приложений с 87 требованиями к их функционалу - 1

Чиновники Росстандарта утвердили предварительный стандарт для мобильных приложений в России. Он содержит 87 требований к функционалу софта, о чем сообщает «Коммерсант». Одно из основных требований — возможность бесплатного ознакомления с возможностями платного софта. Пока что сам стандарт и его требования носят сугубо рекомендательный характер, но разработчики документа считают, что при создании новых приложений стоит ориентироваться именно на него.

Требования разделяются на несколько категорий, включая качество мобильных приложений, юзабилити, безопасность, производительность. Заместитель руководителя Роскачества Илья Лоевский заявил: «Раньше в России не было госстандартов в области мобильных приложений, и разработчики ориентировались на гайдлайны корпораций, в частности Google и Аpple».
Читать полностью »

Автор: Adam Alami, PhD Fellow, IT University of Copenhagen (перевод с англ.)

ВВЕДЕНИЕ

Нефункциональные требования широко представлены в литературе. Нет недостатка в определениях и примерах нефункциональных требований. Международный институт бизнес-анализа (IIBA) определяет нефункциональные требования следующим образом:

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

Ключевыми словами в этом определении являются «не имеют прямого отношения к поведению или функциональности решения». Это либо «условия», либо «качества».

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

Качества: это бизнес-требования, которые определяют не системное поведение и не связаны с процессом, а являются требованиями к качеству решения.
Читать полностью »

Все мы знаем, какую боль в самых разных частях тела вызывают проблемы с требованиями у всех в Разработку ПО вовлеченных. Казалось бы даже у контор, которые давно на рынке, уже должны быть целостные практики формализации и подготовки требований — ан-нет, процесс в большинстве случаев достаточно примитивен, и нигде не расписан. Кому-то этого достаточно, но в моем случае команда наша еще и распределенная, да еще и с языковым барьером (к-к-ккомбо!).

image

Дисклеймер: Каждая организация уникальна — от внутренней структуры, и до того, как она общается с внешним миром. Так что я не считаю ни один воркфлоу (или бизнес-процесс, как любят говорить на русском) универсальным решением. Пост не претендует на полноту и исключительность, он скорее о том, что подобный подход работает у нас в SkuVault, в текущей конфигурации команды, и демонстрирует положительные результаты. Наша специфика — это 50 человек, 16 из которых оторваны от другой части 10-часовой разницей во времени.
Читать полностью »

image

Анализ требований — часть процесса разработки программного обеспечения, включающая в себя сбор требований к программному обеспечению (ПО), их систематизацию, выявление взаимосвязей, а также документирование.
https://ru.wikipedia.org/wiki/анализ_требований

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

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

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

С частью 4 можно ознакомиться, перейдя по ссылке

VIII Определяем сущности предметной области

Все, что видим мы, — видимость только одна.
Далеко от поверхности мира до дна.
Полагай несущественным явное в мире,
Ибо тайная сущность вещей — не видна
Омар Хайям

Практика формирования требований в ИТ проектах от А до Я. Часть 5. Сущности предметной области. Немного о стратегиях - 1
Определив абстрактные хранилища продукта, мы получаем костяк для построения детальной модели данных. При проектировании структуры сущностей продукта, удобно использовать канонические диаграммы «Сущность-связь» (ERD), логическую диаграмму (Logic Diagram) или диаграмму классов (Class diagram).

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

Теория проектирования такого типа диаграмм детально изложена в литературе, описывающей работу с UML. Например, эта тема очень удачно представлена в [11]. Поэтому остановлюсь лишь на некоторых аспектах, интересных на мой взгляд,.
Читать полностью »

С частью 2 можно ознакомиться, перейдя по ссылке

VI ОПРЕДЕЛЯЕМ ФУНКЦИИ СИСТЕМЫ И ГРАНИЦЫ ПРОЕКТА

Каждая модель ограничена в своих ответах, но нет ограничения на то, как и что моделирует модель, как нет ограничения на человеческую мысль
Дуглас Т. Росс

Практика формирования требований в ИТ проектах от А до Я. Часть 3. Функции системы и Границы проекта - 1

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

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

Границы проекта (project scope) показывают, какая область конечного продукта будет реализована в текущем проекте. Другими словами, определяется черта между тем, что мы будем делать сейчас и тем, что отложим на потом или от чего вообще сможем отказаться. Для этого в арсенале команды должен быть инструмент, позволяющий не просто строить модели создаваемого продукта, а помогающий наглядно очертить рамки автоматизируемых процессов, а также предоставлять возможность легко выносить процессы за границу или включать их обратно. Это очень важно для осознания и более качественного планирования объемов работ. Подобный инструмент полезен не только для «борьбы» с непомерными желаниями заказчика, но и для маневров менеджмента со стороны разработчиков.
Читать полностью »

С частью 1 можно ознакомиться, перейдя по ссылке

IV ОПРЕДЕЛЯЕМ ЦЕЛИ, ПРОЕКТА

Цель не обязательно должна достигаться. Порой это просто направление двигаться дальше.
Брюс Ли.

Практика формирования требований в ИТ проектах от А до Я. Часть 2. Цели и Потребности - 1

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

Цель данной группы работ: определить основные задачи, которые ставят перед собой группы заинтересованных лиц, участвующих в проекте.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js