Недавно я прочитал, что Дэвид Кэмерон не понял, что было написано в White paper о реструктуризации NHS в Великобритании. Он был сбит с толку языком и сокращениями.
Эта ситуация напомнила мне, как в прошлом году я участвовал на конференции с рядом британских бизнес-школ, где мы обсуждали, чего бизнес хочет от студентов. Я был третьим спикером, и на руках была уже заготовленная речь. Так было, пока не начал выступление первый спикер. Он был руководителем крупного производителя, и я не понял ни слова из его речи. Тоже самое произошло и со следующим спикером: он говорил о чем-то, а я продолжал не понимать, о чем он говорил. В этот момент промелькнула мысль: либо я не на той конференции, либо они не общаются, а просто передают информацию.
В итоге свое выступление я начал с того, что честно признался в том, что понятия не имею, о чем говорили предыдущие спикеры. И моя речь уже в этот момент базировалось на том, что бизнесу нужно проявлять сочувствие и понимание по отношению к студентам, делать лучше не только себя, но и всех вокруг.
При этом я работаю в IT-индустрии, где ситуация еще хуже с общим языком и пониманием.
Одинаковое название, но разное содержание
На другой крупной отраслевой конференции очень уважаемый высокопоставленный деятель IT-отрасли сказал, что «все знают, что такое бизнес-аналитик или менеджер проекта», и продолжил объяснять, что это стандартные постоянные роли для всех организаций. К сожалению, мой опыт показывает, что не всегда это оказывается так!
За последние 10 с лишним лет я регулярно встречаю людей с одинаковым названием должности, но с очень разным набором обязанностей, навыков и опыта. Даже в рамках одной компании можно найти группу бизнес-аналитиков, которые все свое время проводят за составлением спецификаций бизнес-требований, и другую группу бизнес-аналитиков с таким же названием, которые также вносят свой вклад в бизнес-обоснование и составляют план приемочного тестирования. Таким образом, есть две группы людей с одинаковым названием должности, но с очень разными профилями навыков – некоторые навыки являются общими, другие появляются только в одном из двух описаний должностей или профилей ролей.
Даже когда мы используем одну и ту же терминологию, у нас не всегда есть однозначное представление о том, что она означает, что снова приводит к тому, что нам сложно поддерживать коммуникацию между людьми, понимать друг друга, чтобы не возникало таких ситуаций, как на вышеуказанных конференциях.
Шесть аргументов против «индивидуальности»
Я регулярно сталкиваюсь с организациями, которые развили собственный набор навыков и компетенций. И вот шесть причин, почему не стоит так делать.
1. Экономия времени
Зачем тратить время на создание того, что уже было создано?
2. Стандартизация
Почему бы не использовать существующую структуру, которая дает последовательные определения и была принята почти в 200 странах?
Пример. Если вы используете свой собственный язык для структуры навыков, кандидаты при приеме на работу, скорее всего, неправильно поймут или истолкуют его, поскольку они использовали другой язык, работая у своих предыдущих работодателях. К тому же, это заметно усложняет период адаптации сотрудника.
3. Упрощение
Мы полагаемся на фреймворки – методологии, своды знаний, международные стандарты, такие как Prince2 и PMBoK в управлении проектами, BABoK в бизнес-анализе, ITIL и VeriSM и ISO/IEC 20000 для управления услугами, DevOps, COBIT, Agile, Scrum, SIAM, ISO/IEC 9001 для управления качеством, NIST и ISO/IEC 27001 для информационной безопасности, .NET и другие языки для разработки программного обеспечения. Список бесконечен, и они неоценимы для повышения согласованности, качества и эффективности. Но сколько терминов, навыков и компетенций дает каждая из них?
4. Полнота
Внутренняя структура компании вряд ли будет охватывать всю основу принятой во всем мире отраслевой структуры, которая существует уже более 20 лет и регулярно обновляется людьми, которые используют эту структуру в компаниях по всему миру. По моему опыту, большинство внутренних структур или KSA (Знания, Навыки и Действия) довольно быстро устаревают, поскольку внутренней команде сложно отслеживать все события в отрасли и различные специализированные технологические дисциплины.
5. Согласованность
Многие из вышеупомянутых структур согласованы с признанной структурой навыков, и предложения от провайдеров обучения также согласуются с этими структурами, что упрощает подбор людей для наиболее подходящей деятельности по разработке.
6. Основная компетенция
Вы действительно хотите заниматься написанием и поддержкой индивидуальных фреймворков? Сложности управления специализированными ресурсами в дисциплинах, зависящих от технологии, не поможет из-за риска недопонимания и непоследовательной интерпретации из-за отсутствия общего языка.
Есть несколько различных фреймворков навыков и компетенций, которые можно рассмотреть. Ключевой момент заключается в том, что нет смысла пытаться создать или поддерживать структуру навыков, которая актуальна только для вашей организации, когда есть зрелый и регулярно обновляемый принятый на международном уровне набор стандартизированных определений навыков для цифровых, ИКТ, кибербезопасности и других технологических сфер, которые используют почти двести стран. Использовать один набор или три вместе взятые, выбор за вами.
Читайте также: