Хочешь уверенно проходить IT-интервью?

Мы понимаем, как сложно подготовиться: стресс, алгоритмы, вопросы, от которых голова идёт кругом. Но с AI тренажёром всё гораздо проще.
💡 Почему Т1 тренажёр — это мастхэв?
- Получишь настоящую обратную связь: где затык, что подтянуть и как стать лучше
- Научишься не только решать задачи, но и объяснять своё решение так, чтобы интервьюер сказал: "Вау!".
- Освоишь все этапы собеседования, от вопросов по алгоритмам до диалога о твоих целях.
Зачем листать миллион туториалов? Просто зайди в Т1 тренажёр, потренируйся и уверенно удиви интервьюеров. Мы не обещаем лёгкой прогулки, но обещаем, что будешь готов!
Реклама. ООО «Смарт Гико», ИНН 7743264341. Erid 2VtzqwP8vqy
30 лет назад технологическая индустрия попыталась внедрить бережливые практики, но потерпела неудачу. Вместо «постоянного улучшения» прогресс остановился. Agile несовместим с исследованиями UX, проектированием и масштабируемой разработкой. Так будет всегда. Пришло время создать новые стандарты.
Поскольку стартапы переключаются на «операционную эффективность», давайте подчеркнем, что эффективность — это про способ работы, а не про численность персонала.
Agile-разработка уже более 20 лет является принципом работы № 1 в технологиях, не проверяемым и не подвергаемым сомнению. Тем не менее у него есть фундаментальные недостатки, которые бросались в глаза нам все это время.
Недостаток № 1: Люди — это не машины.
Недостаток № 2: Проектирование — это не переучет.
Недостаток № 3. Продукт не может быть определен тем, что может быть сделано произвольным количеством людей с произвольными навыками и опытом за двухнедельный спринт.
Давайте взглянем назад на то, как мы ограничивали себя во времени:
- 2001 — Agile
- 1995 — Scrum
- 1988 — Lean
- 1960’s — Toyota Production System (TPS)
Начнем с начала

Система TPS развивалась десятилетиями, с 40-х по 70-е годы, что позволило Toyota достичь и сохранить свое доминирующее положение среди мировых автопроизводителей. Эти блестящие начинания были сосредоточены на устранении муда (напрасных трат), мура (непоследовательности) и мури (перегруженности).
Наиболее тщательно документировали устранение отходов. Среди восьми видов отходов наиболее вредными оказались излишки товарных запасов — как готовой продукции, так и сырья, а также простаивающее оборудование. Другими словами, вещи, на которые вы потратили деньги, не приносящие вам денег. Решения Toyota были связаны с материально-техническим снабжением и стали известны как «производство точно в срок».
«Получите материалы вовремя, чтобы сборочная линия обработала их вовремя, чтобы готовый продукт соответствовал требованиям клиентов».
Партнером в совершенствовании TPS был «Путь Тойоты». Эта философия призывала к постоянному совершенствованию, включая преодоление трудностей на пути к долгосрочному виденью, кайдзен (инновациям в операциях) и моему личному фавориту – генти генбуцу. Дословно означая «реальное место, реальную вещь», этот принцип гласил: «пойди и посмотри сам», т. е. принимай соответствующие решения. Он также поощрял подход к улучшению «снизу вверх», сбор информации от каждого сотрудника, независимо от его уровня.
Америка сотворила свое волшебство и превратила «Путь Тойоты» в аналог быстрорастворимой лапши. Ладно, может быть, я несправедлив. Производство «точно в срок» хорошо применялось в США для… производства. Он был переименован в Lean в статье 1988 года «Триумф системы бережливого производства (Lean)» — однако было понятно его происхождение.
Бережливое производство и его предшественники идеально подходят для производства физических товаров, особенно при наличии устоявшегося рынка и зрелого продукта. В основе лежит предсказуемость как спроса, так и цепочки поставок. Когда дело доходит до создания нового продукта, производители полагаются на разные процессы в своих отделах исследований и разработок. Будь то Genentech, разрабатывающая синтетический инсулин, или Proctor & Gamble, разрабатывающая Swiffer, процесс был долгим и довольно линейным. Он включал в себя глубокие исследования и анализ рынка перед разработкой продукта.
Как Waterfall сделали козлом отпущения

