Когда всё горит

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

На тему преодоления кризисных ситуаций с точки зрения руководителя принёс вот такую статью.

Автор предлагает сосредоточиться на следующих аспектах.

Обеспечение поставок продукта (круто звучит по-английски – Ensuring Goal-Aligned Delivery).
– жесточайше приоритизируйте: нужно сосредоточиться только на самых критических моментах
– ускоряйте работу: сократить бюрократические проволочки, выдать команде полномочия на принятие решений
– цените время: нужно максимально ограничить отвлекающие факторы, убрать лишние встречи
– управляйте техдолгом: он неизбежно будет расти, а ваша задача аккуратно фиксировать и подсвечивать проблемные места для будущих фиксов
– будьте с командой: вы как руководитель должны быть вовлечены в проблемы проекта и команды, помогать их решать

Под каждый пунктом готов подписаться, все их так или иначе применяли в разных кризисных ситуациях. Эти шаги действительно позволят в кризисной ситуации продолжать поставлять продукт.

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

И ещё немаловажное замечание. Не забывайте о своем здоровье: вы не сможете помочь другим, если сами выгорите. Заботьтесь о себе, находите время на отдых и восстановление. В конце концов, не корову проигрываете.
#edu #teamwork

When to write strategy, and how much?

Отличная статья Will Larson. Она посвящена созданию стратегии в инженерной команде с акцентом на выборе подходящего момента для её написания, определении оптимального объёма и способе внедрения.

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

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

Далее самое интересное. Для внедрения стратегии нужно учитывать масштаб внедрения (команда или вся организация) и стиль изложения стратерии: запретительный (proscriptive, пример: "блокировать MR, если код не прошёл линтеры") или разрешительный (permissive, пример: "давайте использовать линтеры, вот основные правила, в каждой команде можно кастомизировать под себя"). Чем больше масштаб внедрения, например, на уровне всей компании, тем больше разрешительных пунктов должно быть. Иначе вряд ли стратегию получится внедрить.

Немаловажный момент, на который обращает внимание автор – оценка эффективности стратегии, а также её влияние на принятие различных решений.

Статья любопытная, как и многие другие от этого автора :)

#edu #systemdesign

Пятничное развлекательное

Проблема вагонетки – это известная этическая задача, иллюстрирующая сложность морального выбора. Задача звучит так: представьте, что вы управляете рычагом, который может изменить путь вагонетки/трамвая. По текущему пути вагонетка мчится на пятерых людей, и, если ничего не сделать, она их собьёт.

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

Наткнулся недавно на замечательный ресурс – Absurd Trolley Problems, моделирующий проблему вагонетки.
Действительно любопытно потыкать, а также посмотреть, как отвечают на эти непростые вопросы другие люди.

#fun #edu

Закон Конвея

Как-то так получилось, что в последнее время вокруг меня несколько раз упоминали закон Конвея.

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

Фаулер предлагает три подхода к учёту закона Конвея:
🔹 Игнорирование — не учитывать закон, что обычно приводит к проблемам в архитектуре.
🔹 Принятие — проектировать систему так, чтобы архитектура соответствовала структуре взаимодействия команд.
🔹 Инверсный манёвр Конвея — перестроить организацию команды для достижения желаемой архитектуры (часто применяется в микросервисах).

В заключении подчеркивается, что важно учитывать закон Конвея не только при создании архитектуры, но и на протяжении всего жизненного цикла проекта, организуя эволюцию архитектуры и организационных структур вместе.
#edu #systemdesign

Как я использую папки в Телеграм для удобства

Меня несколько раз спрашивали, как я живу с сотней активных чатов и десятком групповых. Сегодня необычное — о нашем опыте применения папок в ТГ для асинхронной коммуникации по работе. Как работать с огромным количеством чатов с длительным сроком жизни? Как удобно организовать чтение каналов, если у вас сотня каналов к прочтению?

#devfm #edu #tools

Почему не нужно отвлекать программиста

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

В статье Как поймать «поток», и как сделать так, чтобы он не сорвался объясняется, что такое состояние потока и как постоянное прерывание этого самого потока замедляет работу. По оценке автора, погружение в состояние потока "стоит" 15 минут, то есть любое прерывание имеет вот такие дополнительные накладные расходы.

В статье Как я использую папки в Телеграм для удобства мы делились опытом, как можно настроить Телеграмм для асинхронного общения, что как раз направлено на сохранение потока.

