пятница, 13 декабря 2019 г.

Гейзенбаг 2019

Было интересно.

Ирина Рубченко, Тинькофф — автоматизация отдела автоматизации

Инструмент для записи тест-кейсов на естественном языке с кликов тестировщика, генерация из этих тест-кейсов кода тестов. Начало — 20 тестов, цель — 1000. Отдел автоматизации не общается с тестерами и разрабами. Код тестов не хранят, генерят на лету с тестов. WAT. TestRail, и убивается версионирование.

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

Александр Воробей, Тинькофф — тестирование микрофронтенда

В начале дал неправильное определение микросервисам (микросервис = отдельный репозиторий, ага. конечно). Затем хорошо и по делу, полезно для инфраструктуры фронтенда, нужно послушать. Говорил слова JEST, Puppeteer, Storybook.

Артём Ерошенко, Qameta Software — визуализация покрытия

  • 15 000 тестов — на 50% больше, чем в команде, с которой я буду сравнивать дальше.
  • 97% стабильность — в 30-300 раз хуже
  • 15 минут на прогон — в 10 раз лучше
  • 800 потоков — в 100 раз лучше
  • Тесты пишут все — аналогично
Инструментирование интерфейса приложения с трассировкой до кейсов в TestRail — до кода. В итоге по хоткею на каждом элементе интерфейса появляется ссылка на все тесты, работающие с ним. Можно делать, когда других задач нет, выглядит красивенько. Применимо в проекте от тысячи тестов. Условно полезная штука с некоторыми минусами поддержки.

Дальше Артём рассказывал про покрытие API.

С помощью EMMA и Cobertura, или что там нынче актуально. API требует 100% покрытия. Затем патчат Swagger цветовой маркировкой: зелёный — метод покрыт, красный — не покрыт. Посчитали покрытие для каждого теста и в Swagger добавили ссылки на тест (вот этот метод покрыт вот этими тестами).

Норм, но:
  • Для апи отлично.
  • Для остального кода нет, так как лямбды.
Доклад — ок, дождаться библиотек и использовать.

Барух Садогурский — DevOps

К просмотру обязательно. Ценное: список практик, список литературы.
Этими четырьмя метриками можно померить любую команду:
  • Time to market
  • Частота релизов
  • Частота факапов
  • Время восстановления


четверг, 28 ноября 2019 г.

Итак, мы съездили в Ростов

Мы уже побывали в Ижевске, Казани, Новосибирске, Питере и Перми.
Муза дальних странствий манила нас.

понедельник, 4 ноября 2019 г.

Итак, мы поехали в Пермь

С очередным митапом.

Когда уезжали, падал прошлогодний снег.


Состав практически тот же, что и в прошлый раз:
  • Ирина Полунина с докладом "Как развестись, но остаться друзьями или зачем тестировать через API, если есть UI"
  • Сергей Махетов с рассказом о том, "Как перехват и анализ трафика помогает в тестировании"
  • Я с новым докладом о жизни "Без менеджеров и тимлидов"
Запись этих докладов мы хотим сделать в Ростове.

воскресенье, 29 сентября 2019 г.

Об использовании статистических методов для оценки сроков

Третьего дня смотрел доклад с teamleadconf о применении Канбан, WIP лимитов и теории ограничений, а также об использовании статистических методов для оценки сроков выполнения задач. Хороший доклад.

В частности. в докладе звучала фраза:
Мы не знаем, когда мы сделаем эту конкретную фичу, но знаем, что за три недели мы сделаем 8 из 9 фич. Это и говорим бизнесу. Так мы сможем не врать и не плодить неоправданных ожиданий.
Попробуем применить к моей реальности и культуре разработки. Сегодня я взял на тестирование задачу, аналитику по которой сделали в феврале. Это не уникальная задача, таких много.
Если кто-то собирается кинуть камень, то я абсолютно точно знаю, что моя команда не единственная, среди продуктовых, у которой подобные сроки разработки фич. У вас либо такие же сроки, либо заказная разработка. Либо вы попадаете в очень небольшой процент продуктовых команд, где реально небольшой time-to-market.
Итак, пытаемся применить метод из доклада для оценки наших SLA.

Бизнесу мы скажем примерно это:
Мы не знаем, когда мы сделаем эту конкретную фичу, но знаем, что за два с половиной года мы сделаем 27 из 30 фич. Не знаем, каких именно. Не знаем, когда именно. Точнее не выходит =)
Интересно, что скажет в ответ бизнес?

