Agile *

Привет! Я Алина, руководитель разработки конструктора ботов Smartbot. В этой статье я хочу поделиться опытом развития цифрового продукта силами маленькой команды.

Если у вас уже есть MVP и вы даже смогли привлечь первых юзеров, перед вами встает целый ряд интересных задач: нужно разрабатывать новую функциональность, исправлять баги, обрабатывать запросы пользователей и искать способы привлечения новой аудитории. Крупным корпорациям в этом плане неплохо живется — обычно под каждую из таких задач формируется целый отдел. А что делать, если над вашим продуктом работает всего 5-6 человек?

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

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

Сегодня я расскажу о том, как мы этого добились. Не буду грузить вас объемными теориями и абстрактными понятиями (почти), а просто поделюсь практическими действиями, которые помогли именно нам. Вполне вероятно, что и вашей команде они смогут принести пользу.

Всем привет! Меня зовут Олег Косарев. Я – ведущий инженер-программист. В группе компаний «Цифра» занимаюсь развитием и поддержкой продукта «Диспетчер». Моя основная специализация – Frontend-разработка.

В данной статье я хочу поделиться с вами нашим опытом по созданию MVP (Minimum Viable Product, «минимально жизнеспособный продукт») редактора аналитических панелей.

Привет, Хабр! Меня зовут Владимир Казаков, я руковожу продуктом «Обучение» в МТС Линк. В его основе — решение для вебинаров, с которого мы начали 16 лет назад как самостоятельный продукт. Сейчас наша платформа для обучения решает более широкий круг задач, к ней добавились и новые продукты (Курсы, Формы). Растет ответственность, число вовлеченных команд, но кое-что остается неизменным — сложность с проставлением дедлайнов.

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

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

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

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

Скорость чтения публикации — 10 минут (но, я надеюсь, вы проведете время с удовольствием).

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

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

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

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

А есть ли что-то более новое и при этом не кринжовое? Есть! Если вы хоть каким-то боком связаны с современным ИТ вы можете наблюдать и даже участвовать в становлении нового религиозного культа.

Долго сидела девица и думала: что такого она умеет делать, за что ей платят денюжку. И тут осознала, запускать крупные стрессовые проекты. Быть QA для тревожника - это ну мед, медятина. А если еще ты вечная стартапница, кортизоловые горки обеспечены. Так как браться за объемные проекты, которые нужно было сделать "еще вчера" и при этом не отъезжать в отпуск в пнд?

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

А еще тут набор базовых правил, которые в принципе и так известны человечеству, но как и в случае здорового образа жизни лишним не будет проговорить о главных принципах (иначе откуда было бы столько коучей в нашем времени)?

Смоделируем ситуацию:

Привет, друзья! Пока в соцсетях айтишники зумеры хвастаются шикарными офисами с видом на океан, я просто работаю: развиваю Huntlee — нашу систему автоматизации найма, и строю крепкие связи с удаленной командой, которая работает где угодно: от шумных кофеен до уютных домашних кабинетов. И это моя история.

Software Development Life Cycle (SDLC) — это фундамент, на котором строится разработка. Он помогает выстроить процессы так, чтобы команда четко понимала, что и когда ей нужно делать, а заказчик знал, на каком этапе находится работа. 

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

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

«Нет, это не будет работать»
«Сейчас вообще нет времени на это»

И еще тысяча и одна фраза от людей, которые сопротивляются.

Когда я начинала работать Scrum Master»ом, мне было страшно столкнуться с сопротивлением и менять процессы. Я боялась, что мои предложения не поддержат. Ретроспективы вызывали тревогу, потому что ожидала волну негодования, с которой не справлюсь.

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

Представьте: ваш СТО тратит месяцы на безупречную архитектуру, но пользователи массово уходят к конкурентам с кривым, но быстрым MVP. Знакомый сценарий? Технический перфекционизм vs. продуктовая реальность — вечная дилемма. Разбираем, почему код не равно продукт и как не дать идеальным решениям похоронить бизнес.

Привет всем! Я работаю Agile-коучем, но смотрю за миром вокруг и вижу что ГИИ (генеративный искусственный интеллект) поменяет работу команд разработки. Меня впечатляет то, что происходит. Решил собрать мысли и поделиться своим взглядом на то, что ждёт нас в ближайшие 5 лет.

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

Такая же история с самоорганизующимися командами. Их не бывает.

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

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

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

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

Так почему же популярна идея построения команд без явно выделенного тимлида?
Адепты «теории плоской команды» называют следующие причины...

Не хватает гибкости? Нужен Scrum. Нужно побыстрее выпустить продукт? Нужен Scrum. Нужна самоорганизованная команда? Работай по Scrum. Кажется, что эта методология стала слишком популярной, но при этом не везде работает так, как должна. Почему так — пообщались с сертифицированным Scrum-мастером Дмитрием Ирешевым и узнали, какие проблемы таит в себе этот фреймворк.

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

Практика работы с блокерами позволяет уйти от субъективного восприятия проблем к объективному анализу системы. Она помогает ответить на ключевые вопросы:

Как часто возникают проблемы и какова их продолжительность?
Главная задача, которую я ставил перед собой, — понять, почему может увеличиваться Lead Time, а также:

- Выявлять причины задержек, анализируя данные, а не полагаясь на догадки;,

- Отслеживать повторяющиеся тенденции в блокировках задач;,

- Формулировать выводы и улучшать процессы на основе объективных данных.

Два года назад я разбирала, как планируют расти разные системы управления проектами. За это время рынок перетряхнуло: многие игроки ушли из России, кто-то разорился, кто-то вырос, а кто-то выбрал новую стратегию. 

В этом материале — главное, что произошло с каждой системой к марту 2025 году: что изменилось, сколько заработала (беру последние открытые данные из Rusprofile) и какая стратегия.

Пока это самый полный обзор российского и зарубежного рынка на 60 страниц. Для удобства в конце сделала сводную таблицу.

Итак, поехали.

Привет! Я уже пять лет возглавляю проектное бюро. До этого я работала главным конструктором в различных строительных компаниях. Ежедневно я сталкивалась с проблемами менеджмента в проектных компаниях и мечтала его изменить. В итоге взялась за дело и смогла, так что коллеги из отрасли смотрят на нас с завистью.

Здесь рассказываю о своем опыте, команде, принципах, результатах и факапах.

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

Методов оценки задач с точки зрения трудозатрат и сроков реализации очень много.

Scrum poker, T-shirt, Метод аналогий, Три Амиго ...

Почему в моей команде ни один из этих методов не используется и как мы пришли к точности планирования сроков и трудозатрат 80-90%.

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

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

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

Но давайте разберёмся: а в чём вообще смысл скрама и почему он "не работает" у некоторых?