27 апреля 2017

Напосмотреть: Продуктовые грезы

Про продуктовую разработку, культуру и жизнь в продуктовых компаниях.



1. Олег Щеголев про то как живет внутри SEMrush



2. Болезненная тема - быстрый рост компании и как меняются процессы - бесценный опыт от CarPrice



3. Обратный пример - маленькая компания которая живет монопродуктом на очень сложном рынке и со своей спецификой.




4. Максим Дорофеев про буферы и планирование.


А если хочется окунуться в эту тему поглубже то вам сюда

13 апреля 2017

Напосмотреть: Подрывные инновации






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


1. Энтони Голдблум о том как машины отнимут нашу работу



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



3. О том что нас ждет в эру посткапитализма и причем тут open source рассказывает Джейми Добсон



4. О том что такое Dark Design Patterns я узнал года три назал, но вот тут вот есть шикарная подборка.



5. Совершенно восхитительное выступление на тему Clean Disruption - если этот парень прав хотя бы на половину, то мы будем жить в очень интересное время.

30 марта 2017

Книга: Debfriefing Facilitation Guide by Etsy


"Технологии - нормальные, это люди - мудаки»

Б.Садогурский, Разбор Полетов


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

Эти самые ретроспективы, after-action review и как бы они еще не назывались (имя им Легион) постепенно врастают в культуру, и некоторые организации начинают пристально смотреть на то, что вросло в их культуру.

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

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

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

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

Собственно говоря, книга раскажет (при том весьма поверхностно)  о том как проходят дебрифинги  в Etsy и как они пытаются встроить обучение в это вот все.

