а что такое "новенький" :)

может он уже "старенький" в плане навыков на уровне вашего бизнеса

а целей или нет или пока спустили сверху вниз, забыли зачем такие показатели)

во во, и вообще они год назад ставились, уже все поменялось, но вы работайте

я бы на время испытательного не давала бонус, а потом включала в общий командный

не думал в таком ключе, по сути мы тоже так делаем: бонус после исп. срока)

я придумаю KPI и он заставит человека делать то чего он не умеет

нет, что вы. это плохой вариант требовать невозможного - будет демотивировать. я про это не писал. хорошая СМ - когда ты понимаешь, что ты можешь этого достичь, но тебе надо чуть напрячься, чтобы сделать больше. я просто опыт имею по такой работе, это реально мотивирует и ты считаешь цифры сколько тебе, например, оборотки, надо доделать и потом бомбишь акцию или прозваниваешь потенциальных клиентов, чтобы добрать еще один заказ)

Есть такая проблема на самом деле, мы пытаемся придумать крутые условия для виртуального человека, а на собеседование приходит реальный. Просто спрашивайте у человек "как ты думаешь, какие условия работы позволят тебе максимально продуктивно выполнять работу, чтобы достигать таких-то примерно результатов" - слушайте что кандидаты говорить будут

Есть такая проблема на самом деле, мы пытаемся придумать крутые условия для виртуального человека, а на собеседование приходит реальный. Просто спрашивайте у человек "как ты думаешь, какие условия работы позволят тебе максимально продуктивно выполнять работу, чтобы достигать таких-то примерно результатов" - слушайте что кандидаты говорить будут

вот тоже подумала щас что под разные системы просто подходят разные люди

и возможно тут надо сначала определить какой тип человека нужен команде

kpi смещают фокус внимания работника на достижение циферок. при этом часто бывает, что процессы в компании еще не отлажены, а kpi уже проставлены

это да. может начать бомбить заказы, которые не очень

а целей или нет или пока спустили сверху вниз, забыли зачем такие показатели)

дело в том, что именно в нашем случае цель пошла снизу вверх и вверху отклик нашла)

а что такое "новенький" :)

новенький - это что он только что пришел на работу) новый в коллективе

нет, что вы. это плохой вариант требовать невозможного - будет демотивировать. я про это не писал. хорошая СМ - когда ты понимаешь, что ты можешь этого достичь, но тебе надо чуть напрячься, чтобы сделать больше. я просто опыт имею по такой работе, это реально мотивирует и ты считаешь цифры сколько тебе, например, оборотки, надо доделать и потом бомбишь акцию или прозваниваешь потенциальных клиентов, чтобы добрать еще один заказ)

опять же индивидуальные показатели), если про прибыль компании, то так или иначе командная работа и ее результат

ну это ж не детский сад

это профессиональный кружок :)

это в социальном плане он новенький, но при чем тут з.п.

игры для взрослых😂

не думал в таком ключе, по сути мы тоже так делаем: бонус после исп. срока)

у вас тоже командный бонус?

нет, ищем варианты как сделать реально командный, сейчас индивидуальные, но увязанные между участниками

это в социальном плане он новенький, но при чем тут з.п.

новенький в том плане, что не понятно наколько вольется в команду, как долго будет работать и какую ценность будет нести в перспективе

доверие идет на первом месте

увы

(в agile историях)

чтобы выполнение одного не мешало другими коллегам, а в идеале помогало)

про прибыль опять-таки, она должна получиться от нанесения пользы клиенту)))

Медведь главное чтобы умер

:)

Кстати собственник не хочет супер прибыли в развитие пустить чтобы вырасти в 2-3 раза?

а не в бонусы?

дело в том, что я пишу о вполне конкретной и реальной ситуации) например, у меня есть ощущение, что вот с коллегами прям сработались и там многие моменты просто понимаем уже и темперамент и вообще где-то можно предугать реакцию и перетягивания каната особо-то не наблюдается. и понятно, что реально каждый несет ценность, уже вложили не мало усилий. однако новенький - ему надо заслужить все-таки доверие, и принести накопительную пользу поэтому, наверное, действительно, лучше о командном бонусе пусть знает, но именно в схему : ) его включать после испытательно срока или если покажет какую-то ценность быстро (например, организовывает движуху, постоянно на подхвате, легко влился, привел массу клиентов)

Кстати собственник не хочет супер прибыли в развитие пустить чтобы вырасти в 2-3 раза?

бонус сотрудникам - это тоже инвестиция)

когда они занимаются управлением и говорят, мол, нужно больше мотивации)

лучше б зп по чуть-чуть повышать)

при стабильных хороших показателях

Кстати у Димы правда крутая история

из мира agile

Спасибо, Вячеслав) Это история не только моя, скорее я имею частично к ней отношение) У нас главный спец по Agile, Канбану коллега Михаил, который обучение проходил в Нетологии, если не ошибаюсь

кеке я в нетологии как раз рассказываю про kpi и мотивацию 😄

Я вообще почему этот вопрос поднял. У нас так как есть ретро и там по сути каждый имеет право голоса и если я потом выдвину тему с мотивацией и обосную что да как, коллеги смогут проголосовать и это будет внедрено)

кеке я в нетологии как раз рассказываю про kpi и мотивацию 😄

однако)

внедрить можно устоявшуюся практику

а на ретроспективе надо договориться об эксперименте

внедрить можно устоявшуюся практику

это какую?

ту которая себя зарекомендовала в результате успешного эксперимента

ретроспектива -> гипотеза -> проверка -> анализ результата -> "проголосовать что будет внедрено"

ну чтоб совсем взрослый agile был "если мы наймем продажника на таких-то условиях, то за 1,5 месяца испыт срока получим такие результаты"

