Менеджер реагирующий vs менеджер инициирующий

Всю активность менеджера можно условно разделить на два вида: реагирование и инициирование. Реагирование — это работа с внешними раздражителями: телефонными звонками, письмами, коллегами, которые подошли с вопросом.

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

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

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

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

​Почему я не люблю дейли-митинги

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

Но с другой стороны, руководитель, который назначает обязательную ежедневную встречу, как бы говорит своей команде: «ребята, вы плохо справляетесь с коммуникацией и тайм-менеджментом, поэтому вот вам теперь фреймворк — дейли-митинги. Теперь вам не нужно ничего думать, просто каждое утро собирайтесь и проходитесь по пунктам». Это не страшно — многим людям этого правда не хватает. Но лично для меня выглядит как наказание.

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

Мы в mtrl.ai практикуем в команде дейли-митинги только в двух случаях — когда несколько человек делают один проект (и сами об этом договорились), или когда участник не справляется с задачами и ему нужна помощь извне.

​Вопрос: вот у вас большое приложение на Django. Как вы разбиваете код по отдельным приложениям внутри?

Сейчас самый большой наш проект разбит на ~50 приложений Django, и намертво мы завязаны не больше, чем на 10 из них.

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

Если я отцеплляю новое приложение и падает всего пара десятков тестов — это ок. Если падает 100 и больше — значит я написал что-то слишком толстое.

Ну а в остальном — нужно ориентироваться на здравый смысл и размер models.py.

Другие вопросы — #вопрос. Задать свой — @fedor_borshev.

Кстати, ответьте пожалуйста, насколько вам здесь интересно читать про Python/Django и вообще про разработку больших приложений с точки зрения кода?

😞 — пофиг, 😍 — интересно, 🚴 — еще расскажи про девопс и микросервисы на ноде

FOMO

FOMO это когнитивное искажение, которое заставляет нас делать странные вещи, к примеру покупать акции «на новостях» — когда упал второй боинг подряд, и мы сломя голову бежим покупать вдолгую.

Тот же самый FOMO настигает нас в торговом центре, когда мы заходим в магазин с распродажей и покупаем себе третий подряд ненужный джемпер, «потому что потом подорожает».

FOMO — это сокращение от Fear Of Missing Out, страх упустить возможность. Он сидит настолько глубоко в каждом из нас, что часто не мы находим возможности, а возможности находят нас и подчиняют себе. Увидел красивый банер с детьми и улыбающейся женщиной в домашней одежде, по телефону тебе объясняют, что цена действует «всего три недели» — и бац, ты уже подписываешь кабальный контракт, по которому 15 лет (треть активной жизни!) будешь платить за однушку посреди поля в 40 километрах от МКАД.

Да, возможности нужно ценить. Акции действительно выгоднее покупать, когда они дешевеют. Одежду действительно лучше покупать на распродажах. Но это нужно делать по плану: купленные акции должны соответствовать стратегии портфеля.

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

Однако Salomon — кроссовки надежные. Если вдруг скидок в феврале не случится (или я не смогу ими воспользоваться, как в этом году), то я не останусь без обуви — просто прохожу ещё год в тех же самых кроссовках.

Так что читайте Нассима Николасовича и не упускайте возможности.

1:1 вместо дейли-митингов

Сразу несколько ребят спросили в личку, а как мы вообще общаемся в команде. Отвечу — коммуникация между разработчиками никак не регламентирована (все взрослые, а команда пока маленькая). А общение разработчиков со мной имеет один обязательный элемент — периодические встречи 1:1.

Я обязательно провожу такие встречи с каждым без исключения участником команды. Цель 1:1 — получить обратную связь: хорошо ли прошли последние спринты, получает ли программист удовольствие от задач, какие проблемы в команде и процессах он видит, что его беспокоит.

Хотя 1:1 может проходить в свободном режиме, совсем без повестки, я готовлюсь к ним все время — в Notes есть заметочка для каждого сотрудника, в которую я записываю идея для обсуждения на следующей 1:1.

Django — это API

