О квалификации

ТОП-5 докладов TED о HR.

Доклады интересные, занятные. Спикеры - мастера своего дела.

Но меня всю дорогу не покидало чувство, что что-то не так.  Какие-то они слишком софт скиллс. Ну или "пиздеть - не мешки ворочать".

Вам знаком тест?

 1) Вы знакомы с беременной женщиной, которая уже имеет 8 детей. Двое из них - слепые, трое - глухие, один - умственно недоразвитый, сама она больна сифилисом.
Посоветуете ли Вы ей сделать аборт? Но прежде, чем ответить на этот вопрос, ответьте на другой.

2) Происходят выборы мирового лидера и Ваш голос - решающий.
Краткие характеристики кандидатов:
а) Связян с политиками, уличенными в мошенничестве, постоянно консультируется с астрологом, имеет двух любовниц, курит трубку и выпивает каждый день 8-10 мартини.
б) Дважды вышибали со службы, имеет привычку спать до полудня, в институте был уличен в употреблении опиума, каждый вечер выпивает бутылку виски.
в) Герой войны, вегетарианец, изредка пьет пиво, не курит, ни в каких матримониальных связях не замечен.

Кого же Вы выбираете? Ответили?
Тогда еще два слова о кандидатах.

а) Уинстон Черчилль
б) Фрэнкли Д. Рузвельт
в) Адольф Гитлер

Вот теперь Вы готовы ответить на самый первый вопрос. Если Вы посоветовали сделать аборт - Вы только что убили Людвига ван Бетховена.

Пример подобной манипуляции из речи одного эйчара на TED.

Дама задает вопрос - а стали бы вы брать на работу или сотрудничать с больным дислексией (проблемы с чтением и письмом)? И тут же добавляет. что  в США 35% успешных предпренимателей больны дислексией, как бы намекая, что зря вы отказались в предыдущем вопросе.

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

Корреляция отличается от причины.

Если среди этих же успешных людей провести вдумчивое исследование, то выяснится, что например 45% из них нюхали кокс и были замечены в супружеской неверности.
И даже если бы 100% успешных людей были больны дислексией, это не означало бы высокую вероятность того, что человек с дислексией станет успешным.
И прочий матан.

/me продолжает читать Нисбетта, главу про эксперименты.

Стенограффия отчет

Итоговый счет - 32 километра, трек.
Задача выполнена практически в полном объеме, пропущено по разным причинам всего пара объектов.

Фотки под катом

Стоя на плечах гигантов, Эли М. Голдратт, 2008

Чем дальше в лес, тем крепче моя убежденность в двух вещах.

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

Из этого следует масса перпендикулярных выводов. Можно, конечно, наращивать объем и эффективность 15% полезных действий годными технологиями и инструментами. Хотя иногда от этого бывает столько пользы, что лучше уж уйти в тайгу и жить молитвами.

А можно избавиться от 85% ерунды.

Стоя на плечах гигантов, Эли Голдратт.

Автор рассказывает о применимости и неприменимости бережливого производства и пути Toyota на примере Hitachi, а также о том, чем  являются и не являются Лин и Канбан.

Ну, мы все это знаем. Это когда мало складов, just in time и доска с карточками. Почему у нас не используется? Мы попробовали, нам не подходит, хотя часть практик мы взяли. Например, у нас есть доска. И нет складов, мы же в IT. И вообще некогда, у нас дедлайн, а это все бесполезные теории.

Что меня впечатлило больше всего

В 1926 году производственный цикл** от добычи железной руды до получения готового автомобиля** (состоящего более чем из 5000 деталей), находящегося на железнодорожной платформе и готового к отправке, достиг **81 часа**!

Нецензурно восхищается

О главном

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

Канбан - это не когда доска и карточки, это когда не больше одной задачи в работе и одной на складе.

Приоритеты

Независимо от того, как организована официальная система определения приоритетов работы над заказами, реальная система приоритетов выглядит так: «срочно», «крайне срочно» и «бросьте все, делайте вот это!».

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