Развивающаяся индустрия программного обеспечения в значительной степени следовала этим процессам; применительно к цифровым продуктам они стали известны как методология Waterfall. Термин Waterfall стал универсальным для описания линейного процесса разработки, кульминацией которого являлся полностью реализованный выпуск продукта. Справедливая критика заключается в том, что выпуск большого дорогого продукта все еще может быть неудачным. Таким образом, Waterfall используется для того, чтобы доказать, что итерация, тестирование и реакция на рынок необходимы в более короткие сроки.
В 1990-х специалисты-практики в технологической отрасли изучали способы применения бережливого производства к цифровым продуктам. К сожалению, с самого начала они неправильно диагностировали проблему. Время выхода на рынок важно, но я считаю, что только с точки зрения денежного потока, особенно для стартапов. Сторонники бережливого производства отказались от ненужного, лишившись также полезного. Обратите внимание, что в литературе по Scrum и Agile практически не упоминаются исследования или стратегия. Проектирование получило плохую репутацию из-за того, что в Waterfall тратится много времени. Основы бережливого производства — это сборка и выпуск.
Примерно в это же время произошла битва в стиле Kaiju vs. Mecha (прим.пер. файтинг между монстрами и роботами) между сторонниками бережливого производства и теми, кто практиковал разработку Waterfall. И монстр, и робот не смогли учесть потребности пользователей, а вместо этого растоптали их и уничтожили мир.
В чем разница? Если представить как диаграмму — Agile представляет часть, Waterfall — целое.

