Перестал вести учёт расходов
С 2015 года я вёл учёт личных расходов — каждый понедельник садился, открывал банковскую выписку и разносил все платежи за прошлую неделю по категориям — еда и хозяйство, одежда, развлечения и т.д. Иногда пропускал неделю, один раз — пропустил целых три. В 2024 году, спустя ровно 9 лет после начала, я перестал это делать.
Базовый принцип «лучше больше зарабатывать, чем меньше тратить» я понял году в 2017, но продолжал вести расходы. А недавно понял, что не принял ни одного решения на основе данных о расходах. Что толку знать, что каждый месяц я трачу на жильё 1500 евро, если принимая решение об ипотеке, я и так могу легко посчитать стоимость всех арендных платежей? Что изменится от того, что в прошлом месяце я потратил на еду 700 евро вместо 400? Зачем знать, сколько обходится автомобиль, если идиоту понятно, что такси в Москве стоит дешевле?
Если я не принимаю решений, то смысла в этих расчётах нет. Разве что в процессе: садишься записывать расходы, и как бы 20 минут напоминаешь себе — все траты предсказуемы, ни одна копейка не уйдёт без твоего ведома. Как мантра.
Но это же неправда! Завтра могут заболеть родственники, центробанк может опустить ставку, я захочу сделать идиотски дорогой подарок супруге, сосед сверху зальёт квартиру, или я сам залью квартиру соседу снизу. Контроля над этим у меня нет.
Получается, что записывать расходы — это работать с прошлым. Так что лучше я буду 20 минут работать с будущим — к примеру начну тратить это время на более качественное планирование недели. Или просто подольше сидеть в кресле и ничего не делать.
С 2015 года я вёл учёт личных расходов — каждый понедельник садился, открывал банковскую выписку и разносил все платежи за прошлую неделю по категориям — еда и хозяйство, одежда, развлечения и т.д. Иногда пропускал неделю, один раз — пропустил целых три. В 2024 году, спустя ровно 9 лет после начала, я перестал это делать.
Базовый принцип «лучше больше зарабатывать, чем меньше тратить» я понял году в 2017, но продолжал вести расходы. А недавно понял, что не принял ни одного решения на основе данных о расходах. Что толку знать, что каждый месяц я трачу на жильё 1500 евро, если принимая решение об ипотеке, я и так могу легко посчитать стоимость всех арендных платежей? Что изменится от того, что в прошлом месяце я потратил на еду 700 евро вместо 400? Зачем знать, сколько обходится автомобиль, если идиоту понятно, что такси в Москве стоит дешевле?
Если я не принимаю решений, то смысла в этих расчётах нет. Разве что в процессе: садишься записывать расходы, и как бы 20 минут напоминаешь себе — все траты предсказуемы, ни одна копейка не уйдёт без твоего ведома. Как мантра.
Но это же неправда! Завтра могут заболеть родственники, центробанк может опустить ставку, я захочу сделать идиотски дорогой подарок супруге, сосед сверху зальёт квартиру, или я сам залью квартиру соседу снизу. Контроля над этим у меня нет.
Получается, что записывать расходы — это работать с прошлым. Так что лучше я буду 20 минут работать с будущим — к примеру начну тратить это время на более качественное планирование недели. Или просто подольше сидеть в кресле и ничего не делать.
Готовые комплекты вещей
Самое смешное бытовое открытие прошлого года — это готовые комплекты вещей. К примеру, комплект проводов и зарядок для поездки. Раньше нужно было подумать, какие устройства я с собой беру (нужен ли lightning? а зарядка для часов?), посмотреть, отыскать всё это, проверить чтобы все провода были совместимы со всеми устройствами, а после поездки — вернуть на место. Сейчас достаточно взять маленькую сумку с зарядками, которая всегда собрана.
Или наушники. Раньше нужно было не забыть наушники, когда идёшь в кофейню, отыскать их перед походом в спортзал, и проследить, чтобы они не сели во время зум-созвона. Сейчас достаточно взять наушники для встреч (самые лёгкие и без шумоподавления, которое не нужно дома), в дороге — достать походные наушники, а в спортзале — взять спортивные, которые так и живут в спортивной сумке.
Дошёл до этого после идеи с айпадом для одиночества. Вы не представляете, сколько времени, а главное — энергии я стал экономить, когда перестал собирать электронику в поездки.
Самое смешное бытовое открытие прошлого года — это готовые комплекты вещей. К примеру, комплект проводов и зарядок для поездки. Раньше нужно было подумать, какие устройства я с собой беру (нужен ли lightning? а зарядка для часов?), посмотреть, отыскать всё это, проверить чтобы все провода были совместимы со всеми устройствами, а после поездки — вернуть на место. Сейчас достаточно взять маленькую сумку с зарядками, которая всегда собрана.
Или наушники. Раньше нужно было не забыть наушники, когда идёшь в кофейню, отыскать их перед походом в спортзал, и проследить, чтобы они не сели во время зум-созвона. Сейчас достаточно взять наушники для встреч (самые лёгкие и без шумоподавления, которое не нужно дома), в дороге — достать походные наушники, а в спортзале — взять спортивные, которые так и живут в спортивной сумке.
Дошёл до этого после идеи с айпадом для одиночества. Вы не представляете, сколько времени, а главное — энергии я стал экономить, когда перестал собирать электронику в поездки.
Императивный и декларативный бизнес
Вообще этот пост — реклама курса о Developer Experience, который мы доработали по итогам обратной связи от живого потока и теперь открыли продажи. Но вообще — это часть моего (внутреннего пока) исследования о том, какие ещё концепции из программирования можно притащить в управление бизнесом. На этот раз хочу поговорить о декларативном и императивном программировании.
Своим первым отделом я начал руководить, страшно подумать, 15 лет назад. И первым моим шагом, конечно же, была разработка регламентов. Даже не задумывался, зачем (KPI мне никто не ставил) — просто делал, потому что так принято. И пофиг, что в отделе 5 человек, а во всей компании — 15: я начал писать страшные бумаги, что-то вроде «если приходит срочная задача, то постановщик должен лично подойти к исполнителю». Довольно похоже на первый код, который пишут джуны: «if user.has_access_to_action() then perform_action()»
У этих регламентов есть одна общая проблема с джуновым кодом — все случаи жизни if-ами не покроешь. Если попытаешься — выйдет длинная портянка, которую ни один нормальный человек читать не будет. Чтобы решать проблемы в императивном коде, давно придумали целый арсенал — от дяди Боба до YAML.
А вот с людьми абстракций не наделаешь: фреймворков, чтобы залезать в голову и управлять каждым шагом исполнителя, пока не изобрели. И тут есть два диаметрально разных подхода: можно назвать их конвейерный и стапельный.
В конвейерном подходе всё как в коде: инструкции прячутся за механизмы, которые вроде как обеспечивают их выполнение. Прежде, чем ставить рабочего к конвейеру, его прогоняют через обучение и экзамен. Результат работы постоянно проверяют, самого рабочего — тоже. Периодически меняют инструкции, людей переаттестуют или вообще заменяют на роботов. Такой подход работает при массовом выпуске — на автомобильных заводах, к примеру.
Стапельный подход — более штучный. Мы не пытаемся прописать каждый шаг исполнителя, а дизайним среду, в которой исполнитель будет выполнять то, что нужно. Работает со штучными производствами. В автомобилях, к примеру — в тюнинг-ателье, где каждый автомобиль уникален.
В разработке (думаю и в любой другой творческой работе) действует только штучный подход. Чтобы люди хорошо закрывали клиентские задачи, им нужна удобная среда — доверие, нормальные инженерные практики, минимальная коммуникация, свободное время, много автоматизации, а в идеале ещё и мало контроля. Создавая такую среду в аутсорсе, мы делаем то самое тюнинг-ателье, которое сегодня обшивает потолок майбаха алькантарой, а завтра вкорячивает 37” колеса на джип.
Грустно смотреть на коллег, которые этого не понимают, и вместо линтеров делают стандарты разработки, а вместо асинхронной коммуникации — дейли-митинги и контроль времени.
---
Собственно курс о среде для штучного производства называется «Без Ерунды», состоит из четырёх писем — о доверии, инженерных процессах, внимании и работе с клиентом. Если вы покупали курс раньше — все обновления уже у вас в LMS. Если сомневаетесь — гляньте отзывы из вложения
Вообще этот пост — реклама курса о Developer Experience, который мы доработали по итогам обратной связи от живого потока и теперь открыли продажи. Но вообще — это часть моего (внутреннего пока) исследования о том, какие ещё концепции из программирования можно притащить в управление бизнесом. На этот раз хочу поговорить о декларативном и императивном программировании.
Своим первым отделом я начал руководить, страшно подумать, 15 лет назад. И первым моим шагом, конечно же, была разработка регламентов. Даже не задумывался, зачем (KPI мне никто не ставил) — просто делал, потому что так принято. И пофиг, что в отделе 5 человек, а во всей компании — 15: я начал писать страшные бумаги, что-то вроде «если приходит срочная задача, то постановщик должен лично подойти к исполнителю». Довольно похоже на первый код, который пишут джуны: «if user.has_access_to_action() then perform_action()»
У этих регламентов есть одна общая проблема с джуновым кодом — все случаи жизни if-ами не покроешь. Если попытаешься — выйдет длинная портянка, которую ни один нормальный человек читать не будет. Чтобы решать проблемы в императивном коде, давно придумали целый арсенал — от дяди Боба до YAML.
А вот с людьми абстракций не наделаешь: фреймворков, чтобы залезать в голову и управлять каждым шагом исполнителя, пока не изобрели. И тут есть два диаметрально разных подхода: можно назвать их конвейерный и стапельный.
В конвейерном подходе всё как в коде: инструкции прячутся за механизмы, которые вроде как обеспечивают их выполнение. Прежде, чем ставить рабочего к конвейеру, его прогоняют через обучение и экзамен. Результат работы постоянно проверяют, самого рабочего — тоже. Периодически меняют инструкции, людей переаттестуют или вообще заменяют на роботов. Такой подход работает при массовом выпуске — на автомобильных заводах, к примеру.
Стапельный подход — более штучный. Мы не пытаемся прописать каждый шаг исполнителя, а дизайним среду, в которой исполнитель будет выполнять то, что нужно. Работает со штучными производствами. В автомобилях, к примеру — в тюнинг-ателье, где каждый автомобиль уникален.
В разработке (думаю и в любой другой творческой работе) действует только штучный подход. Чтобы люди хорошо закрывали клиентские задачи, им нужна удобная среда — доверие, нормальные инженерные практики, минимальная коммуникация, свободное время, много автоматизации, а в идеале ещё и мало контроля. Создавая такую среду в аутсорсе, мы делаем то самое тюнинг-ателье, которое сегодня обшивает потолок майбаха алькантарой, а завтра вкорячивает 37” колеса на джип.
Грустно смотреть на коллег, которые этого не понимают, и вместо линтеров делают стандарты разработки, а вместо асинхронной коммуникации — дейли-митинги и контроль времени.
---
Собственно курс о среде для штучного производства называется «Без Ерунды», состоит из четырёх писем — о доверии, инженерных процессах, внимании и работе с клиентом. Если вы покупали курс раньше — все обновления уже у вас в LMS. Если сомневаетесь — гляньте отзывы из вложения
Затаскивать проекты, а не людей
Клёво затаскивать проекты. Запускать обещанное в срок, выстраивать для этого понятные планы и чёткую коммуникацию. Выбивать команде самые удобные инструменты. Договариваться с заказчиком, придумывать как срезать углы или наоборот, сделать больше работы, принеся больше пользы.
Неклёво затаскивать людей. Не работать вместе над общим делом, а всей командой обходить неумение кого-то одного писать код или выполнять обещания — перераспределять нагрузку, какделировать несамостоятельных, выкидывать работу не потому, что неважно, а потому, что не успеваем.
Когда затаскиваешь проекты — растёшь. Учишься делать это эффективнее, чужими руками, а потом и руками тех, кто сам делает это чужими руками.
Когда затаскиваешь людей — ты просто тратишь время на то, чтобы принести результат.
Клёво затаскивать проекты. Запускать обещанное в срок, выстраивать для этого понятные планы и чёткую коммуникацию. Выбивать команде самые удобные инструменты. Договариваться с заказчиком, придумывать как срезать углы или наоборот, сделать больше работы, принеся больше пользы.
Неклёво затаскивать людей. Не работать вместе над общим делом, а всей командой обходить неумение кого-то одного писать код или выполнять обещания — перераспределять нагрузку, какделировать несамостоятельных, выкидывать работу не потому, что неважно, а потому, что не успеваем.
Когда затаскиваешь проекты — растёшь. Учишься делать это эффективнее, чужими руками, а потом и руками тех, кто сам делает это чужими руками.
Когда затаскиваешь людей — ты просто тратишь время на то, чтобы принести результат.
Два новых выступления
1) Как не превратиться из хорошего программиста в плохого менеджера: рассказываю о двух профессиональных путях — «лидерах» и «хакерах»: https://www.youtube.com/watch?v=XWs-Iwe8wuc
2) Ищем, куда девается время программистов: как при помощи анализа пользовательских сценариев можно находить места, в которых программистам неудобно: https://www.youtube.com/watch?v=rZvtwKShR7U
1) Как не превратиться из хорошего программиста в плохого менеджера: рассказываю о двух профессиональных путях — «лидерах» и «хакерах»: https://www.youtube.com/watch?v=XWs-Iwe8wuc
2) Ищем, куда девается время программистов: как при помощи анализа пользовательских сценариев можно находить места, в которых программистам неудобно: https://www.youtube.com/watch?v=rZvtwKShR7U
Кастомный воркфлоу не нужен
Я тут недавно решил поменять монитор — честно служивший 8 лет LG UltraFine поменял на Apple Studio Display. Оказалось довольно трудозатратно — поменялось очень много паттерном использования.
Старый монитор был довольно маленьким — 21“ хватало только, чтобы воспроизводить привычный экран ноутбука. Работа за ним по сути ничем не отличалась от ноута — всегда было открыто 2–3 спейса с одним окном, максимум — с двумя. На 27“ фигни входит гораздо больше, поэтому я решил заняться её организацией — вспомнил любимый линуксовый dwm и тайлинг в целом.
Оказывается в macOS есть куча инструментов, чтобы управлять тайлингом — юникс-вейный yabai, фреймворк для скриптования Hammerspoon, или Aerospace как решение всё-в-одном. Можно сделать клёвый статус-бар на SketchyBar или настроить любые хоткеи через shkd, Karabiber или BTT. Можно даже сделать всё то же самое, просто накупив программ в AppStore!
Беду с этими инструментами я осознал ближе к десятой помидорке, которую на них потратил — огромный порог входа и совершенно непрогнозируемая стоимость поддержки. Получается настолько же сложно, как какая-нибудь средненькая среда разработки, вместе с IDE, CI и таскраннером.
Правда, когда занимаешься DevEx на рабочем проекте — ты получаешь прогнозируемый выхлоп в виде того же TTM. А вот выхлоп от автоматического тайлинга я спрогнозировать не могу, хоть и проработал на нём больше 5 лет. Кажется, в итоге я сделаю гораздо больше работы, если 3 лишних минуты в день буду возить мышкой, чем если буду раз в месяц тратить по паре часов на починку фичей, которые отвалились из-за очередного обновления.
Программисты вообще любят всё настраивать — от цветов в консоли до статусов в жире. И если цвета вредят разве что зрению, то статусы и другие кастомные воркфлоу жрут вполне измеримое время. Я программист уже не настоящий (надеюсь), так что посижу на встроенном UI.
Я тут недавно решил поменять монитор — честно служивший 8 лет LG UltraFine поменял на Apple Studio Display. Оказалось довольно трудозатратно — поменялось очень много паттерном использования.
Старый монитор был довольно маленьким — 21“ хватало только, чтобы воспроизводить привычный экран ноутбука. Работа за ним по сути ничем не отличалась от ноута — всегда было открыто 2–3 спейса с одним окном, максимум — с двумя. На 27“ фигни входит гораздо больше, поэтому я решил заняться её организацией — вспомнил любимый линуксовый dwm и тайлинг в целом.
Оказывается в macOS есть куча инструментов, чтобы управлять тайлингом — юникс-вейный yabai, фреймворк для скриптования Hammerspoon, или Aerospace как решение всё-в-одном. Можно сделать клёвый статус-бар на SketchyBar или настроить любые хоткеи через shkd, Karabiber или BTT. Можно даже сделать всё то же самое, просто накупив программ в AppStore!
Беду с этими инструментами я осознал ближе к десятой помидорке, которую на них потратил — огромный порог входа и совершенно непрогнозируемая стоимость поддержки. Получается настолько же сложно, как какая-нибудь средненькая среда разработки, вместе с IDE, CI и таскраннером.
Правда, когда занимаешься DevEx на рабочем проекте — ты получаешь прогнозируемый выхлоп в виде того же TTM. А вот выхлоп от автоматического тайлинга я спрогнозировать не могу, хоть и проработал на нём больше 5 лет. Кажется, в итоге я сделаю гораздо больше работы, если 3 лишних минуты в день буду возить мышкой, чем если буду раз в месяц тратить по паре часов на починку фичей, которые отвалились из-за очередного обновления.
Программисты вообще любят всё настраивать — от цветов в консоли до статусов в жире. И если цвета вредят разве что зрению, то статусы и другие кастомные воркфлоу жрут вполне измеримое время. Я программист уже не настоящий (надеюсь), так что посижу на встроенном UI.
Стать Тимлидом
В последнее время из разных мест слышу, как тяжело менеджерам без технического бекграунда становится искать работу, связанную с управлением программистами. Думаю, это неплохо — клёво, когда руководитель приносит ценность в проект, а не просто следит, как бы чего не вышло.
Думаю, следующие в очереди на ненужность — программисты без менеджерского опыта. Когда-нибудь на собеседованиях вместо литкода начнут ковырять проактивность, рефлексивность и умение отвечать за результат — умения, которые в отличие от вращения деревьев, нужны каждый день.
Когда я в 19 году уходил из ГдеМатериала, я оставил 10 человек без руководителя. Не было даже тимлида. Очень гордился тем, как, прощаясь с командой, сказал, что каждый из них сам вполне может быть себе CTO. Хотя большой моей заслуги в этом и нет (просто ребята золотые), до сих пор идеал программиста для меня — это сотрудник, который сам себе если уж не CTO, то тимлид: сам договорится с бизнесом, поучаствует в собеседовании, а если дадут нерадивого коллегу — спокойно и ненавязчиво организует его время.
Из этого убеждения в 20 году у нас с Марьяной и появился курс «Стать Тимлидом» — мы собирали в одном месте пачку софтскиллов, нужную, чтобы выполнять работу без внешних костылей. С тех пор курс мы полностью переписали, но идея осталась прежней — отучившись 5 недель действительно можно разобраться чего не хватает, чтобы стать тимлидом, если не для крутой команды, то для себя — уж точно. Курс построен вокруг типичных лидерских вопросов: как договариваться с людьми, как быть, когда ребята не тянут, как поддерживать порядок; при этом не работая за всех круглые сутки.
Основная часть курса — это 5-недельный интенсив. За это время вы получите набор знаний, который выручит, когда нужно будет взять ответственность или провернуть что-то сложное на работе.
Смотреть программу →
Вторая, и самая важная, часть, происходит после курса — вы уходите применять знания, а сталкиваясь с проблемами, возвращаетесь в LMS. Материалы построены вокруг вопросов, с которыми рано или поздно сталкивается любой тимилд: начнёте нанимать — вернётесь к разделу про найм; получите доступ к бизнесу — перечитаете, как выстраивать с ним отношения; унаследуете хаос в процессах — перечитаете блок про управление проектами.
Стартуем 19 марта. По промокоду
В последнее время из разных мест слышу, как тяжело менеджерам без технического бекграунда становится искать работу, связанную с управлением программистами. Думаю, это неплохо — клёво, когда руководитель приносит ценность в проект, а не просто следит, как бы чего не вышло.
Думаю, следующие в очереди на ненужность — программисты без менеджерского опыта. Когда-нибудь на собеседованиях вместо литкода начнут ковырять проактивность, рефлексивность и умение отвечать за результат — умения, которые в отличие от вращения деревьев, нужны каждый день.
Когда я в 19 году уходил из ГдеМатериала, я оставил 10 человек без руководителя. Не было даже тимлида. Очень гордился тем, как, прощаясь с командой, сказал, что каждый из них сам вполне может быть себе CTO. Хотя большой моей заслуги в этом и нет (просто ребята золотые), до сих пор идеал программиста для меня — это сотрудник, который сам себе если уж не CTO, то тимлид: сам договорится с бизнесом, поучаствует в собеседовании, а если дадут нерадивого коллегу — спокойно и ненавязчиво организует его время.
Из этого убеждения в 20 году у нас с Марьяной и появился курс «Стать Тимлидом» — мы собирали в одном месте пачку софтскиллов, нужную, чтобы выполнять работу без внешних костылей. С тех пор курс мы полностью переписали, но идея осталась прежней — отучившись 5 недель действительно можно разобраться чего не хватает, чтобы стать тимлидом, если не для крутой команды, то для себя — уж точно. Курс построен вокруг типичных лидерских вопросов: как договариваться с людьми, как быть, когда ребята не тянут, как поддерживать порядок; при этом не работая за всех круглые сутки.
Основная часть курса — это 5-недельный интенсив. За это время вы получите набор знаний, который выручит, когда нужно будет взять ответственность или провернуть что-то сложное на работе.
Смотреть программу →
Вторая, и самая важная, часть, происходит после курса — вы уходите применять знания, а сталкиваясь с проблемами, возвращаетесь в LMS. Материалы построены вокруг вопросов, с которыми рано или поздно сталкивается любой тимилд: начнёте нанимать — вернётесь к разделу про найм; получите доступ к бизнесу — перечитаете, как выстраивать с ним отношения; унаследуете хаос в процессах — перечитаете блок про управление проектами.
Стартуем 19 марта. По промокоду
LEADYOURSELF действует 10% скидка до конца выходных.Где начинали — там и общайтесь
Типичная ситуация: у компании есть трекер задач, слак и ещё личная телега у сотрудников. Изобилие коммуникаций приходит к тому, что ни в одном месте нет ни одной завершённой. Заходишь в трекер и видишь, что задачу двигают уже три спринта. Пытаешься понять в чём дело — а последний раз по ней писали что-то как раз те самые три спринта назад.
Или ищешь ссылку, которую коллега давал по задаче. Вроде общались в слаке, всё обыскал и ничего не нашёл. А она была в комментах к трекеру, потому что вспомнили о ней на планировании спринта. Или наоборот, в личной телеге, потому что говорили о ней после работы.
Кароч, если не получается удалить лишние средства общения, поддерживайте хотя бы консистентность:
— Если задача стоит в трекере, старайтесь общаться там же.
— Наоборот, если начали в слаке — не обманывайте себя, что уйдёте оттуда, сделайте хотя бы удобный тредик.
— Если начали в трекере, а в процессе работы переехали куда-то ещё — дублируйте в трекер хотя бы ключевые договорённости.
Сэкономите кучу времени на поиске информации, не говоря уж о том, что перестанете выглядеть наружу как кучка молчунов.
---
Напоминаю, что идёт набор на «Стать Тимлидом», где мы рассказываем, как завоёвывать доверие у коллег и бизнеса, в том числе и такими мелкими хаками
Типичная ситуация: у компании есть трекер задач, слак и ещё личная телега у сотрудников. Изобилие коммуникаций приходит к тому, что ни в одном месте нет ни одной завершённой. Заходишь в трекер и видишь, что задачу двигают уже три спринта. Пытаешься понять в чём дело — а последний раз по ней писали что-то как раз те самые три спринта назад.
Или ищешь ссылку, которую коллега давал по задаче. Вроде общались в слаке, всё обыскал и ничего не нашёл. А она была в комментах к трекеру, потому что вспомнили о ней на планировании спринта. Или наоборот, в личной телеге, потому что говорили о ней после работы.
Кароч, если не получается удалить лишние средства общения, поддерживайте хотя бы консистентность:
— Если задача стоит в трекере, старайтесь общаться там же.
— Наоборот, если начали в слаке — не обманывайте себя, что уйдёте оттуда, сделайте хотя бы удобный тредик.
— Если начали в трекере, а в процессе работы переехали куда-то ещё — дублируйте в трекер хотя бы ключевые договорённости.
Сэкономите кучу времени на поиске информации, не говоря уж о том, что перестанете выглядеть наружу как кучка молчунов.
---
Напоминаю, что идёт набор на «Стать Тимлидом», где мы рассказываем, как завоёвывать доверие у коллег и бизнеса, в том числе и такими мелкими хаками
Дедлайны в трекере не нужны
В любом таск-трекере у задачи есть поле с дедлайном. Если его заполнить — трекер начинает напоминать о задаче: вот неделя осталась, вот уже завтра, вот уже на два дня проёбано. Иногда с дедлайнами выстраивают красивые календари: типа вчера вот эту задачу проебём, завтра вон те 10 проебём.
Не могу вспомнить ни одного случая, когда это поле приносило пользу. Зачем дедлайн программисту, если у него спринт и все задачи с одним дедлайном, либо канбан, где WIP-лимиты, либо бизнес которому надо вчера? Зачем дедлайн менеджеру, если при постановке задачи дедлайн с ним никто не согласовывает?
Получается поле есть, совершает какие-то действия, создаёт какую-то уверенность («вот же, дедлайн установили»), а пользы не приносит. Подозреваю, что это какой-то глобальный заговор владельцев таск-трекеров. А может просто таск-трекер без дедлайна в задачах никто не купит — это ж несерьёзно как-то.
Переубедите меня?
В любом таск-трекере у задачи есть поле с дедлайном. Если его заполнить — трекер начинает напоминать о задаче: вот неделя осталась, вот уже завтра, вот уже на два дня проёбано. Иногда с дедлайнами выстраивают красивые календари: типа вчера вот эту задачу проебём, завтра вон те 10 проебём.
Не могу вспомнить ни одного случая, когда это поле приносило пользу. Зачем дедлайн программисту, если у него спринт и все задачи с одним дедлайном, либо канбан, где WIP-лимиты, либо бизнес которому надо вчера? Зачем дедлайн менеджеру, если при постановке задачи дедлайн с ним никто не согласовывает?
Получается поле есть, совершает какие-то действия, создаёт какую-то уверенность («вот же, дедлайн установили»), а пользы не приносит. Подозреваю, что это какой-то глобальный заговор владельцев таск-трекеров. А может просто таск-трекер без дедлайна в задачах никто не купит — это ж несерьёзно как-то.
Переубедите меня?
Контроль — это костыль
Этот пост — реклама курса «Стать Тимлидом». Как всегда — полезная: прочитайте, если как и я, боитесь ошибок и лечите это гипер-контролем
Тут Марьяна рассказывает, как на горнолыжном склоне училась не бояться собственных ошибок. Это действительно очень полезный навык: страх ошибки на работе может парализовать так же, как и на склоне — так, что с места не сдвинешься.
У меня, при переходе в управление, страх ошибок был немного другим (хотя и синдром самозванца тоже приходил). Дело в том, что на склоне, как и в программировании, всё довольно бинарно: упал — ошибка, доехал до конца — молодец. А в управлении от этой бинарности не остаётся и следа: о том, что ты испортил отношения с бизнесом начинаешь понимать через месяц после первой встречи, на которой всё пошло не так. Что команда без тебя начала говнокодить, можешь узнать только когда бизнес-задачи уже встанут колом. Обратная связь если и приходит, то очень медленно.
Сначала пытался справиться со страхом очевидными способами — уведомления на почту, выдуманные KPI, напоминалки, чтобы проверить, что эти уведомления пришли. В общем пытался всё контролировать. Как можете догадаться — довольно безрезультатно.
В какой-то момент я всё-таки дошёл, что контролировать я могу исключительно себя. Вряд ли я заставлю бизнес на себя не обижаться — зато если сфокусируюсь на своём собственном поведении, начну их слушать, превращать проблемы в таски и помогать команде эти таски закрыть, то скорее всего всё будет хорошо. Кароче, ушёл качать скиллы.
Помогло — вернулось чувство контроля, появились силы на профессиональный рост. Когда вырос — перенёс этот подход на предпринимательство, где определённости ещё меньше: опираюсь на скиллы и качаю те, которых не хватает.
———
Если тоже замучил страх ошибок — приходите к нам на «Стать Тимлидом». В безопасной среде прокачиваем ключевые навыки, нужные ответственным программистам — работу с командой, найм, управление проектами и умение общаться с бизнесом.
Этот пост — реклама курса «Стать Тимлидом». Как всегда — полезная: прочитайте, если как и я, боитесь ошибок и лечите это гипер-контролем
Тут Марьяна рассказывает, как на горнолыжном склоне училась не бояться собственных ошибок. Это действительно очень полезный навык: страх ошибки на работе может парализовать так же, как и на склоне — так, что с места не сдвинешься.
У меня, при переходе в управление, страх ошибок был немного другим (хотя и синдром самозванца тоже приходил). Дело в том, что на склоне, как и в программировании, всё довольно бинарно: упал — ошибка, доехал до конца — молодец. А в управлении от этой бинарности не остаётся и следа: о том, что ты испортил отношения с бизнесом начинаешь понимать через месяц после первой встречи, на которой всё пошло не так. Что команда без тебя начала говнокодить, можешь узнать только когда бизнес-задачи уже встанут колом. Обратная связь если и приходит, то очень медленно.
Сначала пытался справиться со страхом очевидными способами — уведомления на почту, выдуманные KPI, напоминалки, чтобы проверить, что эти уведомления пришли. В общем пытался всё контролировать. Как можете догадаться — довольно безрезультатно.
В какой-то момент я всё-таки дошёл, что контролировать я могу исключительно себя. Вряд ли я заставлю бизнес на себя не обижаться — зато если сфокусируюсь на своём собственном поведении, начну их слушать, превращать проблемы в таски и помогать команде эти таски закрыть, то скорее всего всё будет хорошо. Кароче, ушёл качать скиллы.
Помогло — вернулось чувство контроля, появились силы на профессиональный рост. Когда вырос — перенёс этот подход на предпринимательство, где определённости ещё меньше: опираюсь на скиллы и качаю те, которых не хватает.
———
Если тоже замучил страх ошибок — приходите к нам на «Стать Тимлидом». В безопасной среде прокачиваем ключевые навыки, нужные ответственным программистам — работу с командой, найм, управление проектами и умение общаться с бизнесом.
Не сливаться с проблем
Постоянно вижу как люди (включая меня) сливаются с жизненных проблем. Живут с лишним весом, ходят на нелюбимую работу, платят ипотеку по 70% дохода, поддерживают дисфункциональные отношения. Сливаться — вполне человеческий механизм защиты, развитый с древних времён: вряд ли можно было бы спокойно прожить, переживая о количество тигров за дверью пещеры.
Сливаются по-разному — кто-то отвлекается на хобби, кто-то прибегает к компьютерным играм, алкоголю или наркотикам. Но есть место, где с жизненных проблем сливаться не получается — это предпринимательство. Чтобы бизнес рос, предприниматель, наоборот, бегает в постоянном поиске — а с чего бы мне не слиться сегодня? Какую неудобную проблему решить? В венчурных фондах есть даже специальные люди, задача которых — тыкать начинающих CEO: а что у тебя с продажами? Как там продакт-маркет фит, сколько гипотез проверил на этой неделе? Как думаешь уменьшать бёрн-рейт? А с отваливающимися клиентами как работаешь?
Просто отключать механизм сливания — нельзя. Начнёшь слишком сильно тревожиться — через два года сгоришь и пойдёшь работать моряком, водителем троллейбуса, или ещё кем поспокойнее. Приходится подбирать более здоровые механизмы — стратсессии, фреймворки для анализа рисков, те самые трекеры из фондов.
У каждого бизнеса и каждого предпринимателя эти механизмы свои. У меня последнее время остался самый тупой — это беклог: сажусь анализировать риски и по итогам составляю беклог для сотрудников, или хотя бы для собственного Things. Проснулся в 5 утра с тревогой про заблокированные счета — идёшь писать беклог. Переживаешь за короткий runway — ищешь способы ускорить поток денег. Не хватает людей — проверяешь, что там с наймом у команды.
А какие у вас механизмы?
———
Первый шаг к предпринимательсту у программистов — это тимлидство. «Стать Тимлидом» стартует уже в следующую среду. На курсе даём скиллы, нужные всем, кто руководит разработкой.
Постоянно вижу как люди (включая меня) сливаются с жизненных проблем. Живут с лишним весом, ходят на нелюбимую работу, платят ипотеку по 70% дохода, поддерживают дисфункциональные отношения. Сливаться — вполне человеческий механизм защиты, развитый с древних времён: вряд ли можно было бы спокойно прожить, переживая о количество тигров за дверью пещеры.
Сливаются по-разному — кто-то отвлекается на хобби, кто-то прибегает к компьютерным играм, алкоголю или наркотикам. Но есть место, где с жизненных проблем сливаться не получается — это предпринимательство. Чтобы бизнес рос, предприниматель, наоборот, бегает в постоянном поиске — а с чего бы мне не слиться сегодня? Какую неудобную проблему решить? В венчурных фондах есть даже специальные люди, задача которых — тыкать начинающих CEO: а что у тебя с продажами? Как там продакт-маркет фит, сколько гипотез проверил на этой неделе? Как думаешь уменьшать бёрн-рейт? А с отваливающимися клиентами как работаешь?
Просто отключать механизм сливания — нельзя. Начнёшь слишком сильно тревожиться — через два года сгоришь и пойдёшь работать моряком, водителем троллейбуса, или ещё кем поспокойнее. Приходится подбирать более здоровые механизмы — стратсессии, фреймворки для анализа рисков, те самые трекеры из фондов.
У каждого бизнеса и каждого предпринимателя эти механизмы свои. У меня последнее время остался самый тупой — это беклог: сажусь анализировать риски и по итогам составляю беклог для сотрудников, или хотя бы для собственного Things. Проснулся в 5 утра с тревогой про заблокированные счета — идёшь писать беклог. Переживаешь за короткий runway — ищешь способы ускорить поток денег. Не хватает людей — проверяешь, что там с наймом у команды.
А какие у вас механизмы?
———
Первый шаг к предпринимательсту у программистов — это тимлидство. «Стать Тимлидом» стартует уже в следующую среду. На курсе даём скиллы, нужные всем, кто руководит разработкой.
В зерокоде появились легаси-инструменты
4 года назад (ужас!) писал, что считаю зерокод техдолгом с самого момента создания. За 4 года ситуация не изменилась — разбираться с созданным другим человеком (или самим собой полгода назад назад) зерокодом всё так же сложно.
Недавно убивал пару внутренних сервисов в пользу зерокода и поржал, осознав, что в индустрии появились целые легаси-фреймворки. К примеру zapier. Штука, которая на старте казалась чудом, сейчас выглядит как тормозной захламлённый интерфейс из двухтысячных, который постоянно пытается мне что-то продать, показывая людей из фотостоков (не AI! фотостоки!). Документация — говно (так и не понял, как нормально шарить креденшелы между проектами). AI-зеркодер лучше бы даже не выкладывали вообще — за 30 минут не смог из него извлечь ничего осмысленного.
И это бывший лидер индустрии! Получается нехилая такая скорость устаревания — совсем чуть-чуть дольше, чем средний JS-фреймворк.
Я в итоге остановился на n8n (наверное есть и лучше), но вот что подумал — а сколько же людей вынуждены до сих пор работать в zapier? Интероперабельности же нет by design — если назерокодил что-то в говноинтерфейсе — в нём и сиди всю жизнь, пока не перепишешь на новый тул. Сочувствую зерокодерам.
4 года назад (ужас!) писал, что считаю зерокод техдолгом с самого момента создания. За 4 года ситуация не изменилась — разбираться с созданным другим человеком (или самим собой полгода назад назад) зерокодом всё так же сложно.
Недавно убивал пару внутренних сервисов в пользу зерокода и поржал, осознав, что в индустрии появились целые легаси-фреймворки. К примеру zapier. Штука, которая на старте казалась чудом, сейчас выглядит как тормозной захламлённый интерфейс из двухтысячных, который постоянно пытается мне что-то продать, показывая людей из фотостоков (не AI! фотостоки!). Документация — говно (так и не понял, как нормально шарить креденшелы между проектами). AI-зеркодер лучше бы даже не выкладывали вообще — за 30 минут не смог из него извлечь ничего осмысленного.
И это бывший лидер индустрии! Получается нехилая такая скорость устаревания — совсем чуть-чуть дольше, чем средний JS-фреймворк.
Я в итоге остановился на n8n (наверное есть и лучше), но вот что подумал — а сколько же людей вынуждены до сих пор работать в zapier? Интероперабельности же нет by design — если назерокодил что-то в говноинтерфейсе — в нём и сиди всю жизнь, пока не перепишешь на новый тул. Сочувствую зерокодерам.
Стать Тимлидом 3 — ласт-колл
Напоминаю, что завтра стартует третий поток «Стать Тимлидом». Если вы купили тариф с обратной связью, приходите на встречу-знакомство в 16:00 MSK.
«Стать Тимлидом» учит решать задачи, которые встают перед каждым самостоятельным программистом (и не обязательно тимлидом):
— Как не просрать (или починить) отношения с бизнесом?
— Как понять, что они хотят, если они каждый раз хотят нового?
— Что делать, когда коллеги не тянут, а в команде бардак?
— Как отличить хороших программистов от плохих
— Где найти время на развитие, когда вокруг пожар?
Оплатить от работодателя успеете (если напишете прямо сейчас), или можно оплатить картой любого банка мира или в рассрочку. Чтобы компенсировать затраты на работе — напишите в сапорт, дадим полный комплект документов. Тем кто в РФ — поможем с налоговым вычетом.
Напоминаю, что завтра стартует третий поток «Стать Тимлидом». Если вы купили тариф с обратной связью, приходите на встречу-знакомство в 16:00 MSK.
«Стать Тимлидом» учит решать задачи, которые встают перед каждым самостоятельным программистом (и не обязательно тимлидом):
— Как не просрать (или починить) отношения с бизнесом?
— Как понять, что они хотят, если они каждый раз хотят нового?
— Что делать, когда коллеги не тянут, а в команде бардак?
— Как отличить хороших программистов от плохих
— Где найти время на развитие, когда вокруг пожар?
Оплатить от работодателя успеете (если напишете прямо сейчас), или можно оплатить картой любого банка мира или в рассрочку. Чтобы компенсировать затраты на работе — напишите в сапорт, дадим полный комплект документов. Тем кто в РФ — поможем с налоговым вычетом.
Полюбил вайб-кодинг
Я тут опять потихоньку пишу код и недавно заценил агентский режим, который стал появляться в LLM-ассистентах.
Вообще у меня с AI в программировании всё с самого начала складывалось плохо — уж слишком много внимания они требовали. Подсказки в коде выглядели впечатляюще, но сколько бы я ни давал им шансов, в конце они оказывались просто спамом. Чтобы найти в них что-то полезное, приходилось потратить больше внимания, чем ушло бы на то, чтобы самому это полезное написать.
Разговоры тоже как-то не зашли — после того, как минут 30 я дебажил простой тест, в котором LLM просто использовал неправильное название свойства (что-то на уровне title вместо name, сразу и не раглядишь).
Ну и совсем я забил, когда весь мой, с таким трудом нагороженный, сетап начал постоянно разваливаться, просто потому что слишком уж много людей пытаются принести пользу человечеству и коммитят говно прямо в мастер моих плагинов.
Недавно, наконец-то, смог получить МНОГО пользы от AI — установил себе Claude Code CLI. Кайф в том, что не нужно никаких интеграций — он просто живёт в соседнем терминале и делает всё, что я попрошу. Такой усердный джун, который к тому же, внимательнее меня читает документацию: и тесты напишет, и кодмод любой сложности проведёт, и выжимку из документации сделает. Причём код, который он пишет, реально похож на мой!
Поручаю ему мелкие задачи, которые тяжело делать без IDE — переписать код и тесты после рефакторинга класса, разнести код по модулям/функциям. Самый кайф испытал, когда недавно попросил его написать рекурсивный SQL-запрос для обхода дерева, прямо в Django ORM. Думал долго, взял с меня полтора доллара, но таки написал! Я бы такое делал часа два, в лучшем случае (как любой нормальный бекендер, я в SQL не умею).
Кажется, агентский режим — лучшее, что случилось с AI-ассистентами в программировании.
Я тут опять потихоньку пишу код и недавно заценил агентский режим, который стал появляться в LLM-ассистентах.
Вообще у меня с AI в программировании всё с самого начала складывалось плохо — уж слишком много внимания они требовали. Подсказки в коде выглядели впечатляюще, но сколько бы я ни давал им шансов, в конце они оказывались просто спамом. Чтобы найти в них что-то полезное, приходилось потратить больше внимания, чем ушло бы на то, чтобы самому это полезное написать.
Разговоры тоже как-то не зашли — после того, как минут 30 я дебажил простой тест, в котором LLM просто использовал неправильное название свойства (что-то на уровне title вместо name, сразу и не раглядишь).
Ну и совсем я забил, когда весь мой, с таким трудом нагороженный, сетап начал постоянно разваливаться, просто потому что слишком уж много людей пытаются принести пользу человечеству и коммитят говно прямо в мастер моих плагинов.
Недавно, наконец-то, смог получить МНОГО пользы от AI — установил себе Claude Code CLI. Кайф в том, что не нужно никаких интеграций — он просто живёт в соседнем терминале и делает всё, что я попрошу. Такой усердный джун, который к тому же, внимательнее меня читает документацию: и тесты напишет, и кодмод любой сложности проведёт, и выжимку из документации сделает. Причём код, который он пишет, реально похож на мой!
Поручаю ему мелкие задачи, которые тяжело делать без IDE — переписать код и тесты после рефакторинга класса, разнести код по модулям/функциям. Самый кайф испытал, когда недавно попросил его написать рекурсивный SQL-запрос для обхода дерева, прямо в Django ORM. Думал долго, взял с меня полтора доллара, но таки написал! Я бы такое делал часа два, в лучшем случае (как любой нормальный бекендер, я в SQL не умею).
Кажется, агентский режим — лучшее, что случилось с AI-ассистентами в программировании.
#вопрос Работаю менеджером в аутсорсе (не программисты), и чувствую себя передастом. Проекты планируются централизовано, а я просто хожу на встречи с командой и клиентом и записываю, что происходит. Как расти?
Ваша роль сейчас — посредник: как риэлтор на рынке недвижимости, или дилер на авторынке. На посредническом рынке растут через наращивание ценности. Риэлтор учится анализировать потребности клиента и продавца, быстро искать подходящую недвижимость (и подходящих покупателей), снимать юиридческие риски. Автодилер предлагает программы рассрочки и трейд-ина, не забывая при этом вовремя платить производителю, настраивает гарантийное обслуживание, строит новые центры поближе к покупателю.
Оба посредника работают над тем, чтобы облегчить жизнь всем участникам процесса: хороший риэлтор работает для обоих сторон сделки, хороший дилер — для автозавода и для покупателя.
Вы — посредник между клиентом и командой. Позадавайте вопросы: как вы можете сделать жизнь команды легче? А жизнь клиента?
Допустим вы найдёте, что клиента беспокоит, что ему приходится объяснять свой бизнес-контекст каждому новому участнику команды. Почему бы вам не забрать эту задачу на себя? Или команду беспокоит, что клиент не знает, что хочет, и каждую неделю меняет планы. Почему бы не разобраться в том, почему это происходит, и не помочь клиенту выстроить более долгосрочное планирование? Ваших руководителей, которые планируют проекты, наверняка беспокоит стабильный кешфлоу. Почему бы не сфокусироваться на стабильности платежей, выстраивая такие отношения с клиентом, где он сам первый рвётся скинуть вам 100%-предоплату?
Увеличите ценность — получите и профессиональный рост в процессе и карьерный рост в результате.
P.S. Присылайте любую рабочую или личную ситуацию на [email protected] — разберём и придумаем, что делать. Ответ (анонимно) опубликуем здесь.
Ваша роль сейчас — посредник: как риэлтор на рынке недвижимости, или дилер на авторынке. На посредническом рынке растут через наращивание ценности. Риэлтор учится анализировать потребности клиента и продавца, быстро искать подходящую недвижимость (и подходящих покупателей), снимать юиридческие риски. Автодилер предлагает программы рассрочки и трейд-ина, не забывая при этом вовремя платить производителю, настраивает гарантийное обслуживание, строит новые центры поближе к покупателю.
Оба посредника работают над тем, чтобы облегчить жизнь всем участникам процесса: хороший риэлтор работает для обоих сторон сделки, хороший дилер — для автозавода и для покупателя.
Вы — посредник между клиентом и командой. Позадавайте вопросы: как вы можете сделать жизнь команды легче? А жизнь клиента?
Допустим вы найдёте, что клиента беспокоит, что ему приходится объяснять свой бизнес-контекст каждому новому участнику команды. Почему бы вам не забрать эту задачу на себя? Или команду беспокоит, что клиент не знает, что хочет, и каждую неделю меняет планы. Почему бы не разобраться в том, почему это происходит, и не помочь клиенту выстроить более долгосрочное планирование? Ваших руководителей, которые планируют проекты, наверняка беспокоит стабильный кешфлоу. Почему бы не сфокусироваться на стабильности платежей, выстраивая такие отношения с клиентом, где он сам первый рвётся скинуть вам 100%-предоплату?
Увеличите ценность — получите и профессиональный рост в процессе и карьерный рост в результате.
P.S. Присылайте любую рабочую или личную ситуацию на [email protected] — разберём и придумаем, что делать. Ответ (анонимно) опубликуем здесь.
Шаблон 1:1
Мы c Марьяной пока готовились к новому потоку «Стать Тимлидом» (запрыгнуть уже не получится), выделили важную штуку, на которую многие тимлиды забивают — 1:1.
Кто-то попробовал пару раз, получилось неловко и забил. Кто-то — даже официально: типа нет смысла тратить силы на эти пустые вопросы, надо работу работать.
Если вы из таких — дайте ещё один шанс встречам 1:1. Это — важная точка роста. Для вас — обратная связь о команде, компании и лично вас. Для коллеги — забота и место, где можно спокойно поднять проблемы, которые HR-ам нести вроде рано.
Посмотрите шаблон 1:1, который мы сделали специально для тех, кто не знает как начать. Тем, кто хочет пополнить свой инструментарий — тоже поможет.
Мы c Марьяной пока готовились к новому потоку «Стать Тимлидом» (запрыгнуть уже не получится), выделили важную штуку, на которую многие тимлиды забивают — 1:1.
Кто-то попробовал пару раз, получилось неловко и забил. Кто-то — даже официально: типа нет смысла тратить силы на эти пустые вопросы, надо работу работать.
Если вы из таких — дайте ещё один шанс встречам 1:1. Это — важная точка роста. Для вас — обратная связь о команде, компании и лично вас. Для коллеги — забота и место, где можно спокойно поднять проблемы, которые HR-ам нести вроде рано.
Посмотрите шаблон 1:1, который мы сделали специально для тех, кто не знает как начать. Тем, кто хочет пополнить свой инструментарий — тоже поможет.