Как стать автором
Обновить

Матрица компетенций аналитика для самурая в запасе

Время на прочтение 28 мин
Количество просмотров 42K
Всего голосов 69: ↑63 и ↓6 +57
Комментарии 32

Комментарии 32

Добрый день. Очень познавательная статья, спасибо за материал. Вы упомянули несколько курсов и сертификатов по ним в рамках раздела "Средство для повышения уверенности". Все они имеют не низкую стоимость, получение всех перечисленных сертификатов обойдется довольно дорого. Вопрос: есть ли бесплатные аналоги перечисленных курсов и сертификатов или, хотя бы, более дешевые, которое Вы, как руководитель, посчитали бы для себя достаточными в качестве подтверждения квалификации аналитика? И, если есть, не могли бы Вы привести несколько примеров?

Бесплатные сертификаты можно получить, разве только, на ресурсе intuit.ru, пройдя тестирование по соответствующим курсам. Я бы предостерег Вас от получения ВСЕХ перечисленных сертификатов. Как бы с водой не выплеснуть ребенка. В случае начинающего аналитика для меня интересны только сертификаты базового уровня по SQL и по BMP (их стоимость минимальна по сравнению с другими сертификатами для аналитика). Именно получение этих сертификатов я рекомендую своим начинающим аналитикам. Все остальные - по желанию и по необходимости.

Не аналитик а программист, но диаграмма, приведенная в первом абзаце статьи настолько субъективна, насколько субъективным является любой собеседование.

Я могу, немного утрируя, составить диаграмму, по которой Джозеф Сиджин не пройдет джуниором в лабу Епама.

Я еще понимаю когда компании уровня Яндекса так фокусируются на алгоритмах всяких Б-деревьев и прочих численных методов — у них тысячи кандидатов, им нужно отсеять банально глупых и не до индивидуальных подходов. Но чем меньше про такие диаграммы будут думать интервьюеры обычных <100 айти-компаний — тем быстрее найдут себе в штат хороших специалистов.

В статье нет рекомендаций применять матрицу Д. Сиджина на собеседованиях. Для меня она послужила неплохим путеводителем на пути моего личного профессионального роста, высветив темные пятна на которые я не обращал внимания. С моей точки зрения, любая матрица компетенций - всегда только инструмент. И как для любого инструмента, результат его применения очень сильно зависит от целей того, как Вы собираетесь этот инструмент использовать. В частности от того, где Вы собираетесь поставить запятую в предложении: "Топить не стоит помогать".

Всё это словоблудие и изощренная детализированность терминами текущего дня, заменяются чем-то вроде «Начальника отдела» среднего звена.

По моему опыту, к сожалению, в комментариях на Хабре слово "словоблудие" очень часто является заменой словосочетанию "я ничего не понял". Если у Вас есть на затронутую тему собственная позиция - Вы можете отразить ее в своих статьях. Удачи.

Мне, например, понятно все что вы хотели сказать, но я повторяю утверждение предыдущего автора замечения: всё это словоблудие. При чем иногда злостное и высосанное из пальца.
В реальности аналитик в качестве задания получает:
— заказчика со стадом тараканов в голове; фантазиями и скрытыми целями всевозможных видов; своей тяжелой ношей, которую он надеется решить с помощью задачи, решение которой он от тебя ждет;
— 10 задач, которые как-бы записаны, но настоящее их описание надо спрашивать все у того-же заказчика;
— полувменяемое руководство, которое знает срок решения любой задачи до того, как задача будет сформулирована;
— тяжелонаследную систему с документацией существенно устаревшей еще лет 10 назад;
— абсолютную недоступность либо недостоверность либо кардинальную неточность всех внешних знаний о работе системы. И как следствие абсолютное и тщательно скрываемое нежелание людей делиться информацией которую они добыли собственным трудом;
— людская ложь всевозможных видов и всевозможных степеней, немыслимые подковерные манипуляции начальников и заказчиков это обыденная среда для аналитика.
90% того о чем вы пишите никогда не встречается в работе обычного системного аналитика. Именно поэтому ваша статья — словоблудие. Все упомянутые технические знания требуются по умолчанию, но не играют существенной роли.

