• Детектив в тестировании: Москва 30 апреля, Минск 7 мая

    Posted on April 20th, 2010 Александр Орлов No comments

    Не так давно мы выясняли вопрос, любят ли хорошие тестеры детективы. Выяснилось, что таки да, большинство любят. А тут оказывается Алексей Баранцев задумал провести два мастер-класса по тестированию методом свободного поиска. То есть, фактически по детективным методам тестирования. :)

    У вас есть в команде тестировщики, которые мечтают стать детективами? Посылайте их на этот тренинг! Тренинг пройдет в Москве 30-го апреля и в Минске 7-го мая. Ниже – официальная информация о программе, стоимости и прочих атрибутах.

    Название: Тестирование методом свободного поиска (exploratory testing)
    Начало: 30 апреля 2010, в 10:00
    Тренер: Баранцев Алексей
    Место проведения: Москва
    Стоимость: руб. 4,500

    Программа тренинга

    1. Вводное упражнение — построение плана тестирования учебного приложения.
    Обсуждение факторов, влияющих на точность планирования (оценка времени, определение последовательность действий, учёт рисков).
    Обсуждение возможных действий при появлении в процессе тестирования новой информации, не учтённой при планировании.

    2. Обсуждение теоретических аспектов.
    Что такое “тестирование”? Какие бывают “виды тестирования”?
    План чего мы построили и что будет являться результатом выполнения этого плана?
    Различные парадигмы тестирования — почему они существуют и каковы практические последствия этого.
    Что такое тестирование методом свободного поиска и какое место оно занимает в общей картине мира.

    3. Первый практический сеанс тестирования, обсуждение результатов.
    Обсуждение влияния результатов тестирования на построенный ранее план.
    Рассмотрение достоинств и недостатков одновременного проектирования и выполнения тестов.

    4. Концепция “сеанса тестирования” и способ организации процесса тестирования в виде набора сеансов.
    Различие между понятиями “цель”, “задание”, “план”.
    Как формулировать цели тестирования?
    Метафора “The touring test”. Построение карты приложения. Выбор “туров”.
    Как описывать результаты тестирования?

    5. Второй практический сеанс тестирования, обсуждение результатов.
    Парное тестирование — достоинства и недостатки.
    Что делать между сеансами тестирования?

    6. Дополнительные идеи, которые можно применять при тестировании методом свободного поиска.
    Метод “шести шляп” де Боно.
    Чит-листы.
    Автоматизация.

    7. Третий практический сеанс: регрессионное тестирование, обсуждение результатов.
    Обсуждение достоинств и недостатков использования тестирования методом свободного поиска при регрессионном тестировании.

    8. Особенности взаимоотношения с коллегами и начальством. — как им объяснить, “чем это вы тут занимаетесь”?
    Как оценивать полноту тестирования?
    Как оценивать качество работы тестировщика?
    Как начать внедрение тестирования методом свободного поиска?
    Когда и где не стоит использовать тестирование методом свободного поиска.

    Бонусы!!!
    Каждый оплативший курс за 15 дней до его начала получит БЕСПЛАТНО записи двух любых двухчасовых (или один четырехчасовой) онлайн-семинаров Алексея Баранцева.

    При одновременной регистрации и оплате двух участников (или одного участника на два тренинга) скидка 10%, трех — 15%.

    Зарегистрироваться на тренинг можно по адресу trainings@software-testing.ru

    Количество мест ограничено, перед оплатой квитанции обязательно зарегистрируйтесь.

    Информация для физических лиц:

    Услуги оказываются на основании публичного договора оферты. Ознакомиться с договором можно ЗДЕСЬ.

    Оплата через банк. Скачать квитанцию для оплаты можно ЗДЕСЬ (квитанция универсальная на все наши семинары и тренинги, в неё необходимо вписать нужную сумму и в графе наименование платежа указать дату и название тренинга).

    Информация для юридических лиц:

    По вопросам оформления договора и выставления счета на оплату обращайтесь по адресу trainings@software-testing.ru

    Возможна оплата участия на условиях публичного договора оферты. Ознакомиться с договором можно ЗДЕСЬ. По вопросам выставления счета на оплату обращайтесь по адресу trainings@software-testing.ru

  • Цитата недели (Рикардо Семлер)

    Posted on April 20th, 2010 Александр Орлов No comments

    Мы просто не верим в то, что наши сотрудники только и мечтают, как бы прийти попозже, уйти пораньше и сделать как можно меньше за максимально возможное количество денег, которое их профсоюз в состоянии вытянуть из нас. В конце концов, эти же люди воспитывают детей, участвуют в общественно-политической жизни своей страны, выбирают мэров, губернаторов, сенаторов и президентов. Они взрослые. В Semco мы и относимся к ним как к взрослым. Мы им доверяем. Мы не заставляем наших сотрудников просить разрешения сходить в туалет, и у нас нет охранников, которые будут их искать, если они отсутствуют целый день. Мы не стоим у них на пути, а просто даем им делать свою работу.

  • О личной неприязни и о том, что с ней делать

    Posted on April 19th, 2010 Александр Орлов 2 comments

    Вероятно, многие замечали, что мнение о человеке влияет на мнение о тех идеях, которые он предлагает. Приходит к тебе с классной идеей сотрудник, которого ты искренне считаешь разгильдяем. И в голове вместо восторга мысль: “Блин, лучше бы работал…” :)

    Все дело в том, что вы человека не уважаете и вообще не очень хорошо к нему относитесь. Испытываете личную неприязнь. Один из читателей сайта прислал ссылку на отличную статью Владимира Германа “Личная неприязнь”. Владимир является директором компании Instream, и видно, что знает о чем пишет.

    Избранные цитаты:

    Личная неприязнь – механизм психики. Действие ее коварно и не сразу распознаваемо сознанием. Человек практически не способен мыслить объективно, находясь под действием личной неприязни. Основное вредоносное ее свойство заключается в следующем. Личная неприязнь делает так, что любые высказывания, суждения или поступки оппонента трактуются нашим сознанием как враждебные или с подвохом – действует крайнее недоверие. Даже улыбка человека, у которого просто хорошее настроение, может быть истрактована как враждебная ухмылка или насмешка. В результате, личная неприязнь сама себя вскармливает. В современных коллективах это свойство личной неприязни подкрепляется еще и склонностью оппонентов общаться по электронной почте или ICQ – средства не передают эмоции.

    Например, если один из оппонентов поставил в приветствии восклицательный знак, подразумевая восторженное приветствие адресата, то адресат, испытывающий личную неприязнь, прочитает восклицательный знак как наезд. Необходимо знать это и рекомендовать избегать общения по email и ICQ в случае возникновения напряженности между людьми.

    И еще:

    Если люди хотят избавиться от личной неприязни, то самое главное – кому-то сделать первый шаг на встречу другому и поговорить откровенно о своих чувствах и том вреде и дискомфорте, который они испытывают. Прямой разговор является основным средством устранения личной неприязни.

    Иногда достаточно пары искренних комплиментов или подчеркнутой поддержки мнения “оппонента” на одном из совещаний. Ведь личная неприязнь включается у людей от личных претензий, когда человек видит, что его атакуют как личность. Если дать другому человеку понять, что вы его цените как личность и разногласия у вас только по рабочим вопросам, то личная неприязнь может испариться без следа и даже перерасти в дружбу.

    Конечно, есть вероятность, что при сильной степени неприятия, ваш оппонент будет искать в вашем шаге навстречу подвох. Но если вы будете откровенны, то этого не произойдет.

    Прочесть статью полностью

  • Сколько стоит честность (ну, если по-честному)?

    Posted on April 17th, 2010 Александр Орлов 1 comment

    Макс Дорофеев продолжает 2-й сезон Курса естествознания для менеджеров проектов. На этот раз Макс, ловко оперируя цифрами, наглядно показывает сколько стоит честность со стороны аутсорсеров. Очень рекомендую посмотреть.

  • Опрос про встречи один на один

    Posted on April 16th, 2010 Александр Орлов 8 comments

    Когда мы только пришли в Intel, нам все выдали раздаточный пакет сотрудника. В нем, конечно же, была ручка. Надпись на ручке гласила: “Regular 1:1″. То есть, надо встречаться 1:1. Регулярно. С каждым своим сотрудником.

    В рамках подготовки к докладу про обратную связь на конференции Software People проведем небольшой опрос (коллеги, если вы пока никем не руководите – отвечайте, есть ли у вас регулярные встречи один на один со своим начальником :) ):

    Проводите ли вы регулярные (хотя бы раз в две недели) встречи один на один с каждым своим сотрудником?

    View Results

    Loading ... Loading ...

    P.S. Если вы сидите в разных офисах, то телефонные разговоры тоже считаются.

    P.P.S. В ЖЖ голосовательный плагин почему-то не работает. Поэтому голосовать лучше прямо на сайте.

  • Скотт Беркун: должны ли менеджеры уметь писать код?

    Posted on April 16th, 2010 Александр Орлов 1 comment

    Разговоры о том, должен ли менеджер уметь писать код, ведутся двести пятьдесят лет. Действительно, такое ощущение, что они начались еще до того, как появился код, программисты и менеджеры. :)

    На эту тему даже разгорелось оживленное обсуждение в мастер-группе Happy PM. И как пошутили там ребята, это обсуждение прочел Скотт Беркун и ответил в своем блоге. :) И добавить к Скотту особенно и нечего. Хорошо написано. Женя Коломыдцев, с которым мы познакомились недавно в Омске, взял и перевел эту статью За что Жене, конечно, большооое спасибо!

    Должны ли менеджеры уметь писать код?

    Автор: Скотт Беркун

    Перевод: Евгений Коломыдцев

    Я часто вижу, как люди, работающие в техническом секторе, например, команды разработчиков, спорят на эту тему. В бытность мою в Microsoft мы все время об этом спорили, в особенности, должны ли уметь программировать люди, работающие на позиции Program Manager (менеджеры проектов в небольших группах). К сожалению, никто и никогда не исследовал вопрос, влияет ли умение программировать на успешность человека как менеджера.

    Вкратце, это зависит от того, что входит в ваши обязанности менеджера. Если вы занимаетесь только тем, что управляете разработчиками ПО, вам лучше уметь программировать и иметь опыт работы программистом. Отнесем таких менеджеров к категории А. Если вы входите в эту категорию, лишь небольшая часть вашего времени (5-20%) должна уходить на написание кода, и чем больше ваша команда, тем меньше времени у вас должно уходить на код.

    Если же вы ­- босс, ваша основная задача – делать то, что отдельные программисты делать не могут. Вести политическую борьбу, чем не может заниматься другой член команды. Отстаивать новые инициативы и направления. Разрешать некрасивые конфликты. Консультировать. Заниматься организацией тренингов, выбивать бюджет, повышать квалификацию своих сотрудников и находить новых – чтобы команда не переставала расти в количестве и профессионально.

    Менеджеры, выросшие из программистов, печально известны тем, что, сохраняя первоначальные профессиональные навыки, полностью пренебрегают большей частью обязанностей, о которых не забывает хороший менеджер. Технический сектор заполнен такими людьми. И это прискорбно. Во многих случаях, на их месте лучше бы оказаться людям категории Б.

    В категории Б роль менеджера более общая, как у менеджера проекта или тимлида, когда вы работаете с группой разработчиков, в этом случае умение программировать не так важно. Возможно, вы пришли из бизнеса, маркетинга, или успели много чем позаниматься за свою карьеру. И здесь важны ответы на вопросы:

    • Есть ли между вами и командой взаимное доверие? Речь не о том, как это доверие заслужить, но ответьте на простой вопрос: доверяют ли вам программисты? Они могут вам либо доверять, либо не доверять, и неважно, насколько вы сильны в программировании. Если вы защищаете своих программистов, помогаете им работать эффективно, помогаете им избегать скучных совещаний и других глупых занятий, вы завоюете их доверие. Доверяя вам, они будут вести себя как ваши партнеры и союзники, что поможет обеим сторонам раскрыться и работать в полную силу, независимо от ваших знаний. Как ни странно, часто доверие можно заслужить, вскрывая обман, или, чтобы не создавать конфликта, задавая уместные, умные, неприятные вопросы, которые могут показать, что вы не только понимаете, о чем речь, но вы проявляете искренний интерес. С другой стороны, как лидер, вы должны проявить доверие первым и отказаться от желания контролировать каждый шаг работы, которую вы не понимаете. Иногда можно просто оставить программистов в покое, после того, как вы вместе с ними достигли кристально четкого понимания задач и согласовали сроки их выполнения, и это может стать примером удивительно эффективного стиля управления.
    • Способны ли вы распознавать ложь? В разговоре с подчиненным, когда он заявляет, что поставленная задача сложна, зачастую приходится мысленно прикидывать, что задача а) действительно сложна; б) он не знает, как проще ее выполнить; или в) он просто не хочет этим заниматься. Хороший лидер достаточно компетентен в понимании компромиссов и знает, как устроено программное обеспечение, чтобы вовремя задать пару неприятных вопросов, а то и вскрыть чей-нибудь блеф.
    • Воспринимаете ли вы моральное состояние команды? Моральное состояние не сводится к одним лишь специальным мероприятиям. Кто-то должен понимать, что мотивирует команду разработчиков. Что их вдохновляет, и что подавляет. Возможно, я знаю больше о программировании, чем сотня программистов, которые на меня работают, но если мне не важно, что они чувствуют по отношению к работе, если я не способен их стимулировать, не помогаю им понять, что работа, которую мы делаем, важна, к чему мои знания программирования? Они бесполезны. Лидер, который способен понять, мотивировать, воодушевлять, убеждать, или иногда просто развеселить команду, вносит свой особый вклад, который вряд ли внесет кто-то еще.
    • Понимаете ли вы принципы программирования? Многим бы не помешало пройти краткий курс «Программирование для менеджеров». Есть принципы, которые действительно важны: производительность, объекты, проблемы, связанные со спецификациями, API, основы тестирования, и т.д., и для их понимания не требуются глубокие познания в программировании. Даже немного знаний о том, как работать с HTML/CSS, Flash, или макросами в Excel, преподанных должным образом, могут дать чувство понимания применяемых принципов, и это именно то, что нужно. Не обязательно самому быть технарем, чтобы говорить с технарями и понимать их язык.
    • Можете ли вы помочь программистам принимать верные решения? Самое верное решение – всегда принимать верные решения. Человек в роли лидера (будь то президент, начальник или родитель) часто попадает в ситуации, когда он не являются экспертами, но вынужден работать с экспертами в какой-то области, кто знает намного больше его самого. Есть род мастерства, особый коммуникативный и мыслительный навык, который помогает максимально использовать способности эксперта в принятии решения. Попробуйте задать разработчику два простых вопроса: 1) попросите назвать 3-4 варианта решения проблемы; и 2) попросите назвать плюсы и минусы каждого решения. Это направит разговор в нужное русло, и зачастую верное решение само всплывает на поверхность в ходе обсуждения. Сам факт того, что его слушают, когда программист объясняет разницу между вариантами решения, заставляет его лучше обдумывать решение, в то время как лидер получает важную информацию о контексте задачи, плюсах и минусах того или иного решения, без необходимости самому становиться экспертом во всех этих вопросах. Менеджерам нет нужды быть экспертами – им нужно уметь извлекать практическую пользу из общения с экспертами в любой области. Другими словами, речь идет о своего рода помощи, хотя многие не захотят признавать, что секрет успешного лидерства скрыт в чем то, что настолько завязано на эмоциональном общении людей.
    • Можете ли вы позволить разработчикам помочь вам в принятии верных решений? Часто случается, что описанный подход взаимен. Способны ли вы воспринимать идеи по дизайну, маркетингу или менеджменту от команды разработчиков? Точно так же, как у вас есть представление о том, чем должны заниматься программисты, у них есть свое видение того, чем занимаетесь вы. Еще один способ быстро завоевать доверие – дать им увидеть, что их предложения или обратная связь находят у вас отклик, что к ним прислушиваются, и их отношение к вам изменится.
    • Можете ли вы представить работу программистов в выгодном свете перед другими людьми? Еще одна функция лидера – докладывать о проделанной командой работе, показывать эту работу посторонним. В такой ситуации, скорее всего, придется отвечать на вопросы, касающиеся технической стороны дела, и лидер должен уметь ответить хотя бы на часть из них. Обычно, если лидер вовлечен в принятие решений и понимает учитываемые компромиссы, он сможет ответить на большинство вопросов о проделанной работе. Если лидер этого сделать не сможет, и ему приходится всегда окружать себя программистами, чтобы не попасть впросак, его ценность для команды сомнительна.

    Вывод: При имеющемся разнообразии команд и проектов, можно дать различные рекомендации, но в среднем, я убежден, менеджеры категории Б, – те, кто не может писать код, но в основном отвечает вышеописанным условиям, достигнет лучших результатов, чем менеджер, способный программировать, но в меньшей степени отвечает этим условиям.

    Оговорка: Разумеется, ничто не мешает человеку быть отличным программистом и успешным лидером одновременно. Такие люди существуют. Но их встретишь нечасто. А скольких за свою карьеру встречали вы?

  • Ruby-лово в Киеве: 21 мая

    Posted on April 15th, 2010 Александр Орлов No comments

    Знакомые ребята в Киеве проводят конференцию для настоящих рубил, то бишь тех, кто рубит на Ruby. Если у вас есть такие сотрудники – не забудьте их туда отправить. Чтобы ребята посмотрели, как рубят другие, как рубят в мире и вернулись обратно с возросшим желанием рубить. :)

    Ruby Shift 2010

    Приглашаем Вас принять участие в конференции Ruby Shift, 21 Мая 2010. Организаторы мероприятия – инициативная группа coffee’n'code.

    Возможности, открываемые Ruby Shift

    • Поддержка Украинского Ruby Community
    • Новые знакомства в IT
    • Обмен опытом
    • Поддержка имиджа и бренда компании
    • Новые идеи, неформальное общение с коллегами

    Программа

    Метапрограммирование в Ruby - объектная модель Ruby очень богата, и позволяет делать многие вещи проще, чем в других языках. Вы узнаете, каким образом использовать её возможности на все 100%. Тонкости и подробности реализации.
    Rails из первых рук - мощный, набирающий все большие обороты фреймворк для создания web-приложений, how-tos, причины перехода на 3ю версию.
    Rails in Cloud - хостинг Rails в облаках. Production-приложения, экономия на хостинге, возможности масштабирования в реальном времени и использования ресурсов, требуемых в конкретный промежуток времени.
    Scaling Rails - принципы расширения Rails приложений, оптимизация High-load приложений, использование различных технологий, примеры и практики.
    Rubinius, альертнативы MRI - JRuby, Rubinius, REE, примеры использования, возможности, поддержка, performance.

    В числе докладчиков

    Workshop

    Помимо докладов на Ruby Shift состоится также Workshop (мастер-класс) для докладчиков и участников конференции, зарегистрировавшихся на Workshop. Количество участников ограничено до 30 человек. Workshop будет проводиться на английском языке.

    В Workshop нет пассивных участников. Все активно вовлечены в действие, и таким образом получают максимум пользы, работая над интересными и нетривиальными задачами.

    Все участники будут разделены на команды, и поучаствуют в разработке и Showreel мини-проекта.

    Записаться на Ruby Shift 2010!

  • Как таки становиться менеджером

    Posted on April 15th, 2010 Александр Орлов No comments

    Время от времени получаю вопросы от слушателей нашего со Славой тренинга “Как стать менеджером в ИТ”. Ну вот, например:

    Как именно двигать в сторону менеджера, если понял, что в своей компании им стать не удастся – искать сразу позиции менеджера в других компаниях, или приходить в другую компанию на должность технического специалиста и уже оттуда расти в менеджера.

    Коллеги, сейчас я объясню, почему на этот вопрос нельзя дать однозначного ответа. А потом таки дам это ответ. :)

    Компании очень разные – бывают компании, занимающиеся заказной разработкой (аутсорсеры). Бывают компании, которые делают продукты. Аутсорсеры бывают гигантские (EPAM, Luxoft, Exigen), которые стараются работать на крупных западных заказчиков (Dell, DB, Boeing, Intel,..). Бывают аутсорсеры средние, бывают мелкие и выживающие.

    Продуктовики бывают крупные и устойчивые (Kaspersky Lab, Parallels, Yandex, Yota,..), бывают средние, бывают стартапы. А еще бывают ИТ отделы в банках и других не софтовых организациях. Например, один мой одногруппник руководит ИТ подразделением крупного авто-дилера. В этом подразделении работает более 200 человек.

    А еще бывают филиалы западных корпораций (Intel, Oracle, Motorola, Google, Siemens, Samsung,..) И там менеджеры занимаются еще кучей всяких интересных дел.

    К чему я это говорю сейчас. Во всем этом многообразии компаний менеджеры занимаются совершенно разными вещами. Да, можно расписать подробно, где и чем менеджеры занимаются, и, вероятно, я это когда-нибудь сделаю. Но суть в том, чтов одних компаниях менеджеры и вообще ИТшники – это люди, приносящие основную прибыль, в других это головы, которые продают заказчику на почасовой основе, в третьих – это такие несчастные люди, которые вообще сбоку и считается, что ничего не делают.

    Орг структура компаний накладывает свой отпечаток. Функциональная, разные матрицы, проектная – от всего этого очень сильно зависит, будет ли менеджер счастлив на работе, и стоит ли туда вообще соваться.

    Не надо думать абстрактно – как бы пойти, на тех. специалиста или на менеджера – надо думать конкретно.

    Выберите ту компанию, где вы хотите работать. Посмотрите на ее тип деятельности, поговорите с людьми, которые там работают – чем они занимаются, что они делают, для кого. Пообщайтесь, поймите перспективы компании, хотя бы приблизительно. Посмотрите, чем там занимаются менеджеры.

    И главное – посмотрите на людей, которые там работают. Это люди, которым что-то надо, или те, кто сидит на своей табуретке за приличные деньги?

    Выбрали компанию – и идите туда на любую должность, которая вам интересна, и для которой у вас есть компетенции. Да, менеджеров обычно ищут внутри прежде чем ищут снаружи. Исключения бывают, но редко. Обычно, когда компания резко расширяется. То есть редко.

    Но еще раз – вначале, выберите компанию и людей, с которыми вы будете работать. Работать надо над тем, что вам интересно, и с теми, кому что-то надо.

  • Делать проекты – вот что надо делать

    Posted on April 14th, 2010 Александр Орлов No comments

    Денис Войханский опубликовал отличный пост на тему того, что проектная деятельность, это хорошо. Для тех, кто читать не любит, ключевые мысли:

    Нужен ownership, без него дела не будет. Чтобы был ownership нужен проект. Там где его нет – придумываете. Спускайте вашу стратегию (идею семейства проектов, продуктов) «вниз» на подпроекты.

    Не надо целей «-12% время ожидания фикса запросов», надо «этот двигатель сделал я, человек, купивший машину, будет видеть моё имя и будет благодарен мне».

    Личная ответственность за результат – она накладывает и придает. :) В общем, очень правильная штуковина.

    Read the rest of this entry »

  • Цитата недели (Эрик Шмидт)

    Posted on April 13th, 2010 Александр Орлов No comments

    Мой опыт показывает, что наилучший способ руководить талантливыми представителями интеллектуального труда – позволить им самостоятельно организовать свою работу и свободно переходить границы