В теме 23 ответа, и 6 участников, последнее обновление сделано пользователем 
Николай Сергеевич 5 г, 5 мес. назад.
-
Сообщения
-
Однажды разработчики признались мне, что читали бы спецификации внимательнее и с большим рвением, если бы они писались с юмором. Разработчики сказали и забыли, а я послушала их и задумалась: ведь если внести в процесс разработки ПО игровой элемент, то это позволит здорово повысить мотивацию да и в целом сделает весь процесс приятнее. По сути тот же скрам популярен не в последнюю очередь потому, что привносит fun в зачастую рутинный и привычный процесс.
В общем интересно будет узнать мнение коллег по этому вопросу, а именно: нужно ли вносить тот самый fun в работу аналитика, как это сделать и где — "разумные пределы"?Ну… как бы, если аналитов на проекте/в конторе явно не хватает (что вроде бы как часто встречающееся явление), то я бы сказал, что нефиг им еще и над фаном работать. Нужно в корне менять отношение разработчиков к труду аналитика (кинуть их с личной ответственностью на проект без анализа и без ПМа
). Но это отдельный топик, поэтому тут разглагольствовать не буду.
Варианты привлечение интереса (из того, чем периодически мы страдаем):
- Больше визуальной составляющей в документах (диаграммы, схемы, причем красивенькие такие… со стразиками
)
- Для примеров в спеках (данные пользователей на мокапах, допустим) можно брать что-нибудь повеселее, например, героев популярных сериалов (что, в принципе, часто делают тестеры, гоняя свои тесткейсы изо дня в день).
- Можно иногда комментарии веселые в баг/таск трэкинг системах оставлять, иногда и матюгнуться по-английски. Главное здесь на 100% обеспечить изоляцию этих вещей от заказчика либо чрезмерно впечатлительных больших боссов.Интересно послушать другие варианты
.Поддерживаю вот это "- Больше визуальной составляющей в документах (диаграммы, схемы, причем красивенькие такие… со стразиками )" сам стараюсь побольше диаграмм рисовать, когда время позволяет
Также можно добавлять примеры, чтобы описать какие-либо нетривиальные моменты.В UX используется один метод, который не только по-своему веселый, но и полезный — Personas (почитать подробнее о нем можно тут[/url]). С одной стороны, персоны — это визуальная составляющая (так как в них, как правило, используются фотографии людей), с другой — для персон можно и нужно использовать забавные имена. Да и интереснее, на мой взгляд, читать описание не абстрактного Администратора, а Биби Джонсона, бейсболиста 39 лет, влюбленного в SharePoint. Это и веселее, и приближает разработчиков к реальной жизни и реальным пользователям.Есть интересный опыт. В качестве системного аналитика был выбран один из разработчиков с хорошим знанием PD и навыками работы с требованиями. В результате через какое-то время (после нескольких ревью и обсуждений) был представлен довольно детальный иерархизированный список требований, который подробно демонстрировал что будет сделано, причем это было четко завязано на бизнес требования. Все нужное все четкое ничего лишнего.
Дабы ускорить получение результата, этот же разработчик был поставлен девелопить.
Вопрос в студию: угадайте что он сделал?phyro, а можно подсказку?Что больше всего вырубает в работе девлеоперов тех кто готовит требования для реализации (ну спеку например)?
Особенно в случаях когда это сделано хорошо?То, что девелоперы сделали не по спеке?)Угу.Т.е. человек взял бизнес требования. Доанализировал их до функциональных. Их утвердили. Обрезали все лишнее. Убедились что они оптимально решают задачу на бизнес уровне.
Затем девелопер в процессе разработки увидел более простые на его взгляд технические решения (пару штук), которые "слегка" изменили требования.Мораль сей басни:
- Девелоперы очень ленивые люди. Плюс считают что они самые ценные и дефицитные в рабочем процессе. Поэтому они готовы угробить любое решение более высокого уровня для того чтобы выиграть несколько часов своего времени
Говорю авторитетно. Потому что я программист.
- Хорошо сформулировать требования очень тяжело. Еще тяжелее донести их смысл до исполнителей, чтобы они были реализованы.
- Формулировать требования очень тяжелая, нудная и тупая с виду работа. На мой взгляд, чем-то похоже на перетаскивать мешки с навозом из точки а в точку б в тридцатиградусную жару.Фана нет. В девелопменте есть фан. Там все ковбои которые на скоку сшибают шашкой капусту. А в анализе фана нет. И нет фана в том чтобы работать над тем что вышло из анализа.
Знаю одно. Настоящий фан — это когда в командной игре получается результат, который работает как часы. А клиент говорит: парни все были в восторге от вашей работы. И каждый может сказать — это сделал я. И каждый знает, что рядом с ним стоит тот кто помог ему это сделать, и что без этой помощи этого результата бы не было.
Может мы не там ищем фан? Где-то.
Есть предложение: Давайте искать фан.
Меня эта тема заинтересовала.
На мой взгляд, чем-то похоже на перетаскивать мешки с навозом из точки а в точку б в тридцатиградусную жару.
Не буду рассуждать на тему, применительно ли сие к работе аналитика, но выражение — огонь!
Фана нет. В девелопменте есть фан. Там все ковбои которые на скоку сшибают шашкой капусту. А в анализе фана нет. И нет фана в том чтобы работать над тем что вышло из анализа.
Знаю одно. Настоящий фан — это когда в командной игре получается результат, который работает как часы. А клиент говорит: парни все были в восторге от вашей работы. И каждый может сказать — это сделал я. И каждый знает, что рядом с ним стоит тот кто помог ему это сделать, и что без этой помощи этого результата бы не было.
Может мы не там ищем фан? Где-то.
Есть предложение: Давайте искать фан.
Меня эта тема заинтересовала.Иногда я, конечно, дистанцирую себя от разработчиков, но чаще всего отождествляю себя, как аналитика, с т.н. командой разработки. И фан, получаемый, от совместно выполненной качественно и в срок работы, я разделяю с командой. Фан тогда может заключаться, например, в том, чтобы впихнуть безобидное пасхальное яйцо в прогу. Просто то, что описано выше — это не фан, это удовлетворение и удовольствие. А фан — это всё-таки веселье, потеха, забава.
Если говорить про фан в работе аналитика, то я соглашусь с тем, что его частенько можно достигать, когда речь заходит про визуализацию.. там можно дорисовывать / пририсовывать и т.д. к серьёзным диаграммам всякие смешные вещи. Например, зная, кто является определённым актёром в юз-кейс диаграмме, можно рисовать юз-кейс диаграмму в виде карикатуры (если позволяют художественные способности).
А вообще надо будет ещё подумать, где я обычно фан нахожу.По моему смысл термина фан — это удовольствие получаемое от действия. И если непосредственно действие удовольствия не приносит и приходится чего-то додумывать. Может косяк в самом действии? Или я не правильно понимаю термин. Но я не вижу смысла в прикольности работы если работа бессмысленная.
В человека природой заложены инстикты чему-то учиться применять это на практике и получать от этого удовольствие потому что оно работает и приносит ему пользу. Если удовольствия нет, значит либо не получается, либо результата нет (что может быть одно и то же).Но я не вижу смысла в прикольности работы если работа бессмысленная.
Вспомните Тома Сойера и историю про забор
работа по содержанию осталась такой же бессмысленной, как и была с самого начала. Но то, как эта работа преподносилась Томом, полностью изменила отношение к ней других: появился и fun, и даже определенный престиж.
Я это к чему… в любой деятельности, естественно, есть неинтересные, будничные элементы, от которых никуда не деться. Вопрос в том, как обогатить эту деятельность, как добавить туда игровых элементов без потери качества на выходе.Часть требований документировано не будет (пропустят или забудут или просто решат что не так важно), часть требований программист "обойдет", часть требований заказчик скажет что он не это имел ввиду или что-нибудь в таком роде, часть требований окажутся "выдуманными" аналитиком чтобы составить целостную картину (на его взгляд) и только какую-то часть требований реализуют как надо, и только какая-то часть требований будет реально волновать потребителя.Смотрю на этим множества и вижу между ними зависимости. Может быть фана будет больше если просто сосредоточиться на действительно важном?
Начнем с того, что ко всем требованиям предъявляются определенные… требования. Это всем хорошо знакомые полнота, ясность, корректность, согласованность, верифицируемость, необходимость, полезность при эксплуатации, осуществимость, модифицируемость, трассируемость, упорядоченность по важности и стабильности, наличие количественной метрики. Задача аналитика в том, чтобы соблюсти все эти требования. Иначе возникают вами описанные ситуации: часть требований пропущена, часть требований двусмысленна, часть требований не соответствует реальности.
Разумеется, даже у самого опытного и умелого аналитика бывают те же самые проблемы. Однако на то он и опытный и умелый, чтобы уметь эти проблемы решать. Нельзя же сказать "долой спецификации, все равно половина требований там не описана, а вторая — не соответствует реальности".
Касательно тезиса о том, что программисты обходят часть требований: для этого есть QA, которые отвечают за качество продукта и контролируют, что разработчики ничего не обошли.
И, наконец, к слову о проблеме того, что реально волнует потребителя: для этого есть маркетинговые исследования, изучение потребителей, составление профилей пользователей, опросы, анкетирования, юзабилити-тестирование и т.д., и т.п., чтобы на самом раннем этапе понять, что входит в эти требования, а что — нет.Если все звенья в этой цепи работают качественно, вопрос о сосредоточении на действительно важном ставить некорректно, он уместен тогда, когда какая-то часть "выпадает" и образуется проблема с анализом, с разработкой или тестированием. И вопрос о внесении fun-а в процесс, по-моему, уместен, если сам процесс стабильный и без дыр. Иначе сначала надо разбираться с существующими проблемами.
Вы должны авторизироваться для ответа в этой теме.
