Управление проектами *

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

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

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

Мы изучили, что происходит в компаниях, и выяснили, почему хорошие специалисты не выдерживают и уходят. Разбираем 5 проблем, которые не компенсируют высокая зарплата и интересные задачи.

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

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

Привет! Меня зовут Ваня Тришкин, я тестировщик в KTS.

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

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

Современный мир буквально погряз в совещаниях. Синки, митинги, созвоны, дейлики, викли… От этих слов порой кружится голова и хочется рыдать, когда видишь забитый календарь. «А когда же работать?» – этот вопрос возникает снова и снова. И ладно бы, если все эти встречи и созвоны приводили к результату, но многие из них оставляют неприятное послевкусие – вроде и собирались, и побрейнштормили, и было сказано много полезного, но по факту не договорились ни до чего, ни к конкретным шагам не пришли, а, если и пришли, то воз и ныне там. И уж совсем становится грустно, когда потрачено время большого количества людей (те пресловутые человекочасы), которые на самом то деле и не нужны были на этой встрече, и могли бы заниматься куда более важными задачами, чем просто «посидеть на звонке». 

Так как же уйти от бестолковых встреч? Есть прекрасная фраза Махатмы Ганди: «Хочешь изменить мир – начни с себя».

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

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

Только как быть, если в вашей команде уже не 5 человек, а 15, и вручную отслеживать данные стало непросто?

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

Под катом рассказываем, как мы начали (и продолжаем) централизованно мониторить эффективность нашего QA-направления. Поэтапно и с практическими советами. 

Когда напьешься — забываешь о жажде.

Японская пословица.

Все возможные операции в космонавтике — например, испытание двигателей, сначала проводятся на Земле. В традиционный набор экспериментов входят изоляционные: группа людей должна жить и работать в замкнутом пространстве с имитацией космических обязанностей. В 2011 году закончился почти 1,5-летний (!) проект «Марс 500». Он показал, как поведет себя малая группа при пилотируемом полете на Красную планету и обратно.

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

Я фронтенд-разработчик в небольшой команде и 2 месяца назад чуть не лишился работы. После двух лет в компании, сотен часов переработок и десятков исправленных багов меня собирались уволить. И они были правы.

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

На этом моя карьера могла закончиться — но я нашёл выход. 

Технологи — особенные пользователи. У них огромная ответственность, руки в перчатках, на лице — защитные очки. В цехе полутемно или светится раскалённый металл, а им нужно отследить сотни параметров техпроцесса. И им очень хочется, чтобы всё работало как часы. Правда, представления об идеальной работе у них сильно отличаются от привычного UI/UX. 

Некоторые мастера внезапно просили нас усложнить интерфейсы. 

Прямо реально усложнить: добавить меню, подменю, передвинуть кнопку, сделать крупнее. Ответ очень простой: они привыкли к старой оракловой системе с интерфейсами из кучи выпадающих меню. Некоторые по 20 лет тыкали в эти менюшки и сформировали мышечную память. Где-то людей просто бесил порядок кнопок, например: «Кнопка «Отменить» всегда была справа. Переставьте, пожалуйста!» 

Аналогично — с горячими клавишами. Если восемь лет назад мастер запомнил, что Ctrl+R означает «Контроль реза», то так и будет нажимать в новой системе, рассчитывая на знакомое поведение. Поэтому мы подняли все старые комбинации и добавили их в новый софт. Теперь работают и новые горячие клавиши, и привычные опытным мастерам аккорды. 

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

В цехах мы узнали ещё много нового про UI/UX, а заодно про себя и свою работу.

Самурай без меча подобен самураю с мечом, но без меча.
Японская пословица.

• Открыть юрлицо (как и любому бизнесу) и прикрутить оплату.
• Запустить ЦОД (у нас несколько площадок, и одна в собственности, потому что там серверы с иммерсионным охлаждением). Там из интересного, например, строительство оптических линий связи.
• И, собственно, соблюсти требования РКН по включению в реестр хостингов.

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

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

Привет, Хабр! Меня зовут Антон, я — тимлид в Ozon. За более чем 20 лет работы в IT, где свыше 15 из них выпало на управленческие должности, меня покидало по разным проектам разработки ПО. Познавая управленческое мастерство, я нередко замечал, как на проектах игнорировали самую важную часть — ориентированность на Клиентов, то есть для кого мы, собственно, эти проекты и продукты реализуем.

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

Проблемы Agile отмечают не только рядовые пользователи, но и такие мастера, как Роберт С. Мартин и Кент Бек — двое из тех, кто составил Agile Manifesto. Как отмечает Ален Холуб, Agile в последнее время стал означать: делать половину задач (активностей) из Scrum плохо с использованием Jira.

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

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

Итак, подслушано в баре об Agile: некомедия в пяти актах...

В очередной раз проснувшись разбитой я поняла: нужно что-то менять. И срочно, пока я окончательно не выгорела. Я прочитала десятки статей по тайм-менеджменту и продуктивности, но советы оттуда почему-то не работали. 

Agile — бог управления проектами последних лет. И неужели он умер? Или многочисленные прожект- и продакт-менеджеры убили его? Разбираемся, почему прозрачность Agile зачастую приводит к хаосу и анархии, а не гибкости и высокой ценности продукта.