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

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

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

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

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

Почитайте другие ответы по тегу #вопрос или задайте свой вопрос на почту fedor@borshev.com

Будь подробнее

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

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

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

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

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

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

Два способа отказать в задаче

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

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

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

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

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

Вопрос: как оцениваете успешность/неуспешность фичи после релиза? На какие метрики смотрите?

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

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

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

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

​AirPods в один клик

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

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

Оказывается, этот процесс можно сократить до одного клика и пары секунд — есть специальные программы, которые сделали именно для того, чтобы моментально подключать AirPods к компьютеру. Я пользуюсь бесплатным workflow для Alfred, который так и называется AirPods Connector. Если у вас вдруг нет Alfred — не беда, заплатите 400 рублей за ToothFairy, которая делает то же самое.

На сайте бюро вышел финальный совет из серии о качестве кода — там я простым языком объясняю два процесса, которые поддерживают качество в любой команде — Continous Integration и Code Review.

Предыдущие советы:
— Почему качество кода важно для бизнеса
— Как измерить качество кода

Вопрос: скажи, есть ли у вас в процессе место для тестировщика, или это рудимент?

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

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

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

Это был традиционный #вопрос по понедельникам. Задайте свой на fedor@borshev.com.

Чем дольше срок, тем с меньшей вероятностью он соблюдается

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

Планируйте короткие и быстрые итерации, а не большие и сложные проекты.

Сомневаешься? Будь прозрачным

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

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

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

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

Вопрос: как вы оцениваете скоуп на итерацию?

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

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

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


Задайте свой вопрос на fedor@borshev.com.

Правила роста: от джуниора до CTO

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

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

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

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

Рабочее и личное время

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

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

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

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

​Sentry и sourcemaps

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

Кстати, source maps не обязательно выкладывать в прод — их можно грузить в Сентри прямо из процесса CI.

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

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

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

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

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

Как вкатить в любой язык программирования без регистрации и СМС

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

​Рассказываю в «советах», почему с разработчиками, которые не вникают в бизнес, лучше не работать. Совсем.

​Начинаем через два часа

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

Приходите!

Вопрос: как оценивать задачи с непонятной сложностью или новой технологией?

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

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

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

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

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