Luxoft как организатор оставил формат в неизменном виде и это порадовало. Организация была на хорошем уровне. (Ну да с обедом как обычно беда, но мне было не до обеда, так что этот минус меня нисколько не волновал).

Так получилось, что я весь день просидел на тренингах секции “Управление проектами”. Поэтому немного пройдусь по тренингам и тренерам.

Ярных Вероника. Управление знаниями в проекте. Руководитель проекта как внутренний тренер и коуч.

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

Представились, рассказали об ожиданиях. Небольшое введение, во время которого меня больше всего смутил тезис “Знание = Информация”, с чем я был категорически не согласен, но в полемику по ходу тренинга вступать не стал, т.к. пришел услышать других, а не выступать.

Затем нас разбили на 2 команды. Одна команда описывала выгоды от внедрения управления знаниями в проекте, а другая – риски сохранения знаний. Это был хороший бонус тренинга. Результаты выложу отдельной статьей.

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

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

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

Александр Зубрицкий. Проектные риски бороться или использовать?

Тема управления рисками для меня не менее интересна. И вот я здесь.

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

Ну пересказывать PMBoK не буду, единственное, что можно упомянуть это то, что при управлении рисками надо работать не только с проблемами, но и с возможностями, т.к. в определение риска добавили “позитивные последствия”.

Время провел не зря, но в общем это серьёзный курс для серьёзных бородатых дядек. Хочу простой, доходчивый и увлекательный курс по управлению рисками.

Максим Дорофеев. Курс естествознания для менеджеров проектов. Теория игр.

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

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

Сергей Архипенков. Факты против мифов: правда ли, что программистами “невозможно управлять”?

Мифология в разработке ПО.

Один из мифов звучал приблизительно так: Разработка ПО – это инженерия.

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

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

Давайте не будем дарить “розовых слоников” бородатым дядькам.

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

В общем, огромное спасибо Александру Байкину за предоставленный “льготный” билет и организаторам за то, что собрали столько интересных людей в одном месте.

В активе как минимум 4 новых мысли на подумать и много позитива.

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

Спасибо всем большое!

Сообщество системных аналитиков сформировалось на базе сайта uml2.ru в 2006-м году, в настоящий момент активно развивается и насчитывает более 30 профессиональных системных и (или) бизнес-аналитиков, которые хотят передавать свой опыт начинающим, организовывать совместную экспертизу и консалтинг, и конечно, развиваться в данном направлении.

По этому поводу 5 ноября в 3-х городах: Москве, Киеве и Санкт-Петербурге прошли офлайн встречи. Питер был на связи, а вот до Киева не достучались (подвел Wi-Fi).

Кроме того замечательные девушки-аналитики (Ирина Сурова и Ирина Векленко) взяли интервью у “отцов основателей” ресурса – Александра Байкина и Эдуарда Галиаскарова. Прочитать его можно здесь.

P.S.  Последнее время off-line жизнь сообщества значительно возросла. Проводится много регулярных семинаров в городе Москве, члены сообщества участвуют в конференциях (Training Labs, SECR, Req-Labs и т.д.). Кроме того, семинары и конференции проводятся в Санкт-Петербурге, Киеве, Минске. Пожелаю удачного развития и в дальнейшем.

http://scepticist.narod.ru/essays/diploma.htm

наткнулся на замечательное определение менеджеров среднего звена:

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

В определении есть спорные моменты, но в целом, с моей точки зрения, верно подмечено.

Главное не останавливаться на этом и идти дальше!

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

На текущий момент Алексей является главным редактором ресурса и его идейным вдохновителем. И несмотря на его заверения про то, что он не верит в профессиональные социальные сети, пару месяцев назад он открыл коллективный проект Панбагон, который жил некоторое время на платформе Blogger, но её возможности оказались ограничены.  Да и не хотелось останавливаться только на одном блоге, хоть и коллективном.

