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

В предыдущем посте я говорил про важность людей, с которыми вы работаете, про их развитие и результаты, закончил я следующим тезисом: “Ваш результат зависит от команды”. Но вопрос следующий - как набрать команду так, чтобы эффективность TL даже в “попугаях” была высокой? Как понять на этапе собеседования, которое ограничено по времени, уровень компетенций сотрудника, будет ли он частью коллектива, сможет ли ужиться с коллегами?

За время работы в двух больших компаниях TL, я пообщался с огромным количеством других лидов, people partner’ов, HR и Senior’ов, которые специализируются на технических собеседованиях. Эта статья - грубый чертеж процесса собеседований, который мы собирали с этими людьми в разных компаниях, к которому можно стремиться.

Поздним вечером генеральный названивает и требует, чтобы релиз выкатили через шесть часов — утром у него встреча с инвесторами в Китае. У разработчиков — в порядке важности для проекта — почесуха, отпуск, профессиональное выгорание, кружок макраме и пикет «зелёных» по защите прав морских свинок. Тестировщики уже разъехались по домам. Тимлид рыдает, как «девушка в автомате» — у неё дела сердечные. Офисный кот опрокинул вазу с водой на документы с мокрыми печатями. Релиз нужно выкатить с китайской и корейской локализацией. А ближайшие специалисты по языкам Азии — таджики в общаге через дорогу.

Вы вздыхаете и принимаетесь за работу. Через шесть часов всё работает. Релиз задеплоили. Генеральный доволен. Разработчики бодры, веселы и рады стараться.

Обычные будни техдира.

На Слёрме DevOps собралось немало технических директоров. После интенсива я поговорил с Эдуардом Медведевым об IT-этике, с Артёмом Галонским об исчезающих профессиях и DevOps. А ещё мне повезло познакомиться с уникальным техдиром-экстравертом, способным организовать, что угодно, и найти общий язык с кем угодно.

Дмитрий Симонов ctorecords, основатель Техдирского клуба и создатель канала «Записки Техдира», https://t.me/ctorecords, рассказал, как стать техническим директором, эдаким Jack of all trades в IT-сфере.

Дмитрий Симонов и голубая то ли лама, то ли альпака от eLama.

Недавно вышла статья, мимо которой я не мог пройти — "Программист не должен решать задачи бизнеса". Неожиданно мой комментарий вырос до мини-статьи. Я не согласен с мнением автора статьи, все сказано ниже ИМХО, с удовольствием подискутирую в комментариях. Сразу замечу, что я веб-разработчик, и все примеры я привожу в контексте своего опыта.

Мало просто сменить свою сферу работы на IT, желательно еще и стать хорошим разработчиком. Бывший тимлид и консультант Александр Усков рассказывает, как понять, что перед вами плохой разработчик и что с ним вообще можно делать

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

Меня зовут Саша Терентьев, я из команды ленты ВКонтакте. В этой статье поделюсь мыслями о проблемах кода, где используются enum и сопоставления типов. Часто встречаю такой код в проектах, ресурсах, примерах. Мы обсуждали это с коллегами на внутреннем событии, и из моего доклада выросла эта статья.

Букв будет много. Но, думаю, материал пригодится широкому кругу разработчиков — и не только iOS. Примеры основаны на псевдо-Swift и написаны по мотивам использования UIKit. Но могут пригодиться для работы с разными платформами и в любой области, где возникают сопоставления с образцом, приведения типов, переборы множеств типов.

Всем привет, я — Сергей Бобрецов, CTO в Wildberries. 

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

Стоит начать с того, что основным генератором прогресса в WB с самого начала и по сей день является фактор роста. По бизнес-метрикам мы растем примерно х2 каждый год уже много лет, а по техническим (количестуву запросов / транзакций / трафику / объему данных и т. д.) — рост может быть даже быстрее, и это создает множество вызовов: технических, архитектурных и организационных. 

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

Сегодня я хочу рассказать немного про нашу инфраструктуру.

Всем привет. Меня зовут Александр Наумов, и последние 5 лет я занимаюсь тестированием сайта Утконос ОНЛАЙН — руковожу группой QA.

Идея написать эту статью пришла ко мне пару месяцев назад. Я возвращался с работы домой, когда мне позвонил коллега: «Привет, тут хотят катить одну фичу в прод. Я против. Катим?» Он был не уверен в своем решении, хотя все проанализировал и сформировал мнение. Почему? 

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

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

Привет, меня зовут Костя, и я руковожу дизайном в Агиме.

В декабре я устроил эксперимент: опубликовал в Linkedin пост с предложением бесплатной консультации. Откликнулось несколько ребят, с которыми мы неплохо поболтали.

В этих беседах мы затронули некоторые боли и проблемы, которые я тоже в свое время пережил. Судя по всему, они вполне типичны. И решения вполне очевидны, если об этом подумать. Но, если ты молодой неопытный тимлид, когда тебе думать? Работать же нннада!

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

