RU/kb/00000182 - Revision history

Sancho at 18:43, 19 September 2011

2011-09-19T18:43:15Z

Sancho at 13:27, 26 August 2011

2011-08-26T13:27:48Z

Sancho: Корректировка ссылки при переименовании страницы

2011-08-15T10:34:24Z

Корректировка ссылки при переименовании страницы

Admin: 3 версии

2011-05-19T13:52:58Z

3 версии

Admin: 1 версия

2011-05-18T14:51:25Z

1 версия

Sancho: Корректировка кода

2011-02-08T10:05:38Z

Корректировка кода

Sancho: RU/qa

2010-11-13T09:34:38Z

RU/qa

Denis0.ru: изменил название

2010-10-14T13:53:42Z

изменил название

Sancho: Основной текст

2010-10-14T10:56:51Z

Основной текст

New page

<section begin=title /><noinclude>{{DISPLAYTITLE:База Знаний: </noinclude>Почему все проблемы равны, но некоторые равны больше<noinclude>}}</noinclude><section end=title />
{{BreadCrumbL10n|RU/kb/common/working_environment/errors}}
__NOTOC__

<section begin=toc />
Читая в прошлом месяце в нашей системе Issue Tracker множество заявок на исправления и улучшения функционала, я постоянно натыкался на комментарий: ''«Почему это до сих пор не внедрено, ведь этой заявке уже 3 года!»'' и ему подобные. Позвольте мне объяснить по каким причинам некоторым заявкам уделяется внимания больше, чем другим.

В таком крупном проекте как OpenOffice.org, к работе над которым подключено большое сообщество пользователей, мы получаем огромное количество заявок. Это великолепно, но из-за ограниченности ресурсов нам приходится расставлять приоритеты. Как заметил Кристиан Липпка: нам приходится взвешивать возможную ценность решения проблемы для всего проекта. Определение подобной «ценности» отнюдь не лёгкая задача. И вот как мы её решаем.

Сначала мы определяем, по каким причинам данную заявку следует удовлетворить в принципе. Для нас особенно важно следующее:
* Спрос
** Обращался ли к нам с данной проблемой кто-нибудь из наших корпоративных клиентов?
** Сколько голосов поддержки получила заявка?
** Сколько дубликатов данной заявки существует в Issue Tracker?
** Есть ли у нас результаты исследований рынка и опросов пользователей по данной проблеме?
** Поможет ли решение данной проблемы в улучшении нашего положения на рынке?
* Стратегическая важность
** Соответствует ли необходимость решения данной проблемы долгосрочным целям нашего проекта?
** Есть ли у нас партнёры или партнёрские проекты, которые могут получить значительную пользу от решения данной проблемы и, как следствие, будут стараться упрочить свои отношения с нами?
* «Ого!»-фактор – полагаю, его название говорит за себя. :-)
* Сравнительный анализ
** Существует ли подобная функция в аналогичных приложениях других производителей, и как к ней относятся их пользователи?
** Не требует ли сама структура OpenOffice.org выполнять данную функцию иным способом, чем у конкурентов?
** Можем ли мы решить проблему лучше, чем они?
* Оценка
** Что мы, как разработчики, думаем об этой проблеме: это простая «полезняшка», важная функция, или она жизненно необходима? Наша «Группа по изучению мнения пользователей» отследила множество поступивших заявок и отметила их ключевыми словами: «rfe_eval_ok». Это означает, что группы, которые работают над разделами нашего проекта, могут приступать к изучению непосредственно самой заявки, с учётом вышеизложенных критериев. Заявки на значительное улучшение функционала, а также требующие значительных усилий для их решения, необходимо обсудить между группами в целях оптимального распределения сил, средств, идей и т.п.

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

В то время как мы выстраиваем некий «список приоритетов», появляются новые заявки, который могут понизить актуальность предыдущих, а то и полностью дискредитировать некоторые из них. Тут нам приходится оценивать следующее:
* Усилия (не только в разработке, но и подготовке QA, документации и т.д.)
* Возможные последствия взаимодействия
** Не поможет ли решение данной проблемы ускорить разрешение остальных?
** Существует ли необходимость проведения подготовительных мероприятий, например, переработка исходного кода?
* Вовлечение сообщества пользователей
** Возможно ли вовлечь членов сообщества в решение данной проблемы?

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

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

* Помогите нам собрать необходимую и достоверную информацию о предполагаемом спросе на элементы функционала
* Общайтесь с нами, принимайте участие в предварительных обсуждениях и составлении спецификаций
* Помогите в решении проблем: присылайте патчи или вливайтесь в ряды разработчиков проекта. Со своей стороны мы обещаем заинтересованным разработчикам всю необходимую поддержку и обучение. И мы обещаем поместить их имена в наш «Зал славы» […], как только проблема будет решена. :-)

Существует ещё несколько причин, негативно сказывающихся на выборе наших приоритетов – юридические и технические проблемы. Но так как они не сильно влияют на нашу работу, я не буду на них останавливаться. Надеюсь, я смог объяснить причины и методы нашего дифференцированного подхода к вашим заявкам.
<section end=toc />

<section begin=signature/>
[http://blogs.sun.com/GullFOSS/entry/why_all_issues_are_equal Оригинал (en)]
{{RUsignyear||Матис Бауэр (Mathias Bauer)|08 марта 2007}}
<section end=signature/>
{{RUkbSettingsBottom}}

@@ Line 1: / Line 1: @@
 <section begin=title /><noinclude>{{DISPLAYTITLE:База Знаний: </noinclude>Почему все проблемы равны, но некоторые равнее<noinclude>}}</noinclude><section end=title />
 {{BreadCrumbL10n|RU/kb/common/errors}}
-{{BreadCrumbL10n|RU/qa}}
+{{BreadCrumbL10n|RU/development/qa}}
 __NOTOC__

@@ Line 1: / Line 1: @@
 <section begin=title /><noinclude>{{DISPLAYTITLE:База Знаний: </noinclude>Почему все проблемы равны, но некоторые равнее<noinclude>}}</noinclude><section end=title />
-{{BreadCrumbL10n|RU/kb/common/working_environment/errors}}
+{{BreadCrumbL10n|RU/kb/common/errors}}
 {{BreadCrumbL10n|RU/qa}}
 __NOTOC__

@@ Line 58: / Line 58: @@
 <section begin=signature/>
 [http://blogs.sun.com/GullFOSS/entry/why_all_issues_are_equal Оригинал (en)]
-{{SignYear||Матис Бауэр (Mathias Bauer)|08 марта 2007}}
+{{SignYear||Автор Матис Бауэр (Mathias Bauer)|08 марта 2007}}
 <section end=signature/>
 {{RUkbSettingsBottom}}

← Older revision	Revision as of 13:52, 19 May 2011
(No difference)

← Older revision	Revision as of 14:51, 18 May 2011
(No difference)