Внезапно вкатилась в мир спикерства весной этого года и планирую в октябре повторить. Для меня это был с одной стороны, плавный переход из внутреннего (в комьюнити компании) спикерства во внешнее, с другой - точка роста и проявления себя (и борьба со стеснительностью).
И отдельный респект за такое вдумчивое отношение к голосовым сообщениям. Имхо, если бы каждый перед отправкой его нормально формулировал и репетировал, то к голосовухам не относились бы с таким негативом.
А товары для левшей сейчас вполне себе есть, типа тех же ножниц, ручек и мышек, но поискать придется - всё-таки аудитория потребителей небольшая.
Спасибо за кейс! Могу предложить пару вариантов: 1. Посадить внутреннего фаната напротив внутреннего критика. Пусть дерутся! Критик говорит обобщения: "Любой бы сделал лучше", а фанат отвечает: "Да все бы сделали хуже!". И так потихонечку ситуация выправится. 2. Можно посидеть и подумать, а зачем мне нужна эта внешняя оценка ("любой бы сделал" и "коллеги молчат"), почему в данном кейсе недостаточно внутренней. И дальше уже работать с первопричиной.
Я решила вопрос контроля за финансами в обратную сторону, не от расходов, а от доходов. Каждое поступление распределяется по целевым счетам, с которых дальше идут траты. Какие-то из счетов каждый месяц пополняются и обнуляются, а на каких-то аккумулируются суммы. Если аккумулируются надолго, то переезжают на вклады.
Таким образом на внезапное желание купить макбук есть свой денежный счёт)
Ещё из плюсов: хорошо масштабируется из личного в совместный бюджет.
У mind map есть слабое место: когда продукт становится слишком большим, разветвленным и с блоками, используемыми в нескольких местах, то теряется наглядность и, соответственно, полезность. Но для малых и средних продуктов - очень подходит.
Грустно слышать такие истории. Особенно учитывая, что в доступе есть большое количество материалов по жизненному циклу ПО и по роли специалиста обеспечения качества. Вешать всю ответственность за баге на одну роль - как минимум нецелесообразно с точки зрения рисков управления.
На прошлых проектах дизайнер периодически себе ставил свежую версию приложения и проходил по всем флоу и экранам, смотрел, чтобы всякие отступы-выступы были на своих местах, нужные оттенки серого цветов использовались, верстка не съезжала и все такое. Заодно еще UX смотрел - удобно ли пользоваться, например, везде ли выезжает нужная клавиатура по тапу на поле ввода (где числовая, где буквенная), кнопки над клавиатурой поднимаются (на тех экранах, где надо) - и все в таком духе. На нынешнем проекте только внедряем эту активность, пока прошла первая итерация: дизайнер подсветил нам те мелочи, на которые у QA уже замылился глаз.
Спасибо за комментарий, мысли ценные. Про обновление регрессионной библиотеки - прям в точку, как раз сейчас в команде рефакторим тестовую модель, чтобы регресс был понятнее и прозрачнее. (И покрытие лучше).
Ответственно за баги на проде лежит на всей команде. (Я напомню, что QA баги не делают.) Пока еще ни разу не сталкивалась с такой реакцией дизайнера на задачу авторского надзора. И ПМ/бизнес в рамках приемочного тестирования часть регресса тоже прогоняет. Поэтому не вижу здесь какой-то потенциально конфликтной ситуации. Если конечно не тестировать тяп-ляп в надежде на то, что "да ладно, там дизайнер сам посмотрит".
Information
Rating
Does not participate
Registered
Activity
Specialization
Инженер по ручному тестированию, Инженер по обеспечению качества
Внезапно вкатилась в мир спикерства весной этого года и планирую в октябре повторить. Для меня это был с одной стороны, плавный переход из внутреннего (в комьюнити компании) спикерства во внешнее, с другой - точка роста и проявления себя (и борьба со стеснительностью).
Мне кажется, что в данном случае идет все же не сравнение аутсорс vs продукт, а проекты с ненастроенными процессами vs проекты со зрелыми процессами.
Так себе процессы могут быть и в продукте, а настроенные - и в аутсорсе. Имхо, продукт в данном случае - не панацея.
Но всей душой рада за автора, что он нашел такую хорошую компанию - это выглядит реально круто!
Спасибо!
Здоровья вам!
И отдельный респект за такое вдумчивое отношение к голосовым сообщениям. Имхо, если бы каждый перед отправкой его нормально формулировал и репетировал, то к голосовухам не относились бы с таким негативом.
А товары для левшей сейчас вполне себе есть, типа тех же ножниц, ручек и мышек, но поискать придется - всё-таки аудитория потребителей небольшая.
Спасибо за кейс!
Могу предложить пару вариантов:
1. Посадить внутреннего фаната напротив внутреннего критика.
Пусть дерутся!Критик говорит обобщения: "Любой бы сделал лучше", а фанат отвечает: "Да все бы сделали хуже!". И так потихонечку ситуация выправится.2. Можно посидеть и подумать, а зачем мне нужна эта внешняя оценка ("любой бы сделал" и "коллеги молчат"), почему в данном кейсе недостаточно внутренней. И дальше уже работать с первопричиной.
Спасибо!
Да, навык саморефлексии здесь очень важен, обратить внимание на свои умения, разгрузить мозг и не требовать от себя лишнего.
Я решила вопрос контроля за финансами в обратную сторону, не от расходов, а от доходов. Каждое поступление распределяется по целевым счетам, с которых дальше идут траты. Какие-то из счетов каждый месяц пополняются и обнуляются, а на каких-то аккумулируются суммы. Если аккумулируются надолго, то переезжают на вклады.
Таким образом на внезапное желание купить макбук есть свой денежный счёт)
Ещё из плюсов: хорошо масштабируется из личного в совместный бюджет.
У mind map есть слабое место: когда продукт становится слишком большим, разветвленным и с блоками, используемыми в нескольких местах, то теряется наглядность и, соответственно, полезность. Но для малых и средних продуктов - очень подходит.
Спасибо за статью, было интересно!
Подскажите, пожалуйста, как решали вопрос с безопасностью входных данных и, возможно, из обезличиванием?
Грустно слышать такие истории. Особенно учитывая, что в доступе есть большое количество материалов по жизненному циклу ПО и по роли специалиста обеспечения качества. Вешать всю ответственность за баге на одну роль - как минимум нецелесообразно с точки зрения рисков управления.
Спасибо!)
На прошлых проектах дизайнер периодически себе ставил свежую версию приложения и проходил по всем флоу и экранам, смотрел, чтобы всякие отступы-выступы были на своих местах, нужные оттенки
серогоцветов использовались, верстка не съезжала и все такое. Заодно еще UX смотрел - удобно ли пользоваться, например, везде ли выезжает нужная клавиатура по тапу на поле ввода (где числовая, где буквенная), кнопки над клавиатурой поднимаются (на тех экранах, где надо) - и все в таком духе.На нынешнем проекте только внедряем эту активность, пока прошла первая итерация: дизайнер подсветил нам те мелочи, на которые у QA уже замылился глаз.
Спасибо за комментарий, мысли ценные.
Про обновление регрессионной библиотеки - прям в точку, как раз сейчас в команде рефакторим тестовую модель, чтобы регресс был понятнее и прозрачнее. (И покрытие лучше).
Ответственно за баги на проде лежит на всей команде. (Я напомню, что QA баги не делают.)
Пока еще ни разу не сталкивалась с такой реакцией дизайнера на задачу авторского надзора. И ПМ/бизнес в рамках приемочного тестирования часть регресса тоже прогоняет. Поэтому не вижу здесь какой-то потенциально конфликтной ситуации. Если конечно не тестировать тяп-ляп в надежде на то, что "да ладно, там дизайнер сам посмотрит".