31

Управление Проектом / Re: один способ управления задачами в команде

« : 01 Октября 2012, 15:40:18 »

А если эти вопросы менеджерам и задать? 
А штрафы в чем заключаются? А где же пряники?

Вопросы задала. На прошлой неделе письмом на несколько руководителей. Сегодня поговорила с непосредственным руководителем. Поняла, что он изъянов в системе не видит. Затраты на данную работу считает незначительными.  У меня аргументы на данный момент закончились, поэтому советуюсь здесь.

Пряников за участие в данном конкретном процессе не полагается.  Штрафы весомые.

32

Для всех / Re: обратная связь по документации с помощью опросника

« : 01 Октября 2012, 15:18:52 »

Судя по Вашим утверждениям, Вы не верите, что можно отделить содержание документа от представления, и сделав представление лучше, облегчить восприятие содержания.

Тем не менее есть замечательная статья от белорусских коллег на эту тему: http://analyst.by/how-to-make-your-texts-clear/.

N лет назад уважаемый профессор из ННГУ им. Лобаческого просил нас, тогда студентов, вычитать написанный им учебник именно проверяя на такие пункты, как наличие синонимов-паразиов. По содержанию мы ничего и не могли ему сказать. =)

Также принцип разделения содержания и представления широко используется в web-разработке.

33

Для всех / Re: обратная связь по документации с помощью опросника

« : 01 Октября 2012, 14:50:28 »

Это-ж неспроста

Это ж-ж-ж действительно неспроста. Но описывать тут откуда оно возникло не стоит.

Ну если Вам делать нечего, то рискните.

Мне не то, чтобы нечего делать, но хочется уважить желание руководителя, и, может быть, простимулировать пользователей документа читать его более внимательно.

Все, что Вы написали, относится к проверке содержания спецификации требований. Просить других участников рассказывать мне, что я не дописала в спецификации конечно смысла нет.

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

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

34

Управление Проектом / один способ управления задачами в команде

« : 01 Октября 2012, 14:37:25 »

Добрый день, коллеги!

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

• по задаче должен быть обязательно указан срок окончания, с учетом всех согласований с Заказчиком и временем проверки менеджером;
• сам исполнитель изменить срок окончания задачи не может;
• исполнитель отвечает за то, чтобы руководитель вовремя проверил поставленную на него задачу;
• если исполнитель вовремя не напомнил руководителю, что надо проверить и закрыть его задачу, на исполнителя накладывается штраф.

С первым пунктом вроде бы все понятно. Взявшись за задачу, ты должен её оценить и предоставить эту оценку руководителю.
Со второго пункта начинаются вопросы. Если, например, заказчик не ответил мне на письмо и вообще не отзывается, нужно срочно ловить руководителя по скайпу/почте, чтобы он переставил срок. За просроченную задачу будет штраф.

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

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

Объясните мне, пожалуйста, в каких условиях эта система может работать и в чем я, возможно, не права.

P.S. В то же время, если руководитель ставит задачу на исполнителя, он не считает нужным уведомить его об этом дополнительно. Зачем? TFS же присылает уведомления.

35

Для всех / обратная связь по документации с помощью опросника

« : 01 Октября 2012, 14:00:03 »

Добрый день, коллеги!

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

Я, на вскидку, могу предложить для включения такие пункты:
1. аккуратность оформления;
2. количество опечаток;
3. однозначность терминов, отсутствие синонимов-паразитов;
4. логичность изложения;
5. полнота;
6. соответствие заголовку;
7. достаточно ли примеров и иллюстраций.

У кого-нибудь есть такой опыт сбора обратной связи? Может быть вы уже создавали подобные опросники, поделитесь, пожалуйста.

36

Сообщество Аналитиков / Re: День Системного Аналитика

« : 21 Сентября 2012, 16:25:57 »

День сисадмина был летом. Точно помню. =)

В конце октября я сама планирую наведаться в Москву, и даже без праздников. =)

37

Сообщество Аналитиков / Re: День Системного Аналитика

« : 21 Сентября 2012, 09:55:09 »

Да, меня очень волнует вопрос: когда будем праздновать в этом году? Хочется, как два года назад, собрать питерское сообщество, и чекаться с Москвой, Беларусью и другими по скайпу!

38

Управление Проектом / Re: Зачем аналитику знать трудоемкость реализации требований?

« : 06 Июля 2012, 21:27:39 »

Анна,

фактически в предыдущих сообщениях Вы говорите о том, что процесс взаимодействия в коллективе налажен плохо. При этом у Вас полномочий меньше, чем ответственности. Приходиться смотреть в глаза заказчику и отвечать за процесс, которым Вы не управляете, краснеть, бледнеть, в общем чувствовать себя неважно. Аналогично, опуская свои требования в "черный ящик", Вы находитесь все время в состоянии стресса, т.к. не знаете во что это выльется.
Если мои предположения верны, то 
1. Берегите здоровье. Это напоминает классический эксперимент.
2. Введением нового поля Вы не решите эту задачу. Более того, рискну предположить, что ее решение лежит вне области Вашей компетенции. Не в том смысле, что у Вас на это нет квалификации, а в том, что это пока не Ваша задача.
Чтобы решить задачу "слабого" взаимодействия, необходимо желание лидеров коллектива и воля руководства. Если в Вашем коллективе это есть - дерзайте, можно продумывать процесс. Только смотреть надо не на отдельный процесс определения трудозатрат, а на всю систему в целом, искать, что мешает адекватному взаимодействию:
- психология?
- открытая не в том месте форточка?
- неудобный интерфейс RMS?
- разные системы целей?

