ТЕСТЕР ПРОТИВ ВСЕХ. PRODUCT DESIGNER. ВЫПУСК#3
Продолжаю серию блиц-интервью, чтобы собрать обратную связь опытных спецов IT о работе тестировщиков и помочь нам:
- сопоставить обязанности QA ожиданиям участников проектной команды,
- скорректировать нашу работу или разрушить бытующие стереотипы,
- лучше понять, чем занимаются коллеги в IT на других позициях.
Сегодня обратимся к опыту Product designer. Этап создания дизайнов интерфейса (UI) и взаимодействия продукта (UX) предполагается в процессе разработки современного приложения. Эту деятельность можно считать базой. Выбор дизайнера задает характер продукту и тем самым формирует отношение пользователей к нему.
Программы делаются людьми для людей. И когда игнорируется этот факт, не учитывается человеческая природа, а дизайн основывается только на вау-эффекте, пользователям трудно. Работая с красивым, но сложным приложением, человек испытывает дискомфорт (т.н. когнитивное сопротивление) и не может ответить продукту лояльностью.
Потому работа дизайнера – это креатив и безграничный простор для творчества. Но это также и скрупулезный труд, требующий настойчивости, системного мышления и широкого кругозора. А еще постоянного развития, поскольку тенденции и стандарты отрасли постоянно меняются.
Моим собеседником станет Head of Design компании Solvd Андрей Ридванский. Помимо заоблачного профессионализма, мне нравятся человеческие качества Андрея: честность, отзывчивость, трудоспособность, уверенность в себе - равно как уважение к другим участникам команды.
Кратко, чем ты занимаешься в IT?
Я занимаюсь дизайном и проектированием взаимодействия клиентов с продуктом. От качества моей работы во многом завит успех проекта. Ведь, прежде всего, пользователи оценивают сервис по удобству пользования его функциями.
Кто для тебя тестировщик?
На проекте он страховка от ошибок, безделья и в какой-то мере непрофессионализма. Когда он работает хорошо, я уверен в корректности реализации элементов дизайна командой.
3 софт / хард скилла, которые важны тестеру по твоему мнению?
Терпение и адекватность. Ведь ошибки встречаются не только из-за обстоятельств бизнеса или рынка, но и по глупости.
Самый главный грех тестировщика?
Быть роботом, который воспринимает все буквально и не подвергает увиденное сомнению.
Бывали ли случай из жизни с тестером, который ты запомнишь?
Когда тестер хорош в своем деле, то я запоминаю его как нужного человека на проекте.
Продолжаю серию блиц-интервью, чтобы собрать обратную связь опытных спецов IT о работе тестировщиков и помочь нам:
- сопоставить обязанности QA ожиданиям участников проектной команды,
- скорректировать нашу работу или разрушить бытующие стереотипы,
- лучше понять, чем занимаются коллеги в IT на других позициях.
Сегодня обратимся к опыту Product designer. Этап создания дизайнов интерфейса (UI) и взаимодействия продукта (UX) предполагается в процессе разработки современного приложения. Эту деятельность можно считать базой. Выбор дизайнера задает характер продукту и тем самым формирует отношение пользователей к нему.
Программы делаются людьми для людей. И когда игнорируется этот факт, не учитывается человеческая природа, а дизайн основывается только на вау-эффекте, пользователям трудно. Работая с красивым, но сложным приложением, человек испытывает дискомфорт (т.н. когнитивное сопротивление) и не может ответить продукту лояльностью.
Потому работа дизайнера – это креатив и безграничный простор для творчества. Но это также и скрупулезный труд, требующий настойчивости, системного мышления и широкого кругозора. А еще постоянного развития, поскольку тенденции и стандарты отрасли постоянно меняются.
Моим собеседником станет Head of Design компании Solvd Андрей Ридванский. Помимо заоблачного профессионализма, мне нравятся человеческие качества Андрея: честность, отзывчивость, трудоспособность, уверенность в себе - равно как уважение к другим участникам команды.
Кратко, чем ты занимаешься в IT?
Я занимаюсь дизайном и проектированием взаимодействия клиентов с продуктом. От качества моей работы во многом завит успех проекта. Ведь, прежде всего, пользователи оценивают сервис по удобству пользования его функциями.
Кто для тебя тестировщик?
На проекте он страховка от ошибок, безделья и в какой-то мере непрофессионализма. Когда он работает хорошо, я уверен в корректности реализации элементов дизайна командой.
3 софт / хард скилла, которые важны тестеру по твоему мнению?
Терпение и адекватность. Ведь ошибки встречаются не только из-за обстоятельств бизнеса или рынка, но и по глупости.
Самый главный грех тестировщика?
Быть роботом, который воспринимает все буквально и не подвергает увиденное сомнению.
Бывали ли случай из жизни с тестером, который ты запомнишь?
Когда тестер хорош в своем деле, то я запоминаю его как нужного человека на проекте.
5 СОВЕТОВ О ТОМ, КАК СОСТАВИТЬ РЕЗЮМЕ
Актуальной темой является составление резюме. В данной статье, проанализировав совместно с qa_career_up варианты CV коллег, делимся обратной связью.
С чего начать?
Стоит определить свои приоритеты, сильные стороны и интересы. Иначе есть риск пойти по пути Алисы из Страны чудес:
- Скажите, пожалуйста, куда мне отсюда идти? — спросила Алиса.
- А куда ты хочешь попасть? — ответил Кот.
- Мне все равно.
- Тогда все равно, куда и идти.
- Только бы попасть куда-нибудь.
- Куда-нибудь обязательно попадешь. Нужно только достаточно долго идти.
Речь о том, чтобы найти компании, в которых хотелось бы работать. А затем настойчиво идти к цели.
Идеальное резюме
Резюме содержит краткую и уместную информацию об опыте, но не бывает универсальным. Причина в том, что вакантные позиции создаются для решения определенных бизнес-задач проекта, а они уникальны (исходя из определения проекта).
Поэтому опыт может быть релевантным в одном месте, а в другом – нет. Лучше составлять отдельное резюме для каждой вакансии.
Помните о механизме найма сотрудников
Он представляет собой поэтапный процесс. Например, на проекте есть вакантное место. Менеджер составляет список требований к соискателям и делегирует проведение конкурсного отбора отделу кадров. Кадровики затем предоставляют кандидатуры менеджеру, и он принимает итоговое решение.
Из этого следует, что наш изначальный клиент – это рекрутеры. И чтобы пройти на следующий этап собеседования, нужно соответствовать указанным требованиям и правильно донести эту информацию, а именно:
1. Не ломать формат заявок, усложняя работу рекрутерам
Лучше отвечать по существу: с какими технологиями, инструментами работали и чем конкретно занимались (типы тестирования, виды приложений). Маловероятно, что HR заинтересует оригинальность подхода, если это не пункт из требований.
К примеру, в вакансии указано:
👎 Работал на Java, пишу репорты. Еще писал тесты на питоне. Несколько раз выступал на конференции.
👍 Разрабатывал тестовую документацию: тест-план, тест-кейсы, чек-листы. Работал с JIRA, VMWare Workstation.
2. Предоставлять факты, а не абстрактные формулировки
Указывая достижения, будьте конкретными. Вместо «качественно обучал несколько специалистов», лучше указать «обучил 10 тестировщиков, 5 из них получили работу на реальных проектах».
👎 “Имею опыт в тестировании сложных систем (интеграция велосипеда, синтезатора “Ямаха” и Боинг-737)”
👍 «Работал на проекте e-commerce: ритейл система с интеграцией с Salesforce, Musesoft, системой доставки …»
👎 «Умею качественно учить, развивать членов команды»
👍 «Обучила 10 интернов, из них вырастила 3 синьора у себя в команде»
👎 «Работал год лидом. Настойчив в достижении целей и выполнении задач. Умею работать в команде. Целеустремленный и стремлюсь повышать профессиональную компетентность.»
👍 «Работал лидом в команде из 4 человек, руководил процессом распределения задач, написанием документацией, отчетностью перед клиентом (демо и репорты), ...»
3. Указывать навыки, подходящие для конкретной должности
Стоит указать опыт, релевантный требованиям вакансии. Если спрашивают об определенных навыках и технологиях, то пишите о них с фокусом на ваши результаты и достижения.
👎 «Работал бариста в универе. Учился в аспирантуре барабаностроительного факультета и получил докторскую (колбасу)»
👍
«Автоматизация: Java, писал и поддерживал web-тесты, работал с TestNG, Maven, …
SQL: пишу скрипты, умело отличаю LEFT JOIN от INNER JOIN, …
Документация: создавал Test strategy, Test Plan (Google sheets, Confluence), …»
Актуальной темой является составление резюме. В данной статье, проанализировав совместно с qa_career_up варианты CV коллег, делимся обратной связью.
С чего начать?
Стоит определить свои приоритеты, сильные стороны и интересы. Иначе есть риск пойти по пути Алисы из Страны чудес:
- Скажите, пожалуйста, куда мне отсюда идти? — спросила Алиса.
- А куда ты хочешь попасть? — ответил Кот.
- Мне все равно.
- Тогда все равно, куда и идти.
- Только бы попасть куда-нибудь.
- Куда-нибудь обязательно попадешь. Нужно только достаточно долго идти.
Речь о том, чтобы найти компании, в которых хотелось бы работать. А затем настойчиво идти к цели.
Идеальное резюме
Резюме содержит краткую и уместную информацию об опыте, но не бывает универсальным. Причина в том, что вакантные позиции создаются для решения определенных бизнес-задач проекта, а они уникальны (исходя из определения проекта).
Поэтому опыт может быть релевантным в одном месте, а в другом – нет. Лучше составлять отдельное резюме для каждой вакансии.
Помните о механизме найма сотрудников
Он представляет собой поэтапный процесс. Например, на проекте есть вакантное место. Менеджер составляет список требований к соискателям и делегирует проведение конкурсного отбора отделу кадров. Кадровики затем предоставляют кандидатуры менеджеру, и он принимает итоговое решение.
Из этого следует, что наш изначальный клиент – это рекрутеры. И чтобы пройти на следующий этап собеседования, нужно соответствовать указанным требованиям и правильно донести эту информацию, а именно:
1. Не ломать формат заявок, усложняя работу рекрутерам
Лучше отвечать по существу: с какими технологиями, инструментами работали и чем конкретно занимались (типы тестирования, виды приложений). Маловероятно, что HR заинтересует оригинальность подхода, если это не пункт из требований.
К примеру, в вакансии указано:
- Опыт разработки тестовой документации: тест-планов, тест-кейсов, чек-листов;.
- Опыт работы с JIRA и виртуальными машинами (VMWare Workstation)
👎 Работал на Java, пишу репорты. Еще писал тесты на питоне. Несколько раз выступал на конференции.
👍 Разрабатывал тестовую документацию: тест-план, тест-кейсы, чек-листы. Работал с JIRA, VMWare Workstation.
2. Предоставлять факты, а не абстрактные формулировки
Указывая достижения, будьте конкретными. Вместо «качественно обучал несколько специалистов», лучше указать «обучил 10 тестировщиков, 5 из них получили работу на реальных проектах».
👎 “Имею опыт в тестировании сложных систем (интеграция велосипеда, синтезатора “Ямаха” и Боинг-737)”
👍 «Работал на проекте e-commerce: ритейл система с интеграцией с Salesforce, Musesoft, системой доставки …»
👎 «Умею качественно учить, развивать членов команды»
👍 «Обучила 10 интернов, из них вырастила 3 синьора у себя в команде»
👎 «Работал год лидом. Настойчив в достижении целей и выполнении задач. Умею работать в команде. Целеустремленный и стремлюсь повышать профессиональную компетентность.»
👍 «Работал лидом в команде из 4 человек, руководил процессом распределения задач, написанием документацией, отчетностью перед клиентом (демо и репорты), ...»
3. Указывать навыки, подходящие для конкретной должности
Стоит указать опыт, релевантный требованиям вакансии. Если спрашивают об определенных навыках и технологиях, то пишите о них с фокусом на ваши результаты и достижения.
👎 «Работал бариста в универе. Учился в аспирантуре барабаностроительного факультета и получил докторскую (колбасу)»
👍
«Автоматизация: Java, писал и поддерживал web-тесты, работал с TestNG, Maven, …
SQL: пишу скрипты, умело отличаю LEFT JOIN от INNER JOIN, …
Документация: создавал Test strategy, Test Plan (Google sheets, Confluence), …»
4. Быть кратким
Резюме не подходит для детального описания достижений или тернистого жизненного пути. Выделите главное на одной странице: несколько ключевых навыков, в чем сильны, чем гордитесь и укажите метрики. Остальное можете добавить в LinkedIn и оставить ссылку в резюме. Заинтересованный человек сможет ознакомиться с деталями в случае необходимости.
👎
«Свой жизненный путь на этой грешной Земле автор этих строк начал в далеком 1991-м. Да, тогда еще компьютеры были редкостью. Представьте себе! Словно Билл Гейтс я искал возможность работать с ними. Помню, как пропадал в компьютерном клубах. На меня ругался папа и бил ремнем. Вот поэтому я и полюбил С++ ….»
👍
«Учился: факультет электроники Кембриджа (2011-2015), курсы тестирования IT-magician (2015-2017) ... ;
Работал: компания “Альбатрос”, ведущий тестер, делал … ;
Хобби: лыжи, санки и каное ….»
5. Быть доброжелательны
Рекрутер, как и любой специалист, может не знать особенностей некоторых технологий. Относитесь с пониманием к недостаточно яркой реакции на ваши регалии или просьбу сделать тестовые задания. Последнее отчасти проверка soft skills: адекватности, умения общаться с незнакомыми людьми и реагировать на нестандартные ситуации.
А еще будьте в себе уверены: не преуменьшайте свой опыт использованием кавычек или эпитетов с негативным оттенком.
👎 «Я не буду выполнять тестовое задание, поцелуйте меня в…»
👍 «У меня трудно со свободным временем, мы можем рассмотреть альтернативный вариант с тестовым заданием?»
👎 «Вообще я был лидом, ну как лидом, ну таким, «номинальным»
👍 «Я имел опыт руководства командой, за год я сумел вывести команду из кризиса и сдать проект»
👎 «Английский у меня такой-сякой. Нет, ну могу нормально общаться, но надо еще учить»
👍 «Уровень английского B2: веду переписку, задания, могу презентовал работу для заказчика на демо»
Вывод
Адаптируйте резюме, ориентируясь на требования в вакансии. Пишите кратко и ясно и будьте дружелюбны - и у вас появится больше шансов найти работу.
Резюме не подходит для детального описания достижений или тернистого жизненного пути. Выделите главное на одной странице: несколько ключевых навыков, в чем сильны, чем гордитесь и укажите метрики. Остальное можете добавить в LinkedIn и оставить ссылку в резюме. Заинтересованный человек сможет ознакомиться с деталями в случае необходимости.
👎
«Свой жизненный путь на этой грешной Земле автор этих строк начал в далеком 1991-м. Да, тогда еще компьютеры были редкостью. Представьте себе! Словно Билл Гейтс я искал возможность работать с ними. Помню, как пропадал в компьютерном клубах. На меня ругался папа и бил ремнем. Вот поэтому я и полюбил С++ ….»
👍
«Учился: факультет электроники Кембриджа (2011-2015), курсы тестирования IT-magician (2015-2017) ... ;
Работал: компания “Альбатрос”, ведущий тестер, делал … ;
Хобби: лыжи, санки и каное ….»
5. Быть доброжелательны
Рекрутер, как и любой специалист, может не знать особенностей некоторых технологий. Относитесь с пониманием к недостаточно яркой реакции на ваши регалии или просьбу сделать тестовые задания. Последнее отчасти проверка soft skills: адекватности, умения общаться с незнакомыми людьми и реагировать на нестандартные ситуации.
А еще будьте в себе уверены: не преуменьшайте свой опыт использованием кавычек или эпитетов с негативным оттенком.
👎 «Я не буду выполнять тестовое задание, поцелуйте меня в…»
👍 «У меня трудно со свободным временем, мы можем рассмотреть альтернативный вариант с тестовым заданием?»
👎 «Вообще я был лидом, ну как лидом, ну таким, «номинальным»
👍 «Я имел опыт руководства командой, за год я сумел вывести команду из кризиса и сдать проект»
👎 «Английский у меня такой-сякой. Нет, ну могу нормально общаться, но надо еще учить»
👍 «Уровень английского B2: веду переписку, задания, могу презентовал работу для заказчика на демо»
Вывод
Адаптируйте резюме, ориентируясь на требования в вакансии. Пишите кратко и ясно и будьте дружелюбны - и у вас появится больше шансов найти работу.
ОБЗОР КНИГИ «ПСИХБОЛЬНИЦА В РУКАХ ПАЦИЕНТА» АЛЕНА КУПЕРА
Об авторе
Американский дизайнер, программист и автор книг.
Факты из жизни:
- в 1988 г. продал Биллу Гейтсу прототип визуальной среды разработки, впоследствии ставший Visual Basic;
- работал с Биллом Гейтсом на заре становления Microsoft;
- в 1995 г. создал метод целенаправленного дизайна (goal-directed design), основанный на раскрытии потребностей пользователей, понимании их индивидуальности и создании интерфейса продукта на базе этих знаний;
- изобрел концепцию проектирования с виртуальными персонажами, которые выступают олицетворением конечных пользователей приложения;
- в 2017 введен в Зал стипендиатов Музея истории компьютеров.
Источники: сайты Wikipedia, личный сайт Алана Купера
О книге
В разработке важно соблюдать баланс приоритетов. Чтобы проект не стал джангой наоборот - попыткой втиснуть в приложение новые фичи, пока оно не «упадет».
Все хотят работать над интересными задачами. Архитекторы и разработчики тяготеют к сложным техническим решениям. Дизайнеры не против внести нотки оригинальности. Тестировщики стремятся найти всевозможные дефекты.
Однако пользователи ожидают от продукта решения своей «боли» и комфорта при выполнении ежедневных задач.
Поэтому Купер призывает начинать работу с проектирования взаимодействия, чтобы удовлетворить потребности пользователей и достичь цели бизнеса.
При таком системном подходе исключаются неприоритетные задачи и значительно оптимизируется работа. Приложения создаются быстрее за счет уменьшения числа корректив и как следствие совершенных ошибок.
Рекомендую книгу тем, кто вовлечен в процесс разработки: дизайнерам, архитекторам, программистам, а также руководителям в тестировании, разработке, маркетинге и продажах.
Цитаты
Успешный профессионал XXI века - это либо инженер, разбирающийся в бизнесе, либо бизнесмен, разбирающийся в технологиях. Бизнесмен, разбирающийся в технологиях, понимает, что его успех зависит от качества доступной ему информации и его умения воспользоваться этой информацией. Инженер, разбирающийся в бизнесе, — это предприимчивый конструктор или ученый, специализирующийся на технологиях, но при этом обладающий деловой хваткой и осознающий, какая огромная сила заключена в информации. Оба новых архетипа будут доминировать в современном бизнесе.
Сложности во взаимодействии с компьютерами влияют на всех нас временами, приводя к фатальным последствиям. Но программные продукты сложны в применении не из-за сложности самих компьютеров, а потому, что в основу их разработки заложен неверный процесс. Данная книга призвана не только продемонстрировать следствия такого неверного процесса, но и прояснить причины его возникновения. Далее мы рассмотрим, как следовало бы изменить процесс, чтобы наше программное обеспечение обрело дружелюбный вид и мощный функционал.
Процесс инженерного проектирования при создании сложной системы не делает разницы между тем, будет ли ею оперировать специально нанятый профессионал или же неподготовленный новичок который на это не подписывался. Процесс инженерного проектирования не обладает представлениями, как работать с этими особенностям человеческого характера. Он концентрируется только на вопросах реализации продукта: «из чего это будет сделано?», «как это будет сделано?».
Проектирование архитектуры следует начинать на ранних стадиях инженерного планирования. Более того, именно оно должно быть движущей силой на этих стадиях.
Об авторе
Американский дизайнер, программист и автор книг.
Факты из жизни:
- в 1988 г. продал Биллу Гейтсу прототип визуальной среды разработки, впоследствии ставший Visual Basic;
- работал с Биллом Гейтсом на заре становления Microsoft;
- в 1995 г. создал метод целенаправленного дизайна (goal-directed design), основанный на раскрытии потребностей пользователей, понимании их индивидуальности и создании интерфейса продукта на базе этих знаний;
- изобрел концепцию проектирования с виртуальными персонажами, которые выступают олицетворением конечных пользователей приложения;
- в 2017 введен в Зал стипендиатов Музея истории компьютеров.
Источники: сайты Wikipedia, личный сайт Алана Купера
О книге
В разработке важно соблюдать баланс приоритетов. Чтобы проект не стал джангой наоборот - попыткой втиснуть в приложение новые фичи, пока оно не «упадет».
Все хотят работать над интересными задачами. Архитекторы и разработчики тяготеют к сложным техническим решениям. Дизайнеры не против внести нотки оригинальности. Тестировщики стремятся найти всевозможные дефекты.
Однако пользователи ожидают от продукта решения своей «боли» и комфорта при выполнении ежедневных задач.
Поэтому Купер призывает начинать работу с проектирования взаимодействия, чтобы удовлетворить потребности пользователей и достичь цели бизнеса.
При таком системном подходе исключаются неприоритетные задачи и значительно оптимизируется работа. Приложения создаются быстрее за счет уменьшения числа корректив и как следствие совершенных ошибок.
Рекомендую книгу тем, кто вовлечен в процесс разработки: дизайнерам, архитекторам, программистам, а также руководителям в тестировании, разработке, маркетинге и продажах.
Цитаты
Успешный профессионал XXI века - это либо инженер, разбирающийся в бизнесе, либо бизнесмен, разбирающийся в технологиях. Бизнесмен, разбирающийся в технологиях, понимает, что его успех зависит от качества доступной ему информации и его умения воспользоваться этой информацией. Инженер, разбирающийся в бизнесе, — это предприимчивый конструктор или ученый, специализирующийся на технологиях, но при этом обладающий деловой хваткой и осознающий, какая огромная сила заключена в информации. Оба новых архетипа будут доминировать в современном бизнесе.
Сложности во взаимодействии с компьютерами влияют на всех нас временами, приводя к фатальным последствиям. Но программные продукты сложны в применении не из-за сложности самих компьютеров, а потому, что в основу их разработки заложен неверный процесс. Данная книга призвана не только продемонстрировать следствия такого неверного процесса, но и прояснить причины его возникновения. Далее мы рассмотрим, как следовало бы изменить процесс, чтобы наше программное обеспечение обрело дружелюбный вид и мощный функционал.
Процесс инженерного проектирования при создании сложной системы не делает разницы между тем, будет ли ею оперировать специально нанятый профессионал или же неподготовленный новичок который на это не подписывался. Процесс инженерного проектирования не обладает представлениями, как работать с этими особенностям человеческого характера. Он концентрируется только на вопросах реализации продукта: «из чего это будет сделано?», «как это будет сделано?».
Проектирование архитектуры следует начинать на ранних стадиях инженерного планирования. Более того, именно оно должно быть движущей силой на этих стадиях.
Попытка снабдить продукт дополнительным новым функционалом, не так важна потребителям, как адекватное взаимодействие с продуктом и те конкретные проблемы, которые можно решить с помощью базовых функциональных возможностей.
Внутренняя часть программы должна быть написана на основе экспертных знаний технических нюансов и с учетом требований компьютеров. Внешняя часть программы должна быть написана с вниманием к потребностям людей. С первой задачей хорошо справятся программисты, а вторая — удел проектировщиков взаимодействия.
Какими бы ни были изменения и улучшения в интерфейсе, они понижают общее качество кода, поскольку неизбежно оставляет после себя некрасивые сращивания и рубцы.
Фанатичное стремление предусматривать возможные исключительные ситуации влечет за собой неминуемые последствия в виде пренебрежения теми событиями, которые имеют больший процент вероятности случиться. В результате на свет появляются программы, которые обладают взаимодействием, напичканным редкими или невостребованными функциями, которые затрудняют работу с тем, что действительно важно и часто применяется. Вот одна из самых распространенных жалоб пользователей: с программой сложно работать, потому что в ней слишком много разных настроек и все смешаны в одну кучу, без какого бы то ни было разделения.
Если вы хотите проектировать программные продукты, которые сделают ваших пользователей счастливыми, вам нужно точно понимать, что это за люди. Поэтому персоны играют важную роль в проекте.
Существует такая шутка: пилот небольшого самолета заблудился в облаках. Он идет на снижение, пока не оказывается рядом с офисным зданием, и кричит человеку в открытом окне: «Не подскажете, где я?» На что человек выдает ответ: «Вы в самолете, примерно в тридцати метрах над землей». Пилот тут же берет верный курс и спустя некоторое время благополучно приземляется в аэропорту. Пассажиры самолета удивленно спрашивают, как он понял, куда лететь. И пилот говорит: «Тот человек ответил мне совершенно точно и правдиво, но эта информация была абсолютно бесполезна, поэтому я сразу догадался, что этот человек — разработчик из Microsoft, а я знаю, где расположено здание Microsoft по отношению к аэропорту».
Если программа утаивает часть информации, вызывая у пользователя затруднения в оценке происходящего, заставляет его тратить время на выискивание самых важных и часто используемых функций и в придачу норовит обвинить пользователя в собственных промахах, пользователь отнесется к такой программе с неприязнью и получит негативный опыт взаимодействия. В этом случае даже присутствие в интерфейсе слов «спасибо» и «пожалуйста» будет не способно исправить ситуацию. Не скроет недостатки и идеально красивый, визуально насыщенный, чрезмерно информативный и даже антропоморфный интерфейс.
Если пользователь выполняет какую-то задачу постоянно, соответствующее взаимодействие должно быть спроектировано на высшем уровне качества. То же справедливо и для задачи, которая выполняется редко, но неизбежно. Взаимодействие для нее также должно быть качественно спроектировано. А вот проектирование взаимодействия для задач, выполнение которых необязательно или происходит не каждый день, не требует такого скрупулезного подхода. Ресурсы в виде времени и денег всегда ограниченны, а потому это отличная возможность сэкономить и перераспределить ресурсы на более полезные вещи. Готовиться нужно ко всем видам сценариев, но детально проектировать взаимодействие следует под те из них, которые наиболее важны или происходят чаще остальных.
Большинство пользователей нельзя отнести ни к «опытным, ни к экспертам – они находятся где-то посередине. Программисты настаивают на взаимодействии, подходящем лишь для таких же продвинутых пользователей, в то время как маркетологи требуют взаимодействия для новичков. Самой же обширной, неизменной и самой важной группой пользователей со средними навыками — попросту пренебрегают.
Чем меньше кода, тем меньше ошибок, запутанных моментов, возможностей для возникновения некорректного поведения, и такую программу легче сопровождать.
Внутренняя часть программы должна быть написана на основе экспертных знаний технических нюансов и с учетом требований компьютеров. Внешняя часть программы должна быть написана с вниманием к потребностям людей. С первой задачей хорошо справятся программисты, а вторая — удел проектировщиков взаимодействия.
Какими бы ни были изменения и улучшения в интерфейсе, они понижают общее качество кода, поскольку неизбежно оставляет после себя некрасивые сращивания и рубцы.
Фанатичное стремление предусматривать возможные исключительные ситуации влечет за собой неминуемые последствия в виде пренебрежения теми событиями, которые имеют больший процент вероятности случиться. В результате на свет появляются программы, которые обладают взаимодействием, напичканным редкими или невостребованными функциями, которые затрудняют работу с тем, что действительно важно и часто применяется. Вот одна из самых распространенных жалоб пользователей: с программой сложно работать, потому что в ней слишком много разных настроек и все смешаны в одну кучу, без какого бы то ни было разделения.
Если вы хотите проектировать программные продукты, которые сделают ваших пользователей счастливыми, вам нужно точно понимать, что это за люди. Поэтому персоны играют важную роль в проекте.
Существует такая шутка: пилот небольшого самолета заблудился в облаках. Он идет на снижение, пока не оказывается рядом с офисным зданием, и кричит человеку в открытом окне: «Не подскажете, где я?» На что человек выдает ответ: «Вы в самолете, примерно в тридцати метрах над землей». Пилот тут же берет верный курс и спустя некоторое время благополучно приземляется в аэропорту. Пассажиры самолета удивленно спрашивают, как он понял, куда лететь. И пилот говорит: «Тот человек ответил мне совершенно точно и правдиво, но эта информация была абсолютно бесполезна, поэтому я сразу догадался, что этот человек — разработчик из Microsoft, а я знаю, где расположено здание Microsoft по отношению к аэропорту».
Если программа утаивает часть информации, вызывая у пользователя затруднения в оценке происходящего, заставляет его тратить время на выискивание самых важных и часто используемых функций и в придачу норовит обвинить пользователя в собственных промахах, пользователь отнесется к такой программе с неприязнью и получит негативный опыт взаимодействия. В этом случае даже присутствие в интерфейсе слов «спасибо» и «пожалуйста» будет не способно исправить ситуацию. Не скроет недостатки и идеально красивый, визуально насыщенный, чрезмерно информативный и даже антропоморфный интерфейс.
Если пользователь выполняет какую-то задачу постоянно, соответствующее взаимодействие должно быть спроектировано на высшем уровне качества. То же справедливо и для задачи, которая выполняется редко, но неизбежно. Взаимодействие для нее также должно быть качественно спроектировано. А вот проектирование взаимодействия для задач, выполнение которых необязательно или происходит не каждый день, не требует такого скрупулезного подхода. Ресурсы в виде времени и денег всегда ограниченны, а потому это отличная возможность сэкономить и перераспределить ресурсы на более полезные вещи. Готовиться нужно ко всем видам сценариев, но детально проектировать взаимодействие следует под те из них, которые наиболее важны или происходят чаще остальных.
Большинство пользователей нельзя отнести ни к «опытным, ни к экспертам – они находятся где-то посередине. Программисты настаивают на взаимодействии, подходящем лишь для таких же продвинутых пользователей, в то время как маркетологи требуют взаимодействия для новичков. Самой же обширной, неизменной и самой важной группой пользователей со средними навыками — попросту пренебрегают.
Чем меньше кода, тем меньше ошибок, запутанных моментов, возможностей для возникновения некорректного поведения, и такую программу легче сопровождать.
Проектировщику хорошо известно, что каждый дополнительный элемент интерфейса – дополнительная нагрузка на пользователя. Каждая лишняя кнопка или значок – это еще один элемент, с которым пользователь должен ознакомиться и попытаться освоить.
Бывает весьма полезно осознать тот факт, что пользователям обычно нет никакого дела до надписей в строке состояния, хотя в программистской среде она столь популярна. В ходе тестирования намеревались понять, насколько эффективна строка состояния в самом низу окна программы. В ходе эксперимента участникам нужно было выполнить несложное задание в электронной таблице. При этом каждые пять минут в строке состояния отображалась надпись: «К обратной стороне вашего стула приклеена банкнота в $50. Заберите ее!» Тестирование продолжалось целый день, однако за это время не нашлось ни одного участника (а их было более десяти), кто предпринял бы попытку забрать купюру.
Прислушиваться — это разумное решение. Это означает, что вы пропускаете всю полученную информацию через себя. Слепо следовать указаниям клиентов – плохое решение. Это значит, что вы просто выполняете все, чего от вас захочет потребитель. В таком случае уже не вы ведете игру с огнем, а он начинает играть с вами.
Разумеется, отслеживая реакцию пользователя во время демо вы можете узнать много интересного, однако, пропуская этап проектирования, вы в итоге можете прийти к осознанию, что тестировали совсем не то, что нужно. Более того, при такой форме эксперимента любое незначительное действие, исходящее от инициатора тестирования, вроде кивка головой, мимолетно сказанного слова, неосторожного взгляда, может оказать сильное влияние на результаты, искажая их.
Никакое проектирование не будет иметь смысла, до тех пор, пока не воплотится в жизнь. А этого не случится, пока оно не будет описано в мельчайших конкретных деталях, в концепциях, понятных программистам. Описывать идеи проектирования нужно в письменном виде, максимально подробно, приводя примеры и неопровержимые доказательства пользы.
Задокументированный план проектирования подобен плану военных действий. Каждый знает свою зону ответственности и осведомлен обо всех критических и важных аспектах.
Программисты обычно используют весьма действенную тактику, называемую «пассивно-агрессивной». Они не будут вступать в конфронтацию для решения какого-либо вопроса, а вместо этого начнут избегать внимания к этой проблеме и втихомолку сами будут действовать – или бездействовать. Если что-либо не было задокументировано, очень велики шансы, что идею истолкуют неверно или вовсе проигнорируют, поскольку внутренние мотивы программистов и пользователей различаются самым кардинальным образом. Просто не описывать диалоговое окно в документе нельзя - проектировщик обязан невероятно четко указать, где этого диалогового окна быть не должно, чтобы программисты не добавляли лишние окна по собственной инициативе. Программисты считают диалоговые отличной вещью и думают, что делают пользователям огромное одолжение, когда, улучив свободную минутку, вставляют в программу пару-тройку диалоговых окон. Для пользователей же эти окна вещь крайне ненавистная, они изнуряют и снижают производительность работы пользователя.
Способность к четкому видению ситуации – это ключевая компетенция, а многие компании из категории ваших клиентов с трудом могут сосредоточиться на собственном бизнесе, не говоря уже о вашем. Поэтому, несмотря на то, что клиенты выдают вам противоречивые указания, они рассчитывают, что вы сами сумеете правильно определить, чему из этого следовать (похожая ситуация складывается в отношениях - примечание автора статьи).
Если в каноэ один участник команды гребет в направлении, противоположном правильному, вся команда уже не может рассчитывать на призовое место. Чтобы прийти к победе, вся команда должна грести сообща, а любой человек, перетягивающий одеяло на себя, способен навредить.
Бывает весьма полезно осознать тот факт, что пользователям обычно нет никакого дела до надписей в строке состояния, хотя в программистской среде она столь популярна. В ходе тестирования намеревались понять, насколько эффективна строка состояния в самом низу окна программы. В ходе эксперимента участникам нужно было выполнить несложное задание в электронной таблице. При этом каждые пять минут в строке состояния отображалась надпись: «К обратной стороне вашего стула приклеена банкнота в $50. Заберите ее!» Тестирование продолжалось целый день, однако за это время не нашлось ни одного участника (а их было более десяти), кто предпринял бы попытку забрать купюру.
Прислушиваться — это разумное решение. Это означает, что вы пропускаете всю полученную информацию через себя. Слепо следовать указаниям клиентов – плохое решение. Это значит, что вы просто выполняете все, чего от вас захочет потребитель. В таком случае уже не вы ведете игру с огнем, а он начинает играть с вами.
Разумеется, отслеживая реакцию пользователя во время демо вы можете узнать много интересного, однако, пропуская этап проектирования, вы в итоге можете прийти к осознанию, что тестировали совсем не то, что нужно. Более того, при такой форме эксперимента любое незначительное действие, исходящее от инициатора тестирования, вроде кивка головой, мимолетно сказанного слова, неосторожного взгляда, может оказать сильное влияние на результаты, искажая их.
Никакое проектирование не будет иметь смысла, до тех пор, пока не воплотится в жизнь. А этого не случится, пока оно не будет описано в мельчайших конкретных деталях, в концепциях, понятных программистам. Описывать идеи проектирования нужно в письменном виде, максимально подробно, приводя примеры и неопровержимые доказательства пользы.
Задокументированный план проектирования подобен плану военных действий. Каждый знает свою зону ответственности и осведомлен обо всех критических и важных аспектах.
Программисты обычно используют весьма действенную тактику, называемую «пассивно-агрессивной». Они не будут вступать в конфронтацию для решения какого-либо вопроса, а вместо этого начнут избегать внимания к этой проблеме и втихомолку сами будут действовать – или бездействовать. Если что-либо не было задокументировано, очень велики шансы, что идею истолкуют неверно или вовсе проигнорируют, поскольку внутренние мотивы программистов и пользователей различаются самым кардинальным образом. Просто не описывать диалоговое окно в документе нельзя - проектировщик обязан невероятно четко указать, где этого диалогового окна быть не должно, чтобы программисты не добавляли лишние окна по собственной инициативе. Программисты считают диалоговые отличной вещью и думают, что делают пользователям огромное одолжение, когда, улучив свободную минутку, вставляют в программу пару-тройку диалоговых окон. Для пользователей же эти окна вещь крайне ненавистная, они изнуряют и снижают производительность работы пользователя.
Способность к четкому видению ситуации – это ключевая компетенция, а многие компании из категории ваших клиентов с трудом могут сосредоточиться на собственном бизнесе, не говоря уже о вашем. Поэтому, несмотря на то, что клиенты выдают вам противоречивые указания, они рассчитывают, что вы сами сумеете правильно определить, чему из этого следовать (похожая ситуация складывается в отношениях - примечание автора статьи).
Если в каноэ один участник команды гребет в направлении, противоположном правильному, вся команда уже не может рассчитывать на призовое место. Чтобы прийти к победе, вся команда должна грести сообща, а любой человек, перетягивающий одеяло на себя, способен навредить.
Точно зная, что именно вы делаете, вы убережете себя от распыления усилий на вещи, которые точно делать не собираетесь. Мало какая компания может позволить себе тратить массу усилий на совершенно не соответствующие общим целям.
Если человек оказывается наделен ответственностью за качество продукта, а также соответствующими полномочиями, он с большой долей вероятности примет этот вызов, вне зависимости от своего уровня подготовки. Так, если вы разыщете подходящего специалиста и вмените ему полную власть над качеством и поведением продукта, вы получите продукт много лучший, чем если бы вы этого не сделали.
Во время калибровки топливного клапана техник военно-морских сил США ввел нуль в один из управляющих компьютеров, оснащенных процессором Pentium Pro и операционной системой Windows NT. Программа предприняла попытку поделить другое число на это нулевое значение, иначе говоря, выполнить действие, запрещенное в математике. Результатом стал глобальный сбой во всей системе управления бортом. Оставшись без компьютерного управления, двигатель встал, и корабль дрейфовал на волнах 2 часа 45 минут, до тех пор, пока его не отбуксировали на базу. Удача, что подобное не случилось в зоне боевых действий.
Программистам не хватает времени, четких указаний и адекватных планов, позволяющих добиться успеха. Повторюсь, чтобы решить проблему, ее следует сначала разобрать на составляющие. Я ищу решения, а не козлов отпущения.
Предсказать, какие функции каждого нового устройства будут востребованы, а какие — нет, несложно. Чем больше манипуляций потребуется сделать, чтобы воспользоваться той или иной опцией, тем меньше она будет востребована, то есть наблюдается обратно пропорциональная зависимость.
Плюсы и минусы
👍 универсальность: IT-спецам полезно почитать книгу, чтобы лучше понимать процесс разработки;
👍практичность: примеры разъясняют излагаемый материал.
👎 формат книги: мягкая обложка и слабый переплет;
👎 нужно переиздание: некоторые технологии в примерах устарели и могут быть неинформативны;
👎 нет выводов: было бы здорово иметь резюме по главам, чтобы по необходимости освежать знания.
Что ещё почитать
Похожие книги по тематике:
Дж. Рейнвотер, «Как пасти котов»
Изображения: сайт Oz.by
Если человек оказывается наделен ответственностью за качество продукта, а также соответствующими полномочиями, он с большой долей вероятности примет этот вызов, вне зависимости от своего уровня подготовки. Так, если вы разыщете подходящего специалиста и вмените ему полную власть над качеством и поведением продукта, вы получите продукт много лучший, чем если бы вы этого не сделали.
Во время калибровки топливного клапана техник военно-морских сил США ввел нуль в один из управляющих компьютеров, оснащенных процессором Pentium Pro и операционной системой Windows NT. Программа предприняла попытку поделить другое число на это нулевое значение, иначе говоря, выполнить действие, запрещенное в математике. Результатом стал глобальный сбой во всей системе управления бортом. Оставшись без компьютерного управления, двигатель встал, и корабль дрейфовал на волнах 2 часа 45 минут, до тех пор, пока его не отбуксировали на базу. Удача, что подобное не случилось в зоне боевых действий.
Программистам не хватает времени, четких указаний и адекватных планов, позволяющих добиться успеха. Повторюсь, чтобы решить проблему, ее следует сначала разобрать на составляющие. Я ищу решения, а не козлов отпущения.
Предсказать, какие функции каждого нового устройства будут востребованы, а какие — нет, несложно. Чем больше манипуляций потребуется сделать, чтобы воспользоваться той или иной опцией, тем меньше она будет востребована, то есть наблюдается обратно пропорциональная зависимость.
Плюсы и минусы
👍 универсальность: IT-спецам полезно почитать книгу, чтобы лучше понимать процесс разработки;
👍практичность: примеры разъясняют излагаемый материал.
👎 формат книги: мягкая обложка и слабый переплет;
👎 нужно переиздание: некоторые технологии в примерах устарели и могут быть неинформативны;
👎 нет выводов: было бы здорово иметь резюме по главам, чтобы по необходимости освежать знания.
Что ещё почитать
Похожие книги по тематике:
Дж. Рейнвотер, «Как пасти котов»
Изображения: сайт Oz.by
СОВМЕСТНЫЙ ПОСТ С VOITIXLER ОБ ОСОБЕННОСТЯХ ТЕСТИРОВАНИЯ В ФИТНЕС-ИНДУСТРИИ
Продолжаем серию об особенностях тестирования в IT и сегодня обсуждаем фитнес сферу. Спрашивает @voitixler, отвечает Lead QA @dseachouk
⠀
❓О чем ваш проект?
Один из клиентов компании - международный производитель спортивной одежды и экипировки. В его бизнес-портфель входило несколько фитнес-приложений для спорта (в основном бега) и мониторинга питания (похудения или наращивания мышечной массы).
⠀
❓В чем сложность тестирования?
Приложения ориентированы на массрынок, отсюда и специфика тестирования:
- разнообразие пользовательского окружения – телефонов и планшетов, на которых всё должно работать;
- множество фитнес-девайсов: трекеры, смарт-часы, смарт-обувь, пульсометры и наушники;
- комплексность совместной работы устройств, приложений и сервисов;
- частые релизы: раз в 1-2 недели;
- высокая цена ошибки тестировщика из-за конкуренции в stores.
⠀
Кроме того, заказчик занимался международным ритейлером. Это требовало проведения A/B тестирования, проверок локализаций, аналитики и Data Layer, а также интеграции с системами бизнес-менеджмента (Salesforce).
⠀
❓Какие инструменты использовались для автоматизации?
В компании использовались собственные разработки, выделенные в отдельный продукт - Zebrunner.
⠀
❓Какие особенности тестирования и требуются ли специальные знания?
Чтобы убедиться, работают ли диеты и не грешат ли датчики в устройствах, функционал проверялся во время занятий спортом. На кону здоровье пользователей и нельзя полагаться на эмуляцию.
⠀
❓Были ли интересные случаи?
На коллегу косо смотрели соседи. Представь, человек выходит на улицу прыгает, бегает по кругу во дворе, топает на месте, бормочет какие-то заклинания а-ля “скипнем дейлик” и уходит домой. Делает он это поздним вечером, под дождем и даже в -20 С зимой. Если не рассказать о своей работе, у людей могут возникнуть мысли о душевной болезни или нахождении под веществами.
⠀
❓Насколько работа тебе интересна и почему?
Это работа мечты для любителей спорта - она позволяет заниматься любимым делом и зарабатывать. Кроме того, приятно быть причастным к чему-то важному. К примеру, до сих пор пользуюсь на пробежках спецверсией часов Samsung, в релизе которых участвовал, а также приложениями, которые тестировал.
Продолжаем серию об особенностях тестирования в IT и сегодня обсуждаем фитнес сферу. Спрашивает @voitixler, отвечает Lead QA @dseachouk
⠀
❓О чем ваш проект?
Один из клиентов компании - международный производитель спортивной одежды и экипировки. В его бизнес-портфель входило несколько фитнес-приложений для спорта (в основном бега) и мониторинга питания (похудения или наращивания мышечной массы).
⠀
❓В чем сложность тестирования?
Приложения ориентированы на массрынок, отсюда и специфика тестирования:
- разнообразие пользовательского окружения – телефонов и планшетов, на которых всё должно работать;
- множество фитнес-девайсов: трекеры, смарт-часы, смарт-обувь, пульсометры и наушники;
- комплексность совместной работы устройств, приложений и сервисов;
- частые релизы: раз в 1-2 недели;
- высокая цена ошибки тестировщика из-за конкуренции в stores.
⠀
Кроме того, заказчик занимался международным ритейлером. Это требовало проведения A/B тестирования, проверок локализаций, аналитики и Data Layer, а также интеграции с системами бизнес-менеджмента (Salesforce).
⠀
❓Какие инструменты использовались для автоматизации?
В компании использовались собственные разработки, выделенные в отдельный продукт - Zebrunner.
⠀
❓Какие особенности тестирования и требуются ли специальные знания?
Чтобы убедиться, работают ли диеты и не грешат ли датчики в устройствах, функционал проверялся во время занятий спортом. На кону здоровье пользователей и нельзя полагаться на эмуляцию.
⠀
❓Были ли интересные случаи?
На коллегу косо смотрели соседи. Представь, человек выходит на улицу прыгает, бегает по кругу во дворе, топает на месте, бормочет какие-то заклинания а-ля “скипнем дейлик” и уходит домой. Делает он это поздним вечером, под дождем и даже в -20 С зимой. Если не рассказать о своей работе, у людей могут возникнуть мысли о душевной болезни или нахождении под веществами.
⠀
❓Насколько работа тебе интересна и почему?
Это работа мечты для любителей спорта - она позволяет заниматься любимым делом и зарабатывать. Кроме того, приятно быть причастным к чему-то важному. К примеру, до сих пор пользуюсь на пробежках спецверсией часов Samsung, в релизе которых участвовал, а также приложениями, которые тестировал.
Forwarded from dev.by: главные ИТ-новости Беларуси
📝Помните письмо сотрудницы EPAM, которая критиковала процедуру повышения и институт ресурсных менеджеров? Другие читатели dev.by рассказали о том, как устроено у них в компаниях. Вот какие способы повышения зп они знают:
😰девплан на 6/9 месяцев + ревью;
🏃пройтись по рынку и собрать офферы;
🗣пойти к груп-менеджеру и объяснить, что хочешь пересмотр;
🤑сказать "прибавка" - руководство само всё поймёт.
Подробнее
😰девплан на 6/9 месяцев + ревью;
🏃пройтись по рынку и собрать офферы;
🗣пойти к груп-менеджеру и объяснить, что хочешь пересмотр;
🤑сказать "прибавка" - руководство само всё поймёт.
Подробнее
Forwarded from Хакер — Xakep.RU
ФБР: мошенники используют дипфейки для устройства на работу
Федеральное бюро расследований (ФБР) предупредило, что преступники все чаще используют украденную личную информацию и дипфейки, чтобы устроиться на удаленную работу. Особенно злоумышленников интересуют технические должности, предполагающие доступ к конфиденциальным системам и информации.
https://xakep.ru/2022/06/29/deepfakes-remote-jobs/
Федеральное бюро расследований (ФБР) предупредило, что преступники все чаще используют украденную личную информацию и дипфейки, чтобы устроиться на удаленную работу. Особенно злоумышленников интересуют технические должности, предполагающие доступ к конфиденциальным системам и информации.
https://xakep.ru/2022/06/29/deepfakes-remote-jobs/
Forwarded from Типичный программист
Выявление и сбор требований к ПО — масштабный гайд
Фундаментальное описание требований к ПО и подходов к их выявлению и сбору — статья освещает все аспекты этой области знаний, структурирует информацию и не оставляет ни малейшего шанса недопониманиям и «тёмным» местам:
https://tproger.ru/articles/vyjavlenie-i-sbor-trebovanij-k-po-ultimate-guide/
#тестирование
Фундаментальное описание требований к ПО и подходов к их выявлению и сбору — статья освещает все аспекты этой области знаний, структурирует информацию и не оставляет ни малейшего шанса недопониманиям и «тёмным» местам:
https://tproger.ru/articles/vyjavlenie-i-sbor-trebovanij-k-po-ultimate-guide/
#тестирование
Forwarded from Типичный программист
Если QA-инженер и тестировщик ПО — разные профессии, то в чём их разница? И можно ли заменить одного специалиста другим?
Что интересно, этот вопрос возникает не только у новичков — иногда задачи QA-инженеров и тестировщиков путают даже в описаниях реальных вакансий!
Давайте разбираться. У нас вышла новая статья, в которой Виталий Станьков, ведущий аналитик группы организации тестирования МТС отвечает на эти вопросы и рассказывает про 3 самых важных отличия: https://tprg.ru/B2rl
#qa #тестирование
Что интересно, этот вопрос возникает не только у новичков — иногда задачи QA-инженеров и тестировщиков путают даже в описаниях реальных вакансий!
Давайте разбираться. У нас вышла новая статья, в которой Виталий Станьков, ведущий аналитик группы организации тестирования МТС отвечает на эти вопросы и рассказывает про 3 самых важных отличия: https://tprg.ru/B2rl
#qa #тестирование
КАК СТАТЬ ТИМЛИДОМ?
Несколько слов о том, как родилась идея статьи. Я задал коллегам вопрос, какие темы их более всего интересуют. Несколько из них касались менеджерской работы:
⠀
📍 ⠀⠀Как в рамках проекта вырасти от Junior до Middle и Senior уровня?
📍 ⠀⠀Как в рамках проекта совмещать функции менеджера и инженера?
⠀
В статье я отвечу на вопросы от коллег и дам несколько советов для получения менеджерской позиции.
Как в рамках одного проекта определить, что Junior вырос до Middle/Senior?
⠀
Верным считаю ориентирование на общие метрики, чем на знания технологий:
🌰 𝗝𝘂𝗻𝗶𝗼𝗿 – работает под руководством опытных коллег, поскольку ещё не до конца понимает «кухню».
⠀
🌱 𝗠𝗶𝗱𝗱𝗹𝗲 – «повидавший» специалист, выполняет задачи самостоятельно, помогает младшим коллегам, но еще испытывает трудности со сложными заданиями.
⠀
🍅 𝗦𝗲𝗻𝗶𝗼𝗿 – специалист с богатым опытом, способный разобраться в любой задаче от начала до конца (своими силами или силами команды), и который понимает, как и зачем нужно действовать, чтобы получить ожидаемый результат.
⠀
Для роста и наработки экспертности важен практический опыт, как положительный, так и отрицательный, а также наблюдение за коллегами и анализ их работы.
По моему мнению, поработав на сложном проекте на разных позициях, можно дорасти до middle-уровня. Однако каким бы трудным проект ни был, дальнейший рост потребует работы и вне его.
Несколько слов о том, как родилась идея статьи. Я задал коллегам вопрос, какие темы их более всего интересуют. Несколько из них касались менеджерской работы:
⠀
📍 ⠀⠀Как в рамках проекта вырасти от Junior до Middle и Senior уровня?
📍 ⠀⠀Как в рамках проекта совмещать функции менеджера и инженера?
⠀
В статье я отвечу на вопросы от коллег и дам несколько советов для получения менеджерской позиции.
Как в рамках одного проекта определить, что Junior вырос до Middle/Senior?
⠀
Верным считаю ориентирование на общие метрики, чем на знания технологий:
🌰 𝗝𝘂𝗻𝗶𝗼𝗿 – работает под руководством опытных коллег, поскольку ещё не до конца понимает «кухню».
⠀
🌱 𝗠𝗶𝗱𝗱𝗹𝗲 – «повидавший» специалист, выполняет задачи самостоятельно, помогает младшим коллегам, но еще испытывает трудности со сложными заданиями.
⠀
🍅 𝗦𝗲𝗻𝗶𝗼𝗿 – специалист с богатым опытом, способный разобраться в любой задаче от начала до конца (своими силами или силами команды), и который понимает, как и зачем нужно действовать, чтобы получить ожидаемый результат.
⠀
Для роста и наработки экспертности важен практический опыт, как положительный, так и отрицательный, а также наблюдение за коллегами и анализ их работы.
По моему мнению, поработав на сложном проекте на разных позициях, можно дорасти до middle-уровня. Однако каким бы трудным проект ни был, дальнейший рост потребует работы и вне его.
Как понять, выросли ли вы? Необходимо почувствовать, что заслуживаете большего, а затем убедиться, что ваша оценка собственных знаний совпадает с мнением коллег и руководства.
Посмотрите забавное видео, иллюстрирующее эти отличия - Senior QA инженер п̶о̶р̶т̶и̶т учит Middle-специалиста. Вагон, кстати, до сих пор на 4м пути
Как в рамках одного проекта совмещать функции менеджера и инженера?
Задавать подобные вопросы – здорово. Значит, вы хотите большего и готовы расти над собой. Дорога возникает под ногами идущего.
Я начну с ответа на вопрос: что представляет собой структура работы менеджера?
С точки зрения работодателя, специалист на руководящей должности в первую очередь должен выполнять следующие 4 функции (здесь я частично созвучен с Адизесом*):
Административные: формирование системы работы команды в штатном режиме (без овертаймов и срывов дедлайнов);
Управленческие: эффективное управление работой команды по достижению бизнес-целей;
Образовательные: донесение знаний до других участников команды с целью совместного роста;
Интеграционные: мотивация и межличностная коммуникация для формирования комфортных условий работы.
Будучи «играющим тренером», у вас вряд ли получится стать эдаким Робином Гудом, который занимается только интересными задачами, а неинтересные отдаетбедным коллегам. Придется совмещать приоритетную работу менеджера (быть администратором) и рутинные задачи специалиста (быть производителем), что возможно потребует больших усилий и навыков.
Посмотрите забавное видео, иллюстрирующее эти отличия - Senior QA инженер п̶о̶р̶т̶и̶т учит Middle-специалиста. Вагон, кстати, до сих пор на 4м пути
Как в рамках одного проекта совмещать функции менеджера и инженера?
Задавать подобные вопросы – здорово. Значит, вы хотите большего и готовы расти над собой. Дорога возникает под ногами идущего.
Я начну с ответа на вопрос: что представляет собой структура работы менеджера?
С точки зрения работодателя, специалист на руководящей должности в первую очередь должен выполнять следующие 4 функции (здесь я частично созвучен с Адизесом*):
Административные: формирование системы работы команды в штатном режиме (без овертаймов и срывов дедлайнов);
Управленческие: эффективное управление работой команды по достижению бизнес-целей;
Образовательные: донесение знаний до других участников команды с целью совместного роста;
Интеграционные: мотивация и межличностная коммуникация для формирования комфортных условий работы.
Будучи «играющим тренером», у вас вряд ли получится стать эдаким Робином Гудом, который занимается только интересными задачами, а неинтересные отдает
YouTube
Фитиль "Порожняк" (1969) смотреть онлайн
Смотрите на iPad: https://itunes.apple.com/ru/app/rvision-tv/id810243002
Подписывайтесь: http://www.youtube.com/subscription_center?add_user=FitilOfficial
Кинопортал RVision.tv - http://rvision.tv
Вступайте в группу: http://vk.com/rvision
Порожняк (1969)…
Подписывайтесь: http://www.youtube.com/subscription_center?add_user=FitilOfficial
Кинопортал RVision.tv - http://rvision.tv
Вступайте в группу: http://vk.com/rvision
Порожняк (1969)…
Как перейти от должности технического специалиста к менеджерской?
Рекомендовал бы для себя разобраться в первую очередь в самой причине «жажды власти»: зарабатывать больше, получить регалии или сделать что-то лучше и вести за собой людей?
Есть 3 способа стать руководителем:
Естественный переход от лидера в руководители, основанный на профессиональных и личных качествах.
Назначение – посредством найма или после прохождения испытательного срока.
Внешние обстоятельств – безысходность и махинации («по знакомству», «подсиживание» своего руководителя и т.д.).
По моему опыту, первые два варианта гармоничны. Причем не только с моральной точки зрения.
Во-первых, становление руководителем как самоцель, вероятнее всего, исключает дальнейшее желание совершенствоваться в этой ипостаси.
В-вторых, действия незрелого руководителя превращают проект в мыльную оперу. Недостаток опыта компенсируется манипулятивными действиями, что разбивает коллектив на группы, между которыми формируются нездоровые отношения.
В-третьих, умелый манипулятор будет защищать “свою власть”, превращая бизнес в “игру престолов”, не позволяя коллегам расти, а компании — развиваться.
Кроме того, из-за отсутствия опыта и знаний, руководители склонны выбирать неправильный стиль менеджмента (по классификации Адизеса*).
И наконец, формальный руководитель может не иметь такого же веса, как неформальный лидер, «серый кардинал», что может вызвать трения в команде.
Рекомендую полистать «48 законов власти» Р.Грина и «Государь» Н.Макиавелли, чтобы лучше понимать и быстрее выявлять манипуляции “власти”.
Рекомендовал бы для себя разобраться в первую очередь в самой причине «жажды власти»: зарабатывать больше, получить регалии или сделать что-то лучше и вести за собой людей?
Есть 3 способа стать руководителем:
Естественный переход от лидера в руководители, основанный на профессиональных и личных качествах.
Назначение – посредством найма или после прохождения испытательного срока.
Внешние обстоятельств – безысходность и махинации («по знакомству», «подсиживание» своего руководителя и т.д.).
По моему опыту, первые два варианта гармоничны. Причем не только с моральной точки зрения.
Во-первых, становление руководителем как самоцель, вероятнее всего, исключает дальнейшее желание совершенствоваться в этой ипостаси.
В-вторых, действия незрелого руководителя превращают проект в мыльную оперу. Недостаток опыта компенсируется манипулятивными действиями, что разбивает коллектив на группы, между которыми формируются нездоровые отношения.
В-третьих, умелый манипулятор будет защищать “свою власть”, превращая бизнес в “игру престолов”, не позволяя коллегам расти, а компании — развиваться.
Кроме того, из-за отсутствия опыта и знаний, руководители склонны выбирать неправильный стиль менеджмента (по классификации Адизеса*).
И наконец, формальный руководитель может не иметь такого же веса, как неформальный лидер, «серый кардинал», что может вызвать трения в команде.
Рекомендую полистать «48 законов власти» Р.Грина и «Государь» Н.Макиавелли, чтобы лучше понимать и быстрее выявлять манипуляции “власти”.
Подведу итог
Быть руководителем и лидером — не одно и то же. Первого назначают, а второго, чувствуя за ним силу, команда интуитивно выделяет среди своих участников.
Если у вас есть задатки лидера и авантюрная жилка, вы готовы брать на себя ответственность. Вероятнее всего, вокруг вас и ранее сплочался коллектив, и в будущем вы обязательно станете руководителем – вопрос времени и ваших усилий.
Другое дело, с каким багажом знаний вы придете к этой должности. Я бы посоветовал сфокусироваться на развитии своих профессиональных навыков и лидерских качеств:
Занимайтесь саморазвитием и практикой
В контексте работы будет полезно развивать такие навыки, как:
- умение презентовать свой опыт и профессионализм;
- определение, декомпозиция, приоритизация и внесения правок в задачи;
- составление и ведение документации;
- коммуникационные навыки и софт скиллы;
- навыки тайм-менеджмента;
- аналитические навыки и интуиция;
- техническая экспертность.
Для этого я советую читать книги, проходить обучение и посещать профессиональные митапы.
Также важно пробовать применять полученные знания на практике. Если у вас нет возможности сделать это на рабочих проектах, найдите волонтерскую команду или организуйте пет-проект, в рамках которого вы сможете сформулировать собственные правила игры и философию.
Будьте проактивным и ищите возможности
Умейте продемонстрировать свою работу. Не стесняйтесь озвучивать свои желания. Можно быть тайным Сантой, но тайным руководителем – нет. Я не призываю стать выскочкой и говорить везде только о своих достижениях, кидаться в коллег указаниями, не принимая обратной связи и не учась у других. Но если у вас нет решимости, ее нужно обрести.
Также не лишнем будет найти менторов и сравнить отзывы коллег-менеджеров со своими ожиданиями, чтобы избежать искаженного восприятия.
Можно попросить руководителя дать вам обратную связь:
- Предложить озвучить мнение о вашей работе. Проанализиров обратную связь, вы сможете исправить недостатки и получить совет.
- Спросить мнение о вашей готовности к руководству командой и узнать, есть ли соответствующие вакансии в рамках компании;
- Предложить поработать в качестве помощника, чтобы научиться ответственности и вырасти как специалист.
При этом будет уместным для начала убедиться, что у вас и вашего руководителя есть доверие друг к другу. Также, не давите сильно – уважайте занятость руководителя.
Не менее важно помогать другим, когда это уместно и необходимо. Пробуйте подключиться к задачам коллег, если они просят помощи. Вы не только поможете команде, но и наберетесь опыта.
P.S. Вы можете прочитать мою статью по смежной тематике “How to Be a Successful Team Leader and Motivate Teams”.
Быть руководителем и лидером — не одно и то же. Первого назначают, а второго, чувствуя за ним силу, команда интуитивно выделяет среди своих участников.
Если у вас есть задатки лидера и авантюрная жилка, вы готовы брать на себя ответственность. Вероятнее всего, вокруг вас и ранее сплочался коллектив, и в будущем вы обязательно станете руководителем – вопрос времени и ваших усилий.
Другое дело, с каким багажом знаний вы придете к этой должности. Я бы посоветовал сфокусироваться на развитии своих профессиональных навыков и лидерских качеств:
Занимайтесь саморазвитием и практикой
В контексте работы будет полезно развивать такие навыки, как:
- умение презентовать свой опыт и профессионализм;
- определение, декомпозиция, приоритизация и внесения правок в задачи;
- составление и ведение документации;
- коммуникационные навыки и софт скиллы;
- навыки тайм-менеджмента;
- аналитические навыки и интуиция;
- техническая экспертность.
Для этого я советую читать книги, проходить обучение и посещать профессиональные митапы.
Также важно пробовать применять полученные знания на практике. Если у вас нет возможности сделать это на рабочих проектах, найдите волонтерскую команду или организуйте пет-проект, в рамках которого вы сможете сформулировать собственные правила игры и философию.
Будьте проактивным и ищите возможности
Умейте продемонстрировать свою работу. Не стесняйтесь озвучивать свои желания. Можно быть тайным Сантой, но тайным руководителем – нет. Я не призываю стать выскочкой и говорить везде только о своих достижениях, кидаться в коллег указаниями, не принимая обратной связи и не учась у других. Но если у вас нет решимости, ее нужно обрести.
Также не лишнем будет найти менторов и сравнить отзывы коллег-менеджеров со своими ожиданиями, чтобы избежать искаженного восприятия.
Можно попросить руководителя дать вам обратную связь:
- Предложить озвучить мнение о вашей работе. Проанализиров обратную связь, вы сможете исправить недостатки и получить совет.
- Спросить мнение о вашей готовности к руководству командой и узнать, есть ли соответствующие вакансии в рамках компании;
- Предложить поработать в качестве помощника, чтобы научиться ответственности и вырасти как специалист.
При этом будет уместным для начала убедиться, что у вас и вашего руководителя есть доверие друг к другу. Также, не давите сильно – уважайте занятость руководителя.
Не менее важно помогать другим, когда это уместно и необходимо. Пробуйте подключиться к задачам коллег, если они просят помощи. Вы не только поможете команде, но и наберетесь опыта.
P.S. Вы можете прочитать мою статью по смежной тематике “How to Be a Successful Team Leader and Motivate Teams”.
👍1
Приложение*
Классификацию стилей менеджмента по Адизесу
Ицхак Адизес разделяет руководителей на 4 типа: производитель (краткосрочные результаты), администратор (процессы и эффективность), и предприниматель (долгосрочные результаты и перспективность) и интегратор (взаимодействие и атмосфера в команде).
Согласно теории Адизеса, ни один руководитель не может одинаково хорошо совмещать в себе все 4 роли - во всяком случае одновременно. Чаще всего наиболее ярко выражены две из них, а остальные компенсируются сильными сторонами других менеджеров.
В том случае, если какие из этих ролей не развиты, это приводит к “перегибам” стиля управления и руководители становятся «героями-одиночками», «бюрократами», «поджигателями» или «мертвыми пням».
Рекомендую как минимум пройти тест на определение преобладающего типа вашего руководства на сайте Адизеса, а еще лучше – прочесть книги автора.
Карнеги: вопросы, которые нужно задавать себе для повышения
- Как повысить ценность своей работы в компании?
- Что я могу сделать для компании такого, чего я не делаю сейчас?
- Каким образом я могу усовершенствовать рабочие процессы в моем отделе?
- Какие новые аспекты нужно изучить, чтобы приносить больше пользы для компании?
- Какие шаги можно предпринять, чтобы поставить в известность руководство о своей готовности брать на себя больше ответственности?
- Что из опыта других отделов может пригодится мне в достижении цели?
- Если я достигну потолка в своей текущей работе, чем я могу заняться в других видах деятельности?
- Есть ли задания, которые не вызывают энтузиазма у других и за выполнение которых я бы мог взяться по собственной инициативе?
- Готов ли я пойти на риски и жертвы, чтобы заслужить право повышения?
Список рекомендованных книг
- Rex Black, “Advanced Software Testing - Vol. 3: Guide to the ISTQB Advanced Certification as an Advanced Technical Test Analyst 1st Edition”
- Rex Black, “Certified Tester. Advanced Level Syllabus. Test Manager”
- Джой Битти и Карл Вигерс, “Разработка требований к программному обеспечению”
- Институт управления проектами, “Свод знаний по управлению проектами (PMBOK)”
- Сергей Дерцап, Алексей Минкевич, “Проджект-менеджмент. Как быть профессионалом”
- Алан Купер, “Психбольница в руках пациентов”
- Дейл Карнеги, “Как перестать беспокоиться и начать жить”
- Дейл Карнеги, “Как выработать уверенность в себе и влиять на людей, выступая публично”
- Дейл Карнеги, “Как завоевывать друзей и оказывать влияние на людей”
- Оливия Кабейн, “Харизма. Как влиять, убеждать и вдохновлять”
- Ицхак Адизес, «Идеальный руководитель. Почему им нельзя стать и что из этого следует»
- Ицхак Адизес, “Развитие лидеров. Как понять свой стиль управления и эффективно общаться с носителями иных стилей”
- Том Демарко и Тимоти Листер, "Человеческий фактор. Успешные проекты и команды"
- Марк Мэнсон, “Тонкое искусство пофигизма. Парадоксальный способ жить счастливо”
- Дэниел Канеман, “Думай медленно... Решай быстро”
- Марина Перескокова, “Мама, я тимлид! Практические советы по руководству IT-командой”
Классификацию стилей менеджмента по Адизесу
Ицхак Адизес разделяет руководителей на 4 типа: производитель (краткосрочные результаты), администратор (процессы и эффективность), и предприниматель (долгосрочные результаты и перспективность) и интегратор (взаимодействие и атмосфера в команде).
Согласно теории Адизеса, ни один руководитель не может одинаково хорошо совмещать в себе все 4 роли - во всяком случае одновременно. Чаще всего наиболее ярко выражены две из них, а остальные компенсируются сильными сторонами других менеджеров.
В том случае, если какие из этих ролей не развиты, это приводит к “перегибам” стиля управления и руководители становятся «героями-одиночками», «бюрократами», «поджигателями» или «мертвыми пням».
Рекомендую как минимум пройти тест на определение преобладающего типа вашего руководства на сайте Адизеса, а еще лучше – прочесть книги автора.
Карнеги: вопросы, которые нужно задавать себе для повышения
- Как повысить ценность своей работы в компании?
- Что я могу сделать для компании такого, чего я не делаю сейчас?
- Каким образом я могу усовершенствовать рабочие процессы в моем отделе?
- Какие новые аспекты нужно изучить, чтобы приносить больше пользы для компании?
- Какие шаги можно предпринять, чтобы поставить в известность руководство о своей готовности брать на себя больше ответственности?
- Что из опыта других отделов может пригодится мне в достижении цели?
- Если я достигну потолка в своей текущей работе, чем я могу заняться в других видах деятельности?
- Есть ли задания, которые не вызывают энтузиазма у других и за выполнение которых я бы мог взяться по собственной инициативе?
- Готов ли я пойти на риски и жертвы, чтобы заслужить право повышения?
Список рекомендованных книг
- Rex Black, “Advanced Software Testing - Vol. 3: Guide to the ISTQB Advanced Certification as an Advanced Technical Test Analyst 1st Edition”
- Rex Black, “Certified Tester. Advanced Level Syllabus. Test Manager”
- Джой Битти и Карл Вигерс, “Разработка требований к программному обеспечению”
- Институт управления проектами, “Свод знаний по управлению проектами (PMBOK)”
- Сергей Дерцап, Алексей Минкевич, “Проджект-менеджмент. Как быть профессионалом”
- Алан Купер, “Психбольница в руках пациентов”
- Дейл Карнеги, “Как перестать беспокоиться и начать жить”
- Дейл Карнеги, “Как выработать уверенность в себе и влиять на людей, выступая публично”
- Дейл Карнеги, “Как завоевывать друзей и оказывать влияние на людей”
- Оливия Кабейн, “Харизма. Как влиять, убеждать и вдохновлять”
- Ицхак Адизес, «Идеальный руководитель. Почему им нельзя стать и что из этого следует»
- Ицхак Адизес, “Развитие лидеров. Как понять свой стиль управления и эффективно общаться с носителями иных стилей”
- Том Демарко и Тимоти Листер, "Человеческий фактор. Успешные проекты и команды"
- Марк Мэнсон, “Тонкое искусство пофигизма. Парадоксальный способ жить счастливо”
- Дэниел Канеман, “Думай медленно... Решай быстро”
- Марина Перескокова, “Мама, я тимлид! Практические советы по руководству IT-командой”
Forwarded from Типичный программист
Тут коллеги поделились интересной пасхалкой от Microsoft из прошлого
Оказывается, в МS Outlook 2010 года, вместо аватарки по-умолчанию использовали силуэт Билла Гейтса! Да не просто силуэт, а с той самой фотографии, на которой Гейтса арестовали за превышение скорости и езду без прав в 1977 году. Подробности истории затерялись, а вот фото сохранилось.
#история #кек #пасхалки
Оказывается, в МS Outlook 2010 года, вместо аватарки по-умолчанию использовали силуэт Билла Гейтса! Да не просто силуэт, а с той самой фотографии, на которой Гейтса арестовали за превышение скорости и езду без прав в 1977 году. Подробности истории затерялись, а вот фото сохранилось.
#история #кек #пасхалки
🔥1
Forwarded from Эксплойт
This media is not supported in your browser
VIEW IN TELEGRAM
Школьники из Москвы целый месяц бесплатно питались во «Вкусно — и точка»: они нашли баг в системе работы терминалов самообслуживания.
Молодые инженеры весь октябрь проворачивали одну и ту же схему: заказывали еду на терминале, открывали техническую дверцу, нажимали на кнопку отключения и, наконец, забирали заказ. Откуда любители фастфуда узнали о баге — загадка.
Суммарно, за месяц бесплатных застолий парни набрали заказов на 12 тысяч рублей.
@exploitex
Молодые инженеры весь октябрь проворачивали одну и ту же схему: заказывали еду на терминале, открывали техническую дверцу, нажимали на кнопку отключения и, наконец, забирали заказ. Откуда любители фастфуда узнали о баге — загадка.
Суммарно, за месяц бесплатных застолий парни набрали заказов на 12 тысяч рублей.
@exploitex
Forwarded from ЖЮ 📡 Новости
Разработчик создал VR-шлем, который убьёт человека, если он проиграет в игре.
Создатель — Палмер Лаки говорит, что когда пользователя убивают в игре, на лобовой части шлема взрываются три заряда. Человек вряд ли после такого выживет.
Система пока не готова: разработчик дорабатывает крепления шлема таким образом, чтобы его нельзя было снять до конца игры. Ну и багов пока много — есть риск умереть из-за какой-нибудь ошибки в самой игре.
Новости от ЖЮ
Создатель — Палмер Лаки говорит, что когда пользователя убивают в игре, на лобовой части шлема взрываются три заряда. Человек вряд ли после такого выживет.
Система пока не готова: разработчик дорабатывает крепления шлема таким образом, чтобы его нельзя было снять до конца игры. Ну и багов пока много — есть риск умереть из-за какой-нибудь ошибки в самой игре.
Новости от ЖЮ