"...5 лет назад я работал в почтовом сервисе. В мои обязанности входило сопровождение разнообразных проектов по международным перевозкам. Как-то раз мой начальник пришел ко мне и поручил следующее задание: «Саша, нужно до конца месяца решить проблему с недостатком машин по маршруту Кишинев».

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

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

Какие бывают проблемы роста, кроме очевидных, когда из 15 человек становится 80, а из одной команды вырастает 10? Почему разработчики начинают удаляться от пользователей и перестают чувствовать их боль? Как им не выпадать из коммуникационных процессов?

Я Дмитрий Шаронов, и я расскажу, как мы в Tarantool преодолевали проблемы роста и пытались избежать разделения между разработчиками при переходе из опенсорса в ентерпрайз. Какие решения использовали, зачем привлекали новичков и стажеров. Мы выделили 4 проблемы коммуникации в стремительно растущей команде и унифицировали инструменты для этого.

Это расшифровка доклада, прочитанного мной на TechLeadConf 2021. Видео доклада можно посмотреть тут.

По мотивам своих собеседований, а также собеседований коллег и mentee, составил список вопросов от тимлида к компании, что стоит прояснить на собеседовании — что спросить собеседующего.

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

Каковы финансовые показатели компании?

Является ли компания прибыльной или тратит деньги инвесторов? Или даже до инвесторов ещё не дошло, и основатели пока платят из своего кармана? Как выглядит бизнесовый план развития?

Если компания имеет представительство в РФ, официальное ли (по ТК РФ) трудоустройство и полностью ли "белая" зарплата?

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

Расскажите про ваше понимание «хорошего тимлида»

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

Возможно, это понимание даже прописано в должностных инструкциях.

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

Оригинал Defining Metrics for Change Management

By Stuart Rance | Originally published on April 28, 2014 in ITIL | Updated on September 12, 2017

Начало цикла из 3-х статей про процесс определение показателей для оценки практик управления предоставления ИТ услуг. Чем может быть интересна? Ходом рассуждений автора. (здесь и далее курсивом комментарии переводчика).

Недавно я работал с заказчиками, и они спросили какие ключевые показатели результативности (key performance indicators, KPIs) им использовать для измерения результатов ИТ-процесса Управления изменениями (change management). После обдумывания я предложил им несколько вариантов. И сейчас хочу поделиться ими здесь, потому что это может быть еще кому-нибудь полезно . Только, пожалуйста, бездумно не копируйте себе предлагаемые показатели (KPIs), ведь они  предложены под конкретных заказчиков, но внимательно просмотрите за процессом их опеределения и задумайтесь, а что стоит измерять в вашей ситуации.

В прошлых двух статьях мы рассказывали об IIoT — индустриальном интернете вещей — строили архитектуру, чтобы принимать данные от сенсоров, паяли сами сенсоры. Краеугольным камнем архитектур IIoT да и вообще любых архитектур работающих с BigData является потоковая обработка данных. В ее основе лежит концепция передачи сообщений и очередей. Стандартом работы с рассылкой сообщений сейчас стала Apache Kafka. Однако, для того, чтобы разобраться в ее преимуществах (и понять ее недостатки) было бы хорошо разобраться в основах работы систем очередей в целом, механизмах их работы, шаблонах использования и основной функциональности.

Мы нашли отличную серию статей, которая сравнивает функциональность Apache Kafka и другого (незаслуженно игнорируемого) гиганта среди систем очередей — RabbitMQ. Эту серию статей мы перевели, снабдили своими комментариями и дополнили. Хотя серия и написана в декабре 2017 года, мир систем обмена сообщениями (и особенно Apache Kafka) меняется так быстро, что уже к лету 2018-го года некоторые вещи изменились.

Движущая сила микросервисов

Сергей Бурладян (Avito)

Иван Михеев (AGIMA)