Рубрика «управление проектами»

Каков C++ в gamedev'e? - 1

Хотел написать продолжение к статье Что почитать игровому программисту? про использование С++ в игровых движках, но размышления свернули куда-то не туда.

Читать полностью »

Была у нас тут история, когда легкий перфекционизм помог привести в порядок конструкторскую документацию и регулярно экономить инженерам кучу дней на прохождение бюрократических процедур. В ее основе – создание системы управления расчетными данными и переход от трудночитаемых и трудноинтегрируемых отчетов Mathcad к гибкой связке Jupyter Notebook с Python и Teamcenter. Но основной рассказ будет про то, как преобразовывать и экспортировать математические формулы, таблицы и другие элементы из Jupyter в красивый и удобный вид.

Читать полностью »
После Мосигры - 1

Я тут 10 лет писал про Мосигру и обещал рассказать, чем кончилась история. Итак, после продажи Мосигры в мае 2019 действующая на тот момент команда слегка подразбежалась. Спецы по рознице остались в сети, я полгода выходил из операционки, плюс была куча ограничений на то, что не всем можно работать друг с другом — и чтобы мы не занимались настолками, консалтингом по настолкам и пропагандой настолок — это набор стандартных условий для того, чтобы мы не объединились за углом и не создали Мосигр~2, чтобы эффективно конкурировать с Мосигр~1. А, зная слабые места своей же конструкции, искушение могло бы быть велико.

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

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

Мы примерно так и сделали.
Читать полностью »

Как мы проходили кризисы 2020-2023 и как заранее готовились к ним - 1
Прикол этого поезда на Шри-Ланке в том, что если смотреть вперёд, повышаются шансы встретиться со стенкой тоннеля

Вообще, 90% работы делается до кризиса: вы занимаете нужную позицию, накапливаете ресурсы, строите информационную сеть. А потом наступает коллизия.

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

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

В общем, у нас создалось полное ощущение, что мы подготовились. Первый же кризис — пандемия-2019 — показал что мы готовы чуть менее, чем никак.

То есть даже на так. Медленные решения мы принимали отлично, а вот тактический уровень очень сильно пострадал. В общем, для начала давайте вернёмся в апрель 2020. Помните те милые времена, когда горела Австралия и какой-то вирус показывал нездоровую контагиозность?
Читать полностью »

День толстой полярной лисички: как построены наши кризисные группы - 1
Это пиесец, да

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

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

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

Итак, в ту субботу примерно в 3 часа ночи наши безопасники (которые не ИБ, а более прикладные) вежливо порекомендовали обратить внимание на ситуацию. Около 5:40 утра глава Липецкой области порекомендовал не ездить в Воронеж, а губернатор Ростовской области — не ездить в Ростов. Информационный поток — это на мне, поэтому я решил, что это не локальная ситуация, нажал на большую красную кнопку и запустил полноценный процесс обработки кризиса.
Читать полностью »

image
Это слябы. Они смотрят на вас с одобрением

Привет с металлургического завода! У нас устроено так: все работают по плану, и на каждом уровне — свой вид планирования. На уровне завода это календарное планирование, а в цехе — графикование.

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

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

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

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

Чтобы 20 января прокат успешно уехал в Иваново, условно 19-го его надо оцинковать и нанести полимерное покрытие. То есть к 19 января у нас на складе должны быть зарезервированы вспомогательные материалы для этих операций, и их нужно заранее заказать и привезти. Чтобы было что цинковать, прокат нужно раскатать и порезать заранее, а чтобы было из чего раскатывать — предварительно выплавить слябы. Для всего этого и сопутствующих операций нужны мощности нескольких цехов: как минимум горячего проката, конверторного производства, холодного проката и покрытия.

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

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

Вот примеры.

1) Например, DRY — don’t repeat yourself. Хорошее полезное правило, но его можно довести до маразма. Из того что я встречал на практике: есть два разных по бизнес-смыслу раздела, которые начинались с простого CRUD, и многие части (и фронта и бека) выглядели во многом абсолютно одинаково. Если их объединить с помощью общей высосанной из пальца абстракции и тем самым избавиться от небольшого дублирования кода, то потом (очень скоро) можно будет сойти с ума, потому что эти две вещи скоро разъедутся, обрастая кастомными фичами, и абстракция будет только вредить. Нельзя абстрагировать неабстрагуемое, даже если DRY нарушен.

«[Немного] дублирования обходится гораздо дешевле, чем неправильная абстракция» — Сэнди Мец

Т.е. DRY — хороший принцип, но бывают исключения.

Читать полностью »

image

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

Системы управления тестированием (они же — TMS) значительно упрощают жизнь команде тестирования. Их десятки разных на рынке. Они нужны для ведения тестовой модели и описания кейсов, их версионирования, интеграции с автотестами и их запуска, сбора данных с них, составления и прохождения тест-планов, формирования разнообразных отчётов.

При большом количестве кейсов (а у нас их несколько тысяч) в тест-плане как автоматизированных, так и ручных тестов без TMS не обойтись.

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

image Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js