Так, значит, я не зверь.

— Ты сам отверг закон людской и Божий!
Зверь, самый лютый, жалости не чужд.
— Я, леди, чужд. Так, значит, я не зверь.
— О, чудо — дьявол истину изрек!

 Ричард III (Уильям Шекспир)

Пять пороков команды

Ленсиони "Пять пороков команды".

Третьего дня дочитал сабж. Неоднозначное чтиво.

Вес бортового залпа

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

А побеждает всегда почему-то информированность, точность прицела и вес бортового залпа.

Вроде бы из книги "Параллельные дневники Виталика Туманова".
https://bash.im/quote/405237

Двойная звезда

 Третьего дня дочитал Двойную звезду Хайнлайна.

Описание с какого-то сайта:

Герой романа — талантливый, но не слишком удачливый актер, Лоренц Смит — человек очень далекий от политики, по существу типичный обыватель по взглядам, втягивается в историю, где ему приходится более, чем играть выдающегося политика его времени так, чтобы его не могли отличить от настоящего самые близкие настоящему люди.
Эта роль требует полного вживания в образ, и Смиту удается осуществить его настолько достоверно, что он и сам проникается политическими идеями и образом мыслей своего прототипа. Это в корне меняет всю его жизнь и судьбу. И не только его.

После Звездного десанта и очерков маэстро о политике - книгой разочарован. Я получил приключенческий боевичок о том, как артист устроил подставу.

Я ждал от Хайнлайна серьезного изменения, перерождения персонажа - как раз то, что он описал на последней странице книги.

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

Этого я в книге не нашел.

Цитата на прощание:

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

Концептуальное

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

Для примера послушайте Будет заваруха. Да там все прекрасно.

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

• Юнона и Авось
• Эльфийская рукопись
• The Wall

И после института:

• Орфей и Эвридика
• Моцарт

Кстати, все перечисленное - к прослушиванию рекомендую.

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

Вот и сейчас...

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

А на прощание - цитата из Брига:

Сегодня тебе нравится Гендель. А завтра - ни хуя... Кого за это пиздить - Генделя? Не надо никого за это пиздить. Это, вроде как, отражение внутреннего твоего развития. Прогресс, регресс там или вообще деградация. И оттого перестает тебе нравится виртуоз Гендель. И глыба Толстой. И пронзительный Левитан. А начинает тебе нравится дурь Рахманинова, ехидство Достоевского и еблан Пиросманишвили. Это они в иерархиях своих - на разных полках, в разных купе и разной значимости. Это пидоры культуроведы им рейтинги раздают. А внутри у меня - они так вот и обитают... Либо нравятся. Либо нет. Потому и живут вместе группа "Ленинград" и Бетховен. Шекспир и Веничка Ерофеев. Леонардо Да Винчи и безвестный мудила с Красного проспекта, который нарисовал однажды мою ненаглядную так, что я и сейчас на этот портрет дрочу.

Mindware, Нисбетт.

Собственно:

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

К прочтению - рекомендую.

Антибиблиотека через год

Год назад я писал пост про антибиблиотеку, о том, что я хочу прочесть, но еще не прочел. Итог:

Не прочел:

• Разработка требований к программному обеспечению, Вигерс
• More Agile Testing Lisa Crispin
• The Human interface, Раскин
• Системоинженерное мышление, Алиев
• Дизайн привычных вещей Норман
• Организация как система, Деминг
• Рождение идеи, Боно
• Эффективный управляющий Друкер
• Найти идею, Альтшуллер

Прочел:

• Джоэл о программировании, Спольски 
• Психология влияния. Чалдини
• Человеческий фактор, Демарко
• Современный методы описания функциональных требований к системам, Коберн

Через пару недель составлю новую.

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

ТОП-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. Однако книга все равно стоит прочтения.
Максим миллион раз подчеркивает, что быстрей и эффективней работать нужно не для того, чтоб работать больше, а для того, чтоб работать меньше. Как мне кажется, подчеркивает недостаточно.

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

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

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

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