Главная » Хабрахабр » [Перевод] Где Agile ужасен, особенно Scrum

[Перевод] Где Agile ужасен, особенно Scrum

Гибкость — без сомнения хорошая вещь, и в манифесте Agile есть смысл. По сравнению с хрупкой практикой под названием «водопад», Agile заметно лучше. Тем не менее, на практике гибкие подходы часто наносят глубокий вред, и в действительности вряд ли здесь уместна дихотомия Agile/Waterfall.

Под «убивают» я имею в виду не «ухудшение культуры», а скорее когда акции компании падают почти на 90% за два года. Я видел, как множество вариантов Agile, называемых Scrum, реально убивают компанию.

Agile вырос из среды веб-консалтинга, где он приносил определённую пользу: при работе с привередливыми клиентами, которые не знают, чего они хотят, обычно приходится выбирать из двух вариантов. Или одолеть клиента: установить ожидания, соответствующую оплату за переделки и поддерживать отношения равенства, а не подчинения. Или принять некорректное поведение клиента (как, скажем, приходится многим дизайнерам) и ориентировать рабочий поток вокруг клиентской дисфункции.
Программисты обычно не очень хорошо работают с клиентами. Мы слишком буквальные люди. Нам нравятся системы с чётко определённым поведением. Это усложняет нам взаимодействие с гуманитариями, потому что мы склонны воспринимать каждый запрос буквально, а не выяснять, что они хотят на самом деле. На корпоративном уровне гибкие методы (вне консалтинговой среды) идут дальше и предполагают, что инженеры недостаточно умны, чтобы понять, чего хотят их внутренние «клиенты». Это означает, что работа распыляется на «пользовательские истории» и «итерации», которые часто лишают нас удовлетворения от выполненной работы, а также любой надежды на долгосрочное видение, куда идут дела.

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

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

Они не продуктивны. Самым вопиющим примером являются офисы открытой планировки. Они антиинтеллектуальны, поскольку люди боятся быть пойманными, читая книги (или просто думая) на работе. В них трудно сконцентрироваться. Офисы открытой планировки вообще не для продуктивности. Когда вы заставляете людей притворяться продуктивными, они на самом деле теряют продуктивность. Стартапы с венчурным финансированием используют такие планировки для демонстрации инвесторам, чтобы офис выглядел занятым. Речь идёт о корпоративном имидже. По разным культурным причинам это сделало вариант открытой планировки «крутым» и «грязным», и теперь он заражает корпоративный мир в целом. (Проще говоря, программист в открытой планировке больше ценится как офисная мебель, а не за код, который пишет).

То же и с программным обеспечением. Хорошо известно, что творческие люди теряют креативность, если их просят объясниться во время работы. Эти системы Agile часто неправильно применяются и требуют унизительной прозрачности работы, несмотря на отсутствие взаимности. Программистам часто приходится работать в условиях односторонней прозрачности. Этот неправильный, но распространённый вариант Agile исключает понятие собственности и расценивает программистов как взаимозаменяемые, одинаковые компоненты. Вместо того, чтобы работать над фактическими долгосрочными проектами, которыми человек мог бы увлечься, они низведены до работы над атомизированными, функциональными «пользовательскими историями» и часто запрещают работать над улучшениями, которые не связаны с краткосрочными, непосредственными потребностями бизнеса (часто спускаемыми сверху).

Это вызывает ненужное беспокойство о микрофлуктуациях производительности человека. Scrum — худший вариант, с глупостью двухнедельных «итераций». Он просто заставляет людей нервничать. Нет абсолютно никаких доказательств, что такой подход действительно ускоряет или улучшает разработку в долгосрочной перспективе. Я в IT-индустрии уже десять лет, как менеджер и как рабочая пчела. Многие в бизнесе думают, что это хороший подход, потому что работа «идёт быстрее». Это неправда.

1. Бизнес-ориентированная разработка.

Agile часто подают в сравнении с «водопадом». Что такое водопад?

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

В свою очередь, Agile довольно часто реплицирует социальную модель дисфункциональной организации без чётко определённой иерархии. Водопад воспроизводит социальную модель дисфункциональной организации с определённой иерархией.

Они имеют значение, и я сам, вероятно, не приму должность ниже уровня директора, но я ненавижу их значение. У меня смешанные мнения о названиях должностей вроде «старший» и «директор», и тому подобное. Эти процессы спроектированы для людей, которые начали программировать месяц назад. Если вы посмотрите на Scrum, он специально лишает прав старших, самых способных инженеров, потому что здесь они обязаны придерживаться установленных процессов (работа только над созданными задачами, 5-10 часов в неделю на планёрках).

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

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

