QA - all in my soul

Software Estimation: Demystifying the Black Art by Steve McConnell

2011-12-09T20:36:00.002+04:00

Software Estimation: Demystifying the Black Art by Steve McConnell
Книжка о магическом искусстве, правненном к математическим формулам.
Когда наступает момент оценки проекта, СПЕЦИАЛИСТ, виртуоз, маг и волшебник берется за ~~перо~~ мышку\ручку и начинает вдохновенно оценивать, оценивать, оценивать, усматривая зорким взглядом все коварные подводные камни, спрятавшиеся на пути к светлому релизу. Так выглядит идеальная картинка в творческих неокрепших умах. Как на самом деле? - Погрешность есть всегда. Весь вопрос в ее размере.
Сюжет в книге развивается примерно следующим образом: вначале вводится понятие конус неопределенности. Потом разбирается конус неопределенности в свете процесса разработки.
После чего в бой вступают различные методы оценки – вначале экспертный, а потом и более – менее численные с клевыми формулами.
Единственное, что сбор статистики по схожим проектам для последующего вычиления все-таки более применим к аутсорсингу. Коробочные продукты натянуть на такие подходы намного тяжелее. Стоит помнить о том, что все методы, которые хоть как-то выражены в формулах перестают работать, когда задача становится нетривиальной. Например, разработать новый алгоритм. У каждого алгоритма есть свой предел. если оказывается что разработанный алгоритм чуть-чуть не дотягивает до требуемого минимума – начинай все с начала.
Но численные методы действительно будут хорошо работать при разработке однотипных проектов. Например, типовых сайтов.
И еще у меня сложилось впечатление, что автор книги – ярый противник Cocomo.
Но не смотря на весь мой скептис, книжку все-таки стоит прочитать.

SPM Conf – впечатления

2011-12-09T20:00:00.002+04:00

Прошла конференция SPM Conf – 1. Очень много интересных людей, знакомых лиц. Конференция проходила в трех потоках докладов. Очень часто хотелось разорваться и попасть на несколько параллельных докладов.
Вот то, что мне удалось посмотреть и послушать.
Сергей Архипенков, Как провалить проект. Антипаттерны управления проектом
Интересный доклад, иногда весьма неожиданный, нисколько не пожалела, что пошла на этот доклад. Единственный минус – в аудитории были колонны, и я умудрилась сесть так, что докладчика я не видела вообще. Но это, конечно, не вина докладчика.
После этого я выступала сама, учитывая, что в параллельной секции выступал Сергей Бережной, я не предполагала аншлага, однако слушателей было больше, чем я предполагала. Спасибо всем, кто пришел меня послушать, надеюсь, вам было интересно.
На свой доклад я уже прочитала один отзыв , большое за него спасибо. Достоинства буду развивать, над недостатками работать.
Очень хотелось пойти послушать Сергея Бережного. Говорят, было ну ооочень здорово.
Михаил Ганчиков, Планирование и запуск проекта в условиях ‘нулевой’ видимости: практический опыт
Интересный доклад, построенный на опыте одного проекта с нулевой видимостью. Михаил, на мой взгляд, немного не рассчитал время, поэтому вторая часть доклада прошла немного бегом. На слайдах была информация, которая требовала немного больше времени на обдумывание и понимание. Хотелось бы получить слайды и посмотреть еще раз, не торопясь. Не считая этого, доклад был очень интересным. Учитывая, что я работаю с коробочными продуктами, мне всегда интересно послушать про аутсорсинг, это как заглянуть в другой мир.
Михаил Завилейский, 6 хороших идей, которые я бы не посоветовал реализовывать, пока это возможно
Тоже интересный доклад, с юмором о наболевшем так рассказать – это восторг. Главный вывод: прежде чем реализовывать хорошую идею, надо еще раз подумать о том, зачем так издеваться над людьми.
Елена Степанцова, PM vs HR: как решить проблему дураков и хаоса в подборе персонала
После обеда выступать тяжело, особенно если зал оказывается проходным между столовой и двумя другими залами, где идут презентации.
Не могу сказать, что я в восторге от этой презентации, она получилась какая-то слегка агрессивная. Много было уделено внимания работе HR, но практически ничего не было сказано про взаимодействие HR & PM.
Александр Калугин, Качественный менеджер
Александр рассказывал про то, какие менеджеры проектов получаются из тестировщиков. При чем именно из тестировщиков, а не из тест лидов. В таком контексте мне показалось это несколько странным. Тестировщика просто оторвали от компа, когда он тест кейс проходил и посадили “менеджерить”. Достоинства и недостатки менеджера проекта – бывшего тестировщика\ девелопера были чересчур усилены. В общем, этот доклад не нашел во мне ожидаемого отклика.
Михаил Гедзберг, Игра с рисками
Михаил еще раз напомнил о главном и простом, о тех рисках, которые незаслуженно раз от раза забываются.
Дмитрий Башакин, Обратная связь: искусство достижения цели (мастер-класс)
Это тот случай, когда приглашенный для розыгрыша кейса затмил ведущего мастер класса. Рассматривался кейс “Реакция менеджера на постоянные опоздания”. Было активное выступление, на второй розыгрыш вышел ну очень артистичный молодой человек, которому аудитория аплодировала чуть ли не стоя. Он в роли сотрудника показал просто все паттерны поведения опаздывающего сотрудника за раз. Было здорово.
Дмитрий Безуглый, Лестница работы с потребностями потребителя (мастер-класс)
Для меня это был самый лучший доклад. Фактически доклад был не про управление проектами, а про управление продуктами. Самое ценное, когда важная информация группирована и визуализирована для подачи слушателям. Важно не только знать, но и уметь научить других. В докладе был представлен инструмент “лестница работы с потребителями”, который наглядно позволяет контролировать все ли требования и потребности будущего потребителя будут покрыты продутом. Очень интересно представлено и рассказано. Я в полнейшем восторге.
Александр Орлов, Переключение инженеров в менеджеры: трудности, методика, рецепты
Тяжело было другим докладчикам в параллельных секциях. Само выступление Саши было как всегда зажигательным и с шуточками. Правда был один бесчеловечный, убивающий напрочь слайд, который просто расстреливал: то, что должен знать менеджер. На маленьких косых полосках было много чего написано, но прочитать и осознать было очень тяжело.
Вот моя презентация

SPM-Conf-1 Как сохранить команду в эпоху перемен - Лилия Горбачик

View more presentations from Лилия Горбачик

Теория мертва?

2011-10-01T08:27:00.002+04:00

Написаны тома про противостояние программистов и тестировщиков.

Программисты: это не баг
Тестировщики: этот ужас надо фиксить

