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

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

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

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

Стоит ли делать чатег канала? anonymous poll Дааа! Больше чатов богу чатов! Тысячи их! – 21 👍👍👍👍👍👍👍 54% Лучше запартнёриться с большим комьюнити и жить в интересном сообществе тимлидов – 10 👍👍👍 26% Нет, нафиг, и так всё в чатах, задрало – 8 👍👍👍 21% 👥 39 people voted so far.

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

Как начать внедрять фиксацию знаний в компании. Конечно, проще всего делать с самого начала, с момента, когда команда собирается. У меня был такой опыт и, по отзывам, вполне успешный (хотя есть подводные камни, о которых расскажу позже). Как поступать с командой, в которой уже сложились подходы - также в грядущих постах :) Как начать с самого начала? Начнём с тезисов: - люди не хотят, не любят и не будут документировать. Их придётся заставить и научить. - люди не умеют в русский язык - хороших экосистем для документации не существует, их надо будет строить. И они сейчас строятся выходцами из техписовой тусовки, но медленно. Люди пока не верят в финансовую отдачу от этой движухи. - документация - это вещь _на стыках_ между людьми/ролями. Нет смысла делать документацию в тех местах, где стыка нет. Подробно всю эту тему освещал тут: https://www.youtube.com/watch?v=NGiN3df_YGc В том числе в видео вы найдёте пример структуры доки и объяснение того, какую структуру доки нужно построить именно вам.

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

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

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

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

Бывает, заговоришь с человеком, мол, с требованиями надо работать аккуратно, а он такой: да, да! Хорошо так на душе становится: разговариваешь с умным человеком. А потом: а давай поговорим об этом. Что вы делаете? И оказывается, что потолок мечтаний - это 1-2 странички с рисунками интерфейсов и описания визуального поведения системы. Карл, этого мало! Карл! Сейчас поясню, о каких проблемах я говорю. - Требования - они порождаются аналитиками. А в это слово в нашей стране слиты две профессии: UX-аналитик и бизнес-аналитик. К сожалению, некоторые люди не видят разницы, и нанимают первых (они вроде что-то понятное говорят - про дизайн и вот это всё). Функция бизнес-аналитики тем не менее должна быть в команде, и если вы не разместите её самостотельно где-то рано в процессах - она окажется на исполнителях или вообще на QA (видел и такое!). Что гарантирует вам постоянную переделку продукта. - Бизнес-аналитиков нельзя в неподготовленном виде вставлять в современную команду. Они обычно зарождаются в недрах энтерпрайза и пишут многостраничные требования, не пригодные, к сожалению, для гибких и невнимательных эджайл сотрудников. Этап передачи бизнес-требований исполнителям - одно из самых чувствительных к сбоям мест для сколь-нибудь сложоных (с бизнесовой точки зрения) систем. Бизнес-аналитика - это ответ на вопрос "нахуа так было сделано?", самый важный вопрос при модификации системы. - Почти никто не отслеживает конфликтов на этапе требований. Новый продакт Вася хочет убрать с формы лишние поля - а эти поля используются ребятами из аналитической команды или вообще выгружаются в другую организацию. То есть да, кто-то должен периодически проходится по тикетам с требованиями и линковать их, мол, "связаны по смыслу" - и автоматизировать это никто ещё не нашёл способа. - Разработчикам нужна внутренняя дока. Так или иначе. И эта дока - должна быть связана с требованиями. Думаю, не надо объяснять почему. - Ну и, наконец, то, чего все очень хотят, но я не слышал, чтобы у кого-то было. ТРАССИРОВКА. Чуть ли не от кода: каждая строчка в системе контроля версий так или иначе промаркирована номером тикета, породившего её. А от номера тикета должна быть возможность взойти к ответу на вопрос "нахуа так было сделано?". Конечно, это влажные мечты, а жизнь вносит свои коррективы. Но вообще говоря, всё это можно сделать без сильного проседания производительности.

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

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

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

В какой котёл подкинуть дровишек? anonymous poll Нужно больше управления знаниями! Уменьшение bus factor, финансовая отдача от документации, вот это всё – 16 👍👍👍👍👍👍👍 40% Нужно больше про софт-скиллы: стрессы, целеполагание, убеждение - всё на реальном опыте – 12 👍👍👍👍👍 30% Процессы и лидерство в команде. Как взять власть, как удержать и как остаться при этом адекватным. – 10 👍👍👍👍 25% К чёрту детали: рассказывай больше о людях в индустрии и об интересных возможностях – 2 👍 5% 👥 40 people voted so far.

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

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

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

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