Сообщений в теме: 15

[SALar]

В очередной раз анализируя запас по настраиваемости разных трекинговых систем (надо, надо тренинг сделать) задумался а так ли уж необходим функционал изменения категории. я работал и в тех и других системах. Мысли во многом совпадают с изложенным здесь:
http://www.trackstud...749.html#p22749

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

И вот подумалось мне, что одно из решений выглядит так:
* Заказчик. Я заказчик. Мне плевать на вашу типизацию. "Я хочу!"
* И в системе создается запрос с категорией "хотелка". С простым жизненным циклом типа: "Новое желание" / "Исполнено" / "Передумал"
* В ее рамках уже ведутся все остальные работы со строгой типизацией.

Что скажете, коллеги?

[Julia Atlygina]

Спасибо за интересную тему!

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

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

Не знаю, ответила ли:)

[SALar]

Спасибо за интересную тему!

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

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

Не знаю, ответила ли:)

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

 

Да, можно на хотелке сделать доп поля, которые указывают платно/ бесплатно и сколько стоит. Это не проблема. Главное, чтоб ЖЦ не менялся.

 

PS. И чем еще это хорошо, тем что для реализации "Хочу!" может понадобиться провести 4 консультации исправить 15 багов и сделать 19 доработок. И все это сделать в 9 системах, причем договора SLA (соглашение по уровню поддержки) по этим 9 системам кардинально различаются. Какие-то относятся к этапу внедрения системы, заказчиком не оплачиваются и бюджетируются из бюджета проекта внедрения. А по каким-то договор по исправлению багов (вне зависимости от того, кто ее нашел) такой зверский, что после не исправления в течении 2 рабочих дней начинает начисляться штраф. Скажем евро по 200 в день. С зарплаты отдела. Ну и да, все 9 систем имеют собственную систему версионирования и свой график релизов. И чтобы заказчику продемонстрировать на демо стенде его хотелку, нужно на демо стенде обновить все 9 систем и убедиться, что они стали нужной версии.

 

Вот как-то так.

 

PS. Крыша не едет?

[Julia Atlygina]

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

 

Я очень конкретного заказчика описывала:) Он заводил задачи определенного типа, потому что от этого типа зависело будет он дополнительно оплачивать или входит в обычную поставку.

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

ЖЦ - ему было важно, что если сделано - то протестировалось + были свои приемочные тесты на будущих конечных юзерах. И обо всех этих стадиях он хотел знал и получть нотификации.

 

 

 

 для реализации "Хочу!" может понадобиться провести 4 консультации исправить 15 багов и сделать 19 доработок. И все это сделать в 9 системах, причем договора SLA (соглашение по уровню поддержки) по этим 9 системам кардинально различаются. Какие-то относятся к этапу внедрения системы, заказчиком не оплачиваются и бюджетируются из бюджета проекта внедрения.

 

 

Ох, 9 систем - уже отдельная проблема:) у нас была многомодульная система, но одна, всей разработкой 1 компания занималась. И да, если для решения 1 проблемы нужно несколько задач - понятно что они к ней линкуются и живут себе в других проектах, изначальная может быть любой, особенно если для заказчика от этого типа ничего не зависит. Да, в JIRA для этого есть например Structure :))

 

Вопрос - какую задачу решаете) Судя по вашему ответу, заказчик вообще не видит багтрекер - тогда откуда взялась проблема с изменением типа? Я просто поняла вопрос как "нужен ли тип задачи для кастомерских хотелок". Поясните немножко в чем вопрос, пожалуйста

[Vasiliy]

Крыша пока держится))

Этот запрос для кого? Для вас или для заказчика?
Если для вас, то как типизируется статус задачи, если проведено 3 консультации и исправлена половина багов?
Или это верхнеуровневый срез по хотелкам заказчика?

[SALar]

Этот вопрос пока для меня. Звучит он примерно так: "Если трекинговая система не имеет штатной процедуры смены категории объекта, то в каких случаях это препятствует ее выбору для внедрения."

 

 

 

Да, в JIRA для этого есть например Structure :))

Который является костылем и не решает проблему нормально. И да, отсутствие нормальной иерархии в Jira является достаточным основанием для отказа от нее в ряде ситуаций.

[Julia Atlygina]

"Если трекинговая система не имеет штатной процедуры смены категории объекта, то в каких случаях это препятствует ее выбору для внедрения."

 

- у вас есть новички, они путают типы задач, потом лиды хотят их менять

- у вас есть "старички", они создают задачи "на автомате", потом сами хотят поменять

- у вас есть девелоперы, которым обидно когда заводят багу, а она на самом деле не бага

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

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

 

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

 

 

отсутствие нормальной иерархии в Jira является достаточным основанием для отказа от нее в ряде ситуаций.

Для кого-то проблема, кому-то абсолютно все равно, у всех разные задачи:) Считаю прекрасным примером к тому, что идти лучше "от своих нужд"

[BadMF]

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

должно быть именно так:

С простым жизненным циклом типа: "Новое желание" / "Исполнено" / "Передумал"

А уже на основе этих мини задач делаются баги/фитчи/Исследования/Документации/и тд.

[Julia Atlygina]

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

должно быть именно так:

С простым жизненным циклом типа: "Новое желание" / "Исполнено" / "Передумал"

А уже на основе этих мини задач делаются баги/фитчи/Исследования/Документации/и тд.

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

Ну и остается вопрос: если для заказчика от типа задачи зависит оплата, как вы ему объясните, что какие-то хотелки денег стоят, а какие-то нет?

[SALar]

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

Ну и остается вопрос: если для заказчика от типа задачи зависит оплата, как вы ему объясните, что какие-то хотелки денег стоят, а какие-то нет?

 

Элементарно. Предоставлю смету в разрезе видов работ, которые были сделаны по хотелке.

[Julia Atlygina]

Элементарно. Предоставлю смету в разрезе видов работ, которые были сделаны по хотелке.

какого размера будет этот документ? Заказчику нужен быстрый ответ типо "платно/бесплатно", а потом уже может быть какие-то сметы.

 

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

[BadMF]

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

[SALar]

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

[krukovskiy]

Я вижу здесь два варианта взаимодействия:

 

1. Заказчик озвучивает свою задачу (не вдается в особенности приложения)

В этом случае нужна роль presales/аналитика, человека, который разберет задачу: напишет пользовательские сценарии, определит перечень компонент и исправлений, составит смету (нужное подчеркнуть).

 

2. Заказчик близко знаком с системой

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

 

 

BadMF,

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

[SALar]

Есть еще варианты. Минимум два.

 

3.

а) Заказчик пишет письмо вида: "Я девочка, я хочу платье." на tracker@companyname

б) по письму создается задача категории "Желание заказчика". В зависимости от обратного адреса определяется раздел бюджета и если месячная квота условных часов не исчерпана, то письмо отправляется диспетчеру IT (ну не менеджер это, а стрелочник)  

в) диспечер отправляет тому, кто может декомпозировать задачу.

г) декомпозитор говорит: "Раз платье такое то, нужно: выточить из дерева пуговицы, купить кружева и крючки, сделать выкройку из вототого веселенького ситчика, ..."

 

Далее все понятно, а заказчику в конце говорят: "Желание исполнено"

[BadMF]

BadMF,

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

 

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

У клиента (любого представителя заказчика), в общем случае, нет права заводить какие-либо задачи в трэкинговой системе.

Скрам это не хаос, это очень чёткий порядок, достигающийся непрерывным опытом работы внутри одной команды (в том числе продукт оунер и тд). Допускать внутрь скрам команды людей которые не участвуют в процессе довольно глупо.