Size: a a a

2019 October 25
FEDOR BORSHEV
Технические долги

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

Представь что ты увидел в магазине новый iMac pro. Можно пойти и накопить 400 тысяч (долго и муторно), а можно достать кредитку и купить прямо сейчас.

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

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

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

В командах у технического долга появляется ещё одно вредное свойство — по долгам одного нерадивого участника приходится платить другим. Относись к такому долгу, как к деньгам: представь, что ты в баре, и нашёл в кармане кредитку коллеги. Ты же не станешь угощать весь бар 18-летним Макаланом, правда?

Давайте жить не в долг и писать понятный код — так быстрее. И работу можно будет менять по собственной воле, а не из-за долговой ямы.
источник
2019 October 28
FEDOR BORSHEV
Вопрос: как вы поступаете с задачами, которые внезапно стали горящими, при условии, что вы не можете менять содержимое спринтов?

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

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

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

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

Почитайте другие ответы по тегу #вопрос или задайте свой вопрос на почту fedor@borshev.com#вопрос или задайте свой вопрос на почту fedor@borshev.com
источник
2019 October 30
FEDOR BORSHEV
Будь подробнее

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

Сравните два письма стейкхолдерам на эту тему. Первое: «Привет! Мы приняли задачу, но к сожалению не сможем гарантированно её сделать до конца спринта».

Или: «Привет! Мы приняли задачу. К сожалению, мы не сможем гарантировать, что сделаем задачу до конца спринта — дело в том, что она ушла стажёру. Конечно, у стажёра стоит дедлайн, но даже несмотря на то, что его сопровождает опытный программист, стажёр — всё-таки новый человек в нашей команде, поэтому результат мы гарантировать не сможем».

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

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

P.S. Как вы заметили, на канале стало гораздо меньше рекламы. Я решил совсем от неё отказаться, но у меня пока остались обязательства, поэтому в ближайшее время выйдет ещё 3–4 поста. Потом с рекламой будет долгое затишье.
источник
2019 November 01
FEDOR BORSHEV
Два способа отказать в задаче

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

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

Жёсткий — это честно объяснить: «к сожалению, Странное Говно — вообще задача не про деньги потому-то и потому-то. Давай подумаем, как мы могли бы её изменить, чтобы она стала про деньги?».

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

А самое главное — если жёстко не объяснять разницу между фичами про деньги и фичами про фичи, то ни один представитель бизнеса никогда не повысит уровень продуктовой осознанности — так и будет приходить со странными вещами, которые продакт будет хоронить в глубине беклога.
источник
2019 November 02
FEDOR BORSHEV
Ребята мне понравилось проводить вебинары :-) Вы оставили 30 отзывов, из которых видно, что два часа концентрированной информации отлично дополняют текстовые знания, которыми я делюсь здесь.

Давайте подумаем, о чём ещё мне рассказать в таком же формате?
Анонимный опрос
26%
Руководство удалённой командой: почему удалённые разработчики эффективнее, чем в офисе
24%
Как всё успеть (тайм-менеджмент): расскажу про внимание, время и хронофагов
10%
Роль программиста в продукте и аналитике: как приоритизировать, резать фичи и проверять гипотезы
6%
Как готовить Django: от бойлерплейта до 200 000 строк
33%
Развитие от джуниора до CTO: от самого начала и до управления людьми и проектами
Проголосовало: 1716
источник
2019 November 04
FEDOR BORSHEV
Вопрос: как оцениваете успешность/неуспешность фичи после релиза? На какие метрики смотрите?

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

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

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

Ответы на другие вопросы — #вопрос. Задать вопрос — fedor@borshev.com#вопрос. Задать вопрос — fedor@borshev.com
источник
2019 November 06
FEDOR BORSHEV
AirPods в один клик

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

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

Оказывается, этот процесс можно сократить до одного клика и пары секунд — есть специальные программы, которые сделали именно для того, чтобы моментально подключать AirPods к компьютеру. Я пользуюсь бесплатным workflow для Alfred, который так и называется AirPods Connector. Если у вас вдруг нет Alfred — не беда, заплатите 400 рублей за ToothFairy, которая делает то же самое.
источник
2019 November 08
FEDOR BORSHEV
На сайте бюро вышел финальный совет из серии о качестве кода — там я простым языком объясняю два процесса, которые поддерживают качество в любой команде — Continous Integration и Code Review.

