## What need to be done?
Need to create a mechanism that allows obtaining an adjusted forecast for the completion of a particular task based on an analysis of deviations in forecasting similar tasks.

This web app created for have reasonable correction of employee estimation.

The calc based on previous experience of the employee. See also about [Evidence Based Scheduling by Joel Spolsky](https://www.joelonsoftware.com/2007/10/26/evidence-based-scheduling/).

Discuss [here](https://t.me/bash_exp_ru/607)

## Goals
- Intuitive UI
- Useful UX
- Scalable DX (clean code)

<ControlsBox
  controlsJson='[
    {
      "title": "PREV",
      "label": "Joel Spolsky // Evidence Based Scheduling (2007)",
      "type": "link",
      "link": "https://www.joelonsoftware.com/2007/10/26/evidence-based-scheduling/"
    },
    {
      "title": "END_NEW_TAB",
      "label": "Life Demo (English version 2024)",
      "type": "link",
      "link": "https://pravosleva.pro/dist.estimate-corrector-2024/"
    }
  ]'
/>

About Estimate Corrector (2024) #EBS // Probability Theory in action (ENG)

Ссылка на оригинал статьи с объяснением принципа Доказательного Планирования (в оригинале Evidence Based Scheduling - далее будет фигурировать как EBS)
- Joel Spolsky [Evidence Based Scheduling](https://www.joelonsoftware.com/2007/10/26/evidence-based-scheduling/)
- [Перевод на русский](https://habr.com/ru/articles/186410/)

## Суть проблемы планирования

Из опыта работы в "Кровавом Enterprise" плечом к плечу с Менеджером Продукта, перед поступлением очередной задачи в работу, у меня интересовались, сколько на нее уйдет времени (внезапно). Такая оценка должна затрагивать все возможные факторы "торможения", к примеру:
- Неоднократное выяснение деталей до того момента, как задача станет "прозрачной"
- Перерывы в работе по разным причинам
- Фактор непредсказуемости изменений ТЗ (добавление требований в процессе разработки фичи)

Да, слишком абстрактно, и эти пункты можно детализировать на много факторов, но сама проблема свелась к учету их всех неявным образом. Условно, будем считать, что проблема локализована (Вы удивитесь, но детали, действительно не так важны).

## Каким я вижу решение
Чтобы получить прогноз для конкретной задачи по срокам, достаточно иметь статистику по аналогичным задачам, каждая из которых должна иметь четыре параметра:
1. Дату старта исполнителем;
2. Дату прогноза от исполнителя;
3. Дату фактического ее завершения (которую потом ~~можно~~ **нужно** двигать по мере доработки задачи);
4. Грейд задачи (сложность фичи по мнению исполнителя) - также может повышаться по мере разработки. Есть категория задач, в процессе реализации которых происходит рост сложности в связи с добавлением требований со стороны бизнеса. Таким образом, любая задача может перейти в категорию более сложных и ее прогноз при этом будет скорректирован.

### Шаг 1: Два вопроса при постановке
- Какова сложность фичи по шкале от 1 до 5?
- Сколько времени тебе нужно на ее выполнение?

### Шаг 2: Контроль дат
Далее следует вопрос самоконтроля эффективного менеджера - зафиксировать даты старта и фактического завершения этой задачи (это важно!). С момента завершения первой задачи, можно предсказывать будущее, с учетом ошибок разработчика, основываясь на предыдущем опыте работы с ним: Чем больше задач набирается в опыт, тем точнее прогноз.

<Alert
type='warning'
header='Да, кстати, важный момент!'
text='Прогноз исполнителя НЕ должен основываться на аналитически расчитаных значениях. Оценить должен именно исполнитель - именно его прогнозы имеют ценность для анализа.'
/>

### Шаг 3: Результат анализа
> Следствие - всегда результат принятых решений (из фильма "Разрабы")
А теперь посмотрим, что мы имеем:
- Предполагаемая дата лучшего сценария (обычно, мало кого интересует)
- Предполагаемая дата "среднего по больнице" сценария (наиболее бесполезный, кмк - см. спойлер ниже)
- ⚡ **Предполагаемая дата худшего сценария** - самая ценная информация при стратегическом планировании сроков фичи (*)

**(*) Поправка в 2024: периодически возвращаясь к интересной задаче, пришел к выводу, что это не совсем верный подход (см. спойлер ниже)**

<CollapsibleBox
header="Спойлер: Обновления 2024"
text="В версии 2024 появится новая характеристика - **Наиболее вероятный сценарий**. То есть, теперь разработан расчет более точного прогноза. Значение ожидаемой даты рассчитывается как среднее между аналогичными случаями, но только теми, **значения разниц скоростей которых минимальны**: Отсортируйте скорости выполнения задач аналогичной сложности и оставьте только те, где дельта отклонения друг от друга равна (либо чуть больше) минимальному из них"
/>

## Инструкция и [Демо](https://pravosleva.pro/team-scoring/legacy)

Хотел бы собрать обратную связь насчет работы демо версии - мнение можно оставить [здесь](https://t.me/bash_exp_ru/415).

Пару слов о том, как я использую этот инструмент в своей работе:

1. **Создаю новую таску, назначенную на исполнителя, который оценивает ее навскидку**:
- а) субъективная оценка сложности от 1 до 5 - возможно, эту оценку можно скорректировать по факту выполнения задачи (думаю, по итогам ретроспективы в момент завершения таски - самое время);
- б) субъективный срок выполнения;
- в) фиксирую дату старта выполнения - она должна соответствовать факту старта;

2. **⚡ Если *такая* задача не первая! Получаю прогноз по методике EBS на самый худший вариант развития** - ~~это тот самый срок, который следует озвучить Продукт Менеджеру~~ (в обновленной версии все иначе, см. обновления в конце);

3. **Фиксирую фактическую дату завершения задачи** - это именно тот параметр, который следует скорректировать в случае, если задача потребовала доработки для более точной статистики и, как следствие, более точной оценки последующих задач.

*При наличии статистики, перед постановкой задачи можно прикинуть, насколько "обманет" испытуемый исполнитель:*

![img](https://pravosleva.pro/express-helper/chat/storage/uploads/team-scoring-2019/1698044852385.png)

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

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

*Продолжение следует...*

<ControlsBox
  controlsJson='[
    {
      "title": "PREV",
      "label": "Joel Spolsky // Evidence Based Scheduling (2007)",
      "type": "link",
      "link": "https://www.joelonsoftware.com/2007/10/26/evidence-based-scheduling/"
    },
    {
      "title": "END_DEMO",
      "label": "Живой пример (русскоязычная версия 2019)",
      "type": "link",
      "link": "/team-scoring/legacy"
    }
  ]'
/>

## 🚀 Обновления 2024

### Более удачный UX
- **Estimated** (заявленный сценарий) - прогрессбар доходит до 100%, дата заявлена исполнителем (никакой магии);
- **The Worst** (худший сценарий) - значение ожидаемой даты основано на той задаче, которая была завершена исполнителем с минимальной скоростью;
- 💥 **Sensed** ("ощущаемый") - это новый прогрессбар, значение даты, соответствующей 100% рассчитано как среднее между теми сценариями, скорости выполнения которых отличаются не слишком сильно (в него НЕ входят те задачи, которые завершены исполнителем аномально быстро или аномально медленно). Логика простая: Человек работает, как правило, [плюс-минус] с одной скоростью - алгоритм должен ее "ощутить". Как именно: если среди возможных вариантов скоростей его работы встречаются два с минимальным отклонением - это повод искать ещё варианты с примерно таким же отклонением. В итоге, найденные варианты образуют "скопления", среднее значение которых можно учитывать как наиболее вероятное.

### Более удачный DX
- "Чем проще, тем лучше" - чисто клиентский билд для раздачи NGINX-ом. Как показала практика, простые проекты живут дольше, деплой проще и быстрее, инфраструктура без особых затрат
- Более современный стек технологий (за 5 лет кое-что изменилось)

### Более удачный UI
- За основу взят MUI v6.x

<ControlsBox
  controlsJson='[
    {
      "title": "END_DEMO",
      "label": "Estimate Corrector (English version 2024)",
      "type": "link",
      "link": "/p/estimate-corrector-2024"
    },
    {
      "title": "NEXT",
      "label": "Продолжение на Хабре (2024)",
      "type": "link",
      "link": "https://habr.com/ru/articles/874226/"
    }
  ]'
