Requirement management (rus)

Знание UML как фактор влияния на карьеру и работу с заказчиком

Круглый стол  «Знание UML как фактор влияния на карьеру и работу с заказчиком»

ПОСТАНОВКА ТЕМЫ

Киселев Алексей

Предисловие

Недавно довелось побывать в компании практикующей UML с целью получить работу, однако всё прошло далеко не столь успешно, как хотелось бы – у меня возникли проблемы с созданием моделей UML и описанием сценариев. Всё бы хорошо, если бы все мои знания UML заканчивались прочтением википедии накануне. Но нет, весной 2010 года я проходил обучение в Luxoft, по итогам которого считал, что я в этом разбираюсь и всё хорошо. Однако, когда я за несколько дней начал повторять материал, то пришло осознание, что знания путаются.. Почему такое могло бы быть?

Проблема

На практике я use-cases никогда не использовал и модели не строил (ну, с некоторыми оговорками, но на 97% я в этом предложении не соврал). Понятно, что не имея целый год практики, да и изучив лишь азы, знания быстро забываются. Это было бы не так, если бы я пошел в компанию, которая всё это использует. Но нет, и что же я получаю сейчас: опыт я могу получить в основном в компаниях, которые используют use-cases и модели в своей работе, которые в свою очередь ищут сотрудников с данным опытом, а в итоге выходит замкнутый круг…

Примеры решения

Решения может быть два – сконцентрировать все мои ресурсы (финансовые и временные) и, настроившись на определенную вакансию, подтянуть знания. В принципе, это может занять год, и не дает гарантии прохождения интервью. Можно пойти стажером и плюнуть на более чем 3-х летний опыт работы аналитиком со всеми последствиями.

Киселев Алексей, Тарханов Павел

Вопросы

  1. В компаниях практическое применение UML является ключевым навыком при приеме кандидата (тогда почему этого не указывают в требованиях к кандидату)?
  2. Где пройти практику моделирования аналитику, если на его предыдущем месте работы UML не был принят как методика моделирования?
  3. Как “выкрутиться” аналитику, если он на предыдущем месте работы дорос до хорошей зарплаты без навыка моделирования UML, а при переходе на новое место его: либо не берут из-за отсутствия этого навыка, либо берут на существенное понижение з/п без установления конкретных сроков, когда эта з/п точно будет повышена по итогам “подтягивания” навыка.
  4. В текущей компании не используется UML и процесс хорошо поставлен, так ли важно знать UML или достаточно за неделю понять стандарты и шаблоны, выполняя самые простые задания?
  5. Как правильно учить UML и кому его учить необходимо?
  6. Что сейчас учат не так по UML?

ИТОГИ И ВЫВОДЫ

1. Знание UML – не главное в деятельности аналитика

Конечно, определять глубину знаний и навык работы соискателя в нотации UML – прерогатива работодателя, но это ли самый главный фактор при прохождении собеседования?
По результатам круглого стола, проведеного 17 августа в офисе компании Luxoft, мы пришли к общему мнению, что это не совсем так…
Следует отметить, что доверять следует тому работодателю, который на собеседовании пытается в первую очередь понять на сколько соискатель знает:

  • жизненный цикл разработки автоматизированной системы (программного средства)
  • деятельность аналитика (этапы работы аналитика)
  • результаты деятельности аналитика (наборы артефактов и их назначение)

Почему знание нотации UML уходит на второй план? Так как это, в первую очередь, инструмент моделирования проектных решений, он не столь важен на начальном этапе работы аналитика, которая начинается с определения проблемы, постановки цели, поиска ключевых заинтересованных лиц и т.д.
При ответе на вопрос (задание) работодателя можно обходиться без UML диаграмм, а начинать рассуждать:

  • выявлять сущности
  • определять проблемы и цели
  • устанавливать границы системы (исследуемой области)
  • выделять операции, комментируя каждый свой шаг