Все, что Вы перечислили - это проблемы заказчика и условия программных проектов. Зачастую, это все так. Как решаю эти проблемы на своих проектах, я писал в предыдущих статьях. Однако, эта статья о другом. Здесь я говорю о путях личного совершенствования сотрудника (в рамках одной из ролей проектной группы). Другими словами - Вы говорите о боли пациентов, симптомах болезней, об условиях, с которыми часто встречаешься в больницах. А я - о квалификации определенной категории врачей, которые входят в состав операционной бригады и , что важно для меня, о их мотивах в профессии.

"В реальности аналитик в качестве задания получает:... " - на то он и аналитик. Все перечисленное - его мастер-данные, в которые должно убраться организационно-техническое решение. Обычно. перечисленный Вами "букет" достается ведущему аналитику, который "зрит в корень", "отделяет мух от котлет", т.е. проводит декомпозицию/классификацию/формализацию требований. Результат, представленный на согласование заказчику в качестве ТЗ часто вызывает у заказчика, по модному нынче выражению, "взрыв мозга", эмоции типа "..зачем я таких умных взял?", а затем полное просветление (позитивный сценарий). Таков уж хлеб аналитика, что поделать.

Зачастую избыточность расщепления на бесчисленное множество формирующих стезю терминологий, прячем за собой уход от сути процесса. Это не в обиду. Но я бы вас не взял на работу. Несмотря на то что вы «Отличник» по написанному.

"Это не в обиду. Но я бы вас не взял на работу." - вопрос ПОДБОРА КОМАНДЫ (взаимопонимания) в данной статье не рассматривается, однако претензии Ваши я попробую представить в формализованном виде (в проекции собственного сознания):

  1. "Путь самурая", как модель сотрудника, неприменим, т.к. самурай - слуга своего господина. Ориентация на увольнение приведет к отсутствию вовлеченности, кризису мотивации и деградации компетенции, что логично приведет к увольнению.

  2. Перечень обязательных материалов для изучения и "внеклассного чтения" избыточен на 90%, т.к. обязательное знание внешних и внутренних требований говорит об отсутствии процесса управления организационными знаниями (которые сотрудник не может получить и вынужден ориентироваться на, возможно устаревший, срез этих знаний. полученных неизвестно когда), а "желательность" говорит об отсутствии организационной работы со стороны руководителя и участников процесса управления персоналом.

  3. Требования к аналитику-старшему-ведущему не наследуются (возможно просто не указано) и местами весьма противоречивы (например: зачем IDEF0 Системному аналитику, если он описывает конкретные процедуры, зачем UML Старшему "Разработка логической структуры БД. Разработка предложений по индексированию БД"? - как правильно заметили, БД - это технический инструмент частной реализации).

    Причем. я понимаю, почему допущены такие ошибки (в статье ли, в ДИ ли..): очень затянута как сама статья, так и описание действующей модели системного анализа на предприятии. Как следствие - присутствуют элементы "затыкания дыр" и дописки забытых элементов.

  1. Утверждение, конечно, понятно - Путь самурая доступен не всем. Непонятна категоричность, с которой он отвергается. Когда Вы говорите об увольнении - вы говорите на самом деле о страхе увольнения. А я говорю о искренности и объективности оценки своих компетенций. Это другое.

  2. Конечно, перечень материалов избыточен, чтобы каждый мог найти свой путь роста.

  3. IMHO - IDEF0 - от общего к частному. Не считаю, что БД - это не уровень аналитика. Напротив, считаю, что БД - это модель реального мира. И спроектировать такую модель, не представляя как этот мир устроен, это как написать картину с закрытыми глазами. Однако, без понимания того, что будешь использовать в работе - краски или уголь - тоже написать картину не получится.


