Результаты попыток проанализировать анализ (страница 4)




Главная   Форумы   Общие вопросы по работе с требованиями   Результаты попыток проанализировать анализ

В теме 67 ответов, и 7 участников, последнее обновление сделано пользователем Аватар (AndrewK) Андрей Курьян 13 г, 6 мес. назад.

Показано 15 ответов - от 46 до 60 (всего 68)
  • Автор
    Сообщения
  • 27.05.2011 в 12:16 # 5273
    Аватар (Belle Morte)
    Belle Morte
    Участник

    Если есть поставленная задача, то анализ уже не нужен. Если конечно вы не хотите подвергнуть задачу сомнению или если вы все таки берете не отдельные требования.

    Вот с этим не соглашусь. Был опыт работы на большом проекте (примерно 50 разработчиков в команде). Аналитики имели представление обо всей системе в целом, разработчики — об отдельных частях, которые сами писали. Все новые задачи от заказчика проходили через аналитиков для того, чтобы определить приоритет, надо ли их реализовывать вообще (проект — большой, бывало и такое, что какая-то фича уже есть, а заказчик забыл), решить вопросы с правами доступа к новому функционалу, обеспечить преемственность и тому подобное.

    Поделиться:

    Цитировать

    27.05.2011 в 12:21 # 5274
    Аватар (AndrewK)
    Андрей Курьян
    Участник

    [quote="Belle Morte"]
    Не будем рассматривать целый проект, возьмем конкретное требование: требуется такой-то такой-то скрин для определенной цели (по сути это — уже задача). Следующий шаг по алгоритму — переформулировать требования в [b]проблему[/b]. Вот этот момент меня и смущает: зачем каждую задачу конвертить в проблему, затем — в противоречие и т.д. ?

    Похоже у нас с вами разные представления на тему того что такое анализ и зачем он нужен.
    Если есть поставленная задача, то анализ уже не нужен. Если конечно вы не хотите подвергнуть задачу сомнению или если вы все таки берете не отдельные требования.[/quote]

    В связи с этим возникает интересный вопрос: должен ли аналитик находить решения и превращать их в задачи?
    Дело в том, что если аналитик не работает с решениями, то откуда он узнает, что какие-то решения порождают проблемы?
    С другой стороны, если аналитик хорошо знает решения, то зачем тогда нужны программисты?

    Предлагаю обсудить эту проблему и противоречие, которое имеет место…

    Поделиться:

    Цитировать

    27.05.2011 в 12:23 # 5275
    Аватар (Belle Morte)
    Belle Morte
    Участник

    [quote="Belle Morte"]Стоп. Вернемся к алгоритму:

    1) Определить основную цель проекта.
    2) Выделить бизнес требования.
    3) Переформулировать требования в виде проблем.
    ….
    Не будем рассматривать целый проект, возьмем конкретное требование: требуется такой-то такой-то скрин для определенной цели (по сути это — уже задача). Следующий шаг по алгоритму — переформулировать требования в [b]проблему[/b]. Вот этот момент меня и смущает: зачем каждую задачу конвертить в проблему, затем — в противоречие и т.д. ?

    ИМХО, п 3) следует расшифровать:
    3.1) Найти решения, удовлетворяющие требованиям
    3.2) Проверить, не порождают ли эти решения проблем
    3.3) Если проблемы возникли, то зафиксировать проблемы[/quote]

    Вот это выглядит уже правдоподобно. Только не расшифровать, а заменить пункт 3.
    Правда мы опять возвращаемся к вопросу "а как, собственно, найти эти решения без анализа тупиковых ветвей?" :)

    Поделиться:

    Цитировать

    27.05.2011 в 12:34 # 5276
    Аватар (Belle Morte)
    Belle Morte
    Участник

    В связи с этим возникает интересный вопрос: должен ли аналитик находить решения и превращать их в задачи?
    Дело в том, что если аналитик не работает с решениями, то откуда он узнает, что какие-то решения порождают проблемы?
    С другой стороны, если аналитик хорошо знает решения, то зачем тогда нужны программисты?

    Предлагаю обсудить эту проблему и противоречие, которое имеет место…

    Это хороший вопрос. Я думаю, с одной стороны, для этого от аналитика и требуется знание IT, отсюда и проблемы без этого знания найти работу. При этом знание широкое, но не глубокое, если вы понимаете, о чем я: аналитик представляет себе набор возможных решений и проблемы, которые они влекут, но не настолько хорошо, чтобы сесть самому и строчить код.
    А когда речь заходит о каких-то фундаментальных решениях, ИМХО принимать их должен аналитик в тандеме с архитектором.

    Поделиться:

    Цитировать

    27.05.2011 в 12:44 # 5277
    Аватар (AndrewK)
    Андрей Курьян
    Участник

    [quote="AndrewK"][quote="Belle Morte"]Стоп. Вернемся к алгоритму:

    1) Определить основную цель проекта.
    2) Выделить бизнес требования.
    3) Переформулировать требования в виде проблем.
    ….
    Не будем рассматривать целый проект, возьмем конкретное требование: требуется такой-то такой-то скрин для определенной цели (по сути это — уже задача). Следующий шаг по алгоритму — переформулировать требования в [b]проблему[/b]. Вот этот момент меня и смущает: зачем каждую задачу конвертить в проблему, затем — в противоречие и т.д. ?

    ИМХО, п 3) следует расшифровать:
    3.1) Найти решения, удовлетворяющие требованиям
    3.2) Проверить, не порождают ли эти решения проблем
    3.3) Если проблемы возникли, то зафиксировать проблемы[/quote]

    Вот это выглядит уже правдоподобно. Только не расшифровать, а заменить пункт 3.
    Правда мы опять возвращаемся к вопросу "а как, собственно, найти эти решения без анализа тупиковых ветвей?" :)[/quote]

    Уточнение: выбрать решения, удовлетворяющие требования. Решения — это то, что мы уже знаем. Если решение "тупиковое", то это уже не решение, а проблема. Поэтому нет никакого "анализа тупиковых ветвей" на уровне решения.

    Поделиться:

    Цитировать

    27.05.2011 в 12:55 # 5278
    Аватар (AndrewK)
    Андрей Курьян
    Участник

    [quote="AndrewK"] В связи с этим возникает интересный вопрос: должен ли аналитик находить решения и превращать их в задачи?
    Дело в том, что если аналитик не работает с решениями, то откуда он узнает, что какие-то решения порождают проблемы?
    С другой стороны, если аналитик хорошо знает решения, то зачем тогда нужны программисты?

    Предлагаю обсудить эту проблему и противоречие, которое имеет место…

    Это хороший вопрос. Я думаю, с одной стороны, для этого от аналитика и требуется знание IT, отсюда и проблемы без этого знания найти работу. При этом знание широкое, но не глубокое, если вы понимаете, о чем я: аналитик представляет себе набор возможных решений и проблемы, которые они влекут, но не настолько хорошо, чтобы сесть самому и строчить код.
    А когда речь заходит о каких-то фундаментальных решениях, ИМХО принимать их должен аналитик в тандеме с архитектором.[/quote]

    Я понимаю :-)
    Но при таком подходе возникает серая зона между аналитиком и программистом. Знаний аналитика может не хватить, и проблема проявится уже только у программиста. Знаний программиста может не хватить для распознавания проблемы. тогда проблема проявится уже у заказчика. Что, собственно, недопустимо.

    Другими словами, мы имеем дело с классическим компромиссом: аналитик знает решения, но не настолько хорошо, чтобы …; программист знает проблемы, но не настолько хорошо, чтобы…

    В ТРИЗ в таких ситуациях выполняется операция, которая называется обострение противоречия. Давайте применим эту операцию к нашему случаю. Давайте представим, что аналитик по-любому не может знать решений настолько хорошо, чтобы узнать о возникновении проблемы. Аналогично, программист не может знать специфику требований заказчика, чтобы распознать проблему в решениях. Что будем делать?

    Поделиться:

    Цитировать

    27.05.2011 в 13:42 # 5279
    Аватар (Belle Morte)
    Belle Morte
    Участник
    AndrewK, это все-таки уже оффтоп, давайте вернемся к обсуждению алгоритма, предложенного Phyro. :)
    Предлагаю поднятый вами вопрос вынести в другую ветку.
    Поделиться:

    Цитировать

    27.05.2011 в 16:04 # 5280
    Аватар (Igor Tkachenko)
    Igor Tkachenko
    Подписчик
    Зачем что-то решать если нет проблемы?
    Поделиться:

    Цитировать

    27.05.2011 в 16:46 # 5281
    Аватар (AndrewK)
    Андрей Курьян
    Участник

    AndrewK, это все-таки уже оффтоп, давайте вернемся к обсуждению алгоритма, предложенного Phyro. :)
    Предлагаю поднятый вами вопрос вынести в другую ветку.

    Вам не угодишь! Сначала Вы хотите знать, как отсечь тупиковые пути поиска решений, а потом говорите — ф топку. Как прикажете Вас понимать?

    Поделиться:

    Цитировать

    27.05.2011 в 22:26 # 5282
    Аватар (Belle Morte)
    Belle Morte
    Участник

    [quote="Belle Morte"]AndrewK, это все-таки уже оффтоп, давайте вернемся к обсуждению алгоритма, предложенного Phyro. :)
    Предлагаю поднятый вами вопрос вынести в другую ветку.

    Вам не угодишь! Сначала Вы хотите знать, как отсечь тупиковые пути поиска решений, а потом говорите — ф топку. Как прикажете Вас понимать?[/quote]
    Я о том, что обсуждение проблемы "серой зоны" между аналитиком и программистом выходит за рамки обсуждения алгоритма и представляет собой, на мой взгляд, довольно объемный вопрос, который стоит обсуждать отдельно.

    Поделиться:

    Цитировать

    28.05.2011 в 11:46 # 5283
    Аватар (AndrewK)
    Андрей Курьян
    Участник

    [quote="AndrewK"][quote="Belle Morte"]AndrewK, это все-таки уже оффтоп, давайте вернемся к обсуждению алгоритма, предложенного Phyro. :)
    Предлагаю поднятый вами вопрос вынести в другую ветку.

    Вам не угодишь! Сначала Вы хотите знать, как отсечь тупиковые пути поиска решений, а потом говорите — ф топку. Как прикажете Вас понимать?[/quote]
    Я о том, что обсуждение проблемы "серой зоны" между аналитиком и программистом выходит за рамки обсуждения алгоритма и представляет собой, на мой взгляд, довольно объемный вопрос, который стоит обсуждать отдельно.[/quote]

    Думаю, что алгоритм аналитика должен включать не только решение проблем, которые возникают до программирования, но и проблемы, которые появляются после программирования. Стоит в алгоритм добавить шаги:
    Y) Передать решения программисту
    Y+1) Реализовать решения (программист)
    Y+2) Получить реализацию решений
    Y+3) Проверить наличие новых проблем, если нет, то закончить, если да, то перейти к обработке проблем

    ИМХО, серая зона между программистом и аналитиком становится частью (заботой) алгоритма аналитика.

    Поделиться:

    Цитировать

    28.05.2011 в 12:11 # 5284
    Аватар (Igor Tkachenko)
    Igor Tkachenko
    Подписчик
    А в любом ли айтишном проекте нужен программист?
    В любом ли проекте где нужен аналитик нужен программист?
    Поделиться:

    Цитировать

    28.05.2011 в 12:38 # 5285
    Аватар (AndrewK)
    Андрей Курьян
    Участник

    А в любом ли айтишном проекте нужен программист?
    В любом ли проекте где нужен аналитик нужен программист?

    По умолчанию мы обсуждаем проекты, результатами которых является программный продукт, который содержит написанный код.
    Написание кода — это работа программиста.

    Поделиться:

    Цитировать

    30.05.2011 в 09:18 # 5286
    Аватар (Denis Syropushchinsky)
    Denis Syropushchinsky
    Подписчик
    Коллеги, вы бы полезную выжимку делали в первом посте. а то следить за вашим полетом мыслей — такие мертвые петли делаете….
    Поделиться:

    Цитировать

    30.05.2011 в 14:28 # 5287
    Аватар (Igor Tkachenko)
    Igor Tkachenko
    Подписчик
    Пока кроме условий и пояснений добавлять особо нечего. Они спорят относительно того чего туда добавить — мне кажется. Я думаю пока вывода и консенсуса нет — выжимку тоже делать бессмысленно.

    Если Andrey и Belle представят свои варианты алгоритма целиком просто отдельными постами в рамках дальнейшей дискуссии — я думаю это выполнит функцию отправной точки дальнейшей дискуссии для них самих и других участников (которые хотели бы присоединиться).

    P.S> Да и у меня есть ряд вопросов относительно их дополнений, которые я попросту не задаю, чтобы не усугубить ситуацию. Потому что надо сначала с алгоритмом в целом разобраться, а потом влазить в отдельные дополнения и изменения.

    Поделиться:

    Цитировать

Показано 15 ответов - от 46 до 60 (всего 68)

Вы должны авторизироваться для ответа в этой теме.