Это основа драматических произведений ИТ.

Сегодня я, возможно, похороню теорию? Почему? Потому что моя команда упорно опровергает постулат.

Как происходит у нас:

Программисты: давайте зафиксим!!! неее, надо фиксить!
Тестировщики: ребята, остановитесь, давайте пофиксим потом, в какой-нибудь следующей версии. Ну пожалуйста!!!
Программисты: да у нас и фикс готов. Что ему пылиться?!
Тестировщики: Вы что, на ночь домой не уходите?????

Когда задумалась почему так, в голову пришел только один ответ: Потому что у нас работают талантливые и самые лучшие программисты, которым не надо кричать, чтобы их услышали. Мы всегда их слушаем, потому что нам важно их мнение и они ерунду не болтают. А еще они романтики и верят в наш проект.

Как же взрастить такую команду, если есть куда стремиться? Прежде всего слушать свою команду и спрашивать мнение всех ее участников. Кто-то сам высказывается с удовольствием, а кого-то надо спросить отдельно в непринужденной обстановке за кофе, чтобы человек разговорился. Очень часто кто-то носит в голове золотую идею, не подозревая о ее ценности. Не давайте своей команде хоронить внутри себя золотые идеи. А уж если кто-то поделился этим сокровищем - обязательно скажите громко о ценности мысли. Как я все время говорю: Страна должна знать своих героев!

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

Уровни абстракции

2011-08-16T20:09:00.002+04:00

Очень часто возникают дебаты на тему: какие качества, компетенции важны для тестировщика. Размышляя на эту тему, не могу не упомянуть такое важное, на мой взгляд, качество, как умение мыслить \ работать на разных уровнях абстракции. Поясню для полноты понимания:
Например,
есть фича А. Ее надо протестировать за 2 дня, т.е. есть жесткие временнные рамки, от которых надо отталкиваться. Да, фича А - не две кнопки, чтобы ее протестировать хорошо, нужно больше времени, но в данной ситуации есть 2 дня. Надо для этих двух дней выбрать что тестировать.
Способность выделять главное и второстепенное для тестирования в такой ситуации очень ценно. Жизнь жестока, приходится поступаться чем-то, иногда качеством. Ведь наша задача - выпустить продукт с приемлемым уровнем качества. Приемлемый уровень качества может отличаться от нашего внутреннего мерила.
Умение переключиться и мыслить на заданном уровне абстракции - ценный навык, который обязательно будет отмечен руководителем.
Крайние формы неприятия жестких сроков могут выливаться в "Лучше никак не тестировать чем так", "Мне стыдно за наш продукт", "Нас постоянно прогибают, мы ничего хорошего не выпустим".
Если ситуация знакома, то надо следовать по двум путям одновременно:

Объяснить, почему так происходит в проекте: например, мы завязаны на сроки другого проекта итд. Если человек испытывает информационный голод, ему вряд ли будут понятны ваши решения.
Научить, как в такой ситуации надо действовать: Сесть рядом и вместе начать выбирать кейсы, поясняя почему надо делать именно так, как нужно рассуждать, постепенно вовлекая сотрудника в самостоятельное плавание.

Так шаг за шагом можно развить эту ценную компетенцию - не боги горшки обжигают.

Не только в песочнице приходится делиться...

2011-08-02T21:00:00.000+04:00

Помните те времена, когда в песочнице приходилось делиться лопатками?

Потом ты думаешь, что вырастишь и будет все так, как ты захочешь... Хочешь - делишься - не хочешь - не делишься.

А вот и нет, опять приходится делиться. Вот ты уже менеджер.

Приходят к тебе и говорят:

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

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

Отбился. Ура!

Но если взглянуть на это с точки зрения долгосрочной перспективы. Эта победа (возможность НЕ делиться) - это УРА или нет?

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

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

Итак, как быть когда у тебя просят помощи и как просить ее у других.

Когда тебя просят о помощи, ты думаешь, не выйдет ли тебе самому эта помощь боком. И это правильно. Спасая один проект, не стоит топить другие проекты.
Сравни краткосрочную и долгосрочную перспективы, чтобы принимать решение осмысленно.
Не молчи и не будь жадиной. Есть сомнения? Поделись своими опасениями с собеседником, возможно, вместе вы сможете найти новый вариант решения проблемы.
Оговори, потом закрепи на бумаге (в почте например) то, каким образом будет происходить помощь другой команде. Обязательно оговори непредвиденные случаи на твоем проекте, которые могут служить причиной пересмотра договоренности. Это позволит избежать ненужных конфликтов и недомолвок.
Если ты просишь помощи, обдумай реальные ее размеры и реальные возможности других команд оказать тебе помощь.
Не забудь о том, что хвалить нужно прилюдно - отправь благодарственное письмо, чтобы вся компания \ подразделение \департамент (в зависимости от размера компании) знали своих героев. Благодарность - это приятно любому человеку.
Когда к тебе приходят за помощью, подумай, ведь ты мог быть на его месте.

Кто знает о milestones кроме вас?

2011-07-29T18:02:00.000+04:00

Тест Менеджер, безусловно, помнит, хоть ночью разбуди и спроси, когда и какие milestones есть в проекте. Это замечательно. Но тут полезно помнить, что не все участники проекта "дергают колбаски" в MS Project.
Информация, которая зашита на подкорке у менеджера, не обязательно хранится в голове других участников проекта. Это не хорошо и не плохо. У каждого голова занята своими задачами.
Важно помнить об этом и не звереть, когда в 10-й раз тебя спросят: .... а когда у нас code freeze \ feature complete \ release notification \ regression.
И не мешает время от времени самому говорить об этих датах, дабы сравнить свое течение времени в проекте с остальными участниками проекта. Не исключено, что некоторые не подозревают, о том, какой великий milestone приближается и не мобилизуются должным образом.
Возможны также реакции: Regression? Code freeze? ну да, ну да, что-то слышал...
Не теряя присутствия духа надо нести светлое знание в чужие головы. Если не мы, то кто же?
Вроде бы не открытие, что про milestones должны знать. Но все равно иногда не сростается. Подобные мелочи, как песок, утекают сквозь пальцы незаметно.

Имеет ли право менеджер на пессимизм

2011-07-18T18:42:00.000+04:00

Имеет ли право менеджер на пессимизм?
Каждый человек (и менеджер тоже!) имет определенный склад ума, свои жизненные установки - это понятно всем.
Кто-то оптимист, кто-то пессимист.
Вопрос в том, имеет ли право менеджер быть на работе пессимистом и проявлять пессимизм в работе?

