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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

👥 40 people voted so far.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я же тут последнее время занимаюсь вопросами knowledge management. Тема, не освещавшаяся пару-тройку лет назад от слова совсем начинает поднимать голову - то тут, то там митапы, обсуждения, видео с презентациями.
И что меня пугает:
Люди почему-то говорят о том, что такое знания. Люди обсуждают методики обмена знаниями. Люди делятся болью. Но я почти не слышу одной простой идеи:

knowledge management должен приводить к росту прибыли компании.

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

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

Я уже писал, что в 2018 году нет смысла в работе в офисе.
Но как перейти к построению распределённой команды, если вы всё-таки хотите на это решиться? Причём сделать это так, чтобы с минимумом риска.
Разорвите порочную связку между теми кто ставит задачу и теми, кто её делает. Банально: сделайте два офиса, между которыми есть ощутимое расстояние. Менеджеры перестанут стоять над душой у разработчиков, и это будет хороший прецедент для обучения людей новым подходам.
И пользуясь этим прецедентом, вы должны быть готовы
- научить людей пользоваться конференц-связью, по каждому чиху. по каждому.
- сделать людям "курилки" - специальные комнаты видеосвязи, где тусуется народ и высока вероятность кого-то застать.
- научить людей пользоваться гугл-календарями (они, кстати, чудесно интегрируются с google meet, в котором одна из лучших конференц-связей. Создал событие - хуяк - и у тебя уже есть ссылка для видеовстречи)
- научить людей писать афтермитинги и проверять, что изменилось с прошлого раза

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

пы.сы. А накидайте @tinyest_devil_secretary_bot вопросов по knowledge management, которые вам близки? Плохих и глупых вопросов не бывает, мы же в аду :)

Как начать внедрять фиксацию знаний в компании.

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

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

Подробно всю эту тему освещал тут: https://www.youtube.com/watch?v=NGiN3df_YGc
В том числе в видео вы найдёте пример структуры доки и объяснение того, какую структуру доки нужно построить именно вам.

Тут поступило предложение сделать чатик для нашего канала. Мол, тимлидам и прочим сотрудникам ада надо обмениваться опытом. Если честно, я не фанат, но всё же.

Стоит ли делать чатег канала?
anonymous poll

Дааа! Больше чатов богу чатов! Тысячи их! – 21
👍👍👍👍👍👍👍 54%

Лучше запартнёриться с большим комьюнити и жить в интересном сообществе тимлидов – 10
👍👍👍 26%

Нет, нафиг, и так всё в чатах, задрало – 8
👍👍👍 21%

👥 39 people voted so far.

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

Воля - это исчерпаемый ресурс. Он расходуется в течение дня, а восстанавливается во время сна.
Поэтому некоторые говорят "вставайте утром рано и начинайте делать дела" (ох уж это ущемление прав совушек!).
Свою волевую мышцу можно "натренировать", чуть-чуть увеличив (но не сильно), а можно организовать свою жизнь так, чтобы волевые усилия приходилось принимать только по действительно важным вопросам. Грустно растрачивать ценнейший ресурс на волевое решение проблем в личной жизни или на криво стоящий стол на кухне - проще ликвидировать первоисточник.

Если есть проблемы с использованием воли и с самодисциплиной - можно начать с выделение "самого главного дела на день". Добейтесь хотя бы того, чтобы закрыть его.
По мере того, как ваша жизнь перестроится (1..2 месяца, наверное) в связи с этим - можно начать выделять 2-3 самых главных дела и так далее.