Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Efficiefy.io, сервис менеджмента знаний на вашем проекте

Введение

Всем привет, меня зовут Александр. Вместе с dou.ua/users/german-chizhov, мы основали проект Efficiefy.io (web.archive.org/...​322/https://efficiefy.io) — сервис для отслеживания движения знаний на проекте. Сервис дает возможность контролировать состояние знаний на проекте в целом, и за каждым разработчиком по отдельности, вести учет продвижения разработчиков в предметной области и получать slack уведомления по изменениям определенных частей кода на проекте.

Идея

Свой путь в IT начался много лет назад. За это время я успел поработать на разных должностях.
На протяжении этого времени я стал замечать проблемы распределения знаний на проектах. Проблемы были разные, кто-то забыл описать новый функционал в confluence, тикеты в jira не обладали большой информативностью, а выполнять задачи было надо.
С решением таких проблем, я думаю все знакомы: спроси того то, он с этим работал и расскажет. Так все и решалось, находил нужного человека он вводил в курс дела, немного (много) кода, и задача выполнена. Проекты сменялись, а подход оставался одним же.
С ростом опыта, я начал подмечать, что от проекта к проекту, такая роль перешла ко мне. Все эти вопросы и ответственности перешли ко мне, причем на регулярной основе. Не сложно заметить что такая роль есть на каждом проекте, и проблематика такая что команда становится плохо сбалансированной. Часто при переходе к следующему проекту, тень прошлых проектов еще долго шла за мной. Так появилось ощущение что это важная проблема менеджмента на проекте. После некоторого осмысления этих проблем, удалось выделить основные признаки плохого управления знаниями:

— Присутствие на проекте мастера на все руки — разработчика, который знает всю бизнес логику, и не один тикет не проходит без его консультирования, а вопросы к нему часто одни и те же
— Поиск необходимых ревьюверов на пулл реквесты занимает долгое время. Не всегда поиск увенчивается успехом, т.к. многие задачи касаются определенных частей бизнес логики лишь вскользь и соотв.человек выполнявший не всегда может быть качественным ревьювером.
— Некоторые члены команды, обязательно должны быть осведомлены об изменениях определенных доменов проекта, чтобы проконтролировать правильность внесенных изменений. Потому как только они знали что тот самый if, не надо было удалять.
— Confluence не дает ответы на вопросы. Только очень общее описание, знания там очень поверхностные, их не хватает, чтобы самостоятельно начать работать над задачей.
— Даже если разработчики уже работали с задачей в рамках предметной области, то они все равно систематически возвращаются с вопросами к
этому человеку. Не 1 или 2 задания в этой предметной области, а систематически, так как, этого не хватает чтобы разобраться.
— На плэнинг митингах, все тикеты по особой предметной области достаются постоянно одному и тому же человеку, только потому что в данный момент, он лучше всех понимает эту область, и сейчас надо делать быстро, а это сейчас не меняется из года в год на проекте.

Это говорит нам что знания на проекте не сбалансированы, кто-то является основным холдером всех знаний. После того, как такой человек уходит на другой проект, деливери нового функционала для бизнеса замедляется в разы, а то и вовсе поезд останавливается на какое-то время. Поддержка проекта замедляется, так как тот самый if оставил , и только он знал об этом, специфическом бизнес требовании которое сказал ему бизнес аналитик в последний момент. Некачественное код ревью влечет за собой потерю прибыли для бизнеса. А все потому что распределение знаний было неравномерным между всеми разработчиками.
Именно такие наблюдения привели к идеи этого проекта. Результатом работы над этим проектом стал сервис для анализа кода — efficiefy.io.

Целью сервиса Efficiefy является помощь в правильном направлении знаний на проекте и распределения знаний по доменам между разработчиками в команде. Сервис полезен всем компаниями работающим в IT-сфере, где число разработчиков больше 7. Но наиболее эффективным он будет когда количество разработчиков 10 — 15 человек. В такой команде, проследить кто каким доменом занимался является проблематиным и найти нужных ревьюверов тоже, знания разбросаны не понятно как, и в этом надо разбираться.

Альтернативы

Альтернативами Efficiefy являются GitPrime WayDev. Эти решения нацелены на показ статистических показателей по коду, в то время как Efficiefy нацелен, на анализ показателей по доменным областям проекта. Т.е. основное отличие в том, что целью является анализ доменов на основе кода и отслеживание отношения домен-разработчик-опыт на проекте.

Так же отдельно можно упомянуть сервисы вроде Confluence. Мы не пытаемся заменять такие сервисы, мы их дополняем: Confluence хранит знания, а Efficiefy контролирует распределение знаний.

Такой взгляд на вещи очень актуален, так как для любого проекта важна ценность и вклад каждого сотрудника в домен проекта. И быстрое ориентирование по проекту скорость разработки и правильность реализации той или иной бизнес логики. Например на очередном пленинге, больше людей будут осведомлены по всему проекту, и каждое решение будет проходит через большее количество умов, выполняя так сказать pre condition check для каждого тикета, до этапа его разработки.

Принцип работы проекта

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

Среда использования

Сервис будет интересен в первую очередь проджект менеджерам, тимлидам, архитекторам проектов и всем, кто интересуется управлением разработки программных продуктов. Самый эффективный результат наш сервис принесет, в командах от 7- 8 человек, в 15 польза будет, как мы видим, ощутима, так как исчезает потребность в ежедневной трате времени на поиск ревьюверов, прослеживании за теми кто с чем работает, чтобы эффективно управлять знаниями. Будет полезно использовать данные анализа Efficiefy, когда будет планирование заданий, спринтов, распределении ресурсов команды.

Регистрация

Попробовать Efficiefy в действии очень просто. Для этого необходимо перейти на app.efficiefy.io/init/user-register, пройти регистрацию и инициализацию проекта и начать пользоваться.
Пока-что efficiefy работает только с github. Чтобы зарегистрироваться необходимо установить github app на выбранные репозитории.
Далее вам будет предложено создать проект, выбрать репозитории, и через какое-то время efficiefy вычитает и проанализирует данные с github. Код проектов, efficiefy не сохраняет, все данные только используются во время обработки чтобы выделить знания которые хранятся в предметной области и коде.

Приложение

Пройдя регистрацию мы увидим главную страницу:

Важной страницей являются регионы. Регионы это аналоги под-доменов. Если представить весь домен, как карту, то очевидно что, будут под-домены, например для многих проектов, типичные функционалы и поддомены как reports, invoices, auth, processors, jobs, orders и многое другие.

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

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

Немного ниже мы увидим информацию, о том какие пул реквесты причастны к изменениям в данном регионе:

Теперь посмотрим на некоторые частотные показатели этих данного региона, коммиты, компетенции, пулл реквесты:

Как я описывал ранее, одна из известных проблем это поиск рекомендуемых ревьюверов для пулл реквестов. На этой странице мы видим что, рекомендуемые ревьюверы отображаются на странице пулл реквестов отдельной колонкой:

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

Как было описано выше очень важным показателем является риски распределения знаниями. Риски указывают на моменты, где бизнес может терять деньги в будущем. В нашем случае решение это более равномерно распределять знания на проекте между разработчиками. Цветами отмечены, возможные причины данных рисков. Их можно отображать по регионам пулл реквестам, и коммитам:

Риски по регионам:

Риски по пулл реквестам:

Риски по коммитам:

Страница с проектами отображает текущие проекты, где можно отредактировать опции проекта, например коллабораторов на проекте:

Также можно посмотреть самые последние коммиты:

Технические особенности

Изначально был выбран github так как, было удобно пробовать это все там, да и вообще понятный сервис, хотя местами их API был не в радость нам. В дальнейшем мы планируем добавить туда, поддержку других git storages и task trackers.

Разрабатывали мы это все на Java, Spring, Angular 8. Данные технологии были выбраны ввиду знакомства с ними и ежедневной работы с ними. По началу мы подумывали посмотреть на Scala но ввиду того что это новые технологии, для нас решили придерживаться спартанских прагматичных взглядов, чтобы максимально сосредоточиться на работе над проектом, а не над самообразованием.

Выводы

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

Мы ожидаем всех желающих попробовать наш сервис, хотя бы в ознакомительных целях. Можете сразу регистрироваться и пробовать сервис, или же заполнить форму docs.google.com/...​E7g_VYfsb2A5FfxA/viewform

и мы с вами свяжемся проведем демо и постараемся понять ваши проблемы чтобы предоставить примеры использования нашего сервиса.

Если есть какие-то вопросы или пожелания, мы с радостью ответим вам в комментариях или по контактах которые предоставлены на efficiefy.io.

Мы будем рады любым замечаниям комментариям и интересу с вашей стороны.
Спасибо за внимание.

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному2
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

При чем тут «знания», если речь об анализе косвенных признаков, кто куда и как часто коммитил? И на основании этого, «вроде как», должен быть в теме... Не сказать что бы это бесполезная автоматизации, но это менеджмент компетенций, а не знаний.

Действительно, это можно называть компетенциями.
Проблема выбора термина здесь — ни одно слово идеально не подходит.

Менеджмент знаний — это верх абсурда бюрократии. Никто не спорит, бюрократия выглядит красиво и показательно. Но это параллельная вселенная, она не должна проникать в реальный мир во избежание отравления реальных процессов этой [плохое слово в 6 этажей]

Менеджмент — не всегда плохо ) Под менеджментом тут имеется ввиду управление распределением, избегание концентрации знаний одним человеком, упрощение процесса онбоардинга и т.д., т.е. ориентация на позитивные моменты, а не на желание кого-то угнетать.

