В теме 23 ответа, и 8 участников, последнее обновление сделано пользователем 
-
Сообщения
-
Как обычно, в степени удовлетворенности Заказчика =)
Представим ситуацию: есть 2 аналитика. Аналитик А выполнил задачу заказчика за один день, после этого у программистов ушел еще один день на ее реализацию. +День на тестирование и деплоймент. Итого: 3 дня на решение задачи.
Аналитику Б понадобилось 3 дня на то, чтобы выполнить задачу заказчика, но в процессе он вскрыл потенциальную дыру в приложении, которую раньше проглядели. Для заказчика эта "дыра" ни о чем не говорит, потому что он человек не имеющий почти никакого представления об IT, и проблема просто выше его понимания. Но команда знает, что если дыру не закрыть, потенциально это может привести к утечке важных данных. У девелоперов уходит 2 дня (1 на фикс дыры, без которого нет смысла выполнять задачу, 2 на выполнение задачи). + День на тестирование и деплоймент.
Итого: 6 дней на решение задачи.Вопрос: работа какого из аналитиков качественней?
Вопрос: работа какого из аналитиков качественней?
На мой взгляд это и подчеркивает субъективность/ситуативность оценки.
Возможно ли оценить качество работы аналитика в указанной ситуации без учета того, какой из факторов важнее для заказчика (стоимость, время, качество)? На мой взгляд — нет.
Как А, так и Б могут здесь считаться "качественнее", если знать максимум деталей о команде, заказчике, ходе проекта и самих этих аналитиках.На мой взгляд, первого, так как1) Он выполнил поставленную задачу быстро и качественно с точки зрения самой задачи
2) У него осталось время заниматься случайными дырами без ущерба задачам, которые перед ним ставят
3) Время , потраченное аналитиком, командой, полностью было оплачено заказчиком.Второй же аналитик занялся помимо выполнения задачи еще и потенциальной дырой (грубо говоря, отвлекся). Он мог сделать пометку, что по окончанию работы над задачей, обратить внимание на несколько моментов, которые привели к вскрытию проблемы, ведь проблема уже существовала и приложение с ней работало. К тому же Аналитик B не смог продать заказчику эту дыру и объяснить, почему ее необходимо пофиксить: то есть время, потраченное аналитиком и остальной командой, не было оплачено заказчиком, в результате, команда проработала бесплатно.
есть время, потраченное аналитиком и остальной командой, не было оплачено заказчиком, в результате, команда проработала бесплатно.
В обоих случаях время, потраченное командой, было оплачено польностью.
Интересную тему подняли, но, к сожалению, никто так и не смог дать ответа на поставленный вопрос, то есть большинство отзывов было, либо о личных характеристиках, либо о частных случаях. Попробую тогда подкинуть кое какие мысли касательно этого.
Итак, понятно, что любой проект базируется на трёх китах: Качество, Деньги, Время. Данные киты применимы к любому участнику проекта, в том числе и аналитику. Отбросим составляющую Деньги (об этом заботятся другие люди) и получим, что от аналитика в плане продуктивности и эффективности требуется Качество и Время. Вот по этим двум параметрам мы и будем его оценивать.Прежде всего посмотрим как можно оценить работу с точки зрения времени. Понятно, что аналитик, как и любой другой член команды работает по внутреннему плану, то есть имеет список задач с определенной продолжительностью работы. Тогда получается следующая картина:
- Планируемое время на задачу — pT
- Contingency — Y (зависит от сложности задачи)
- Актуальное время, потраченное на задачу — aT
Далее, забиваем эти данные, например, в Excel и смотрим динамику по задачам, если картина выглядит следующим образом: pT <= aT <= pT*(1+Y), то аналитик работает эффективно с точки зрения времени. Если же время aT выбивается (в большую сторону), то это уже повод для того, чтобы побеседовать с человеком.Что касается качества, то тут всё гораздо сложнее. На текущий момент есть только общие мысли/представления касательно этого, если кто то разовьёт их дальше, то будет здорово. Итак, в качестве входов для функции оценки качества поставляемой документации можно использовать следующие параметры:
- Количество страниц документации — pN
- Количество дизайн ошибок для конкретной документации — iN
- Сложность реализуемого функционала — X
…
Далее осталось понять, чего же нам ещё не хватает для входа и что же мы ожидаем увидеть на выходе. Над этим надо подумать и поработать ещё, если будут мысли, то пишите.Не всё так просто.
Во-первых, вы говорили про проект и про проектные 3 кита. Аналитик — это часть проекта, а часть, как вы знаете, может сильно отличаться от целого. Что важно для целого, не всегда важно для части, и наоборот.
Во-вторых, 3 кита — это довольно узко. Пример.. Проект выполнили в срок и бюджет и с нужным качеством, но после проекта Заказчик ушёл. (Сами догадайтесь почему). Другой пример.. Проект выполнили в срок и бюджет и с нужным качеством, но после проекта Команда ушла / кто-то получил нервный срыв / … (Тоже догадайтесь почему).. Я уверен, что можно ещё придумать (;Да и даже что касается, например, Времени, с которым вы, как будто, уже разобрались.
Contingency, которое, конечно, лучше назвать просто погрешностью, стоит считать как в одну, так и во вторую сторону (т.е. не только +, но и -). Потом.. а кто давал эту оценку? Если кто-то другой, то, может, этот другой не брал в расчет, что именно этот аналитик будет выполнять эту работу и дал сильно оптимистическую оценку? Или может этот другой просто ошибся? А если это был сам аналитик, то, может, он тоже ошибся, когда её давал? А даже если он ошибся, он вложился в приемлемое для проекта и заказчика время? Ну а если аналитик ошибся, когда давал оценку, то это ведь тоже работа.. и это тоже важное качество, уметь оценивать свою работу.Как видите вопросов больше, чем ответов (:
Ну и напоследок, ещё один, правда не от меня (;
Определить формальные правила конечно можно, всегда. А польза от этого кому и какая?
Касательно первых двух пунктов, они имеют мало общего с представленной тут темой, можно дополнительно обсудить в рамках других тредов.
Гораздо более интересны пункты 3 и 4. Начнём с последнего.С моей точки зрения, самый первый пост отвечает на вопросы кому и какая польза от этого. Опять же, с моей стороны это интересно прежде всего тем, что на текущем проекте внедрения работают восемь аналитиков, которых, с позиции лида по анализу, необходимо оценивать. Оценивать по следующим причинам:
1. В целях поощерения сотрудников
2. В целях подготовки резюме на сотрудника, при снятии или переводе его с проекта
3. В целях "наказания", имеется ввиду поговорить с человеком, обсудить его проблемы, если хронически не укладывается в срокиДалее, что касается пункта три:
1. Contingency — это не совсем погрешность, в данном случае это то дополнительное LOE, которое надо заложить на задачу. То есть первичная оценка не всегда может быть выдана правильно, поэтому, в зависимости от сложности задачи, дополнительно перезакладываемся.
2. Касательно выдач самих оценок. В большинстве случаев задачи оценивают BA/SA Lead(s), которые обладают богатым жизненным опытом и знают специфику той или иной области. Если случаи выдачи неверных оценок единичны, то тут нет ничего страшного, если же оценки на регулярной основе не соответствуют действительно, как в большую, так и в меньшую сторону, то есть повод призадуматься и предпринять действия по исправлению этой ситуации.И ещё, если формальные правила всегда можно определить, то почему же никто так и не поделился своим опытом? Было бы интересно посмотреть их и обсудить.
Вы должны авторизироваться для ответа в этой теме.