Периодически встречаю ребят, которые учат Django от корки до корки, включая такие странные вещи как Django Templates или Django Forms.

Ребята, не тратьте на это время! Если на вашем проекте в 2019 году генерируют HTML на бекенде, он скорее всего серьезно болеет. Гораздо быстрее, понятнее и проще взять любой современный JS-фреймворк. Или вообще без него обойтись, но ни в коем случае не генерить HTML в Django.

В Django есть несколько удобных и красивых (если не читать исходники) вещей — Django ORM, Django admin, вещи связанные с обработкой HTTP-запросов и переводами. Во всем остальном Django — это монстр из начала двухтысячных, затаскивая которого в проект вы с первой строчки начинаете писать legacy.

Так что ставьте DRF, Graphene или что вам ближе, но даже не пытайтесь генерить HTML на джанге.

​Уменьшить количество обещаний

Обещания надо соблюдать. Пацан сказал — пацан сделал.

Самый хороший способ соблюдать обещания — давать их поменьше. К примеру я очень не приветствую обещания, которые оканчиваются посреди спринта: если задача ушла в спринт, то у неё должен быть такой же дедлайн, как и у всех остальных.

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

К тому же, когда у команды каждый день — дедлайн, это давит. Когда дедлайн раз в две недели — давит только раз в две недели. А при своевременном контроле и здоровой атмосфере в команде — не давит вообще.

Не надо учить технологии — учитесь решать задачи

В личке много ребят задают вопрос — как правильно выбрать технологии? Что учить, чтобы не отстать от прогресса?

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

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

Пример хард-скилла — умение размахивать молотком. Само по себе это умение ничего ничего не стоит. Молоток нужен, чтобы забить гвоздь, а гвозди забивают, чтобы построить дом. Вот это и есть самое главное умение — строить дома. И это — софт-скилл.

Чем вы построите этот дом: шуруповертом, подъёмным краном или нанятой командой монтажников — не так уж важно. Важно ваше умение решать задачи, при необходимости включая в свой арсенал неизвестные ранее инструменты.

​Вопрос: вот уже третий раз пытаюсь внедрить пустой инбокс, но к концу недели все равно копится гора писем, которую не хочется разбирать. В итоге я в унынии забиваю. Что делать?

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

Если количество писем в инбоксе причиняет сильное беспокойство (ааа, 200 писем, куда бежать??77) то вряд ли вы их когда-нибудь разберете. У меня вообще в такие моменты включается чувство вины (условное «я дно, даже почту разобрать не могу»). Хочется всячески прокрастинировать: писать всем в телеграм, звонить по телефону, или тупануть в фейсбучек.

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

1) «Отвечу через неделю». Можно просто пообещать ответить через неделю, запланировать задачу, и заархивировать письмо. Есть много задач, для которых это нормально: к примеру вы обсуждаете постановку задачи на следующий спринт, до которого ещё пара недель. Избавляешься таким образом от первого десятка писем — и отвращение выключается, дальше начинается нормальный разбор.

2) Попрятать все письма куда подальше. Смысл в том, чтобы убрать вообще все напоминания о неразобранной горе, включая саму папку входящих. Помогает от отвращения, которое возникает в момент открытия почтового клиента, чтобы, скажем, написать письмо. Я для этих целей держу специальную папочку «_empty», куда прячу все письма из инбокса, пока он не дорастет до нормальных размеров. Содержимое этой папочки разбираю потихоньку, по 30 минут в день.

3) Почтовое банкротство. Внезапно, можно просто удалить все письма. Кому надо — еще раз напишут. Я так делаю два-три раза в год, и пока никто не умер :-)

Другие вопросы — #вопрос. Задать свой — @fedor_borshev.

​Автоматизация рутины при помощи клавиатурных шаблонов в маке

Я, как любой разработчик, люблю автоматизировать рутину. В этой заметке расскажу про не очень очевидный способ автоматизации — при помощи клавиатурных шаблонов.

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

Поэтому я выбрал путь настоящего джедая — клавиатурные сокращения в настройках мака: Keyboard → Text.

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

