FEDOR BORSHEV

@pmdaily Нравится 2

Пишу о производстве сложных проектов, управлении продуктами, а также о развитии софтскиллов у программистов. Личка — @fedor_borshev
borshev.com
Гео и язык канала
Россия, Русский
Категория
Технологии


Написать автору
Гео канала
Россия
Язык канала
Русский
Категория
Технологии
Добавлен в индекс
26.12.2017 02:52
Последнее обновление
20.05.2019 00:58
реклама
Telegram Analytics
Самые свежие новости сервиса TGStat. Подписаться →
Searchee Bot
Каталог 270k+ Telegram-каналов с удобным поиском в боте.
@TGStat_Bot
Бот для получения статистики каналов не выходя из Telegram
6 915
подписчиков
~6.1k
охват 1 публикации
~3.9k
дневной охват
~4
постов / нед.
88.4%
ERR %
19.87
индекс цитирования
Репосты и упоминания канала
47 упоминаний канала
14 упоминаний публикаций
21 репостов
🤖 The Bell Tech
Remote IT (Inflow)
IT Relocation (Inflow)
Job Moscow it (Inflow)
Пусть будет™
๖ۣۜХауди Хо™
Рабы галерные
Clean Code
Архивач
drebezgi
1С wiki
Тёмная сторона
Analysis Paradisis
🤖 The Bell Tech
THINGS PROGRAMMERS DO
🤖 The Bell Tech
🤖 The Bell Tech
Groks
🤖 The Bell Tech
Java Dev
Python Textbooks
Remote IT (Inflow)
๖ۣۜХауди Хо™
Записки админа
China with trump
WebDEV
Job Nsk it (Inflow)
IT Relocation (Inflow)
Remote IT (Inflow)
TechRocks
Эксплойт
UniLecs
miStore
FrontEndDev
Machinelearning
Возможности
Next Time
IT|BLOG|SYSADMIN
Каналы, которые цитирует @pmdaily
Python Books
Startups & Products
Бабаева, к доске!
toverovskiy
Oh My Py
Kulinkovich is typing...
запуск завтра
Binary District
Analysis Paradisis
Binary District
WebDEV
Groks
Java Dev
Java Dev
Java Dev
Тёмная сторона
Тёмная сторона
Артемий Лебедев
Канал Саши Бизикова
Последние публикации
Удалённые
С упоминаниями
Репосты
FEDOR BORSHEV 20 May, 10:45
Вопрос: как увольнять людей без драмы и внутренней боли?

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

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

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

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

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

Другие ответы — #вопрос. Задать вопрос — @fedor_borshev
👍 117
💩 9
Читать полностью
FEDOR BORSHEV 17 May, 10:45
Как донести HADI до руководства

Вышел мой совет о том, как продавать руководству идею продуктовых экспериментов — https://bureau.ru/soviet/20190516/
FEDOR BORSHEV 16 May, 12:00
#реклама
Продолжается набор на курс «DevOps: практики и инструменты», разработанный совместно с компанией инженеров из Express 42: https://otus.pw/NyMy/

📌 На занятиях вас ждет подробное изучение следующих практик:
— инфраструктура как код;
— непрерывная поставка ПО;
— непрерывный сбор метрик (мониторинг и логирование) и многое другое.

👤 Для кого подойдет курс? Для разработчиков, системных архитекторов и администраторов, для тестировщиков и QA инженеров.

⁉️В представленной на курсе карте практик, без преувеличения, каждый специалист найдет для себя область применения и пути развития в профессии. Как стать частью профессиональной тусовки DevOps-инженеров?

👉🏻ПРОЙТИ ТЕСТИРОВАНИЕ: https://otus.pw/NyMy/⁉️
Читать полностью
FEDOR BORSHEV 15 May, 10:50
Начинаем проект на Django: собственные точки входа

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

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

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

Кастомные точки входа стоит сделать в начале проекта еще и для того, чтобы ваши программисты их постоянно видели — так они с большей вероятностью начнут рассматривать модификацию базовых точек входа как опцию в своих архитектурных решениях.
Читать полностью
FEDOR BORSHEV 14 May, 09:00
#реклама

14 мая в 20:00 мск OTUS приглашает на бесплатный урок онлайн-курса «Реляционные СУБД» — «Внутренняя архитектура СУБД»: https://otus.pw/TP55/

На вебинаре будут рассмотрены компоненты СУБД на примере Postgres и SQL Server.

Вебинар проведёт Кристина Кучерова — архитектор модели данных в Сбербанке России и аспирант в Санкт-Петербургском политехническом университете им. Петра Великого.

Проходите вступительное тестирование и присоединяйтесь — будет круто: https://otus.pw/TP55/
Читать полностью
FEDOR BORSHEV 13 May, 10:45
Вопрос: что делать с задачами, которые прилетают посреди спринта? Бизнес всегда очень убедительно объясняет, что они важнее, чем то, что мы делаем сейчас. Все бросать?

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

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

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

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

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

