Доброе субботнее утро:) Как и обещал  - много всего про технический долг. Долго растекаться мыслью по древу не буду. Скажу лишь, что с техническим долгом можно жить и вполне себе сносно справляться, если отнестись к нему серьёзно, но лучше бы всё-таки не быть должным, потому как техдолг - это кредит, а не рассрочка, а значит будут проценты, а следом будет технический дефолт. Я помню момент, когда в одной из контор, где мне довелось работать, на одной из команд был совокупный долг по оценкам в комадогод. Т.е. по сути шансы на его устранение были почти равны нулю. Тем не менее - покривлялись, отприоритизировали, кое-что признали вечным долгом, кое-что выкинули с пометкой - это не долг, в итоге решили этот вопрос. Но больше так не запускали ситуацию.  

Хотел найти видос от Бориса Вольфсона (он тогда ещё был техдиром ХХ) "
Стратегия сокращения технического долга” , но не смог:( Если подвернётся - обязательно посмотрите, но есть видос от Антона Бевзюка с аджайлдэйс 2014 - http://talks.rosalab.com/20140321-54

Также тему техдолга неплохо осветил Максим Шульга, а главное - в конце стать куча ссылок на хорошие материалы. https://www.maxshulga.ru/2014/03/technical-debt.html - не смотря на то, что  все материалы  написаны до 2014ого года, менее актуальными они не стали.

Ну и тем, кто совсем решит разобраться и изучить максимальное количество точек зрения на этот вопрос - обещанный лонгрид https://www.infoq.com/minibooks/emag-technical-debt. Очень много букв и разных точек зрения. Для скачивания попросят зарегистрироваться, не переживайте - Инфоку не сильно спамит рассылками и всегда можно отписаться, а материалы там попадаются периодически очень интересные.

До завтра!

Привет!

https://medium.com/@krisgage/8-things-i-learned-reading-50-books-a-year-for-7-years-cb11c4acffb1 - статья, так сказать, на ход ноги и в тему каналов и чатов, где публикуют избранные, если можно так сказать, материалы. Они экономят кучу времени и защищают от откровенного треша. Это статья от чувака, который прочитал больше !!300!! книг за 7 лет и решил поделиться с нами своими соображениями. Имхо очень по делу, слегка самокритично и с хорошими мыслями и заключениями. Понятно, что на вкус и цвет, понятно, что все мы разные, но иногда пара мнений со стороны может сэкономить кучу времени и сил. Я сам неоднократно начинал читать и бросал, не осилив и трети, потому как понимал, что не моё. По правде сказать, были случаи, когда я возвращался к отложенной книжке и дочитывал. Скорее всего я достигал нужного уровня просветления, либо понимания сути вопроса.


Всё. С вами эту неделю был я, Роман Ивлиев. Спасибо, что терпели меня! Надеюсь, что я не разочаровал:) Вести такой канал - это серьёзный и сложный, но очень полезный труд. Я честно перечитал всё, что опубликовал, прошерстил свои списки статей, которые когда-то были помечены, как крутые и интересные и …. выкинул в корзину 2/3 по причинам, которые описал коллега по ссылке выше:))))

Всего вам доброго и до новых встреч!

Фб, твитер, тг: @dumtest
почта: roman@ivliev.info
скайп: roman.ivliyev

З.Ы. важная новость для тех, кто гоняет или планирует гонять GraphQL в своих проектах.

https://techcrunch.com/2018/11/06/facebooks-graphql-gets-its-own-open-source-foundation/

GraphQL, the Facebook -incubated data query language, is moving into its own open-source foundation. Like so many other similar open-source foundations, the aptly named GraphQL Foundation will be hosted by the Linux Foundation.

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

На этой неделе выделенного ведущего нет. Если чувствуете в себе силы и желание повести канал сейчас или в будущем – пишите @etolstoy, поставлю вас в план.

Привет, пока нет нового ведущего, я буду подкидывать иногда что-нить интересное, так что если что  - это @dumtest:)

