"каких "попугаях" измеряются у вас результаты работы аналитика?" - извольте: 1. Выполнение должностных обязанностей, соблюдение регламентов и сроков подготовки документов. 2. Количество подготовленного материала 3. Качество выполнения должностных обязанностей: количество окончательных решений без замечаний, количество замечаний, количество возвратов на доработку и т.п.
Группа параметров комплектуется весовыми коэффициентами в зависимости от степени влияния на бизнес и управляемости аналитиком (т.е., если итоговый документ был отклонен заказчиком по причинам не зависящим от разработчика, весовой коэффициент будет ниже, если отклонен именно материал, подготовленный этим сотрудником, то и весовой коэффициент будет выше).
Обращаю внимание, что такая методика применима ко всем специальностям, давно и повсеместно (в том смысле, что география и отрасли использования ничем не ограничены) используется. Использование такой методики на конкретном предприятии зависит лишь от качества процесса мотивации и управления персоналом.
Интересно, а зачем брать человека пишущего на одном языке, чтобы заставить его писать на другом? Т.е. в требованиях "водитель категории А", а в ДО - Б и С?
Попахивает незаконной эксплуатацией. Предполагаю, что и программисты 30+ увольняются сами, т.к. не каждый готов выбросить в мусор кусок своей жизни в несколько лет. Да и юридически подкованы уже.
"..способность разрабатывать структуру БД для аналитика считаю одной из ключевых компетенций." - Александр, я предположу, что Вы сами являетесь ГУРУ в структурировании БД. В таком случае, для Вас знания в части БД будут понятным параметром качества аналитических способностей сотрудника. Но вот для меня, как системотехника и специалиста по процессному моделированию, такими параметрами будут несколько иные реализации аналитических способностей.
Таким образом, я бы предложил использовать на усмотрение руководителя вариативный ряд таких показателей исходя из области, где предполагается использовать конкретного специалиста.
Если мы воспитываем слугу или аналитик более чем на должность слуги не рассчитывает, "Путь самурая" вполне возможен как часть мировосприятия. Цель должна быть не УВОЛЬНЕНИЕ, а ПОЛУЧЕНИЕ НОВЫХ ВЫЗОВОВ. И увольнение, по сути, в новую цель входит в числе прочих. Но двигателем в данном случае будет уже не страх, а креативность и самореализация.
Но выглядит этот список чрезвычайно угнетающе. :-) Выжимку из этого материала следует доносить до сотрудника на этапе обучения и шефства. А уже заинтересованный сотрудник сможет выбрать материал.
Вот в этом то и противоречие: с одной стороны навыки подобраны из соображения от общего к частному, с другой стороны - от частной реализации к системной модели (т.е. ровно наоборот). IDEF0, на мой взгляд, является одной из сложнейших нотаций по следующим причинам: а. минимальный набор компонентов модели обязывает иметь полное представление о состоянии объекта, описываемого одним значком; б. с помощью IDEF0 описывают архитектуру взаимодействия ключевых процессов и ОШИБКА в таком моделировании стоит чрезвычайно дорого; в. переход между блоками описан с максимально возможной неопределенностью.
Я бы не хотел, чтобы мой комментарий воспринимался деструктивно - если система работает, значит а. имеет право на существование; б. её можно постепенно и бесконечно улучшать, ставя себе новые вызовы.
Ваш материал, бесспорно, ценен уже хотя бы удачной попыткой формализовать требования к сотрудникам и определением роли бизнес-анализа в целом.
"Это не в обиду. Но я бы вас не взял на работу." - вопрос ПОДБОРА КОМАНДЫ (взаимопонимания) в данной статье не рассматривается, однако претензии Ваши я попробую представить в формализованном виде (в проекции собственного сознания):
"Путь самурая", как модель сотрудника, неприменим, т.к. самурай - слуга своего господина. Ориентация на увольнение приведет к отсутствию вовлеченности, кризису мотивации и деградации компетенции, что логично приведет к увольнению.
Перечень обязательных материалов для изучения и "внеклассного чтения" избыточен на 90%, т.к. обязательное знание внешних и внутренних требований говорит об отсутствии процесса управления организационными знаниями (которые сотрудник не может получить и вынужден ориентироваться на, возможно устаревший, срез этих знаний. полученных неизвестно когда), а "желательность" говорит об отсутствии организационной работы со стороны руководителя и участников процесса управления персоналом.
Требования к аналитику-старшему-ведущему не наследуются (возможно просто не указано) и местами весьма противоречивы (например: зачем IDEF0 Системному аналитику, если он описывает конкретные процедуры, зачем UML Старшему "Разработка логической структуры БД. Разработка предложений по индексированию БД"? - как правильно заметили, БД - это технический инструмент частной реализации).
Причем. я понимаю, почему допущены такие ошибки (в статье ли, в ДИ ли..): очень затянута как сама статья, так и описание действующей модели системного анализа на предприятии. Как следствие - присутствуют элементы "затыкания дыр" и дописки забытых элементов.
"В реальности аналитик в качестве задания получает:... " - на то он и аналитик. Все перечисленное - его мастер-данные, в которые должно убраться организационно-техническое решение. Обычно. перечисленный Вами "букет" достается ведущему аналитику, который "зрит в корень", "отделяет мух от котлет", т.е. проводит декомпозицию/классификацию/формализацию требований. Результат, представленный на согласование заказчику в качестве ТЗ часто вызывает у заказчика, по модному нынче выражению, "взрыв мозга", эмоции типа "..зачем я таких умных взял?", а затем полное просветление (позитивный сценарий). Таков уж хлеб аналитика, что поделать.
"каких "попугаях" измеряются у вас результаты работы аналитика?" - извольте: 1. Выполнение должностных обязанностей, соблюдение регламентов и сроков подготовки документов. 2. Количество подготовленного материала 3. Качество выполнения должностных обязанностей: количество окончательных решений без замечаний, количество замечаний, количество возвратов на доработку и т.п.
Группа параметров комплектуется весовыми коэффициентами в зависимости от степени влияния на бизнес и управляемости аналитиком (т.е., если итоговый документ был отклонен заказчиком по причинам не зависящим от разработчика, весовой коэффициент будет ниже, если отклонен именно материал, подготовленный этим сотрудником, то и весовой коэффициент будет выше).
Обращаю внимание, что такая методика применима ко всем специальностям, давно и повсеместно (в том смысле, что география и отрасли использования ничем не ограничены) используется. Использование такой методики на конкретном предприятии зависит лишь от качества процесса мотивации и управления персоналом.
Интересно, а зачем брать человека пишущего на одном языке, чтобы заставить его писать на другом? Т.е. в требованиях "водитель категории А", а в ДО - Б и С?
Попахивает незаконной эксплуатацией. Предполагаю, что и программисты 30+ увольняются сами, т.к. не каждый готов выбросить в мусор кусок своей жизни в несколько лет. Да и юридически подкованы уже.
"..способность разрабатывать структуру БД для аналитика считаю одной из ключевых компетенций." - Александр, я предположу, что Вы сами являетесь ГУРУ в структурировании БД. В таком случае, для Вас знания в части БД будут понятным параметром качества аналитических способностей сотрудника. Но вот для меня, как системотехника и специалиста по процессному моделированию, такими параметрами будут несколько иные реализации аналитических способностей.
Таким образом, я бы предложил использовать на усмотрение руководителя вариативный ряд таких показателей исходя из области, где предполагается использовать конкретного специалиста.
По пунктам:
Если мы воспитываем слугу или аналитик более чем на должность слуги не рассчитывает, "Путь самурая" вполне возможен как часть мировосприятия. Цель должна быть не УВОЛЬНЕНИЕ, а ПОЛУЧЕНИЕ НОВЫХ ВЫЗОВОВ. И увольнение, по сути, в новую цель входит в числе прочих. Но двигателем в данном случае будет уже не страх, а креативность и самореализация.
Но выглядит этот список чрезвычайно угнетающе. :-) Выжимку из этого материала следует доносить до сотрудника на этапе обучения и шефства. А уже заинтересованный сотрудник сможет выбрать материал.
Вот в этом то и противоречие: с одной стороны навыки подобраны из соображения от общего к частному, с другой стороны - от частной реализации к системной модели (т.е. ровно наоборот). IDEF0, на мой взгляд, является одной из сложнейших нотаций по следующим причинам: а. минимальный набор компонентов модели обязывает иметь полное представление о состоянии объекта, описываемого одним значком; б. с помощью IDEF0 описывают архитектуру взаимодействия ключевых процессов и ОШИБКА в таком моделировании стоит чрезвычайно дорого; в. переход между блоками описан с максимально возможной неопределенностью.
Я бы не хотел, чтобы мой комментарий воспринимался деструктивно - если система работает, значит а. имеет право на существование; б. её можно постепенно и бесконечно улучшать, ставя себе новые вызовы.
Ваш материал, бесспорно, ценен уже хотя бы удачной попыткой формализовать требования к сотрудникам и определением роли бизнес-анализа в целом.
"Это не в обиду. Но я бы вас не взял на работу." - вопрос ПОДБОРА КОМАНДЫ (взаимопонимания) в данной статье не рассматривается, однако претензии Ваши я попробую представить в формализованном виде (в проекции собственного сознания):
"Путь самурая", как модель сотрудника, неприменим, т.к. самурай - слуга своего господина. Ориентация на увольнение приведет к отсутствию вовлеченности, кризису мотивации и деградации компетенции, что логично приведет к увольнению.
Перечень обязательных материалов для изучения и "внеклассного чтения" избыточен на 90%, т.к. обязательное знание внешних и внутренних требований говорит об отсутствии процесса управления организационными знаниями (которые сотрудник не может получить и вынужден ориентироваться на, возможно устаревший, срез этих знаний. полученных неизвестно когда), а "желательность" говорит об отсутствии организационной работы со стороны руководителя и участников процесса управления персоналом.
Требования к аналитику-старшему-ведущему не наследуются (возможно просто не указано) и местами весьма противоречивы (например: зачем IDEF0 Системному аналитику, если он описывает конкретные процедуры, зачем UML Старшему "Разработка логической структуры БД. Разработка предложений по индексированию БД"? - как правильно заметили, БД - это технический инструмент частной реализации).
Причем. я понимаю, почему допущены такие ошибки (в статье ли, в ДИ ли..): очень затянута как сама статья, так и описание действующей модели системного анализа на предприятии. Как следствие - присутствуют элементы "затыкания дыр" и дописки забытых элементов.
"В реальности аналитик в качестве задания получает:... " - на то он и аналитик. Все перечисленное - его мастер-данные, в которые должно убраться организационно-техническое решение. Обычно. перечисленный Вами "букет" достается ведущему аналитику, который "зрит в корень", "отделяет мух от котлет", т.е. проводит декомпозицию/классификацию/формализацию требований. Результат, представленный на согласование заказчику в качестве ТЗ часто вызывает у заказчика, по модному нынче выражению, "взрыв мозга", эмоции типа "..зачем я таких умных взял?", а затем полное просветление (позитивный сценарий). Таков уж хлеб аналитика, что поделать.