Научится делать эти самые дебрифинги по книжке вы вряд ли сможете, но сможете посмотреть на то как выглядит довольно самобытная практика фасилитации в большой организации
Вообще тема человеческого фактора и человеческой ошибки исследована чуть менее чем нихера и пожалуй  одним из пионеров в этой области и является Сидни Деккер, кучей ссылок на книги которого пестрит миникнига (в частности https:// www.youtube.com/watch?v=PVWjgqDANWA).  

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

Most traditional accident investigations tend to focus on discovering things around an event that never actually happened. In an attempt to prevent future accidents, there is an underlying assumption (Shorrock, 2014) for this somewhat peculiar emphasis, which is:

Someone did not do something they should have, according to someone else.

Through this lens, what generally surfaces in investigations are “findings” about what people did not do (pay attention, make the right decision, etc.) rather than what they actually did. Without anyone really noticing, these items get labeled as “human error” and through a seductive and convenient contortion of logic, an event that never actually happened is deemed after the fact as the “cause” of the accident. Perhaps unsurprisingly, this results in an obvious recommendation for the future:

“Next time, do what you should.”

Unfortunately, this approach does not result in the safer and improved future we want.

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

21 марта 2017

Напосмотреть : HR : Кризис (пере)оценки


Асхат Уразбаев про то как измерять эффективность IT-специалистов


Интересный рассказ от Яндекса на тему организации школ для подготовки специалистов. Некоторые цифры мне кажутся весьма спорными (ну или я не знаю до конца как считали), но вот про воронки - соответствует тому что я вижу.



В продолжение темы оценки и ревью - опыт коллег из Badoo про внедрение процесса оценки



Пара коротких видео-шпаргалок от Crisp:
 про размеры команд и процессы с этим связанные


про ловушку утилизации ресурсов



Отличный доклад с иллюстрацией когнитивных искажений в организациях



Оценивайте своих коллег по заслугам 

15 марта 2017

Про GTD

Этот пост я порывался написать давно, и так или иначе меня просили его написать(«слушай, интересно, напиши, почитаем») разные люди, долгое время. Крайним в очереди оказался Барух Садогурский.

Преамбула

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

Почему она есть ?
Потому что «дефицит приносит ясность» как говорилось в одной книге про Гугл, а люди думают что у них дефицит времени, а у специалистов это думание про дефицит времени развито особо сильно.
Время хорошего специалиста (это я про любого специалиста, не только про IT) стоит дорого, всегда и везде.
Это знает его работодатель (если таковой у него есть), это знает сам специалист, это знают его клиенты.
Поэтому работодатель стремится загрузить специалиста по полной (resource-utilization trap в химически-чистом виде) ,  специалист старается сделать как можно больше работы (особенно, если он работает на себя), ну а клиент- тут и так понятно, пытается отжать либо как больше времени спеца за свои деньги, либо как можно больше пользы для себя.

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

Тайм-менеджмент.

Видит он там именно эту самую фразу, сопрягаемую с кучей книг, тренингов, методик.
Книги, тренинги и методики довольно разные, и у каждой есть какой-то круг приверженцев/адептов/последователей, которым она подходит.
Иногда там еще есть такое словосочетание «личная эффективность», но такую тему шевелить мне противно, даже палочкой и издалека.
А вот чего нет и вот что самое главное, что я хочу донести.
Никакого тайм-менеджмента или управления временем нет.
Просто, блядь, нет.
Выдохните, успокойтесь и можете читать дальше.
Управлять временем нельзя - вы не можете его замедлить, остановить, ускорить, отмотать назад, взять в банке в кредит или положить под процент.
В ваших сутках 24 часа, каким бы вы специалистом не были, равно как и в сутках  папуаса с Новой Гвинеи тоже 24 часа, но по что ему, папуасу, об этом знать ?

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


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

Система v 0.1

Я был студентом и начал работать.
Но учится я хотел продолжать бесплатно, а для этого учится надо было хорошо.
Осложнялось все тем что работа находилась ровно на противоположном конце Москвы от ВУЗа.
Когда-то тогда, на третьем курсе и родилась моя первая, естественная система управления задачами.
Состояла она из одного Excel-файла с табличкой типа:
Предмет, Задача, Срок, Приоритет, Доп. инфа, Выполнено

Табличка создавалась раз в семестр, по окончании семестра и сдачи сессии, напиваясь, я ритуально ее удалял.
С такими табличками я закончил институт, сдавая по меньшей мере половину экзаменов автоматом и работая не менее 20 часов в неделю.
Это работало. Через год (это я сейчас уже осознаю)  у меня произошел первый срыв этой системы , продлился он недели 2, и вот тогда я понял что эта система вывозила меня целый год.
Собрал себя, загнал в эту систему обратно и закончил ВУЗ.

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

Система v 1.0

Еще пока я учился и работал в Auriga, я познакомился с Максимом Дорофеевым, который поведал мне о книге Дэвида Аллена Getting Things Done.
Точнее так, я про нее слышал и до этого, но речи Максима в курилке Auriga стали той каплей, которой не хватало до критической массы, чтобы реакция пошла.

В тот год я прочитал две книги - «7 навыков высокоэффектиных людей» Стивена Кови и «Как привести дела в порядок» Дэвида Аллена.
Я могу смело и честно сказать, что эти книги меня изменили, но не берусь оценить какая больше.Я рассматриваю их как систему: Кови рассказывает верхнеуровневую философию, а Аллен - показывает тебе конкретные приемы только для одного из разделов этой философии.

Итог - в 2010 году я «ударился» об GTD.
У меня в памяти остались несколько воспоминаний  о том периоде.
Одно из самых ярких - когда ты осваиваешь привычку вытеснять из головы во Входящие любые задачи.
В какой-то момент я поймал себя на том что даже 2-минутные задачи вытесняю туда - уж так мне нравилось понимать и документально фиксировать то, что я что-то не продолбал.
Потом этот перегиб прошел.
Второе самое значимое что появляется - это свободная голова.
Мало кто из вас скорее всего ей обладает, а если это и бывает - то скорее всего случайно.
Восхищает не само состояние свободной головы, а то что оно искусственное и управляемо тобой.

В качестве инструмента для своей тогдашней системы я выбрал Outlook.
Да-да, это офигенный почтовый клиент.
Задачи у меня были в виде писем которые я слал сам себе, и далее рассортировывал из входящих  на папки Действия, Документы, Контроль и МодетБыть/КогдаНибудь.
Что очень круто в Outlook - это офигенная интеграция с календарем и (даже!) заметками OneNote.


Система v 1.X

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

В общем ваша система будет регулярно ломаться, вы ее будете чинить и переделывать.
И это нормально.
В свою систему v 1.0  я вносил очень много всяких улучшений, часть из них отмерла, часть из них стабильно живет со мной по сей день.
Например, управление чем-то что чуть больше чем один проект по Аллену я вынес в MindMap-ы (Xmind, Freemind).
Даже у моей текущей системы ( равно как и у всех предыдущих) есть один вроженный недостаток который обуславливается мною - я не люблю работать с календарем, потому что не люблю быть загнанным в сроки.


Система v 2.0

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

Точнее даже вот как  - понять я это понял сильно раньше, чем у меня в руках появился нормальный инструмент для того чтобы сделать другую систему.
Сейчас я использую MaxDone (бывший Micromiles), пробовал Remember The Milk и другие инструменты, но не прижились.
Для управления проектами и неструктурированной информацией я продолжаю пользоваться XMind, но в нагрузку к нему у меня появился Evernote за деньги.

Что изменилось в моей системе 2.0 :
1. Я научился пользоваться контекстами выполнения задач и планировать на контекст - работая  в компании, которая размазана на три локации  это, наверное, не удивительно.
2. В ней почти нет календаря - точнее есть , но календарь живет отдельной жизнью.

Система 2.X - GTF

По аналогии с Getting Things Done у меня возникла аббревиатура GTF (Getting Things/Them Fuck) - это когда твоя система управления задачами заточена на то, чтобы другие люди выполняли задачи, которые являются строительными блоками твоих проектов. Да, вы все правильно поняли - это для менеджеров и про менеджеров.

Вот уже почти два года я менеджерствую - то есть управляю людьми и процессами, и код практически сам не пишу - только по большим праздникам и выходным.
Это отразилось на системе.
В моей системе появилось много регулярных задач - еженедельных, ежемесячных, ежеквартальных - повторяющихся.
В моей системе 1.0  было очень мало задач в папке Контроль - теперь у меня нет папки Контроль, но есть куча задач проконтролировать что-то.
Работа с контекстами расширилась и углубилась - ты набрасываешь себе задач на работу в конкретной локации и оценивая список задач (попутно умножая его на 2 - потому что на месте вылезет еще что-то)  можешь прикинуть на сколько дней тебе нужно ехать.
Сказать, что инструментально GTF чем-то отличается от GTD - нельзя.
Ты просто в ту же систему суешь несколько другие вещи.
Ты суешь контрольные точки  и дэдлайны по проектам, ты суешь в цели различные степени зрелости(этапы) продукта.
Это не какая-то новая оформленная система, это мутация старой.
Система помогает выполнять задачи из проектов, но проекты управляются этой системой только частично. Часть информации находится во внешних системах - Jira, Wiki, XMind прочее.

Что дает GTD

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

Самое главное

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

Ну а тем кто дочитал этот первый в истории уютненького лонгрид - ачивка - вы молодцы!


14 марта 2017

Напосмотреть: Лицекнижие

Большей частью про тестирование.

1. Кирилл Толкачев о том в какую правильную позу надо ставить Jenkins особенно если ты часть кровавого ынтерпрайза





2.  Неочевидные подходы к обеспечению качества путем анализа архитектуры (осторожно, UML), коммитов и работы кода в продакшене.

кстати говоря код их поделия можно посмотреть здесь


3. Продолжая тему Jenkins и то сколько там вокруг граблей и как это все натягивать на суровую разработку





4. Про то как в Яндексе пишут автотесты прямо в браузере





5. Концентрат мудрости - Алексей Лупан про обучение тестировщиков




В завершение два видео от Facebook на тему автоматизации тестирования Android и IOS.

IOS


Android

27 февраля 2017

Книга : Planning as a social event - Scaling Agile at LEGO, Henrik Kniberg

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

Будут мысли:

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

1. Читая эту книжку в уме всплывали ГОСТы которыми нас дрючили в моей первой alma mater, и корявые описания артефактов и инструментов RUP, которыми дрючили во второй alma mater.
Вывод из всей книжки далеко не свежий - agile-методологии хреново масштабируются. Да и вообще с чего бы им масштабироваться хорошо ? Все инструменты устремлены в заказчика и команду, и в то как навести мосты любви и дружбы между ними, а не в то как это сделать в случае с N командами, где N>2.

2. Коллективный сеанс планирования длительностью в два дня на 4 итерации разработки по две недели (два месяца, в итоге) как практика - что еще может лучше иллюстрировать эквивалентную стоимость хренового планирования и издержек, которые несет организация по этой причине. Выдернуть 50-80 человек из процесса написания и поставки кода на два дня - эти расходы можно очень просто посчитать. Видимо издержки от непроведения такого мероприятия сильно выше (принимая во внимание масштабы операционной деятельности Lego можно смело сказать что они запредельно выше). Итог: план - ничто, планирование - все.

3. Очень интересный момент, что менеджеров заставляют напрямую работать с рисками выявленными при планировании командами по ROAM-фреймворку (Resolved, Owner, Accepted, Mitigated). Очень интересно, что само планирование - является ответственностью команды, а адекватность планов и учет рисков  - зоной ответственности менеджмента. Итого :  менеджмент нужен.

4. Из четырех итераций три посвящены самой разработке, а четвертая - буфер для инноваций, рефакторингов, и просто для того чтобы успеть. 25% плана - в буфер.  Суровая реальность.



Собственно сама книжка вот тут.

А вот тут все про тоже выравнивание только уже от Мартина Фаулера - тоже очень интересно.

21 февраля 2017

Напосмотреть: Девелоперско-попсовый

Подобралась пачечка попсовых девелоперских тем.



1. О том что такое CRDT но человеческим языком и с картинками



2. Отличный рассказ о том что есть Kotlin и каковы его возможности. После этого рассказа даже я ударился об хипстерство и попробовал.




3. Dan North в очередной раз про микросервисы, но вот тирады про "Costs" и "Fits in your head" просто  заставляют меня поставить это видео в выпуск.


4.  Умный дядька про распределенные системы



5. О том что такое gRPC , зачем оно вообще надо, в двух частях (вторую найдете сами :))