:)

ок) будем пробовать)

всем спасибо за беседу)

Стоило мне уйти, в чат попал директолог!

Доброго пожаловать)

доброй ночи) спасибо

не просто попал, я здесь)

Дима ну чтобы команде (или отдельно продажнику) давать бонус с прибыли помимо оклада - эту прибыль еще нужно правильно, стабильно и одинаковым образом считать, плюс еще и человеческие отчёты той же команде предоставлять (без лишних "бухданных"), чтобы она понимала и видела динамику (возможно это даже как то в описания\комментарии досок вкючить, как вариант). Чего у нас сейчас увы нет) Хотя это уже новая тема и наверное не для данного чата🙂

это да

Всем привет, а подскажите плиз, как в рамках SAFe формировать вижен продукта для команды если ты PO? при условии что ты поставляешь небольшие проекты или кусочки（инкременты）продукта? и надо ли?

Если я правильно помню SAFe, вижен продукта пишется именно для продукта, а не для команды. Т.е. если несколько команд пишут один продукт, то и видение продукта у них одно.

Денис, спасибо! т.е. если на проекте несколько PO, то получается вижен должен быть один на всех PO

Вот, Вадим, проект не всегда равен продукт, потому именно в такой формулировке, так однозначно ответить нельзя. Если говорить, про ситуацию, когда на продукте несколько PO, то видение одно, но здорово, чтобы разбивка по командам была такая, чтобы каждая команда могла создавать независимо ценность для пользователя. В таком случае круто иметь каждой команде круто иметь свои метрики, для отслеживания эффективности и полезности того, что они поставляют пользователям

Вадим а покажите какой-нибудь вижен продукта, так сказать пообразовываться 🙂

Прошу прощения, есть проблемка с переводом с англ. инет почти не ловит, вопросов много, а времени мало и препод вышел ) Кто поможет?)

Простите ещё раз за офф но напишите в личку

#whois всем привет! Я отвечаю за развития портфеля продуктов в nullgravity. Правда мы делаем не собственные продукты, а отвечаем за продукты наших клиентов. Наш клиент - большие и медленные киты корпоративного бизнеса. Поэтому часто нужно менять процессы, подходы и делать достаточно радикально. В целом, ищем единомышленников которые не бояться ломать системы.

Подписка на #whois

#whois Привет, меня зовут Юрий. Я из г. Екатеринбурга, и работаю в СКБ Контуре. Занимаюсь базами данных MSSQL (DBA) для внутренних продуктов. Не имею понятия, чем могу быть интересен сообществу, однако, я ищу новые методы в работе с масштабными проектами (со стороны БД опять же), и интересуюсь agile. Про вас мне рассказал друг разработчик.

Задам первый глупый вопрос: Господа, чем эджайл может мне помочь со стороны управления жизненными циклами бд, управления коммандой, и интеграции с разработчиками в их процессе разработки и вводе в эксплуатацию новых продуктов?

что такое жизненный цикл бд?

А что интересует? План действий?

А что интересует? План действий?

План действий это забота ДБА. Интересует, в первую очередь, интеграция с разработчиками на этапе разработки. Честно говоря, я не очень хорошо представляю себе, что такое эджайл. Это некая форма существования ITIL?

жизнь - форма существования белковых тел 😀

что такое жизненный цикл бд?

Это жизнь бд от момента ее разработки, до момента отправки на бессрочное хранение. Оптимизации, бекапы, и все такое прочее

Остроумно. Это конфа микробиологов? Помогите мне клубнику склонировать!

Боюсь, что тут вам пока ничем не смогут помочь

А что у вас а работе нужно улучшить первым делом, как вы считаете?

План действий это забота ДБА. Интересует, в первую очередь, интеграция с разработчиками на этапе разработки. Честно говоря, я не очень хорошо представляю себе, что такое эджайл. Это некая форма существования ITIL?

если закопаться в какие-то философские основы, то суть может быть похожа, но как-то слишком далеко это понятия для меня)

А что у вас а работе нужно улучшить первым делом, как вы считаете?

Взаимодействие с разработкой. (Ломаем систему, да). Есть, например, некий сервис. Назовем его - CRM. У него довольно увесистая БД, 700Гб. Проблема: Разработчики не хотят замарачиваться с кодом, и добавлять возможность дробления бд на файловые группы (для увеличения производительности и повышения отказоустойчивости). Как можно убедить их в этом. Как сделать это правильно, как интегрироваться в процесс разработки ДБА? ДБА это, в сущности, сисадмины, только для СУБД, а не для служб.

А клиентов производительность устраивает?

Миграции кто делает у вас?

Теперь устраивает. После того, как команда потратила две недели на поиск и устранение недоработок. Остаются другие архитектурные проблемы, которые лучше и правильнее решать в процессе разработки.

Миграции кто делает у вас?

рабочие группы из ДБА, сисадминов и разрабов.

Взаимодействие с разработкой. (Ломаем систему, да). Есть, например, некий сервис. Назовем его - CRM. У него довольно увесистая БД, 700Гб. Проблема: Разработчики не хотят замарачиваться с кодом, и добавлять возможность дробления бд на файловые группы (для увеличения производительности и повышения отказоустойчивости). Как можно убедить их в этом. Как сделать это правильно, как интегрироваться в процесс разработки ДБА? ДБА это, в сущности, сисадмины, только для СУБД, а не для служб.

разработчики и не должны заморачиваться, оптимизации уровня БД - это задача DBA, плюс рекомендации разработчикам как писать запросы, чтобы база не обосралась, назовите это сводом правил или концвенцией, как у вас вообще DBA отслеживают косяки в БД, медленные запросы, есть какой-либо мониторинг?