Система постановки и ведения целей с согласованием выполнения

Задача

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

Что сделано

• Иерархия из четырёх типов сущностей: сфера, проект, цель, задача — со своими правилами для каждого уровня
• Четыре роли: владелец, исполнитель, наблюдатель, согласующий
• Пять статусов и переходы между ними, включая отдельную ветку для задачи, назначенной другому человеку
• Согласование выполнения: несколько согласующих с раздельными решениями и обязательным комментарием
• Дедлайны с наследованием от родителя и правилом, когда срок ещё можно менять, а когда он уже заморожен
• Календарь и мобильный контур: вход по телефону, работа с узкого экрана
• Матрица прав на экране сущности: что доступно каждой роли в каждом статусе

Внутри системы

• Видимость не каскадирует по дереву: роль на родителе не даёт доступа ко всем дочерним сущностям. Это противоречит интуиции, но иначе наблюдатель проекта автоматически получал бы доступ к личным задачам внутри него. Пользователь видит только то, где у него есть собственная роль, и удалённый из участников теряет доступ даже по прямой ссылке.
• Согласующих может быть несколько, и решение каждого учитывается отдельно: сущность не считается выполненной, пока каждый не принял решение, а состояние показывает, кто уже решил и кто ещё нет. Комментарий обязателен именно при выполнении с согласующими — при отмене и отклонении он остаётся на усмотрение автора.
• Дедлайн можно менять, пока к сущности не подключены наблюдатель или согласующий; после этого он становится доступным только для чтения. Иначе срок, на который согласился участник, задним числом переписывал бы автор — а именно на этом строится доверие к контуру.
• Выполнение родителя каскадом закрывает дерево, но требует одного комментария на всё дерево, а не на каждую задачу отдельно: иначе закрытие проекта из тридцати задач превращается в тридцать однотипных записей, которые никто не читает.

Как устроено

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

Результат

Продукт в промышленной эксплуатации с собственной проектной документацией и матрицей прав, описанной до разработки экранов.

Цифры

Типы сущностей

4: сфера, проект, цель, задача

Роли

4: владелец, исполнитель, наблюдатель, согласующий

Статусы

5 с переходами и отдельной веткой назначения