Набираю «календарик» и получаю ссылку на свой appoint.ly, которую высылаю для назначения встречи со мной, чтобы не обмениваться письмами.

​Ответы на вопросы переезжают

Ответы на вопросы про ИТ, которые я давал по понедельникам, плавно переезжают на сайт Бюро Горбунова. Там они будут выходить в формате советов, по четвергам, раз в три недели.

Аудитория бюро по большей части состоит из дизайнеров и руководителей, а вопросы ко мне прилетают гораздо чаще, чем раз в три недели, поэтому я продолжу отвечать и здесь. На сайт бюро пойдут более развернутые и фундаментальные ответы, а здесь останутся короткие и практические советы. Например, вопрос «Федя, расскажи вы у себя оформляете пулл-реквесты» получит ответ в канале, а «Федя, какие технические знания нужны менеджеру, чтобы управлять командой программистов?» — пойдет на сайт Бюро.

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

Совет на сайте бюро можно спросить не только у меня, но и у других экспертов в дизайне продуктов и услуг, верстке, переговорах, программировании, управлении проектами и редактуре:

А еще на VC вышла моя статья о том, как правильно готовить гитхаб, чтобы людям не приходилось переключаться между 5 разными средствами коллаборации — https://vc.ru/services/60710-github-kak-edinstvennoe-sredstvo-obshcheniya

Если на работе вас сейчас достает Асана\Битрикс\Жира и слек с телеграмом, почитайте по ссылке как надо было.

Python: никогда не использовать unittest

В стандартной библиотеке питона лежит модуль unittest — набор инструментов для написания тестов. В комлпекте Django лежит даже надстройка над unittest, которая умеет ходить в API и заворачивать тесты в транзакции.

Так вот — никогда не пытайтесь использовать эту библиотеку, даже на маленьких проектах и даже чтобы попробовать. Unittest — ОЧЕНЬ плохая библиотека.

Начнем с того, что unittest — это порт древнего Junit, кажется вообще первого инструмента для тестирования, которое придумало человечество еще в 90-х годах. От Java в нем осталось совершенно ненужное ООП и наркоманские ассерты, вроде self.assertEqual(a, 'b') вместо assert a == 'b'.

А еще:
— unittest не умеет нормально распараллеливать тесты (вроде бы есть nose, но он умер). Когда на проекте появляется больше 500 тестов, это становится большой проблемой.
— unittest не позволяет переиспользовать фикстуры. Только через наследование, из-за которого вы очень быстро перестаете понимать, что у вас вообще происходит.
— В unittest очень неудобно отключать тест большими кусками — у вас нет возможности пометить набор тестов, скажем как требующий elasticsearch, и прогонять их только в средах, где elasticsearch доступен — только по именам тестовых классов
— У unittest очень плохой генератор тестов.

Возьмите лучше pytest. Да порог входа чуть выше — функциональное программирование понятно не с первого раза. Но если вы собираетесь построить проект с управляемыми тестами, то замену вы вряд ли найдете.

Кстати, каждый тесткейс на unittest — это тесткейс и на pytest, так что можете взять его прямо сейчас.

​Чем опытнее программист, тем проще код он пишет

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

Я говорю не о цикломатической сложности — дело скорее в читаемости. У новичка код как будто из фильма про хакеров: неинтутивные названия переменных (o вместо order), сложные методы, излишние абстрактные классы и генераторы, «лазанья» и т.д.

Хотите стать синьором — пишите проще. Представьте, что ваш код будет читать QA, который не сильно глубоко знает ваш язык, и сделайте так, чтобы он вас понял.

Вопрос: были ли у вас проблемы с внимательностью у разработчиков? Как отлавливаете это на собеседовании?

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

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

А вообще хочется разобраться поглубже — какие проблемы невнимательность вызывает в бизнесе? Возможно проблема не в разработчиках? К примеру, если вам кажется, что из-за невнимательности говно часто попадает в релиз, то наверное у вас плохие тесты или проблемы с QA. Если невнимательность приводит к тому, что программисты не соблюдают требования, прописанные в задачах, то может быть вы просто мало говорите со своей командой?

