История о том, как мы практически с нуля запускали стартап, выстраивали в нем процессы, договаривались с нашим первым клиентом, про внезапно горящие сроки, и какие ошибки были допущены по ходу.
А так же на практических примерах и наших ошибках поговорим о плюсах гибких методологий управления проектами.
Привет, Хабр! Это Иван Чаплыгин, руководитель отдела переводов компании КРОК. Сегодня речь пойдет про Agile. Вы, конечно, все на нем собаку съели, а может, и не одну. И сколько agile-коучей обитает на Хабре, одному богу известно. Но в области ИТ-переводов, вечно находящейся на стыке технических и гуманитарных знаний, гибкость оказалась тоже очень кстати. К Agile мы пришли не в результате цифровой трансформации, коучинговых сессий или серии онлайн-тренингов. Все гораздо банальнее. Методом проб и ошибок мы изобрели свой переводческий «agile-велосипед», чтобы ехать с ветерком. Подробности о том, как мы дошли до жизни такой - под катом.
Ваш планинг — фикция? Перестаньте гадать на кофейной гуще: как декомпозировать сложную задачу и оценить сроки, нырнув прямо в код. Инструмент и методика внутри.
В 2025 году процесс управления проектами становится всё более насыщенным и многослойным. Многие команды, привыкшие к GanttPro, начинают замечать, что инструмент уже не отвечает всем их требованиям — и начинают искать что-то более гибкое и дружелюбное.
В этой статье расскажем, почему компании уходят от GanttPro, и покажем современные сервисы, которые могут стать достойной альтернативой.
В Agile есть прекрасная штука, которая называется Daily Standup или «Ежедневный стендап». Короткая ежедневная встреча команды, во время которой каждый сотрудник делится своими достижениями, планами и затруднениями. Эти встречи позволяют держать руку на пульсе и решать возникшие трудности быстро, а так же не терять фокус на текущей работе. Меня зовут Виталий, я хочу рассказать в этой статье о том, с какими проблемами мы столкнулись при внедрении в команде стендапов (хотя казалось бы что‑там сложного) и как их решили. Получилось, на мой взгляд, достаточно просто, красиво и функционально.
В то время как Agile-разработка становится все более популярной, информационной безопасности становится все сложнее с ней взаимодействовать. Результатом этих проблем становится то, что новые системы оказываются незащищенными, либо в них используются наложенные средства для обеспечения безопасности. В этой статье мы рассмотрим, какие сложности возникают при использовании решений информационной безопасности в Agile.
Но для начала рассмотрим, что из себя представляет методология Agile, и чем она отличается от классической Waterfall.
Меня зовут Александр, я CTO компании AppFox. Мы более 10-ти лет занимаемся заказной разработкой и также имеем собственные продукты.
Всем привет, на связи Scrum‑мастер команды eXpress Дмитрий Шугалей. Совсем недавно мы добавили функцию тегов в мобильной версии нашего корпоративного мессенджера (на десктоп‑клиенте они работали уже давно), и еще раз убедились, что это вполне рабочий инструмент организации работы над задачами в проекте. Попробовал сам, поговорил с коллегами — и родилась идея посмотреть, как один из популярных методов повышения личной эффективности «встраивается» в рабочий мессенджер при помощи тегов. Получилась эта заметка как отражение личного опыта и нового взгляда на старый известный подход.
В первой части статьи я коротко напомню суть метода GTD (Getting Things Done), как одного из приемов работы с информацией, который помогает классифицировать рабочие задачи. Далее покажу, как этот метод можно внедрить в рабочую рутину с помощью тегов. А после поделюсь лайфхаками и собственными системами тегов от моих коллег. Статья может быть полезна как тем, кто уже использует теги в рабочем мессенджере, так и тем, кто сомневается в их эффективности или еще просто не попробовал внедрить их в свою рабочую рутину.
Привет, Хабр! Меня зовут Игорь Батулин, я руководитель группы разработки виртуального хостинга в Рунити. Эта статья — не просто рассказ о том, как я люблю рогейн, а пример того, как можно за несколько итераций и в условиях ограниченных ресурсов создать полезный инструмент, действительно помогающий команде принимать решения. Мой рассказ также подскажет, как можно применять Agile-подходы в реальных задачах.
Внедрение Agile «на хайпе» и искаженное понимание принципов манифеста ведет к сырым ненужным пользователю продуктам. Вместе с автором канала Junior PM, Артемом Летюшевым, разбираемся в разнице между настоящим значением принципов и мифами, которые компании принимают за правила и внедряют в свои процессы.
Небольшое интро:
— Недавно наткнулась на видео, где рассказывается старая шутка про переработки. На сотрудника в корпорации все смотрят косо, потому что он несколько дней подряд уходит с работы в шесть. Когда коллектив не выдерживает и предъявляет ему претензию, оказывается, что у сотрудника отпуск.
— Удивительно, но в комментариях была тотальная поддержка «претензий». Одна из цитат, набравшая больше всего лайков: «Если человек отрабатывает от звонка до звонка, например с 9 до 18, то он не заинтересован в этой работе».
— Я крайне редко вступаю в дискуссии под чужими видео, но тут не выдержала)) И была рада, когда увидела непривычное для меня количество сердечек — значит, ещё не всё потеряно.
ИИ повышает эффективность Agile за счёт автоматизации задач, улучшения решений и оптимизации рабочих процессов. По прогнозам Gartner, в скором времени ИИ заменит 80 % ручного труда в управлении проектами, а это означает, что команды Agile смогут быстрее выявлять закономерности, прогнозировать проблемы и вносить коррективы в проекты.
Аналитик живёт в мире противоречий. С одной стороны - методологии, которые обещают навести порядок: SMART, INVEST, MoSCoW. С другой - реальность: брифы, скользкие бизнес-цели и коммуникации в духе “Ну тыжаналитик! Разберись!”
Инструменты вроде SMART, INVEST и MoSCoW помогают систематизировать хаос, структурировать требования, сделать их понятными, оценимыми, удобными для команды. Но если применять их бездумно, то становятся просто декорацией.
Привет, Хабр! Все знают про сторипоинты, но мало кто понимает, как и зачем оценивать в них задачи. А между тем это мощный инструмент в руках тимлида, который позволяет предсказывать сроки и контролировать нагрузку на команду.
Загвоздка в том, что популярные методы оценки далеки от практики и редко у кого работают. Команды, использующие их, получают статистический шум и делают вывод, что сторипоинты не нужны. Но проблема-то не в них самих, а в методах оценки.
Меня зовут Алексей Панаэтов. Я руковожу технической командой Центра Геосервисов в МТС Web Services и сегодня расскажу, как мы оцениваем задачи через их декомпозицию, чтобы на выходе получались понятные всем значения без флера «я так вижу».
Привет! Я Алина, руководитель разработки конструктора ботов Smartbot. В этой статье я хочу поделиться опытом развития цифрового продукта силами маленькой команды.
Если у вас уже есть MVP и вы даже смогли привлечь первых юзеров, перед вами встает целый ряд интересных задач: нужно разрабатывать новую функциональность, исправлять баги, обрабатывать запросы пользователей и искать способы привлечения новой аудитории. Крупным корпорациям в этом плане неплохо живется — обычно под каждую из таких задач формируется целый отдел. А что делать, если над вашим продуктом работает всего 5-6 человек?
Простого ответа здесь нет, и сама я тоже не нашла большой красивой кнопки, по нажатию которой все процессы налаживались сами собой, а релизы вставали на поток. Поверьте, даже когда вы работаете с крутыми и целеустремленными людьми, при неправильном распределении задач они едва будут успевать разбираться с багами. Оказалось, что для грамотного управления командой недостаточно два раза в день принимать простой советский скрам.
И все же за последний год наша маленькая команда сумела встать на верный путь. Шаг за шагом мы пришли к стабильному результату: сейчас нам удается запускать по релизу-двум в неделю, хотя раньше такая скорость казалась фантастикой.
Сегодня я расскажу о том, как мы этого добились. Не буду грузить вас объемными теориями и абстрактными понятиями (почти), а просто поделюсь практическими действиями, которые помогли именно нам. Вполне вероятно, что и вашей команде они смогут принести пользу.
Всем привет! Меня зовут Олег Косарев. Я – ведущий инженер-программист. В группе компаний «Цифра» занимаюсь развитием и поддержкой продукта «Диспетчер». Моя основная специализация – Frontend-разработка.
В данной статье я хочу поделиться с вами нашим опытом по созданию MVP (Minimum Viable Product, «минимально жизнеспособный продукт») редактора аналитических панелей.
Привет, Хабр! Меня зовут Владимир Казаков, я руковожу продуктом «Обучение» в МТС Линк. В его основе — решение для вебинаров, с которого мы начали 16 лет назад как самостоятельный продукт. Сейчас наша платформа для обучения решает более широкий круг задач, к ней добавились и новые продукты (Курсы, Формы). Растет ответственность, число вовлеченных команд, но кое-что остается неизменным — сложность с проставлением дедлайнов.
После очередного заруба и обсуждения, кто — продакты или разработчики — определяют сроки и несут ответственность за них, у меня родилось желание расписать все с максимально живыми примерами. Так и появилась эта «тру стори». Под катом — иллюстрация того, как важно взаимопонимание в команде на примере одной отдельно взятой семьи и стандартной бытовой задачи.
Каждый раз, когда меня спрашивают: «А как ты вообще пришел к этим заповедям?», я улыбаюсь и вспоминаю одну историю. Она началась не в IT, не в офисе и даже не за чашкой кофе (хотя кофе, конечно, был). Она началась там, где начинается всё важное — в голове одного человека, который однажды осознал, что его жизнь превратилась в бесконечный марафон без финишной черты.
Всем привет. Меня зовут Алена и я продакт по профессии, любитель планирования и определенности в душе и рисования дорожных карт в любой ситуации.
Очень давно я чувствовала, что меня распирает от разных мыслей о профессии. Мои друзья больше не хотят слушать мои идеи о работе, и поэтому у меня созрел план поделиться мыслями с профессиональным сообществом и единомышленниками.
Скорость чтения публикации — 10 минут (но, я надеюсь, вы проведете время с удовольствием).
Продакт — идеальная профессия для меня, к ней я шла с одной стороны очень давно, с другой стороны, это было очень естественным процессом, ведь я уже в детстве учила моих игрушечных зайцев и кукол как делать разные задачи по дому, в школе была старостой, для решения личных проблем рисовала схемы развития событий.
Прочитав это, вы можете подумать, «ну а что особенного, ведь многие дети и люди делают это», и будете абсолютно правы. Я убеждена что принципы продуктового подхода мы используем повсеместно в своей обычной жизни, и во многих профессиях, которые на первый взгляд совсем никак не связаны с проектной или продуктовой логикой.
Позже я напишу пост‑знакомство и расскажу о своем карьерном треке, но сейчас я хочу поделиться своими наблюдениями почему и как навыки продуктового подхода мы используем в разных сферах своей деятельности. Возможно, такие сравнения помогут проще объяснить нашим родственникам, что же мы делаем на работе. Или так же это будет полезно для объяснения новым клиентам, чего ожидать от управления продуктами 😊.
Две тысячи двадцать пятый год. Без малого две тысячи лет христианству, четырнадцать веков исламу, истоки культа Матери Моржихи теряются в глубине общественных формаций.
А есть ли что-то более новое и при этом не кринжовое? Есть! Если вы хоть каким-то боком связаны с современным ИТ вы можете наблюдать и даже участвовать в становлении нового религиозного культа.