Оценка

Факты:

• Оценка увеличивает время выполнения задачи
• Оценка отдельной задачи врет

Нам важно знать, когда задача будет закончена и мы будем оценивать.

Ценность - время

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

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

За неделю я минимум дважды слышу что-то вроде: 

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

К чему это все

Опыт - не образование. Здравый смысл - не знание.

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

Элияху гораздо более убедителен, чем я. Прочтите статью.

Рассказ Людвига Быстроновского «Как я выхожу из тупиков»

Намедни посетил двухдневную лекцию.
Остался доволен. Далее - впечатления, выводы и пополнившийся список литературы на будущее.

Впечатление

Как всегда - очевидное о жизни. Как обычно - лектор уложил интуитивное и очевидное в структуру. Ощущение - "именно эти слова я искал" и "я такой же".
Почему нет? Мне понравилось.

Конспект первого дня.

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

Людвиг пользуется тремя эвристиками, помогающими преодолеть тупняки и совершить прорыв.

• Контринтуитивное. Решить вопрос противоречащим интуиции способом. снимать носок за пятку. Есть сахар по утрам, чтоб не есть торты вечерами. Часто есть, чтоб похудеть. 
• Ошибки мышления. Читать о ошибках мышления, находить их в себе и, осознавая, искоренять.
• Получать системные знания. Когда знаешь, как все работает на самом деле.

После этого еще два этапа.
Первый - отработка техники. Второй - изменение мировоззрения.

II.  Программа для ведения финансов YNAB.
Принципы:
Не контролировать и ограничивать, а помогать понять свои приоритеты и заранее положить в них деньги

• тратить деньги из прошлого
• непредвиденные статьи
• понять сколько ты можешь не работать

III.  Схема планирования дня.
По большей части о книге: Марк Форстер, Do it tomorrow
Суть: 

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

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

IV. Мелкие советы: 

• дубликаты вещей
• программа альфред
• postnauka.ru
• оценивать работу по когнитивной нагрузке
• научиться медитировать

Конспект второго дня.

I. Что делать с ощущением неуспеха?

Найти человека, с которым можно поговорить

Читать литературу о когнитивных искажениях и психологии. Зачем - чтоб получить право на нормальность.

Примеры головняков, которые вешают родители: "шапка", "мы не смогли, но ты".

II. Как избавиться от сверхконтроля за подчиненными?

Давать больше возможностей. Дать планировать бюджет.

Давать право на ошибку.

Чаще проводить не финальное, а промежуточные демо.

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

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

Не брать долги. Совсем.

• Денежные
• Технические
• Управленческие

Не обещать, что все будет хорошо. Все будет плохо и поменяется.

В случае смертельного марша - спасать людей, а не проект.

 Список литературы

Мастхэв:

• Марк Форстер, Do it tomorrow
• Ричард Нисбетт, Мозгоускорители

Остальное:

• АРИЗ Интеллектуальное айкидо
• Правила игры без правил
• Щедровицкий , Оргуправленческое мышление
• Фрит, Мозг и душа
• Кэтмелл, Корпорация гениев
• Хоровиц, Легко не будет
• Лич, Вовремя и в рамках бюджета
• Бек, Когнитивная терапия
• Арнхейм, Искусство визуального восприятия
• Байстер, Искусство видеть паттерны
• Румельт, Хорошая стратегия, плохая стратегия
• Люттвак, стратегия. Логика войны и мира

Статья Болтона "Проблемы тестирования – это результаты тестирования"

http://software-testing.ru/library/testing/general-testing/2562-testing-problems-are-test-results

И референс к предыдущей впечатлившей меня статье: вам не нужно больше тестировщиков.


Оригинал статьи: http://www.developsense.com/blog/2011/09/testing-problems-are-test-results/
Автор: Майкл Болтон (Michael Bolton)
Перевод: Ольга Алифанова

