Следующее выступление, которым я хочу поделиться, я видел лично на прошедшей в июне конференции QCon New York. И мне очень понравилось как легко и понятно Heidi Helfand смогла рассказать свою тему, которой она занимается последние несколько лет.

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

Heidi утверждает, что часто меняющиеся команды - это хорошо. В докладе она поделится несколькими приемами как направить изменения в нужное русло, а также чего вам не стоит делать.

P.S. кстати в Booking.com команды меняются тоже довольно часто, и это работает достаточно хорошо.

https://www.infoq.com/presentations/dynamic-change-teams

Снова привет. Не к ночи будет упомянуто, но вот тут по ссылке можно почитать про то, как крупный голландский банк ING превращался из кровавого энтерпрайза в эджайл стартапчик. Ну, то есть, конечно же, не так все было, но эджайла прибавилось.

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

https://www.mckinsey.com/industries/financial-services/our-insights/ings-agile-transformation

Доброе утро. Я сначала хотел запостить сегодня немного другую ссылку, но на глаза попался этот текст, и я не смог устоять. А дело в том, что у всех хороших руководителей из любых областей есть схожие черты.

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

https://m.facebook.com/story.php?story_fbid=10205180093009489&id=1460265912

P.S. другая ссылка тоже будет, попозже

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

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

Определенно must see для лидеров.

https://www.youtube.com/watch?v=MIh_992Nfes

У них там ещё, как полагается на западе, целый сайт и книжка про это есть:
https://www.radicalcandor.com/

Всем привет!

Прошло чуть больше недели, как я (все еще @glamcoder) начал рулить тут на канале. И поскольку план был, что я тут побуду как раз-таки неделю, сегодня я сдаю свои бразды правления.

Не знаю как вам, а мне понравилось делиться с вами материалами, которые я лично считаю полезными для современного ИТ-лидера (да и не только). Может быть Егор позовет меня снова, тогда увидимся.

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

https://goo.gl/forms/aUnaXcEavs5XDTJH3

Для тех, кто хочет меня о чем-то спросить или просто законнектиться, вот мои координаты:
Facebook: https://facebook.com/glamcoder
Twitter: https://twitter.com/glamcoder
Telegram: https://t.me/glamcoder
Web: http://glamcoder.org

Всем удачи и до скорых встреч!

Ладно, напоследок запощщу еще одну статью. На вырост, так сказать (название говорит само за себя):

https://medium.com/from-the-edge/how-to-go-from-developer-to-cto-ce72d261c5fc

Вот теперь я точно все. Завтра улетаю в Сан-Франциско выступать на конференции QCon San Francisco (должен же я похвастаться, ведь так?).

Всем добра!

Всем привет! Эту неделю рулить каналом буду я, Роман Ивлиев. В узких кругах ИТ известен, как @dumtest (fb, twitter, tgm).

Представлюсь тем, кто меня не знает. В ИТ я с 2002, начинал с написания автоматических тестов для авионики, потом работал на оборонную промышленность, медицину, аутсорсинг всякой всячины. Потом делал Касперский.ком, тасс.ру, банки.ру и кучу всего вокруг них. Последние 6 лет техдиректорствую. С конца 2016 делаю мос.ру, тот самый портал Мэра и Правительства Москвы.

А ещё я член программных комитетов Highload++ и РИТ, а с этого года возглавляю программный комитет конференции для тимлидов Teamlead Conf. Так что про это со мной тоже можно поговорить, поругать и похватить конечно же в чатике Боль Тимлида.

Волею судеб я читаю и на английском тоже, за сим обязательно поделюсь чем-нибудь интересным с медиума, течрепаблики и мало ли ещё откуда. Материалы раскиданы по интернетам, т.к. для, например, управления в ИТ почему-то нет (или я не знаю) единой точки входа, но и для не управления тоже нет. Источников много, за сим, имхо, мы тут и собрались, чтобы добывать интересное и полезное.

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

