Настраивать «своих AI-чат-ботов на базе Coze» — это как дитя обучать. И хорошо, если в этом «воспитании-обучении» принимают участие «Взрослые». Но пока таких не много (и все они заняты делами), можно и «старших ботов» привлекать…
Например, так:
Промт:
Я дам тебе дискурс, контексты, ограничения и поставлю задачу, а ты — в заданных мной рамках, выдели роли, объясни практики этих ролей, с помощью которых, выделенные тобой роли, действуя совместно, решат мою задачу.
На основе выявленных тобой практик, напиши чек-листы для каждой роли по каждой практике.
### Дискурс:
компания по производству компьютерных игр на базе Android. Разработка, тестирование и продажа подписки на созданные компанией игры осуществляется через Google Play.
### Контекст:
сотрудники (разработчики, дизайнеры, маркетологи и др.) постоянно конфликтуют между собой, продукт не создаётся, продаж нет.
### Ограничения:
финансирование осуществляется исключительно за счёт средств собственника компании, т.к. он категорически отказывается связываться с инвесторами ибо боится потерять бизнес. Задача: сделать так, чтобы продукт был создан и пошли первые продажи.
Отвечай подробно, дай ссылки на источники твоей информации.
Perplexity:
Для решения задачи создания продукта и начала продаж в компании по производству компьютерных игр на базе Android, необходимо выделить ключевые роли в команде, объяснить их практики и составить чек-листы для каждой роли. Основываясь на предоставленных источниках, можно выделить следующие роли и практики:
Роли в команде разработки игр
- Разработчики (Программисты)
- Дизайнеры (Графические дизайнеры, UI/UX дизайнеры)
- Тестировщики (QA инженеры)
- Маркетологи
- Продюсеры (Менеджеры проектов)
Практики для каждой роли
Разработчики
Практики:
Итеративная разработка:
Разработка игры поэтапно, с регулярными проверками и обратной связью.Управление требованиями:
Четкое определение и приоритизация требований к игре.Управление изменениями:
Введение процесса контроля изменений для отслеживания и документирования всех изменений в проекте.Чек-лист:
- Разбить проект на небольшие итерации.
- Регулярно проводить встречи для обсуждения прогресса и получения обратной связи.
- Определить и задокументировать все требования к игре.
- Приоритизировать требования в соответствии с целями проекта.
- Ввести процесс контроля изменений и документировать все изменения.
Дизайнеры
Практики:
- Создание и поддержка документации по дизайну: Поддержание актуальности и четкости документации по дизайну игры.
- Оптимизация и стандартизация: Следование лучшим практикам и стандартам в области игрового дизайна.
Чек-лист:
- Создать и поддерживать актуальную документацию по дизайну игры.
- Следовать стандартам и лучшим практикам в области игрового дизайна.
- Регулярно проверять и обновлять документацию по мере необходимости.
- Обеспечить оптимизацию графики и интерфейса для различных устройств.
Тестировщики
Практики:
- Функциональное тестирование: Проверка соответствия игры первоначальным спецификациям.
- Тестирование совместимости: Проверка оптимизации игры для различных устройств и экранов.
- Регрессионное тестирование: Повторное тестирование функциональности после внесения изменений.
Чек-лист:
- Провести функциональное тестирование игры.
- Проверить совместимость игры с различными устройствами и экранами.
- Выполнить регрессионное тестирование после внесения изменений.
- Документировать все найденные ошибки и баги.
- Составить отчет о результатах тестирования.
Маркетологи
Практики:
- Анализ целевой аудитории: Определение и анализ целевой аудитории для игры.
- Разработка маркетинговой стратегии: Создание стратегии продвижения игры на рынке.
- Мониторинг и анализ результатов: Отслеживание и анализ результатов маркетинговых кампаний.
Чек-лист:
- Определить целевую аудиторию для игры.
- Провести анализ рынка и конкурентов.
- Разработать маркетинговую стратегию для продвижения игры.
- Запустить маркетинговые кампании.
- Отслеживать и анализировать результаты кампаний.
- Вносить коррективы в стратегию на основе полученных данных.
Продюсеры
Практики:
- Эффективная коммуникация: Обеспечение четкой и эффективной коммуникации между членами команды.
- Управление проектом: Координация всех этапов разработки и тестирования игры.
- Контроль качества: Обеспечение высокого качества продукта на всех этапах разработки.
Чек-лист:
- Обеспечить регулярные встречи команды для обсуждения прогресса и проблем.
- Координировать работу всех членов команды.
- Следить за выполнением задач в соответствии с планом проекта.
- Обеспечить высокое качество продукта на всех этапах разработки.
- Внедрить процесс контроля качества и тестирования.
Заключение
Для успешного создания продукта и начала продаж необходимо наладить эффективное взаимодействие между всеми членами команды, следовать лучшим практикам и четко выполнять свои роли. Использование чек-листов поможет структурировать работу и избежать конфликтов.
Источники:
- Starloop Studios: Game Testing 101: Basic Tips and Strategies
- Starloop Studios: Game Testing: Best Practices and Emerging Trends
- LinkedIn: Tips and Resources to Improve Your Game Art Skills
- Assembla: A Blueprint for Successful Game Development
- Reddit: What are the roles in a gamedev team, and who are they for?
Aisystant:
Отлично, давайте разберёмся с вашими запросами по шагам.
Шаг 1. Выделение ролей
На основе контекста и дискурса можем выделить следующие ключевые роли:
Разработчик (инженер продукта)
Дизайнер (инженер продукта)
Маркетолог (продвиженец)
Менеджер (организатор)
Администратор (обеспечивающий работу)
Лидер (обеспечивающий сотрудничество)
Эти роли покрывают основные потребности проекта в создании и продвижении продукта.
Шаг 2. Объяснение практик ролей
Практики для каждой из этих ролей будут следующими:
Разработчик
Кодирование: Написание и отладка кода.
Тестирование: Проведение юнит-тестов и интеграционных тестов.
Документирование кода: Создание технической документации.
Дизайнер
Создание концептов:
Разработка графического контента и пользовательских интерфейсов.Тестирование UX/UI:
Проведение пользовательских тестов для улучшения интерфейса.Работа с инструментами дизайна:
Использование программ для создания графики и анимации.Маркетолог
Исследование рынка:
Анализ конкурентов и целевой аудитории.Разработка стратегий продвижения:
Создание маркетинговых кампаний.Работа с платформами:
Управление рекламными кампаниями, особенно в Google Play.Менеджер
Организация работы:
Составление рабочих планов и расписаний.Контроль проектов:
Отслеживание прогресса и соблюдение дедлайнов.Взаимодействие с командой:
Улаживание конфликтов и мотивация сотрудников.Администратор
- Обеспечение ресурсами:
Закупка необходимого оборудования и ПО.- Поддержка инфраструктуры:
Обеспечение бесперебойной работы серверов и сетей.- Ведение документации:
Управление документацией и отчетностью.Лидер
- Вдохновение команды:
Мотивация и поддержка команды.- Разрешение конфликтов:
Медиация и решение конфликтных ситуаций.- Стратегическое планирование:
Определение долгосрочных целей и стратегий.Шаг 3. Чек-листы
Разработчик
Кодирование
- Определить функциональные требования.
- Написать код согласно требованиям.
- Провести ревью кода с командой.
- Внедрить код в основную ветку.
Тестирование
- Создать тестовые сценарии.
- Выполнить юнит-тесты.
- Провести интеграционные тесты.
- Записать результаты тестов и устранить ошибки.
Документирование кода
- Написать комментарии в коде.
- Создать техническую документацию.
- Обновить документацию при изменении кода.
Дизайнер
Создание концептов
- Изучить требования к дизайну.
- Разработать концепты интерфейсов.
- Представить концепты на ревью.
Тестирование UX/UI
- Подготовить макеты для тестирования.
- Провести пользовательские тесты.
- Собрать обратную связь и внести изменения.
Работа с инструментами дизайна
- Использовать профессиональные программы для дизайна.
- Сохранить все исходные файлы.
- Обеспечить доступность файлов для команды.
Маркетолог
Исследование рынка
- Проанализировать конкурентов.
- Определить целевую аудиторию.
- Подготовить отчет по результатам анализа.
Разработка стратегий продвижения
- Создать маркетинговую стратегию.
- Определить рекламные каналы.
- Настроить рекламные кампании.
Работа с платформами
- Управлять рекламными кампаниями в Google Play.
- Анализировать эффективность рекламы.
- Вносить коррективы на основе данных.
Менеджер
Организация работы
- Создать расписание проекта.
- Назначить ответственных за задачи.
- Обеспечить наличие ресурсов.
Контроль проектов
- Отслеживать прогресс выполнения задач.
- Обновлять статус проекта.
- Предоставлять отчеты собственнику.
Взаимодействие с командой
- Проводить регулярные совещания.
- Разрешать конфликты.
- Поддерживать мотивацию команды.
Администратор
Обеспечение ресурсами
- Определить потребности в ресурсах.
- Закупить или арендовать ресурсы.
- Обеспечить их доступность для команды.
Поддержка инфраструктуры
- Настроить серверы и сети.
- Обеспечить резервное копирование данных.
- Обновлять ПО и устранять неполадки.
Ведение документации
- Поддерживать актуальность документации.
- Хранить документы в защищенном месте.
- Предоставлять доступ к документации по запросу.
Лидер
Вдохновение команды
- Организовать мотивационные мероприятия.
- Поддерживать позитивную атмосферу.
- Оказывать поддержку сотрудникам.
Разрешение конфликтов
- Выслушивать стороны конфликта.
- Предлагать компромиссы.
- Внедрять решения и следить за их выполнением.
Стратегическое планирование
- Определить долгосрочные цели.
- Разработать стратегический план.
- Обсудить стратегию с командой.
Ссылки на источники информации
Методология, глава 4 - Системное мышление, глава 5 - Моделирование и Собранность, глава 4
Моделирование и Собранность, глава 11 Надеюсь, это поможет вам наладить процесс и добиться первых продаж!
Материалы:
Главный приём определения практики
2.2. Методология (А. Левенчук) / 4. Практика как объект первого класса
Главным приёмом появления практики как объекта вашего внимания будет задаться вопросом, откуда исполнитель проектной роли (человек, команда, коллектив, предприятие) знает, как ему выполнять свою работу. Вот человек что-то делает: Он сам придумал, как именно это нужно делать? Подглядел у других? Он читал учебник, проходил курсы? Когда это было? А что сейчас говорят на эту тему в университетах, что пишут в блогах ведущие практики по этой дисциплине? Можем ли мы представить, что мы должны получить такие же результаты его работы, но быстрее и дешевле, поменяв способ работы? Как бы мы начали искать этот новый способ работы? Если вы задались этими вопросами (в этом-то и проблема, что они не приходят в голову! Нужно иметь специальную привычку эти вопросы задавать!), то поздравляем: в вашем внимании практика, и курс «Методология» поможет вам рассуждать об этой практике: описывать её, менять версии этой практики. Главным тут будет переход от обсуждения собственно работы (быстро, медленно, какие ресурсы) к способу выполнения работы и далее к альтернативным вариантам в способах выполнения работы.
Мышление об агентах (людях и AI): прежде всего они исполнители ролей
2.1. Cистемное мышление (А. Левенчук) / 5. Методы/функции/практики/деятельности/культуры/методы работы и роли
Цель создания списка систем — достижение понимания создателями системы «таблетка из лактобактерий», что работа по каким-то инженерным методам будет на всех этих уровнях. Поэтому в проекте придётся обратиться к самым разным агентам, имеющим мастерство и инструментарий для методов работы с существами, методов работы с веществами, методов работаты с личностями, методов работы с сообществами и даже обществом в целом (если выяснится, что это как-то затрагивает общественные интересы и нужно вести какие-то общественные дискуссии, менять законодательство и тем самым заниматься политикой). А ещё нужно будет создать организацию проекта, которая всем этим займётся, так что есть и роль организатора::менеджер, и возможно там будет не один человек её исполнителем (отдельно операционный менеджер, отдельно орг-проектировщик, отдельно лидер). Подробней про методы организовывания и роль организатора и его дробление на более мелкие роли говорится в курсе инженерии организации (курс «Системный менеджмент»). Методологический (разнообразие методов работ, он же — трудовой/деятельностный/практический/инженерный) кругозор важен, чтобы не запутаться в этом разнообразии культурно-обусловленных методов работы и исполняющих эти методы ролей: нужно примерно представлять, что скрывается за самыми разными действиями с самыми разными объектами, которые мы наблюдаем, за самыми разными словами, которые мы слышим и читаем от самых разных агентов в самых разных проектах. И после того, как будет понятно, какого типа упоминаемые агентами объекты (какой системный уровень, какой метод работы используется, какая проектная/деятельностная/функциональная/инженерная/трудовая/культурная роль выполняет используемый метод работы, как её называют такую роль, какой учебник или инженерный стандарт для метода работы говорит о SoTA в этом методе, что там в проекте целевая система, какие роли у систем создания этой целевой системы и какие интересы этих ролей, что там с графом создания, что там функциональные объекты, а что там конструктивы, каким образом выбирались аффордансы для этих конструктивов, и т.д.), станет много проще: обо всём этом «зоопарке» самых разных объектов и деятельностей вы будете думать примерно одинаковым образом и не упускать важного. В системном мышлении мы всегда должны думать: От границы системы в её окружение в момент использования сначала, а о составе системы внутри границы системы потом. О методах работы, ведущих к изменению состояния мира сначала, затем о роли исполнителя метода, и только потом о поиске аффорданса (агента, имеющего мастерство исполнения работ по методу и инструментарий для этих работ) как конструктива для роли. Если мы не знаем про то, какая разыгрывается перед нами деятельность/пьеса/практика/культура/метод работы, то мы не можем оценить действия этих людей (они будут казаться личной прихотью), спланировать свои действия (они будут неважны для людей-в-ролях, ибо лежат вне их ролевых предметов интереса, буквально неинтересны, не будут иметь отношения к их предпочтениям), не можем сыграть свои роли в играемой ими пьесе (ибо будем бескультурными, «не выучили роль», книжек не читали, не знаем, как обычно это делается) — и без этого нас просто не поймут! И мы ни в коем случае не должны путать Принцев Гамлетов и Василиев Пупкиных! Мы не должны обращаться к Принцу Гамлету как к Офелии — исполнитель роли просто не будет знать, что делать и вместо работы по проекту будет «бытовой разговор» с выяснением отношений и (правильными) упрёками в непрофессионализме. Конечно, у вас может быть множество ролей (особенно в маленьких проектах, где вечно «театр одного актёра» или «игра одного игрока»), но лучше бы маркировать и для себя, и для окружающих, когда вы::актёр переходите из одной роли в другую. Это объявление своей роли для окружающих нужно тренировать, усиливать свой интеллект (осваивать методы мышления интеллект-стека, в том числе наш курс системного мышления занят как раз этим), а также тренировать ролевое мастерство (в котором можно выделить ещё мастерство собранности как мастерство надёжного управления вниманием), расширять свой методологический/трудовой/инженерный кругозор, чтобы не попасть впросак, не заметив какого-то культурно-обусловленного метода работы и не узнав тем самым культурно-обусловленной роли её выполняющего актёра. Для получения этого кругозора важно проходить прикладные курсы по инженерии разных видов систем (у нас это прежде всего курсы системной инженерии, инженерии личности, системного менеджмента). Трудностей в таком мышлении про методы работы и выполняющие их роли — множество. Например, когда на вас орут на каком-нибудь совещании, то просто невозможно сосредоточиться — видишь только человека (не человека::актёра, не исполнителя роли) и его к тебе отношение «вне роли», а как личности к личности. Но это «невозможно сосредоточиться» лишь означает недостаточный ваш уровень мастерства собранности и тем самым близость к мыслительной ошибке: вы перестали мыслить системно, вернулись к мышлению дикаря, которого ведут эмоции — видите в людях только эмоциональных животных и не учитываете знаний цивилизации о методах работы и ролях людей как агентов. Вы теряете доступ к даже имеющемуся у вас методологическому/трудовому/инженерному кругозору, вы не можете вписать ваше собственное прикладное мастерство в коллективные ситуации задействования мастерства множества агентов, вы не можете учесть ваш ролевой предмет интереса к каким-то системам в ситуации и удовлетворить интерес из-за того, что вы не замечаете ролевого поведения людей::актёров, позволяя эмоциям выключить рациональное рассуждение. Важно, чтобы в проекте все обсуждения проходили в терминах «действующих лиц» и методов их работы, а не исполнителей/актёров с игнорированием знаний/теорий и инструментария методов, и никакие эмоции или другие отвлечения тут не должны мешать. Сравните два диалога: — Иванов опять чертежи испортил! Он присылает их в формате .dwg и ссылается на Петрова! Сидорова не может работать! — А что думает об этом «Красшефмонтаж»? — Его не волнует, лишь бы «Заготбазарбаза» не возражала! Всё ли вам понятно, если вы случайно попали на совещание? Можно ли задать какие-то уточняющие вопросы по непониманию — и какие? Если вы хорошо знаете всех действующих лиц, то можете ли вы предсказать хоть как-то их предполагаемые реакции в данной ситуации? 2. Ролевое обсуждение, когда вместо имён актёров называют имена их персонажей/ролей (ровно тот же пример, что в предыдущем пункте): — Конструктор опять чертежи испортил! Он присылает их в формате .dwg и ссылается на расчётчика! Архив не может работать! — А что думает об этом технолог завода-изготовителя? — Его не волнует, лишь бы поставщик корпусов не возражал! Стало ли понятней, о чём идёт речь? Какие уточняющие вопросы вы бы задали? Вот ещё пример, где мы назовём исполнителя по его должности, а не по роли: – Старший программист: когда я вчера смотрела на график нашего проекта, то поняла, что нам может не хватить времени на тестирование, поэтому неплохо бы озаботиться контрактацией дополнительных серверов для этой работы. Варианты продолжения беседы (какой выберете?): Инженерный: какие ошибки требуют дополнительных серверов для их тестирования? Можем ли мы уменьшить объём тестирования? [и оцените вероятность, что «старший программист» не подумала об этих вопросах, когда делала своё заявление] Менеджерский: у нас предусмотрено это бюджетом, или как всегда? У вас есть проект контракта? Кто найдёт поставщика? [и оцените вероятность, что «старший программист» и впрямь не знает ответов на эти вопросы] Можно ли верить, что «старший программист» желает обсудить инженерные аспекты дела, она и вправду выступила как программист? Или она выступила как менеджер? Вы бы сами какую линию разговора повели: чем бы озаботились, о чём спросили? Как кто вы поступили бы в этом разговоре (какую бы компетенцию вытащили в качестве основной — инженерную или менеджерскую)? Вспомните, когда последний раз в разговоре вы проводили такой ролевой анализ «кто и о чём говорит — кто и о чём должен ему отвечать»? Отслеживаете ли вы смену предметов разговора (смену предмета интересов/важных характеристик в обсуждении)? Не означает ли это для вас, что агент-собеседник поменял роли, или просто вытащил для обсуждения другой предмет интереса той же самой роли? Как долго (в часах разговора! собранность!) можете удерживать внимание на диалоге так, чтобы в любой момент понимать «кто (какая роль) говорит — кто (какая роль) отвечает — предмет обсуждения/интереса, какие предпочтения в этом предмете у ролей (не у исполнителей ролей/актёров)»? Обсуждение в терминах «действующих лиц» (понимание проектных ролей как ролевых/функциональных «деятелей», а не конкретных агентов-исполнителей, например, конкретных людей или конкретных людей-на-должности) крайне важно для коммуникации: такое обсуждение направляет мысль и позволяет понимать, какие «пьесы» сейчас обсуждаются — какие реплики могли бы следовать, а не только какие реплики следуют прямо сейчас. Если какой-то Принц Гамлет вдруг начинает давать реплики Офелии — то можно дальше обсуждать: спасает ли он пьесу ввиду неявки Офелии, или просто портит дело как некомпетентный актёр-исполнитель и нужно немедленно его заменить в роли Гамлета, уволить из спектакля и назначить на роль другого актёра, более грамотного/квалифицированного в своей роли или хотя бы более внимательного. То же самое в ролевой игре «Принц Гамлет», эта нелепость будет видна и при импровизационном характере отыгрыша ролей. Ровно то же будет и в рабочих проектах, если финансист начнёт давать реплики разработчика чат-бота и наоборот, разработчик чат-бота вдруг начнёт давать реплики финансиста: надо сразу начинать разбираться, это спасение проекта, или порча дела. Когда идёт проектная деятельность, то людей (и искусственные интеллекты тоже!) лучше называть по их проектным ролям, а не по фамилиям или названиям организаций. Самый тяжёлый случай, это когда люди в проекте знают важность какого-нибудь Василия Петровича (он точно исполняет какую-то проектную роль! Он существенно влияет на проект! Он начальник!), но не могут назвать его проектную роль, не понимают каким методом он работает в этой роли, насколько он мастер в этом методе, насколько осознанно его мастерство, не понимают его ролевых предметов интереса, предпочтений, задаваемых методом работы. Действия Василия Петровича поэтому для участников в проекта «невычислимы», так что они не знают, что от него ожидать, как реагировать. Чаще всего это бывает с начальниками, людьми-в-должности, про полномочия по распоряжению трудом и ресурсами которых можно долго и много рассказывать, но вот их мышление, их методы работы и задействующие эти методы работы роли и мастерство в этих ролях — вот этого сказать про них нельзя, знание производственной культуры тут бессильно, и нужно специально исследовать вопрос про профессиональные/трудовые роли этих людей в проекте, какие у них ролевые предметы интереса и предпочтения в них, что они умеют делать, кроме как что-то продавливать своими часто немаленькими полномочиями. Выглядят «начальники» часто как менеджеры (инженеры организации), но обычно оказываются очень узкими специалистами в какой-то специфической «железной» или «программной» инженерии, или коммуникациях как умении «договариваться и улаживать конфликты», и даже довольно редко в менеджменте (организационном и операционном), когда заходит речь именно об их ролевой работе. Всё остальное время они просто штампуют своими полномочиями чужую ролевую работу (проверяя формально, что у остальных участников проекта нет возражений — но это и голосование в чате может сделать, не нужно чату для этого быть начальником!), воспроизводя медленно работающий каскад «предложений-утверждений» в организации с организационной культурой «аналитиков и начальников».
1.1. Моделирование и Собранность (П. Медведева, В. Агроскин, А. Лубенченко) / 4. Что такое онтологическая работа
Теперь вы оказались в какой-то роли, у вас есть в рамках этой роли достаточно определённые планы, вы собрались сделать действия, характерные именно для этой роли. Мы будем называть такие типовые, знакомые вам в этой роли действия - «практиками». Для некоторых своих ролей мы сами разрабатываем (изобретаем) практики. Некоторые практики мы изучаем в образовательных организациях, а некоторые - подхватываем у других людей, которые явно или неявно убеждают или заставляют нас занимать какую-то новую роль, после чего мы начнем смотреть на мир из этой роли и её глазами. Если же типовых действий вы совсем не знаете и научить вас некому – тогда вы, скорее всего, вовсе не знакомы с требуемой от вас ролью, вы будете придумывать всё на ходу, и сперва никакого осмысленного выделения объектов не сможете сделать, а будете случайным образом хватать во внимание то, что попадется под руку. Подробно про роли и практики вы сможете узнать в нашем курсе “Системное мышление”, а про типичные роли в разных видах деятельности мы будем рассказывать на курсах прикладной инженерии. В роли повара, зная, что надо будет чистить, отмерять, резать, варить и жарить - вы наверняка в первую очередь обратили внимание на книгу с рецептами, продукты в холодильнике, оборудование кухни (ножи, разделочные доски), посуду, мойку, плиту. А не на картину на стене, обои, люстру и так далее. Шум за пределами кухни вас заинтересует только если вы оцениваете, не прервут ли ваши труды домашние. Погоду за окном – только если вы хотите решить, не включить ли свет над плитой. Когда вы смотрите из своей роли, вы видите нужный для неё набор объектов, попадающих в ваше внимание, выделяемых вами из фона. Ролевое рассмотрение становится исходной точкой для выделения объектов. Выделение какого-то набора объектов становится первым шагом на пути разработки онтологии и построения модели деятельности (этот путь будет долгим). Но мы уже будем называть такой набор «онтологией», постепенно уточняя это понятие. А ещё мы будем говорить иногда «картина мира», имея в виду специфический взгляд на мир из определённой роли. Обратите внимание, когда люди выделяют объекты для своей деятельности, они редко явно задумываются над своей ролю. Вы просто не замечаете себя, вы не проговариваете вопрос: «А как кто я сейчас смотрю на это яблоко (ноутбук, стакан воды, задачи, сотрудников, мужа, жену, проект, фирму)?» Если вы для тренировки позадаёте себе такой вопрос – вы обнаружите, что ответить на него в большинстве случаев не очень сложно, и в простых бытовых ситуациях ответ будет очевидным, не слишком интересным. Зато в сложных ситуациях, когда вас не понимает собеседник, или вы не понимаете собеседника, эта тренировка даст результат – вы автоматически зададитесь вопросом о роли (своей или собеседника), найдёте на него ответ, и очень часто этого будет достаточно для улучшения коммуникации. В качестве следующего важного принципа заметим, что, исходя из практик роли, мы при выделении объектов учитываем в первую очередь их функции, то есть то, чем они могут быть полезны с точки зрения необходимых действий в вашей роли. Если вам нужно разливать суп по тарелкам, и вы не можем найти половник – ваши интересы удовлетворит кружка, то есть по сути вы выделите объект «черпало». Если вы не найдёте доску для резки – вы обратите внимание на качество рабочей поверхности и её чистоту, то есть вас будет интересовать объект «место для резки». Кстати, другие люди – это, конечно же, тоже выделяемые вами объекты. И тут важно замечать, что вас либо действительно интересуют эти люди как индивидуальные биологические существа (например, если вы в роли врача), либо вас интересуют только какие-то отдельные аспекты деятельности людей в определённой роли (например, вас в роли менеджера интересуют именно рабочие роли людей в рамках деятельности фирмы, а не эти люди целиком). То есть перед тем, как выделять людей, вам из своей роли хорошо бы увидеть (выделить) другие роли, а уж потом искать – кто их исполняет. И тут может оказаться, что вам нужны как объекты не только люди, но и другие агенты, например, компьютеры с интеллектуальными программами. Кроме функционального взгляда на выделяемые объекты, в системном подходе существуют и другие, но мы сейчас не будем на них останавливаться, просто запомним на будущее, вы встретитесь с этим в других курсах. А вот к функциональному взгляду мы ещё вернёмся подробнее в этом курсе, специальные (и довольно экзотические) «функциональные объекты» нам ещё встретятся. Повторим - источником объектов для онтологии является именно ролевое рассмотрение и выделение функциональности значимых для этой роли (для её действий, практик) объектов. То есть для качественного выделения объектов вы должны явно задать себе вопросы: Я кто? В какой я роли? Какие действия (практики) предполагает моя роль? Что я буду сейчас делать? Что необходимо для совершения нужных мне действий? Какие функции мне понадобятся? Где я буду действовать, что за фрагмент мира вокруг? Что есть или что может быть вокруг меня (какой тут фон)? Какие объекты тут могут быть полезны для выполнения этих функций? При первом знакомстве с новой ролью и её практиками вам, скорее всего, всё же объяснят про необходимые объекты. Вы узнаете об этом из лекций, учебников, стандартов, методик. Вам покажут образцы, дадут шаблоны для выделения и описания объектов. Поэтому выделяемые вами объекты с самых первых шагов окажутся хотя бы отчасти общими с какими-то другими агентами, которые бывают в этой же роли. Мы говорим, что онтология должна быть обязательно разделяемой. Объекты, выделенные только вами уникальным образом – могут быть полезны вам лично (если вы являетесь гениальным изобретателем в абсолютно новой области), но бесполезны в коммуникации, пока вы не расскажете о них другим. В уже знакомой вам роли выделение объектов происходит за секунды, после чего кусок мира, который был раньше единым фоном, оказывается разделен на объекты и всё остальное (фон), и это можно зафиксировать, например, записать для себя или для других. Разделяемые объекты, понятные для значительного количества представителей какой-то роли, принято называть все вместе «предметной областью». Например, кулинария – предметная область для роли «повар», строительное дело – предметная область для роли «строитель». Предметные области – это удобный способ делить большие онтологии на части разного размера, для разработки, изучения, использования.
1.1. Моделирование и Собранность (П. Медведева, В. Агроскин, А. Лубенченко) / 11. Наведение внимания
Хорошие модели и качественные онтологии крайне редко (если вообще) строятся целиком на озарении, «из головы». Обычно для получения хорошей модели сначала надо откуда-то взять «строительные кирпичики» – понятия, которые уже были придуманы до вас, и попробовать применить их. Поскольку выбор концептов / понятий зависит от роли, сначала нужно поговорить о том, как отбирать подходящие роли. Как уже говорили ранее, роли рассматриваем как абстрактные функциональные объекты. Роль агента определяется по его поведению: то есть по тому, что он говорит или делает. Например, в ходе разговора сотрудник говорит о плохом качестве лидов в компании и обсуждает способы его улучшить – значит, он исполняет роль маркетолога. Когда сотрудник делает отчет по срокам и бюджету проекта, то он находится в роли операционного менеджера. Если мы не наблюдаем некоторое поведение, то мы ничего не можем сказать о роли агента: функция не демонстрируется. Чтобы понимать, в какой роли находится агент, или в какую роль нужно встать вам, чтобы получить желаемый рабочий продукт, нужно не только знать концепт «роли», но и иметь хотя бы минимальный ролевой кругозор. Естественным ролевым кругозором мы владеем так же, как естественным языком: он выучивается в ходе жизни в обществе. Вы не спутаете врача и юриста, отличите повара от дизайнера и фотографа, знаете о существовании маркетологов и операционных менеджеров. Но можно выделить еще проектный ролевой / трудовой кругозор. Проектный трудовой кругозор требуется для запуска и успешного завершения проекта. В разных проектах роли будут отличаться: так, в проекте разработки ПО будет роль «программиста-разработчика», которой не будет в проекте обучения английскому языку. Зато в проекте обучения английскому будет методист, который будет отсутствовать в проекте разработки ПО. Однако благодаря системному подходу можно выделить минимальный набор ролей, который должен быть в любом проекте вне зависимости от того, что будет создаваться в рамках проекта. Такой «минимальный базовый набор» мы будем называть проектным ролевым / трудовым кругозором (мета-моделью ролей в проекте). В минимальный проектный кругозор включаем следующие типовые роли: продвиженец (например, маркетолог), инженер (целевой системы, продукта), менеджер, администратор, лидер. Продвиженец отвечает на вопросы «кому нужна будет система? Кто за нее заплатит? Кто будет пользоваться? Кому продвигать?», инженер конструирует систему, менеджер организует работы по ее созданию (создает «производственный конвейер»), администратор обеспечивает работу этого конвейера, лидер обеспечивает сотрудничество людей в ходе реализации. Иногда в этот набор удобно включать еще инвестора, выделяющего ресурс на создание системы с целью получить отдачу в дальнейшем. Когда вы приходите в проект, вам требуется найти агентов, выполняющих эти роли. Ролей может быть (и будет!) больше; кроме того, одну и ту же роль может играть несколько человек. Однако если какой-то типовой роли вы не нашли соответствие в проекте вообще – то есть, если у вас вообще отсутствует исполнитель одной из ролей как таковой (например, никто не исполняет роль продвиженца) – то, скорее всего, ключевые проблемы проекта будут «закопаны» именно там. Ключевые они потому, что частью проекта никто не занимается совсем, она «в темноте» – в итоге функция не исполняется вообще. Именно там через время «рванет», потому что если не прикладывать усилия, то ситуация будет чаще всего постепенно ухудшаться. Выделите в самом простом из ваших проектов минимальный набор ролей. Есть ли какие-то роли в проекте, которые не исполняются совсем или исполняются непонятно как? В проектах в вашей области могут быть свойственные вашей сфере деятельности роли, как методист в образовательном проекте. О наличии таких типовых ролей в вашей сфере надо знать, следует понимать в общих чертах, чем занимаются исполнители ролей, какие у них интересы. Все это облегчит коммуникацию в командах. Допишите в пост типовые для вашей сферы деятельности роли. Выделите их интересы. Понимаете ли вы, чем занимаются исполнители этих ролей в вашей команде или вашем коллективе? В разговоре роли часто можно определить по наличию в речи специальных терминов, например, «лиды» для маркетолога. Часто такие термины звучат как «птичий язык» для тех, кто не имеет соответствующего ролевого кругозора. Что делать, если вы не понимаете, о чем говорит человек? Можно просить его расшифровать употребляемые термины. Также можно самостоятельно выделить их в речи или в тексте и попробовать прогуглить. Это позволит вам определить роль и ролевые интересы. Если есть какие-то роли, которые должны входить в ваш проектный ролевой кругозор или ролевой кругозор ваших сотрудников, но которые пока плохо понятны, можно специально изучать их. Также можно составлять «ролевой словарь» с объектами внимания (интересами) роли – для себя или для коллектива. Составление такого словаря или словаря / глоссария предприятия будет домашним заданием к главе.