избегание концентрации знаний одним человеком

Концентрация знаний толковыми спецами — как правило, вещь объективная T.к. всякими «управлениями» тянущего чела не клонируешь и его мозги коллегам не вставишь — соответственно, проблема не организационная, а в ином.

Представим себе ситуацию — на проекте 30 девелоперов + нное количество других специалистов. Один из девелоперов принимает решение покинуть проект — допустим он не супер ответственный плюс новая работа уже на горизонте. Как понять какие знания он должен передать? Как проконтроллировать эффективность передачи?
Я думаю, что знания должны передаваться регулярно между членами команды, а не тогда, когда кто-то уходит (навсегда, в отпуск, на больничный). Чтоб этот процесс был эффективным, нужно понимать, где есть какие гэпы(✌️). Т.е. возникает задача количественной оценки уровня знаний девелопера по бизнес/тех областям проекта. При чём этот уровень динамичен, области динамичны и специфичны для каждого проекта.
efficiefy выявляет области динамически; на основании диффов коммитов определяет кто, где, когда и сколько работал с какой областью и хранит эти исторические данные.
В итоге при пленнинге задач на спринт можно определять кому дать какую задачу (знания не должны концентрироваться у одного человека) и так же кто будет соотв ментором/ревьювером по этой задаче.
Если кто-то покинет проект, то всегда будет готовая ему замена — соответственно меньше стресса для членов команды и профит для бизнеса.