Поскольку выходной, начну с легкого - немного затрону тему конференций. На этой неделе пройдёт одно из крупнейших ИТ-мероприятий в России и Восточной Европе - 12ая конференция для разработчиков высоконагруженных систем Highload++.  Что её отличает от прошлых мероприятий? Из основного - впервые в этом году будет проведена премия для тех, кто вложил душу и всё остальное в индустрию. Это премия от разработчиков разработчикам. Церемония пройдёт 8 ноября в Сколково, так что если будете там, то обязательно не пропустите. Обещают восторг:))

Также для тех, кто будет на конференции (а я надеюсь, что многие из вас примут участие), и особенно для тех, кто интересуется современным положением дел в области СУБД и около, перед тем, как топать на конфу или в последствие смотреть видеозаписи докладов, рекомендую ознакомиться с двумя очерками о самых интересных докладах про базы данных от

+ Константина Осипова (основной разработчик СУБД Tarantool)  - https://m.facebook.com/story.php?story_fbid=10213227075379185&id=1465256664, Костя очень круто разбирается в базах данных и плохого не посоветует.
+ Николая Самохвалова ( Коля адепт PostgreSQL, автор Nancy Cli, развивает крупны сообщества постресоидов и круто разбирается в базах данных)  - https://medium.com/@postgresql/postgres-%D0%BD%D0%B0-highload-2018-39dfa982f077

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

Ну и раз я заговорил о конференциях - вот ещё один неплохой текст о том, что айтишникам очень полезно и нужно эти самые конференции посещать - сборник мнений с разных сторон от завсегдатаев и организаторов - http://klever.blog/useful-conference/, уверен, что это не вопрос для тех, кто собрался здесь, но всё-же.

А ещё в Минске пройдёт неплохой, окрепший с прошлого раза, Product Sence, но поскольку там про продукты и вот это всё, то не буду ничего писать:)))))

На сон грядущий и в завершение праздничных выходных продолжу тему образования. Яндекс анонсировал второй митап для тимлидов (https://events.yandex.ru/events/meetings/28-nov-2018/ - регистрация пока открыта для спикеров и экспертов). В этот раз планируют обсуждать пути развития руководителей разработки и тех, кто хочет ими стать. В целом достаточно частая траектория развити тимлида и техлида. Так что, если интересуетесь карьерой - регистрируйтесь. По доброй традиции Яндекс проводит кастинг гостей и не публикует программу:), так что рекомендую тщательно отвечать на их вопросы.

А пока Яндекс думает программу и состав участников, отправлю вас посмотреть и почитать про их первый и второй  Тимлид митап, которые прошли в январе и в мае этого года. За что я ценю этих ребят, так это за тщательную домашнюю работу. Материалы качественные и количественные.

На январском мероприятии обсуждали вопросы выявления и развития талантов в ИТ. Для больших контор это серьёзная задача. И всё больше сил тратится на внутреннее воспитание, образование и отбор героев.  В мае  уделили внимание автоматизации процессов в командах разработки. Тема более техническая, но не менее востребованная. Оба раза участие принимали очень крутые спикеры из известных и крупных компаний.

Видео-материалы собраны тут:
https://events.yandex.ru/events/meetings/24-jan-2018/
https://events.yandex.ru/events/meetings/22-may-2018/

Текстовые материалы собраны тут:
https://m.habr.com/company/yandex/blog/346194/
https://m.habr.com/company/yandex/blog/358450/
https://m.habr.com/company/yandex/blog/358078/

Отмечу, что последнее время тематика тимлидерства и техлидерства стала очень востребована и популярна, митапы появляются, как грибы после дождика. Я посетил почти все из них и хочу сказать - качество очень высокое, организация на уровне как очной части, так и заочной, ходите и смотрите, если есть возможноть, вписывайтесь в рассылки и чатики. Нетворкинг, инсайты, ну и просто возможноть послушать и выступить в камерной обстановке. С некоторыми из них я планирую партнёриться и разыгрывать бесплатные билеты на зимнюю Teamlead Conf (секундочка рекламы:)).

