И так, пока продолжаю писать статью о том, "что же такое предсказуемость и как ее понять?”, в канале обсуждаем тему создания алгоритма для оценки задач.
Опрос, показал, что большинство проголосовало за вариант:
"Нулевая гипотеза верна, и алгоритм оценки таким методом нельзя сделать." Хотя другие варианты отстают не далеко.
Как же верно будет строить алгоритм?
Задачи изначально обладают какими-то характеристиками, описанием, приоритетом, автором, и т. д. и именно эти характеристики в большей степени влияют на категорию этой задачи.
Мода в Lead Time графике нам лишь говорит о том, что какая-то категория или категории за этот период закрываются чаще. Такое может быть, например, связано с рабочей неделей или спринтом.
Как и в этом случае.
Внимательные читатели заметили, что моды формируются по 5-дневным отрезкам.
И если, я, например, включу время только по рабочим дням, то мы получим график по форме близкой к распределению Вэйбула.
(Как показано на картинке)
По этому нулевая гипотеза: “Моды в частотной диаграмме Lead Time не являются признаком сложности решаемой задачи, и связаны с другими явлениями", как в этом случае, имеет большее обоснование для подтверждения.
А алгоритм прогнозирования надо строить относительно входящих характеристик, на Lead Time же стоит проверять фактический результат по времени решения:
1. Определяем характеристики задач по которым выбираем категории. Например, описание, приоритет, автор
2. Выделив категории, строим отдельный график Lead Time.
3. Строим прогноз, если для новой задачи характеристики близки к категории N, то и время решения этой задачи будет соответствовать распределению для этой категории.
#мысливслух
#статья
Опрос, показал, что большинство проголосовало за вариант:
"Нулевая гипотеза верна, и алгоритм оценки таким методом нельзя сделать." Хотя другие варианты отстают не далеко.
Как же верно будет строить алгоритм?
Задачи изначально обладают какими-то характеристиками, описанием, приоритетом, автором, и т. д. и именно эти характеристики в большей степени влияют на категорию этой задачи.
Мода в Lead Time графике нам лишь говорит о том, что какая-то категория или категории за этот период закрываются чаще. Такое может быть, например, связано с рабочей неделей или спринтом.
Как и в этом случае.
Внимательные читатели заметили, что моды формируются по 5-дневным отрезкам.
И если, я, например, включу время только по рабочим дням, то мы получим график по форме близкой к распределению Вэйбула.
(Как показано на картинке)
По этому нулевая гипотеза: “Моды в частотной диаграмме Lead Time не являются признаком сложности решаемой задачи, и связаны с другими явлениями", как в этом случае, имеет большее обоснование для подтверждения.
А алгоритм прогнозирования надо строить относительно входящих характеристик, на Lead Time же стоит проверять фактический результат по времени решения:
1. Определяем характеристики задач по которым выбираем категории. Например, описание, приоритет, автор
2. Выделив категории, строим отдельный график Lead Time.
3. Строим прогноз, если для новой задачи характеристики близки к категории N, то и время решения этой задачи будет соответствовать распределению для этой категории.
#мысливслух
#статья
👍2
Я являюсь продюсером трека "Принятие управленческих решений на основании данных"
в конференции Flow Days. Эта конференция про опыт.
Возможно у тебя есть хороший Case о котором стоит рассказать.
Чтобы было проще поделится своим опытом у меня есть подсказка которую можно прочитать.
Если хочешь поделится подавай заявку
В подготовке доклада буду обязательно консультировать.
Видео о чем будет эта конференция
https://www.youtube.com/watch?v=3TMIeFODQJo
Подавай заявку, делись опытом!
Приходи на конференцию, пообщаемся и поделимся своим опытом и кейсами.
Будет полезно и тем кто делает доклад, и тем кто слушает
в конференции Flow Days. Эта конференция про опыт.
Возможно у тебя есть хороший Case о котором стоит рассказать.
Чтобы было проще поделится своим опытом у меня есть подсказка которую можно прочитать.
Если хочешь поделится подавай заявку
В подготовке доклада буду обязательно консультировать.
Видео о чем будет эта конференция
https://www.youtube.com/watch?v=3TMIeFODQJo
Подавай заявку, делись опытом!
Приходи на конференцию, пообщаемся и поделимся своим опытом и кейсами.
Будет полезно и тем кто делает доклад, и тем кто слушает
👍6
Подготовил статью про предсказуемость
Остается понять куда ее лучше разместить, на какой площадке.
Если у вас есть предложение, напишите в тред!
Спасибо
#мысливслух
Остается понять куда ее лучше разместить, на какой площадке.
Если у вас есть предложение, напишите в тред!
Спасибо
#мысливслух
👍6
“Что такое предсказуемость выполнения задач и как ее понять?”
Я решил выбрать в качестве площадки, для статьи про “предсйказуемость” будет kanbangude.ru.
Размещаю как и обещал 3 сентября.
Но, думаю, что кое-какие корректировки в статью еще буду вносить.
Так как один из моих читателей при первом прогоне сказал о том, что пока статья написана “сложновато”.
Попрошу и вас оценить ее
Ставьте
👍— если считаете, что статья хорошо раскрывает тему
🔥 — оказалась полезной
😱 — если статья все таки сложная, и ее стоит упростить
Спасибо!
#статья
Я решил выбрать в качестве площадки, для статьи про “предсйказуемость” будет kanbangude.ru.
Размещаю как и обещал 3 сентября.
Но, думаю, что кое-какие корректировки в статью еще буду вносить.
Так как один из моих читателей при первом прогоне сказал о том, что пока статья написана “сложновато”.
Попрошу и вас оценить ее
Ставьте
👍— если считаете, что статья хорошо раскрывает тему
🔥 — оказалась полезной
😱 — если статья все таки сложная, и ее стоит упростить
Спасибо!
#статья
👍5🔥3😱2
Перед тем как предложить свой ТОП-4 методик оценки задач давайте попробуем вместе ответить на вопрос для чего чаще всего используется оценка?
Выбирайте 3-и варианта:
Выбирайте 3-и варианта:
Anonymous Poll
72%
Ориентир к дате, чтобы планировать другие активности
26%
Инструмент для “мотивации” и “контроля”, не затягивать на долго
45%
Для выбора наиболее экономически выгодных задач
8%
Для само-утверждения менеджера
24%
Определения SLA-для связанных сервизных команд
60%
Построения Road Map сложных продуктов
При подготовке статьи и сбора совершенно разной информации, я столкнулся со следующей проблемой
Методик оценки существует большое количество, и каждая из них имеет как свою область применения, так и цель.
Давайте подкатом соберем варианты оценок которые нам будут важны для рассмотрения в нашем ТОП-е.
Приведу список разных методик которые вы могли использовать и применять на практике:
1. Оценка простая Story Points.
2. Оценка в Story Points с категоризацией типов работ
3. Оценка в человеко-часах
4. #NoEstimate
5. WSJF
6. RISE/ICE
7. Методика Карла Вигерса
8. MoSCoW-приоретизация
9. Кано-анализ для приоретизация
10. Risk Assessment Framework
11. Оценка основанная на статистике
12. Классы обслуживания Triage Table
И так задача: перечислить какие методики оценки нам интересны, не более 8-ми.
А статьей мы определим не только ТОП, но так же раскроем их область применения, как они работают и почему, в том числе и со стороны математики.
Подкатом, попробуйте указать какая методика из представленных мной интересна, или предложите свои.
#артефакты
Методик оценки существует большое количество, и каждая из них имеет как свою область применения, так и цель.
Давайте подкатом соберем варианты оценок которые нам будут важны для рассмотрения в нашем ТОП-е.
Приведу список разных методик которые вы могли использовать и применять на практике:
1. Оценка простая Story Points.
2. Оценка в Story Points с категоризацией типов работ
3. Оценка в человеко-часах
4. #NoEstimate
5. WSJF
6. RISE/ICE
7. Методика Карла Вигерса
8. MoSCoW-приоретизация
9. Кано-анализ для приоретизация
10. Risk Assessment Framework
11. Оценка основанная на статистике
12. Классы обслуживания Triage Table
И так задача: перечислить какие методики оценки нам интересны, не более 8-ми.
А статьей мы определим не только ТОП, но так же раскроем их область применения, как они работают и почему, в том числе и со стороны математики.
Подкатом, попробуйте указать какая методика из представленных мной интересна, или предложите свои.
#артефакты
15 сентября в пятницу пройдет
Конференция flowdays
https://flowdays.ru/#tickets
На которой будет несколько докладов в теме "принятие решений на основе метрик"
Где будут разобраны истории
- настройки бизнес процесса используя статистику с приростом результатов в 2-а раза
- метод анализа связей графа взаимодействия коллег и выявление точек роста улучшением коммуникации
- кейс когда компания выстроила все возможные сборы метрик, но они не помогли, пока не выявили ключевые
В общем о чем я?
Это наверное первая конфа, где можно взять билеты в "кредит"
#доклады
Конференция flowdays
https://flowdays.ru/#tickets
На которой будет несколько докладов в теме "принятие решений на основе метрик"
Где будут разобраны истории
- настройки бизнес процесса используя статистику с приростом результатов в 2-а раза
- метод анализа связей графа взаимодействия коллег и выявление точек роста улучшением коммуникации
- кейс когда компания выстроила все возможные сборы метрик, но они не помогли, пока не выявили ключевые
В общем о чем я?
Это наверное первая конфа, где можно взять билеты в "кредит"
#доклады
👍4
Многие меня знают как автора плагина к Chrome (Yandex Browser, ... Chromiun base) под названием Jira-Helper
Который используют, чтобы была возможность превратить JIRA в настоящий Tool для построения визуализации для Канбан-систем.
Этот плагин сейчас позволяет делать такие вещи как
- Personal WIP-лимты
- WIP-лимиты на несколько колонок
- WIP-лимиты на свимлайны
- WIP-лимиты на пересечение свималйна и колонок
- WIP-лимиты на значение полей в карточках, подсчитывающие количество карточек с этим значением, или количества таких значений в карточках
А так же в нем есть очень полезная функция SLA линия для Control Chart JIRA.
Сам плагин был создан, с надеждой на то, что скоро в JIRA смогут заметить и исправить свои недочеты.
Однако, шутка продлилась слишком долго.
И уже более 5500 пользователей с разных уголков планеты и разных компаний используют его как важное дополнение.
А так как он работает поверх JIRA, которая (особенно Cloud) меняется, то нужна помощь тем кто работает сейчас и на Cloud JIRA.
Если вы хотите присоеденится к проекту пишите в комьюнити плагина https://t.iss.one/jirahelper
Очень нужна помощь тех кто умеет в JS.
#проинструменты
Который используют, чтобы была возможность превратить JIRA в настоящий Tool для построения визуализации для Канбан-систем.
Этот плагин сейчас позволяет делать такие вещи как
- Personal WIP-лимты
- WIP-лимиты на несколько колонок
- WIP-лимиты на свимлайны
- WIP-лимиты на пересечение свималйна и колонок
- WIP-лимиты на значение полей в карточках, подсчитывающие количество карточек с этим значением, или количества таких значений в карточках
А так же в нем есть очень полезная функция SLA линия для Control Chart JIRA.
Сам плагин был создан, с надеждой на то, что скоро в JIRA смогут заметить и исправить свои недочеты.
Однако, шутка продлилась слишком долго.
И уже более 5500 пользователей с разных уголков планеты и разных компаний используют его как важное дополнение.
А так как он работает поверх JIRA, которая (особенно Cloud) меняется, то нужна помощь тем кто работает сейчас и на Cloud JIRA.
Если вы хотите присоеденится к проекту пишите в комьюнити плагина https://t.iss.one/jirahelper
#проинструменты
🔥19
Продолжаю работать над статьей.
Изначально казалось что стоит написать поверхностно и просто.
Но, за последнее время пообщался с разными Тимлидами, и узнал у них разные боли связанные с оценкой.
И местами показывал метод оценки который мы используем в одной из команд. У этой команды есть много заказчиков.
И есть встреча по пополнению, где все заинтересованные заказчики могут принять решение какие фичи стоит брать вперёд.
А команда для них возвращает правила того сколько возможно взять задач.
И вот это "сколько задач" строится на формуле того, сколько рисков на себе берет команда, и есть предел.
Сами риски суммируются и каждый имеет свой коэфициент влияния.
Какие же факторы риска используются?
FC - фактор постановки задачи от клиента
FT - фактор технических возможностей
FD - фактор зависимости
FE - фактор нового опыта
Каждый последующий фактор влияет на порядок меньше чем предыдущий.
Оценка же данная в этих факторах сразу возвращает обратную связь и заказчикампостанов и задачи был оценён как FC=XL, а у другой FC=S.
Сразу понятно, что риск с первой задачей выше, а значит если ее нужно брать в работу, то количество взятых обязательств будет меньше.
А сам заказчик сразу понимает, что именно постановка задачи требует доработки.
При этом мы не лишаем заказчиков возможности ставить задачи типа "сделай то не знаю что, но чтоб было хорошо", однако даём понять, что если он полностью перекладывает риски на команду, то эта задача может занять весь объем и имеет большую неопределенность в сроках выполнения.
Более подробно об этом хочу как раз изложить в статье.
#мысливслух
Изначально казалось что стоит написать поверхностно и просто.
Но, за последнее время пообщался с разными Тимлидами, и узнал у них разные боли связанные с оценкой.
И местами показывал метод оценки который мы используем в одной из команд. У этой команды есть много заказчиков.
И есть встреча по пополнению, где все заинтересованные заказчики могут принять решение какие фичи стоит брать вперёд.
А команда для них возвращает правила того сколько возможно взять задач.
И вот это "сколько задач" строится на формуле того, сколько рисков на себе берет команда, и есть предел.
Сами риски суммируются и каждый имеет свой коэфициент влияния.
Какие же факторы риска используются?
FC - фактор постановки задачи от клиента
FT - фактор технических возможностей
FD - фактор зависимости
FE - фактор нового опыта
Каждый последующий фактор влияет на порядок меньше чем предыдущий.
Оценка же данная в этих факторах сразу возвращает обратную связь и заказчикампостанов и задачи был оценён как FC=XL, а у другой FC=S.
Сразу понятно, что риск с первой задачей выше, а значит если ее нужно брать в работу, то количество взятых обязательств будет меньше.
А сам заказчик сразу понимает, что именно постановка задачи требует доработки.
При этом мы не лишаем заказчиков возможности ставить задачи типа "сделай то не знаю что, но чтоб было хорошо", однако даём понять, что если он полностью перекладывает риски на команду, то эта задача может занять весь объем и имеет большую неопределенность в сроках выполнения.
Более подробно об этом хочу как раз изложить в статье.
#мысливслух
👍10
Не успел подготовить статью к моменту начала отчетного периода.
По этому двигатся стал медленее.
Хотя в день пишу чуть ли не том "Войны и Мир".
#мысливслух
По этому двигатся стал медленее.
Хотя в день пишу чуть ли не том "Войны и Мир".
#мысливслух
👍4
Atlassian JIRA продолжает двигаться не туда.
Теряет свою иникальность превращаясь в Trello.
И при этом не может предложить новых решений по интерфейсам, и улучшению методов анализа работы.
#забавное
Теряет свою иникальность превращаясь в Trello.
И при этом не может предложить новых решений по интерфейсам, и улучшению методов анализа работы.
#забавное
💩1
Наверное, одна из лучших игр для старта в процессы — это featureban. Немного изменяя форму подачи, на основе нее можно показать достаточно много интересных фич о том как работает команда/сервис и как можно анализировать работу. Вчера проводил featureban на 25 человек, где удивительным образом, на очень простом способе моделирования, смогли посмотреть на то, что же такое время решения задачи. И как можно работать с ним.
Настоятельно рекомендую играть в featureban вживую за столом с коллегами, потому, что такой способ общения и глубокого осмысления не получить иным способом.
#интересное
Настоятельно рекомендую играть в featureban вживую за столом с коллегами, потому, что такой способ общения и глубокого осмысления не получить иным способом.
#интересное
👍15❤1💩1
Что чаще всего предлагают как “оценка задач” в интернете, не плохо собрали в этом видео:
✒ Timeline:
✔ 0:00 - Введение
✔ 0:47 - Принципы оценки в Agile
✔ 2:52 - T-Shirt Sizes
✔ 4:24 - Planning Poker
✔ 5:41 - Bucket System
✔ 6:56 - Dot-voting
✔ 7:57 - Maximum Size or Less
✔ 9:02 - Big/Small/Uncertain
✔ 10:05 - Ordering Rule
#артефакты
✒ Timeline:
✔ 0:00 - Введение
✔ 0:47 - Принципы оценки в Agile
✔ 2:52 - T-Shirt Sizes
✔ 4:24 - Planning Poker
✔ 5:41 - Bucket System
✔ 6:56 - Dot-voting
✔ 7:57 - Maximum Size or Less
✔ 9:02 - Big/Small/Uncertain
✔ 10:05 - Ordering Rule
#артефакты
👍3💩1
This media is not supported in your browser
VIEW IN TELEGRAM
Думаю, тут коллега сделал отличную работу, когда авторски перевел книгу
https://sdu2020.blogspot.com/2018/10/01.html?m=1
#артефакты
https://sdu2020.blogspot.com/2018/10/01.html?m=1
#артефакты
Blogspot
The Principles of Product Development Flow: Second Generation Lean Product Development
Только 15% разработчиков продуктов знают стоимость задержки своих проектов. Чтобы делать экономически обоснованные выборы, нужно понимать связь между прокси-переменными и прибылью на жизненном цикле.
Возможные решения этих проблем:
1. Экономика
2.…
Возможные решения этих проблем:
1. Экономика
2.…
👍13🔥3💩1
Вернулся к статье про оценки, решил все таки ее разбить на несколько, будет 2-е или три.
Почему получается такой объем?
Первая проблема связана с тем как большенство людей воспринимает суждения.
Для объяснения и разговора про оценки, нужно сначала определить несколько тезисов и ввести в обсуждение термины.
Дальше на основе этого расскрыть тезисы о том, что оценка задач это не просто действие с гаданием, а целый процесс, в который включает в себя создание сбалансированной системы создания ценности.
Далее нужно привести общие инстурменты достижения баланса в системе, в которой возможна оценка задач.
И, потом привести пример, с исследованием который проводил с командой на личном опыте.
Получается достаточно объемный материал. К нему приходилось подходить несколько раз и переделывать, чтобы упростить вопсриятие. Много людей выражают мнение о моем сложном изложении материала, работаю над собой.
А тут вам приведу список полезных ссылок которые использовал при создании статей:
* Книга “Real-World Kanban: Do Less, Accomplish More with Lean Thinking”, Mattias Skarin
* Книга “Forecasting and Simulating Software Development Projects: Effective Modeling of Kanban & Scrum Projects using Monte-carlo Simulation“, Troy Magennis
* Книга “Думай медленно решай быстро”, Даниэль Канеман
* Книга, “Agile. Оценка и планирование проектов”, Mike Cohn, не рекомендую
* Книга, “Scrumban [R]Evolution, The: Getting the Most Out of Agile, Scrum, and Lean Kanban (Agile Software Development Series)”, Ajay Reddy
* Книга, “Cynefin - Weaving Sense-Making into the Fabric of Our World”, David Snowden
* Книга, “Actionable Agile Metrics for Predictability: An Introduction”, Daniel S. Vacanti
* Книга, “Essential Upstream”, Patrick Steyaert
* Книга, “Одураченные случайностью. О скрытой роли шанса в бизнесе и в жизни”, Нассим Николас Талеб
* Книга, “Черный лебедь.”, Нассим Николас Талеб
* Презентация, “Probabilistic Planning”, Дмитрий Бакарджиев
* Статья, “Story Points Revisited”, Ron Jeffries
* Статья, “Что такое предсказуемость выполнения задач и как ее понять?”, Павел Ахметчанов
* Статья, “Как работает метод Монте-Карло”, Павел Ахметчанов
* Статья, “Время в процессе: что мы реально о нём знаем?”, Alexei Zheglov перевод Артур Нек.
* Статья, “Анализ диаграммы распределения времени выполнения заказа”, Alexei Zheglov перевод Артур Нек.
* Игра, “No Estimate”, интерпретация от Евгения Степченко
* Видео, “О WIP-лимитах. Что такое WIP-лимит, как он работает и на что влияет”, Алексей Пименов
* Видео, “Capacity Allocation — как совмещать разработку продукта, поддержку, выплачивать техдолг”, Алексей Пименов
* Видео, “Работа с узкими звеньями процесса”, Алексей Пименов
* Видео, “Как прогнозировать время выполнения задач? Методики прогноза”, Павел Ахметчанов
#артефакты
Почему получается такой объем?
Первая проблема связана с тем как большенство людей воспринимает суждения.
Для объяснения и разговора про оценки, нужно сначала определить несколько тезисов и ввести в обсуждение термины.
Дальше на основе этого расскрыть тезисы о том, что оценка задач это не просто действие с гаданием, а целый процесс, в который включает в себя создание сбалансированной системы создания ценности.
Далее нужно привести общие инстурменты достижения баланса в системе, в которой возможна оценка задач.
И, потом привести пример, с исследованием который проводил с командой на личном опыте.
Получается достаточно объемный материал. К нему приходилось подходить несколько раз и переделывать, чтобы упростить вопсриятие. Много людей выражают мнение о моем сложном изложении материала, работаю над собой.
А тут вам приведу список полезных ссылок которые использовал при создании статей:
* Книга “Real-World Kanban: Do Less, Accomplish More with Lean Thinking”, Mattias Skarin
* Книга “Forecasting and Simulating Software Development Projects: Effective Modeling of Kanban & Scrum Projects using Monte-carlo Simulation“, Troy Magennis
* Книга “Думай медленно решай быстро”, Даниэль Канеман
* Книга, “Agile. Оценка и планирование проектов”, Mike Cohn, не рекомендую
* Книга, “Scrumban [R]Evolution, The: Getting the Most Out of Agile, Scrum, and Lean Kanban (Agile Software Development Series)”, Ajay Reddy
* Книга, “Cynefin - Weaving Sense-Making into the Fabric of Our World”, David Snowden
* Книга, “Actionable Agile Metrics for Predictability: An Introduction”, Daniel S. Vacanti
* Книга, “Essential Upstream”, Patrick Steyaert
* Книга, “Одураченные случайностью. О скрытой роли шанса в бизнесе и в жизни”, Нассим Николас Талеб
* Книга, “Черный лебедь.”, Нассим Николас Талеб
* Презентация, “Probabilistic Planning”, Дмитрий Бакарджиев
* Статья, “Story Points Revisited”, Ron Jeffries
* Статья, “Что такое предсказуемость выполнения задач и как ее понять?”, Павел Ахметчанов
* Статья, “Как работает метод Монте-Карло”, Павел Ахметчанов
* Статья, “Время в процессе: что мы реально о нём знаем?”, Alexei Zheglov перевод Артур Нек.
* Статья, “Анализ диаграммы распределения времени выполнения заказа”, Alexei Zheglov перевод Артур Нек.
* Игра, “No Estimate”, интерпретация от Евгения Степченко
* Видео, “О WIP-лимитах. Что такое WIP-лимит, как он работает и на что влияет”, Алексей Пименов
* Видео, “Capacity Allocation — как совмещать разработку продукта, поддержку, выплачивать техдолг”, Алексей Пименов
* Видео, “Работа с узкими звеньями процесса”, Алексей Пименов
* Видео, “Как прогнозировать время выполнения задач? Методики прогноза”, Павел Ахметчанов
#артефакты
🔥15👍8💩1
Посмотрел несколько видео на youtube, о том как нужно оценивать задачи.
Большая часть этих видео говорит о том, как надо оценивать задачи, но не отвечают прямо на вопрос: "Зачем оценивать задачи?"
#забавное
Большая часть этих видео говорит о том, как надо оценивать задачи, но не отвечают прямо на вопрос: "Зачем оценивать задачи?"
#забавное
😁6👍2👎1💩1
Статья Прогнозирование — это сложно, опубликована на Хабре
https://habr.com/ru/companies/tinkoff/articles/782012/
Статья получилась не маленькая, будьте к этому готовы.
Однако это всего лишь 20% от изначального материала. 🙂
На сколько смог на столько упростил.
В статье раскрываются проблемы
— Прогнозирование — это сложный процесс, который связан в первую очередь с тем как работает ваша система, а не способности оценки задач специалистами
— Объяснение причин почему так сложно прогнозировать
— Оценки ничто - стабильный процесс наше все
— Как построить стабильную систему?
#статья
https://habr.com/ru/companies/tinkoff/articles/782012/
Статья получилась не маленькая, будьте к этому готовы.
Однако это всего лишь 20% от изначального материала. 🙂
На сколько смог на столько упростил.
В статье раскрываются проблемы
— Прогнозирование — это сложный процесс, который связан в первую очередь с тем как работает ваша система, а не способности оценки задач специалистами
— Объяснение причин почему так сложно прогнозировать
— Оценки ничто - стабильный процесс наше все
— Как построить стабильную систему?
#статья
🔥20👍2💩1