Управление разработкой *

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

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

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

Привет, Хабр! Я Женя Кучерявый, директор по фронтенду в Rentu. В этой статье расскажу как мы переезжали с Vue2 на Vue3, какие шишки набили и чему научились. Статья не хардовая.

Здравствуйте! Я Александр Шульман, руководитель компании Active, в которой мы уже несколько лет занимаемся амбициозным проектом — пишем продукт для обеспечения кибербезопасности и достигли первых результатов: полгода назад мы получили аккредитацию от Минцифры, попали в реестр отечественного софта и у нас открылись продажи. Я хочу поделиться своим опытом и представлениями о рынке кибербезопасности с вами с позиции управленца, а не от лица специалиста ИБ, хочу рассказать о своих разочарованиях, открытиях и о том, как в итоге у нас в команде родилась идея сделать свой вклад в рынок ИБ. Мне кажется, что это многим будет интересно, т.к. рынок ИТ активно движется в сторону информационной безопасности по причинам регуляции и по причине роста реальных угроз, а значит, все больше менеджеров и управленцев столкнется с вызовами по кибербезопасности.

Как понять, насколько правильно ты оценен, насколько верно оценены люди в твоей команде, соответствует ли оценка приносимой пользе и багажу их знаний и навыков? Стоит ли платить больше за знания, которые в данный момент не применяются и могут никогда не задействоваться? Как правильно оценить опыт? Как не обидеть коллег оценками и сподвигнуть их к саморазвитию, а не переходу в другую компанию? И как не раздуть ФОТ до бесконечности, когда люди открывают охоту за грейдами?

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

Мы часто помогаем клиентам не только с модерацией приложений, но и с регистрацией аккаунта разработчика в Google Play. Казалось бы — что такого? Вводишь данные и готово. Но лицензия платная, а на пользователях РФ санкции. Как в таких реалиях создать аккаунт, чтобы опубликовать мобильное приложение — рассказываем в статье.

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

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

Меня зовут Игорь Буняков, я был фичекрайним за реалистичные дороги в 2ГИС. Недавно они вышли в навигаторе, а позже будут доступны в режиме карт на мобильных устройствах и на 2gis.ru. Реалистичные дороги оказались невероятно большими, невероятно сложными, невероятно красивыми. При этом реалистичность — это не столько про красивость, сколько про функциональность. Мы даём пользователям нашего навигатора новый опыт.

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

«Через пять лет мы увидим решения, которые смогут заменить как минимум 50% программистов уровня junior и middle», ― шокирует один из экспертов недавней дискуссии, прошедшей на Youtube-канале Ai4Dev. Но так ли страшен черт, как его малюют? Более ста тысяч строк кода в секунду, автоматизация рутинных задач, повышение эффективности ― все это уже часть нашей реальности благодаря применению ИИ в разработке. Однако не все согласны с тем, что искусственный интеллект ― это лекарство от всех болезней. «Именно люди двигают компанию. И генеральный директор, и дворник ― каждый вносит свой вклад», ― напоминает другой участник разговора. Так что же нас ждет ― революция или эволюция? Ответы на этот и другие вопросы вас ждут в сегодняшнем новом материале блога ЛАНИТ на Хабре.

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

Всем привет! Меня зовут Саша, я — старший специалист по автоматизации тестирования в компании ITFB Group. По роду своей профессиональной деятельности я общаюсь с большим количеством своих коллег, даю советы, рекомендации, а также занимаюсь упрощением и улучшением процессов тестирования. На одном проекте у нас возникла необходимость уйти от Jira как системы управления тестами, и я взялся за эту исследовательскую задачу, чтобы воплотить ее в жизнь. Всем, кому интересна эта история, — добро пожаловать под кат.

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

Иногда мне кажется, что одни и те же темы поднимаются периодически. Я слышу от нескольких людей одну и ту же тему. Эта статья появилась потому, что в последнее время я неоднократно слышал от клиентов коучинга и тренингов, что их перспективы продвижения ограничены. Лично я пришел к выводу, что во многом это ограничение является самовнушением, а не фактическим ограничением. После того как я объяснил и написал нижеизложенное в электронном письме нескольким людям, я решил, что, возможно, имеет смысл написать это в виде статьи. Так что если я недавно писал вам что-то подобное, спасибо за вдохновение! :)

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

