Комментарии 38
Из описания CMMI-0 в каком-то фициальном документе мне понравилось «Производственный процесс подобен хаосу, результат достигается за счет героического усилия отдельных лиц»
+2
Вот если бы автор изложил предложенную шкалу с характеристиками отдельных этапов своими словами, исходя из собственного опыта — было бы гораздо интереснее. Сейчас же первое, что приходит в голову при ознакомлении с предложенной классификацией — «поверхностная», «формальная», «местами подменяющая понятия». Впрочем, это могут быть и проблемы перевода. Примеры ниже.
И да… Что я отчаянно люблю в моделях зрелости, так это то, как скромно молчат их продвиженцы о естественных результатах любого процесса взросления. Да и сами модели этот вопрос обходят как-то стороной. :)
Пример 1.
«Первый шаг перехода от полного отсутствия требований к их появлению — это выявление и документирование требований.»
Первый ли? Вот, например, отечественные ГОСТы 19 и 34 серии. Они позволяют документировать требования в ряде простых и непритязательных документов, которые отвечают всем перечисленным в пункте критериям.
А кроме того, они в своем составе предполагают много чего разного, включая инструменты трассировки, характерные лишь для 4-го уровня предложенной классификации.
Пример 2.
«набора требований который понятно, непротиворечиво и однозначно описывает желаемое поведение разрабатываемого продукта. Для того, чтобы получить требования с указанными критериями качества, необходимо придерживается принятых правил оформления спецификаций, хранить их в доступном всем участникам проекта месте, разграничить права доступа к требованиям и вести историю изменений.»
«Для продолжения рода нужно совсем другое» (с) «Тот самый Мюнхгаузен»
Все перечисленное «необходимое» улучшит лишь доступность набора требований (как техническую, так и в какой-то степени «когнитивную»). Перечисленные условия не имеют ничего общего с обеспечением непротиворечивости и однозначности. «Понятность» же в первую очередь зависит от косноязычия формулировщика требований, и только затем (не сильно) от выбранного способа их оформления.
Пример 3.
«Таким образом, на третьем уровне зрелости выполняются активности по планированию процесса управления требованиями и группировки выявленных требований по типам в соответствии с объединяющими признаками, что облегчает управление и приводит к лучшему пониманию требований всеми участникам проекта.»
Можно подумать, на других «уровнях зрелости» об этих активностях никто и не помышляет. Например, двумя уровнями ранее, без всяких специальных инструментов запросто происходит и планирование управления, и само управление, и группировка требований.
И да… Что я отчаянно люблю в моделях зрелости, так это то, как скромно молчат их продвиженцы о естественных результатах любого процесса взросления. Да и сами модели этот вопрос обходят как-то стороной. :)
Пример 1.
«Первый шаг перехода от полного отсутствия требований к их появлению — это выявление и документирование требований.»
Первый ли? Вот, например, отечественные ГОСТы 19 и 34 серии. Они позволяют документировать требования в ряде простых и непритязательных документов, которые отвечают всем перечисленным в пункте критериям.
А кроме того, они в своем составе предполагают много чего разного, включая инструменты трассировки, характерные лишь для 4-го уровня предложенной классификации.
Пример 2.
«набора требований который понятно, непротиворечиво и однозначно описывает желаемое поведение разрабатываемого продукта. Для того, чтобы получить требования с указанными критериями качества, необходимо придерживается принятых правил оформления спецификаций, хранить их в доступном всем участникам проекта месте, разграничить права доступа к требованиям и вести историю изменений.»
«Для продолжения рода нужно совсем другое» (с) «Тот самый Мюнхгаузен»
Все перечисленное «необходимое» улучшит лишь доступность набора требований (как техническую, так и в какой-то степени «когнитивную»). Перечисленные условия не имеют ничего общего с обеспечением непротиворечивости и однозначности. «Понятность» же в первую очередь зависит от косноязычия формулировщика требований, и только затем (не сильно) от выбранного способа их оформления.
Пример 3.
«Таким образом, на третьем уровне зрелости выполняются активности по планированию процесса управления требованиями и группировки выявленных требований по типам в соответствии с объединяющими признаками, что облегчает управление и приводит к лучшему пониманию требований всеми участникам проекта.»
Можно подумать, на других «уровнях зрелости» об этих активностях никто и не помышляет. Например, двумя уровнями ранее, без всяких специальных инструментов запросто происходит и планирование управления, и само управление, и группировка требований.
+4
Leonid76, я еще ни разу не встречал, чтобы разработка программного проекта велась по документам, подготовленным по ГОСТ 19 и 34 серий. А встречал, когда наоборот — документы по указанным стандартам готовились постфактум и носили формальный характер. Если же требования и готовились перед началам проекта, то исключительно для того, чтобы потешить самолюбие заказчика, повторяющего магическое заклинание: «Техническое задание». После чего про документ забывали и начинали просто «кодить».
По поводу косноязычия согласен, но уверен, что не один я сталкивался с «трудностями перевода» при чтении документа, написанного литературным языком, но сплошным текстом.
В статье категорично не заявляется, что структурирование требований должно производиться исключительно с использованием специализированных инструментов. Указанные активности являются показателями зрелости процесса и если команда проекта прибегает к ним ранее, то это говорит исключительно об ее профессионализме.
По поводу косноязычия согласен, но уверен, что не один я сталкивался с «трудностями перевода» при чтении документа, написанного литературным языком, но сплошным текстом.
В статье категорично не заявляется, что структурирование требований должно производиться исключительно с использованием специализированных инструментов. Указанные активности являются показателями зрелости процесса и если команда проекта прибегает к ним ранее, то это говорит исключительно об ее профессионализме.
0
я еще ни разу не встречал
А я встречаю регулярно. В основном — по 34 серии. Когда и ТЗ, и технорабочий проект — не формальность, а насущная потребность. И в отношениях с заказчиком, и в организации разработки (особенно когда работает несколько команд от разных юрлиц, да еще и раскиданных по разным городам).
Разумеется, количество таких проектов на нашем ИТ-рынке сильно меньше, чем «сделайте мне магазин, быстро и дешево».
В статье категорично не заявляется, что структурирование требований должно производиться исключительно с использованием специализированных инструментов
Разве?
Уровень 3. Структурирование требований
На данном уровне зрелости возникает необходимость применения специализированных инструментальных средств, предназначенных для работы с требованиями.
если команда проекта прибегает к ним ранее, то это говорит исключительно об ее профессионализме
Либо о недостатках классификации.
Поймите правильно — я не стараюсь забросать статью экскрементами. Просто становится не по себе, когда неплохие, в общем, мысли продвигаются в жизнь в такой вот наивной оболочке. Это чревато вполне измеримыми потерями и снижением КПД нашего «производства».
Кроме всего прочего, такое вот разделение на «уровни взросления» между строк говорит, что 1 — это детский лепет, а 5 — это круто и солидно. Но в реалиях, 5й уровень — это высочайшей цены компромисс между управляемостью и производительностью рабочих команд в масштабах крупных организаций. И у него масса отрицательных эффектов. Один из них — то, что фокус профессионального мастерства «постановщика требований» смещается от содержания к форме (от самих требований к инструментам управления ими). То есть, специалист считается крутым не потому, что он круто обращается с требованиями, а потому, что у него 5-й дан по какому-нибудь энтерпрайз-архитектору.
0
разделение на «уровни взросления» между строк говорит, что 1 — это детский лепет, а 5 — это круто и солидно
В свое повествование я вкладывал несколько иной смысл:
принятие решения о достижении того или иного уровня зрелости процесса управления требованиями должно осуществляться взвешено и на основании четкого понимания целей и задач, стоящих перед командой проекта или компанией
и еще
достижение высокого уровня зрелости в одном процессе не гарантирует общего повышения зрелости организации в целом
Я сам сторонник того, что бОльший уровень развития порождает бОльшие накладные расходы. Это не всегда бывает оправдано и только крупная компания может себе позволить пожертвовать производительностью в угоду управляемости.
Что же касается категоричности, то я смягчил формулировку в статье.
Leonid76, спасибо за обратную связь!
0
В свое повествование я вкладывал несколько иной смысл:
Это неотъемлемый атрибут моделей взросления. Мол, «взрослеть надо, чада неразумные».
Пришлось бы приложить очень большие усилия, чтобы его нивелировать. Гораздо больше процитированных. А самое главное, делать это особо незачем. Иначе суть подхода теряется.
принятие решения о достижении того или иного уровня зрелости
Сейчас звучит примерно как «всё, я решил, что мне теперь есть 18!»
Наверное, можно принять решение о приведении процессов в соответствие с требованиями того или иного уровня зрелости. Но решить, что «мы теперь зрелые вот на столько» — это вряд ли.
и только крупная компания может себе позволить пожертвовать производительностью в угоду управляемости.
Гм… Скорее, крупная компания не может себе позволить не жертвовать. Иначе у нее будет беда. Исключение — крупные компании, состоящие из относительно маленьких полуавтономных «ячеек».
спасибо за обратную связь!
Рад стараться!
0
«я еще ни разу не встречал, чтобы разработка программного проекта велась по документам, подготовленным по ГОСТ 19 и 34 серий.»
ГОСТ 34 — не на программы, а не информационные системы, если вы последними не занимались, немудрено, что вы не встречали :)
А ГОСТ 19 достаточно простой по сути, там значимых разделов — раз-два и обчёлся, поэтому сейчас распространены более современные стандарты на структуру требований типа IEEE 838: school.system-analysis.ru/standards/
ГОСТ 34 — не на программы, а не информационные системы, если вы последними не занимались, немудрено, что вы не встречали :)
А ГОСТ 19 достаточно простой по сути, там значимых разделов — раз-два и обчёлся, поэтому сейчас распространены более современные стандарты на структуру требований типа IEEE 838: school.system-analysis.ru/standards/
0
Что за мещанская склонность к искажению смысла цитируемого текста и желание интерпретировать его в удобном для себя контектсте? А контекст тут простой — самопиар, ведь цитирующий руководит и преподает в указанной Школе.
Моя фраза полность звучит так:
Кроме того, в ГОСТ'е нет понятия «информационная система», а есть термин «автоматизированная система» (см. ГОСТ 34.003-90). Именно это, а не выдернутая из контекста фраза, иллюстрирует кто с чем не знаком. :)
Моя фраза полность звучит так:
Я еще ни разу не встречал, чтобы разработка программного проекта велась по документам, подготовленным по ГОСТ 19 и 34 серий. А встречал, когда наоборот — документы, по указанным стандартам, готовились постфактум и носили формальный характер.
Кроме того, в ГОСТ'е нет понятия «информационная система», а есть термин «автоматизированная система» (см. ГОСТ 34.003-90). Именно это, а не выдернутая из контекста фраза, иллюстрирует кто с чем не знаком. :)
0
Все верно, но это отлично работает, когда есть заказчик и его требования. Да, есть такое мнение, что заказчик бывает внутренним. Верно, бывает, но формализация этих отношений как с внешним заказчиком часто несет лишние риски проекту. (Это отдельная большая тема, достойная большой статьи)
Если разработка продуктовая и тем более инновационная (стартапы) — требования превращаются в гипотезы и эксперименты. В таком режиме строгое структурирование требований часто вступает в противоречие с гибкой разработкой. Это уже высший пилотаж, управления требованиями в гибкой разработке.
Если разработка продуктовая и тем более инновационная (стартапы) — требования превращаются в гипотезы и эксперименты. В таком режиме строгое структурирование требований часто вступает в противоречие с гибкой разработкой. Это уже высший пилотаж, управления требованиями в гибкой разработке.
0
ncix, не соглашусь! Не важно, какой заказчик — внешний или внутренний, важно, что у каждого программного продукта есть заинтересованное лицо или лица, которые ждут от него разрешения своих проблем (удовлетворения потребностей). И команда проекта должна быть нацелена как раз на удовлетворение этих самых потребностей, а не на реализацию собственного видения решения, изучение новых технологий и т.д. То есть основная задача состоит в синхронизации видения конечного продукта между всеми участниками проекта. В каком виде описывать и насколько подробно доносить — это вопрос другой, но требования должны быть!
0
Вы с чем именно не согласны?
Требования конечно должны быть, только эти требования — гипотезы. Т.е. мы предполагаем что клиенты захотят такой продукт с такими фичами. Через полгода выясняется что не с такими а с другими. А мы уже два месяца потратили на спеку и ее согласование и 4 на первый черновой релиз.
В такой ситуации требования должны максимально быстро перемещаться из области идей в задачу разработчику.
Требования конечно должны быть, только эти требования — гипотезы. Т.е. мы предполагаем что клиенты захотят такой продукт с такими фичами. Через полгода выясняется что не с такими а с другими. А мы уже два месяца потратили на спеку и ее согласование и 4 на первый черновой релиз.
В такой ситуации требования должны максимально быстро перемещаться из области идей в задачу разработчику.
0
Не согласен с тем, что Вы заведомо усложняете. Разве где-то сказано, что для проверки гипотезы нужно потратить большое количество времени на разработку спецификации по стандарту IEEE 830, например? Скорее наоборот.
0
Но тогда я не очень понимаю: если для проверки гипотезы нужно что-то запрограммировать, требования на данном этапе будут или нет?
0
И еще, управление требованиями подразумевает многоэтапное и многоуровневое их согласование. Что, без должного вмешательства, очень сильно растягивает разработку. Поэтому, управляя требованиями, нельзя забывать об эффективности согласовательного процесса между участниками.
0
Нет, не подразумевает. Оно вполне может быть, но не обязано.
0
Ок, возможно, бывают ситуации когда Заказчик (или Product Owner) написали спеку со своим видением, а разработке остается только взять под козырёк и делать. Но я такого никогда не видел.
Обычно спеку согласуют как минимум с экспертом по разработке, который должен сказать реализуемо ли это, в какой сррок и какими ресурсами. Если проект большой — таких экспертов несколько. А результат экспертизы может запросто привести к пересмотру требований, т.к. оценочные качество-сроки-ресурсы не устроят заказчика.
Обычно спеку согласуют как минимум с экспертом по разработке, который должен сказать реализуемо ли это, в какой сррок и какими ресурсами. Если проект большой — таких экспертов несколько. А результат экспертизы может запросто привести к пересмотру требований, т.к. оценочные качество-сроки-ресурсы не устроят заказчика.
0
В реальности почти всегда обязательно, т.к. в любом серьезном проекте у лиц, уполномоченных утверждать окончательный вариант требований, нет ни компетенций, ни времени (это просто не их задача) писать требования самим. А раз автор и утверждающий — разные лица, то процесс согласования неизбежен. Продуктовая разработка имеет свою специфику, но там мороки с огласованиями (правда уже внутри компании-вендора) не меньше
+1
Процесс согласования неизбежен. Избежны такие вещи, как многоуровневость и многоэтапность.
Пример многоуровневости (как это могло бы быть прописано в Регламенте управления требованиями):
Порядок согласования требований.
Сформулированное требование согласуется в следующей последовательности:
1. С руководителем группы разработки.
2. С руководителем проекта ООО «Василек».
3. С ответственным за раз/дорабатываемый продукт ООО «Василек»
4. С функциональным заказчиком.
5. С руководителем проекта от Заказчика.
6. С генеральным директором ООО «Василек».
7. С генеральным директором Заказчика.
Там же, уже про этапы:
Этапы согласования требований
Для согласования с руководителем группы разработки (РГР) устанавливаются следующие этапы:
1. Предоставление требований на ознакомление — не менее, чем за 10 дней до плановой даты их согласования.
2. Отработка замечаний и предложений руководителя группы разработки — не позднее, чем за 3 дня до плановой даты их согласования.
3. Устранение финальных замечаний — не позднее дня плановой даты согласования требований.
Для согласования с руководителем проекта устанавливаются следующие этапы:
1. Предоставление требований на ознакомление — не менее, чем за 15 дней до плановой даты их согласования.
…
и т.д.
А по факту, аналитик пришел к программисту, спросил «я тут такую хрень придумал, закодить сможешь?». По получении утвердительного ответа пошел к заказчику и сказал: «мы для тебя разработали уникальное, не имеющее аналогов по эффективности решение!...» а дальше — рассказал про то, как замечательно свежепридуманная хрень порешает задачи заказчика до полного восторга у последнего. Менеджер продукта? Нет такого. Архитектор? А ему пофиг. Директор? Да он потом на всем техпроекте оптом распишется.
Пример многоуровневости (как это могло бы быть прописано в Регламенте управления требованиями):
Порядок согласования требований.
Сформулированное требование согласуется в следующей последовательности:
1. С руководителем группы разработки.
2. С руководителем проекта ООО «Василек».
3. С ответственным за раз/дорабатываемый продукт ООО «Василек»
4. С функциональным заказчиком.
5. С руководителем проекта от Заказчика.
6. С генеральным директором ООО «Василек».
7. С генеральным директором Заказчика.
Там же, уже про этапы:
Этапы согласования требований
Для согласования с руководителем группы разработки (РГР) устанавливаются следующие этапы:
1. Предоставление требований на ознакомление — не менее, чем за 10 дней до плановой даты их согласования.
2. Отработка замечаний и предложений руководителя группы разработки — не позднее, чем за 3 дня до плановой даты их согласования.
3. Устранение финальных замечаний — не позднее дня плановой даты согласования требований.
Для согласования с руководителем проекта устанавливаются следующие этапы:
1. Предоставление требований на ознакомление — не менее, чем за 15 дней до плановой даты их согласования.
…
и т.д.
А по факту, аналитик пришел к программисту, спросил «я тут такую хрень придумал, закодить сможешь?». По получении утвердительного ответа пошел к заказчику и сказал: «мы для тебя разработали уникальное, не имеющее аналогов по эффективности решение!...» а дальше — рассказал про то, как замечательно свежепридуманная хрень порешает задачи заказчика до полного восторга у последнего. Менеджер продукта? Нет такого. Архитектор? А ему пофиг. Директор? Да он потом на всем техпроекте оптом распишется.
0
аналитик пришел к программисту, спросил «я тут такую хрень придумал, закодить сможешь?». По получении утвердительного ответа пошел к заказчику и сказал: «мы для тебя разработали уникальное, не имеющее аналогов по эффективности решение!...»
Только потом окажется что программист закодил не то и не через 2 дня а через две недели. И ответит, что о сроках его не спрашивали, а задание он со слов аналитика понял именно так, как сделал. А клиент посмотрев на решение, отказался покупать. И с кого спрашивать, если нет официального согласования?
И, главное, где тут формализованные структурированные требования? В словах аналитика?
0
Только потом окажется что программист закодил не то и не через 2 дня а через две недели.
Это уже реализация, а не согласование. Требование согласовано аж с заказчиком (не так уж и редко у аналитика есть на это полномочия).
А клиент посмотрев на решение, отказался покупать.
Он ведь был в восторге и согласился, когда аналитик ему это презентовал?
И с кого спрашивать, если нет официального согласования?
А если есть? Если же нет — то это или нарушение процесса (в котором заказчик должен поставить согласующие подписи) или риски того же процесса (если «верим на слово»). Может быть и так, и так. И последствия будут разными.
И, главное, где тут формализованные структурированные требования? В словах аналитика?
Нет их тут. Пример — про важный участок работ под названием «согласование». Давайте считать, что после восторгов заказчика все требования были внесены «куда следует», протрассированы и включены в планы релизов.
0
Это уже реализация, а не согласование.Так согласование и нужно, чтобы реализация соответствовала требованию, не так ли? Поэтому требование должно быть максимально подробным. И программист, лишь один раз получивший «на орехи» за неверную интерпретацию требований, в следующий раз будет занудно и педантично выяснять все детали, и требовать их письменной спецификации, прежде чем приступит к работе. Это мое наблюдение из практики.
Он ведь был в восторге и согласился, когда аналитик ему это презентовал?Так ведь закодили не то что презентовали :)
Давайте считать, что после восторгов заказчика все требования были внесены «куда следует», протрассированы и включены в планы релизов.Так это и потребует уйму времени.
0
Так согласование и нужно, чтобы реализация соответствовала требованию, не так ли?
В частном случае — так.
Еще раз хочу обратить внимание: эта ветка идет от Вашего поста с утверждением «управление требованиями подразумевает многоэтапное и многоуровневое их согласование». Мои посты в ней — на тему этого утверждения.
До согласования и после него с требованиями может происходить много интересного и в разной степени полезного. Здесь я этого вопроса не касался. Только «утверждение», только хардкор.
Поэтому требование должно быть максимально подробным. И программист, лишь один раз получивший «на орехи» за неверную интерпретацию требований, в следующий раз будет занудно и педантично выяснять все детали, и требовать их письменной спецификации, прежде чем приступит к работе. Это мое наблюдение из практики.
В зависимости от того, кто на него смотрит, и от преследуемой цели (согласование — это одно, разработка — другое, тестирование — третье и т.д.), требование может выглядеть очень по-разному (не меняя своей сути). К заказчику мы идем с концепцией требования, программисту отдаем детализацию, с тестировщиком обсуждаем кейсы по требованию.
0
Статья очень спорное впечатление производит. Оказывается, управление изменениями требований уже не ключевая и жизненно необходимая для любого современного проекта активность, а нечто nice to have, что появляется только в идеале — на последнем уровне зрелости. А базовые вещи у нас, оказывается, не забывать картинки в доках нумеровать
+1
Не поверхностно. За это спасибо!
Но однонаправленно. В части перед «введением» создавалось предчувствие, что будет глубоко, и совсем не плоско. Но по факту нет движения от банальной релевантности до понятий и метрик типа левериджа. Это не спорит с вашими утверждениями. Это им перпендикулярно, и именно поэтому может создать объемное восприятие и понимание проблематики.
Я хотел раздавать ссылку на эту статью! Благо есть кому и зачем давать. Пока не допишете — сделать этого не могу.
Вопросы, если есть, пишите в ЛС (хотя гугль тоже может подсказать почти все, можно просто брать и копировать заинтересовавшие фразы).
Но однонаправленно. В части перед «введением» создавалось предчувствие, что будет глубоко, и совсем не плоско. Но по факту нет движения от банальной релевантности до понятий и метрик типа левериджа. Это не спорит с вашими утверждениями. Это им перпендикулярно, и именно поэтому может создать объемное восприятие и понимание проблематики.
Я хотел раздавать ссылку на эту статью! Благо есть кому и зачем давать. Пока не допишете — сделать этого не могу.
Вопросы, если есть, пишите в ЛС (хотя гугль тоже может подсказать почти все, можно просто брать и копировать заинтересовавшие фразы).
0
Опять под управлением требованиями понимается разработка требований и управление требованиями.
Сходите что-ли сам CMMI почитайте, если уж:
www.software-quality-assurance.org/cmmi-requirements-management.html
www.software-quality-assurance.org/cmmi-requirements-development.html
Это всё равно, что разработку автомобиля называть управлением автомобиля.
Сходите что-ли сам CMMI почитайте, если уж:
www.software-quality-assurance.org/cmmi-requirements-management.html
www.software-quality-assurance.org/cmmi-requirements-development.html
Это всё равно, что разработку автомобиля называть управлением автомобиля.
0
Денис, отличные ссылки. :)
Во первых строках читаем:
Во первых строках читаем:
Disclaimer: The opinions expressed here are the authors
and do not express a position on the subject from the
Software Engineering Institute (SEI) or any organization
or SEI Partner affiliated with the SEI.
0
Ну так они же на CMMI основываются, а не на земельном кодексе Зимбабве. Имхо это лучше, чем никаких ссылок на первоисточники, как в статье.
0
Так и статья автора тоже не на земельном кодексе. И даже ссылка есть:
(А даже если была бы на земельном кодексе — какая разница? Гораздо интереснее, что получилось в результате.)
Я о том, что собственное мнение авторов по тем двум ссылкам настолько же авторитетно, сколь и собственное мнение нашего автора (в хорошем смысле).
В частности, мешать разработку требований и управление ими или нет — дело вкуса, навыков (и «качества» кадров в целом), оперативной ситуации, случая и прочих факторов.
Я, например, более эффективным вижу разработку требований со встроенными фичами под дальнейшее управление ими во вполне конкретном окружении. Цена такого подхода — невысокая эффективность разработки без понимания специфики дальнейшего управления и невысокая эффективность управления без понимания нюансов разработки. Другими словами — высокие ожидания от сотрудников и повышенная стоимость(продолжительность) выхода сотрудников на крейсерскую производительность.
Если вернуться к Вашей аналогии, эффективнее (с точки зрения раскрытия возможностей и знания недостатков) водить автомобиль, спроектированный и собранный своими руками.
обнаружил шкалу уровней зрелости процесса управления требованиями (requirements management maturity), предложенную в 2003 году одним из специалистов по работе с требованиями Rational Software Джимом Хьюманном (Jim Heumann).
(А даже если была бы на земельном кодексе — какая разница? Гораздо интереснее, что получилось в результате.)
Я о том, что собственное мнение авторов по тем двум ссылкам настолько же авторитетно, сколь и собственное мнение нашего автора (в хорошем смысле).
В частности, мешать разработку требований и управление ими или нет — дело вкуса, навыков (и «качества» кадров в целом), оперативной ситуации, случая и прочих факторов.
Я, например, более эффективным вижу разработку требований со встроенными фичами под дальнейшее управление ими во вполне конкретном окружении. Цена такого подхода — невысокая эффективность разработки без понимания специфики дальнейшего управления и невысокая эффективность управления без понимания нюансов разработки. Другими словами — высокие ожидания от сотрудников и повышенная стоимость(продолжительность) выхода сотрудников на крейсерскую производительность.
Если вернуться к Вашей аналогии, эффективнее (с точки зрения раскрытия возможностей и знания недостатков) водить автомобиль, спроектированный и собранный своими руками.
0
Леонид, давайте к основам.
Умение различать понятия, проводить границы — одно из важнейших аналитических умений.
Запихивая деятельность по созданию чего-то под название «управление», мы теряем важные компоненты смысла.
Про то, как совмещать эти деятельности на практике — отдельный разговор, я тут не против ваших рассуждений совершенно.
Умение различать понятия, проводить границы — одно из важнейших аналитических умений.
Запихивая деятельность по созданию чего-то под название «управление», мы теряем важные компоненты смысла.
Про то, как совмещать эти деятельности на практике — отдельный разговор, я тут не против ваших рассуждений совершенно.
0
Умение различать понятия, проводить границы — одно из важнейших аналитических умений.
Запихивая деятельность по созданию чего-то под название «управление», мы теряем важные компоненты смысла.
Так вроде никто и не утверждал, что созидание и управление — одно и то же. Просто они настолько пересекаются и врастают друг в друга, что рассматривать одно вне контекста другого — как раз и есть верный способ потерять важные компоненты смысла. Практически важные.
Именно поэтому я считаю, что с прикладной точки зрения полезно рассматривать разработку в составе управления. В его контексте, так сказать. Или же наоборот: что во что встраивать, зависит от относительных масштабов явлений в конкретной ситуации. Может получиться так, что управление станет «бедным родственником» при разработке.
Ну а в автоматизаторской жизни под «управлением» каким-то объектами чаще всего подразумевается активность а-ля CRUD («управление договорами», «управление учебными группами», «управление анкетами» и т.п.). То же худо-бедное управление персоналом — и то начитается с разработки образа будущего сотрудника (а не худо-бедное — с «сот» под образы в виде оргштатки).
Про то, как совмещать эти деятельности на практике — отдельный разговор
Если применение теории на практике требует большого напильника, то может, с ней что-то не так? Классик утверждал, что теория без практики мертва.
Я не призываю отказаться от этих теорий. Они милы и по-своему полезны. Я призываю не применять их как нечто, имеющее абсолютный авторитет. А уж тем более, как прокрустово ложе.
0
Пара ссылок на ту же тему, на которые почему-то постеснялся сослаться автор:
grigorash.ru/archives/905
www.ibm.com/developerworks/ru/library/r-requirements/
grigorash.ru/archives/905
www.ibm.com/developerworks/ru/library/r-requirements/
0
Тогда уж приведу ссылку на оригинал:
http://www.ibm.com/developerworks/rational/library/content/RationalEdge/feb03/ManagementMaturity_TheRationalEdge_Feb2003.pdf
http://www.ibm.com/developerworks/rational/library/content/RationalEdge/feb03/ManagementMaturity_TheRationalEdge_Feb2003.pdf
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Уровни зрелости процесса управления требованиями