Идеальный финансовый менеджер

После длительного испытательного срока, проб и ошибок, матюков и слов благодарности, пришел к мнению, что меня совершенно не устраивает положение, которое сложилось в области финансовых менеджеров.

Большинство из них делятся на: тупые, совсем тупые, не для людей, с невероятно странной логикой, слишком сложные и запутанные.

Поработав в течении года с системой 4konverta, ничего кроме раздражения не испытывал. Вроде и сделано толково, интерфейс приятный и задум не плохой, но блин, зачем нужно было делить месяц на 4 недели и соответственно 4 конверта, и подвязывать под это всю остальную логику работы с личными финансами?!

Приведу пример, пусть ваш месячный доход (допустим зарплата) составляет 10 000 грн. Как правило, между получением этого дохода проходит месяц, что в системе можно легко настроить. Однако после внесения этой суммы в качестве регулярного дохода она будет поделена на 4 недели, что само по себе меньше! В итоге, в остатке у вас будет написана сумма ≈ 9333 исходя из которой будут рассчитаны все 4 конверта на месяц в перёд.

Лично меня такой подход в корне не устраивает. Я хочу видеть всю сумму, текущий остаток (хотя в последней версии это таки было интегрировано) и оперировать финансами не привязываясь к “конвертам”, а исходя из расчета финансов на месяц вперёд.

Вот несколько критериев:

  • Мой расчетный период ровно месяц, а не неделя
  • Даже если поступает доход в середине месяца он всё равно попадает на общий месячный баланс
  • Если я формирую финансовую цель, значит я изначально знаю какую сумму откладывать ежемесячно. Я не откладывю “понедельно” по 478 грн. 66 коп.
  • У меня есть регулярные траты (например оплата коммунальных услуг, интернет и т.д.), которые не привязаны конкретно к первой или второй неделе месяца. Эти траты просто существуют и сумма на них перманентно выделяется в самом начале (тут даже планировать нечего, эту сумму нужно просто вычесть!).

Исходя из всего этого, сформирую список требований к системе, которой бы я хотел пользоваться:

  • Хочу заносить дневные траты автоматически. Например, просто сканируя чек своим мобильным телефоном.
  • Подстройка логики учета финансов под отдельно взятую ситуацию.
  • Возможность отклаывать на финансовые цели не привязываясь к дате. Захотел в начале месяца всю сумму, захотел 4 раза по разу в неделю – пожалуйста.
  • Интеграция с платежными системами и с моей платежной карточкой.
  • Работа параллельно с несколькими счетами.
  • Настройка финансовых инструментов. Например есть у вас депозит приносящий определенный процент в месяц или акции или недвижимость. Было бы здорово подстроить под это отдельный счет, который будет автоматически пополняться.
  • Различные виды отчетов. Детализация по категориями трат.
  • Умный планировщик/помощник, помогающий оптимизировать траты.

И завернуть всё это в интуитивно понятный и удобный интерфейс.

9 comments so far, add yours

Настройка связки Glassfish / MySQL / Spring

Намедни понадобилось перевести свой старый проект на Glassfish. Проект построен на SpringMVC, и как не сложно догадаться в качестве главного хранилища данных использует гадкий MySQL.

По умолчанию, как и предполагалось, ничего не заработало, не найдя вразумительных ответов по теме в гуглах, пришлось часок поковыряться самостоятельно, и решение было найдено.

В старой версии проекта использовался пресловутый JdbcTemplate и URL коннекта прописывался непосредство в XML конфиге Spring’а.

Однако, какой смысл использовать это неповоротливое, в плане масштабируемости решение, если мы переводим весь проект на могучий Glassfish, где есть удобная в настройке поддержка JNDI ресурсов и пулов, и даже контроль транзакционности “из коробки”.

Первое, что понадобится сделать — это правильно сконфигурировать наше веб приложение. Для этого понадобиться внести правки в конфигурацию контекста Spring, web.xml, а также создать специальный sun-web.xml декскриптор.

Continue Reading

Принципы написания User Stories

User StoriesПару слов о критериях, которым стоит следовать при создании новых User Story.

Существует такой термин — I.N.V.E.S.T.

Данная аббревиатура состоит из первых букв шести принципов, которым стоит придерживаться при создании новой User Story:

  • Independent (Независимая)
    Каждая новая User Story должна быть максимально независима от других (на сколько это возможно). Зависимости между историями делают их планирование, приоритизацию и оценку более сложными. Чаще всего, зависимостей между User Story можно избежать засчет объединения историй в одну или же разбиения на более мелкие.
  • Negotiable (Подверженная изменениям/обсуждению)
    Истории нужно обсуждать и изменять если это необходимо. “Карточка” с User Story — это всего лишь краткое описание истории, которое не содержит деталей. Детали, как правило, прорабатываются на стадии обсуждения. Однако, не стоит забывать, что избыточное количество деталей может ограничивать общение с заказчиком в процессе разработки.
  • Valuable (Полезная)
    Каждая, отдельно взятая история, должна приносить определенную пользу (будь-то пользователь или заказчик). Самый надежный способ сделать историю полезной — это заставить заказчика написать её. Как только заказчик осознает, что User Story это не окончательный документ на подпись, и что User Story можно обсуждать и менять, он будет чувствовать себя комфортнее при её написании.
  • Estimable (Поддающаяся временной оценке)
    Разработчики должны иметь возможность оценивать истории, тем самым позволяя расставить приоритеты на итерацию. Проблемы, которые могут помешать разработчикам выполнить оценку истории: отсутствие понимания бизнес процессов (в этом случае необходимо выделять больше времени на обсуждение историй); или же история слишком большая (в этом случае требуется разбиение на более мелкие истории).
  • Small (Небольшая)
    Хорошая User Story должна быть проста в реализации, обычно представляющая не более 1-й человеко/недели реализации. История, для реализации которой требуется больше времени может содержать больше ошибок связанных с масштабированием и оценкой.
  • Testable (Тестируемая)
    User Story должна поддаваться тестированию. Главное помнить, мы не разрабатываем ничего что нельзя протестировать. Если вы не можете протестировать историю, вы никогда не сможете сказать готова ли она.Пример истории не поддающейся тестированию: “Программа должны быть простая в использовании”.

Источник: http://agilesoftwaredevelopment.com

2 comments so far, add yours

Chromicious 2.0 – Релиз новой версии плагина

Chromicious Bookmarks Extension

Не так давно я выложил первую версию своего плагина для работы с закладками Delicious.com для браузера Google Chrome. Неожиданно для меня плагин получил довольно большое одобрение со стороны пользователей Chrome, не смотря на то что первая версия была ни на что не похожа.

За три месяца плагин приобрел собственный логотип, который представляет собой смесь концепции логотипа Delicious.com и цветов логотипа Google Chrome, достаточно подходящее название, которое было предложено одним из пользователей, а также оброс более богатой функциональностью.
Continue Reading

Краткое резюму об Agile методологиях

В свете грядущей конференции AgileBaseCamp, которая состоится уже завтра хотелось бы резюмировать некоторые мысли и опыт, накопившиеся за последнее время.

Continue Reading