Я начала кодить в 12 лет: 2000 год, Turbo Pascal 7.0, привет! Образование у меня тоже техническое, судя по диплому, я должна была стать программисткой. Нравилось ли мне это? НЕТ!
Но IT-сфера – однозначно моё. Поэтому в 2013 году я нашла себя в роли менеджера IT-проектов. Летом 2017 года попала в международную компанию. Менеджерила в проекте “VEON Engagement Platform”, который внезапно «закончили» (об этом можно найти много статей). Так я перешла из Beeline Евразия в Beeline Казахстан.
Меня зовут Катя Тен, и сегодня я расскажу про внедрение Scrum и что я думаю по этому поводу. Скорее всего, эта статья будет интересна менеджерам, Scrum-мастерам, Agile-коучам и тем, кто начинает работать или работает по Scrum в средних и крупных компаниях.
Как мы внедряли Scrum
После закрытия моего проекта компания предложила не уходить, а попробовать себя в Agile, точнее – в Scrum в роли Scrum-мастера. По секрету: тогда я думала, что меня просто не знают куда девать и таким образом сливают =) Я ничего не знала о будущей профессии, понимала, что это «как-то связано с разработкой», поэтому решила попробовать. И втянулась.
2018–2019. До внедрения Scrum продукты разрабатывались по водопадному принципу годами: сначала полгода обсуждений и согласований бюджета, долгий анализ, затем выбор вендоров и наконец реализация, по итогу получаем не то, что хотели.
Решили все-таки попробовать in-house разработку. В качестве пилота запустили новый подход в нашей дирекции (IT): 1 продукт = 1 кросс-функциональная команда. За пару дней прошли с командой тренинг по Scrum, закик-оффились – всё по-фэншую. Итого по окончанию пилота (запуск MVP за 2 месяца) в компании приняли решение запускать по Scrum остальных, а это плюс ещё 5 команд.
Какие проблемы решали:
Бюрократия: бессрочные доступы разрабам на скачивание ПО для работы.
«Выбивали» нормальные ноутбуки, мониторы, SSD, ОЗУ и т. д.
Первый год был сфокусирован на развитие инфраструктуры для разработчиков. По мне – это самое важное. То, с чего нужно начинать.
2019–2020. Команд становилось больше, проблемы, которые мы решаем, – масштабнее. Коронавирус, мотивация, культура, общение. Интересно, что из-за локдаунов спада производительности команд не наблюдалось. Скорее всего, потому что инфраструктура хоть и имела ряд ограничений, но в целом была готова к переводу сотрудников на формат удалёнки. У нас уже практиковали формат гибрида: можно было работать удалённо несколько раз в неделю.
Какие проблемы решали:
Нехватка живого общения и выгорание.
Получение доступов в корпоративные сервисы, обновление сертификатов вне локальной сети.
Фокус был на том, чтобы сотрудник мог работать комфортно – со своего или рабочего ноутбука, не выходя из дома. Плюс нужна была не только техническая поддержка, но и поддержание здоровой обстановки в командах.
2020–2021. Развиваем продуктовый майндсет: от целей через метрики к валидации гипотез. Запускаем SAFe-поезда (Scaled Agile Framework), реинкарнируем Change Agent’ов 2.0 – инициативы, которые влияют на организационные изменения в компании.
Какие проблемы решаем:
Удержание сотрудников. Из-за удалёнки двери в иностранные компании открылись для всех умных и знающих иностранный язык. Рынок программистов из стран СНГ начал меняться. Все, кто как-то мечтал или хотел работать за рубежом, решились на это. Если уехать в другую страну бывает страшно, то сейчас можно поработать на иностранный рынок не переезжая. А если понравится – релоцироваться. Плюс к этому – ЖИРНАЯ зарплата в валюте, с которой мы пока не можем конкурировать. И да, конкуренцию на местном рынке тоже никто не отменял.
Новая стадия выгорания – год без отпусков в 4 стенах, конечно же, доканает любого. Помимо этого, на удалёнке есть возможность пофрилансить. Никто же не видит, чем ты занимаешься помимо основных задач. Фриланс не всегда идёт на пользу. Получается, что ты фигачишь на работе + у тебя есть дополнительная нагрузка. Как итог – идеальное выгорание, с которым потом бороться нам. (Это, скорее, моя гипотеза).
Количество команд выросло до 40, в среднем это около 150 человек, не считая саппорт-функций. Управлять стало очень-очень тяжело. У большинства команд больше двух бизнес-оунеров, соответственно, цели у всех разные. Поэтому сфокусировались на запусках поездов (там, где много пересечений) и дискавери команд со сквозными целями с командами разработки.
Кого и как мы теряем, переходя на Scrum
Дисклеймер: наблюдая за развитием Scrum в нашей компании и у коллег, с которыми часто общаюсь, могу сделать небольшие выводы. Эта статья – моё видение и мнение. Возможно, оно не совпадает с вашим. Поэтому хотелось бы обсудить это в комментариях, пишите – не стесняйтесь!
Незаменимые
Scrum может привести к потере незаменимых членов команд. Как именно? Всё просто – работа спринтами. Люди, не готовые работать в авральном режиме, быстро выдыхаются. Представьте, что каждый день вы должны показать результат. Если результата нет, но при этом вы много чего сделали, это демотивирует. Гиперответственному человеку и перфекционисту, наверное, сложно прийти на DSM без результата.
Такую работу можно сравнить с гончими собаками. Начиная забег, у гончих есть цель в виде кролика. Они бегут на полную мощь, ведь главное – добежать до цели. Кто первый прибежал, тот и победил. Но мало кто знает, что после такой гонки собака не может бегать ещё очень долгое время. Потому что у неё был забег на измор. Чтобы восстановиться, нужно время.
Попробуем переложить это на людей. Каждый раз мы собираемся всеми силами, чтобы сделать этот рывок, а как итог – через год-два в компаниях демотивированные сотрудники, которым ничего не приносит радости и мотивации: ни отпуск, ни новые продукты. Всё потому, что у них не было того самого восстановления: физического и морального отдыха.
Особо хочу подчеркнуть, что это происходит не со всеми. Если правильно выстроить процессы, такого вообще не должно происходить.
Как это лечить самому
Если честно, пока я не знаю. Потому что сама такой была: работала на измор, иногда понимая, что «что-то идёт не так и все задолбало». Но лично у меня есть пара моментов, которые не позволяют работать ручками во внерабочее время:
Муж и маленькие дети. После 6 я полностью занимаюсь семьей.
В выходные – только отдых и никакой работы. Уезжайте подальше от цивилизации, если любите тишину. Тусите в клубах, если любите движуху. Для любого человека важно восполнять ресурсы, и у каждого процесс восстановления свой.
При этом не нужно ожидать от компании или команды, что они за вас что-то порешают, насильно отправят в отпуск, заберут ноутбук, предложат другой вариант и т. д. Мы – взрослые люди. Поэтому прежде всего нужно думать о себе самостоятельно, а не перекладывать это на других.
Уверена, что если вы будете работать в таком же режиме еще парочку лет, то вам захочется запереться подальше от всех и никого не видеть и не слышать.
Что делать организации
Отправлять сотрудников в отпуск вовремя! Не разрешать работать без отпуска.
Если есть дежурства, давать отгулы, а не дополнительные деньги.
Взращивать кадры: брать джунов и околоджунов – тех, у кого есть желание и время.
Не замыкать всё на одном сотруднике. Если внедряете или разрабатываете что-то новое, вовлекайте, как минимум, двух людей.
Прививать сотрудникам привычку делиться опытом и знаниями. Создавайте для них подходящие площадки.
Не наши
Да, Scrum отлично помогает с опознанием: наш и не наш. После перехода на Scrum сразу отвалятся те, кто не подходит компании по продуктовому майндсету.
В каждой команде были те, кто не любит Scrum, как думаете, почему? По моему мнению, Scrum быстро выявляет тех, с кем нам не по пути, это и неплохо, просто каждый привык работать так, как ему комфортнее. Обычно такие ребята сопротивляются всему новому, не любят ивенты, им лишь бы по ТЗ работать и ни с кем не разговаривать, а мы, представьте, хотим, чтобы они с конечным пользователем заговорили и делали то, что нужно конечному пользователю.
На самом деле, майндсет людей поменять можно, если человек сам захочет этого, только важно правильно это сделать.
Рекомендации тем, кто чувствует себя некомфортно в продуктовой команде
Дайте этому шанс! Попробуйте или, как это модно говорить, – пропилотируйте. Только обязательно запишите на старте, какие у вас ожидания от пилота, а в конце подведите итоги. Важно понять, получили ли вы «тот самый эффект» или нет. Кстати, в этом вам наверняка сможет помочь Scrum Master или Team Lead.
Если все-таки продуктовая команда – не ваше, а компания в целом вас устраивает, попробуйте поговорить с руководителем. Расскажите какие у вас сложились обстоятельства, спросите, есть ли альтернативы. Дайте компании шанс, уйти вы всегда успеете.
Спрашивайте на собеседовании, как работает команда.
Что делать организации
-
Решайте на старте, куда лучше определить будущего сотрудника и как это сделать. Для этого можно на старте проверить продуктовый ли майндсет у человека. У меня есть простая задачка для такой проверки:
«Представь, у тебя 100 000 баксов, ты собираешься открывать интернет-магазин вещей/запчастей (неважно, всё зависит от увлечений человека). Как будешь наполнять витрину товаром?»
Из рассуждений или уточняющих вопросов сразу будет понятно, куда лучше определить человека. Если в итоге кандидат решит спросить потенциального клиента, провести ресёрчи, посмотреть на рынок и т. д. – его нужно определять в продуктовую команду. Иначе лучше отправить в другую команду, которая пилит кор-задачи или, например, переписывает чьё-то легаси.
Если все ваши вакансии только в продуктовые команды, человек на собеседовании крут, но точно не про вас – не берите его, пожалейте всех. Когда командные цели разные, вряд ли удастся реализовать что-то крутое.
Если с рынком всё негусто, заранее обговаривайте с кандидатами условия работы, чтобы ожидания соответствовали реальности.
Бюрократия больших компаний
Часть людей уходит из-за бюрократии и внутренних процессов. У нас тоже такое иногда случается: компания относительно большая (4K сотрудников), понятное дело, на каждый чих есть процедуры и куча людей, у которых нужно всё согласовать. Это довольно логично: чем больше людей, тем больше процессов, чтобы управлять этой махиной. Но бывает, что в команду разработки приходит человек из стартапа, и ему сложно.
В корпорации нужно быть готовым к тому, что не всё решается быстро. Те вопросы, которые в стартапе можно решить за один разговор, у нас займет вечность. Мой любимый пример – пересмотр зарплаты согласно рынку. Вроде как рынок изучили, зарплату пересмотрели, но пока согласовывали, рынок в очередной раз убежал.
В общем примеров много, но это не значит, что корпорация – зло и не стоит туда идти работать.
Советы тем, кто пришёл в такую компанию
Не миритесь с тем, что работает нелогично, пробуйте это менять.
Если не получается самостоятельно что-то изменить, эскалируйте выше. И, да, если хочется быстрых изменений, приходите с возможным решением проблемы, а не просто с «нытьём».
Делитесь результатами изменений со всеми заинтересованными лицами – в команде продвигать такие инициативы намного проще, чем в одиночку.
Что делать организации
Если вы нацелены занять определённую нишу среди разработки IT-продуктов (это сфера, в которой быстрее всего происходят изменения), нужно быстрее меняться. Особенно нужно менять процессы, которые уже очевидно не работают или требуют оптимизации.
Такое можно менять в рамках Change Agent’ов. Генерить идеи и change-стори, а потом прорабатывать задачи с теми, кто «держит» процесс. Тут важно помнить, что организационные изменения – это совсем не быстро.
LEAN всему голова. У нас есть целое подразделение, которое оптимизирует процессы, облегчая жизнь другим, вовлекая в это всё всю организацию. Это работает очень круто.
Менеджеры становятся «Do'ерами»
Тут всё просто. Часто менеджеры становятся решателями всех проблем команд. Команды несут и несут свои проблемы, по итогу менеджер становится сотрудником своих сотрудников. Это происходит потому, что никто в команде не готов взять ответственность и начать решать проблемы самостоятельно, без привлечения менеджера, а менеджер не может отказать.
Что делать, если понял, что ты «Do’ер»?
Задайте тому, кто пришёл с проблемой, вопрос: «Что ты пытался сделать до того, как пришёл, и почему это не помогло?» Уверена, часть людей ответит, что не подумал, что можно сделать что-то самостоятельно.
Учите сотрудников приходить с решением, а не с проблемой. Наверняка тот, у кого есть проблема, знает, как её решить, но, например, у него нет полномочий.
Не делайте из себя «узкое горлышко». Всё, что можно делегировать, – делегируйте.
Решайте проблемы согласно приоритету: сколько команд столкнулось с этой проблемой и на что она влияет. Так будет проще понять, за что браться. Применяйте в работе инструменты по приоритезации.
Сделайте свою работу прозрачной. Можно записывать свои таски в JIRA/notion/trello, чтобы у всех команд был к этому доступ. Это спасёт вас от тысячи сообщений: «Когда что-то решится?!»
Не бойтесь просить помощи, если понимаете, что не «вывозите».
За свою работу Scrum-мастером я сделала несколько выводов
-
Всем не угодишь. Иногда нужно смириться даже с потерями «незаменимых». Да, страшно, «Как же мы без него/неё?», «Все развалится на следующий день!!!» и т. д.
Могу сказать на своём примере: ничего не развалится. Да, какие-то процессы будут идти дольше, да, возможно, работа будет не на том уровне, как хотелось бы – но дай шанс тем, кто есть и новичкам. Со временем ситуация наладится. Также немаловажно дать шанс отдохнуть от нас и тому, кто уходит. Иногда человеку нужно посмотреть, как устроено всё в других компаниях, сравнить прошлый опыт с новым и вернуться «домой».
Если есть поддержка «сверху» и поддержка от тех, кто с тобой всегда за любой кипеж (обычно всегда есть пара таких человек) – то море по колено! Пробуйте что-то новое, если то старое не сработало. Все компании разные, а люди – тем более.
Развивайте корпоративную культуру так, чтобы это было «тортом», а не «вишенкой на торте».
Используйте продуктовый подход везде, не только в IT-продуктах.
PS: Scrum ли приводит к потерям?))
Комментарии (112)
Amokmorg
10.12.2021 12:01+11"работа спринтами. Люди, не готовые работать в авральном режиме"
????
DimaVadovov
10.12.2021 12:39+6имелось ввиду, как я понял, на постоянной основе. Есть люди, которые не готовы постоянно так работать
ApeCoder
10.12.2021 14:53+8Как так? Почему должны быть авралы, если команда сама определяет цель спринта и планирует, что будет поставлено?
lamerok
10.12.2021 21:36Наверное потому что есть дедлайн, и сбой скорости спринта приводит к его сдвигу. В итоге, приходится делать всё не останавливаясь, чтобы поддержать нужную скорость.
И ещё, вы всегда прямо точно всё планируете? Особенно новые неизвестные фичи, прямо точно в фичепоинтах угадываете скорость каждого спринта?
t-nick
10.12.2021 23:15+8Из моего опыта 50%-70% спринтов в итоге "проваливаются" по различным причинам: неучтенная сложность, внешние зависимости, болезни и т.п. Но на самом деле это неважно. Важен сам факт пересмотра целей в конце каждого спринта. Если есть дедлайн, то можно пересмотреть подходы, которые не сработали, поискать возможности срезать углы или предупредить менеджмент о том, что в сроки не уложимся заранее, а не в последнюю неделю.
Настоящие дедлайны случаются раз в пару лет (например требования законодательства), все остальные - выдумки эффективных менеджеров, с которыми каши не сваришь при любом процессе.
LARII
11.12.2021 00:05+2Когда спринты перманентны это должно называться марафон. Даже Форест Гамп после перманентного бега устал и ушел домой бросив всех.
t-nick
11.12.2021 14:36В марафоне нет остановок. В скраме они предусмотрены в виде церемоний.
LARII
11.12.2021 15:09О чём тут тема, напомните? Вроде как о том что люди выгорают и уходят от того, что фактические реалии отличаются от модели.
t-nick
11.12.2021 15:27+2И винят в этом скрам. Якобы при вотерфоле или канбане выгореть нельзя.
Я о том, что правильный скрам дает автономию команде в том числе и в планировании. Но бывают и карго культы, которые под видом скрама по факту просто устанавливают регулярные интервалы для удара кнутом: легкий удар каждый день (дейли) и хороший хлесткий удар в конце спринта.
Еще бывает конечно низкое чсв членов команды, что приводит к самобичеванию. В этом случае нужен мотивирующий наставник, сейчас для этого есть отдельная роль - аджайл коач. Я работал с несколькими и могу сказать, что не все аджайл коачи одинаково полезны.
LARII
11.12.2021 15:56Проблема в том, что дезинформирующие данные на входе приводят к чудовищным результатам. Потому как автономия - это самостоятельность. Самостоятельность команды.есть только в опенсорс/пет проектах. В коммерческой или производственной разработке самостоятельности нет. Точка.
t-nick
11.12.2021 17:22Есть много продуктовых компаний, где самостоятельность приветствуется. Бизнес ставит задачи, а команда решает, как их выполнять. Если есть жесткие сроки, то обговариваются варианты, как в них уложиться при имеющихся ресурсах. Но это в Европе, тут переработки и стресс в принципе не приветствуются.
t-nick
11.12.2021 23:55Какая разница в Европе или где-то еще? Компании все разные. Я всего лишь делюсь опытом работы в скрам команде без стрессов и выгорания.
LARII
12.12.2021 00:10Я вас понимаю. Но не верю что вы не видите разницу между работой по скрам в Европе и в наших компаниях. Это примерно как убить человека заточенной зубной щеткой и потом говорить :"Видите, чистить зубы опасно для здоровья".
t-nick
12.12.2021 00:34Я не работал в российских компаниях. Я из Украины, и там разработчиков вообще "носят на руках" из-за перегретости рынка. В Европе не так сладко, но тоже неплохо, в том числе из-за трудового законодательства. Мне сложно, но интересно понять, почему в России до сих пор все настолько жестко.
t-nick
12.12.2021 01:05На всё, что более менее востребовано на рынке, можно найти компанию, где будут носить. Есть масса возможностей по переезду в Киев, Харьков, Львов. У меня нет знакомых из IT, кто жаловался бы на условия труда в Украине. Знаю как минимум пару человек, кто решил не оставаться в европках по вышеуказанным причинам.
LARII
12.12.2021 01:19Есть стеки, где ты будучи на позиции мидла с зарплатой мидла должен сказать сроки выполнения любой доработки любого типового приложения на несколько миллионов строк с массой неизвестного количества легаси-доработок с точностью до часа на любом оборудовании и любой среде и это потом будет использовано как аргумент против тебя.
t-nick
12.12.2021 01:30+1Скорее всего дело не в стеке, а в компании. Обычно такие называют "бодишоп" или "галера". Ну и у мидла конечно выбор не настолько широкий. Я сам через это проходил. Но с позиции синиор открываются все лавры и появляется возможность диктовать условия.
LARII
12.12.2021 01:38Именно дело в стеке. В нем ты вечный мидл, будь у тебя хоть 25 лет опыта и сотни своих успешных проектов, а компании в которых используют "экспертный метод оценки времени выполнения" с перекладыванием ответственности на рядового специалиста называют не галерами, а франчами.
А в нормальной компании по скраму в этом стеке просто спринт за спринтом работаешь нон стоп. 176 часов. Из месяца в месяц.
lamerok
11.12.2021 11:08+1Да, всё так и есть, единственное, когда вы предупреждаете менеджмент о том, что сроки уедут, первым делом начинают выяснять причины медленной скорости, например, много внеспринтоаой работы, мало людей в спринте и т. Д. В итоге принимается некоторое решение, по которому эти проблемы стараются убрать, но гонка остаётся, т. Е вы без передыха из одного спринта а другой делаете задачи и пытаетесь уложиться в запланированное для задачи время.
Бывает, что задача оценена сильно больше, чем есть на самом деле и тогда можно на ней "отдохнуть", но в основном всё наоборот, особенно для джуниоров и мидлов и новых людей в проекте.
А человек он такая натура, если каждый день на скраме ты говоришь, что ещё не сделал, ещё осталось Х-2 часа, хотя рабочий день 8 часов, то и перед командой тебе стрёмно и команда на тебя смотрит, как на лентяя или ламера.
Вот и пытаются всё делать так, чтобы показать, а вот я смог. Но это не нормально и ведёт к перенапрягу.
Менеджеры может и выдумщики, но сроки им дают разработчики, на основании чего они принимают решение, стоит ли вообще проект делать.
ApeCoder
11.12.2021 00:37Планируются обязательные и найситухев фичи. Обязательные фичи стараемся сделать в спринт. Найстухев можно перенести дальше. Соответственно, так и планируем загрузку.
Про дедлайны я уже несколько раз привел ссылку здесь что нет скрамгайде теперь комитмента сделать все фичи а только форекаст.
lamerok
11.12.2021 11:12Дедлайн для фичи то есть, если одна фича зависит от другой, то и будет вам дедлайн реализации ыичи на несколько спринтов.
Роадмап же менджер делают, мол в 2022 вы получите поддержку вот этой нацстухев фичи, а в 2023 вот этой и пользователи ориентируются на это - попробуй не успей во время.
ApeCoder
11.12.2021 13:25Ну если менеджеры комитятся на все-все-все фичи то вам нужен не скрам. Тогда четкие спецификации и никаких изменений после комитмента. Иначе любой процесс будет приводить к срыву.
lamerok
11.12.2021 15:09Тут, скорее соглашусь с вами. Что возможно в таком случае проще использовать водопад
t-nick
11.12.2021 14:45Грамотный менеджмент закладывает риски и мыслит стратегически в том числе и о человеческих ресурсах. Дедлайны ставят либо наивные, либо ушлые, чтобы красиво отчитаться и продвинуться по карьерной лестнице ценой выгорания команды исполнителей.
lamerok
11.12.2021 15:08Ну нет, иногда важно быстро выпустить новый продукт, чтобы быть первым на рынке. И у менджемнта всегда дилема между качеством, стоимостью и временем.
Как говориться, Быстро, Качественно, Недорого, выбери два.
И если менеджмент выбрал быстро и качественно, но очень дорого, то вы и все будут в мыле.
t-nick
11.12.2021 15:14Да, но скрам тут абсолютно не причем.
lamerok
11.12.2021 15:20Почему? Это просто процесс разработки, реализации чего то. Вы вполне можете всё необходимые для реализации к определённой дате фичи распланировать по спринтам. Так же из бэклога выбираете фичи по приоритетам... Всё тоже самое, только фичи заранее известны до определённой даты.
t-nick
11.12.2021 15:39Полностью согласен. Я имел в виду, что не скрам сам по себе создает условия для выгорания.
KoteMilote
12.12.2021 01:25Вот что мешает передвинуть на следующий спринт фичу если она оказалась сложнее чем оценивалась?
svetadanilchenko
10.12.2021 12:41Ну по сути, если ты работаешь постоянными спринтами, то нет времени, чтобы сидеть и тупить полторы недели, а потом за ночь всё быстренько сделать. Слишком всё прозрачно.
TerraV
10.12.2021 12:45+16Нет времени остановиться и подумать а правильно ли мы идём, а можно ли решить проблему проще, а не висит ли на нас грузом неправильное решение с прошлого месяца. Стратегическая слепота это классическая болезнь скрама.
svetadanilchenko
10.12.2021 13:03О, а что с таким делать, кстати. Я для себя, например, не до конца определилась, нравится ли мне работать по скраму, так как пока применяю только в небольших и условно конечных проектах.
TerraV
10.12.2021 13:35+9Если вы с этим что-то можете сделать, вы счастливый человек. Обычно Скрам спускается сверху как серебряная пуля. Вообще если говорить терминами аджайл, есть такое понятие tailoring - адаптация процесса под нужды организации/команды. Правда в связи с тем что Скрам это зарегистрированная торговая марка, любое отклонение от "библии" приводит к тому что вы теряете право называть свой процесс Скрамом.
Если подходить с открытыми глазами, смотрите какие артефакты Скрама вам помогают а какие просто пустая трата времени. Универсальных советов тут нет, т.к. очень сильно зависит от размера команды, проекта или проектов, опыта сотрудников. К примеру у нас на команду из 8 человек в зоне ответственности 20 проектов разной степени легаси. От махровых Java 1.5 до Spring Boot 2.6. В таких условиях ретроспективы и командные стандапы это пустая трата времени (слишком широкий скоуп). Чем короче спринт, тем выше накладные расходы на распланировать/подвести итоги. Чем длиннее спринт, тем хуже утилизация команды.
Держать спринт закрытым - продуктовые горящие баги будут футболиться в бэклог (знаю примеры таких команд). Дать возможность докидывать срочные таски - получается хаос а не спринт. Разделить команды на разработку (Скрам) + техподдержку - придется набирать больше людей. Когда в спринте гетерогеные команды (бэк + фронт + аналитик) очень сложно обеспечить равномерную загрузку каждому. При уходе человека из тимы идёт сильная просадка скорости из-за несбалансированности. С учетом текучки кадров в ковидную эпоху, скрамовские команды постоянно недоукомплектованы и тем оправдывают свою низкую эффективность.
Для меня лично наиболее удобный вариант - помесь канбана и водопада. Канбан многополосный по сути и мне комфортно переключаться между свимлайнами если у меня затык на внешней стороне (доступ, доп. информация, UAT) Водопад позволяет "просеивать" фичи через сито заинтересованных. Но как я уже писал выше, у нас условия достаточно экзотические так что рекомендовать не буду.
ApeCoder
10.12.2021 14:47Держать спринт закрытым - продуктовые горящие баги будут футболиться в бэклог (знаю примеры таких команд). Дать возможность докидывать срочные таски - получается хаос а не спринт.
В скрамгайде написано, что можно добавлять таски в спринт при условии, что они не ставят под угрозу цель спринта.
Ilusha
10.12.2021 13:15+4Agile - это про гибкость.
Scrum-команда может и должна поменять свои процессы так, чтобы всем членам было комфортно.
Но почти все забывают о том, что «люди важнее процессов»: мы получаем карго-культ и стратегическую слепоту.
А ещё у нас есть аутсорсинг всякий, который использует итерации для удобства клиента: смотрите как мы быстро работаем. Очевидно, что здесь проблема не в скраме.
P.S.: остановиться и подумать - это встреча команды на пару часов. Очевидно, что проблема не в скраме. Вы точно работали по нему?
TerraV
10.12.2021 13:42+1>> P.S.: остановиться и подумать - это встреча команды на пару часов. Очевидно, что проблема не в скраме. Вы точно работали по нему?
Какой-то вы скорострел. Мне пары часов не хватает. Иногда нужен день, иногда неделя.
ApeCoder
10.12.2021 14:35Возможно разные задачи. Есть фоновое думание, есть сфокусированное думание. Обычно задаи не требуют сфокусированного думания и только его в течении недели, нет?
Либо это рождение каких-то артефактов типа дизайнов либо это исследования.Исследования и дизайны вполне могут быть частью беклога.
JustDont
10.12.2021 14:54+1В "остановиться и подумать" главное — остановиться, а не подумать. Думать-то вы всегда думаете (надеюсь). Но чтоб подумать на дальнюю перспективу, надо для начала прекратить думать на короткую.
ApeCoder
10.12.2021 15:56И вы останавливаетесь на несколько дней и думаете не производя при этом никаких артефактов?
Angeld
10.12.2021 16:18зачем для этого останавливаться на несколько дней?
в чем проблема собраться на пару часов обсудить как это лучше реализовывать? и запланировать необходимое время на реализацию этого?
Kanut
10.12.2021 16:20Хм, а в чём конкретно заключаются претензии к скраму в этом контексте? То есть он вас по хорошему даже обязывает это делать минимум один раз за спринт.
Angeld
10.12.2021 16:28+1вот мне тоже непонятно, откуда в скраме обязательный авральный режим и отсутствие планирования реализации
то описано больше похоже на то , что команда в оценке никак не участвует, все сроки спускают сверху, и сроки такие, что ничего кроме костылей сделать не получается
Gasaraki
10.12.2021 22:40вот мне тоже непонятно, откуда в скраме обязательный авральный режим и отсутствие планирования реализации
Потому что при планировании спринта все забивают на принцип Парето - 20% усилий дает 80% результата. Поэтому забивают время в спринте под 100% и получают аврал (т.к. будут накладываться мелкие проблемы, несогласованности и т.п.) и выгорание.
Ilusha
13.12.2021 00:13Тут проблема даже не в этом. Достаточно убрать восприятие спринта как строгих сроков: его не нужно закрывать на 100%.
Ставить себе рамки для гибкости, а потом делать эти рамки строгими - это как-то нелогично в моей системе ценностей
Ilusha
10.12.2021 15:21+2Вы можете за пару часов обсуждения с командой выстроить план "как выяснить, что и не так"?;
Вы можете взять на весь спринт задачу "research этой проблемы" и думать только об этом.
kalombo
10.12.2021 13:50+1Если "люди важнее процессов", могу ли я считинговать и запланировать на спринт очень маленькую задачу, которую точно сделаю за пару часов и при этом у меня не будет давления дедлайнами и я оставшуюся часть спринта буду работать в комфортном для себя режиме?
ApeCoder
10.12.2021 14:17Если "люди важнее процессов", могу ли я считинговать и запланировать на спринт очень маленькую задачу, которую точно сделаю за пару часов и при этом у меня не будет давления
Я не скрам мастер, но по гайду
Topic Two: What can be Done this Sprint?Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint. The Scrum Team may refine these items during this process, which increases understanding and confidence.
Соответстенно вы лично не можете, но у вас есть совещательный голос как разработчика.
См также:
https://www.scrum.org/resources/commitment-vs-forecast
One of the most controversial updates to the 2011 Scrum Guide has been the removal of the term “commit” in favor of “forecast” in regards to the work selected for a Sprint.kalombo
10.12.2021 14:50+2Ну то есть как в меме про сбербанк. "Люди важнее процессов, скрам это про гибкость, а не про дедлайн, есть ретро, планирование, нет никакого давления, вы просто его неправильно используете". А по факту: "Продолжаем работать в авральном режиме"
JustDont
10.12.2021 14:57+1По факту в сбере оно "Другое подразделение вывалило на вас новые требования посреди спринта? Ну, это ваши проблемы. Таких подразделений не одно, а десять, и с новыми требованиями приходят они не по одному? Всё еще ваши проблемы (с)".
ApeCoder
10.12.2021 15:58Проблема была бы, если бы требования надо было сделать в этом же спринте. А так оно откладывается на следующий.
JustDont
10.12.2021 16:48+2Я не знаю, кому и что вы пытаетесь доказать, но нетрудно заметить, что по факту оно так и происходит.
Подобные требования внешних сил — это отдельное от команды явление, и ни в какие спринты оно не укладыватеся (еще бы, у сбера этих работающих-типа-по-аджайлу команд — сотни, и расписание у всех разное). В этих условиях вопрос "когда это надо сделать" вообще никак не связан (и не может быть, чисто исходя из вводных) со спринтами. Если повезет, то да, можно будет отложить, сделать, вот это всё. Если повезет.Kanut
10.12.2021 16:52Ну так если у вас регулярно есть такие "требования внешних сил", то вы резервируете под такое слоты в спринте.
Либо если их много и/или они абсолютно хаотичны, то просто ищите вариант работать вообще без особого планирования. Потому что вам всё равно тогда не удастся ничего нормально планировать. Ни в скраме, ни в водопаде, ни ещё где-то.
ApeCoder
10.12.2021 18:07В том что я наблюдаю, требования об других команд возникают в середине спринта но при этом обычно выполняются в следующем.
Бывают срочные баги, но очень редко срочные новые требования.
Возможно, вам подходит что-то типа канбана
Kanut
10.12.2021 15:30Ну вообще-то там написано "Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint."
То есть в "ванильном" скраме именно разработчики(а точнее "команда разработки", то есть вместе с тестерами и всеми остальными) решают что будет делаться в спринте. Product Owner может максимум влиять на приоритеты. Но не на объёмы.
Ilusha
10.12.2021 15:28Смотрите, как это работает:
- PO: эта задача влезет в спринт?
- devs: да
- PO: а эта?
- devs: нет.
- PO: а эта маленькая?
- devs: да.
Решает команда. Если она доверяет вашим суждениям, то ваш совещательный голос превращается в последнее слово.
nin-jin
10.12.2021 16:34+2На самом деле оно выглядит скорее так:
РО: эта задача на сколько потянет?
Девы: хз, может на пол дня, может на неделю.
РО: вы неделю будете делать 1 простую задачу?!?
Девы пол часа играют в покер и пытаются друг друга переубедить
Девы в итоге приходят к тому, что с 90% вероятностью сделают за 1 день.
РО: отлично, берём в спринт вот эти 5 задач по 1 дню.
С вероятностью 40% спринт провален.
Kanut
10.12.2021 16:38Ну во первых "РО: отлично, берём в спринт вот эти 5 задач по 1 дню." это уже не скрам. РО ничего никуда не берёт.
А во вторых ну случилось так один раз. Ну два. Ну три. Но рано или поздно "девы" должны понять что оно так не работает. Ну если они совсем не идиоты...
nin-jin
10.12.2021 17:13+2Вы своей придиркой прекрасно продемонстрировали, как вроде бы не совсем идиоты, могут обсуждать несущественные детали часами без полезного выхлопа.
А вы где-нибудь видели в скраме использование теоремы Байеса для оценки выполнимости спринта?
Kanut
10.12.2021 17:15А вы где-нибудь видели в скраме использование теоремы Байеса для оценки выполнимости спринта?
А вы считаете что без этого вот никак нельзя найти способ адекватно оценивать объёмы работы на пару недель вперёд?
П.С. Да и какой толк вам будет от теоремы Байеса если вероятности всё равно из пальца высосаны? :)
nin-jin
10.12.2021 17:25+2Теорема Байеса говорит, что даже зная точную вероятность выполнения отдельной задачи к сроку, мы не сможем обеспечить приемлемую вероятность успеха спринта просто складывая оценки отдельных задач без многократной перестраховки. Грубо говоря, можно достаточно уверенно утверждать, что за рабочую неделю будут выполнены лишь 2 однодневные задачи. Неуверенно - ещё одна. А если взять 5, то точно что-то будет либо не доделано, либо сделано спустя рукава.
Kanut
10.12.2021 17:27+1Ааааа. Вот вы о чём. То есть мы просто перестаём планировать в ИТ и всё. Ну ведь если мы уж спринт в скраме спланировать не можем, то про всякие водопады и заикаться не стоит. Я правильно вас понял?
Единственное что я не понимаю это как тогда куча фирм и команд умудряется более-менее нормально планировать свои спринты и релизы? :)
nin-jin
10.12.2021 17:41+3А очень просто: фиксируется дедлайн, и либо объём работ является неопределённой величиной, либо качество. А если сильно не угадали с дедлайном - начинаются разборы полётов в духе "вы же закоммитились, чего вы так медленно/некачественно работаете?".
Kanut
10.12.2021 17:45Вообще-то всё ещё проще: если что-то из запланированного не усправают сделать, то просто не успевают и всё. Это легитимно, хотя и не особо привествуется. Если такое происходит часто, то просто начинают планировать немного более "пессимистично".
По крайней мере так было в тех фирмах где я работал со скрамом.
nin-jin
11.12.2021 01:39Как забор ни перекрашивай суть остаётся одна: либо этот прогноз бесполезен для всех, либо у людей так или иначе будут ожидания касательно объёма+сроков и они будут расстраиваться, когда они не будут оправдываться.
ApeCoder
11.12.2021 13:51Наверняка есть такие люди, которые бесятся от любого несоответствия прикидки и реальности. Интересно, что вы даже не допускаете существования людей, которые относятся к прикидкам не так как вы.
Как это происходит у нас. Команда комитится на несколько фич в спринт. Может даже на ноль. Обычно это жесткие зависимости. Остальное время делают найс ту хев фичи. Они облегчают жизнь пользователям, но в принципе не срочные. Если за спринт сделаны не все найс ту хев фичи, то это ок.
После нескольких спринтов новичок понимает, что можно не успевать найстухев и все ок и не особо парится.
Ну бывают иногда гиперответственные которые парятся на любое несоответствие реальности картине мира.
ApeCoder
11.12.2021 14:03Да. Еще пробовали в конце спринта пытаться затолкать фичи со срезанием углов по качеству, но оказалось, что потом себе дороже. У нас баги в проде довольно дорого стоят и расмотрев на ретроспективе пришли к выводу что лучше бы фичу отложили но выпустили качественно
nin-jin
11.12.2021 16:01вы даже не допускаете существования людей
А я-то тут при чём?
Как это происходит у нас. Команда комитится на несколько фич
Зачем?
ApeCoder
12.12.2021 11:48-2А я-то тут при чём?
Вы же сказали "либо у людей так или иначе будут ожидания касательно объёма+сроков и они будут расстраиваться" соответственно именно вы и не допускаете
Зачем?
Обычно это зависимости (другой команде нужно к какому-то сроку), новые требования законодательства или публичные обещания руководства. Бывает есть крупный заказчик, который не будет внедрять продукт, если там нет какой-то фичи и с ним договорились.
p0st
10.12.2021 21:54Из практики решения, мы жили в скрамбане не брезгуя всем тем, что нам дал вотерфол и PMI - до начала спринта менеджер/мастер просчитывал ёмкость команды с учётом занятости каждого.
Техлид максимум 20-30% времени может потратить на разработку, у всех есть свой скил, который со временем отрастает + поправки на "Серёга переболел ковидом, -40% от его способностей на месяц".
Дальше само распределение по типам задач или корзинам, есть общая ёмкость, в ней 20% резерва, 10% на пиздец, остальное на отдельные эпики 50% и 20 на поддержку (может меняться в зависимости от целей спринта).
Соответственно больше ёмкости задач не бралось ни под каким видом, если что-то срочное залетает после/во время, то с согласования с бизнесом выносится, что-то равнозначное.
И да на каждой колонке тоже есть ёмкость и навалить 40 задач на 150 дней в тест, когда там два живых человека нельзя. Система не даст, но тестирование и его учёт внутри планирования отдельная история.
marshinov
11.12.2021 00:52А есть англоязычная стать с картинками для самых маленьких на эту тему? Мне бы для заказчиков ой как пригодилась:))
Ilusha
10.12.2021 18:36С вероятностью 40% спринт провален.
Да хоть с 100%. Какая разница, от точности оценки скорость не изменится.
"Провальность спринта" - это уже к эффективному менеджменту.
Ilusha
10.12.2021 15:26А что вы будете делать, если не взяли задач в спринт?
По сабжу, аджайл еще и про то, что "команда состоит из мотивированных профессионалов".
И в спринт берет задачи команда, а не вы лично. Поэтому к вам возникнут вопросы от коллег: самоорганизация. По сути, отсутствие ролей "начальник/лид и т.п." компенсируется большей личной ответственностью и необходимости мотивации от членов команды.kalombo
10.12.2021 15:33+2А что вы будете делать, если не взяли задач в спринт?
Брать задачи из беклога по порядку? Я понимаю стармодно, но что делать :)
И в спринт берет задачи команда, а не вы лично. Поэтому к вам возникнут вопросы от коллег: самоорганизация. По сути, отсутствие ролей "начальник/лид и т.п." компенсируется большей личной ответственностью и необходимости мотивации от членов команды.
Самоорганизация, личная ответственность, отсутствие начальников вообще никак не связаны со скрамом. Могут быть любые сочетания этих параметров со скрамом или без.
ApeCoder
10.12.2021 16:05+2Брать задачи из беклога по порядку? Я понимаю стармодно, но что делать :)
Это модно, но только в Канбане )
Kanut
10.12.2021 16:16Брать задачи из беклога по порядку? Я понимаю стармодно, но что делать :)
Это хорошо работает когда вы один или у вас одна команда от которой никто не зависит. Тогда вы можете просто спокойно так работать.
Но если от вас зависит кто-то ещё, то ему обычно нужно хоть какое-то планирование. Хотя бы на пару недель вперёд.
p0st
10.12.2021 21:56как вариант, возможен скрам скрамов или классические инструменты проектного менеджмента вроде диаграмм Ганта поверх
Ilusha
10.12.2021 18:05Ну что значит "по порядку"? Порядок определяет PO на планиниге. Вы не знаете, какие задачи нужно взять, поскольку не в курсе текущих приоритетов бизнеса. Один из принципов agile:
Изменение требований приветствуется, даже на поздних стадиях разработки.
А если фичи требуют работы не одного, а нескольких специалистов?
Или вы зарелизили фичу, молодец. А маркетологи потом - почему нас не предупредили, мы не сделали анонс? Аналитики еще прибегут. А потом придет PO и скажет: эту задачу делать было не нужно, бизнес передумал.
Agile scrum без самоорганизации, личной ответственности и т.д. не работает. Еще несколько принципов agile:- Над проектом должны работать мотивированные профессионалы
- Команда должна систематически анализировать возможные
способы улучшения эффективности и соответственно корректировать стиль своей работы
- Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
- Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
t-nick
10.12.2021 13:27+1В конце каждого спринта в SCRUM предусмотрены ретроспектива и планирование, как раз для того, чтобы остановиться и подумать.
Если отбросить церемонии, то SCRUM - это всего лишь планирование на короткие промежутки времени, пара недель вместо 3-х месяцев.
Дедлайны не имеют прямого отношения к SCRUM. Менеджмент решает, делать конец спринта дедлайном или нет.
sYB-Tyumen
10.12.2021 14:31+1Ок. Про железо для разработчиков сказали. А на мой любимый вопрос - как быть при Scrum/Agile с железом для выполнения того, что накодили? Своё (долго закупается; если закупать с запасом - дорого), облака - за них кто-то в корпорации готов платить (и иметь шанс навсегда "прилипнуть" к сервисам условного Амазона)?
Если будет вторая статья о том, что происходит на границах Scrum'а, то будет очень круто.
Kanut
10.12.2021 14:54+3Всё просто – работа спринтами. Люди, не готовые работать в авральном режиме, быстро выдыхаются
С чего это вдруг спринты стали авральным режимом?
Каждый раз мы собираемся всеми силами, чтобы сделать этот рывок, а как итог – через год-два в компаниях демотивированные сотрудники, которым ничего не приносит радости и мотивации: ни отпуск, ни новые продукты.
Ну так может просто не надо никаких "рывков"? Что вам мешает запланировать в спринт адекватный объём работы?
Если честно, пока я не знаю.
Очень просто: пока не умеете планировать объёмы работы точно, просто возьмите и запланируйте меньше. И если вдруг в конце спринта будет нечем заняться, то никто не запрещает взять что-то из бэклога.
Тут всё просто. Часто менеджеры становятся решателями всех проблем команд.
Откуда у вас в скраме менеджеры? Product Owner? Так они не менеджеры. У них есть своя зона ответственности и она чётко ограничена.
SkyZion
12.12.2021 10:23Я вот тоже не понял, откуда взялся менеджер :). Видимо, очень хочется менеджерить, общаться и быть doером.
vyatsek
10.12.2021 15:04+10"2018–2019. До внедрения Scrum продукты разрабатывались по водопадному принципу годами: сначала полгода обсуждений и согласований бюджета, долгий анализ, затем выбор вендоров и наконец реализация, по итогу получаем не то, что хотели."
Вот это вот какая-то дичь, которая говорит о том, что менеджмент в компании дно, которые понятия не имеют о том, что такое обратная связь.
Вендор vs in-house тема спорная и просто так брать и инвестить в in-house может быть опрометчиво, там критерии совсем другие, хотя в вашем случае надо было просто сменить работу с вендорами.
Я из тех кто не любит Scrum, хотя бы только за то, что все факторы производительности сводятся в burndown chart и velocity, как понять какие факторы повлияли на эти значения - непонятно.
Бывает операционная и спонтанная активность, которая непредсказуема, мы ее просто логируем, хотя это уже как бы не scrum/
Вообще история создания Scrum мутная и не фундаментальная, тот же RUP, куда более фундаментальный, хотя по нему никто особо и не работал. Ну и продавцы scrum очень любят противопоставлять waterfall vs scrum, но waterfall это была первая формализация процесса, с выделением этапов и сам же автор говорил о цикличности этих этапов, об этом почему-то продацы scrum умалчивают.Качество процесса определяет результат, ядро Linux пишут без скрама, а оно работает от калькуляторов до супер компьютеров.
Вообще за более, чем 20 летний опыт написания софта, я пришел к выводу, что если команда(в том числе менеджмент) не может придумать себе процессы для облегчения взаимодействия между собой, то это слабая команда и не более того.
Более формализованные процессы нужны, когда взаимодействует несколько команд, но и там всегда можно договориться.Если же смотреть шире, то производство софта это детский утренник по сравнению с процессами и сложностью авиазавода например.
Jammarra
10.12.2021 16:54Если же смотреть шире, то производство софта это детский утренник по сравнению с процессами и сложностью авиазавода например.
Вы работали на этом самом авиазаводе? Не знаю как зарубежом но в тех что я встречал уровень раздолбайства и бюрократии зашкаливает. И софт производить так же проблем нет ни каких. Правда каждый новый релиз будет максимум раз в 3-4 года а то и 10 лет. Что для IT просто неприемлемо.
Собственно так почти во всем производстве которое построено по процессам 50-80 летней давности. Там любые изменения принимаются с огромным скрипом. И кажись едиственный человек который понял что что то идет не так для нашего времени и решил что то поменять в таких производствах это Иллон Маск. Что бы изменения занимали не десятки лет и тысячи согласований. А адекватное время. Результат оказался потрясающий. И он уже заставил и остальных оторвать жопу и начать что то делать и менять в процессах. Жаль только разорваться он не может и до авиации не добрался.
vyatsek
11.12.2021 23:34У меня вся родня с завода, плюс я также был в IT подразделении на другом заводе. То, что вы пишите с одной стороны правда, бюррократия и старый подход, который не пытается обойти конкуренцию, а наоборот ее подавить.
Но я бы хотел акцентировать внимание на другом. Если в софте можно откатить много чего и вернуть все назад в 95% случаев, то косяки на производстве стоят просто на порядки дороже.
Завод это прежде всего материальное производство, необходимо управлять запасами. Косяки в производстве сложных деталей могут просто заруинить все изделие (например ракету) и откат там невозможен в принципе.
Связи между цехами, людьми и этапами намного жесче, чем в IT и управление всем этим балаганом требует куда больших усилий, чем когда одна команда использует api сервис другой.
Ilusha
11.12.2021 04:08Не нужно пытаться натянуть сову на глобус. Scrum и не нужен глобально для ядра/завода. У фреймворка есть определённые границы применимости: заказчик не знает чего хочет, бизнес-требования меняются довольно быстро, некоторые виды R&D, эксперименты.
Ни и всегда можно найти отдельные кусояки завода, где итерации хорошо подойдут для переоценки ситуации.
А таким на уровне таких крупных предприятий используется канбан, например. От японцев 5s иногда перенимают.
alexxz
10.12.2021 17:07+1И водопадный принцип был переиначен и скрам также извратили. Не давать команде оборудования - это, знаете ли, не проблема скрама или водопада. Уравнивать спринты с авралом. Это - разруха в головах. Не надо делать из методологии управления проектом соковыжималку.
Как хорошо что некоторые компании о себе такое рассказывают честно и добровольно.
laatoo
10.12.2021 17:23+4менеджеры становятся решателями всех проблем команд.
это их работа
Команды несут и несут свои проблемы, по итогу менеджер становится сотрудником своих сотрудников.
удивительная мысль.
у вас феодализм, или скрам? почему менеджер не должен решать проблемы коллектива? почему член команды не может обратиться к менеджеру за решением проблемы?он так хотел править и руководить, но его вынудили работать на результат и на команду :(
бедный менеджер!Это происходит потому, что никто в команде не готов взять ответственность и начать решать проблемы самостоятельно, без привлечения менеджера
это его чертова работа, решать проблемы!
если все проблемы успешно решаются без менеджера — он не нужен и будет уволен.бедный менеджер!
менеджер не может отказать
а кто ему дал право отказывать, если это его работа? если же это не его работа (проблема, с которой обратились вне зоны ответственности менеджера) — почему не может отказать/перенаправить/делегировать/посодействовать/походотайствовать от своего имени, не "отменеджерить" вопрос?
если менеджер отказывается менеджерить — он должен быть уволен.бедный менеджер!
Ilusha
11.12.2021 04:18Идеально все выразили.
Работал в компаниях, где менеджер(или PO) - твой лучший друг и товарищ. Правда, зачастую, эти люди выросли из технической среды (ну и, не редко, их уровень CTO/founders небольших компаний).
И меня все эти стоны «менеджеров» крайне удивляют. Им бы ещё сказать, что в аджайде есть понятие «служащий лидер».
Люди, чья работа - обеспечивать функционирование процессов, жалуются на то, что они не смогли построить взаимодействия. Чудовищное извращение понимания своей роли: обслуживание и развитие процессов.
Dmitry3A
10.12.2021 17:41+2Даже срам-мастеры хотят чтобы их любили.
Сколько смотрю на скрам-мастеров и в большинстве случае это девушки не очень обременённые умственными способностями, но любящие пообщаться — вот и возникает вопрос, это они выбирают такую позицию или позиция притягивает к себе подобных?
a3or
10.12.2021 18:59"Если есть дежурства, давать отгулы, а не дополнительные деньги."
А если давать выбор? Некоторым деньги важнее.
Gasaraki
10.12.2021 23:21+1По хорошему, полагается давать и деньги и отгулы.
a3or
11.12.2021 08:17+1Вроде или деньги или отгулы. При этом есть тонкость, за работу в выходной/праздничный положена двойная оплата, т.е. за те же деньги можно взять два дня за свой счет. Т.е. за работу в выходной/праздник нужно давать два дня отгулов, если считать в денежном выражении.
p0st
10.12.2021 21:41+1Из опыта с последней компании (еком):
1) Выстраивать процессы, по пути их автоматизации для уменьшения количества касаний и встреч, в том числе менеджеров/бизнеса, а не только разработка/менеджер.
После передачи команды в руки приемнице, она сделала качественные дашборды и договорилась с бизнесом схлопнуть 3 встречи до 1й + обновления дашборда. Тех лид стал свободнее и менеджер/мастер получила пространства для работы и жизни.
Я этого не сделал, потому что переоценил свои силы - взял себе больше проектов и был в огне.
2) Выстраивание границ с четким их соблюдением, временных, пространственных и прочих.
С командой договорились, что после 19 часов, бизнес может писать только в саппорт (у тех есть есть контакты дежурного разработчика, но это тоже про процессы) или менеджеру напрямую, но только в случае, если шеф всё упало и сломалось и только после уведомления саппорта.
В членов команды напрямую ходить категорически запрещено, каждый может ответить любому, кто придёт: "Идите на фиг, мне мама запретила разговаривать с незнакомыми!". Работает на всех, даже на топов.
Сами менеджеры стараются не упарываться, регулярно делятся о таких ситуациях на 1-2-1 с руководителями и общих встречах с коллегами по цеху и все в команде берут 1-2 дей офф, если понимают, что подкатывает.
3) Про фриланс и вторую работу - это очень хорошо чувствуется на уровне лида или выше, если этим лид решил сам пострадать.
Можно решать на уровне общения тех/тех с минимальным привлечением менеджера, если договориться не получается и страдает и сам пациент и его проекты, то решение о расставании может инициировать менеджер.
4) Лучше несколько небольших отпусков, чем весь год без отпуска и вот мои 28 дней.
Регулярный отдых помогает выжить, особенно на полной удалёнке. И это хороший повод посмотреть на ком слишком много замкнуто и расшить такие места, потому что незаменимый тех/тимлид - это бомба с часовым механизмом.
5) Корпоративные активности - меньше онлайна и больше оффлайна в любом доступном виде. В этом году у компании был юбилей, который HR вместе с топ, полностью решили провести онлайн.
Такой дизмарали давно не видел, при этом волна ковида была на спаде и можно было извернуться, но нет.
И отдельная часть комментария про изменения в большой корпорации - надо чётко понимать зачем вам это нужно, прежде чем ввязаться в бой.
Для изменения орг. структуры в моей предыдущей компании, мне пришлось эскалировать, понять что никто из линейных руководителей и топов не хочет брать ответственность, взять её на себя, просчитать экономику вместо линейных, защитить её у топов и добиться фиксации новой структуры в бюджете.
У меня мотив был, что должно быть правильно, логично и я знал, что если потерплю поражение, компания потеряет 2-3 талантливых инженеров.
Разменом стала сама работа, к которой были вопросы, а после решения не типовой задачи вне моих рамок компетенции, желание работать с этими людьми отпало.
SkyZion
11.12.2021 20:06+2Менеджеры становятся «Do'ерами»
Лучше и не скажешь! У менеджеров есть план
по надоямдедлайн, к которому они стремятся прийти в независимости от того сколько правок было в проекте и сколько для их реализации потребовалось времени. И начинается бесконечная дойка команды...Обычно такие ребята сопротивляются всему новому, не любят ивенты, им лишь бы по ТЗ работать и ни с кем не разговаривать, а мы, представьте, хотим, чтобы они с конечным пользователем заговорили и делали то, что нужно конечному пользователю.
Обычно "такие ребята" устают от того, что им пытаются продать проект, который не прошел стадию экспертизы, под видом одной из заповедей Agile о готовности к изменениям на любой стадии проекта. И как любой нормальный человек, им попросту жалко потраченных времени и сил, которые попросту выкидываются в мусорное ведро с каждой новой правкой.
Я достаточно долго поработал в Agile-командах в Казахстане и у меня абсолютно иное видение причин по которой команды теряют людей. Где-то в первых версиях вашей статьи была фраза о том, что многие не готовы постоянно работать в авральном режиме, которая затем приобрела более политкорректные обороты.
Так вот! Хорошая команда разработчиков может работать по Agile без менеджера проектов (я даже не помню чтоб такая роль была предусмотрена в SCRUM) и скрам-мастера, при этом они будут выдавать хорошие результаты! А вот менеджеры, уж точно не могут работать без команды разработчиков. Помните об этом, когда делаете выводы о том, по какой причине вы теряете людей.
Gasaraki
12.12.2021 00:28Интересно - а как много людей вносит в оценку времени скрама - сам скрам? 4 встречи в неделю по 15-30 минут - по факту займут суммарно 4 часа (минимум 5 минут до, 15 минут встреча, минут 30 чтобы после встречи просто вернуться в работу и помножить на 4 дня) .
Затем вносим час на планирование - опять по факту затрат времени 1.5-2 часа.
Если добавляем ретро - еще 1.5 часа.
По факту получаем практически потраченный день в неделю чисто на скрам. И внезапно 40 часов для работы превращается в 32.
Kanut
13.12.2021 10:11+1Интересно — а как много людей вносит в оценку времени скрама — сам скрам?
Я бы сказал что если у кого-то в скраме начнают оценивать таски в часах и планировать таким образом спринты, то это уже не особо хорошо. То есть мы так пробовали(вопреки совету скрам мастера), но получилось хуже чем брать абстрактные вещи вроде тех же стори поинтов. Ну и да, когда мы так делали, то отводили "таски" и под сам скрам.
n0isy
Если "продуктовый майндсет" это отсутствие нормальных компов и доступа к интернету ключевых разработчиков, то да, я пожалуй, потеряюсь.