Например, приходит к тест менеджеру тестировщик и говорит:
- у нас бага критичная, девелоперы говорят, что у них не воспроизводится.
тест-менеджер:
- Не дергайся, Титаник идет ко дну. Конечно, у них ничего никогда не воспроизводитсяНастройки сообщения!!! Сейчас пойду их простимулирую.
После этого разговора у тестировщика на подкорочке откладывается: девелоперы зачастую неправы, проект безнадежен. Такие мысль легко поселяются в сознании, но выбросить их потом трудно.
Проходит какое-то время, тест-менеджер пытается придать силы команде и приободрить перед релизом. Но! Надо выйти поработать в выходные, дабы приблизить заветный релиз.
Вы уже догадываетесь, что некоторые тестировщики не будут радостно кидаться спасать проект, который был назван менеджером "Титаник".

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

Подготовка к презентации - внимание к деталям

2011-07-13T12:10:00.002+04:00

О подготовке к презентации написано много. Как говорить, как снимать стресс перед выступлением.
Я хочу рассказать о тех этапах подготовки, которые незаслуженно порой забываются. Это детали. Но детали важные.
Подготовка презентации в Power Point - анимация
Возможно, у вас уже сформировался свой подход к подготовке \ оформлению файла презентации Power Point. Кто-то делает статичные слайды, кто-то любит анимацию. Как это может повлиять на ваше выступление? Необходимо перед выступлением, желательно заранее, выяснить какое техническое обеспечение будет в той аудитории, в которой вы будете выступать. Почему? Наличие пульта для управления презентацией позволяет вам делать анимацию любой сложности для вашей презентации. Проблема снимается сама. Но если такого чудесного пульта нет, возможно, вам придется задействовать кого-то для управления вашими слайдами, это существенно усложнит управление слайдами\ анимацией\ презентацией, будет отвлекать вас от аудитории.

Так и случилось на моем выступлении на SQA Days. У меня была такая динамичная презентация, тут двигается, тут летает. Когда я пришла в зал, в котором мне предстояло выступать, и осознала, что пульта у меня не будет, а будет Александр Орлов, который с помощью пробела на клавиатуре ноутбука будет выполнять переключение слайдов и анимации, я была удивлена. К моему счастью, Александр замечательно управлял анимацией, так что аудитория не заметила потенциального коллапса. Повезло. А могло ведь и не повезти.

Подготовка презентации в Power Point - картинки
Казалось бы, что плохого может крыться в картинках, которые многие любят вставлять в свои презентации? Прежде чем вставить картинку, подумайте, зачем вы это делаете? Поясняет ли картинка текст или идею слайда. Если картинки не по теме, они не помогают, не поясняют то, что вы рассказываете, это может отвлекать ваших слушателей. Обращайте на это внимание.

У меня был очень забавный случай, связанный с картинками в презентации. Я опробовала свою презентацию на ~~тех кого не жалко~~ коллегах. Рассказала, ребята задавали вопросы, все вроде шло хорошо. Потом опытный товарищ встал и с видом человека, который не может держать это в себе, сказал: "и последний комментарий: Лиля... объясни зачем ты вставила эту картинку на слайже номер 5???" Я судорожно начала отматывать презентацию на пятый слайд? Смотрю и не могу понять немого вопроса. "А что такого? Вот картинка иллюстрирует работу сплоченной команды. Как раз к теме слайда." Ответ поразил меня до столбняка: "Убери из презентации этих мужчин чуждой нам ориентации. Я не помню о чем ты говорила на этом слайде, я все думал, зачем ты это спихнула сюда и недоумевал..." (это адаптированная версия реплики) Такая мысль не укладывалась в моей голове, но когда эту идею поддержало большинство мужчин, я поняла, что лучше убрать эту картнку.

Какой из этого вывод? Возможно, ваши картинки могут вызвать непонятную для вас ассоциацию у аудитории. Если ваша потенциальная аудитория и вы видите разный контекст одной и той же картинки - стоит подумать над ее заменой.
Также следует уделить внимание такой простой детали как разрешение картинок. Многие сейчас люди мобильные, с ноутбуками, нетбуками, айпадами и прочими мобильными девайсами. Помните, что картинка на маленьком экране вашего ноутбука и на большом экране от проектора могут выглядеть по-разному. Качество картинки может казаться замечательным на маленьком экране, но на большом это будет смотреться ужасно. Мелочь, но ее заметят все.
Помните о том, что дьявол кроется в мелочах, и удачи на презентациях.

"Как сдвинуть гору Фудзи?" - Уильям Паундстоун

2011-07-11T12:08:00.002+04:00

Уильям Паундстоун - Как сдвинуть гору Фудзи? Подходы ведущих мировых компаний к поиску талантов

Интересная книжка о различных подходах крупные компаний к поиску нетривиальных и креативных умов.

Из нее можно узнать, что на самом деле хотят о тебе узнать на собеседовании, когда задают вопрос: Почему канализационный люк круглый?

Т.е. зачем и почему задают вопросы, на которые невозможно ответить.

Есть ли подход к решению лочических задачек и задач на сообразительность?

Так же книга поведает о печальной истории непоколебимой веры в IQ и еще много о чем...

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

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

Собеседование - когда количество переходит в качество

2011-07-08T14:44:00.000+04:00

Частенько говорят, что количество в качество не переходит.
Спешу не согласиться, я знаю по крайней мере один случай, опровергающий этот постулат - собеседование.
Если вы работаете на текущем месте работы достаточно продолжительное время и решились поменять работу, то скорее всего сам процесс собеседования будет стрессом.
Как известно все по-разному реагируют на стресс - кто-то краснеет, кто-то замолкает как рыба об лед, кто-то запинается и не может выразить хоть как-то свою мысль.
Но главная цель собеседования - это показать себя с лучшей стороны, продемонстрировать, рассказать о своих сильных сторонах. Следовательно, надо бороться с робостью и столбенением. Как это можно сделать?

готовиться. посмотреть в интернете вопросы, которые задают на собеседовании. Подготовить на них ответы заранее.
прочитать книжку "Как сдвинуть гору Фудзи" про подход к подбору креативных специалистов. В книжке есть примеры странных вопросов из разряда: Почему крышка люка круглая?
ходить на собеседования часто и много, чтобы снять внутренний порог стресса. Не надо отказываться от собеседования в компании, которая заведомо вам не подходит. Сходите! Просто для тренировки. После N-го собеседования вы обязатлеьно почувствуете себя более спокойно и раскованно на собеведованиях. Это тот случай, когда количество переходит в качество.
анализируйте каждое собеседование. Возможно, будет удобным делать заметки "по горячим следам". Анализ своих ответов, поведения очень помогает в работе над собой.
не волнуйтесь, если вы завалили первое собеседование. Первый блин... как говорится. Главное - понять, из-за чего это произошло и идти дальше.

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

