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

В этот момент мне повезло, и знакомый рассказал мне про систему Дэвида Аллена - getting things done...

В 2022 году из России ушли мировые IT-лидеры, ограничив использование своих программных продуктов. Порядка 100 тыс. работников отрасли покинули Россию.
Как это сказалось на финансовых результатах IT-отрасли?

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

Поэтому в управление проектами всегда должна входить работа с рисками. Поиск их причин и вариантов предотвращения. Иначе одно непредвиденное обстоятельство может погубить весь ваш проект.

Привет! Меня зовут Александр Токмаков, я Head of Product в СберМаркете. Сегодня я хочу обсудить с вами приоритизацию. Я считаю, что это один из главных скиллов в работе продакта, а если ты работаешь в крупной компании — точно главный. Именно поэтому я полюбил приоритизировать, разобрался во фреймворках и выработал свою систему, которая показывает крутой результат: >30% наших фичей улучшают продукт. 

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

То есть налицо противоречие: документация IT-продукта в Agile менее важна, чем сам продукт, но при этом, чтобы продукт был качественно разработан, требования должны быть полными.

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

В настоящее время в интернете много эфирного времени посвящено обсуждению различных достоинств масштабирования Agile и ведущих подходов в этой области: Scaled Agile Framework (SAFe http://www.scaledagileframework.com) и Large Scale Scrum (LeSS http://www.craiglarman.com/Large-Scale_Scrum ).

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

На бумаге …

SAFe основан на работе Дина Леффингвелла (Dean Leffingwell), и был формализован в виде фреймворка в 2011 году. Я работал с Дином в 2008 во время руководства командой консультантов в одной крупной многонациональной компании мобильной связи, помогая им определить и внедрить ранний подход к планированию Agile Release Train (ART)  –  то, что теперь эволюционировало в SAFe.

Под грустное рычание,
Под бодрое мычание,
Под дружеское ржание
Рождается на свет
Большой СКЕЛЕТ для маленькой,
Для маленькой такой компании,
Для скромной такой компании
Огромный такой СКЕЛЕТ!

Привет Хабр!

В своей предыдущей статье про разбор кода победившего в VK Cup'22/23 я описывал как мне удалось ускорить копирование одной картинки в другую в 30 раз с помощью чёрной магии unsafe. Однако я не переставал задаваться вопросом, можно ли увеличить скорость еще больше. Я даже привлёк OpenAI в поисках решения, но он мне помог только с картинкой для обложки статьи. В итоге я нашел способ улучшить код еще в 2 раза. Чем и хочу поделиться.

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

Затронем темы

- Генерация QR-кодов трекинг ссылок под разные UTM-параметры
- Подстановка уникальной трекинг ссылки к кнопкам магазинов приложений с параметрами UTM из query string

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

Но без делегирования полномочий не решается проблема загруженности ТОП менеджмента. Происходит интересная ситуация, когда есть человек “отвечающий” за проект, но все решения принимает ТОП менеджмент. Проблема становиться менее видимой, потому что “виноват” во всех принятых решениях ПМ. ПМ, как правило, ответственный человек, то он упорно ищет причины неудач в себе. В компании могут звучат красивые слова про то, что каждый может повлиять на ситуацию, у нас Lean, Agile и вот это все. Но это только мешает увидеть несоответствие обязанностей и полномочий.

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

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

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

За свою 20-летнюю карьеру я успел поработать и электромонтажником, и разработчиком, и менеджером, и CTO, и даже директором по BigData в Cloud в зеленом банке. За годы успел поменять более 10 компаний и сотню проектов (недавно прям выписывал в эксельку). Не скажу, что поменять проект или компанию для меня как за "хлебушком сходить", и стресс есть абсоютно всегда. Очевидные проблемы: новые люди, новые проекты и задачи, новый офис, - и ко всему необходимо привыкать. А есть и неочевидная проблема: вам по новому проекту могут передать не всю информацию, не из-за злого умысла, а из-за отсутствия методологического подхода к передаче дел. Представляю чеклист для передачи дел по проектам.

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

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

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

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

Вы бы стали читать рецепт из 10 страниц, чтобы приготовить салат? Что-то я сомневаюсь. Схожая ситуация бывает в документации, когда она пишется без шаблона по принципу "чем больше, тем лучше".

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

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

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

Этой статьёй я хочу ещё раз напомнить, как инструменты командного взаимодействия решают проблемы качественной разработки, что ответственность за качество лежит на всей команде и что agile-понятия «Прозрачность» и «Предсказуемость» часто теряются на фоне клепания тасок в Jira. Несмотря на свою очевидность, Agile-практики применяются не везде, где могли бы приносить пользу, либо применяются с ошибками и антипаттернами, противоречащими самой культуре Agile. Я расскажу, с какими сложностями столкнулся на разных этапах распространения этой культуры и что делал, чтобы их преодолеть.

Если вы готовы тащить такие практики или пробовали их, но не взлетело, тоже смело заходите под кат. Буду счастлив, если найдёте для себя что-то новое и интересное.

1. Can’t Unsee

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