#edu

Когда ИИ заменит разработчиков, то...

Татьяна aka IT DIVA пишет о негативных последствиях замены миддл-инженеров на ИИ. О таких планах заявил Цукерберг на интервью у Джо Рогана (новость, оригинал подкаста на ютубе на 02:07:32). Конкретно прогнозам Цукерберга я бы особо не верил, потому что его мета-вселенные провалились. Но указанная тенденция действительно существует.

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

2. Текущая кодовая база и так сложная, а написанный ИИ код будет ещё сложнее. Плюс на большом проекте добиться от ИИ результата будет сложнее.

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

Но, вероятно, это можно решить с помощью образования. Институт должен готовить пригодных для работы сотрудников. И крупные компании активно вовлекаются в образовательную движуху. Теперь нужно будет готовить разработчика, который умеет эксплуатировать ИИ для написания кода. Порог входа в профессию вырастет. Но он и сейчас довольно большой. Для разработки нужно знать много технологий, и чем дальше, тем больше. Если классическое образование не справится, то на помощь придут разные книги, курсы (в том числе бесплатные) и другие источники знаний.

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

#edu

Пятничное развлекательное

No Vehicles in the Park — необычная инди-игра, которая на самом деле не про транспорт, а про контент-модерацию.

Как установить простые правила для сложных явлений? Где границы допустимого? И можно ли вообще создать систему, которая не сломается об исключения и контекст?

Разработчик вдохновился гипотетическим кейсом "No vehicles in the park" (H.L.A. Hart, 1958) и решил показать, что контент-модерация — это не просто вопрос скорости обработки жалоб, а фундаментальная проблема неопределённости.

В итоге получился интерактивный эксперимент: какие "транспортные средства" вы запретите в парке? Где проходит грань между велосипедом и инвалидной коляской, игрушечной машинкой и электросамокатом?

Стоит ли пытаться вписать хаос в жёсткие правила или проще отказаться от модерирования совсем?

#fun #edu

Как проводить skip level 1-1

Любопытная статья, посвящённая проведению 1-1 встреч с коллегами на два и более уровня ниже вас. Такие встречи называются один-на-один, или one-to-one, сокращённо 121.

Я не знаю термина, обозначающего такие встречи на русском языке, но в английском есть емкое название skip level 1-1.

С моей точки зрения, начало статьи достаточно банальное, но в разделе с советами автор даёт несколько действительно полезных рекомендаций.

По части организации таких встреч:
— Встречи должны быть прозрачными. Важно заранее обозначить для собеседника формат встречи, её цели, подготовить примерный набор вопросов и ожиданий от встречи.
— Желательно, чтобы такие встречи проводились регулярно. Это позволит избежать нежданчиков и стресса для коллег.
— Руководители людей, с кем вы проводите встречи, также должны быть в курсе таких встреч и их целей.

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

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

#teamwork #edu

The 37signals Guide to Internal Communication

Мы уже писали про замечательную книгу Getting Real от ребят из 37signals.

Давно хотел написать про ещё один классный гайдлайн от ребят — The 37signals Guide to Internal Communication.

Мы внедряем различные практики разработки — как пишем код, какие линтеры используем, как проводим ревью и т.д. А вот как правильно коммуницировать, чтобы были единые, всем понятные правила? На моей практике с этим аспектом не всё так гладко.

В гайде вас ждёт набор очень ёмко сформулированных правил коммуникации. Приведу без перевода особенно откликнувшиеся мне:
— Real-time sometimes, asynchronous most of the time.
— Meetings are the last resort, not the first option.
— Speaking only helps who’s in the room, writing helps everyone.
— If your words can be perceived in different ways, they’ll be understood in the way which does the most harm.
— Never expect or require someone to get back to you immediately unless it’s a true emergency. The expectation of immediate response is toxic.
— Five people in a room for an hour isn’t a one hour meeting, it’s a five hour meeting. Be mindful of the tradeoffs.
— “Now” is often the wrong time to say what just popped into your head. It’s better to let it filter it through the sieve of time. What’s left is the part worth saying.
— Urgency is overrated, ASAP is poison.
— Ask if things are clear. Ask what you left out. Ask if there was anything someone was expecting that you didn’t cover. Address the gaps before they widen with time.

#teamwork #edu