13 февраля 2017

Напочитать: Мобилизация автоматизированного тестирования


1. О том как расширять Calabash с помощью UIAutomator рассказывают ребята из Badoo
2. Что такое Robolectric и надо ли оно вообще - от eLegion.
3. Потестировать свой сайтик на соответствие представлениям гугла о верстке мобильных сайтов теперь можно за счет самого гугла. Детали тут.
4. LinkedIn выкинул в open source BluePill - свою приспособу для параллельного запуска тестов на IOS.
5. Подборка онлайн-курсов по мобильной разработке - врага надо знать в лицо.
6. Курсы яндекса по мобильную разработку, интерфейсы и дизайн - тут.
7. Про то как тестируют в Cloudera: mrunit  для unit-тестирования Map-Reduce Job и Fault-Injection Testing
8. Gremlin-ы для тестирования пользовательского интерфейса - старая идея Monkey Testing в новом обличии
9. Помните макросы в MS Word/Excel ? Google вмутил тоже самое у себя - Google App Script.
10. Пацаны из SpringTest окончательно упоролись (хотя казалось бы куда уж дальше, и так Spring) и начали писать вложенные друг в друга тесты. И все бы ничего, но эти же поцы причастны к JUnit 5 (Lambda), так что скоро это станет стандартом де-факто пойдет в массы .
11. Dex Test Parser или как LinkedIn борется с граблями Android разложенными в области тестирования. 

