Это задача QA инженеров выбивать себе время на тестовую документацию и прочие важные и нужные, по вашему мнению, активити. Потому что никто больше этим заниматься за вас не будет.

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

Если руководство устраивает - значит они не видят в этом проблем\рисков\убытков.

Если вы видите, а они нет - всегда можно это красочно донести.

Если не видите и просто хочется "чтоб хорошо было" - то сорян.

Если вы видите, а они нет - всегда можно это красочно донести.

Были и неоднократные попытки, но слушать кого-либо там не намерены.

Тут три варианта: 1) Плохо аргументировали 2) Аргументировали хорошо, но риски не достаточны, что бы это имело смысл. 3) В Руководстве самодуры и мудаки, которым уже ничем не помочь.

т.е. мы пришли, что в одном случае из трёх это всё таки не нормально

Нет, в двух из трех.

В третьем - не нормально, но обычно.

Аргументация была очень красочна и риски достаточны)

П.С. не на что не намекаю.

Аргументация была очень красочна и риски достаточны)

С вашей точки зрения, или с точки зрения бизнеса?

Ещё раз. Бизнес заказчиков волнуют деньги. Если вы им приходите такой классный и говорите, что сейчас мы тратим N денег, а бизнес от этого получает(или экономит) N^2 в перспективе в месяц - никто не будет просто так отказываться.

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

Ну, вполне резонный ответ.

Значит предлагайте решения, которые дадут профит в краткосрочной перспективе.

Вот на краткосрочную и были предложены чек-листы и ТК, однако по мнению рук-ва ТК никому непотребная штука.

А о какой-либо регрессии сказали забыть.

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

нез абивайте джуну голову.

Ещё раз. Бизнес заказчиков волнуют деньги. Если вы им приходите такой классный и говорите, что сейчас мы тратим N денег, а бизнес от этого получает(или экономит) N^2 в перспективе в месяц - никто не будет просто так отказываться.

Если бы так, то fmcg не тратили бы уйму денег на репутационные проекты

Если бы так, то fmcg не тратили бы уйму денег на репутационные проекты

Репутационные проекты это тоже деньги.

Репутационные проекты это тоже деньги.

Их никто не в состоянии посчитать

Вообще то нет.

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

Там все очень хорошо считается в плане long term ROI, в зависимости от проектов есть даже внятные метрики местами.

просто нужна нормальная аналитика с ясными и измеримыми целями. а если носороги из 90х делают промо-проекты "от крутого дизайнера" за мульты и никак их не меряют, это их проблемы

Там все очень хорошо считается в плане long term ROI, в зависимости от проектов есть даже внятные метрики местами.

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

ну а профит то какой от укрепления репутации?

наверное бОльшие продажи?

а это уже можно посчитать

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

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

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

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

если ты что-то не считаешь – ты в прошлом веке

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

Все считают цифры.

люди собирают вообще ВСЮ инфу по принципу "соберем, а дальше посчитаем"

Инструментов для этого более чем достаточно

ребятки, ну, я вам передаю из уст человека реализовывавшего эти проекты :)

в 21 веке its all about money

ребятки, ну, я вам передаю из уст человека реализовывавшего эти проекты :)

Передайте человеку, что ему пора бы начать правильно их реализовывать.

А не просто сливать бабло с надеждой на выхлоп.

а кто сказал, что правильно сначала считать?

люди собирают вообще ВСЮ инфу по принципу "соберем, а дальше посчитаем"

вы видели когда-нибудь как nielsen передаёт данные?

а кто сказал, что правильно сначала считать?

а как тогда оценить риски? как оценить правильные ли решения принимаются?

а кто сказал, что правильно сначала считать?

Здравый смысл подсказывает.

Если вы что то делаете - нужны критерии успешности и definition of done.

Иначе это деятельность ради освоения бюджетов, и за такое гнать надо.

Если вы что то делаете - нужны критерии успешности и definition of done.

критерий количество человек посмотревших на проект и улыбнувшихся с результатом 1кк чел. достаточен?

критерий количество человек посмотревших на проект и улыбнувшихся с результатом 1кк чел. достаточен?

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

Если нет - буллшит.

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

в деньги это не переводится :)

