Форум Сообщества Аналитиков
Обсуждения => Работа => Тема начата: AndreyB от 11 Мая 2010, 22:00:06
-
Доброе время суток!
Вопрос: Какие существуют показатели хорошей работы аналитика?Если конечно этот вопрос уместен.
Маленькое дополнение.Скажем показатели хорошей работы HR-манагера скажем количество закрытых вакансий.
Про текучку и собеседования я не буду далее развивать тему :-)
Для тестировщика - количество найденных ошибок ,определенная категория найденных ошибок(если я буду искать только грамматические ошибки в интерфейсе , то это не будут поощрять) и тд.
С количественный потолок тут обычно устанавливают сравнивая со средней температурой по палате.
И как тогда измерять работу аналитика?
-
как вариант:
может качеством управления требованиями (удовлетворенностью заказчика) и количеством доработок, связанных с ошибками в документации, разрабатываемой аналитиками(удовлетворенностью ПМ-а)?
-
Для тестировщика - количество найденных ошибок ,определенная категория найденных ошибок(если я буду искать только грамматические ошибки в интерфейсе , то это не будут поощрять)
а вот и нет, для тестировщика, на мой взгляд, - это количество багов, найденное конечными пользователями, и чем меньше их тем лучше.
-
а вот и нет, для тестировщика, на мой взгляд, - это количество багов, найденное конечными пользователями, и чем меньше их тем лучше.
т.е. получается тестировщикам будет выгодно, чтобы в системе было больше ненайденных багов до передачи ее в эксплуатацию.
Должно быть наоборот: тестировщикам должно быть выгодно, чтобы в переданной пользователям системе было МЕНЬШЕ багов. Поэтому их акцент должен быть направлен на усиленное тестирование системы ДО передачи ее в эксплуатацию.
Почитайте про "черную команду" у ДеМарко и Листера.
-
Мне кажется, что основной критерий работы аналитика - это соответствие выданного продукта требованиям заказчика.
Т.е. чтобы у заказчика, не возникало желания сказать "Вы не правильно меня поняли" или "Да, но я имел в виду другое" или "Да, но это только частный случай" и т.п.
-
т.е. получается тестировщикам будет выгодно, чтобы в системе было больше ненайденных багов до передачи ее в эксплуатацию.
Должно быть наоборот: тестировщикам должно быть выгодно, чтобы в переданной пользователям системе было МЕНЬШЕ багов. Поэтому их акцент должен быть направлен на усиленное тестирование системы ДО передачи ее в эксплуатацию.
Почитайте про "черную команду" у ДеМарко и Листера.
Так и я об єтом же. Чем меньше багов, которые найдет конечный пользователь, тем качественней поработали тестировщики. Конечно количество найденных багов ДО передачи в эксплуатацию - это показательно, но такой показатель не объективен и становится неадекватным, если конечные пользователи найдут ПОСЛЕ передачи в эксплуатацию еще больше или хотя бы парочку.
-
Мне кажется, что основной критерий работы аналитика - это соответствие выданного продукта требованиям заказчика.
Т.е. чтобы у заказчика, не возникало желания сказать "Вы не правильно меня поняли" или "Да, но я имел в виду другое" или "Да, но это только частный случай" и т.п.
Как будете мерить?
-
Как будете мерить?
Работу машинистки измерить можно.Считай кол-во напечатанных листов.
Программиста - затраченное время и качество кода (найденных косяков)
PM -? Пока Не знаю.
Мерить на глазок :-)
-
для PM:
абсол. - бюджет проектов, выполненных без задержек по срокам и с необходимым качеством
относит. - соотношение бюджетов проектов, выполненных с опозданием, с неадекватным качеством, по отношению к бюджету качественных проектов без опозданий
-
У нас принято мерить качество работы аналитика и качество самого аналитика по отзывам людей с которыми он контачит в процессе работы - как со стороны исполнителя так и со стороны заказчика. Если эти мнения более менее совпадают то это и есть качество работы аналитика, если нет то начинают копать - почему... ну в общем некоторый процесс
-
у меня какое-то дежа вю. покопайтесь, тут уже была такая тема.
-
Понятно, что количественными метриками оценить работу аналитика сложно - количество багов в требованиях разве что. Но это на проектах, где классно выстроен процесс контроля качества. Вообще тестирование требований - отдельный вопрос :)
Для меня критерием качества работы аналитика на проекте являются удовлетворенные ожидания Заказчика в конце проекта. Тут тоже всё условно и можно говорить, что успех проекта и удовлетворенность Заказчика - это общее достижение всех участников проекта. Но тем не менее, "главный" человек, который может повлиять на ожидания Заказчика и в конечном итоге его удовлетвоернность разработанным продуктом - это аналитик.
-
Мне кажется, что основной критерий работы аналитика - это соответствие выданного продукта требованиям заказчика.
Т.е. чтобы у заказчика, не возникало желания сказать "Вы не правильно меня поняли" или "Да, но я имел в виду другое" или "Да, но это только частный случай" и т.п.
У нас принято мерить качество работы аналитика и качество самого аналитика по отзывам людей с которыми он контачит в процессе работы - как со стороны исполнителя так и со стороны заказчика. Если эти мнения более менее совпадают то это и есть качество работы аналитика, если нет то начинают копать - почему... ну в общем некоторый процесс
Бедные-бедные аналитики :)
Так как отрасль у нас требует хорошего развития логики, то эмоциональный компонент во что только не сублимируется - даже в оценки работы.
Вот например у музыкантов все просто: лажа это когда человек поет и играет мимо нот. Она очевидна и ее можно услышать даже невооруженным ухом, хотя и не всем. Если нет нот, это называется импровизация - в ИТ это по-моему называется XP, или Agile :)
Однако даже в импровизации есть тональность - т.е. некий общий контекст, в котором все находятся. Если выпадаем из контекста, то теряем согласованность с другими участниками.
Ну и наконец можно не слышать ритма (это такая штука, которую должен задавать барабанщик - а в нормальных проектах его должен задавать ПМ). Это хуже всего :)
А вот удовлетворенность заказчика - фактор во многом мистический. Ее в попугаях не измеришь. Так что наверное лучше все-таки сосредоточиться на более формальных критериях :)
-
у меня какое-то дежа вю. покопайтесь, тут уже была такая тема.
Да.Тема поднималась тут http://www.uml2.ru/forum/index.php?topic=1824.0
-
А вот интересно что.
А каков минимальный порог?
Сколько минимально должен найти ошибок в месяц тестировщик? 1 , 2 или 100?
Сколько должен аналитик написать ТЗ в месяц?
Каково должно быть соотношение довольных и недовольных клиентов?Принцип 20/80?Или 50 на 50?
-
А сколько минимально должен съедать человек ежедневно, чтобы не умереть от голода?
Если я отвечу - 0,3кг белков, 0,5кг жиров и 0,2кг углеводов - вы пойдете мерять всех этими категориями, а не удовлетворяющих условиям расстреливать?
Какую цель вы преследуете своими вопросами? Как вы будете использовать полученные ответы?
Если говорить в общем - метрики не только иногда полезны, но и почти всегда вредны. Особенно, если метрика рассматривается изолировано, без принятия во внимание контекста ее измерения.
-
Какую цель вы преследуете своими вопросами? Как вы будете использовать полученные ответы?
А ты не задавался вопросом?
У меня складывается ощущение , что никто не любит отвечать на этот вопрос.
Тут обычно вспыхивает буря эмоции.
Болно кажется :-)
P.S. Мне нужно для понимания причины- следствия
-
Задавался, и пришел к выводу:
Если говорить в общем - метрики не только иногда полезны, но и почти всегда вредны. Особенно, если метрика рассматривается изолировано, без принятия во внимание контекста ее измерения.
-
Если говорить в общем - метрики не только иногда полезны, но и почти всегда вредны. Особенно, если метрика рассматривается изолировано, без принятия во внимание контекста ее измерения.
Полностью поддерживаю! Возможно можно придумать какой-то интегрированный показатель, но все индивидуально и не без субъктивизма..
-
Полностью поддерживаю! Возможно можно придумать какой-то интегрированный показатель, но все индивидуально и не без субъктивизма..
Тут видимо проблема заключается в стремлении сотрудника предсказать поведение начальства.
А цепочку ведущую к выводам надо расскрыть.
Иначе все это пустая реторика и нечего больше.
-
Не поняла к чему здесь начальство.
Я имела в виду, что нет одного рецепта - что подходит в одном случае, может совсем не работать в другом.
-
Не поняла к чему здесь начальство.
Я имела в виду, что нет одного рецепта - что подходит в одном случае, может совсем не работать в другом.
Рецепт для аналитиков знаете?Меня не интересует пока другие роли.
-
что нет одного рецепта - что подходит в одном случае, может совсем не работать в другом.
Конечно.
У кадровиков подсмотрел такие оценки.Они называются -"валидные показатели".
И имеют такую структуру:
1 Должность
2 На что смотреть:Кол-во,Качество и Жуткие формулы
-
Если погуглить, например, на тему "должностная инструкция бизнес-аналитика", то можно найти вот что:
http://www.kdelo.ru/job-description/6884
http://www.glavbuh.net/trudovoi/dolgnost_inst/biznes-analitika/
http://www.lawmix.ru/doc/20087
http://www.klubok.net/article1927.html
В частности, по последней ссылке есть такой пункт:
"...
9 Критерии эффективности труда
9.1 Достижение целевых значений критериев оценки эффективности бизнес-процессов после проведения их оптимизации.
9.2 Степень удовлетворенности сотрудников организации работой в рамках бизнес-процесса после его оптимизации.
9.3 Соблюдение календарного плана работ."
На мой взгляд только последний пункт можно "измерить", а первые два весьма субъективны
-
В свое время на RSDN долго обсуждали, как можно количественно измерить качество работы тех или иных позиций в проекте и пришли к выводу, что в общем случае сделать это нельзя.
-
Котик, так разработайте и предложите свою методику оценки.
Раз у вас есть подобная актуальность, и никто не может ничего подходящего порекомендовать.
А мы заценим.
-
Зачем изобретать уже созданное?
Все уже изобрели :)
-
Вопрос: Какие существуют показатели хорошей работы аналитика?
И как тогда измерять работу аналитика?
Показатели и методы измерения работы аналитика — это система.
Давайте поймём потребителей системы и их интересы. Тогда можно будет сформулировать требования к системе, а не гадать, как сейчас.
Кто(1) хочет использовать эти показатели и для чего(2)?
Какого рода решения(3) будут приниматься на основе изучения значений показателей? В ходе какой деятельности(4)? Как часто(5)?
-
Зачем изобретать уже созданное?
Все уже изобрели :)
Ткните меня носом пожалуйста, где на приведенной схеме показатели работы аналитика?...
-
Ткните меня носом пожалуйста, где на приведенной схеме показатели работы аналитика?...
IDA!!!???
У меня наступил когнитивный диссонанс.
Или это конец света.
Разве ТЗ и прочие артефакты , генерируемые аналитиком не показатель работы?(Схема взята из справочника по RUP)
-
Где измеряемые количественные параметры работы аналитика?
-
Где измеряемые количественные параметры работы аналитика?
IDA и Денис ,для начала вы можете назвать цели и миссию вашей компании?(это верхний уровень)
На сайтах ваших компании я что-то похожие не нашел.
А уже потом спустимся ниже , к аналитиком.
-
IDA!!!???
У меня наступил когнитивный диссонанс.
Или это конец света.
Разве ТЗ и прочие артефакты , генерируемые аналитиком не показатель работы?(Схема взята из справочника по RUP)
Коллеги, давайте говорить, что показатели работы это по-сути KPI, и будем понимать, что это метрики (имеющие количественные, или может быть качественные характеристики), на основании которых будет проводиться оценка того, насколько успешен тот или иной аналитик. Теперь вопрос - какие метрики могут быть использованы вообще, для оценки работы аналитика, и какие из них в конкретных случаях (т.е. в конкретных компаниях, командах, ...) выступают в качестве KPI?
-
У нас используются:
- удовлетворенность заказчика (определяется самим заказчиком по 5 бальной шкале по завершении проекта (этапа проекта)),
- удовлетворенность ПМ-а (определяется ПМ-ом по 5 бальной шкале по завершении проекта (этапа проекта)),
- превышение сроков работ над плановыми, количество доработок сделанных в результате ошибок аналитика (ченджреквесты заказчика не считаются),
- достаточность артефактов, разработанных аналитиками для разработчиков (полнота изложения требований, разработаны все документы, которые нужны для данного проекта)
- лояльность (способность работать сверхурочно когда это необходимо вне зависимости от собственных планов на нерабочее время)
пожалуй и все...
-
IDA и Денис ,для начала вы можете назвать цели и миссию вашей компании?(это верхний уровень)
На сайтах ваших компании я что-то похожие не нашел.
А уже потом спустимся ниже , к аналитиком.
А как связаны цели и миссия моей компании с оценкой эффективности деятельности системного аналитика вообще?
Вы как спускаться собираетесь, через 7 этажей стратегий? И придёте к единичному кейсу оценки эффективности деятельности у нас? Так я это и без прямой трассировки на миссию могу рассказать, только долго.
Вы аналитик? Возможные контексты оценки выявили? Возможные наборы заинтересованных сторон в этих контекстах? Возможные наборы интересов этих сторон?
Если вас так интересует эта тема, кто мешает выполнить аналитическую работу прямо сейчас? Вы на форум учиться пришли или получать готовые ответы на вопросы? Второе называется консалтинг и то не всегда сразу.
-
У нас используются:
- удовлетворенность заказчика (определяется самим заказчиком по 5 бальной шкале по завершении проекта (этапа проекта)),
- удовлетворенность ПМ-а (определяется ПМ-ом по 5 бальной шкале по завершении проекта (этапа проекта)),
- превышение сроков работ над плановыми, количество доработок сделанных в результате ошибок аналитика (ченджреквесты заказчика не считаются),
- достаточность артефактов, разработанных аналитиками для разработчиков (полнота изложения требований, разработаны все документы, которые нужны для данного проекта)
- лояльность (способность работать сверхурочно когда это необходимо вне зависимости от собственных планов на нерабочее время)
пожалуй и все...
Спасибо за ответ.
-
О, все передрались, а ответа на вопрос темы так и нет :)
Душевный нынче Марс... :) ну хоть кино посмотрели.
-
Денис ,для начала вы можете назвать цели и миссию вашей компании?
А цели компании не могут быть коммерческой тайной?
-
А цели компании не могут быть коммерческой тайной?
Нет.
Это больше подходит к постановке целей.
Обычно пишут:быть лидером - получить 60% рынка.Улучшить качество далее пишут как.
Во времена СССР был логунг догнать и перегнать Америку :-)
-
Модератор: Флуд и выяснение отношений удалены.
Чеширский котик, просьба уважительно относиться к посетителям форума.
-
Одним из показателей, в нашей компании, является
загрузка на проекте (часы на решение определенной задачи) :).
В целом с с подходом приведенным в
статье (http://habrahabr.ru/blogs/i_am_cio/22536/) (http://habrahabr.ru/blogs/i_am_cio/22536/)) я согласен.
В данной статье приведено
При расчете эффективности я (автор) не отличаю аналитиков от программистов, т.к. в их работе так же существуют задачи, как и у программистов. А значит, можно посчитать эффективные часы.
Обычно есть проект. В нем всегда есть треугольник ограничений : бюджет - время - содержание.
Соответственно, задача аналитика за заданное время подготовить, например, документ, по качеству который бы удовлетворил Заказчика.
Но при этом качество как бы "согласуется с Заказчиком" (мы как эксперты в своей области знаем что вот так лучше и т.д)
-
Это только мне так кажется, или в основном действительно тут одни общие слова?...
Вот например, прозвучали такие варианты:
- удовлетворенность заказчика (определяется самим заказчиком по 5 бальной шкале по завершении проекта (этапа проекта)),
- удовлетворенность ПМ-а (определяется ПМ-ом по 5 бальной шкале по завершении проекта (этапа проекта)),
- превышение сроков работ над плановыми, количество доработок сделанных в результате ошибок аналитика (ченджреквесты заказчика не считаются),
- достаточность артефактов, разработанных аналитиками для разработчиков (полнота изложения требований, разработаны все документы, которые нужны для данного проекта)
- лояльность (способность работать сверхурочно когда это необходимо вне зависимости от собственных планов на нерабочее время)
У первых двух есть один недостаток, перекрывающий возможные достоинства: субъективность. Поэтому использовать их практически бессмысленно. Когда у заказчика болит зуб, он оценит работу аналитика в 1 балл, а когда заказчику делают массаж в турецкой бане, он ту же работу оценит в 5 баллов.
И если параметризация вопросов позволяет получить впечатление о разных аспектах работы аналитика, а не абстрактной "удовлетворенности", то субъективизма это не отменяет.
По сути однозначно принять можно только третий вариант.
Достаточность - в каких попугаях и кто ее будет измерять?
Лояльность - не показатель. Один работает плохо и медленно, другой хорошо и быстро - поэтому один постоянно работает сверхурочно, а другой успевает все сделать за троих (но этого, разумеется, никто не заметит - кому ж выгодно нанимать еще двух аналитиков :)).
-
Марина, а эти показатели работают комплексно.
Да, в них много субъективного (оценки Заказчика и ПМ-а), тем не менее на размер премий в соответствии с этими показателями пока никто не жаловался. Все показатели имеют числовое (балльное) значение.
-
Прекрасный комментарий, подтверждающий, что метрики определяются целью их применения :)
Вот как раз для цели "измерить количественно работу аналитика" и подходят из предложенных "превышение сроков работ" и "количество доработок".
А для распределения прибылей - тут вам виднее :)
-
Модератор: Флуд и выяснение отношений удалены.
Если не секрет, по какому принципу определяется, какие сообщения являются флудом и выяснением отношений, а какие - в рамках правил?
Эти критерии являются постоянными, или меняются от темы к теме в зависимости от состава участников перепалки и прочая, и прочая? :)
-
Если не секрет, по какому принципу определяется, какие сообщения являются флудом и выяснением отношений, а какие - в рамках правил?
Эти критерии являются постоянными, или меняются от темы к теме в зависимости от состава участников перепалки и прочая, и прочая? :)
Есть опубликованные правила при регистрации, вот их копия:
http://www.uml2.ru/index.php?option=com_smf&Itemid=45&topic=1901.0
Если остались еще вопросы по модерации и правилам, то просьба задавать их в соответствующей или отдельной теме.
-
Вот здесь http://www.requirementsnetwork.com/node/620 тоже похожие вопросы обсуждают, причем давно - с 2006г
-
Вот http://www.apkit.ru/committees/education/meetings/standarts.php (http://www.apkit.ru/committees/education/meetings/standarts.php) профессиональные стандарты в области ИТ, в том числе и системного аналитика. Среди всего прочего в них присутствуют должностные обязанности. Некоторые вполне можно измерить, но большинство оч субъективны, как то: саморазвитие. Вобще довольно странная должностная обязанность.
-
Перечитал обе ветки, эту и http://www.uml2.ru/forum/index.php?topic=1824.0 . Выскажу своё мнение.
Аналитик – абсолютно такой же сотрудник, как все остальные. В ходе проекта, ему ставят конкретные задачи, и он их выполняет в конкретные сроки, при различных обстоятельствах. Текущая оценка «в целом» в ходе проекта должна состоять из множества оценок «в частности» за выполненные конкретных задач, а также учитывать стабильность и динамику работы и результата. Эти оценки могут быть существенно более объективными, чем чьи-то мнения и суждения, чувство удовлетворённости. Про удовлетворённость как критерий отдельно написал здесь, http://alextheraven.livejournal.com/4316.html .
Зачем изобретать какие-то ещё текущие общие оценки? В них и прорывается субъективность. Например, задачи нужно ставить по SMART, а затем обеспечивать условия для их выполнения. Кроме того, нужно учитывать, что во время выполнения появляются новые обстоятельства, нужно эти обстоятельства предвидеть и минимизировать их воздействие. Не все руководители это умеют.
Говорить «ну если ты настоящий аналитик, то сообрази сам, что нам нужно, и удовлетвори нас всех» - манипуляция и перекладывание ответственности. Да, сотрудник должен сам предлагать, чем может помочь, уточнять постановку, следить за обстоятельствами, сам себе помогать, а когда у самого не получается - сигналить наверх, но у него и горизонт другой, и полномочия, чем у того, кто ставит задачи.
А так, в общих оценках, зачастую ответственность за свои ошибки, в т.ч. перед начальством, перекладывают на исполнителя. «Поставил задачи/делегировал обязанности неправильным людям, которые получили за это низкие оценки и уже наказаны» - нелогичная, но существенно более безопасная формулировка, чем честное «сначала сам сказал ерунду сделать, а потом сам недосмотрел, что ерунду делают, ещё и сам никак не повлиял на обстоятельства, которые мешали сделать эту ерунду в срок, в результате на ерунду такие большие затраты».
Оценка многое говорит о том, кто оценивает.
В конкретных контрольных точках и по завершению проекта, наверное, нужно оценивать работу всех. Да и обстановку на проекте в целом. Такую контрольную оценку должны давать люди, которые умеют:
1) учитывать содержание и качество постановки задач, которые ставили, и обстоятельства, в которых их выполняли;
2) ценить то, что результат работы человека полезен, ну или не полезен, для проекта или направления в целом, хотя может быть неприятен (я уже писал в http://www.uml2.ru/forum/index.php?topic=1824.msg18798#msg18798 , что аналитик принимает или помогает принять решения, которые могут отличаться от того, что другие хотят или считают нужным, т.е. обеспечивает выработку общих интересов и ущемление частных);
3) понимают, то, что существующий результат – намного лучше, ну или хуже, чем работа вообще без:
-- требований;
-- моделей системы;
-- связи с заказчиками, технологиями и исследованиями, рынком и трендами, просто знающими людьми на проекте и вне его;
-- учёта предложений и запросов на изменения;
-- доведения до всех и каждого требований и решений;
-- всякой определённости с тем, что нужно разработать и протестировать;
-- просто человека-справочника, который может решать извечный спор между разработчиком и тестировщиком/приёмщика, как должно быть на самом деле, баг или enhancement;
4) учитывать, то, что работа с человеком приносит чувство удовлетворённости, вдохновляет, ну или наоборот, раздражает и расхолаживает (сильно зависит от ожиданий, отношений, отношения);
5) учитывать, что сначала нужно дать возможность и помочь научиться и сработаться, и только потом спрашивать;
6) что то, что для одного тривиально - то для другого может быть большим достижением, и эти достижения нужно ценить; кстати, в этом люди часто меняются ролями и дополняют друг друга.
Если людей, которые могут сделать такие контрольные оценки, нет – вообще не нужно делать таких оценок. Лучше никаких оценок, чем неправильные или неправильно применённые.
-
Перечитал обе ветки, эту и http://www.uml2.ru/forum/index.php?topic=1824.0 . Выскажу своё мнение.
Аналитик – абсолютно такой же сотрудник, как все остальные. В ходе проекта, ему ставят конкретные задачи, и он их выполняет в конкретные сроки, при различных обстоятельствах. Текущая оценка «в целом» в ходе проекта должна состоять из множества оценок «в частности» за выполненные конкретных задач, а также учитывать стабильность и динамику работы и результата. Эти оценки могут быть существенно более объективными, чем чьи-то мнения и суждения, чувство удовлетворённости. Про удовлетворённость как критерий отдельно написал здесь
Саша, приведи пожалуйста пример этого вектора оценок для какого-нибудь аналитика. Что это за вектор?
-
Денис, у меня есть реальные WBS каждого аналитика, со всеми без исключения задачами, статусами, оценками, сколько ушло и осталось, и историей выполнения. В т.ч. на какой неделе какой у задачи был статус (хотя задача, которая в работе 2 календарные недели, уже привлекает внимание), сколько, по нашим оценкам, на неё тратили времени и оставалось потратить, как шло выполнение.
Задачи - разные, от "спланировать проработку...", "разработать доменную модель к...", "написать и согласовать требования к...", "проверить макет GUI... на соответствие требованиям...", до "разобраться с правильным поведением системы в issue id..." или "вычитать раздел документации...". Но стараемся все доводить до SMART. Конкретные примеры - покажу тебе в понедельник.
По этим задачам и можно строить вектор "проект-задача-аналитик-оценка". Но я считаю, что нельзя делать этот процесс формальным и частым, а оценки - общедоступными, т.к. чревато демотивацией. Даже в школе не каждую неделю оценки по предмету ставят. Лучше вообще выделить время на самооценку. Но вот если уж необходим "разбор полётов", то поднимать задачи и историю выполнения, и строить такие векторы, причём не только для аналитиков, но и для других участников. А не опрашивать, кто чьей работой насколько удовлетворён.
Подход, конечно, напоминает "к пуговицам претензии есть?", но не каждый видит пиджак в целом и имеет возможность его улучшить.
Тут Григорий Деминга цитировал, http://www.uml2.ru/forum/index.php?topic=1824.msg18552#msg18552 . Так вот, при оценке важно понимать, где та часть, которая зависит от организации, а где та, которая зависит от работы конкретного сотрудника :) .
-
Денис, у меня есть реальные WBS каждого аналитика, со всеми без исключения задачами, статусами, оценками, сколько ушло и осталось, и историей выполнения. В т.ч. на какой неделе какой у задачи был статус (хотя задача, которая в работе 2 календарные недели, уже привлекает внимание), сколько, по нашим оценкам, на неё тратили времени и оставалось потратить, как шло выполнение.
Задачи - разные, от "спланировать проработку...", "разработать доменную модель к...", "написать и согласовать требования к...", "проверить макет GUI... на соответствие требованиям...", до "разобраться с правильным поведением системы в issue id..." или "вычитать раздел документации...".
И кто ставит оценку за выполнение задачи?
-
Аналитик – абсолютно такой же сотрудник, как все остальные. В ходе проекта, ему ставят конкретные задачи, и он их выполняет в конкретные сроки, при различных обстоятельствах. Текущая оценка «в целом» в ходе проекта должна состоять из множества оценок «в частности» за выполненные конкретных задач, а также учитывать стабильность и динамику работы и результата. Эти оценки могут быть существенно более объективными, чем чьи-то мнения и суждения, чувство удовлетворённости. Про удовлетворённость как критерий отдельно написал здесь, http://alextheraven.livejournal.com/4316.html .
Зачем изобретать какие-то ещё текущие общие оценки? В них и прорывается субъективность. Например, задачи нужно ставить по SMART, а затем обеспечивать условия для их выполнения.
Склонен согласиться с данным мнением. В качестве одного из вариантов снижения субъективности оценок (http://bustor.livejournal.com/30039.html) можно использовать подход, когда сотрудник оценивается на основе анализа трёх составляющих:
а) поставленной перед сотрудников цели;
б) выполненных для достижения поставленной цели действиях;
в) полученных в результате выполнения этих действий результатах и их соответствия начальной цели.
Хотя такой подход предъявляет высокие требования к квалификации:
а) постановщика цели, который должен таки уметь:
i) поставить цель с учетом влияния различных внешних факторов;
ii) донести эту цель до сотрудника и оценщика;
б) оценщика, который должен уметь:
i) оценить, насколько выполняемые действия соответствуют достигаемой цели;
ii) учесть при оценке факторы, которые появились в процессе достижения цели (или не были должным образом учтены при постановке цели) и объективно повлияли не конечный результат.
-
аналитик такой же как все???
нет ну понятно дисциплина, хотя почитайте последние вакансии на hh, им всем готовы дать по дивану для расслабиться, а не лежать и спортинвентарь чуть ли не в кабинете...обратитесь к опыту зарубежному...
одаренный аналитик - это необычный сотрудник, и во многих организациях это просто тень, не всегда и понятно рядовым и линейным руководящим сотрудникам, что он делает и кто он. нередко при приходе аналитика в организацию сами по себе баласты (пустые должности) заявления пишут, и это необъяснимо, т.к даже человек не приступил даже к обязанностям и обычно он подчиняется все же тем кто стратегию развития компании решает.
его положение сильно зависит от целей и задач, а его основная оценка - это результат...во времени!
но опять, мы о персонаже стереотипе или все же о том, у которого в голове более двух измерений?
-
Так вот, при оценке важно понимать, где та часть, которая зависит от организации, а где та, которая зависит от работы конкретного сотрудника :) .
тут можно добавить, это об очевидном, а теперь возьмем и представим, что человек этот мыслит грандиознее и много более чем рабочий день, более того он сравнивать умеет, объемные факторы, как чувства...ведь простой психолог это скучная личность, а аналитик??? уже интереснее...
мой опыт показал, что приходя в организацию, на таком сотруднике замыкаются все ниточки, к нему тянутся все, если ему дано от Бога заниматься этим, и вопросы любые от самых простых до самых сложных, все ему по плечу...да, грамотный человек настроив процессы, далее начинает пытаться окружающих заставлять и учить работать самостоятельно, что в проектах и является основной задачей, от организации ровным счетом не зависит ничего, зависит от стратегии развития компании, если с аналитиком не по пути, можно даже туда и не идти, смысл тратить время? ну разве что ради заработка, но тогда получается простой таланта...хоть и оплачиваемый...однако результат проекта обычно для аналитика все же предсказуем...на то он и аналитик...
-
tolikspb согласно с вами, но на моей практике... такой человек становится руководителем, все больше отдаляясь от аналитики.
-
tolikspb согласно с вами, но на моей практике... такой человек становится руководителем, все больше отдаляясь от аналитики.
Если ему нравится таскать на горбу кирпичи (чужие) - да, становится.
Однако это вовсе не закономерность.
-
и не потому что ему хочется таскать кирпичи, просто во многих компаниях ( может мне в этом плане не повезло) что-то решать может только руководитель, а аналитик хоть каким талантом он не обладай - все равно простой рабочий. Вот и таланту чтобы доказать свою правоту приходится становиться руководителем.
-
Полагать, что руководителями становятся для того, чтобы доказать кому-то свою правоту - очень наивное заблуждение.
Правота понятие относительное - оно справедливо для данного конкретного человека, в данных конкретных условиях. Поэтому если аналитик стал руководителем, понятие о правоте у него изменилось. А если оно не изменилось, и он пытается руководить со своими аналитическими представлениями о правоте, то это очень печальный факт.
Каждый принимает решения в рамках своей компетенции и занимаемой должности - если аналитик не может работать продуктивно, вовсе не факт, что он сможет продуктивно руководить (хотя такое бывает - но по причинам, никак не связанным с особенностями принятия решений в конкретной компании).
-
аналитик такой же как все???
Да. С одной стороны - да, он отличается от рабочего на конвейере. Хотя и рабочие иногда выдвигают настолько полезные и проработанные идеи и рац. предложения, что диву даёшься. С другой стороны - ничего исключительного. Обычный инженер. Ощущение "исключительности" и "элитарности" - ложное, как и во всех остальных случаях. За редчайшим исключением.
нет ну понятно дисциплина, хотя почитайте последние вакансии на hh, им всем готовы дать по дивану для расслабиться, а не лежать и спортинвентарь чуть ли не в кабинете...обратитесь к опыту зарубежному...
Дисциплина - не самоцель, а способ организации достижения результата рабочей группой. Когда группа становится командой, в ней всегда развивается самодисциплина. Например в том, чтобы:
1) вовремя закоммитить работающий, поддерживаемый и прокомментированный код, от которого зависит ночная сборка и утренняя выдача в тестирование
2) максимально быстро и объективно провести ревью, от которого зависит дальнейшая работа остальных
3) терпеливо собирать, предлагать, дорабатывать и объяснять требования, пока всем не станет понятно, что, почему и зачем нужно/будут реализовать.
Дисциплина "отсидеть с 9:oo до 17:oo с каменным лицом" никому не нужна. Дисциплина "прийти на работу/встречу вовремя, чтобы сэкономить время своё и остальных, не расхолаживать, и/или повысить качество (1), (2), (3)" - почти обязательна. Дисциплина "сделать (продумать и записать) творчески, качественно и в срок, хоть сидя за столом, хоть занимаясь в это время на тренажёре, хоть лёжа дома на диване" - абсолютно необходима.
одаренный аналитик - это необычный сотрудник, и во многих организациях это просто тень, не всегда и понятно рядовым и линейным руководящим сотрудникам, что он делает и кто он.
Ага, не признанный всеми везде гений, как же.
Системный аналитик во время разработки уменьшает неопределённость, что делать, и вероятность того, что спроектируют, реализуют, протестируют, выпустят, запустят на рынок не то, что нужно. Для менеджера проекта - экономит весьма конкретное время, деньги, силы/энергию/мотивацию и душевное здоровье по сравнению с отсутствием аналитика. Для маркетинга и продавцов - не даёт упустить весьма конкретные возможности, часто не даёт провалить единственную попытку. Для проектной группы - быстро и правильно отвечает на весьма конкретные вопросы.
Если никто не объяснил ни системному аналитику, что и кому он должен, ни его окружению, зачем он нужен, какие проблемы решает, как с ним работать и чего от него ждать - это проблема тех, кто организовывал работу. Нужно сначала объяснить, а уже потом приглашать аналитика в проектную группу. Если после этого аналитик не делает то, что должен, и окружение это видит, это проблема системного аналитика.
нередко при приходе аналитика в организацию сами по себе баласты (пустые должности) заявления пишут, и это необъяснимо, т.к даже человек не приступил даже к обязанностям и обычно он подчиняется все же тем кто стратегию развития компании решает.
Если стратегия развития компании далека от тех, кто будет обязательства брать и планировать, проектировать, код писать, тестировать, продукт рекламировать и продавать - она так и останется на бумаге, в самом лучшем случае её реализуют на оценку "для галочки". Стратегия должна с самого начала быть для них близкой, а для этого её нужно создавать при их участии. Чтобы каждый знал, что конкретно ему в соответствии с этой стратегией делать.
"Балласты" - зачастую старые и очень компетентные сотрудники, эксперты, пользующиеся заслуженным авторитетом - могут видеть, как какой-то мутный тип теперь помогает определять стратегию развития, и "спускает" им ТЗ, проявляя попутно некомпетентность, неуважение, необязательность и небрежность. Видят в этом угрозу для компании, своего личного благополучия и душевного здоровья. И уходят.
его положение сильно зависит от целей и задач, а его основная оценка - это результат...во времени!
Да. Но в довольно коротком и обозримом времени. Через месяц его работы на проекте людям должно уже стать легче понять, что нужно сделать. Даже если аналитик просто фиксирует запросы на доработку и помогает отвечать на вопросы "как пользователю нужно, чтобы вот в этом месте работало", при этом ещё слабо разбираясь в предметной области, не создав полные целостные [логико-математические] модели системы и организации, в первую очередь в своей голове.
А вот если и когда разберётся и создаст - тогда сможет вывести продукт на другой уровень потребительского качества и привлекательности для заказчиков.
но опять, мы о персонаже стереотипе или все же о том, у которого в голове более двух измерений?
Голова и измерения в ней - инструмент. Без хорошо подобранного инструмента качественно сделать работу очень трудно. Но рабочему платят не за то, что у него на поясе висят молоток и клещи, а за результат работы, которую он с их помощью делает.
-
tolikspb согласно с вами, но на моей практике... такой человек становится руководителем, все больше отдаляясь от аналитики.
наверное да...
-
AlexTheRaven спасибо, весьма развернуто и полезно!!!
по балластам одно но, пройдя цикл от начала до нуля проект-сотрудников надо либо перепрофилировать либо закрыть...этим сотрудникам нужно или перенастроиться на новое или уйти, просто созерцать смысла нет, но отношение к этим кадрам обычно все-таки много положительнее и лояльнее, чем к только что нанятому...и аналитик в принципе в иерархии не особо участвует...хотя все очень индивидуально конечно, спору нет!
-
и не потому что ему хочется таскать кирпичи, просто во многих компаниях ( может мне в этом плане не повезло) что-то решать может только руководитель, а аналитик хоть каким талантом он не обладай - все равно простой рабочий. Вот и таланту чтобы доказать свою правоту приходится становиться руководителем.
а вот это вопрос того самого доверия...согласен - встречается нередко.