До завтра! Поговорим про успех и продуктивность:) Псевдо-понедельник же:)))

Привет!

Как и обещал, слегка затрону тему продуктивности. Эта неделя короче на день, но это ли повод сделать меньше. Ведь в сутках так много ещё часов. Здесь демонический хохот, если вы не поняли.

Частенько тема тотальной занятости и нехватки времени стала проскакивать, например, в Боли тимлида https://t.me/TeamLeadTalks, трекеры, напоминалки, помидоры и прочие причендалы встали рядом с зубной щёткой и всё ради того, чтобы брать больше и кидать дальше. Вокруг нас в последние несколько лет возник культ продуктивности, эффективности и производительности. Десятки книг, сотни статей от совершенно разных специалистов и не очень специалистов, а иногда тех, кто просто хочет срубить очков на хайпе. Часть из них учит, как работать с огромными потоками входящих задач, часть из них настаивает на том, что нужно открывать в себе уникальные возможности и способности, часть из них предлагает “уникальные” методы улучшения, увеличения и достижения, фокусировки на достижении высот и вот этим всем. В своё время, обчитавшись различной литературы  сам пал жертвой “сверхпродуктивности в обмен на потерю здоровья”, после чего крепко задумался и скорректировал свою жизнь. Другими словами, если бездумно брать в оборот все тезисы из книг и статей, то можно достичь совершенно обратного эффекта.

Но. Есть и те авторы, которые предлагают подойти к этой тематике без сверхусилий и работы по 20 часов в сутки (вы же наверняка читали истории про такие трудовые подвиги). Авторы предлагают в первую очередь задуматься над тем, что же ты, дорогой читатель, хочешь получить. Я с тех пор отдаю предпочтение именно таким И оказывается, что можно достигать большего и при этом тратить жизненной энергии меньше. Вот лишь пара примеров.

Пример того, что было воспринято когда-то с восторгом и не зря, как мне кажется. «Выйди из зоны комфорта. Измени свою жизнь. 21 метод повышения личной эффективности». Книга оказалась полна простых примеров, большая часть из которых сводится к выбору точки приложения усилий, а не бездумной молотьбе задач. Многие тезисы в разных вариантах фигурируют и в других источниках. По ссылке я их выписал, книга, как мне кажется достойна внимания, хотя бы в моём сверхкратком изложении:) https://clck.ru/EfB2V. Время на прочтение минуты три.

На прошлой неделе МИФ выпустил в продажу книгу Катерины Ленгольд “Просто космос. Практикум по Agile-жизни, наполненной смыслом и энергией.”. Автор в 14 лет экстерном закончила школу. В 20 основала стартап — первый в мире маркетплейс спутниковых данных. В 23 года продала его калифорнийской компании Astro Digital, перебралась в Кремниевую долину и стала самым молодым вице-президентом мировой космической индустрии. Наверное, вы подумали: «Она либо гений, либо робот. Или и то, и другое». Но нет. Достижения Катерины — результат умения ставить четкие цели, «нарезать» их на маленькие кусочки, планировать шаги и находить «мотивирующую морковку» — награду для себя за достигнутые результаты. И при этом спать, есть, ходить в кино и жить нормальной жизнью. Достаточно посмотреть на её фотки в ФБ.
Честно, я ещё не успел ознакомиться с книжкой, но про успехи Катерины слышал ещё до этого. Если кто-то прочитает пораньше https://www.mann-ivanov-ferber.ru/books/prosto-kosmos/ - поделитесь впечатлениями пжлста, по идее должно быть очень полезно.

А наконец третий пример. Кстати тоже от женщины, что немаловажно имхо в контексте тематики. Статья "7 Things to Start Being More Productive, Today” https://link.medium.com/dzuQ5FFuCR На секундочку - 113К ладошек и всего 11 минут на прочтение.