Даже если аналитик не знает UML, задавая правильные вопросы, он уже зарабатывает себе баллы. Главное – установить что именно хочет заказчик (пользователь), что программа (приложение или функция) должна делать в его понимании.
Компании, которые жестко и в первую очередь требуют знание UML, должны вызывать подозрение. Язык UML всегда можно изучить в довольно короткие сроки, а вот системное мышление дано не всем.
Есть ещё такие варианты развития событий, когда незнанием UML пытаются сбить зарплату соискателю. Аналитику снижают зарплату по причине незнания определенных  нотаций, диаграмм или тонкостей, без которых, по мнению работодателя, настоящему аналитику не обойтись. Позже может выясниться, что это вообще в данной компании не требуется. Следует заметить, что этот момент лежит на совести работодателя. Захотите ли вы работать в такой компании? Советы аналитику: по возможности выясните до собеседования или во время его, использует ли компания язык UML, в каком объеме, на каких уровнях взаимодействия, приняты ли соглашение о моделировании, есть ли опытные практики, как осуществляется обучение UML.
Если от вас до собеседования требуют решить задачки или пройти тесты (обычно удаленно), в которых используется UML –  это нормально. Этот момент носит характер “конкурентного отбора” и “отсева ошибочно забредших”.
Советы аналитику:
а) не надо пугаться таких заданий;
б) пытайтесь выяснить контекст, в котором необходимо начинать создавать диаграммы, на каком уровне абстракции, кто будет принимать результат;
в) узнайте, возможно ли моделировать без использования нотации UML, пользуясь при этом любым другим известным вам визуальным языком;
г) если же вы решились попробовать, вовсе не обязательно “рисовать” без единой ошибки (даже эксперты могут допускать грубые ошибки, поскольку мнений о правильности той или иной модели может быть несколько даже у устоявшейся и опытной проектной команды).
Взаимодействуйте с работодателем, давая понять уровень вашей аналитической подготовки, знаний и опыта работы на проектах, понимания процессов создания ПО и целей создания необходимых артефактов. Учтите: всё зависит от ваших нынешних познаний в UML. Возможно не имеет смысла и начинать решать подобные задачи, откровенно и прямо заявив об этом, сделав акцент на моментах, которые отражают ваш аналитический “багаж”. Как вариант, можете попробовать решить их для собственного развития (если позволяет время), с прицелом на будущее, обсудив результаты на uml2.ru.
Совет работодателю:
а) готовить адекватные тестовые задания, не требующие длительного мыслительного процесса;
б) помечать в тестах уровни сложности для определения уровня аналитика;
в) если тест единый для всех, то следует помечать, что принимается любой ответ в любых возможных нотациях или языках;
г) иметь собственные, правильные со своей точки зрения, ответы на тесты;
д) готовить специалистов HR к ответам на запросы (вопросы) аналитика, настоящий аналитик будет проявлять навык интервьюирования.
Следует отметить, что при собеседовании на должность младшего аналитика  вполне может быть поставлена задача – распознать диаграмму, найти очевидную ошибку в ней. Кстати, такие вопросы можно услышать и от HR агенств.
Если уж дело дошло до построения диаграмм и написания сценариев, то помните, что именно вы определяете то, как всё будет работать. На одну большую задачу  может быть множество различных решений , а следовательно – правильных наборов диаграмм вариантов использования и сценариев, главное – верная и обоснованная аргументация.
Итог
В заключении можно добавить следующее:

  1. При отсутствии навыка моделирования на UML аналитику желательно ознакомиться с основными диаграммами, используемыми в работе (диаграмма вариантов использования, диаграмма деятельности, диаграмма состояний, диаграмма классов), а так же элементами и связями.
  2. Аналитику требуется максимально посвятить время изучению процессов сбора требований, их оформления, а также процесса создания ПО.
  3. Проводить оценку аналитика на уровень компетентности в знании нотации UML работодатель может, но правильный работодатель не должен делать на этом акцент. На этом моменте аналитику следует сосредоточиться и самому “брать инициативу в руки”, пояснив работодателю, что идентификаторами и результатами деятельности аналитика являются не столько правильно нарисованные диаграммы, сколько навык умения работать с людьми, информацией, анализировать ее, синтезировать и оформлять в любом удобном читателю виде, будь то ГОСТ, Excel, BPMN etc.