Презентация - не экзамен и не ловушка

2011-07-07T16:22:00.002+04:00

Я думаю, весм знакома ситуация:
- Кто хочет выступить с презентацией и рассказать 0 (нужное подчеркнуть)

наших достижениях;
нашем продукте;
наших процессах?

А в ответ - тишина. Желающие испарились, сверкая пятками...
Почему так происходит? За презентацию не бьют, не ругают, но желающих все равно нет.
Наверно, первоисточник - это наше среднее образование, когда вызывают тебя к доске со словами и ухмылкой:
- Ну, давай, Петров, расскажи, что ты знаешь о грызунах Португалии...
Потом стоишь, мучительно рассказываешь, а учитель начинает задавать вопросы, и кажется уже, что ты не у доски стоишь, а на допросе присутствуешь.
Так убивается талант оратора в средней школе. В итоге во взрослой жизни мало кто добровольно рвется что-то презентовать. Но бороться с собой можно и нужно.
но вот в чем вопрос: как это сделать?
Чтобы уменьшить тревожность надо:

Четко понимать цель выступления. Это снимет некоторые опасения.
Представлять какова будет целевая аудитория. (это поможет в определении потенциальных вопросов)
Готовиться заранее - очень важный пункт. Бывает, что страх так парализует, что одна мысль о начале подготовке приводит в состояние столбняка. Так происходит до последнего дня, а потом начинается обоснованная паника. Результат закрепляется на подкорке, и круг замкнулся.
Тренироваться на кошках, или на друзьях, или на коллегах, в общем, на тех, кого не жалко. Помогает закрепить структуру выступления в голове и придает уверенности.
Не стесняться просить помощи. Например, вы не сильны в создании слайдов к презентации. Попросите о помощи. Скорее всего, вам не откажут. Кто-то поможет найти картинки для презентации, кто-то помжет четко сформулировать тезисы. С миру по нитке... Очень часто мы боимся попросить о помощи, спросить- переспросить, и от этого сами себя вгоняем в стрессовое состояние.

Наконец, надо самому себе сказать, что я выступаю не в клетке со львами в цирке, а среди людей, которым интересно то, что я говорю. А если кому-то неинтересно, то скорее всего он сядет в уголочке и будет заниматься своими делами. Поэтому никто меня не съест. Случаи, когда на рядовой презентации оратора закидали кирпичами скорее выдумана теми, кто панически боится выступать.
И помните: Если вам не страшно сделать шаг вперед, значит он слишком мал для вас.
Сегодня, может быть, шаг вперед - это шаг на сцену для презентации.

Как оживить Postmortem?

2011-07-01T17:19:00.000+04:00

Для начала несколько слов о том, что такое Postmortem, возможно, кому-то не знакома такая практика.
Postmortem – это пострелизный документ, который призван аккумулировать информацию по проекту, которая может быть важна для последующих версий этого проекта или для процессов компании в целом. Это может быть произвольной формы документ, или в компании принят определенный формат документа.
Каждый пункт документа следует рассмотреть с трех сторон:

Что было сделано успешно
Что требует доработки
Как можно улучшить ситуацию (если применимо)

Рассмотрим информацию, которую можно включить в Postmortem:
i. Управление и планирование
Трудности, а может, у кого-то и радости, которые возникали во время планирования, разработки \ тестирования проекта. Необходимо также упомянуть те отклонения, которые возникли в проекте: удалось ли с ними справится или отклонения привели к задержке выпуска продукта. Форс-мажоры, если они были. После этого нужно крепко задуматься, были ли это на самом деле форс-мажоры или все-таки это были риски, которые надо было и можно было учитывать на этапе проектирования. Важно не только обозначить проблемы, но и проанализировать причины их возникновения:

Недооценка сложности функционала;
Проблемы с третьесторонними продуктами, которые потребовали непрофильных знаний сотрудников;
Неучтенные зависимости в работе команды (если команда не постоянная, а собрана под проект)

ii. Ресурсы любого вида:

сотрудники (обещали выделить для тестирования производительности специалиста, а он уволился)
железо (не хватало памяти на машинах, не хватало места на сервере)
софт (необходима была лицензия на что-то, но ее покупка заняла много времени и задержала выполнение некоторых задач)

iii.            Команда, командообразование, взаимодействие и коммуникации в любых проявлениях. Это становится критичным пунктом, если члены команды разбросаны по странам и континентам.
iv.            Процессы. Использовались корпоративные процессы в чистом виде или произошла адаптация к конкретному проекту. Если процессы были адаптированы и принесли положительные результаты, надо поделиться опытом. Если процессы приносили негатив, но необходимо проанализировать ситуациюю
Итак, мы определили те темы, которые могут быть освещены в Postmortem.
Теперь рассмотрим подходы к заполнению Postmortem и проанализируем факторы, сводящие эти отличные начинания к нулю.
Итак, завершается проект, вы облегченно вздыхаете перед тем, как начать новый проект (или, возможно, вы уже частично заняты новым проектом). Но тут для отчетности надо заполнить этот злосчастный Postmortem, а ваши мысли уже отданы новому проекту. Поэтому в перерыве между боем, вы быстренько чиркаете этот документ и с облегчением его закрываете. Конечно, вы не враг своему успешно (я в этом не сомневаюсь) завершенному проекту. Просто после финиша вы наслаждаетесь результатом, а трудности процесса уже начинают стираться из памяти – такова человеческая сущность. В этом и кроется главная причина провалов таких благих начинаний как Postmortem.
Что же делать?
Надо начинать писать этот документ с самого начала проекта. Чтобы и это благое начинание не постигла участь забвения, нужно держать этот документ или напоминание о нем перед глазами. Я, например, создаю папку «_Postmortem» в Outlook и копирую в эту папку все полезные письма, которые потом использую в качестве источника информации для Postmortem.
Таким образом, Postmortem не составляется на тот момент, когда некоторые детали, события подзабылись, а пишется, когда все еще свежо в памяти.
Если у кого есть склонности к ведению дневника, черновик Postmortem может стать своеобразным дневником проекта: пришел с совещания на взводе, твое решение не поддержали, теперь проект будет непременно завален! Садишься, записываешь свое возмущение, решение, которое приняли, аргументы, которые стали решающими при принятии решения – и тебе легче становится и полезная информация сохранена. Через месяц открываешь документ, натыкаешься на эту запись и понимаешь, что тогда погорячился, решение было неплохое или наоборот, что ты был прав, но, возможно аргументировал не очень, или твое решение было неприемлемо в силу третьих обстоятельств.
В школе нас стыдили и отучали подглядывать, списывать у других. Но, вы уже выросли, и про это правило нужно забыть! Подглядывать, анализировать Postmortem чужих проектов можно и нужно! Не исключено, что проблемы, с которыми столкнулись вы, не только не уникальны, но хорошо известны и имеют широкую линейку решений. Поэтому, не стесняемся и перенимаем опыт коллег.
Возможно, те решения, которые вы выработали в процессе разработки проекта, могут быть очень и очень полезны. Не надо стесняться делиться своими ценными знаниями и опытом в решении проблем с другими. Вы эффективно изменили процесс и рамках одного проекта и получили явный бонус – сообщите об этом другим. Если в вашей компании есть практика Best Practice, начните процесс дополнения этого документа. Усилия, которые потребуются для обнародования ваших достижений, не так велики, но принесут значительные бонусы в будущем.
Резюмируя все выше изложенное, выводим правила неумирающего и эффективного Postmortem:
i.            Начинать писать документ с начала проекта;
ii.            Делать записи, когда информация свежа в памяти;
iii.            Держать документ на виду, чтобы не забывать к нему обращаться;
iv.            Заполнять не только свой Postmortem, но и анализировать Postmortem других проектов.
v.            Выделять информацию из Postmortem в Best Practice.