Переводится.

Узнаваемость бренда, повышение конверсий и вот это всё.

Узнаваемость бренда, повышение конверсий и вот это всё.

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

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

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

Весьма спорное утверждение, на самом деле.

В товарах народного потребления лояльность роляет как нигде.

я смотрел презентацию корпорации под названием "лояльности не существует" :)

там этакая брейкин ньюс, спорная, но подтвердженная

А я смотрел видео под названием "Разоблочение заговора: теория гелиоцентризма".

там этакая брейкин ньюс, спорная, но подтвердженная

Кем подтвержденная?

той же самой корпорацией, от имени которой глобальная презентация :) и я не про "видосик на ютубе" говорю, товарищ Шу.

мы, кажется, далеко в дебри уползли.

той же самой корпорацией, от имени которой глобальная презентация :) и я не про "видосик на ютубе" говорю, товарищ Шу.

А тут вопрос репрезентативности, как бы

Тут что один доклад одного спикера, что один видосик видеоблогера.

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

ERROR: S client not available

вы мне скажите, интереса ради, есть какие-то метрики способные оценить прибыль от рефакторинга кода, на который нужно N человеко-часов?

Да, есть.

вот на эту тему бы послушал рассказы

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

это эмпирические ценности, по факту никто заранее это оценить не может

это эмпирические ценности, по факту никто заранее это оценить не может

шу сможет, похоже :)

это эмпирические ценности, по факту никто заранее это оценить не может

По факту заранее можно поставить дефинишен оф дан и сравнить с тем, что выйдет.

По факту заранее можно поставить дефинишен оф дан и сравнить с тем, что выйдет.

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

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

хорошо, а как ты примешь решение проводить рефакторинг или нет?

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

А потом по результатам оценивать.

хорошо, а как ты примешь решение проводить рефакторинг или нет?

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

Рефакторинг ради рефакторинга не нужен.

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

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

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

Любые действия должны решать определенную проблему

как понять, что рефакторинг нужен с точки зрения бизнеса?

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

Ну, следовательно вносить изменения в этот код долго, дорого и рисковано.

как понять, что рефакторинг нужен с точки зрения бизнеса?

Обосновать, что говнокод реально замедляет разработку. По причинам написанным выше )

если рефакторинг позволит ускорить работу сервиса/облегчить расширяемость приложения – он нужен

если кому-то хочется красивый код, то нет

рефакторинг СЛИШКОМ широкое понятие, чтобы в отрыве от бизнес задач можно было считать от него выгоду. Рефакторинг ВСЕГДА в текущий момент времени - не написание фич и нерешение бизнес задач

если рефакторинг позволит ускорить работу сервиса/облегчить расширяемость приложения – он нужен

то это не рефакторинг, а фича

рефакторинг СЛИШКОМ широкое понятие, чтобы в отрыве от бизнес задач можно было считать от него выгоду. Рефакторинг ВСЕГДА в текущий момент времени - не написание фич и нерешение бизнес задач

+

то это не рефакторинг, а фича

вовсе нет :)

то это не рефакторинг, а фича

Или фикс )

как понять, что рефакторинг нужен с точки зрения бизнеса?

Если в роадмэпе по продукту есть 1+ задача затрагиваяющая этот участок кода - посчитать кост на копание в этом дерьме.

фича это новая функциональность, а то что ты свои костыли заставляешь лететь быстрее – это техдолг, который ты рефакторишь

рефакторинг СЛИШКОМ широкое понятие, чтобы в отрыве от бизнес задач можно было считать от него выгоду. Рефакторинг ВСЕГДА в текущий момент времени - не написание фич и нерешение бизнес задач

Рефакторинг это всегда способ лучше решать задачи бизнеса.

Лучше - измеримое понятие.

фича это новая функциональность, а то что ты свои костыли заставляешь лететь быстрее – это техдолг, который ты рефакторишь

вообще-то нет. Переписав работу не слать запрос в БД, а юзать кеш - ты че, не сделал фичу?

вообще-то нет. Переписав работу не слать запрос в БД, а юзать кеш - ты че, не сделал фичу?

пользователя не волнует, БД у тебя или кэш, ему надо чтоб работало