Накопилось 5 постов, но их причесывание и публикация задержатся :) завтра буду на РИТ, может быть покидаю оттуда интересного в режиме прямой трансляции.

Александр Сербул.
Крутой инженер из компании 1с-Битрикс. Один из немногих в ней, кого парит говеный код платформы 1с-битрикс. Но, увы, не на все можно повлиять.
Мировой товарищ со своим взглядом на мир (и это важно).

Надпись эксперты по кубернетес - это просто наш стенд, а не название рубрики :)

Кубернетес в тренде, еле отбиваемся

На фото: Александр Чистяков - девопс инженер, программист, регулярно рассказывающий удивительные инженерные кустори о скрещении ужа с ежом. Никто не знает, сколько у него проектов, но товарищ входит в топ самых интересных инженеров.

Еще: Александр Макаров, мейнтейнер фремворка yii. Тоже совратился на кубы.

Макаров, к слову, ушел в skyeng.

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

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

Из бомбившего на прошлой неделе:
И в 40, и в 50 нужно оставаться пластичным. Если ваш язык поворачивается произнести фразы вида "мне 40 лет, я лучше разбираюсь" или "5 лет на проекте Х делали - всё нормально было" - вы точно идёте не туда.
Выживает тот, кто умеет адаптироваться. И если вы перестали тренировать свои навыки адаптации - всё очень плохо.

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

Руководство компании не умеет работать с людьми в удалённом режиме. Не умеет, боится пробовать и вообще фуфуфу. И не учит людей всего нескольким критичным вещам:

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

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

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

Как узнать эту замечательную компетенцию? Да хотя бы с помощью открытых вопросов-кейсов:
- вам надо сделать фичу в условных 100 человекочасов, у вас есть неделя и один человек. Что делать будешь?
- пилили фичу и вдруг за день до релиза выяснили, что билд не собирается, тесты не проходят. Разраб говорит "щаща починим". Что делаем?
- разраб пообещал запилить фичу до завтра, и вы видите, что вся команда ушла на какую то аварию. Что делаем?

В какой котёл подкинуть дровишек?
anonymous poll

Нужно больше управления знаниями! Уменьшение bus factor, финансовая отдача от документации, вот это всё – 17
👍👍👍👍👍👍👍 40%

Нужно больше про софт-скиллы: стрессы, целеполагание, убеждение - всё на реальном опыте – 13
👍👍👍👍👍 31%

Процессы и лидерство в команде. Как взять власть, как удержать и как остаться при этом адекватным. – 10
👍👍👍👍 24%

К чёрту детали: рассказывай больше о людях в индустрии и об интересных возможностях – 2
👍 5%

👥 42 people voted so far.

Пожалуйста, проголосуйте в опросе выше ^ Там паритет мнений

Выявление групповой цели

А что делать, если вы пришли, группа уже есть, и вроде как какая-то групповая цель существует. Но какая - непонятно.
Например, есть компания, вы в неё пришли. И вроде все копошатся, но зачем - непонятно. Ведь ответов может быть несколько, например
- чтобы заработать многоденег для каждого из участников команды
- чтобы сделать великий продукт
- чтобы основатель купил себе бентли
- чтобы чувствовать себя нужными
- чтобы все завидовали и хотели работать в компании
Если групповая цель не озвучена и контракт не заключён - скорее всего, в головах у людей разные ответы на вопрос "а зачем мы тут?". Лебедь рак и щука.
Причём самое смешное - 80% людей как обычно пофиг куда тянуть, просто им не сказали.

Решение:
- найти лидеров мнений, тех, кто реально определяет судьбу
- определить их иерархию
- цели этих лидеров озвучить, сделать официальными

А ещё я наткнулся на очень интересный сайтец. Ссылка - на картинке.

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

А потом: а давай поговорим об этом. Что вы делаете?

И оказывается, что потолок мечтаний - это 1-2 странички с рисунками интерфейсов и описания визуального поведения системы.

Карл, этого мало! Карл! Сейчас поясню, о каких проблемах я говорю.

- Требования - они порождаются аналитиками. А в это слово в нашей стране слиты две профессии: UX-аналитик и бизнес-аналитик. К сожалению, некоторые люди не видят разницы, и нанимают первых (они вроде что-то понятное говорят - про дизайн и вот это всё). Функция бизнес-аналитики тем не менее должна быть в команде, и если вы не разместите её самостотельно где-то рано в процессах - она окажется на исполнителях или вообще на QA (видел и такое!). Что гарантирует вам постоянную переделку продукта.

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

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

- Разработчикам нужна внутренняя дока. Так или иначе. И эта дока - должна быть связана с требованиями. Думаю, не надо объяснять почему.

- Ну и, наконец, то, чего все очень хотят, но я не слышал, чтобы у кого-то было. ТРАССИРОВКА. Чуть ли не от кода: каждая строчка в системе контроля версий так или иначе промаркирована номером тикета, породившего её. А от номера тикета должна быть возможность взойти к ответу на вопрос "нахуа так было сделано?".

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