В том числе ввела концепцию «инженерной» компании. Кремниевая долина сделала много ошибок, особенно в последние пять лет, но кое-что сделала правильно. Для инженеров не всегда лучше управлять всей компанией целиком, но когда инженеры управляют разработкой и устанавливают приоритеты, то выигрывают все: инженеры счастливы работой, которую им назначают (или, ещё лучше, сами себе назначают), а бизнес получает гораздо более высокое качество разработки.

Тогда не нанимайте инженеров в штат, если вам нужен талант. Но у вас «бизнес-компания», это нормально. Хорошие инженеры хотят работать в фирмах, управляемых инженерами, где они будут участвовать в планировании работы без необходимости оправдываться перед «скрам-мастерами», «владельцами продукта» и несколькими уровнями менеджеров-гуманитариев. Вы можете получить лучших людей в качестве консультантов (начиная с $200 в час и резко поднимаясь с этого уровня), но не в качестве штатных сотрудников «бизнес-компании».

В конечном счёте, Agile (как практикуется) и Waterfall — формы бизнес-ориентированной разработки, и поэтому ни одна из них не подходит для разработки качественного ПО или мотивации сотрудников.

2. Подчиненённое положение молодых.

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

Там нет варианта «Нам не придётся больше это делать, когда мы достигнем [X]». Проблема с двухнедельными итерациями Agile (или «спринтами») и пользовательскими историями заключается в том, что нет стратегии выхода. Архитектура, НИОКР и развитие продуктов уходят из работы программиста, потому что не вписываются в атомизированные «истории пользователей» и двухнедельные спринты. Предполагается, что эта система навсегда: ориентированные на бизнес митинги никогда не исчезнут.

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

Ну, вообще-то нет. Однажды я работал в компании, где менеджер по продуктам сказал, что разница между старшим инженером и младшим инженером — в способности давать более точные оценки по срокам. Я ненавижу оценки, потому что они генерируют политики и на самом деле не делают работу быстрее или лучше (на самом деле, обычно наоборот). И это даже оскорбительно.

Это заставляет программистов отдавать предпочтение простым вещам низкого уровня, которые на самом деле не нужны бизнесу (даже если неуклюжие менеджеры среднего звена думают иначе), но это «безопасно». Самое худшее в оценках — что они стимулируют выполнение работы, которую можно оценить. Концентрация Agile на краткосрочной ценности для бизнеса в конечном итоге отталкивает людей от работы, которая действительно нужна компании, ради управления репутацией каждого программиста в режиме реального времени. Всё, что на самом деле стóит делать, имеет ненулевой шанс неудачи и слишком много неизвестных параметров для разумной оценки сроков.

Я не согласен с таким мнением. Такая культура наталкивает на мысль, что программирование — это ребячество, от которого нужно избавиться к 35 годам. Мне 30 с небольшим, и я чувствую, что только начинаю хорошо программировать. На самом деле, я думаю, что это вредная мысль. Преследование старших программистов только потому что они достаточно опытны, чтобы знать, что этот гибкий/scrum-процесс не имеет ничего общего с информатикой и что он не добавляет ценности — это ужасная идея.

3. Слишком краткосрочный подход, что глупо и опасно.

Agile предназначен для второстепенных консалтинговых фирм, у которых нет достаточного кредита доверия, чтобы вести переговоры с клиентами на равных, и которые сталкиваются с жёсткими сроками, а каждый клиентский проект является экзистенциальным риском. Он для «маргинальных» аутсайдеров. Но вот проблема: Scrum часто развёртывают в крупных компаниях и финансируемых стартапах. Но люди идут в такие компании, потому что не хотят быть аутсайдерами. Они хотят безопасности. Вот почему они работают в этих компаниях, а не создают свои собственные. Никто не хочет быть позади, если в этом нет значительной личной выгоды. Agile в корпорации означает боль и риск без вознаграждения.

Агрессивное управление проектами имеет смысл в чрезвычайной ситуации. Когда каждый клиентский проект несёт экзистенциальный или серьёзный репутационный риск, Agile может оказаться подходящим решением, поскольку фокус на краткосрочных итерациях полезен, когда компания находится под угрозой и может исчезнуть в долгосрочной перспективе. Это не имеет смысла как постоянная договоренность; по крайней мере, не для талантливых программистов, у которых есть менее стрессовые и более приятные варианты.

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

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

4. Он не имеет никакого отношения к построению карьеры.

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

