Культ путешествий позволяет многим людям убежать от проблемы самоопределения. Не все могут себе ответить с удовольствием на вопросы. Чем я хочу заниматься? В чём я самореализовался? В чём смысл моей жизни? А так, отправился в путешествие и вроде что-то сделал, наполнил жизнь свою каким-то содержанием от впечатлений путешествия.
Конечно, это не относится к путешественникам, отдыхающим и просто любознательным людям.
Но массовость и культ возведён именно из-за этих культурно-психологических проблем людей. Гораздо проще работящему гражданину нарисовать картинку диковинного путешествия, чем создавать культуру, в которой у каждого будет возможность поставить себе цель в жизни, и самое главное иметь условия для её достижения.
Да, я как раз об этом говорю. Вы рисуете образ менеджера, который должен заниматься организацией всего рабочего процесса и только людьми. Но это не так. Даже если мы говорим про тимлида продуктовой, а не функциональной команды, тимлид — это в первую очередь исполнитель, технарь, а потом уже менеджер.
Рассуждения тут логические. Кто может убедится в адекватности принятых технических решений? Оперативно, а не стратегически. Тот, кто разбирается в этих технологиях в контексте текущей ситуации. Менеджер гуманитарий не может физически вам собрать компоненты для релиза, верифицировать оценки, или понять в кого перенаправлять техническую проблему. Только тимлид.
Поэтому чтобы тимлид занимался тем, что может выполнить только он, другие менеджерские задачи, не связанные со спецификой деятельности его команды, должны отойти соответствующим ролям. Из ваших примеров:
разобраться с грустью у Пети: PeopleOps
объяснить основы secure coding Жене: ментор
поговорить с суппортом про текущие проблемы: бизнес аналитики и PO
договориться о ресурсах инфраструктуры на тестирование: QA и DevOps инженеры
сделать статусную презентацию: PO, техпис, продуктовый дизайнер
Тимлид у нас чаще всего еще и техлид. Именно поэтому у нас столько непродуманностей в дизайне, именно поэтому у нас столько непочиненных процессов.
Нет, такая ситуация у нас, потому что технический директор снеки покупает, тимлид презентацию рисует, а начальники придумывают всяких императоров, лишь бы не разбираться в вопросах организации, управления и руководства.
О, император — это что-то новенькое, плюсик хотя бы за нескучную терминологию.
Вообще в российских компаниях процветает какое-то извращенное применение слова тимлид. Часто так называют чистого менеджера, руководителя целого направления или подразделения с десятками сотрудников. Наверно, потому что начальники боятся слова “руководитель” в штатном расписании. При этом, разработчиков, в обязанности которых входит менеджмент небольшой команды называют просто сениорами.
Статистика по зарплате эту странность иллюстрирует. На лида компании хотят просто менеджера, а на сениора менеджера и эксперта в одном лице. Вот и приходится ребятам, как вы говорите, дауншифтиться чтобы получить наилучшее соотношение затраченных сил к зарплате.
Тимлиды не могут нормально погрузиться в архитектуру и дизайн.
В хорошо организованной компании у тимлида команда не больше чем на 5 человек. В таких условиях он может и обязан погружаться в архитектуру и дизайн. Иначе зачем он вообще нужен?
Тимлид команды разработки это — бригадир, младший менеджер, которой понимает все нюансы работы своей команды, может перевести их на другой уровень управленческой абстракции, и обратно.
Можно, конечно, сказать, что есть тимлид тимлидов — сотрудник у которого в зоне ответственности руководство сразу несколькими командами(бригадами). Но зачем? Его можно просто назвать руководителем.
В чужой монастырь лезть не буду. Если вас и ваших разработчиков всё устраивает, могу искренне только порадоваться. Никаких претензий.
Однако вы публикуете статью, которая оформлена как руководство к действию. Этим могут воспользоваться другие менеджеры. Поэтому на правах дискуссии я всё же отвечу на ваши вопросы, чтобы плохие практики не уходили в массы без обсуждения.
TL;DR Каждый должен заниматься своим делом. Выбор технического решения и проектирование API — не дело менеджеров.
Не очень понимаю где тут техническое решение. Удобное предоставление информации по взаимодействию с API и данными это техническое решение?
Интересно что придумывание API вы не считаете техническим решением. В любом случае это не удобное представление. Сейчас можно сказать стандартом является спецификация OpenAPI или аналоги, которую можно использовать не только для описания API, но и для автоматизации разных процессов разработки.
Может быть, вам всё это не нужно, но приводя в пример такие приколы, некоторые подрядчики будут и дальше считать, что нормально присылать на интеграцию API в Word файлах вот с такой вот отсебятиной:
И да, указание, когда начинать загрузку, до скрола или нет, как представлять параметры запросов в API — всё это техническое решение.
Хорошо если ваши проектные менеджеры настолько компетентны в техническом плане. Но они в любом случае не видят устройство системы изнутри, а значит могут ошибиться. Если ваши разработчики никогда не жалуются на технические решения менеджеров, может быть, они всё делают на пофиг. Не задумывались над этим?
Разработчики, в моем представлении, не должны придумывать как решать проблему бизнеса, не должны пытаться выяснять требования, они должны решать технические вопросы, писать красивый и качественный код с минимальным числом ошибок и переделок. А для этого следует давать им необходимую информацию.
В общем смысле не должны. А проектные менеджеры и бизнес аналитики не должны решать технические задачи за разработчиков. Чтобы получался качественный код с минимальным числом ошибок и переделок не нужно API за разработчиков писать и кнопки на макетах расставлять. Нужно предоставлять наиболее полное описание сценариев, особенно негативных, особенно с перспективой на развитие бизнеса. Тогда технический анализ и прогноз разработчика будет более точный, а значит и решение более качественное.
Кажется, что разработчикам не особо надо пояснять зачем нужна загрузка данных или для чего нужен неавторизованный стейт экрана.
Вот в этом и проблема. Если говорить про неавторизованный стейт экрана:
А анонимный и неавторизованный пользователь это одно и то же?
А если неавторизованный стейт предполагает демо режим приложения?
А если его потом нужно конвертировать в авторизованного?
А что, если нужно переносить неавторизованный стейт между разными устройствами?
Если вместо ответа на эти и подобные вопросы вы указываете разработчику, где кнопку разместить, то не удивляйтесь потом что разработанное решение невозможно адаптировать под ваши новые хотелки.
Короче говоря, моя мысль в том, что, указывая разработчикам техническое решение, вместо предоставления качественной аналитики и проектирования по задаче, вы блокируете возможность выбрать наиболее эффективное решение не сейчас, так в будущем.
Поясню, что мы занимаемся аутсорс разработкой и требования к моменту передачи фичи в разработку уже довольно определены.
И это хорошее замечание. Для качественной продуктовой разработки ваши примеры неуместны.
В любом случае, кроме примеров, в вашей статье есть дельные соображения, спасибо.
Такие попытки были: plain english, basic english, а еще разные упрощенные региональные диалекты.
Я не эксперт, но думаю, что английский не может стать языком земли, как и любой национальный язык, потому что содержит в себе культурное наследие и политический контекст.
В этом плане, когда мы реально захотим запустить язык Земли, логичнее будет запускать искусственно созданный язык, очищенный от обломков старых истин.
Вот вам пример по актуальной западной повестке. В эсперанто нет рода, а значит не нужно выдумывать феминативы, парить мозг друг другу местоимениями и прочее, можно сразу переходить к общению.
Текст статьи не станет проще и интереснее, если вы будете втыкать мемы через абзац.
Если говорить, по существу. Проблема вашего представления постановки задачи в том, что оно императивное, то есть техническое решение известно еще на этапе постановки. В таком случае зачем вам вообще разработчики? Пишите сами, будет быстрее.
Разработчику не нужны ваши идеи, как и что использовать на техническом уровне — это его прямой интерес и зона ответственности. Не говоря уже о том, что вы можете предлагать просто сложные и ошибочные решения, технических навыков то у вас нет.
В этом плане ваши примеры "хорошо описанных задач" просто ужасны. Ни в одном из примеров не описано, кому вообще нужны эти фичи, в каком контексте и какая польза бизнесу, зато полно сомнительных технических деталей.
На практике, взаимодействие аналитиков и исполнителей часто деградирует до такого императивного описания, потому что аналитик, уставший от вопросов разработчиков, замечает, что вопросов становится меньше, когда он буквально описывает расположение кнопок и название переменных — это жиза.
На самом деле проблема в том, что проектный менеджер не выдаёт качественный анализ предметной области, сам не знает чего хочет бизнес.
Для правильной постановки задачи нужно исчерпывающее описание и бизнес аналитика предметной области: кто действующая роль, позитивные и негативные сценарии, ограничения и допущения. Разработчик, если нет соответствующей роли, сам проведет системный анализ и выдаст вам классные варианты решения задачи с оценками.
Эсперанто занимает нишу чистого языка, который можно будет использовать в новых областях человеческого развития, не отягощая себя наследием национальных языков. Например:
Восстановление навыков общения после распада психических функций
Единообразное описание законов международного или космического права
Информирование и журналистика свободная от социальных болезней конкретной страны (привет словам master, black и т.д.)
Изучал эсперанто в армии, пока проходил срочную службу. В свободное время делать было особо нечего, приходилось развлекаться советскими книгами. Язык реально с низким порогом входа.
В этом суть. Никто не спорит со значением английского языка на текущий момент, однако он отягощён своим историческим наследием. Эсперанто — это новая абстракция, которая может помочь решить конкретные задачи. Например, внести ясность в тех областях, где неверное толкование может иметь тяжелые последствия, или упростить контакт с неразвитыми племенами людей. В конце концов, это прекрасный эксперимент, который помогает развивать лингвистическую науку.
Тут прямая аналогия с языками программирования. Есть C язык, который доступен на любой платформе и в принципе способен как-то решить задачи из любой области. Но это не останавливает нас от изобретения новых языков.
Видно, что эти инструменты должны пересекать границы ограничивающих функций — стать более продвинутыми, чем человеческая когнитивная способность, и более энергоэффективными, чем современные решения. Энергоэффективность означает автоматизацию, а снижение когнитивной нагрузки — что машины должны стать более компетентными.
Автоматизация как средство увеличения энергоэффективности имеет один недостаток по определению — она направлена на решение концептуально понятных человеку задач. В этом плане GitHub Copilot никак не двигает технологический прогресс — это просто статистически усредненная коллекциях снипетов, новые концептуальные задачи Copilot решить не может.
Если говорить о реальном технологическом прорыве, будущее наших технологий находится в другой оси, по аналогии с мнимыми числами, за пределами вашего графика. Скорей всего оно не будет учитывать человеческие когнитивные способности, так же как тепловой двигатель не учитывает физические способности человека.
Фантазировать тут можно сколько угодно, но вероятно это будет связано с эффектами квантовых компьютеров, вневременными концепциями и новыми процессами “кибер-эмоций” от взаимодействия человека и информационных систем.
Видимо, два самых важных параметра разработки ПО сформулировал Алан Кей. Это человеческие усилия и технологическая сложность.
Оба этих параметра когнитивные. Значит любая аналитика на их основе будет зависеть от субъективных представлений аналитика. Это ставит под сомнение научность любых размышлений на их основе, и как следствие, некорректность прикладного применения.
Дело конечно не в том, что Python и Haskell можно легко поменять местами на графике. Сами категории, которые вы выводите через график не более чем иллюстрация вашего личного понимания предметной области. Практического смысла в этом не много.
Столько умных книг на картинке, тема интересная. А по сути, вы всё свели к заветам "эффективного" менеджмента.
В итоге управление людьми — это постоянное общение, согласование ожиданий и обратная связь.
Из формальных вещей нужны встречи по планированию личного развития и перформанс-ревью как ретроспективы этого. Перформанс-ревью — это процесс оценки того, что получилось в ожиданиях, что не выполнено, а что превзошло ожидания. Это оценка индивидуального вклада в работу компании в целом.
Организация — подготовка или формирование чего-либо для осуществления деятельности. Например, организовать можно производственный процесс или команду.
Управление — непосредственный контроль и действие. Управлять можно транспортным средством или бюджетом.
Руководство — направление деятельности. Руководитель планирует и контролирует достижение целей, управляет ожиданиями компании и сотрудников, мотивирует.
Управлять людьми можно только в кризисных ситуациях, когда они сами не могут, но ситуация требует немедленного исполнения. В остальных случаях забудьте про управление людьми, они вам не принадлежат.
Если хотите повысить продуктивность — организуйте и руководите людьми. Перфоманс ревью, OKR, KPI будут приводить только к их формальному выполнению на бумаге.
Не стесняйтесь сопоставлять реальные желания и возможности обоих сторон. Не удивляйтесь, если вместо нового фреймворка по плану индивидуального развития, разработчик хочет:
зарплату в два раза больше под нового ребёнка в семье
отпуск на всё лето для гастролей своей рок группы
создать группу по йоге внутри компании
и. т.д.
Если вы сможете совместить эти желания с целями компании, то получите разработчика, который увидит дополнительный смысл сотрудничества, а значит станет производительнее и лояльнее.
Благодаря извращенному толкованию Agile многие менеджеры теперь думают, что для решения задач не нужен анализ, проектирование и планирование — достаточно всем вместе обсудить что-то на созвоне.
Это только упрощает жизнь управленцам, которые привыкли работать по наитию. Соблюдать никакие регламенты и процессы не нужно — можно хоть каждый день свои внезапные догадки вбрасывать в рабочую команду, в зависимости от настроения.
Контроль качества, о котором вы вероятно говорите, достигается с помощью QA инженеров, которые буквально следят за тем, что мы идём верным курсом: цели актуальны, методы достижения эффективны, требования выполняются.
Agile тут ни при чем, обеспечением качества можно и нужно заниматься в любой модели разработки.
Поздравляю, вы переизобрелиинкрементную модель разработки, которая, по сути, является улучшенным водопадом, тем самым, которым вас так пугали в процессе принятия Agile веры.
Попробуйте в начало этих месячных циклов также добавить качественное проектирование, вместо бесконечных разговоров с заказчиком на демках — увеличение скорости разработки вас приятно удивит.
Вполне закономерная реакция на сложившуюся ситуацию. Некоторые известные компании превратили процесс собеседования буквально в испытание — экзамен в несколько этапов на пару календарных недель. Не надо удивляться что соискателям приходится набивать руку и тренироваться, чтобы справится с этими испытаниями.
Язык формируется говорящими здесь и сейчас. Если кто-то использовал определенные слова — значит они уже оправданы.
Проблема не в англицизмах, об этом уже миллион раз говорили, русский язык чуть более чем полностью состоит из иностранных заимствований.
Проблема в терминологии и сленге. Вы раздражаетесь, когда чего-то не понимаете и это нормально. Задача грамотного переговорщика использовать тот словарь, который будет максимально понятен всем участникам переговоров.
Например, если вы начнёте говорить с разработчиками, соответственно вашему примеру, словами "независимый программный модуль", "полезная часть продукта", "ежедневная планёрка для согласования деятельности", "поток работы" — негодовать начнут уже они.
Я разделил его на две части: как управляющий проектом видит и желает видеть программистов ("взгляд сверху") и наоборот - как подчинённые хотели бы, чтобы с ними взаимодействовал руководитель и что они от него ждут ("взгляд снизу").
Представление руководителя как надзирателя, который сидит высоко, глядит далеко — было оправдано пару веков назад. Тогда общество переходило от рабского натурального труда к индустриальному. Продуктивность всё еще можно и нужно было контролировать физически. Прораб-надзиратель должен был буквально палками гонять работников чтобы те делали рутину.
Позже, надзирателя узаконили, и он превратился в начальника — должностное лицо, которое вместо палки стал использовать нормативные акты и административные наказания для поддержания приемлемой продуктивности работников на заводах.
Сейчас руководитель в IT не начальник, а равноправный участник команды, он ни сверху и не снизу. Его задача организовать, руководить и управлять рабочим процессом. Никакого благородства тут нет, творческий процесс свободных людей физически невозможно и не нужно контролировать если вы хотите получить реальную продуктивность. Этот процесс нужно обеспечивать и развивать.
К сожалению, руководители "старой школы" всё еще пытаются работать в образе начальников. Ваша статья этому прекрасное подтверждение — в ней каждый пункт сквозит авторитарностью и должностной подчиненностью.
Ваш опыт я не оспариваю и не осуждаю, какой есть. Но мне кажется неправильно поддерживать устаревшие представления о роли руководителя в работе IT, даже если это ваша личная история. Молодой и неокрепший руководитель начитается у вас про то, кто и что ему должен и пойдёт на практике подчинять подчинённых. Поэтому поставил вам минус.
Ваше представление сложилось так, потому что "поток" — тоже определенная абстракция, за которой стоят детали реализации. Стоит разобраться, о чем именно мы говорим.
"Системные потоки" — то есть потоки управляемые ОС, могут выполняться буквально и физически параллельно на разных ядрах процессора или разных процессорах. В рамках одного системного процесса или нет. Для этого и придумывают многоядерные процессоры, многопроцессорные суперкомпьютеры, тензорные ядра и сопроцессоры.
"Виртуальные потоки" — разного рода легкие|тонкие|зелёные потоки, тоже могут выполняться параллельно. Представьте что ваша виртуальная машина умеет компоновать несколько виртуальных операций в одну физическую и исполнять за один такт физического процессора, тогда потоки выполнятся параллельно даже на одном ядре. Для этого придумывают всякие Erlang'и.
Проблема планирования времени выполнения этих потоков возникает тогда, когда физический ресурс меньше, чем логический. Если на вашем компе 128 ядер, а системных потоков 512, тогда да, не все из них будут физически одновременно работать, будет оверхед на переключение и так далее.
Об этом и речь. Возвращаясь к вашему изначальному вопросу. Суть не в том, что потоки берут откуда-то дополнительную работу ЦПУ. Суть в том, что дефолтное асинхронное приложение на ивентлупе с одним потоком не утилизирует многоядерный ЦПУ на 100%
Асинхронность — свойство операции, которое означает что время выполнения этой операции принципиально не совпадает с ходом времени вашей программы, можно сказать нелинейно. Как правило — это длительные и не дискретные операции: пользовательский ввод, календарное планирование, долгий запрос в базу данных или внешний сервис.
Многопоточность — свойство системы, которое позволяет выполнять несколько операции параллельно, то есть одновременно. В современных компьютерах это физически параллельные вычисления на разных ядрах CPU (отсюда такая гонка за количеством ядер и феноменальная производительность GPU на тензорных операциях).
Напрямую противопоставлять эти свойства некорректно.
Да, дефолтная реализация в Python или JavaScript использует ивент луп - то есть цикл с диспетчеризацией неблокируемых и последовательных операций. Ключевой момент здесь — последовательных. Заметное увеличение производительности происходит только за счёт того, что приложение продолжает выполнение других задач пока ожидает ответ от подсистемы IO (например поток байт из сокета). Но параллельных вычислений при этом не происходит, а значит компьютер не использует все свои вычислительные мощности.
Но, асинхронное программирование можно реализовать, как угодно. Например, в C# дефолтная реализация асинхронщины использует разогретый пул потоков, читай многопоточность. В Python тоже можно запускать async/await на потоках, через какой-нибудь ThreadPoolExecutor.
Таким образом максимальную производительность вы можете получить, комбинируя неблокируемые операции и параллельные вычисления. Конфигураций можно придумать миллион. В одном потоке принимать в расшаренную память данные из сокетов, а в другом их обрабатывать в векторе с кэшем процессора. Ну или запускать несколько ивент лупов, потому что на больших количествах RPS начинают играть даже накладные расходы на диспетчерезацию внутри цикла (так, все асинхронные Python фреймворки в продакшене работают через ранеры которые, сюрприз-сюрприз, запускают несколько потоков или даже процессов для выполнения вашего асинхронного кода).
Использовать при этом сахарный async/await или долбить всё на колбеках — это уже вам решать. Главное, что от физики не уйти, нужно понимать, как работает железо под копотом, о том и речь.
Культ путешествий позволяет многим людям убежать от проблемы самоопределения. Не все могут себе ответить с удовольствием на вопросы. Чем я хочу заниматься? В чём я самореализовался? В чём смысл моей жизни? А так, отправился в путешествие и вроде что-то сделал, наполнил жизнь свою каким-то содержанием от впечатлений путешествия.
Конечно, это не относится к путешественникам, отдыхающим и просто любознательным людям.
Но массовость и культ возведён именно из-за этих культурно-психологических проблем людей. Гораздо проще работящему гражданину нарисовать картинку диковинного путешествия, чем создавать культуру, в которой у каждого будет возможность поставить себе цель в жизни, и самое главное иметь условия для её достижения.
Да, я как раз об этом говорю. Вы рисуете образ менеджера, который должен заниматься организацией всего рабочего процесса и только людьми. Но это не так. Даже если мы говорим про тимлида продуктовой, а не функциональной команды, тимлид — это в первую очередь исполнитель, технарь, а потом уже менеджер.
Рассуждения тут логические. Кто может убедится в адекватности принятых технических решений? Оперативно, а не стратегически. Тот, кто разбирается в этих технологиях в контексте текущей ситуации. Менеджер гуманитарий не может физически вам собрать компоненты для релиза, верифицировать оценки, или понять в кого перенаправлять техническую проблему. Только тимлид.
Поэтому чтобы тимлид занимался тем, что может выполнить только он, другие менеджерские задачи, не связанные со спецификой деятельности его команды, должны отойти соответствующим ролям. Из ваших примеров:
разобраться с грустью у Пети: PeopleOps
объяснить основы secure coding Жене: ментор
поговорить с суппортом про текущие проблемы: бизнес аналитики и PO
договориться о ресурсах инфраструктуры на тестирование: QA и DevOps инженеры
сделать статусную презентацию: PO, техпис, продуктовый дизайнер
Нет, такая ситуация у нас, потому что технический директор снеки покупает, тимлид презентацию рисует, а начальники придумывают всяких императоров, лишь бы не разбираться в вопросах организации, управления и руководства.
О, император — это что-то новенькое, плюсик хотя бы за нескучную терминологию.
Вообще в российских компаниях процветает какое-то извращенное применение слова тимлид. Часто так называют чистого менеджера, руководителя целого направления или подразделения с десятками сотрудников. Наверно, потому что начальники боятся слова “руководитель” в штатном расписании. При этом, разработчиков, в обязанности которых входит менеджмент небольшой команды называют просто сениорами.
Статистика по зарплате эту странность иллюстрирует. На лида компании хотят просто менеджера, а на сениора менеджера и эксперта в одном лице. Вот и приходится ребятам, как вы говорите, дауншифтиться чтобы получить наилучшее соотношение затраченных сил к зарплате.
В хорошо организованной компании у тимлида команда не больше чем на 5 человек. В таких условиях он может и обязан погружаться в архитектуру и дизайн. Иначе зачем он вообще нужен?
Тимлид команды разработки это — бригадир, младший менеджер, которой понимает все нюансы работы своей команды, может перевести их на другой уровень управленческой абстракции, и обратно.
Можно, конечно, сказать, что есть тимлид тимлидов — сотрудник у которого в зоне ответственности руководство сразу несколькими командами(бригадами). Но зачем? Его можно просто назвать руководителем.
В чужой монастырь лезть не буду. Если вас и ваших разработчиков всё устраивает, могу искренне только порадоваться. Никаких претензий.
Однако вы публикуете статью, которая оформлена как руководство к действию. Этим могут воспользоваться другие менеджеры. Поэтому на правах дискуссии я всё же отвечу на ваши вопросы, чтобы плохие практики не уходили в массы без обсуждения.
TL;DR Каждый должен заниматься своим делом. Выбор технического решения и проектирование API — не дело менеджеров.
Интересно что придумывание API вы не считаете техническим решением. В любом случае это не удобное представление. Сейчас можно сказать стандартом является спецификация OpenAPI или аналоги, которую можно использовать не только для описания API, но и для автоматизации разных процессов разработки.
Может быть, вам всё это не нужно, но приводя в пример такие приколы, некоторые подрядчики будут и дальше считать, что нормально присылать на интеграцию API в Word файлах вот с такой вот отсебятиной:
И да, указание, когда начинать загрузку, до скрола или нет, как представлять параметры запросов в API — всё это техническое решение.
Хорошо если ваши проектные менеджеры настолько компетентны в техническом плане. Но они в любом случае не видят устройство системы изнутри, а значит могут ошибиться. Если ваши разработчики никогда не жалуются на технические решения менеджеров, может быть, они всё делают на пофиг. Не задумывались над этим?
В общем смысле не должны. А проектные менеджеры и бизнес аналитики не должны решать технические задачи за разработчиков. Чтобы получался качественный код с минимальным числом ошибок и переделок не нужно API за разработчиков писать и кнопки на макетах расставлять. Нужно предоставлять наиболее полное описание сценариев, особенно негативных, особенно с перспективой на развитие бизнеса. Тогда технический анализ и прогноз разработчика будет более точный, а значит и решение более качественное.
Вот в этом и проблема. Если говорить про неавторизованный стейт экрана:
А анонимный и неавторизованный пользователь это одно и то же?
А если неавторизованный стейт предполагает демо режим приложения?
А если его потом нужно конвертировать в авторизованного?
А что, если нужно переносить неавторизованный стейт между разными устройствами?
Если вместо ответа на эти и подобные вопросы вы указываете разработчику, где кнопку разместить, то не удивляйтесь потом что разработанное решение невозможно адаптировать под ваши новые хотелки.
Короче говоря, моя мысль в том, что, указывая разработчикам техническое решение, вместо предоставления качественной аналитики и проектирования по задаче, вы блокируете возможность выбрать наиболее эффективное решение не сейчас, так в будущем.
И это хорошее замечание. Для качественной продуктовой разработки ваши примеры неуместны.
В любом случае, кроме примеров, в вашей статье есть дельные соображения, спасибо.
Такие попытки были: plain english, basic english, а еще разные упрощенные региональные диалекты.
Я не эксперт, но думаю, что английский не может стать языком земли, как и любой национальный язык, потому что содержит в себе культурное наследие и политический контекст.
В этом плане, когда мы реально захотим запустить язык Земли, логичнее будет запускать искусственно созданный язык, очищенный от обломков старых истин.
Вот вам пример по актуальной западной повестке. В эсперанто нет рода, а значит не нужно выдумывать феминативы, парить мозг друг другу местоимениями и прочее, можно сразу переходить к общению.
Текст статьи не станет проще и интереснее, если вы будете втыкать мемы через абзац.
Если говорить, по существу. Проблема вашего представления постановки задачи в том, что оно императивное, то есть техническое решение известно еще на этапе постановки. В таком случае зачем вам вообще разработчики? Пишите сами, будет быстрее.
Разработчику не нужны ваши идеи, как и что использовать на техническом уровне — это его прямой интерес и зона ответственности. Не говоря уже о том, что вы можете предлагать просто сложные и ошибочные решения, технических навыков то у вас нет.
В этом плане ваши примеры "хорошо описанных задач" просто ужасны. Ни в одном из примеров не описано, кому вообще нужны эти фичи, в каком контексте и какая польза бизнесу, зато полно сомнительных технических деталей.
На практике, взаимодействие аналитиков и исполнителей часто деградирует до такого императивного описания, потому что аналитик, уставший от вопросов разработчиков, замечает, что вопросов становится меньше, когда он буквально описывает расположение кнопок и название переменных — это жиза.
На самом деле проблема в том, что проектный менеджер не выдаёт качественный анализ предметной области, сам не знает чего хочет бизнес.
Для правильной постановки задачи нужно исчерпывающее описание и бизнес аналитика предметной области: кто действующая роль, позитивные и негативные сценарии, ограничения и допущения. Разработчик, если нет соответствующей роли, сам проведет системный анализ и выдаст вам классные варианты решения задачи с оценками.
Эсперанто занимает нишу чистого языка, который можно будет использовать в новых областях человеческого развития, не отягощая себя наследием национальных языков. Например:
Восстановление навыков общения после распада психических функций
Единообразное описание законов международного или космического права
Информирование и журналистика свободная от социальных болезней конкретной страны (привет словам master, black и т.д.)
Изучал эсперанто в армии, пока проходил срочную службу. В свободное время делать было особо нечего, приходилось развлекаться советскими книгами. Язык реально с низким порогом входа.
В этом суть. Никто не спорит со значением английского языка на текущий момент, однако он отягощён своим историческим наследием. Эсперанто — это новая абстракция, которая может помочь решить конкретные задачи. Например, внести ясность в тех областях, где неверное толкование может иметь тяжелые последствия, или упростить контакт с неразвитыми племенами людей. В конце концов, это прекрасный эксперимент, который помогает развивать лингвистическую науку.
Тут прямая аналогия с языками программирования. Есть C язык, который доступен на любой платформе и в принципе способен как-то решить задачи из любой области. Но это не останавливает нас от изобретения новых языков.
Насчёт будущего.
Автоматизация как средство увеличения энергоэффективности имеет один недостаток по определению — она направлена на решение концептуально понятных человеку задач. В этом плане GitHub Copilot никак не двигает технологический прогресс — это просто статистически усредненная коллекциях снипетов, новые концептуальные задачи Copilot решить не может.
Если говорить о реальном технологическом прорыве, будущее наших технологий находится в другой оси, по аналогии с мнимыми числами, за пределами вашего графика. Скорей всего оно не будет учитывать человеческие когнитивные способности, так же как тепловой двигатель не учитывает физические способности человека.
Фантазировать тут можно сколько угодно, но вероятно это будет связано с эффектами квантовых компьютеров, вневременными концепциями и новыми процессами “кибер-эмоций” от взаимодействия человека и информационных систем.
Оба этих параметра когнитивные. Значит любая аналитика на их основе будет зависеть от субъективных представлений аналитика. Это ставит под сомнение научность любых размышлений на их основе, и как следствие, некорректность прикладного применения.
Дело конечно не в том, что Python и Haskell можно легко поменять местами на графике. Сами категории, которые вы выводите через график не более чем иллюстрация вашего личного понимания предметной области. Практического смысла в этом не много.
Но в любом случае статья хорошая, спасибо!
Столько умных книг на картинке, тема интересная. А по сути, вы всё свели к заветам "эффективного" менеджмента.
Организация — подготовка или формирование чего-либо для осуществления деятельности. Например, организовать можно производственный процесс или команду.
Управление — непосредственный контроль и действие. Управлять можно транспортным средством или бюджетом.
Руководство — направление деятельности. Руководитель планирует и контролирует достижение целей, управляет ожиданиями компании и сотрудников, мотивирует.
Управлять людьми можно только в кризисных ситуациях, когда они сами не могут, но ситуация требует немедленного исполнения. В остальных случаях забудьте про управление людьми, они вам не принадлежат.
Если хотите повысить продуктивность — организуйте и руководите людьми. Перфоманс ревью, OKR, KPI будут приводить только к их формальному выполнению на бумаге.
Не стесняйтесь сопоставлять реальные желания и возможности обоих сторон. Не удивляйтесь, если вместо нового фреймворка по плану индивидуального развития, разработчик хочет:
зарплату в два раза больше под нового ребёнка в семье
отпуск на всё лето для гастролей своей рок группы
создать группу по йоге внутри компании
и. т.д.
Если вы сможете совместить эти желания с целями компании, то получите разработчика, который увидит дополнительный смысл сотрудничества, а значит станет производительнее и лояльнее.
Благодаря извращенному толкованию Agile многие менеджеры теперь думают, что для решения задач не нужен анализ, проектирование и планирование — достаточно всем вместе обсудить что-то на созвоне.
Это только упрощает жизнь управленцам, которые привыкли работать по наитию. Соблюдать никакие регламенты и процессы не нужно — можно хоть каждый день свои внезапные догадки вбрасывать в рабочую команду, в зависимости от настроения.
Контроль качества, о котором вы вероятно говорите, достигается с помощью QA инженеров, которые буквально следят за тем, что мы идём верным курсом: цели актуальны, методы достижения эффективны, требования выполняются.
Agile тут ни при чем, обеспечением качества можно и нужно заниматься в любой модели разработки.
Поздравляю, вы переизобрели инкрементную модель разработки, которая, по сути, является улучшенным водопадом, тем самым, которым вас так пугали в процессе принятия Agile веры.
Попробуйте в начало этих месячных циклов также добавить качественное проектирование, вместо бесконечных разговоров с заказчиком на демках — увеличение скорости разработки вас приятно удивит.
Слово «англицизм» пришло к нам толи из французского, толи из из латыни. Это вас не удивляет?
Мне нравится русский язык, стараюсь его использовать по полной. Так что у меня никаких претензий к вашему комментарию и раздражениям.
Поделитесь лучше своими вариантами, что вы используете вместо слов «синк» и «плагин».
Вполне закономерная реакция на сложившуюся ситуацию. Некоторые известные компании превратили процесс собеседования буквально в испытание — экзамен в несколько этапов на пару календарных недель. Не надо удивляться что соискателям приходится набивать руку и тренироваться, чтобы справится с этими испытаниями.
Язык формируется говорящими здесь и сейчас. Если кто-то использовал определенные слова — значит они уже оправданы.
Проблема не в англицизмах, об этом уже миллион раз говорили, русский язык чуть более чем полностью состоит из иностранных заимствований.
Проблема в терминологии и сленге. Вы раздражаетесь, когда чего-то не понимаете и это нормально. Задача грамотного переговорщика использовать тот словарь, который будет максимально понятен всем участникам переговоров.
Например, если вы начнёте говорить с разработчиками, соответственно вашему примеру, словами "независимый программный модуль", "полезная часть продукта", "ежедневная планёрка для согласования деятельности", "поток работы" — негодовать начнут уже они.
Представление руководителя как надзирателя, который сидит высоко, глядит далеко — было оправдано пару веков назад. Тогда общество переходило от рабского натурального труда к индустриальному. Продуктивность всё еще можно и нужно было контролировать физически. Прораб-надзиратель должен был буквально палками гонять работников чтобы те делали рутину.
Позже, надзирателя узаконили, и он превратился в начальника — должностное лицо, которое вместо палки стал использовать нормативные акты и административные наказания для поддержания приемлемой продуктивности работников на заводах.
Сейчас руководитель в IT не начальник, а равноправный участник команды, он ни сверху и не снизу. Его задача организовать, руководить и управлять рабочим процессом. Никакого благородства тут нет, творческий процесс свободных людей физически невозможно и не нужно контролировать если вы хотите получить реальную продуктивность. Этот процесс нужно обеспечивать и развивать.
К сожалению, руководители "старой школы" всё еще пытаются работать в образе начальников. Ваша статья этому прекрасное подтверждение — в ней каждый пункт сквозит авторитарностью и должностной подчиненностью.
Ваш опыт я не оспариваю и не осуждаю, какой есть. Но мне кажется неправильно поддерживать устаревшие представления о роли руководителя в работе IT, даже если это ваша личная история. Молодой и неокрепший руководитель начитается у вас про то, кто и что ему должен и пойдёт на практике подчинять подчинённых. Поэтому поставил вам минус.
Ваше представление сложилось так, потому что "поток" — тоже определенная абстракция, за которой стоят детали реализации. Стоит разобраться, о чем именно мы говорим.
"Системные потоки" — то есть потоки управляемые ОС, могут выполняться буквально и физически параллельно на разных ядрах процессора или разных процессорах. В рамках одного системного процесса или нет. Для этого и придумывают многоядерные процессоры, многопроцессорные суперкомпьютеры, тензорные ядра и сопроцессоры.
"Виртуальные потоки" — разного рода легкие|тонкие|зелёные потоки, тоже могут выполняться параллельно. Представьте что ваша виртуальная машина умеет компоновать несколько виртуальных операций в одну физическую и исполнять за один такт физического процессора, тогда потоки выполнятся параллельно даже на одном ядре. Для этого придумывают всякие Erlang'и.
Проблема планирования времени выполнения этих потоков возникает тогда, когда физический ресурс меньше, чем логический. Если на вашем компе 128 ядер, а системных потоков 512, тогда да, не все из них будут физически одновременно работать, будет оверхед на переключение и так далее.
Об этом и речь. Возвращаясь к вашему изначальному вопросу. Суть не в том, что потоки берут откуда-то дополнительную работу ЦПУ. Суть в том, что дефолтное асинхронное приложение на ивентлупе с одним потоком не утилизирует многоядерный ЦПУ на 100%
Давайте разберёмся.
Асинхронность — свойство операции, которое означает что время выполнения этой операции принципиально не совпадает с ходом времени вашей программы, можно сказать нелинейно. Как правило — это длительные и не дискретные операции: пользовательский ввод, календарное планирование, долгий запрос в базу данных или внешний сервис.
Многопоточность — свойство системы, которое позволяет выполнять несколько операции параллельно, то есть одновременно. В современных компьютерах это физически параллельные вычисления на разных ядрах CPU (отсюда такая гонка за количеством ядер и феноменальная производительность GPU на тензорных операциях).
Напрямую противопоставлять эти свойства некорректно.
Да, дефолтная реализация в Python или JavaScript использует ивент луп - то есть цикл с диспетчеризацией неблокируемых и последовательных операций. Ключевой момент здесь — последовательных. Заметное увеличение производительности происходит только за счёт того, что приложение продолжает выполнение других задач пока ожидает ответ от подсистемы IO (например поток байт из сокета). Но параллельных вычислений при этом не происходит, а значит компьютер не использует все свои вычислительные мощности.
Но, асинхронное программирование можно реализовать, как угодно. Например, в C# дефолтная реализация асинхронщины использует разогретый пул потоков, читай многопоточность. В Python тоже можно запускать async/await на потоках, через какой-нибудь ThreadPoolExecutor.
Таким образом максимальную производительность вы можете получить, комбинируя неблокируемые операции и параллельные вычисления. Конфигураций можно придумать миллион. В одном потоке принимать в расшаренную память данные из сокетов, а в другом их обрабатывать в векторе с кэшем процессора. Ну или запускать несколько ивент лупов, потому что на больших количествах RPS начинают играть даже накладные расходы на диспетчерезацию внутри цикла (так, все асинхронные Python фреймворки в продакшене работают через ранеры которые, сюрприз-сюрприз, запускают несколько потоков или даже процессов для выполнения вашего асинхронного кода).
Использовать при этом сахарный async/await или долбить всё на колбеках — это уже вам решать. Главное, что от физики не уйти, нужно понимать, как работает железо под копотом, о том и речь.