Другие вопросы — #вопрос. Задать свой — @fedor_borshev.
👍 172
💩 7
Читать полностью
FEDOR BORSHEV 12 May, 16:04
#гитхаб анонсировал package registry — реестр внутренних пакетов организации. Фактически это полная замена gemfury, о котором я писал в прошлом году, и немножко замена docker hub (реестр контейнеров тоже есть).

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

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

Анонс тут, записываться на бета-тестирование тут.
Читать полностью
FEDOR BORSHEV 10 May, 10:45
Избавиться от состояния

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

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

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

А вот если файлы хранятся в облаке, то достаточно прописать read-only доступ к ним в docker-compose.yml, и все будет доступно на той же машине, на которой запускают бекенд. Так любой фронтендер сможет поднять у себя сайт со всеми картинками и отлаживать верстку локально, или, скажем, тестировать производительность в CI.
Читать полностью
FEDOR BORSHEV 8 May, 10:45
Пулл-реквесты меньше 500 строк

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

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

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

А еще декомпозиция хороша сама по себе — пусть лучше у тебя не примут немного кода в начале спринта, чем много и в конце.
Читать полностью
FEDOR BORSHEV 7 May, 12:00
#реклама

Улучшить компетенции продакт-менеджера поможет только практика управления продуктом. Но где оттачивать мастерство без риска для реального проекта?
В SkillFactory уже в мае начинаются занятия на курсе для product-менеджеров в формате тренажера для безопасной наработки навыков → https://clc.to/A3-KvA

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

За вами — тренировка и отработка навыков, за менторами курса — фидбек и контроль вашего прогресса.
Курс “Тренажер product-менеджера” — фундамент для правильного карьерного роста продакта.

Забронируйте место на курсе со скидкой 20%
Читать полностью
FEDOR BORSHEV 6 May, 10:45
Вопрос: как ты думаешь, CTO — это рост из тим-лида или тех-лида?

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

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

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

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

Другие вопросы — #вопрос. Задать свой — @fedor_borshev
Читать полностью
FEDOR BORSHEV 4 May, 12:00
#работамечты

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

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

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

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

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

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

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

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

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

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

Другие вопросы — #вопрос. Задать свой — @fedor_borshev.
Читать полностью
FEDOR BORSHEV 26 Apr, 10:45
Как резать фичи на основе экспериментов

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

Там я описываю подход из классических книг по менеджменту, который позволяет не инвестировать дорогущее время разработки непонятно куда.
FEDOR BORSHEV 24 Apr, 10:45
Сначала процесс, потом автоматизация

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

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

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

Пока люди сами не протопчут себе дорожку — никакие указатели направления не заработают.
Читать полностью
FEDOR BORSHEV 23 Apr, 12:00
#реклама

@pythonbooks - канал с книгами на русском и английском языке для тех, кто хочет стать трушным Python Developer(ом). Скачивайте книги у нас @pythonbooks.
FEDOR BORSHEV 22 Apr, 10:45
Вопрос: как программисту начать отвечать за результат? Не просто выполнять задачи, но и предлагать своё видение?

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

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

Сделали предложение, задав плохой вопрос. Получили плохой ответ, и итоге в спринт уходит плохая задача.

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

Задали открытые вопросы, поучаствовали в диалоге, принесли пользу: не делаем глупую задачу.

Отвечая на ваш вопрос — просто побольше участвуйте в обсуждениях, но всегда начинайте с вопросов, а не с предложений.
Читать полностью
FEDOR BORSHEV 19 Apr, 10:45
Презентация — неотъемлемая часть работы

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

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

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

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

Если бы мы сделали такую расшифровку в самом начале задачи, то запустились бы как минимум на неделю быстрее. Мораль — думайте о презентации работы в самом начале: тогда и в ожидания заказчика попадёте с большей вероятностью, и сама сдача пройдет быстрее.
Читать полностью
FEDOR BORSHEV 18 Apr, 10:45
Когда я попал в Студию Лебедева, первые несколько месяцев я каждый день удивлялся от огромного количества всего, что происходит вокруг. За день случалось больше, чем за две недели в любой другой компании до этого — звонки, знакомства, проекты, знания: все сыпалось на мою привыкшую к неспешной провинциальной жизни голову.

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

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

С тех пор скорость одного разработчика конечно замедлилась (совсем немного), но скорость разработки в целом только увеличилась за счёт удобной инфраструктуры, девопса и того, что мне повезло набрать идеальную команду.

К чему это я? Если на текущем месте работы вы замечаете, что вокруг происходит мало нового — напишите мне.

Мы ищем:
— Продакт-менеджера
— Дизайнера
— Фулл-стека Django + vue.js
— Фронтендера, который умеет писать тесты и не боится верстать (vue.js, сайт у нас на гридах)

Работа удалённая у всех, кроме продакта. График — свободный.

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

Для начала разговора просто напишите мне на fb@gdml.ru.
Читать полностью
FEDOR BORSHEV 17 Apr, 10:45
Стали бы мы делать эту задачу, если бы компании оставалось жить две недели?

А месяц?

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