Текст было бы неплохо начать с постановки задачи. То есть, какие проблемы призван решать системный аналитик в Альфа-банке. Оттуда уже можно вывести и скиллы.
Тогда читатели будут понимать, что системный аналитик это не богом с неба спущенная сущность, а роль, призванная решать проблемы конкретного бизнеса (Альфа-банка) при помощи каких-то умений. А также то, что проблемы другого бизнеса нужно решать другими скиллами системного аналитика или же вообще без системного аналитика.
Нужно сначала ответить на вопрос, зачем мы вообще делим людей на сорта? Ответ: чтобы понять, какую пользу они могут принести компании. Junior это тот, кто не приносит (почти) никакой пользы и только потребляет ресурсы команды/компании. Middle это тот кто приносит "стандартную" пользу и (почти) не потребляет ресурсов. Senior это тот, кто приносит пользу сверх средней.
Как это выглядит с практической точки зрения: у меня есть представление о неком усредненном SDLC (software development life cycle) для каждого стэка технологий и какого-то усредненного бизнес-проекта. Грубо говоря, это набор действий, которые нужно совершить чтобы вывести идею с нуля в production. Собрать требования, качественно закодить, протестировать, наладить деплоймент, мониторинг, избежать типичных ошибок, и так далее.
Тот, кто знает (и может объяснить) только часть этого SDLC, тот Junior. Мотивация такая: не важно, сколько фреймворков или языков знает кандидат. Хорошему специалисту недостаточно только уметь писать код. Нужно уметь тестировать, нужно знать, как понять, что хочет бизнес, нужно уметь нести ответственность за свой продукт, и так далее.
Тот, кто знает его целиком или почти целиком, тот Middle. Он может самостоятельно работать в рамках какого-то процесса, не разрушая его и не создавая проблем.
Тот, кто знает целиком и может рассказать, как большую часть этого SDLC запустить с нуля, тот Senior. Он может работать самостоятельно, может помогать коллегам и может помогать оптимизировать процесс.
Тот, кто знает, как запустить с нуля всю цепочку целиком и демонстрирует знание деталей, тот попадает в категорию software/solution architect'ов, для них отдельный процесс с другими критериями.
очевидно, имеет место ужасное недопонимание. похоже, кто-то подумал, что задача санкций - сделать так, чтобы россиянам было хорошо. чтобы россияне продолжали покупать товары и услуги, платя НДС государству. чтобы россияне продолжали высокопроизводительно работать, эффективно создавая добавочную стоимость и платя НДФЛ. чтобы россияне долго жили и поддерживали своего президента.
нет.
задача санкций - сделать ровно наоборот. чтобы власти пришлось отвлекать ресурсы на поддержание уровня жизни населения, на увеличение штата полиции, на закупку автозаков и строительство новых тюрем, на поиски россиянам работы, на выплату им социальных пособий, на борьбу с массовой эммиграцией, на поддержку бесконечных обанкротившихся бизнесов.
в результате санкций много людей в россии потеряют работу, многие потеряют жилье и многие умрут. но в конце концов власти россии завязнут в этом экономическом болоте. возможно, это займет десять лет, а может и больше. но это единственный способ предотвратить урон, который власти россии начали наносить окружающему миру.
Одна из идей скрама состоит в том, чтобы избавиться от всяких «лидов». Лиды не масштабируются, это центральная точка отказа, они аккумулируют знание, которым не умеют делиться, их иногда переезжает автобус, или же они уходят в другие компании.
Папа-лид заболел - и команда, как стадо овец, топчется на месте, потому что либо не имеет права принять решение, либо не имеет компетенции, либо не имеет информации.
Все гибкие методологии так или иначе содержат идею о том, что команда должна быть самодостаточной, независимой единицей. «Лиды» в этой структуре - прошлый век, отголоски типичных иерархичных моделей.
У большинства скрам-мастеров, которых я видел, есть проблема с самоопределением. Они не знают, кто они, зачем нужны и чего хотят. Особенно сильно это заметно на пост-советском пространстве, где аджайл все еще воспринимается как ЕЩЕ более креативный способ глумления и капиталистической эксплуатации простого трудяги от клавиатуры.
Скрам-мастер, как тренерская роль, не может жить без плана, без стратегии. Выработайте себе стратегию и последовательно реализуйте. И помните, что ваша задача - не таски в джире копипастить и стулья на митинге расставлять, а поднимать команды на новый уровень совместной работы и коммуникации.
Да, внезапно может оказаться, что «сеньоры» совершенно не умеют работать в команде, потому что они привыкли всю жизнь сидеть в своем подвале. Они будут сопротивляться изменениям, это нормально. Это от того, что на самом деле они не «сеньоры». Придется вытаскивать их на свет божий и объяснять, почему для компании важно чтобы все были открытыми, работали вместе.
Хочу посочувствовать, что приходится использовать SAFe. SAFe не имеет никакого отношения к аджайлу, это старый-добрый waterfall, щедро обмазанный сверху дремучей бюрократией. В сети достаточно ресурсов, рассказывающих про врожденные проблемы SAFe, искренне рекомендую. Я понимаю, что решение использовать SAFe пришло из Deutsche Telekom, но тем не менее врага нужно знать в лицо.
Хотел бы обратить внимание на несколько пунктов в тексте:
приходит зеленый скрам мастер в систем тим (ох уж этот SAFe), где сидят матерые мужики (простите за сексизм) в составе архитекторов, конфиг-менеджеров и автоматизатора и говорит: "ребята, я тут методичку прочитала на 16 страниц, сертификат получила, сейчас я буду вам рассказывать, как нужно выстраивать скрам/канбан процесс". Реально?? Можно было просто сказать "вы тупые, работали столько лет неправильно, а я умная, сейчас вас научу". Я была бы послана обратно со скоростью пули.
"Сеньорность" определяется не выслугой лет, это не армия. Одними из важнейших характеристик "сеньора" является открытость, способность к рефлексии и стремление постоянно улучшать свою работу. Без этого он продолжает оставаться джуниором, не важно, какой title написан у него в договоре найма.
Если вы сталкиваетесь с командой (будь то команда архитекторов или команда тестировщиков), которая отвергает любые изменения или не способна давать качественный фидбек, не стоит сразу относить это на счет своей "зелености". Смотрите на это как на challenge, на возможность помочь команде действительно вырасти.
мы некоторые задачи не можем оценить и не делаем этого. Вот как можно оценить саппорт скрам-команды, когда она переходит....ну пусть на java 14? Или как можно оценить РоС? А совместный рефакторинг архитектора и команды?
Все задачи из приведенных примеров можно оценить. Вы молодцы, что позволяете работать принципу "individuals and interactions over processes and tools". Но у оценок есть важная функция: заставить команду подумать о задаче до того, как принять ее в спринт. Неоцененные задачи любят попадать в спринт и вызывать там всевозможные затыки, потому что внезапно, каждый раз, с ними что-то оказывается "не так просто".
Если команда говорит вам, что задачу нельзя оценить, это сигнал о том, что они просто не хотят думать над задачей. Нужно начинать хоть с каких-то, максимально грубых оценок, стимулировать обсуждения "а что, если ...?", и, по мере увеличения опыта команды, добавлять больше деталей.
на первых порах я с рвением пыталась решить все, что команда высказывала на ретро. А как иначе, это же Impediment! А классный скрам-мастер должен их устранять.
Скрам-мастер не мама. Задача скрам-мастера - научить команду видеть и решать свои проблемы самостоятельно, помочь команде стать той самой самоорганизующейся командой.
Да, проблемы, поднятые командой, нужно приоритезировать, это должна делать сама команда. Нужно выбирать несколько важнейших проблем и максимально делегировать их решение команде.
Подведу итог. Вы на верном пути. Нужно только помнить, что скрам-мастер - не слуга команды, не мальчик на посылках и не офис-менеджер. Скрам-мастер это тренер, задача которого - помочь команде вырасти, научив идентифицировать проблемы и показав, как их решать.
можно ведь открыть соответствующие договоры (опубликованы на сайте МИДа вроде бы) и почитать их, вместо того чтобы дезинформировать аудиторию?
Текст было бы неплохо начать с постановки задачи. То есть, какие проблемы призван решать системный аналитик в Альфа-банке. Оттуда уже можно вывести и скиллы.
Тогда читатели будут понимать, что системный аналитик это не богом с неба спущенная сущность, а роль, призванная решать проблемы конкретного бизнеса (Альфа-банка) при помощи каких-то умений. А также то, что проблемы другого бизнеса нужно решать другими скиллами системного аналитика или же вообще без системного аналитика.
Я не автор поста, но поделюсь своими критериями.
Нужно сначала ответить на вопрос, зачем мы вообще делим людей на сорта? Ответ: чтобы понять, какую пользу они могут принести компании. Junior это тот, кто не приносит (почти) никакой пользы и только потребляет ресурсы команды/компании. Middle это тот кто приносит "стандартную" пользу и (почти) не потребляет ресурсов. Senior это тот, кто приносит пользу сверх средней.
Как это выглядит с практической точки зрения: у меня есть представление о неком усредненном SDLC (software development life cycle) для каждого стэка технологий и какого-то усредненного бизнес-проекта. Грубо говоря, это набор действий, которые нужно совершить чтобы вывести идею с нуля в production. Собрать требования, качественно закодить, протестировать, наладить деплоймент, мониторинг, избежать типичных ошибок, и так далее.
Тот, кто знает (и может объяснить) только часть этого SDLC, тот Junior. Мотивация такая: не важно, сколько фреймворков или языков знает кандидат. Хорошему специалисту недостаточно только уметь писать код. Нужно уметь тестировать, нужно знать, как понять, что хочет бизнес, нужно уметь нести ответственность за свой продукт, и так далее.
Тот, кто знает его целиком или почти целиком, тот Middle. Он может самостоятельно работать в рамках какого-то процесса, не разрушая его и не создавая проблем.
Тот, кто знает целиком и может рассказать, как большую часть этого SDLC запустить с нуля, тот Senior. Он может работать самостоятельно, может помогать коллегам и может помогать оптимизировать процесс.
Тот, кто знает, как запустить с нуля всю цепочку целиком и демонстрирует знание деталей, тот попадает в категорию software/solution architect'ов, для них отдельный процесс с другими критериями.
очевидно, имеет место ужасное недопонимание. похоже, кто-то подумал, что задача санкций - сделать так, чтобы россиянам было хорошо. чтобы россияне продолжали покупать товары и услуги, платя НДС государству. чтобы россияне продолжали высокопроизводительно работать, эффективно создавая добавочную стоимость и платя НДФЛ. чтобы россияне долго жили и поддерживали своего президента.
нет.
задача санкций - сделать ровно наоборот. чтобы власти пришлось отвлекать ресурсы на поддержание уровня жизни населения, на увеличение штата полиции, на закупку автозаков и строительство новых тюрем, на поиски россиянам работы, на выплату им социальных пособий, на борьбу с массовой эммиграцией, на поддержку бесконечных обанкротившихся бизнесов.
в результате санкций много людей в россии потеряют работу, многие потеряют жилье и многие умрут. но в конце концов власти россии завязнут в этом экономическом болоте. возможно, это займет десять лет, а может и больше. но это единственный способ предотвратить урон, который власти россии начали наносить окружающему миру.
в шамони трешка за 200? я только месяц назад как был в шамони: 30-40 квадратных метров стоят 500+. трешка там стоит значительно больше миллиона.
Одна из идей скрама состоит в том, чтобы избавиться от всяких «лидов». Лиды не масштабируются, это центральная точка отказа, они аккумулируют знание, которым не умеют делиться, их иногда переезжает автобус, или же они уходят в другие компании.
Папа-лид заболел - и команда, как стадо овец, топчется на месте, потому что либо не имеет права принять решение, либо не имеет компетенции, либо не имеет информации.
Все гибкие методологии так или иначе содержат идею о том, что команда должна быть самодостаточной, независимой единицей. «Лиды» в этой структуре - прошлый век, отголоски типичных иерархичных моделей.
Не за что.
У большинства скрам-мастеров, которых я видел, есть проблема с самоопределением. Они не знают, кто они, зачем нужны и чего хотят. Особенно сильно это заметно на пост-советском пространстве, где аджайл все еще воспринимается как ЕЩЕ более креативный способ глумления и капиталистической эксплуатации простого трудяги от клавиатуры.
Скрам-мастер, как тренерская роль, не может жить без плана, без стратегии. Выработайте себе стратегию и последовательно реализуйте. И помните, что ваша задача - не таски в джире копипастить и стулья на митинге расставлять, а поднимать команды на новый уровень совместной работы и коммуникации.
Да, внезапно может оказаться, что «сеньоры» совершенно не умеют работать в команде, потому что они привыкли всю жизнь сидеть в своем подвале. Они будут сопротивляться изменениям, это нормально. Это от того, что на самом деле они не «сеньоры». Придется вытаскивать их на свет божий и объяснять, почему для компании важно чтобы все были открытыми, работали вместе.
Интересная в общем работа, да ;)
Ну, добро пожаловать в аджайл ;)
Хочу посочувствовать, что приходится использовать SAFe. SAFe не имеет никакого отношения к аджайлу, это старый-добрый waterfall, щедро обмазанный сверху дремучей бюрократией. В сети достаточно ресурсов, рассказывающих про врожденные проблемы SAFe, искренне рекомендую. Я понимаю, что решение использовать SAFe пришло из Deutsche Telekom, но тем не менее врага нужно знать в лицо.
Хотел бы обратить внимание на несколько пунктов в тексте:
"Сеньорность" определяется не выслугой лет, это не армия. Одними из важнейших характеристик "сеньора" является открытость, способность к рефлексии и стремление постоянно улучшать свою работу. Без этого он продолжает оставаться джуниором, не важно, какой title написан у него в договоре найма.
Если вы сталкиваетесь с командой (будь то команда архитекторов или команда тестировщиков), которая отвергает любые изменения или не способна давать качественный фидбек, не стоит сразу относить это на счет своей "зелености". Смотрите на это как на challenge, на возможность помочь команде действительно вырасти.
Все задачи из приведенных примеров можно оценить. Вы молодцы, что позволяете работать принципу "individuals and interactions over processes and tools". Но у оценок есть важная функция: заставить команду подумать о задаче до того, как принять ее в спринт. Неоцененные задачи любят попадать в спринт и вызывать там всевозможные затыки, потому что внезапно, каждый раз, с ними что-то оказывается "не так просто".
Если команда говорит вам, что задачу нельзя оценить, это сигнал о том, что они просто не хотят думать над задачей. Нужно начинать хоть с каких-то, максимально грубых оценок, стимулировать обсуждения "а что, если ...?", и, по мере увеличения опыта команды, добавлять больше деталей.
Скрам-мастер не мама. Задача скрам-мастера - научить команду видеть и решать свои проблемы самостоятельно, помочь команде стать той самой самоорганизующейся командой.
Да, проблемы, поднятые командой, нужно приоритезировать, это должна делать сама команда. Нужно выбирать несколько важнейших проблем и максимально делегировать их решение команде.
Подведу итог. Вы на верном пути. Нужно только помнить, что скрам-мастер - не слуга команды, не мальчик на посылках и не офис-менеджер. Скрам-мастер это тренер, задача которого - помочь команде вырасти, научив идентифицировать проблемы и показав, как их решать.