Эта статья попалась на глаза пару лет назад и зацепила тем, что автор не предлагает читателю приложить пресловутые сверхусилия, сверхконцентрацию и много других сверхслов. Наоборот, речь в статье идёт о том, что в своё время было описано одной фразой - “Работать надо не 24 часа в сутки, а головой”. Статья на английском, но очень легко читается. Если покопаться в медиуме автора, то можно найти ещё некоторое количество забавных статей на совершенно разные темы.

Приятного прочтения! Поближе к вечеру поговорим про успех. А пока пойду выполнять свои задачи на день ;)

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

1. https://www.infoq.com/articles/0-bugs-policy - политика разработки с нулём дефектов. Чуваки разрабатывают таким образом, что не оставляют никаких дефектов за собой. Т.е. нашёл дефект - или исправил дефект, или исправил его на следующий спринт (максимум) или запил из дефекта новую фичу и всё в таком ключе. С моей точки зрения провокационная статья, многое в ней - игра слов, да и сам подход идёт сильно в разрез с тем, как работаем мы, например, но это ещё одна точка зрения достойная внимания, как работать с дефектами. Кстати, тема работы с дефектами была освещена в одном из  докладов на прошешей тимлидской конференции и вызвала очень бурные обсуждения и критику, что говорит об актуальности тематики.


2. http://www.timecockpit.com/blog/2015/03/29/Eight-Anti-Patterns-for-Optimization-Projects - в этой статье речь идёт об ещё одной сложной задаче - проекты по оптимизации (кода в первую очередь). Уверен, что многие из вас хоть раз да принимались за улучшение, рефакторинг, оптимизацию, тюнинг, ну так далее. На моей памяти не все такие проекты достигали нужного эффекта. На памяти автора судя по всему тоже:). Не смотря на внешнее капитанское повествование, многие сценарии я видел вживую со всеми вытекающими. Так что польза от прочтения будет нанесена гарантированно. Большим плюсом рассказа считаю то, что автор не только перечислил 8 анти-паттернов, но и в заключение предложил 8 (интересно, специально подгонял или нет) шагов, которые надо сделать, чтобы проект по оптимизации не вышел боком.

Приятного прочтения и до завтра!

Доброе утро:) Воспользуюсь служебным положением. Мы уже пару недель тихонько ведём подготовку к зимней конференции для тимлидов в Москве. Первые доклады уже поступили в систему, а программный комитет рыщет по просторам интернетов в поисках интересных тем и спикеров. Осенью в Питере нам удалось собрать почти 600 человек, два полных дня, 31 доклад и круглый стол, много общения, пива и хорошего настроения. Судя по отзывам было круто! Средний балл докладов по версии слушателей надежно перевалил за 4.

В общем мы воодушевлены вашим интересом и успехом и планируем в Москве ещё более масштабную тусовку. И может быть даже технические доклады:)) Так что совершенно официально приглашаю вас подавать доклады, закупаться билетами (пока они не подорожали). Вся информация по ссылке http://teamleadconf.ru/moscow/2019. На любые вопросы отвечу в личку @dumtest или в канале Боль Тимлида t.me/TeamLeadTalks. Вливайтесь!

З.ы. это не все на сегодня, не отключайтесь:)

Среда - неделе конец.

Решил копнуть ещё одну нужную и важную тему - тему ревью кода. В ней не так много холиваров, как в юнит-тестировании, например, но тем не менее за долгие годы наблюдения за этим процессом я неоднократно наблюдал ожесточённые битвы инженеров. Многие команды просто игнорируют эту практику ссылаясь на нехватку времени, на наличие тестировщиков, автотестов и вот этого всего, забывая при этом, что код-ревью - это один из важнейших процессов в софтверной разработке. Как минимум это гигиена кода и один из способов борьбы с хрупкостью, как максимум - это статическое тестирование кода, КПД которого в ряде случаев может превышать пользу от динамического тестирования руками тех самых тестировщиков, особенно если речь идёт о системах класса А.

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

