В теме 67 ответов, и 7 участников, последнее обновление сделано пользователем 
Андрей Курьян 12 г, 10 мес. назад.
-
Сообщения
-
Если есть поставленная задача, то анализ уже не нужен. Если конечно вы не хотите подвергнуть задачу сомнению или если вы все таки берете не отдельные требования.
Вот с этим не соглашусь. Был опыт работы на большом проекте (примерно 50 разработчиков в команде). Аналитики имели представление обо всей системе в целом, разработчики — об отдельных частях, которые сами писали. Все новые задачи от заказчика проходили через аналитиков для того, чтобы определить приоритет, надо ли их реализовывать вообще (проект — большой, бывало и такое, что какая-то фича уже есть, а заказчик забыл), решить вопросы с правами доступа к новому функционалу, обеспечить преемственность и тому подобное.
[quote="Belle Morte"]
Не будем рассматривать целый проект, возьмем конкретное требование: требуется такой-то такой-то скрин для определенной цели (по сути это — уже задача). Следующий шаг по алгоритму — переформулировать требования в [b]проблему[/b]. Вот этот момент меня и смущает: зачем каждую задачу конвертить в проблему, затем — в противоречие и т.д. ?Похоже у нас с вами разные представления на тему того что такое анализ и зачем он нужен.
Если есть поставленная задача, то анализ уже не нужен. Если конечно вы не хотите подвергнуть задачу сомнению или если вы все таки берете не отдельные требования.[/quote]В связи с этим возникает интересный вопрос: должен ли аналитик находить решения и превращать их в задачи?
Дело в том, что если аналитик не работает с решениями, то откуда он узнает, что какие-то решения порождают проблемы?
С другой стороны, если аналитик хорошо знает решения, то зачем тогда нужны программисты?Предлагаю обсудить эту проблему и противоречие, которое имеет место…
[quote="Belle Morte"]Стоп. Вернемся к алгоритму:
1) Определить основную цель проекта.
2) Выделить бизнес требования.
3) Переформулировать требования в виде проблем.
….
Не будем рассматривать целый проект, возьмем конкретное требование: требуется такой-то такой-то скрин для определенной цели (по сути это — уже задача). Следующий шаг по алгоритму — переформулировать требования в [b]проблему[/b]. Вот этот момент меня и смущает: зачем каждую задачу конвертить в проблему, затем — в противоречие и т.д. ?ИМХО, п 3) следует расшифровать:
3.1) Найти решения, удовлетворяющие требованиям
3.2) Проверить, не порождают ли эти решения проблем
3.3) Если проблемы возникли, то зафиксировать проблемы[/quote]Вот это выглядит уже правдоподобно. Только не расшифровать, а заменить пункт 3.
Правда мы опять возвращаемся к вопросу "а как, собственно, найти эти решения без анализа тупиковых ветвей?"
В связи с этим возникает интересный вопрос: должен ли аналитик находить решения и превращать их в задачи?
Дело в том, что если аналитик не работает с решениями, то откуда он узнает, что какие-то решения порождают проблемы?
С другой стороны, если аналитик хорошо знает решения, то зачем тогда нужны программисты?Предлагаю обсудить эту проблему и противоречие, которое имеет место…
Это хороший вопрос. Я думаю, с одной стороны, для этого от аналитика и требуется знание IT, отсюда и проблемы без этого знания найти работу. При этом знание широкое, но не глубокое, если вы понимаете, о чем я: аналитик представляет себе набор возможных решений и проблемы, которые они влекут, но не настолько хорошо, чтобы сесть самому и строчить код.
А когда речь заходит о каких-то фундаментальных решениях, ИМХО принимать их должен аналитик в тандеме с архитектором.[quote="AndrewK"][quote="Belle Morte"]Стоп. Вернемся к алгоритму:
1) Определить основную цель проекта.
2) Выделить бизнес требования.
3) Переформулировать требования в виде проблем.
….
Не будем рассматривать целый проект, возьмем конкретное требование: требуется такой-то такой-то скрин для определенной цели (по сути это — уже задача). Следующий шаг по алгоритму — переформулировать требования в [b]проблему[/b]. Вот этот момент меня и смущает: зачем каждую задачу конвертить в проблему, затем — в противоречие и т.д. ?ИМХО, п 3) следует расшифровать:
3.1) Найти решения, удовлетворяющие требованиям
3.2) Проверить, не порождают ли эти решения проблем
3.3) Если проблемы возникли, то зафиксировать проблемы[/quote]Вот это выглядит уже правдоподобно. Только не расшифровать, а заменить пункт 3.
Правда мы опять возвращаемся к вопросу "а как, собственно, найти эти решения без анализа тупиковых ветвей?"[/quote]Уточнение: выбрать решения, удовлетворяющие требования. Решения — это то, что мы уже знаем. Если решение "тупиковое", то это уже не решение, а проблема. Поэтому нет никакого "анализа тупиковых ветвей" на уровне решения.
[quote="AndrewK"] В связи с этим возникает интересный вопрос: должен ли аналитик находить решения и превращать их в задачи?
Дело в том, что если аналитик не работает с решениями, то откуда он узнает, что какие-то решения порождают проблемы?
С другой стороны, если аналитик хорошо знает решения, то зачем тогда нужны программисты?Предлагаю обсудить эту проблему и противоречие, которое имеет место…
Это хороший вопрос. Я думаю, с одной стороны, для этого от аналитика и требуется знание IT, отсюда и проблемы без этого знания найти работу. При этом знание широкое, но не глубокое, если вы понимаете, о чем я: аналитик представляет себе набор возможных решений и проблемы, которые они влекут, но не настолько хорошо, чтобы сесть самому и строчить код.
А когда речь заходит о каких-то фундаментальных решениях, ИМХО принимать их должен аналитик в тандеме с архитектором.[/quote]Я понимаю :-)
Но при таком подходе возникает серая зона между аналитиком и программистом. Знаний аналитика может не хватить, и проблема проявится уже только у программиста. Знаний программиста может не хватить для распознавания проблемы. тогда проблема проявится уже у заказчика. Что, собственно, недопустимо.Другими словами, мы имеем дело с классическим компромиссом: аналитик знает решения, но не настолько хорошо, чтобы …; программист знает проблемы, но не настолько хорошо, чтобы…
В ТРИЗ в таких ситуациях выполняется операция, которая называется обострение противоречия. Давайте применим эту операцию к нашему случаю. Давайте представим, что аналитик по-любому не может знать решений настолько хорошо, чтобы узнать о возникновении проблемы. Аналогично, программист не может знать специфику требований заказчика, чтобы распознать проблему в решениях. Что будем делать?
AndrewK, это все-таки уже оффтоп, давайте вернемся к обсуждению алгоритма, предложенного Phyro.
Предлагаю поднятый вами вопрос вынести в другую ветку.Зачем что-то решать если нет проблемы?AndrewK, это все-таки уже оффтоп, давайте вернемся к обсуждению алгоритма, предложенного Phyro.
Предлагаю поднятый вами вопрос вынести в другую ветку.Вам не угодишь! Сначала Вы хотите знать, как отсечь тупиковые пути поиска решений, а потом говорите — ф топку. Как прикажете Вас понимать?
[quote="Belle Morte"]AndrewK, это все-таки уже оффтоп, давайте вернемся к обсуждению алгоритма, предложенного Phyro.
Предлагаю поднятый вами вопрос вынести в другую ветку.Вам не угодишь! Сначала Вы хотите знать, как отсечь тупиковые пути поиска решений, а потом говорите — ф топку. Как прикажете Вас понимать?[/quote]
Я о том, что обсуждение проблемы "серой зоны" между аналитиком и программистом выходит за рамки обсуждения алгоритма и представляет собой, на мой взгляд, довольно объемный вопрос, который стоит обсуждать отдельно.[quote="AndrewK"][quote="Belle Morte"]AndrewK, это все-таки уже оффтоп, давайте вернемся к обсуждению алгоритма, предложенного Phyro.
Предлагаю поднятый вами вопрос вынести в другую ветку.Вам не угодишь! Сначала Вы хотите знать, как отсечь тупиковые пути поиска решений, а потом говорите — ф топку. Как прикажете Вас понимать?[/quote]
Я о том, что обсуждение проблемы "серой зоны" между аналитиком и программистом выходит за рамки обсуждения алгоритма и представляет собой, на мой взгляд, довольно объемный вопрос, который стоит обсуждать отдельно.[/quote]Думаю, что алгоритм аналитика должен включать не только решение проблем, которые возникают до программирования, но и проблемы, которые появляются после программирования. Стоит в алгоритм добавить шаги:
Y) Передать решения программисту
Y+1) Реализовать решения (программист)
Y+2) Получить реализацию решений
Y+3) Проверить наличие новых проблем, если нет, то закончить, если да, то перейти к обработке проблемИМХО, серая зона между программистом и аналитиком становится частью (заботой) алгоритма аналитика.
А в любом ли айтишном проекте нужен программист?
В любом ли проекте где нужен аналитик нужен программист?А в любом ли айтишном проекте нужен программист?
В любом ли проекте где нужен аналитик нужен программист?По умолчанию мы обсуждаем проекты, результатами которых является программный продукт, который содержит написанный код.
Написание кода — это работа программиста.Коллеги, вы бы полезную выжимку делали в первом посте. а то следить за вашим полетом мыслей — такие мертвые петли делаете….Пока кроме условий и пояснений добавлять особо нечего. Они спорят относительно того чего туда добавить — мне кажется. Я думаю пока вывода и консенсуса нет — выжимку тоже делать бессмысленно.Если Andrey и Belle представят свои варианты алгоритма целиком просто отдельными постами в рамках дальнейшей дискуссии — я думаю это выполнит функцию отправной точки дальнейшей дискуссии для них самих и других участников (которые хотели бы присоединиться).
P.S> Да и у меня есть ряд вопросов относительно их дополнений, которые я попросту не задаю, чтобы не усугубить ситуацию. Потому что надо сначала с алгоритмом в целом разобраться, а потом влазить в отдельные дополнения и изменения.
Вы должны авторизироваться для ответа в этой теме.
