Когда-то, помыкавшись в поисках онлайн системы управления задачами было решено писать свой «велосипед». Но с уклоном в ту область, которая, к примеру, мне более важна — учет будущих и повторяющихся задач, а грамотного подхода к этому вопросу я не увидел ни у одного существующего сервиса.

Похожие системы пишет под себя огромное количество разработчиков, даже прослеживаются некоторые тенденции:

• большинство тяготеют к управлением проектами, т.е. уклон в область совместной работы, постановки задач другим пользователям и прочим видам collaboration
• подходы к определенным вопросам очень сильно похожи на лидеров рынка (Google calendar с его принципами установки повторения задач, к примеру). Мало кто делает нормальное древовидное представление задач, т.к. коли это не особо распространено, то значит и не особо востребовано. Но я почему-то всегда попадаю в ту группу пользователей, которым не хватает возможности что-то подкрутить, порыться в настройках. Отдельная песня – идеология Apple, где в большинстве случаев настройки программы сводятся к паре галочек. Иногда такой подход даже обижает.

Вкратце сразу сообщу ключевые функции системы (т.е. те, которые либо мало распространены у аналогов, либо вообще не встречаются у них):

• подзадачи, папки, подпапки, неограниченная вложенность
• повторяющиеся задачи (несколько методов повторения)
• односторонняя и двусторонняя синхронизация с Google Tasks
• триггеры (определяемые действия на создание, изменение, удаление задач, наступление времени и т.п.)
• пользовательские фильтры (настраиваемые практически до SQL запроса)

Итак, в наличии было небольшое количество выделенных серверов в ДЦ Hetzner (Германия), арендованных по рабочим нуждам, но слабо используемых (основное назначение – хранение данных, поэтому нагрузки мало). Также имелся опыт разработки на T-SQL, Delphi, Visual C, .NET. Крайне мало опыта было в Javascript, пришлось наверстывать.

Мы – это полтора разработчика и много подчиненных пользователей – тестеров. Система активно используется в повседневной работе, никак не связанной с разработкой софта. Специфика работы такова, что задач однотипных много, много из них еще не наступили, но нужно иметь возможность их видеть и делать заранее.

К примеру, учет доверенностей. Основная задача – не пропустить срок ее истечения и заблаговременно предпринимать действия по ее продлению. Для этого использовались следующие фичи:

• за месяц до окончания доверенности шло уведомление по почте (триггер)
• за неделю до окончания доверенности задача по ее продлению помечалась как важная и, соответственно, отображалась в списке самых важных дел (триггер)
• отдельным фильтром отображались все доверенности, истекающие в течение месяца
• отдельным фильтром отображались все доверенности, истекающие в следующие три месяца

Прежде всего некий disclaimer. Мы не пытались сделать очередной “комбайн”, наш сервис не является системой для, к примеру, багтрекинга, т.к. это абсолютно другая специфика. Сервис прежде всего ориентирован на обычных “продвинутых” пользователей, которым нужно чуть больше от систем управления задачами, область применения – учет личных задач (купить, отследить, напомнить и т.п.) с возможностью совместного использования с другими пользователями (пускай, родственники, коллеги).

Что реализовать даже не пытались:

• таймтрекинг
• аналоги багтрекинга
• общение, всякие социальные кнопки
• строгого соответствия канонам GTD. Точнее все необходимое вроде для этого есть (поле «Контекст», тэги с неограниченной вложенностью), но особо на методику GTD не ориентировались.

А нужно мне было от управления задачами следующее (список, конечно, неполный, но показательный):

1. Cписок задач принципиально в древовидном виде, с папками и подпапками, вложенность должна быть неограничена (чтобы там ни говорили про то, что три уровня вложенности хватит всем – враки)
2. добавление задач по электронной почте, причем при направлении по разным адресам — в разные подпапки
3. учет домашних дел (оплата по квитанциям, проверка масла в машине, отслеживание сроков окончания оплаты и т.п. с разной степенью периодичности, автоповторения и настраивания уведомлений обо всем этом абсолютно разными способами — хотел чтобы об оплате я предупреждал сам себя три раза, а о некоторых событиях — предупреждал о просрочке более чем на неделю)
4. по работе — тут сложность в количестве — нужно было отслеживать сроки окончания доверенностей, договоров, сертификатов и т.п., причем также нужно было настроить уведомления о пропуске сроков. Количество этих задач — сотни, поэтому ни один из существующих менеджеров задач с этим либо не справился, либо реализация всего этого была неудобной
5. просмотр повестки дня (списка актуальных дел) кроме сегодняшнего еще и на любой произвольный период, причем с навороченной фильтрацией, к примеру в одном списке нужно было выводить текущие задачи, задачи которые начнутся в ближайшую неделю плюс все домашние задачи, кроме неважных задач (с небольшим приоритетом)
6. давать доступ Read-only кому нужно на все это
7. давать write доступ кому нужно, причем с правами изменения только определенных полей задачи (к примеру, работнику, который может только менять статус задачи)
8. использование временных зон, т.к. коллеги работают с теми же данными, но в других часовых поясах, поэтому все используемые даты должны корректироваться в нужную временную зону
9. система меток (тэгов) – обязательно древовидная, с возможностью совместного использования (т.е. чтобы определенные метки были видны другим пользователям, а другие – только мне)
10. возможность временного сокрытия некоторых задач (к примеру – мозолит глаза какая-то задача – скрываем ее на 2 дня, после этого она опять появится). К слову такой механизм можно и так реализовать еще другими способами