FDCC testing

2011-06-30T01:57:00.000+04:00

FDCC - это Federal Desktop Core Configuration, т.е. безопасная конфигурация. Подробнее можно прочитать на официальном сайте - http://nvd.nist.gov/fdcc/index.cfm На данный момент безопасная конфигуррация FDCC существует для Windows XP, Vistа, для других ОС конфигурации не сертифицированы.
Для чего это нужно и почему это стоит тестировать?
Если разрабатываемое приложение продается в государственные учреждения США, то приложение обязано быть жизнеспособным в условиях такой безопасной конфигурации, в частности, работать под пользователями, которые не являются админимтраторами на машине. Так же немаловажно, чтобы во время установки приложения, инсталятор не вносил изменений в безопасную конфигурацию.
Если же необходимо отключить антивирус, firewall, для того, чтобы иметь шанс заставить работать приложение, то продать приложение в государственные учреждения США вряд ли сможете. Т.е. надо отталкиваться от целевой аудитории приложения. Для игр вряд ли когда-нибудь понадобится такой вид тестирования (если это не военные симуляторы), а вот для корпоративных приложений документооборота это может стать актуальным.
После проверки приложения в условиях безопасной среды составляется отчет, в котором указываются найденные во время тестирования проблемы.
Варантов решения два - они стандартные и до боли знакомые:

чинить
не чинить, добавить в документацию информации о проблемах.

Взаимодействие с командой поддержки как средство повышения качества продукта

2011-06-29T01:13:00.001+04:00

Рассмотрим каждое звено взаимодействия и кратко опишем основные функции и уникальные знания о продукте, которые необходимо передать другим командам.
Команда технической поддержки – Support team. Это команда, которая первой принимает на себя поток проблем от конечных пользователей системы, поэтому они являются своеобразным буфером между клиентами и разработкой продукта. Очень важно аккумулировать знания о вариантах использования системы, окружения, в котором работает система. Так же не менее важно собирать информацию о не только о сбоях, но и об ошибках, вызванных неправильной конфигурации системы для последующего анализа.
Команда поддержки – Maintenance team – команда, которая выпускает патчи к существующим официальным версиям продукта. Команда обладает не только знаниями об уязвимых функционалах программы, но и хранит уникальные тестовые окружения, используемые для фиксирования и тестирования проблем.
Команда разработки новых версий – разрабатывает новые версии продукта для удовлетворения меняющихся требований рынка.

Как же поставить процесс взаимодействия команд для достижения максимальной эффективности в гонке за качество продукта?
Рассмотрим иллюстрацию кругового взаимодействия

Процесс взаимодействия клиента и support team начинается с логирования обращения клиента с некой проблемой – consult request. В результате выясняется, чем вызвано беспокойство, а может, и недовольство клиента, в чем причина: неправильная конфигурация системы, нецелевое использование, отсутствие поддержки старого функционала в новой версии, сбой системы или, может быть запрос на новый функционал. В случае неправильной конфигурации или нецелевого использования системы, возможно подкорректировать это дистанционно для удовлетворения и спокойствия клиента. Если же проблема в работе системы, то логируется запрос на исправление проблемы для Maintenance team – fix request. Происходит дальнейшее исследование проблемы – запрашиваются логи, уточняется окружение, в которой работает и взаимодействует система, детализируются настройки и использование ПО. В процессе этого исследования в Maintenance team формируются иногда уникальные по сложности тестовые окружения, поэтому очень важно, чтобы эта команда обладала соответствующими ресурсами как человеческими, там и производственными.
После устранения проблемы формируется патч, который отдается клиенту. В течение определенного времени клиент либо принимает патч, как необходимое решение, либо процесс идет на второй виток.
Когда проблема локализована и устранена, необходимо убедиться, что для других версий продукта (которые еще не выпущены), проблема не воспроизводится. Таким образом, fix одной проблемы попадает в несколько версий продукта – это позволяет предотвратить регресс на стадии разработки новый версий продукта.

Команда разработки, взаимодействуя с командой Maintenance team получает знания о потребностях конечного пользователя и имеет возможность уменьшить общие затраты на построение тестового окружения, необходимого для эмуляции работы системы. Общая база операционных систем, тестовых доменов, виртуальных машин, тестовых нагрузочных лабораториях позволяет эффективно использовать ресурсы.
Также очень важно тесное взаимодействие команд на стадии пострелизной передачи проекта от команды разработки к команде maintenance. Созданная база тестов поможет сформировать локальные регрессионные тесты для тестирования патчей, тем самым снизив трудозатраты.
На стадии разработки при системном тестировании нередко возникают трудности при взаимодействии системы с третье-сторонними компонентами или системами (сервера приложений, базы данных итд). Тонкости настройки и общей интеграции, собранные в отдельный внутренний документ для команды support, поможет в будущем предотвращать и оперативно решать подобные проблемы и сложности, не прибегая к привлечению других команд для локализации и исследования проблемы.
В данном случае мы рассмотрели пример, когда знания и опыт, накопленный любой командой, обязательно передается другим командам, что значительно повышает эффективность. Тесные коммуникации косвенно повышают качество продукта, потому что предоставляют не только знания о реальном использовании системы клиентами, но и за счет общих технологических ресурсов повышают эффектность работы различных команд.

Кто должен нас учить?

2011-06-28T02:00:00.000+04:00