В курсе Rapid Software Testing я даю студентам такое упражнение: я прошу их перечислить все, что, с их точки зрения, усложняет или замедляет тестирование. Их ответы, как правило, однотипны – я регулярно слышу одни и те же вариации (пример таких ответов можно посмотреть, к примеру, в обсуждении на Stack Exchange). Обычно это примерно следующий перечень:

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

И, в плюс к вышеперечисленному,

• Компания, в которой я работаю, утверждает, что работает по Agile
• Помимо двухнедельных итераций, на самом деле мы применяем максимум пару практик, относящихся к Agile-подходу – как правило, ежедневные scrum-встречи или канбан-доски.

И вишенка на торте:

• Приходящие на тестирование билды очень нестабильны. Система падает при самых базовых smoke-тестах, и мне приходится ждать и/или пересобирать билд вместо того, чтобы заниматься своим прямым делом.

Как можно проанализировать эти наблюдения?
Мы можем расценивать их, как проблемы тестирования, но мы также можем взглянуть на них иначе – как на результаты тестирования.
Результаты тестирования не говорят нам, что что-то пошло хорошо или плохо. Они поставляют информацию для принятия решений, оценки, и тому подобных вещей. Люди, получающие результаты тестирования, решают, есть ли в продукте проблемы и в чем они заключаются, что еще надо выяснить, и какие решения принять. Это требует участия живых людей, оценки множества факторов, и нескольких возможных интерпретаций.
Так же, как и в случае с автотестами и другими результатами тестирования, очень важно принимать во внимание  весь спектр возможных причин и интерпретаций мета-результатов тестирования – наблюдений, касающихся тестирования. Если мы этого не делаем, то рискуем упустить важные проблемы, угрожающие качеству как тестирования, так и продукта как такового.
Джерри Вайнберг в своей книге "Perfect Software and other illusions about testing" отмечает, что то, что мы получаем в качестве результата – это прежде всего информация. Если тестирование, по словам Джерри – это сбор информации с целью ее передачи лицам, принимающим решения, то нельзя оставлять за бортом потенциально значимые наблюдения.
Тестируя, мы часто сталкиваемся с теми или иными проблемами. Однако вместо того, чтобы относиться к ним как к проблемам для тестирования, мы можем также думать о них, как о симптомах проблем продукта или проекта – проблем, которые тестирование может решить.
К примеру, если тестировщик страдает из-за большого количества разработчиков, или если тестировщику не хватает времени на тестирование – это результат теста. Зачастую это ощущение вызывается тем, что программисты генерируют столько сложных задач, что тестировщик просто не может справиться с ними в одиночку. Сложность, как и качество – это взаимоотношение между человеком и чем-либо еще. Сама по себе сложность необязательно будет проблемой, в отличие от реакции людей на нее. Наблюдая за тем, как люди реагируют на субъективную сложность и риски, мы можем узнать много полезного.

• Помогаем ли мы, как тестировщики, коллегам иметь представление о рисках – особенно о "Черных лебедях" – которые обычно ассоциируются со сложностью?
• Если люди представляют себе риски, обращают ли они на них внимание? Паникуют ли они, или просто игнорируют в надежде, что все образуется? Или что-то другое?
• Реагируют ли люди спокойно и прагматично? Признают ли они сложность продукта, пытаются ли с ней справляться?
• Если сложность продукта или процесса нельзя снизить, предпринимается ли что-то для того, чтобы сделать продукт/процесс проще для понимания?
• Случается ли, что программисты пишут или изменяют код так быстро, что у них просто нет времени разобраться, что же там на самом деле происходит?
• Если кто-то полагает, что команде нужно больше тестировщиков, почему он так думает? (Я обсуждал этот вопрос несколько лет назад)

Как же найти ответы на эти вопросы? Один из способов – внимательно посмотреть на результаты и мета-результаты тестирования:

