Скрам - это новый ватерфол, который все полюбили, ведь любить нужно новое и модное, а старое и не модное принято презирать. Скрам это лекарство от всех болезней, однако оно не помогает, если его неправильно принимать. Скрам это благословение и проклятие в одном флаконе, дар небес, который мы не заслужили, и наказание за грехи, которые мы не совершали. Скрам проник в самое сердце нашей индустрии, и теперь медленно убивает ее изнутри. Возникает один вопрос.
Каждый раз, когда меня спрашивают: «А как ты вообще пришел к этим заповедям?», я улыбаюсь и вспоминаю одну историю. Она началась не в IT, не в офисе и даже не за чашкой кофе (хотя кофе, конечно, был). Она началась там, где начинается всё важное — в голове одного человека, который однажды осознал, что его жизнь превратилась в бесконечный марафон без финишной черты.
Всем прекрасного вторника, коллеги!
Сейчас 11 ноября - пик кленовой шуршальности и срок когда стоило бы закрыть работы по строительству, потому что строить под дождем, когда по ночам минус - неприятно и больно. Слева дачка моего соседа. Он строит ее уже 6 год и потратил миллионов 10, она еще не накрыта крышей, хотя летом он планировал закрыть тепловой контур. У моего соседа свой бизнес, связанный со строительством, он трудолюбивый, аккуратный и богатый. То есть его компетенции и ресурсы не вызывают сомнений.
Справа моя дачка, внутри нее есть мохнатое кресло, теплые полы, горячая ванна, посудомоечная машина, а в печке горит огонь. Я построил ее за полгода и 2 миллиона рублей и уже 4 год в ней живу.
+
И вопрос, который я бы хотел поднять в этой статье - это почему заведомо более ресурсный и компетентный специалист проиграл в достижении цели некомпетентному и бедному. И вопрос конечно не строительстве дома, а в IT- долгостроях. Всегда ли куча ресурсов и компетентности гарантируют если не коммерческий успех, то хотя бы вывода MVP в продакшн.
Другими словами почему Паша Дуров, командой из 30 человек тянет телегу с миллиардом пользователей за него вступается Илон Маск и Президент ОАЭ, а ты своей командой из 30 сеньоров почти закончил за год фичу, по регулировке сыра в приложухе для заказа пиццы.
Для честности сразу скажу, у меня дом 96 метров, у него больше 350, и я не хочу начинать срач, на тему зачем на даче 4 туалета на трех членов семьи и зачем спальня в 50 метров на 2 этаже. Даже если выкинуть это то путем простой экстраполяции мы понимаем, что дом в четыре раза больше оказался в 10 раз дороже и в 20 раз дольше по срокам.
Привет, Хабр! Все знают про сторипоинты, но мало кто понимает, как и зачем оценивать в них задачи. А между тем это мощный инструмент в руках тимлида, который позволяет предсказывать сроки и контролировать нагрузку на команду.
Загвоздка в том, что популярные методы оценки далеки от практики и редко у кого работают. Команды, использующие их, получают статистический шум и делают вывод, что сторипоинты не нужны. Но проблема-то не в них самих, а в методах оценки.
Меня зовут Алексей Панаэтов. Я руковожу технической командой Центра Геосервисов в МТС Web Services и сегодня расскажу, как мы оцениваем задачи через их декомпозицию, чтобы на выходе получались понятные всем значения без флера «я так вижу».
Привет, Хабр!
Я Иван, за двадцать лет самых разных занятий в области инфотеха успел плотно поработать переводчиком внутри разных удалённых команд, даже поруководил проектом. Людей было не много, но сейчас жалею, что не пользовался одним из этих таск-трекеров, а вёл вручную огромный чек-лист контроля качества текстов.
Сегодня делюсь рейтингом из восьми лучших, перебранных руками, систем управления задачами — именно задачами, причём для небольших и средних команд.
В список попали российские системы управления проектами, которые в том или ином виде закрывают основные нужды любой команды.
Впервые со сложностью согласованного принятия решений менеджеры «Фланта» столкнулись в 2022 году. Компания сильно выросла, и нужно было синхронизировать процессы в разных командах, развивать межкомандные коммуникации, продажи и управление бюджетом.
Число руководителей уже не позволяло выбирать решения единогласно. Мы пробовали собрать рабочие группы по пяти основным направлениям задач, но быстро выяснилось, что их состав недостаточно гибкий. Гораздо более эффективным подходом оказались эфемерные рабочие группы для решения каждой конкретной проблемы. В статье рассказываем, как они появились и работают.
Привет! Я Алина, руководитель разработки конструктора ботов Smartbot. В этой статье я хочу поделиться опытом развития цифрового продукта силами маленькой команды.
Если у вас уже есть MVP и вы даже смогли привлечь первых юзеров, перед вами встает целый ряд интересных задач: нужно разрабатывать новую функциональность, исправлять баги, обрабатывать запросы пользователей и искать способы привлечения новой аудитории. Крупным корпорациям в этом плане неплохо живется — обычно под каждую из таких задач формируется целый отдел. А что делать, если над вашим продуктом работает всего 5-6 человек?
Простого ответа здесь нет, и сама я тоже не нашла большой красивой кнопки, по нажатию которой все процессы налаживались сами собой, а релизы вставали на поток. Поверьте, даже когда вы работаете с крутыми и целеустремленными людьми, при неправильном распределении задач они едва будут успевать разбираться с багами. Оказалось, что для грамотного управления командой недостаточно два раза в день принимать простой советский скрам.
И все же за последний год наша маленькая команда сумела встать на верный путь. Шаг за шагом мы пришли к стабильному результату: сейчас нам удается запускать по релизу-двум в неделю, хотя раньше такая скорость казалась фантастикой.
Сегодня я расскажу о том, как мы этого добились. Не буду грузить вас объемными теориями и абстрактными понятиями (почти), а просто поделюсь практическими действиями, которые помогли именно нам. Вполне вероятно, что и вашей команде они смогут принести пользу.
Привет, Хабр! Меня зовут Светлана Болсуновская, я стратегический коуч-консультант в YADRO. Многие компании перешли на гибридный формат работы, где команды нуждаются в особом подходе для поддержания самоорганизации — процесса, при котором люди выполняют задачи без постоянного контроля руководителя. Я поделюсь своими наблюдениями, почему в современных условиях самоорганизация не происходит «магически» и что должен (и не должен) делать тимлид, чтобы помочь команде достичь этой цели.
В последнее время я стал замечать, что применение подходов Agile в отдельных проектных коллективах стало носить характер религиозного культа. Иногда понимание целей знание названий основных терминов Scrum для некоторых эффективных перспективных руководителей успешно заменяет здравый смысл. Они гордо заявляют о якобы успешном применении методов Scrum в условиях, в которых эти методы в принципе неприменимы. При этом в обоснование своих решений адепты Scrum как догму декламируют положения книги Джеффа Сазерленда «SCRUM: революционный метод управления проектами». Однако кроме основных догматов в некоторых конфессиях существуют другие древние артефакты, посвящённые ключевым заповедям. Вместе с тем эти артефакты не признаются церковью и не включены в канон. Несмотря на то, что авторство этих скрижалей также приписывается основателям церкви, эти документы противоречат основным положениям религии и являются запрещенными для адептов культа. Такие документы называются апокрифами.
Привет, Хабр! Меня зовут Антон, я — тимлид в Ozon. За более чем 20 лет работы в IT, где свыше 15 из них выпало на управленческие должности, меня покидало по разным проектам разработки ПО. Познавая управленческое мастерство, я нередко замечал, как на проектах игнорировали самую важную часть — ориентированность на Клиентов, то есть для кого мы, собственно, эти проекты и продукты реализуем.
Методология Agile как раз и была призвана решить проблему фокуса на Клиенте, где в тесном сотрудничестве с ним создаётся первоклассный продукт. Люди и коммуникации выведены в Agile на первый план, а технологии, можно сказать, не упомянуты вообще.
Проблемы Agile отмечают не только рядовые пользователи, но и такие мастера, как Роберт С. Мартин и Кент Бек — двое из тех, кто составил Agile Manifesto. Как отмечает Ален Холуб, Agile в последнее время стал означать: делать половину задач (активностей) из Scrum плохо с использованием Jira.
В целом все знают плюсы использования данной методологии, но за годы работы я выделил для себя ряд негативных моментов. В данной статье я предлагаю рассмотреть 4 негативных последствия плохого использования Agile, которые, собственно, и подрывают эффективность применения, а также рекомендации, как встроить Agile в понятные бизнесу процессы.
Проблемы я стараюсь рассматривать равнозначно как со стороны бизнеса, так и со стороны IT, поэтому надеюсь, что данная статья будет полезна не только техническим менеджерам, но и представителям бизнес-подразделений.
Итак, подслушано в баре об Agile: некомедия в пяти актах...
Эта статья для тебя, если ты когда-нибудь задумывался о том, сколько получают IT-специалисты в Германии и как это всё сравнить с зарплатами в России. Я расскажу про реальные цифры и поделюсь своим личным опытом переезда.
Я живу третий год в Европе. В апреле 2024 года я начал работать на позиции scrum master в компании ALDI SUD int в городе Мюльхайм на реке Рур.
Мой профессиональный опыт в роли scrum master на апрель 2024 составлял 5 лет.
Сравнивать будем на основе позиции на которой я работал и работаю - скрам мастер.
Цифры и порядок на этой позиции и на других в ИТ в целом соизмеримы.
Всем привет! Я Дима Солодов, инженер по тестированию в Авито. За свой почти десятилетний опыт в тестировании я успел поработать в разных методологиях – от классического «водопада» до современного и эффективного Agile, а именно – по Scrum.
У автоматизации тестирования в Scrum-командах есть ряд особенностей, с которыми приходится сталкиваться или же вовсе преодолевать их при работе над улучшением продукта. Об этом и идёт речь в данной статье.
Меня зовут Сергей Яковлев, я руковожу проектами в ИТ более 10 лет. Хочу поделиться историей о том, как мы сделали проект, который попал в статистические 31 % реализованных ИТ-проектов, и при этом выдержали все базовые показатели: содержание, сроки, бюджет, качество. Причём в начале у меня был минимум знаний в предметной области, команды не было вовсе, а сдать проект необходимо было через год. Здесь я постарался описать весь жизненный цикл проекта, чего я ни разу не встречал в книгах и методологиях, и то, с чем сталкивается руководитель создания продукта.
Наверное, кто-то слышал, что бывает такой человек, как скрам-мастер. Обычно он приходит, ничего не делает, а потом ничего не происходит, и зачем он нужен — вообще не понятно.
Примерно так звучала одна из версий о том, кто такой скрам-мастер, которую я слышала недавно.
А представьте, что есть ещё такая разновидность скрам-мастера, как агент изменений. Это скрам-мастер в сферическом вакууме. В том вакууме, где скрама нет, но ты должен всех вокруг убедить, что он нужен.
Вот про агента и поговорим. И о том, как такому агенту выжить среди тех, кто его не звал и не понимает, зачем он такой красивый нужен.
Дисклеймер. Эта статья — для скрам-мастеров. Если вы не он/она/они — вам будет некомфортно. В статье я рассказываю про здоровье: ментальное, физическое, психическое и прочие «ические». Но если что — вы предупреждены.
Никогда не понимал хейт со стороны некоторых разработчиков в сторону Scrum!
Особенно его много здесь, на Habr. Казалось бы, этот фреймворк придуман разработчиками для разработчиков в противовес классическим многовековым иерархичным ступенчатым подходам к организации труда. В основе Scrum лежат самоорганизация, эмпиризм, бережливое производство. Взрослый подход для взрослых людей. Что здесь может не нравится?
И опирается это всё на Agile манифест, который тоже был создан разработчиками для разработчиков: Роберт Мартин, Кент Бек, Роберт Фаулер и т.д. Знакомые фамилии?
Можно конечно сказать, что тут есть определенное ограничение: Agilе говорит нам, что «над продуктам должны работать мотивированные профессионалы». Так значит всю волну хейта поднимают только зелёные джуны, которых лишили няньки и заставили разделать командную ответственность?
Так вроде нет. Я видел массу случаев, когда молодые ребята активно участвуют во всех процессах, пытаясь понять итоговую ценность разрабатываемого функционала, пытаются найти решения исходя из ценности для пользователя.
Так что позиция «я хочу кодить, а не невотэтовотвсё» совершенно не зависит от опыта. А тогда от чего?
Давайте разбираться.
Привет, Хабр! Меня зовут Владимир Казаков, я руковожу продуктом «Обучение» в МТС Линк. В его основе — решение для вебинаров, с которого мы начали 16 лет назад как самостоятельный продукт. Сейчас наша платформа для обучения решает более широкий круг задач, к ней добавились и новые продукты (Курсы, Формы). Растет ответственность, число вовлеченных команд, но кое-что остается неизменным — сложность с проставлением дедлайнов.
После очередного заруба и обсуждения, кто — продакты или разработчики — определяют сроки и несут ответственность за них, у меня родилось желание расписать все с максимально живыми примерами. Так и появилась эта «тру стори». Под катом — иллюстрация того, как важно взаимопонимание в команде на примере одной отдельно взятой семьи и стандартной бытовой задачи.
Если вы запускали продуктовый проект с новой командой, то точно проходили тернистый путь притирки. Это сложный и порой болезненный период, когда команда только начинает работать вместе, друг друга не знает, а процессы очень далеки от идеала.
Так случилось и с нами, когда мы собрались запускать новый сервис. Команда, которая раньше не работала вместе, словно застряла на месте. Мы месяцами обсуждали архитектуру, переделывали задачи и двигали сроки. С каждой планерки мы выходили с разным пониманием и скрытым недовольством, а потом и вовсе начали конфликтовать.
Этот опыт заставил нас обратиться к теориям командообразования и попробовать найти свое решение, чтобы перерасти этот этап.
Я, Гузель Хамидуллина, системный аналитик департамента управления данными Positive Technologies. Рассказываю, что помогло нашей команде объединиться.
Рассматриваю 10 оставшихся систем управления проектами и задачами, которые могу смело рекомендовать для использования в России в 2025 году. Также помянем тех, кого больше с нами нет. В конце — сравнительная таблица.
Критерии, по которым я составляла рейтинг систем управления:
• Стабильная работа в России. Доступность, легальность, работа без vpn, сервера на территории страны, включение в Реестр российского ПО.
• Актуальность на начало 2025 года. Регулярные обновления системы.
• Наличие русскоязычной техподдержки.
• Разнообразие функционала. Доски, календари, Гант, мессенджеры, отчеты, интеграции, автоматизации. Больше, чем просто todo-списки.
Я нашел свою систему «Личного планирования», о чем я поделился в этой статье и передаю этот опыт студентам курсов по менеджменту в Практикуме.
В этой статье расскажу:
— Зачем начинать планирование в начале дня,
— Почему нужно ограничивать количество задач и блокировать время для их выполнения,
— Какие приложения помогают отслеживать продуктивность,
— Зачем подводить итоги дня и анализировать свою эффективность.