По пунктам:

  1. Если мы воспитываем слугу или аналитик более чем на должность слуги не рассчитывает, "Путь самурая" вполне возможен как часть мировосприятия. Цель должна быть не УВОЛЬНЕНИЕ, а ПОЛУЧЕНИЕ НОВЫХ ВЫЗОВОВ. И увольнение, по сути, в новую цель входит в числе прочих. Но двигателем в данном случае будет уже не страх, а креативность и самореализация.

  2. Но выглядит этот список чрезвычайно угнетающе. :-) Выжимку из этого материала следует доносить до сотрудника на этапе обучения и шефства. А уже заинтересованный сотрудник сможет выбрать материал.

  3. Вот в этом то и противоречие: с одной стороны навыки подобраны из соображения от общего к частному, с другой стороны - от частной реализации к системной модели (т.е. ровно наоборот). IDEF0, на мой взгляд, является одной из сложнейших нотаций по следующим причинам: а. минимальный набор компонентов модели обязывает иметь полное представление о состоянии объекта, описываемого одним значком; б. с помощью IDEF0 описывают архитектуру взаимодействия ключевых процессов и ОШИБКА в таком моделировании стоит чрезвычайно дорого; в. переход между блоками описан с максимально возможной неопределенностью.

    Я бы не хотел, чтобы мой комментарий воспринимался деструктивно - если система работает, значит а. имеет право на существование; б. её можно постепенно и бесконечно улучшать, ставя себе новые вызовы.

    Ваш материал, бесспорно, ценен уже хотя бы удачной попыткой формализовать требования к сотрудникам и определением роли бизнес-анализа в целом.

Вполне.

Не совсем понимаю несколько пунктов про обязанности господ аналитиков.

Ведущий аналитик должен проектировать архитектуру? Что вы подразумеваете под архитектурой? Поделитесь, пожалуйста, своим опытом, много ли вы написали различных HLD, по которым команда смогла дать оценку и в итоге реализовать качественное решение по этим HLD? Серьезно, у вас аналитик разрабатывает архитектуру и она актуальна?

Аналитик должен давать требования по разработке СУБД, таблиц и индексов. А кто принимает решение, что это должен быть условный SQL? Так же аналитик, при разработке архитектуры? Я к тому, зачем вообще аналитику лезть на этот уровень, если в этой области хватает других специалистов? А вот качественно разработанная информационная модель, так это стезя аналитика. А объекты данных без него создадут.

На проектах, которыми я руковожу, нет господ. Как и нет холопов. Это принципиальный момент в организации работы.
Вы пытаетесь анализировать приведенную матрицу, как должностную инструкцию. Это не должностная инструкция - это примерный перечень целей, ориентиров к которым, с моей точки зрения может стремиться аналитик на заказном программном проекте. При этом цели выставлены немного выше, чем требуется.
С моей точки зрения, ведущий аналитик проекта должен являться ключевым интегрирующим звеном в проектировании архитектуры ПО, поскольку он является техническим представителем заказчика на проекте. Однако, к проектированию архитектуры должны привлекаться все технические специалисты по мере необходимости.
Повторюсь, что способность разрабатывать структуру БД для аналитика считаю одной из ключевых компетенций. При этом считаю, в большинстве случаев, нецелесообразным формирование промежуточных моделей (ER и логической), поскольку можно сразу создавать физическую. На моих проектах аналитик создает структуру БД, после чего она проходит рецензирование со стороны программистов - по их замечаниям формируется вариант, который пойдет в эксплуатацию.


"..способность разрабатывать структуру БД для аналитика считаю одной из ключевых компетенций." - Александр, я предположу, что Вы сами являетесь ГУРУ в структурировании БД. В таком случае, для Вас знания в части БД будут понятным параметром качества аналитических способностей сотрудника. Но вот для меня, как системотехника и специалиста по процессному моделированию, такими параметрами будут несколько иные реализации аналитических способностей.

