Уютный IT адочек

Две очень больных проблемы в коммуникациях инженерных команд
- потеря фокуса внимания - больная и регулярная проблема, как только вопрос выходит за рамки решения сугубо технической проблемы. Трёп ни о чём, разговоры о сторонних проблемах, тухляк и расслабон - все это свидетельства потери фокуса. Хорошо понимающие смысл встречи и свои цели от этой встречи люди так не делают.
- отсутствие подготовки ко встрече. Люди приходят на встречу с клиентом / на обсуждение зарплатных ожиданий / на командный митинг и не понимают чего они хотят от этой встречи. Типа, вот он я такой молодец, сейчас что-нибудь замутим. Фу такими быть!

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

А главное - не проводите встреч "для галочки"!

Инструменты технического менеджера
Расскажу о своих ежедневных тулзах на состояние августа 2018.
- Slack - все коммуникации в команде идут через него. В качестве резерва - экстренный канал в Telegram, где есть почти вся компания.
- Google Meet - если разговор в слаке длится больше 5 минут и/или создаётся ощущение непонимания/конфликта - бегом говорить голосом. Google Meet очень стабилен, позволяет писать видео и нормально кроссплатформенный.
- Google Calendar - если он правильно настроен, то создавая мероприятие вы сразу можете позвать коллег (GCalendar делает автокомплит) и автоматом создать ссылку для встречи в Google Meet. Очень удобно!
- Google Docs - без комментариев :) Помните, что нельзя делать файл доступным "всему интернету", только - "всей компании".
- KeePass/KeePassX - у меня порядка 300..400 паролей, хранить их в голове и вспоминать, что ключевые нужно регулярно сменять - невозможно. Есть ещё интересное совместимое решение KeeWeb, но его пока не распробовал.
- Учёт задач. Рабочие - в нашем корпоративном сервисе (о котором как-нибудь отдельно), личные - в Trello. Я не заморачиваюсь с "датами окончания", а в трелло для личных дел у меня колонки "Идеи", "Сегодня", "В работе", "Сделано", "Заброшено".
- Учёт времени. Я вообще гик учёта своего времени, ибо убеждён, что это единственное, чем я по-настоящему владею. Рабочего - в корпоративном сервисе (вот он прямо офигенный, как-нибудь расскажу!), личное (когда я не с семьёй и не сплю) - в Toggl. Toggl, кстати, хорошо дружится с треллой.
- VSCode. Вообще я фанат решений Intellij, но последние полгода приходится работать не с каким-то одним языком, а со всеми сразу. Решение от Intellij на этот случай дороговато.
- скриншотлика. Сейчас использую встроенную в Ubuntu, если вдруг её будет не хватать - буду искать ту, которая позволит загружать файлы в корпоративное хранилище (ибо картинки на левом сервисе, вылезающие в выдаче гугла - это очень больно для NDA и безопасности, например). Кажется, monosnap так умеет.
- theoldreader - самая приятная RSS читалка

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

Про слова
Talk is not so cheap, на самом деле.
Правильно сказанные слова и навешенные лейблы, в правильное время, нужным людям могут сотворить чудо.
Я говорю сейчас про сказку, связанную с вдохновлением людей, с объяснением им смысла того, что они делают и общей картинки. Очень часто в сильно иерархичных компаниях забывают об этом.
Инженерам, разработчикам, дизайнерам и прочим техписателям *нужна* общая картинка. Им *нужны* мечты о том, куда они могут вырасти и кем стать. И здорово, если кто-то умеет в них это вкладывать.
Можно заставить людей сделать корабль и получить корабль.
А можно вложить в людей мечту о море и получить флот.

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

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

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

И очень хочется процитировать слова Линуса Торвальдса: talk is cheap, show me the code.
Смотрите в корень, господа и дамы. И очень учитесь отсекать, когда ваши слова и мысли основываются на *вашем* опыте, а когда - на чужих лейблах и предубеждениях.

отказоустойчивость менеджеров

В то время как тимлиды находятся под пристальным вниманием (онижпродуктделают!), менеджерская братия зачастую предоставлена сама себе. Разберётесь ли вы в хитросплетениях договорённостей с Важными Людьми, если менеджер завтра траванётся и отлежится денёк-другой? Это будет мучительно. Я расскажу о рецепте, к которому пришёл.

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

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

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

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

Минутка юмора на канале

Если кому интересно, как решена вышеописанная проблема. До финала ещё не дошла, но я уверен, что путь выбран правильный.

1. Манифесты-фигесты пошли к чёрту. На словах не удалось договориться
2. Я завёл в gitlab-е шаблоны для всех issue (в конце сообщения будет пример) и потребовал, чтобы вся активность укладывалась в них. А то, что не укладыватся/идёт в обход я мониторю и разбираю индивидуально, по аналогии.
3. В гитлабе же завёл простейший воркфлоу: backlog, in analysis, task formed, doing, review, complete.
4. Переходы backlog -> in analysis -> task formed решаю я лично, с помощью тимлидов и 2..3 самых компетентных инженеров в компании
5. Связку task formed -> doing -> review делают техписы и инженеры. Ревью делаю я.
6. Список шаблонов для issue будет дополняться и они будут переписываться, инфа сотка. Кроме того, для сложных кейсов вроде "написать гайд из 5..7 документов" мне нужно будет первое время писать костяк на стадии in analysis, а постепенно сформируются шаблоны и для таких костяков.

Примеры шаблонов issue:

# Статья о решении проблемы

**На кого ориентирована статья**

- [ ] DevOps инженеры
- [ ] Ops инженеры
- [ ] Новички
- [ ] PM-ы инженерных команд
- [ ] Менеджмент компании

**Какую проблему решает эта статья**

@todo: описать