Поэтому родился проект Сообщества тестировщиков 2.0, который работает на движке LiveStreet и живет по этому адресу: http://community.software-testing.ru/.

Там будут жить коллективные проекты портала Software-Testing.Ru, предполагающие возможность открытой регистрации и участия всех желающих.

Прошел месяц – полет нормальный.

Краткая хронология:

07 сентября В преддверии дня тестировщика в Москве собрались человек 10 с форума it4business отметить это дело в неофициальной обстановке. Не смотря на нелетнюю погоду беседа на Калужской площади под открытым небом оказалась увлекательной, пиво – вкусным, компания – интересной.

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

10 сентября. Сергей Мартыненко: Дмитрий Ручко задал вопрос, а не пора ли? Надо сказать, что к этому времени я уже относительно безуспешно вел переговоры с людьми, предлагая взяться за это дело. Ну что ж, мы нашли друг друга и нас стало двое.

13 сентября. На семинаре по Scrum Сергей попросил помощи у комьюнити Agile Russia. Ребята обещали помочь с помещением и докладами. Денис обещал помочь с организацией

19 сентября. Старт подготовки. В этот день был утвержден состав организаторов в количестве четырех человек (Сергей Мартыненко, Денис Бесков, Дмитрий Ручко, Александр Лобач) и распределены задачи. Все общение в этот день и последующие проходило в онлайн через skype и wiki.

20 сентября. Началась реклама.

27 сентября. Организаторы впервые встретились лично. Наконец мы все познакомились.

28 сентября. Последняя встреча. На которой выяснилось, что делать почти нечего.

29 сентября. Конференция.

Десять дней. Как много сделано и как много не успели!

Конференция прошла 29 сентября 2007 года.

Т.к. все было бесплатно для участников, то в организации были некоторые упущения, о которых я написал в блоге конференции.

На конференции присутствовало более 140 специалистов из Москвы, Санкт-Петербурга, Минска, Харькова, Екатеринбурга, Севастополя, Йошкар-Олы, городов ближнего и дальнего Подмосковья (статистика участников). Под стать масштабу конференции увеличился и круг обсуждаемых вопросов.

Впечатления Алексея Баранцева.

Еще отзывы:

1. Пожалуй действительно, спрос превышает предложение. Поскольку большинство докладов были довольно общего характера, многое осталось за кадром, не высказано, не спрошено, не отвечено. А отсюда – прямая дорога к 3й конференции, с более узкими проблемами, еще большей аудиторией.
2. Мне (и моим коллегам, кто были со мной) конференция понравилась и оказалась полезной. Ни на секунду не возникло мысли, мол, зря тащились из Минска, нового ничего не узнали и вообще, всё плохо. Наоборот! Всё было очень хорошо!
3. Лично для меня данная конференция это прежде всего возможность пообщаться с интересными людьми. На любой конференции передача реальных знаний происходит в кулуарах. Эта не исключение. Общение было исключительно интересным.
По теме докладов. Да, есть куда расти. Собственно это и хорошо. Сообщество еще весьма молодо и первый полученный опыт очень ценен. Важно то, что есть желание переосмыслить роль специалиста по обеспечению качества. И впервые!!! мы собрали всех вместе: руководителей проектов, аналитиков, разработчиков.
4. Вообще-то я на конференцию ходил не столько доклады послушать, сколько познакомиться с некоторыми людьми, а также встретиться лично с теми, с кем до сих пор приходилось общаться только в онлайне. Так что свою программу я выполнил на 100% и этим вполне удовлетворён. В результате чувство двойственное — с одной стороны очень приятно, что людям интересно, и что за столь короткий срок собралось так много участников, при этом минимум рекламы. А с другой стороны — может быть лучше было бы проявить твёрдость и прекратить регистрацию на 50 участниках и провести всё так, как задумывалось… Непонятно. Ясно одно — в следующий раз надо рассчитывать сразу на достаточно большой масштаб.

Продолжение следует…

12 Марта

