что такое функциональная карта
Методика и правила формирования функциональной карты профессии и видов профессиональных компетенций специалистов
Методика и правила формирования функциональной карты профессии и видов профессиональных компетенций специалистов
Модели ключевых профессиональных компетенций для освоения профессии основаны на анализе трудовой деятельности и требований к ее результатам и подлежат постоянному мониторингу и обновлению по мере изменений в содержании трудовой деятельности.
Предлагаемая процедура разработки модели базируется на методе функционального анализа, а именно, на выявлении функций, которые должны выполняться в конкретной области профессиональной деятельности, а не на описании того, кто их выполняет. Другими словами, отправная точка формирования модели– анализ трудовой деятельности. В качестве инструмента формирования модели профессиональных компетенций можно взять функциональную карту профессии (специальности)
Функциональная карта профессии (специальности) включает в себя основную цель профессии и содержит все виды трудовой деятельности и основные трудовые функции (рис. 1)
Правила разработки функциональной карты
Разработка проекта функциональной карты и первичного списка знаний, умений и ключевых компетенций, а также примерного перечня средств и предметов труда для выполнения функций, которые являются основой для формирования образовательной программы (учебных модулей программы), а также анкет, используемых в дальнейшем при проведении опросов предприятий и работодателей.
Основная цель данного этапа работы состоит в выявлении функций, которые выполняют работники, занятые в конкретной области профессиональной деятельности на различных предприятиях, и, как производную от этих функций – в обобщенном виде – тех знаний, умений и ключевых компетенций, которые необходимы для выполнения этих функций. Обработанные первичные данные, составляют основу для разработки анкеты, необходимой для проведения масштабного опроса работодателей и профессионалов.
Разработка функциональной карты начинается с формулировки основной цели области профессиональной деятельности. Основная цель области профессиональной деятельности кратко описывает суммарный результат того, для чего предназначена данная область профессиональной деятельности.
Примеры описания основной цели:
Область профессиональной деятельности
Производство деталей и сборочных единиц машиностроения на станках различных типов
Рационально изготавливать детали на различных типах станков, в том числе и на станках с ЧПУ
Организовывать производство деталей и сборочных единиц для машиностроения
Обслуживание посетителей на предприятиях питания
Подготовить зал к обслуживанию посетителей и обслужить посетителей
Осуществлять техническое оборудование и ремонт различных типов автомобильного транспорта
Производство продукции на предприятиях питания
Подготавливать продукты и производить продукцию в соответствии с требованиями к безопасности готовой продукции для различных категорий потребителей
Диагностировать и устранять неисправности в компьютерном оборудовании и программном обеспечении
Основная цель описывается по следующей схеме:
глагол в неопределенной форме – объект действия – область осуществления деятельности (направленность действия) или конечный потребитель.
После описания основной цели следует ее поэтапная конкретизация. На первом этапе осуществляется описание видов трудовой деятельности, объединенных общим назначением и охватывающих интегрированную группу функций. Например, «подготовить оборудование и инструмент к производству», «контролировать процесс производства», «организовывать процесс производства» и т. д.
На следующем этапе происходит вычленение конкретных функций из обобщенных видов трудовой деятельности, т. е. каждый вид трудовой деятельности далее подразделяется на набор составляющих ее трудовых функций. Каждая конкретная функция должна представлять собой отдельный законченный элемент трудовой деятельности, требующий собственных методов, материалов, оборудования и процессов.
Так, например, обобщенная функциональная область «подготовить оборудование и инструмент к производству» может распадаться на 2 конкретные функции: «подготовить оборудование» и «подготовить инструмент», которые будут иметь схожее предназначение, но различаться с точки зрения предмета труда.
Возможные принципы классификации при формулировании обобщенных функциональных областей:
- линейный (например, разработка проекта, реализация); циклический (подготовка к осуществлению процесса, реализация о процесса, проверка качества); по используемым методам и процессам; по характеру действий/ продукции или результатам.
Выбор принципа классификации зависит от характера области профессиональной деятельности. Решение о принципе классификации принимается экспертной/рабочей группой.
Функциональная карта профессии (специальности) оформляется в виде таблицы с определенными правилами нумерации.
Виды трудовой деятельности (ВТД) обозначаются арабскими цифрами – 1, 2, 3, 4 и т. д. Для обозначения конкретной функции к номеру ВТД через точку добавляются цифры, обозначающие номера конкретных функций – 1.1, 1.2, 4.1, 5.2 и т. д.
Помимо собственно профессиональных функций (аспектов профессиональных компетенций) в функциональной карте описываются надпрофессиональные функции (ключевые общеобразовательные) и специальные функции, т. е. те функции, которые работодатель ожидает от работника в любой области профессиональной деятельности.
Возможный набор таких функций может включать в себя следующие:
организовать процесс собственного труда и вносить предложения по совершенствованию организации труда;
соблюдать требования охраны труда и защиты окружающей среды;
эффективно взаимодействовать с коллегами, руководством и клиентами.
Эти функции обозначаются арабскими цифрами 01, 02, 03 и т. д. Набор надпрофессиональных функций может варьировать в зависимости от области профессиональной деятельности. Описание надпрофессиональных функций (требуемых общеобразовательных компетенций и их уровней) помещается внизу функциональной карты.
Ликбез по техническому заданию
Польза: получите знания о том, что такое ТЗ и как его составить. Обогатите словарный запас словами: концептуальная модель, data flow, mind card, user flow. use cases, wireframes, ER-model, client-server, API.
Для кого: начинающим разработчикам и желающим чтобы их поняли (заказчикам, стартапам и менеджерам).
Время чтения: 7 минут.
Отправная точка — требования
Хочу пирожное, потом морожное!
Вовка в тридевятом царстве
Существует распространенное заблуждение, что достаточно сказать: “Нужно приложение для музея/кошки/завода” и сразу станет понятно, что вам необходимо.
К сожалению, все не так просто. Представьте, что вам нужно построить дом. Вы идете к строителю, и он приступает к работе. Вы не предоставили ему ни чертежей, ни участка, даже не сказали какого цвета должен быть забор. Но дали на все про все полгода и значительную сумму денег.
Жутко правда? Бюджет уже потрачен и срок истек.
Чтобы такого не произошло все требования к продукту фиксируют, это и есть то, с чего начинается любая разработка.
Удобный вид требований — ТЗ
Замесить и нарубить!
Вовка в тридевятом царстве
Хорошо. Будут требования. Теперь вас точно поймут разработчики. Но тут возникает подводный камень №1: человечество пока не научилось читать мысли. Поэтому нужно в каком-то виде передать информацию и лучший для этого способ — Техническое задание.
Его также называют ТЗ, SRS, PRD — все это названия документа, в котором в правильной форме зафиксированы требования к продукту.
Рецепт грамотного ТЗ
Техническое задание для разработчиков это своеобразный рецепт приготовления успешного продукта. Успешный продукт — тот, который легко поддерживать, можно развивать и менять, он не развалиться при смене разработчика и приносит прибыль в любом ее виде. Вы хотите, чтобы ваш проект был полноценным? Отлично. Напишите для этого хороший рецепт. Классическими ингредиентами (по международному стандарту IEEE-830) служат:
Ниже я разберу подробно каждый из пунктов. Для тех, кому не хочется подробно разобраться, оставляю ссылку на международный стандарт c шаблоном технического задания: ссылка на документ.
Концептуальная модель
В этот пункт входит краткое описание продукта, в нем отражается цель проекта и его отличительные черты.
Например: “Приложение для знакомств, в котором можно смотреть короткие видео в профилях пользователей и общаться в чате”.Также не помешает сказать пару слов об аудитории продукта, так команда проекта сможет понять его особенности и дать вам несколько полезных советов. Расскажите о ее возрасте, характере и территориальном расположении, каких-то особенностях, которые должны отразиться на проекте.
Например: “Это молодые люди, выезжающие за рубеж для отдыха и интересующиеся общением за пределами языкового барьера, которые любят снимать фото и видео”.
Стоит рассказать о типах пользователей и их ключевых отличиях.
Например: “В приложении должны быть обычные пользователи и модераторы, которые получают жалобы от пользователей на контент или профили. Модераторы могут просматривать чат обычных пользователей после жалобы и заблокировать в сервисе нарушающий правила аккаунт”.
И в завершении расскажите о компонентах вашего продукта.
Например: панель администратора, которую используют модераторы; мобильное приложение, которое использует пользователь, чтобы зарегистрироваться, добавить контент, поучаствовать в чате и т.д.
Высшим пилотажем будет сделать так называемый data flow или контекстную диаграмму, в которой будет отражено как пользователи взаимодействуют с продуктом, его компонентами и между собой.
Функциональная карта
Функциональная карта отображает общую концепцию проекта с уровнем детализации необходимым для того, чтобы оценить объем работ, расставить приоритеты.В традиционном формате такая карта напоминает карту сайта. Но удобнее всего ее отобразить в виде mind card (майнд карт, интеллект карт). Часто менеджеры рисуют на совещании на доске или листе бумаги слова и между ними связи, так вот, это и есть майнд карта. Это можно сделать удобно в бесплатных сервисах (coggle, draw.io и mindmeister) или просто в Office Word.
Очень важно отразить в функциональной карте все пользовательские особенности. В первом приближении это просто набор функций продукта.
Например: “В приложении должна быть регистрация по почте, создание и заполнение данных профиля,, возможность загрузить и отредактировать фото и видео, список аккаунтов других пользователей с различными типами фильтров, текстовый чат, обращение к службе поддержки.
Путь пользователя
Так называемый user flow или путь пользователя, это последовательный список действий или экранов, по которым может переходить пользователь в процессе взаимодействия с продуктом. Опишите, как в вашем представлении будет взаимодействовать с продуктом пользователь. Очень удобно это можно сделать также майнд картой или просто списком действий.
Например: “Пользователь заходит в приложение, чтобы познакомиться с сверстниками. Он заполняет свой профиль данными и загружает фото и видео. Затем пользователь заходит в ленту и фильтрует ее по каким-либо критериям. В качестве результата он получает список релевантных профилей, может посмотреть их и написать другому пользователю в чате.
Путь пользователя — это общий алгоритм работы с продуктом. Также существует еще use cases (варианты использования) — это детализация user flow. В случае мобильного приложения для знакомств вы создали путь пользователя по экранам, а затем описываете, что пользователь может сделать на каждом экране.
Например: на экране регистрации пользователь может:
перейти на экран авторизациизарегистрироваться через соцсети (Facebook, Twitter)может ввести почту, пароль, затем его повторить и подтвердить регистрацию в письме, пришедшем на почту.
Пользовательский интерфейс
Продукт должен мало того что работать, так еще и приятно выглядеть. Немного отойдем от тематики приложений, чтобы не заставлять вас их скачивать для ознакомления. Лучше посмотрим на симпатичные сайты:
Опишите в общем виде, каким вы хотите видеть свой продукт, какие у него должны быть цвета, какие элементы использоваться, какую вы хотите анимацию и т.д. Если у вас есть фирменный стиль или брендбук, отлично, сошлитесь на них.
Дизайнеры скажут вам большое спасибо, если вы укажите стиль дизайна интерфейса, например flat design или material design.
Высшим пилотажем будет добавить wireframes (вайрфреймы) — прототипы интерфейса продукта в виде приближенных схем.
Программные интерфейсы
Этот раздел для специалистов. Если вы уверены в своих силах, то продолжайте чтение.В лучшем техническом задании также описывается архитектура продукта, то есть то, из каких программных компонентов он состоит. В случае клиент-серверного приложения для знакомств сервис разбивается на часть сервера, которая хранит данные и обрабатывает их, производит какие-то логические операции и часть клиента, который отображает данные.
Сервер декомпозируется на модули: базы данных, аутентификации, чата и т.д.Клиент связывается с сервером через API (интерфейсы передачи данных), стоит указать его тип (REST, WEB, RPC и т.д.) и описать методы, ответы и обработку ошибок.
Данные обычно хранятся в базе данных в виде специальных структур, чаще всего таблиц (для реляционных БД) и json структур (для нереляционных). Разработчики скажут вам огромное спасибо, если в техническом задании вы укажите сущности базы данных (ER-модели) и опишите хранимые поля, с указанием их типов данных (string, int и т.д), ключей (primary, foreign), обязательности (required) и пустого значения (nullable).
Нефункциональные требования
Это общие требования к продукту. Их можно разделить на требования к техническому обеспечению, требования безопасности и требования к производительности.В требованиях к техническому обеспечению указывают пожелания к устройствам и операционной среде, например для приложения знакомств это Android 7.0+ и JDK 8+, iOS 11.0+ и Swift 4.2.
В требованиях к безопасности можно указать, что передача данных в чате должна осуществлять с помощью шифрования SHA-1 и что при регистрации сложность пароля должна быть не менее 8 бит.В требованиях к производительности говорится о связи компонентов и отказоустойчивости, например стоит указать, что таймаут на чтение сообщения в чате не более 1 с и что приложении частично хранит кеш и может ограниченное время работать в автономном режиме.
Функциональные карты и диаграммы вариантов использования
Сегодня несколько слов о техниках работы бизнес-аналитика. Уже пару десятков лет основной техникой моделирования функционала информационных систем является разработка вариантов использования (use cases). Техника, действительно, неплохая. Особенно если бизнес-аналитик прочитал книжку Алистера Коберна «Современные методы моделирования функциональных требований» или посетил учебный курс по разработке юзкейсов. Однако визуализация вариантов использования в виде соответствующей UML диаграммы до сих пор вызывает сдержанную ухмылку у разработчиков и легкое недоумение у функциональных заказчиков. Пару месяцев назад в заметке Так ли уж близки корпоративная архитектура и бизнес-процессы? я писал о том, что на уровне бизнес-архитектуры никто никаких юзкейсов не рисует. Для отображения деятельности организации используется Business Capability Map – техника, позволяющая отобразить все виды деятельности предприятия на одной картинке. Довольно часто звучит и другой термин: функциональная карта. Что это такое и как использовать эту карту в проектах я позволю себе изложить в виде небольшой истории о вымышленном проекте разработки системы управления инцидентами, рассказанной от лица ведущего бизнес-аналитика этого проекта.
Как-то утром, когда завтрак уже давно кончился, а обед еще не думал начинаться, в нашу комнату влетел руководитель службы бизнес-анализа. Сбивая на своем пути зазевавшихся молоденьких сотрудниц и отчаянно жестикулируя, он подлетел к моему рабочему столу и срывающимся голосом заорал: «Когда?… Почему! Где?! Где функциональные требования?». Я тяжело вздохнул, пытаясь догадаться, о чем собственно идет речь. Даже пару раз попытался перебить его, чтоб задать этот вопрос, но потом решил дать руководителю немного остыть. Минут через десять руководитель службы немного успокоился и сумел объяснить, что речь идет о системе управления инцидентами. Только что он был на планерке у Директора по ИТ, который устроил всем грандиозный разнос за отсутствие в нашей организации этой замечательной системы. Департамент эксплуатации ИТ-систем, являющийся основным заказчиком такой системы, и Служба разработки ИТ-решений перевели все стрелки на нас, заявив, что система управления инцидентами уже пару лет остается абстрактной мечтой, потому что служба бизнес-анализа так и не удосужилась собрать требования. Резонное возражение, что с такой задачей к нам никто не обращался, естественно, не возымело действия, и уже через полчаса мы сидели в кабинете руководителя департамента эксплуатации и выслушивали его рассказ о космических кораблях, бороздящих просторы…
Из этого разговора я вынес совсем немного. Оказывается, наша служба поддержки разделена на два уровня. На первом уровне работают начинающие специалисты, не способные решить большинство поступающих проблем. Какие-то инциденты они решают, но их основное занятие заключается в направлении запросов на ту или иную группу сотрудников второго уровня. И вообще самое главное, чтоб пользователи самостоятельно подтверждали закрытие инцидентов, потому что с ними подписан соответствующий SLA. Набросав в visio простенькую UML диаграмму, остаток дня я посвятил строительству веселой фермы.
Без пяти девять утра следующего дня я уже стоял с красиво распечатанным рисунком у кабинета руководителя департамента эксплуатации.
– Что это у тебя? – поинтересовался руководитель департамента, выходя из своего кабинета.
– ЮэМэЛь диаграмма вариантов использования – отрапортовал я без малейшей запинки, протягивая ему картинку.
Он нацепил очки, взял мой рисунок и на несколько секунд опустил на него взгляд. Когда руководитель службы эксплуатации вновь поднял голову, я по косвенным признакам сообразил, что картинка ему понравилась как-то не очень. Наверное, такое же выражение лица, сочетающее сдерживаемый гнев и полную безнадежность, бывает у него от известия о случившейся проблеме минус первого приоритета.
– Пойдем! – сдерживая гнев прошипел он и, размахивая картинкой, потащил меня в кабинет директора по ИТ.
Директор, как назло, оказался в своем кабинете. Вместе с ним за столом сидели еще двое и о чем-то оживленно беседовали. Одного из участников обсуждения я знал. Он работал у нас в проектном офисе. Другой же человек, в строгом деловом костюме, был мне незнаком.
Прервав обсуждение, ни с кем не поздоровавшись, руководитель департамента эксплуатации подошел к директору и, пробурчав: «Как Вы думаете, что это?», сунул ему мой рисунок. Взглянув на рисунок, директор улыбнулся и добродушно ответил: «Пляшущие человечки, я полагаю». Он небрежно передал мой рисунок другим собеседникам, которые тут же принялись его заинтересованно разглядывать, а сам обратился к руководителю департамента эксплуатации:
– Очень хорошо, что ты зашел. Присаживайся. Я решил оформить эти работы отдельным проектом, и мы как раз обсуждаем систему управления инцидентами с будущим менеджером проекта и внешним консультантом. Вот и еще один участник команды к нам присоединился – отметил ИТ директор, бросив на меня недолгий, но пристальный взгляд, от которого мне стало как-то не по себе. Я и руководитель службы эксплуатации сели за стол.
– Мы не будем больше рисовать такие картинки – безапелляционно заявил человек в строгом деловом костюме, идентифицированный мною, как внешний консультант. Он достал из своей папки другой рисунок и протянул его руководителю департамента эксплуатации. — Это функциональная карта типового решения по управлению инцидентами. Отметьте галочкой те функции, которые необходимы Вам в первую очередь.
Руководитель департамента эксплуатации достал авторучку и принялся последовательно расставлять галки в каждом прямоугольнике, стараясь ничего не пропустить. Некоторые он даже обвел кругом, а затем, вероятно, для пущей убедительности нарисовал несколько стрелок и положил рисунок в центр стола, чтоб его могли видеть все участники встречи.
– Отлично! – резюмировал консультант и передвинул листок менеджеру проекта. – Вот наш scope. По этой карте мы будем отслеживать прогресс на всех фазах проекта, начиная с уточнения требований и вплоть до ввода системы в эксплуатацию. Впрочем, и после запуска системы функциональная карта нам еще пригодится.
Не понимая до конца, что следует делать с этим рисунком, но услышав слово «требования» и проассоциировав их с бизнес-анализом, проектный менеджер передал рисунок мне. На этом встреча закончилась. Я взял рисунок и вместе с участниками встречи покинул кабинет директора. В приемной консультант остановил меня и сунул мне еще один рисунок:
– Смотрите! – дружелюбно проговорил консультант – На следующей встрече нам надо будет определить действующих лиц решения и сопоставить их с функциональной картой. Это похоже на Вашу диаграмму, только без тощих человечков и эллипсов. Возьмите за основу этот рисунок.
Вернувшись на свое рабочее место, абсолютно счастливый тем, что все так удачно сложилось, я быстро отсканировал картинку и отправил её проектному менеджеру в качестве сопроводительных материалов для следующей встречи, намереваясь посвятить остаток рабочего дня обустройству веселой фермы. Однако после обеда раздался звонок. Менеджер проекта управления инцидентами ехидно поинтересовался, как у меня дела, и спросил, не желаю ли я вместе с ним поработать над границами проекта. Пришлось тащиться к нему и выслушивать утомительные рассуждения о том, что запуститься следует всего через шесть недель, и если не удастся сузить рамки проекта, то митигировать риски срыва сроков будет решительно невозможно. В общем, он потребовал, чтоб к завтрашней встрече с разработчиками я указал на функциональной карте стадии проекта и приоритеты требований. К счастью, в нашей службе бизнес-анализа работало достаточное количество молодых привлекательных сотрудниц, и одной из них я перепоручил эту мегаважную и необычайно срочную задачу. Получилось у неё примерно следующее:
Слегка пожурив её за унылую цветовую гамму и излишне формальный подход, следующим утром я вместе с менеджером проекта отправился на встречу с разработчиками. Тем уже было известно про наше новое развлечение в виде системы управления инцидентами, и встретили они нас во всеоружии. В ходе этой встречи мы узнали много нового, в частности, то, что служба бизнес-анализа и проектный офис у нас полные идиоты, совершенно не разбирающиеся в информационных системах (уверен, это замечание относилось не лично к нам, а скорее к молодой сотруднице, готовившей картинку). Также мы узнали, что еще полтора года назад компания закупила лицензии на программный продукт «Сервис-менеджер», на котором и следует реализовывать проект. Кроме того разработчики осыпали нас градом непонятных слов, из которых я сумел запомнить только малую часть. Чаще других звучали айтил, ЕэСБи и еще какие-то трехбуквенные сокращения. В общем, сплошной ТиСиПи-АйПи. В какой-то момент они начали ругаться друг с другом, обсуждая, следует ли дозакупить недостающие лицензии или «нафигачить экранную форму в интранете». Затем позвали начальника отдела интранет-решений и повесили на него задачу разработки формы для заведения и закрытия инцидентов. В конечном счете руководитель службы разработки отобрал у меня исходную картинку, нарисованную консультантом и, пообещав к завтрашнему утру самостоятельно нарисовать правильное решение, вместе с проектным менеджером выгнал с совещания.
На следующее утро в почтовом ящике я обнаружил новый рисунок. Я удалил с него несущественные технические детали: названия серверов, пиктограммы баз данных и прочую муть и в таком виде отправил его консультанту:
Получил в ответ письмо благодарности за отличную работу и переслав его своему непосредственному руководителю, я смог, наконец, забыть об этой суматошной задаче. Снова задача напомнила о себе ближе к осени, когда на веселой ферме приближался сезон дождей.
Позвонил проектный менеджер и сказал, что завтра у него управляющий комитет с докладом о статусе проекта. Что разработчики практически ничего не сделали, а тестирование прошли два модуля из восьми. Впрочем, проблема понятна. Дело в том, что нам хронически не хватает программистов на си-плюс-плюс и юзабилити дизайнеров для интранет-сайта. А еще, оказывается, отправка смс сообщений с компьютера стоит денег. Мы должны что-то платить алчному оператору связи, и чтоб рассчитать эту сумму, нужны нефункциональные требования. Одним словом, в итоге во всем оказались виноваты бизнес-аналитики. Я понял, что просто так мне не отвертеться, и позвонил консультанту, попросив его помочь в подготовке к завтрашней встрече. Он оказался на удивление отзывчивым человеком и к утру прислал следующую картинку:
Видели бы вы, с каким апломбом проектный менеджер докладывал по этой картинке статус проекта. Он рассказал и про цветовую легенду функциональной карты, отображающую статус работ по конкретной задачи, и о пиктограммах, визуализирующих уже протестированные модули, и про С++, и про важность эргономичного пользовательского интерфейса, и даже поставил под сомнение целесообразность смс-уведомлений. В общем, все, наконец, поняли, что во всем виноваты вовсе не аналитики. В отличие от разработчиков и тестировщиков, нас с проектным офисом даже похвалили. А в конце квартала мне выписали хорошую премию. И теперь я регулярно рассказываю о преимуществах функциональных карт перед диаграммами вариантов использования. Все у нас стали описывать функциональность именно так. Хотя порой мне немного жаль, что мы отказались от UML диаграмм. Ведь функциональная карта — источник постоянных споров и разногласий в нашем дружном коллективе. Разработчики, администраторы, проектные менеджеры и даже заказчики постоянно что-то на них зачеркивают, обводят и исправляют. С UML диаграммами такого не было. Потому что это стандарт! К тому же, диаграмма вариантов использования — единственная картинка, которую в этом проекте я нарисовал сам.
Другие статьи по теме:
Канал «Архитектура ИС» в Telegram: https://t.me/it_arch
UPDATE: 4 июля 2018 года в ВШБИ( Москва, улица Трифоновская, д. 57, корп. 1) бесплатный вебинар по этой теме. Обязательная регистрация по этой ссылке