Нечестное преимущество

Когда-то читал анкету одного венчурного фонда, и там был хороший вопрос — «опишите, какое у вас есть нечестное преимущество перед конкурентами». То есть почему у вас получится, а у них нет. Слово «нечестное» резануло слух — как это нечестное? Это ж бизнес, а не мошенничество. А потом я как понял.

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

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

Пример грустного и сложного бизнеса — пункт выдачи WB/Ozon. Открываешь, и попадаешь в рабство: следишь, чтобы сотрудники приходили вовремя, ищешь замену уволенным, борешься со всякими мутными схемами, разбираешься в постоянно обновляемых требованиях и штрафах сюзерена. Получается усложнённая форма самозанятости. Может быть и выгодная (не знаком с экономикой), но явно не масштабируемая. Конечно можно по-школьному: усердно поработать, и в итоге получить хороший пункт выдачи, который знают все в округе. Но это будет всего лишь пункт выдачи. Богатством\успехом, вопреки нарративам, это не пахнет. На квартиру внутри МКАД точно не накопишь.

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

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

Ищем авторов в Школу Сильных Программистов

Люблю профессионалов. Вот говоришь с человеком и понимаешь, что у него всё хорошо — и есть чему поучиться, и рассказывает интересно, и опыт крутой. Но вот никто не учится, кроме разве что 2–3 коллег, которым повезло быть рядом. Школу я когда-то начал строить именно из этого: хотелось делиться людьми, чьими знаниями я восхищаюсь.

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

К вашим знаниями мы добавим отработанные механизмы обучения взрослых, которые обеспечивают высокую доходимость (на текущем потоке «Стать Тимлидом» домашку после трёх недель делает ~70% учеников) и супер-лояльную аудиторию.

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

В Школе два трека — хардовый и софтовый. Софтовый трек помогает разработчикам становиться зрелыми менеджерами. В хардовом треке у нас есть семейство архитектурных курсов с Антоном и питоний курс с Никитой Соболевым. У нас немного продуктов, но над каждым мы работаем очень крафтово — продумываем образовательные механики, допиливаем LMS и уделяем много времени тому, чтобы сделать сложное понятным.

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

Точно НЕ хотим: AI, крипту и другие хайповые истории: нам важно, чтобы знания были полезными и через несколько лет.

Напишите пару слов о себе и своей любимой области знаний на fedor@tough-dev.school. Если из вашего рассказа поймём, что нам интересно — ответим.

Шаблон 1:1

Мы c Марьяной пока готовились к новому потоку «Стать Тимлидом» (запрыгнуть уже не получится), выделили важную штуку, на которую многие тимлиды забивают — 1:1.

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

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

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

#вопрос Работаю менеджером в аутсорсе (не программисты), и чувствую себя передастом. Проекты планируются централизовано, а я просто хожу на встречи с командой и клиентом и записываю, что происходит. Как расти?

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

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

Вы — посредник между клиентом и командой. Позадавайте вопросы: как вы можете сделать жизнь команды легче? А жизнь клиента?

Допустим вы найдёте, что клиента беспокоит, что ему приходится объяснять свой бизнес-контекст каждому новому участнику команды. Почему бы вам не забрать эту задачу на себя? Или команду беспокоит, что клиент не знает, что хочет, и каждую неделю меняет планы. Почему бы не разобраться в том, почему это происходит, и не помочь клиенту выстроить более долгосрочное планирование? Ваших руководителей, которые планируют проекты, наверняка беспокоит стабильный кешфлоу. Почему бы не сфокусироваться на стабильности платежей, выстраивая такие отношения с клиентом, где он сам первый рвётся скинуть вам 100%-предоплату?

Увеличите ценность — получите и профессиональный рост в процессе и карьерный рост в результате.

P.S. Присылайте любую рабочую или личную ситуацию на fborshev@pm.me — разберём и придумаем, что делать. Ответ (анонимно) опубликуем здесь.

Полюбил вайб-кодинг

Я тут опять потихоньку пишу код и недавно заценил агентский режим, который стал появляться в LLM-ассистентах.

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

Разговоры тоже как-то не зашли — после того, как минут 30 я дебажил простой тест, в котором LLM просто использовал неправильное название свойства (что-то на уровне title вместо name, сразу и не раглядишь).

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

Недавно, наконец-то, смог получить МНОГО пользы от AI — установил себе Claude Code CLI. Кайф в том, что не нужно никаких интеграций — он просто живёт в соседнем терминале и делает всё, что я попрошу. Такой усердный джун, который к тому же, внимательнее меня читает документацию: и тесты напишет, и кодмод любой сложности проведёт, и выжимку из документации сделает. Причём код, который он пишет, реально похож на мой!

Поручаю ему мелкие задачи, которые тяжело делать без IDE — переписать код и тесты после рефакторинга класса, разнести код по модулям/функциям. Самый кайф испытал, когда недавно попросил его написать рекурсивный SQL-запрос для обхода дерева, прямо в Django ORM. Думал долго, взял с меня полтора доллара, но таки написал! Я бы такое делал часа два, в лучшем случае (как любой нормальный бекендер, я в SQL не умею).

