КаБа

В общем-то очевидная вещь: чем крупнее мобильное приложение, тем тяжелее с ним управляться и тем меньше желания с ним иметь хоть какие-то отношения. Напрашивается идея дробления больших решений на решения поменьше. Но опять вопрос - по какому принципу долбашить? По функциональному? Или из понимания архитектуры? Или еще как-то так, как в голову с ходу не приходит? В общем когда мы в этот вопрос уперлись (мы - это я и  +Юлия Фокина ), у нас спонтанно появилась вот такая картинка: Что хотелось этой картинкой сказать... Когда клиент обращается к мобильному приложению, он это делает исходя из необходимости добиться какого-то результата (цель), значимого в контексте его жизненной ситуации. Т.е. жизненная ситуация диктует ему, какой функциональностью воспользоваться. А опыт все это дело усугубляет ожиданиями от результата и пути его достижения. Отсюда возникает идея, что дробить большие решения на набор мелких предпочтительно исходя из пересечения двух пониманий: жизненный оп

Ниже будет несколько мыслей по мотивам прочтения вот этой статьи:  Магазин финансовых приложений от Credit Agricole Во всем этом деле есть несколько моментов, обращающих на себя внимание: Банк не просто открыл API, но и создал сообщество девелоперов, которые разрабатывают для его магазина мобильные приложения. Клиенты вовлекаются в разработку приложений - генерят идеи для новых приложений, предлагают изменения в существующие и т.п. Клиенты платят абонентскую плату за использование приложений из магазина, есть три тарифа (мне очень понравилось название “разведывательный”). Из собранных денег доля перепадает в том числе и внешним разработчикам (в зависимости от популярности их приложений). Что очень прикольно - по сути банк создал некоторую социосреду, которая потребляет мобильные продукты, но при этом формирует идеи и оплачивает их реализацию. Т.е. в идеале можно вообще выйти на такой уровень, когда банк будет просто иметь постоянное пополнение своего магазина и богатое предл