В теме 22 ответа, и 7 участников, последнее обновление сделано пользователем 
Стас С 13 г, 9 мес. назад.
-
Сообщения
-
Разновидностью является "Тестеры не читают мои документы", "Заказчики не читают мои документы" и апогей — "Никто не читает моих документов
"
Иногда это заблуждение, а иногда — суровая реальность.
Предположим второе.Замечали ли вы такое? Что вы делали / сделали, чтобы исправить ситуацию? Расскажите о своем успешном опыте или неудачах…
Вспомнилась одна книжка, которая мне недавно попалась на глаза: http://oz.by/books/more1016852.html?id_search=4363080.
Думаю, почитать стоит всем аналитикам, а уж тем более координаторам/ ПМ.Что касается моего опыта… Да, к сожалению, это суровая реальность. И страдают этим многие. Исправить ситуацию помогает отрицательный пример. Когда человек делает что-то не по спеке, а потом оказывается что все, что он сотворил, в общем-то напрасная потеря времени и приходится все переделывать еще раз — это помогает. Заранее предупредить такие ситуации проблематично, мне кажется, многое тут зависит от практик, принятых и соблюдаемых в коллективе: к примеру, если каждому новичку объясняют сразу же, что документы читать надо, без этого никак, проблемы чаще всего не возникает вообще.
А я, со своей стороны, стараюсь донести до человека мысль, что спеки они хоть длинные и неинтересные, но ведут в конечном итоге к минимизации его же затрат. И стараюсь подчеркнуть, что я тоже человек, могу ошибаться, и если он видит, что в каком-то месте можно предложить решение лучше, чем это сделала я, надо обязательно об этом сказать. Такая позиция больше подстегивает к сотрудничеству, нежели "дали спеку — сиди и пиши по ней", в задание добавляется элемент творчества.
Да, что касается тестеров — нареканий никаких не было, вот кто-кто внимательно читает мои документы — так это они
Вот буквально вчера читала этот топик и согласилась с мнением о том, что пока не придется разработчику переделать половину своей работы по причине игнора спеки, он не осознает всю ее необходимость. И собственно сегодня столкнулась с такой ситуацией на текущем проекте. А что касается тестеров, это да, они часто к требованиям более внимательны, чем девелоперы.Я сейчас на одном из проектов столкнулась с тем, что не то чтобы не читают, а не хотят искать где написано. Т.е. проще дернуть аналитика и спросить где какое правило написано, чем поискать самому.
Особенно этим страдают молодые тестеровщики и разработчики с не очень высокой квалификацией.
Решила лечить это сведением всей коммуникации в почту (чтобы думали пока пишут вопрос) и игнорированием откровенно не умных вопросов.Я сейчас на одном из проектов столкнулась с тем, что не то чтобы не читают, а не хотят искать где написано. Т.е. проще дернуть аналитика и спросить где какое правило написано, чем поискать самому.
Особенно этим страдают молодые тестеровщики и разработчики с не очень высокой квалификацией.
Решила лечить это сведением всей коммуникации в почту (чтобы думали пока пишут вопрос) и игнорированием откровенно не умных вопросов.А что если попробовать проверить ещё вот такое предположение: раз им (разработчикам и тестерам) проще дернуть аналитика и спросить, где и какое правило написано, то, может, дело в том, что требования плохо организованы и структурированы?
Может же быть такая ситуация, что им действительно сложно находить нужную информацию? Например, один большой непонятный документ, или куча маленьких разрозненных, с отсутствием четкого оглавления и связей между ними.
Или вот еще такое: может быть, они просто не знают, как именно можно быстро и эффективно искать информацию? Ну, скажем, не умеют пользоваться поиском в ворде, или ходить по гиперссылкам вперёд и назад и т.д.В любом случае, я бы попробовал в такой ситуации поговорить с пользователями документа (разработчики и тестеры). Для начала рассказал бы, как у меня всё организовано, где и что лежит, и как легко можно найти нужную информацию. А потом спросил бы, какие есть вопросы или проблемы.. если они еще останутся, то, опять же, выяснить причины и помочь их устранить.
…пока не придется разработчику переделать половину своей работы по причине игнора спеки, он не осознает всю ее необходимость…
Вот бы ещё платили бы за такие ошибки сами ошибающиеся (овертаймами, работой на выходных, ещё как-нибудь), а не компания, и, уж тем более, не другие члены команды.
Как раз в моем случае был организован общий доступ к требованиям, да и требования не хранились в разных документах, а был создан СРС и прототип, разработчики были уведомлены о том, где можно смотреть требования. Один из них делал по спеке, другой этот момент упустил, и пользовался артефактами от заказчика.Юра, это первое о чем я подумала. Но требования хранятся в RSM системе, отдельно описан документ по структуре требований и тому, где что находиться =). И проблема наблюдается только у молодых и/или невнимательных людей.
Так же были встречи, на которых я поясняла как и где искать. Но, либо они не запомнили, либо…
Это наверное не специфическая болезнь. Просто есть люди которые не любят гуглить, а любят спрашивать.И вот кстати большая у разработчиков с трассировками наблюдается в RSM системах. Типа "а почему я должен ходить по трейсам — дайте мне одно большое требование, в котором все описано". Я даже, если честно не знаю, как им объяснить необходимость трассировок. В принципе польза трассировок, только для управления изменениями, т.е. для меня. Вот думаю где найти золотую середину.
Согласен с принимаемыми мерами — в откровенный игнор таких разработчиков. Да и вообще — настаивать и еще раз настаивать на чтении документации. Если у каждого разработчика появится понимание проекта хотя бы с точки зрения кому это нужно и о чем идет речь (к примеру обзорные разделы спецификаций), то это уже большой плюс к успеху проекта. А то ведь некоторые абсолютно не в курсе даже что они делают.Как раз в моем случае был организован общий доступ к требованиям, да и требования не хранились в разных документах, а был создан СРС и прототип, разработчики были уведомлены о том, где можно смотреть требования. Один из них делал по спеке, другой этот момент упустил, и пользовался артефактами от заказчика.
Попробую предположить, что до разработчика не была доведена важность работы по требованиям. У нас на проектах эта проблема уже практически неактуальна ибо не раз уже виновные были общественно обруганы и всем по двадцать раз уже объяснено, что креатив такого плана не есть гуд
. Но требования хранятся в RSM системе, отдельно описан документ по структуре требований и тому, где что находиться =). И проблема наблюдается только у молодых и/или невнимательных людей.
А удобно ли это для разработчиков, если попытаться абстрагироваться от факта удобства для самого себя? Я не настаиваю, а просто спрашиваю, потому что опыта работы с RSM системами у меня нету (и даже особо не представляю что это такое)
.Сорри, в букавках запуталась =) RMS — Requirements Management Systems.
Под документом со структурой я имею ввиду что-то типа устава проекта, в котором прописано, где в каком разделе какой вид требований искать, соглашения по структуризации требований, именованию и проч. Он не большой, но ИМХО понятный (писала не я =))
С точки зрения удобства RMS . Для аналита они безусловно удобны, например, у меня нахождение нужного требования/информации, даже по старому проекту займет от 2 до 10 минут .
Нарекания разработчиков слышала только о трассировках (ну и общей юзабильности системы, но это зависит от выбора системы). Потому что на крупных проектах трейсы растут как кролики и ими сложно управлять, не то что читать. Но тут опять же могут спасти грамотные соглашения по структуризации и трассированию требований.Меня кстати поражают разработчики, которые могут работать на проекта более года и не знать что, зачем и почему. Но это уже оффтоп.
RMS уже более знакомо. А то я минут десять гуглил RSM и чего только не находил .
А если попробовать генерить friendly спеки из RMS? Насколько я знаю, большинство инструментов такого рода это поддерживают.Для аналита они безусловно удобны, например, у меня нахождение нужного требования/информации, даже по старому проекту займет от 2 до 10 минут .
Ну то, что для аналита это понятно, это ясно. Небось сами и предложили, и внедрили данный подход?
Меня кстати поражают разработчики, которые могут работать на проекта более года и не знать что, зачем и почему. Но это уже оффтоп.
Меня тоже. Абсолютно убивают. Мы кстати, когда тренируем новых аналитиков, одним из наиболее важных навыков пытаемся привить постоянное стремление познать большее. К примеру встречаешь ты слово "deployment" где-нибудь в письме, в котором ты в копии. Вроде бы и не обязательно, а все же посмотри, спроси, узнай.. А бывают и аналитики, которые оперируют понятиями, им абсолютно незнакомыми — и даже спеки пишут на вещи, в которых абсолютно полный ноль. Про девелоперов я уже не говорю…
Ну то, что для аналита это понятно, это ясно. Небось сами и предложили, и внедрили данный подход?
Аха
Я уже отписалась в другой теме. Мы использовали Caliber RM, так вот он с большим трудом генерит читабельные спеки. Нужно писать скрипты и все равно они получаются излишне структурированными (на каждый нод в дереве — заголовок в спеке).
Да, любознательность — это ИМХО ключевое качество аналитика. Всего знать нельзя, но нужно хотеть узнать. Иначе как можно браться с энтузиазмом за новый не знакомый домен.
Я вот, как разработчик, могу сказать, что сам редко спеки читаю спеки от корки до корки… И пока с этим никаких проблем не было. В большинстве, когда мне приходит спека, я уже и так из устных разговоров знаю, что там надо сделать. Потом уже походу реализации, если возникают вопросы могу подсмотреть детали, конечно. А вообще ведь ничего не заменит по эффективности живого общения, мне куда приятнее чтобы мне все рассказали, чтобы я походу мог задавать уточняющие вопросы, тем самым активно учавствуя в процессе понимания и по реакции собеседника сразу же видеть правильно ли я все воспринимаю. Общаются ведь аналиты с заказчиком, почему бы им не уделить время на разговоры и с нами? Ведь от этого зависит то как будет реализована их задумка.Полностью поддерживаю Стаса по поводу живого общения между аналитиками и девелоперами! Такое общение бывает полезным еще и с другой позиции: девелоперы часто озвучивают советы и пожелания, которые могут оказаться полезными (особенно если речь идет о разработке нового функционала).Кстати, интересно было бы узнать, есть ли какие-то разделы спецификации, которые разработчики не читают практически никогда? И, наоборот, разделы, на которые обращают самое большое внимание?
Вы должны авторизироваться для ответа в этой теме.