• Считает ли кто-то в команде, что тестирование затруднено или занимает много времени? Кто?
• Почему он так думает, какие предположения привели его к этой мысли?
• Не ухудшается ли тестовое покрытие от того, что тестировщики тратят много времени на исследование, локализацию и оформление багов? (Я писал об этой проблеме ранее).
• Выявляет ли тестирование единообразные паттерны отказов?
• Систематически ли эти отказы и их паттерны удивляют программистов?
• Вызывают ли небольшие изменения кода большие или трудноуловимые проблемы?
• Хорошо ли программисты понимают внутренние взаимосвязи продукта? Необходимы ли продукту эти взаимосвязи, или их можно избежать?
• Предпринимают ли разработчики какие-то шаги для предотвращения или предупреждения проблем, связанных с интерфейсами и взаимодействиями?
• Если автоматические проверки трудно разработать и поддерживать, говорит ли эта ситуация об уровне профессиональных навыков тестировщиков, качестве интерфейсов автоматизации, или масштабе проверок? Или она сигнализирует о чем-то еще?
• Мешают ли нестабильные билды глубокому тестированию?
• Можно ли интерпретировать нестабильные билды как знак того, что в продукте настолько много серьезных проблем, что их можно найти даже при поверхностном тестировании?
• Если после череды нестабильных билдов наконец-то появился стабильный – насколько он на самом деле стабилен?

Возможно, получив ответы на эти вопросы, мы можем задать еще больше вопросов.

• Как эти проблемы угрожают успеху продукта в краткосрочном и долгосрочном периодах?
• Если тестирование систематически выявляет паттерны отказов и сопутствующих рисков, что делает команда с этой информацией?
• Обязаны ли программисты только и исключительно предоставить код, или они обязаны предоставить код с гарантией, что этот код делает то, что должен (и не делает того, что не должен), насколько им известно? Насколько искренне программистам предпочтителен второй вариант?
• Заставляет ли кто-то программистов выдерживать сроки/объемы работ, в которые они на самом деле не могут уложиться?
• Могут ли программисты и тестировщики противостоять навязанным им срокам и объемам работы, если эти сроки повышают продуктовые или проектные риски?
• Прислушивается ли бизнес к опасениям команды? Знают ли они о рисках, найденных тестировщиками и разработчиками? Когда команда разработки указывает на существующие риски, предпринимает ли менеджмент/бизнес адекватные шаги в ответ на это?
• Работает ли команда в комфортном режиме, или продукт/проект серьезно задавлен сложностью, внутренними взаимосвязями, хрупкостью и трудностями, находящимися за пределами возможностей разработки/тестирования справиться с ними?
• Действительно ли команда работает по Agile, соблюдая манифест Agile? Может, "гибкость" используется как карго-культ – практики и артефакты только маскируют бестолковость проекта?

Тестировщики зачастую считают, что их задача – искать, исследовать и сообщать о багах в тестируемом ПО. Обычно это так и есть, но такой взгляд на тестирование крайне ограничен. Продукт – это все, что кем-то произведено: программа, требования, диаграмма, спецификация, график, прототип, процесс, идея… Тестирование может искать информацию о любых продуктах, если им уделяется достаточное внимание.
С одной стороны, проблемы, перечисленные в начале этой статьи, выглядят серьезными проблемами тестирования. Возможно, это так, но это не все, что за ними стоит. Если вспомнить определение Джерри Вайнберга – "тестирование – это сбор информации для передачи ее людям, принимающим решения", окажется, что абсолютно все, что мы обнаруживаем и замечаем в процессе тестирования – это результат тестирования.

О проектах

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

Пратчетт, "Патриот" 

Не так давно слушал доклад Паши Егорова, рассказывающего о ценности специалистов, умеющих вести проекты над специалистами, воркающими в рамках процессов. Надеюсь, он опубликует доклад, он того стоит.

Кстати, определение:

• Проект – это временное предприятие, предназначенное для создания уникальных продуктов, услуг или результатов (PMBoK)
• Проект — предприятие (предпринятие) с определёнными датами начала и завершения, предпринятое для создания продукта или услуги (сервиса) в соответствии с заданными ресурсами и требованиями (ISO/IEC/IEEE 15288:2008).
• Проект — предприятие с предопределёнными целями, масштабом и длительностью (ISO/IEC 2382-20:1990).
• Проект – это последовательность взаимосвязанных событий, которые происходят в течение установленного ограниченного периода времени и направлены на достижение неповторимого, но в то же время определенного результата (Фил Бэгьюли).

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

Я делю свои проекты на два вида:

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

Сегодня посчитал блудняки, в которые я вписался или анонсировал, вышло больше десяти, разной длительности, от недели до пары лет. Это к вопросу о том, зачем в эпиграфе Ветинари и жонглирование.

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

Проекты - закончатся, но останутся в памяти и опыте. Процессы - эффективный инструмент. Образ жизни - то, чем я являюсь.
Хм.

Стихи

Оксана Мельникова:

Забывают лица, слова и даты,
Но живёт веками один сюжет:
Не забыть того, кто тебя когда-то
Так и не сумел полюбить в ответ.

Олег Ладыженский

Разбиты стекла в нашем витраже
И не помогут жалобные речи.
Пора учиться тверже быть и резче,
Пора учиться говорить: -- До встречи!
И знать, что мы не встретимся уже.

Imagine Dragons Evolve

Черт возьми, офигенно.

Особенно:
Whatever It Takes
Believer
Yesterday
Thunder

Встреча сообщества, новые проекты и всякое

2 июня прошла встреча UTC - про подведение итогов, раздачу слонов и новые горизонты.

О самой встрече
Самая многочисленная.
Неудавшаяся, но все же состоявшаяся экскурсия по яндексу.
Раздача книг
Миллионы стикеров и позитив.
Лично для меня встреча закончилась на плотинке в 5 часов утра следующего дня.

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

Больше пары проектов все равно не запустим. Очень не хотелось бы понижать планку.
Сам я стараюсь отходить от роли организатора проектов в сторону консультирования и активного участия.

А ведь у нас уже есть заготовки пары тест-сессий, ролевой игры и выезд.
Будет интересно.


DUMP-2107
Доклад на дампе, который я делал с Леной и Иларией:

Гейзенбаг

Третьего дня просмотрел трансляцию конференции Гейзенбаг.

Суть коротко: конференция определенно стоит того, чтоб купить ее трансляцию и не дотягивает до поездки.

Особенно хотелось бы отметить доклад Николая Алименкова Паттерны проектирования в автоматизации тестирования.

В докладе Николай пройдётся по всем известным паттернам и подробно опишет их с несколькими практическими примерами.

Рекомендую просмотреть.
Основную и самую ценную мысль Николай сказал в самом начале. Своими словами:

Вы не сможете купить и внедрить инструмент автоматизации, фреймворк, CI, автотествы. Вы обязаны купить и внедрить принципиально иной подход и отношение к разработке.

Нет времени

- Почему ты не читаешь книги?
- Я очень хочу, но не хватает времени.

- Почему ты не ведешь курс по заведению багов?
- Я очень хочу, но не успеваю, очень много задач.

- Почему ты закроешь этот техдолг?
- Менеджер не выделяет времени.

- Эта полугодовая цель не сдвинулась с места, отчего?
- У нас были срочные задачи.

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

Майская прогулка 2017

Итого: проехал маршрут на 70, итоговый счет 96км.
Несколько лет  назад майская велопрогулка родилась от майской пешей и была именно прогулкой - неспешным коротким заездом по интересным и красивым местам города.
Затем, по тем или иным причинам, организаторы поняли, что велопрогулки - не для них и решили сосредоточиться на том, что умеют и любят - пеших прогулках.

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

У которого абсолютно свое представление о велопрогулке.
Лозунг пешей прогулки - "Испытай себя" - заиграл совершенно новыми красками.
Больше километра набора, грязь, броды и неслабые апхилы - все включено.