Таким образом, я бы предложил использовать на усмотрение руководителя вариативный ряд таких показателей исходя из области, где предполагается использовать конкретного специалиста.

Я не настаиваю на своей точке зрения. Если у Вас получается добиваться успеха в проекте без того, чтобы аналитики разбирались в структуре БД - да пребудет с Вами сила. Иногда такое возможно. Например, при использовании Drupal или ОПОРА.УФОС, как платформы для создания ПО, значение понимания структуры БД уходит на второй план. Однако, точно не будет лишним.
К сожалению, несмотря на атакующее отрицание предложенных подходов, ни один из критиков не предложил собственных критериев измерения эффективности аналитической работы. Может поделитесь, в каких "попугаях" измеряются у вас результаты работы аналитика?

"каких "попугаях" измеряются у вас результаты работы аналитика?" - извольте: 1. Выполнение должностных обязанностей, соблюдение регламентов и сроков подготовки документов. 2. Количество подготовленного материала 3. Качество выполнения должностных обязанностей: количество окончательных решений без замечаний, количество замечаний, количество возвратов на доработку и т.п.

Группа параметров комплектуется весовыми коэффициентами в зависимости от степени влияния на бизнес и управляемости аналитиком (т.е., если итоговый документ был отклонен заказчиком по причинам не зависящим от разработчика, весовой коэффициент будет ниже, если отклонен именно материал, подготовленный этим сотрудником, то и весовой коэффициент будет выше).

Обращаю внимание, что такая методика применима ко всем специальностям, давно и повсеместно (в том смысле, что география и отрасли использования ничем не ограничены) используется. Использование такой методики на конкретном предприятии зависит лишь от качества процесса мотивации и управления персоналом.

7 лет набирать опыт в откровенно несправедливой компании, чтобы потом кто-то другой заплатил, если захочет? Разве для этого не придумали ВУЗы и теорию обучения? И где сейчас эти "японцы", которые выдают за кузницу кадров наглеж в каждой статье ТК?

Почему несправедливой? ВУЗы придумали для формирования массовых специальностей. А в приведенном примере речь шла об уникальной профессии. В определенных отраслях цеховая система обучения не умерла. Иногда выучить учебники недостаточно. Эта тема хорошо раскрывается в диалогах Учителя (Николо Амати) и Ученика (Антонио Страдивари) в фильме "Визит к Минотавру". Рекомендую.

Подскажите, пожалуйста, что такое:

альбом выходных документов (печатных отчетов);

описание систем классификации и кодирования;

ретро-данные

  1. Альбом выходных документов - документ содержащий описание отчетов выводимых на печать (на бумагу), а так же правила построения таких отчетов. Иногда нормативные акты требуют построения отчетов, которые просто нельзя построить на основе имеющихся исходных данных. Поэтому, несмотря на кажущуюся "понятность" отчетов, стоит фиксировать алгоритм представления данных на бумаге.

  2. Пример описания систем классификации и кодирования можете посмотреть здесь.

  3. Ретро-данные - данные которые попали в БД на предыдущих этапах ее существования или данные заказчика которые надо загрузить в БД при вводе системы в эксплуатацию. Зачастую выясняются, что эти данные не соответствуют принятым в БД ограничениям, но загружать/запускать систему надо срочно, ограничения БД снимаются. О необходимости принятия решения по исправлению этих данных (или хотя бы описанию этих противоречий) вскоре забывают. И через некоторое время "внезапно" начинается головная боль, источник которой удается обнаружить далеко не сразу...

Спасибо

Сотрудник должен, прежде всего, постоянно помнить - помнить днем и ночью, с того утра, когда он приходит на новую работу, до последнего рабочего дня старого года, когда он ожидает выплаты премии - что он должен быть уволен.

Подробнее про путь самурая - Всегда старайтесь быть н̶е̶заменимым