07 февраля 2017

Книга: Agile Ретроспектива

Собственно соучаствовал в издании, пора бы и отчитаться за труды.


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

Книга Дианы Ларсен и Эстер Дерби никак не претендует на звание фундаментального труда.
Скорее методичка для "отчаянных агилистов", которые забыли про ретроспективу .

Что смутило с самого начала и не отпускало до конца книги - пример ретроспективы которую команда проводит за час и каждый раз у команды новый ведущий.
Итак, что предложит вам книга:
1. Общее описание процесса ретроспективы
2. Каталог активностей (упражнений)  для каждого этапа, сопровождаемый комментариями а-ля "умелый фасилитатор-самоучка".
3. заключительные мысли.


За что книгу можно похвалить:
1. за хороший каталог активностей (упражнений). Действительно их там не мало, по сравнению с книгой Норма Керта. Особенно понравилось , ИПОЗ.
2. Мысль о том что "день рождения - это ваша ретроспектива которая всегда с вами"  - блеск.
3. Менять помещение для свежего взгляда - тоже очень хорошая мысль, проверял на практике сам.


За что книгу хочется поругать :
1. Утверждения о целях на ретроспективу - на мой взгляд, это скорее редкость. Обычно ретроспектива и служит для поиска цели, а не отталкивается от нее.
2. Примерные выкладки по времени ретроспективы, вида "недельная итерация -часовая ретроспектива" - бред. Существует нижний предел времени, меньше которого ретроспективу (качественно!) провести невозможно, и он, по моим наблюдениям, в районе 1,5-2 часов. Все что выше - вполне валидно, все что меньше - не возможно.

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