**Кто сказал, что проблема существует?**

- [ ] Личный опыт
- [ ] Тимлиды
- [ ] Менеджмент

**В какой момент эти люди сталкиваются с проблемой**

@todo: описать

## Как пользователи должны выходить на эту статью?

[ ] Через поиск

@todo: описать, по каким запросам доступна статья

[ ] Через закладки 

@todo: описать, как до людей будет донесено существование этой статьи

[ ] Через меню

@todo: описать, в каком разделе должна быть эта статья

## Внедрение

@todo: описать, как планируется внедрять эту статью и когда ожидаются первые merge request-ы от пользователей (дату)

Если что - предыдущее сообщение дополяется вот этой гуглодокой https://docs.google.com/document/d/1PEdUSz35jB1RU4mXjpsNh_ce7nNfvJLSB7ZtmsUHDrY/edit#heading=h.a0kv8gkktldn
Там можно оставлять комменты-предложения. Ну или можно обсудить его в чатике.

Как выстроить разработку внутренней документации

Игорь @i_tsupko спрашивает в чате @docsascode:

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

Как договориться? В программировании для этого есть фреймворки и паттерны. А с русским языком как быть? Он ж не компилируется и автотесты не напишешь.

Что важно в документации:

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

У вас тоже это болит? Знаете решение? Приходите в @docsascode, обсудим.

Адаптация новичков.

Кроме прочего управления знаниями, я сейчас выстраиваю процессы по адаптации новичков. Постарался максимум интересного в статью https://habr.com/company/flant/blog/419051/ о том, как я делаю это сейчас и какие векторы развития виднеются.

"Чёто он мне не нравится"

Когда технический менеджер или тимлид говорит такую фразу про кого-то из своих инженеров (и не только про них, на самом деле), мол, наверное надо увольнять - это прям грустно.
Грусть увеличивается в разы, если это происходит в "супер-пупер эджайл организации".
90% проблем в людях (если мы говорим про адекватную выборку людей в IT) решается просто *ртом*. Не нравится что-то в поведении человека ("расслабился", "кажется не внимательный", "тупит") - дайте ему обратную связь. Сделайте это правильно, чтобы
а) понять, считает ли он это проблемой
б) донести до него, что вы реально считаете это проблемой
Конечно, для начала разговора вам нужно сформулировать - в чём конкретно проявляется _вот это вот, что не нравится_.
Если вы достигнете согласия в вышеописанном - уже можно обсуждать как эту проблему сотрудник будет решать. Сроки, промежуточные точки, какие конкретно шаги он начнёт делать прямо сейчас.

На примере знакомых компаний: шуточки про бегство.

Что бы вы, как тимлид/технический менеджер, делали, если бы в чате-флудилке разработчики регулярно шутили бы на тему "пора валить", "всё валится - время обновлять резюме", "сделал говна - пора увольняться"?
Давайте обсудим в @TeamLeadTalks.

Ещё одна минутка оффтопа.
Заменил стандартный роутер "от провайдера" на собственный (Mi Wifi), с функцией 5G. И понял, насколько отстал от жизни. Не мог себе представить, что по вайфаю можно выжать больше 5 мегабит, однако же.
Учитывая, что игрушка стоила не так много и решает кучу других проблем - считаю, что это хороший пример для подражания.

У автора адовищного канала сегодня др.
Написать что-нибудь едкое, но по делу, можно тут: https://www.facebook.com/i.tsupko

Возник вопрос - как делать "раскрытие" в sequence диаграме, генерируемой с помощью plantuml.
Условно говоря - рисуете вы описание работы системы трёх систем

Система1->Система2: хттп запрос
Система2->Система3: загрузка файла

Как сделать так, чтобы ту же Систему2 можно было укрупнить и увидеть, что происходит внутри неё?

Ответ найден - plantuml умеет выдавать свой результат не только в png, но и в svg. И тогда на помощь приходят ссылки http://plantuml.com/link
Сам ещё не пробовал, но выглядит вкусно, особенно если подобную конвертацию сможет органично сделать модуль plantuml для гитлаба. Надо будет попробовать, как руки дойдут.

Я чуток залип в инженерные дела, и даже руки не поднимаются писать про технический менеджмент. Сорян.
Поделюсь пока одним вычислением, которое сделал намедни.

Моя паранойя периодически шепчет: "Заведи себе безопасный бэкап-сервер! Хватит бегать с жёсткими дисками! Только Raid-массив, только хардкор!"
Естественно, бэкап-сервер должен быть доступен для подключения только по VPN и закрыт от внешних воздействий. Естественно, он должен быть доступен с моих устройств, а в идеале - внутри VPN подключения должен быть доступ ко всем домашним инфраструктурам (чтобы можно было спокойно те же веб-камеры поставить) - впрочем, это уже следующий шаг.

Я полез смотреть - чего бы стоило сделать нормальный сервачок где-нибудь в Германии или Франции, с парой террабайт диска. И, с сожалением, пришёл к тому, что проще взять Raspberry Pi, подключить к ней два диска, сложить всё это в коробочку и поставить у надёжного человека дома.
Raspberry уже достал с полки, соображаю, как это лучше всё собрать в удобную коробку.

В чатике @TeamLeadTalks прям очень хороших несколько тем и постов о том, как сподвигнуть людей на что-то, начиная с https://t.me/TeamLeadTalks/7877 (спасибо @Constantine_f за помощь с освоением передачи ссылок в Телеграме)

Привет, канал. Мы с ребятами решились-таки поделать markdown ide, просто потому что можем :) Плюс надо чуток подготовиться к грядущим конференциям.
Недельку-полторы постов в канале не будет и потом я вернусь с новыми силами. В черновиках валяется много интересного, stay tuned.

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