Ну и, понятно, что также нужны распространенные базовые функции:

• вывод и отсылка на почту повестки дня (настраивается как простой вариант – просто список на почту ежедневно в назначенное время, так и в виде триггера по расписанию – высылаются нужные ветки задач путем редактирования текста письма)
• настраиваемые пользовательские поля (настраиваемость, правда, заключается только в изменении названия, смена типа данных не реализована, пока не видел необходимости)
• настраиваемый внешний вид задач (шрифт, иконка, цвета)
• произвольная сортировка подзадач каждой задачи по трем критериям (задач, повторюсь, много, поэтому без сортировки никак)
• RSS канал с настраиваемыми уведомлениями (ну люблю я лежа полистать feedly, заодно поглядеть и свою ленту уведомлений)
• Поле «Прогресс» с графическим отображением (на самом деле, мало кому действительно нужно)
• Приоритеты задач

4 месяца работы и в итоге получился некий «движок» для учета задач, все что хотел — реализовал.

Вкратце о получившемся.

Основная единица информации – задача. Задача имеет дату начала и дату конца (due date). Если с due date все понятно, то с датой начала стоит объяснить, т.к. далеко не во всех аналогичных системах она есть. По сути, это дата, с которой задача считается актуальной. Т.е. присвоив задаче дату, она не будет выводиться в списке задач до тех пор, пока не наступит эта дата.

В основе группировки задач и разделения доступа — понятие «Список задач». Т.е. некий набор задач, к примеру, «Дом», «Работа», «Компьютер» и пр. В других системах это может называться тасклистом, проектом, календарем, workspace и т.п. Также функция такого деления – каждый список имеет свои настройки прав доступа при совместном использовании и свои настройки временной зоны.

Отдельно про временные зоны. Мне кажется, на практике это мало кому нужно, но нам это нужно было просто критически. Несколько наших работников и лиц, которым предоставлен доступ, работают в совершенно разных временных зонах, редактируя и просматривая задачи из одинаковых списков. Если при установке даты задачи указывать конкретно время особо и не нужно, то при настройке уведомлений, триггеров иногда необходимо указывать конкретное время, к примеру, ежедневно сменять статус задачи в 20-00. Т.е. смена статуса должна происходить именно в 20-00 временной зоны пользователя, поставившего триггер. Для корректной реализации этого устанавливается временная зона каждого пользователя и конкретного списка задач.

Что касается прав доступа, то пришли к следующему решению. Пользователь может делегировать право на просмотр/редактирование определенного списка задач другому пользователю.

Могут быть установлены следующие права:

• Только просмотр
• Только добавление задач
• Только редактирование задач
• Только удаление задач
• Редактирование и удаление задач
• Редактирование и добавление задач
• Добавление и удаление задач
• Полный доступ

Дополнительно при условии права на редактирование устанавливается список полей, которые запрещено редактировать пользователю. Это позволяет реализовать такой механизм взаимодействия пользователей при совместной работе – кто-то, владеющий правами ставит задачи, а кто-то другой, имеющий только ограниченный набор прав может только помечать задачи как выполненные. Т.е. можно ставить задачи, не волнуясь, что кто-то сотрет саму задачу или что-то в ней подправит. Понятно, что в системах управления проектами все это реализовано на более высоком уровне, но мы не пытались объять необъятное и реализовали базовый набор.

Просмотр дерева задач возможен на любую дату, как прошлую, так и будущую. Т.к. информация о задачах хранится безотносительно к текущей дате, можно ткнуть какую-либо будущую дату и увидеть состояние выполнения задач на эту дату. К примеру, частенько, когда есть лишнее время, хочется сделать что-то заранее, но коли время еще не подошло, то и будущие задачи еще не показываются, т.к. они в будущем. Тыкаем будущую дату – и видим что можно сделать из будущих задач.

Фильтрация

С помощью настраиваемых фильтров можно реализовать следующие пожелания:

• список задач только из определенной папки (к примеру, либо с подпапками либо без них)
• список задач только на следующую неделю
• в одном списке – задачи из определенного списка задач на следующую неделю, из другого списка – только просроченные на 1 месяц