Для затравочки достаточно познавательная и с высокой моралью история ООП. Вы же не забыли ещё, что это такое? Автор - Эрик Эллиот - активист всяких там сооществ, автор книжки про программирование на джаваскрипте и просто дюже толковый чувак. Обязательно прочитайте каменты к статье - там тоже много интересного. https://medium.com/javascript-scene/the-forgotten-history-of-oop-88d71b9b2d9f

Привет! Просто интересная заметка о строка кода и тестах в Oracle Database 12.2 и рассуждения автора и комментаторов на эту тему. Просто оцените масштаб цифр https://news.ycombinator.com/item?id=18442941

Всем пятницы. https://www.youtube.com/watch?v=McCgpTONOV8 - Ролик с одного из http://codefreeze.ru/ об ещё одной важной части инжереной деятельности. Борис Вольфсон (долгое время был СТО hh.ru) об эффективных ретроспективах. Имхо процесс крайне важный для команды, даже если вы не адепт гибких метолодогий. Покопаться в сделанном и не сделанном крайне полезно. Два часа на просмотр, поэтому под выходные:)

Всем привет! На этой неделе, каналом буду рулить я, Федоров Никита, известный как @nik3r.

По традиции представлюсь и расскажу немного о себе. В IT кручусь уже больше 8 лет. Последний год работаю в Avito как техлид юнита Billing. Отвечаю, как можно понять из названия юнита, за биллинговую систему, а так же за оплату услуг и интеграции с платежными провайдерами. До Avito работал техлидом в компании RuCenter, отвечал за разработку практически всего веба.

Предыдущие ведущие, @glamcoder и @dumtest, высоко подняли планку качества постов, поэтому буду стараться не опускать её и делиться максимально полезным контентом.

