Не так давно мы выясняли вопрос, любят ли хорошие тестеры детективы. Выяснилось, что таки да, большинство любят. А тут оказывается Алексей Баранцев задумал провести два мастер-класса по тестированию методом свободного поиска. То есть, фактически по детективным методам тестирования.
У вас есть в команде тестировщики, которые мечтают стать детективами? Посылайте их на этот тренинг! Тренинг пройдет в Москве 30-го апреля и в Минске 7-го мая. Ниже – официальная информация о программе, стоимости и прочих атрибутах.
Название: | Тестирование методом свободного поиска (exploratory testing) |
Начало: | 30 апреля 2010, в 10:00 |
Тренер: | Баранцев Алексей |
Место проведения: | Москва |
Стоимость: | руб. 4,500 |
Программа тренинга1. Вводное упражнение — построение плана тестирования учебного приложения. 2. Обсуждение теоретических аспектов. 3. Первый практический сеанс тестирования, обсуждение результатов. 4. Концепция “сеанса тестирования” и способ организации процесса тестирования в виде набора сеансов. 5. Второй практический сеанс тестирования, обсуждение результатов. 6. Дополнительные идеи, которые можно применять при тестировании методом свободного поиска. 7. Третий практический сеанс: регрессионное тестирование, обсуждение результатов. 8. Особенности взаимоотношения с коллегами и начальством. — как им объяснить, “чем это вы тут занимаетесь”? Бонусы!!! При одновременной регистрации и оплате двух участников (или одного участника на два тренинга) скидка 10%, трех — 15%. Зарегистрироваться на тренинг можно по адресу trainings@software-testing.ru Количество мест ограничено, перед оплатой квитанции обязательно зарегистрируйтесь. Информация для физических лиц: Услуги оказываются на основании публичного договора оферты. Ознакомиться с договором можно ЗДЕСЬ. Оплата через банк. Скачать квитанцию для оплаты можно ЗДЕСЬ (квитанция универсальная на все наши семинары и тренинги, в неё необходимо вписать нужную сумму и в графе наименование платежа указать дату и название тренинга). Информация для юридических лиц: По вопросам оформления договора и выставления счета на оплату обращайтесь по адресу trainings@software-testing.ru Возможна оплата участия на условиях публичного договора оферты. Ознакомиться с договором можно ЗДЕСЬ. По вопросам выставления счета на оплату обращайтесь по адресу trainings@software-testing.ru |
Мы просто не верим в то, что наши сотрудники только и мечтают, как бы прийти попозже, уйти пораньше и сделать как можно меньше за максимально возможное количество денег, которое их профсоюз в состоянии вытянуть из нас. В конце концов, эти же люди воспитывают детей, участвуют в общественно-политической жизни своей страны, выбирают мэров, губернаторов, сенаторов и президентов. Они взрослые. В Semco мы и относимся к ним как к взрослым. Мы им доверяем. Мы не заставляем наших сотрудников просить разрешения сходить в туалет, и у нас нет охранников, которые будут их искать, если они отсутствуют целый день. Мы не стоим у них на пути, а просто даем им делать свою работу.
Вероятно, многие замечали, что мнение о человеке влияет на мнение о тех идеях, которые он предлагает. Приходит к тебе с классной идеей сотрудник, которого ты искренне считаешь разгильдяем. И в голове вместо восторга мысль: “Блин, лучше бы работал…”
Все дело в том, что вы человека не уважаете и вообще не очень хорошо к нему относитесь. Испытываете личную неприязнь. Один из читателей сайта прислал ссылку на отличную статью Владимира Германа “Личная неприязнь”. Владимир является директором компании Instream, и видно, что знает о чем пишет.
Избранные цитаты:
Личная неприязнь – механизм психики. Действие ее коварно и не сразу распознаваемо сознанием. Человек практически не способен мыслить объективно, находясь под действием личной неприязни. Основное вредоносное ее свойство заключается в следующем. Личная неприязнь делает так, что любые высказывания, суждения или поступки оппонента трактуются нашим сознанием как враждебные или с подвохом – действует крайнее недоверие. Даже улыбка человека, у которого просто хорошее настроение, может быть истрактована как враждебная ухмылка или насмешка. В результате, личная неприязнь сама себя вскармливает. В современных коллективах это свойство личной неприязни подкрепляется еще и склонностью оппонентов общаться по электронной почте или ICQ – средства не передают эмоции.
Например, если один из оппонентов поставил в приветствии восклицательный знак, подразумевая восторженное приветствие адресата, то адресат, испытывающий личную неприязнь, прочитает восклицательный знак как наезд. Необходимо знать это и рекомендовать избегать общения по email и ICQ в случае возникновения напряженности между людьми.
И еще:
Если люди хотят избавиться от личной неприязни, то самое главное – кому-то сделать первый шаг на встречу другому и поговорить откровенно о своих чувствах и том вреде и дискомфорте, который они испытывают. Прямой разговор является основным средством устранения личной неприязни.
Иногда достаточно пары искренних комплиментов или подчеркнутой поддержки мнения “оппонента” на одном из совещаний. Ведь личная неприязнь включается у людей от личных претензий, когда человек видит, что его атакуют как личность. Если дать другому человеку понять, что вы его цените как личность и разногласия у вас только по рабочим вопросам, то личная неприязнь может испариться без следа и даже перерасти в дружбу.
Конечно, есть вероятность, что при сильной степени неприятия, ваш оппонент будет искать в вашем шаге навстречу подвох. Но если вы будете откровенны, то этого не произойдет.
Макс Дорофеев продолжает 2-й сезон Курса естествознания для менеджеров проектов. На этот раз Макс, ловко оперируя цифрами, наглядно показывает сколько стоит честность со стороны аутсорсеров. Очень рекомендую посмотреть.
Когда мы только пришли в Intel, нам все выдали раздаточный пакет сотрудника. В нем, конечно же, была ручка. Надпись на ручке гласила: “Regular 1:1″. То есть, надо встречаться 1:1. Регулярно. С каждым своим сотрудником.
В рамках подготовки к докладу про обратную связь на конференции Software People проведем небольшой опрос (коллеги, если вы пока никем не руководите – отвечайте, есть ли у вас регулярные встречи один на один со своим начальником ):
P.S. Если вы сидите в разных офисах, то телефонные разговоры тоже считаются.
P.P.S. В ЖЖ голосовательный плагин почему-то не работает. Поэтому голосовать лучше прямо на сайте.
Разговоры о том, должен ли менеджер уметь писать код, ведутся двести пятьдесят лет. Действительно, такое ощущение, что они начались еще до того, как появился код, программисты и менеджеры.
На эту тему даже разгорелось оживленное обсуждение в мастер-группе Happy PM. И как пошутили там ребята, это обсуждение прочел Скотт Беркун и ответил в своем блоге. И добавить к Скотту особенно и нечего. Хорошо написано. Женя Коломыдцев, с которым мы познакомились недавно в Омске, взял и перевел эту статью За что Жене, конечно, большооое спасибо!
Должны ли менеджеры уметь писать код?
Автор: Скотт Беркун
Перевод: Евгений Коломыдцев
Я часто вижу, как люди, работающие в техническом секторе, например, команды разработчиков, спорят на эту тему. В бытность мою в Microsoft мы все время об этом спорили, в особенности, должны ли уметь программировать люди, работающие на позиции Program Manager (менеджеры проектов в небольших группах). К сожалению, никто и никогда не исследовал вопрос, влияет ли умение программировать на успешность человека как менеджера.
Вкратце, это зависит от того, что входит в ваши обязанности менеджера. Если вы занимаетесь только тем, что управляете разработчиками ПО, вам лучше уметь программировать и иметь опыт работы программистом. Отнесем таких менеджеров к категории А. Если вы входите в эту категорию, лишь небольшая часть вашего времени (5-20%) должна уходить на написание кода, и чем больше ваша команда, тем меньше времени у вас должно уходить на код.
Если же вы - босс, ваша основная задача – делать то, что отдельные программисты делать не могут. Вести политическую борьбу, чем не может заниматься другой член команды. Отстаивать новые инициативы и направления. Разрешать некрасивые конфликты. Консультировать. Заниматься организацией тренингов, выбивать бюджет, повышать квалификацию своих сотрудников и находить новых – чтобы команда не переставала расти в количестве и профессионально.
Менеджеры, выросшие из программистов, печально известны тем, что, сохраняя первоначальные профессиональные навыки, полностью пренебрегают большей частью обязанностей, о которых не забывает хороший менеджер. Технический сектор заполнен такими людьми. И это прискорбно. Во многих случаях, на их месте лучше бы оказаться людям категории Б.
В категории Б роль менеджера более общая, как у менеджера проекта или тимлида, когда вы работаете с группой разработчиков, в этом случае умение программировать не так важно. Возможно, вы пришли из бизнеса, маркетинга, или успели много чем позаниматься за свою карьеру. И здесь важны ответы на вопросы:
Вывод: При имеющемся разнообразии команд и проектов, можно дать различные рекомендации, но в среднем, я убежден, менеджеры категории Б, – те, кто не может писать код, но в основном отвечает вышеописанным условиям, достигнет лучших результатов, чем менеджер, способный программировать, но в меньшей степени отвечает этим условиям.
Оговорка: Разумеется, ничто не мешает человеку быть отличным программистом и успешным лидером одновременно. Такие люди существуют. Но их встретишь нечасто. А скольких за свою карьеру встречали вы?
Знакомые ребята в Киеве проводят конференцию для настоящих рубил, то бишь тех, кто рубит на Ruby. Если у вас есть такие сотрудники – не забудьте их туда отправить. Чтобы ребята посмотрели, как рубят другие, как рубят в мире и вернулись обратно с возросшим желанием рубить.
Приглашаем Вас принять участие в конференции Ruby Shift, 21 Мая 2010. Организаторы мероприятия – инициативная группа coffee’n'code.
![]() |
Метапрограммирование в Ruby - объектная модель Ruby очень богата, и позволяет делать многие вещи проще, чем в других языках. Вы узнаете, каким образом использовать её возможности на все 100%. Тонкости и подробности реализации. |
![]() |
Rails из первых рук - мощный, набирающий все большие обороты фреймворк для создания web-приложений, how-tos, причины перехода на 3ю версию. |
![]() |
Rails in Cloud - хостинг Rails в облаках. Production-приложения, экономия на хостинге, возможности масштабирования в реальном времени и использования ресурсов, требуемых в конкретный промежуток времени. |
![]() |
Scaling Rails - принципы расширения Rails приложений, оптимизация High-load приложений, использование различных технологий, примеры и практики. |
![]() |
Rubinius, альертнативы MRI - JRuby, Rubinius, REE, примеры использования, возможности, поддержка, performance. |
Помимо докладов на Ruby Shift состоится также Workshop (мастер-класс) для докладчиков и участников конференции, зарегистрировавшихся на Workshop. Количество участников ограничено до 30 человек. Workshop будет проводиться на английском языке.
В Workshop нет пассивных участников. Все активно вовлечены в действие, и таким образом получают максимум пользы, работая над интересными и нетривиальными задачами.
Все участники будут разделены на команды, и поучаствуют в разработке и Showreel мини-проекта.
Время от времени получаю вопросы от слушателей нашего со Славой тренинга “Как стать менеджером в ИТ”. Ну вот, например:
Как именно двигать в сторону менеджера, если понял, что в своей компании им стать не удастся – искать сразу позиции менеджера в других компаниях, или приходить в другую компанию на должность технического специалиста и уже оттуда расти в менеджера.
Коллеги, сейчас я объясню, почему на этот вопрос нельзя дать однозначного ответа. А потом таки дам это ответ.
Компании очень разные – бывают компании, занимающиеся заказной разработкой (аутсорсеры). Бывают компании, которые делают продукты. Аутсорсеры бывают гигантские (EPAM, Luxoft, Exigen), которые стараются работать на крупных западных заказчиков (Dell, DB, Boeing, Intel,..). Бывают аутсорсеры средние, бывают мелкие и выживающие.
Продуктовики бывают крупные и устойчивые (Kaspersky Lab, Parallels, Yandex, Yota,..), бывают средние, бывают стартапы. А еще бывают ИТ отделы в банках и других не софтовых организациях. Например, один мой одногруппник руководит ИТ подразделением крупного авто-дилера. В этом подразделении работает более 200 человек.
А еще бывают филиалы западных корпораций (Intel, Oracle, Motorola, Google, Siemens, Samsung,..) И там менеджеры занимаются еще кучей всяких интересных дел.
К чему я это говорю сейчас. Во всем этом многообразии компаний менеджеры занимаются совершенно разными вещами. Да, можно расписать подробно, где и чем менеджеры занимаются, и, вероятно, я это когда-нибудь сделаю. Но суть в том, чтов одних компаниях менеджеры и вообще ИТшники – это люди, приносящие основную прибыль, в других это головы, которые продают заказчику на почасовой основе, в третьих – это такие несчастные люди, которые вообще сбоку и считается, что ничего не делают.
Орг структура компаний накладывает свой отпечаток. Функциональная, разные матрицы, проектная – от всего этого очень сильно зависит, будет ли менеджер счастлив на работе, и стоит ли туда вообще соваться.
Не надо думать абстрактно – как бы пойти, на тех. специалиста или на менеджера – надо думать конкретно.
Выберите ту компанию, где вы хотите работать. Посмотрите на ее тип деятельности, поговорите с людьми, которые там работают – чем они занимаются, что они делают, для кого. Пообщайтесь, поймите перспективы компании, хотя бы приблизительно. Посмотрите, чем там занимаются менеджеры.
И главное – посмотрите на людей, которые там работают. Это люди, которым что-то надо, или те, кто сидит на своей табуретке за приличные деньги?
Выбрали компанию – и идите туда на любую должность, которая вам интересна, и для которой у вас есть компетенции. Да, менеджеров обычно ищут внутри прежде чем ищут снаружи. Исключения бывают, но редко. Обычно, когда компания резко расширяется. То есть редко.
Но еще раз – вначале, выберите компанию и людей, с которыми вы будете работать. Работать надо над тем, что вам интересно, и с теми, кому что-то надо.
Денис Войханский опубликовал отличный пост на тему того, что проектная деятельность, это хорошо. Для тех, кто читать не любит, ключевые мысли:
Нужен ownership, без него дела не будет. Чтобы был ownership нужен проект. Там где его нет – придумываете. Спускайте вашу стратегию (идею семейства проектов, продуктов) «вниз» на подпроекты.
Не надо целей «-12% время ожидания фикса запросов», надо «этот двигатель сделал я, человек, купивший машину, будет видеть моё имя и будет благодарен мне».
Личная ответственность за результат – она накладывает и придает. В общем, очень правильная штуковина.
Мой опыт показывает, что наилучший способ руководить талантливыми представителями интеллектуального труда – позволить им самостоятельно организовать свою работу и свободно переходить границы
Последние коментарии