/>

Теория Вероятностей в действии (2019) // Методика #EBS #рабочие_моменты

```js
import {useEffect, useState} from "react";

export const useWebSockets = () => {
    const [state, setState] = useState([]);

    useEffect(() => {
        const ws = new WebSocket("ws://localhost:8889");

        ws.onopen = () => {
            console.log("open");
        };

        ws.onclose = () => {
            console.log("closed");
        };

        ws.onmessage = (msg) => {
            const dataMsg = JSON.parse(msg.data)
            if (dataMsg.hasOwnProperty('tick')) {
                setState((prev)=> [...prev, dataMsg.tick])
            }
            return null
        };

        return () => {
            ws.close();
        };
    }, []);

    return state
}
```

#reactHook | useWebSockets

https://www.youtube.com/watch?v=LMagNcngvcU

2021.11 Build and Deploy a Fully Responsive Modern UI/UX Website in React JS

https://www.youtube.com/watch?v=bSMZgXzC9AA

EBS

About Estimate Corrector (2024) #EBS // Probability Theory in action (ENG)

Теория Вероятностей в действии (2019) // Методика #EBS #рабочие_моменты

#reactHook | useWebSockets

2021.11 Build and Deploy a Fully Responsive Modern UI/UX Website in React JS

#portfolio #front | How to build a portfolio website using Next.js, Chakra UI, Framer Motion, and Three.js

#nginx as a WebSocket Proxy