Спасибо за ответ!

На самом деле, в процессе написания всего этого поняла, что просто команда еще не привыкла к присутствию аналитика, как сервиса. (Воистину, женщине нужно сказать, чтобы подумать. =) ) Никакого отрицательного отношения нет, но и полного понимания как его использовать тоже нет. Просто надо потихоньку встраиваться. Тем более, я уверена на все 100%, что в данном случае я не лишнее звено.

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

Ощущение опускания требований в "черный ящик" присутствует.

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

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

39

Управление Проектом / Re: Зачем аналитику знать трудоемкость реализации требований?

« : 06 Июля 2012, 20:45:44 »

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

40

Управление Проектом / Re: Зачем аналитику знать трудоемкость реализации требований?

« : 06 Июля 2012, 20:43:56 »

Анна, наверное вопрос не в том "Зачем, как ты будешь это использовать", а "Как ты будешь ее определять?"
Когда Вы сможете описать этот процесс, то поймете, будет ли ценность в этой оценке, насколько она (в соответствии с Вашим процессом определения) будет адекватной. Если эта оценка будет определяться Вами самостоятельно, без общения с проектировщиками/разработчиками и будете называть сразу ее заказчику, то вряд ли будет польза. Может оказаться много конфликтов, как внутри (с РП), так и с внешней стороной - заказчиком.
Поэтому, на мой взгляд, надо сначало описать не просто поля в БД для заполнения, а процесс, который за этим стоит и понять, нужен ли такой процесс Вашей компании.

Речь идет как раз о том, чтобы получить оценку со стороны разработки. Никому не собираюсь навязывать свою оценку. Просто хочу ориентироваться в том, что происходит.

А вот нужен ли такой процесс и как его построить и пытаюсь понять.

41

Управление Проектом / Re: Зачем аналитику знать трудоемкость реализации требований?

« : 06 Июля 2012, 20:40:07 »

Аня,

п.1-2 - это чистой воды менеджерская работа, если ты ее выполняешь, то тогда и аргументация на твоей стороне, если нет, то привлеки МП и продай ему это.
п.3 - с трудом верится, что это поможет. Бывает так, что требований 2 строчки, а с т.з. архитектуры это ой как не просто. Ну разобьешь ты это требование на 2-3 штуки и что? Это уже таски разработчикам/арх-ам, причем тут требование? Бывает наоборот, что лучше не бить требования, чтобы выидеть полную картину ...

Тебе реально зачем это надо? Скажи честно

Саша, по результатам хорошего размышления, честно могу сказать, что это очередная попытка получить обратную реакцию на создаваемые мной требования. Сейчас я в большинстве случаев не получаю вопросов со стороны разработки при создании требований. Это очень смущает. Отсутствие вопросов может быть в двух случаях:
1. все понятно (не могу льстить себе настолько);
2. ничего не понятно (вроде не такой я паршивый аналитик).

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

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

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

42

Управление Проектом / Зачем аналитику знать трудоемкость реализации требований?

« : 04 Июля 2012, 17:07:04 »

Добрый день, коллеги!

Обсуждаем с тимлидером структурирование и управление требованиями в TFS. Одним из пунктов предложила ему указывать трудоемкость выполнения требований совместно с приоритетом, указанным  Заказчиком. Получила вопрос: "Зачем, как ты будешь это использовать?".

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

Какую еще пользу может принести знание трудоемкости выполнения требования аналитику? И стоит ли настаивать на этом пункте?

43

Конференции Семинары и Тренинги / Re: ЛАФ-2012: Темы и докладчики

« : 19 Апреля 2012, 20:04:36 »

Если говорить о предметных областях, то интересно обсудить не только конкретную предметную область, но автоматизацию работы, которая нужна в любой предметной области, например построение Службы поддержки. Хотя про ТелеКом тоже интересно, я недавно в него пришла и информация мне нужна.

Уже давно предлагала Эдуарду темы по обучению аналитика и взаимодействию с другими членами команды. Кому какие артефакты нужны от аналитика. Например, чего ждет от аналитика тестировщик и в каком виде? Все-таки, признаемся честно, члены команды редко читают полную документацию. =)

Еще недавно возникла интересная мысль. Мы все время обсуждаем кто и что такое аналитик внутри себя (IT-сообщества). А как позиционировать себя вне? У меня есть несколько стандартных ответов на этот вопрос для непосвященных, но хочется иметь такую "презентацию наружу", чтобы человек сразу понял, что ему вот прямо сейчас нужен аналитик. =) Ну или не нужен прямо сейчас, но когда будет нужен, он будет знать как и кого выбирать на эту роль.

44

Обсуждение статей / Re: Analyst Days, Минск, 25-26 мая

« : 27 Марта 2012, 21:13:14 »

Да, снять квартиру хороший вариант. Надо как-то кооперироваться.

45

Обсуждение статей / Re: Analyst Days, Минск, 25-26 мая

« : 27 Марта 2012, 12:14:51 »

А вот интересно, где наши планируют жить? В гостинице конференции или есть другие интересные варианты? И собирается ли кто-нибудь оставаться гулять по Минску в воскресенье? Конференция же идет только пятницу и субботу.