Безусловная и непонятная директива
Вот работаете вы над новым интерфейсом, и тут от коллеги прилетает просьба, типа «а давай перенесём эту кнопку наверх». И всё: ни объяснения чем кнопке плохо жилось внизу, ни хода мыслей, ничего не понятно.
Это — безусловная и непонятная директива. Такими директивами обычно общаются непродуктивные ребята, когда приходят с решениями вместо проблем (см. Фичреквесты, которые не стоит выполнять).
Если вы сами начнёте приходить к продуктовым коллегам с решениями вместо проблем — вас начнут валидировать так же, как непродуктовых коллег извне: задавать кучу вопросов о том, что на самом деле у вас болит, проверять болит ли вообще, или может вам просто фичу захотелось.
Будьте подробными: рассказывайте о том, почему пришли к тем или иным решениям. Не «давай перенесём кнопку наверх», а «Эта кнопка — ключевой call-to-action на странице, а я боюсь, что новые пользователи сразу её не увидят» Так вы не только уменьшите количество переписки в трекере, но ещё и опытом с коллегами поделитесь.
Вот работаете вы над новым интерфейсом, и тут от коллеги прилетает просьба, типа «а давай перенесём эту кнопку наверх». И всё: ни объяснения чем кнопке плохо жилось внизу, ни хода мыслей, ничего не понятно.
Это — безусловная и непонятная директива. Такими директивами обычно общаются непродуктивные ребята, когда приходят с решениями вместо проблем (см. Фичреквесты, которые не стоит выполнять).
Если вы сами начнёте приходить к продуктовым коллегам с решениями вместо проблем — вас начнут валидировать так же, как непродуктовых коллег извне: задавать кучу вопросов о том, что на самом деле у вас болит, проверять болит ли вообще, или может вам просто фичу захотелось.
Будьте подробными: рассказывайте о том, почему пришли к тем или иным решениям. Не «давай перенесём кнопку наверх», а «Эта кнопка — ключевой call-to-action на странице, а я боюсь, что новые пользователи сразу её не увидят» Так вы не только уменьшите количество переписки в трекере, но ещё и опытом с коллегами поделитесь.
Главный карьерный принцип
Когда-то давно услышал полезный совет: зайдя в новую комнату, всегда ищи самого умного человека, и говори с ним. Если самый умный человек в комнате это ты — ищи другую комнату.
То же самое и в карьере — ищи место, где в твоей работе будут находить недостатки. Если недостатки в своей работе можешь найти только ты — ищи другое место.
Когда-то давно услышал полезный совет: зайдя в новую комнату, всегда ищи самого умного человека, и говори с ним. Если самый умный человек в комнате это ты — ищи другую комнату.
То же самое и в карьере — ищи место, где в твоей работе будут находить недостатки. Если недостатки в своей работе можешь найти только ты — ищи другое место.
Вопрос: какие меры вы применяете для провинившегося сотрудника?
Мы не нанимаем людей, которым нужна внешняя стимуляция. Гораздо проще выстроить найм подходящих программистов, чем сложный механизм поощрения или наказания. В распределённой команде нанимать подходящих людей ещё легче — вы же не ограничены рамками одного города или района: просто максимально жёстко подбирайте тех, кто вам подходит.
Для себя я давно решил, что вместо семейной терапии и попыток выжать чуть больше из отстающих ребят, я лучше настрою более удобный процесс планирования, или помогу с архитектурой тем, кто впереди. Иначе получается вот так:
Мы не нанимаем людей, которым нужна внешняя стимуляция. Гораздо проще выстроить найм подходящих программистов, чем сложный механизм поощрения или наказания. В распределённой команде нанимать подходящих людей ещё легче — вы же не ограничены рамками одного города или района: просто максимально жёстко подбирайте тех, кто вам подходит.
Для себя я давно решил, что вместо семейной терапии и попыток выжать чуть больше из отстающих ребят, я лучше настрою более удобный процесс планирования, или помогу с архитектурой тем, кто впереди. Иначе получается вот так:
Время — невосполнимый ресурс
Если вы придёте на новогоднюю вечеринку второго января вместо первого, то увидите пустую комнату с запахом алкоголя — вечеринки уже не будет.
Если 1 ноября вы запускаете на рынок новый корм для кошек, то к 1 октября у вас полюбому должны быть нарисованы макеты банеров для наружки, а к середине октября запущен сайт, который рассказывает о продукте. Если банеров или сайта не будет, то продукт банально никто не возьмёт с полки — результат вашей работы пропадёт.
Что вы станете делать, если баннеры до сих пор не готовы, а уже 7 октября? Вы будете искать способы закончить раньше. Этих способов не так уж и много — либо пожертвовать проработкой макетов (запустить меньше посылов, сделать макеты проще), либо пожертвовать себестоимостью, наняв, к примеру, пять дополнительных дизайнеров.
Единственное, что вы не сможете сделать, когда опаздываете — это добавить себе ещё неделю, чтобы закончить проект: машину времени пока не изобрели. Пожертвовать деньгами или качеством — можно. Уменьшить проработку — можно. Добавить себе срок — нет.
Время стоит беречь не только в проектах, но и в личной жизни. Всё так же — если уже 20:00, а вы ещё не ходили в спортзал, то вы никак не можете сделать так, чтобы сейчас стало 18:00 — вы можете только не пойти в спортзал. Если вы приехали на работу в метро, а по дороге слушали музыку или изучали новинки в Arcades — вы просто приехали на работу на метро. А эти же 40 минут можно было потратить на чтение книги или спокойно поспать.
Берегите время.
Если вы придёте на новогоднюю вечеринку второго января вместо первого, то увидите пустую комнату с запахом алкоголя — вечеринки уже не будет.
Если 1 ноября вы запускаете на рынок новый корм для кошек, то к 1 октября у вас полюбому должны быть нарисованы макеты банеров для наружки, а к середине октября запущен сайт, который рассказывает о продукте. Если банеров или сайта не будет, то продукт банально никто не возьмёт с полки — результат вашей работы пропадёт.
Что вы станете делать, если баннеры до сих пор не готовы, а уже 7 октября? Вы будете искать способы закончить раньше. Этих способов не так уж и много — либо пожертвовать проработкой макетов (запустить меньше посылов, сделать макеты проще), либо пожертвовать себестоимостью, наняв, к примеру, пять дополнительных дизайнеров.
Единственное, что вы не сможете сделать, когда опаздываете — это добавить себе ещё неделю, чтобы закончить проект: машину времени пока не изобрели. Пожертвовать деньгами или качеством — можно. Уменьшить проработку — можно. Добавить себе срок — нет.
Время стоит беречь не только в проектах, но и в личной жизни. Всё так же — если уже 20:00, а вы ещё не ходили в спортзал, то вы никак не можете сделать так, чтобы сейчас стало 18:00 — вы можете только не пойти в спортзал. Если вы приехали на работу в метро, а по дороге слушали музыку или изучали новинки в Arcades — вы просто приехали на работу на метро. А эти же 40 минут можно было потратить на чтение книги или спокойно поспать.
Берегите время.
Качество кода: какие метрики снимать
Когда бюрошному советчику очень хочется рассказать о какой-то важной лично для него теме, то он не ждёт вопроса, а рассказывает сам. Месяц назад я воспользовался этим шансом и начал длинный рассказ о качестве кода. Почему это важно лично для меня — см. в первом посте.
Почему в бюро, а не здесь? Потому что эти ребята очень требовательны — они никогда не разрешат опубликовать скучный совет или текст с ошибками: Артём лично проверяет все выходящие советы, скурпулёзно докапываясь до всего, начиная от качества примеров и заканчивая последней запятой.
Во втором совете из серии, который вышел вчера, я понятным языком рассказываю о цикломатической сложности, уровнях покрытия тестами и о том, какие метрики надо снимать в продакшене.
Покажите своему менеджеру скорее.
Когда бюрошному советчику очень хочется рассказать о какой-то важной лично для него теме, то он не ждёт вопроса, а рассказывает сам. Месяц назад я воспользовался этим шансом и начал длинный рассказ о качестве кода. Почему это важно лично для меня — см. в первом посте.
Почему в бюро, а не здесь? Потому что эти ребята очень требовательны — они никогда не разрешат опубликовать скучный совет или текст с ошибками: Артём лично проверяет все выходящие советы, скурпулёзно докапываясь до всего, начиная от качества примеров и заканчивая последней запятой.
Во втором совете из серии, который вышел вчера, я понятным языком рассказываю о цикломатической сложности, уровнях покрытия тестами и о том, какие метрики надо снимать в продакшене.
Покажите своему менеджеру скорее.
3 программы, которые помогают больше писать
У вас было когда-нибудь такое, что вы собираетесь написать письмо или заметку в блог, и никак не можете — тут же находятся более срочные дела? Так заметка и пылится до лучших времён, которые не наступают никогда.
Существует куча способов бороться с такой прокрастинацией, но все они относятся к всего к двум группам: робото-само-дисциплина и умение договариваться с собой. Лично у меня подход с дисциплиной не работает — через пару недель насилия над собой в голове не остаётся ничего, кроме желания заснуть часов на 20.
Мой любимый способ, чтобы победить текстовую прокрастинацию — это хорошее окружение: тихая кофейня с вкусным кофе и приятные приложения для текста: IA Writer, Bear и Day One. Подробнее о том, как они помогают больше писать — рассказал в блоге.
У вас было когда-нибудь такое, что вы собираетесь написать письмо или заметку в блог, и никак не можете — тут же находятся более срочные дела? Так заметка и пылится до лучших времён, которые не наступают никогда.
Существует куча способов бороться с такой прокрастинацией, но все они относятся к всего к двум группам: робото-само-дисциплина и умение договариваться с собой. Лично у меня подход с дисциплиной не работает — через пару недель насилия над собой в голове не остаётся ничего, кроме желания заснуть часов на 20.
Мой любимый способ, чтобы победить текстовую прокрастинацию — это хорошее окружение: тихая кофейня с вкусным кофе и приятные приложения для текста: IA Writer, Bear и Day One. Подробнее о том, как они помогают больше писать — рассказал в блоге.
Писать так, чтобы не переспрашивали
Самое важное в общении распределенной команды — писать так, чтобы не переспрашивали. У нас в ГдеМатериале, к примеру, всё асинхронно, и когда коллега из GMT+10 в следующий раз выйдет на связь — никто не знает. А значит в сообщении должно содержаться все необходимое для выполнения задачи.
Когда общаются распределенные программисты, и глючит переданный код, начинается пиздец — из-за разных часовых поясов десятиминутная задача может растянуться на неделю с ночными посиделками всех участников.
Чтобы не сидеть ночами — всегда передавайте работу вместе с тестами. Написали новый эндпоинт в АПИ — дайте ссылку на тесты ключевых возможностей. Исправили ошибку — выкладывайте тест, который это проверяет. Коллеги сразу поймут, как воспользоваться результатами вашей работы, а вы будете на 100% уверены, что не сделали неработающее говно.
Ну а чтобы прокачать навык написания тестов — приходите на мой мастер-класс в субботу :-)
Самое важное в общении распределенной команды — писать так, чтобы не переспрашивали. У нас в ГдеМатериале, к примеру, всё асинхронно, и когда коллега из GMT+10 в следующий раз выйдет на связь — никто не знает. А значит в сообщении должно содержаться все необходимое для выполнения задачи.
Когда общаются распределенные программисты, и глючит переданный код, начинается пиздец — из-за разных часовых поясов десятиминутная задача может растянуться на неделю с ночными посиделками всех участников.
Чтобы не сидеть ночами — всегда передавайте работу вместе с тестами. Написали новый эндпоинт в АПИ — дайте ссылку на тесты ключевых возможностей. Исправили ошибку — выкладывайте тест, который это проверяет. Коллеги сразу поймут, как воспользоваться результатами вашей работы, а вы будете на 100% уверены, что не сделали неработающее говно.
Ну а чтобы прокачать навык написания тестов — приходите на мой мастер-класс в субботу :-)
Технические долги
Есть ребята, которые пишут говнокод не потому, что не могут отличить хороший код от плохого, а потому, что считают, что так быстрее. Эта заметка для них.
Представь что ты увидел в магазине новый iMac pro. Можно пойти и накопить 400 тысяч (долго и муторно), а можно достать кредитку и купить прямо сейчас.
Во втором случае в нагрузку к аймаку ты получаешь долг. Теперь что бы с тобой не случилось, ты должен банку 400 тысяч. Если их не отдать в ближайший месяц, то будешь должен уже 403 тысячи, ещё через месяц — 406, и т.д.
В принципе, по долгам можно не платить, правда придётся отключить телефон. Однако долг никуда не денется — когда-нибудь в Пятёрочке не примут платеж с твоей карты, а вернувшись домой ты не найдешь нового мака — его опишут приставы.
Технический долг устроен так же, как финансовый — первое время он почти не беспокоит. Чем дольше висит долг — тем выше риск. И однажды в солнечную пятницу тебе придется остаться на работе, потому что долг потребует платежа. Конечно, можно наговнокодить ещё сильнее и пойти домой. А потом ещё и ещё — пока проект совсем не остановится. Вероятно, к этому времени ты уже поругаешься с семьёй, друзьями и менеджером, или сменишь работу.
В командах у технического долга появляется ещё одно вредное свойство — по долгам одного нерадивого участника приходится платить другим. Относись к такому долгу, как к деньгам: представь, что ты в баре, и нашёл в кармане кредитку коллеги. Ты же не станешь угощать весь бар 18-летним Макаланом, правда?
Давайте жить не в долг и писать понятный код — так быстрее. И работу можно будет менять по собственной воле, а не из-за долговой ямы.
Есть ребята, которые пишут говнокод не потому, что не могут отличить хороший код от плохого, а потому, что считают, что так быстрее. Эта заметка для них.
Представь что ты увидел в магазине новый iMac pro. Можно пойти и накопить 400 тысяч (долго и муторно), а можно достать кредитку и купить прямо сейчас.
Во втором случае в нагрузку к аймаку ты получаешь долг. Теперь что бы с тобой не случилось, ты должен банку 400 тысяч. Если их не отдать в ближайший месяц, то будешь должен уже 403 тысячи, ещё через месяц — 406, и т.д.
В принципе, по долгам можно не платить, правда придётся отключить телефон. Однако долг никуда не денется — когда-нибудь в Пятёрочке не примут платеж с твоей карты, а вернувшись домой ты не найдешь нового мака — его опишут приставы.
Технический долг устроен так же, как финансовый — первое время он почти не беспокоит. Чем дольше висит долг — тем выше риск. И однажды в солнечную пятницу тебе придется остаться на работе, потому что долг потребует платежа. Конечно, можно наговнокодить ещё сильнее и пойти домой. А потом ещё и ещё — пока проект совсем не остановится. Вероятно, к этому времени ты уже поругаешься с семьёй, друзьями и менеджером, или сменишь работу.
В командах у технического долга появляется ещё одно вредное свойство — по долгам одного нерадивого участника приходится платить другим. Относись к такому долгу, как к деньгам: представь, что ты в баре, и нашёл в кармане кредитку коллеги. Ты же не станешь угощать весь бар 18-летним Макаланом, правда?
Давайте жить не в долг и писать понятный код — так быстрее. И работу можно будет менять по собственной воле, а не из-за долговой ямы.
Вопрос: как вы поступаете с задачами, которые внезапно стали горящими, при условии, что вы не можете менять содержимое спринтов?
На самом деле очень просто — у нас есть ребята, которые работают он-колл. Это значит, что у них нет спринтов, только канбан-доска с текущими задачами.
В он-колл обычно попадают небольшие маркетинговые задачи — докрутить что-то на сайте под новую рекламную интеграцию, доработать аналитику. Одним словом — задачи, в которых важны абсолютные сроки.
Проблема он-колл разработки в том, что её хочется использовать, чтобы затыкать дыры. Менеджер будет запихивать в он-колл задачу, которую обещал, но забыл поставить в спринт. Веб-аналитик будет просить по-быстрому доработать корзину под новую интеграцию, про которую забыл предупредить всех вовремя.
Важно отличать действительно срочные задачи от стандартного менеджерского желания взять побольше и закинуть подальше. Если простой из-за отсутствия результатов задачи стоит нам измеримое количество денег или данных в день, и это количество больше, чем ваш внутренний Х, он-колл может подойти. Если нет — в спринт.
Почитайте другие ответы по тегу #вопрос или задайте свой вопрос на почту fedor@borshev.com
На самом деле очень просто — у нас есть ребята, которые работают он-колл. Это значит, что у них нет спринтов, только канбан-доска с текущими задачами.
В он-колл обычно попадают небольшие маркетинговые задачи — докрутить что-то на сайте под новую рекламную интеграцию, доработать аналитику. Одним словом — задачи, в которых важны абсолютные сроки.
Проблема он-колл разработки в том, что её хочется использовать, чтобы затыкать дыры. Менеджер будет запихивать в он-колл задачу, которую обещал, но забыл поставить в спринт. Веб-аналитик будет просить по-быстрому доработать корзину под новую интеграцию, про которую забыл предупредить всех вовремя.
Важно отличать действительно срочные задачи от стандартного менеджерского желания взять побольше и закинуть подальше. Если простой из-за отсутствия результатов задачи стоит нам измеримое количество денег или данных в день, и это количество больше, чем ваш внутренний Х, он-колл может подойти. Если нет — в спринт.
Почитайте другие ответы по тегу #вопрос или задайте свой вопрос на почту fedor@borshev.com
Будь подробнее
У нас в команду периодически приходят стажёры. Чтобы стажёры могли спокойно учиться, но при этом не сильно ломали разработку, у нас есть правило — мы никогда не обещаем сделать в спринте задачу, которую делает стажёр. Обычно о таких задачах мы дополнительно предупреждаем стейкхолдеров.
Сравните два письма стейкхолдерам на эту тему. Первое: «Привет! Мы приняли задачу, но к сожалению не сможем гарантированно её сделать до конца спринта».
Или: «Привет! Мы приняли задачу. К сожалению, мы не сможем гарантировать, что сделаем задачу до конца спринта — дело в том, что она ушла стажёру. Конечно, у стажёра стоит дедлайн, но даже несмотря на то, что его сопровождает опытный программист, стажёр — всё-таки новый человек в нашей команде, поэтому результат мы гарантировать не сможем».
Два письма об одном и том же. Первое — просто нейтрально информирует, причём так сухо, что неопытным коллегам вообще может показаться пренебрежительным. Получил 3 таких письма подряд — и как будто на хуй послан.
Второе письмо выполняет ровно ту же задачу, но приоткрывает внутреннюю кухню настолько, что никогда не покажется пренебрежительным. Скорее наоборот, получатель почувствует заботу — его задачу делают целых два человека, да ещё и менеджер следит.
P.S. Как вы заметили, на канале стало гораздо меньше рекламы. Я решил совсем от неё отказаться, но у меня пока остались обязательства, поэтому в ближайшее время выйдет ещё 3–4 поста. Потом с рекламой будет долгое затишье.
У нас в команду периодически приходят стажёры. Чтобы стажёры могли спокойно учиться, но при этом не сильно ломали разработку, у нас есть правило — мы никогда не обещаем сделать в спринте задачу, которую делает стажёр. Обычно о таких задачах мы дополнительно предупреждаем стейкхолдеров.
Сравните два письма стейкхолдерам на эту тему. Первое: «Привет! Мы приняли задачу, но к сожалению не сможем гарантированно её сделать до конца спринта».
Или: «Привет! Мы приняли задачу. К сожалению, мы не сможем гарантировать, что сделаем задачу до конца спринта — дело в том, что она ушла стажёру. Конечно, у стажёра стоит дедлайн, но даже несмотря на то, что его сопровождает опытный программист, стажёр — всё-таки новый человек в нашей команде, поэтому результат мы гарантировать не сможем».
Два письма об одном и том же. Первое — просто нейтрально информирует, причём так сухо, что неопытным коллегам вообще может показаться пренебрежительным. Получил 3 таких письма подряд — и как будто на хуй послан.
Второе письмо выполняет ровно ту же задачу, но приоткрывает внутреннюю кухню настолько, что никогда не покажется пренебрежительным. Скорее наоборот, получатель почувствует заботу — его задачу делают целых два человека, да ещё и менеджер следит.
P.S. Как вы заметили, на канале стало гораздо меньше рекламы. Я решил совсем от неё отказаться, но у меня пока остались обязательства, поэтому в ближайшее время выйдет ещё 3–4 поста. Потом с рекламой будет долгое затишье.
Два способа отказать в задаче
У продакта есть два способа отказать представителю бизнеса, пришедшему с бесполезной задачей — классический и жёсткий.
Классический — это принять задачу и сделать её примерно никогда. «Конечно, мы сделаем тебе Страннное Говно, скорее всего в следующем же спринте. Вот карточка в беклоге, подпишись на новости». К следующему спринту вопрошающий скорее всего уже забудет про задачу — ведь она же ему на самом деле не нужна.
Жёсткий — это честно объяснить: «к сожалению, Странное Говно — вообще задача не про деньги потому-то и потому-то. Давай подумаем, как мы могли бы её изменить, чтобы она стала про деньги?».
Жёсткий вариант обижает многих людей — им неприятно, что какой-то продакт-менеджер решает за них. Классический вариант — мягкий и спокойный: все друг с другом дружат, все довольны. Только вот денег не прибавляется.
А самое главное — если жёстко не объяснять разницу между фичами про деньги и фичами про фичи, то ни один представитель бизнеса никогда не повысит уровень продуктовой осознанности — так и будет приходить со странными вещами, которые продакт будет хоронить в глубине беклога.
У продакта есть два способа отказать представителю бизнеса, пришедшему с бесполезной задачей — классический и жёсткий.
Классический — это принять задачу и сделать её примерно никогда. «Конечно, мы сделаем тебе Страннное Говно, скорее всего в следующем же спринте. Вот карточка в беклоге, подпишись на новости». К следующему спринту вопрошающий скорее всего уже забудет про задачу — ведь она же ему на самом деле не нужна.
Жёсткий — это честно объяснить: «к сожалению, Странное Говно — вообще задача не про деньги потому-то и потому-то. Давай подумаем, как мы могли бы её изменить, чтобы она стала про деньги?».
Жёсткий вариант обижает многих людей — им неприятно, что какой-то продакт-менеджер решает за них. Классический вариант — мягкий и спокойный: все друг с другом дружат, все довольны. Только вот денег не прибавляется.
А самое главное — если жёстко не объяснять разницу между фичами про деньги и фичами про фичи, то ни один представитель бизнеса никогда не повысит уровень продуктовой осознанности — так и будет приходить со странными вещами, которые продакт будет хоронить в глубине беклога.
Ребята мне понравилось проводить вебинары :-) Вы оставили 30 отзывов, из которых видно, что два часа концентрированной информации отлично дополняют текстовые знания, которыми я делюсь здесь.
Давайте подумаем, о чём ещё мне рассказать в таком же формате?
Давайте подумаем, о чём ещё мне рассказать в таком же формате?
Anonymous Poll
26%
Руководство удалённой командой: почему удалённые разработчики эффективнее, чем в офисе
24%
Как всё успеть (тайм-менеджмент): расскажу про внимание, время и хронофагов
10%
Роль программиста в продукте и аналитике: как приоритизировать, резать фичи и проверять гипотезы
6%
Как готовить Django: от бойлерплейта до 200 000 строк
33%
Развитие от джуниора до CTO: от самого начала и до управления людьми и проектами
Вопрос: как оцениваете успешность/неуспешность фичи после релиза? На какие метрики смотрите?
Критерии успеха фичи мы определяем ещё до начала разработки — в каждой задаче мы указываем, на какую метрику собираемся повлиять. Скажем, мы перевёрстываем второй шаг корзины на сайте — сразу понятно, что мы хотим улучишь конверсию на конкретно этом шаге. Задачи без метрик мы даже не начинаем делать.
Если делаем что-то более сложное, к примеру в нашей ЦРМ, определяем больше метрик. К примеру, мы делаем новую систему загрузки документов от поставщиков. Базовая метрика — насколько люди вообще грузят туда документы: если документы не грузятся, значит мы плохо продаём эту фичу. Бизнес-метрика: скорость сбора документов: если документы грузятся, но при этом не быстро, значит у нас проблема с контролем.
Если не определять метрики с самого начала — вы рискуете вложить деньги в фичу, которая никому не нужна, включая вас.
Ответы на другие вопросы — #вопрос. Задать вопрос — fedor@borshev.com
Критерии успеха фичи мы определяем ещё до начала разработки — в каждой задаче мы указываем, на какую метрику собираемся повлиять. Скажем, мы перевёрстываем второй шаг корзины на сайте — сразу понятно, что мы хотим улучишь конверсию на конкретно этом шаге. Задачи без метрик мы даже не начинаем делать.
Если делаем что-то более сложное, к примеру в нашей ЦРМ, определяем больше метрик. К примеру, мы делаем новую систему загрузки документов от поставщиков. Базовая метрика — насколько люди вообще грузят туда документы: если документы не грузятся, значит мы плохо продаём эту фичу. Бизнес-метрика: скорость сбора документов: если документы грузятся, но при этом не быстро, значит у нас проблема с контролем.
Если не определять метрики с самого начала — вы рискуете вложить деньги в фичу, которая никому не нужна, включая вас.
Ответы на другие вопросы — #вопрос. Задать вопрос — fedor@borshev.com
AirPods в один клик
Apple делает много приятных вещей, но иногда попадаются интерфейсы, за которые создателей хочется сильно поругать — к примеру интерфейс публикации приложения в AppStore, для которого я уже неделю пытаюсь восстановить свой Developer Account.
Или интерфейс подключения AirPods на макбуке. Чтобы переключить наушники между телефоном и компьютером, нужно сначала нажать на значок звука, затем дождаться, когда в списке устройств появятся наушники, потом нажать на них и дождаться, пока случится вся магия подключения. Иногда по загадочным причинам магия не случается, и операцию нужно повторить, выполняя все те же клики-ожидания-клики — бесит.
Оказывается, этот процесс можно сократить до одного клика и пары секунд — есть специальные программы, которые сделали именно для того, чтобы моментально подключать AirPods к компьютеру. Я пользуюсь бесплатным workflow для Alfred, который так и называется AirPods Connector. Если у вас вдруг нет Alfred — не беда, заплатите 400 рублей за ToothFairy, которая делает то же самое.
Apple делает много приятных вещей, но иногда попадаются интерфейсы, за которые создателей хочется сильно поругать — к примеру интерфейс публикации приложения в AppStore, для которого я уже неделю пытаюсь восстановить свой Developer Account.
Или интерфейс подключения AirPods на макбуке. Чтобы переключить наушники между телефоном и компьютером, нужно сначала нажать на значок звука, затем дождаться, когда в списке устройств появятся наушники, потом нажать на них и дождаться, пока случится вся магия подключения. Иногда по загадочным причинам магия не случается, и операцию нужно повторить, выполняя все те же клики-ожидания-клики — бесит.
Оказывается, этот процесс можно сократить до одного клика и пары секунд — есть специальные программы, которые сделали именно для того, чтобы моментально подключать AirPods к компьютеру. Я пользуюсь бесплатным workflow для Alfred, который так и называется AirPods Connector. Если у вас вдруг нет Alfred — не беда, заплатите 400 рублей за ToothFairy, которая делает то же самое.
На сайте бюро вышел финальный совет из серии о качестве кода — там я простым языком объясняю два процесса, которые поддерживают качество в любой команде — Continous Integration и Code Review.
Предыдущие советы:
— Почему качество кода важно для бизнеса
— Как измерить качество кода
Предыдущие советы:
— Почему качество кода важно для бизнеса
— Как измерить качество кода
Вопрос: скажи, есть ли у вас в процессе место для тестировщика, или это рудимент?
Качество — это такая же важная характеристика проекта как время, стоимость и скоуп. Никому не нужна выполненная задача, если код не работает. Если вы сделали промо-страницу для нового товара, но не проверили как она работает на ширине пятого айфона (которого у вас 20% трафика) — вы сделали работу зря.
Я, признаюсь честно, не люблю сложные конвейеры, в которых фронт делает один человек, бек — другой, а тестирует их совместимость — третий. Это неизбежное зло в больших командах с гетерогенным стеком, но пока я могу сделать, чтобы за одну фичу отвечал один человек — буду делать именно так.
У такого человека нет соблазна перевесить ответственность за качество на соседа, или заставить людей возить мышкой и тыкать кнопки вместо правильной автоматизации тестирования.
Это был традиционный #вопрос по понедельникам. Задайте свой на fedor@borshev.com.
Качество — это такая же важная характеристика проекта как время, стоимость и скоуп. Никому не нужна выполненная задача, если код не работает. Если вы сделали промо-страницу для нового товара, но не проверили как она работает на ширине пятого айфона (которого у вас 20% трафика) — вы сделали работу зря.
Я, признаюсь честно, не люблю сложные конвейеры, в которых фронт делает один человек, бек — другой, а тестирует их совместимость — третий. Это неизбежное зло в больших командах с гетерогенным стеком, но пока я могу сделать, чтобы за одну фичу отвечал один человек — буду делать именно так.
У такого человека нет соблазна перевесить ответственность за качество на соседа, или заставить людей возить мышкой и тыкать кнопки вместо правильной автоматизации тестирования.
Это был традиционный #вопрос по понедельникам. Задайте свой на fedor@borshev.com.
Чем дольше срок, тем с меньшей вероятностью он соблюдается
Очень #тупое_правило, которое работает всегда:
— Вы скорее напишете письмо прямо сейчас, чем завтра.
— Вы скорее напишете завтра, чем в следующую среду.
— Вы скорее выполните двухдневную задачу за два дня, чем двухнедельную — за две недели.
— Вы скорее выполните личный план на неделю, чем личный план за год.
Планируйте короткие и быстрые итерации, а не большие и сложные проекты.
Очень #тупое_правило, которое работает всегда:
— Вы скорее напишете письмо прямо сейчас, чем завтра.
— Вы скорее напишете завтра, чем в следующую среду.
— Вы скорее выполните двухдневную задачу за два дня, чем двухнедельную — за две недели.
— Вы скорее выполните личный план на неделю, чем личный план за год.
Планируйте короткие и быстрые итерации, а не большие и сложные проекты.
Сомневаешься? Будь прозрачным
Простое правило: чем больше сомневаешься в том, что делаешь — тем больше пиши об этом. И это — не бюрократическое правило «больше бумаги — чище зад», это способ привести мысли в порядок.
Формат простой: «Я уже сделал то-то, стало так-то. Собираюсь делать вот это, чтобы то, измерять будем так-то». Слова имеют магию — когда выписываешь свои мысленные построения в письме на всех, включается максимально жестокий критик — ты задаёшь самому себе неприятные вопросы.
«Я делаю новое ответвление в карте коммуникаций. А правда ли это касание повысит ритешн? А как мы его замерим?». Или «Я делаю корпоративный блог, чтобы повысить продажи. Как я буду измерять? Верю ли я в это?».
По итогам таких писем вам начнёт приходить внешняя критика — более опытные коллеги всегда с радостью делятся сомнениями. У нас в ГдеМатериале к примеру, прямо в гитхабе есть Али (@reshilavonasah), который видит весь журнал действий и периодически приходит с неудобными вопросами — одно знание об этом заставляет задавать вопросы себе до постановки задачи, а не после.
Простое правило: чем больше сомневаешься в том, что делаешь — тем больше пиши об этом. И это — не бюрократическое правило «больше бумаги — чище зад», это способ привести мысли в порядок.
Формат простой: «Я уже сделал то-то, стало так-то. Собираюсь делать вот это, чтобы то, измерять будем так-то». Слова имеют магию — когда выписываешь свои мысленные построения в письме на всех, включается максимально жестокий критик — ты задаёшь самому себе неприятные вопросы.
«Я делаю новое ответвление в карте коммуникаций. А правда ли это касание повысит ритешн? А как мы его замерим?». Или «Я делаю корпоративный блог, чтобы повысить продажи. Как я буду измерять? Верю ли я в это?».
По итогам таких писем вам начнёт приходить внешняя критика — более опытные коллеги всегда с радостью делятся сомнениями. У нас в ГдеМатериале к примеру, прямо в гитхабе есть Али (@reshilavonasah), который видит весь журнал действий и периодически приходит с неудобными вопросами — одно знание об этом заставляет задавать вопросы себе до постановки задачи, а не после.
Вопрос: как вы оцениваете скоуп на итерацию?
Оценок задач у нас нет — я противник бюрократии и считаю, что результат на продакшене гораздо важнее, чем сторипоинты и эстимейты. Подробнее об этом можно почитать здесь.
Во время планирования спринта, мы просим исполнителей просто прикидывать время: кому-то удобнее в днях, кому-то — в часах. Дальше собираем два плана — пессимистичный, с задачами-минимум, которые сделаем в любом случае, и оптимистичный — задачи, которые мы сделаем только, если успеем.
Подробнее о двух планах на спринт см. в посте о буфере.
Задайте свой вопрос на fedor@borshev.com.
Оценок задач у нас нет — я противник бюрократии и считаю, что результат на продакшене гораздо важнее, чем сторипоинты и эстимейты. Подробнее об этом можно почитать здесь.
Во время планирования спринта, мы просим исполнителей просто прикидывать время: кому-то удобнее в днях, кому-то — в часах. Дальше собираем два плана — пессимистичный, с задачами-минимум, которые сделаем в любом случае, и оптимистичный — задачи, которые мы сделаем только, если успеем.
Подробнее о двух планах на спринт см. в посте о буфере.
Задайте свой вопрос на fedor@borshev.com.
Правила роста: от джуниора до CTO
Ребята, я запускаю второй вебинар! Вы выбрали рассказ о правилах профессионального роста, поэтому 7 декабря (это через 3 недели в субботу) мы соберёмся и поговорим, как планировать свой рост — как найти время на развитие, где практиковаться, как руководить коллегами, доводить дела до завершения и в чём разница между профессиональным и служебным ростом.
Вебинар будет полезен всем, кто хочет не просто писать код, а менять вещи вокруг — ускорять проекты, влезать в продукт, тренировать себя и коллег. У нас не будет инфоцыганщины с историями, как добиться успешного успеха сидя на диване — скорее вы сформируете у себя в голове дорожную карту: что, как и в какой момент прокачивать, чтобы стать тем, кем вы хотите.
Никаких специфичных знаний иметь не нужно — мы будем говорить о софт-скиллах, полезных и джуниорам, и тимлидам.
Участие стоит 1900 ₽, цена увеличивается на 200 ₽ каждую пятницу. Всем, кто купит билет до конца недели, я предлагаю поучаствовать в составлении программы — если хотите, чтобы я рассказал о чём-то, интересном лично вам — просто заполните форму в конце покупки.
Ребята, я запускаю второй вебинар! Вы выбрали рассказ о правилах профессионального роста, поэтому 7 декабря (это через 3 недели в субботу) мы соберёмся и поговорим, как планировать свой рост — как найти время на развитие, где практиковаться, как руководить коллегами, доводить дела до завершения и в чём разница между профессиональным и служебным ростом.
Вебинар будет полезен всем, кто хочет не просто писать код, а менять вещи вокруг — ускорять проекты, влезать в продукт, тренировать себя и коллег. У нас не будет инфоцыганщины с историями, как добиться успешного успеха сидя на диване — скорее вы сформируете у себя в голове дорожную карту: что, как и в какой момент прокачивать, чтобы стать тем, кем вы хотите.
Никаких специфичных знаний иметь не нужно — мы будем говорить о софт-скиллах, полезных и джуниорам, и тимлидам.
Участие стоит 1900 ₽, цена увеличивается на 200 ₽ каждую пятницу. Всем, кто купит билет до конца недели, я предлагаю поучаствовать в составлении программы — если хотите, чтобы я рассказал о чём-то, интересном лично вам — просто заполните форму в конце покупки.