Забавно, но именно эта оценка не будет ложью, а те, что обычно звучат — будут.

К чему я?

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





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

А пока продолжим по старинке: переносить дедлайны, резать фичи, слегка обманывать заказчиков и тянуть сроки. Ага?

четверг, 12 сентября 2019 г.

Турне в Казань и Ижевск

Суть коротко

Я и несколько коллег из Контура в прошедший четверг выступили на Izh Tech Talks #6, а в субботу на Kzn Tech Talks #2. Добирались поездами.


вторник, 3 сентября 2019 г.

воскресенье, 28 июля 2019 г.

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

В очередной раз покатался по памятным местам фестиваля.

Сайт и карта для самостоятельного досмотра
### Суть
Ежегодный фестиваль Стрит-арт художников. Круче год от года.

Фотоньки

Около Палладиума впечатленный русскими елочными игрушками англичанин fanakapan создал такое:

пятница, 5 июля 2019 г.

Так

Я обещаю, блог не превратится в репосты смехуечков. Тем не менее:

Kpeдиты, ипoтeкa, влacть, жeнa,
Дocтaл нaчaльник и с дeньгaми глyxo...
И ecли вдpyг cyдьбa пpeдpeшeнa,
To

четверг, 27 июня 2019 г.

Грег Иган, Карантин и Отчаяние

Полгода назад я писал о том, что книга Игана "Город перестановок"  - отличная.

Сегодня я дочитал ещё две книги трилогии Субъективная космология: Карантин и Отчаяние.


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

 
Общая аннотация серии с какого-то сайта:
Три разных истории о разных людях, о разных событиях из разных версий Земли середины двадцать первого века.

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

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

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

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

понедельник, 20 мая 2019 г.

Просто так


Прям да.

А ещё советую посмотреть на офигенный музыкальный разбор хорошей песни Shallow. С шикарным переводом на русский. Начинайте смотреть с 1:29, если интересует только перевод.
 

Напевает:
Расскажи чикса,
Как великой стать за полчаса
Так ли хорошо,
Что всё время мы хотим ешо...

Расскажи пацан
На  раёне ты то счастлив сам
Или на душе
Ничего хорошего вообщЭ


четверг, 16 мая 2019 г.

Дайджест

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

вторник, 16 апреля 2019 г.

UTC



Это только апрель. 

Есть ли в России ещё хотя бы одно некоммерческое IT сообщество с таким качеством и объемом движухи? Такое, что не держится на одном энтузиасте, а создается участниками?

вторник, 2 апреля 2019 г.

Книги по тестированию

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

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

 

Тестирование

ISTQB, Foundation Level, материалы для подготовки.
Слова интеграционные тесты могут значить что угодно. Перед следующими шагами нужно определиться с терминологией.
Lessons Learned in Software Testing, Cem Kaner.
Почти три  сотни историй, справок и советов от очень неглупых людей. Для всех, одна из лучших книг.
ГОСТ Р 56920-2016/ISO/IEC/IEEE 29119-1:2013 Системная и программная инженерия. Тестирование программного обеспечения.
На удивление неплох.
A Practitioner's Guide to Software Test Design, Lee Copeland.
Как придумывать тесты, лучше этой книги ничего нет.
Автоматизированное тестирование ПО, Дастин.
Для а-а-а-автоматизаторов, привет адекватности из прошлого века.

Проектирование

Купер, Об интерфейсе.
У него есть более попсовая психбольница, в этой книге меньше воды, больше примеров и по делу.

Аналитика

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

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

"Про гит"
Это уже гигиена разработки
Шаблоны тестирования xUnit, Месарош
Сколько а-а-а-автотестеров ознакомились с ней?

Процессы

Блэк, Ключевые процессы тестирования
Всё придумано до нас. Наши проблемы уже решали и описали их в большом справочнике.
Голдратт, Цель 1-3
Почему большая очередь на тестирование почти никогда не означает нехватку тестировщиков, как выпускать задачи втрое быстрее и другие удивительные вещи. Осторожно, после прочтения и осознания необратимо меняется отношение ко многим менеджерам.

Чего тут нет

Нет хороших книг по devops и по ITSM, хотя должны быть, наверное. Ещё нет чего-то годного из психологии.

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

пятница, 1 марта 2019 г.

Оценка исполнителем сроков на разработку и тестирование задачи (не нужна)


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

Дорофеев, Эффект выпрямления сроков

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

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