Мало кто откажется от пары недель неприятной или иной работы, не имеющей отношения к развитию карьеры, если это действительно важно для компании. В чрезвычайной ситуации, будь то консультация, стремящаяся успокоить важного клиента или корпоративная «военная комната», мысли о резюме могут подождать. Если вы можете сказать «Я сидел в штабе и по 20 минут в день общался с гендиректором», это оправдывает выполнение тупой работы. Важность работы здесь приоритет.

Иначе они уйдут. Но если нет чрезвычайной ситуации, программисты ожидают, что их карьерный рост будет воспринят серьёзно. Одно дело сделать тупую работу, потому что гендиректор признал, что неприятная задача добавит миллионы долларов стоимости (и он вознаградит её соответствующим образом). «Я был в команде Scrum» означает, что вы груша для битья. Но если вам просто назначили «пользовательские истории» и тикеты Jira — значит, вас рассматривают как лузера.

5. Цель определить низкие показатели, но при этом неприемлемо высок уровень ложноположительных результатов.

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

Некоторые любят утверждать, что вторжение в частную жизнь, скажем, правоохранительными органами, не является проблемой, потому что они сами не преступники. В дебатах о гражданских свободах часто упоминается распространённая ошибка: аргумент «нечего скрывать». Например, что законы меняются. Эти люди упускают несколько ключевых вещей. Даже для респектабельных людей состояние слежки — это состояние тревоги. Спросите любого, кто был евреем в Центральной Европе в 1930-х годах.

В творческих областях это вредит. Факт наблюдения меняет то, как люди работают. Практически невозможно работать творчески, если нужно отчитываться о работе каждый день.

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

Если ты не «плохой работник», ты ведь не против ежедневных планёрок, верно? Agile и особенно Scrum уязвимы для ошибки «нечего скрывать». Ну, нет. Единственные люди, кто будет возражать против ежедневных отчётов о своей работе с точки зрения краткосрочной стоимости бизнеса — это «бездельники», которые хотят украсть деньги у компании, верно? Очевидно, нет.

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

Одержимость краткосрочными «итерациями» или спринтами означает невозможность опробовать нечто новое, рискованное. Часто от внедрения Agile/Scrum страдают лучшие сотрудники, потому что R&D эффективно устраняется.

Люди знают, кто они. Правда об отстающих сотрудниках заключается в том, что определить их вы сможете без всякого Agile. Это проблема менеджмента на уровне персонала, а не на уровне рабочего процесса. Причина, почему некоторые команды заполняются бездельниками, некомпетентными или токсичными людьми, заключается в том, что никто ничего не делает с ними.

6. Пьяный эффект.

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

Проблема в том, что разница между программистами 7 и 5 существенно больше, чем между 5 и 3. С точки зрения менеджера, который не знает, как работает программное обеспечение, это может показаться приемлемым компромиссом: несколько «примадонн» уровня 7+ покинут корабль под парусом Дивного Нового Scrum, зато 3-ки и 4-ки станут вполне приемлемыми 5-ками. Если вы потеряете своих лучших людей и своих лидеров (которые необязательно находятся на руководящих ролях), то небольшое повышение уровня некомпетентных, для которых предназначен Scrum, не приносит пользы.

По сути, многие люди судят о своих успехах или неудачах не объективно, а исходя из субъективных изменений в статусе. Scrum и Agile играют в то, что я называю предвзятостью к смене статуса. Убедить программиста уровня 5 согласиться на зарплату программиста уровня 3 в стартапе (в обмен на долю в стартапе) психологически расценивается не как потеря денег, а как серьёзная прибавка в статусе.

Её можно достичь, как правило, путём найма людей, которые принесут наибольшую ценность (даже если вы предлагаете на 50% выше рыночной ставки, потому что лучшие программисты стоят в 10-30 раз больше их рыночной ставки). Agile/Scrum и культура дискриминации по возрасту в целом касаются получения наиболее впечатляющей статусной прибыли, а не фактической экономической прибыли.

Вы найдете 22-летнего программиста уровня 6, который думает, что у него уровень 3 и который согласится на Scrum, но 50-летний уровень 9, вероятно, знает, что у него 9 и может неохотно принять условия уровня 8,5, но точно не опустится до 3 или даже 6. Люди, которые меньше всего осведомлены о том, какой социальный статус они «должны» иметь — это молодёжь. Эти пункты ничего не значат. Поиск статусной прибыли, конечно, бесполезен. Может быть, существует целая индустрия в привлечении инженеров 5-го уровня, расценивая (и оплачивая) их как 4, но в нынешних рыночных условиях гораздо выгоднее нанять 8 и относиться к нему как к 8. Вы выигрываете в бизнесе на разнице в доходах и расходах, а не на разнице в бессмысленных пунктах статуса.