Во многих компаниях предусмотрено обучение за счет работодателя, как метод мотивации и развития сотрудника.
Но вот парадокс, сотрудники хотят учиться и развиваться, но считают существующие курсы и тренинги профанацией - замкнутый круг.
Витает такое устойчивое мнение, что учить других могут лишь те, кто сам очень и очень много добился на данном поприще. Соответственно, те, кто многого добился, слишком занят, чтобы преподавать. А те, кто преподают, сами не добились высот и только теоретизируют. Отсюда недоверие к консультантам и обучающим структурам в целом. На это накладывается незрелость российского рынка образования, который уже перенимает зарубежный опыт, но еще не имеет многогодовой адаптации к отечественным реалиям.
К сожалению, не берется в расчет тот факт, что обладание знанием не равно способности передавать знания другим. Из этого вырастает еще одна крайность: опыт + неумение его передать другим.
Получается, что тренером \консультантом должен быть крайне разносторонний человек: профессионал с большим опытом с одной стороны, и педагог с другой.
Представляете, Плющенко говорит тренеру: Какой же ты тренер, если не можешь прыгнуть четвертной?
Нонсенс! ни один спортсмен в своем уме такого не скажет. И никто не скажет Тарасовой: ты даже не Олимпийская чемпионка!
Но у суровых технических специалистов все по-другому. Требуется особый подход.
Мне очень понравилось как сказал Саша Орлов: тренер должен накапливать опыт своих учеников, чтобы потом этот опыт помогал в обучении последующих учеников. (ну или как-то так)

На этом принципе построен курс MBA (зарубежный). Подбираются слушатели, которые имеют опыт управления в разных областях бизнеса. Важен не только учебный курс, который читается, но и групповое взаимодействие - поиск совместного решения предложенной проблемы на основе разнородного опыта группы. Обмен опытом и знаниями очень важен.
Из этого я для себя могу сделать следующий вывод: для меня важно в обучении, чтобы преподносимый материал был хорошо структурирован, логично и последовательно изложен и подкреплен опытом, практической составляющей. А уж чей именно это опыт: самого тренера или кого-то еще, мне не важно.
И еще - надо внимательно прислушиваться к чужим комментариям по ходу обучения - это ценный источник знаний!

"Managing the Testing Process" - Rex Black

2011-06-23T09:32:00.000+04:00

Мне очень нравится, как пишет Рекс Блэк, поэтому, как вы догадываетесь, я настоятельно рекомендую прочитать эту классическую книжку, пережившую уже несколько редакций.
Разные авторы по-разному преподносят один и тот же материал - теорию тестирования и управления тестированием, однако, каждый стремиться выбрать того автора, чья логика изложения кажется более понятной и стройной. Для меня такой идеальный автор - Рекс Блэк.
Мне очень нравится, что для иллюстрации теории он вводит абстрактный проект, и на протяжении всей книги показывает варианты применения теории. Наглядно, хоть и стократно упрощено.
В общем, присоединяйтесь к клубу любителей Рекса Блэка.
Кстати, для любителей можно скачать для iPod подкасты Рекса Блэка - http://itunes.apple.com/podcast/rbcs-podcast/id338086108

Полный список книг с отзывами на странице Полезные Книги сайта http://lilia-gorbachik.com/

Сертификация ISTQB - за и против

2011-06-22T09:29:00.000+04:00

Прогресс дошел и до меня, я отправилась учиться и сдавать экзамен на ISTQB сертификат.
Оглядываясь назад, хочется еще раз проанализировать плюсы и минусы сертификации как класса и, в частности, ISTQB.

Реалии сертификации ISTQB в нашей стране таковы, что наличие сертификата не дает существенных преимуществ ни при устройстве на работу, ни при определении зар. платы. Это надо четко осознавать, чтобы не наступило горькое разочарование. Да, в других странах - это своеобразный стандарт качества, естественная и необходимая вещь. Но не у нас. Конечно, каждому, кто получает сертификат, грезится это наступающее будущее, когда обладателя сертификата будут носить на руках... Когда-нибудь, возможно, но не в ближайшем будущем. Обладателя множественных сертификатов могут даже причислить к тем, кто стремится только бумажку получить., а не знания (бывает и такое). Вывод: сертификат нужен лично тебе, как средство структуризации теории.
Основные документы при подготовке - syllabus, glossary, а также список рекомендованных книг.
Тренинги по подготовке к сдаче сертификационного экзамена. В России есть только одна официально аккредитованная компания по проведению тренингов подготовки к ISTQB экзамену, именно там мы с коллегами и учились. От нашей компании на тренинге было 4 человека, и все мы ожидали от тренинга одного: подготовки к экзамену с целью получить сертификат, т.е. мы рассчитывали прослушать не только теорию в терминах данной сертификации, но и получить представление об экзамене: какие формулировки, какая логика, какие варианты тестов (натаскивание на тест). Но, к нашему величайшему сожалению, наши ожидания не совпали с целями компании, преподающей курс подготовки. Курс подготовки был рассчитан только на прочтение теории. Из этого я для себя сделала вывод, что курс подготовки полезен тем, кто чувствует недостаточное знание теории.
Подготовка и сдача экзамена на русском языке может представлять определенную сложность из-за того, что те термины, которые мы привыкли использовать по-английски, не всегда однозначно переведены на русский язык. Запоминание перевода на русский язык, разбор глоссария занимает значительное количество времени. Сейчас, имея опыт сдачи на русском языке, могу сказать: надо было сдавать на английском языке и готовиться по книжке. Купленная книжка по подготовке к экзамену была незаменима. Получалась двойная работа - читаешь по-английски, мысленно переводишь на русский, сверяешься с глоссарием, понимаешь, что ничего не понимаешь и идешь на второй круг. Русская терминология упорно не хотела поселяться в моей голове.
Сдача экзамена на английском - для подготовки достаточно будет специализированной книжки, например, "Software Testing An ISEB Foundation". (ISEB и ISTQB имеют общую теоретическую платформу для сдачи Foundation Level.) В книжке четкая структура теории, в конце каждой главы примеры вопросов из теста.
Для подготовки в интернете можно найти множество вариантов теста. В основном это устаревшие вопросы, т.к. тест постоянно обновляется, но все равно это дает представление о логике формирования теста, что очень важно.

Остается вопрос: сдавать ли экзамен на сертификат следующего уровня? Для себя я однозначно решила: ДА!
Правда, для начала надо дождаться, пока по почте придет первый сертификат:)

"IT starts with one" - J. Stewart Black, Hal B Gregersen

2011-06-21T09:30:00.000+04:00

Книга о переменах, важности отслеживания тенденций, способах внедрения инноваций.

