Модели разработки программного продукта
Процесс разработки программного обеспечения обычно движется с помощью того, что получают пользователи. В начале была модель водопада (waterfall model) на основе мира, где все известно заранее, и спецификации не меняются (например, плод). В конце разработки пользователи получают что-то функциональное, но не то, что они хотели или им требовалось.
Затем пришла спиральная модель (spiral model): Iterative, Agile, XP. Она была нацеленна на удовлетворенность клиента. В отличие от модели водопада (которые идут в одном направлении и не делают резервную копию), спиральная модель может производить программное обеспечение которое более вероятно, соответствует тому, что хотят пользователи. Юзабилити необходимо для спирального развития, так как на каждом этапе оцениваеться успешность принятого решения.
Но что будет после юзабилити?
Будут ли новые подходы к разработке ПО и что бдует на них влиять? Ниже представленна иерархия потребностей и желаний пользователей. Которая явно или косвенно влияет на разработку программного обеспечения:
После юзабилити будет пользовательский «поток»
Сейчас пользователь благодарит нас за предоставленную ему полезную, хорошо продуманную и удобную программу. Но потом он захочет, чтоб приложение было интересным и затягивало его в происходящее с первой секунды. Можно ли будет держать его в такой степени вовлеченности, чтоб во время использования он забывал о повседневной жизни? Програмное обеспечение должно очаровывать и затягивать пользователя с собой.
Даже если пользователи не начинают требовать «потока», это огромные возможности и преимущества для тех, чьи продукты реализовывают его и один из основных критериев продуктов для активных пользователей.
Это всё грубые предположение по поводу развития разработки программного продукта.
Хотелось бы услышать, что думают специалисты по этому поводу?
Не понимаю, почему такой оборот: «после юзабилити». Кто-то придет и отменит юзабилити, заменив его чем-то совершенно иным?
Пирамида потребностей весьма и весьма спорная как по составу, так и по расположению элементов.
Местами создается ощущение, что статья — машинный перевод с английского. Англоязычные блогеры почему-то любят вот такие «философские» статьи, из которых нельзя извлечь никакой полезной информации.
Спасибо, Scriptin. Хотелось бы услышать ваше предложение по пирамиде.
Специалисты думают, что автор плохо представляет себе идеи и ценности вотерфольного и гибкого подхода, и делает сомнительные выводы из неправильных предпосылок.
Автор не так плохо себе представляет ценности этих 2-х подходов как может показаться. Если есть ссылки на полезные ресурсы, то я их с радостью добавлю для детального ознакомления.
Согласен с предыдущим оратором в том, что пирамида глупая, и что воды здесь налито, и вообще очень поверхностный взгляд.
Тот же итерационный подход имеет множество вариаций — неохота их тут приводить.
А у разработчика приоритет вообще тоже всегда один: сделать то, что будут покупать.
Но сам вопрос о будущем юзабилити от этого не становится хуже. На мой взгляд, будущее за «незаметным тестированием». Меньше опросов и фокус-групп, меньше подглядываний и айтрекингов — больше пользования как такового.
И здесь возникает задача, которая лично меня очень интересует: как представить качественные показатели (нравится/не нравится, хочу этих данных больше/меньше, я устал/хочу продолжения и т. п.) в виде количественных, измеряемых показателей. Рынок такого служебного софта только-только начинает зарождаться. Вот у меня есть кое-какие наработки в этом направлении, но я их вам, так и быть, пока не покажу )
Спасибо, arvik! Очень интересно увидеть ваши наработки ) Что касается пирамиды потребностей, то мне она представляется такой. Если есть предложения по улучшению или свои виденья потребностей то хотел бы узнать.
Вот пример игры с сильным вовлечением — http://intihuatani.usc.edu/cloud/flowing/
Интересная статья! Пирамида, вроде как, отражает потребности и желания пользователей, но мне кажется что она будет изменяться (меняться местами уровни) как со временем, так и для каждой группы пользователей в отдельности. Мне кажется что такую пирамиду можно строить для каждого проекта, для каждой концепции отдельно!
Так и не понял сущности Post-Agile. Сверхбыстрые циклы никак не могут быть его целью. Точно также, как и пользовательский поток. Поток вообще вещь двойственная. Во многих случаях, пользователи не хотят быть вовлеченными. Т.е. проектировать для потока — это в какой-то степени проектировать против пользователей.
В пирамиде потребностей пользователей никак не выражен социальный компонент. (Потребность в уважении и признании у Маслоу.) + Потребность в самореализации.
Я думаю, что именно в эту сторону, а не в сторону потока будет двигаться проектирование.