Те, кто привык к прогулкам - были нимало удивлены. Остальные отдохнули так, как любят.
Фото.
1.

2.

3.

3.

4.

5.

6.

Больше фото.

GTD, прокрастинация, личная эффективность и книги

Намедни освоил новую, модную книгу Максима:

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

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

Совсем недавно прочел другую, но похожую книгу:

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

Прочтите обе. Хуже не будет. А вдруг - поможет?

DUMP 2017

Дамп 2017 - особенная для меня конференция.

Лучшая и последняя (в которой я был организатором секции тестирования).

Почему лучшая?

• Вообще, отдельной группы организаторов - не было. Практически каждый докладчик был в оргкомитете, просматривал, выбирал, помогал создавать доклады. Секцию сделало сообщество.
• Мы готовились намного серьезней. Идеи, репетиции, прогоны начались еще в сентябре-ноябре прошлого года, за полгода до начала конференции. Ничего не делалось в последний день.
• Докладов, которые я хотел бы выкинуть - в этот раз не было. Но самый значимый для меня - "UTC. Первые шаги.", то, что сообщество сделало за год.
• Я встретил тех, кого хотел встретить и тех, кого давно не видел. Познакомился с Олей Назиной, в конце концов.
• И да. Меня шикарно поздравили.

Почему последняя?

•  Дамп перестает быть городской конференцией. Уже меньше четверти докладов от местных рассказчиков. Это неизбежное развитие, но в качестве СНГшной конференции для тестеров лучше SQA Days.
• Не могу сформулировать точно, но есть ощущение, что из Дампа ушла разработка. Мобилки, тестирование, дизайн остались. И менеджмент. И девопс. А разработки нет.
• Я выбираю определенные доклады, даю конкретные советы. И сделаю секцию именно такой. Не лучше, не хуже. А секции нужно меняться. Теперь ваша очередь делать тестирование на Дампе.
• Не стало бесплатного бухла.

P.S. Доклады хороши. Но сильно зацепил один -  "Профессиональное выгорание" от Орлова Александра.

30

Поздравление от сообщества:

И Наумен передает привет:

Шикарно.

Отчет по дампу, рефлексия о подготовке и всякое такое с фотками - позже.

Язык шаблонов. Города. Здания. Строительство

Авторы книги:
Кристофер Александер, Сара Исикава, Мюррей Силверстайн.

Как выглядит:

Хорошее описание есть на сайте Артемия Лебедева.
Небольшая цитата оттуда:

«Язык шаблонов» — одна из самых значимых книг XX века, которая до сих пор не издавалась на русском, хотя оказала сильнейшее влияние на развитие дизайна, проектирования, архитектуры и компьютерных наук, в том числе объектно-ориентированного программирования.

Источник: https://www.artlebedev.ru/izdal/yazyk-shablonov/

«Язык шаблонов» — одна из самых значимых книг XX века, которая до сих пор не издавалась на русском, хотя оказала сильнейшее влияние на развитие дизайна, проектирования, архитектуры и компьютерных наук.

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

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

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

Дальше - картинки.

Вторая часть эксперимента Да́ннинга — Крю́гера

Все в курсе про эффект. На всякий случай, вики:

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

В целом как-то так:

Третьего дня открыл для себя вторую часть эксперимента.

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

 Звучит, как неплохой тест - проверить, с кем ты работаешь и общаешься. И себя.
На способность изменить мнение, если ты умнее, чем думал. Или тупее.

Лекция Сергея Мартыненко

Спасибо Насте Ронжиной и проекту Контура "Гуру на Урале".

Тервер на службе менеджера:

ROI от автоматизации тестирования:

Следующий тренер - через год.

Бремя белого человека

 Оставлю здесь себе на память.

Вслух

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

- Квентин, а вам не кажется, что вы так и не сняли ничего лучше "Криминального чтива"?
- А кто снял?