В теме 25 ответов, и 5 участников, последнее обновление сделано пользователем 
Belle Morte 13 г, 7 мес. назад.
-
Сообщения
-
Выношу вопрос из курилки (на тему фана в анализе).
Делать анализ требований нудно.
Пользоваться результатами анализа скучно.
Материал предоставленный в результате анализа либо уделяет внимание не тому, либо не верный, либо не воспринимается.Какие проблемы приводят к этим симптомам? (кроме квалификации аналитиков).
Выношу вопрос из курилки (на тему фана в анализе).
Делать анализ требований нудно.
Пользоваться результатами анализа скучно.
Материал предоставленный в результате анализа либо уделяет внимание не тому, либо не верный, либо не воспринимается.Какие проблемы приводят к этим симптомам? (кроме квалификации аналитиков).
Нудные и скучные аналитики.
Нудные и скучные аналитики.
Таки да. Полностью согласен
Еще:
1) Делать анализ требований нудно.
Источники:
- Отношение к работе (ну вот для меня не нудно…)
- Методики анализа требований (есть наверняка и нудные подходы, но ведь можно свою работу разнообразить и сделать веселее).
- Неадекватные заказчики или братья/сестры по анализу2) Пользоваться результатами анализа скучно.
Источники:
- Отношение к работе (привыкать надо…)
- Методики анализа требований (делать веселее и интереснее).
- Личные issues потребителя результатов анализа, не имеющие отношения к проекту3) Материал предоставленный в результате анализа либо уделяет внимание не тому, либо не верный, либо не воспринимается.
Источники:
- Вигерса надо читать… а если читали, то еще и применять.Просигнальте, когда перейдем от источников к путям решения
Phyro, просто не могу не спросить: у вас был опыт участия в проектах, которые закончились благополучно? Просто все расписано такими черными красками: нудно, скучно, бесполезно…
Для меня делать анализ требований нудно, если в целом домен для меня нудный. Во всех остальных случаях сам процесс нравится. Может здесь еще уместен вопрос о том, на своем ли месте находится специалист?
Что касается использования результатов анализа: не будем рассматривать некачественно подготовленные требования — это отдельный вопрос. Я не вижу причин не использовать и не читать спецификацию. Да, может быть — скучно и сложно, длинный документ, а хочется писать-писать-писать. Но на мой взгляд это, прежде всего, вопрос ответственности. Мне бы и в голову не пришло забить на требования и написать так, как я себе это представляю, без согласования с кем бы то ни было. Потому что этим я бы поставила под удар не только себя, но и в целом команду.У меня есть опыт удачных проектов. У меня неудачных то было штуки 2-3, наверное, за весь опыт работы (если не считать личные затеи, на которые я просто забил).
Просто нет предела совершенству. И эти проекты могли бы быть еще лучше. Они могли бы быть написаны быстрее и полезнее (ну раза в два, я думаю точно), если бы с анализом все было бы в порядке.(Кстати очень удачную статью выкинули в эту строну http://analyst.by/imsoftwaredeveloper).
Надо сделать замечание: я обеими руками за анализ. И считаю большой ошибкой запускать проект без аналитика (если там больше дня активной разработки).
Но я не могу понять из-за чего беды с анализом )
После беседы и по прочтению статьи (кстати спасибо — не знаю был ли связан порыв выкинуть ее сюда или нет).
Могу сделать выводы:1) Аналитики генерят ком информации в которой не сделаны акценты на самом важном и это походу отбивает желание работать с их продуктом. (Ответы есть в аджайле, но интересно на сколько они помогают)
2) Аналитики тоже делают ошибки (даже прочитав Вигерса. как и архитекторы и девелоперы, прочитав Фаулера, Мартина и Гамму). И их ошибки стоят так дорого, что люди предпочитают не пользоваться вообще продуктом анализа, чем получить тоже самое что обычно, плюс потратить время на его переработку. (Может аналитикам тоже нужен какой-то qa? говорить о том что заказчик подписывается под спекой я думаю не уместно.).
3) Девелоперы думают что они самые умные и иногда игнорируют работу аналитиков (но мне кажется, это следствие из того что написано выше).Есть ли дополнения или замечания?
1) Аналитики генерят ком информации в которой не сделаны акценты на самом важном и это походу отбивает желание работать с их продуктом. (Ответы есть в аджайле, но интересно на сколько они помогают)
2) Аналитики тоже делают ошибки (даже прочитав Вигерса. как и архитекторы и девелоперы, прочитав Фаулера, Мартина и Гамму). И их ошибки стоят так дорого, что люди предпочитают не пользоваться вообще продуктом анализа, чем получить тоже самое что обычно, плюс потратить время на его переработку. (Может аналитикам тоже нужен какой-то qa? говорить о том что заказчик подписывается под спекой я думаю не уместно.).
3) Девелоперы думают что они самые умные и иногда игнорируют работу аналитиков (но мне кажется, это следствие из того что написано выше).Есть ли дополнения или замечания?
Дополнения замечания к чему? Что люди могут плохо выполнять свою работу? или цель — составить свод ошибок в деятельности аналитика?
По всем пунктам ответы уже давно есть в теории. Но кроме знания теории, нужно уметь применять её на практике, а также воспитывать в себе и команде дисциплину использования "лучших практик".
1) Для этого выделена отдельная активность "расставление приоритетов". Она же пересекатся с аналогичной активность менеджера проекта. Про "ком информации" даже не буду пояснять — умение структурировать информацию является ключевым в работе любого анлитика (в IT или нет).
2) Для этого существует валидация требований. Валидаторами могут быть как люди внутри команды, так и вне её (заказчик, внешний консультант).
3) Понимание процессов и дисциплину в команде надо выстраивать. В том числе вынесение на общее обсуждение вопросов "здесь можно лучше".
Я бы сказал, что это совместная задача менеджера проекта и аналитика (скорее сеньора).Т.е. ни у кого подобных проблем нет в 80%-100% случаев?Т.е. ни у кого подобных проблем нет в 80%-100% случаев?
Есть и, я думаю, у всех, но я, пожалуй, соглашусь с Денисом в том, что порой ответ достаточно простой: надо просто качественно выполнять свою работу (;
Мне, наверное, повезло, т.к. никогда не приходилось работать в команде, негативно настроенной по отношению к аналитикам. Наоборот, у команды был положительный опыт работы с участием аналитика в процессе, поэтому прецедентов "забил на все, что дали аналитики, и сделал по-своему" не было. Да, бывает, что какие-то вещи игнорируются: откровенно говоря, я сомневаюсь, что кто-то из разработчиков читает спецификации от корки до корки. Но все эти вещи потом обнаруживают QA и их все равно делают. Бывает, что какие-то фичи делают не по спеке, если на то есть веские причины, например — технические ограничения. Но в таких случаях меня ставят в курс дела, и эти изменения в итоге ни для кого не сюрприз.
И ошибки, конечно, у меня бывают. Но ситуаций в духе: "спеку в урну, все неправильно, проще сделать снова" у меня не было.Ну, осталось раскрыть смысл слова "качественно", как-то более емко, чем тонна литературы и google.com )Belle Morte
Можно пару вопросов?:
1. Какого размера проекты?
2. Является ли аналитик специалистом предметной области и как часто она меняется?
3. Какая методика ведения проекта используется?
4. Какие методики работы с требованиями используются?Так как работал с Асей долгое время на одном проекте (долгосрочный, > 2-х лет), могу раскрыть эти вопросы с колокольни того самого проекта:1. Огромный и длинный.
2. Отчасти. Некий наработанный опыт за время участия в проекте есть, но нельзя сказать, что его хватает. Но: у девелоперов знание области гораздо хуже.
3. Своя. Чем-то было похоже на скрам, но работа с требованиями присутствовала в гораздо больших объемах.
4. Своя:). Что именно интересно?Спасибо, Герыч, все так и было.
Помимо проекта, упомянутого Герычем, были и гораздо меньшие по объему проекты из других проблемных областей. Принципиальной разницы нет, разве только все то же самое укладывается в более сжатые сроки.
Мне кажется на скрам все же очень и очень отдаленно было похоже, большую часть этих 2-х лет к скраму никакого отношения процесс не имел, уже потом стали пытаться вводить некоторые элементы. А так все было довольно традиционно: подготовили требования, отдали QA на вычитку (не всегда, к сожалению, получалось это сделать, но старались), отправили в разработку и т.д.Следствие зашло в тупик. )Искусство да и только.
Я понял вашу позицию. Чтобы получить аналитика нужно:
Вигерс, еще вагон литературы, пару проектов опыта и талант.Ладно. Уточним одну вещь, чтобы следствие совсем не зашло в тупик:
Проверку требований кто совершает?
- Если другой аналитик ему может быть так же скучно как и деву. И за очередным зевком можно пропустить что-то важное.
- Устраивать целую презентацию команде может не быть времени.
- Если пм ему может быть строго пох как и деву (да, да такое бывает).
- Если клиент ему еще больше может быть пох чем пму (киньте в меня камнем если я не прав).
- Если проверка требований идет по формальным признакам какой-то методологии другим аналитиком можно за формальным порядком пропустить суть. Особенно если нету фокусировки на чем-то небольшом (то что можно легко и быстро прочитать и осознать) и важном (чтобы этими 20% покрыть 80% проблем).О )
Если не можем определить проблему, начинаем пенять на мотивацию (классический симптом — сори).
Следствие сдвинулось с мертвой точки. Начинаем думать.Запишем так.
Проблема: не хватает мотивации.Я то знаю в чем проблема, кажется, (сори) тока на слишком глубоком уровне — где сложно конкретное решение предложить ) (на том же где мотивация).
Поэтому не буду ее озвучивать, попробуем найти ее ближе к тем вещам, где можно сказать: надо взять вот этот инструмент потом вот этот и применить их так-то.P.S> я знаю примеры простых решений которые работают не хуже мотивации.
Да и что такое мотивация? Заинтересованность в получении результата приводящая к активности (можно начать спорить относительно формулировки). Она есть всегда, когда человек сознательно делает то что считает полезным. Ведь, все люди хотят приносить пользу себе или кому-нибудь (природа у них такая).Грубо говоря, если процесс построить так, что человек будет видеть то как он приносит пользу, совершая его шаги — мотивация появится сама по себе )
Давайте поищем проблему в процессе.
Вы знаете целую кучу инструментов, приемов и рекомендаций. Какие-то работают лучше какие-то работают хуже. Какие-то работают в одних ситуациях. Какие-то в других. Какая в этом кроется засада?Вот мои мысли:
Некоторые привычные методики анализа требований (их сбора, декомпозиции, формулировки) оказываются не эффективны:
- Например, потому что, могут поставить точку зрения на систему таким образом что получившийся перечень будет нести мало полезной информации о том каким будет проект относительно его целей, или будет упускать важные детали (например будет не хватать уровня декомпозиции), или деталей слишком много (они будут скрывать за собой смысл требований — чрезмерная декомпозиция), и т.д. и т.п.
- Созданные список требований понятен разработчикам и совершенно не понятен PM и клиенту, и наоборот. Т.е. точка зрения на систему либо слишком оторвана от реализации, либо слишком техническая.
- В требованиях заложено слишком много информации которую можно было бы просто стандартизировать и вообще не упоминать (т.к. она не содает реальный value для конечного потребителя, например). Например, описаны способы валидации данных (простите за тупой пример). Как следствие фокс может сместиться с того что важно сделать на то что просто сделать.
Хороший аналитик (опытный и с 80% хорошим результатами) интуитивно меняется между проектами типа афилейтных систем и информационно расчетных интерфейсов, например (где акценты расставлены по разному на разных типах требований UI, SI и PD).
Не опытный аналитик скорее будет все проекты анализировать по одинаковой схеме.
Но в обоих случаях если человек привык уделять внимание всем составляющим а не наиболее критичной для проекта, он получит в 2-3 раза больше требований где хватило бы, например, сосредоточиться только на SI и дать какое-то общее описание UI. В результате если он мастер UI он сделает хорошо именно то что у него получается хорошо, и возможно все вниманием привлечет к этому.
В результате может получиться и не плохо. Но не идеально, и решение может оказаться не таким ценным как могло бы.Какие еще проблемы, или процессы при решении, которых есть какие-то внутренние колебания у вас лично, вы могли бы назвать?
P.S> SI, UI и PD — это частный пример разделения. Можно взять любую классификацию, любого уровня.
О )
Да и что такое мотивация? Заинтересованность в получении результата приводящая к активности (можно начать спорить относительно формулировки). Она есть всегда, когда человек сознательно делает то что считает полезным. Ведь, все люди хотят приносить пользу себе или кому-нибудь (природа у них такая).Грубо говоря, если процесс построить так, что человек будет видеть то как он приносит пользу, совершая его шаги — мотивация появится сама по себе )
Не соглашусь с вами. Мотивация всегда происходит из какой-то актуальной потребности. У каждого человека эти потребности — свои. На то, какими они будут, влияет множество факторов, от воспитания до экономического контекста. И далеко не все люди хотят приносить пользу. Для кого-то перспектива принести пользу каким-то там людишкам в команде заказчика — это пустой звук. А вот прошариться, например, в разработке под SharePoint — это круто и интересно. Не будем также забывать и о таком банальном способе мотивации как оплата труда. При всей готовности сделать что-то полезное многие не будет выкладываться на полную катушку, зная, что их старания все равно не оцениваются.
Проблемы с отсутствием мотивации надо решать на индивидуальном уровне. Но решать их нужно обязательно, т.к. такого рода настроения бывают заразительными и передаются и другим работникам. А нет ничего более разрушительного для проекта, чем всеобщее уныние и отсутствие энтузиазма у всех участников.
Вы должны авторизироваться для ответа в этой теме.