Фильтры — вещь достаточно удобная и гибкая, но мало кто ее прикручивал хорошо. Чтобы это действительно было удобно, нужна возможность группировки критериев, это реализовано (спасибо DevExpress, тут львиная доля заслуг у них).

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

Мобильная версия.

Сам я 80% процентов своего свободного времени провожу за iPad, поэтому вопрос создания приложения под iOS/Android не стоял – оно было необходимо. И было решено его не разрабатывать. Совсем. Пошли другим путем – путем гибкой синхронизации с Google Tasks можно основную часть повседневной работы (основное редактирование задач, просмотр и отметки о выполнении, т.е. основной функционал tasks) перенести именно в Google Tasks, а всю информацию периодически синхронизировать (двусторонним или односторонним путем) с сервисом. Точнее синхронизация автоматическая, точнее периодическая (push Google Tasks не поддерживает). Приложений для Google Tasks более чем достаточно, некоторые просто шедевры. Почему бы хотябы в этой части не изобретать велосипед, а использовать чужие наработки :)

Техническая сторона.

Сервис написан на ASP.NET, крутится на одном дедике. БД – PostgreSQL, крутится на другом.
Изначально писалось на MSSQL, но потом стало понятно, что постгрес подходит больше. Тяжеловато было переписывать все на постгрес, но оно того стоило.
80% бизнес-логики реализованы в БД, так оно как-то быстрее работает.
Использованы серверные компоненты DevExpress – основная нагрузка лежит на ASPxTreeList. Да, пришлось использовать именно серверные компоненты, пускай это лишний трафик для клиента, но иначе не реализовать работу с тысячами задач и некоторыми функциями. Да, это ведет к некой инертности работы “дерева”, но “отклик” порядка 200-300 мс практически незаметен, поэтому устроил. Из аналогичных компонентов пробовал и телериковские, но там очень неприятные тормоза при сворачивании/разворачивании дерева, некомфортно работать.
Используется ASP.NET WebForms, знаю, что немного устаревшая технология, но практически вся работа сосредоточена на одной странице и постоянных коллбэках одного элемента, поэтому переход на MVC мало что бы дал. А вечную проблему излишнего размера ViewState вроде минимизировал.
В два отдельных приложения вынесены операции с почтой (прием задач по почте и отправка) и синхронизация с Google Tasks. Их писал на Delphi.

Опять disclaimer

1. 1Ради убыстрения разработки многие относительно нечасто используемые части интерфейса (редактирование списков задач, триггеров) написаны с применением готовых элементов управления от DevExpress, поэтому чуть тяжеловаты
2. Поддерживаются все распространенные браузеры, но со старыми версиями могут быть проблемы. IE8 иногда выдает ошибки, но т.к. под рукой чистого IE8 нет, руки пока до исправления ошибок не дошли.
3. Синхронизация с Google Tasks работает, но злобный Google недостаточно пока увеличил квоту на запросы к их API, поэтому теоретически в случае притока пользователей, которые настроят эту фичу, возможна остановка синхронизации в ночное время на первых порах. Долблю их саппорт как могу.

Монетизация и сохранность данных

Монетизация в обозримом будущем, разумеется, не планируется. Если она и будет, то только в случае постоянного роста активных пользователей и увеличения потребности в мощностях. На данный момент ресурсов у нас достаточно, чтобы без напряга выделить пару серверов под этот проект, тем более по hetzner`овским ценам. В случае чего — можно и увеличить количество. Если какие-либо платные аккаунты будут вводиться, то правильной практикой будет то, что зарегистрировавшиеся ранее пользователи получат пожизненный бесплатный «premium» аккаунт. Про сохранность данных — в случае закрытия сервиса все пользователи будут уведомлены и будет не менее двух месяцев на перенос данных. Если кто-то знает как лучше предложить пользователям резервировать данные — сообщите, пожалуйста. Мне пока кроме синхронизации в Google Tasks ничего на ум не приходит. Можно и экспорт прикрутить, к примеру, в csv.

Планы

• Интеграция с google calendar. В процессе. Пока нет четкого понимания в каком виде это красиво реализовать, т.к. аналогов нет.
• Оптимизация, оптимизация, оптимизация. Особенно использования клиентского трафика. Плюс под старые браузеры.
• SSL
• Добавить временных вариантов повторения и планирования задач (пока реализованы базовые периодичности)
• Кинулся было писать календарное представление задач, написал, но потом решил сосредоточиться на стандартном древовидном, т.к. не стоит сразу за все хвататься, не сделав безглючным уже реализованное.

Ну и чуть позже опубликую пост поподробнее про триггеры и синхронизацию с Google Tasks, там есть что рассказать.
Ссылка на сам сервис — betasked.ru

Автор: betasked

Источник