Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - InfinitI

Страницы: « 1 2 3 4 5 6 7 8 »
46
А что именно нужно сделать, чтобы 3-ий выпуск журнала вышел в свет? :)

47
но в каком-то конкретном случае ты можешь оказаться "не ко двору", потому что начальство ценит не профессионализм, а личную преданность.
а причем тут тогда "объективная правота" и эффективность?;)

48
5. Немного о самих показателях.
Скорее всего, можно говорить о качественных и количественных показателях. Показатели можно разделить на: показатели, динамика роста которых отражает эффективность деятельности; показатели, динамика снижения которых отражает эффективность деятельности.
Примеры (подготовлены на скорую руку, прошу отнестись с пониманием).
Общие:
а) количество видов деятельностей, в которых аналитик компетентен.
Если, например, знания и опыт, синтезированные в навыки позволяют ему эффективно выполнять все вышеобозначенные виды деятельностей, значит он по этому показателю эффективен – насколько, можно определить пропорцией «x/8».

Выявления (для задачи «идентификация и описание заинтересованных в проекте лиц»):
а) знание всех областей в которых осуществляется идентификация;
б) знание принципов и методов идентификации ЗЛ из каждой области;
в) время затраченное на выделение;
г) время затраченное на описание;

Идея мне очень понравилась! Потому что понятно было, что надо выделять какие-то показатели, понятно, что один из способов выделения показателей - это разложение процесса на действия... Но как-то не связывала эти моменты друг с другом до сих пор... Вообще, мне было бы интересно развить эту тему. :)

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

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

Т.е. понятно, что можно было бы дальше задаться вопросом: а почему дочкам не нужно?... Но, на мой взгляд, все равно пришли бы к тому, что тогда, по-хорошему, надо было разбираться с каждым столбцом в отдельности. :) И в итоге все равно приходим к тому, что это дополнительные трудозатраты...

51
Возникает резонный вопрос: а есть ли идеал, пусть недостижимый, но к которому реально стремиться? Или аналитик обречен ощущать всеобщее недовольство?

Хороший вопрос! :) Правда, когда мы говорим о "всеобщем недовольстве", мы должны понимать, что здесь мы как раз говорим об ожиданиях тех или иных лиц: представителей заказчика, менеджера проекта, разработчиков, тестировщиков... Можно ли по субъективным ожиданиям давать оценку эффективности? Исходя из определения эффективности (например, вот такого: "ЭФФЕКТИВНОСТЬ — относительный эффект, результативность процесса, операции, проекта, определяемые как отношение эффекта, результата к затратам, расходам, обусловившим, обеспечившим его получение", http://slovari.yandex.ru/dict/economic), скорее всего, нет.

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

Вот хороший показательный пример. Задача моей коллеги заключалась в том, чтобы обеспечить формирование отчета, содержащего около 100 столбцов. Ей необходимо было сказать разработчикам, какая информация, по какому алгоритму и из какого места системы должна была браться в каждый из столбцов. У нее была инструкция, полученная от заказчика, в которой было описано, что должно содержаться в каком столбце отчета. При этом, согласно этой инструкции, часть столбцов отчета заполняться не должна была. Логично, что прорабатывала она в итоге оставшуюся часть, т.е. те столбцы, которые заполнять было нужно. В результате, спустя несколько месяцев выяснилось, что один из столбцов, которые по инструкции заполняться не должны были, заполнять было нужно. Коллега получила нагоняй за то, что "не подумала" об этом заранее. Правильно ли это? На мой взгляд, нет. Потому что тогда, получается, она должна была отдельно проанализировать каждый из не подлежащих заполнению столбцов (согласно инструкции) на предмет необходимости его заполнения. (А нагоняй она получила именно за этот конкретный столбец, что именно про него она не подумала.) Но такой задачи перед ней никто не ставил. Более того, в виду очень ограниченного количества времени, отведенного на реализацию, у нее просто даже физически не было возможности этим заниматься.

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

52
Отличная идея! Готова поддержать любую тему :)
Виталик, может у тебя есть уже какие-нибудь наброски мыслей и т.д.? ;)

Со своей стороны, обещаю подумать.

53
А вот в этом я сомневаюсь. Можно услышать аргументы?

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

Так что прошу прощения за то, что ввела вас (да и себя) в заблуждение. ::) Получается, что тема по-прежнему остается открытой...

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

Почему не удовлетворят? По результатам дополнительных уточнений порой постановка задачи целиком переписывается и хорошо, если это происходит до того, как требования отданы в реализацию. К тому же, по таким данным можно делать выводы и пытаться понять, что именно послужило причиной того, что требование, например, не было реализовано с первого раза, и что можно предпринять для того, чтобы в следующий раз не случилось того же самого.