Кажется, агентский режим — лучшее, что случилось с AI-ассистентами в программировании.

Стать Тимлидом 3 — ласт-колл

Напоминаю, что завтра стартует третий поток «Стать Тимлидом». Если вы купили тариф с обратной связью, приходите на встречу-знакомство в 16:00 MSK.

«Стать Тимлидом» учит решать задачи, которые встают перед каждым самостоятельным программистом (и не обязательно тимлидом):
— Как не просрать (или починить) отношения с бизнесом?
— Как понять, что они хотят, если они каждый раз хотят нового?
— Что делать, когда коллеги не тянут, а в команде бардак?
— Как отличить хороших программистов от плохих
— Где найти время на развитие, когда вокруг пожар?

Оплатить от работодателя успеете (если напишете прямо сейчас), или можно оплатить картой любого банка мира или в рассрочку. Чтобы компенсировать затраты на работе — напишите в сапорт, дадим полный комплект документов. Тем кто в РФ — поможем с налоговым вычетом.

В зерокоде появились легаси-инструменты

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

Недавно убивал пару внутренних сервисов в пользу зерокода и поржал, осознав, что в индустрии появились целые легаси-фреймворки. К примеру zapier. Штука, которая на старте казалась чудом, сейчас выглядит как тормозной захламлённый интерфейс из двухтысячных, который постоянно пытается мне что-то продать, показывая людей из фотостоков (не AI! фотостоки!). Документация — говно (так и не понял, как нормально шарить креденшелы между проектами). AI-зеркодер лучше бы даже не выкладывали вообще — за 30 минут не смог из него извлечь ничего осмысленного.

И это бывший лидер индустрии! Получается нехилая такая скорость устаревания — совсем чуть-чуть дольше, чем средний JS-фреймворк.

Я в итоге остановился на n8n (наверное есть и лучше), но вот что подумал — а сколько же людей вынуждены до сих пор работать в zapier? Интероперабельности же нет by design — если назерокодил что-то в говноинтерфейсе — в нём и сиди всю жизнь, пока не перепишешь на новый тул. Сочувствую зерокодерам.

Не сливаться с проблем

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

Сливаются по-разному — кто-то отвлекается на хобби, кто-то прибегает к компьютерным играм, алкоголю или наркотикам. Но есть место, где с жизненных проблем сливаться не получается — это предпринимательство. Чтобы бизнес рос, предприниматель, наоборот, бегает в постоянном поиске — а с чего бы мне не слиться сегодня? Какую неудобную проблему решить? В венчурных фондах есть даже специальные люди, задача которых — тыкать начинающих CEO: а что у тебя с продажами? Как там продакт-маркет фит, сколько гипотез проверил на этой неделе? Как думаешь уменьшать бёрн-рейт? А с отваливающимися клиентами как работаешь?

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

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

А какие у вас механизмы?

———
Первый шаг к предпринимательсту у программистов — это тимлидство. «Стать Тимлидом» стартует уже в следующую среду. На курсе даём скиллы, нужные всем, кто руководит разработкой.

Контроль — это костыль

Этот пост — реклама курса «Стать Тимлидом». Как всегда — полезная: прочитайте, если как и я, боитесь ошибок и лечите это гипер-контролем

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

У меня, при переходе в управление, страх ошибок был немного другим (хотя и синдром самозванца тоже приходил). Дело в том, что на склоне, как и в программировании, всё довольно бинарно: упал — ошибка, доехал до конца — молодец. А в управлении от этой бинарности не остаётся и следа: о том, что ты испортил отношения с бизнесом начинаешь понимать через месяц после первой встречи, на которой всё пошло не так. Что команда без тебя начала говнокодить, можешь узнать только когда бизнес-задачи уже встанут колом. Обратная связь если и приходит, то очень медленно.

Сначала пытался справиться со страхом очевидными способами — уведомления на почту, выдуманные KPI, напоминалки, чтобы проверить, что эти уведомления пришли. В общем пытался всё контролировать. Как можете догадаться — довольно безрезультатно.

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

Помогло — вернулось чувство контроля, появились силы на профессиональный рост. Когда вырос — перенёс этот подход на предпринимательство, где определённости ещё меньше: опираюсь на скиллы и качаю те, которых не хватает.

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

Дедлайны в трекере не нужны

В любом таск-трекере у задачи есть поле с дедлайном. Если его заполнить — трекер начинает напоминать о задаче: вот неделя осталась, вот уже завтра, вот уже на два дня проёбано. Иногда с дедлайнами выстраивают красивые календари: типа вчера вот эту задачу проебём, завтра вон те 10 проебём.

Не могу вспомнить ни одного случая, когда это поле приносило пользу. Зачем дедлайн программисту, если у него спринт и все задачи с одним дедлайном, либо канбан, где WIP-лимиты, либо бизнес которому надо вчера? Зачем дедлайн менеджеру, если при постановке задачи дедлайн с ним никто не согласовывает?

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

