Рассмотрим основные причины, а также способы разрешения проблемных ситуаций.
Рубрика «требования к системе»
«Хотели как лучше, а получилось как обычно»: почему заказчик получает не то, что хотел?
2024-12-14 в 19:49, admin, рубрики: аналитика, бизнес-анализ, системный анализ, техническое задание, требования, требования к системе, управление ожиданиямиКак мы автоматизировали управление проектными требованиями с помощью AI и ML
2024-09-19 в 18:03, admin, рубрики: искусственный интеллект, машинное обучение, проектный офис, системный анализ, требования заказчика, требования к системе, управление требованиямиМы команда департамента разработки в контуре одной госкорпорации. Наш отдел разрабатывает ПО для управления проектами при создании и проектировании сложных инженерных объектов.
Постановка задачи на импортозамещение информационной системы, например Notion
2024-09-03 в 15:40, admin, рубрики: импортозамещение, стартап, требования заказчика, требования к системеДобрый вечер уважаемые читатели Хабра, Хабровчане, а также все спеллчекеры с личным мнением - мое специализированное почтение.
Перед вами пример Первого Инженерного Действия, а именно пример принятия решения в обстоятельствах неопределенности, с ходом обдумывания дальнейших шагов развития в ситуации с обозначенным топиком - пора валить, куда как, кого, опенсорс, самопис, заказ и тд и тп.
Большинство известных мне случаев при принятии решений характеризуются одним общим показателем - отсутствием письменного размышления при принятии решений.
Те кто приходят к этой практике получают много полезного в своей жизни.Читать полностью »
Почему я не верю в бум беспилотных машин в ближайшие пять лет
2022-09-29 в 16:03, admin, рубрики: Nvidia, research, tesla, архитектура, беспилотный автомобиль, будущее здесь, искусственный интеллект, лидар, машинное обучение, машинное обучение. нейросети, образование, проблема вагонетки, робототехника, транспорт, требования к системеПредисловие
Всё описанное далее, личное мнение, претендующее на единственно верное, но не факт, что являющееся таковым. Все лица, компании, метафоры - выдуманные и к реальности отношения не имеют.
Однажды, беседуя с коллегами по цеху о том, почему я не очень хочу заниматься именно беспилотными автомобилями, я сказал, что я не верю в них. А точнее я не верю в их коммерческий запуск в ближайшие пять лет, на что моя подруга позже дала ремарку, что это одно и то же, да и я не выгляжу как человек, который в это не верит. И я вдохновился это всё довольно чётко (хотя где-тоЧитать полностью »
Пользовательские истории – это не требования
2020-09-13 в 12:59, admin, рубрики: agile, пользовательские истории, требования к системе, Управление продуктом, управление проектамиПривет! Представляю вашему вниманию перевод статьи «User stories are not requirements» автора Пер Лундхольм (Per Lundholm).
Слоны – не жирафы, а пользовательские истории – это не требования. Они имеют и общие черты и общий контекст, однако это не ставит между ними знак равенства. Тем не менее, многие полагают, что пользовательские истории являются своего рода новым прочтением того, что традиционно называется требованиями к программному обеспечению — ведь, должны же быть требования на проекте, правильно? Так вот, я отвечу — нет, и еще раз нет. Во – первых, это не требования, во – вторых, требования — это не то, что нам на самом деле нужно. Пользовательские истории — это прежде всего шанс увидеть различные варианты реализации, чтобы потом можно было воспользоваться открывшимися возможностями. А требования… это решить все наперед, чтобы потом в этом увязнуть.
Как организовать CI-CD на проекте: от постановки задач до настройки конвейера развертывания
2018-10-19 в 8:48, admin, рубрики: bugs, ci, continuous integration, devops, epic, project management, qa, qa management, user story, Блог компании EastBanc Technologies, Тестирование веб-сервисов, требования к системе, управление проектамиВ чем залог успешной настройки Continuous Delivery на проектах? Слаженная работа команд разработки, тестирования и инженеров по инфраструктуре. Спасибо, кэп, как говорится :) Но как это реализовать на практике? В этой статье поделимся нашими наработками, как это всё организовать и воплотить в жизнь.
Мы обобщили базовые основы в одну шпаргалку для себя и делимся с вами:
- Какие бывают требования и чем они характеризуются,
- Типы задач и порядок их описания в Issue tracker,
- Как оформлять User story и Tech story,
- Как описывать баги,
- Настройка конвейера развертывания.
Опытные инженеры вряд ли узнают из статьи что-то новое, но надеемся, что начинающим специалистам эта информация пригодится.
Моделирование конструкций. Требования к моделлеру
2017-05-26 в 19:11, admin, рубрики: IT-стандарты, Анализ и проектирование систем, бизнес-анализ, конструкция, моделирование конструкций, Проектирование и рефакторинг, Семантика, требования к системеВ прошлой статье Понятие системы и конструкции. Их место в проектировании информационных систем, посвященной конструкциям, я вкратце затронул герменевтический круг – это один из способов нашего мышления, нацеленного на достижение понимания. Герменевтический круг состоит из двух направлений мышления: анализа и синтеза.
Анализ – это процесс, при котором мы представляем изучаемый объект в виде множества его частей (изучаем различные конструкции, на которые можно разложить изучаемый объект).
Синтез — это обратная «сборка» объекта.
Утверждается, что чувство понимания достигается, когда, сделав разборку объекта (анализ), а затем его сборку (синтез), — субъект получает непротиворечивый результат. В той же статье я отметил, что стандарты, как правило, нацелены на описание только одного направления мышления — анализа, но совершенно игнорируют второе направление – синтез.
Игнорирование процесса синтеза приводит к тому, что мы теряем способность делать проверку результатов анализа и начинаем мыслить шаблонами. Например, если нас спросить, из чего состоит велосипед, то довольно быстро найдется «правильный» ответ. Но если спросить: "Частью чего является велосипед?", – мы сильно затруднимся с ответом.
Читать полностью »
У нас же есть техническое задание на систему – сайт – приложение – проект…
2015-08-17 в 13:24, admin, рубрики: техническое задание, требования, требования заказчика, требования к системе, Управление продуктом, управление проектамиСитуация
- На входе в студию клиент (виртуально / реально не важно).
- Клиент хочет что-то заказать у нас — систему, сайт, приложение, аппу, что угодно — все что можно разработать и даже потом скрестить бульдога с муровьедом например (1С битрикс, просто 1С, другие системы и наша разработка).
- Высылает он нам нечто (как мы это видим), называя это «тз» (как он это видит) и говорит — оценить / посчитать / задать вопросы и далее везде, ожидая в ответ как правило получить вполне конкретную точную цифру и срок (беру пример крайней клиники) когда это будет готово.
- Ждет.
За годы работы я пришел к работающей конструкции в данной части воронки моих продаж — я всегда отвечаю на такие письма — отлично, получил, я вижу ваши пожелания к решениям в письме и, а тз вы забыли приложить?
В такой конструкции диалог не выглядит слишком агрессивным и всегда случается плавный переход в следующий шаг воронки — позитивный диалог что такое тз и что там должно быть, что еще необходимо изложить именно клиенту, а особенно что не нужно излагать клиенту, а делать это должны мы.