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

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

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

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

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

Мы предельно упростили процесс выхода на эти две недели
- достаточно прислать скан подписанного НДА. Сразу после этого на почту падает приглашение в нашу команду на гитхабе (все общение там) и пара пристрелочных задач.

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

#работамечты

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

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

Google Tag Manager Если вы вдруг работаете с вебом, и до сих пор не знаете про Google Tag Manager
- эта заметка для вас. GTM
- это фундаментальный инструмент для управления интеграциями с внешними системами.

Вот представьте ситуацию, вы
- маркетолог, подключаете новый канал (к примеру Фейсбук), а он требует установки какого-то кода на сайт (к примеру Фейсбук-пикселя). Если у вас на сайте нет ГТМ
- приходится идти к айтишникам, а у них еще 100 задач, спринт и вообще не до вас. Если ГТМ установлен
- вы просто идете в его интерфейс, копируете код и все моментально появляется на сайте.

Или вы
- аналитик, для проверки новой гипотезы хотите измерить количество нажатий на определенную кнопку. В ГТМ вы просто создаете новое событие, и данные сами собой записываются в Google Analytics (или куда там вам надо).

GTM
- полностью бесплатный сервис, имеет в комплекте пачку готовых интеграций и позволяет легко устанавливать свои. Из минусов
- только Material design и традиционная для Гугла отвратительная документация. Альтернативы есть, но какие-то невнятные и платные.

tagmanager.google.com

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

Вики Ивелума

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

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

Вот пара интересных мест:
- Еженедельные отчеты всех сотрудников.

- Процесс разработки
- методология, тестирование, общение с заказчиком.

- Порядок реакции на инциденты в продакшене.

Полностью
- тут.

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

FEDOR BORSHEV
Управление проектами
Подписаться
Вышла вторая версия терминала на электроне — Hyper.

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

Терминал. Зависал. От данных.

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

Терминал, который зависает, если вывести много текста? База данных, в которой нет реляционности? Бекенд на языке, который может работать только в один поток? Пожалуйста!

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

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

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

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

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

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

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

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

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

#гитхаб

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/

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

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