Итак, теперь ты тимлид, и тебе стоит знать, что...

Чему нужно обучить junior QA, чтобы он начал приносить пользу проекту? Конечно, было бы здорово «всему и сразу», но это может затянуться надолго. А вот с основами тестирования можно познакомить буквально за пару-тройку дней. Особенно если это фулл-тайм дни (рабочее время).

Я обучаю новичков больше 6 лет, больше тысячи людей выпустила, книгу вот написала. И на опыте студентов вижу, что «план-минимум» на самом деле небольшой.

Если перед вами стоит задача «завтра выйдут два джуниора, обучи их», начните с основ. Один из вариантов: 

• дали посмотреть видео или прочитать статьи;

• собрались вместе в переговорке или зуме, обсудили;

• дали ДЗ на закрепление материала;

• через три дня получили более-менее адекватного джуна, профит!

В этом посте я собрала ссылки в помощь по каждой теме:

• видео — варианты из публичного доступа. Выбираете то, что больше по душе, отдаете падаванам;

• статьи — даете как дополнительный материал.

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

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

Сегодня делюсь очень полезным инструментом - пирамида аргументации от основателя YCombinator Пола Грэма, которая помогает работать с критикой, избегать бессмысленных споров и не грустить из-за существования хейтеров.

Пирамида аргументации Грэма, описанная им в эссе «Искусство возражать» — хороший инструмент, помогающий вырваться из этого порочного круга. Она четко структурирует возможные варианты критических комментариев – и связывает их с истинными намерениями оппонента. Теперь вы всегда можете идентифицировать "ступень" и понять: стоит ли критика вашего внимания — или это грязь под ногами, которую просто надо перешагнуть.

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

Текущая аналитика брокера показывает только открытые позиции, а профиль в "пульсе" подсчитывает лишь общий процент, без конкретики. Это не дает возможность увидеть «настоящую» картину своего портфеля.

К примеру, покупаем 1 акцию по 1000, после падения до 900 усредняем еще одной акцией. Затем при отскоке до 950 продаем 1 акцию. В итоге оставшаяся акция в портфеле "горит зеленым" (образуется плюс +50 по правилу fifo), хотя фактический результат бумаги на данный момент будет 0 (без учета комиссий). Такое отображение бумаг в приложении может сбить с толку, и привести к неправильным решениям и большим потерям, при совершении множества сделок.

Идея вести дневник сделок в excel, или периодически копаться в налоговом/брокерском отчете, мне не понравилась. Зато приглянулась мысль - обрабатывать данные полученные из официального API.

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

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

Привет, я Александр Пузеев, Software Lead инженер Beeline Казахстан. За 2021 год провёл 85+ собеседований, не считая внутренних переходов, то есть провожу одно собеседование в 3–4 дня. Я делаю это не потому, что мне нечем заняться или просто по фану. Это одна из моих рабочих задач.

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

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

Меня зовут Андрей Булов. Я простой питерский технарь, архитектор, разработчик, DevOps технический менеджер. Сейчас работаю в Quantori.

Я не буду описывать самоорганизующиеся команды, а расскажу про алгоритм их создания. Это мой личный опыт — я так работаю с командами (их было 30+). Он перекликается с Management 3.0, моделью Херши-Бланшар, LeSS, Sсrum и даже SAFe, а также со многими другими софтовыми областями. И в нем есть конкретика на уровне действий.

Для ленивых: я исследую окружение, проектирую дизайн культуры, объясняю правила и делегирую задачи команде. Я не поддерживаю внедрение самоорганизации через фреймворк. Видео моего выступления об этом на конференции TeamLead Conf 2021 можно посмотреть здесь.

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

На прошедшей в апреле конференции TeamLead Conf 2021 я поделился своим опытом, как вытащить проект из пожара и обойтись без человеческих жертв. Под катом моя история, а если предпочитаете смотреть — вот запись выступления.

В данном посте мне хотелось бы поделиться списком книг, которые (по крайне субъективному мнению) являются полезными и весьма практичными для Engineering Manager’а. При этом акцент хочу сделать именно на современных книгах (выпущенных в последние 5-6 лет). Под Engineering Manager’ом, в моем вольном определении, будем понимать бывшего инженера, ставшего руководителем, решающего как технические (например, внедряем RabbitMQ или Kafka), так и административные вопросы (например, план обучения новичков, сколько еще нанять разработчиков и каких и т.п.). Под такое понятие могут подпадать Tech Lead, Team Lead, Project Manager.

Корпоративная (пред)история

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

Консультанты и  команда проекта получили полный карт-бланш от самого генерального, и уже на первом заседании управляющего комитета проекта рассказали о значимых достижениях, а ещё через шесть месяцев были представлены результаты в 10 (!) раз превышающие целевые.

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

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

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

Серьезно. Кода на который можно посмотреть и сказать "это сделано на отлично" почти не бывает – в основном один фарш из легаси, гвоздей, и иероглифов.

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

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