FEDOR BORSHEV
Управление проектами
Подписаться
Мой любимый таск-трекер

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

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

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

Для нас в mtrl.ai было еще два ограничения
- неудобно ставить задачи, которые касаются нескольких репозиториев (к примеру одна фича затрагивает несколько микросервисов), и очень хотелось показывать статусы задач для бизнеса.

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

Для второй задачи
- прозрачности
- мы просто подключили гитхаб к трелло, где до этого хранили беклог. Раз в неделю при планировании спринта перетаскиваем выполненные задачи в колонку Done, а новые
- в колонку WIP. Каждая карточка в трелло ссылается на задачу в гитхабе, так что если вы авторизованы в обоих системах, проверка статусов занимает 3 минуты.

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

#гитхаб

Другие статьи канала FEDOR BORSHEV

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

Бирман вот пишет про правильных верстальщиков
- https://ilyabirman.ru/meanwhile/all/plohoy-i-horoshiy-verstalschiki/.

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

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

VPN Меньше, чем за две недели, ВПН из инструмента для мутных личностей и параноиков превратился в необходимость. Чтобы не ставить планы в зависимость от дураков с огнеметами, приходится искать способы шифровать свой канал.

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

За половину стоимости нормального ВПС можно купить аккаунт у любого крупного провайдера ВПН, вроде PureVPN или NordVPN. Мой любимый
- NordVPN: в добавок к удобному способу соединения, вы получаете ещё набор расширений для браузеров и быстрые SOCKS-прокси. Прокси удобно прописывать в телеграмме, чтобы приложение на телефоне работало даже без ВПН.

Скорость на платных ВПН почти не падает
- можно смело заворачивать весь канал туда. Разница будет видна только если начинаете качать что-нибудь крупное.

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

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

Чтобы не наращивать конфликт, достаточно просто говорить. Тупое правило: если видишь в сообщении от коллеги хоть небольшой намек на эмоции
- немедленно прекращай общение и назначай встречу. Если сам написал эмоциональное сообщение
- стирай скорее.

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

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

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

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

НЕ ЗАВИСАЙ

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

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

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

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

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

Нет. Проблема докера
- в пороге вхождения. Уметь докер
- это как уметь HTML
- чтобы его применить, нужно учить еще вагон технологий: CSS, JS, да и бекенд желательно. У докера это кубернейтс, чтобы запускать контейнеры, прометеус, чтобы их мониторить, и куча самописных скриптов, чтобы все это деплоить.

Такие сложности имеют смысл, когда ваша команда дорастает до разделения на разработку и эксплуатацию, или вы начинаете БЫСТРО масштабироваться. Тогда докер становится удобным языком общения между командами и хорошим помощником, чтобы моментально поднимать инфраструктуру на любой площадке.

Если вы до этого еще не доросли, то используйте докер «как все»
- чтобы быстро разворачивать куски инфраструктуры на машине разработчика. А сервера автоматизируйте на старом добром Ansible.

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

datadoghq.com Сегодня расскажу о важной штуке
- Application Performance Monitor, или APM. APM нужна программистам, чтобы анализировать скорость работы кода прямо в продакшене.

Когда приходит тикет «АА, у меня сайт тормозит», программист без APM вынужден поднимать инфраструктуру на локальной машине и долго созерцать код в попытках угадать узкое место. Программист с APM просто заходит в удобный интерфейс и смотрит трейсы
- слепки из живых ответов системы, на которых видно распределение времени между частями программы. Думать вообще не надо
- все узкие места как на ладони.

Датадог
- один из трех доступных на рынке APM для питона (есть еще new relic и obeat). Кроме APM, содержит в себе еще развитую систему мониторинга серверов
- снимает метрики с железа и контейнеров, шлет уведомления, и интегрируется с тоннами систем.

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

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

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

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

FEDOR BORSHEV
Управление проектами
Подписаться
Стейджинг → деплой превью

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

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

Расскажу про наш сетап. Про первую часть я уже писал в заметке про нетлифай
- это автоматическая публикация веток фронтенда на поддоменах. На каждый ПР у нас появляется ссылка вида deploy-preview--<
feature>
--<
project>
.netlify.com.

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

У нас это специальная машина на селектеле, на которой через docker-compose крутится минимальная инфраструктура, отключенная от внешних интеграций. Образы постоянно обновляются через ночные сборки в CI, включая полную копию рабочей базы.

Фичи, которые затрагивают бекенд, обычно выкатываем прямо в продакшн, еще до запуска фронта. Так можно делать, если вы не нарушаете обратную совместимость (вы же только добавляете поля в API, а не удаляете, правда?). Затем фича через ночные сборки попадает на демонстрационный бекенд, куда уже ходят фронтовые превью.

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

FEDOR BORSHEV
Управление проектами
Подписаться
Наиболее эффективная коммуникация У всех людей разные привычки и возможности общения.

Я для себя открыл наиболее эффективный способ общения: одно дело в одном сообщении.

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

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

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

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

- Это поэтому ты так много успеваешь? А ты сам придумал этот лайфхак? А как мне научиться делать как ты?- ...

FEDOR BORSHEV
Управление проектами
Подписаться
Продолжение вчерашней темы. В слеке не работает важнейшее правило электронного общения:

одно сообщение
- один вопрос. Почитайте Тему вот:

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

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

Скиньте эту ссылку прямо сейчас в свой рабочий слек
- https://borshev.com/slack-productivity/

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

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

Ребята выявили и идеально закрыли конкретную боль фронтендеров
- до появления сервиса, чтобы опубликовать даже самое простое приложение, приходилось идти к девопсам
- поднимать CI, разбираться в хостинге и DNS.

Нетлифай закрывает вопрос полностью
- в нем есть CI (который не надо настраивать!), быстрый хостинг на амазоне, автоматический DNS и деплой-превью. Если остается желание, то в каждую часть процесса можно влезть и что-нибудь покрутить
- сделать домен верхнего уровня, настроить редиректы или проксирование, докрутить CI.

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

И все это бесплатно.

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

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

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

Перефокусироваться с процесса на результат
- тяжело: это связано с индивидуальными особенностями личности. Мне в свое время помогали простые вопросы про бизнес:
- Зачем я вообще делаю эту задачу? Кто ожидает от нее результат? Как этот результат выглядит?
- Как бизнес получал бы результат, если бы меня не было? Как бы я мог бы им в этом помочь?
- Если бы я мог потратить на эту задачу всего 30 минут, какими бы ее частями я пожертвовал, чтобы бизнесу было наименее больно?
- Какая самая сложная часть задачи? Что можно изменить в постановке, чтобы избавиться от нее?

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

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

Редко читаю (а тем более советую) художку, но мимо этой серии пройти невозможно. Трилогия называется «Воспоминания о прошлом земли», написал ее китаец Лю Цысинь.

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

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

О художественной части я могу судить только на уровне «интересно-не интересно». «Воспоминания»
- интересно.

Похоже всю серию на русском так и не выпустили, так что гуглите английскую The Remembrance of Earth's Past.

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

В общении с плохими программистами (и сантехниками) часто проскакивает тон «это нерешаемая задача»:


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


- Давай передавать данные о телефонных заказах в Гугль-аналитику? Не получится, мы для таких заказов не знаем ИД аналитики.

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


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


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

Будьте решателями проблем, а не создавателями.

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

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