Спасибо за наводку. Хорошо дополняет мысль высказанную в начале статьи - обязательно дам почитать своим сотрудникам. Сразу вспомнилась фраза Генри Форда: "Если у Вас появился незаменимый сотрудник, лучшее что Вы можете сделать - это уволить его."

Не нашёл в списке предложенных обязанностей практически ничего про: взаимодействие с заказчиком с целью выявления его потребностей, формирование требований, выработки опций дизайна системы; соответственно, в достигнутых результатах работы ни слова про оценку достижения выявленных потребностей с помощью разработанного решения. Предполагается, что это не входит в обязанности системного аналитика [работающего в ЛАНИТ]?

Повторюсь - это не список обязанностей - это список ожидаемых компетенций, хотя, конечно, в контексте статьи, эти понятия близки друг другу.
Обратите внимание, что первая компетенция системного аналитика указанная в этой статье - Управление требованиями. Учитывая важность этой компетенции - по данному вопросу написана отдельная статья (переходите по ссылке). Кроме того, ранее написана отдельная статья по формированию и нюансам согласования с представителями заказчика проектных решений, контроль исполнения которых так же входит в компетенции аналитика. Как результат работы аналитика выступает количество внедренных в промышленную эксплуатацию проектных решений. Надеюсь, в этих двух статьях Вы найдете ответы на свои вопросы.
Так же, хотел бы предостеречь от обобщений. В статье неоднократно отмечено, что предложенный подход не может быть рассмотрен как общие правила на всех проектах Ланит и является личной позицией автора. Решение, применять или нет такой подход на своих проектах - остается за Вами.

Отлично! Если бы на Хабре были все статьи такого уровня, то все прочие подобные площадки ИТ-сообщества уже давно бы вымерли.

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

Поэтому у меня два вопроса. Первый, это регламент, скажем так, Вы писали для руководителя или для соискателя такой вакансии и работы?

Второй. Вот в подразделах «Достигнутые результаты» необходимо указать количество того-сего. А как быть с качеством? Результаты-то бывают очень разные. Я вот за свои 25 лет в ИТ (мама родная, уже четверть века) много, чего наваял (системы автоматизации управления промпредприятиями), но помню только две свои разработки, о которых могу воскликнуть вслед за Пушкиным А. С., «Ай да Я, ай да сукин сын!». Причем одна так и не была внедрена. Это была система автоматизации службы снабжения. Её демонстрация была последним контактом с этой службой. Когда снабженцы поняли, чем это им грозит, то начался тотальный саботаж, и все закончилось увольнением зама директора, который продвигал эту автоматизацию.

Так, как Вы учитываете качество работы аналитика?

Про замечание - рекомендации о разделении статей на более мелкие части слышу не в первый раз, но продолжаю упорствовать в своих заблуждениях. Для меня Хабр тем и интересен, что позволяет выражать мысли так как хочется, а не так как диктуют правила публикации научных статей или нормативно-технической документации. Сепарация философской и технической части разорвала бы причинно-следственные связи. Меня не пугает, если кто-то не сможет дочитать до конца. Я никого не стремлюсь "обращать" в свою веру. Эти статьи я пишу больше для себя и для тех кому этой статьи мало. Пишу, чтобы разложить по полочкам свой опыт и обсудить с теми кто способен понять и применять то, о чем я пишу. Технический регламент на пректе я предлагаю писать своим аналитикам на основе моих статей. Такой вот "реинженеринг".

