Что это за дичь?
Этот инструмент должен дать нам полное представление о том, когда, скорее всего, произойдет релиз (на основании уже сделанных ошибок прогнозов). По мотивам статьи от Джоэла Спольски Доказательное планирование:
Система решает проблему ненадежной оценки времени выполнения задач, отслеживая фактическое время выполнения по сравнению с первоначальными оценками. Для каждого сотрудника она строит статистическую модель точности его оценки для задач различной сложности, создавая три сценария прогнозирования:
Первоначальная оценка сотрудника
Скорректированное по вероятности на основе исторической точности
Пессимистический сценарий на основе исторических максимумов
Алгоритм прогнозирования анализирует аналогичные выполненные задачи (отфильтрованные по рейтингу сложности от 1 до 5) и вычисляет вероятностные распределения соотношений оценки к фактическому времени. Это позволяет построить доверительную кривую, показывающую вероятность завершения в различные будущие даты.
Тип TJob представляет собой основную единицу работы в системе. Он объединяет метаданные задач, информацию о прогнозировании, журналы активности, этапы дорожной карты и иерархические связи.
Система предоставляет хронологическую запись работы, выполненной над заданиями, посредством структурированных записей в журнале, которые могут содержать текст, показатели прогресса, контрольные списки и внешние ссылки. Хронологическая шкала активности объединяет журналы по всем заданиям, обеспечивая единое представление о недавней работе.
Контрольные списки обеспечивают структурированное отслеживание задач, позволяя пользователям разбивать записи в журнале на отдельные, выполнимые элементы с возможностью отслеживания завершения и упорядочивания.
Должности могут быть связаны между собой, образуя иерархические структуры, где родительские должности представляют собой проекты, содержащие дочерние должности в качестве подзадач.
Задания назначаются сотрудникам через структуру TForecast, встроенную в каждое задание.
1 до 5 (либо возьмите таймаут и вернитесь к этому вопросу позже);Есть пара важных моментов!
06Задачи с такими оценками не будут учитываться при анализе для пронозов обычных задач
Система управления рабочим временем предоставляет пользовательский интерфейс для определения и управления пользовательскими еженедельными графиками работы, хранящимися в локальном хранилище браузера (localStorage). Эти конфигурации определяют, какие часы считаются «рабочим временем» для каждого дня недели, что позволяет проводить аналитику на основе времени и прогнозные расчеты. Система поддерживает несколько именованных конфигураций с полным набором операций CRUD, проверкой и редактированием.
Страница «Настройка рабочего времени» позволяет пользователям создавать, редактировать и управлять несколькими шаблонами недельного расписания. Каждая конфигурация задает рабочие часы для каждого дня недели в формате HH:MM:SS, поддерживая несколько временных диапазонов в день (например, сменная работа). Система проверяет все введенные данные о времени и сохраняет конфигурации в localStorage для использования в разных сессиях.
Это настройка для следующих целей:
_descr является опинальным);Ожидается следующий формат для описания распорядка дня:
start - время начала рабочего промежутка;end - время окончания рабочего промежутка;_descr - комментарий (Здесь я пишу причину почему я вынужден отвлечься в конце промежутка, это будет использоваться для наглядности при анализе эффективности);Этот режим я назвал MainsGroup (чисто код) - в целом, это рабочее время, исключая плановые созвоны.
Также советую создать отдельные такие графики на случаи посиделок в выходные (овертаймы), если это имеет место.
{
"sunday": null,
"monday": [
{
"start": "09:50:00",
"end": "11:30:00",
"_descr": "далее перерыв 30min"
},
{
"start": "12:00:00",
"end": "13:30:00",
"_descr": "далее перерыв 30min -> Созвон Ретро 14-15:00 -> перерыв 30min"
},
{
"start": "15:30:00",
"end": "16:45:00",
"_descr": "далее перерыв 15min"
},
{
"start": "17:00:00",
"end": "18:00:00",
"_descr": "затем перерыв 30min -> конец дня"
}
],
"tuesday": [
{
"start": "09:50:00",
"end": "11:30:00",
"_descr": "далее перерыв 30min"
},
{
"start": "12:00:00",
"end": "13:45:00",
"_descr": "далее перерыв 15min"
},
{
"start": "14:00:00",
"end": "14:45:00",
"_descr": "работать между перерывом и созвоном нет смысла - поэтому 45мин не учитываю как рабочее время, далее перерыв 15min -> 15-15:30 созвон 0.5-1h -> обед 0.5h"
},
{
"start": "16:00:00",
"end": "18:00:00",
"_descr": "затем перерыв 30min -> конец дня"
}
],
"wednesday": [
{
"start": "09:50:00",
"end": "11:40:00",
"_descr": "далее перерыв 20min -> 12:00 созвон 0.5h -> перерыв 30min до 13 (первая часть обеда)"
},
{
"start": "13:01:00",
"end": "14:45:00",
"_descr": "далее перерыв 15min -> 15-15:30 созвон 0.5-1h -> обед 0.5h"
},
{
"start": "16:00:00",
"end": "18:00:00",
"_descr": "затем перерыв 30min -> конец дня"
}
],
"thursday": [
{
"start": "09:50:00",
"end": "11:45:00",
"_descr": "далее перерыв 15min -> 12:00-13:00 созвон 1h+ -> обед 1h- до 14"
},
{
"start": "14:00:00",
"end": "14:45:00",
"_descr": "между созвонами работать смысла нет, 45мин пропадает -> далее перерыв 15min -> 15-15:30 созвон 0.5h+ -> перерыв 0.5h- до 16"
},
{
"start": "16:00:00",
"end": "18:00:00",
"_descr": "затем перерыв 30min -> конец дня"
}
],
"friday": [
{
"start": "09:45:00",
"end": "11:30:00",
"_descr": "Ретро передвинули на понедельник в 14:00, так что в этот день можно нормально работать"
},
{
"start": "12:00:00",
"end": "13:45:00"
},
{
"start": "14:00:00",
"end": "14:45:00",
"_descr": "Далее перерыв 15min -> 15-15:30 созвон 0.5h+ -> перерыв или обед 0.5h- до 16"
},
{
"start": "16:00:00",
"end": "18:00:00",
"_descr": "затем перерыв 30min и конец дня"
}
],
"saturday": null
}Что это дает? По сути это ориентир по расходу времени (если смотреть с ракурса оценки конкретной задачи). Это может быть использовано для ML для получения альтернативного расчета.
Абсолютное и вычисленное рабочее время одной из задач для двух рабочих графиков: 5/2 by Default и MainsGroup (чисто код)
{
"estimated": {
"items": [
"Absolute: 25d 2h",
"BT \"5/2 by Default\": 114.8h",
"BT \"MainsGroup (чисто код)\": 97.8h"
]
},
"realistic": {
"items": [
"Absolute: 6d 10h",
"BT \"5/2 by Default\": 29.6h",
"BT \"MainsGroup (чисто код)\": 23.8h"
]
}
}Исходя из того, что промежутки между прерываниями 45 минут и менее приняты как критически непродуктивными 👉 их не учитывать их смысла особо не вижу, т.к. планировать решение сложных задач становится невозможным, таким образом по большому счету расчитывать на это время не приходится.
Вы можете создать несколько рабочих графиков и сравнить эффективность рабочего процесса внутри разных компаний. На своем опыте, могу сказать, при небольших различиях в первом приближении стратегически разница довольно существенна.
Результат анализа - это набор графиков для сравнения разных режимов работы.
Заложены следующие правила:
Об этом писали на хабре:
Переключение между контекстами убивает эффективность разработчиков на корню
Из интересного (только то, что показалось интересным лично мне):
🔒 Выделяйте время для сосредоточенной работы. Установите полуторачасовые интервалы для сосредоточенной работы по методике, описанной в книге Кэла Ньюпорта «В работу с головой». Это оптимальное время для сохранения стабильной концентрации внимания. При этом нужно организовать минимум 4–6 часов сосредоточенной работы. Отметьте эти блоки у себя в календаре и для их выполнения выберите время дня, когда вы на пике энергии. Для большинства людей это — утро.
🚧 Оставляйте себе «хлебные крошки» на случай, если вас отвлекут. Когда вы занимаетесь сложной задачей, оставляйте себе подсказки. Если вас отвлекли, лаконичный комментарий о том, почему в файле с исходным кодом в IDE вы написали именно эту строчку, сэкономит вам несколько часов, которые ушли бы на восстановление вашего хода мысли. Этим же приёмом можно пользоваться в конце дня. Тогда завтра вы точно будете знать, с чего продолжить. А ещё это помогает бороться с эффектом Зейгарник — стремлением заполнять рабочую память незавершёнными задачами.
🔕 Минимизируйте отвлекающие факторы. Ка�� вариант, наденьте шумоподавляющие наушники, отключите неважные уведомления или создайте изолированное рабочее пространство. Отличный вариант — выключать на какое-то время мессенджеры и включать на телефоне режим «Не беспокоить».
🤹 Откажитесь от многозадачности. Наш мозг может корректно и сосредоточенно работать только над одной задачей. Так что берите в работу что-то одно.
💺 Продумайте эргономику. Обзаведитесь эргономичным столом и стулом, настройте монитор, чтобы сократить физический дискомфорт.
📂 Организуйте пространство. Не загромождённое рабочее пространство снижает когнитивную нагрузку и помогает сосредоточиться на задаче.
🤔 Взаимодействуйте, если это действительно нужно. Если вы работаете в офисе, где высоко ценят открытость и доступность, проанализируйте свою готовность к взаимодействию с окружающими. Как пишут авторы книги «Алгоритмы для жизни»: «Взаимодействуйте только в той мере, в какой это для вас комфортно».
🗓 Планируйте день стратегически. В конце рабочего дня подведите итоги и запланируйте задачи на следующий день. Или, наоборот, начинайте каждый день с планирования. Это помогает начать день продуктивно.
🙅 Легализуйте возможность говорить «нет». Организуйте работу так, чтобы сотрудники не стеснялись говорить «нет», когда они перегружены. Благодарите их за то, что они делятся плохими новостями — тем самым, предотвращают усугубление ситуации.
🤝 Сделайте совещания содержательными (да, так тоже бывает). Разрешите сотрудникам не приходить на встречи, которые посвящены непонятно чему, или на которых им быть необязательно. Из-за такого подхода организаторам совещаний придётся уважать чужое время, предоставив коллегам возможность заниматься действительно важными делами. Планируйте совещания в часы, примыкающие к перерывам: до или после обеденного времени, в начале или в конце рабочего дня.
Началось все с того, что я начал испытывать отвращение к чуть более сложным задачам. С какого-то момента осознал это и начал рефлексировать. Выяснил, что меня отвлекают примерно раз в час (в среднем. т.е. это может быть и 2 раза за час и раз в три часа). А вот подсознательно, мозг понимает, что нет смысла копать в глубокий контекст, потому что сейчас звоночек и все рассыпется, как карточный домик, поэтому будем экономить энергию. Как решение - стал ставить себе кирпич, а корпоративные источники связи проверять, когда сам поставил себе перерыв. Попробуйте, это реально увеличивает продуктивность и снижает стресс.
Есть визуализация Productivity Analysis. Для того, чтоб конкретный рабочий график отобразился там - нужно в разделе настроек Business Time для этого графика в нижней секции добавить следующий json:
{
"_diagrams": [
"common",
"SimpleRadialBarChart"
]
}WIP
Сюда скоро подъедут скрины...
Это набор статусов для визуализации Roadmap в рамках конкретной задачи (в одной задаче может быть только один Roadmap). Набор статусов в каждой компании свой, поэтому я сделал его конфигурируемым - сама настройка хранится на устройстве в Local Storage.
Create (это будет отдельный списочек)Active namespace{
"pointStatusList": {
"no-status": {
"label": "",
"emoji": ""
},
"business": {
"label": "На согласованиях бизнеса",
"emoji": "🟡"
},
"designer": {
"label": "В работе у дизайнера",
"emoji": "🟡"
},
"paused": {
"label": "На паузе",
"emoji": "⏸️"
},
"qn:front": {
"label": "Есть вопрос от фронта",
"emoji": "❓"
},
"rework": {
"label": "На доработке",
"emoji": "🔵"
},
"dead": {
"label": "Мертвая задача",
"emoji": "💀"
},
"dev:front": {
"label": "Фронт: В разработке",
"emoji": "🔥"
},
"dev:back": {
"label": "Бэк: В разработке",
"emoji": "🟡"
},
"dev:ofr-core": {
"label": "Проблема на стороне команды Ядра ОФР",
"emoji": "⛔️"
},
"test:ready": {
"label": "Готово к тестированию",
"emoji": "🟢"
},
"devops:mg": {
"label": "DevOps инжиниринг на нашей стороне",
"emoji": "🟡"
},
"devops:rgs": {
"label": "DevOps инжиниринг на стороне заказчика",
"emoji": "⛔️"
},
"test:mg": {
"label": "Тестирование на нашей стороне",
"emoji": "▶️"
},
"test:rgs": {
"label": "Тестирование на стороне заказчика",
"emoji": "⏳"
},
"prod": {
"label": "На проде",
"emoji": "🏁"
}
}
}Анализ от DeepWiki
На основе анализа кодовой базы проект демонстрирует несколько архитектурных шаблонов и оптимизаций, ориентированных на масштабируемость.
Проект реализует масштабируемость на стороне клиента с помощью веб-воркеров для параллельной обработки, систем пагинации для больших наборов данных и оптимизированных конфигураций сборки с разделением на фрагменты. Он разработан как однопользовательское приложение с оптимизацией производительности для обработки сложных прогнозных вычислений и больших наборов данных заданий.
Параллельная обработка с помощью веб-воркеров Приложение использует несколько выделенных веб-воркеров для разгрузки ресурсоемких вычислений от основного потока:
withRootMW.js:129-160types.js:99-107types.js:117-125types.js:72-80withRootMW.js:143-150withRootMW.js:151-160calc.v4.js:73-89Конфигурация Vite реализует несколько оптимизаций производительности:
useSearchBasicWorker.ts:1-35Архитектура оптимизирована для производительности на стороне клиента для одного пользователя, а не для масштабируемости сервера для нескольких пользователей. Система обеспечивает масштабируемость за счет:
Проект, по всей видимости, разработан как настольное/веб-приложение для отдельных руководителей групп или менеджеров проектов, а не как многопользовательская SaaS-платформа. Основное внимание в масштабируемости уделяется обработке больших наборов данных и сложных вычислений в рамках ограничений браузера, а не масштабированию для одновременной работы нескольких пользователей.