Ни для кого не секрет, что одной идеи мало. Есть тысяча способов, как погубить прекрасную идею, но мало вариантов ее осуществить.

Есть те, кто предвидит тенденции,

есть те, кто генерит идеи,

но тех, кто способен реализовать идеи - единицы.

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

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

Интересная книга, достойная прочтения, хотя, местами многовато воды.

Полный список книг можно найти на странице Полезные Книги

Заказчики в коробочном продукте

2011-06-17T10:04:00.000+04:00

Тема взаимодействия с заказчиком, формирование требований и разработка в непрерывном контакте с заказчиком стала очень популярной. Но это в случае разработки ПО под конкретного заказчика. Становится обидно за отрасль коробочного ПО. Как же дело обстоит в этой области?

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

При формировании требований ориентируются обычно на:

маркетинговые исследования
пожелания клиентов (если на рынке уже есть выпущенные версии продукта или есть бизнес решения текущей компании в этой сфере). Пожелания \ потребности клиентов можно узнать от саппота и \ отдела продаж.
конкурирующие продукты

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

Потребности уже существующих клиентов. Здесь все очень сильно зависит от того, каков именно коробочный продукт. Клиентами могут быть физические лица - конечные пользователи, а могут быть корпорации. Соответственно, и поток информации может разниться. Необъятный форум обсуждений продукта для физических лиц или страница пожеланий \ улучшений \ требований, которую весьма трудно добыть из бюрократической корпорации. При взаимодействии с командами саппорта и отдела продаж важно классифицировать и ранжировать полученную информацию. Однако, важно четко видеть стратегию продукта, чтобы продукт не затачивался постепенно под самого крупного заказчика, ущемляя при этом других, более мелких клиентов.

Сравнение с конкурирующим продуктом - весьма распространенный и эффективный метод улучшения продукта или выпуск на рынок нового. Поэтому, не исключено, что вам придется владеть не только своим продуктом, но и одним (или несколькими) аналогичными продуктами конкурентов, сравнивать и выделять самое лучшее у конкурентов, чтобы давать толчок к развитию своего продукта.

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

Poker game широкого спектра действия

2011-06-16T22:08:00.002+04:00

В гибких методологиях, в частности, в Scrum, применяется такой метод оценки трудозатрат, как Poker game. Однако, Poker game становится популярным и применяется не только в Scrum. Основная идея заключается в том, чтобы совместными усилиями всей команды последовательно давать оценку трудозатрат на девелопмент, тестирование и документирование фичи. Каждый участник дает свою оценку, не имея возможности подглядеть у соседа. Когда все участники предоставили свои оценки – «вскрываеются карты» с оценками. Выделяются пиковые значения оценки трудозатрат и те, кто поставил эти пиковые значения пытается объяснить остальным свою логику, в соответствии с которой получилась оценка. С одной стороны, парадоксально. Как тестировщик, или документатор может дать оценку затрат девелопмента? И наоброт, как девелопер может оценить усилия тестировщиков?

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

Помимо основной цели – оценки трудозатрат Poker game несет в себе важные полезные побочные эффекты.

Команда имеет возможность (площадку) для обмена точками зрения. Давно известно и ни для кого не секрет, что тестировщики и программисты по-разному смотрят на вещи (в частности на функционал продукта). Так как представитель программистов, тестировщиков перед началом представления оценок озвучивают свое видение фичи, ее имплементации \ тестирования, то есть возможность сравнить картину мира. Это очень важно и полезно. Тестировщики больше узнают об архитектуре приложения, деталях реализации, что помогает точнее определить стратегию тестирования. Программисты больше узнают о подходе к тестированию, образу и логике мышления тестировщиков, с большим энтузиазмом вовлекаются в процесс обсуждения, например, областей регрессионного тестирования.

Чем больше мы узнаем о командах, с которыми взаимодействуем, тем эффективнее будет это взаимодействие, и проще найти общий язык в будущем.

Частенько оказывается, что понятные термины для тестировщиков (регрессионное тестирование, привнесенные фиксом баги, критические баги) для программистов значат совсем другое. Невероятные расхождения кроются за базовыми терминами. Основной вывод, который напрашивается – используйте все возможности, в том числе Poker Game, для установления взаимопонимания с другими командами.

Моя статья в журнале "Testing Experience" №14

2011-06-15T10:25:00.000+04:00

Я рада представить мою статью "Educating new hire as a part of improving testing process" в журнале Testing Experience #14.

Общая тема номера "Improving the Test Process", а сама моя статья раскрывает возможности улучшения процесса тестирования через обучение нового сотрудника.
Новый сотрудник - новый, свежий взгляд, который поможет в улучшении процессов тестирования в компании. О том, как это возможно, читайте в свежем номере Testing Experience - http://www.testingexperience.com

"Вверх! Практический подход к карьерному росту" - Инна Кузнецова

2011-06-14T12:56:00.000+04:00

Очень структурированная, логично представленная информация о том, как строить вертикальную карьеру. Особое внимание уделено компетенциям и картине мира на разных этапах карьеры. Такого четкого представления о том, как человек должен меняться, если он хочет двигаться вверх я не встречала ни в одной книге. Все советы и высказывания конкретные, нет воды.
шаг от специалиста к менеджеру: надо выработать ...., изменить свое отношение и мышление о.....
шаг от линейного менеджера к менеджеру 2-го уровня: надо выработать ...., изменить свое отношение и мышление о.....
Не "надо работать над собой..." как обычно пишут в книжках, а "вырабатывать умение разрешать конфликты и не прятаться от них, сотрудничать, уметь объединять усилия с менеджерами других подразделений, итд" с примерами. Яркие примеры предельно ясно отражают мысли автора.
Так же затронута темы неравенства и личных внутренних барьеров, которые нужно победить, чтобы идти вверх. Очень тонко подмечены сомнения и ошибки при работе с внутренними установками. Самая яркая фраза:

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

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

Полный список книг и отзывов на странице Полезные книги сайта http://lilia-gorbachik.com/

Почему нам задают странные вопросы на собеседовании

2011-06-13T10:47:00.001+04:00