Задача начинает «дымиться», и мы приступаем к ней. Если ничего не случилось, то мы успеваем вовремя, а вот если что-то случилось… Резерв мы на это «что-то» уже потратили и в итоге опаздываем.

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

Демарко, Человеческий фактор

В пятой части первой главы есть ссылки и объяснения исследований.

Коротко: сам факт оценки влияет на сроки в худшую сторону примерно на 40%. Рекомендую прочесть. Все факторы, перечисленные в книге, релевантны до сих пор.

Деминг и Нив, статистика и вариации

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

Упомянутые в заголовке авторы говорят, что верный способ оценки сроков — статистический. Оценивается пакет типовых задач.
У нас все задачи разные.
Это ложь. На промежутке в год будет уже не очень много разных задач. Как правило, такое заявление является признаком отсутствия рефлексии над процессом и невыполнения упражнений: декомпозиция, mvp, прототипы, стандартизация.

Что делать, заказчик же требует сроки?

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

Как правило, ответом на вопрос успеем ли мы к заданному сроку? является аналитика и mvp, качественная инфраструктура разработки и размер техдолга: скорость рефакторинга, наличие автоматической регрессии. Ещё раз, оценка сроков мешает исполнителю успеть к дедлайну.

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

  • MVP.
  • Декомпозиция задачи.
  • Раздельный релиз фронта и бекенда.
  • Канареечные релизы.
  • Фича-флаги.
  • Умение тестировщиков отделять важные дефекты от неважных и умение релизить с неважными
  • Pull стратегия работы над задачами (я говорю о том, что программисту не должны совать новые задачи, пока не вышли старые, даже если над задачей пока работает не он).
  • Много раз слышал о такой стратегии: сперва релиз рефакторинга, который готовит код к появлению новой фичи, затем релиз самой функциональности. По сути, та же декомпозиция.
Если выполнены упражнения и менеджер квалифицирован, то для ответа заказчикам ему не нужно требовать от исполнителей назвать срок.  Если упражнения не выполнены, то с высокой вероятностью, назвав любой срок, менеджер солжет заказчику.

Ты выпадаешь на умняк и учишь жизни, а чего добился сам?

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

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

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

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

В последний раз я задерживался на работе по просьбе менеджера, чтоб выпустить срочную задачу в январе 2017 года. До этого пару раз,  в 2015 и в 2016 году.

P.S. 

Речь идет о продуктовой разработке.



четверг, 21 февраля 2019 г.

Метрика процесса разработки

Максим Дорофеев нашел эмпирическое правило «Число задач в производстве не должно превышать число программистов более, чем на 2».


Предлагаю такое деление команд. Ну или классификацию квалификации менеджеров.

  • Команды А-класса: задач в работе у команды не больше числа разработчиков плюс два.
  • Команды B-класса: число задач не превышает удвоенного числа разработчиков.
  • Команды С-класса: число задач не больше квадрата числа разработчиков.
  • Команды D-класса: не смогли за минуту ответить сколько у них задач.
По этой модели я работаю в команде B-класса.

четверг, 7 февраля 2019 г.

Приговор

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

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

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

понедельник, 28 января 2019 г.

Диксит, Теория игр

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

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

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

Ну и лейтмотив: думай в обратном порядке, с завершения истории к её началу.
К прочтению — рекомендую.

пятница, 25 января 2019 г.

Тест-сессия, седьмая городская

Спасибо компаниям.

В 2013 E96.


В 2014 Яндекс.
В 2015 Контур.
В 2016 Экстрим.
В 2017 Контур.
Хотели в 2018, но перенесли на январь 2019 УБРиР.
В 2019 Контур.


Спасибо организаторам:
Саша А., Юра Р., Оксана В., Дима Я., Игорь Б.,  Настя Р., Семен В..
Теперь плюс Катя В., Наташа С., Антон В., Гриша Г..
Теперь плюс Питер и Новосиб, одновременно.

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

Семь лет, каждый год мы делаем круто и интересно.
Вот и сейчас. Я опять среди оргов.

Регистрируйтесь на седьмую.
Пост в UTC.

четверг, 24 января 2019 г.

Заслуженный артист тестирования

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

  • Сотрудничает с администрацией
  • Работает в сложных условиях
  • Заслуженный артист
Есть ещё идеи? Что-то из этого точно использую.

среда, 23 января 2019 г.

Про экзокортекс (и блокнотики)