Влад Орликов на форуме software-testing.ru (ныне расположен на it4business.ru/forum) открывает тему Who is Tester со следующими тезисами:

1. Профессия тестировщика не престижна.
2. Многие не имеют представления от том "Who is tester".
3. Оплата труда тестировщика как правило ниже чем разработчика.
4. На тестировщиков нигде не обучают (курсы на которых дают только поверхностное представление не в счет). В ВУЗах отсутствует такая специальность/специализация.
5. Нет общепризнанной сертификации тестировщиков (brainbench не в счет).
6. и т.д. и т.п. …

22 марта

Сергей Гринкевич предлагает встретиться:

>Коллеги!

>С удовольствием встречусь с вами, членами клуба единомышленников, где-нибудь в кафе.

Влад хватается за эту идею

>Я только за! Сам уже давно вынашиваю эту идею. Предлагаю это в отдельной теме оформить

и

Дмитрий Ручко открывает тему Встреча клуба единомышленников: 21.04.07, Москва

В итоге Влад берет на себя организацию мероприятия, и 2 апреля открывает тему Формат встречи 21 апреля в Москве, К теме "Встреча клуба единомышленников"

Формат приблизительно ясен – официальная часть, затем – посиделки.

Буквально за 2 дня до встречи Сергей Гринкевич предлагая не закидывать его камнями говорит о бесполезности встречи в таком формате. Разворачивается небольшая дискуссия в ходе, которой применяются если не камни, то, как минимум тапки, но всё заканчивается достаточно мирно.

Итак, 21 апреля.

Сразу предупреждаю – хронология может отличаться от реальной в ту или иную сторону.

Вставать в 7 утра, да ещё и в субботу – это практически подвиг, но предвкушение увидеть коллег по сообществу достаточно велико и подвиг – свершен. Сознаюсь, очень хотелось увидеть Case-а (Слава Панкратов), и, забегая наперед, скажу, что когда увидел его и узнал что он мой ровесник, задал себе вопрос – а чем блин я занимался все эти годы. Ну да ладно это вопрос для самокопания.

День начался.

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

9:30

Итого 14 человек в сборе, но нет киевских коллег включая «легендарную личность» – Славу Панкратова. И вдруг звонок – мы заблудились. Влад Орликов самоотверженно бросается на спасение утопающих и с честью выполняет свой долг организатора.

10:15

16 человек в сборе, 4-х – нет и уже не ожидается. Начинаем в таком составе.

Представление каждого в формате: ник на форуме, реальные ФИО и компания. Запомнить всех сразу сложно, но на этот случай были предусмотрены бейджики.

Первым идет доклад Александра – одного из сотрудников Кворум Телеком, собственно повторяющий тезисы темы Who is Tester

Возникает предложение, что неплохо бы вести запись встречи и вот из закромов родины вытащен раритет – кассетный плеер (хватило его ненадолго).

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

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

Слушаем доклад Сергея Мартыненко про автоматизацию. Мною вынесена интересная мысль про разделение юнит- и модульного тестирования.

Далее Слава описывает произошедшее на рынке Киева.

И дискуссия продолжается.

Собственно эту часть Влад описал здесь.

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

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

Около 14:00

представляю обзор некоммерческих организаций тестировщиков за рубежом.

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

14:30

поднимается вопрос о том, что всё-таки неплохо заслушать доклад о состоянии тестирования в Минске. Слушаем. (Если не ошибаюсь были Сергей Полаженко и Наталья Густыр (ныне Искорцева))

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

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

Что делать дальше?

1. Разработка и ревью тренингов, возможно, сотрудничество с ресурсами вроде http://www.intuit.ru/

2. Написание статей в журналы

3. Организация команды по примеру http://redmonk.com/ – необходимо изучение и дальнейшее обсуждение

15:30

Вроде как все – дальше будет или повторение пройденного или бессмысленная дискуссия.