Практика повторения существующего продукта на рынке — это роскошь для программного обеспечения — обновления могут быть запущены в любое время; сборочные линии и инструменты не нуждаются в реконструкции. Каждый технологический продукт должен создаваться поэтапно, но он также должен быть создан для достижения конечной цели и полностью реализованного продукта. Успех требует стратегии, исследований, проектирования и генти генбуцу, как и предполагалось в «Пути Тойоты». Аргумент Agile против Waterfall — это ложная дихотомия: компания может иметь долгосрочную стратегию и реализовывать ее, продолжая выпускать продукт постепенно, итеративно.
Ошибка 30-летней давности
Когда владельцы продуктов и инженеры пытались применить принципы бережливого производства к разработке программного обеспечения, они нашли способы имитировать сборочную линию. Требования будут определены как раз вовремя, а затем кросс-функциональная команда будет спешить, чтобы выпустить работающее программное обеспечение. Термин «Scrum» был удачным — он пришел из регби, когда ряд парней мчатся по полю, перебрасывая мяч туда-сюда. Подход к разработке программного обеспечения имеет тот же уровень изящества и стратегии.
Вам всем приходилось иметь дело со Scrum, вот причины, почему он такой, какой он есть:
- Должно быть ограничение по времени спринтом (Sprint), чтобы убедиться, что программное обеспечение может быть выпущено на рынок в «итеративном» цикле.
- Планирование спринта (Sprint Planning) происходит прямо перед спринтом, потому что именно тогда у вас будет понимание того, на чем нужно сосредоточиться.
- Проведение ежедневных заседаний (Daily Standup) для того, чтобы на лету проводить «оперативные улучшения». (Выступать разрешено только разработчикам, дискуссии не допускаются, так как в этом случае техника простаивает.)
- В конце спринта проводить ревью (Review) для просмотра работающего программного обеспечения и определения того, что не было завершено или что нуждается в улучшении.
- Также предполагается проведение ретроспективы (Retrospective) для обсуждения того, что получилось хорошо, а что не очень, в интересах увеличения количества выпускаемой продукции.
- Незавершенные задания (Backlog) не являются основой практики Scrum, это артефакт побочного ущерба и обломков всего, что было выброшено за борт во время спринта.
Вы можете заметить, что Scrum уже довольно нелогичен, но дальше все становится намного хуже.
Несколько создателей Scrum объединились с другими парнями, которые разработали другие методы бережливого производства. Объединив свои усилия, они создали Манифест гибкой разработки программного обеспечения. Марксистский подтекст, вероятно, преднамеренный: они заявляли, что рабочие будут владеть средствами производства.
Манифест хрупкого Agile
Что касается манифестов, то это один из самых жалких документов, когда-либо созданных. В нем перечислены четыре «ценности» и двенадцать «принципов». Возможно, вначале у них были благие намерения — относиться к разработчикам как к людям, а не как к винтикам в машине, — но теперь мы прошли полный круг и уже стало понятно, что принципы превратились в нечто едкое для организаций. Если смотреть сейчас, они представляют собой вариации на тему того, как скрам-группа может снять с себя какую-либо ответственность.
Основные моменты (с моими переводами):
- Люди и взаимодействия важнее процессов и инструментов. (Да, мы будем делать все, что захотим).
- Приветствуется изменение требований, даже на поздних стадиях разработки. (Мы также можем передумать в любое время).
- Проекты строятся вокруг целеустремленных людей, которым стоит доверять. (Оставь нас в покое, бери что есть).
- Работающее программное обеспечение является основным мерилом прогресса. (Тот факт, что мы что-то произвели, имеет значение).
- Простота — искусство минимизации лишней работы — крайне необходима. (Мы собираемся сделать как можно меньше).
- Лучшие архитектуры, требования и проекты создаются самоорганизующимися командами. (Не говорите нам, что делать).
Это не нападение на наших друзей-инженеров. Большинство разработчиков, с которыми я работаю, заботятся о том, чтобы делать работу хорошо, и чувствуют себя обязанными производить качественную работу, основываясь на сроках спринта и обещанных результатах. Тем не менее некоторые техлиды, приобщившиеся к культу Agile, чувствуют себя вполне свободно, следуя вышеуказанным принципам. Требования — это больше предложение, чем правило, проектирование требует интерпретации, все можно вырезать, если конечный результат все еще «работает».
Сочетание принципов Agile и практики Scrum губительно для стартапов. Это оперативные указания руководства; дизайнеры, продакт-менеджеры и инженеры не самоорганизуются и не выбирают такой способ работы. Это все во имя MVP и времени выхода на рынок. Вот что происходит. Каждый. Раз.
Исследования и проектирования создают решения для решения проблем клиентов, но то, что создается, всегда меркнет по сравнению с ними.
Менеджеры по продукту торопятся создать следующий блестящий объект в дорожной карте… только как можно меньше.
С инженерами обращаются как с машинами на сборочной линии, от них всегда ожидают, что они будут производить и поставлять, их поощряют срезать углы, чтобы «сделать это».
Руководству остается только ломать голову, почему продукт такой шаткий и неэффективный.
Далекие от устранения муда, Agile и Scrum создают только потери. Это грязная смесь выгорания, технического долга, долга за проектирование, раздувающийся бэклог, жестко закодированная логика интерфейса и постоянная угроза полного рефакторинга.
Как мы можем выйти из этого цикла?
Просто остановитесь.
Вы не можете впихнуть ориентированное на клиента решение в спринт.
- Определите, что нужно создать.
- Определите лучший способ создания, который позволит в будущем совершать масштабирование и проверки.
- Затем создайте его, сколько бы времени это ни заняло. (Это не займет два года, но и не займет две недели. Релизы можно нарезать на кусочки, пока продукт создается в соответствии со спецификацией.)
- Поощряйте создание продукта превосходного качества, а не «срезание углов».
- Инвестируйте в фундаментальную работу, такую, как системы проектирования и стек чистых технологий, чтобы будущие усилия могли быть более эффективными.
- Инвестируйте в UX и глубину, а не в широту набора функций.
- Правильно инвестируйте в операционную эффективность, а не сокращайте численность персонала и ожидайте того же количества продукции.
Agile можно любить и ненавидеть, но она живет и будет жить. Как вы к ней относитесь?