В теме 67 ответов, и 7 участников, последнее обновление сделано пользователем 
Андрей Курьян 12 г, 10 мес. назад.
-
Сообщения
-
Если Andrey и Belle представят свои варианты алгоритма целиком просто отдельными постами в рамках дальнейшей дискуссии — я думаю это выполнит функцию отправной точки дальнейшей дискуссии для них самих и других участников (которые хотели бы присоединиться).
Вот что у меня получилось:
1. Собрать требования
2. Собрать решения
3. Обнаружить и решить проблемы
4. Оценить решения. При необходимости, повторить.А вот что у меня:
Сама постановка задачи вызывает массу вопросов:
1) Автор исходит из ложных предпосылок:
- в процессе работы над требованиями все аналитики неизбежно тратят время на анализ тупиковых и слабо нужных вещей
- работа аналитика нудна
2) Как поднять продуктивность аналитика до максимума, избежав анализа тупиковых и слабо нужных вещей: абсурдность этого утверждения была доказана Hawkeye. Как мы уже выяснили, непосредственно количество задач не влияет на продуктивность, т.к. продуктивность есть результат делить на время, т.е. по сути скорость работы.
3) Что есть "тупиковая" ветвь анализа? Так и не удалось увидеть от автора вразумительных критериев определения ветви анализа как "тупиковой" с примерами из жизни.
4) Если допустить, что так называемые тупиковые ветви анализа существуют и влияют на продуктивность, возможно ли вообще полностью их отсечь с самого начала, когда у аналитика очень мало информации о каждой из этих ветвей? Я склоняюсь к варианту "нет", минимальный анализ произвести все же придется (хотя бы для идентификации этих самых ветвей).Далее, собственно алгоритм:
1) В алгоритме, предложенным уважаемым Phyro, предпринята попытка собрать все шаги анализа от начала проекта и до его конца, в то время как первоначальная постановка задачи относилась только к моменту разрешения проблем. В связи с этим акцент смещается и в общем-то эту самую задачу-то алгоритм и не решает. Так как никаких гарантий того, что анализа тупиковых ветвей не будет, он не дает. Можно возразить мне, что такие гарантии дает ТРИЗ. Но тогда возникает вопрос: зачем сочинять алгоритм, если эту проблему уже решает ТРИЗ?
2) В алгоритме намешаны в кучу общие рекомендации и частные методологии. И дело тут не в примечаниях "например ТРИЗ", а в самом подходе, предусматривающем трансформацию проблем в противоречия, и манипулировании в дальнейшем этим понятием, пришедшим из ТРИЗ.
3) Не стоит множить сущности без надобности. Были требования, стали проблемы, потом — противоречия, однако я так и не увидела аргументов в пользу такого подхода. Не всякое требование есть проблема. Равно как и не всякая проблема может и должна быть представлена в виде противоречия.
4) Мне в целом не импонирует идея алгоритмизации творческой деятельности: и тут я говорю именно об этом моменте принятия решений, а не о сборе требований или их документировании. Иными словами, если даже забыть обо всех допущениях, принятых при постановке задачи, алгоритмизировать эту деятельность мне не представляется возможным и целесообразным.А вот что у меня:
Сама постановка задачи вызывает массу вопросов:
1) Автор исходит из ложных предпосылок:
- в процессе работы над требованиями все аналитики неизбежно тратят время на анализ тупиковых и слабо нужных вещей
- работа аналитика нудна
2) [i]Как поднять [b]продуктивность[/b] аналитика до максимума, избежав анализа тупиковых и слабо нужных вещей[/i]: абсурдность этого утверждения была доказана Hawkeye. Как мы уже выяснили, непосредственно количество задач не влияет на продуктивность, т.к. продуктивность есть результат делить на время, т.е. по сути [b]скорость[/b] работы.
3) Что есть "тупиковая" ветвь анализа? Так и не удалось увидеть от автора вразумительных критериев определения ветви анализа как "тупиковой" с примерами из жизни.
4) Если допустить, что так называемые тупиковые ветви анализа существуют и влияют на продуктивность, возможно ли вообще полностью их отсечь с самого начала, когда у аналитика очень мало информации о каждой из этих ветвей? Я склоняюсь к варианту "нет", минимальный анализ произвести все же придется (хотя бы для идентификации этих самых ветвей).Уважаемая Belle Morte,
давайте упростим ситуацию и рассмотрим аналитика в 2-х ситуациях: (1) аналитик должен "махать метлой"; (2) аналитик должен "подметать улицу".В чем цель работы аналитика? Очевидно, сделать улицу чистой.
Как он это должен делать? Чтобы "подмести улицу", аналитик должен "махать метлой".
Чем определяется его продуктивность: количеством "махов"? Длиной подметенной улицы за один "мах"?
За что аналитику платят деньги: за "махание" или за "подметание"?А может грязь с улицы лучше смывать, а не подметать?
Далее, собственно алгоритм:
1) В алгоритме, предложенным уважаемым Phyro, предпринята попытка собрать все шаги анализа от начала проекта и до его конца, в то время как первоначальная постановка задачи относилась только [b]к моменту разрешения проблем[/b]. В связи с этим акцент смещается и в общем-то эту самую задачу-то алгоритм и не решает. Так как никаких гарантий того, что анализа тупиковых ветвей не будет, он не дает. Можно возразить мне, что такие гарантии дает ТРИЗ. Но тогда возникает вопрос: зачем сочинять алгоритм, если эту проблему уже решает ТРИЗ?
2) В алгоритме намешаны в кучу общие рекомендации и частные методологии. И дело тут не в примечаниях "например ТРИЗ", а в самом подходе, предусматривающем трансформацию проблем в противоречия, и манипулировании в дальнейшем этим понятием, пришедшим из ТРИЗ.
3) Не стоит множить сущности без надобности. Были требования, стали проблемы, потом — противоречия, однако я так и не увидела аргументов в пользу такого подхода. Не всякое требование есть проблема. Равно как и не всякая проблема может и должна быть представлена в виде противоречия.
4) Мне в целом не импонирует идея алгоритмизации творческой деятельности: и тут я говорю именно об этом моменте принятия решений, а не о сборе требований или их документировании. Иными словами, если даже забыть обо всех допущениях, принятых при постановке задачи, алгоритмизировать эту деятельность мне не представляется возможным и целесообразным.Каждый имеет право на свое мнение… Приведу еще парочку мнений известных в истории персон:
"Фонограф… не представляет никакой коммерческой ценности" — сказал Томас Эдиссон в 1880 г. (Фонограф — это проигрыватель пластинок)
"Полеты на аппаратах тяжелее воздуха невозможны" — астроном Саймон Ньюком в одной из статей 1902 г.
"Бессмысленно мечтать, что … автомобили вытеснят железные дороги в перевозке пассажиров на дальние расстояния" — "Американский дорожный экспресс", 1913 г.
"Нет никакого смысла каждому обзаводиться собственным компьютером" — Кен Олсен, президент DEC, 1977 г. (Если не знакомы с историей фирмы DEC, то почитайте, очень рекомендую.)Belle MorteСпасибо, очень хороший промежуточный итог.
AndrewK
Давайте не будем плодить бессмыссленные посты с попытками "обобщить". Тем более когда берётся физический труд и переносится на интеллектуальный.Также есть одна хорошая практика в работе аналитика — помимо вопросов сразу давать своё видение и мнение. Вот поясните, чего вы хотите достичь примером про подметание/махание? Чтобы это не было очередным витком отгадываний.
Вообще-то система можем менять значение своих параметров при смене точки зрения.Я предлагаю Andrew окончить спор, дабы не тратить время. Осмелюсь предположить, что мы с ним с большего друг друга поняли, хотя и врядли сошлись во мнениях больше чем по 50% пунктов. Остальные остались при своей точке зрения и вполне имеют на это право.
Для меня, целью данного поста было: поделиться результатами наблюдений, сделанными на основе бесед и получить отзывы о моих выводах. Я их получил, развернутые и обоснованные. Не вижу смысла их оспаривать, но, пожалуй за исключением пары корректировок, предложенных Andrew останусь при своем мнении.
[b]AndrewK[/b]
Давайте не будем плодить бессмыссленные посты с попытками "обобщить". Тем более когда берётся физический труд и переносится на интеллектуальный.Также есть одна хорошая практика в работе аналитика — помимо вопросов сразу давать своё видение и мнение. Вот поясните, чего вы хотите достичь примером про подметание/махание? Чтобы это не было очередным витком отгадываний.
1) По ходу дискуссии у меня сложилось впечатление, что у разных участников разные представления о том, кто такой аналитик и что он должен делать. Если мы хотим получить какую-то пользу от этой дискуссии, то начать стоит с определения целей аналитика в проекте.
ИМХО, аналитик должен производить выбор решений, которые будут реализованы в проекте, и отвечать за точность их реализации. Наиболее полно аналитику соответствует роль product owner.2) Исходя из (1) можно определить объекты, с которыми имеет дело аналитик, — это (а) требования, (б) решения; соответственно, работа в аналитика сводится к 2 процессам: (i) управление требованиями; (ii) управление решениями;
3) Про управление требованиями написано много всякого бла-бла-бла; напомню лишь, что аналитик должен работать как с бизнес требованиями, так и с системными требованиям;
В управлении решениями можно выделить следующие стадии цикла:
- отбор решений и их детализация до уровня, понятного программистам;
- проверка соответствия результатов выбранным решениям;4) по ходу работы с решениями аналитик будет сталкиваться с проблемами; следовательно, он должен уметь их выявлять и решать. ИМХО, проблемы в проекте — это нормально; ненормально, когда проблем в проекте нет. Отсутствие проблем — это либо неадекватный заказчик, либо неадекватный аналитик. Есть еще один вариант — типовой проект, в котором и требования и решения уже известны и уже (может быть, не один раз) реализовывались. Но в таком проекте не нужен аналитик.
5) Для того, чтобы правильно управлять проектами, нужно понимать, какова продуктивность работы аналитика. Другими словами, сколько времени ему потребуется для проекта. Если посмотреть на состав работ, которые делает аналитик в проекте, то легко заметить, что простой оценке поддаются работы с требованиями и с решениями, потому что это рутинные работы. Работы по устранению проблем плохо поддаются оценке, потому что это творческие работы. Другими словами, устранение проблем — это фактор неопределенности любого проекта.
Если мы проанализируем, на что тратит время аналитик, когда занимается устранением проблем, то как раз и придем к предмету спора в нашей дискуссии. ИМХО, многие согласились, что аналитик тратит время на перебор вариантов решения проблем, пока не найдет нужное решение. Проблема с проблемами (каламбур!) не в том, что аналитик тратит время, проблема в том, что никто не знает, сколько надо перебрать вариантов и потратить времени, чтобы найти решение, а потом найденное решение реализовать. Возникают известные вопросы: что делать? и кто виноват? Можно ничего не делать в этой ситуации, потом поездить по ушам заказчику и вставить счет за потраченное на решение проблем время. А можно использовать технологии, которые позволяют сократить перебор вариантов и, тем самым, тратить время рационально. Belle Morte не верит, что такое возможно… даже после того, как я рассказал об одной такой технологии.
P.S. На BABoK не тенет, конечно, но тоже много слов получилось
Похоже тема умирает, лето, думать лень либо некогда….AndrewK
Всё что вы написали до пункта 5, я даже не буду пытаться комментировать. Я либо не согласен, либо не понял ваши мысли или их цель. Тем более что вместо определения понятий вы ввели ещё больше понятий, которые надо определять.В пункте 5 вы почти попали в точку, на мой взгляд, но всё же я немного подкорректирую:
5) Для того, чтобы правильно управлять проектами, нужно понимать, какова продуктивность работы аналитика. Другими словами, сколько времени ему потребуется для проекта. Если посмотреть на состав работ, которые делает аналитик в проекте, то легко заметить, что простой оценке поддаются работы по анализу выявленных требований и их документированию, потому что это рутинные работы (анализ — не совсем, но с условной долей приближения можем принять, что это так). Работы по выявлению требований, выявлению и устранению проблем плохо поддаются оценке, потому что а) это творческие работы б) они очень сильно зависят от знаний, опыта и условий работы аналитика. Другими словами, такие задачи — это фактор неопределенности любого проекта.Вы почему-то всегда упускаете выявление требований/проблем, что является самой сложной и неопределенной задачей. Если мы что-то выявили, то применять техники по устранению можно от простых (тупого добавления рисков к оценкам и уведомления стейкхолдеров) до сложносочиненных.
Если вы не знаете/видите, что где-то заложена проблема, то как бы "продуктивно" вы не работали, ваша продуктивность не приносит проекту ничего хорошего.
Похоже тема умирает, лето, думать лень либо некогда….
[b]AndrewK[/b]
Всё что вы написали до пункта 5, я даже не буду пытаться комментировать. Я либо не согласен, либо не понял ваши мысли или их цель. Тем более что вместо определения понятий вы ввели ещё больше понятий, которые надо определять.Не поняли
В пункте 5 вы почти попали в точку, на мой взгляд, но всё же я немного подкорректирую:
5) Для того, чтобы правильно управлять проектами, нужно понимать, какова продуктивность работы аналитика. Другими словами, сколько времени ему потребуется для проекта. Если посмотреть на состав работ, которые делает аналитик в проекте, то легко заметить, что простой оценке поддаются работы по [b]анализу выявленных требований и их документированию[/b], потому что это рутинные работы (анализ — не совсем, но с условной долей приближения можем принять, что это так). Работы по [b]выявлению требований[/b], [b]выявлению и устранению проблем[/b] плохо поддаются оценке, потому что а) это творческие работы б) [b]они очень сильно зависят от знаний, опыта и условий работы аналитика[/b]. Другими словами, [b]такие задачи[/b] — это фактор неопределенности любого проекта.Я вас умоляю…
В каждом конкретном проекте мы имеем конкретного, а не абстрактного аналитика, с конкретным опытом. Более опытный аналитик будет знать больше готовых решений, чем менее опытный. Но при наличии проблемы (а проблема, это уже из области незнания, а не знания) все аналитики равны, кроме тех, которые знают, что делать с проблемами.Вы почему-то всегда упускаете выявление требований/проблем, что является самой сложной и неопределенной задачей. Если мы что-то выявили, то применять техники по устранению можно от простых (тупого добавления рисков к оценкам и уведомления стейкхолдеров) до сложносочиненных.
Выявление требований — это тривиальная работа аналитика "спрашивай — записывай". Выявление проблем — это совсем другой процесс, который не имеет прямого отношения к требованиям. Если у вас есть решение, которое удовлетворяет всем требованиям, то никаких проблем вообще не возникает. Проблемы возникают, когда вы не знаете приемлемого решения.
Если вы не знаете/видите, что где-то заложена проблема, то как бы "продуктивно" вы не работали, ваша продуктивность не приносит проекту ничего хорошего.
Так я ж о том и талдычу который раз, что аналитик должен знать, как работать с проблемами. Конечно, аналитик, который не знает, как решать проблемы (не путать с задачами), никакой пользы проекту не принесет. Это же… очевидно. И в управленческом аспекте именно неопределенность в решении проблем является ключевым фактором неопределенности проекта.
Для иллюстрации сказанного я сформулирую противоречие, касающееся обсуждаемой темы:
1) для того, чтобы проект был управляемым, он должен включать только те требования, по которым есть приемлемые решения; но такой проект не сможет удовлетворить требованиям заказчика, по которым нет решений, т.е. возникают проблемы
2) Для того, чтобы проект удовлетворил заказчика, он должен включать все требования, в т.ч., те требования, по которым неизвестны решения; но такой проект будет плохо управляемым (большие риски по срыву сроков, бюджетов).Как сделать, что проект удовлетворял заказчика и был управляемым?
Вы должны авторизироваться для ответа в этой теме.
