Форум Сообщества Аналитиков
Общий раздел => Для всех => Тема начата: maksiq от 27 Июня 2012, 10:21:26
-
Пост навеян ретроспективой прошедшего ЛАФ-2012.
Я тут осознал, что на фестивале было много докладов про место аналитика, про организацию процесса и общение с бизнесом, но очень мало собственно про основную работу аналитика - проектирование системы. Из тех, что я слышал к этой категории можно отнести доклады Алексея Смирнова про Реверс-инжиниринг требований в проекте по миграции КИС и Рустема Гайфутдинова про прототипирование GUI, и еще Юрий Веденин про юзабилити рассказывал.
Этому могут быть три объяснения:
1) работа аналитика выродилось в описание usecase/userstory и проектирование интерфейса, остальное делают разработчики;
2) когда первичные требования сняты, в проектировании реализацию - структуры данных и прочее - нет ничего сложного, берешь и делаешь;
3) все общее, что можно сказать о проектировании, сказано методологами по ООП и другими, остальное зависит от проекта и сплошной креатив - не расскажешь и не обсудишь.
Мне все эти варианты не слишком нравятся, да и не представляются верными.
Поэтому как идея: попробовать перед программой следующего ЛАФ поработать над поиском докладов именно в эту сторону.
А что остальные думают? Было бы интересно услышать/рассказать/обсудить именно проектирование системы?
Да, Саша Байктн попросил уточнить, что я понимаю под проектированием системы. Если рассмотреть классический процесс, то там есть этап бизнес-анализа, на котором тем или иным способом выясняются и формулируются потребности бизнеса, и этап системного анализа, на котором создается архитектура и/или дизайн системы (методологи расходятся). Включая структуру данных/классов и интерфейсов, но не ограничиваясь ими.
-
Я сильно соглашусь с Максимом. Он попал в точку ситуации. У меня подобное ощущение тоже складывается. Правда, для себя я это обозначал иначе: переносом акцента на организацию, чем на практику и технологию. Т.е. мысль, что мол вот навыки аналитика они как есть, так и есть. И чего о них рассказывать. Когда уходим в рассуждения о технических вопросах, то тут все сильно зависит от контекста и тоже казалось бы нечего обсуждать - у каждого своя правда, никто не договорится. Но может быть договоримся?
Я сейчас пытаюсь поднять курс по Системной инженерии и в поисках материала обнаружил кое-что полезное. Например, про архитектуру, которая автором рассматривалась как некоторая деятельность на стыке процессов работы с требованиями и проектирования. Есть и другие моменты требующие обсуждения.
Ясно, что для людей с интеллектом нет ничего невозможного, и то что раз решено, перестает так сильно волновать и воспринимается обыдено. Но вот это и может быть сильно интересно другим.
-
А может просто сначала опишем критерии почему я , он , они не занимаются проектированием системы.
1. Не хватает опыта для проектирования всей системы. Говоря понятиями Дениса Иванов и Федора Новикова, часто трудно охватить и представление использования, и представление структуры, и представление поведения системы.
2. Не дают (сформулировал требования и свободен :)). Дальше разработчики решают. Можно сказать - организационная часть . В АПКИТ, например разделяют, Системный аналитик и Системный архитектор.
3. Финансовая сторона - мне не платят за доп работу. Это уже нацеленность именно команды на результат. Одному сложновато спроектировать систему.
4. Нет времени еще и на это. Именно в данном проекте. Что-то вроде, надо за 2 неделе написать ТЗ, когда надо новое и по сути в ТЗ описываешь требования только для общей архитектуры системы.
-
На одной посещённой мною конфереции (ProfsoUX) доклады были сгруппированы по трём темам - требования, разработка, тестирование. Возможно, в будущем имеет смысл и на ЛАФ сделать что-то похожее, но перекос, на мой взгляд, всё равно должен быть в сторону требований.
-
Коллеги, по тому же самому BABoK'у нет разделения на системного и бизнес-аналитика - всё это выполняет бизнес-аналитик, и на сертификат CBAP будут спрашивать всё)))
Соглашусь с вами - был явный перекос в сторону методологии, психологии и оценки качества. Ещё, по-моему, был слабо освещен вопрос работы аналитика в смежных предметных областях, ничего не было сказано про синтез новых знаний, а это очень важная часть системного анализа ???
Также, не поднимали вопрос о разнице между бизнес-аналитиком и экспертом предметной области - а многие даже опытные специалисты и руководители делают эти понятия синонимами :'(
-
Максим, спасибо за актуальную тему.
У меня есть такое мнение на этот счет.
1) работа аналитика выродилось в описание usecase/userstory и проектирование интерфейса, остальное делают разработчики;
Описание это лишь малая часть работы аналитика.
Основные задачи:
- построение коммуникаций Заказчик - Разработчик (Заказчик - Система);
- управление требованиями;
- управление "ожиданиями Заказчика" (в части проектируемых систем).
Не стоит забывать, что есть проекты связанные с внедрением различных систем на интегрированных платформах (1C, Axapta, Oracle, SAP и т.п.), где доля классического или ООП программирования невысока. В таких проектах востребованы сущностные модели и модели прикладного решения.
И здесь нужны очень серьезные знания по текущему или готовому решению, что требует наличия Архитектора решения, который может оценить предлагаемые изменения с точки зрения всей системы (или совокупности систем).
2) когда первичные требования сняты, в проектировании реализацию - структуры данных и прочее - нет ничего сложного, берешь и делаешь;
3) все общее, что можно сказать о проектировании, сказано методологами по ООП и другими, остальное зависит от проекта и сплошной креатив - не расскажешь и не обсудишь.
Я сторонник "разумной специализации". И для тех проектов про которые я говорил наличие выраженной роли архитектора (ведущего разработчика) очень важно.
В этом случае "сложность" переходит на уровень Архитектора.
Также это позволяет аналитику не особо углубляться в очень уж технические моменты и направлять свои усилия на логический уровень системы и коммуникации с Заказчиком.
А что остальные думают? Было бы интересно услышать/рассказать/обсудить именно проектирование системы?
Мне кажется аналитикам важнее обсуждать не собственно само проектирование, а именно вопросы взаимодействия аналитик - архитектор/разработчик.
Я, например, как аналитик на всех проектах на которые прихожу говорю: "Я не буду вмешиваться серьезно в архитектуру решения, но оставляю за собой право на экспертизу предлагаемых решений и возможность блокировать те или иные решения, если они не укладываются в стратегию развития системы и имеют сомнительную ценность для Заказчика."
С другой стороны аналитик понимая архитектуру решения и понимание как проектируются системы должен помочь донести до Заказчика моменты связанные с ограничениями выбранной платформы или архитектуры, убедить что сложность решения задачи в постановке заказчика превышает выгоды от использования, отсекать "хотелки" не отвечающие требованиям (ну или трансформировать "хотелки" в более серьезные требования решающие проблемы бизнеса в целом, а не конкретного пользователя).
На следующем ЛАФе было бы интересно привлечь на конференцию представителей "его величество Заказчика" (в следующем году возможно я смогу выступить в такой роли и сделать доклад или поучаствовать в дискуссии). В моем новом проекте куда ухожу с 09 июля, я как раз буду выступать в первую очередь на стороне бизнеса и выстраивать отношения и процессы взаимодействия с подразделением разработки.
-
Максим, аналитик отвечает за проектирование ВНЕШНИХ свойств системы. Архитектор, разработчик — ВНУТРЕННЕГО устройства.
Внешние свойства описываются логикой взаимодействия, НФТ и пользовательским интерфейсом.
Часто, особенно для заказных систем, внутренней разработки описать логику взаимодействия трудно без предварительного/параллельного анализа бизнес-процессов.
Второй необязательной деятельностью является сущностное моделирование.
Часто ещё аналитик описывает внутренние алгоритмы, но на языке предметной области, а не платформы разработки.
Иногда проектирует ИС как ИС, а не просто ПО, но такое редко кому достаётся по ряду причин.
Резюмируя, типовыми объектами работы аналитика являются, по мере убывания частоты:
1. Внешнее поведение системы
2. Алгоритмы (бизнес-правила)
3. Внешний облик системы
4. Устройство предметной области
5. Процесс, который строится или меняется при создании/доработке этой программной системы
6. Организационно-техническая система (бизнес)
Собственно 1, 3 и 4, 5 — это то, что больше всего обсуждалось на конференции. Всё разумно.
-
Не было на ЛАФ, да и на других не помню, кроме своего доклада: "Описание инфологической модели. Применимость различных нотаций в зависимости от контекста." Тема сложная, но идет на ура. Только где на нее докладчика найти?
Что касается проектирования системы, то часто аналитик берет на себя описание и/или разработку API. С внешними системами, так это просто раздел 34.602. Но бывает обязательно и внутренние API. Опять же скажу по двум проектам, в которых участвовал тема очень интересная и весьма сложная.
Такая же тема про нефункциональные требования. Мало кто делает, хотя очень полезно. Вот и докладов нет. Мы просто не доросли.
-
Не было на ЛАФ, да и на других не помню, кроме своего доклада: "Описание инфологической модели. Применимость различных нотаций в зависимости от контекста." Тема сложная, но идет на ура. Только где на нее докладчика найти?
Тема-то какая? Опсание инфологической модели? А насколько устойчив данный термин сейчас? А что значит в различных нотациях, в чем прелесть?
-
Не было на ЛАФ, да и на других не помню, кроме своего доклада: "Описание инфологической модели. Применимость различных нотаций в зависимости от контекста." Тема сложная, но идет на ура. Только где на нее докладчика найти?
Что касается проектирования системы, то часто аналитик берет на себя описание и/или разработку API. С внешними системами, так это просто раздел 34.602. Но бывает обязательно и внутренние API. Опять же скажу по двум проектам, в которых участвовал тема очень интересная и весьма сложная.
Такая же тема про нефункциональные требования. Мало кто делает, хотя очень полезно. Вот и докладов нет. Мы просто не доросли.
Ну так и "дорастите" к следующему ЛАФУ - сделайте доклады на эти темы :). Тем более есть опыт в проектах.
-
Все-таки, у нас - сообщество системных аналитиков, а не бизнес-аналитиков. Системный аналитик - он (по классике) стоит после бизнес-аналитика и создает дизайн системы, в рамках верхнеуровневой архитектуры, заданной архитектором. Это к вопросу о понятиях вообще. Если говорить о практике, то, наверное, где-то аналитик выступает именно как бизнес-аналитик, снимает требования в виде usecase/userstory, а дальше все делают разработчики. Но, наверное, не все так - кто-то из аналитиков делает диаграммы классов/ER-диаграммы, описывают поведение объектов системы? И там есть свои проблемы и решения. И хочется к следующему ЛАФу призвать поделиться опытом. Я могу рассказать как делаем мы (я, собственно, весь прошлый год рассказывал это на разных конфах, включая ЛАФ), но мне интересно чужой опыт послушать...
-
создает дизайн системы, в рамках верхнеуровневой архитектуры, заданной архитектором
Максим, можно ссылку на такое классическое определение? Классическое для какой культуры?
Почему ты считаешь, что разработка use case'ов — это бизнес-анализ?
-
Все-таки, у нас - сообщество системных аналитиков, а не бизнес-аналитиков.
А я думал что мы "волшебники". Максим я бы не стал так ограничивать границы сообщества.
-
Все чаще задумываюсь о месте чистого системного аналитика. И прихожу к такому выводу: думаю, что такая профессия себя изживет. Бизнес-аналитики активно осваивают информационные технологие и вникнуть в технические тонкости разрабатываемой системы им уже не сложно. Например, в нашей компашке смело пишут US и выполняют две функции бизнес и системный анализ. А писать ТЗ с реализацией проще программисту, чем СА вечно пристающий с вопросами к программисту. Т.е. функции СА разделит БА и Разработчик между собой. Да сейчас БА и СА могут позволить только крупные и богатые компании.
-
Системный аналитик - он (по классике) стоит...
Для начало с определений можно начать
Максим а можно ссылку на классику :)
А то на разное ссылаться будем.
Что делает аналитик - обязанности:
Организует аналитическое и методическое обеспечение проведения исследовательских работ. Проводит аналитическую и научно-исследовательскую работу с целью сбора, оценки и анализа получаемой информации, а также выработки практических рекомендаций. Осуществляет мониторинг публикаций, в том числе в российских и зарубежных средствах массовой информации, дает им оценку. Составляет необходимую отчетную документацию. Координирует деятельность соисполнителей при совместном выполнении работ с другими структурными подразделениями организации.
-
Под классикой я понимал Водопадную модель (http://en.wikipedia.org/wiki/Waterfall_model), из которой выросло в том или ином виде большинство стандартов. И уже потом они вобрали в себя agile-подходы. Так вот, requiremenrs - бизнес-аналитик, design - системный аналитик и архитектор.
Я не имею ввиду ограничить сообщество системным анализом, потому как действительно столь детальное ролевое деление сейчас встречается редко, обычно выделяют роль "аналитик", который занимает позицию между заказчиком и разработчиком, но при этом ограничиваться частью requirements я бы считал неправильным, тем более что по факту, я уверен, многие аналитики занимаются не только этой частью. О чем и был мой пост.
-
Что делает аналитик - обязанности:
Организует аналитическое и методическое обеспечение проведения исследовательских работ. Проводит аналитическую и научно-исследовательскую работу с целью сбора, оценки и анализа получаемой информации, а также выработки практических рекомендаций. Осуществляет мониторинг публикаций, в том числе в российских и зарубежных средствах массовой информации, дает им оценку. Составляет необходимую отчетную документацию. Координирует деятельность соисполнителей при совместном выполнении работ с другими структурными подразделениями организации.
Кажется, я недавно встречал такие требования (http://www.facebook.com/pages/%D0%A0%D0%A6%D0%A3%D0%9F/247982328568639?sk=app_188363131263770) к должности "аналитик" в описании вакансии на одном из сайтов :)
-
У меня была мысль сделать на ЛАФ доклад "Почему системные аналитики не занимаются системным анализом", как раз на тему что обычно ожидают от системного аналитика и что он на самом деле может дать проекту. Но в этом году не сложилось приехать...
Насчет обязаностей - с моей точки зрения самое правильное определение дает (как это не смешно) Википедия: http://en.wikipedia.org/wiki/System_analyst (http://en.wikipedia.org/wiki/System_analyst):
A systems analyst researches problems, plans solutions, recommends software and systems, and coordinates development to meet business or other requirements.
Это, как бы, отличительное качество системного аналитика, присущее роли.
А дальше, в разделе "Чем может заниматься аналитик", можно найти все из вышеперчисленных занятий:
...
* Interact with customers to learn and document requirements that are then used to produce business requirements documents.
* Write technical requirements from a critical phase.
* Help programmers during system development, ex: provide use cases, flowcharts or even Database design.
...
...
* Document requirements or contribute to user manuals.
* Whenever a development process is conducted, the system analyst is responsible for designing components and providing that information to the developer.
...
-
На самом деле при выставлении требований к аналитику очень хорошо на что-нибудь опираться.
На википедию как-то не очень хорошо.
А вот на законодательство, точнее на Приказ Министерства здравоохранения и социального развития РФ (про Квалификационный справочник должностей руководителей, специалистов и других служащих) это уже можно. Но обычно данный документ используется при написании должностных инструкций.
И спасибо Максиму за простое определение
Так вот, requiremenrs - бизнес-аналитик, design - системный аналитик и архитектор
-
Друзья, рискну отвлечь вас от завязавшегося холивара на тему разновидностей аналитиков и их обязанностей. Всё же цель данной дискуссии - выявить темы докладов о проектировании систем, которые нам было бы интересно услышать или о которых мы могли бы рассказать.
Например, в исходном обсуждении в гугл групс было такое пожелание:
Максим прав, хочется услышать больше именно про проектирование. Например, про принципы проектирования систем определенного назначения, например CRM. Тема неисчерпаемая.
В ответ могу предложить доклад о том, как мы проектировали и прототипировали (http://youtu.be/PhVNBUEN7bc) интерфейсы веб-клиента CRM-системы взамен устаревшего десктоп-клиента. Таким образом, если на ЛАФ-2012 наш доклад (https://vimeo.com/44926180) был о процессе прототипирования в компании в целом, то теперь мы можем показать, как это работает на конкретном проекте. Интересен был бы такой доклад?
p.s. Максим, благодарю за упоминание моего доклада. Все мысли и идеи, представленные в нём, я собрал в статье на Хабре (http://habrahabr.ru/company/alee/blog/146781/), приглашаю к обсуждению.
-
Но, наверное, не все так - кто-то из аналитиков делает диаграммы классов/ER-диаграммы, описывают поведение объектов системы? И там есть свои проблемы и решения.
От мне интересно на каких проектах востребовано что-то большее нежели Use case/User Story/GUI Mock up?
3 год в аналитике, для успеха проекта наличие UML и ER диаграм не влияло на разработку.
И если делать UML/ER диаграммы как показать роботодателю и заказчику ихнюю нужность?
-
От мне интересно на каких проектах востребовано что-то большее нежели Use case/User Story/GUI Mock up?
Оказывается есть такие проекты.
Например в ваших проектах есть справочники - где и как они хранятся? А ролевая модель?
А сущности , точнее объекты предметной области и логические взаимосвязи между ними как Вы показываете.
Вот Задача - написать разработчику что делать, перечень полей, и т.п.
То здесь нам ER поможет. :) Или просто деятельность какую-нибудь описать.
И не обязательно их Заказчику показывать, если это для разработчика.
-
Оказывается есть такие проекты.
Например в ваших проектах есть справочники - где и как они хранятся? А ролевая модель?
А сущности , точнее объекты предметной области и логические взаимосвязи между ними как Вы показываете.
Вот Задача - написать разработчику что делать, перечень полей, и т.п.
То здесь нам ER поможет. :) Или просто деятельность какую-нибудь описать.
И не обязательно их Заказчику показывать, если это для разработчика.
Да есть, как правило в состояние на момент старта проекта. При предложение пересмотреть/передизайнить заказчики( в даном случае) девелоперы не понимают зачем им ето нужно. А ПМ зачем на ето тратить еще время.
-
И если делать UML/ER диаграммы как показать роботодателю и заказчику ихнюю нужность?
Диаграммы — это инструмент:
1. Быстрой передачи информации. В случае, если используются простые неформальные диаграммы или ARIS eEPC/VAD. Не UML, и даже наверное не BPMN.
2. Обеспечения качества требований. Для анализа полноты, что ничего не забыли из того, что должно как-то отразиться в требованиях — входы/выходы, последовательности, связи. Для этого подходят DFD, UML, ER, BPMN.
Диаграммы 1 могут быть понятны и полезны заказчику при прикладывании оправданных усилий с вашей стороны.
Диаграммы 2 — это ваша внутренняя кухня. Заказчику они на фиг не сдались, также как и покупателю современного телевизора схемы его внутренней разводки. Если повезёт, они также могут быть полезны разработчику для цели 1. Но обычно на это рассчитывать не стоит.
Объяснять работодателю необходимость конкретных видов диаграмм — это всё равно, что объяснять необходимость теодолита для геодезиста.
Разумнее вести разговор о составе работ, и рисках для проекта по срокам и деньгам, если какие-то работы не будут сделаны.
В этом составе работ графическое моделирование не должно выделяться как отдельный этап, а быть встроенной частью моделирования и разработки требований — т.е. работ по созданию артефактов, представляющих однозначную ценностью для заказчика и работодателя (Концепция, ТЗ, Регламенты деятельности, Инструкция по использованию программы).
-
Спасибо огромное за описание подхода.