История о том, когда мне не нужно компьютеризировать и автоматизировать.

Год назад я писал о том, как работаю с бэклогами. В той статье всё еще больше половины правды.

Есть такая штука в современном дискурсе, как экзокортекс, о нем много пишет Левенчук. Вики:
Экзоко́ртекс (др.-греч. ἔξω [exō] — вне, снаружи; лат. cortex — кора) — внешняя система обработки информации, которая поможет усилить интеллект или выступить нейропротезом для коры головного мозга. Если термин «экзокортекс» понимать расширенно, то можно сказать, что его функции уже выполняются Интернетом, смартфонами, различными гаджетами и что его история началась с изобретения письменности.
Чем дальше в лес, тем больше органическая память становится оперативной, а не долговременной. Плюс индексом к железной памяти.  Дальше текст о том, как у меня работает внешняя память. Чтоб через пару лет сравнить с самим собой.
Стоит отметить, что я наполовину чертов менеджер и много работы у меня в виде встреч, опыт применим не ко всем.

Что я не использую как хранилище

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

YoungGen (время жизни около недели), Micromiles

Micromiles на телефоне, главная задача: разгрузить оперативную память, ничего не запоминать.
  • Любые мысли, которые пришли в голову или в телегу, когда я не у компа. Их потом нужно перенести в остальные хранилища.
  • Напоминалки. Тетрадки, мапки и всё остальное не умеет "напомнить в следующую среду".

OldGen (время жизни полгода), темповый блокнот для всего подряд



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




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

OldGen (время жизни полгода), блокнот по отделу

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

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

PermGen (время жизни не ограничено), файлы в облаке

Все задачи, по которым есть какое-то файло(таблицы, картинки, черновики статей) хранятся в папке месяца. У больших проектов свои отдельные имена.

Файлы стараюсь называть осмысленно, выходит не всегда.

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

Храню файло с 2012 года, научил Саша Ликулин в Наумене.

PermGen  (время жизни не ограничено), мапки

В ней информация по каждому тестировщику и по каждой команде.

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

Веду с 2011 года, по одной мапке на компанию, в которой работаю, научила одна из тестировщиц в Наумене.

Личная библиотека в домашнем кабинете

Когда буду совсем старый и у меня будет много денег (_ага_), хочу, чтоб было так:

Вместо выводов

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

понедельник, 21 января 2019 г.

Лекций и ностальгии пост

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

Мусорное слово "вот" мешает, а тема в 19м кажется несколько более заезженной, чем в 2011.

вторник, 15 января 2019 г.

Самоограничения пост

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

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

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

Прямо сейчас вычеркнул из антибибллиотеки:
  • Максимальный заряд, Том Рат
  • Драйв, Дэниел Пинк
  • Правильный выбор, Хэммонд
  • 45 татуировок личности, Батырев

понедельник, 14 января 2019 г.

Пако Андерхилл «Почему мы покупаем»

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

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

Пара примеров-баек, ярко демонстрирующих идею и поведение.

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

Второй.
Бутылка 2 литра колы стоит 60 рублей, Две двухлитровых бутылки стоит 60 рублей.
"Вот дураки", думает потребитель, и покупает две.

И еще миллионы примеров.




пятница, 11 января 2019 г.

Стивен Кинг, Воспарение

Она же "На подъеме", в оригинале "Elevation".

Хорошая новелла. Светлая, добрая, мотивирующая. В конце все плохие становятся хорошими, в целом даже плохих-то и нет.  К прочтению рекомендую.

P.S. Кажется, маэстро собрался на тот свет. Светлая и добрая книга Кинга, по-моему,эти слова так близко друг от друга не стояли никогда.

четверг, 10 января 2019 г.

Книги 2018

24 книги за 2018 год
14 художественных, 10 нет.
7 аудио, 7 на клиндле, 10 в бумаге.

Еще 17 книг начал читать, но прекратил.

Лучшее:
  • Ильяхов, Новые правила деловой переписки — полезное.
  • Щедровицкий, Оргуправленческое мышление — на подумать.
  • Грег Иган, Город Перестановок — старая добрая НФ.
  • Лалу, Открывая организации будущего — спорное.
  • Норман, Дизайн привычных вещей — вдохновляющее.
  • Энди Вейр, Артемида — ещё одна годная НФ.

среда, 9 января 2019 г.

Ностальгии пост

Раньше и трава была зеленее.
И ачивки были из серебра. Хорошая компания, мне нравилось там работать.