Комментарии 29
Спасибо.
Жду с нетерпением следующую статью.
Жду с нетерпением следующую статью.
При уточнении требований, когда у нас уже есть частичная документация мы с этой документацией возвращаемся к пользователям. На практике пользователи редко понимают абстракции, сформулированные требования. Вот варианты использования ближе, ведь это по сути их пошаговые действия. Еще лучший способ это прототип и вариант использования. Прототип не обязательно должен быть написан программистами как часть будущей системы. Это может быть макет или рисунок на бумаге. Правда, чаще всего пользователь начнет обсуждать дизайн. Например такой диалог:
Пользователь: Это кнопка лучше бы слева смотрелась?
Аналитик: Почему?
Ползователь: Ну тогда после нажатия на неё всплывающий тескт не закрывал эту информацию, а мне удобнее видеть и то и другое одновременно.
Опытный аналитик сразу цепляется за слово «надо» и уже прикидывает: «это атрибут качества или функциональное требование?»
Пользователь: Это кнопка лучше бы слева смотрелась?
Аналитик: Почему?
Ползователь: Ну тогда после нажатия на неё всплывающий тескт не закрывал эту информацию, а мне удобнее видеть и то и другое одновременно.
Опытный аналитик сразу цепляется за слово «надо» и уже прикидывает: «это атрибут качества или функциональное требование?»
А нельзя-ли блок-схему привязать к циклу Деминга по управлению качеством:
— Совершенствование — Планирование — Выполнение — Анализ —
На мой взгляд, похоже.
— Совершенствование — Планирование — Выполнение — Анализ —
На мой взгляд, похоже.
Почему именно управление качеством? Это классический цикл управления всем — PDCA.
Данная схема также соответствует функциональной петле Петра Кузьмича Анохина.
Одно из описаний подхода приведено на сайте http://www.zooton.net/ind1026.html
Оттуда же — схема реакции человеческого организма:
Так что у этой классики еще и физиологические основы.
Одно из описаний подхода приведено на сайте http://www.zooton.net/ind1026.html
Оттуда же — схема реакции человеческого организма:
Так что у этой классики еще и физиологические основы.
Чем дальше, тем страшнее схемы))) Цель серии статей Как стать настоящим аналитиком? это помочь разобраться в работе аналитика, поделится опытом, придать ясности неопределенным вопросам. Можете ответить, чем блок схемы, которые вы представили в этом помогут. Заранее спасибо)
В том то и дело, что деятельность аналитика также может быть подвергнута анализу.
Мои предложения по анализу человеческой деятельности — в http://integral-community.ru/forum/viewtopic.php?f=8&t=12#p68
Таким образом, представленную в Вашем посте схему после инвариантного графического преобразования без потери смысла можно распространить на любую деятельность. На мой взгляд, это легче, чем запоминать отдельные интерпретации для кажого вида деятельности.
С уважением, Алексей.
Мои предложения по анализу человеческой деятельности — в http://integral-community.ru/forum/viewtopic.php?f=8&t=12#p68
Таким образом, представленную в Вашем посте схему после инвариантного графического преобразования без потери смысла можно распространить на любую деятельность. На мой взгляд, это легче, чем запоминать отдельные интерпретации для кажого вида деятельности.
С уважением, Алексей.
Ваша блок-схема — это циклически повторяющийся процесс принятия решения. В статье блок-схема представлена для наглядности и показывает этапы создания требований. И если вы заметили там присутствуют обратные связи, т.к. с любого этапа можно вернутся на этап, который был раньше.
Хотелось бы услышать опыт о разрешении конфликтов интересов.
Имеется ввиду конфликт интересов пользователей (руководство клиента тоже пользователи по сути).
Прямые саботажи (кому оно надо внедрять что-то новое, еще и «мутить» будут мешать, лучше все буду запутывать) и прочие человеческие факторы?
Хотелось бы статью на эту тему.
Ведь банальный подход — слушай того кто выше не пройдет — выше хочет побольше контроля, часто неуместного и т.п.
Имеется ввиду конфликт интересов пользователей (руководство клиента тоже пользователи по сути).
Прямые саботажи (кому оно надо внедрять что-то новое, еще и «мутить» будут мешать, лучше все буду запутывать) и прочие человеческие факторы?
Хотелось бы статью на эту тему.
Ведь банальный подход — слушай того кто выше не пройдет — выше хочет побольше контроля, часто неуместного и т.п.
Работая с пользователями, вы будете задавать вопросы, выслушивать ответы и наблюдать за их действиями (выявление требований).
Чтобы не упустить из виду потребности отдельных пользователей необходимо:
Выясните у пользователей, какие задачи им требуется выполнять средствами ПО.
Я правильно понял, что вы предлагаете разрабатывать систему только на основании пользовательских требований? А как же бизнес-требования? Как работа с разными заинтересованными лицами — заказчик, спонсор, владелец системы, покупатель, продавец, внедренец?
Я не предлагаю разрабатывать систему на основе только пользовательский требований. Я рассматривала требования в общем, т.е. они включают в себя бизнес-требования, пользовательские требования и функциональные требования. В статье описаны общие методы, которые подойдут и для бизнес-требований. Ведь бизнес-требования включают бизнес-цели организации и представление о внешнем виде и функциональности системы. Т.е. чтобы их выявить можно спросить у заинтересованных лиц, например Зачем мы начинаем данный проект? У меня чаще бывало, что сначала собираешь со всех требования, а уж потом разносишь по типам, что это бизнес-требования, пользовательские требования или функциональные.
Я считаю важным делать акцент, что сначала необходимо получить модель проблем ключевых заинтересованных лиц, а потом уже идти исследовать пользователей.
Потому что иначе мы можем пойти исследовать ту деятельность, которая никакого отношения к проблемам заказчика не имеет и её изменение/автоматизация влияния на них не окажет.
И если с пользователями нужно обсуждать их задачи, и, возможно, пожелания к устройству системы,
то с заказчиками нужно обсуждать прежде всего бизнес-проблемы и бизнес-эффекты, методы их измерения и т.д.
Совсем другая повестка встречи и содержание.
Потому что иначе мы можем пойти исследовать ту деятельность, которая никакого отношения к проблемам заказчика не имеет и её изменение/автоматизация влияния на них не окажет.
И если с пользователями нужно обсуждать их задачи, и, возможно, пожелания к устройству системы,
то с заказчиками нужно обсуждать прежде всего бизнес-проблемы и бизнес-эффекты, методы их измерения и т.д.
Совсем другая повестка встречи и содержание.
Рекомендация литературы убийственная — взяли и сходу самую толстую книгу порекомендовали, чтобы убиться ей, наверное :)
Можете ее не читать))) Есть и другие хорошие книги по анализу, но мне нравится эта)))
Мне тоже нравится. Но почему бы не порекомендовать более мягкий вход — например, с 60-100 страниц?
bagcheck.com/bag/1377
Вы знакомы со статьёй Химонина?
Зачем создавать такой высокий порог входа? Вам выгодна эта «элитарность» аналитиков? Не каждый, мечтающий стать аналитиком, долетит до середины Вигерса?
bagcheck.com/bag/1377
Вы знакомы со статьёй Химонина?
Зачем создавать такой высокий порог входа? Вам выгодна эта «элитарность» аналитиков? Не каждый, мечтающий стать аналитиком, долетит до середины Вигерса?
> Не каждый, мечтающий стать аналитиком, долетит до середины Вигерса
Именно поэтому и появилась эта серия статей:)
Именно поэтому и появилась эта серия статей:)
Денис, почему же сразу «высокий порог»? Книги можно и нужно читать системно: не за один подход, так за несколько. По-моему, Вигерс очень чётко всё разложил, чтобы можно было понять основы, прочитав книгу «по диагонали».
«Нужно» — это из идеального мира.
В реальном мире 95% требований пишут менеджеры проектов, у которых нет выделенного аналитика, потому что он не рентабелен в их проектах.
И вот у менеджера разработка требований — это ~20% всей работы, поэтому ожидать, что он будет читать книжку в 500 страниц — не приходится.
Основы можно и нужно понять по более простым и коротким книгам.
Зачем тратить время на анализ и выискивание полезного в большом тексте, если можно прочитать короткий?
В реальном мире 95% требований пишут менеджеры проектов, у которых нет выделенного аналитика, потому что он не рентабелен в их проектах.
И вот у менеджера разработка требований — это ~20% всей работы, поэтому ожидать, что он будет читать книжку в 500 страниц — не приходится.
Основы можно и нужно понять по более простым и коротким книгам.
Зачем тратить время на анализ и выискивание полезного в большом тексте, если можно прочитать короткий?
Зачем тратить время на анализ и выискивание полезного в большом тексте, если можно прочитать короткий?
Как вариант — усваиваемость лучше.
Конспекты сделаны для тех, кто уже понял материал, и хочет уточнить себе детали или что-то освежить в памяти.
А длинные учебники — чтобы много раз с разных сторон преподнести материал, чтобы ты понял.
Я не против длинных учебников вообще.
Я против того, чтобы первый учебник по теме был — длинным учебником.
Ну и про усваиваемость при браузинге большого вместо чтения короткого — я не верю.
Я против того, чтобы первый учебник по теме был — длинным учебником.
Ну и про усваиваемость при браузинге большого вместо чтения короткого — я не верю.
Ну вот простой пример — взял я на хабре пару статей, да и сделал себе из них конспект. Грубо говоря заголовки сохранил + некоторые мысли.
Вопрос: Человечку который не имеет достаточного опыта, но который скорее всего останется на моем месте когда я сбегу с этой работы — какой вариант давать? Ссылку на статьи или мои краткие записи? Нет, всё важное я таки выписал… Но читать дам лучше эти статьи. Со всеми комментариями. Со всеми оборотами автора. Ибо как минимум месяца два у человека есть, чтобы всё переварить, и т.п.
А если мне надо будет БЫСТРО ввести человека в курс дела, то я скажу «Открой папку RTFM, прочитай там всё, и заглядывай туда когда будут вопросы. Остальное уже на шишках выучишь».
Вопрос: Человечку который не имеет достаточного опыта, но который скорее всего останется на моем месте когда я сбегу с этой работы — какой вариант давать? Ссылку на статьи или мои краткие записи? Нет, всё важное я таки выписал… Но читать дам лучше эти статьи. Со всеми комментариями. Со всеми оборотами автора. Ибо как минимум месяца два у человека есть, чтобы всё переварить, и т.п.
А если мне надо будет БЫСТРО ввести человека в курс дела, то я скажу «Открой папку RTFM, прочитай там всё, и заглядывай туда когда будут вопросы. Остальное уже на шишках выучишь».
Усваиваемость это не демонстрирует.
Есть разные задачи, режимы и форматы:
Ознакомление — обзорный материал
Глубокое погружение — исследование
Изучение конкретной методики — методичка
Пересмотр своего опыта — модель процесса, подхода, карты понятий и явлений
Справка — справочник
Я настаиваю на том, кто конкретно Химонин и Леффингуэлл, а также, с мая, Корнипаев, а затем уже Кон и Коберн, будут лучшими вариантом для изучающего тему анализа и требований, чем отвратительно переведённый на русский многостраничный Вигерс.
Вы Вигерса читали?
Есть разные задачи, режимы и форматы:
Ознакомление — обзорный материал
Глубокое погружение — исследование
Изучение конкретной методики — методичка
Пересмотр своего опыта — модель процесса, подхода, карты понятий и явлений
Справка — справочник
Я настаиваю на том, кто конкретно Химонин и Леффингуэлл, а также, с мая, Корнипаев, а затем уже Кон и Коберн, будут лучшими вариантом для изучающего тему анализа и требований, чем отвратительно переведённый на русский многостраничный Вигерс.
Вы Вигерса читали?
Нет, не читал.
Мои аргументы были против
Я не могу спорить с вопросом отвратительности перевода, если я его не читал.
Вопрос усваиваемости это не столько вопрос размера, сколько концентрации новых знаний.
Если опытный инженер вполне удовлетворится такой записью
То неопытному лучше объяснять так:
Мои аргументы были против
Я против того, чтобы первый учебник по теме был — длинным учебником.
Я не могу спорить с вопросом отвратительности перевода, если я его не читал.
Вопрос усваиваемости это не столько вопрос размера, сколько концентрации новых знаний.
Если опытный инженер вполне удовлетворится такой записью
Колесо — устройство для уменьшения силы трения при перемещении предметов.
Колесо — круглое. Другая форма как правило неэффективна, но бывают варианты.
Технически колеса это относительно небольшие устройства закрепленные на основном транспортном средстве так, чтобы они могли свободно прокручиваться. Эффект уменьшения силы трения основан на том, что сила трения качения меньше.
Недостатки — сложность конструкции, требует более качественных материалов и обработки
Преимущества — значительное сокращение силы трения и как следствие экономия энергоресурсов.
То неопытному лучше объяснять так:
Для того, чтобы сократить количество рабов необходимых для транспортировки груза необходимо сократить усилие, требуемое для перемещения груза.
Давайте представим себе, что нам нужно переместить сто тысяч огромных камней.
Очевидно, что количество рабов необходимое для перемещения каждого камня зависит от веса камня.
Однако мы не можем уменьшить камень — тогда нам понадобится больше камней, так что выигрыш будет сомнительным.
Давайте подумаем — что мешает камню двигаться?
Оказывается, что это так называемая сила трения.
Да, не удивляйтесь — камень просто трется о дорогу, и это мешает ему двигаться быстрее.
Сила трения зависит от многих факторов — от веса камня, от его размера, от площади контакта с дорогой, от качества дороги, от гладкости камня, и еще от многих факторов.
Еще наши предки заметили, что более гладкий камень легче тянуть, что если поливать дорогу перед камнем водой, то тянуть будет легче, что можно подложить под камень мягкие шкуры, и множество других хитростей.
Однако революционным было открытие, что сила трения качения намного меньше — в самом деле, если толкать бревно так чтобы оно катилось, то это будет сделать намного легче, чем толкать его перпендикулярно. Хотя казалось бы — площадь соприкосновения с дорогой одинакова, вес одинаков и т.п.
О причинах такого удивительного феномена мы узнаем в следующей главе. А сейчас мы научимся этим пользоваться.
Давайте подложим пять-шесть бревен под наш камень. Так толкать камень становится значительно проще.
Однако камень перемещается по бревнам, и их приходится постоянно переставлять с зада на перед.
Как это можно еще улучшить?
Представьте себе, что мы подкладываем под камень не целые бревна, а только короткие куски по краям камня.
Катить такую конструкцию ничуть не тяжелее чем предыдущую, но она чертовски нестабильна, чурки все время норовят выкатится…
Давайте соединим противоположные чурки длинной палкой.
А эти палки соединим между собой другими палками, но таким образом, чтобы палки соединяющие чурки могли свободно крутиться в местах соединения.
Наша конструкция стала чуть менее быстрой, за счет силы трения в местах соединения, зато намного более стабильной. И как бонус — мы можем закрепить на поперечных палках настил, который не будет крутится, а значит
положив на него наш камень, нам не придется что-то перекладывать и т.п.
Так вот, дорогие читатели — те чурки, на которых катится наша конструкция называются колесами.
Это вы демонстрируете различные стили изложения.
Второй стиль, более пространный и наглядный — это не то, чем отличается Вигерс.
Мой опыт показывает, что в среднем, при одинаковом стиле изложения, вероятность прочтения книги обратно пропорциональна квадрату от её объёма.
Второй стиль, более пространный и наглядный — это не то, чем отличается Вигерс.
Мой опыт показывает, что в среднем, при одинаковом стиле изложения, вероятность прочтения книги обратно пропорциональна квадрату от её объёма.
Кстати, ваши комментарии хорошо иллюстрируют мои тезисы — анализом интересуетесь, вопросы по теме задаёте узкие, предметные (про конфликт требований ЗЛ), т.е. в теме не новичок, а Вигерса не читали.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Как стать настоящим аналитиком? Часть 2. Выявляем требования