На практике, из этих 30:

— 2-3, максимум 5 — будут квалифицированными и способными тянуть (у них будут сосредотачиваться знания)
— ещё 5-10 будут средненькими, с какими-то опытом, каким-то рабочим временем (типа, 4 часа/день), с какой-то активностью/инициативностью. Их можно чему-то научить — но инициативы в процессе они проявлять не будут, изученное быстро и успешно забудут
— остальные — бесполезный балласт, по многим измерениям (неспособность в причинно-следственные, патологическая лень, итп)

«топ-категорию» незачем особо учить — т.к. они научатся сами, если будет нужно. Для них достаточно кода и спеки.
«средних» можно учить, но «топов» они заменить не смогут
«балласт» учить — только время тратить

В общем, с передачей знаний — как правило, проблема не в организации, а в людях.

Я бы сказал, что топ девелоперов в среднем около 5-10% на проекте, ещё 5-10% — баласт. Если первые не требуют внимания, то от вторых с течением времени нужно избавляться. Остальные 80-90% — это те, с кем нужно работать каждый день, мотивируюя, обучая, напрягая. А для этого нужны средства.

Не менеджмент плохо, а бюрократия. Здесь дело в полном непонимании что такое знания, как они формируются, как их вообще оценивать, и как применять на практике.

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

Вы вместо этого ХОТИТЕ чтобы законы реального мира менялись под ваши хотелки (задним числом, разумеется, лучше прямо в ДНК динозавров). И ломаете всё, что не соответствует вашему видению.

var reallyUsableConstant = yetAnotherConstant + 716;
Внимание вопрос: как осуществить менеджмент знаний данной строчки кода? А как его осуществит предложенный супер-софт.

Если в моей компании используется локальный гит-репозиторий, который не хотелось бы выкладывать на Github — будет ли возможность воспользоваться вашим сервисом? И если да, то когда?

Добрый день, пока такой возможности нет. Так как мы ориентировались на широкоизветсный github.

Выглядит неплохо, удачи в проекте! Кстати можно ещё посмотреть Котлин, у них есть полноценная поддержка Spring и можно частично переносить части функционала, или писать новые на Котлин, где много интересных фишек, по типу null-safety или data classes.

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

Підписатись на коментарі