Фёдор Борщёв

Новее

Remote: офис не нужен

37 сигналов — ребята, которые придумали делать софт без фич, запустили гениальный Бейскемп и написали Руби-он-рейлс. Все свои продукты они разработали без офиса. Недавно перечитал книгу «Remote: Офис не нужен», в которой они делятся опытом удаленной работы.

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

Любишь бегать по лесу вместо беговой дорожки — пожалуйста, живи за городом. Нравится работать в толпе, — иди в кафе или коворкинг. Надоело — возвращайся домой. Работай хоть из республики Конго — главное поставляй вовремя результат.

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

Удаленная работа выгодна — не нужно тратить время на дорогу, отвлекаться на коллег, пытаться работать по 8 часов подряд (это же невозможно!). Для владельцев бизнеса удаленная работа — это работа на результат и отсутствие расходов на офисную девочку и корпоративные обеды.

Remote: офис не нужен

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

Читать больше:

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

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

Чеклист: презентация диаграмм по ToC

Читаю крутейшую книгу Уильяма Детмера о теории ограничений. Пост о книге напишу как только разложу знания по полочкам, а пока не могу не поделиться прекрасным чеклистом.

Детмер предлагает использовать этот чеклист для демонстрации любых логических построений с помощью Мыслительных Процессов Голдрадта. Но кажется, что по нему стоит проверять вообще любые обсуждения производственных нововведений с проектной командной.

  • При составлении диаграмм разработчики опираются на логику.
  • Разработчики диаграмм представляют их команде и участвуют в обсуждении последующих необходимых действий.
  • Разработчики диаграмм небезралзличны к своим творениям и заинтересованы в их применении.
  • Разработчики диаграмм показывают команде не только сами схемы, но и использованную при их построении логику.
  • Разработчики не предоставляют команде логически слабые построения.
  • Презентацию диаграмм проводят не только, чтобы получить молчаливое одобрение команды, но и чтобы услышать конструктивные советы и свежие идеи.
  • Участники обсуждения способны воспринимать конструктивную критику в адрес выдвинутых ими логических построений.
  • Участники обсуждения способны и стремятся принять конструктивный совет, если он высказан не в агрессивной форме: не «я против тебя», а «мы с тобой против системы».
  • Приглашенные эксперты должны быть заинтересованы в командной работе над изучаемой проблемой.
  • Приглашенные эксперты не должны ставить себе целью оскорбить разработчика или самоутвердиться за его счет.
  • Приглашенные эксперты должны быть специалистами в предметной области, к которой относится изучаемая проблема.
  • Координаторы работы концентрируются на логике представляемых схем, а не на содержании составляющих эти схемы элементов.

Не совсем пустой инбокс и почтовое банкротство

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

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

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

  1. залезаем в почту, чтобы найти старое письмо от клиента;
  2. видим письмо о подарке коллеге на свадьбу, которое не удалили, чтобы не забыть скинуть 100 рублей;
  3. задумываемся о подарке;
  4. просыпаемся в компании котиков из фейсбука.

В моем случае копились письма-цели: долгие задачи вроде согласования документов или сложных фич на проектах. На удаление этих писем стояла какая-то внутренняя блокировка: как же, ведь это письмо от Самого Главного! Задачи из таких писем я не добавлял в задачник, a хранил во входящих. Мой пустой инбокс никогда не был по-настоящему чистым — всегда оставалось 3–4 письма, которые я привычно игнорировал. Только отвлекался на них несколько раз в день, чтобы вспомнить от кого они и зачем.

Привычка исчезла как только я 2 раза за неделю применил почтовое банкротство — удалил по 40–50 писем не читая, чтобы не размывать фокус. И, представьте себе, небо не упало на землю — все, кому действительно было что-то от меня нужно, не поленились и написали еще раз. Документы не потерялись, цели не сместились дедлайны не проебались. Не произошло вообще ничего!

Почтовый клиент хорошего менеджера

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

Спрятать приложение из AppStore

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

Чтобы выпустить приложение, нужно сначала дождаться разрешение от Эпл. Над разрешением они думают не меньше недели и никак не гарантируют срок ответа. Идеальный способ избавиться от этой неопределенности на своем проекте — сделать предварительную сборку приложения без фич и за 3–4 недели до релиза отправить ее на модерацию. Эту сборку выпустит ваша команда, если вас вдруг собьет автобус.

После того, как Эпл вынесет резолюцию о судьбе вашего приложения (это если вы конечно, нашли незаметную галочку «не выпускать приложение сразу после модерации», и оно сразу не пошло в народ), нужно принять решение — или выпустить, или отменить релиз. Если отменить, то останетесь без релиза (результат модерации аннулируется). Если выпустить — люди увидят сырую сборку раньше срока. Если оставите в подвешенном состоянии — потеряете возможность тестировать через Тестфлайт (напишу отдельный пост о том, что с этим делать).

Способ не запускать продажу готового приложения так же неочевиден, как и все остальное в айтюнс коннект — нужно зайти в управление ценами (пункт Pricing) и отключить продажу для всех возможных стран. Тогда статус у приложения станет красным — «Developer Removed from Sale», и вы сможете добавить следующую версию приложения, пока никто не видит предыдущую.

iTunes connect — main

iTunes connect — pricing

Апдейт

Эпл обновили внешний вид Коннекта, и теперь стало легче:

iTunes connect — hide from appstore

Пока, дропбокс!

Я, как и многие, использую Дропбокс. С 2012 года я привык к тому, что не боюсь за сохранность файлов и могу открыть их в любой момент на любом устройстве. Вот, как я его использую:

  • Храню все без исключения свои файлы. Даже медиатеку (она с каждым годом все меньше, спасибо Spotify). Иногда открываю с мобильника.
  • Заливаю бекапы в отдельную папочку в облаке, которая ни с чем не синхронизируется — надо же где-то их хранить.
  • Пользуюсь автоматической загрузкой фоточек в бесконечную папку. Получается долговременная неструктурированная память, этакий фото-дневник. Все, для чего можно сделать зарубку в памяти, есть в этой папочке — документы, ключевые даты, даже некритичные пароли.
  • Синхронизирую с мобилой хранилище документов и паролей на основе Кипас-икс.

После скачка курса доллара я перешел на отечественный продукт — мне хватает 100 ГБ места, а у Яндекса это ощутимо дешевле (150 ₽ против 10$ у Дропбокса). Теперь я знаю оба сервиса и могу их сравнить:

  • Загрузка в Диск быстрее в несколько раз. Ну конечно — толстый канал до Яндекса есть в любом уголке России.
  • По сравнению с Дропбоксом, Яндекс.диск вообще не тормозит. Дропбокс медлит постоянно — при запуске, при выходе, при распаковке архивов. Диск наоборот, даже при работе с кучей мелких файлов из npm, не заставляет ноутбук включать вентилятор.
  • На телефоне скорость работы тоже отличается на порядок. На моем пятом айфоне Дропбокс запускается около 5 секунд и тормозит даже при отрисовке.
  • Дома я пользуюсь Онлаймом, поэтому Диск для меня бесплатен.

Единственное, чем Яндекс.диск безусловно проигрывает Дропбоксу — это собственным кривым алгоритмом двухфакторной авторизации. Видимо Яндексу в свое время сильно не понравилось название компании, которая первой реализовала RFC 6238 на айфонах. Ну ничего, когда-нибудь допилят.

Пока, дропбокс!

Старее