Наверно, было подобное у каждого: недоумение по поводу цели вопроса. Более того, интересно, как будут интерпритироваться ответы. Собеседование - это стресс, который усиливается, когда тебе задают вопрос, явно не случайный. Но остается непонятным, как ответы будут интерпритироваться и какие ответы правильные.
Каким видом спорта вы увлекаетесь?
Казалось бы, вопрос задан для поддержания разговора, чтобы дать возможность кандидату перевести дух. Не тут-то было! Важные акценты, которые "могут быть использованы против вас" - это вид спорта: командный или одиночный, нацеленный на процесс или на результат.
Увлечение командным видом спорта может охарактеризовать вас как командного игрока, умеющего существовать в коллективе, способного "отдавать пас", играть на общий командный результат. Если вакансия предполагает командную игру, ориентацию на успех команды, такой ответ добавит вам баллов в общий зачет. Так же важно, каким именно игроком в команде вы являетесь. Вы - нападающий, но в тоже время участвуете в разработке стратегии команды. Такой ответ, если вы специалист, охарактеризует вашу готовность перейти в ранг менеджера.
Увлечение одиночным видом спорта охарактеризует вас соотвественно. Это будет оценено положительно, если характер работы предполагает достаточно автономную работу, способность самому планировать свои действия и нести ответственность за результат.
Спорт, нацеленный на процесс. Вы любите плавать перед работой минут 20. Т.е. главное - не результат (проплыть 100 метров за N секунд), а именно процесс, который доставляет удовольствие.
Спорт, нацеленный на результат. Вы любите плавание и проплываете 50 метров за N секунд. Ваша стихия - реализация конечного результата. Здорово! Вам надо озвучить конечный результат и вы будете выстраивать стратегию, ведущую к этому результату. Конкурентная борба - ваша стихия.
Расскажите о вашем самом большом достижении.
Ответ на этот вопрос состоит из двух важных частей: Что вы считаете большим достижением и как вы это достижение преподносите.
В зависимости от того, какие навыки и требования к кандидату, какой характер работы, необходимо видоизменять "легенду ваших достижений".
Первое: Что является достижением? Возможно вы гордитесь какими-то своими достижениями, но для собеседования важно подобрать достижение, которое охарактеризует вас с нужной стороны. Замечательно, если достижения будут представлены из рабочей области, а не из ряда ваших хобби и личных увлечений. Вы ведь пришли искать работу. Так же важно отметить то, почему это достижение вы считаете важным? Какие показатели позволяют утверждать, что это достижение?
Второе: Как преподносить достижение?

Я внедрил новый процесс работы с метриками. По началу коллеги не хотели со мной соглашаться, начальник не мог оценить преимуществ, но я преодолел все преграды, предоставил яркие аргументы, и теперь эта система работает как часы.

Давайте рассмотрим расставленные акценты: главное в рассказе - это ВЫ! Я смог, я сделал - концентрация на личном одиночном достижении. Нет упоминания о командной работе.
"коллеги не хотели", "начальник не мог оценить" - даже если это было так на самом деле, желательно, подобрать более мягкую формулировку, чтобы у собеседника не возникло подозрение на конфликт.
"преодолел все преграды, предоставил яркие аргументы" - если преимущества можно предоставить в каком-то численном или сравнительном виде - это предпочтительнее сделать. например, "я предоставил текущие показатели, выявил слабые стороны нашего процесса, после чего предложил коррекционные меры, призванные в короткий срок улучшить первое, второе, третье, произвел анализ требуемых для коррекции ресурсов и план реализации."
"система работает как часы" - эту фразу также лучше усилить объективными данными.
В заключении хотелось бы отметить, что рассмотренные примеры не стоит вопринимать как правду в последней инстанции. Безусловно, вас не будут оценивать только по любимому виду спорту и любовь к рыбалке - не приговор. Но все же стоит заранее продумать свои ответы и расставить нужные акценты, чтобы убедить собеседника, что при всех прочих равных - вы идеальная кандидатура на данную вакансию, а возможно, задуматься еще раз насколько вам подходит сама вакансия.
Это только 2 примера вопросов из великого множества, что приготовлено для соискателей. Удачи на собеседованиях.

Метрики статические и динамические

2011-06-10T11:20:00.000+04:00

Часто сталкиваюсь с ситуацией, когда метрики неправильно интерпретируются.
В частности, возникает путаница между статическими и динамическими метриками.
Статические метрики показывают текущий срез проекта. Единственный срез - бесполезен. Пытаться объяснить или прогнозировать протекающие в проекте процессы по одному срезу - все равно, что лечить по фотографии. Необходимо с периодически снимать срезы, чтобы по выстроенному на основе срезов графику оценить проект и его перспективы, активности итд. Например, мы решили для нашего проекта начинать снимать метрики: open, fixed, closed bugs. Замерили - записали, послали коллегам. разу возникает вопрос: и ЧТО? Что значит 20, 40, 150? У нас все хорошо или все плохо? Правильный ответ: у нас все только начинается! Если перевести метрики, которые частенько всех смущают, в область более привычную и понятную, то получится примерно так:
допустим, вы купили новую машину, это ваша первая машина. И вот вы первый раз поехали на ней на работу новым неизведанным путем и проехали 15 км за 45 минут. Это много или мало? Есть ведь другие пути, бывают и пробки меньше, а может, и больше. Непонятно.
Непонятно не от того, что вы не знаете, что делать с машиной и как ездить, а непонятно от того, что не с чем сравнить.
Вот когда вы проездите на машине полгода, вы уже сможете сказать, что есть несколько маршрутов, какой-то быстрее, какой-то медленнее, какой-то длиннее, какой-то короче, как объезжать пробки. Т.е у вас появляется опыт.
Метрики, которые показывают срез состояния проекта, как опыт. Чтобы им воспользоваться, надо его накопить.
Динамические метрики - показывают динамику какого-то процесса. Например, Количество закрытых за неделю багов.
Можем ли мы анализировать единичный показатель? Да. Мы знаем состояние, активности, численность нашего проекта, поэтому можем сказать 20 багов на весь отдел - это мало или много. Если 20 багов за неделю, если это стадия тестирования нового функционала в команде из 1-2 х человек - это нормально (может быть, маловато), но если это приемочное тестирование перед релизом, то это много.
Проводя аналогии с машинами, если мы едем по дороге 110 км\час. Это много или мало? Непонятно. Но если мы знаем, что это автострада - то нормально, если это город, то много.

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

"Hunting security bugs" - Bryan Jeffries, Tom Gallagher, Lawrence Laundauer

2011-06-09T11:18:00.001+04:00

Убийственная книжка про уязвимости приложений. Описаны многие виды зависимостей, такие как SQL injection, скриптовые атаки и многие другие. Рассмотрены проблемы назначения уровней доступа в приложении, основные ошибки кодирования, которые ведут к появлению проблем безопасности. Описан подход и логика "злоумышленника".
Книга рассчитана на подготовленного читателя. Признаюсь, понимание некоторых аспектов потребовало дополнительной литературы.
Прочитать стоит, даже если проблемы безопасности не являются в вашем проекте приоритетными. Достойное издание, своеобразная энциклопедия.

Все отзывы о книгах в разделе Полезные книги на сайте http://lilia-gorbachik.com/