P.S. Что касается оценки эффективности тестировщиков по сравнению с аналитиками, аргументы приведу позже. Может, имеет смысл это обсуждение перенести в отдельную тему, коль уж есть подозрения на оффтоп?  

55
Я бы посетила семинар, посвященный количественным методам оценки эффективности:

- работы аналитика, как конкретного сотрудника;
- процессов, связанных с требованиями (разработка, управление, и подпроцессы, входящие в разработку).

Бытует мнение, что оценить эффективность работы аналитика практически не представляется возможным, потому что сложно подобрать количественные измеряемые показатели. Измерить эффективность тестировщиков, например, намного проще. Что касается, требований и процессов, с ними связанных, то здесь все не так сложно - нужно только определить критерии / показатели, по которым хотим оценивать. Например, это может быть время, затрачиваемое на выполнение каких-то действий, или количество ошибок в требованиях или что-то еще в этом роде.

А вообще, мне, например, эта тема давно интересна, но в связи с тем, что она не востребована, и тем, что все как-то не доходят руки, пока тоже вопросов больше, чем ответов.

56
Типичная ситуация: аналитик едет к заказчику и там с ним оживлённо беседует. Вопросы задаёт, шутит, картинки рисует - живой такой, весёлый. Экстраверт, в общем.

Потом он приезжает к себе на работу и садится писать отчёт о встрече. Разгребает свои картинки, записи, отключает телефон, кофе пьёт литрами, на всех приближающихся к его столу тихо рычит. Или просто игнорирует. Интроверт, однозначно.
Вот, я такая же...  ::) А дома рычу порой еще сильнее.  :D

57
Работа / Re: Знание английского языка
« : 05 Ноября 2009, 14:52:08 »
Аналогию не понял. Я сомневаюсь, что студентов кто-то обижает за то, что они читают книги. Скорее наоборот.
Имеется в виду, что студентов надо отучать читать только Википедию (и не читать книг). :)

58
Для всех / Re: Кто я?
« : 05 Ноября 2009, 13:28:33 »
Согласна. Имхо, у аналитика и руководителя проекта разные интересы по ролям. У аналитика - полнее и точнее описать требования клиента, у руководителя проекта - сделать систему с минимальными трудозатратами.
Т.е. вы намекаете на то, что при таком раскладе менеджеру проекта, по совместительству выполняющему роль аналитика, может быть просто не выгодно "обращать внимание" на какие-то требования клиента? ;) Точнее, учитывая, что задача МП сводится к тому, чтобы минимизировать трудозатраты, в том числе, возможно, и за счет минимизации усилий по выявлению и описанию требований, он как аналитик рискует недовыявить требования и тем самым навредить и всему проекту?

59
Для всех / Re: Кто я?
« : 05 Ноября 2009, 12:57:11 »
Классификация вполне соответствует и моему пониманию. На тему совмещения должностей есть в MSF любопытная табличка Из нее в частности вытекает что совмещение аналитика и руководителя проекта(PM) нежелательно. Мой опыт (в данном случае горький!) подтверждает это.
Интересная мысль! Мне как-то всегда казалось, что это, в принципе, возможно... Может, поясните, к каким последствиям такое совмещение может привести? ;)

60
Для всех / Re: Кто я?
« : 04 Ноября 2009, 02:01:21 »
Здесь проблемы:
1. Я программист.
Часто мне не хватает какого-то проектирования при реализации той или иной программы. Все планирование ведется во время написания кода. Бывает так, что приходится переписывать часть кода, либо применять рефакторинг из-за неудобной реализации или просто пришло в голову что-то более оптимальное. Из-за этого часто появляется мертвый код, т.е. код который уже не используется, но чтобы это определить надо затратить довольно много времени.
2. Мне приходится анализировать ТЗ, разрабатывать общую структуру ПО и выдавать задания другим программистам.
В наших ТЗ часто присутствуют противоречия. Объемы большие и процесс затягивается. Часто получается так, что противоречие найдено позже чем уже есть какой-то вариант реализации. Так же бывает, что часть требований не имеют достаточного описания.

Вызывает их мое незнание в этих областях.
Интересно было бы посмотреть на того, кто убедил вас в том, что ответственность за бардак в организации процесса разработки лежит на ваших плечах... :)

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

P.S. А вообще, набор действий для решения проблемы "спасение компании" целиком и полностью зависит от того, как вы определите то, чего вы хотите достичь для себя лично.

Страницы: « 1 2 3 4 5 6 7 8 »