СУП — наша Система Управления Проектами

Мы делаем свою «систему управления проектами» / или «систему управления знаниями».

Когда я говорю об этом, у всех сразу возникает вопрос: «Зачем, их и так завались!?»

Сейчас я расскажу зачем,  что нас к этому подтолкнуло. Я опишу нашу задумку 🙂

Кто я и почему я этим занимаюсь

Меня зовут Михаил Павлов, я закончил РГАТУ по специальности ВС — «Вычислительные машины, комплексы, системы и сети». У меня много интересов в области ИТ, например я веду следующие проекты:

• Работал  в области железа, ЦОС и АСКУЭ
• Открыл первый удалённый офис-филиал разработки компании ТЕНЗОР и работал над платформой для их продуктов, создавал команды и запускал внутренние проекты.
• Сейчас я работаю в компании друзей над своими/нашими проектами, развиваем свои юр. лица, делаем роботов и soft.
• мой центральный проект «Акапелла» — облачная виртуальная машина
• СУП — система управления проектами
• IOT платформа на Spark / Tornado и Cassandra + производство своего железа для климатического оборудования
• и много внутренних web технологий

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

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

Я начал делать его один, параллельно создавая  очередную «сумашедшую» концепцию построения web, создавая попутно платформу для неё и каркас.

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

В итоге первые три версии я полностью переписывл раза три точно, а СУП был тем проектом на котором платформа обкатывалась. СУП подходила для этого идеально, ведь там и работа с данными, RIA, PUSH/COMET, индесация и текстовый поиск, и масштабность иинетфейс смешанный из HTML и динамической графики и модульность/плагинность в разумных пределах… Мне нужно было всё самое самое…

Как личное впечатление  от работы над проектом я бы сказал : «Тащусь, я хочу эту штуку».

Изюминка проекта

Что это за проект ? Зачем он нужен?

Ну зачем он нужен я уже сказал: «для управления проектами и знаниями».  Для организации информации.

Я позже обосную почему мы решили именно так, но вот, что мы решили:

СУП имеет главный web интерфейс в виде MindMap — «карта знаний».

Базовый набор инструментов в стиле Social для обсуждений, чатов, поделиться, поискать…  Но он расширяется через  внешние сервисы. Мы их называем Web Hooks

Есть два типа компаний:

• Одни «закрытые». Там надо назначать права, чтобы кому-то показать информацию и назначить роли. Секретность же!
• Другие «открытые», это для творческих коллективов, где креатив и наборы работающих практик. Там много информации открыто и важно удобно найти, представить и впитать.

Есть ещё третий тип, это небольшие компании, в которых весь креатив идёт от директора, но их мы пока не будем брать тут в расчёт, хотя для них тоже все это подходит.

Многим командам нужно просто организовать как-то информацию, чем она лаконичнее — тем все лучше и быстрее. Чтобы надписи были простые и короткие важен контекст. Контекст хорошо описывается деревом т.е. MindMap.

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

Добавив в открытый MindMap права и доступ — получам рабочее поле для «закрытых компаний».

А Что таккое «расширяемый за счёт внешних сервисов ?».

Если Вы пытались сделать свою сборку Redmine — Вы меня поймёте. (Jira и подобные — туда же).

Нужен доступ (типа админского) к целевой машине, сложные языки настройки, сложные языки запросов, плохая расширяемость, плохая совместимость логики модулей, необходимость пересборки и даже ! иногда конвертации БД — полный кошмар для быстрого расширения вашей системы управления проектами.

Мы даём по SaaS доступ к базовой установке и такое API, которое позволяет управлять ситуацией, так многие поступают, но часто невозможно реагировать на события обрабатывать их. Мы делаем внешний сервис обработчиком событий и помещаем в него логику «методологий» управления проектами, которых много.

Вам нужен контроль дат исполнения или отчёты по сделанному — зашли в настройку карты и прописали Url спец сервиса и вуаля — новая логика в системе появилась. Можно самому написать такой сервис или разместить его у нас на машине рядом с базовой установкой или выбрать готовый из множества полезных. Можно сделать пресеты из набора полезных предложений для разных типов бизнеса или отделов…

