В теме 35 ответов, и 7 участников, последнее обновление сделано пользователем 
Igor Tkachenko 12 г, 10 мес. назад.
-
Сообщения
-
А если качества и так достаточно. А аналитику просто хочется развиваться?
всякие фишки типа CMM я бы сказал скорее отвечают на вопрос: как проще управляться с возрастающими производственными мощностями.
но вполне успешная бизнес модель может вполне предполагать небольшую команду, которой просто не нужен на столько формальный процесс, потому что его и так можно контролировать. или большую команду специалистов экстракласса которым просто не нужна высокая степень контроля (я понимаю что это цельнометалический конь в вакууме)
но все равно это тоже самое что сказать что ISO9000 гарантирует качество конечного продукта
и если все так просто: берешь да ведешь работу "над ошибками". может кто-то из присутствующих может поделиться примерном своей такой работы.
Присоединяюсь к Mantis.
Добавлю, что обнаруженные проблемы необходимо фиксировать в требованиях. Здесь можно использовать следующий алгоритм:
1) Описать проблему в том виде, как она выявлена
2) Провести причинно-следственный анализ и определить противоречия, связанные с проблемой (см. 3 часть обзора по ТРИЗ)
3) Обострить противоречие (см., например, 2 часть обзора по ТРИЗ)
Как правило, на этой стадии заказчик в полной мере осознает, какая засада его ожидает, если проблему не решать. В этот момент он открыт для принятия предложений о решениях проблем.Идея заказчика — гавно, если она не решает проблему должным образом или порождает новые проблемы. Здесь также работает указанный алгоритм.
А если качества и так достаточно. А аналитику просто хочется развиваться?
От одного своего знакомого я услышал отличную фразу в тему: "Человек (аналитик) становится умнее в тот момент, когда он находит решение задачи (проблемы)". ИМХО, очень правильная мысль.
Всё может быть, но процессы у них будут те же, просто степень формализации разная. Или команда специалистов экстракласса может без процесса работать?
Если считать качество соответствием ожиданиям, то определите свои ожидания. Исходя из них выбирайте инструменты для контроля качества и исправления/корректировки проблем. Можно просто не вылазить из своего болота заниженных ожиданий.
Для самоконтроля достаточно чеклиста в экселе. Пример из "реального" пост-мортема, пусть не совсем чисто-аналитический, но всё же:
Проблема
Практически на всех платформах вылазили проблемы с работой приложений на устройствах, которые мы не проверяли/которых у нас нет.
Негатив
Явное недовольство клиента, особенно в случаях когда ошибка упорно у нас не желала воспроизводиться.Возможные решения
Согласовать с клиентом заранее список устройств, на которых будет проведено тестирование работы приложений по:
1. Версии ОС
2. Разрешению экрана
3. Установленной локали.
Чётко обозначить, что с любыми другими устройствами доработка за их счёт.и если все так просто: берешь да ведешь работу "над ошибками". может кто-то из присутствующих может поделиться примерном своей такой работы.
На самом деле это отдельная "наука" — как с максимальной пользой проводить пост мортемы для проектов — есть много шаблонов, чеклистов и рекомендаций (можно погуглить по словам project post mortem).
Целесообразнее их проводить именно для проектов, а потом уже спускаться "вглубь" к аналитическим ошибкам, если таковые были.
Из моего опыта, мы проводили пост мортемы достаточно неформально: если обстановка в команде хорошая, то просто устный митинг после окончания проекта.
Если отношения менее доверительные и есть опасность, что кого-то кто-то "задавит авторитетом" при устном разговоре, то можно провести закрытое анкетирование (вопросы у всех одинаковые), а потом отдельно выбранный человек обрабатывает результаты ответов и озвучивает обобщенный результат всем (желательно при этом, чтобы он был вне команды).
Ну и конечно все, к чему пришли должно как-то остаться в истории — попасть в базу знаний, шаблон определенного артефакта для следующего проекта и т.д.Ладно есть один Case.
"Практически на всех платформах вылазили проблемы с работой приложений на устройствах, которые мы не проверяли/которых у нас нет."Попробую его разобрать ради интереса.
Но мне нужна будет помощь инициатора (возможно). Я начал писать заодно набрасываю диаграммку )Составил )
Появился ряд вопросов:
1) Считаете ли вы, что если проверить на ВСЕХ возможных платформах, вы ОБЯЗАТЕЛЬНО найдете ВСЕ платформо-зависимые баги?
2) Что происходит когда находится баг на какой-то платформе клиентом? И что происходит когда баг находится на какой-то отличной от девелоперской платформы вами?
3) От того что вы выпускаете продукт раньше что вы получаете: больше денег т.к. раньше начинаете продавать? бонусы от заказчика? не получаете штрафы от заказчика?
4) Какие дополнительные расходы создает фикс бага который пришел от клиента по сравнению с багом который был найден внутри компании?И доп вопросы:
1) Есть ли у клианта какие-то проблемы с тем чтобы определить требования к платформе?
2) Сколько всего потенциальных платформ (предыдущие вопросы были заданы из предположения что речь идет о чем-то типа java софта для мобильных)?
3) На сколько проблемно выделить комманду на фикс багов проекта после его завершения , и почему?Все это было спонтанно и отбалды. Но кому интересно — присоединяйтесь )
Надо еще будет свой кейс рассмотреть. а то простого однозначного ответа похоже нет.
на сова "пост мортем" — википедия выкидывает статьи про волондеморта ) а наглийская вот это: http://en.wikipedia.org/wiki/Post_mortem
так что походу надо либо рыть либо выдумывать. а т.к. у меня в руках ща молоток ) я попытаюсь повыдумывать
У нас на форуме завёлся адский сотона! И я знаю, как его зовут (:Как кейс, конечно, можно обсудить, но.. есть некоторые инструменты, вроде, альфа и бета тестирования. И ещё есть сервисы, вроде, http://www.utest.com/, http://www.usertesting.com/ и иже с ними. Удаленное массовое тестирование (причем многие виды) за не очень большие деньги.
Что касается пост-мортема.. Не, ну вот, реально сотона (: или к концу рабочего дня и недели вскипает мозг.. в общем — http://lmgtfy.com/?q=projects+post+mortem
Привет, Юра. )Сарказм это хорошо )
Проекты по тестированию вообще отличные я про такие не знал.
На счет гугла, и вскрытия ) Пройдя по данной ссылке, я увидел 70% фиолетовых ссылок ) Как ты думаешь что это значит?
Но этот подход требует какой-то организованности даже командной. Я же пишу про индивидуальную инициативу:
а) как за мотивировать себя (кого-то) индивидуально провести работу над ошибками?
б) как минимизировать затраты времени на это и сделать это "незаметной" частью процесса
в) что делать потом с этими ошибками оставшись с ними на едине — если даже не ты в них виноват (ну это я уже сочиняю… но в тему)…а на счет решения с сервисами для конкретного кейса.
один раз я поехал на очень авторитетное и рекомендуемое мне друзьями СТО. видя марку моей машины и выслушав симптомы — мастер быстро приговорил к замене датчик температуры головы двигателя. естественно предварительно послушав её с умным видом и посмотрев на компе. (хотя я тоже предварительно пользовался этой же софтиной и не понял чего он там мог увидеть )).
потом анализируя то что он сказал (т.к. проблема не ушла). я заметил интересный момент в его комментарии "ну он часто ломается — распространенный случай".
проблему я таки устранил спустя пол года, т.к. она меня сильно не парила, но суть истории не в этом… или в этом )))конечно в случае с тестированием можно дать 100500 советов которые скорее всего сработают (дадут результат в плане проведенного тестирования).
Но раз уж Андрей К. задал ритм в сторону стремления к идеальности системы я бы не торопился. возможно для конкретного случая может найтись еще более простое и дешевое решение ) и раз уж мы рассматриваем какой-то кейс и жаренный петух за нами не бегает (а других кейсов я тут не вижу, чтобы выбрать более интересный) — я считаю что можно слегка поупражняться…
P.S> Написано в здравом уме и твердой памяти (единственная нагрузка с утра это курсы английского и зарядка).
Все это было спонтанно и отбалды.
Вот и я об этом подумал — спонтанно и полностью от балды. Я половину вопросов и их назначение не понял. Что мы пытаемся понять?
1. Надо ли делать работу над ошибками?
2. Или разобрать, какие могут быть выводы в данном конкретном случае?Если второе — то здесь это оффтоп.
Это было про решение проблемы с тестированием на различных платформах.
Если какие-то вопросы не понятны — поясните какие.А было это к тому как правильно решить эту проблему (идеально).
P.S> Обсуждение не может быть офтопом. Т.к. разбирается пример к топу.
Важная роль бизнес-аналитика — понимать, насколько правильны желания клиента. "Правильные желания" означает, что желания соответствуют законам развития бизнес-систем. Многие проекты обречены на неудачу именно потому, что в них заложены "неправильные желания клиента".
Возможно, что эта мысль противоречит тому, чему вас учили, например, принципу "клиент всегда прав". …Хоть это и не совсем в тему имхо, но не могу не выразить солидарность. "Принцип" "клиент всегда прав" сгубит этот мир.
[b]Проблема[/b]
Практически на всех платформах вылазили проблемы с работой приложений на устройствах, которые мы не проверяли/которых у нас нет.
[b]Негатив[/b]
Явное недовольство клиента, особенно в случаях когда ошибка упорно у нас не желала воспроизводиться.[b]Возможные решения[/b]
Согласовать с клиентом заранее список устройств, на которых будет проведено тестирование работы приложений по:
1. Версии ОС
2. Разрешению экрана
3. Установленной локали.
Чётко обозначить, что с любыми другими устройствами доработка за их счёт.Для данного кейса можно сформулировать следующее противоречие:
Если не проводить тестирование приложений на разных платформах, то (-) на них будут возникать баги (а это будет раздражать клиента); но (+) затраты на тестирование будут низкие.
Цель решения: при минимальных затратах на тестирование добиться отсутствия багов на разных платформах.1) Считаете ли вы, что если проверить на ВСЕХ возможных платформах, вы ОБЯЗАТЕЛЬНО найдете ВСЕ платформо-зависимые баги?
- Нет, не считаем. Если что — задача "проверить на всех платформах" не ставится. Также мне кажется, что сначала надо договориться, что понимается под "платформой".
2) Что происходит когда находится баг на какой-то платформе клиентом?
Клиент недоволен, если находит баги. Нам а) надо выяснить почему баг происходит б) если это действительно наша вина, то исправить его в) как-то протестировать на платформе/устройстве, аналогичных клиентской.
3) От того что вы выпускаете продукт раньше что вы получаете: больше денег т.к. раньше начинаете продавать? бонусы от заказчика? не получаете штрафы от заказчика?
Если вопрос про конкретный проект — то ничего, кроме, возможно, удовлетворения клиента.
4) Какие дополнительные расходы создает фикс бага который пришел от клиента по сравнению с багом который был найден внутри компании?
Сначала от клиента надо добиться внятного описания действий, которые приводят к багу. У клиента нет ни желания, ни понимания, как это правильно описать. После, если баг воспроизводится у нас — то больше никаких. Если баг не воспроизводится — то потенциально много времени уйдет на выяснение условий его воспроизведения.
И доп вопросы:
1) Есть ли у клианта какие-то проблемы с тем чтобы определить требования к платформе?
Да, клиент не владеет технической частью вопроса.
2) Сколько всего потенциальных платформ (предыдущие вопросы были заданы из предположения что речь идет о чем-то типа java софта для мобильных)?
4 глобальные (уровня iOS) + подмножества версий глобальных платформ
3) На сколько проблемно выделить комманду на фикс багов проекта после его завершения , и почему?
Проблемно, потому что люди заняты на других проектах, следовательно возникают все затраты на переключение.
Ща в меня полетят помидоры (даже наверняка гнилые).Скорее всего, вас эта проблема не парит, и тяжелых последствий никаких не создает реальных. А вы её выкинули просто как кейс, который можно было бы мимоходом решить. И желание решить проблему аналитиком для собственного развития — причина высказывания кейса.
И правильно сделали — меня это кое чему научило и ответило на мой вопрос заданный этой темой!
Поправьте меня если я ошибаюсь.А вообще, такая проблема решается (если её надо решать) на уровне управления пакетом проектов.
Есть конечно еще вопрос в поиске примеров платформ. Но купить устройство, или там найти эмулятор, или выкрутиться как еще — это уже дело десятое, как мы все понимаем.Можно накапливать н багов под одно устройство с разных проектов, и когда люди на каком-то проекте уходят в стабилизацию или заканчивают проект пересаживать их на наиболее приоритетный на данный момент проект. )))
Что это значит?
Это значит, что если объем дополнительных доходов полученных от разрешения некоторого набора багов, ниже чем потенциальный доход от следующего нового проекта. То может и фиксить их и не надо?
А если перед клиентами есть какие-то обязательства (т.е. им нельзя просто сделать рефанд и баг надо фиксить), то тогда надо этому "проекту" (снежному кому из багов) приоритет поднимать над новыми проектами.Доп. решение: Если у вас проекты слишком длинные и условных команд слишком мало чтобы "проект" их ждал, можно уменьшать размеры итераций и вставлять между итерациями. Как вариант если поток подобных багов достаточно стабильный и на них и так постоянно кто-то сидит — то можно выделить отдельную команду, состав которой периодически менять (чтобы люди не кисли).
Но. Понравилось вам предложенное решение или нет. Не так важно, потому что, рассмотрев данный кейс, я понял одну вещь:
Такие кейсы нет смысла рассматривать!!! Потому что есть вероятность 90-95%, что даже если вы решите эту проблему вы ухудшите ситуацию в организации в целом (причем от того какое это будет решение это не зависит). Дальнейшие условия должны пояснить почему.Чтобы решение этой задачи имело смысл должно выполняться одно из следующих условий:
1) Возвращающиеся баги являются причиной резкого снижения дохода (больше чем естественные колебания рынка — т.е. погрешность).
2) Есть риск экспоненциального роста затрат в ближайшем будущем при сохранении текущей стратегии (против нормального линейного).
3) Выпуск новой продукции замедляется, в то время как каждый новый продукт ощутимо увеличивает доходы компании (ощутимо в смысле что его доходность сравнима с доходностью всех предыдущих продуктов, при условии что все они имеют сравнимый со сроком разработки срок окупаемости).Вывод, который я упомянул вначале, кейсы для аналитиков в виде отдельного примера — штука вредная.
Т.к. может рождать в людях иллюзию того, что они нашли хорошее полезное решение, а то еще и желание его применить, чем усугубят ситуацию.Подведу итог: Если у кого-то есть острое желание решить подобную проблему вне перечисленных условий (причем должны быть факты доказывающие существование этих условий). Решение которое вам надо найти: валерьянка и психотерапия. Бдительным модераторам: это не троллинг, не оскорбление и не шутка ( http://ru.wikipedia.org/wiki/%D0%90%D0% … 1%82%D0%B8).
Вывод, который я упомянул вначале, кейсы для аналитиков в виде отдельного примера — штука вредная.
Т.к. может рождать в людях иллюзию того, что они нашли хорошее полезное решение, а то еще и желание его применить, чем усугубят ситуацию.Вы правы в том, что любое решение должно быть "настроено" на конкретную ситуацию и учитывать все особенности этой ситуации.
Что касается вредности кейсов, то категорически не могу согласиться. ИМХО, назначение кейса не в том, чтобы хранить готовое решение для определенного класса проблем, а в том, чтобы хранить способ анализа определенного класса проблем. При этом решений у кейса может быть много разных, в том числе, при учете (или не учете) тех или иных специфических условий.
Вспомнил интересный пример в тему из истории космонавтики:
в свое время в НАСА стояла задача разработать шариковую ручку для условий невесомости. Но проблема с шариковой ручкой в том, что чернила в ней подаются под действием силы тяжести. В условиях невесомости для подачи чернил нужна какая-то другая сила. Для решения этой задачи в НАСА даже выполнялся отдельный проект. А потом они увидели, что русские используют в условиях невесомости обычные карандаши.Если по простому, то в кейсе интерес для аналитика представляет противоречие (набор противоречий), а не решение (набор решений). Не побоюсь показаться банальным, но правильно сформулированная проблема гораздо важнее любого, пусть даже самого замечательного решения непонятной проблемы.
Вы должны авторизироваться для ответа в этой теме.