Тут Влад ещё разочек приятно удивляет – всем приготовлены сувениры – значок с эмблемой форума и черная футболка с надписью на спине.

На страже качества

www.software-testing.ru

+ компакт с материалами Mercury Quality Methodology и сертификат участия в слете

Все приоделись в свежеприобретенные футболки и пошли на фотосессию.

После фотосессии часть людей покинула наши ряды, а остальные отправились в Пивной ресторан «Дурдинъ». Лень описывать, но и вторая часть прошла не зря и с удовольствием.

Какими я увидел некоторых участников:

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

Сергей Гринкевич вставлял свои комментарии в любое место, но по делу и без него дискуссия потеряла бы свое очарование.

Softquacoman обычно дремал, иногда удивленно посматривая на Case-а и качал головой. Оживлялся при словах бизнес и кричал: несите идеи – все будет, если оно того стоит.

Слава Панкратов постоянно тянул руку и давил своим весом авторитетом, запрещал рассказывать сказки и говорил умные вещи.

Влад Орликов хочет двигаться в развитии дальше, поэтому и толкает других.

Продолжение истории

Источник http://payalnik.livejournal.com/722051.html

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

В понедельник 03/08/09 посетил семинар Сергея Мартыненко и Стаса Фомина по мотивам теории ограничений (ТОС) и книгам Голдрата. Семинар проводился на площадке компании Заказные ИнформСистемы.

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

В ходе подготовки семинара Стас с помощью линейного программирования нашел ошибки в рассуждениях Голдрата и это было весело.

Единственное, что не могу удержаться продублировать выводы семинара:

• Человек не рожден для вычислений.
• Рассуждения в литературной форме из-за аббераций восприятия легко уводят от оптимума.
• Поиск оптимума в виде рассуждений трудно верифицировать.
• Если есть возможность — нужно составить математическую модель. Человеку ее легко верифицировать, а машине — легко решать.

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

Вчера 31.07.09 Лаборатория качества провела первый семинар из этой серии, который я и посетил.

На семинар пришло около 30 человек.

Начали с короткого знакомства (Имя, компания, должность)

Сам семинар длился 3 часа (19.00 – 22.00) и состоял из трех частей.

Часть 1. О тест-дизайне. (Александр Фёдоров)

Начали с 3-х слайдов:

• Типичная группа тестирования;
• Нетипичная: выделен тестдизайн в отдельную группу;
• Выделенный за пределы проектов сервис тест-дизайна.

Слайды вызвали живое обсуждение плюсов\минусов каждой схемы и каждый высказывался исходя из своего опыта.

Особый спор вызвала третья схема внедряемая Александром у себя в компании.

Затем были показаны слайды с таблицами сущностей (это достаточно загадочные зверьки).

Времени на детальное обсуждение не хватало так что о зверьках особо рассказать не чего.

Замечания:

Не была заявлена цель доклада, поэтому в начале было не понятно причем заявленная тема и схемы построения процесса тестирования, в итоге цель удалось выяснить задав пару наводящих вопросов (Цель: кто-нибудь выберет себе схему построения)

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

Часть 2. «О заземлении» (Лорена (коуч))

Каждого в аудитории попросили ответить на следующие вопросы:

1. Сколько стоит ваш рабочий час сейчас, год назад, будет стоить через год
2. Идеальный человек вашей профессии (ИЧВП) – какой он?
3. Если брать идеального человека вашей профессии за 100, то где на шкале находитесь Вы(имелась ввиду компетенция\навыки)?
4. Напишите 5 отличий в компетенции Вас и ИЧВП
5. То же что и 3-й вопрос но про деньги
6. Напишите за последний месяц 3 проблемы где вам не хватило компетенции

Затем записали речевку:

Я … сейчас зарабатываю в час Х, через 6 месяцев своей жизни с 1 февраля 2010 года час моего времени стоит X*Y,  а через 12 месяцев – X*Y*Z. (соответственно каждый ставил суммы для себя)