Ничего с админсткими правами не надо ковырять — всё делается чрез настройки карты, базовый сервис остаётся стабильным.

В нашем MindMap мы для пущей формализации сделали узлы типизированными (это не обязательно) и у них есть свойства разного типа и правила форматирования…

Короче мы пробуем управлять и знаниями  компании  и работами/задачами  компании прямо из карт MindMap online.

Технологии разработки

При разработке использовались следующие звенья:

• Flask — большая часть синхронной логики
• Tornado — в него встраивется wsgi контейнер Flask , сам он нужен для PUSH social целей.
• Postgres 9.4 jsonb для хранения структуры узлов
• libtree,  ClosureTable для хранения иерархии узлов (мы там немого допилили транзакционность)
• AngularLight до 12-й версии — DirtyCheck JS library/framework для управления состоянием клиентской части web приложения
• aplib —  я написал как дополнение — хорошая система JS  web компонентов, которую буду двигать как отдельный «продукт»

Ответы на вопросы «Почему Х» ?

• Flask. Он прост как валенок снаружи и глубок внутри, для синхроной логики «то , что надо»
• Tornado. Я люблю эту штуку за то, что она может всё. А нам нужна асинхронная работа с можеством соединений…
• Postgres. Я в первых версиях использовал TokyoCabinet + Distopia  т.к. основная структура это дерево документов, а не их множество. Изначально карты планировались огромными — много много миллионов узлов а планаризация графа расчитывалась на сервере для всех юзеров сразу, точнее поддерживалась в актуальном состоянии. Но отказался от этой версии. «PG — надёжен как слон!», вот и всё. А планаризацию мы переписали на JS.
• ClosureTable. Ой уж сколько я взвешивал все «за» и «против».  И в итоге решил, что гибкостьдля СУП критически важна. А  т.к. в PG «большие»/»средние» траназакции часто не мешают другим, то приемлимо взять CT. И не жалею совершенно, камень с плечь свалился после этого решения.
• AngularLight. Я так в него верил, а он сейчас неисправимо испортился. И мы остались на ядре версии до 12-й, и счастливы. По моему это очень хорошая штука, точнее её ядро. Я поверх него очень интересный каркас написал. AL — это DirtyCheck state controller, поверх которого накручены функции-директивы, которые декларируют синтаксис пометок в DOM. Важно, что у AL «ручной спуск» и это позволяет запускать проверки только для валидных состояний, которые не находятся в рассогласованнии с самим собой… Технологичекая единица, короче.
• aplib. тут я так её назову. Это маленькая библиотека уже выросла до концепции построения web компонентов и о ней надо отдельно писать.

Будущее проекта

Какое будущее для проекта я вижу ?

• Сначала добавим типовые методики управления проектами
  • добавим методики для управления командами «разработки софта» т.к. тут у нас наибольший опыт
  • добавим методики для управления отделами продаж и call центрами и т. д.