Но есть примеры, когда компании декларируют более “приземленные” и рабочие принципы своей работы или модели действий (никого не рекламирую). Следуют им компании или нет – другой вопрос. Мне было интересно не это, а скорее то, как компании приходят к подобным декларациям. Если и вам интересно это узнать, то делюсь. 

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

Привет, Хабр! На связи Андрей Аврамчук (@Mimizavr). Недавно я побывал на онлайн-презентации GitVerse — платформы для совместной разработки и хостинга кода. Планируется, что она станет инструментом нового поколения, избавляющим разработчика от многих болей. Под катом вы узнаете:

— Чем GitVerse может помочь открытому ПО.

— Почему перенос своих проектов на платформу — это легко и приятно.

— Куда спрятаться от ИИ (спойлер: никуда).

— Умеет ли GitVerse в CI/CD.

— И наконец, какие есть причины смотреть в будущее с оптимизмом.

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

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

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

Привет! На связи Митя Кожевников и Юра Соколов из Mindbox, и это третья, финальная часть гайда по софтам для джунов. В первой части мы говорили о том, что значит «приносить пользу» в разработке. Во второй — об ориентации на результат. В этой части речь пойдет о развитии: что делать, чтобы расти быстрее. 

О гайде. Этот гайд — внутренний документ разработчиков Mindbox. Его писали не один год, опираясь на ошибки тех, кто давно стал мидлами и синьорами. И хотя Mindbox — продуктовая компания с особенной культурой, большинство советов из гайда подойдут и для работы в других командах. 

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

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

«На прошлой неделе McKinsey опубликовала статью под названием «Да, вы можете измерить продуктивность разработчиков программного обеспечения». Эта статья вызвала настоящий переполох в сообществе разработчиков ПО. Кент Бек — инженер-программист и создатель экстремального программирования —написал что «Отчет настолько абсурден и наивен, что нет смысла подробно его критиковать».

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

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

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

Пост не будет ни научной оценкой, ни A/B-исследованием. Это моё личное мнение после разработки игр на Rust маленькой инди-командой (два человека) в попытках заработать достаточно денег, чтобы финансировать процесс. Мы не одни из тех разработчиков с бесконечными финансами от инвестора и многолетним запасом времени. Если вы находитесь в этой категории и получаете удовольствие от многолетней разработки систем, то всё написанное ниже к вам не относится. Я рассматриваю всё с такой точки зрения: «Мне хочется создать игру максимум за 3-12 месяцев, чтобы люди могли сыграть в неё, а я — немного заработать». Статья не написана с точки зрения «Я хочу изучить Rust, а разработка игр — это весело», хотя это и вполне нормальная цель; просто она никак не согласуется с тем, чего хотим мы — заниматься разработкой игр коммерчески успешным и самодостаточным образом.

Мы выпустили несколько игр на Rust, Godot, Unity и Unreal Engine, и многие люди сыграли в них в Steam. Мы создали с нуля собственный игровой 2D-движок с простым рендерером, а также в течение нескольких лет использовали Bevy и Macroquad во многих проектах, некоторые из которых были очень нетривиальными. Кроме того, я бэкенд-разработчик на полную ставку и пишу код на Rust. Этот пост — не какое-то поверхностное мнение после изучения нескольких туториалов или разработки небольшой игры для геймджема. За три с лишним года мы написали сильно больше ста тысяч строк кода на Rust.

Задача этого поста — развеять популярные и часто повторяемые аргументы. Но это всё-таки субъективное мнение; по большей части я написал пост, чтобы не объяснять снова и снова одно и то же. Пусть это будет справочный материал о том, почему мы, скорее всего, откажемся от Rust как от инструмента для разработки игр. Мы ни в коем случае не планируем прекращать создавать игры, просто не будем делать это на Rust.