Pull to refresh

Comments 44

UFO just landed and posted this here
Бумажные описания не очень-то цепляют — в них не видно финиша

Видимо никудышные описания. Мне казалось что смысл описания - именно в том, чтобы очертить границы того, что надо сделать.
Дело не в качестве описаний. Дело в том, что часто (вне зависимости от качества и подробности документации) разработчики обращаются не к ней, а к визуальным документам — дизайну, прототипу, схемам страниц.

Прототип не отменяет текстовые спецификации, он дает еще один взгляд на них. Который для многих гораздо нагляднее и удобнее.
По нашему опыту талмуды с большим количеством текста программистами и менеджерами проекта игнорируются. Доходит до смешного — они начинают задавать вопросы, ответа на которых есть в этих документах.
Картинки с небольшими компактными приложениями много доходчивее.
Во-во :) У нас недавно смешно получилось с use cases — они были описаны давно и очень подробно, с детальными алгоритмами работы страниц. Разработчики постоянно обращались с вопросами и очень удивились, когда вспомнили про них и увидели, что там все давно есть :)
Я, конечно, понимаю, что «Хабр уже не тот» ©, где много букв прокатывает все реже. И да, статья уже была републикована на GUI.ru, но ведь не все читают GUI.ru и тем более мой блог. Но все равно, не очень понятна такая трешовая реакция. Хабру не нужны авторские материалы? За качество не буду говорить, но по-моему мнению и тех, кто статью републиковал — по крайней мере достаточно сносное.
Ну если бы я хотел скандала — писал бы на Лепру :) Хотя реакция в комментариях такая, будто туда и написал :)
Юра, мою статью здесь увели в -19 практически без каких-либо комментариев, так что ее вообще не найти, кроме как через мой профиль.
Холивары народу гораздо ближе :)
Незашт :) Приятно видеть адекватных людей, а не второй сезон упячки :)
мне, лично, на орфографию наплевать. Важен контент и его актуальность
Стараемся и там, и там удачно сделать :)
спасибо, очень интересно.
А кто создает прототип на html+js? Как я понял, команда разработки в этом не участвует. Значит, созданием прототипа занимаются менеджеры и аналитики?
Просто я слабо представляю себе менеджера, делающего html макет и аналитика, прикручивающего к нему заглушки на js.
Есть два варианта интерактивных прототипов — грубо говоря, черно-белые на основе wireframes и цветные, на основе дизайна. Первые может генерировать автоматом менеджер или аналитик (если они сделаны в программе, которая это умеет), вторые делаются HTML-верстальщиком. В зависимости от свободных людей в команде, интерактивный прототип делается либо тот же человек, что верстает начисто, либо еще один. Многие считают, что делать две верстки дорого, но плюсов гораздо больше. Но не буду забегать вперед — об этом как раз во второй и третьей части :)
большое спасибо, вопрос исчерпан.
спасибо. Давно не заходил к Вам в блог, вот и пропустил обновление:))
Значит все-таки не баян :)
Для некоторых баян, а для некоторых нет. Видимо здесь общество разношерстное и всем сразу не угодишь. Мне даже интересно читать двух разных авторов пишущих на одну и ту же тему. Вы пишите пишите. Эта тема для меня актуальна:)
Значит продолжим тему :)
Спасибо. Читал статью на вашем блоге, интерестно. Особенно приятно, что публикация проиллюстрирована реальными примерами работ, которые можно посмотреть (http://uimodelling.com/) живьем (это относится к следующим частям).
Мог бы - поставил бы +
Стараюсь по-возможности иллюстрировать все материалы, но часть старых работ не могу подробно показывать, а часть текущих — потому что еще в работе. В феврале запускается два масштабных проекта, так что будет масса интересных историй и картинок :)
Классная статья! второй день собирался прочитать, наконец-то добрался :) как раз сейчас выводим это у нас в компании на новый уровень, и я собираюсь этим серьезнее заняться. теперь буду читать вторую часть. Спасибо!
спасибо :) я вчера перечитал почти весь Ваш блог. и нашел там третью статью :)
Надеюсь, нашлось еще много интересного :)
да, у Вас действительно полезные статьи, читал одну за другой, не мог оторваться :) единственное чего не нашел - описание документов которые вы используете и их поддержки по ходу проекта. например у нас принято несколько: Vision/PFD(proposal for development), Estimate и SRS (Software requirements Specification), всей документацией на данный момент у нас занимаются руководители проектов. Думаю, что стоит добавить спецификацию по дизайну с более-менее четкими требованиями, насколько это возможно. и возможно стоит разнести в разные документы test cases и use cases со ссылками из Project Chapter документа. Также, я думаю, что стоит выделить отдельно человека для поддержки документов по проекту. в общем, хочется улучшить проектную документацию и повысить качество и эффективность работы команд. поэтому я сейчас стараюсь ознакомиться максимум с тем что уже есть и придумано, чтобы не изобретать велосипед. :) а за Ваши статьи большое спасибо! очень полезные :)
Спасиб еще раз! До документов я пока не добрался — писал про самые вкусные и понятные вещи вроде схем страниц и прототипов, но постепенно дойду и до них :) Мы пишем Vision, SRS и серию других документов. Не знаю точно, что именно у вас понимается под Estimate, но судя по предположению (объем работ, расчет сроков и стоимости) — также покрывается, но другими документами. Тут все зависит от построенного в компании процесса, так что их названия и состав могут различаться. Но в любом случае те три вещи, что у вас указаны — описание проекта, его оценка и техническое задание — в каком-то виде есть всегда.

Про устав проекта, кстати, я писал недавно, а про остальное пока не успел :) Но со временем все это появится, так что подписывайтесь на RSS :)
спасибо за ответ :) буду ждать обновлений
На следующей неделе будет материал о user stories — это и часть оценки, и часть ТЗ. Надюесь, получится компактнее, чем с прототипами :)
UFO just landed and posted this here
Автор, огромное спасибо! Подписался на RSS.
Sign up to leave a comment.

Articles