46
О Сайте и Форуме / Re: А чем Вы можете помочь ресурсу uml2.ru?
« : 29 Ноября 2009, 18:55:34 »
А что именно нужно сделать, чтобы 3-ий выпуск журнала вышел в свет?

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
но в каком-то конкретном случае ты можешь оказаться "не ко двору", потому что начальство ценит не профессионализм, а личную преданность.а причем тут тогда "объективная правота" и эффективность?
5. Немного о самих показателях.
Скорее всего, можно говорить о качественных и количественных показателях. Показатели можно разделить на: показатели, динамика роста которых отражает эффективность деятельности; показатели, динамика снижения которых отражает эффективность деятельности.
Примеры (подготовлены на скорую руку, прошу отнестись с пониманием).
Общие:
а) количество видов деятельностей, в которых аналитик компетентен.
Если, например, знания и опыт, синтезированные в навыки позволяют ему эффективно выполнять все вышеобозначенные виды деятельностей, значит он по этому показателю эффективен – насколько, можно определить пропорцией «x/8».
Выявления (для задачи «идентификация и описание заинтересованных в проекте лиц»):
а) знание всех областей в которых осуществляется идентификация;
б) знание принципов и методов идентификации ЗЛ из каждой области;
в) время затраченное на выделение;
г) время затраченное на описание;
очень страшно, что оценивать будет какой-то не понятно откуда взявшийся человек по непонятным никому правиламВот поэтому правила-то и должны быть понятны, т.е. заранее определены и озвучены всем оцениваемым и, желательно, с ними согласованы... Хотя, по-моему, это уже попахивает утопией...
Возникает резонный вопрос: а есть ли идеал, пусть недостижимый, но к которому реально стремиться? Или аналитик обречен ощущать всеобщее недовольство?
А вот в этом я сомневаюсь. Можно услышать аргументы?
Не думаю что аналитика, как специалиста, удовлетворят метрики вида: "сколько требований было реализовано с первого раза, без дополнительных уточнений", "сколько времени было затрачено на выявление требований".
Я бы посетила семинар, посвященный количественным методам оценки эффективности:
- работы аналитика, как конкретного сотрудника;
- процессов, связанных с требованиями (разработка, управление, и подпроцессы, входящие в разработку).
Типичная ситуация: аналитик едет к заказчику и там с ним оживлённо беседует. Вопросы задаёт, шутит, картинки рисует - живой такой, весёлый. Экстраверт, в общем.Вот, я такая же...
Потом он приезжает к себе на работу и садится писать отчёт о встрече. Разгребает свои картинки, записи, отключает телефон, кофе пьёт литрами, на всех приближающихся к его столу тихо рычит. Или просто игнорирует. Интроверт, однозначно.
Аналогию не понял. Я сомневаюсь, что студентов кто-то обижает за то, что они читают книги. Скорее наоборот.Имеется в виду, что студентов надо отучать читать только Википедию (и не читать книг).
Согласна. Имхо, у аналитика и руководителя проекта разные интересы по ролям. У аналитика - полнее и точнее описать требования клиента, у руководителя проекта - сделать систему с минимальными трудозатратами.Т.е. вы намекаете на то, что при таком раскладе менеджеру проекта, по совместительству выполняющему роль аналитика, может быть просто не выгодно "обращать внимание" на какие-то требования клиента?
Классификация вполне соответствует и моему пониманию. На тему совмещения должностей есть в MSF любопытная табличка Из нее в частности вытекает что совмещение аналитика и руководителя проекта(PM) нежелательно. Мой опыт (в данном случае горький!) подтверждает это.Интересная мысль! Мне как-то всегда казалось, что это, в принципе, возможно... Может, поясните, к каким последствиям такое совмещение может привести?
Здесь проблемы:Интересно было бы посмотреть на того, кто убедил вас в том, что ответственность за бардак в организации процесса разработки лежит на ваших плечах...
1. Я программист.
Часто мне не хватает какого-то проектирования при реализации той или иной программы. Все планирование ведется во время написания кода. Бывает так, что приходится переписывать часть кода, либо применять рефакторинг из-за неудобной реализации или просто пришло в голову что-то более оптимальное. Из-за этого часто появляется мертвый код, т.е. код который уже не используется, но чтобы это определить надо затратить довольно много времени.
2. Мне приходится анализировать ТЗ, разрабатывать общую структуру ПО и выдавать задания другим программистам.
В наших ТЗ часто присутствуют противоречия. Объемы большие и процесс затягивается. Часто получается так, что противоречие найдено позже чем уже есть какой-то вариант реализации. Так же бывает, что часть требований не имеют достаточного описания.
Вызывает их мое незнание в этих областях.
Здесь же я пытаюсь получить совета, с чего лучше начать в моей ситуации.Зависит от того, чего вы хотите добиться для вашей организации и для себя лично. Начинать желательно с себя (ибо эффективно совмещать в одном человеке функции аналитика, проектировщика, программиста и руководителя проекта не реально) - больше шансов добиться желаемого. Если же все-таки у вас возникло желание спасти