Начну с ребят из Баду. Ребята постоянно делятся своими наработками в инженерии, не обошли они и тему ревью. Здесь отмечу, что у них есть ещё performance-review, о котором рассказывал Алексей Рыбак на одном из хайлодов, но это не то ревью:)) Итак.

https://habr.com/company/badoo/blog/354856/ - история становления код-ревью в Баду, как оно появилось, как оно видоизменялось в процессе роста числа разработчиков. Важный момент - рассказ написал Илья Агеев  - директор по контролю качества. Т.е. всё, как у взрослых - ревью - часть процесса обеспечения качества продукта.

https://habr.com/company/badoo/blog/413965/ - продолжение первого поста, но теперь взгляд чуть с другой стороны - для чего ещё может применяться код-ревью (а там обучение новичков, свежий взгляд на код, снижение бас-фактора и т.д.). Но секс в том, что это на самом деле совершенно не является основным назначением этого процесса, и часто за этими псевдо-целями теряется то, ради чего это всё затевалось - правильность архитектуры, соблюдение соглашений, корректность решения и тестируемость кода. Собственно ещё одна точка зрения на эту тему от всё того же Ильи Агеева.   Кстати, в статье в самом начале есть ссылка на кучу статей по этой тематике, не удивляйтесь, когда увидите, куда она приведёт. Тема реально популярная и востребованная в мировой ИТ-индустрии.

З.Ы. Кстати, если вы до сих пор не подписаны на их бложеки и видосы - рекомендую обязательно это сделать, например, здесь https://tech.badoo.com/ru/

Завтра, как я уже писал чуть выше, стартует 12-ый Хайлод++. По доброй традиции трансляция из главного зала будет совершенно бесплатной. О том, как подключиться и что будет транслироваться можно посмотреть вот тут https://habr.com/company/oleg-bunin/blog/428852/. В главный зал попадают доклады, которые слушатели выбрали, как наиболее интересные, ПК лишь выстраивает их в цепочку. Подключайтесь, если не будете присутствовать лично.

Доброе утро, вчера сачканул и не выложил вторую часть материалов по ревью. Был увлечён подготовкой докладчиков. Хайлод, кстати, стартанул и через 10 минут начнутся доклады. Напоминаю о трансляции из главного зала. Сегодня выложу сразу всё, следующая порция знаний будет завтра, поговорим о кросс-функциональности.

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

https://habr.com/company/Voximplant/blog/272469/ -  инструкции о том, как делать review чужого кода и пережить review собственного. Статья переведена очень неплохо, но для любителей в начале есть ссылка на оригинал. Если в двух словах, то статья фокусируется на практических аспектах code review и содержит множество толковых рекомендаций, как и что делать, чтобы было легко и полезно.

https://medium.com/palantir/code-review-best-practices-19e02780015f - очень неплохая статья от Palantir Technologies (ребята пилят софт для анализа данных и много сотрудничают с спецслужбами и банками, в 2016 их стартап был 4-ый по капитализации, но по другим данным это был пузырь:))) c кучей полезных ссылок, если хочется погрузиться в тему ещё сильнее. В статье можно поискать ответы на вопросы: почему, зачем и когда делать код ревью? подготовка кода к ревью (а вы всё ещё отдаёте код на ревью просто так?) собственно сам процесс код ревью и примеры его проведения. 12 минут на всё про всё.

И наконец,  https://medium.freecodecamp.org/unlearning-toxic-behaviors-in-a-code-review-culture-b7c295452a3c
Даже не смотря на то, что автор девушка-индус (хи-хи, вы же слышали про качество индийского кода), статья достойна внимания хотя бы потому, что это ещё одна точка зрения на этот процесс. Токсичность в поведении некоторых членов команд может очень серьёзно навредить бизнесу, а если речь идёт о ревью кода, когда один официально получает право уничтожать другого, ситуация может обернуться проблемами посильнее, чем Фауст Гёте.  В статье один за одним рассматриваются 8 нехороших паттернов и аж 12 хороших. И снова 12 минут. В начале страница не очень интересного текста, не обращайте внимания, мякотка дальше.

