Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 84
Мысль, которая выраженна в иллюстрации, в полной мере передает то, с чем обычно я сталкиваюсь по будням, только немного в другом сегменте!)
В процессе чтения, не уходило ощущение, что это текст из методического пособия или чей-то курсовой работы. Дежурные фразы «сухим» формальным языком
Статья слишком «сухая», что бы быть «научно-популярной», и при этом слишком абстрактная, что бы разработчики почерпнули из неё практическую пользу прямо сейчас.
Зачастую в проектах вообще сложно вытащить из заказчика требования как таковые.
Буду рад если кто-нибудь поделится опытом именно получения требований, удовлетворяющим всем 10 пунктам.
Буду рад если кто-нибудь поделится опытом именно получения требований, удовлетворяющим всем 10 пунктам.
Зачем Вы все это написали?
Позволю себе предположить — Вы хотели донести до читателей Хабра то, что знаете сами.
Но, например, я, как человек, который сам является менеджером проектов, пролистнул это очень быстро — тонны слов и все неинтересно.
Давайте на примерах — возьмите конкретный кейс, распишите для него эту теорию на практике.
Если надо помочь — обращайтесь, помогу. Сделаем практическую конфетку из теоретической сухой статьи.
Ю а велком.
Позволю себе предположить — Вы хотели донести до читателей Хабра то, что знаете сами.
Но, например, я, как человек, который сам является менеджером проектов, пролистнул это очень быстро — тонны слов и все неинтересно.
Давайте на примерах — возьмите конкретный кейс, распишите для него эту теорию на практике.
Если надо помочь — обращайтесь, помогу. Сделаем практическую конфетку из теоретической сухой статьи.
Ю а велком.
Присоединюсь, тоже перелистнул очень быстро. Процитирую: «тонны слов и все» это лишнее. Извините, порекомендую к чтению: Купера «Психбольница в руках пациентов». Иллюстрация прям по этой книге. Отличная! Правда, у одного знакомого CIO на стенке висел более пессимистичный вариант.
Мне субъективно не понравилось освещение управлением требованиями с использованием тяжеловесных программных продуктов. Возьму на себя смелость заявить, что мало кто из хабросообщества сталкивается с очень крупными проектами, где стадия проектирования, формулирования требований, планирования несколько месяцев и использование таких систем управления требованиями оправданно. В реальности проекты меньше, сроки разработки меньше, на инструментарий не разоряются и один человек выполняет несколько обязанностей. Только по Rational был такой толстенный талмуд. Ни у кого нет времени все это осваивать, плюс не дадут, уволят раньше :-), а менеджеры не захотят осваивать. Из-за этого от статьи ощущение оторванности от реальной практики. Это как после институтов приходят вчерашние студенты и начинают все делать по теории. Успехов Вам! Молодцы, что написали статью.
Мне субъективно не понравилось освещение управлением требованиями с использованием тяжеловесных программных продуктов. Возьму на себя смелость заявить, что мало кто из хабросообщества сталкивается с очень крупными проектами, где стадия проектирования, формулирования требований, планирования несколько месяцев и использование таких систем управления требованиями оправданно. В реальности проекты меньше, сроки разработки меньше, на инструментарий не разоряются и один человек выполняет несколько обязанностей. Только по Rational был такой толстенный талмуд. Ни у кого нет времени все это осваивать, плюс не дадут, уволят раньше :-), а менеджеры не захотят осваивать. Из-за этого от статьи ощущение оторванности от реальной практики. Это как после институтов приходят вчерашние студенты и начинают все делать по теории. Успехов Вам! Молодцы, что написали статью.
Точно.
Время — самый дорогой ресурс в разработке ПО, поэтому тратить его на излишнюю документацию расточительно.
Описанное управление требованиями рассчитано на крупные проекты, которых на рынке не очень много.
Для средних и мелких проектов, ИМХО, нужно не детально фиксировать требования, а быстро создавать прототип, получать feedback от пользователей и переходить к следующей итерации. Мышлению всегда проще работать, когда есть от чего оттолкнуться. А рассматривать сферического коня в вакууме — это, конечно, полезно для развития фантазии, но совершенно бесполезно для конкретных нужд разработки ПО.
Время — самый дорогой ресурс в разработке ПО, поэтому тратить его на излишнюю документацию расточительно.
Описанное управление требованиями рассчитано на крупные проекты, которых на рынке не очень много.
Для средних и мелких проектов, ИМХО, нужно не детально фиксировать требования, а быстро создавать прототип, получать feedback от пользователей и переходить к следующей итерации. Мышлению всегда проще работать, когда есть от чего оттолкнуться. А рассматривать сферического коня в вакууме — это, конечно, полезно для развития фантазии, но совершенно бесполезно для конкретных нужд разработки ПО.
Эта иллюстрация — явная же компиляция из того классического варианта.
Разработка большой и сложной системы не может быть завершена за один подход — итерацию.
Это может быть не верно если вы являетесь и заказчиком проекта и одновременно его разработчиком.
Отсутствие барьера объяснить/понять идею — может стать самым главным преимуществом проекта.
Это может быть не верно если вы являетесь и заказчиком проекта и одновременно его разработчиком.
Отсутствие барьера объяснить/понять идею — может стать самым главным преимуществом проекта.
По-моему это реклама ПО для управления требования к IT-проектам.
Boring. Манера изложения напомнила институтские методички.
Сухо. Увы.
Да. Статья сухая, да и воды полно…
А по делу — как раз недавно пытались с менеджером проекта поговорить — чтобы заказчик поточнее давал спецификации того, что он хочет. В итоге после переговоров с заказчиком получили такой ответ — что проект у нас «с хаотической спецификацией». То есть «заказчик сам не знает что ему в конце надо будет. вот соберутся его топ-менеджеры в кафешке или на совещании, выпьют чая/кофе/алкоголя, потрындят и таки что-нибудь в виде какой-то части спецификаций вам выдадут.» А на практике — такие совещания у заказчиков случаются видимо раз в неделю минимум. Ибо часто каждую нгеделю спецификации не только новые приходят, но и полностью противоречащие предыдущим. Очень сложно работать.
Правда я был на нескольких проектах — и такое, в большей или меньшей степени есть везде. В меньшей — если заказчик близок к основной тематике вашей компании или заказчик внутренний. Но, увы, мы работаем в аутсорсинге и такое случается крайне редко. Видимо, специфика.
А по делу — как раз недавно пытались с менеджером проекта поговорить — чтобы заказчик поточнее давал спецификации того, что он хочет. В итоге после переговоров с заказчиком получили такой ответ — что проект у нас «с хаотической спецификацией». То есть «заказчик сам не знает что ему в конце надо будет. вот соберутся его топ-менеджеры в кафешке или на совещании, выпьют чая/кофе/алкоголя, потрындят и таки что-нибудь в виде какой-то части спецификаций вам выдадут.» А на практике — такие совещания у заказчиков случаются видимо раз в неделю минимум. Ибо часто каждую нгеделю спецификации не только новые приходят, но и полностью противоречащие предыдущим. Очень сложно работать.
Правда я был на нескольких проектах — и такое, в большей или меньшей степени есть везде. В меньшей — если заказчик близок к основной тематике вашей компании или заказчик внутренний. Но, увы, мы работаем в аутсорсинге и такое случается крайне редко. Видимо, специфика.
Смиритесь или менйте работу.
КО как бэ подсказывает «требования» меняются.
Это может происходить по разным причинам. Среди них:
1)Политические игры в стане заказчиков.
2)«Заказчик» — идиот
3)PM со стороны заказчика идиот
3)Ваш аналитик — идиот
4)Ваш PM — идиот
5)Вы идиот
6)«жизнь» не стоит на месте — и всё меняется.
(никогда не задумывались почему PMI приводит такую ужасающую статистику по успешному заверщению проектов? И это учитывая что далеко не всякая организованная активность может называться проектом. А только активность котороая соответсвует вполне конкретным правилам и должным образом оформленная)
Вобщем пока заказчик готов оплачивать все свои фантазии — задача «разработки» всяечки способствовать их воплощению в жизнь. ПОменялись фантазии — ок — строим новые. Есессно при условии что всякая работа требует денег и времени — если если нет — смените работу.
КО как бэ подсказывает «требования» меняются.
Это может происходить по разным причинам. Среди них:
1)Политические игры в стане заказчиков.
2)«Заказчик» — идиот
3)PM со стороны заказчика идиот
3)Ваш аналитик — идиот
4)Ваш PM — идиот
5)Вы идиот
6)«жизнь» не стоит на месте — и всё меняется.
(никогда не задумывались почему PMI приводит такую ужасающую статистику по успешному заверщению проектов? И это учитывая что далеко не всякая организованная активность может называться проектом. А только активность котороая соответсвует вполне конкретным правилам и должным образом оформленная)
Вобщем пока заказчик готов оплачивать все свои фантазии — задача «разработки» всяечки способствовать их воплощению в жизнь. ПОменялись фантазии — ок — строим новые. Есессно при условии что всякая работа требует денег и времени — если если нет — смените работу.
Требования меняются — это не значит что кто-то идиот. Я бы даже сказал, что идиот тот кто не полагает что изменение требований — это нормально в некоторых проектах. У проектов где полностью пишутся требования свои болезни, в некоторых случях это большой риск того что пользоваться системой будет пользоваться невозможно(ужасно неудобно).
Заказчик обычно не знает, чего он хочет. И тем более не знает, если это не разработка новой системы, а адаптация какой-либо системы под нужды заказчика.
Заказчик в первую очередь заинтересован в том, чтобы его бизнес шел в гору, а не в том, чтобы у него была система. Если он не может сам адекватно объяснить, что от системы требуется, то задача аналитика (как бизнес-консультанта) ему навязать решение в конце-концов.
Как раз для того, чтобы каждую неделю систему не переделывать и нужно управлять требованиями. Здесь много топиков с текстом а-ла «сначала пишите ТЗ, потом делайте». ТЗ — тоже в определенной степени документ, регламентирующий требования. Согласитесь, когда оно жестко прописано разрабатывать гораздо легче.
Заказчик в первую очередь заинтересован в том, чтобы его бизнес шел в гору, а не в том, чтобы у него была система. Если он не может сам адекватно объяснить, что от системы требуется, то задача аналитика (как бизнес-консультанта) ему навязать решение в конце-концов.
Как раз для того, чтобы каждую неделю систему не переделывать и нужно управлять требованиями. Здесь много топиков с текстом а-ла «сначала пишите ТЗ, потом делайте». ТЗ — тоже в определенной степени документ, регламентирующий требования. Согласитесь, когда оно жестко прописано разрабатывать гораздо легче.
«Согласитесь, когда оно жестко прописано разрабатывать гораздо легче. „
Я бы сказал по другому: хорошо когда есть заинтересованность и диалог. ТЗ как таковое тут не причём)
ТЗ вобще стало одним из buzzword в нашей отрасли. Юмор ситуации в том что, хотя это мало кто осознаёт, ТЗ ничего не гарантирует и ни от чего не защищает. Точней ТЗ “защищает» интересы только юристов.
Дело вот в чём. Представте. Есть заказчик, Есть Подрядчик. Они составили подробнейшее ТЗ («жестко всё прописали»). Начали делать. Закрываются этапы. Заказчик их так или иначе оплачивает. И вот в какой-то момент — толи потому что по статистика все идиоты, толи потому что жизнь так устроена и обстоятелсьтва изменились, заказчик гововрит что ему нужно [не]совсем другое.
Вот ситуация. Да есть ТЗ. В котором всё «жётско» пропсиано. Что делать?
«ТЗ защищает интересы подрядчика» — очевидно что нет. Бекоспромисность под предлгом того что в ТЗ всё жестко пропсиано — прямая дорога к убыткам и длительным судебный разбирательствам с целью получить деньги за выполненный, но непринятый этап и не оплаченный этап(а ведь есть догвоовры в которы есть предоплата, и оплата по завершении) + отрицательная карма.
«ТЗ защищает заказчика» — тоже очевижно что нет. Подрядчик чтото сделал. Может похожее на ТЗ может не похожее. Но в любом случае — не то что нужно заказчику. Требовать по ТЗ? Угрожать не оплатить этап работ? Разорвать договор? Требовать выплат неустоек предусмотренных догвоовром?
Это опять — потеря времени, потеря денег, суды, а главное — если вам разработка для чегото была нужна — у вас её как небыло так и нет и в ближайшее время уже точно не появится.
Перспективы подбного рода судебных разбирательств весьма туманны если честно. Дело в том что судья — он как бэ ничего в этом не понимает. И в своих суждениях он может опираться только на заключения экспертов. Каждая из сторон естесвенно представит своих экспертов.
+Если например у вас приложением к договору идут документы где есть какието «схемки» (типа UML и проч нотаций) и тз писал подрядчик — то заказчик так вобще ничего в этих схемах не понимает — может подрядчик мошенник может нет. новые экспертизы экспертов.
+ затягивание процесса.
профит только у юристов и экспертов. у всех остальных участников — убытки.
Так что «жесткое ТЗ» как и любая другая безкомпромиссная позиция чаще всего оказываются ошибочной.
Хотя безусловно — подбробное, полное и непротиврочивое тз оно безусловно хорошо и способствует реализации — но вот от «изменений» никак не страхует.
Я бы сказал по другому: хорошо когда есть заинтересованность и диалог. ТЗ как таковое тут не причём)
ТЗ вобще стало одним из buzzword в нашей отрасли. Юмор ситуации в том что, хотя это мало кто осознаёт, ТЗ ничего не гарантирует и ни от чего не защищает. Точней ТЗ “защищает» интересы только юристов.
Дело вот в чём. Представте. Есть заказчик, Есть Подрядчик. Они составили подробнейшее ТЗ («жестко всё прописали»). Начали делать. Закрываются этапы. Заказчик их так или иначе оплачивает. И вот в какой-то момент — толи потому что по статистика все идиоты, толи потому что жизнь так устроена и обстоятелсьтва изменились, заказчик гововрит что ему нужно [не]совсем другое.
Вот ситуация. Да есть ТЗ. В котором всё «жётско» пропсиано. Что делать?
«ТЗ защищает интересы подрядчика» — очевидно что нет. Бекоспромисность под предлгом того что в ТЗ всё жестко пропсиано — прямая дорога к убыткам и длительным судебный разбирательствам с целью получить деньги за выполненный, но непринятый этап и не оплаченный этап(а ведь есть догвоовры в которы есть предоплата, и оплата по завершении) + отрицательная карма.
«ТЗ защищает заказчика» — тоже очевижно что нет. Подрядчик чтото сделал. Может похожее на ТЗ может не похожее. Но в любом случае — не то что нужно заказчику. Требовать по ТЗ? Угрожать не оплатить этап работ? Разорвать договор? Требовать выплат неустоек предусмотренных догвоовром?
Это опять — потеря времени, потеря денег, суды, а главное — если вам разработка для чегото была нужна — у вас её как небыло так и нет и в ближайшее время уже точно не появится.
Перспективы подбного рода судебных разбирательств весьма туманны если честно. Дело в том что судья — он как бэ ничего в этом не понимает. И в своих суждениях он может опираться только на заключения экспертов. Каждая из сторон естесвенно представит своих экспертов.
+Если например у вас приложением к договору идут документы где есть какието «схемки» (типа UML и проч нотаций) и тз писал подрядчик — то заказчик так вобще ничего в этих схемах не понимает — может подрядчик мошенник может нет. новые экспертизы экспертов.
+ затягивание процесса.
профит только у юристов и экспертов. у всех остальных участников — убытки.
Так что «жесткое ТЗ» как и любая другая безкомпромиссная позиция чаще всего оказываются ошибочной.
Хотя безусловно — подбробное, полное и непротиврочивое тз оно безусловно хорошо и способствует реализации — но вот от «изменений» никак не страхует.
Мне кажется, что вам нужно определиться для какого типа людей вы пишите:
если это менеджеры — то оформить текст в виде презентации, которая будет нести в себе мысль «как все плохо без профессионального трекинга требований, и как все здорово, когда он есть»
если инженеры — выделить из вашего исследования факты, и разбавить их реальными кейсам.
И я думаю, что практический обзор одной системы имел бы большую ценность, чем поверхностный обзор функционала нескольких
если это менеджеры — то оформить текст в виде презентации, которая будет нести в себе мысль «как все плохо без профессионального трекинга требований, и как все здорово, когда он есть»
если инженеры — выделить из вашего исследования факты, и разбавить их реальными кейсам.
И я думаю, что практический обзор одной системы имел бы большую ценность, чем поверхностный обзор функционала нескольких
Теория такая теория)
«9.Обязательность — требование представляет собой определенную заинтересованным лицом характеристику, отсутствие которой ведет к неполноценности решения, которая не может быть проигнорирована. Необязательное требование — противоречие самому понятия требования.»
На мой взгляд оч интересное необходимое условие.
Если любой запрос «представляет собой определенную заинтересованным лицом характеристику, отсутствие которой ведет к неполноценности решения, которая не может быть проигнорирована» — то тогда любой запрос автоматически проходт это условие. Тогда зачем введено это условие?
А вот ещё интересный вопрос — если «заинтересованное лицо» — заблуждается относительности «неполноценности» и невозможности «проигнорировать». В этой ситуации — запрос уже не явлется требованием? Или всётаки является?
теория такая теория. Она помогает создавать иллюзию контроля и порядка)))
«9.Обязательность — требование представляет собой определенную заинтересованным лицом характеристику, отсутствие которой ведет к неполноценности решения, которая не может быть проигнорирована. Необязательное требование — противоречие самому понятия требования.»
На мой взгляд оч интересное необходимое условие.
Если любой запрос «представляет собой определенную заинтересованным лицом характеристику, отсутствие которой ведет к неполноценности решения, которая не может быть проигнорирована» — то тогда любой запрос автоматически проходт это условие. Тогда зачем введено это условие?
А вот ещё интересный вопрос — если «заинтересованное лицо» — заблуждается относительности «неполноценности» и невозможности «проигнорировать». В этой ситуации — запрос уже не явлется требованием? Или всётаки является?
теория такая теория. Она помогает создавать иллюзию контроля и порядка)))
Недавно читал «Креативное программирование 2.0», приведенные примеры достаточно четко показывают, насколько сильно теория не стыкуется с практикой.
Это самое то место, где теория расходится с практикой. Согласен, и ITIL не идеален, но дает хорошую почву для начала работы и чем ближе ваши требования будут к описанным в стандарте, тем легче будет описанные там же методики использовать в реальных проектах.
В общем смысле, по всем 10 пунктам можно вообще сказать одно — требование должно быть написано так, чтобы разработчик мог понять, что он должен разработать, а тестировщик протестировать.
В общем смысле, по всем 10 пунктам можно вообще сказать одно — требование должно быть написано так, чтобы разработчик мог понять, что он должен разработать, а тестировщик протестировать.
Для меня было открытием, что требованиями вообще можно управлять отдельно. Иначе говоря, подсистема управления требованиями выделяется настолько явно, что автоматизируется как отдельный продукт.
Я-то считал, что работаю в достаточно серьёзной фирме по производству ПО (250 человек, и это только российский «филиал» транснациональной корпорации, наибольшая доля заказов которой идёт непосредственно от IBM). И здесь за глаза всем хватает Jira (с кучей собственных модификаций, но суть та же). Требования оформляются тут ровно также, как задачи и баги, скажем.
Подозреваю, что такой «независимый» продукт для управления требованиями обязательно должен интегрироваться в некий набор продуктов из линейки ПО этой же компании. Этот набор, комплекс ПО, должен уже в целом управлять проектами, документооборотом и собственно организацией. Мне трудно поверить, что управление требованиями может быть единственным или хотя бы просто центральным звеном ПО организации. И вот как раз место такого продукта в общей системе управления было бы интересно увидеть.
Впрочем, интерес достаточно отвлечённый. Я не думаю, что мне придётся когда-нибудь работать в организации достаточно монструозной, чтобы она нуждалась в таком комплексе ПО, где одними только требованиями управляет отдельный продукт.
Я-то считал, что работаю в достаточно серьёзной фирме по производству ПО (250 человек, и это только российский «филиал» транснациональной корпорации, наибольшая доля заказов которой идёт непосредственно от IBM). И здесь за глаза всем хватает Jira (с кучей собственных модификаций, но суть та же). Требования оформляются тут ровно также, как задачи и баги, скажем.
Подозреваю, что такой «независимый» продукт для управления требованиями обязательно должен интегрироваться в некий набор продуктов из линейки ПО этой же компании. Этот набор, комплекс ПО, должен уже в целом управлять проектами, документооборотом и собственно организацией. Мне трудно поверить, что управление требованиями может быть единственным или хотя бы просто центральным звеном ПО организации. И вот как раз место такого продукта в общей системе управления было бы интересно увидеть.
Впрочем, интерес достаточно отвлечённый. Я не думаю, что мне придётся когда-нибудь работать в организации достаточно монструозной, чтобы она нуждалась в таком комплексе ПО, где одними только требованиями управляет отдельный продукт.
Требованиями нужно управлять.
IBM предлагает линейку продуктов, которая замечательно интегрируется между собой. И да, мы ее используем — IBM ClearQuest для багов, IBM RequisitePro для требований и IBM Rational Rose для моделирования. Проекты, в которых это гораздо более управляемы чем те, в которых требования документируются просто в ворде и через него же согласовываются.
IBM предлагает линейку продуктов, которая замечательно интегрируется между собой. И да, мы ее используем — IBM ClearQuest для багов, IBM RequisitePro для требований и IBM Rational Rose для моделирования. Проекты, в которых это гораздо более управляемы чем те, в которых требования документируются просто в ворде и через него же согласовываются.
Разумеется, нужно управлять. Вопрос в том, каким инструментарием.
Нам вот Jira хватает. Именно там идёт обсуждение, а в ворде (.pdf) уже только фиксация достигнутых договорённостей происходит. Текущая статическая версия подписывается сторонами, имхо вполне логично.
Думаю, всё дело в размере проекта, количестве требований, их сложности, в количестве уровней вложенности и прочих зависимостей. В каких-то организациях без системы управления требованиями просто не обойтись, наверное. Но в подавляющем большинстве фирм внедрение такого комплекса ПО не оправдано.
Так что для продвижения подобных решений надо бы ещё указывать, с какого именно момента внедрение этого ПО целесообразно.
Нам вот Jira хватает. Именно там идёт обсуждение, а в ворде (.pdf) уже только фиксация достигнутых договорённостей происходит. Текущая статическая версия подписывается сторонами, имхо вполне логично.
Думаю, всё дело в размере проекта, количестве требований, их сложности, в количестве уровней вложенности и прочих зависимостей. В каких-то организациях без системы управления требованиями просто не обойтись, наверное. Но в подавляющем большинстве фирм внедрение такого комплекса ПО не оправдано.
Так что для продвижения подобных решений надо бы ещё указывать, с какого именно момента внедрение этого ПО целесообразно.
Интересный пост, только хочу внести коррективу. Во- первых для того что бы эффективно работали госты и стандарты требуется определенная зрелость бизнеса как у заказчика так и у интегратора, иначе простая трата времени и денег, со зрелостью у нас вообще проблемы. Ваша ситуация изображенная на картинка абсолютна типична на сегодняшний день. Решаться она должна комплексно, процесса управления требованиями недостаточно, Важно уметь применять лучшие практики различных стандартов ситуационно. Так же если вводится в проект понятие управление требованиями, необходимо одновременно вводить управление качеством продукта и управление конфигурациями, иначе требования сведут проект на НЕТ! оч. распространенная ошибка, присутствует в большинстве не успешных проектов.
Добавлю что большинство изменений требований на лету связаны с неопределенностями в проекте, которые необходимо устранять в самом начале.
Проклассифицируйте неопределённости-то
неуверен что существуют какие то единственно верные классификаторы, но от себя добавлю:
неопределенности
1. Неопределенные качественно цели
2. непродуманные, неэффективные правила и процедуры согласования и управления
3. Заниженные бюджеты, вход в проект слоном
4. Завышенные ожидания
5. Борьба за статусность
6. плохо определенные проблемы бизнеса
7. Неадыкватное описание бизнеса
8.… и т.д.
неопределенностей много, некоторые из них исскуственно создаются интегратором, но управление требованиями как единица стратегии не решает индивидуальну ни одну из перечисленных определенностей. Так же повторюсь важна зрелость бизнеса как заказчика так и исполнителя.
Среди всех стандартов и программ которые собраны у вас в кучу и непонятно каким образом корелируют друг с другом, вы забыли самое главное — то что для зрелых процессов ИТ рамочным является ИСО 12207, уже манипулируя процессами внутри этого стандарта можно охватить все необходимые процессы для конкретного ИТ проекта. и не городить огород (ласкутное одеяло). Спасибо
неопределенности
1. Неопределенные качественно цели
2. непродуманные, неэффективные правила и процедуры согласования и управления
3. Заниженные бюджеты, вход в проект слоном
4. Завышенные ожидания
5. Борьба за статусность
6. плохо определенные проблемы бизнеса
7. Неадыкватное описание бизнеса
8.… и т.д.
неопределенностей много, некоторые из них исскуственно создаются интегратором, но управление требованиями как единица стратегии не решает индивидуальну ни одну из перечисленных определенностей. Так же повторюсь важна зрелость бизнеса как заказчика так и исполнителя.
Среди всех стандартов и программ которые собраны у вас в кучу и непонятно каким образом корелируют друг с другом, вы забыли самое главное — то что для зрелых процессов ИТ рамочным является ИСО 12207, уже манипулируя процессами внутри этого стандарта можно охватить все необходимые процессы для конкретного ИТ проекта. и не городить огород (ласкутное одеяло). Спасибо
За список софта спасибо. Учту.
В остальном статья темусисек управления требованиями совсем никак, ни в малейшей степени не раскрывает.
Основные грабли, из виденных мной, это:
1) прочувствовать разницу между ожиданиями и требованиями. Если требования будут исполнены, а ожидания не удовлетворены, то обязательно настанет негативный результат проекта. Какие методики на этом поприще?
2) ограничить «хотелки» заказчика рамками бюджета/проекта. А это фактически половина так называемых «управлений требованиями». Есть хинты?
3) заказчик не может уточнить требования, пока не увидит реализацию требований (в раннем согласовании) в реальном продукте. Как только видит, сразу понимает, что хотел не этого. Тема не раскрыта.
4) проекция требований. Система может быть построена почти всегда с точки зрения одного человека: либо директора, либо оператора, либо финансиста, либо аналитика, либо ещё кого-то. Одновременно всем она оптимально отвечать не сможет (чисса математически), максимум двоим-троим из десяти. Как выбрать ключевых и как заставить остальных подвинуться, не обижаясь? Иначе визы от остальных невозможно будет получить.
5) актуализация требований. Даже не считая решения №3 прототипированием надо учитывать, что согласно «требованию момента» набор изменится просто в течение проекта или сразу после него — указ новый выйдет, новый номер вестника бухгалтера подоспеет. Что делать?
В остальном статья тему
Основные грабли, из виденных мной, это:
1) прочувствовать разницу между ожиданиями и требованиями. Если требования будут исполнены, а ожидания не удовлетворены, то обязательно настанет негативный результат проекта. Какие методики на этом поприще?
2) ограничить «хотелки» заказчика рамками бюджета/проекта. А это фактически половина так называемых «управлений требованиями». Есть хинты?
3) заказчик не может уточнить требования, пока не увидит реализацию требований (в раннем согласовании) в реальном продукте. Как только видит, сразу понимает, что хотел не этого. Тема не раскрыта.
4) проекция требований. Система может быть построена почти всегда с точки зрения одного человека: либо директора, либо оператора, либо финансиста, либо аналитика, либо ещё кого-то. Одновременно всем она оптимально отвечать не сможет (чисса математически), максимум двоим-троим из десяти. Как выбрать ключевых и как заставить остальных подвинуться, не обижаясь? Иначе визы от остальных невозможно будет получить.
5) актуализация требований. Даже не считая решения №3 прототипированием надо учитывать, что согласно «требованию момента» набор изменится просто в течение проекта или сразу после него — указ новый выйдет, новый номер вестника бухгалтера подоспеет. Что делать?
Пункт 4 требует доказательств. Не верю, даже не смотря на упоминание математики. Почему не может-то?
Простой пример: OLAP vs OLTP — для OLAP операторам нужна хорошая нормализация, для OLTP аналитикам нужна хорошая денормализация.
Из OLTP быстро глубокого отчёта не построишь, с OLAP бизнес-процесс почти невозможен.
В одной базе это не уместить.
Первичное построение куба на данных OLTP долгий процесс, а кубы аналитику нужны постоянно разные.
Из OLTP быстро глубокого отчёта не построишь, с OLAP бизнес-процесс почти невозможен.
В одной базе это не уместить.
Первичное построение куба на данных OLTP долгий процесс, а кубы аналитику нужны постоянно разные.
Итого: в системе должно быть и то и другое, с постоянно-периодическим доливом данных из подсистемы OLTP в подсистему OLAP. И такая система одновременно удовлетворит обе подгруппы пользователей. Все так и делают, где на OLAP-аналитиков начальство выделяет деньги. Где я не прав?
во-1 это две системы (не подсистемы одного контракта). Вы выходите за рамки обсуждения одной системы. Сам заказчик сразу два параллельных контракта делать вряд ли будет — риск учетверяется.
во-2 это опять гемор с портированием данных, регулярно еженедельным. Какие-то кубы стареют, какие-то заново проектировать. Но это я ниже описал как №2. И опять это другой контракт — на оперирование OLAP.
во-2 это опять гемор с портированием данных, регулярно еженедельным. Какие-то кубы стареют, какие-то заново проектировать. Но это я ниже описал как №2. И опять это другой контракт — на оперирование OLAP.
с какого бодуна это другой контракт?
То есть вы уже согласны, что системы-подсистемы весьма разные, что пункт 4 о проекции справедлив, и дискутируем дальше?
Наоборот, не согласен. Контракт может быть всего один: первичный договор на создание системы, удовлетворяющей всех сразу.
Я по-прежнему считаю, что систему всегда можно сделать такой, чтоб она удовлетворяла требованиям всех групп её пользователей. В крайнем случае, за счёт включения в себя дополнительных подсистем. И никаких вынужденных «ущемлений» одних групп за счёт других со стороны системы быть не может. Ущемления отдельных групп пользователей могут быть лишь со стороны их начальства — заказчика системы, если это начальство будет не готово заплатить за те возможности системы, которые нужны только для этих групп.
Так, например, считать что OLAP-аналитики должны «подвинуться», чтоб система могла удовлетворить требованиям OLTP-сотрудников — в принципе некорректно, ибо без OLTP у OLAP вообще данных не будет.
Я по-прежнему считаю, что систему всегда можно сделать такой, чтоб она удовлетворяла требованиям всех групп её пользователей. В крайнем случае, за счёт включения в себя дополнительных подсистем. И никаких вынужденных «ущемлений» одних групп за счёт других со стороны системы быть не может. Ущемления отдельных групп пользователей могут быть лишь со стороны их начальства — заказчика системы, если это начальство будет не готово заплатить за те возможности системы, которые нужны только для этих групп.
Так, например, считать что OLAP-аналитики должны «подвинуться», чтоб система могла удовлетворить требованиям OLTP-сотрудников — в принципе некорректно, ибо без OLTP у OLAP вообще данных не будет.
«удовлетворяющей всех сразу»
Вы реально проекты внедряли? Реверс-инжиниринг делали, требования документировали?
Вы реально проекты внедряли? Реверс-инжиниринг делали, требования документировали?
Давайте лучше, не переходя на обсуждение моего опыта, Вы продемонстрируете доказательство или хотя бы пример, подтверждающий это Ваше утверждение: «Система может быть построена почти всегда с точки зрения одного человека. Одновременно всем она оптимально отвечать не сможет (чисто математически)»
Если возможно — тогда то самое, математическое.
так я уже и сказал: OLAP vs OLTP, и это разные системы.
Пример два: главбух говорит, что кнопка должна быть слева, а бух говорит, что справа.
Пример три: директор говорит, что надо регистрировать начало рабочего дня по активности в системе, а оператор говорит, что до включения компа он перебирает стопки договоров.
Пример четыре: начальник отдела считает, что клиента надо заводить визардом, а оператор знает, что удобнее одной длинной формой.
Пример пять: директор считает, что система должна снимать проблемы, а финансист считает, что лучше потерпеть с закрытием опердня, но иметь более верные с его точки зрения цифры.
Пример шесть: один считает, что система должна быть модулями, нанизанными на его бизнес-процесс, второй считает, что система должна быть цепочкой модулей в свою очередь его бизнес процесса.
«тысячи их»
Пример два: главбух говорит, что кнопка должна быть слева, а бух говорит, что справа.
Пример три: директор говорит, что надо регистрировать начало рабочего дня по активности в системе, а оператор говорит, что до включения компа он перебирает стопки договоров.
Пример четыре: начальник отдела считает, что клиента надо заводить визардом, а оператор знает, что удобнее одной длинной формой.
Пример пять: директор считает, что система должна снимать проблемы, а финансист считает, что лучше потерпеть с закрытием опердня, но иметь более верные с его точки зрения цифры.
Пример шесть: один считает, что система должна быть модулями, нанизанными на его бизнес-процесс, второй считает, что система должна быть цепочкой модулей в свою очередь его бизнес процесса.
«тысячи их»
1 — OLAP и OLTP — это разные ПОДсистемы. И к тому же первая без второй не бывает. То, что OLAP зачастую делается и продаётся отдельно — не означает, что она не является подсистемой, ибо продаётся она всегда для интеграции в общую систему учёта.
2 — кто её будет нажимать, того и слушать. Игнорирование мнения по подсистеме от человека, не работающего с этой конкретной подсистемой — не является ущемлением его возможностей. Однако, если он дело говорит, а непосредственный пользователь упирается — это проблема непосредственного пользователя и его начальства. Но не заказываемой системы.
3 — и как с точки зрения этих двух человек — директора и оператора — может быть по-разному построена система? Почему Вы считаете, что директор с оператором не смогут и, главное, не должны в любом случае, найти общее определение понятию «начало рабочего дня» и способ его учёта?
4 — см. отзыв 2
5 — см. отзыв 3. Кроме того, я не очень понял чем «снимать проблемы» противоречит выбору момента «закрытия опердня»?..
6 — что может помешать общие модули нанизать на две цепочки сразу? что может помешать сделать модули контекстно-зависимыми, знающими о текущей цепочке?
ни один не доказателен…
2 — кто её будет нажимать, того и слушать. Игнорирование мнения по подсистеме от человека, не работающего с этой конкретной подсистемой — не является ущемлением его возможностей. Однако, если он дело говорит, а непосредственный пользователь упирается — это проблема непосредственного пользователя и его начальства. Но не заказываемой системы.
3 — и как с точки зрения этих двух человек — директора и оператора — может быть по-разному построена система? Почему Вы считаете, что директор с оператором не смогут и, главное, не должны в любом случае, найти общее определение понятию «начало рабочего дня» и способ его учёта?
4 — см. отзыв 2
5 — см. отзыв 3. Кроме того, я не очень понял чем «снимать проблемы» противоречит выбору момента «закрытия опердня»?..
6 — что может помешать общие модули нанизать на две цепочки сразу? что может помешать сделать модули контекстно-зависимыми, знающими о текущей цепочке?
ни один не доказателен…
Дык это живая практика, чего доказывать. Можно было бы и переписку по этому поводу приподнять, где-то на тех предприятиях она могла сохраниться. Но вам придётся поверить, что она была такая, эта переписка.
Директору отчитываться акционерам, день не закрыт, финансист предварительные цифры дать не могёт, главбух ждёт когда аналитик докрутит перегруженную им базу, потому, что аналитик тоже даёт главу в отчёт директора. Кроме того главбух ждёт завершения своих транзакций — в банке сбой их системы. Результат простой: директор в ярости, вместо решения проблем исполнитель преобразовал их в другие.
А вы рисуете какого-то сфероконического заказчика, который во всех головах имеет единое мнение и гладких контрагентов.
Директору отчитываться акционерам, день не закрыт, финансист предварительные цифры дать не могёт, главбух ждёт когда аналитик докрутит перегруженную им базу, потому, что аналитик тоже даёт главу в отчёт директора. Кроме того главбух ждёт завершения своих транзакций — в банке сбой их системы. Результат простой: директор в ярости, вместо решения проблем исполнитель преобразовал их в другие.
А вы рисуете какого-то сфероконического заказчика, который во всех головах имеет единое мнение и гладких контрагентов.
Кто директору пообещал решение проблем, которые не могут быть решены — тот идиот или подлец. Сам директор видимо тоже не далёк от него…
Ибо невозможно получить отчёт, завязанный на ресурсоёмкий анализ не до конца собранных ещё данных и на результаты не проведённых банком транзакций. И значит отчёт, если он таки нужен, должен быть независим ни от того, ни от другого. Например, опираться на результаты вчерашнего дня или прошлой недели. Или включать раздел с легко получаемой сводкой по незавершённым транзакциям и не проанализированной первичке.
И акционеры вполне могут понять, если это представить в доступной форме, почему в отчёте нет той части, которую в принципе невозможно получить к заданному сроку.
Ибо невозможно получить отчёт, завязанный на ресурсоёмкий анализ не до конца собранных ещё данных и на результаты не проведённых банком транзакций. И значит отчёт, если он таки нужен, должен быть независим ни от того, ни от другого. Например, опираться на результаты вчерашнего дня или прошлой недели. Или включать раздел с легко получаемой сводкой по незавершённым транзакциям и не проанализированной первичке.
И акционеры вполне могут понять, если это представить в доступной форме, почему в отчёте нет той части, которую в принципе невозможно получить к заданному сроку.
Примеры 2 и 4 решаются индивидуальными и/или кастомизируемыми интерфейсами. Тут, правда, встаёт вопрос бюджета, но если заказчик хочет удовлетворить все такие требования своих пользователей, то проблем быть не должно.
«Ну, вы поняли...»
Заказчик не будет удваивать бюджет потому, что два человека видят систему по разному.
Он просто скажет, что старший прав не особо вникая.
И так по каждому вопросу. В результате получится система для директора, и не очень-то для оператора.
Заказчик не будет удваивать бюджет потому, что два человека видят систему по разному.
Он просто скажет, что старший прав не особо вникая.
И так по каждому вопросу. В результате получится система для директора, и не очень-то для оператора.
Если директор идиот, а подрядчик бесхребетен — да, так и получается.
Люди не идиоты, не льстите себе. Они некомпетентны в программировании и организации программистских проектов.
Кроме того они заняты своими делами, чтобы дополнительно заниматься решением программистских проблем.
Кроме того они заняты своими делами, чтобы дополнительно заниматься решением программистских проблем.
«Програмисстские проекты» тут как правило вообще не причём.
Согласитесь, что чтобы понять в какой последовательности должны быть расположены поля формы какогото доумента — не надо быть «крутым компьютерщиком» или чтото понимать в новомодных ныне «usability» и «UX» — для ответа на этот вопрос достаточно понаблюдать как люди заполняют соответсвующи бумажный бланк. в какой последовательности, куда подглядывают, с чем сверяются. И из этого этого вырастает пусть, возможно, не самый лучший вариант, но уже достаточно хороший и обоснованный.
И если в данной ситуации начальник этих операторов упорствует и требует всё неприменно сделать по «евойному» — то он просто «идиот».
А по поводу вашего тезиса о «невозможности удовлетворить всех» — в целом согласен. Но «математика» тут не причём) Причины этих проблем всёже — человеческий фактор, а не фундаментальное противоречие OLTP и OLAP)
Кстати — может быть кто-то может порекомендовать какую-нибудь толковую книгу по работе с людьми которые настроены неконструктивно?
Согласитесь, что чтобы понять в какой последовательности должны быть расположены поля формы какогото доумента — не надо быть «крутым компьютерщиком» или чтото понимать в новомодных ныне «usability» и «UX» — для ответа на этот вопрос достаточно понаблюдать как люди заполняют соответсвующи бумажный бланк. в какой последовательности, куда подглядывают, с чем сверяются. И из этого этого вырастает пусть, возможно, не самый лучший вариант, но уже достаточно хороший и обоснованный.
И если в данной ситуации начальник этих операторов упорствует и требует всё неприменно сделать по «евойному» — то он просто «идиот».
А по поводу вашего тезиса о «невозможности удовлетворить всех» — в целом согласен. Но «математика» тут не причём) Причины этих проблем всёже — человеческий фактор, а не фундаментальное противоречие OLTP и OLAP)
Кстати — может быть кто-то может порекомендовать какую-нибудь толковую книгу по работе с людьми которые настроены неконструктивно?
По пункту 5 — у требования же требуется наличие такой характеристики, как «Актуальность» — вот её подправляют с течением времени и получают новую картину, исходя из которой можно принимать очередные решения…
Неверно. Дополнительные требования увеличивают ожидания.
Если их реализовать, то упираемся в №2
Если их не реализовать, то сразу после внедрения ожидания не оправдываются — предприятие испытывало стресс реинжинринга, платило «огромные бабки», терпело часовые интервью, шло на всякие прочие жертвы, а система не удовлетворяет. По букве контракта да (и то если ТЗ однозначное), а по духу контракта (удалить проблемы заказчика) — нет. В лучшем случае будет плохая репутация. В худшем суд.
Если их реализовать, то упираемся в №2
Если их не реализовать, то сразу после внедрения ожидания не оправдываются — предприятие испытывало стресс реинжинринга, платило «огромные бабки», терпело часовые интервью, шло на всякие прочие жертвы, а система не удовлетворяет. По букве контракта да (и то если ТЗ однозначное), а по духу контракта (удалить проблемы заказчика) — нет. В лучшем случае будет плохая репутация. В худшем суд.
Нужно изначально не забывать одним из требований к системе указывать (учитывать) возможность развития и изменения требований, и исходя из этого сразу предусматривать достаточный уровень гибкости системы… Грамотный разработчик это знает, как минимум из негативного опыта, как максимум — из книжек и подобных бесед.
«Преждевременный рефакторинг — основа всех зол»/перефразированный Дейкстра/
Если вы в ТЗ таки акуратно учли главу «Перспективы развития, модернизации Системы», то это автоматически означает, что ТЗ написано почти окончательно, и вы натыкаетесь на грабли №3 «заказчик не может уточнить требования, пока не увидит реализацию».
Если вы в ТЗ таки акуратно учли главу «Перспективы развития, модернизации Системы», то это автоматически означает, что ТЗ написано почти окончательно, и вы натыкаетесь на грабли №3 «заказчик не может уточнить требования, пока не увидит реализацию».
Про грабли №3 — вполне реально заранее оговорить в договоре неизбежность итеративного подхода. Тут, правда, придётся подумать над условием выхода из цикла, и как заказчика с этим смирить…
И действительно проще бывает обмануть, пообщещать золотые горы в первой же итерации — но на такой хитрый подход обычно накладывают ограничения субъективная совесть и объективные перспективы судебного разбирательства и выплаты неустойки… И приходится стараться быть реалистом и добиваться от заказчика того же.
И действительно проще бывает обмануть, пообщещать золотые горы в первой же итерации — но на такой хитрый подход обычно накладывают ограничения субъективная совесть и объективные перспективы судебного разбирательства и выплаты неустойки… И приходится стараться быть реалистом и добиваться от заказчика того же.
«придётся подумать над условием выхода из цикла, и как заказчика с этим смирить…»
Во-1 это = грабли№2
Во-2 писать главу «Перспективы развития и модернизации Системы» вы уже слишком поспешили. В итеративном подходе стороны сами не знает куда повернёт проект, хотя грабли №3 и №5 вроде решаются почти мягко. С другой стороны если исполнитель не знает куда заведёт проект, он просто прекращает им управлять. То есть вряд ли уложится в сроки&бюджет&качество (тут контроллируется только качество).
Во-1 это = грабли№2
Во-2 писать главу «Перспективы развития и модернизации Системы» вы уже слишком поспешили. В итеративном подходе стороны сами не знает куда повернёт проект, хотя грабли №3 и №5 вроде решаются почти мягко. С другой стороны если исполнитель не знает куда заведёт проект, он просто прекращает им управлять. То есть вряд ли уложится в сроки&бюджет&качество (тут контроллируется только качество).
С граблями №2 я и не думал спорить :)
А что касается бесконтрольности — так на каждой итерации вполне реально оговаривать и бюджет, и сроки, и всю остальную конкретику. И пытаться контролировать их.
Другое дело, что НИОКР планировать по строкам и бюджету всегда сложно…
А что касается бесконтрольности — так на каждой итерации вполне реально оговаривать и бюджет, и сроки, и всю остальную конкретику. И пытаться контролировать их.
Другое дело, что НИОКР планировать по строкам и бюджету всегда сложно…
Это пошаговые контракты одного проекта (включающего несколько систем-подсистем). Вы пытаетесь разрезать систему по контрактам не на подсистемы уже, а на шаги квартальные шаги.
В свою очередь этот метод тоже неплох, но срок и бюджет проекта в целом становится по определению неисчислимым. Тут свои грабли — раздражения коллектива заказчика от стресса длительного реверс-инжиниринга, необходимости задерживаться после работы для ведения и тестирования параллельной системы. В конце концов middle management саботирует работу напрочь.
В общем, аффтар скрылся, предпочитая на вопросы не отвечать.
В свою очередь этот метод тоже неплох, но срок и бюджет проекта в целом становится по определению неисчислимым. Тут свои грабли — раздражения коллектива заказчика от стресса длительного реверс-инжиниринга, необходимости задерживаться после работы для ведения и тестирования параллельной системы. В конце концов middle management саботирует работу напрочь.
В общем, аффтар скрылся, предпочитая на вопросы не отвечать.
> В условиях современной экономики выигрывает тот, кто производит больше с меньшими затратами.
Это очень и очень спорный вопрос. Можно доказывать вплоть до обратного.
В современной экономике IT-компании переходят от понятий продукта к понятию сервиса, который не размывает грань между разработкой и поддержкой. 95% проектов достается крупным компаниям, которые имеют постоянных клиентов. Цены на рынке более-менее устоявшиеся. Причем, основные затраты уходят отнюдь не на разработку, а на т.н. огранизацию «сервиса» (на зарплату менеджерам, инфраструктура, etc...).
Скажу курьезную фразу, но для такого вида бизнеса (сервис) делать качественные и законченные продукты невыгодно. Вы поставляете решение, и заинтересованы в постоянном спросе на него (а не разовом заказе!). А для этого Вы должны поставлять всегда наполовину сделанное решение.
> По данным исследования, проведенного IBM в области IT, 60% затрат времени организации-разработчики
Классический пример неэффективно работающей компании. Огромные обороты при плачевном качестве продуктов, разрабатываемом на аутсорсинге (в Индии). Оборот, получаемый от продаж не идет ни в какое сравнение с затратами на разработку. Активно пытается пропехнуть свои Rational, крича о том, что все работают неэффективно. ))
Это очень и очень спорный вопрос. Можно доказывать вплоть до обратного.
В современной экономике IT-компании переходят от понятий продукта к понятию сервиса, который не размывает грань между разработкой и поддержкой. 95% проектов достается крупным компаниям, которые имеют постоянных клиентов. Цены на рынке более-менее устоявшиеся. Причем, основные затраты уходят отнюдь не на разработку, а на т.н. огранизацию «сервиса» (на зарплату менеджерам, инфраструктура, etc...).
Скажу курьезную фразу, но для такого вида бизнеса (сервис) делать качественные и законченные продукты невыгодно. Вы поставляете решение, и заинтересованы в постоянном спросе на него (а не разовом заказе!). А для этого Вы должны поставлять всегда наполовину сделанное решение.
> По данным исследования, проведенного IBM в области IT, 60% затрат времени организации-разработчики
Классический пример неэффективно работающей компании. Огромные обороты при плачевном качестве продуктов, разрабатываемом на аутсорсинге (в Индии). Оборот, получаемый от продаж не идет ни в какое сравнение с затратами на разработку. Активно пытается пропехнуть свои Rational, крича о том, что все работают неэффективно. ))
Если не считать db/2, то остальные продукты IBM вполне культурные :-)
Что касается некачественной работы, то тут есть три ситуации:
1) если вам разработка выгоднее, то выгоднее предыдущий проект завершить как можно полнее
2) если область постоянно меняется, как бухгалтерия, то в каждый конкретный момент у вас полностью завершённый продукт, но через месяц-два добавляются новые требования.
3) если вы не намерены делать проект в один год, то он вполне разумно бьётся на несколько лет поэтапно, так что в каждом конкретном этапе продукт завершён, а на следующем этапе развивается.
Но если вы пропагандируете что-то свыше трёх названных схем, то я бы с вами не работал — не хочется сидеть на игле халтуры.
Что касается некачественной работы, то тут есть три ситуации:
1) если вам разработка выгоднее, то выгоднее предыдущий проект завершить как можно полнее
2) если область постоянно меняется, как бухгалтерия, то в каждый конкретный момент у вас полностью завершённый продукт, но через месяц-два добавляются новые требования.
3) если вы не намерены делать проект в один год, то он вполне разумно бьётся на несколько лет поэтапно, так что в каждом конкретном этапе продукт завершён, а на следующем этапе развивается.
Но если вы пропагандируете что-то свыше трёх названных схем, то я бы с вами не работал — не хочется сидеть на игле халтуры.
Для любого бизнеса делать качественные и законченные долгоживущие продукты не выгодно — рынок насытится и очередные экземпляры продавать будет некому. Продукт должен быть либо одноразовым (типа пирожка), либо сподвигающим к совершенствованию, ремонту или замене. :(
Со слов «Глоссарием терминов программной инженерии IEEE», «стандартом разработки требований ISO/IEC 29148», «глоссарий ITILv3» и т.п. в интернет-статье ДОЛЖНЫ быть ссылки! Ну просто таки ОБЯЗАНЫ!!!
Но даже так статья весьма хороша.
Но даже так статья весьма хороша.
По ITILv3 получается бывают «Эргономические требования», что в виду их же определения обязательности для требования вводит меня в когнитивный диссонанс. Ибо обосновать обязательность ЛЮБОГО эргономического требования — совершенно нереально.
Так кто-нибудь какую то систему из перечисленных в статье использует? Или не из перечисленных
Указанные системы вроде достаточно старые, сейчас популярна идея реализовывать тоже самое на основе issue tracker-а (как плюс — не надо заниматься интеграцией 2-х систем).
Но есть особенность — иерархия требований может быть достаточно глубокой, так что полезно иметь в трекере возможность создавать иерархии задач большой глубины вложенности.
Но есть особенность — иерархия требований может быть достаточно глубокой, так что полезно иметь в трекере возможность создавать иерархии задач большой глубины вложенности.
Как можно понять из приведенного выше обзора программного обеспечения для управления требованиям все оно базируется на одном принципе — человек, а в данном случае, аналитик, вводит требование в систему, смотрит, нет ли такого требования в системе уже.
Принципов «несколько» больше, можно посмотреть хотя бы четыре отсюда Системы управления требованиями: что и зачем?
На днях вышла книжка по разработке и управлению требованиями на базе Cradle. Альфа-версия доступна бесплатно, включает учебный проект, выполненный по книжке. Посмотреть содержание и скачать можно отсюда saturs.ru/index.php?r=block/plain&label=cradle-book
Прямая ссылка для скачивания пакета с книжкой saturs.ru/elfiles/requirements_management_Cradle.zip
Прямая ссылка для скачивания пакета с книжкой saturs.ru/elfiles/requirements_management_Cradle.zip
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Управление требованиями к IT-проектам