Встреча 2 (17 III)

Команда предоставила ссылку на беклог, сформированный в результате митинга 13 марта.

Планирование архитектуры упёрлось в отсутствие чёткого понимания о том, для какой цели введены группы. На митинг 12-го числа, команда предположила, что группа может создаваться под какую-то задачу (проект), и иметь некоторый бюджет. Бюджет будет пополняться администратором, и в рамках этого бюджета группа может осуществлять свою финансовую деятельность. Заказчик настоял, что речь идёт только о компенсации, не о накопительном счёте, и все покупки должны "валиться в кучу".

Заказчик предложил зафиксировать два параметра:

1. Максимальный долг менеджера - та сумма, по достижении которой всеми участниками группы новые покупки не могут быть зарегистрированы.
2. Лимит участника - сколько максимум может купить один человек.

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

Таким образом мы пришли к тому, что нужно чётко определить, для чего существуют группы, какие задачи они решают (не может быть инструмента ради инструмента, инструмент должен выбираться и подстраиваться в связи с какой-то задачей). Команда выдвинула следующие соображения по этому поводу:

1. Группа - это собрание людей, которые хотят какой-то активности. Собирается группа, из X человек, и падает администрации пожелание "хотим новую мебель". Или такая-же группа, которая хочет шашлык. Или канцтовары. Или ещё что-то. Администрация решает, какие из этих заявок удовлетворить, и на сколько (к примеру, канцтовары надо всем купить, это логично, а шашлык можно оплатить на 50%). Остальные траты участники делят между собой, если решат осуществлять проект.
2. Группы создаёт только главный админ, строго определяет менеджера и бюджет. Менеджер набирает себе людей и они как-то тратят деньги в рамках своего бюджета.
3. группа жестко привязана к организационной структуре компании, а пользователь имеет лимиты по всем группам, в которых он состоит. Также есть лимиты по отделам.

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

1. Отражают фактическое распределение расходов на сотрудников. Если покупает пеньки кто-то один, записывают расход на отдел из 10 человек, а едят двое - это не отражает реального положения вещей.
2. Упрощают расчет сотрудников.

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

При таком подходе, группа - это набор людей, и её не надо хранить как постоянную сущность, а покупка не является причиной её (группы) образования. От потратившегося сотрудника просто требуется указать набор сотрудников, на которых будут распределены траты (дополнительно можно думать о том, какие границы приватности у покупки, может ли сотрудник апрувть/реджектить свой участие в трате, можно ли вести какое-то обсуждение траты и как эту трату занести в несколько категорий). Для удобства, можно определить какое-то количество предустановленных наборов людей (вся фирма, весь отдел, сотрудники какого-то проекта) а также хранить последние 10 использованных наборов.

Для построения различных вариантов статистики, этот подход даёт все возможности! Можно учитывать даже переходы сотрудников из отдела в отдел, отпуска и прочее.

Организационную структуру можно брать из LDAP (надо посмотреть python-ldap) или в MS AD. Если не получится, придётся сделать ещё свою простую систему управления кадрами.

Следующая встреча ориентировочно намечена на четверг.