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 часов. Все что выше - вполне валидно, все что меньше - не возможно.

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

17 января 2017

Напочитать: DEV-ственные Heap-стеры


1. нечеткие регулярные выражения - случайно попали в поле зрения (Осторожно, хипстеры! По ссылке sourceforge)
2. Netflix сливает в open-source очередную порцию своих проектов: Hollow и Conductor
3. jcmd прямо в коде. Прикрутил себе кое-куда, удобно чо.
4. О том как ByteBuddy может помочь в борьбе за SecurityManager да и вообше много про SecurityManager в этом бложике.
5. А вот тут можно заглянуть под юбку java разработке в Facebook - jcommons
6. Spring тоже решил ударится об реактивщину (на самом деле давно) - Reactor. Мне это все начинает напоминать JavaScript-мир - каждый задрот на коленке пилит свой новый велосипед, думая что ну вот в его-то исполнении колеса точно будут круглыми. А вот тут вот еще можно посмотреть примеров холодных и горячих  стримов.
7. Надоело наблюдать как все python-ируют на Machine Learning (привет, Coursera)? Не расстраивайтесь, на Java тоже можно. Ну и канальчик от Гугла на ту же тему - вот да.
8. Что  такое service images и executable images и чем они отличаются в Docker? Нет, не подумайте, у меня не докер головного мозга, но вот у некоторых  - да.
9. Конструктор дэшбордиков от NASA - OpenMCT. NodeJS, если что.
10. MutabilityDetector для ваших хипстерских POJO-ей.
11. Огромнейшая простыня про Nashorn - тут.
12. Про то как хипстота из гугла запускает Python на Go - Grumpy.
13. метод 3-I (Isolate-Improve-Inline)  или как правильно рефакторить. Руководство для начинающих хипстеров.
14. failsafe - не hystrix единым.
15. Ну и напоследок  набор хипстерских git alias-ов

28 декабря 2016

Напосмотреть: GTAC 2016

Каждый год я подаю заявку на GTAC и каждый год получаю отказ.
Я уже даже привык.
Но каждый год отсматриваю доклады.

Итак, мой личный рейтинг с GTAC 2016
1. How Flaky Tests in Continuous Integration - собственно говоря гугл решил привлечь математика к проблеме моргающих тестов. Словил несколько инсайтов, буду курить тему дальше.



2. Automating Telepresence Robot Driving - лидар, пластиковый стаканчик и другие трюки для тестирования системы телеприсутствия. В этом докладе нет большой технической жести, но именно так выглядит тестирование будущего (или будущее тестирования ? ). Таких доклады вдохновляют работать дальше.



3. Using Test Run Automation Statistics to Predict Which Tests to Run - доклад о том на какие ухищрения приходится идти когда запуск тестов длиться долго, а тестировать все равно нужно. В принципе ничего нового, гугл о таких практиках у себя рассказывал еще в 2012 году, но поражает масштаб - словить проблемы запуска всех тестов с которой гугл борется на масштабе 3,5 миллионов тестов и 125 миллионов выполнений тестов в сутки можно и на 30 000 тестов.  Понятно, что Unity  - не Google, финансовая и ресурсная база разные, но кто ж вам гарантирует что вы не окажетесь в подобной ситуации с 10000 тестов. It depends (c)




Ну и еще пара интересных докладов:
Finding Bugs in C++ Libraries Using LibFuzzer  - отличный рассказ про методики фаззинга, теоритическая часть очень понравилась.
OpenHTF - The Open-Source Hardware Testing Framework - ребята из гугла продолжают биться за автоматизацию, в том числе и на железе. Python (не, ну а что еще можно запихнуть в железяку? ), SL4A (про который Сергей Высоцкий рассказывал еще в далеком  2013 в Киеве), плагины.



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

Anyway GTAC остается самой значимой (лично для меня) конференцией  в мире в области автоматизированного тестирования.




Сайт конференции 
Плейлист со всеми докладами.

14 декабря 2016

Напочитать: про уродов и людей


2. Как правильно негативно фидбечить подчиненных - спорно по ряду моментов, но тем не менее.
3. Про недостаток скуки у подростков  и что из этого выходит.
4. Про наказания и как с этим быть менеджеру.
5. Серотонин снижает восприимчивость отрицательных явлений, эндорфины вызывают эйфорию бегуна и другое интересное про нейромедиаторы (1,2,3)
6.  Замечательная Camilla Fournier об обратной стороне (сторонах) инженерных организаций.



И ковыряя ее выступление наткнулся на описание карьерное лестницы инженера в ее компании.(тут вот еще документик и поясниловка, очень интересно да).

7. Об синдроме самозванца (impostor syndrome )


Ну и в качестве десерта мысль от Хенрика Книберга
Here’s the thing. Suppose you introduce a change X to your workplace, and then business improves noticably. That doesn’t mean X caused the business to improve. Well, MAYBE it did. Or perhaps business improved for other reasons, and X was actually detrimental, and business would have improved even more without it. So did things work out well because of the great X, or despite the lousy X? You’ll never know, unless you could rewind the clock and play out the same scenario without X. Correlation doesn’t imply causation.

So people like me who work with organizational change, we are in the business of pseudo-science. We get customer feedback and anecdotal evidence, but we can’t actually prove that we are doing any good, it’s just opinions and observations and guesswork. I think that’s fine, but let’s be honest about it 🙂