• Добавим больше отчётов, красивых и полезных, это делается очень просто
• PR инструменты. Интеграция с соц. сетями и блогами, чтобы можно было автоматически публиковать целые классы материалов при достижении определенных условий. Например у вас в команде, есть молчаливый специалист, который пишет иногда научные статьи — можно публиковать их автоматически.  Иногда новости в проекте должны быть актоматичеки доступны заказчику и он хочет получать их в свой telegam…
• Умная лента. Очень важно для сроков проекта, чтобы все уведомлялись только о том, что важно для конечной цели так, чтобы это требовало от них действий. Но не уведомлялись о «всякой ерунде». Как составить для себя умную ленту ? дело в том, что если ты сам её формируешь, отсекая «ненужное», то важное может до тебя не дойти извне… тут тоже есть методики определения фактов необходимости уведомлений. Если у вас просто трекер — этого там не будет никогда. Вы будете видеть или все=ничего, или не видеть вовремя важное. Уведомления это не просто лента! это станет напоминаниями в телефоне или будет интегироваться с вашим todo. Или уведомления будут идти на почту или публиковаться в rss.
• Автоматическая транформация предствалений информации + фильтры. Узлы дерева MindMap можно автоматически кластеризовать «по дате», «по исполнителю», «по результатам». Это меняет иерархию, но это иногда полезно. Можно высветить важное по ряду критериев.
• Несколько разных методик управления проектами для разных отделов внутри компании с одним полем информации.
• Также я хочу методики так сказать «с миссией, а не целью», например, я хочу формализовать Японский «P2M» (как то «сбалансированная система показателей» и подобные элементы)
• Сервисы-Плагины станут влиять не только на логику обработки информации, но и на представления — можно сделать интерфейс плагинным. Позволить управлять клиентским состонием или встраивать в него компоненты, которые могут расширить состояние или изменить сам интерфейс. Это позволит строить поверх СУП новые системы с иным интерфейсом, или добавлять в карту мини-приложения
• Будет легко делать бизнес приложения по требованию. Ведь база уже есть, с поиском и логикой. Останется написать пару логических модулей и может 1-2 web компонента.

интересности, которые мы уже преодолели

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

Надо было отобразить дерево элементов MindMap. Это и графика и HTML контент. Что я только не придумывал.

Сначала я попробовал так всё сверстать, чтобы браузел всё это расположил, но тогда не рабобтал drag &drop и я не мог нормально провести просто линии от любого узла другому вне единой ветки иерархии. Это было «закостенело».

На Canvas можно рисоватьhtml , но с ним «никак взаимодействовать», как с обычным контентом, попробовал кучу библиотек, круто, но  не то.

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

Сейчас мы совместили SVG, управлемый директивами для AL и HTML узлы поверх него, управляемый также. Наш код, получился очень лаконичным а модификация состояния быстрой, за счёт своих директив для AL.

Планаризация. Дерево узлов MindMap хоть и простой граф, дерево, но всё же это граф, который надо разложить на плоскости. У каждого пользователя структура дерева одинаквая, но отображение разное т.к. у кого-то одни узлы свёрнуты, у других открыты. У кого-то размер узла установлен удобный ему а у другого пользователя размер другой, из-за установки или других шрифтов… Надо расчитать позиции узлов каждому пользователю, чтобы отобразить карту или её часть — сделать планаризацию.

Раньше у нас планаризация жила на сервере, как и вся карта, я уже писал об этом чудо планаризаторе.

Потом мы решили взять уже готовый планаризатор на Python и запустить его на JS — странслировать, чтобы не переписывать, и одно время так и жили. О  этом тоже есть статья, как странслировать Python  в код JS.

Vis.js я с самого начала отметал как негодный и вот почему: «надо для любой точки получать контекст, это требуется для drag & drop, а обычные планаризаторы умеют только в одну сторону расчитать координаты и всё, а обратно по координатам не умеют…».

Потом мы нашли время и переписали на JS планаризатор и теперь там вообще «летает всё».

Хранение деревьев в БД. Об этом я тоже написал статью.

Сначала хотелось  даже отказаться от БД, но позже мы согласились, что надо жить уже в 21 веке 😉 , как я люблю говорить.

Все остальное , кажется,  было делом техники.. А! компоненты.

Компоненты. Дело в том, что веб интерфейс это такая штука в которой «чем дальше в лес, тем больше дров.» Мне не хотелось этот проект в такое превращать, и хотелось держать код в чистоте. Мы как-то 31 декабря сидели с Сашей и мучались вопросом: «что же в вебе всё так не по людски-то?!». Мы оба вспомнили тот момент когда была шумиха : «вооот всё, теперь есть bootstrap компоненты, теперь заживём…. !!!» а когда мы узнали, что просто CSS мы ….. короче я не буду тут это описывать, что это было!.

Тут полной статьи пока нет, есть кусочки. Вот я начал с описания истории web интерфейсов. Там оголил плюсы и минусы опредеденных подходов.

Описание наших Web Компонентов будет скорее в технической документации к СУП.

 

СУП в пути. Ждите!