Возникает оно не в вакууме, а потому что мы оказались в точке какого-то целевого для нас сценария:
Веб-сайты: Регистрация на мероприятии или авиарейсе, покупка билета на концерт The Hatters.
Мобильные приложения: Отправка сообщения или голосование в телеграм-чате.
Банкоматы и терминалы: Получение наличных или заказ еды из каталога.
Умные колонки: Включение музыки или управление просматриваемым фильмом.
GPT: Исследование, расширенный поиск, обобщение, переработка и суммаризация какой-то объемной информации, ранее невозможной к изучению в разумные сроки, генерация бойлерплейтов (кто не понял тот поймет).
Из этого мы разделим "взаимодействие" на "воз-дейсвтие" и "реакцию" - воздействие ваше, реакция программы.
Любое воздействие осуществляется через какую-то точку касания с программой, ее называют "интерфейс", или компонентом интефрейса.
Компонентом, потому что как правило это будет группа конкретных элементов интерфейса, принимающих данные и тригерные сигналы воздейсвтия, на которые последует рекция программы.
Как указано выше воздействие осуществелятся "каким-то образом", это значит, что взаимодействие с программой скорее всего будет одним из наиболее распространенных сейчас способов:
Пользовательский интерфейс - мы листаем страницы, читаем текст, смотрим картинки и видео, жмем на ссылки, кнопки, заполняем текстовые поля и прочие формы, отправляем данные.
Голосовой интерфес - мы разговариваем с колонкой и получаем реакцию в виде звуков и прочих действий.
Командный интрефейс - подвид пользовательского и голосового, но с акцентом на одну команду или последовательность с уточнениями, где подразумается объемная вычислительная работа и конкретный артефакт как продукт работы, картинка, видео, текст, пример кода, таблица данных ...
Объекты предметной области
Несмотря на возможную нетривиальную реакцию программы и ее сложные вычисления под капотом, мы все равно ожидаем какую-то понятную форму результата, несмотря на вид интерфейса.
При заказе бигмака мы хотим получить БигМак, а не дабл чиз. Какой бы у нас не был интерфейс - кассир или терминал, - мы заинтересованы только в БигМаке, как бы и где бы он сейчас не назывался, и мы страемся донести эту информацию до злобной бесчеловечной машины (или доброго человека за кассой).
Нам выдадут номер заказа. Он нам не так интересен как бигмак, это проходная информация. Рутина, как многие скажут. Но мы тоже понимаем что без этой информации мы не идентифицируем наш заказ на стойке выдачи.
Бигмак и номер заказа - это объекты предметной области. Но при этом на чеках еще много всякой информации, а программисты сразу скажут что есть еще АЙДИ заказа, то есть номер его записи в базе данных.
Мы этого даже можем никогда не узнать, поедая бигмак, хотя он там был.
Предметное действие
Важно всегда одно - что нам интересно. Бигмак интересен, а номер заказа не особо. Пэтому запишем что бигмак - это объект нашего интереса в момент заказа.
Если бы мы разрабатывали такую систему, где интерсны бигмаки, то мы вынужденно пришли бы к ясному утверждению - нам нужно обеспечить процесс заказа объектов бигмак типа блюдо.
Если мы ждем от программы, что она будет решать нашу задачу, таким образом она будет нам полезна, мы должны перечислить интересующие нас объекты внимания в контексте с действиями над ними.
Такая табличка называется - предметные действия.
Подсказка: как правило, действие над предметом завершается каким-то изменением состояния этого предмета, то есть оформление заказа приведет предмет "заказ" в состояние, например "оформлен" или "размещен.
Предметные действия. Пример таблички
Предмет
Действие
Состояние
Заказ
Оформление заявки
Размещен / оформлен
Заказ
Отгрузка заказа роботом в зале
Получен
Результаты работы программиста
В ответ на предметные действия и начнается разработка и отладка программы.
Будут проявлятся какие-то компоненты интерфейса, которыми можно пользоваться, проверять как это все работает или нет.
Программист в итоге долженсформулировать такие интерфейсы, а также обеспечить их нужным количеством внутренних операций, чтобы поддержать указанные предметные действия.
Таким образом, полезный и измеряемый результат работы программистов -- это интерфесы, которые где-то можно пощупать в процессе выполнения предметного действия над объектом интереса.
Это можно купить, оплатить, отказаться, повертеть носом, но все равно указать пальцем и измерить - все остальное полезными результатами считать не стоит.
Концентрируясь на предметных действиях и вы, и разработчик будете заинтересованы закрыть задачу как можно быстрее, чтобы перейти к следующей.
Помещая взаимный интерес в эту точку вы создаете деловое сотрудничество, ориентированное на результат для обеих сторон, и получите автоинетес к выполнению и приемке результата, которым уже вот можно воспользоваться.
Думать, что программист знает какие вам нужные предметные действия.
Именно по этой причине стараются найти "опытных программистов", вкладывая в слово опыт не опыт программирования, а опыт в предметной области.
Например, кто-то уже делал программы для фитнес клубов, кто-то делал программы для банков, кто-то делал телеграм боты для музыкальных коллективов.
И ставящий задачу, часто не догадывается, что сформулировать предметные дейсвтия, даже при наличии такого "опыта" программист не способен, потому что это другая сфера деятельности.
Полагаться на формулировку предметных действий программистами всегда приведет вас не туда, куда вам надо, а куда-то, куда придумал программист.
Нам не нужно плыть по течению, нам не нужно плыть по течению, нам нужно плыть туда, куда нам нужно.
В этом и ответ - что вам нужно, знаете только вы. И дело не в опыте.
Но, допустим разработчик готов для вас что-то сформулировать, помочь, написать ТЗ как все любят, то вы столкнетесь с очередной проблемой - а что будет задокументировано, и будет ли задокументировано то что нужно, а что не будет задокументировано?
Вопрос из зала - а что еще мы можем не знать ...
Есть ответы и на эти вопросы, но главное это понимание что разработка программы, и разработка понимания программы это два разных этапа, и привлекать програмистов на вторую задачу, которая на самом деле первая -- крайне рисковая затея.
Как разрабатывать пониамние программы обсудим в следующих материалах.
В этом примере были задействованы
Элемент
Тип
1. Стратегия
2. Деятельность
(воз-) действие
Действие
Бигмак
Объект внимания
Бигмак
Продукт
Вы
Деятель
Заказ бигмака
Бизнес-процесс
Заказ размещен
Событие
Изготовление бигмака
Действие
Мы
Рабочая группа
Я
Деятель
3. Софт
Вбивание заявки
Операция
Заказ
Модель данных
Какие-то данные
Модель данных
Реакция
Операция
4. Технологии
Chat GPT
Программа
ERP
Программа
Банкомат
Устройство
Веб-сайт
Программа
Мобильное приложение
Программа
Программа
Программа
Терминал самообслуживания
Устройство
Умная колонка
Устройство
5. Физика
6. Мотивация
7. Реализация
Если материал был вам полезен, поделитесь им с товарищами и жаждущими знаний. Ну и подписывайтесь на канал https://t.me/apavlyut.
С вами был Александр Павлють, www.apavlyut.ru, До новых встреч!
