Задача просит - "Разбери меня полностью!"
Автор: Хакехиро ДайскеНеизвестность
Случалось ведь такое? Идете на остановку, а автобус уже уехал. Или дали задачу на работе, а как её сделать не знаете. Хотите написать рассказ, а о чем он будет не придумали. Или как соединить сцены.
Все эти проблемы имеют такую сложную тему как неопределённость и действия в условиях не определённости. Конкретно именно работе с "Тёмными данными", я говорить не буду. Вместо этого хочу рассказать о данных которые есть, но кажется что их нет.
Что за парадокс?
Откуда взяться таким парадоксальным данным? Из самой задачи! Даже если задача звучит как "Сколько настройщиков пианино в Чикаго?", можно сделать оценку.
Метод Ферми
Многие прочитав вопрос уже поняли, что речь пойдет о известном методе Ферми.
Метод Ферми (или Ферми-оценка) — это способ быстрого получения приблизительного ответа на сложный, казалось бы, неразрешимый вопрос с помощью логических рассуждений и известных фактов. Назван в честь физика Энрико Ферми, который славился умением делать грубые оценки, поразительно близкие к реальности, даже при минимуме исходных данных.
Суть в том, что сама задача уже говорит о том какие данные использовать. Если разобрать вопрос мы заметим.
- Речь идет о: Настройщиках пианино -> есть объект пианино и есть человек которые его может настроить.(То есть два объекта)
- Есть условия: Находятся в Чикаго.
- Цель: Узнать сколько их там.
Получается если мы знаем:
- Сколько в Чикаго человек
- У скольких людей есть пианино,
- Сколько раз в среднем нужно чинить пианино
- Сколько в среднем один настройщик настраивает пианино в день
Можно будет приблизительно высчитать ответ.
Ферми рассуждал так:
- Население Чикаго ~ 3 млн человек.
- В семье в среднем 4 человека → ~750 000 семей.
- Пианино есть примерно у одной семьи из 20 → ~37 500 пианино.
- Каждое пианино нужно настраивать раз в год.
- Один настройщик настраивает 4 пианино в день, работает 250 дней в году → 1000 пианино в год.
- Тогда число настройщиков ≈ 37 500 / 1000 = 37,5 ≈ 38 человек.
Реальное число, по статистике тех лет, было около 50–60. Оценка дала порядок величины (десятки), что достаточно для понимания ситуации.
Суть метода в разбиении задачи на более мелкие части (Разделяй и властвуй). Но вот как разбить задачу в более житейских случаях? Как найти нужное решение, если задача ни как не даётся?
Для этого я представляю вам простенький "алгоритм изучения системы задачи(АИСЗ)"
Состоит алгоритм из двух больших этапов.
Первая честь - Разбор самой задачи на элементы и их связи.
Вторая часть - Анализ системы, среды и отдельных частей в которой появилась эта задача.
Анализ Задачи
1. Зафиксировать исходную формулировку
Запишите задачу так, как она была поставлена. Если формулировка размыта или неполна, уточните её у заказчика (или у самого себя). На этом этапе важно понять контекст: откуда взялась задача, какова её предыстория, на каком этапе находится проект/процесс.
2. Определить цель
Ответьте на вопросы:
- Какой конкретный результат должен быть достигнут?
- Как измерить успех? (критерии качества, количества, сроки)
- Зачем это нужно? (какую проблему решает задача, какую ценность приносит)
Цель должна быть сформулирована чётко и желательно по SMART (конкретна, измерима, досИтог:тижима, актуальна, ограничена во времени).
3. Выявить условия(что уже есть)
Условия — это исходные данные и предпосылки, которые даны или считаются истинными:
- Исходные материалы, информация, документы.
- Существующие процессы или системы.
- Предположения, которые можно принять без доказательств (например, «предполагаем, что пользователи имеют базовые навыки работы с ПК»).
4. Определите роли (кто участники?)
Кто вовлечён в выполнение задачи и на каких условиях?
- Заказчик — тот, кто ставит задачу и принимает результат.
- Исполнитель — кто непосредственно выполняет.
- Пользователи — кто будет использовать результат.
- Эксперты, консультанты, смежные команды — кто может помочь или чьи интересы нужно учесть.
- Руководство, контролирующие органы — если требуется согласование.
Зафиксируйте для каждой роли их ожидания и зону ответственности.
5. Выявите ограничения (что нельзя нарушать?)
Ограничения бывают разных типов:
- Временные — дедлайны, этапы.
- Ресурсные — бюджет, доступные люди, оборудование, ПО.
- Технические — платформа, стек технологий, совместимость.
- Правовые и нормативные — законы, стандарты, политики компании.
- Организационные — иерархия, процедуры согласования.
Важно отличать ограничения от условий: условия — это то, что можно использовать; ограничения — это рамки, которые нельзя переступать.
6. Опишите зависимости и связи
С чем связана задача?
- Какие другие задачи/проекты влияют на неё или зависят от неё?
- Какие внешние факторы (рынок, сезонность, погода) могут повлиять?
- Есть ли скрытые зависимости, которые неочевидны?
7. Проведите анализ рисков и предположений
- Что может пойти не так? (технические, человеческие, внешние риски)
- Какие допущения мы делаем? (если допущение окажется неверным, это повлияет на решение)
- Как можно минимизировать риски?
8. Сформулируйте критерии приёмки
Как проверить, что задача решена полностью и правильно?
- Перечислите измеримые показатели (тесты, чек-листы).
- Определите, кто и как будет принимать работу.
9. Декомпозируйте (при необходимости)
Если задача крупная, разбейте её на подзадачи и повторите для каждой подзадачи шаги 2–8 (или хотя бы уточните цели и ограничения на уровне подзадач). Это поможет создать план работ.
10. Оформите результат анализа
Сведите все данные в единый документ (техническое задание, бриф, план проекта). Используйте табличную форму или структурированный текст. Убедитесь, что все ключевые элементы зафиксированы и понятны всем участникам.
Пример применения (коротко)
Задача: «Разработать мобильное приложение для заказа пиццы».
- Исходное: фраза заказчика.
- Цель: выпустить MVP приложения для iOS и Android, позволяющее выбирать пиццу из меню, оформлять заказ и оплачивать онлайн. Успех — 100 скачиваний в первую неделю.
- Условия: есть бэкенд с каталогом, команда из 2 разработчиков, дизайн-макеты в Figma.
- Роли: заказчик — владелец пиццерии, исполнители — разработчик iOS, Android, дизайнер, тестировщик.
- Ограничения: срок — 2 месяца, бюджет — 500 тыс. руб., технологический стек — React Native, интеграция с существующей CRM.
- Зависимости: от готовности API бэкенда.
- Риски: задержка API, высокая конкуренция.
- Критерии: приложение работает без критических ошибок, проходит модерацию в магазинах приложений, пользователь может совершить заказ.
- Декомпозиция: разработка экрана меню, корзины, оплаты, личного кабинета и т.д.
Анализ Системы задачи
1. Определить основную систему.
- Что является основной системой?(Устройство, Процесс, продукт)
- Какая основная функция этой системы(Зачем она нужна, что делает)
- Какие ограничения и проблемы в ней
2. Анализ подсистем(Частей системы)
- какие подсистемы внутри
- Какие элементы в этих подсистемах
- Как они взаимодействуют
3. Анализ Надсистем(Внешняя среда)
- Что является надсистемой?
- Как надсистема влияет на систему (Влияние окружения на систему)
- Как система влияет на надсистему
- Какие возможности надсистемы для улучшения
4. Анализ поля и взаимодействийИтог:
Поле - это то, что взаимодействует. Взаимодействие - Как поле влияет на вещество.
Магнитное поле - это поле. Примагничивание - Взаимодействие.
Воздух - Химическое поле. Окисление метала - Взаимодействие.
- какие "поля" действуют?
- Какие есть полезные и вредные взаимодействия
- Доступные ресурсы в полях
5. Сбор и структура базы знаний
Собрав данные нам нужно их структурировать. нужно выписать найденные ресурсы, то что нам теперь известно. И самое главное найти Противоречия!
Противоречия это по сути и есть задачи. Так мы можем перейти из состояния "Хочу, но не знаю как" а "Хочу и для этого надо сделать вот это".
Немного про решение противоречий
В первую очередь надо стремится к тому, чтобы две противоположности полностью выполнились!
Если мы нашли противоречие "Должно быть горячим и холодным", нужно сделать чтобы обе части противоречия решились 100%. Ни каких компромиссов "Оно теплое".
Для этого мы должны разделить противоречие в пространстве, времени, взаимодействии.
В пространстве: Одна часть объекта горячая, другая холодная. В одном месте горячая, в другом холодная.
Во времени: Одно время горячая, в другое холодное.
При взаимодействии: При взаимодействии горячая, при другом взаимодействии холодная.(Например взаимодействие плиты и холодной воды.)
Есть еще метод ухода в надсистему(Для простоты: в окружение). То есть, сделать так чтобы окружение делала её теплой или холодной. Само действие уходит в окружение. Но получается тоже самое что и при размышлении о взаимодействии, так что я опущу этот вариант.
Итог:
Даже имея минимум информации, сама задача рассказывает где искать решение. В самой задаче уже есть цель - Что должно получится, условия - что можно использовать, что уже есть, ограничения и т.д. А это уже те части задачи которые можно использовать. Даже если мы не знаем сколько людей в Чикаго, мы уже знаем что можем получить эти данные. Либо на прямую(Гугл в помощь), либо косвено(Разбить подзадачу на еще более мелкие подзадачи.)
Так что даже если ситуация кажется безвыходной, это лишь значит что, вы еще не все нашли. Всегда есть хитрое решение, которое создаст нужные условия.