7. Нечестная реклама.

Здесь я сосредоточусь на Scrum. Некоторые утверждают, что Scrum является «экстремистским вариантом Agile», а другие — что это самый далёкий вариант от истинного Agile. (Возможно, здесь проявляется одна из проблем: мы не можем договориться о том, что является и не является Agile).

Нечестно говорить, что оно работает везде и на постоянной основе. Решениям вроде Scrum есть своё место: очень ограниченное, временное.

До того, как причуда Agile сделала его постоянным процессом, Scrum означало нечто вроде «красного кода» или «чрезвычайной ситуации». Если бы возникла неожиданная, быстро развивающаяся проблема, вы бы собрали своих лучших людей и сформировали экстренную команду.

Вы не хотите, чтобы он был официальным «менеджером людей» (так как он должен быть максимально беспристрастным). У этой команды не будет чёткого менеджера, поэтому вы выберете лидера (например, “Scrum Master”) и дадите ему полномочия. Это считается «спринтом», потому что люди должны работать так быстро, как могут, чтобы решить проблему, и потому, что им будет разрешено вернуться к своей обычной работе, как только спринт закончится. Поскольку кризис носит краткосрочный характер, карьерные цели отдельных лиц могут быть приостановлены. Основное внимание уделяется миссии и только миссии. Кроме того, в такой чрезвычайной ситуации вам нужно дать понять, что никто не оценивается индивидуально.

Они понимают, что их пометят как «слабых исполнителей», если неделя за неделей отдельные показатели пойдут не так. Когда вы навязываете процесс и требуете односторонней прозрачности всех работников, люди чувствуют, что за ними наблюдают. Это дисфункционально. Такое обижает людей. С другой стороны, если вы собираете группу проверенных специалистов, чтобы справиться с конкретным и ограниченным по времени кризисом, они не возражают против частых отчётов, если понимают, что это острота ситуации, а не их собственный низкий социальный статус, стал причиной этого.

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

Таким образом, Scrum признаёт идею, что иногда власть нужно делегировать «экстренным» руководителям: они будут делать всё, что считают необходимым, чтобы выполнить работу, оставив споры на потом. Всё нормально. Иногда всё должно быть именно так.

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

Проблема с агрессивным настаиванием Scrum на бизнес-ориентированной инженерии заключается в том, что она делает ценностями («сотрудничество с клиентами») привлечение и убийство драконов (известных как «требования»), когда может быть более разумным не выманивать тех из своих пещер. Честолюбивому демагогу (скрам-мастер?) легче проявить себя в схватке с драконами, чем избежать их появления.

Это их главная проблема. Agile и Scrum прославляют чрезвычайные ситуации. Это не позволяет устойчиво работать. Некая версия того, что индустрия видеоигр называет «шоу-тайм». Люди стерпят краткосрочную потерю автономии, но только если впереди будет чёткая точка, когда они её вернут. Агрессивный акцент на индивидуальной производительности, отсутствие заботы о карьерных целях людей при распределении работы и мандат, в соответствии с которым люди работают только на заявленный высший приоритет — всё это даёт большую пользу в краткосрочной чрезвычайной ситуации, но становится токсичным и деморализующим в долгосрочной перспективе.

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

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

Этой культуре подчинённого положения молодых, низкой автономности и агрессивного управления пришло время уйти. Это не просто плохие идеи. Здесь более серьёзная опасность, потому что выросло поколение инженеров-программистов, которые поглощают их, не зная ничего лучшего. Есть слишком много молодых программистов, обречённых на посредственность из-за уверенности в том, что бизнес-ориентированная разработка и «пользовательские истории» — так всегда всё работало. Такое следует предотвратить: от этого зависит будущее нашей индустрии. Agile, по крайней мере, а такой извращённой реализации, как всё, что я видел, — полная ерунда, которая не имеет никакого отношения к программированию и, конечно же, не имеет никакого отношения к информатике. Бизнес-ориентированная разработка в целом — тупик. Её следует бросить обратно в грязь, из которой она вышла.


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Перевезти дата-центр за 14 400 секунд

Всем знакома пословица «Один переезд равен двум пожарам». Смысл этой народной мудрости в том, что процесс переезда сопряжен со стрессами, суетой, переживаниями и, конечно, беготней, которые бывают и при пожаре, а подчас и с утратами ценного имущества. К тому же, ...

Дорожная карта математических дисциплин для машинного обучения, часть 1

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