2. UML и заказчик

UML, как язык взаимодействия проектной команды, не теряет позиции, и, кроме того, может являться удобным средством коммуникации с заказчиком. Однако, для бизнеса UML – не  самый лучший и удобный вариант. Диаграммы в нотации BPMN или ГОСТ являются более подходящими, поскольку они практически не требуют предварительной подготовки читателя для понимания.
Если же заказчик выставляет требования к использованию UML, то сразу следует понимать, что команда разработки должна обладать соответствующими навыками и иметь как минимум одного гуру-эксперта по данному требованию. Простого обучения неподготовленной проектной команды или прослушивания семинаров перед проектом не достаточно.
Иногда может возникнуть обратная ситуация: проектная команда знает и использует UML, но заказчик в этом вопросе некомпетентен. Может потребоваться дополнительное обучение заказчика, но это оправдано и, возможно, достаточно будет представить заказчику описание нотации (соглашение о моделировании).
Здесь же следует отметить, что язык UML больше предназначен для работы внутри проектной команды. Этот язык является прежде всего уровнем “проектных решений”, а не уровнем “выявления проблем и постановки целей”. Документы, с помощью которых мы общаемся на уровне бизнеса (заказчика), должны быть максимально просты, понятны и универсальны для всех, в том числе для топ-менеджмента. Если же заказчик технически подкован, имеет в своем арсенале архитекторов, аналитиков со знанием UML, которые могут его читать, то тогда без нотации UML нам, как исполнителю не обойтись.
Опять же, UML не есть цель – если заказчик беспричинно требует  использовать UML,  то это должно настораживать. Практика показывает, что многое должно быть описано текстом, иначе работа может просто “лечь в стол”. Почему?  Наличие одних лишь диаграмм в чистом виде не достаточно, они обязательно должны дополняться текстом. Любая модель должна состоять из двух частей – диаграммы и текстовой части, ведь диаграмма упрощает понимание визуализируя информацию. Например, вариант использования – это не окончательное проектное решение, оно дает ещё некоторую свободу в реализации, поэтому вся модель вариантов использования может видоизменяться неограниченное количество раз.
Если обратиться к оформлению требований в виде “Система должна…”, то в настоящее время этого уже не достаточно (хотя для заказной разработки по госпроектам только в таком виде требования и оформляются). Необходимо детальнее описывать кто и что делает в виде последовательности шагов сценариев и визуализировать с помощью любых диаграмм.
Формат документов (артефактов) должен быть согласован до начала проектной работы. Одним заказчикам удобнее использовать прототипы, другим – диаграммы и схемы. Для аналитиков они равнозначны, а лучше всего – использовать текстовое описание и диаграммы (UML, ГОСТ, BPMN etc.)  дополняя их прототипами.
Совет аналитику: необходимо учитывать, что с одной стороны он взаимодействует на уровне  менеджеров, пользователей систем и операторов, а с другой стороны с проектной командой. Очень важно учитывать и отрабатывать навыки коммуникации – это дает знания о том, с кем мы общаемся и его роль в проекте. Общайтесь, и проблемы будут рано или поздно решены.
Примечание: По мнению аудитории по BPMN есть хорошие курсы Анатолия Белойчука.

3. Правильно ли учат аналитиков?

В вопросе выбора обучения следует руководствоваться следующими критериями:

  1. Компетентность преподавателя и его опыт
  2. Четкая нацеленность курса на конкретный уровень подготовки слушателя: базовый, продвинутый, эксперт
  3. Хорошо проработанная теория  и большой объем практических занятий
  4. Учет занимаемой позиции/должности или роли обучаемого (аналитик, тестировщик, архитектор, дизайнер, разработчик). Например, можно разделить даже на бизнес/системных аналитиков, хотя учитывать, что частично методики перекрываются.
  5. Востребованность курсов и студентов после них

