>> команд все еще могут быть классические менеджеры
>> как их может не быть?)
Возможно все, например — стартап. Собрался я с Васей и Колей сделать лучшую в мире блокчейн-платформу, Вася привел свою девушку, Коля привел своего брата. Из инвестиций у нас — собственные ноуты и коворкинг, оплаченный из денег на завтраки, Idea по студенческой лицензии. Работаем just for fun до первых инвестиций, менеджеров не будет. Но это, конечно, утрированно сильно )))
В идеальном случае, должно быть так — стейкхолдеры объясняют РО свою стратегию развития организации\возврата инвестиций, и РО обеспечивает эту стратегию через управление бэклогом.
Иначе говоря, критерии успешности продукта — задают стейкхолдеры, за достижение этих критериев — отвечает РО (естественно, через правильное наполнение беклога). И эти критерии могут быть и прибыль, и лидерство на рынке, и РОИ, и просто вывод продукта на рынок, и укрепление HR-бренда, да что угодно.
Пример — у вас есть 1 млрд рублей и вы хотите сделать новую игру. Поздравляю, вы стейкхолдер — и теперь вам можно нанять скрам-команду. Вы находите РО, который хорошо шарит в рынке игр, понимает что в тренде, какие есть каналы продвижения и т.д. и т.п. Вы формируете ему цели, например сделать отдачу от инвестиций 5% в течении этого года и он приступает — наполняет беклог тем, что может этой цели достигнуть (и тут важно сказать что РО разделяет ваше видение, если вы например говорите что хотите фентези игру, РО может сказать вам что нынче в моде танки и не согласиться работать с вами, т.к. считает цели недостижимыми при таких условиях). Команда разработки же превращает элементы беклога — в инкримент, который потом можно зарелизить и вывести на рынок (и тут то РО проверит, был он прав предполагая что на этом можно получить денег или нет).
Я слышал про Kenneth Rubin и, внезапно, даже прочитал. Scrum Guide он не противоречит, просто разжевывает гайд в начале и дополняет как команда может работать в разных организациях и при разных условиях. И да, там есть прямо глава с названием «Managers», где рассказывается о том, как можно работать с руководством за пределами скрам (emacsway, которые никуда не делись, в скрамгайде они включены в группу 'stakeholders', но в этой группе не только менеджмент).
Так вот, согласно этой книге, у команд все еще могут быть классические менеджеры — Head of QA, Head of BA, CTO, CEO, CFO, CIO etc. Роли этих менеджеров примерно следующие — формирование команды, постановка целей, определение границ работы команды и смена участников команды. Менеджер и правда может уволить или выдать бонус (если он гендир, например). Но в этом он опирается в первую очередь на мнение скрам-команды и это явно написано в книге — там даже есть пример с Фредом, который плохо работает в команде и СНАЧАЛА команда разработки работает с ним, потом СМ (как часть уже скрам-команды), и только потом они идут к менеджеру вне скрам-команды — см. скриншот из книги ниже. Скрамгайду на мой взгляд это совсем не противоречит. А вот такого, что бы менеджер кого то оценивал сам, без ОС команды разработки — это явный антипаттерн.
На мой взгляд лучше подготовиться сначала, ибо в процессе подготовки может появиться понимание что сертификация не нужна. Если решили окончательно и 100% сдавать — можно подать заявку и оплатить, если на горизонте много времени. Если нет, лучше все таки сделать расписание подготовки и следовать ему, сдать в случае отсутствия форс-мажоров ничего не помешает.
Интересная статья, спасибо!
Только не понял смысла в предложении «по опыту работы с аспирантами знаю, что многие специально за 2 года до поступления начинают учить другой язык, чтобы набрать лишний балл». Почему если хорошо знаешь английский, и, например, не очень хорошо знаешь немецкий лучше сдавать немецкий?
Странно, вроде Сазерленд — автор скрам, и я был уверен что такого не напишет. Хотя, кто знает… Я не хотел такие книги читать, и теперь еще более убедился что не надо. Если хочется узнать о технологии — надо скачать справочник, пообщаться с тем кто использовал это на практике и пробовать самому. Книги по 500 страниц с историями и пояснениями на мой взгляд не так полезны…
Но, советую скачать скрамгайд. Он бесплатный, 16 страниц всего — стоит прочитать в любом случае.
Хм, возможно дело в переводе. На русском эти книги даже читать не стоит, они переведены по принципу «Что знали, перевели, что непонятно выкинули, как поняли так и поняли».
Например, книга «Scrum: The Art of Doing Twice the Work in Half the Time» легко и непринужденно переведена на русский как «Scrum. Революционный метод управления проектами». Ну а потом, на конференциях начинаются споры — «Мы попробовали скрам по книжке, не пошло, фигня этот ваш скрам!».
Для того что бы начать внедрять Скрам (Принс2, ITIL, авторитарное управление и что угодно еще) мало прочитать 1-2-3 книжки. Мое мнение — надо звать тренера который уже не одну трансформацию провел, что бы он оценил — применимы ли к вашей компании вообще гибкие методологии и будет ли профит, а потом уже внедрять что то.
Проектирование моста непростая задача.
Но, заметьте, что на графике выше — не просто сложность, а сложность по определенным критериями.
Согласно графику, эджайл хорошо заходит в проектах, где все плохо с пониманием того, что делать, и пониманием того, как делать.
Если понимания, куда строить мост нет — наверное, его не надо начинать строить. Так же, если не понимать как именно его строить — мост это, туннель под водой, или, скажем, телепорт, начинать его строить нет смысла.
Именно поэтому мост по эджайл строить не нужно — здесь все в порядке с тем, что мы понимаем что надо построить и куда надо построить.
В разработке софта же все не так. Очень часто приложение или портал, которое мы делаем, будет меняться в процессе изготовления. Например ФБ задумывался как сеть для студентов, но рынок определил ему другую участь, Windows задумана как оболочка над операционкой МС ДОС, но выросла в полноценную ОС, телеграм задумывался как мессенджер, но по сути уже целая социальная сеть и т.д. и т.п.
Тоже и с технологиями — можно взять и спланировать приложение (UML например), но это будет очень дорого и не факт что эффективно. Даже в самом кровавом энтерпрайсе я видел документацию к приложениям в виде концепции или техзадания + описание проекта + руководств. Конечно, они не включали в себя описания классов, стандарты кодирования, расшифровки комментариев, и конечно были написаны уже по факту написания кода.
В итоге — строить мост по эджайлу можно, но ни к чему (определенность и использование известных технологий). Строить софт по вотерфоллу — всегда пожалуйста, просто дороже и не факт что это кому то будет нужно.
Да, сертификация конечно не изменит подхода, да и вряд ли вообще поможет в реальной ситуации. Но, все-таки, когда человек начинает на эджайл конференции с рассказа о себе, и у него есть сертификаты, хотя бы не ждешь треш и угар.
В этом году я был на конференции, на которой спикер заявил — в манифесте написано «Люди и взаимоотношения важнее результата!», и, увы, его не остановили модераторы, а времени на вопросы он предусмотрительно не оставил. Или, компания, которая внедряла продукт по эджайл и хвасталась этим на хабре — мол, наши ПМы стали СМами, команду мы били палками только за то, что она не бьет себя сама, а планерки по утрам заменили на дейли скрам. И это читаешь, и плакать хочется.
Так что для меня, наверное, серт — это скорее доказательство адекватности, а вот мериться ими смысла точно нет.
P.S. За примеры спасибо, не видел видео с этого события.
Был в вашем московском офисе, строгого дресса не видел. На пресейлы, понятно, вряд ли ездят в футболках, но в офисе свободно. Опять же московский офис понравился, тренажеров там на тот момент точно не было и переговорки не все уютные, но в целом — видно, что не просто безликая безымянная компания, а тут работают люди.
За внутреннюю валют — отдельный плюс в карму, идея правда очень клевая )
Нормальная подборка, я успел соскучится по этим странным но прикольным мобилам. Эх, было время, когда мобильники не были похожи один на другой как две капли воды…
Но, еще и был Siemens — и бюджетки и MC60, и смартфоны, защищенные убердевайсы и знаменитый S75…
Плюсую, у меня книжка на Линуксе. С подсветкой на минимуме, при режиме чтения — 20-30 минут перед сном, хватает на месяц. Может быть, потому что не засыпает, а выключается (через 15 мин сна вырубается сама), ну и мне комфортно, т.к. загружается секунд за 5.
По собственному опыту — 6 брать не стоит точно.
Как оптимальный вариант — за 3-5к посмотреть 10-дюймовый планшет о 4 ядрах и 1,5 Гб памяти с 5 и выше андроидом (бюджетно, можно посмотреть уцененный).
Я активно пользуюсь 6-дюймовой электронной книгой для чтения иностранной литературы, очень удобно что аккумулятор не садится месяц, и в книге есть переводик, который можно вызвать тапом по слову, но, увы, для PDF она не подходит вообще. Файлы либо не открываются (например, тяжелые самодельные PDF из сканов методичек), либо тормозят и масштабируются кошмарно, а качество сенсорного экрана (мультитач) вот вообще никак не предназначено для быстрой навигации по PDF\DJVU.
В итоге, поскольку часто читаю документацию и методички, купил один из самых дешевых планшетов. И, как по волшебству — туда влезли все книги, стоит 2 читалки на выбор (и если форма PDF очень хитрый, одна из читалок его откроет), масштабирование и навигация просто супер, и совсем не жалко взять с собой (ибо дешевый).
Хорошая двушка в районе ТТК в Москве будет стоить около 65к. С консьержем, двором без машин, посудомойкой, колясочной, мойкой для собак в подъезде и т.д.
Да, за 30 — не снимите двушку, но за 60-70к жилья навалом офигительного и очередей за ним не стоит. Очереди стоят за однушками с бабушкиным ремонтом за 25-30к, либо за двушками за 40-45к, снимаемыми на двоих.
У меня коллега на старом месте был из одной из этих контор (Мск). Ушел из за преобразовний внутри, но скажу что прокачен он был очень сурово после них, куча сертификатов, инглиш, дойч, софт-скиллс.
Второй товарищ попал в одну из этих контор после универа (физика), к разработке ПО имеет отношение очень опосредственное — скорее инженер. Платили ему на входе зарплату, сопоставимую с Java Jun Dev, но инглиш у него был. Еще раз специально повторю — платили СРАЗУ хорошо (х1,5 от официальной средней ЗП по городу), БЕЗ опыта, только университет. Прямо звезд с неба он не хватал, но и далеко не дурак — работать бы к себе взял с удовольствием (в случае совпадения технологий). И рассказывал он о работе только позитив — премии, командировки в Германию, карьерный рост (за 2 года до ведущего инженера), развитие от спонсирование курсов немецкого до обучения в той же Германии на производствах.
Рабочие места я видел в 2х из этих компаний — не Авито, но и не советский союз — обычный современный офис класса В+\А. Единственное — очень любят они далеко от метро (и МКАДа или его аналогов) — ну не может быть офис в гребеньках плюсом.
Сименс при желании платит более чем хорошо (в Мск). Шнайдер — в Самаре давал выше среднего по рынку да еще и джунам (универ есть соответствующий, кафедра радиофизики сильная, набирай — не хочу). В Самаре еще есть и Бош, где тоже неплохо кормят, можно сильно подтянуть инглиш, повидать много интересного в командировках и подумать о релокации, но уже в немецкий Бош или Сименс.
Так почему же сотрудники должны бросить работы и пойти к вам? )
Ага, тоже видел такую ситуацию в Самаре, где джуны-аналитики заходили на 45к на руки, т.к. общаться умеют и заказчику надо показывать, а на железе с телемеханикой и разработкой под контроллеры, парни с опытом 5-6 лет получали по 30к (с поездками на всякие заводы, сдачей экзаменов по электробезопасности, ночевками в дешевых гостиницах и ненормированным рабочим днем).
Много до кого очень быстро дошло, что фасилитировать — не мешки ворочать, и люди потихоньку разворачивались в сторону аналитики, а через 5-7 лет заноют — некого звать, специалистов нет…
>> как их может не быть?)
Возможно все, например — стартап. Собрался я с Васей и Колей сделать лучшую в мире блокчейн-платформу, Вася привел свою девушку, Коля привел своего брата. Из инвестиций у нас — собственные ноуты и коворкинг, оплаченный из денег на завтраки, Idea по студенческой лицензии. Работаем just for fun до первых инвестиций, менеджеров не будет. Но это, конечно, утрированно сильно )))
В идеальном случае, должно быть так — стейкхолдеры объясняют РО свою стратегию развития организации\возврата инвестиций, и РО обеспечивает эту стратегию через управление бэклогом.
Иначе говоря, критерии успешности продукта — задают стейкхолдеры, за достижение этих критериев — отвечает РО (естественно, через правильное наполнение беклога). И эти критерии могут быть и прибыль, и лидерство на рынке, и РОИ, и просто вывод продукта на рынок, и укрепление HR-бренда, да что угодно.
Пример — у вас есть 1 млрд рублей и вы хотите сделать новую игру. Поздравляю, вы стейкхолдер — и теперь вам можно нанять скрам-команду. Вы находите РО, который хорошо шарит в рынке игр, понимает что в тренде, какие есть каналы продвижения и т.д. и т.п. Вы формируете ему цели, например сделать отдачу от инвестиций 5% в течении этого года и он приступает — наполняет беклог тем, что может этой цели достигнуть (и тут важно сказать что РО разделяет ваше видение, если вы например говорите что хотите фентези игру, РО может сказать вам что нынче в моде танки и не согласиться работать с вами, т.к. считает цели недостижимыми при таких условиях). Команда разработки же превращает элементы беклога — в инкримент, который потом можно зарелизить и вывести на рынок (и тут то РО проверит, был он прав предполагая что на этом можно получить денег или нет).
Так вот, согласно этой книге, у команд все еще могут быть классические менеджеры — Head of QA, Head of BA, CTO, CEO, CFO, CIO etc. Роли этих менеджеров примерно следующие — формирование команды, постановка целей, определение границ работы команды и смена участников команды. Менеджер и правда может уволить или выдать бонус (если он гендир, например). Но в этом он опирается в первую очередь на мнение скрам-команды и это явно написано в книге — там даже есть пример с Фредом, который плохо работает в команде и СНАЧАЛА команда разработки работает с ним, потом СМ (как часть уже скрам-команды), и только потом они идут к менеджеру вне скрам-команды — см. скриншот из книги ниже. Скрамгайду на мой взгляд это совсем не противоречит. А вот такого, что бы менеджер кого то оценивал сам, без ОС команды разработки — это явный антипаттерн.
Только не понял смысла в предложении «по опыту работы с аспирантами знаю, что многие специально за 2 года до поступления начинают учить другой язык, чтобы набрать лишний балл». Почему если хорошо знаешь английский, и, например, не очень хорошо знаешь немецкий лучше сдавать немецкий?
Но, советую скачать скрамгайд. Он бесплатный, 16 страниц всего — стоит прочитать в любом случае.
Например, книга «Scrum: The Art of Doing Twice the Work in Half the Time» легко и непринужденно переведена на русский как «Scrum. Революционный метод управления проектами». Ну а потом, на конференциях начинаются споры — «Мы попробовали скрам по книжке, не пошло, фигня этот ваш скрам!».
Для того что бы начать внедрять Скрам (Принс2, ITIL, авторитарное управление и что угодно еще) мало прочитать 1-2-3 книжки. Мое мнение — надо звать тренера который уже не одну трансформацию провел, что бы он оценил — применимы ли к вашей компании вообще гибкие методологии и будет ли профит, а потом уже внедрять что то.
Но, заметьте, что на графике выше — не просто сложность, а сложность по определенным критериями.
Согласно графику, эджайл хорошо заходит в проектах, где все плохо с пониманием того, что делать, и пониманием того, как делать.
Если понимания, куда строить мост нет — наверное, его не надо начинать строить. Так же, если не понимать как именно его строить — мост это, туннель под водой, или, скажем, телепорт, начинать его строить нет смысла.
Именно поэтому мост по эджайл строить не нужно — здесь все в порядке с тем, что мы понимаем что надо построить и куда надо построить.
В разработке софта же все не так. Очень часто приложение или портал, которое мы делаем, будет меняться в процессе изготовления. Например ФБ задумывался как сеть для студентов, но рынок определил ему другую участь, Windows задумана как оболочка над операционкой МС ДОС, но выросла в полноценную ОС, телеграм задумывался как мессенджер, но по сути уже целая социальная сеть и т.д. и т.п.
Тоже и с технологиями — можно взять и спланировать приложение (UML например), но это будет очень дорого и не факт что эффективно. Даже в самом кровавом энтерпрайсе я видел документацию к приложениям в виде концепции или техзадания + описание проекта + руководств. Конечно, они не включали в себя описания классов, стандарты кодирования, расшифровки комментариев, и конечно были написаны уже по факту написания кода.
В итоге — строить мост по эджайлу можно, но ни к чему (определенность и использование известных технологий). Строить софт по вотерфоллу — всегда пожалуйста, просто дороже и не факт что это кому то будет нужно.
Думаю, любой опытный ПМ\АЛ понимает, что кесарю кесарево.
В этом году я был на конференции, на которой спикер заявил — в манифесте написано «Люди и взаимоотношения важнее результата!», и, увы, его не остановили модераторы, а времени на вопросы он предусмотрительно не оставил. Или, компания, которая внедряла продукт по эджайл и хвасталась этим на хабре — мол, наши ПМы стали СМами, команду мы били палками только за то, что она не бьет себя сама, а планерки по утрам заменили на дейли скрам. И это читаешь, и плакать хочется.
Так что для меня, наверное, серт — это скорее доказательство адекватности, а вот мериться ими смысла точно нет.
P.S. За примеры спасибо, не видел видео с этого события.
Отсюда фасилитировать события — обеспечивать коммуникацию на собраниях команды, что бы команда достигала целей собраний.
За внутреннюю валют — отдельный плюс в карму, идея правда очень клевая )
Но, еще и был Siemens — и бюджетки и MC60, и смартфоны, защищенные убердевайсы и знаменитый S75…
Ждем офис в Самаре!
Как оптимальный вариант — за 3-5к посмотреть 10-дюймовый планшет о 4 ядрах и 1,5 Гб памяти с 5 и выше андроидом (бюджетно, можно посмотреть уцененный).
Я активно пользуюсь 6-дюймовой электронной книгой для чтения иностранной литературы, очень удобно что аккумулятор не садится месяц, и в книге есть переводик, который можно вызвать тапом по слову, но, увы, для PDF она не подходит вообще. Файлы либо не открываются (например, тяжелые самодельные PDF из сканов методичек), либо тормозят и масштабируются кошмарно, а качество сенсорного экрана (мультитач) вот вообще никак не предназначено для быстрой навигации по PDF\DJVU.
В итоге, поскольку часто читаю документацию и методички, купил один из самых дешевых планшетов. И, как по волшебству — туда влезли все книги, стоит 2 читалки на выбор (и если форма PDF очень хитрый, одна из читалок его откроет), масштабирование и навигация просто супер, и совсем не жалко взять с собой (ибо дешевый).
Да, за 30 — не снимите двушку, но за 60-70к жилья навалом офигительного и очередей за ним не стоит. Очереди стоят за однушками с бабушкиным ремонтом за 25-30к, либо за двушками за 40-45к, снимаемыми на двоих.
Второй товарищ попал в одну из этих контор после универа (физика), к разработке ПО имеет отношение очень опосредственное — скорее инженер. Платили ему на входе зарплату, сопоставимую с Java Jun Dev, но инглиш у него был. Еще раз специально повторю — платили СРАЗУ хорошо (х1,5 от официальной средней ЗП по городу), БЕЗ опыта, только университет. Прямо звезд с неба он не хватал, но и далеко не дурак — работать бы к себе взял с удовольствием (в случае совпадения технологий). И рассказывал он о работе только позитив — премии, командировки в Германию, карьерный рост (за 2 года до ведущего инженера), развитие от спонсирование курсов немецкого до обучения в той же Германии на производствах.
Рабочие места я видел в 2х из этих компаний — не Авито, но и не советский союз — обычный современный офис класса В+\А. Единственное — очень любят они далеко от метро (и МКАДа или его аналогов) — ну не может быть офис в гребеньках плюсом.
Так почему же сотрудники должны бросить работы и пойти к вам? )
Много до кого очень быстро дошло, что фасилитировать — не мешки ворочать, и люди потихоньку разворачивались в сторону аналитики, а через 5-7 лет заноют — некого звать, специалистов нет…