Предыдущие советы:
Почему качество кода важно для бизнеса
Как измерить качество кода
источник
2019 November 11
FEDOR BORSHEV
Вопрос: скажи, есть ли у вас в процессе место для тестировщика, или это рудимент?

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

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

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

Это был традиционный #вопрос по понедельникам. Задайте свой на fedor@borshev.com#вопрос по понедельникам. Задайте свой на fedor@borshev.com.
источник
2019 November 13
FEDOR BORSHEV
Чем дольше срок, тем с меньшей вероятностью он соблюдается

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

Планируйте короткие и быстрые итерации, а не большие и сложные проекты.
источник
2019 November 15
FEDOR BORSHEV
Сомневаешься? Будь прозрачным

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

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

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

По итогам таких писем вам начнёт приходить внешняя критика — более опытные коллеги всегда с радостью делятся сомнениями. У нас в ГдеМатериале к примеру, прямо в гитхабе есть Али (@reshilavonasah), который видит весь журнал действий и периодически приходит с неудобными вопросами — одно знание об этом заставляет задавать вопросы себе до постановки задачи, а не после.
источник
2019 November 18
FEDOR BORSHEV
Вопрос: как вы оцениваете скоуп на итерацию?

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

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

Подробнее о двух планах на спринт см. в посте о буфере.


Задайте свой вопрос на fedor@borshev.com.fedor@borshev.com.
источник
2019 November 19
FEDOR BORSHEV
Правила роста: от джуниора до CTO

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

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

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

Участие стоит 1900 ₽, цена увеличивается на 200 ₽ каждую пятницу. Всем, кто купит билет до конца недели, я предлагаю поучаствовать в составлении программы — если хотите, чтобы я рассказал о чём-то, интересном лично вам — просто заполните форму в конце покупки.
источник
2019 November 20
FEDOR BORSHEV
Рабочее и личное время

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

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

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

Секрет в том, что когда делаешь что хочется, вместо того, что нужно, то время нужное на отдых сильно сокращается — можно спокойно работать по 6—7 дней в неделю, отдыхая когда нужно, а не когда положено обществом.
источник
2019 November 22
FEDOR BORSHEV
Sentry и sourcemaps

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

Кстати, source maps не обязательно выкладывать в прод — их можно грузить в Сентри прямо из процесса CI.
источник
2019 November 25
FEDOR BORSHEV
Вопрос: у меня есть коллега, который ушёл с senior-позиции в управление. Прошло несколько месяцев, и теперь он сомневается, думает вернуться назад — кажется что в разработке вышло лучше. Может быть у тебя есть какой-то паттерн ответа на его вопрос?

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

Лучше позадавайте коллеге открытых вопросов:
- Для чего он уходил в управление?
- Что из этого он сейчас не получил?
- Что нужно сделать, чтобы получить?

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

Ответы на другие вопросы — #вопрос. Задайте свой на fedor@borshev.com.#вопрос. Задайте свой на fedor@borshev.com.
источник
2019 November 26
FEDOR BORSHEV
Как вкатить в любой язык программирования без регистрации и СМС

1. Покупаешь хорошую книгу по твоему языку программирования. «Хорошая» означает, что её кто-нибудь кому-нибудь советовал в группах/форумах больше 5 раз. К примеру по питону это Марк Лутц — «Изучаем питон».
2. Изучаешь её всю, от корки до корки, делая все домашние задания.
3. Выбираешь самый популярный фреймворк на своём языке. «Самый популярный» означает «чаще всего упоминается на тематических сайтах». В питоне под веб это Django.
4. Изучаешь всю официальную документацию, от корки до корки. Проходишь официальные обучалки. Гугишь <framework> best practices, изучаешь их.
5. Делаешь свой пет-проект. Блог, сайт, исследование аномалий в поведении соседей, что угодно — зависит от выбранного языка.
6. Ищешь команду с высокой инженерной культурой, которая возьмёт тебя джуниором. Дальше учишься у них.
источник
2019 November 29
FEDOR BORSHEV
Рассказываю в «советах», почему с разработчиками, которые не вникают в бизнес, лучше не работать. Совсем.
источник
2019 December 01
FEDOR BORSHEV
Начинаем через два часа

В 14:00 начинаю стримить обещанную разработку по TDD — https://youtu.be/qrff0VyUWrk

Приходите!
источник
2019 December 02
FEDOR BORSHEV
Вопрос: как оценивать задачи с непонятной сложностью или новой технологией?

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

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

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

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

Другие вопросы — #вопрос. Задать свой — fedor@borshev.com#вопрос. Задать свой — fedor@borshev.com
источник