Обсуждать увиденное тут призываю в чатике для тимлидов "Боль Тимлида" (https://t.me/TeamLeadTalks), я там тоже есть. Если есть желание обсудить что-то лично, пишите мне, с удовольствием отвечу тоже  (@nik3r).

Для разминки поговорим немного про такую важную штуку, как целеполагание.

В Авито, для работы с целями, мы уже несколько лет активно используем систему OKR, которая внедрена на уровне всей организации. Про то, как это устроено у нас, очень подробно рассказал Денис Дудоров на одном из митапов: https://www.youtube.com/watch?v=49Yz59e2yfc

На тему OKR написано огромное количество статей и гайдов. Приведу несколько:
• https://medium.com/@robingop/целеполагание-с-помощью-okr-7934ac3d7303 - хорошая вводная статья, объясняющая что такое OKR и зачем они нужны.
• https://habr.com/company/wrike/blog/329272/ - хорошая статья с конкретными примерами.
• https://rework.withgoogle.com/guides/set-goals-with-okrs/steps/introduction/ - гайд от гугла по постановке целей используя OKR (en).

И в догонку - шаблон OKR для быстрого старта. Отлично подойдет, если захотите попробовать внедрить у себя в команде/компании:
https://docs.google.com/spreadsheets/d/1-5y32GQKyshg9GUXjIreyuzI0DXnPOmv9BHqeurY4G0/edit#gid=0

А вот про следующий подход, как мне кажется, знают не многие, потому что информации о нем в интернете представлено очень мало. Это то, как устроено целеполагание в небезызвестной Spotify.  В определенный момент времени, они отказались от постановки целей через OKR и разработали собственный фреймворк стратегического планирования «Spotify Rhythm».

Если кратко описывать его, то можно выделить 3 основные сущности, которые используются для определения целей во всей компании:

Company beliefs - основа модели, описание видения того, каким будет мир вокруг компании через 3-5 лет.
North Star - верхнеуровневые цели компании на ближайшие 2 года.
Bets - конкретные инициативы и проекты. Они бывают разного уровня - компании, функциональные или рыночные. Для запуска нового проекта, используется фреймворк DIBB (Data-Insights-Belief-Bet).

Чуть более подробно посмотреть можно на слайде с одной из презентаций: https://blog.crisp.se/wp-content/uploads/2016/06/Spotify-Rhythm-Agila-Sverige.pdf

Небольшая статья о преимуществах работы по такому подходу: https://hackernoon.com/place-your-bets-4022b732ba4c

Сегодня хочется поговорить про инженерную культуру Google, компании, которая подарила миру невероятное количество инструментов, практик, подходов и продуктов.

Начнём, пожалуй, с такой важной темы как инцидент-менеджмент. А если конкретнее, то про анализ инцидентов и предупреждение их в будущем.

Рано или поздно, любая компания переходит на стадию, когда подход «быстро поднятое, упавшим не считается» перестаёт работать, потому что каждая минута простоя сервисов выливается в крупные финансовые потери. И бизнес не хочет, чтобы такие количество таких инцидентов в будущем было минимальным. Google, как очень крупной компании, это было сверхактуально и они разработали свой подход к сбору и анализу ошибок - написание postmortem’ов.

Что это такое: это детальный документ, в котором описываются все подробности случившегося инцидента: статус, impact, как решели проблему, как развивался инцидент с подробным таймлайном, конкретные action items и уроки, которые вынесли из него. Многие компании подхватили эту практику и используют у себя. Хорошим тоном считается публикация postmortem’ов в открытый доступ, для того, чтобы другие компании могли учиться не только на своих ошибках, но и на чужих.

Что почитать на эту тему:
• https://landing.google.com/sre/sre-book/chapters/postmortem-culture/  - оригинальная статья от Google
• https://landing.google.com/sre/sre-book/chapters/postmortem/ - пример конкретного Postmortem’a.
• https://github.com/danluu/post-mortems - большая подборка postmortem’ов от разных компаний, собранных в одном месте и сгруппированных по типам проблем.

Автор последнего поста не очень часто обновляет подборку, но в pull request’ах можно найти свежие ссылки от сообщества.

Небольшое чтиво перед сном, в продолжение предыдущей истории. В Авито у нас тоже есть практика написания Postmortem’ов на инциденты. Но, очевидно, что сами себя они не заполнят, не оценят убытки и не определят конкретные action items. А ещё нужно их как-то классифицировать и понимать, какой инцидент нужно разбирать, а какой нет. Для этого нужен определенный процесс.

За основу мы взяли процесс LiveSite Review, родившийся в недрах компании Microsoft. Это часть большой культуры LiveSite. Про неё мы поговорим чуть позже. Вернёмся к инцидентам. На LSR мы выносим инциденты, которые соответствуют хотя бы одному из следующих критериев: привели к потере денег, деградации сервиса или потере данных. Заводится тикет в Jira, который назначается на техлида определенного юнита (обычно на того, в чьей зоне ответственности произошёл инцидент). Он либо сам заполняет postmortem, либо делегирует кому-то из команды.

В раз в неделю, овнер процесса LiveSite Review, составляет список инцидентов на разбор и собирает на встречу людей, которые так или иначе связаны с ними. На эту встречу приходят с уже заполненными Postmotem’ами и совместно челленджат action items - действительно ли они помогут избежать проблем в будущем. После встречи action items берутся в работу.

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

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

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

И так, что почитать?

1. База
https://simulator.gopractice.ru - интерактивный курс по управлению продуктом на основе данных от Олега Якубенкова. По своему опыту могу сказать, что это лучшее вложение денег в образование, которое я когда-либо делал.

2. Unit economics
https://khanin.info/blog/85 - хорошая вводная статья про юнит-экономику. Вообще можно почитать блог автора статьи, пишет достаточно годные вещи.
https://medium.com/@MBGilroy/early-stage-saas-unit-economics-596c90af23e6 - юнит-экономика для стартапов

3. Customer Development
https://www.ozon.ru/context/detail/id/34432645/ - прекрасная книга, которая рассказывает что такое cusdev, как правильно его проводить и интерпретировать результаты. Советую начать погружение в тему именно с нее.

4. User stories
https://medium.com/@alexandertvar/как-писать-user-story-2410093b23c2 - хорошая статья, про то, как правильно писать User Stories.
https://www.lucidchart.com/blog/how-to-create-a-user-story-map - в дополнение к предыдущей.

5. Value proposition
https://optinmonster.com/32-value-propositions-that-are-impossible-to-resist/ - для лучшего понимания, что такое ценностное предложение, нужно смотреть на примеры. В этой статье разобраны 32 VP от разных компаний.

Это далеко не все, тема очень глубокая. Если интересно, накидаю еще - напишите об этом в чатик тимлидов (https://t.me/TeamLeadTalks).

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

https://youtu.be/-LvCJpnNljU - рассказ о том, как устроен процесс разработки в Microsoft в командах работающих над Visual Studio. Очень рекомендую к просмотру.

https://www.youtube.com/watch?v=TNGkMvggc7I&t=1642s - Kanban не стоит на месте, а продолжает развиваться и эволюционировать. Хороший доклад от Леши Пименова с последнего AgileDays про то, что новенького в методе. Бонусом идут несколько полезных инструментов.

https://youtu.be/5Etw2TpEKlk - доклад Алексея Паршукова с митапа тимлидов в Skyeng. Классная история про масштабирование разработки и переход от функциональных команд к кросс-функциональным.

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

Zero Bug Policy
@dumtest в предыдущих постах уже упомянул этот подход. В авито мы внедрили его около года назад и работает он на ура. Для того, чтобы это завелось, нужно выполнить два условия:

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

https://medium.com/qualityfaster/the-zero-bug-policy-b0bd987be684 - хорошая вводная статья, с которой можно начать погружение.
https://medium.com/swlh/how-we-got-to-zero-bugs-and-implemented-a-zero-bug-policy-c77ee3f2e50b - история внедрения техники в одной из компаний

Risk-base Testing
Интересная практика, достаточно популярная на западе и не очень на просторах бывшего СНГ. Мы начали применять ее относительно недавно и только в одном юните в качестве эксперимента, поэтому говорить о результатах рано. Статьи подобрал хорошие, поэтому не буду их подробно пересказывать:

https://www.performance-lab.ru/blog/testirovanie-na-osnove-riskov - основательная статья с подробным описанием самой практики, а так же истории ее возникновения.

https://www.softwaretestinghelp.com/risk-management-during-test-planning-risk-based-testing/ - будет хорошим дополнением к предыдущей статье, содержит примеры.

Всем привет!
С одобрения автора канала, расскажу про свой небольшой pet project, которым занимаюсь в свободное время последние два года: https://qase.io. Это облачная Test Case Management System (пока без standalone версии). Проект потихоньку развивается и уже можно полноценно использовать его в работе.

Что есть сейчас:
* Работа с тесткейсами и сьютами
* Общие шаги для кейсов (shared steps)
* Составление тест планов
* Тестовые прогоны по планам
* Работа с дефектами
* Интеграции с Jira и Redmine (на подходе Slack и YouTrack)

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

Про новый функционал периодически рассказываю в телеграм канале https://t.me/qaseio и в блоге на медиуме https://medium.com/qase. Фидбэк и вопросы по приложению можно кидать мне напрямую - @nik3r 🙂

Подходит к концу мое дежурство в качестве ведущего на этом канале. Напоследок хочется рассказать про одну интересную штуку. Кто-то может читал её - «Гайд для новых сотрудников Valve» - https://steamcdn-a.akamaihd.net/apps/valve/Valve_NewEmployeeHandbook.pdf. Что же в нем примечательного? А то, что те инструменты и практики, которые сейчас горячо обсуждаются на коференциях у нас, на западе давно само собой разумеющееся. Холократия, самоорганизующиеся команды, performance review и так далее. Все это у них было в 2012. И думаю, что много чего нового есть сейчас.

Если вы знаете интересные или нестандартные подходы и практики, вставайте у руля канала и делитесь ими и личным опытом с сообществом! Пишите @etolstoy.

Всю эту неделю с вами был @nik3r. Надеюсь, что не разочаровал и вы нашли для себя что-то действительно полезное.

Фб: https://www.facebook.com/nikita.fedorov.351
Почта: nik333r@gmail.com

Привет, это @dumtest! Воспользуюсь тишиной и подкину достаточно интересный с моей точки зрения материал  - https://labs.spotify.com/2014/09/16/squad-health-check-model/ - рассказ (с примерами, которые можно скачать) Spotify о squad health check model (каждый переведёт в меру своей испорченности).  Суть в том, что ребята выбрали для оценки несколько самых важных критериев  деятельности команды, придумали светофорную градацию состояний  и вынесли на доску для наглядности. Имхо просто и очень наглядно.

Всем привет! Эту неделю канал буду вести я, Андрей Гоменюк.
Немного обо мне. Начинал с сайтов на CMS больше 10 лет назад, потом пара стратапов про конструкторы сайтов, а с 2011 работаю в бэкэнде Badoo. Последние года 3-4 на должности тимлида.

И сразу к делу!

В первой статье на сегодня автор делится впечатлениями о книге “Как работает Google”. Основные мысли посвящены тому, что при найме нужно искать тех, кто постоянно учится (learning animals), и как потом их удерживать. Мысль про поиск тех, кто постоянно учится, кажется простой и правильной, но как таких искать? По своему опыту, большинство компаний на собеседованиях просто убеждаются в том, что у человека есть нужные знания. Некоторые засчитывают за плюс, если человек не знал, но вопросами/рассуждениями пришел к ответу. Единицы специально заводят человека туда, где у него нет ответов, и наблюдают. Собственно, сама статья здесь https://medium.com/@gilligan_conor/the-learning-animals-how-training-your-staff-retains-them-4481ca43a3dc, но и саму книгу рекомендую.

Вторая статья посвящена культуре в компании. Если в двух словах, то автор строит модель 2х2, где по одной оси отложены навыки/компетенции, а по другой ценности/культурное соответствие. Получаются 4 квадрата: классные и компетентные, классные и некомпетентные, компетентные засранцы и некомпетентные засранцы. Автор рассматривает в отдельности все 4 квадрата, но на мой взгляд, самая важная идея - не держать в компании компетентных засранцев. Я бы даже перефразировал так: как только вы поняли, что человек в культуру не вписывается, с ним надо расставаться, каким бы компетентным он ни был. А еще проще: научиться понимать на этапе собеседования, впишется человек в компанию или нет. Сама статья здесь https://medium.com/s/company-culture/your-companys-culture-is-who-you-hire-fire-and-promote-c69f84902983.

Интересно, а без какого (одного) качества вы точно не готовы взять человека на работу? И есть ли качества, при наличии которых вы точно не возьмете человека на работу?
Предлагаю все обсуждения и ответы на вопросы переносить в чатик "Боль Тимлида" (https://t.me/TeamLeadTalks), либо лично @andreygomenyuk.

Полагаю, все здесь знают, что такое 1-1 (или one on one, 1:1, один-один, тет-а-тет). Я считаю, что этот формат общения — один из самых важных инструментов в рукаве тимлида/руководителя, но очень недооценен. Про него обе сегодняшние статьи.

Мне 1:1 довольно долго не заходил, пока я где-то не наткнулся на хороший материал про этот формат (к сожалению, найти его уже не могу). Основная идея в том, что он предназначен не для получения статуса по задачам от подчиненного, а для обсуждения успехов, неудач, планов и т.д. Если сделать 1:1 откровенными, честными, открытыми, то можно будет узнавать о людях очень много такого, чего в обычной обстановке они бы не рассказали: свои взгляды на карьеру, чего хочется, что не нравится. Вам, как руководителю, остается только использовать эту информацию для роста человека и предотвращения кризисов. Статья уровня “сейчас я научу вас жизни”, но в ней есть интересные мысли. https://medium.com/@zackbloom/youre-doing-one-on-ones-wrong-dfc27f36f204

Наверное, не сильно ошибусь, если скажу, что большинство тимлидов и руководителей на этом канале так или иначе вышли из разработки/тестирования/администрирования, в общем, люди с техническим бэкграундом. По своему опыту, таким людям не всегда легко дается открытое общение с начальством/подчиненными. Следующая статья как раз про то, что хорошие 1:1 получаются тогда, когда вам “неловко”: вы перешагиваете через себя и рассказываете о своих мыслях, мечтах, планах, неудачах. В статье есть примеры вопросов/тем, которые подталкивают к открытому общению. https://medium.com/@mrabkin/the-art-of-the-awkward-1-1-f4e1dcbd1c5c (есть вторая часть про то, как получать честный фидбек о себе — тоже рекомендую).

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

А вы считаете 1:1 полезными? (Отвечайте отрицательно, если не проводите/с вами не проводят).