Типичная ситуация - взял задачу в работу, делать задачу пару дней, за эти пару дней, помимо задачи - два дейли, ретро, грумминг, митинг, проведение собеседования, 1-2-1 и плюс отвлечься проверить фикс бага.
Я вижу такие варианты как это можно обойти в данном контексте:
Разбивать задачи на супер маленькие, типа на час-два. Почти всегда нереалистично и/или требует кучи времени
Не отвлекаясь делать одну задачу. Если она на пару дней - тоже малореалистично
Каждый раз менять задаче статус, что ты ей не занимаешься. Или как-то иначе отмечать сколько времени потрачено. Как раз то о чем я выше пишу.
Какие у вас варианты в таком случае, как вы поймете, что слишком уж дофига встреч на тестере, например?
Так ведь списывание часов - это и есть ручное внесение информации. Это как раз тот случай, когда "составлял отчет по дню - 30минут", которое всех и раздражает.
Ссылка кажется не очень показательной. Там весь доказательный дизайн сводится к тому, что изучили конкурентов и сделали так же. Где там метрики упоминаемые у вас в статье и работа с ними, я не увидел
Вижу, что у ораторов выше все живут в мире, где очень осознанные люди, которые держат процессы команды в фокусе, а не заняты своими задачами. И команды все маленькие и все внутри команды понимают, что происходит и как сделать лучше и есть время в этом разбираться и копаться. И изменения такие, что не +/- пару процентов, а уменьшение ттм в пять раз, например.
Что ж, есть несколько человек, которые живут в другом мире и там метрики - полезное дело.
---
Я бы отметил, что метрики еще отлично подходят для ситуации, когда есть один процесс, который меняется на другой. И в процессе изменений надо не просыпать всякое, а в идеале что-нибудь даже улучшить. Тут без сбора метрик справиться довольно сложно, если конечно хочется иметь аргументированную позицию, а не "пальцем в небо"
К автору статьи есть пара вопросов:
1) по накладным расходам - откуда взять данные по которым строить метрики? Как будто бы перечисленные проблемы это больше ручной сбор, причем с постоянно меняющимся наполнением. Это как раз и основная причина, по которой метрику и не считают. Все автоматизированные вещи на этот счет - вызывают дикий баттхерт и заслужено - это всякие скриношты экранов или отметки сколько времени потрачено на задачу и т.д. Возможно есть какой-то разумный вариант, поделитесь?
2) про доказательный дизайн и его метрики есть что-то более подробное почитать, поделитесь ссылочкой, пожалуйста.
Вы сами пишите, что переделка так или иначе задевает то что работало хорошо
Рефлексия в целом не очень приятное занятие, особенно если ты раньше этим никогда не занимался, а без нее сложно понять со стороны, а что собственно говоря нужно менять
То что изменений ждут, не делают процесс приятным, аналогично, горькое лекарство все равно будет горьким, даже если ты точно знаешь, что оно поможет.
Любопытный кейс. Я видел две такие "умирающие" команды и в обоих ребята просто разошлись и не стали тратить время на то чтобы спасти ненужный им конструкт "команда". И это несмотря на то, что тоже глубоко погрузились в специфику и делали очень серьезные вещи (кстати тоже в банках обе команды были).
Во всем этом интересна мотивация команды участвовать в этом - менять процессы, долго больно и с неочевидным финалом. Когда альтернатива - просто перейти в другую команду/компанию, да еще и почти наверняка с повышением оклада.
Все так, это не редкая история. Я сам был дважды свидетелем, как украли мобильник банально взяв из руки и выпрыгнув в последни момент из транспорта. Один раз в Москве, один раз в Кордове.
Я прожил в Аргентине чуть больше полугода и большую часть времени не в БА, так что могу немного раскрыть тему.
Медицина - в целом считается, лучшей в Южной Америке, несколько лучше, чем в России. При этом если говорить про бесплатную медицину или медицину за пределами столицы, то проблемы в общем-то такие же как аналогичные темы в России. За не очень большие (по айтишным меркам) деньги в БА, все будет плюс-минус так же как и у нас. Какие-то конкретные области, например, лечение специфических видов рака - могут сильно отличаться в обе стороны, нужно выяснять отдельно.
Транспортная доступность Аргентины - на три головы выше, чем в России. Условно, попасть в горы Фицрой (наиболее известные) можно просто на автобусе, который ходит каждый день и стоит не очень большие деньги. При этом попасть на Байкал, например, гораздо сложнее. Так же намного приятнее окружение и удобства - всякие кемпинги и прочее, лучшего качества и их больше.
Если говорить про транспорт внутри города, то про БА в целом ТС сказал верно, в других городах - очень сильно разнится статус этих городов. В Кордове, например, похожая ситуация, в Мендосе она даже лучше, я бы сказал, но в какой-нибудь там Ушуае или в каких-нибудь захудалых провинциях типа Хухуя, все намного хуже.
Образование примерно как медицина. Тоже считается лучшим в ЛА и считается лучше, чем в России. Как бонус, их дипломы учитываются в Европе и США.
Безопасность. В целом согласен с ТС. Если в Москве прийти ночью в подворотню, на задворках МО и посветить там новым айфоном себе дорогу, то безопасность будет примерно такая же как в аналогичной ситуации в БА. Но полиции в БА реально очень много. В других городах намного меньше, но там и проблем намного меньше.
Если у меня десять разных айфонов и пять разных айпадов с одинаковым приложением на нем и на одном из них запросы дублируются - это однозначно баг. Есть конечно маааааленький шанс того, что в спецификации указано, что на конкретном айпаде, условно, нужно делать двойные запросы и даже может быть это правильное поведение, но я не очень в это верю. Ну и да, в том маловероятном случае, когда я таки не прав, объяснить это можно разными способами.
В начале моей карьеры, лет восемь назад, я устроился в компанию, которая разрабатывала мобильные приложения на заказ.
У меня был довольно большой парк устройств и в какой-то момент я обнаружил, что ровно на одном устройстве, при старте приложения все запросы почему-то дублируются. Я тогда еще только начинал разбираться в тестировании мобильных приложений и не мог сказать, как так вышло, но тут была очевидная проблема - на всех остальных девайсах так, а на этом не так. Ну и явно два одинаковых запроса подряд (и так с каждым) - это какая-то ерунда.
Ну я и завел баг, что мол, так и так, какая-то ерунда.
Буквально через пять минут ко мне прибегает разработчик и начинает орать на меня матом. В целом суть претензий свелась к тому, что мал я еще в архитектуре приложения разбираться и не пошел бы я куда-нибудь далеко с таким багом. И вообще это не баг, а я ничего не понимаю.
Вот это я конечно тогда знатно оху... удивился. Сейчас меня бы такое уже не выбило бы из колеи и я знаю, что в таких ситуациях делать, но тогда я аж засомневался, а стоит ли вообще тут работать с таким подходом.
Всё закончилось хорошо, через месяц этот человек ушел в Сбертех, а я еще год работал в той компании.
Тут есть довольно много зависимостей на разные обстоятельства. Например, два месяца назад я работал в компании, где узким местом всего процесса были разработчики - их было меньше, чем нужно. Поэтому тестирование там было весьма прокачанным и тратило довольно много времени на подробную локализацию дефектов. А сейчас я перешел работать в компанию, где тестирование - узкое место, разработчиков хорошего уровня существенно больше, чем тестировщиков. Поэтому тут время на заведение дефекта минимальное, иначе страдает общий тайм-ту-маркет.
Поэтому я бы не стал однозначно в таком вопросе высказываться - слишком много вводных, и сеньор их должен адекватно учитывать
Был у меня в команде как-то один парень. Он мог, найдя ошибку, потратить часа три, докопаться до конкретного места в коде и завести задачу на разработку, где нужно просто поправить это самое место. Т.е. сделать 95% все работы разработчика в данном кейсе.
В то время я не обладал такими навыками в чтении кода, поэтому просто делал примерно 80% всех остальных задач в команде. И когда натыкался на похожую ошибку, просто прикладывал шаги, скриншоты, логи, стектрейсы и т.д.
Технически он был сильнее, но выхлоп от его работы был намного ниже.
Так что у настоящего сеньора не должно быть "разбираться до конца". Он должен оценить какой выхлоп он получит от того, что будет разбираться, какие есть риски по пути, а так же не забыть оценить скорость процесса.
И он должен понимать, что практически всегда "разбираться до конца", проигрывает по эффективности "распараллелить работу, чтобы успеть проверить N задач, пока разработчик занимается выяснением корня проблемы и его фиксом, чтобы успеть сдать релиз вовремя".
Вариантов как развлечь себя с точки зрения тестирования конечно вагон, кто ж спорит. Но это не отменяет того, что все равно будет какой-то процент рутины. Для джуна он может и 90%, а для сеньора 30-40%
Любопытно, я уже далеко не первый раз вижу такую ситуацию: статья о чем-то связанном с тестированием, основные потребители которой, очевидно, будут тестировщики. И комментарий в этой статье, который каким-либо образом выражает мысль, что тестирование - это отстой.
Ну т.е. очевидно, что подавляющее большинство людей, которые увидят этот комментарий - будут как раз теми, кто занимается этим тестированием и они будут недовольны. Что выльется в понижении кармы, минусах, гневных комментариях и прочем.
Зачем? Я думал, может просто люди-тролли, но я пару раз смотрел по комментариям и нет, вроде достаточно все адекватно. Нулевая эмпатийность и отсутствующее понимание границ? Захадачна.
P.S. по смыслу комментария могу сказать, что я работаю тестировщиком одиннадцать лет. И я специалист (т.е. не лид или хед) и получаю больше чем большинство программистов-специалистов, с которыми работаю. Рутина в работе есть, разумеется, но она есть везде, в том же программировании - точно так же есть рутинный кодинг. Вопрос в процентном соотношении и меня этот процент устраивает
Любопытно, плацкарт и правда считается безопаснее, чем купе? А есть какая-то статистика по этому поводу (проишествия всякие и т.д.)?
Для меня плацкарт - синоним ада, особенно тот факт, что там может любой желающий вломиться к любому желающему... Для меня самый идеальный сценарий: взять всё купе целиком под свою компанию, тогда посторонние люди в принципе не имеют к тебе доступа и слава богу.
Я, с точки зрения квестов, из больших ААА-тайтлов вспоминаю разве что третьего ведьмака, но с точки зрения открытого мира и модостроительства там конечно все не так радужно. Из инди вообще ничего не знаю, возможно и зря, можете привести примеры, я бы ознакомился?
Тут двоякая ситуация. Лично мне больше нравится квестовая составляющая Морры, чем Скайрима, однако, по очевидным причинам, Скайрим более популярен и, соответственно, его разработчики больше получают за него денег. А значит у каких-то еще разработчиков больше желания сделать что-то РПГшное. Конечно большая часть будет а ля Скайрим, но иной раз будет выстреливать и что-то наподобие Морры.
Честно говоря, сейчас так на вскидку не вспомню ничего похожего за последние лет десять, но, возможно я что-то упустил, конечно.
По поводу книг, к слову, в Морре были квесты, которые нельзя было фактически взять, но можно было выполнить — это почти все квесты богов, например. Помню, что один из квестов — нужно было найти под водой в море недалеко от рандомного побережья вход в какое-то подводное укрепление и понять, что там вообще в принципе есть что искать можно было исключительно из книг.
Как развивались квесты в линейке свитков:
— Морровинд.
Где-то на севере есть озеро, рядом с ним замок. Тебе нужно будет обогнуть его по краю и в холмах ты увидишь нужную катакомбу. В ней живет такой-то персонаж, нужно попытаться его уговорить.
В реальности — час исследуешь всю округу в поисках этих катакомб, случайным образом наконец натыкаешься, а нпс там невозможно уболтать, если ты уже сделал некоторые другие квесты (о чем тебя, конечно же, не уведомляют заранее). Убить нпс не получается, ты еще слишком слаб. Возвращаешься через месяц.
— Обливион.
В двух минутах на север озеро такое-то, я отметил на карте. Там будет катакомбы, я отметил на карте. Иди туда и договорись с нпс. Приходишь — договариваешься.
— Скайрим.
Блаблабла, иди за маячком на карте, блаблабла.
P.S. один из лучших модов скайрима, на мой взгляд, это Enderal: Forgotten Stories. Он полностью переделывает всю игру целиком.
Типичная ситуация - взял задачу в работу, делать задачу пару дней, за эти пару дней, помимо задачи - два дейли, ретро, грумминг, митинг, проведение собеседования, 1-2-1 и плюс отвлечься проверить фикс бага.
Я вижу такие варианты как это можно обойти в данном контексте:
Разбивать задачи на супер маленькие, типа на час-два. Почти всегда нереалистично и/или требует кучи времени
Не отвлекаясь делать одну задачу. Если она на пару дней - тоже малореалистично
Каждый раз менять задаче статус, что ты ей не занимаешься. Или как-то иначе отмечать сколько времени потрачено. Как раз то о чем я выше пишу.
Какие у вас варианты в таком случае, как вы поймете, что слишком уж дофига встреч на тестере, например?
Так ведь списывание часов - это и есть ручное внесение информации. Это как раз тот случай, когда "составлял отчет по дню - 30минут", которое всех и раздражает.
Ссылка кажется не очень показательной. Там весь доказательный дизайн сводится к тому, что изучили конкурентов и сделали так же. Где там метрики упоминаемые у вас в статье и работа с ними, я не увидел
Отличная статья.
Вижу, что у ораторов выше все живут в мире, где очень осознанные люди, которые держат процессы команды в фокусе, а не заняты своими задачами. И команды все маленькие и все внутри команды понимают, что происходит и как сделать лучше и есть время в этом разбираться и копаться. И изменения такие, что не +/- пару процентов, а уменьшение ттм в пять раз, например.
Что ж, есть несколько человек, которые живут в другом мире и там метрики - полезное дело.
---
Я бы отметил, что метрики еще отлично подходят для ситуации, когда есть один процесс, который меняется на другой. И в процессе изменений надо не просыпать всякое, а в идеале что-нибудь даже улучшить. Тут без сбора метрик справиться довольно сложно, если конечно хочется иметь аргументированную позицию, а не "пальцем в небо"
К автору статьи есть пара вопросов:
1) по накладным расходам - откуда взять данные по которым строить метрики? Как будто бы перечисленные проблемы это больше ручной сбор, причем с постоянно меняющимся наполнением. Это как раз и основная причина, по которой метрику и не считают. Все автоматизированные вещи на этот счет - вызывают дикий баттхерт и заслужено - это всякие скриношты экранов или отметки сколько времени потрачено на задачу и т.д. Возможно есть какой-то разумный вариант, поделитесь?
2) про доказательный дизайн и его метрики есть что-то более подробное почитать, поделитесь ссылочкой, пожалуйста.
Менять процессы это всегда больно, так как:
Надо переучиваться делать по другому
Вы сами пишите, что переделка так или иначе задевает то что работало хорошо
Рефлексия в целом не очень приятное занятие, особенно если ты раньше этим никогда не занимался, а без нее сложно понять со стороны, а что собственно говоря нужно менять
То что изменений ждут, не делают процесс приятным, аналогично, горькое лекарство все равно будет горьким, даже если ты точно знаешь, что оно поможет.
Любопытный кейс. Я видел две такие "умирающие" команды и в обоих ребята просто разошлись и не стали тратить время на то чтобы спасти ненужный им конструкт "команда". И это несмотря на то, что тоже глубоко погрузились в специфику и делали очень серьезные вещи (кстати тоже в банках обе команды были).
Во всем этом интересна мотивация команды участвовать в этом - менять процессы, долго больно и с неочевидным финалом. Когда альтернатива - просто перейти в другую команду/компанию, да еще и почти наверняка с повышением оклада.
Выясняли этот вопрос?
Я и ТС в целом уже отметили про безопасность. Если нужна статистика, то вот сайт по России https://epp.genproc.gov.ru/web/gprf/activity/crimestat , чего-то аналогичного по аргентине не нагуглил, вот какая-то рандомная статья https://gilsocmin.ru/ru/node/1409
Все так, это не редкая история. Я сам был дважды свидетелем, как украли мобильник банально взяв из руки и выпрыгнув в последни момент из транспорта. Один раз в Москве, один раз в Кордове.
Я прожил в Аргентине чуть больше полугода и большую часть времени не в БА, так что могу немного раскрыть тему.
Медицина - в целом считается, лучшей в Южной Америке, несколько лучше, чем в России. При этом если говорить про бесплатную медицину или медицину за пределами столицы, то проблемы в общем-то такие же как аналогичные темы в России. За не очень большие (по айтишным меркам) деньги в БА, все будет плюс-минус так же как и у нас. Какие-то конкретные области, например, лечение специфических видов рака - могут сильно отличаться в обе стороны, нужно выяснять отдельно.
Транспортная доступность Аргентины - на три головы выше, чем в России. Условно, попасть в горы Фицрой (наиболее известные) можно просто на автобусе, который ходит каждый день и стоит не очень большие деньги. При этом попасть на Байкал, например, гораздо сложнее. Так же намного приятнее окружение и удобства - всякие кемпинги и прочее, лучшего качества и их больше.
Если говорить про транспорт внутри города, то про БА в целом ТС сказал верно, в других городах - очень сильно разнится статус этих городов. В Кордове, например, похожая ситуация, в Мендосе она даже лучше, я бы сказал, но в какой-нибудь там Ушуае или в каких-нибудь захудалых провинциях типа Хухуя, все намного хуже.
Образование примерно как медицина. Тоже считается лучшим в ЛА и считается лучше, чем в России. Как бонус, их дипломы учитываются в Европе и США.
Безопасность. В целом согласен с ТС. Если в Москве прийти ночью в подворотню, на задворках МО и посветить там новым айфоном себе дорогу, то безопасность будет примерно такая же как в аналогичной ситуации в БА. Но полиции в БА реально очень много. В других городах намного меньше, но там и проблем намного меньше.
Если у меня десять разных айфонов и пять разных айпадов с одинаковым приложением на нем и на одном из них запросы дублируются - это однозначно баг. Есть конечно маааааленький шанс того, что в спецификации указано, что на конкретном айпаде, условно, нужно делать двойные запросы и даже может быть это правильное поведение, но я не очень в это верю. Ну и да, в том маловероятном случае, когда я таки не прав, объяснить это можно разными способами.
В начале моей карьеры, лет восемь назад, я устроился в компанию, которая разрабатывала мобильные приложения на заказ.
У меня был довольно большой парк устройств и в какой-то момент я обнаружил, что ровно на одном устройстве, при старте приложения все запросы почему-то дублируются. Я тогда еще только начинал разбираться в тестировании мобильных приложений и не мог сказать, как так вышло, но тут была очевидная проблема - на всех остальных девайсах так, а на этом не так. Ну и явно два одинаковых запроса подряд (и так с каждым) - это какая-то ерунда.
Ну я и завел баг, что мол, так и так, какая-то ерунда.
Буквально через пять минут ко мне прибегает разработчик и начинает орать на меня матом. В целом суть претензий свелась к тому, что мал я еще в архитектуре приложения разбираться и не пошел бы я куда-нибудь далеко с таким багом. И вообще это не баг, а я ничего не понимаю.
Вот это я конечно тогда знатно оху... удивился. Сейчас меня бы такое уже не выбило бы из колеи и я знаю, что в таких ситуациях делать, но тогда я аж засомневался, а стоит ли вообще тут работать с таким подходом.
Всё закончилось хорошо, через месяц этот человек ушел в Сбертех, а я еще год работал в той компании.
Тут есть довольно много зависимостей на разные обстоятельства. Например, два месяца назад я работал в компании, где узким местом всего процесса были разработчики - их было меньше, чем нужно. Поэтому тестирование там было весьма прокачанным и тратило довольно много времени на подробную локализацию дефектов. А сейчас я перешел работать в компанию, где тестирование - узкое место, разработчиков хорошего уровня существенно больше, чем тестировщиков. Поэтому тут время на заведение дефекта минимальное, иначе страдает общий тайм-ту-маркет.
Поэтому я бы не стал однозначно в таком вопросе высказываться - слишком много вводных, и сеньор их должен адекватно учитывать
Не согласен со вторым пунктом.
Был у меня в команде как-то один парень. Он мог, найдя ошибку, потратить часа три, докопаться до конкретного места в коде и завести задачу на разработку, где нужно просто поправить это самое место. Т.е. сделать 95% все работы разработчика в данном кейсе.
В то время я не обладал такими навыками в чтении кода, поэтому просто делал примерно 80% всех остальных задач в команде. И когда натыкался на похожую ошибку, просто прикладывал шаги, скриншоты, логи, стектрейсы и т.д.
Технически он был сильнее, но выхлоп от его работы был намного ниже.
Так что у настоящего сеньора не должно быть "разбираться до конца". Он должен оценить какой выхлоп он получит от того, что будет разбираться, какие есть риски по пути, а так же не забыть оценить скорость процесса.
И он должен понимать, что практически всегда "разбираться до конца", проигрывает по эффективности "распараллелить работу, чтобы успеть проверить N задач, пока разработчик занимается выяснением корня проблемы и его фиксом, чтобы успеть сдать релиз вовремя".
Вариантов как развлечь себя с точки зрения тестирования конечно вагон, кто ж спорит. Но это не отменяет того, что все равно будет какой-то процент рутины. Для джуна он может и 90%, а для сеньора 30-40%
Любопытно, я уже далеко не первый раз вижу такую ситуацию: статья о чем-то связанном с тестированием, основные потребители которой, очевидно, будут тестировщики. И комментарий в этой статье, который каким-либо образом выражает мысль, что тестирование - это отстой.
Ну т.е. очевидно, что подавляющее большинство людей, которые увидят этот комментарий - будут как раз теми, кто занимается этим тестированием и они будут недовольны. Что выльется в понижении кармы, минусах, гневных комментариях и прочем.
Зачем? Я думал, может просто люди-тролли, но я пару раз смотрел по комментариям и нет, вроде достаточно все адекватно. Нулевая эмпатийность и отсутствующее понимание границ? Захадачна.
P.S. по смыслу комментария могу сказать, что я работаю тестировщиком одиннадцать лет. И я специалист (т.е. не лид или хед) и получаю больше чем большинство программистов-специалистов, с которыми работаю. Рутина в работе есть, разумеется, но она есть везде, в том же программировании - точно так же есть рутинный кодинг. Вопрос в процентном соотношении и меня этот процент устраивает
Любопытно, плацкарт и правда считается безопаснее, чем купе? А есть какая-то статистика по этому поводу (проишествия всякие и т.д.)?
Для меня плацкарт - синоним ада, особенно тот факт, что там может любой желающий вломиться к любому желающему... Для меня самый идеальный сценарий: взять всё купе целиком под свою компанию, тогда посторонние люди в принципе не имеют к тебе доступа и слава богу.
Честно говоря, сейчас так на вскидку не вспомню ничего похожего за последние лет десять, но, возможно я что-то упустил, конечно.
— Морровинд.
Где-то на севере есть озеро, рядом с ним замок. Тебе нужно будет обогнуть его по краю и в холмах ты увидишь нужную катакомбу. В ней живет такой-то персонаж, нужно попытаться его уговорить.
В реальности — час исследуешь всю округу в поисках этих катакомб, случайным образом наконец натыкаешься, а нпс там невозможно уболтать, если ты уже сделал некоторые другие квесты (о чем тебя, конечно же, не уведомляют заранее). Убить нпс не получается, ты еще слишком слаб. Возвращаешься через месяц.
— Обливион.
В двух минутах на север озеро такое-то, я отметил на карте. Там будет катакомбы, я отметил на карте. Иди туда и договорись с нпс. Приходишь — договариваешься.
— Скайрим.
Блаблабла, иди за маячком на карте, блаблабла.
P.S. один из лучших модов скайрима, на мой взгляд, это Enderal: Forgotten Stories. Он полностью переделывает всю игру целиком.