FEDOR BORSHEV

Пишу о производстве сложных проектов, управлении продуктами, профессиональном росте программистов

FEDOR BORSHEV
Управление проектами
Подписаться

Запись чата. Спасибо всем, кто дослушал до конца!

FEDOR BORSHEV
Управление проектами
Подписаться
Завтра в 19:

00 MSK с Васей Половнёвым говорим о профессиональном росте
- как выбирать траекторию роста, как выбирать компанию, стоит ли делать пет-проекты. Будут спойлеры с будущего курса и личные истории. Приходите
- говорим в канале.

FEDOR BORSHEV
Управление проектами
Подписаться

Удалёнка != асинхронная работа

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

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

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

FEDOR BORSHEV
Управление проектами
Подписаться

#вопрос Расскажи, как правильно писать readme?

Readme
- это штука, которая первой попадается на глаза каждому посетителю вашего репозитория. Поэтому и относиться к ней стоит как к главной странице сайта. Поймите, для чего люди заходят на эту страницу, и помогите им реализовать все эти сценарии использования. Я предлагаю вот такие сценарии для начала:

- Что это такое? Заходит админ, менеджер или дизайнер. Поясните им, что это за проект и для чего он используется. Можно даже не в readme, а в описании репозитория, GitHub показывает это выше, чем readme.- Как работает CI? Где это лежит? Разработчики заходят проверить статус CI или открыть панель хостинга, чтобы посмотреть, хорошо ли их приложению живётся в проде. Поставьте ссылки на CI и дешборды, которые делают девопсы.- Как это развернуть? В репу с бекендом заходит фронтендер или джуниор-бекендер. Расскажите им, как у вас тут принято разворачивать: фронтендерам дайте докер-образ (а лучше положите docker-compose в репу с фронтом, чтобы к вам вообще не ходили), джуну
- ссылку на мануал.- Как тут принято писать код? Это уже не только для джунов, но и для всех. Поставьте ссылки на ваши стандарты кодирования.

У вас наверняка есть ещё какие-нибудь сценарии, специфичные для вашей команды. Поделитесь?

P.S. Каждый понедельник я отвечаю на один конкретно поставленный вопрос. Задавайте на fedor@borshev.com

FEDOR BORSHEV
Управление проектами
Подписаться
Как настроить зум, чтобы удобно говорить

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

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


- Отключите комнату ожидания (waiting room). Она совершенно не нужна
- обычно мы проводим встречи каждый раз по новой ссылке. Если очень боитесь, что к вам зайдёт кто-то лишний во время приватной беседы, просто запирайте комнату (security → lock meeting в нижней панели).

- Включите пароль (meeting passcode) и проверьте, что этот пароль автоматически подставляется во все ссылки, которые вы делаете (Embed passcode in invite link for one-click join). Так вы защититесь от ботов-зумбомберов.

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

- Разрешите приходить на встречи до вас (Allow participants to join before host). Если кто-то придёт раньше вас на 30 секунд, он зайдёт в комнату и настроится, а не будет пялиться в унизительный белый экран ожидания.

- Разрешите всем шарить экран (Screen sharing → who can share выберите All Participants).

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

FEDOR BORSHEV
Управление проектами
Подписаться
Не принимать важные решения в присутствии других

Периодически встречаю людей, которые хорошо умеют «давить»
- заставлять других делать то, что хотят, не через взвешенные аргументы а-ля Кемп, а через эмоции: повышенный голос или чувство вины («Что, не можете? А мы так на это рассчитывали...»). Эмоции могут быть не только негативными
- вы даже не представляете, насколько мы становимся сговорчивыми, если пару раз искренне поинтересоваться нашими делами или открыто улыбнуться.

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

Это просто. Для начала разберитесь, по каким законам манипуляторы это делают. Для этого помогут две книги
- «Договориться можно обо всём» Гевина Кеннеди и «48 законов власти» Роберта Грина. А затем установите простое правило
- не принимайте важные решения в присутствии других людей. Особенно если сомневаетесь в их профессионализме. Собирайте вводные, принимайте решение в одиночестве, а затем защищайте принятое решение уже на новой встрече.

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

FEDOR BORSHEV
Управление проектами
Подписаться

#вопрос: подскажи, как питон или прикладная математика могут помочь предпринимателю/управленцу

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

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

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

-
-
-Каждый понедельник я отвечаю на один конкретно поставленный вопрос. Задавайте на fedor@borshev.com.

FEDOR BORSHEV
Управление проектами
Подписаться
Лучше предупредить и сделать, чем не предупредить и не сделать

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

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

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

Так что всегда, когда чувствуете, что есть даже небольшой риск пропустить дедлайн, сообщайте об этом команде. .

FEDOR BORSHEV
Управление проектами
Подписаться
Профессиональный рост:

меня и команды Сейчас мне 33 года, я
- неплохой программист, классно умею управлять разработчиками и даже почти научился вести бизнес. Всё это я мог бы иметь и в 25, если бы занимался развитием не как придётся, а системно
- не тратил бы время на бессмысленную работу, не читал книги, которые выглядели умно, но не приносили ничего, и чаще общался с умными людьми. Даже если бы я просто начал ставить годовые планы не в 30 лет, а в 20
- уже был бы гораздо дальше.

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

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

4 недели, лонгриды и домашка, q&
a-сессии. Запускаемся 10 августа, до конца недели промокод на 10%
- idbeholds.

FEDOR BORSHEV
Управление проектами
Подписаться

Где проходит граница между зонами ответственности менеджера и тимлида?

FEDOR BORSHEV
Управление проектами
Подписаться
«Соберём команду и спросим кто что думает»