Другие вопросы — #вопрос. Задать свой — @fedor_borshev

Стали бы мы делать эту задачу, если бы компании оставалось жить две недели?

А месяц?

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

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

Надо отдать должное студии — ощущение огромного количества происходящего вокруг не отпускало меня все те несколько лет, которые я там проработал.

Когда я попал в ГдеМатериал, количество происходящего только увеличилось — я со своей энергичностью попал в стартап, который и без меня летел вперёд со скоростью света. За два месяца мы запустили прототип платформы, за три — работающую MVP с личным кабинетом поставщика и кучей интеграций со всеми нужными системами.

С тех пор скорость одного разработчика конечно замедлилась (совсем немного), но скорость разработки в целом только увеличилась за счёт удобной инфраструктуры, девопса и того, что мне повезло набрать идеальную команду.

К чему это я? Если на текущем месте работы вы замечаете, что вокруг происходит мало нового — напишите мне.

Мы ищем:
— Продакт-менеджера
— Дизайнера
— Фулл-стека Django + vue.js
— Фронтендера, который умеет писать тесты и не боится верстать (vue.js, сайт у нас на гридах)

Работа удалённая у всех, кроме продакта. График — свободный.

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

Для начала разговора просто напишите мне на fb@gdml.ru.

Презентация — неотъемлемая часть работы

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

Отвечаю — работает прекрасно: в 99% случаев, когда исполнитель приложил видео или скриншот к задаче, она не возвращениям обратно со словами «ничего не работает».

Презентация работы — это неотъемлемая и равноправная часть самой работы. Недавно мы, к примеру запускали новый калькулятор доставки. У нас он сложный — тарифы зависят от срочности, особенностей товара (к примеру гипсокартоновый профиль не увезешь на Портере), необходимости поднимать, носить, разгружать товар и ещё кучи параметров.

С задачей мы справились — все эти параметры начали сводиться к одному единственному числу — стоимости доставки. Но переписка с бизнесом по поводу крайних случаев затихла только тогда, когда внизу, по специальному GET-параметру мы вывели полную расшифровку: доставка стоит X рублей, потому что в заказе есть вот такой-то габаритный товар, общий объём корзины такой-то, а ещё вот надбавка за срочность.

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

Вопрос: как программисту начать отвечать за результат? Не просто выполнять задачи, но и предлагать своё видение?

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

Реальный пример:
— Давай сделаем рассылку писем через мейлджет? Будем сами рассылать по нашей клиентской базе, сделаем сервис отписки и т.д.
— Но ведь у мейлджета уже есть инструменты не только для транзакционных, но и для маркетинговых писем. Это как раз то, что нам нужно! Давай их заюзаем?
— Ну, а зачем нам от него зависеть? А если мы провайдера сменим? Давай лучше про следующую задачу поговорим.

Сделали предложение, задав плохой вопрос. Получили плохой ответ, и итоге в спринт уходит плохая задача.

Чтобы принести пользу — задавайте открытые вопросы:
— Давай сделаем рассылку писем через мейлжет? Будем сами рассылать по нашей клиентской базе, сделаем сервис отписки и т.д.
— Скажи, а чего нам не хватило в стоковой функциональности мейлджета? Почему ты решил усложнить?
— Мы хотим по расписанию отправлять дайджест из самых популярных товаров за неделю, а руками каждый раз их лень верстать. На шаблонах мейлджета такое сделать невозможно.
— А что если мы скриптом сверстаем 5 писем на месяц вперед, разошлём силами мейлджета, а если письмо докажет свою эффективность, то будем думать, как автоматизировать?
— Давай!

Задали открытые вопросы, поучаствовали в диалоге, принесли пользу: не делаем глупую задачу.

Отвечая на ваш вопрос — просто побольше участвуйте в обсуждениях, но всегда начинайте с вопросов, а не с предложений.

​Сначала процесс, потом автоматизация

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

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

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

Пока люди сами не протопчут себе дорожку — никакие указатели направления не заработают.