И попросили ответить на вопрос: Что изменится во мне через 6 месяцев и через 12 месяцев?

Замечания:

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

Часть 3. Кто такой тест-менеджер (Наталья Руколь)

Специфика сферы тестирования:

• Высокий уровень ответственности\ Невысокий уровень возможностей повлиять на результат.
• Творческий деструктивизм (конструктивный деструктивизм).
• Уровень требуемых знаний не всегда пропорционален зарплатам.
• Значимость интуиции.

Менеджер – это дирижер.

Классификация обязанностей менеджера:

1. Обеспечение (выполнения) результата.
2. Обеспечение своих сотрудников условиями работы (Обеспечение возможности).
3. Создание комфортной среды для работы сотрудников.
4. Обеспечения развития сотрудников.

Мифы о тест-менеджерах:

1. Тест-менеджер – это самый лучший тестировщик\тест-дизайнер.
2. Тест-менеджер – самый главный сотрудник в команде (в смысле если его не будет то все пропадет).

Замечания:

Все это можно сказать и про других менеджеров.

Что не так в организации мероприятия:

Если читать объявление о семинаре:

1.

Первую часть встречи, носящую гордое название "Скажи тест-дизайну "Да!"", проведёт Александр Фёдоров. В рамках этого семинара Александр поведает о роли тест-дизайнера как в крупных, так и в небольших компаниях, не имеющих выделенного отдела тест-дизайна.
Вторую часть, раскрывающую секреты того, как стать идеальным тест-менеджером, проведёт Наталья Руколь. Кодовое название второй части – "Достижимые идеалы"

Более четко определяем цель и тему каждого семинара

2.

…но и предоставляем среду для общения специалистов в нашей области…

Для общения очень неудобно сидеть рядами (и бейджики ситуацию не исправят).

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

3. На представлении не было сказано о том, зачем каждый пришел.

4. Необходимо более жесткое модерирование дискуссии для ограничения вопросов не по теме. Из всех выступающих с этим справлялась только Лорена.

P.S. Несмотря на все замечания, все было неплохо и, я не пожалел, что потратил вечер пятницы на это мероприятие.

P.P.S. Спасибо за предоставленную возможность пообщаться (аудитория собралась очень активная), совершенствуйтесь и зовите в гости.

Вопрос был следующий: зачем это нужно, а если нужно, то по каким критериям оценивать влияние.

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

В итоге разобрались и документально зафиксировали следующее:

Severity и Priority – это две отдельные активности.

Severity – это оценка важности дефекта в контексте приложения в целом, и определяется тестировщиком.

Priority – это необходимость исправления этого дефекта в контексте текущего релиза, и устанавливается лицом, отвечающим за релиз, исходя из нескольких факторов (например – severity, частоты проявления и рисков появления новых проблем при исправлении, плюс цели релиза).

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

Выставляя severity тестировщик оценивает влияние дефекта на работоспособность приложения. Чем выше severity, тем масштабнее негативные последствия данного дефекта.
Priority – это инструмент менеджера по планированию работ. Чем выше priority, тем быстрее нужно исправить дефект.

Берем типового тестировщика. Его задача – узнать, как себя ведет программный продукт. Он в большинстве случаев взаимодействует с ним "снаружи", то есть без особых технических подробностей. Исходя из знания продукта и особенностей его применения, он оценивает важность обнаруженной проблемы.

По большому счету, можно ограничиться тремя критериями:

а) юзабилити проблема (надписи в диалоге съехали, комбо-бокс смотрится отвратно);

б) функциональная проблема (участок функционала работает неправильно);

в) блокирующая проблема (определенная функциональность отвалилась).

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

Как резюме можно процитировать одного из участников обсуждения на форуме it4business:

Вопрос не в том, нужно ли использовать priority и severity, толстый клиент или тонкий, а в эффективности работы команды.
Если добавление полей повысит эффективность – добавляйте. Если внесет путаницу – не множьте сущности без необходимости