Роскошная статья про настоящий легаси. Очень люблю такую инженерную археологию

https://habr.com/ru/post/547820/

Еще немного инженерной археологии в чат. Как позабытый опыт прошлого (Ada) помогает в настоящем

https://habr.com/ru/post/549688/

А есть где-то подтвержденные исследования, что если тестирует не программист, а тестировщик, то ПО (в смысле, у пользователя) получается более качественным в конечном итоге?

Вот опять встретил, как кто-то в Фейсбуке задается вопросом, чем продуктивная настойчивость отличается от момента, когда лошадь сдохла и пора слезать. И самое главное - как отличить одно от другого, как быть упорным, а не упертым?

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

*не является инвестиционным советом, и может вам не подойти

Для любителей аргумента "люди превыше инструментов и процессов" загадка. Что такого магического произошло с людьми в 1850-м году, что до него бизнес был почти исключительно малым, а потом вдруг, за какие-то 30-40 лет появились корпорации, бизнес-школы, национальные проекты, etc?

Об тимлидов

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

Судя по тому, что тимлиду платят всего на 10-20% больше при том, что он отвечает за работу 10+ сотрудников, бизнес делиться успехом не согласен, и такой руководитель группы, самоходная единица ему особо не нужен, а нужен на самом деле - пилот корпоративной машины, который будет послушно жать на врученные педали и крутить врученный руль, а бизнес (на словах) постарается решить все "руководческие проблемы", от ресурсного обеспечения до карьерного трека и мотивации. Фактически, конечно, все это не решается, так что днём такая самоходная разработческая единица бегает по верхней палубе, вечером растыкивает тикеты за тех, кто "просто пришел программировать". А когда код писать тимлиду? А код тимлид по ночам фигачит, потому что обязанность по выработке с него никто и не снимал.

Как же это продают тимлиду, да и всей команде? Тут в ход вступает заветное "зато над нами ненавистных менеджеров нет!". Ведь менеджер (всегда бесполезный) - конец любого дела, безотказный жупел, аргумент в любом споре.

О том, что ждет тимлида, обычно никто не говорит, ну так давайте я вспомню типичные вопросы. Команда немотивирована, а ты крайний? Прогеры посрались из-за табов/пробелов? Безопасники неделями проект на тормозах спускают? Три продакта суют задачи свои, у каждого самые важные, угрожают оценить ниже низкого, прощай, новый грейд? Таков корпоративный аджайл. Зато менеджеров в команде нет! Просишь сотрудника помочь, он отвечает, мол, это не в моих рабочих обязанностях, доплачивай, или я буду вежливо скипать задачу. Бюджета нет, должностные обязанности шатаешь не ты, руководитель говорит - "ну, ты же управленец, найди подход, а то какой ты тимлид".

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

Есть мнение, что это все работает, потому что а) эффект масштаба - в крупной компании матричная структура крайне эффективна б) современные инженеры, в среднем, крайне мотивированы и прилежны. Таким образом 10% самых неравнодушных в компании с успехом привозят пирог прибыли, который делится и на оставшиеся 90% корпоративных паразитов. Компания не только не гибнет, а еще и развивается - но только крупная.

При этом компанию тащат и развивают 10% вот таких вовлеченных тимлидов. Зато .. - что? Правильно.

Про 20% времени, которое гугл отдает сотрудникам

В компании невозможно все 100% времени людей держать занятыми. Поэтому иногда они будут простаивать - это нормально, Голдратт в "Критической цепи" обосновывает, почему это нормально, и показывает, что это необязательно означает падение производительности.

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

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

Второй возможный вариант, похоже, придумали в Гугле: 20% времени, которые можно потратить на любой проект по выбору - при условии, что свободное время от проекта есть, все все понимают, работа есть работа.

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

А относительно недавно Гугл отказался от практики 20%. Любопытно, какое иное решение озвученной проблемы они придумали..

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

Мне иногда в личку прилетают вопросы, вот один из них: надо ли иметь талант и предрасположенность, чтобы управлять, или конструировать — или этому можно научиться? Многие считают, что писать код это интересно, а управлять людьми – "не их".

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

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

Об паттерны

Кажется, сейчас наступило вполне благодатное время, чтобы расчехлить давно позабытые паттерны проектирования, и дать им вторую жизнь. Связано это с распространением NoCode-подхода, где из набора подходящих кубиков собирается бизнес-процесс. Проблема в том, что проектировщик хотел бы максимально избежать глубокой кастомизации, но тогда может пострадать гибкость, а через это - и простота, и стоимость поддержки.

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

- Медиатор - здесь подсистема (iftt, zapier) сливает в себя все данные, а потом дирижирует другими сервисами, не давая связаться напрямую.

- Декоратор - здесь подсистема выполняет действие (порождает события), и пробрасывает вызов дальше по сервисам.

- Ну и так далее. Я перечислил только пару паттернов из Э. Гаммы сотоварищи, но классификаций и вариантов сильно больше.

Ждем курса по паттернам на Гикбрейнзах и прочих Скиллбоксах для НеРазработчиков?

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

Об успех в стартапах

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

Об людей-функции

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

Программисты радостно движутся в сторону замены людей на software. И первым делом программисты заменят других программистов, потому что технократам
всё
равно,
кого
заменять.

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

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

В последнее время все настойчиво приглашают в вакансии, в которых отдельно акцентируется, что команда успешно экспериментирует с Amazing ComputerVision AI BigData Machine Learning и прочие такие баззворды, как будто это должно как-то впечатлить или стать аргументом в пользу выбора.

Ситуация буквально "а если кому-то удается сделать хоть что-то мало-мальски работоспособное, то все его поздравляют, потому что это правда успех".

Я бы вообще, если мог бы, настроил фильтр, в котором не будет CV AI ML и прочих этих буквосочетаний в почте. Тенденция, когда deep tech из мультипликатора бизнеса становится его основой, лично меня неприятно беспокоит.

Уроборос Аджайла

Конец нулевых в ИТ прошел под созвездием Agile Manifesto. Ну, вы все знаете эти завораживающе, прекрасные, космические слова:
- Индивидуумы и взаимодействие важнее процессов и инструментов.
- Работающий продукт важнее исчерпывающей документации.
- Сотрудничество с заказчиком важнее согласования условий контракта.
- Реакция на изменения важнее следования первоначальному плану.

Тезисы, красивые настолько же, насколько и туманные. Насколько пресловутый PRINCE2 или PMBOK был понятен в одно лицо с книгой, настолько же Agile требовал непременного "тренера". Тем не менее, индустрия постепенно облекла их в понятные формы и взаимодействия. А дальше случилось то, что и должно было случиться -- Agile Manifesto 2.0. И звучит он так:

- Команда и ответственность важнее индивидумов и взаимодействия
- Бизнес-ценность важнее рабочего продукта
- Развитие партнёрских отношений важнее сотрудничества с клиентом
- Готовиться к изменениям важнее реакции на изменения

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

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

Опросничек

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

P.S. Антиспам бот не приветствует отправку сообщения с картинкой, если это ваше первое сообщение сюда. Те, кто отметились сообщениями в чате ранее, постят без проблем

Однажды Джек Ма сказал про предпринимательство примерно так:

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