Меня зовут Олег, я уже 20 лет работаю в ИТ и в основном на Enterprise-проектах. Сейчас работаю в Альфа-Банке на проекте Альфа-Онлайн и хочу поделиться своим видением управления сложностью на больших проектах.

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

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

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

Если не читали первую часть, настоятельно рекомендую это сделать, чтобы оставаться в контексте.

Итак, продолжим.

Лучший способ понять теорию — получить больше опыта в разных проектах. Для системных и бизнес‑аналитиков я постоянно показываю подходы к работе через публикацию разборов задач: БД, API, Интеграции, требования, и все, что связано с проектированием систем.

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

Постоянно откладываешь дела на потом и не видишь в этом проблемы? Мне это знакомо. Расскажу как не повторить моих ошибок и почему пора это прекращать. Не откладывай эту статью на потом!

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

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

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

• Мой опыт по описанному вопросу
• Проблемы запоминания
• Теоретическое разрешение проблем
• Практическое разрешение проблем с Evernote
• Практическое разрешение проблем с Anki

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

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

Создаем персонажа, который сам решает, что ему стоит сделать с игроком.

В этой статье я познакомлю вас с методикой проектирования искусственного интеллекта под названием GOAP на примере игры Hitman.

Подобные методики редко применяются в СНГ, но более популярны в зарубежных студиях (чаще всего уровня ААА), где есть отдельный департамент разработки ИИ и вместо готовых ассетов проектируются интереснейшие поведения. Но чем плохо начать сейчас внедрять в наш геймдев эти техники и наконец сделать достойную триплэй игру?

Syn ack, Хабр!

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

В преддверии 2022 года я сидел и не думал о Новом Годе, тем не менее, новогоднее чудо со мной все же случилось - ко мне на работу пришел настоящий Дед Мороз (с бородой)! Только в мешке у него были не подарки, а проблемы, которые он надеялся мне доставить. Сначала, дойдя до моего руководства, он пытался очернить мою репутацию, а затем встретился и со мной - этот Дед Мороз не хотел слушать от меня стихи, он хотел, чтобы я наконец удалил статью, написанную  почти полгода назад. С тех пор её настойчиво просят удалить неизвестные мне личности.

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

Взлом компьютера, телефона, электроподстанции, беспилотника или даже целого города – кого этим удивишь?

Взлом мозгов сотен миллионов людей – вот это впечатляет! США, Великобритания и граждане стран третьего мира попали под влияние компании SCL Group и ее дочерних организаций, особенно на слуху была и останется теперь навечно Кембридж Аналитика.

Этот цикл рассказывает историю SCL и ее дочерних компаний глазами бывшего директора по исследованиям – Кристофера Уайли. Перед вами третья часть, и посвящена она различным методикам сбора приватных данных и тому, как команда психологов и аналитиков построила невероятно точную модель американского общества. Удивительно, порой, как плотно гуманитарные науки могут смыкаться с сугубо техническими.

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

Дмитрий Зимин был великим человеком, прожившим три глубоких жизни: инженера, бизнесмена и филантропа. Легче всего его сравнить с Биллом Гейтсом.

Сначала родившийся в 1933 году потомок старообрядческого купеческого рода Дмитрий Зимин сделал блестящую инженерную карьеру, став к закату СССР лауреатом крупных премий, руководителем по разработкам в ведущем радиотехническом институте и замом главного конструктора системы противоракетной обороны вокруг Москвы. Ведь он отлично разбирался в фазированных антенные решётки + был сильным организатором. Тут немного воспоминаний коллеги из тех времён.

В посвободневшей России 58-летний Зимин занялся амбициозными стартапами.

Цитата из Википедии:

"На фоне резкого сокращения оборонных заказов, 6 марта 1991 года зарегистрировал на базе Радиотехнического института малое предприятие КБ «Импульс». Первой разработкой фирмы стала система спутникового телевидения, которая была запущена в серийное производство на Вильнюсском заводе радиоизмерительных приборов (ВЗРИП) и продавалась в московском магазине «Эфир» на Тверской улице, но почти никакой прибыли этот проект не принёс. Следующим проектом была система кабельного телевидения АС-600, она также была запущена в серию и уже принесла небольшой доход. В 1991 году организовал группу технических экспертов внутри Радиотехнического института по разработке сотовой телефонной связи. В 1992 году было создано акционерное общество «Вымпел-Коммуникации», где Зимин стал президентом и генеральным директором"

Ого, три пивота за 1991 год: из оборонки в спутниковое тв, потом в кабельное тв, потом в сотовую связь.

Поиск работы в американских компаниях, особенно с прицелом на будущий переезд – это всегда актуальная тема. Я сам живу в США уже более пяти лет, прошел все стадии профессиональной эмиграции, запустил здесь не один бизнес и нанял немало людей. 

В этой статье я собрал материалы для тех, кто задумывается о поиске сначала удаленной работы в США, а затем и о переезде. В тексте есть описания виз, списки компаний, нанимающих на remote, инструменты для подготовки к собеседованиям. Надеюсь, будет полезно!

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

King’s Bounty II, на первый взгляд визуально простая игра, но в ней сосредоточено огромное множество сложных и комплексных технических решений, продиктованных одновременным выходом на все платформы. Отдельным, и, пожалуй, самым сложным  испытанием для команды стало портирование на Nintendo Switch.

Осторожно, Лонгрид!
Рекомендую заготовить чай с печеньками.
Много интересной информации про очень разные технические аспекты разработки.

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

В этой статье я хочу рассказать о том, как, используя Buttons (Кнопки), Bookmarks (Закладки) и Selection Pane (Панель управления объектами), можно сделать ваш отчет более функциональным, не перегружая его излишними элементами.

Наверное, все сталкивались с таким паттерном проектирования, как Inversion of control(IoC, инверсия управления) и его формой - Dependency Injection (DI, внедрение зависимостей). .NET и, в частности, .Net Core предоставляют этот механизм «из коробки». Очень важным моментом является такое понятие, как Lifetime или, время существования зависимости.
Давайте немного подробней разберемся, какие типы зависимостей бывают, какое время их существования и в чём различия.

Когда вы Когда вы открываете любой сайт — например, google или facebook, вы видите конечный продукт. Но чтобы этот продукт увидеть, и пощупать, нужно:

1. Написать код приложения

2. Собрать проект

3. Поднять его на сервере приложения

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

Привет, я Дарья Двоеглазова, менеджер продукта в Quadcode. В своей предыдущей статье я рассказала об инструментах и методах, которые использовала для планирования и тайм-менеджмента последние 3,5 года. На десерт осталось самое вкусненькое — моя текущая система, которая позволяет мне планировать свои долгосрочные цели и связывает их с планами на завтра. 

На эту систему планирования я начала переходить несколько месяцев назад. Она отталкивается от среднесрочных и долгосрочных целей-желаний. Предупрежу, что система громоздкая сама по себе, переход к ней займет много времени. Например, в первый раз я потратила много времени на конкретизацию и декомпозицию целей. Сейчас мне достаточно от 15 минут до полутора часов (раз в 1-2 недели), чтобы поддерживать всю систему в порядке. Но это время потрачено не зря: теперь я точно понимаю, как сегодняшние дела помогут мне исполнить мечты. И это лучший мотиватор, чтобы вылезать утром из-под одеяла.