В продолжение предлагаю ознакомиться с двумя “феноменами”, которые частенько проскакивают в буржуйской литературе, русскоговорящие авторы не очень её жалуют, но тоже иногда упоминают ( если повнимательнее посмотреть на текст Артёма из утренней почты, то T-shaped стоит в тегах статьи). Важно! Я не буду говорить про фул-стек-инженеров. Я про них не забыл, и это тоже проявление кросс-функциональности. Это близко нам и примерно и так все понимают. Но сейчас речь немного не об этом.

Первый “феномен” - «T-shape person» или «Т-образная личность». Термин, введенный в начале 90-х прошлого века Дэвидом Гэстом (там ещё был математик - полный тёска в начале 20ого века, так вот это не он. Математика грохнул снайпер во время чтения газеты.). Свою популярность термин получил благодаря CEO международной дизайнерской фирмы «IDEO» – Тиму Брауну, который провозгласил «T-shape»-человека одним из ключевых аспектов любой креативной работы. Сейчас идея «T»-личности используется не только применительно к дизайну, но и везде, где речь идет о важности наличия у сотрудника не только специфических знаний и какой-то экспертизы в определенной сфере, но и знаний в кросс-функциональных областях.
А теперь подробнее…
Модель «Т», согласно Гэсту, имеет 2 составляющие.
Первая – это вертикальная линия буквы Т или «глубина», которая говорит об уровне «экспертности» специалиста в конкретной сфере.
Вторая составляющая – горизонтальная линия буквы Т или «ширина», говорит о тех областях, в которых специалист также имеет определенный опыт и знания.
Это кратко, теперь поподробнее в тексте статьи.
https://collegeinfogeek.com/become-t-shaped-person/ - если кратко передать суть статьи, то это а) стать и быть T-shaped это очень круто и полезно. Не надо быть прям Вассерманом во всех вопросах. Достаточно быть крутым в одной теме и иметь широкий кругозор в других темах. (Спасибо, Кэп?) Это тебе поможет тебе легче находить общий язык с коллегами, повысит заинтересованность во многих процессах, добавит креативности и сделает более привлекательным для работодателя. Ну и для тех, кого зацепит - приведёт простой алгоритм, как оценить свои скилы из крышки буквы Т и составить план развития, если их там нет, но есть понимание, что очень хочется. Ну и в конце фирменное Don’t give up!
И второй “феномен” это "Generalizing specialist”. Не взялся переводить, лучше после прочтения сформируете своё определение для этого. Если кратко, то с моей колокольни суть этого термина близка к T-shaped, но не так пафосно звучит:))) Поэтому в литературе и статьях всё-таки больше первого. Если читать внимательно, то можно легко найти пересечения с первым опусом. Здесь также рассмотрены плюсы быть женералайзингом, схемы, как им можно стать и измерить свою женералайзность. Важный момент - в этой статье постоянно идёт отсылка к аджайл-практикам, собственно к тому, с чего начали утром. http://www.agilemodeling.com/essays/generalizingSpecialists.htm - если лень читать, приведу цитату из заключения, которая примерно передаёт суть текста. Robert A. Heinlein said it best: "A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects."

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

Ну и поскольку впереди выходные, а ведь не все из вас уже бегут в кабак:), вот вам ещё два неплохих текста на эту тематику.

https://vc.ru/flood/40369-avtonomnost-motiviruyushchaya-cel-masterstvo-zachem-kompaniyam-t-shaped-specialisty-i-kak-ih-razvivat - это небезызвестный Райфайзенбанк рассуждает на тему того, что организациям очень выгодно нанимать этих самых T-shaped.

А вот здесь
https://www.agileconnection.com/article/examining-cross-functionality-bias-software-development-teams речь идёт о том, что кросс-функциональность это хорошо и здорово, если бы не три “Но”: непонимание цели специализации, поклонение герою (круто же, когда восьмикрылый семилап всё делает) и отсутствие в организации желания культивировать культуру кросс-функциональности, т.к. специализация удобна многим, например ичарам (проще искать героев, которым потом будут поклоняться и делать из героя единую точку отказа). С этими “Но” нужно обязательно работать и по максимуму убирать их влияние.


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

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

Хотел найти видос от Бориса Вольфсона (он тогда ещё был техдиром ХХ) "
Стратегия сокращения технического долга” , но не смог:( Если подвернётся - обязательно посмотрите, но есть видос от Антона Бевзюка с аджайлдэйс 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
почта: [email protected]
скайп: 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
Почта: [email protected]

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