Переубедите меня?

Где начинали — там и общайтесь

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

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

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

Сэкономите кучу времени на поиске информации, не говоря уж о том, что перестанете выглядеть наружу как кучка молчунов.

---
Напоминаю, что идёт набор на «Стать Тимлидом», где мы рассказываем, как завоёвывать доверие у коллег и бизнеса, в том числе и такими мелкими хаками

Стать Тимлидом

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

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

Когда я в 19 году уходил из ГдеМатериала, я оставил 10 человек без руководителя. Не было даже тимлида. Очень гордился тем, как, прощаясь с командой, сказал, что каждый из них сам вполне может быть себе CTO. Хотя большой моей заслуги в этом и нет (просто ребята золотые), до сих пор идеал программиста для меня — это сотрудник, который сам себе если уж не CTO, то тимлид: сам договорится с бизнесом, поучаствует в собеседовании, а если дадут нерадивого коллегу — спокойно и ненавязчиво организует его время.

Из этого убеждения в 20 году у нас с Марьяной и появился курс «Стать Тимлидом» — мы собирали в одном месте пачку софтскиллов, нужную, чтобы выполнять работу без внешних костылей. С тех пор курс мы полностью переписали, но идея осталась прежней — отучившись 5 недель действительно можно разобраться чего не хватает, чтобы стать тимлидом, если не для крутой команды, то для себя — уж точно. Курс построен вокруг типичных лидерских вопросов: как договариваться с людьми, как быть, когда ребята не тянут, как поддерживать порядок; при этом не работая за всех круглые сутки.

Основная часть курса — это 5-недельный интенсив. За это время вы получите набор знаний, который выручит, когда нужно будет взять ответственность или провернуть что-то сложное на работе.

Смотреть программу →

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

Стартуем 19 марта. По промокоду LEADYOURSELF действует 10% скидка до конца выходных.

Кастомный воркфлоу не нужен

Я тут недавно решил поменять монитор — честно служивший 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.

Два новых выступления

1) Как не превратиться из хорошего программиста в плохого менеджера: рассказываю о двух профессиональных путях — «лидерах» и «хакерах»: https://www.youtube.com/watch?v=XWs-Iwe8wuc

2) Ищем, куда девается время программистов: как при помощи анализа пользовательских сценариев можно находить места, в которых программистам неудобно: https://www.youtube.com/watch?v=rZvtwKShR7U

Затаскивать проекты, а не людей

Клёво затаскивать проекты. Запускать обещанное в срок, выстраивать для этого понятные планы и чёткую коммуникацию. Выбивать команде самые удобные инструменты. Договариваться с заказчиком, придумывать как срезать углы или наоборот, сделать больше работы, принеся больше пользы.

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

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

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

Императивный и декларативный бизнес

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

Своим первым отделом я начал руководить, страшно подумать, 15 лет назад. И первым моим шагом, конечно же, была разработка регламентов. Даже не задумывался, зачем (KPI мне никто не ставил) — просто делал, потому что так принято. И пофиг, что в отделе 5 человек, а во всей компании — 15: я начал писать страшные бумаги, что-то вроде «если приходит срочная задача, то постановщик должен лично подойти к исполнителю». Довольно похоже на первый код, который пишут джуны: «if user.has_access_to_action() then perform_action()»

У этих регламентов есть одна общая проблема с джуновым кодом — все случаи жизни if-ами не покроешь. Если попытаешься — выйдет длинная портянка, которую ни один нормальный человек читать не будет. Чтобы решать проблемы в императивном коде, давно придумали целый арсенал — от дяди Боба до YAML.

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

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

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

В разработке (думаю и в любой другой творческой работе) действует только штучный подход. Чтобы люди хорошо закрывали клиентские задачи, им нужна удобная среда — доверие, нормальные инженерные практики, минимальная коммуникация, свободное время, много автоматизации, а в идеале ещё и мало контроля. Создавая такую среду в аутсорсе, мы делаем то самое тюнинг-ателье, которое сегодня обшивает потолок майбаха алькантарой, а завтра вкорячивает 37” колеса на джип.

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

---

Собственно курс о среде для штучного производства называется «Без Ерунды», состоит из четырёх писем — о доверии, инженерных процессах, внимании и работе с клиентом. Если вы покупали курс раньше — все обновления уже у вас в LMS. Если сомневаетесь — гляньте отзывы из вложения

Готовые комплекты вещей

Самое смешное бытовое открытие прошлого года — это готовые комплекты вещей. К примеру, комплект проводов и зарядок для поездки. Раньше нужно было подумать, какие устройства я с собой беру (нужен ли lightning? а зарядка для часов?), посмотреть, отыскать всё это, проверить чтобы все провода были совместимы со всеми устройствами, а после поездки — вернуть на место. Сейчас достаточно взять маленькую сумку с зарядками, которая всегда собрана.

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

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