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

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

И оказывается, что потолок мечтаний - это 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 самых главных дела и так далее.

Делюсь одной из лучших моделей, описывающих как начать писать статьи и художественные тексты.

Меня тут хорошо пропесочили за пдф-ку. Спасибо, @factorized (он, кстати, делает проект http://documentat.io).
Вот его подборка:
- если речь о публицистике, то есть неплохая «Автор, ножницы, бумага» Кононова, https://www.mann-ivanov-ferber.ru/books/avtor-nozhniczyi-bumaga-kak-byistro-pisat-vpechatlyayushhie-tekstyi/, но она не про технические тексты
- ближе к техписателям/копирайтерам лежит Ильяхов, https://book.glvrd.ru/ и его набор советов, https://soviet.glvrd.ru/

Всем привет! Мы теперь дружим с @TeamLeadTalks - и предлагается обсуждение постов вести там :) Всё официально и без консервантов.
Да здравствует единство технических менеджеров и обмен знаниями!

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

Не правильно:
в ответ на вопросы других команд "какова вероятность провала?", "какие риски?", "стоит ли бояться?" отвечать "ну как получится", "поберегите нервы", "не переживайте" и "мы будем стараться".
Это то же самое, что человеку с депрессией сказать "не парься" - он будет париться, он в депрессии!

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

Технический менеджер: Мы будем переезжать на другой сервер на следующей неделе
Другая команда: Но у нас релиз в среду!
Технический менеджер: В среду убедимся, чтобы всё работало. Сообщишь за 2 часа до момента Х, что скоро покатите? Сколько вам времени на релиз нужно?
Другая команда: Ок. В идеале 2 часа, но скорее всего как обычно затянем на 5.
Технический менеджер: Договорились.

Управление знаниями: диагностика багов

Есть методология диагностики багов, которая повышает интеллектуальный уровень разработчиков, помогает со "сложными" багами и делает ваши волосы мягкими и шелковистыми.
Очень здорово, если ваши ключевые алгоритмы (они же - ключевые действия пользователей) будут описаны в виде sequence диаграм (https://cdn-images-1.medium.com/max/1820/1*vnSPuXKP9w7He0CBkLtaKA.png например). Колонки - это компоненты проекта. В парадигме микросервисной архитектуры это могут быть микросервисы, в парадигме монолита - например, модули.
Смысл заключается в том, чтобы научить инженеров представлять себе картинку процесса целиком и уметь его держать в голове. Потому что смысл любой диагностики сводится к половинному поиску по этой схеме: берём наиболее интересную точку, проверяем в ней состояние и делаем выводы, где проблема - выше или ниже.

Управление знаниями: диагностика багов, часть 2

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

Тикет: не загружаются файлы
Зашёл в Sentry - вижу ошибку, что кончилось место
Зашёл на srv1
Набрал команду df, места на /dev/sda1 1 мегабайт

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

В любом случае, это хороший способ обучать людей.

Разбавлю серьёзные посты :) Приснился мне тут сон к стиле кибер-панк.

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

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

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

Прямо сейчас обсуждаем документацию на Highload Siberia. Вот непрерывно обновляемый конспект: https://github.com/NickVolynkin/highload-siberia-2018/blob/master/docs-meetup.md

Как заставить людей докать и использовать доку?

Только меняя процессы, чтобы через доку шли коммуникации. И нет, это не противоречит "эджайл манифесту" и прочим модным вещам.
Как изменить подход к коммуникациям, если у вас нет власти - я хз. Если вы знаете - пожалуйста, расскажите в @tinyest_devil_secretary_bot.
Добивайтесь власти, чоуж.

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