Silver bullet или fun в анализе




В теме 25 ответов, и 5 участников, последнее обновление сделано пользователем Аватар (Belle Morte) Belle Morte 12 г, 11 мес. назад.

Показано 15 ответов - от 1 до 15 (всего 25)
  • Автор
    Сообщения
  • 25.04.2011 в 16:18 # 5186
    Аватар (Igor Tkachenko)
    Igor Tkachenko
    Подписчик
    Выношу вопрос из курилки (на тему фана в анализе).

    Делать анализ требований нудно.
    Пользоваться результатами анализа скучно.
    Материал предоставленный в результате анализа либо уделяет внимание не тому, либо не верный, либо не воспринимается.

    Какие проблемы приводят к этим симптомам? (кроме квалификации аналитиков).

    Поделиться:

    Цитировать

    25.04.2011 в 16:42 # 5187

    Выношу вопрос из курилки (на тему фана в анализе).

    Делать анализ требований нудно.
    Пользоваться результатами анализа скучно.
    Материал предоставленный в результате анализа либо уделяет внимание не тому, либо не верный, либо не воспринимается.

    Какие проблемы приводят к этим симптомам? (кроме квалификации аналитиков).

    Нудные и скучные аналитики.

    Поделиться:

    Цитировать

    25.04.2011 в 18:27 # 5188
    Нудные и скучные аналитики.

    Таки да. Полностью согласен :)

    Еще:
    1) Делать анализ требований нудно.
    Источники:
    - Отношение к работе (ну вот для меня не нудно…)
    - Методики анализа требований (есть наверняка и нудные подходы, но ведь можно свою работу разнообразить и сделать веселее).
    - Неадекватные заказчики или братья/сестры по анализу

    2) Пользоваться результатами анализа скучно.
    Источники:
    - Отношение к работе :) (привыкать надо…)
    - Методики анализа требований :) (делать веселее и интереснее).
    - Личные issues потребителя результатов анализа, не имеющие отношения к проекту

    3) Материал предоставленный в результате анализа либо уделяет внимание не тому, либо не верный, либо не воспринимается.
    Источники:
    - Вигерса надо читать… а если читали, то еще и применять.

    Просигнальте, когда перейдем от источников к путям решения :)

    Поделиться:

    Цитировать

    25.04.2011 в 18:48 # 5189
    Аватар (Belle Morte)
    Belle Morte
    Участник
    Phyro, просто не могу не спросить: у вас был опыт участия в проектах, которые закончились благополучно? Просто все расписано такими черными красками: нудно, скучно, бесполезно…
    Для меня делать анализ требований нудно, если в целом домен для меня нудный. Во всех остальных случаях сам процесс нравится. Может здесь еще уместен вопрос о том, на своем ли месте находится специалист?
    Что касается использования результатов анализа: не будем рассматривать некачественно подготовленные требования — это отдельный вопрос. Я не вижу причин не использовать и не читать спецификацию. Да, может быть — скучно и сложно, длинный документ, а хочется писать-писать-писать. Но на мой взгляд это, прежде всего, вопрос ответственности. Мне бы и в голову не пришло забить на требования и написать так, как я себе это представляю, без согласования с кем бы то ни было. Потому что этим я бы поставила под удар не только себя, но и в целом команду.
    Поделиться:

    Цитировать

    26.04.2011 в 10:53 # 5190
    Аватар (Igor Tkachenko)
    Igor Tkachenko
    Подписчик
    У меня есть опыт удачных проектов. У меня неудачных то было штуки 2-3, наверное, за весь опыт работы (если не считать личные затеи, на которые я просто забил).
    Просто нет предела совершенству. И эти проекты могли бы быть еще лучше. Они могли бы быть написаны быстрее и полезнее (ну раза в два, я думаю точно), если бы с анализом все было бы в порядке.

    (Кстати очень удачную статью выкинули в эту строну http://analyst.by/imsoftwaredeveloper).

    Надо сделать замечание: я обеими руками за анализ. И считаю большой ошибкой запускать проект без аналитика (если там больше дня активной разработки).

    Но я не могу понять из-за чего беды с анализом )

    После беседы и по прочтению статьи (кстати спасибо — не знаю был ли связан порыв выкинуть ее сюда или нет).
    Могу сделать выводы:

    1) Аналитики генерят ком информации в которой не сделаны акценты на самом важном и это походу отбивает желание работать с их продуктом. (Ответы есть в аджайле, но интересно на сколько они помогают)
    2) Аналитики тоже делают ошибки (даже прочитав Вигерса. как и архитекторы и девелоперы, прочитав Фаулера, Мартина и Гамму). И их ошибки стоят так дорого, что люди предпочитают не пользоваться вообще продуктом анализа, чем получить тоже самое что обычно, плюс потратить время на его переработку. (Может аналитикам тоже нужен какой-то qa? говорить о том что заказчик подписывается под спекой я думаю не уместно.).
    3) Девелоперы думают что они самые умные и иногда игнорируют работу аналитиков (но мне кажется, это следствие из того что написано выше).

    Есть ли дополнения или замечания?

    Поделиться:

    Цитировать

    26.04.2011 в 11:16 # 5191
    Аватар (Denis Syropushchinsky)
    Denis Syropushchinsky
    Подписчик

    1) Аналитики генерят ком информации в которой не сделаны акценты на самом важном и это походу отбивает желание работать с их продуктом. (Ответы есть в аджайле, но интересно на сколько они помогают)
    2) Аналитики тоже делают ошибки (даже прочитав Вигерса. как и архитекторы и девелоперы, прочитав Фаулера, Мартина и Гамму). И их ошибки стоят так дорого, что люди предпочитают не пользоваться вообще продуктом анализа, чем получить тоже самое что обычно, плюс потратить время на его переработку. (Может аналитикам тоже нужен какой-то qa? говорить о том что заказчик подписывается под спекой я думаю не уместно.).
    3) Девелоперы думают что они самые умные и иногда игнорируют работу аналитиков (но мне кажется, это следствие из того что написано выше).

    Есть ли дополнения или замечания?

    Дополнения замечания к чему? Что люди могут плохо выполнять свою работу? или цель — составить свод ошибок в деятельности аналитика?

    По всем пунктам ответы уже давно есть в теории. Но кроме знания теории, нужно уметь применять её на практике, а также воспитывать в себе и команде дисциплину использования "лучших практик".
    1) Для этого выделена отдельная активность "расставление приоритетов". Она же пересекатся с аналогичной активность менеджера проекта. Про "ком информации" даже не буду пояснять — умение структурировать информацию является ключевым в работе любого анлитика (в IT или нет).
    2) Для этого существует валидация требований. Валидаторами могут быть как люди внутри команды, так и вне её (заказчик, внешний консультант).
    3) Понимание процессов и дисциплину в команде надо выстраивать. В том числе вынесение на общее обсуждение вопросов "здесь можно лучше".
    Я бы сказал, что это совместная задача менеджера проекта и аналитика (скорее сеньора).

    Поделиться:

    Цитировать

    26.04.2011 в 14:23 # 5192
    Аватар (Igor Tkachenko)
    Igor Tkachenko
    Подписчик
    Т.е. ни у кого подобных проблем нет в 80%-100% случаев?
    Поделиться:

    Цитировать

    26.04.2011 в 14:33 # 5193

    Т.е. ни у кого подобных проблем нет в 80%-100% случаев?

    Есть и, я думаю, у всех, но я, пожалуй, соглашусь с Денисом в том, что порой ответ достаточно простой: надо просто качественно выполнять свою работу (;

    Поделиться:

    Цитировать

    26.04.2011 в 14:45 # 5194
    Аватар (Belle Morte)
    Belle Morte
    Участник
    Мне, наверное, повезло, т.к. никогда не приходилось работать в команде, негативно настроенной по отношению к аналитикам. Наоборот, у команды был положительный опыт работы с участием аналитика в процессе, поэтому прецедентов "забил на все, что дали аналитики, и сделал по-своему" не было. Да, бывает, что какие-то вещи игнорируются: откровенно говоря, я сомневаюсь, что кто-то из разработчиков читает спецификации от корки до корки. Но все эти вещи потом обнаруживают QA и их все равно делают. Бывает, что какие-то фичи делают не по спеке, если на то есть веские причины, например — технические ограничения. Но в таких случаях меня ставят в курс дела, и эти изменения в итоге ни для кого не сюрприз.
    И ошибки, конечно, у меня бывают. Но ситуаций в духе: "спеку в урну, все неправильно, проще сделать снова" у меня не было.
    Поделиться:

    Цитировать

    26.04.2011 в 16:14 # 5195
    Аватар (Igor Tkachenko)
    Igor Tkachenko
    Подписчик
    Ну, осталось раскрыть смысл слова "качественно", как-то более емко, чем тонна литературы и google.com )

    Belle Morte

    Можно пару вопросов?:
    1. Какого размера проекты?
    2. Является ли аналитик специалистом предметной области и как часто она меняется?
    3. Какая методика ведения проекта используется?
    4. Какие методики работы с требованиями используются?

    Поделиться:

    Цитировать

    26.04.2011 в 16:35 # 5196
    Так как работал с Асей долгое время на одном проекте (долгосрочный, > 2-х лет), могу раскрыть эти вопросы с колокольни того самого проекта:

    1. Огромный и длинный.
    2. Отчасти. Некий наработанный опыт за время участия в проекте есть, но нельзя сказать, что его хватает. Но: у девелоперов знание области гораздо хуже.
    3. Своя. Чем-то было похоже на скрам, но работа с требованиями присутствовала в гораздо больших объемах.
    4. Своя:). Что именно интересно?

    Поделиться:

    Цитировать

    26.04.2011 в 16:43 # 5197
    Аватар (Belle Morte)
    Belle Morte
    Участник
    Спасибо, Герыч, все так и было.
    Помимо проекта, упомянутого Герычем, были и гораздо меньшие по объему проекты из других проблемных областей. Принципиальной разницы нет, разве только все то же самое укладывается в более сжатые сроки.
    Мне кажется на скрам все же очень и очень отдаленно было похоже, большую часть этих 2-х лет к скраму никакого отношения процесс не имел, уже потом стали пытаться вводить некоторые элементы. А так все было довольно традиционно: подготовили требования, отдали QA на вычитку (не всегда, к сожалению, получалось это сделать, но старались), отправили в разработку и т.д.
    Поделиться:

    Цитировать

    26.04.2011 в 17:04 # 5198
    Аватар (Igor Tkachenko)
    Igor Tkachenko
    Подписчик
    Следствие зашло в тупик. )

    Искусство да и только.

    Я понял вашу позицию. Чтобы получить аналитика нужно:
    Вигерс, еще вагон литературы, пару проектов опыта и талант.

    Ладно. Уточним одну вещь, чтобы следствие совсем не зашло в тупик:

    Проверку требований кто совершает?
    - Если другой аналитик ему может быть так же скучно как и деву. И за очередным зевком можно пропустить что-то важное.
    - Устраивать целую презентацию команде может не быть времени.
    - Если пм ему может быть строго пох как и деву (да, да такое бывает).
    - Если клиент ему еще больше может быть пох чем пму (киньте в меня камнем если я не прав).
    - Если проверка требований идет по формальным признакам какой-то методологии другим аналитиком можно за формальным порядком пропустить суть. Особенно если нету фокусировки на чем-то небольшом (то что можно легко и быстро прочитать и осознать) и важном (чтобы этими 20% покрыть 80% проблем).

    Поделиться:

    Цитировать

    27.04.2011 в 11:48 # 5199
    Аватар (Igor Tkachenko)
    Igor Tkachenko
    Подписчик
    О )
    Если не можем определить проблему, начинаем пенять на мотивацию (классический симптом — сори).
    Следствие сдвинулось с мертвой точки. Начинаем думать.

    Запишем так.
    Проблема: не хватает мотивации.

    Я то знаю в чем проблема, кажется, (сори) тока на слишком глубоком уровне — где сложно конкретное решение предложить ) (на том же где мотивация).
    Поэтому не буду ее озвучивать, попробуем найти ее ближе к тем вещам, где можно сказать: надо взять вот этот инструмент потом вот этот и применить их так-то.

    P.S> я знаю примеры простых решений которые работают не хуже мотивации.
    Да и что такое мотивация? Заинтересованность в получении результата приводящая к активности (можно начать спорить относительно формулировки). Она есть всегда, когда человек сознательно делает то что считает полезным. Ведь, все люди хотят приносить пользу себе или кому-нибудь (природа у них такая).

    Грубо говоря, если процесс построить так, что человек будет видеть то как он приносит пользу, совершая его шаги — мотивация появится сама по себе )

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

    Вот мои мысли:
    Некоторые привычные методики анализа требований (их сбора, декомпозиции, формулировки) оказываются не эффективны:
    - Например, потому что, могут поставить точку зрения на систему таким образом что получившийся перечень будет нести мало полезной информации о том каким будет проект относительно его целей, или будет упускать важные детали (например будет не хватать уровня декомпозиции), или деталей слишком много (они будут скрывать за собой смысл требований — чрезмерная декомпозиция), и т.д. и т.п.
    - Созданные список требований понятен разработчикам и совершенно не понятен PM и клиенту, и наоборот. Т.е. точка зрения на систему либо слишком оторвана от реализации, либо слишком техническая.
    - В требованиях заложено слишком много информации которую можно было бы просто стандартизировать и вообще не упоминать (т.к. она не содает реальный value для конечного потребителя, например). Например, описаны способы валидации данных (простите за тупой пример). Как следствие фокс может сместиться с того что важно сделать на то что просто сделать.
    Хороший аналитик (опытный и с 80% хорошим результатами) интуитивно меняется между проектами типа афилейтных систем и информационно расчетных интерфейсов, например (где акценты расставлены по разному на разных типах требований UI, SI и PD).
    Не опытный аналитик скорее будет все проекты анализировать по одинаковой схеме.
    Но в обоих случаях если человек привык уделять внимание всем составляющим а не наиболее критичной для проекта, он получит в 2-3 раза больше требований где хватило бы, например, сосредоточиться только на SI и дать какое-то общее описание UI. В результате если он мастер UI он сделает хорошо именно то что у него получается хорошо, и возможно все вниманием привлечет к этому.
    В результате может получиться и не плохо. Но не идеально, и решение может оказаться не таким ценным как могло бы.

    Какие еще проблемы, или процессы при решении, которых есть какие-то внутренние колебания у вас лично, вы могли бы назвать?

    P.S> SI, UI и PD — это частный пример разделения. Можно взять любую классификацию, любого уровня.

    Поделиться:

    Цитировать

    27.04.2011 в 12:58 # 5200
    Аватар (Belle Morte)
    Belle Morte
    Участник

    О )
    Да и что такое мотивация? Заинтересованность в получении результата приводящая к активности (можно начать спорить относительно формулировки). Она есть всегда, когда человек сознательно делает то что считает полезным. Ведь, все люди хотят приносить пользу себе или кому-нибудь (природа у них такая).

    Грубо говоря, если процесс построить так, что человек будет видеть то как он приносит пользу, совершая его шаги — мотивация появится сама по себе )

    Не соглашусь с вами. Мотивация всегда происходит из какой-то актуальной потребности. У каждого человека эти потребности — свои. На то, какими они будут, влияет множество факторов, от воспитания до экономического контекста. И далеко не все люди хотят приносить пользу. Для кого-то перспектива принести пользу каким-то там людишкам в команде заказчика — это пустой звук. А вот прошариться, например, в разработке под SharePoint — это круто и интересно. Не будем также забывать и о таком банальном способе мотивации как оплата труда. При всей готовности сделать что-то полезное многие не будет выкладываться на полную катушку, зная, что их старания все равно не оцениваются.
    Проблемы с отсутствием мотивации надо решать на индивидуальном уровне. Но решать их нужно обязательно, т.к. такого рода настроения бывают заразительными и передаются и другим работникам. А нет ничего более разрушительного для проекта, чем всеобщее уныние и отсутствие энтузиазма у всех участников.

    Поделиться:

    Цитировать

Показано 15 ответов - от 1 до 15 (всего 25)

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