Начинаем стрим в 14:00!

В прямом эфире расскажу, как Django интегрирована с Tilda у меня на pmdaily.ru, и как повторить это у себя. Потом, как обычно, попишем код. Будет даже немного jQuery, кто не знает — это такой дедовский способ манипулировать DOM, его юзали когда реакт ещё не изобрели.

https://youtu.be/zxO4gxkp7LI

Не сомневаться в принятых решениях

Важный принцип из ГТД — нужно отделить принятие решения от его выполнения.

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

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

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

Почему лучше разделить фронтенд и бэкенд

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

Что я забыл? Добавляйте в комментариях.

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

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

Возможно вам поможет принцип «show, not tell»: вместо того, чтобы объяснять свою ценность на словах — докажите её. Начните закрывать свои таски быстрее. Если не получается на работе — потратьте свободное время на свой проект (там же заодно и хард-скиллы прокачаете), а потом покажите руководителю.

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

Задайте свой вопрос на fedor@borshev.comfedor@borshev.com

​Правильная обратная связь

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

— Федя, я тут разобрал проект, который ты сделал. Мне очень понравилось, как быстро вы его запустили: подключили стороннюю команду, не тянули с согласованиями — буквально за три дня. Немного смущает, что мобильная версия не работает на старых айфонах, но вы это наверное поправите. А иллюстрации — вообще огонь!

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

Говорить с видео

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

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

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

Если работаете в распределённой команде — пользуйтесь видео, это прикольно и полезно.

​Начинаем через 5 минут

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

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

Включатесь!

#Вопрос#Вопрос: руковожу проектом страховых терминалов. Чтобы сервис работал, нужно, чтобы корректно взаимодействовало много систем — ядро нашей системы, МВД, другие гос. базы. У каждой системы есть менеджер. Как быть, когда менеджер одной из них ломает функциональность других?

Заключите с коллегами контракт — задокументируйте API, по которому общаются ваши сервисы. Я имею ввиду не файл «Документация.docx» а внятно описанный формат взаимодействия, идеально — что-нибудь вроде API Blueprint или любого другого, который позволяет запускать автоматические тесты.

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

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

Задайте свой вопрос на fedor@borshev.comfedor@borshev.com

Счастье и процессы в удалённой работе

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

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

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

Вебинар пройдёт 16 февраля в 14:00.

Как измерить уровень инженерной культуры

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

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

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

Впихивание и вынимание

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

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

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

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

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

Взять на работу человека, ни разу его не увидев

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

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

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

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

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

P.S. 16 февраля приходите на мой вебинар об удалённой работе — расскажу, как именно строить прозрачные системы контроля результатов

Обсуждать свои ошибки, а не чужие

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

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

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

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

Так новые ребята сразу понимают, что в этом месте за ошибки их не побьют. А значит сразу начнут ошибаться и учиться на этих ошибках.

Нужно встречаться

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

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

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

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

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

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

Созвоны из кафе — будущее наступило

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

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

Если, как и я, любите поработать из кафе — рекомендую комбо из Krisp и любых наушников с активным шумоподавлением. К сожалению, Krisp берёт деньги по подписке, так что если вдруг знаете альтернативы — черкните пару строк на fedor@borshev.com

Самая важная часть увольнения

Самая важная часть увольнения — эксит-интервью. Эксит-интервью — это такое время для честной обратной связи. Самое время рассказать, что руководитель душил инициативу, вёл себя неуважительно или ставил плохие задачи.

Чтобы магия случилась, важно, чтобы эксит-интервью проводил не тот самый руководитель, а кто-нибудь авторитетный со стороны. У нас в ГдеМатериале, к примеру, со всеми уходящими программистам (их немного, но бывает), разговаривает CEO.

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

— Что хочешь получить на новом месте, чего не хватило на старом?
— Что нравилось\не нравилось у нас?
— Что посоветовал бы поменять после того, как ты уйдёшь?
— В какой момент ты начал задумываться об уходе? Когда начал активно искать работу?

А давайте встретимся в следующую среду?

19 февраля в 19:00 в Коворкафе (это в Москве, на Флаконе) пройдут мои живые советы. Живые советы — это такая свободная встреча в формате вопросов-ответов, на которой мы обсудим всё, связанное с управлением разработкой — продуктовый подход, планирование времени, организацию совместной работы.

Условие посещения — собственный вопрос к советчику. Доступно всего 20 мест, так что если будете в Москве в это время — регистрируйтесь.

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

Федя и Самат

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

В любом случае, вдвоём страшно чуть меньше. Мы с Саматом запускаем совместную услугу — настройку ин-хаус разработки. Это не аутсорс, который перепродаёт часы программистов, и не консалтинг, который говорит «как надо» и уходит в сторону, когда получается «как вышло».

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

Совсем скоро мы в реальном времени начнём рассказывать, как именно мы помогаем одному из наших клиентов: расскажем, как крупный сервис доставки с 4000 заказов в день решает наболевшие у всех проблемы, вроде накопленного техдолга и перегруженной команды разработки.

Если хотите, чтобы мы помогли вашей компании — напишите Самату на @samatg. Если вы — разработчик и хотите работать в одной из наших команд, напишите мне на fedor@borshev.com.

#вопрос почему ты решил уйти из агентства в продуктовую разработку?

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

Хотелось доказать себе, что я могу не только делать, что говорят клиенты, но и самостоятельно участвовать в процессе зарабатывания денег. Мне очень повезло с ГдеМатериалом — я пришёл в только образовавшуюся команду без собственных наработок, поэтому выстроил все процессы буквально из ничего.

Ну а ещё — я фанат качественного кода, а в агентствах обычно с этим туго.

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

А давайте потусим в Питере в субботу?

В эту субботу в 14:00 собираемся в творческом пространстве Код 505 на Старом Невском.

Будет AMA — вы задаёте вопросы, а я отвечаю. Как Живые Советы, только в Питере. Чтобы прийти, нужно зарегистрироваться и придумать вопрос. Доступно всего 30 мест.

Регистрируйтесь и подписывайтесь на канал встречи с оперативными новостями.