Привет! Четверг сегодня оказался пятницей, с чем я вас и поздравляю.

Кто не любит хайлод слушать и смотреть, тот слегка не прав:)

Как и обещал вчера - поговорим о кросс-функциональности.  В лучших традициях ИТ с терминологией в этой части тоже беда. Поэтому я решил посмотреть на эту тему с двух сторон.

Первая сторона - это сторона командная, когда речь идёт о том, что в одной команде собираются разные специалисты и делают что-то клёвое. Поговаривают, что до прихода аджайла таких команд не было, и именно аджайл сделал из разрозненных узкоспециализированных команд что-то более универсальное. Честно - фиг знает, но в моей разработческой молодости моя команда на одном из оборонных предприятий делала софт под ключ, т.е. у нас была лаборатория, в ней были аналитики, тестировщики, разработчики приклада и разработчики системного софта, причём разработчики пилили задок и передок, а тестировщики тыкали мышкой и пилили автотесты одновременно. Т.е. де-факто мы были той самой кросс-функциональной командой больше 10 лет назад. Этакий такой squad по классификации Spotify. Правда мы таких слов тогда не знали, потому как аджайл в моей жизни появился чуть позже благодаря г-ну Дорофееву ещё до того, как он стал известным прокрастинатологом, бо мне посчастливилось с ним поработать в разных конторах аж с 2002 года и до 2012:)))) А Спотифай в мою жизнь проник через Кодефест, а не через наушники.  Сразу скажу - материалов на эту тему вагон и сколько контор, начальников и нормальных людей - столько мнений на этот счёт. Я приведу лишь два - от Авито и ЦФТ, т.к. знаю точно, что ребята знатно поковырялись в этой теме.

Итак.

https://www.youtube.com/watch?v=bQth2oo66B8 - кино про кроссфункциональность в одной из команд Авито (я осознанно говорю “в одной из”, потому как точно за всех не знаю). Авито много сил потратило на изменение внутреннего устройства и процессов, так что даже если вы не разделяете их подходы к управлению, ознакомиться с деталями стоит однозначно. Этот доклад хорош тем, что его автор - инженер и тимлид одной из команд, т.е. непосредственный участник разработки, что в моих глазах делает его рассказ более точным и правдивым. Рассказ о том как команда Ивана пришла от монолитных функций к небольшим полнофункциональным командам, зачем это было нужно, с какими проблемами столкнулись и как их решали. И, конечно, вы узнаете, при чем здесь кроссфункциональность и как она помогает достигать лучших результатов как командам, так и самим разработчикам. 35 минут, как раз на обед:)

https://artemanin.blogspot.com/2018/04/crossfunctionalteam.html - Артём представитель ещё одной крупной конторы - ЦФТ и рулит там разработкой веба и мобилки. ЦФТ неоднократно были замечены за очень толковыми рассказами на разные темы (можно погуглить Артёма Каличкина или Ольгу Давыдову). Конкретно в этой статье Артём смотрит на кф-команды с точки зрения плюсов и минусов их организации и функционирования, ну и делает определённые выводы о том, что получилось. Очень структурировано, без лишних букв. Всё, как мы любим. Минут 5-7 займет почитать, т.к. на русском:)

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

Хорошего дня!

В продолжение предлагаю ознакомиться с двумя “феноменами”, которые частенько проскакивают в буржуйской литературе, русскоговорящие авторы не очень её жалуют, но тоже иногда упоминают ( если повнимательнее посмотреть на текст Артёма из утренней почты, то 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 речь идёт о том, что кросс-функциональность это хорошо и здорово, если бы не три “Но”: непонимание цели специализации, поклонение герою (круто же, когда восьмикрылый семилап всё делает) и отсутствие в организации желания культивировать культуру кросс-функциональности, т.к. специализация удобна многим, например ичарам (проще искать героев, которым потом будут поклоняться и делать из героя единую точку отказа). С этими “Но” нужно обязательно работать и по максимуму убирать их влияние.


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