Forwarded from Knowledge and bacon - Управление знаниями в IT
Долг компетенций
Понятие технический долг уже плотно вошло в нашу жизнь, но оно предельно широкое, к нему относят множество аспектов разработки и по сути все, что не совпадает с представлением об идеальном техническом решении: архитектура, тесты, ресурсы, документация, навыки команды.
Мне бы хотелось поговорить об одном из аспектов технического долга, который как раз про "управление знаниями" – это долг компетенций.
Долг компетенций – это узкая специализация в процессе разработки, когда знания об архитектуре системы, о принятых решениях, о деталях реализации, сосредоточены у отдельных людей, подход к изменению такого кода или настроек может отнять у других участников команды намного больше времени, а может и вообще привести е неверным решениям.
Уход специалиста сразу превращает такой код в "legacy", "not invented here", "to rewrite", "так исторически сложилось" и прочие штампы. Усложняется поддержка и, как правило, ухудшается точность декомпозиции задач при работе с таким кодом, поскольку не влезая в детали сложно оценить реальный объем изменений.
К посту прикреплена иллюстрация типичного долга компенетций, где есть пересекающееся знание, а есть уникальное, с bus фактором – 1. Долг компетенций растет тем быстрее, чем чаще вы вносите изменения в код базу и чем меньше у вас общего кода и библиотек, которыми пользуется большинство в команде.
Что снижает долг компетенций
Парное программирование, перекрестные ревью кода, когда с одним и тем же кодом постоянно знакомы хотя бы два человека. Аналогично и с периодическим командным рефакторингом.
Также могут помочь автоматические тесты, юнит и функциональные, чтобы написать тест, как правило, нужно понимать работу системы или ее функциональной части более-менее хорошо, плюс документация в коде или рядом с ним. Причем, не требуется страниц текста, да и вообще текст, например, вы можете фиксировать каждый модуль в виде флоучарта или UML диаграммы последовательности, хранить их рядом с кодом в PlantUML с возможностью перед началом работы над модулем быстро сгенерить диаграмму в условный HTML.
Еще одна хорошая практика – фиксировать принятые архитектурные и технические решения с небольшим обоснованием, даже если они приняты на митинге или во время разговора на кухне.
Радикальные методы вроде взять и переписать все, заменить старый код на новый, обычно в условиях быстрой доставки функциональности – это роскошь, ведь у нас всегда есть дела поважнее, но есть положительный аспект, чтобы переписать хотя бы часть системы – нужно понять, как она работает.
Еще по теме
http://www.leanway.no/a-deeper-look-at-competence-debt/
http://www.julianbrowne.com/article/competence-debt
Понятие технический долг уже плотно вошло в нашу жизнь, но оно предельно широкое, к нему относят множество аспектов разработки и по сути все, что не совпадает с представлением об идеальном техническом решении: архитектура, тесты, ресурсы, документация, навыки команды.
Мне бы хотелось поговорить об одном из аспектов технического долга, который как раз про "управление знаниями" – это долг компетенций.
Долг компетенций – это узкая специализация в процессе разработки, когда знания об архитектуре системы, о принятых решениях, о деталях реализации, сосредоточены у отдельных людей, подход к изменению такого кода или настроек может отнять у других участников команды намного больше времени, а может и вообще привести е неверным решениям.
Уход специалиста сразу превращает такой код в "legacy", "not invented here", "to rewrite", "так исторически сложилось" и прочие штампы. Усложняется поддержка и, как правило, ухудшается точность декомпозиции задач при работе с таким кодом, поскольку не влезая в детали сложно оценить реальный объем изменений.
К посту прикреплена иллюстрация типичного долга компенетций, где есть пересекающееся знание, а есть уникальное, с bus фактором – 1. Долг компетенций растет тем быстрее, чем чаще вы вносите изменения в код базу и чем меньше у вас общего кода и библиотек, которыми пользуется большинство в команде.
Что снижает долг компетенций
Парное программирование, перекрестные ревью кода, когда с одним и тем же кодом постоянно знакомы хотя бы два человека. Аналогично и с периодическим командным рефакторингом.
Также могут помочь автоматические тесты, юнит и функциональные, чтобы написать тест, как правило, нужно понимать работу системы или ее функциональной части более-менее хорошо, плюс документация в коде или рядом с ним. Причем, не требуется страниц текста, да и вообще текст, например, вы можете фиксировать каждый модуль в виде флоучарта или UML диаграммы последовательности, хранить их рядом с кодом в PlantUML с возможностью перед началом работы над модулем быстро сгенерить диаграмму в условный HTML.
Еще одна хорошая практика – фиксировать принятые архитектурные и технические решения с небольшим обоснованием, даже если они приняты на митинге или во время разговора на кухне.
Радикальные методы вроде взять и переписать все, заменить старый код на новый, обычно в условиях быстрой доставки функциональности – это роскошь, ведь у нас всегда есть дела поважнее, но есть положительный аспект, чтобы переписать хотя бы часть системы – нужно понять, как она работает.
Еще по теме
http://www.leanway.no/a-deeper-look-at-competence-debt/
http://www.julianbrowne.com/article/competence-debt
Думаю про гендерное в тестировании. Я бы хотела написать про это статью или сделать подробный рассказ, но сил пока хватает только на заметки по ходу размышлений.
В большинстве дискуссий о женщинах в IT я слышу про программисток. Это действительно важные вопросы - и про STEM, и про то, как пробиваться в престижные области, которые считаются сейчас в обществе мужскими.
В тестировании много женщин и казалось бы, что тут особых проблем нет - если хочешь - приходи и становись тестировщицей. И я сталкивалась с тем, что даже программистки считали, что стать тестировщицей - это легкая дорога.
Но я считаю, что не все так просто. В тестировании в России явно выделяются разные сегменты работы - преимущественно ручное тестирование, автоматизированное и требующее других глубоких технических навыков тестирование, управление.
В моем опыте больше всего женщин в ручном тестировании и оно же ценится меньше всего. Мужчины тут тоже есть, но чаще они достаточно быстро уходят в то, что приносит больше денег и почета.
В IT в целом есть культура кода и технических навыков, которые первичны и престижны. И из этого мне кажется все эти разговоры про то "должны ли менеджеры/дизайнеры/тестировщики уметь программировать?".
Ручное тестирование же при этом - про социальное, про слушать и слышать людей, про строить гипотезы и их доказывать. И это все чаще всего происходит в голове тестировщика/тестировщицы. Это такая работа, которая не видна снаружи - виден только результат. Невидимая работа.
Нашу работу и не видят и не интересуются по-настоящему, что мы делаем и сколько это занимает времени и сил. И вопросы "да что тут тестировать?" мне кажутся близкими к "да что тут дома делать, с современной техникой-то?".
И как и с домашними делами, видно, только когда эта работа не сделана. И то далеко не всегда сразу. Если не протестировать или недостаточно протестировать пару раз может даже ничего страшного не случится, если не делать это значимое время - система будет деградировать.
А еще многие тестировщицы живут с ощущением того, что их не ценят. Они знают, что они делают важную работу, но эта невидимая работа. И мы думаем, что чем больше мы будем стараться и чем лучше мы ее будем делать, тем больше будут ценить.
В моем опыте признание получаешь от людей, которые работают с тобой бок о бок, которые видят как становится лучше - даже если не понимают, как мы это делаем. А вот уровнем выше - уже нет. Редко какой технический директор вспомнит про то, что у него есть ручные тестировщики и скажет про их достижения.
И это тоже попадает в опыт многих женщин - стараться, делать невидимую работу раз за разом и надеяться, что нас оценят по достоинству.
Продолжение следует...
#diversity
#women_in_tech
В большинстве дискуссий о женщинах в IT я слышу про программисток. Это действительно важные вопросы - и про STEM, и про то, как пробиваться в престижные области, которые считаются сейчас в обществе мужскими.
В тестировании много женщин и казалось бы, что тут особых проблем нет - если хочешь - приходи и становись тестировщицей. И я сталкивалась с тем, что даже программистки считали, что стать тестировщицей - это легкая дорога.
Но я считаю, что не все так просто. В тестировании в России явно выделяются разные сегменты работы - преимущественно ручное тестирование, автоматизированное и требующее других глубоких технических навыков тестирование, управление.
В моем опыте больше всего женщин в ручном тестировании и оно же ценится меньше всего. Мужчины тут тоже есть, но чаще они достаточно быстро уходят в то, что приносит больше денег и почета.
В IT в целом есть культура кода и технических навыков, которые первичны и престижны. И из этого мне кажется все эти разговоры про то "должны ли менеджеры/дизайнеры/тестировщики уметь программировать?".
Ручное тестирование же при этом - про социальное, про слушать и слышать людей, про строить гипотезы и их доказывать. И это все чаще всего происходит в голове тестировщика/тестировщицы. Это такая работа, которая не видна снаружи - виден только результат. Невидимая работа.
Нашу работу и не видят и не интересуются по-настоящему, что мы делаем и сколько это занимает времени и сил. И вопросы "да что тут тестировать?" мне кажутся близкими к "да что тут дома делать, с современной техникой-то?".
И как и с домашними делами, видно, только когда эта работа не сделана. И то далеко не всегда сразу. Если не протестировать или недостаточно протестировать пару раз может даже ничего страшного не случится, если не делать это значимое время - система будет деградировать.
А еще многие тестировщицы живут с ощущением того, что их не ценят. Они знают, что они делают важную работу, но эта невидимая работа. И мы думаем, что чем больше мы будем стараться и чем лучше мы ее будем делать, тем больше будут ценить.
В моем опыте признание получаешь от людей, которые работают с тобой бок о бок, которые видят как становится лучше - даже если не понимают, как мы это делаем. А вот уровнем выше - уже нет. Редко какой технический директор вспомнит про то, что у него есть ручные тестировщики и скажет про их достижения.
И это тоже попадает в опыт многих женщин - стараться, делать невидимую работу раз за разом и надеяться, что нас оценят по достоинству.
Продолжение следует...
#diversity
#women_in_tech
❤1
Про тестирование и гендерное часть два. Напоминаю, что это формат черновиков.
В моем опыте от тестировщиков те, кто их нанимает, ожидают кропотливости, внимательности, способности к длительному монотонному труду и ответственности. И это тоже попадает в гендерные ожидания. Невидимая, монотонная, кропотливая работа, с которой лучше справляются женщины.
На самом деле у нас может быть совсем другое тестирование, но даже если про это рассказывать другим людям - все равно не верят) Сколько разговоров про то, что ручное тестирование - это делать из раза в раз одно и тоже? И что разработчики не хотели бы тестировать - это скучно?
А еще от тестировщиков и особенно тестирировщиц окружающие коллеги ждут, что они будут заботиться о деле, будут отвественны и будут отвечать за конечный результат. Занятно, что люди, у которых меньше всего власти и влияния, отвечают за то, как все получится. На деле, понятно, что мы не можем за это отвечать, но часто от нас ждут именно этого.
И это приводит и к переработкам, и к попыткам успеть все и еще немного. Отвечать за все, контролировать, много работать и ждать, что нас оценят.
Зона нашей работы все время размывается. Раз уж это невидимая работа, то почему бы тестировщикам не делать еще что-нибудь? Как в том же домашнем хозяйств - дело перетекает в другое дело, мы начинаем делаем то, что кроме нас не сделает никто, а проекту без этого ощутимо плохо. Чаще всего это менеджерская и аналитическая работа. Мы латаем дыры, подхватываем расползающееся полотно и пытаемся его заштопать.
В лучшем случае - это признается, нам больше платят и ценят. В плохом - это проходит незамеченным или разумеется само собой.
А еще на нас скидывают разную монотонную работу, под девизом "надо же развиваться". Править селекторы в коде, править метки во фронтовых шаблонах - без системы это не дает ничего, забывается сразу, как прекращаешь это делать и занимает изрядно времени. А иногда мы предлагаем это сами - потому, что нам нужен результат, а уговорить это сделать тех, кто должен - не получается.
#diversity
#women_in_tech
В моем опыте от тестировщиков те, кто их нанимает, ожидают кропотливости, внимательности, способности к длительному монотонному труду и ответственности. И это тоже попадает в гендерные ожидания. Невидимая, монотонная, кропотливая работа, с которой лучше справляются женщины.
На самом деле у нас может быть совсем другое тестирование, но даже если про это рассказывать другим людям - все равно не верят) Сколько разговоров про то, что ручное тестирование - это делать из раза в раз одно и тоже? И что разработчики не хотели бы тестировать - это скучно?
А еще от тестировщиков и особенно тестирировщиц окружающие коллеги ждут, что они будут заботиться о деле, будут отвественны и будут отвечать за конечный результат. Занятно, что люди, у которых меньше всего власти и влияния, отвечают за то, как все получится. На деле, понятно, что мы не можем за это отвечать, но часто от нас ждут именно этого.
И это приводит и к переработкам, и к попыткам успеть все и еще немного. Отвечать за все, контролировать, много работать и ждать, что нас оценят.
Зона нашей работы все время размывается. Раз уж это невидимая работа, то почему бы тестировщикам не делать еще что-нибудь? Как в том же домашнем хозяйств - дело перетекает в другое дело, мы начинаем делаем то, что кроме нас не сделает никто, а проекту без этого ощутимо плохо. Чаще всего это менеджерская и аналитическая работа. Мы латаем дыры, подхватываем расползающееся полотно и пытаемся его заштопать.
В лучшем случае - это признается, нам больше платят и ценят. В плохом - это проходит незамеченным или разумеется само собой.
А еще на нас скидывают разную монотонную работу, под девизом "надо же развиваться". Править селекторы в коде, править метки во фронтовых шаблонах - без системы это не дает ничего, забывается сразу, как прекращаешь это делать и занимает изрядно времени. А иногда мы предлагаем это сами - потому, что нам нужен результат, а уговорить это сделать тех, кто должен - не получается.
#diversity
#women_in_tech
❤1
Про тестирование и гендерное часть три. И что со всем этим делать?
И сначала я хочу поговорить о том, что мы чувствуем.
Для меня было самым главным понять, что это не только моя проблема. Что это не я такая неправильная, что это вижу, чувствую и переживаю.
Я не видела про это выступлений на конференциях, но про это говорят в более неформальной и приватной обстановке - в барах и чатиках)
А еще мне помогли книги про социальное и работу - "Не бойся действовать" Шерил Сэндберг и Нелла Сковелла, "Хороши девочки отправляются на небеса, а плохие - куда захотят" Уте Эрхардт и "Третья волна" Элвина Тоффлера.
Когда мы начинаем про это говорить, пусть даже в узком кругу, мы получаем поддержку - с этим сталкиваются многие из нас, мы не одиноки. Я бы советовала искать и/или создавать безопасную группу, в которой вы могли бы говорить о том, что чувствуете в профессии.
Я думаю, что в нашей профессии много гендерной специфики и нам тоже нужны группы "Женщины, которые тестируют" также как и програмисткам.
Мне также помогло ходить с этим к психологу и говорить про то, что я чувствую и вижу. Про социальное и гендерное, про власть и иерархию и искать какие-то собственные выходы.
#diversity
#women_in_tech
И сначала я хочу поговорить о том, что мы чувствуем.
Для меня было самым главным понять, что это не только моя проблема. Что это не я такая неправильная, что это вижу, чувствую и переживаю.
Я не видела про это выступлений на конференциях, но про это говорят в более неформальной и приватной обстановке - в барах и чатиках)
А еще мне помогли книги про социальное и работу - "Не бойся действовать" Шерил Сэндберг и Нелла Сковелла, "Хороши девочки отправляются на небеса, а плохие - куда захотят" Уте Эрхардт и "Третья волна" Элвина Тоффлера.
Когда мы начинаем про это говорить, пусть даже в узком кругу, мы получаем поддержку - с этим сталкиваются многие из нас, мы не одиноки. Я бы советовала искать и/или создавать безопасную группу, в которой вы могли бы говорить о том, что чувствуете в профессии.
Я думаю, что в нашей профессии много гендерной специфики и нам тоже нужны группы "Женщины, которые тестируют" также как и програмисткам.
Мне также помогло ходить с этим к психологу и говорить про то, что я чувствую и вижу. Про социальное и гендерное, про власть и иерархию и искать какие-то собственные выходы.
#diversity
#women_in_tech
❤1
Про тестирование и гендерное, часть четыре.
Я думаю, что очень важно выбирать свои битвы.
С одной стороны сложно молчать и улыбаться, когда про тестирование говорят чушь. Или когда про тестирование говорят только в контексте автоматизированого или не упоминают вообще. И чем больше мы высказываем свою позицию, тем больше шансов, что нас услышат. Что мы выйдем из глубокой оппозиции и разговоров по чатам.
И начинать говорить бывает ужасно страшно. Ну по крайней мере мне было (да есть, временами). Потому, что это во многом перестать быть милой, внимательной и ответственной.
С другой стороны есть такая штука, как активисткое выгорание. Потому, что надоедает каждый раз объяснять с нуля, что такое тестирование и почему вот то, о чем вы говорите - это не оно. И каждый разговор начинать с того, что вы выясняете термины и понятия.
И тут стоит выбирать - где и как мы хотим говорить, сколько сейчас сил, насколько безопасная среда и насколько мы можем рисковать, говоря сильно необщепринятые вещи.
#diversity
#women_in_tech
Я думаю, что очень важно выбирать свои битвы.
С одной стороны сложно молчать и улыбаться, когда про тестирование говорят чушь. Или когда про тестирование говорят только в контексте автоматизированого или не упоминают вообще. И чем больше мы высказываем свою позицию, тем больше шансов, что нас услышат. Что мы выйдем из глубокой оппозиции и разговоров по чатам.
И начинать говорить бывает ужасно страшно. Ну по крайней мере мне было (да есть, временами). Потому, что это во многом перестать быть милой, внимательной и ответственной.
С другой стороны есть такая штука, как активисткое выгорание. Потому, что надоедает каждый раз объяснять с нуля, что такое тестирование и почему вот то, о чем вы говорите - это не оно. И каждый разговор начинать с того, что вы выясняете термины и понятия.
И тут стоит выбирать - где и как мы хотим говорить, сколько сейчас сил, насколько безопасная среда и насколько мы можем рисковать, говоря сильно необщепринятые вещи.
#diversity
#women_in_tech
Про тестирование и гендерное, часть пять
Еще одна сложная штука - это предъявлять то, что ты сделала или придумала. Делать это видимым. На работе, в отличие от института или школы, нет явных параметров, по которым тебя оценивают. И если ты что-то делаешь и молчишь, это все эти люди вокруг скорее всего этого не заметят.
Это тяжело, потому что многих из нас всю дорогу учили, что надо просто хорошо делать своё дело и стараться. Но этого оказывается, к сожалению, мало. Да, и тут против нас тоже действуют гендерные стереопиты - нас меньше слушают и слышат, чаще перебивают и нам сложнее говорить о своём.
Часто решения о том, как тебе развиваться дальше или что должны делать тестировщицы принимают люди, которые либо никогда не тестировали, либо тестировали давно и недолго. Нередко в тим-лиды и тест-лиды вырастают как раз тестировщики-автоматизаторы.
И если мы не будем говорить о том, как на самом деле обстоят дела - наш голос не будет услышан. И мы столкнемся уже с тем, что мы уже _должны_ делать. В последние несколько раз я выбирала работу по тому, насколько моё мировоззрение совпадает с мировоззрением моего/моей тимлида. И это сильно другое качество работы)
Кажется, что все мои рекомендации можно свести к следующему:
- собирать группу поддержки и все то, что дает ресурсы
- показывать свои мысли, идеи и результаты
- говорить о том, что думаешь и что тебе важно.
И первый пункт тут ключевой.
#diversity
#women_in_tech
Еще одна сложная штука - это предъявлять то, что ты сделала или придумала. Делать это видимым. На работе, в отличие от института или школы, нет явных параметров, по которым тебя оценивают. И если ты что-то делаешь и молчишь, это все эти люди вокруг скорее всего этого не заметят.
Это тяжело, потому что многих из нас всю дорогу учили, что надо просто хорошо делать своё дело и стараться. Но этого оказывается, к сожалению, мало. Да, и тут против нас тоже действуют гендерные стереопиты - нас меньше слушают и слышат, чаще перебивают и нам сложнее говорить о своём.
Часто решения о том, как тебе развиваться дальше или что должны делать тестировщицы принимают люди, которые либо никогда не тестировали, либо тестировали давно и недолго. Нередко в тим-лиды и тест-лиды вырастают как раз тестировщики-автоматизаторы.
И если мы не будем говорить о том, как на самом деле обстоят дела - наш голос не будет услышан. И мы столкнемся уже с тем, что мы уже _должны_ делать. В последние несколько раз я выбирала работу по тому, насколько моё мировоззрение совпадает с мировоззрением моего/моей тимлида. И это сильно другое качество работы)
Кажется, что все мои рекомендации можно свести к следующему:
- собирать группу поддержки и все то, что дает ресурсы
- показывать свои мысли, идеи и результаты
- говорить о том, что думаешь и что тебе важно.
И первый пункт тут ключевой.
#diversity
#women_in_tech
И P.S.
Все эти активности - это когда вам не хватает признания, гордости за свою работу, видимости и карьеры.
Если у вас небезопасная среда и вы никуда не можете из нее сейчас деться. Если у вас нет подушки безопасности и нет уверенности, что вы быстро найдете работу. Если у вас на руках люди и звери, которые от вас и вашей зарплаты критично зависят. Если у вас стоит задача выжить - затаиться и просто делать то, что скажут - годная, правильная идея.
Выживание очень плохо совмещается с развитием.
#diversity
#women_in_tech
Все эти активности - это когда вам не хватает признания, гордости за свою работу, видимости и карьеры.
Если у вас небезопасная среда и вы никуда не можете из нее сейчас деться. Если у вас нет подушки безопасности и нет уверенности, что вы быстро найдете работу. Если у вас на руках люди и звери, которые от вас и вашей зарплаты критично зависят. Если у вас стоит задача выжить - затаиться и просто делать то, что скажут - годная, правильная идея.
Выживание очень плохо совмещается с развитием.
#diversity
#women_in_tech
И еще кусок про социальное и тестирование.
Меня бесит, когда ко мне приходят с карьерными советами без моего запроса. Когда люди, которые даже не тестировщики начинают рассказывать мне, куда мне надо стремиться и чем заниматься - автотестированием, за ним будущее. Или идти в управление. Или еще что-то делать, что им кажется правильным. При этом люди мало что знают о тестировании, моей работе и мне.
И это ведь происходит сплошь и рядом. Когда ты говоришь, что ты тестировшица - многие люди из IT пытаются высказать своё ценное мнение.
При этом есть бережная обратная связь, от людей которые меня знают. Они говорят мне, что у меня хорошо выходит вот это или вон то и возможно мне интересно будет идти в том направлении? И я это слышу совсем иначе и благодарна за это.
#подпольный_евангелизм
Меня бесит, когда ко мне приходят с карьерными советами без моего запроса. Когда люди, которые даже не тестировщики начинают рассказывать мне, куда мне надо стремиться и чем заниматься - автотестированием, за ним будущее. Или идти в управление. Или еще что-то делать, что им кажется правильным. При этом люди мало что знают о тестировании, моей работе и мне.
И это ведь происходит сплошь и рядом. Когда ты говоришь, что ты тестировшица - многие люди из IT пытаются высказать своё ценное мнение.
При этом есть бережная обратная связь, от людей которые меня знают. Они говорят мне, что у меня хорошо выходит вот это или вон то и возможно мне интересно будет идти в том направлении? И я это слышу совсем иначе и благодарна за это.
#подпольный_евангелизм
Ещё пример про кодоцентричность IT.
Forwarded from Product channel fit Ӏ Камилла Самохина
Канал молчал, потому что было очень напряженное предрелизное время. Зато теперь в приложении iOS одного желто-черного банка можно купить билеты на концерты и спектакли, что и советую вам сделать. А пока хочу вернуться и с вопросом:
Должен ли аналитик уметь кодить, если ему не нужно это по работе?
Недавно с коллегой спорили, должен ли аналитик уметь писать код. Не трогаем вариант, когда это входит в обязанности аналитика (скрипты какие-нибудь там для обработки данных писать и т.п), здесь вопросов нет. Но, если не входит, то мнения делятся: кто-то считает, что без умения писать код аналитик не поймет разработчика, кто-то считает, что это лишнее.
Я обычно говорю так: умение писать код и знание основ программирования обычно является признаком, что человек умеет логически мыслить и понимает IT-специфику. Но здесь нередко случаются перекосы, когда аналитик начинает указывать разработчику, что ему сделать и иногда (где-то компании такое позволяют) порывается написать код за него. Или начинает писать ТЗ так, что оно понятно только разработчикам, но никому из коллег. Или получает доступ к коду, начинает сам в нем копаться и искать ответы на вопросы, что обычно приводит к огромным ошибкам а-ля "я посмотрел, тут вот так реализовано", что используется для дальнейших постановок задач, и запускает долгую цепочку ошибок.
В общем, считаю, что уметь кодить совсем не обязательно, но, если ты уж это умеешь, нужно уметь вовремя себя остановить и оставить работу с кодом людям, у которых это основная обязанность. И мне смешно и грустно за компании, которые в вакансиях пишут "уверенное знание С++, PHP, Scala" и на вопрос "зачем?" отвечают "чтобы понимать разработчиков лучше".
Вы как думаете?
✅согласен с постом
⛔️ должен уметь кодить, даже если ему это не нужно в работе
Должен ли аналитик уметь кодить, если ему не нужно это по работе?
Недавно с коллегой спорили, должен ли аналитик уметь писать код. Не трогаем вариант, когда это входит в обязанности аналитика (скрипты какие-нибудь там для обработки данных писать и т.п), здесь вопросов нет. Но, если не входит, то мнения делятся: кто-то считает, что без умения писать код аналитик не поймет разработчика, кто-то считает, что это лишнее.
Я обычно говорю так: умение писать код и знание основ программирования обычно является признаком, что человек умеет логически мыслить и понимает IT-специфику. Но здесь нередко случаются перекосы, когда аналитик начинает указывать разработчику, что ему сделать и иногда (где-то компании такое позволяют) порывается написать код за него. Или начинает писать ТЗ так, что оно понятно только разработчикам, но никому из коллег. Или получает доступ к коду, начинает сам в нем копаться и искать ответы на вопросы, что обычно приводит к огромным ошибкам а-ля "я посмотрел, тут вот так реализовано", что используется для дальнейших постановок задач, и запускает долгую цепочку ошибок.
В общем, считаю, что уметь кодить совсем не обязательно, но, если ты уж это умеешь, нужно уметь вовремя себя остановить и оставить работу с кодом людям, у которых это основная обязанность. И мне смешно и грустно за компании, которые в вакансиях пишут "уверенное знание С++, PHP, Scala" и на вопрос "зачем?" отвечают "чтобы понимать разработчиков лучше".
Вы как думаете?
✅согласен с постом
⛔️ должен уметь кодить, даже если ему это не нужно в работе
Я несколько раз тестировала в паре, чтобы ввести человека в новый проект. Сначала я вела пару сессий, объясняя что я делаю и откуда все взялось. Потом пару сессия была в качестве штурмана. Это был интересный опыт и я думаю, что он помог.
#заметки_с_полей
#заметки_с_полей
Forwarded from QA Календарь
А вы тестировали в паре? В статье ноября две Оли рассказывают о задачах, которые им помогает решить эта практика, и приводят пример её неудачного использования. Приятного прочтения :)
https://habr.com/company/skbkontur/blog/431460/
https://habr.com/company/skbkontur/blog/431460/
Хабр
«Календарь тестировщика» за ноябрь. Разумное парное тестирование
Авторами ноябрьского «Календаря тестировщика» стали Оля Фазулзянова, тестировщик Контур.Экстерна, и Оля Изюрьева, тестировщик Контур.Биллинга и организатор курса...
Полезная мнемоника от Джеймса Баха в переводе Ольги Назиной - http://okiseleva.blogspot.com/2018/11/sfpdo-san-francisco-depot-james-bach.html
#база_тестирования
#база_тестирования
Blogspot
SFPDO (San Francisco Depot) — мнемоника от James Bach
Оригинал статьи — http://www.satisfice.com/articles/sfdpo.shtml . Сразу оговорюсь, что не ставила себе цели точного перевода всей статьи...
http://wolonter.blogspot.com/2018/11/edi.html
Мне очень отзывается то, о чем пишет Макс. Все люди рано или поздно уходят из команды - и как сделать так, чтобы это не стало большой проблемой для команды. И как сохранить отношения с людьми.
#менеджерское
Мне очень отзывается то, о чем пишет Макс. Все люди рано или поздно уходят из команды - и как сделать так, чтобы это не стало большой проблемой для команды. И как сохранить отношения с людьми.
#менеджерское
Blogspot
Когда и как нужно уходить из команды
Блог о тестировании вообще и обо мне в частности. Хроники тестировщика.
Видела вчера вариант шутки "QA Engineer walks into a bar. Orders a beer. Orders 0 beers..."
QA Engineer walks into a bar. Orders a beer. Orders 0 beers. Orders 999999999 beers. Orders a lizard. Orders -1 beers. Orders a ueicbksjdhd.
First real customer walks in and asks where the bathroom is. The bar bursts into flames, killing everyone.
И если первая еще более-менее смешная и описывает одну из техних тест-анализа, то эта уже нет. Она сводит работу тестировщика только к поиску багов, в то время как реальные пользователи ведут себя по-разному.
На самом деле мы как тестировщики обычно начинаем с того, как пользователи будут применять наш продукт.
Я бы перефразировала этот анекдот на русском так.
Тестировщица заходит в бар. Заказывает 1 кружку пива. Заказывает 1 кружку безалкогольного пива. Заказывает 1 бутылку воды. Заказывает 1 стакан чая. Заказывает 1 стакан кофе. Заказывает еду здесь. Заказывает еду на вынос. Спрашивает, где находится туалет. Просит сделать музыку тише. Спрашивает бармена "за жизнь".
#подпольный_евангелизм
QA Engineer walks into a bar. Orders a beer. Orders 0 beers. Orders 999999999 beers. Orders a lizard. Orders -1 beers. Orders a ueicbksjdhd.
First real customer walks in and asks where the bathroom is. The bar bursts into flames, killing everyone.
И если первая еще более-менее смешная и описывает одну из техних тест-анализа, то эта уже нет. Она сводит работу тестировщика только к поиску багов, в то время как реальные пользователи ведут себя по-разному.
На самом деле мы как тестировщики обычно начинаем с того, как пользователи будут применять наш продукт.
Я бы перефразировала этот анекдот на русском так.
Тестировщица заходит в бар. Заказывает 1 кружку пива. Заказывает 1 кружку безалкогольного пива. Заказывает 1 бутылку воды. Заказывает 1 стакан чая. Заказывает 1 стакан кофе. Заказывает еду здесь. Заказывает еду на вынос. Спрашивает, где находится туалет. Просит сделать музыку тише. Спрашивает бармена "за жизнь".
#подпольный_евангелизм
Читатели дополняют, что надо еще добавить "соблазняет бармена", "напивается", "громит кабак" и "выходит из бара" )
#подпольный_евангелизм
#подпольный_евангелизм
И еще добавляют - "Для бара еще не помешает проверить "хватает денег заплатить", "не хватает денег" и оплату картой/наличкой". Сейчас мы коллективно составим идеальный сценарий проверки бара)
Я тут думаю, что я бы еще проверила оплату мобильными приложениями)
#подпольный_евангелизм
Я тут думаю, что я бы еще проверила оплату мобильными приложениями)
#подпольный_евангелизм
Про просьбы о помощи со стороны подчиненных и доверие -
https://m.facebook.com/story.php?story_fbid=2170115179719577&id=100001633472623
#менеджерское
https://m.facebook.com/story.php?story_fbid=2170115179719577&id=100001633472623
#менеджерское
Facebook
Log in to Facebook
Log in to Facebook to start sharing and connecting with your friends, family and people you know.
Forwarded from Вычитала
Я на выходных дочитала книжку про прекариат, к которой присматривалась уже давно.
Более-менее разобралась, что это за прекариат такой, и могу вкратце пересказать/процитировать, потому что это интересная современная штука.
Если коротко и по-простому, то прекариат — это социальный класс, который не считает себя социальным классом. Потому что он разнородный.
Это люди, которые вынуждены хвататься за разовые, внештатные, случайные заработки, лишенные социальных гарантий, карьерных возможностей, связей и профессиональных горизонтов по самым разным причинам.
Кто-то вылетает в прекариат, потому что после определенного возраста устроиться по специальности уже не выходит (не берут) — и начинаются случайные заработки "посидеть с ребенком соседки", "подменить подругу на смену", гардеробщиками, уборщиками, охранниками. Кто-то вышел из тюрьмы и понял, что достаточно много путей закрыто и как будто бы даже гораздо проще пребывать в серой зоне, чем пытаться доказать, что ты не верблюд.
Кто-то переехал в другую страну и готов браться за что угодно, ведь разрешение на работу трудно получить, а образование, полученное в другой стране, еще труднее подтвердить («Американха» моей любимой Чимаманды как раз об этом).
Кто-то ищет подработку на несколько часов в день (подросток, одинокий родитель), но в ужасе от того, что может ее потерять — берет ещё одну для страховки, а так и третью, в итоге работает полный день, но не получает никаких гарантий, которые салариату (людям на зарплате в штате) достаются за такой же объем работы (или меньший).
А кто-то и хотел бы работать полный день, но компании выгодно держать людей на почасовой ставке, не добирая до штатного минимума один час в месяц (в No logo Наоми Кляйн так описывает политику Старбакса), чтобы не давать социальных гарантий и не обеспечивать постоянную занятость.
Сомнительные свободные экономические зоны в «Киндии» (Китае, Индии и других странах, куда утекает дешевое производство) тоже стоят на местном прекариате.
Прекариат интересен тем, кто каждый из нас может в него угодить, стоит только оступиться — и тем, что в планетарных масштабах он только растет, это интересное и страшное мировое явление. Компаниям выгодно брать внештатных и временных сотрудников. Экономике выгодно, чтобы компании были мобильнее. А у людей часто нет другого выбора.
Более-менее разобралась, что это за прекариат такой, и могу вкратце пересказать/процитировать, потому что это интересная современная штука.
Если коротко и по-простому, то прекариат — это социальный класс, который не считает себя социальным классом. Потому что он разнородный.
Это люди, которые вынуждены хвататься за разовые, внештатные, случайные заработки, лишенные социальных гарантий, карьерных возможностей, связей и профессиональных горизонтов по самым разным причинам.
Кто-то вылетает в прекариат, потому что после определенного возраста устроиться по специальности уже не выходит (не берут) — и начинаются случайные заработки "посидеть с ребенком соседки", "подменить подругу на смену", гардеробщиками, уборщиками, охранниками. Кто-то вышел из тюрьмы и понял, что достаточно много путей закрыто и как будто бы даже гораздо проще пребывать в серой зоне, чем пытаться доказать, что ты не верблюд.
Кто-то переехал в другую страну и готов браться за что угодно, ведь разрешение на работу трудно получить, а образование, полученное в другой стране, еще труднее подтвердить («Американха» моей любимой Чимаманды как раз об этом).
Кто-то ищет подработку на несколько часов в день (подросток, одинокий родитель), но в ужасе от того, что может ее потерять — берет ещё одну для страховки, а так и третью, в итоге работает полный день, но не получает никаких гарантий, которые салариату (людям на зарплате в штате) достаются за такой же объем работы (или меньший).
А кто-то и хотел бы работать полный день, но компании выгодно держать людей на почасовой ставке, не добирая до штатного минимума один час в месяц (в No logo Наоми Кляйн так описывает политику Старбакса), чтобы не давать социальных гарантий и не обеспечивать постоянную занятость.
Сомнительные свободные экономические зоны в «Киндии» (Китае, Индии и других странах, куда утекает дешевое производство) тоже стоят на местном прекариате.
Прекариат интересен тем, кто каждый из нас может в него угодить, стоит только оступиться — и тем, что в планетарных масштабах он только растет, это интересное и страшное мировое явление. Компаниям выгодно брать внештатных и временных сотрудников. Экономике выгодно, чтобы компании были мобильнее. А у людей часто нет другого выбора.
Тоже читаю сейчас "Прекариат" и думаю про интерсекциональность в IT.
В нашей работе есть множество линеек - по гендеру, по возрасту, по количеству и сложности кода, по формальной иерархии, по стабильности рабочего места, зарплаты и профессиональной идентичности. И где-то у нас привелегии, а где-то нас меньше видят и дают меньше возможностей.
Так я - белая русская женщина-тестировщица 30+ лет. Работаю на бессрочном контракте с полностью белой зарплатой, с оплачиваемыми отпусками, больничными и перспективами пенсии, с оплатой ДМС компанией. Мне сложнее в том, что я женщина и тестировщица, но существенно проще с белой зарплатой и гарантиями от компании.
У мужчины-программиста с черной зарплатой будет больше привелегий по линии кодоцентричности и гендера, но меньше защищенности и социальных гарантий из-за чёрной зарплаты.
И получается такое лоскутное одеяло. Где-то больше, где-то меньше.
#книги
#подпольный_евангелизм
В нашей работе есть множество линеек - по гендеру, по возрасту, по количеству и сложности кода, по формальной иерархии, по стабильности рабочего места, зарплаты и профессиональной идентичности. И где-то у нас привелегии, а где-то нас меньше видят и дают меньше возможностей.
Так я - белая русская женщина-тестировщица 30+ лет. Работаю на бессрочном контракте с полностью белой зарплатой, с оплачиваемыми отпусками, больничными и перспективами пенсии, с оплатой ДМС компанией. Мне сложнее в том, что я женщина и тестировщица, но существенно проще с белой зарплатой и гарантиями от компании.
У мужчины-программиста с черной зарплатой будет больше привелегий по линии кодоцентричности и гендера, но меньше защищенности и социальных гарантий из-за чёрной зарплаты.
И получается такое лоскутное одеяло. Где-то больше, где-то меньше.
#книги
#подпольный_евангелизм
Forwarded from Уютный IT адочек
Вообще говоря, я несколько обескуражен результатами опроса и в то же время их, отчасти, понимаю.
А обескуражен из-за хайпа вокруг ускорения релизов.
Ускорение релизов — это прекрасно, важно и полезно. Но это ни в коем случае не может быть единственной целью улучшений продуктовой команды.
Те, кто стремятся ускориться ради ускорения — теряют суть.
Целью продуктовой работы могут являются хорошие, продуманные гипотезы. Фигачить быстро рандомные, недодуманные вещи не может быть стратегией развития. Ошибки согласованности изменения могут загубить прекрасную гипотезу.
Глубоко думать и уметь работать профессионально на мой вкус капец как важно. Важнее загрузки производства, важнее частоты релизов, важнее хайпа.
Я очень хочу верить, что все интересующиеся ускорением релизов разделяют эти ценности.
А обескуражен из-за хайпа вокруг ускорения релизов.
Ускорение релизов — это прекрасно, важно и полезно. Но это ни в коем случае не может быть единственной целью улучшений продуктовой команды.
Те, кто стремятся ускориться ради ускорения — теряют суть.
Целью продуктовой работы могут являются хорошие, продуманные гипотезы. Фигачить быстро рандомные, недодуманные вещи не может быть стратегией развития. Ошибки согласованности изменения могут загубить прекрасную гипотезу.
Глубоко думать и уметь работать профессионально на мой вкус капец как важно. Важнее загрузки производства, важнее частоты релизов, важнее хайпа.
Я очень хочу верить, что все интересующиеся ускорением релизов разделяют эти ценности.