Для того, чтобы проверить, на сколько курс соответствует критериям и ожиданиям следует просмотреть его анонс, прочитать о преподавателе, посмотреть состав курса.  Очень важно убедиться в наличии в процессе обучения практических заданий (иногда они решаются в смежном курсе). На российском рынке на данный момент, в основном, представлены курсы для начинающих!
При обучении UML  следует понимать, что мы изучаем инструмент, а не процессы  создания ПО, или, например, “Методы интервьюирования заказчика” – это иной курс!
Рекомендуется проходить курсы по UML после изучения наиболее важных предметов деятельности аналитика. Без практического использования знания быстро забываются, а без предварительной базовой подготовки так и вообще пустая трата времени и существенные финансовые потери. Здесь можно сказать, что изучение  UML, как изучение иностранного языка – требует постоянной практики.
На сегодняшний день на российском рынке не существует ни одного семинара и курса с методикой преподавания UML, после которой можно с уверенностью и гарантией утверждать: “Ученик полностью готов правильно применять нотацию UML в проектной деятельности”. Как строить эту методику? Вопрос на круглом столе остался открытым.

4. Взаимодействие с разработчиками

Основная проблема, озвученная одним из присутствующих разработчиков – аналитик считает, что ему незачем тратить время на  создание и оформление UML-диаграмм, если достаточно описать это текстом.  Тем не менее, нам, аналитикам , надо работать так, чтобы разработчик всё понял однозначно и, желательно, в кратчайшие сроки (это, кстати, политика  одного крупного системного интегратора в США, где разработчики могут предъявлять требования к постановкам на разработку).
Гораздо лучше, если постановка передается в работу после того, как разработчики и тестировщики ее посмотрели (проработали совместно), так они могут найти  дополнительные альтернативные сценарии, либо иные проблемы. Это уже вопрос тестирования требований и проектного управления, он выходит за рамки  круглого стола.
Совет аналитику: Ищите среди проектной команды коллег, знающих UML или проявляющих к нему интерес, договаривайтесь внутри команды о языке взаимодействия (соглашениях о моделировании) и держите в курсе вашего интереса менеджера проекта. За внедрение UML  в компании ответственно руководство, но, инициатива может идти от аналитиков, разработчиков и тестировщиков.

5. Вместо заключения

“У страха глаза велики”
Народная мудрость

Общий вывод, который мы сделали по итогам круглого стола, такой: UML – это не панацея от всех бед, встающих на тернистом пути аналитика при работе с заказчиком и информацией, тем более не обязательный и ключевой инструмент, требующийся в работе. Знание UML является хорошим довеском к наиболее важным и ключевым навыкам аналитика (преимущественно “системного аналитика”), таким как: коммуникации, анализ, синтез, работа с информацией и документирование. Язык UML всегда можно изучить в довольно короткие сроки, а вот навыки системного мышления даются с трудом и далеко не всем.

Тарханов Павел
Linkedin: http://ru.linkedin.com/in/ptarkhanov
Киселев Алексей
Мой Круг: http://akiselev87.moikrug.ru/

Большое спасибо Александру Белину и Александру Байкину за активное участие в КС и множество полезной информации.

Публикация на uml2.ru.

Рекомендуемый софт

CaseComplete  – платный софт, с возможностью построения диаграмм на основании описанных сценариев использования. Ссылка: http://www.casecomplete.com/
TopCased – бесплатный софт для построения диаграмм , ссылка: http://www.topcased.org/

Advertisements
Standard

6 thoughts on “Знание UML как фактор влияния на карьеру и работу с заказчиком

  1. Дмитрий Митяев says:

    Алексей, а можно поподробнее что именно не устроило компанию на собеседовании в построении UML? Можно по e-mail’у.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s