Я бы посетила семинар, посвященный количественным методам оценки эффективности:
- работы аналитика, как конкретного сотрудника;
- процессов, связанных с требованиями (разработка, управление, и подпроцессы, входящие в разработку).
Измерить эффективность тестировщиков, например, намного проще.А вот в этом я сомневаюсь. Можно услышать аргументы? (т.к. это оффтоп, то можно в личку :) )
Измерить эффективность тестировщиков, например, намного проще.Интересно было бы узнать варианты,но на мой взгляд, метрики для оценки эффективности тестировщиков, не проще. Не думаю что аналитика, как специалиста, удовлетворят метрики вида: "сколько требований было реализовано с первого раза, без дополнительных уточнений", "сколько времени было затрачено на выявление требований".
Не думаю что аналитика, как специалиста, удовлетворят метрики вида: "сколько требований было реализовано с первого раза, без дополнительных уточнений", "сколько времени было затрачено на выявление требований".
А вот в этом я сомневаюсь. Можно услышать аргументы?
Возвращаясь к отцу Вигерсу, находим следующие характеристики идеальных требований:Список хороший. Только он основан исключительно на экспертных оценках людей, проверяющих требования.
1. Полнота
2. Однозначность
3. Корректность
4. Тестируемость
5. Трассируемость
6. Согласованность
(необходимость и осуществимость я не включаю, т.к., на мой взгляд, не удовлетворяющие этим критериям требования вообще не должны попадать в документы).
Можно опираться на этот список для проверки качества требований.
Хорошим показателем качества требований является количество запросов на изменения после начала реализации и поставки системы заказчику.
Можно даже строить различные графики, показывающие отношение запросов на изменение к общему набору требований
Делая различные срезы можно оценивать эффективность работы аналитика
Пример из практики. По каждой функциональной области системы был назначен ответственный аналитик. После фиксации требований (читай бейзлайн) все изменения в документацию вносились по запросам на изменение. Так вот, аналитика по документу которого было больше всего запросов на изменение и вопросов от разработчиков, можно считать менее эффективным. Но это статистика, а в жизни еще бывают факторы которые нужно учитывать : опыт, работоспособность, умение коммуницировать с заказчиком, аналитический склад ума и умение видеть альтернативы.
NB: Субъективные оценки важны и нужны, потому что качество — это соответствие ожиданиям ключевых ЗЛ, а ожидания всегда субъективны.
Хорошим показателем качества требований является количество запросов на изменения после начала реализации и поставки системы заказчику.
Качество -не есть соответствие чьим либо ожиданиям. Мне кажется, что качество аналитика - это…Вы правда считаете, что можно вести дискуссию подобным образом?
Короче вывод получается такой - что оценка аналитика (персоны, работника) есть действительно субьективная штука, только наверное не внешними (по отношению к проекту/процессу) личностями, а самой командой1. Кто такие «внешние»? 2. Что такое «сама команда», если в процесс управления требованиями вовлечено, например, 9 производственных ролей?
Качество -не есть соответствие чьим либо ожиданиям.Ожидание - есть потребность в чем-то.
Ни разу не согласен - например, одному попалась разработка справочников системы (относительно стабильной части) а другому - требования по новой (развивающейся) ветке бизнеса...Никто и не говорит про то, что руководитель должен "тупо" смотреть на статистику. Если вы знаете все нюансы работы в команде и кто чем занимается, можно и без статистики оценить работу сотрудников. Однако это ваши личные оценки, а иногда требуется доказательства например высшему руководству для повышения должности и/или зарплаты сотрудника. Для больших команд или отделов, это всего лишь один из множества методов.
Кроме того, качество требований не равно тождественно качеству аналитика!!!!! Ведь они отчасти создаются и бизнесом (заказчиком)
этот подход не учитывает командную работу. бывает так, что у одного аналитика действительно мало запросов на изменения, но когда доходит до объединения результатов с другими аналитиками, то всё оказывается совсем не так радужно.Учитывает. Общее количество требований на все запросы на изменение. Можно придумать разные выборки, отношение это лишь одна из них. Графики можно строить помесячно, или по бейзлайнам. Также можно отследить источник запроса на изменение.
Думаю что следует задать главный вопрос:Кому вопрос?
Для какой цели Вы планируете использовать количественную оценку работы аналитика ?
Kirillss, расскажите про свой опыт и то, как вы оцениваете эффективность.
Бытует мнение, что создание, внедрение и использование различных шкал оценки персонала относится к "смертельным грехам менеджмента". Не верите мне, почитайте метров. Деминга почитайте (http://findbook.ru/redir/book?url=http%3A%2F%2Fwww.bolero.ru%2Fcgi-bin%2Fdsc.cgi%3F66641528%26partner%3Dfindbook%26new%3D1).Де Марко вроде бы по другому считает :)
Или Генри Нива : http://findbook.ru/redir/book?url=http%3A%2F%2Fmy-shop.ru%2Fshop%2Fbooks%2F132831.html%3Fpartner%3D00519 (у него язык попроще)
Де Марко вроде бы по другому считает :)
Ты бы ещё Макконнелла вспомнил. :)Да никак они у нас не используются!
А правда, расскажи, как у вас используются эти показатели качества? Это числовые метрики? Вы их используете просто как индикаторы в динамике (в этом месяце стало больше запросов на изменения - красная лампочка зажглась), числа как ориентировочные значения (должно быть не более 10% "плохих" требований) или для сравнения аналитиков между собой?
...то функционал практически не дорабатывается первые три четыре месяца. Если анализ был проведен неверно, то как правило возникает большое колличество доработок.
Ошибку мог допустить раработчик - тестировщики ее пропустили - а пнут аналитика.доработка функционала - как-то на ошибку не тянет.
Да никак они у нас не используются!Управление рисками по модели риск-оптимувов не хотите попробовать?
Сам не знаю как их применять нужно по правильному - не дорос еще.
Я их делал исключительно для себя.
У нас эффективность оценивается путем подсчета заявок на доработку того или иного функционала. То есть если аналитик отработал хорошо, то функционал практически не дорабатывается первые три четыре месяца. Если анализ был проведен неверно, то как правило возникает большое колличество доработок.Круто. Посмотрите у Деминга, кто в процентном отношении виноват в браке. Результат вас неприятно удивит.
Огласите плз в какой бизнес-области работаете, делаете продукт или заказная разработка, методология разработки - используется ли agile-подходы, outsourcing или внутренняя разработка? Просто интересно в каком случае такой подход работает!!!!!!А какая разница в какой области?
Если применять подход дословно то это презумпция виновности аналитика))))
.. параметр "количество запросов на изменение" ..бесполезен для отслеживания эффективности работы аналитика..
2Salar
Вы не могли бы изьясняться более конкретно - а то одни отсылы к толстым фолиантам, а конкретики не видно
1 "Бытует мнение, что создание, внедрение и использование различных шкал оценки персонала относится к "смертельным грехам менеджмента"." Тема так и не раскрыта
2 "Посмотрите у Деминга, кто в процентном отношении виноват в браке." Тема так и не раскрыта.
Кто отвечает за качество? Ответ: высшее руководство. Качество продукции компании не может быть выше уровня, который был определён наверху.
Ранжирование — это фарс. Производительность труда на самом деле зависит большей частью от системы, в которой работает человек, а не от него самого.
Убеждение в том, что, если проблему нельзя измерить, то её невозможно решить, — это очень дорогостоящий миф.
По моему опыту, большинство проблем и возможностей улучшить ситуацию соотносятся примерно так: 94% приходится на систему (ответственность руководства) и 6% — на особенные причины.
Ошибку мог допустить раработчик - тестировщики ее пропустили - а пнут аналитика.На самом деле немного не так. Речь идет не о багах кода, а о багах ТЗ ( например отсутствие заложенного функционала необходимого пользователю, или некорректная работа разрабатываемого функционала с другими модулями системы)
Огласите плз в какой бизнес-области работаете, делаете продукт или заказная разработка, методология разработки - используется ли agile-подходы, outsourcing или внутренняя разработка? Просто интересно в каком случае такой подход работает!!!!!!
Если применять подход дословно то это презумпция виновности аналитика))))
Вот и программист - прочитает по-русски, а поймет "так". Потом "так" сделает.1. По поводу неправильного понимания программистом. У нас существует практика проверки того что написал программист аналитиком ( то есть насколько написанный функционал соответствует изначально задуманному аналитиком).
Меня удивляет, что на форуме аналитиков ни один аналитик не обратил внимание на то, что запросы на изменение могут иметь какую угодно причину. далеко не всегда эта причина существовала в момент, когда аналитик зафиксировал, а заказчик согласовал требования. Она могла появиться позже и к аналитику не иметь никакого отношения.
Поэтому параметр "количество запросов на изменение" так же бесполезен для отслеживания эффективности работы аналитика, как стрельба из пистолета в ручей - если долго стрелять, обязательно попадешь в рыбу. Когда-нибудь.
Необходимо еще устанавливать причину этих запросов: являются ли они новыми требованиями заказчика, недовыявленными аналитиком требованиями или следствиями ошибок программистов.
2SalarПростите, а как вы собираетесь стать профессионалом, не читая толстых фолиантов? Конкретно Деминга и Голдрата читать нужно.
Вы не могли бы изьясняться более конкретно - а то одни отсылы к толстым фолиантам, а конкретики не видно
2 "Посмотрите у Деминга, кто в процентном отношении виноват в браке." Тема так и не раскрыта.На это Григорий ответил. Мне остается только добавить, что Деминг неоднократно пересматривал свою оценку, все время увеличивая долю ответственности руководства за брак.
1 "Бытует мнение, что создание, внедрение и использование различных шкал оценки персонала относится к "смертельным грехам менеджмента"." Тема так и не раскрыта
СМЕРТЕЛЬНЫЕ БОЛЕЗНИМожет все таки найти книгу и прочитать?
...
3. СИСТЕМЫ АТТЕСТАЦИИ И РАНЖИРОВАНИЯ ПЕРСОНАЛА
Системы аттестации и ранжирования персонала, оценка личного вклада, ранжирование по значимости, оценка качества функционирования, ежегодная аттестация, премиальные системы, плата по труду — оказывают разрушительный эффект.
"Управление по Целям" — зло того же порядка; "управление на основе страха" было бы более подходящим его названием. Результаты подобной практики следующие:
Развивается "близорукое" мышление, взращивается соперничество, интриганство и страхи, уничтожается перспективное планирование, разрушается дух команды; Одни люди испытывают чувство горечи, другие — отчаяние, некоторые работники переживают депрессию, из-за которой они неработоспособны в течение недель после получения оценки своей деятельности, причем они не в состоянии понять, в чем их вина. Эти методы несправедливы, т. к. они приписывают людям в группах такие различия, которые могут быть полностью обусловлены системой, в которой работает группа. (см. главу 30).
ткните пальцем, где из предыдущего обсуждения четко и ясно следует, что речь шла именно об этом?...
речь шла о запросах на изменение - из 20 человек, участвующих в обсуждении, каждый может подразумевать под "запросами на изменение" все, что угодно.
вот это типичная программерская логика: "а я думал, что это не то, а это..." Елы-палы, ну мало ли кто что думал - не можем же мы друг другу залезть в мозги и поправить там нужные шестеренки.
Остается только один инструмент взаимопонимания - язык. Если пользоваться им по назначению.
Простите, а как вы собираетесь стать профессионалом, не читая толстых фолиантов? Конкретно Деминга и Голдрата читать нужно.Сергей, т.е. ты полагаешь, что без прочтения этих авторов ну никуда? И специалист не специалист?
У нас эффективность оценивается путем подсчета заявок на доработку того или иного функционала. То есть если аналитик отработал хорошо, то функционал практически не дорабатывается первые три четыре месяца. Если анализ был проведен неверно, то как правило возникает большое колличество доработок.Если я правильно понял, причина сомнения многих коллег относительно эффективности этого способа оценки основывается на уверенности в том, что за 3 месяца у заказчика требования поменяются в любом случае, так как он более глубоко осознает задачу по мере наблюдения за разработкой. Я раньше придерживался такого же мнения, тем более, что эта точка зрения помогает аналитику снимать с себя ответственность за большое количество чейндж реквестов на функционал.
Если я правильно понял, причина сомнения многих коллег относительно эффективности этого способа оценки основывается на уверенности в том, что за 3 месяца у заказчика требования поменяются в любом случае, так как он более глубоко осознает задачу по мере наблюдения за разработкой. Я раньше придерживался такого же мнения, тем более, что эта точка зрения помогает аналитику снимать с себя ответственность за большое количество чейндж реквестов на функционал.
Но в последнее время мне кажется, что действительно профессиональный аналитик, умеющий докапываться до корневых проблем, разбирающийся в предметной области, и представляющий современные технологические и бизнес - тенденции должен предвидеть (хотя бы на 90%) такие изменение требований и заранее предлагать их заказчику.
Другое дело, что когда появляется такой человек, то он за одну зарплату долго не работает ;)
Если заказчик изменит изначальные требования, то это не ошибка аналитика. Лучьше привести пример наверно. Например ставится задача разработки интернет магазина. Аналитик исследует предметную область и собирает требования. После реализации оказывается, что интернет - магазин не обладает функционалом для заказа товара (утрированыый такой случай). То есть разработанный механизм не удовлетворяет изначальному требованию (что либо продавать). Вот это прямая ошибка аналитика. А если после разработке заказчик говорит, я тут полазила по сайтам и хочу что бы меню было справа, а не слева, как мы сначала договаривались. Это не ошибка аналитика, а простое изменение требований (аналитик не виноват).LastLegion86:
Но в последнее время мне кажется, что действительно профессиональный аналитик, умеющий докапываться до корневых проблем, разбирающийся в предметной области, и представляющий современные технологические и бизнес - тенденции должен предвидеть (хотя бы на 90%) такие изменение требований и заранее предлагать их заказчику.
По поводу запросов на изменение...
А как вам такой случай - заказчик пустил аналитиков только на один из своих объектов, с мотивацией - у нас бизнес процесс единый и этот объект лучший. На все наши доводы, что дайте нам хотя бы сделать экспресс анализ нескольких объектов для получения сравнительной оценки только отмахнулся.
Что имеем в итоге - по закону подлости это оказался единственный объект, в котором отсутствовал важный элемент бизнеса. В итоге получили серьезную проблему и МНОГО запросов на изменение. Но аналитик не виноват...
Если уж судить работу аналитика по количеству запросов на изменение, то надо брать каждый (запрос) и анализировать его природу. Трудоемкая работа.
А как вам такой случай - заказчик пустил аналитиков только на один из своих объектов...Для аналитика это из разряда "Бывает"... Самый ловкий спецназовец может попасть под шальную бомбу. Надо набирать статистику по работе аналитика по разным проектам,с учетом их сложности.
Что имеем в итоге - по закону подлости это оказался единственный объект, в котором отсутствовал важный элемент бизнеса. В итоге получили серьезную проблему и МНОГО запросов на изменение.
В данном случае это не проблема аналитика, а тупость заказчика. Если при обсждении ТЗ он не заметил того что там отсутствует выжный аспект бизнеса.
А по данному случаю это недоработка ПМа - он должен был после отказа пустить на другие объекты заставить закзачика подписать бумагу, что если на других объектах обнаружатся дополнительные требования, то это будет расширение рамок договора и, следовательно, доп. соглашение по деньгам.
По поводу трудоесмкости, я бы не сказал что это трудно. В любом случае когда возникает какая либо задача(запрос на доработку), то явно или неявно задается вопрос: "А почему заказчик это хочет, зачем оно ему и почему не сделано раньше?". Поэтому это как бы побочный результат от основного процесса. Плюч ко всему необезательно переводить данный показатель в числовые значения. Его можно использовать для получения обшей картины работы аналитика/ов.Перевести "в числовые значения" (некие абсолютные показатели) не сложно. Проблематично провести детальный анализ запросов в условиях большого числа изменений вцелом по фирме. А проводить анализ в рамках проекта неправильно - не та компетенция: аналитики проекта - лица заинтересованные, РП могут не обладать необходимой глубиной знания предметной области (если предметка достаточна сложна) и понять природу изменения. Нужно привлекать специалистов из других проектов, подразделений (или даже заказчиков систмы...).
При работе по найму первым, что я делала, получив отчет заказчика о тестировании очередной версии - разбрасывала замечания в три кучки (какие именно, писала выше).Не нашлись описания про кучки ((
Если пользоваться моим примером, то некоторое представление об эффективности даст соотношение размеров кучек.
А как вам такой случай - заказчик пустил аналитиков только на один из своих объектов, с мотивацией - у нас бизнес процесс единый и этот объект лучший.А это, как нам Гриша пояснил на конференции ReqLabs, - "Персональные риски аналитика" :). Спасибо ему, хороший был доклад!
Наверно, можно оценить эффективность аналитика по количеству запросов на изменение, вот только анализ этих самых запросов должен быть очень качественным.
LastLegion86, а можно пару уточняющих вопросов - т.е. вы анализируете каждый запрос на изменение и типизируете (дифференцируете) его. Кто участвует в этом процессе (РП, нач. отдела аналитики, ведущий разработчик, архитектор или...).
Перевести "в числовые значения" (некие абсолютные показатели) не сложно. Проблематично провести детальный анализ запросов в условиях большого числа изменений вцелом по фирме.
kirillss
3. Не совсем понимаю что значит 'Для такой методы оценки должна быть хорошо отлажена трассируемость требования-фича-релиз-баг'. Поясните плиз. :)
1. Оценка требований продукт-менеджером и менеджером проекта относительно общего качества и эффективности продукта на рынке после разработки продукта.Для менеджера продукта - системные требования отвратительные: в них не вошла и половина того "турбулентного потока сознания", который он выплеснул на системного аналитика. Ну и что, что это потому что архитектор с ведущим разработчиком сказали, что реализовать невозможно.
2. Отзывы ключевых клиентов о реализации процесса управления требованиямиДля ключевого клиента требования отвратительные: его "хотелки" не будут реализованы сейчас же, как он хотел! Клиент этим не удовлетворён, ну и что, что он сменил "элитную" поддержку на самую дешёвую, и хочет сделать из АСУ склада систему SCADA. Да к тому же он же написал "сделайте, чтобы мне было хорошо, нажимаешь кнопку и ага!", чего уж непонятного, а этот глупый системный аналитик зачем-то расспрашивает...
3. Показатели удовлетворенности клиентов
4. Соблюдение или превышение планов разработки требований, ограничений по ресурсам и качественных целейПлан не соблюли! Хотели сделать за неделю 20 UC на 15 страниц, а пришлось 3 месяца делать 1500 требований и UC на 2000 страниц. Ну и что, что оказалось, что это - естественная сложность предметной области, помноженная на то, что решили делать подробное ТЗ для аутсорсеров...
5. Контроль расползания требований, связанный с пропущенными требованиями и просачиванием "неформальных" требований в проектТребования "расползлись", разработчики всеми правдами и неправдами добились того, что в SRS прошло их представление о том, что нужно Заказчикам. Ну и что, что именно благодаря этому продукт имел оглушительный успех.
Так, на мой взгляд, выглядит идея проектных измерений в общих чертах. В любом случае метрики - это просто информация к размышлению, позволяющая выявить риски и проблемные области с большой долей объективности.+100, о чем я и пытался сказать в самом начале. А народ хочет все свести к автоматизму, это невозможно! Нужно еще мозгами и руками потом поработать.
Возникает резонный вопрос: а есть ли идеал, пусть недостижимый, но к которому реально стремиться? Или аналитик обречен ощущать всеобщее недовольство?
NB: Субъективные оценки важны и нужны, потому что качество — это соответствие ожиданиям ключевых ЗЛ, а ожидания всегда субъективны.
Вот... а для того, чтобы иметь возможность четко определить, какой результат и при каких затратах должен быть получен, нужна статистика, нужны какие-то показатели, метрики - т.е. чтобы еще и было понятно, что реально за такое-то время сделать можно вот столько-то с таким-то качеством... Иначе оценки с большой долей вероятности будут субъективными, на мой взгляд. :)Никуда мы не денемся от субъективности. Даже если мы вводим показатели, шкалы, каталоги компетенций, их КТО-ТО вводит, КТО-ТО отбирает исходные данные для оценки. Даже для оценки 360 КТО-ТО отбирает людей, которые будут оценивать специалиста. Всем хочется, чтобы этим КТО-ТО был либо он сам, либо тот, кому он доверяет и очень страшно, что оценивать будет какой-то не понятно откуда взявшийся человек по непонятным никому правилам.
очень страшно, что оценивать будет какой-то не понятно откуда взявшийся человек по непонятным никому правиламВот поэтому правила-то и должны быть понятны, т.е. заранее определены и озвучены всем оцениваемым и, желательно, с ними согласованы... Хотя, по-моему, это уже попахивает утопией... ::)
Хороший вопрос! :) Правда, когда мы говорим о "всеобщем недовольстве", мы должны понимать, что здесь мы как раз говорим об ожиданиях тех или иных лиц: представителей заказчика, менеджера проекта, разработчиков, тестировщиков... Можно ли по субъективным ожиданиям давать оценку эффективности? Исходя из определения эффективности (например, вот такого: "ЭФФЕКТИВНОСТЬ — относительный эффект, результативность процесса, операции, проекта, определяемые как отношение эффекта, результата к затратам, расходам, обусловившим, обеспечившим его получение", http://slovari.yandex.ru/dict/economic), скорее всего, нет.
Поэтому чтобы говорить об эффективности необходимо сравнивать характеристики полученного результата с затратами тех или иных ресурсов, выраженных количественно. Чтобы иметь такую возможность сравнивать, нужно определить, описать заранее, каков должен быть результат (например, что и в какие сроки и с каким качеством должно быть сделано) и какие допустимы затраты (например, такая-то задача должна быть решена за столько-то часов).
Вывод получается что оценивать все таки надо не аналитиков, а целиком команду или решение/продукт полученный этой командойДа. Так оно и есть.
Согласны?
5. Немного о самих показателях.
Скорее всего, можно говорить о качественных и количественных показателях. Показатели можно разделить на: показатели, динамика роста которых отражает эффективность деятельности; показатели, динамика снижения которых отражает эффективность деятельности.
Примеры (подготовлены на скорую руку, прошу отнестись с пониманием).
Общие:
а) количество видов деятельностей, в которых аналитик компетентен.
Если, например, знания и опыт, синтезированные в навыки позволяют ему эффективно выполнять все вышеобозначенные виды деятельностей, значит он по этому показателю эффективен – насколько, можно определить пропорцией «x/8».
Выявления (для задачи «идентификация и описание заинтересованных в проекте лиц»):
а) знание всех областей в которых осуществляется идентификация;
б) знание принципов и методов идентификации ЗЛ из каждой области;
в) время затраченное на выделение;
г) время затраченное на описание;
но в каком-то конкретном случае ты можешь оказаться "не ко двору", потому что начальство ценит не профессионализм, а личную преданность.а причем тут тогда "объективная правота" и эффективность?;)