Ответ на 1 вопрос:
Я ленив - поэтому стремлюсь одним выстрелом убить нескольких "зайцев". Статья написана и для руководителя проекта, и для соискателя, и для действующего сотрудника, и для директора руководителя. Это правила, по которым обеспечивается на проекте взаимодействие руководства и сотрудника-аналитика. Это основа для индивидуального учебного плана развития. Это договоренности с директором об условиях повышения зарплаты аналитика. Это квалификационная сетка для определения уровня сложности задач в JIRA (для каждой задачи у нас на проекте фиксируется уровень квалификации, необходимый для ее решения, уровни квалификации соответствуют должностной сетке, однако уровень квалификации задачи не обязательно должен соответствовать должности исполнителя). Это фильтр предварительной очистки для кандидатов на должность (некоторые, ознакомившись со статьей, отказывались от собеседования; некоторые наоборот переоценивали свои силы и стремились попасть на вакансию).

Ответ на 2 вопрос:

Судя по тексту вопроса, понятия "шедевр" и "качественный результат работы" для Вас тождественны, а вот для меня - нет. В промышленной разработке, понятие "качество" для меня означает соответствие требованиям заказчика. И не больше. Для того чтобы обеспечить качество выполнения задач, у нас есть подзадачи на рецензирование проектных решений аналитика со стороны РП и программистов. Кроме того, эти проектные решения должны быть внедрены в промышленную эксплуатацию. Конечная количественная оценка осуществляется именно по фактам сдачи результата работ заказчику. Более подробно о планировании и оценке результатов работ сотрудников на моих проектах предполагаю написать в следующей статье.
Спасибо за оценку статьи - мотивирует на дальнейшее творчество.

Спасибо за ответы. Вопросов нет, есть уточнение по второму вопросу. Возможно я его неточно сформулировал, но понятия "шедевр" и "качественный результат работы" для меня не тождественны. И то, что "качественный результат работы" определяется прежде всего соответствием продукта требованиям заказчика – это, можно сказать, банальность, или – опция по умолчанию. «Шедевр» - это личная эмоциональная оценка, а, впрочем, оценка временем: вот заказчик эксплуатирует 15 лет систему и на предложение перейти на новую платформу отвечает, что платить за модернизацию нет смысла, т.к. все отлично работает и на старой.

Я о другом. Вы же сами пишите, что «Почти шаблоны резюме» служат «для понимания сотрудниками, каких результатов они могут достичь, работая в моей команде, и с другой стороны — чего я жду от них». Но в «Достигнутые результаты» указаны только количественные оценки, типа «разработано и внедрено ХХ» чего-то. Но это «что-то» у разных исполнителей может сильно отличаться даже в «промышленной разработке», т.к. разработка ПО – это весьма творческая работа, и каждый раз уникальная.

Короче говоря, Вы ждете от сотрудников шедевров?

Конечно, я хотел бы чтобы мои сотрудники стремились к совершенству. Однако с моей точки зрения - это стремление должно быть подкреплено результатами, которые можно выразить количественно. Попробую пояснить на примере. С одной стороны, можно охарактеризовать школьника, что он очень талантлив, скажем, в математике, долго ходил на факультатив и несколько лет занимался с лучшими учителями. Но, с другой - на мой взгляд, гораздо представительней будет, если сказать, что он, например, самостоятельно решил XX задач из конкретного раздела конкретного учебника, занял Х в олимпиаде X уровня и т.п. Да действительно - все сотрудники разные. Однако, на мой взгляд, квалификация так или иначе всегда проявляется количественно. Один лучше подтягивается, другой быстрее бегает. То и другое можно измерить. Как сложить эти показатели - это отдельная тема для разговора. Как вариант.
В отношении уникальности: на своих проектах я стремлюсь к снижению уникальности решений через унификацию и нормирование работ аналитика. Об этом я подробно рассказывал в одной из своих предыдущих статей. Обратите внимание на калькулятор для оценки трудоемкости этих работ при планировании. При этом унификация - это не ограничение для творчества. Это инструмент оценки и задания уровня. Квалификационные сетки в спорте не отменяют рекордов. Если на проекте рождается что-то эксклюзивное - это повод добавить этот эксклюзив в резюме отдельной строкой. В шаблонах резюме нельзя зафиксировать требование на озарения и инсайты, но это не отменяет их на проекте.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий