​Как резать фичи на основе экспериментов

На сайте бюро вышел мой совет о том, как резать фичи на основе экспериментов — 
https://bureau.ru/soviet/20190425/

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

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

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

Лайфхак: не пишите код, если вам скучно. А лучше вообще не начинайте новые проекты с кода. Особенно, если вы в этом не профессионал, и не хотите делать программирование своей профессией. Придумайте, как проверить вашу идею без кода. Возьмите готовый бекенд вроде FireBase, накидайте интерфейс в Retool, сверстайте сайт на Тильде, возьмите какую-нибудь Headless CMS если надо.

В общем не думайте про код, думайте про максимально быстрый прототип. Когда у вас на руках появится провернная идея с прототипом, вы легко сможете привлечь профессионалов, которые напишут код за вас. Ну а потом всего 10 лет поработаете по 12 часов в день без выходных, и там уже до IPO недалеко.

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

#работамечты

Аналитик к нам в ГдеМатериал

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

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

Любой аспект нашей деятельности мы покрываем цифрами. Если вам не хватит данных — поможет команда разработки во главе со мной. Данные храним в PostgreSQL и Google Big Query, все БД объединены в единое информационное пространство — мы легко делаем джоины между данными по посещаемости сайта и отгрузкам товаров.

Работа удаленная, график свободный.

Если вы умеете соблюдать дедлайны и знаете SQL на отлично — напишите Саше Хлебниковой на ahleb@gdml.ru.

Если вы джуниор — тоже напишите, возьмем на стажировку и научим.

Вопрос: как ты думаешь, CTO — это рост из тим-лида или тех-лида?

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

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

Вообще, в подборе людей самая сложная задача у CEO — он вообще должен нанимать исключительно людей, сильнее себя :-)

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

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

Пулл-реквесты меньше 500 строк

У нас в ГдеМатериале есть правило — пулл-реквест не должен быть больше 500 строк.

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

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

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

Избавиться от состояния

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

Чем меньше в вашей инфраструктуре состояния — тем лучше. Идеальный вариант для небольших проектов — отдавать работу с состоянием профессионалам: хранить файлы в облачных бакетах, базу — в managed базах данных.

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

А вот если файлы хранятся в облаке, то достаточно прописать read-only доступ к ним в docker-compose.yml, и все будет доступно на той же машине, на которой запускают бекенд. Так любой фронтендер сможет поднять у себя сайт со всеми картинками и отлаживать верстку локально, или, скажем, тестировать производительность в CI.

#гитхаб анонсировал package registry — реестр внутренних пакетов организации. Фактически это полная замена gemfury, о котором я писал в прошлом году, и немножко замена docker hub (реестр контейнеров тоже есть).

Кроме докера, есть поддержка JS, Java, Ruby и .NET, другие, думаю, тоже скоро подвезут.

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

Анонс тут, записываться на бета-тестирование тут.

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

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

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

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

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

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

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

​Начинаем проект на Django: собственные точки входа

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

К примеру, ваш фреймворк предоставляет базовую модель — сделайте собственную копию и наследуйтесь от нее. То же самое с базовыми вьюхами, базовыми пермишенами и базовым всем.  Минимум для Django  — базовая модель, базовый ModelAdmin и базовый вьюсет DRF. Для базовой модели рекомендую выбрать что-нибудь из django-behaviors.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

settings.local.pysettings.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.