Добрый день! Понимаю, что это перевод статьи, но в последнем запросе, чтобы развернуть данные указываются конкретные значения (2005, 2007 и тд). В общем случае таких значений может быть много или они могут быть не определены на момент написания запроса (в базу постоянно что-то дописывается). Как можно унифицировать такую развёртку, чтобы запрос выполнялся на данных с произвольными значениями?
Внезапно менеджеры поняли, что надо разговаривать с людьми ртом. Интересно, что они до этого делали?
По сабжу периодические встречи 1 на 1 великолепный инструмент, который повышает прозрачность и уровень доверия. Однако его достаточно сложно освоить в полной мере, а понять, что по результатам должны формироваться договорённости, которые нужно соблюдать, ещё сложнее. В ряде случаев проблемы, которые надо решать не требуют даже финансовых сливаний. Люди хотят развиваться? Дайте им задачи, где им нужно узнавать новое. Люди хотят гибкого графика? Договоритесь об обязательных активностях, где надо быть, и каналах коммуникации, а дальше работай, как тебе угодно. Людей бесит/напрягает/мешает что-то или кто-то? Разберитесь по фактам, выделите, что надо изменить, внедрите изменения. Люди хотят больше денег? Тонкий момент - иногда компании реально недоплачивают до рынка (это норм, бизнес, есть бизнес, сэкономил, считай заработал), иногда человека реально перекупают за оверпрайс, в любом случае можно разобрать, где человек сейчас, чего достиг, куда можно двигаться и как это может влиять на заработок.
В любом случае, это сопровождается встречей 1 на 1, где говорим ртом, безопасно (что случилось на встрече, остаётся там), с документровнием договорённостей и внедрением изменений.
Можно уточнить, как на практике разрешается конфликт того, что команда двигается к цели спринта, а аналитик в теории прорабатывается задачи на будущее? Насколько аналитик нужен непосредственно в команде вместе с разработчиками? Почему не стоит выделять аналитиков в отдельную команду?
Все, что ниже, не хейта ради, а пользы для.
Очередной пример того, когда менеджер пишет статью с красивым названием и пустую по сути. У нас в компании куча систем, мы интегрируемся с кучей других, чтобы работали те или иные сценарии. Модель развития продуктов спиральная. Команды работают по Scrum, где-то Kanban, где-то водопад. Задачки есть разные. Аналитики работают в командах, взаимодействуют со всеми. Пишут пользовательские истории, оптимизируют процессы, участвуют в тестировании.
Где будни? Где набор инструментов и практик, которые используются в аналитике, где примеры артефактов, которые рождают аналитики, где рассказы о задачах, когда аналитик с горящей пятой точкой бегает между заказчиками и разработчиками в попытке согласовать несогласуемое? Вот это вот будни.
Ну да, ну да, приходите на наш конкурс.
Добрый день! Понимаю, что это перевод статьи, но в последнем запросе, чтобы развернуть данные указываются конкретные значения (2005, 2007 и тд). В общем случае таких значений может быть много или они могут быть не определены на момент написания запроса (в базу постоянно что-то дописывается). Как можно унифицировать такую развёртку, чтобы запрос выполнялся на данных с произвольными значениями?
Внезапно менеджеры поняли, что надо разговаривать с людьми ртом. Интересно, что они до этого делали?
По сабжу периодические встречи 1 на 1 великолепный инструмент, который повышает прозрачность и уровень доверия. Однако его достаточно сложно освоить в полной мере, а понять, что по результатам должны формироваться договорённости, которые нужно соблюдать, ещё сложнее. В ряде случаев проблемы, которые надо решать не требуют даже финансовых сливаний. Люди хотят развиваться? Дайте им задачи, где им нужно узнавать новое. Люди хотят гибкого графика? Договоритесь об обязательных активностях, где надо быть, и каналах коммуникации, а дальше работай, как тебе угодно. Людей бесит/напрягает/мешает что-то или кто-то? Разберитесь по фактам, выделите, что надо изменить, внедрите изменения. Люди хотят больше денег? Тонкий момент - иногда компании реально недоплачивают до рынка (это норм, бизнес, есть бизнес, сэкономил, считай заработал), иногда человека реально перекупают за оверпрайс, в любом случае можно разобрать, где человек сейчас, чего достиг, куда можно двигаться и как это может влиять на заработок.
В любом случае, это сопровождается встречей 1 на 1, где говорим ртом, безопасно (что случилось на встрече, остаётся там), с документровнием договорённостей и внедрением изменений.
Можно уточнить, как на практике разрешается конфликт того, что команда двигается к цели спринта, а аналитик в теории прорабатывается задачи на будущее? Насколько аналитик нужен непосредственно в команде вместе с разработчиками? Почему не стоит выделять аналитиков в отдельную команду?
Очередной пример того, когда менеджер пишет статью с красивым названием и пустую по сути. У нас в компании куча систем, мы интегрируемся с кучей других, чтобы работали те или иные сценарии. Модель развития продуктов спиральная. Команды работают по Scrum, где-то Kanban, где-то водопад. Задачки есть разные. Аналитики работают в командах, взаимодействуют со всеми. Пишут пользовательские истории, оптимизируют процессы, участвуют в тестировании.
Где будни? Где набор инструментов и практик, которые используются в аналитике, где примеры артефактов, которые рождают аналитики, где рассказы о задачах, когда аналитик с горящей пятой точкой бегает между заказчиками и разработчиками в попытке согласовать несогласуемое? Вот это вот будни.
Ну да, ну да, приходите на наш конкурс.