Как донести HADI до руководства

Вышел мой совет о том, как продавать руководству идею продуктовых экспериментов — https://bureau.ru/soviet/20190516/

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

Вообще конечно лучше не нанимать людей, которых приходится увольнять :-)

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

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

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

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

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

Не копить изменения

Вроде бы простое правило, но соблюдается плохо, особенно в маленьких командах: никогда не копите изменения на стейджинге. Когда вы неделю пилите код, напилили 3000 строк и разом выкладываете это в прод, это почти всегда оканчивается проблемами и хотфиксами в мастере.

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

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

Растяните один релиз на 10 маленьких, но зато каждый день. 10 пулл-реквестов для одной задачи — это вполне нормально.

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

settings.local.py

Ещё один антипаттерн, который я часто встречаю в проектах Django (да, мне приносят их на ревью: напишите на fedor@borshev.com, чтобы я посмотрел ваш) — это несколько файлов settings.py для разных сред. Чем это вызвано, в общем-то понятно: думаю авторы джанги до сих пор краснеют от своей идеи хранить настройки в гигантском питоньем файле.

Но раз уж от settings.py мы никуда не денемся, давайте хотя бы попробуем его сделать более понятным. Представьте, что ваше приложение крутится в трёх местах: прод, стейджинг и машина фронтендера. Во всех — разные настройки доступа к БД, на дев-машинах могут быть отключены какие-то фичи и и.д. Если вы заведете settings.prod.py и settings.dev.py то, вам придётся заводить два разных докер-образа для этих целей, либо писать код, который в зависимости от среды будет определять нужный файл настроек. А правильно определять среду — весьма интересная задача, учитывая то, что делать это придётся изнутри изолированного контейнера.

Решать проблему разных настроек нужно при помощи третьего правила 12-факторного приложения — переменных окружения. Вся конфигурация вроде доступов к базе и фиче-флагов должна храниться в переменных окружения. Так вы сможете запускать одну и ту же кодовую базу через один контейнер в удобной конфигурации в любой среде — ведь переменные окружения так приятно хранить в docker-compose.py или в настройках UWSGI если вы олдфаг.

Для Джанго существует пакет django-environ: просто поставьте его и забудьте про settings.local.py.

Не разговаривать про программирование

Те, кто работал со мной знают, как я не люблю разговаривать про программирование с ребятами из бизнеса. Если не-программисты просят меня «добавить поле в базу» или «поставить один if» — я всегда обрываю такой разговор.

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

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

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

Красноречивый наброс на скрам, мол, Agile > Scrum = 💩 и у всех прорывает.

Если вы ничего не поняли — это нормально. Фраза — практически тест на то, занимались ли бизнес-программированием в последние 5 (10?) лет.

Agile — идея (учение) о том, как правильно разрабатывать программы. Вот простой для понимания первоисточник, рекомендую: 12 заповедей (принципов) Agile (русский перевод). Оцените полет мысли, это практически госпел (понимаю, почему его так любит Герман Греф).

Я капитально упорот на идее servant leadership и работал исключительно в стартапах. Даже я чувствую иррациональный страх перед идеями Agile. Уровень страха нормальных менеджеров можно сравнить со страхом фарисеев перед идеями Христа, я думаю. Поэтому авторами Agile Manifesto был придуман SCRUM.

SCRUM — четко описанные процессы, где отдельный человек и даже продукт уже не так важны. Можно стать сертифицированным коучем SCRUM, есть курсы SCRUM, можно повесить себе шильдик «успешно внедрили и следуем СКРАМ» и т.д.

Разница между Agile и SCRUM — примерно как между учением Христа и табачным бизнесом РПЦ. Поэтому в классных компаниях ценят результат и людей, этот результат достигающих, а в стремных — «процессы». Аминь.

@pmdaily, что скажешь?

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

Вон же программисты сидят: дойди ногами, объясни команде, как заработать деньги, получи MVP за пару дней. Но нет — у нас беклог, оценки-приоритеты, роадмап туда-сюда.

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

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

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

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

Так что если в вашей компании меньше 20 человек и вам приходится внедрять SCRUM чтобы их организовать — вероятно, вы наняли кого-то сильно не того.

Найм людей: лучше false negative, чем false positive

Лучше не взять хорошего специалиста, чем взять недостаточно хорошего — это особенно актуально для небольших команд в стартапах.

Самое главное в команде — общая среда, которую еще иногда называют «корпоративной культурой». Среда может развивать ответственность у новых участников (скажем, Студия Лебедева, почитайте их конституцию), а может наоборот, подавлять (как условный ЖелДорСвязьКредитБанк, где инициатива наказуема). В хорошей среде люди цветут и развиваются, в плохой — киснут.

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

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

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

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

Главное, не поддавайтесь классическому искажению, что у соседа трава зеленее — уйти в другую компанию вы всегда успеете :-) К тому же, если компания берет тимлида без опыта работы, это означает, что она ОЧЕНЬ сильно в нём нуждается. Не думаю, что место, которое нуждается в вас больше, чем вы в нем — хороший выбор.

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

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

Управление командой: военное и мирное время

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

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

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

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

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

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

Коммуникация в удалённой команде

Вышел мой совет об организации коммуникации в распределённой команде разработки — http://bureau.ru/soviet/20190606/.

Внедрите эти простые правила в своей команде, даже если вы сидите в одном офисе.

Кстати, мы в ГдеМатериале ищем маркетолога. Если хотите на деле увидеть, что такое правильная коммуникация в распределенной команде, поработать со сквозной аналитикой с точностью до рубля, в компании, где от идеи до внедрения проходит меньше недели — напишите Арсену @iamarsenibragimov.

​Ежедневный герой

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

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

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

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

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

Кстати, если вы — питонист, думаете сменить работу и хотите, чтобы код, написанный на работе, добавлялся в ваше опенсорс-портфолио — напишите мне на fb@gdml.ru.

Профессиональный сленг

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

Упомянул про юнит-экономику — и ты уже продакт-менеджер. Рассказал про отличия роторных машинок от индукционных — и ты уже тату-мастер.

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

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

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

Мне сказали — я копаю

В любой здоровой компании есть атмосфера критики. Кто бы ни пришёл с идеей: акционер, CEO или линейный сотрудник, его идею обязательно обсуждают и валидируют. Автору задают важные вопросы: «мы это делаем, чтобы что?», «если это не заработает, то из-за чего?» и тд. Такой фичекатинг, ещё до продакт-менеджера.

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

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

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

Вопрос: какой программист более ценен — кто глубоко знает одну технологию, или тот, кто в целом имеет хороший кругозор и знает много?

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

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

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

А вообще — не учите технологии, учитесь решать задачи.

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

Django и кластеры

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

Во-первых, они сделали модульную абстракцию от системы хранения — просто подключаем любой модуль из django-storages вместо FileSystemStorage и перестаём думать о хранении файлов.

Во-вторых, Django запускается через общепринятый протокол WSGI, что позволяет как угодно настраивать мультипоточность при помощи того же UWSGI. Я рекомендую классический master mode с двумя воркерами на контейнер, и ограничение по количеству запросов на каждый, чтобы не есть память.

В-третьих, почти вся функциональность, нужная для современного девопса, в Django сделана через удобные внешние зависимости.
— Мониторинг статистики через Datadog. Просто заводим его на каждой машине в кластере и получаем в дополнение ещё и мониторинг серверов.
— Сбор статистики через statsd. Можно использовать dogstatsd из того же Датадога, либо взять оригинальный, если хотите держать значения метрик у себя.
— Мониторинг ошибок — просто ставим sentry.
— Логирование — что угодно, мы в ГдеМатериале используем Papertrail, но можно тот же datadog
— Мониторинг здоровья контейнеров — django-healtchecks.

P.S. Кстати, Django работает и с модным serverless, так что если вы модный хипстер — обязательно посмотрите Zappa.

Поработал? Убери!

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

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

Если ваш ПР ничего не улучшает для других — это плохой ПР.

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

Если у вас на проекте все начнут следовать этому простому правилу, то ваша кодовая база начнёт ухудшаться гораздо медленнее.

Вопрос: расскажи, как ты находишь время на блог?

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

Каждый раз, когда я объясняю что-то новое, я обязательно после разговора записываю это в специальную доску в трелло. Одна карточка — одна мысль, 3–5 карточек в неделю.

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

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

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

Почему я не люблю оценивать задачи

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

Почему я не даю оценок маленьких задач? Во-первых потому, что если в задаче указано сколько её нужно делать, это подрывает саму основу контракта с исполнителем: ведь я же, отдавая задачу, ожидаю получить фичу на проде, а не 5 часов работы по написанию кода.

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

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

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

Где провести границу MVP

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

Вопрос: что разработчик должен знать о дизайне? А тимлид?

Если разработчик занимается интерфейсами, то базовые вещи вот такие:
— Теория близости и Закон Фиттса
— Анимация в интерфейсах
— Как писать тексты в интерфейсах

Идеально — освоить какой-нибудь дизайнерский инструмент, к примеру Фигму.

Когда закончите с технологиями, почитайте о продукте и результате:
— Понятие «боли» и «мира клиента», Джим Кэмп
— jobs-to-be-done или любая другая методика проектирования
— Психбольница в руках пациентов
— Intercom on Product Magement

Это был традиционный вопрос по понедельникам. Задать свой — @fedor_borshev, посмотреть другие ответы — #вопрос