На курсе «Стать тимлидом» у нас есть домашка
- найти недостаток в коммуникации своей команды и построить план его устранения. И самая частая ошибка
- первым пунктом плана становится собрать всю команду и поговорить.

Дело в том, что на таких встречах вы будете слышать только самых громких людей, которые склонны громко говорить о себе и своих проблемах. И далеко не всегда громкие люди
- это те, кто может решить вашу проблему.

Допустим, у вас есть команда из 10 человек, все привыкли быть в слаке 24/7, и когда кто-то один уходит в отпуск, работа сразу встаёт: не находится нужных доступов, никто не знает, какие библиотеки можно использовать или как катить на прод. Если вы соберёте встречу на всю команду, то, потратив 10 человеко-часов, рискуете постановить что-то вроде «давайте хранить доступы в 1password, а в слаке писать более подробные сообщения». И если в первом случае у вас ещё что-то может получиться (если не забудете назначить ответственного), то во втором не изменится примерно ничего.

А теперь представьте, что вы выберете двух-трёх участников команды, которые умеют выражать свои мысли письменно, и сравните их работу с остальными. Скажем, сделаете с ними тестовый проект, во время которого они уйдут в отпуск. Или измерите количество времени, которое они проводят в слаке, и сравните это количество с какой-нибудь другой контрольной группой? Тогда команде можно будет презентовать уже не проблему, а решение
- «делайте как Вася, Петя и Серёжа, тогда станете Х».

Сравните разницу
- с одной стороны, вы потратите 10 человеко-часов с риском получить бесполезные невыполнимые решения, а с другой
- выдвинете конкретное предложение, потратив в три раза меньше времени. Так что никогда не собирайте команду, чтобы придумать решение проблемы
- выбирайте 1–3 человек, придумывайте решение с ними, а потом уже доносите его до всей команды.

FEDOR BORSHEV
Управление проектами
Подписаться

пост, в котором как раз описываются виды диаграмм в архитектуре. Из книг, могу порекомендовать "Software Architecture Handbook" от Joseph Ingeno. Это хендбук по архитектуре, где поверхностно описаны тем, которые пригодятся архитекторам. Поэтому глава о документации и диаграммах там тоже присутствует.


-
-
-Каждый понедельник я отвечаю на один конкретно поставленный вопрос. Задавайте на fedor@borshev.com.

FEDOR BORSHEV
Управление проектами
Подписаться
Курс от системы или курс от человека Я не люблю курсы о понятных вещах.

Такие курсы обещают какой-нибудь конкретный скилл из топа поисковика: научить вас питону или сделать девопсом. У курса о понятных вещах простая формула
- берём пару книг, чувака из рандомной крупной компании и запускаем рекламу а-ля «ВОЙДИ В АЙТИ ПРЯМО СЕЙЧАС». Мне такие курсы кажутся бесполезными
- все эти знания есть в книгах, блогах и на конференциях. Если соберёте знания самостоятельно
- приобретёте больше нейронных связей, а значит больше примените потом в работе.

Я люблю курсы о том, что в книгах не прочитаешь. Чаще всего такой курс
- это отражение личного опыта. Недавно прошёл Ильяховские «видео и подкасты» и восхитился. Представляете
- редактор, вроде бы далёкий от ютуба, продакшена и монтажа взял и поделился опытом
- как он построил студию, как монтирует видео, как выстраивает кадр и что говорит. Это не курс «СТАНЬ ЮТУБ-БЛОГЕРОМ», а реальная жизнь, рассказанная простым языком и полезная даже для тех, кто давно варится в сфере видео.

В нашей школе все курсы
- о новом: мы не повторяем чужие мысли, не перепаковываем известные книги и следим за содержанием больше, чем за формой (привет, прошлый поток «Асинхронной архитектуры»). Рядом с нами есть ещё одна школа с похожими принципами и одним общим сооснователем, Марьяной,
- это Школа ченджеров. Школа построена на личном опыте Наташи Бабаевой, ex-директора по развитию МИФ. Тема Наташи
- чейндж и ран: о том, чем создание нового отличается от поддержки существующего.

Если вам когда-нибудь становилось скучно на работе потому, что каждая новая неделя похожа на предыдущую, а ваши задумки руководство мягко заворачивает, потому что они слишком радикальны
- посмотрите их курс Change Basics, там расскажут, что делать. Мы ссылаемся этот курс как минимум два раза
- в «Стать Тимлидом» и «Асинхронной Архитектуре» (Антон одобряэ). Если решитесь
- вот вам промокод на 10%: PMDAILY.

P.S. На следующей неделе анонсируем наш курс *о новом*, готовьтесь.

FEDOR BORSHEV
Управление проектами
Подписаться

Похвастаюсь: мы с Федей наняли аккаунта! Наш первый не-программист, Дари Лебедкина отвечает за:

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

Я счастлив. Когда мы начали работать с Федей, я совсем перестал беспокоиться о реализации проектов, когда нужно что-то запрогать. Федя все сделает когда обещал и ничего не забудет.

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

FEDOR BORSHEV
Управление проектами
Подписаться
Простое правило про технический долгВ какой-то умной книге прочитал правило:

Простое правило про технический долг

В какой-то умной книге прочитал правило: «если пилишь фичу
- сначала сделай так, чтобы ее удобно было добавлять, а только затем
- добавляй».

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

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

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

См. так же
- технический долг как финансовый.

Рейтинг авторов

  • "Записки Дизайнера" (про дизайн и только про него 157 157 157
  • (Не) только немецкий 157 157 157
  • #анямастерконтента 157 157 157
  • #Фудтех 157 157 157
  • 10 идей и трендов дня 157 157 157
Показать весь рейтинг
Загрузка ...