Господин Архитектор

Об внедрение Скрама Работать некому, в стране одни коучи. Вчера я видел вакансию OKR коуча. То есть буквально - человек, который никак не отвечает за результат, будет помогать командам понять, чего они хотят в эту итерацию. Очень красиво, правда? Подводя к вопросу, расскажу, что я попытался применить принципы системной инженерии к Скраму, и результаты очень любопытные. Заодно стало понятно, за что именно отвечает скрам-тренер, и каким таким единым чиселком KPI следует измерять работу целого ИТ-департамента. Но об этом я напишу позже, а сейчас я расскажу внешнюю точку зрения. Вопрос в том, почему внедрения аджайла, Скрама и так далее находятся в состоянии "начали, но не закончилось". Если вы посмотрите в конкретную ситуацию, которые я видел не раз, вы обнаружите одну или несколько причин из списка: 1. Это не выгодно скрам-тренеру. Ну, потому что его очень быстро попросят на выход, то есть -- прямо закрутят финансовый поток в обмен на "кейс" какой-то степени успешности. Несколько успешных кейсов, разумеется, нужны для презентации, а дальше они становятся бесполезны. 2. Это не выгодно менеджменту. Потому что задача Скрама - устранить препятствия на пути работы команды. И очень быстро становится понятно, что главным препятствием на пути работы команды становится непонимание среднего менеджмента, как вести компанию дальше - видение есть, стратегия, может быть, есть, но средний менеджмент в недоумении, как это превратить в планы. Выражаясь другими словами, внедренный Скрам быстро перемещает бутылочное горлышко на сторону бизнеса. Если раньше можно было ссылаться на священную, но очень упрямую корову ИТ, то теперь уже нельзя, ИТ готов к работе и предсказуем (почитайте: https://habr.com/ru/post/567416/). Еще по этому вопросу можно почитать саркастическую "Черную книгу скрам" (https://iselihovkin.com/bookonline) 3. Это не выгодно самим командам. Самоуправляемые команды, как идеальный газ, случаются не часто, на пути их формирования -- системный кризис, который может вылиться в масштабные увольнения не готовых к "бирюзе". 4. Скрам это дорого - я уже выше писал несколько раз, почему. 5. Банально, сейчас на скрамизацию благополучно списываются бюджеты обучения подразделений, и это всех устраивает. Часто ситуацию поясняют философским "easy to start, hard to master", особенно тренеры, но тут очень простой ответ: потому что это не выгодно никому.

(Утащил из Интернета и подрихтовал для понятности) Подавляющее большинство гипотез - х%йня, и работать так не будет. Но фаундерам не нужен тот, кто скажет им, что это х%йня и работать не будет. Им нужны те, кто скажет: "ребята, вы ох%енные, лучше всех, и это обязательно будет работать, только надо сделать вот так вот и так и еще вот так". Парадокс в том, что это все равно получится нерабочая х%йня - потому что фаундер уже все равно придумал это вот именно так, как вам описал, и не собирается отступать от своей идеи, в которую уже влюбился. Чтобы сделать "вот так вот и еще вот так" вам самому нужно сесть и начать это делать - и не в статусе наёмника или консультанта, а кофаундера - потому что иначе все равно проект сделают по-своему, а вы только огребете негатива. За "х%йня и так работать не будет" вы тоже огребете негатива - после того, как за вами закроют дверь. Потом это действительно оказывается х%йней и так не работает, но если об этом напомнить, огребете негатива еще раз, потому что "х%ли вы такой умный тут, попробовали бы сделать это сами".

Edtech с2с в России текущем виде это маркетплейсы "клиент"-"преподаватель", которые: - инвестиционными деньгами заливают маркетинговые каналы, чтобы авторскому курсу на рынке было делать нечего, только идти на площадку - попробуйте загуглить курсы и с интересом поизучайте поисковую выдачу; - за счет этого прессует авторов и преподавателей, забирая 90%+ выручки себе (поинтересуйтесь ставкой преподавателя SkyEng, кстати: рублей эдак 100-200 за час). Почему люди несут туда деньги? Ну, это совокупность факторов, как и у любого явления: - хейт "официального" образования (кстати, как вам победы на последних физ и мат олимпиадах, плохое образование?) - мантра "лучшие инвестиции это инвестиции в себя! не дай себя обмануть в другом месте!"; ну и в самом деле, при относительной бедности другие формы инвестиций не особо доступны; - последовавшее за глобализацией вайтишничество; - подкрепление компаниями деньгами и пиар-активностями обсуждений повестки про деньги и зарплаты -- иногда кажется, что в любом ИТ сообществе только и разговоров, что о зарплатах; - эксплуатация комплекса ученика: надо хорошо учиться, и тогда придет успех; если успеха нет, надо еще поучиться. Оценить ёмкость рынка я не могу, с интересом наблюдаю. Про Edtech b2b я еще напишу, не переключайтесь.

Сеньорность in habitat Надысь в твиттере что-то расплодились треды про сеньорность. Вот и я закину свои пять копеек. На оба треда ответ — нет. Нет в нашей индустрии чёткой линейки. И никогда не было. Начнём с того что в аутсорс-галерах лычку "сениора" дают тупо за выслугу лет. Обычно - крайне маленькую. От 3 до 5. Приходили ко мне такие мальчики на собеседования, да. Самому младшенькому было 23. За плечами 2-3 проекта в лучшем случае, фундаментальных знаний ноль, код пишет как обезьяна лапой. И ничего — гордо называет себя сениор. Приходил и сениор, который не знал чем cookies отличается от сессии. Мрак же? Но на своём рабочем месте — сениор. Так что, планка сениора — большая условность и варьиуется от компании к компании. Теперь про потребности бизнеса. Увы, но факт: зарабатывает на разработке только очень и очень маленький IT-бизнес. Вооот такусенький. Питающийся, можно сказать, подножным кормом. Или аутсорс, но там своя история. А когда потребность в ежедневном баблопотоке отпадает — у бизнеса натурально отлетает кукуха. Разработка замедляется и требования не только к сениорам, а к разработчикам вообще начинают свой вояж в неведомые ебеня. В одном месте от разработчика хотят чтобы он был со всеми мил в общении и участвовал во всех встречах (хотя бы номинально). В другом — чтобы разделял ценности критической расовой теории и яро поддерживал LGBTQ+. В третьем ненавязчиво требуют лизать жопу начальству и восхвалять технический скилл Самого учредителя. В чётвёртом — чтобы сам умел смотреть в продуктовые метрики (вам знакомы термины Retention, Churn, LTV, NPS, D/MAU? Вот то-то же). В пятом нужно знать все тонкости гибких методологий разработки и молиться на Scrum Guide. В шестом предпочитают набирать любителей просыпаться в 4:20 (если вы понимаете о чём я). В седьмом хотят чтобы разработчики "были счастливы на своём рабочем месте", что бы то ни значило. И так далее. Верный маркер таких бизнесов на собесе — или какая-то экзотика ("покажи фотографию своей книжной полки": мой любимый пример, который подарил мне Лекс АйтиБорода при очень необычных обстоятельствах), или дежурное решение leetcode в технической части, или какое-то невообразимо огромное количество этапов. Важно же, как мне кажется, понять главное: Таким бизнесам не нужен разработчик вообще. Совсем. Потому что ну не принесёт он сколько-нибудь значимых денег. И не потратит. На чём же там зарабатываются деньги? Если это стартапная история — то инвестиции. Разработка заканчивается на этапе "сляпать MVP", а в остальном это про то, как правильно торгануть лицом. B2B — это продажи крупным клиентам. Особенно если вовлечён американский deep business. Миллиарды баксов. Основной продукт ужасен, неудобен, но уже сделан. Обслуживать его особо много ума не надо, а в остальном — опять же про торговлю лицом и решение вопросиков с нужными человечками. Если это продуктовая компания, скажем продающая приложеньки — то основной источник бабла — маркетинг. Реклама, реклама и ещё раз реклама. Добавить немного b2b по вкусу. Продукт, опять же, написан и требует лишь доводки и поддержки. Если это FAANG, то не исключены госзаказы и стратегические сделки. Ну не принесёт разраб FAANG-у полтора миллиона пользователей в базе данных, как ни крути. О чём мы? Ах да, о сениорстве. Знаете, мне нравится такой подход: берите задачи, которые вам не по зубам и грызите потихоньку в свободное от работы время. Так чтобы решить, откинуться в кресле, посмотреть на результат и сказать самому себе — "а я хорош!". Станьте самому-себе сениором. Заодно синдром самозванца подлечите. Такие дела

А вот как в другую сторону картинка качается. В форварде пост, как автор решил кепку программиста с пропеллером сменить на кипу бизнесмена. Ну, как сменить: когда к программисту приходят с вопросом, почему так плохо сделано, он сразу в бизнесмена превращается, ROI считать начинает

Я периодически отсматриваю резюме/вакансии и программистов, и менеджеров (тимлидов), и что я вижу там -- менеджеры/тимлиды просят и получают сильно меньше и, что важно, ищут их сильно меньше, чем разработчиков. Вопрос -- почему? Ответ простой: весь управленческий потенциал ИТ само себе засунуло подальше, когда начало кругом насаждать скрам и аджайл. То есть буквально: в текущей зарплате разработчика заложены затраты на управление, которые раньше платили менеджеру, а теперь разделили по всей команде. Потому что самоуправляемые команды все равно должны как-то управляться. А как они управляются? А вот как на картинке к посту

Однажды Джек Ма сказал про предпринимательство примерно так: "Никогда не сдавайтесь. Сегодня вам тяжело, завтра будет намного тяжелее, но зато послезавтра - наконец взойдет яркое утреннее солнце. Немного жаль, что большинство из вас умрет завтра на закате"

Опросничек Господа, а кто из дома работает тут - расскажите, как обустроились? Кабинет? Кухня? Коворкинг? Старбакс? С интересом послушаю, сами или контора помогала. Если фоток home office пришлете, вообще уважать буду. Присланные фотки -- с желания и разрешения, конечно -- соберу в галерею и положу следующим постом. P.S. Антиспам бот не приветствует отправку сообщения с картинкой, если это ваше первое сообщение сюда. Те, кто отметились сообщениями в чате ранее, постят без проблем

Уроборос Аджайла Конец нулевых в ИТ прошел под созвездием Agile Manifesto. Ну, вы все знаете эти завораживающе, прекрасные, космические слова: - Индивидуумы и взаимодействие важнее процессов и инструментов. - Работающий продукт важнее исчерпывающей документации. - Сотрудничество с заказчиком важнее согласования условий контракта. - Реакция на изменения важнее следования первоначальному плану. Тезисы, красивые настолько же, насколько и туманные. Насколько пресловутый PRINCE2 или PMBOK был понятен в одно лицо с книгой, настолько же Agile требовал непременного "тренера". Тем не менее, индустрия постепенно облекла их в понятные формы и взаимодействия. А дальше случилось то, что и должно было случиться -- Agile Manifesto 2.0. И звучит он так: - Команда и ответственность важнее индивидумов и взаимодействия - Бизнес-ценность важнее рабочего продукта - Развитие партнёрских отношений важнее сотрудничества с клиентом - Готовиться к изменениям важнее реакции на изменения Что мы видим тут? Что успех, по мнению авторов, это: - команда экспертов и четкая ответственность - согласованная проработанная концепция и модель, где бизнесу гарантируют ценность - тщательная подготовка важнее, чем нестись, сломя голову, и вносить изменения. Аджайл сходил по кругу и пришел в тот Waterfall, который отрицал. Потому что команда молодых, проактивных сотрудников -- это замечательно, но платят почему-то только за сделанную работу.

А есть среди моих читателей кто-то с опытом настройки и установки Min Io, особенно все это дело в K8S? Запрос на платную консультацию. Напишите @meowthsli, кто готов, пжлст

В последнее время все настойчиво приглашают в вакансии, в которых отдельно акцентируется, что команда успешно экспериментирует с Amazing ComputerVision AI BigData Machine Learning и прочие такие баззворды, как будто это должно как-то впечатлить или стать аргументом в пользу выбора. Ситуация буквально "а если кому-то удается сделать хоть что-то мало-мальски работоспособное, то все его поздравляют, потому что это правда успех". Я бы вообще, если мог бы, настроил фильтр, в котором не будет CV AI ML и прочих этих буквосочетаний в почте. Тенденция, когда deep tech из мультипликатора бизнеса становится его основой, лично меня неприятно беспокоит.

Если верить нашей бигдате, ваш самый любимый товар — пакет

Как бы вы определили, что такое киллер-фича? Ну, чтобы понял не только тот, кто ее делает

Об людей-функции Переход на удаленную работу - второй шаг на пути к "сотрудник-функция". Для тебя неважно, кто на том конце сидит, может, человек, а может, и роботом давно заменили. Вот чтобы заменить было легко, сначала надо сепарировать и четко api выставить, в виде тикетницы, например. Первым шагом был agile и движение в бирюзовую сторону, где роль (само)управления вручена самой команде, потому что менеджер роботом заменяется плохо. Биржи NoCode, FMS (freelance management system) - тоже какой-то из таких шагов. Программисты радостно движутся в сторону замены людей на software. И первым делом программисты заменят других программистов, потому что технократам всё равно, кого заменять.

Об успех в стартапах В Forbes 100 за 2020 год 52 основателя стартапов, 2 жены основателей и 2 ранних сотрудника с долей. Жениться/выйти замуж за основателя стартапа это примерно так же результативно, как и придти ранним сотрудником и много лет рвать ж@пу за долю. Вернее, если посчитать, даже более результативно – жён основателей поменьше, чем ранних сотрудников с долей

Прочел давеча, что бизнес в ИТ строится от инициатив разработки. Так и представил, что сидит маркетинг, менеджмент, сейлзы, аккаунты круглым столом вокруг разработчика: "ну, с%кабл%ть, где твои инициативы, ты что, не видишь, ты щас весь наш бизнес рушишь?!"

Об паттерны Кажется, сейчас наступило вполне благодатное время, чтобы расчехлить давно позабытые паттерны проектирования, и дать им вторую жизнь. Связано это с распространением NoCode-подхода, где из набора подходящих кубиков собирается бизнес-процесс. Проблема в том, что проектировщик хотел бы максимально избежать глубокой кастомизации, но тогда может пострадать гибкость, а через это - и простота, и стоимость поддержки. Структурные и поведенческие паттерны тут могут придтись как никогда к месту. Только элементами тут будут не классы, а целые системы. - Медиатор - здесь подсистема (iftt, zapier) сливает в себя все данные, а потом дирижирует другими сервисами, не давая связаться напрямую. - Декоратор - здесь подсистема выполняет действие (порождает события), и пробрасывает вызов дальше по сервисам. - Ну и так далее. Я перечислил только пару паттернов из Э. Гаммы сотоварищи, но классификаций и вариантов сильно больше. Ждем курса по паттернам на Гикбрейнзах и прочих Скиллбоксах для НеРазработчиков?

*** Ищу специалиста *** Господа, у кого есть опыт и желание выполнить возмездно небольшую работу по Java Cards, отзовитесь -- есть дело

Мне иногда в личку прилетают вопросы, вот один из них: надо ли иметь талант и предрасположенность, чтобы управлять, или конструировать — или этому можно научиться? Многие считают, что писать код это интересно, а управлять людьми – "не их". Лично я считаю, что это врождённое, и нужны способности — практически нельзя научиться управлению, и проектированию архитектуры, и ещё чему-то сложному кого угодно, без способностей. Но я также считаю, что врождённые способности это не большая редкость, они у многих есть. Просто способности спят, сидят тихо и не подают виду, и вообще не знаешь, что они у тебя есть. Думаю, у многих они могут обнаружиться вообще "когда-то тогда-то", и то, если целенаправленно раздражать свое сознание задачами, которые требуют, чтобы компетенции "проснулись".