#вопрос. А расскажи просто по пунктам про корпоративную культуру в компании? Как сделать, чтобы люди забирали ответственность?
Ни одна моя попытка отдать ответственность человеку, который не хотел её брать, не окончилась ничем, кроме страданий и потраченного времени.
Наверное, где-то есть суперлюди, которые умеют менять сознание, мотивировать и перевоспитывать сотрудников. Возможно, кто-то даже от них не сбегает и действительно перевоспитывается.
Но вживую я такого не видел, поэтому мой подход к ответственности — простой:
1. Отдавать людям ответственность.
2. Если не берут — отдавать другим людям.
Задать вопрос → fedor@borshev.com
Ни одна моя попытка отдать ответственность человеку, который не хотел её брать, не окончилась ничем, кроме страданий и потраченного времени.
Наверное, где-то есть суперлюди, которые умеют менять сознание, мотивировать и перевоспитывать сотрудников. Возможно, кто-то даже от них не сбегает и действительно перевоспитывается.
Но вживую я такого не видел, поэтому мой подход к ответственности — простой:
1. Отдавать людям ответственность.
2. Если не берут — отдавать другим людям.
Задать вопрос → fedor@borshev.com
Хороший код не соответствует ТЗ
Хороший код отличается от плохого тем, что его легко и приятно менять: понятно, какой модуль за что отвечает, на каком слое архитектуры делать ту или иную задачу, какие модули можно расширять, а какие лучше выкинуть. Решения о качестве программисты принимают сами, в меру своей образованности, и никто эти решения не валидирует — обычно в ТЗ всё прозаично: поставь кнопку сюда, письмо уходит туда, циферки прибавляются вон там.
Проблема в том, что мир, описанный в ТЗ, часто успевает поменяться ещё до того, как по этому ТЗ что-нибудь сделают. И вот уже магазин превращается в службу доставки, а сервис подписок — в систему управления игровыми турнирами.
Если программист ни о чём, кроме ТЗ, не думал и из последних сил родил к дедлайну гору говнокода, то, скорее всего, всё, что умеет эта гора, — это чётко соответствовать ТЗ. Но то, изначальное, ТЗ уже никому не нужно — пока делали код, уже Путин успел три раза выступить, мир стал другим!
Хороший код, особенно в стартапе, — это не чёткое соответствие ТЗ, а вариация на тему ТЗ, которую легко можно адаптировать как к самому ТЗ, так и ко всему, что хоть как-то пересекается по предметной области.
См. также:
— Почему длинные ТЗ не работают
— Почему важно писать хороший код
Хороший код отличается от плохого тем, что его легко и приятно менять: понятно, какой модуль за что отвечает, на каком слое архитектуры делать ту или иную задачу, какие модули можно расширять, а какие лучше выкинуть. Решения о качестве программисты принимают сами, в меру своей образованности, и никто эти решения не валидирует — обычно в ТЗ всё прозаично: поставь кнопку сюда, письмо уходит туда, циферки прибавляются вон там.
Проблема в том, что мир, описанный в ТЗ, часто успевает поменяться ещё до того, как по этому ТЗ что-нибудь сделают. И вот уже магазин превращается в службу доставки, а сервис подписок — в систему управления игровыми турнирами.
Если программист ни о чём, кроме ТЗ, не думал и из последних сил родил к дедлайну гору говнокода, то, скорее всего, всё, что умеет эта гора, — это чётко соответствовать ТЗ. Но то, изначальное, ТЗ уже никому не нужно — пока делали код, уже Путин успел три раза выступить, мир стал другим!
Хороший код, особенно в стартапе, — это не чёткое соответствие ТЗ, а вариация на тему ТЗ, которую легко можно адаптировать как к самому ТЗ, так и ко всему, что хоть как-то пересекается по предметной области.
См. также:
— Почему длинные ТЗ не работают
— Почему важно писать хороший код
Забота 80 уровня от DigitalOcean
Недавно экспериментировал со своим облачным огородиком и получил вот такое письмо от DigitalOcean. Типа «Мы тут видим, что у тебя редис смотрит наружу. Это точно ок?»
DigitalOcean нигде на сайте это не продаёт, денег за такие письма не берёт. При этом они потратили силы — интегрировались с партнёром, который это делает, составили текст письма, настроили отправку. Обожаю компании, которые работают не только для того, чтобы было что написать на лендинге, но ещё и для счастья пользователей.
Недавно экспериментировал со своим облачным огородиком и получил вот такое письмо от DigitalOcean. Типа «Мы тут видим, что у тебя редис смотрит наружу. Это точно ок?»
DigitalOcean нигде на сайте это не продаёт, денег за такие письма не берёт. При этом они потратили силы — интегрировались с партнёром, который это делает, составили текст письма, настроили отправку. Обожаю компании, которые работают не только для того, чтобы было что написать на лендинге, но ещё и для счастья пользователей.
Если облажался — признавай сразу
Не люблю людей, которые не признают свои ошибки. Вот выкатил программист плохой код, ты указываешь на недостатки, а с тобой не соглашаются. По неопытности я тратил на таких людей силы — приводил примеры, приглашал коллег и независимых арбитров. Сейчас просто перестал — всё равно такие разговоры обычно ничем не заканчиваются.
Возможно, причины такого поведения лежат где-то в области психологии, что-нибудь вроде наказания детей за недостаточное количество пятёрок. Я — не большой эксперт в этом, зато могу точно привести пару рациональных аргументов, почему любую критику стоит принимать вообще всегда.
Во-первых, критика — это комплимент: если к вам никто не приходит рассказывать о ваших недостатки — значит, вы или ничего не делаете, или всем вокруг на вас пофиг. За любую критику (если она конструктивна, конечно) нужно говорить «Спасибо» — человек оторвал жопу от кресла, подошёл к вам, чтобы вы могли улучшить свою работу. Это же круто!
Во-вторых, не принимать критику — это неконструктивно. Представьте, что вы не сдали клиенту работу вовремя и доказываете, что это по его вине. Какая разница, чья вина, если проект не запущен?
В-третьих, это портит отношения. Если вы пару раз грубо пошлёте человека, который пришёл к вам с полезной критикой, он не просто перестанет вас критиковать — он, скорее всего, вообще начнёт избегать коммуникации с вами и будет прав.
Не люблю людей, которые не признают свои ошибки. Вот выкатил программист плохой код, ты указываешь на недостатки, а с тобой не соглашаются. По неопытности я тратил на таких людей силы — приводил примеры, приглашал коллег и независимых арбитров. Сейчас просто перестал — всё равно такие разговоры обычно ничем не заканчиваются.
Возможно, причины такого поведения лежат где-то в области психологии, что-нибудь вроде наказания детей за недостаточное количество пятёрок. Я — не большой эксперт в этом, зато могу точно привести пару рациональных аргументов, почему любую критику стоит принимать вообще всегда.
Во-первых, критика — это комплимент: если к вам никто не приходит рассказывать о ваших недостатки — значит, вы или ничего не делаете, или всем вокруг на вас пофиг. За любую критику (если она конструктивна, конечно) нужно говорить «Спасибо» — человек оторвал жопу от кресла, подошёл к вам, чтобы вы могли улучшить свою работу. Это же круто!
Во-вторых, не принимать критику — это неконструктивно. Представьте, что вы не сдали клиенту работу вовремя и доказываете, что это по его вине. Какая разница, чья вина, если проект не запущен?
В-третьих, это портит отношения. Если вы пару раз грубо пошлёте человека, который пришёл к вам с полезной критикой, он не просто перестанет вас критиковать — он, скорее всего, вообще начнёт избегать коммуникации с вами и будет прав.
Четвёртая часть совета об аккуратном коде: принцип единой ответственности
Я рассказал про S из SOLID — почему плохо делать божественные объекты и что каждый класс, должен решать только одну задачу.
Хотите получить развёрнутый совет об управлении разработкой? Задавайте вопросы. Только обязательно напишите, что задаёте вопрос Фёдору, чтобы я мог отличить ваш вопрос от вопросов к другим советчикам.
Я рассказал про S из SOLID — почему плохо делать божественные объекты и что каждый класс, должен решать только одну задачу.
Хотите получить развёрнутый совет об управлении разработкой? Задавайте вопросы. Только обязательно напишите, что задаёте вопрос Фёдору, чтобы я мог отличить ваш вопрос от вопросов к другим советчикам.
Список вопросов для 1:1
Отличный список для вдохновения, ~300 вопросов, которые можно задать на личной встрече с сотрудником.
Есть всё, от банального «Что ты думаешь о моей работе» до крутейшего «Если бы ты был CEO, что бы ты поменял первым делом?».
Отличный список для вдохновения, ~300 вопросов, которые можно задать на личной встрече с сотрудником.
Есть всё, от банального «Что ты думаешь о моей работе» до крутейшего «Если бы ты был CEO, что бы ты поменял первым делом?».
Скоро: как запускать проекты без хуйни
Самат круто придумывает названия. Когда он предложил назвать статью про особенности разработки в стартапах «как запускать проекты без хуйни» я сразу же согласился. «Без хуйни» — принцип, который я вынес ещё из Студии Лебедева.
Хуйня — это когда сорвал дедлайн, опоздал на встречу, сказал что починил, а оно не работает, пообещал написать и не написал. Дейли-митинги, ТЗ, свой инстанс гитлаба, стендапы, код без тестов, планинг-покер и релизные циклы — тоже хуйня.
Статья пока доступна у меня на патреоне, скоро опубликуем для всех.
Самат круто придумывает названия. Когда он предложил назвать статью про особенности разработки в стартапах «как запускать проекты без хуйни» я сразу же согласился. «Без хуйни» — принцип, который я вынес ещё из Студии Лебедева.
Хуйня — это когда сорвал дедлайн, опоздал на встречу, сказал что починил, а оно не работает, пообещал написать и не написал. Дейли-митинги, ТЗ, свой инстанс гитлаба, стендапы, код без тестов, планинг-покер и релизные циклы — тоже хуйня.
Статья пока доступна у меня на патреоне, скоро опубликуем для всех.
Мой супер-патч к django-money попал в историю — его записали на плёнку и сложили вместе с кучей другого опенсорсного кода в подземное хранилище где-то в Арктике.
Мне конечно приятно быть вписанным в вечность, но немного жаль, что туда попал однострочный патч к не очень полезной либе, который я сделал просто потому, что надо было бампнуть джангу.
Ну ничего, надеюсь, впишусь, в следующий пятилетний цикл архивирования с чем-нибудь более стоящим.
Мне конечно приятно быть вписанным в вечность, но немного жаль, что туда попал однострочный патч к не очень полезной либе, который я сделал просто потому, что надо было бампнуть джангу.
Ну ничего, надеюсь, впишусь, в следующий пятилетний цикл архивирования с чем-нибудь более стоящим.
Запретить float
Что только не хранят программисты во float — деньги, количество и вес, сотни всего. Особенно умиляют координаты — неужели они их реально складывать и вычитать собираются?
Если кто не знает, float — это числа с плавающей точкой, которые не гарантируют точности. Верно, вам никто не обещает, что 0.1 + 0.2 будет равно 0.3. Если говорить грубо, причина в том, что в компьютере нет нецелых чисел — там вообще только нули и единицы.
Если вам надо хранить десятичные дроби, используйте специальные типы данных, которые для этого разрабатывались: Decimal, или что там у вас в языке. Подробнее почитайте на https://0.30000000000000004.com.
Что только не хранят программисты во float — деньги, количество и вес, сотни всего. Особенно умиляют координаты — неужели они их реально складывать и вычитать собираются?
Если кто не знает, float — это числа с плавающей точкой, которые не гарантируют точности. Верно, вам никто не обещает, что 0.1 + 0.2 будет равно 0.3. Если говорить грубо, причина в том, что в компьютере нет нецелых чисел — там вообще только нули и единицы.
Если вам надо хранить десятичные дроби, используйте специальные типы данных, которые для этого разрабатывались: Decimal, или что там у вас в языке. Подробнее почитайте на https://0.30000000000000004.com.
Выложил в блог расширенную версию поста о том, зачем нужно оцифровывать инфраструктуру — https://borshev.com/devops-signals/.
Ссылку можно давать всем, кто до сих пор грепает по логам в консольке.
Ссылку можно давать всем, кто до сих пор грепает по логам в консольке.
Блог Фёдора Борщёва
Органы чувств в инфраструктуре
Вот упал у вас прод, вы заходите по ssh и видите, что Load Average в 10 раз больше, чем количество ядер. Люди не могут воспользоваться сервисом, партнёры задают вопросы, а всё, что вы знаете, — это то, что нагрузка выше номинальной. Где именно, из-за чего…
FEDOR BORSHEV
Скоро: как запускать проекты без хуйни Самат круто придумывает названия. Когда он предложил назвать статью про особенности разработки в стартапах «как запускать проекты без хуйни» я сразу же согласился. «Без хуйни» — принцип, который я вынес ещё из Студии…
Доредактировали с Саматом нашу статью и опубликовали на виси — https://vc.ru/hr/143929-kak-zapuskat-proekty-bez-zhiry-i-prochey-skukoteni-vot-nashi-glavnye-principy
Набрасываем много — и про скрам, и про жиру, и про огородики.
Набрасываем много — и про скрам, и про жиру, и про огородики.
vc.ru
Как запускать проекты без жиры и прочей скукотени: вот наши главные принципы
Недавно мы закончили важный проект — UIG. Для нашего партнёрства это важная веха: за два месяца мы запустили полноценный MVP технологически сложного проекта — сервиса для проведения киберспортивных турниров. Сервис хранит расписание матчей, подсчитывает результаты…
Давай решай уже
Вообще, задача хорошего управленца — принимать правильные решения, которые приносят компании денег, делают людей счастливыми и вообще выполняют KPI. Но принимать правильные решения всегда — тяжело и почти невозможно. Начинаются страдания: решения затягивают, откладывают на завтра, собирают ненужные отчёты и просто по-всякому прокрастинируют.
Вреда от затянутого решения часто больше, чем от ошибочного. Типичный пример — увольнение сотрудника: вроде он и не тянет, но только соберёшься принять решение — а тот уже одну задачку закрыл, другую, вроде и после работы задержался. Результатов всё не нет, а ты тянешь, переключаешься на другое, откладываешь. Так и работают годами неподходящие люди на нелюбимых работах.
А что случится, если уволить такого сотрудника по ошибке? Парадоксально, но, скорее всего, ничего: просто найдёшь нового.
Человек вообще склонен приумножать сложность и важность своих решений. Что говорить, если мы иногда даже не можем договориться с близким человеком, в какое кино пойти, хотя оба получили бы примерно одинаковое удовольствие и от артхаусной короткометражки, и от семейной мелодрамы?
Мой выбор — поскорее принимать решения, чтобы поскорее получить результат или поскорее исправить последствия своей ошибки. Do not make right decisions, but make decisions and then make them right.
Вообще, задача хорошего управленца — принимать правильные решения, которые приносят компании денег, делают людей счастливыми и вообще выполняют KPI. Но принимать правильные решения всегда — тяжело и почти невозможно. Начинаются страдания: решения затягивают, откладывают на завтра, собирают ненужные отчёты и просто по-всякому прокрастинируют.
Вреда от затянутого решения часто больше, чем от ошибочного. Типичный пример — увольнение сотрудника: вроде он и не тянет, но только соберёшься принять решение — а тот уже одну задачку закрыл, другую, вроде и после работы задержался. Результатов всё не нет, а ты тянешь, переключаешься на другое, откладываешь. Так и работают годами неподходящие люди на нелюбимых работах.
А что случится, если уволить такого сотрудника по ошибке? Парадоксально, но, скорее всего, ничего: просто найдёшь нового.
Человек вообще склонен приумножать сложность и важность своих решений. Что говорить, если мы иногда даже не можем договориться с близким человеком, в какое кино пойти, хотя оба получили бы примерно одинаковое удовольствие и от артхаусной короткометражки, и от семейной мелодрамы?
Мой выбор — поскорее принимать решения, чтобы поскорее получить результат или поскорее исправить последствия своей ошибки. Do not make right decisions, but make decisions and then make them right.
Стрим: настрока CI\CD в Docker Swarm
Совсем забыл вас предупредить, но завтра в 14:00 будет очередной стрим! В прямом эфире настроим непрервыную доставку микросервиса на node.js в кластер на docker swarm, в конце поотвечаю на вопросы по теме.
Совсем забыл вас предупредить, но завтра в 14:00 будет очередной стрим! В прямом эфире настроим непрервыную доставку микросервиса на node.js в кластер на docker swarm, в конце поотвечаю на вопросы по теме.
YouTube
Настраиваем Continous Deployment в Docker swarm
С помощью GitHub и CircleCI настраиваем CI\CD микросервиса на node.js в Docker swarm
Задонатить $3 — https://bit.ly/df213
Задонатить $3 — https://bit.ly/df213
#вопрос Расскажи, зачем стоит покупать кастомный SSL-сертификат?
Если отбросить чисто технические причины вроде странного софта, который сам терминирует HTTPS и требует положить себе в контейнер сертификат и ключ, я не вижу ни одной причины покупать кастомный сертификат.
Конечно, если вы банк или Яндекс, вы, наверное, купите себе дорогой сертификат и будете хранить ключи на каком-нибудь хитром носителе — но в таком случае вы не задавали бы этот вопрос. Так что, если сомневаетесь — не берите, оставайтесь на letsencrypt.
У lesencrypt есть только один минус по сравнению с кастомными сертификатами — короткий срок действия. Мне это кажется только более безопасным, но я до сих пор вижу много инфраструктур, где сертификат обновляют живые люди вместо роботов. Если вдруг вы сомневаетесь именно из-за срока длительности — просто включите свежесть сертификата в ваш мониторинг: пусть он начинает названивать админу недели за 3 до окончания, тогда уж точно будете продлять вовремя.
Каждый понедельник я отвечаю на один чётко поставленный насущный вопрос про ИТ. Присылайте вопросы на fedor@borshev.com
Если отбросить чисто технические причины вроде странного софта, который сам терминирует HTTPS и требует положить себе в контейнер сертификат и ключ, я не вижу ни одной причины покупать кастомный сертификат.
Конечно, если вы банк или Яндекс, вы, наверное, купите себе дорогой сертификат и будете хранить ключи на каком-нибудь хитром носителе — но в таком случае вы не задавали бы этот вопрос. Так что, если сомневаетесь — не берите, оставайтесь на letsencrypt.
У lesencrypt есть только один минус по сравнению с кастомными сертификатами — короткий срок действия. Мне это кажется только более безопасным, но я до сих пор вижу много инфраструктур, где сертификат обновляют живые люди вместо роботов. Если вдруг вы сомневаетесь именно из-за срока длительности — просто включите свежесть сертификата в ваш мониторинг: пусть он начинает названивать админу недели за 3 до окончания, тогда уж точно будете продлять вовремя.
Каждый понедельник я отвечаю на один чётко поставленный насущный вопрос про ИТ. Присылайте вопросы на fedor@borshev.com
Как уменьшить количество кликов в зуме
После вынужденного перехода на удалёнку до меня стало долетать гораздо больше страданий, связанных с ужасным UI зума. Он на самом деле ужасный — требует не меньше трёх кликов, чтобы зайти на каждую встречу. Делюсь советом, который экономит целый клик (Самат, спасибо!).
Нужно купить Choosy — это такая утилитка, которая в зависимости от кликнутого урла запускает нужный браузер: можно, к примеру, фигму открывать в хроме вместо сафари, чтобы меньше жрать памяти. Для зума это тоже работает — добавляете ссылки на зум, и в следующий раз, когда в телеге кликаете на ссылку, у вас открывается не браузер, а сразу зумовский клиент.
P.S. Ещё это работает для ноушена — по умолчанию электроновское приложение ноушена не открывает ссылки notion.so, поэтому вы постоянно оказываетесь с двумя ноушенами вместо одного — в браузере и в электроне.
После вынужденного перехода на удалёнку до меня стало долетать гораздо больше страданий, связанных с ужасным UI зума. Он на самом деле ужасный — требует не меньше трёх кликов, чтобы зайти на каждую встречу. Делюсь советом, который экономит целый клик (Самат, спасибо!).
Нужно купить Choosy — это такая утилитка, которая в зависимости от кликнутого урла запускает нужный браузер: можно, к примеру, фигму открывать в хроме вместо сафари, чтобы меньше жрать памяти. Для зума это тоже работает — добавляете ссылки на зум, и в следующий раз, когда в телеге кликаете на ссылку, у вас открывается не браузер, а сразу зумовский клиент.
P.S. Ещё это работает для ноушена — по умолчанию электроновское приложение ноушена не открывает ссылки notion.so, поэтому вы постоянно оказываетесь с двумя ноушенами вместо одного — в браузере и в электроне.
Не продавливать по срокам
Неопытные менеджеры часто строят разговоры с программистами на давлении. Начиная от банального «5 дней, говоришь? А может, давай за 4, но без тестов?» и заканчивая манипулятивными просьбами расписать подробную смету по часам на каждое требование.
Это — ошибка: даже если программист под давлением пообещает срок меньше, результат от этого не приблизится. Во-первых, программист будет помнить, что срок назвал не он сам, а менеджер, а значит, если этот срок проебать, то уже не так и стыдно. Во-вторых, количество работы всё равно не уменьшается — если сделать пятидневную задачу за три дня, то оставшиеся два (а может, и больше) попадут в техдолг и выстрелят через пару месяцев.
Ну и, конечно, такие менеджеры не ценят своё время: гораздо проще получить предсказуемый результат через 5 дней, чем непредсказуемый через 3, но с риском потратить ещё 5 на исправление последствий техдолга или отношений с заказчиком.
Единственный нормальный способ уменьшить названный программистом срок — это спросить у него совета, какое требование из задачи выкинуть, чтобы стало легче работать. Все остальные — манипуляции, которые не приведут ни к чему, кроме сорванных дедлайнов.
Неопытные менеджеры часто строят разговоры с программистами на давлении. Начиная от банального «5 дней, говоришь? А может, давай за 4, но без тестов?» и заканчивая манипулятивными просьбами расписать подробную смету по часам на каждое требование.
Это — ошибка: даже если программист под давлением пообещает срок меньше, результат от этого не приблизится. Во-первых, программист будет помнить, что срок назвал не он сам, а менеджер, а значит, если этот срок проебать, то уже не так и стыдно. Во-вторых, количество работы всё равно не уменьшается — если сделать пятидневную задачу за три дня, то оставшиеся два (а может, и больше) попадут в техдолг и выстрелят через пару месяцев.
Ну и, конечно, такие менеджеры не ценят своё время: гораздо проще получить предсказуемый результат через 5 дней, чем непредсказуемый через 3, но с риском потратить ещё 5 на исправление последствий техдолга или отношений с заказчиком.
Единственный нормальный способ уменьшить названный программистом срок — это спросить у него совета, какое требование из задачи выкинуть, чтобы стало легче работать. Все остальные — манипуляции, которые не приведут ни к чему, кроме сорванных дедлайнов.
Рассказал в новом совете про CI\CD на простом языке — что это такое и зачем нужно.
Покажите это своему менеджеру и дизайнеру, и скорее внедряйте.
Покажите это своему менеджеру и дизайнеру, и скорее внедряйте.
Ремоут- и неремоут люди
Бывают ребята, работать с которыми удалённо просто невыносимо. Это чуваки, которые не умеют выражать свои мысли письменно. В офисе это прекрасные люди, с которыми приятно работать и поговорить за пивом, но на удалёнке вся приятность куда-то пропадает.
Это от них вместо развёрнутых запросов приходят сообщения в слэк вроде «привет, у нас корзина не работает». И не важно, что корзина ломается, только если положить в неё 150 товаров с мобильного интернета — ты, обеспокоенный, лезешь проверять мониторинг и метрики, а потом уже, увидев, что всё в порядке, начинаешь задавать вопросы.
Корни у неумения письменно общаться идут из детства. Ещё в школе нас приучают, что все сидят в одном кабинете, а если над заданием должно поработать пять школьников — они встают из-за парт и садятся в сторонке. Задачи в школе либо ставят устно, либо берут заранее заготовленные задачи из учебников — во времена, когда проектировали школьное образование, никому в голову не приходило, что в мире появится хоть что-либо, похожее на скайп, и люди смогут взаимодействовать, ни разу друг друга не увидев.
В неумении общаться удалённо нет ничего страшного — карантин уже заканчивается, вещи потихоньку возвращаются на место. Если вы всё ещё вынуждены работать на удалёнке с «офисными» ребятами, попробуйте пожёстче внедрить ежедневные встречи, когда вся команда собирается с видео и проговаривает все мантры из стандартного скрамовского дейли: вчера я сделал X, сегодня сделаю Y, беспокоит меня Z — обычно помогает.
Бывают ребята, работать с которыми удалённо просто невыносимо. Это чуваки, которые не умеют выражать свои мысли письменно. В офисе это прекрасные люди, с которыми приятно работать и поговорить за пивом, но на удалёнке вся приятность куда-то пропадает.
Это от них вместо развёрнутых запросов приходят сообщения в слэк вроде «привет, у нас корзина не работает». И не важно, что корзина ломается, только если положить в неё 150 товаров с мобильного интернета — ты, обеспокоенный, лезешь проверять мониторинг и метрики, а потом уже, увидев, что всё в порядке, начинаешь задавать вопросы.
Корни у неумения письменно общаться идут из детства. Ещё в школе нас приучают, что все сидят в одном кабинете, а если над заданием должно поработать пять школьников — они встают из-за парт и садятся в сторонке. Задачи в школе либо ставят устно, либо берут заранее заготовленные задачи из учебников — во времена, когда проектировали школьное образование, никому в голову не приходило, что в мире появится хоть что-либо, похожее на скайп, и люди смогут взаимодействовать, ни разу друг друга не увидев.
В неумении общаться удалённо нет ничего страшного — карантин уже заканчивается, вещи потихоньку возвращаются на место. Если вы всё ещё вынуждены работать на удалёнке с «офисными» ребятами, попробуйте пожёстче внедрить ежедневные встречи, когда вся команда собирается с видео и проговаривает все мантры из стандартного скрамовского дейли: вчера я сделал X, сегодня сделаю Y, беспокоит меня Z — обычно помогает.
Стрим без темы
А давайте в этот понедельник в 19:00 соберёмся на ютубе? Будет не обычный образовательный стрим — в этот раз мы просто поболтаем в свободной форме. Темы общения задаёте вы сами — заходите на https://app.sli.do/event/d33ahdeg и задавайте вопросы, или голосуйте за уже заданные.
Это — эксперимент: я целиком отдаю вам решение о том, что будет. Подойдёт что угодно: если принесёте код на джанге — сделаю ревью, если попросите рассказать, как планировать спринты так, чтобы всё успевать — поговорим об этом.
А давайте в этот понедельник в 19:00 соберёмся на ютубе? Будет не обычный образовательный стрим — в этот раз мы просто поболтаем в свободной форме. Темы общения задаёте вы сами — заходите на https://app.sli.do/event/d33ahdeg и задавайте вопросы, или голосуйте за уже заданные.
Это — эксперимент: я целиком отдаю вам решение о том, что будет. Подойдёт что угодно: если принесёте код на джанге — сделаю ревью, если попросите рассказать, как планировать спринты так, чтобы всё успевать — поговорим об этом.
Тупое правило менеджера: не написано, значит, не было
Тупое правило, которое здорово помогает менеджеру во всех спорных ситуациях.
Программист не сдал задачу вовремя, потому что не знал? Покажи, где это было написано. Если не нашёл — значит, дедлайна не было.
На встрече договорились что-то сделать и не записали? Значит, никому не надо.
Правило «не написано, значит, не было» здорово мотивирует писать минутки ко всем встречам и поддерживать актуальность задачников. Если тебе что-то от кого-то нужно, значит, ты сядешь и напишешь задачу с дедлайном — иначе тебя пошлют нафиг и будут правы.
#тупое_правило: Не написано, значит, не было.
Тупое правило, которое здорово помогает менеджеру во всех спорных ситуациях.
Программист не сдал задачу вовремя, потому что не знал? Покажи, где это было написано. Если не нашёл — значит, дедлайна не было.
На встрече договорились что-то сделать и не записали? Значит, никому не надо.
Правило «не написано, значит, не было» здорово мотивирует писать минутки ко всем встречам и поддерживать актуальность задачников. Если тебе что-то от кого-то нужно, значит, ты сядешь и напишешь задачу с дедлайном — иначе тебя пошлют нафиг и будут правы.
#тупое_правило: Не написано, значит, не было.