« Rev
@agile_ru   428
Fwd »


Vladislav
Окей, спасибо :)
Ермолаева
Коллеги, добрый день! Я занимаюсь вопросами­ эффективности Agile­ в Retail в рамках ди­ссертации. Если Вам н­е сложно, пройдите, п­ожалуйста опрос: http­s://docs.google.com/f­orms/d/1CpmhnRLEz6wvG­qK5Y_Nd8fKkhbjRk8skJ9­1Br4SgYcU Поможем отечественной­ науке вместе!
Stanislav
😁 На мой слоган похоже
Stanislav
И с ссылкой какая-то проблема
Ермолаева
https://docs.google.com/forms/d/1CpmhnRLEz6wvGqK5Y_Nd8fKkhbjRk8skJ91Br4SgYcU/edit?chromeless=1
Vitaly
https://docs.google.com/forms/d/1CpmhnRLEz6wvGqK5Y_Nd8fKkhbjRk8skJ91Br4SgYcU/edit?chromeless=1
Вам бы на представителей Детского Мира выйти...
Slava
Чтобы помочь отечественной науке, сначала надо терминологическую базу сделать отечественной.
Slava
А не писать в вопросах "Agile методологии". Хрень
Slava
Если дословно написать "гибкие подходы к разработке п.о." - то половину вопросов потеряют смысл.
Irina
Про эффективность прям интересно, что люди понимают под ней. В отечественной науке есть крен не прорабатывать теоретическую рамку вообще.
Slava
Да, правильные слова - продуктивность и выработка. О какой тут "науке" идет речь :)
Asja
одна из задач опросника: "как оценивать эффективность гибкого проектного управления и какие именно критерии являются наиболее важными при оценке эффективности." = и на эту тему (точнее, типа на эту) тут три вопроса. простите, но чот странное. (плюсую к вышесказанному)
Max
Чтобы помочь отечественной науке, сначала надо терминологическую базу сделать отечественной.
Как то с ног на голову.. Термины создаются вследствие научной деятельности, а не наоборот. Исследовали/изобрели раньше вас? Заимствуйте термины
Denis
>Повысить удовлетворенность заказчика
Denis
ржу
Denis
софт оказывается для заказчика, а не пользователей делают
Ермолаева
софт оказывается для заказчика, а не пользователей делают
Вы, наверно, не сталкивались с внутренними заказчиками, когда они и являются пользователями. И да, софт создают по заказу заказчика, а не по запросу пользователя. В свою очередь, заказчик формирует требования исходя из запросов пользователей (а может из своих тараканов). А всем пользователям никогда в жизни не угодишь)
Denis
Не противоречит. С любым customer можно работать. Ценность Agile это customer collaboration, а не end user statisfaction.
каллобарировать с какой целью? сделать качественный продукт же. это и есть ценность agile. если цель - мы вам деньги - вы нам конкретное решение то а) ценность продукта для пользователей уходит на второй план б) зачем колаборироваться, мы вам деньги платим не за то, что бы мы с вами вместе делали
Андрей
Это в @agile_jobs
Mikhail
О_О
Mikhail
Работающий продукт важнее исчерпывающей документации.
Pavel
Если ваш customer не считает удобство для end users чем-то важным - это его сувереное право.
Stanislav
Господа, есть команда, которая занимается разработкой, у нее есть свои стейкхолдеры (например, заказчик). Задача команды сделать так, чтобы заказчик был удовлетворен. Задача заказчика - формировать свои требования так, чтобы пользователь был удовлетворен. Это мое мнение, не претендующее на истину.
Denis
Если ваш customer не считает удобство для end users чем-то важным - это его сувереное право.
Явно не написано, это если хотите моя интерпретация с чем ценности совместимы. Так вот ответьте на вопрос, если мне чихать на удобвство для end users зачем мне нужны все итерации? Для чего нужна адаптивность? Что бы улучшать продукт, так ведь?
Pavel
Вот для этого нужны итерации
Denis
То есть вы хотите сказать, что можно делать cometitive advantage не улушая продукт для end users?
Pavel
Да, разумеется.
Pavel
Т во многих случаях так и происходит :)
Denis
Ну, дело ваше
Daniil
Павел, объясните пожалуйста на примере
Daniil
Как это может быть
Pavel
Например вы делаете бухгалтерский софт и быстро внедряете поддержку новых изменений в законодательстве.
Pavel
ДЛя end user ничего не меняется, для customer - многое.
Denis
если ваши end users не могут быстро увидеть уведомления об обновлениях, толку от них?
Daniil
Но почему не меняется. Меняя справочник и информацию в выводе, вы автоматом меняете пользовательский опыт...
Pavel
Или вы делаете e-commerse платформу и включаете поддержку проверки остатков товара через 3rd-party ERP :)
Daniil
Пусть даже незначительно, чисто визуально, но значительно, с точки зрения основного бизнес-процесса
Pavel
Опять же для end users ничего не меняется, зато для customer - очень много.
Pavel
В общем, примеров, когда изменение для customer не равно изменению для end users - масса.
Denis
и я вообще не понимаю это антогонии заказчик-бухгалтеры. а бухгалтеры типа совковые овощи, которым срать получают они обновления или нет? если так, то я уже сказал. Напишите ТЗ, и побольше туда НАЕБАЛОВА, тогда все будетв шоколаде.
Pavel
Вот вам совсем линейный пример: вы добавляете для customer поддержку автоматизированного деплоя решения в облако.
Pavel
end user никак не увидит изменений. Зато customer увидит, и сможет использовать это в качестве competititive advantage при продаже своей e-commerce платформы.
Denis
если end users не получает быстрее обновлений за счет деплоя, то можно сказать эффекта от него не было. зато закачик удовлетворен, че, контракт подписан, фича запилена.
Pavel
Денис, у вас излишне радикальные взгя=ляды на end user :)
Denis
=)
Pavel
В цепочке developer-customer-user у customer может быть как цель улучшить user experience, так и уменьшить операционные расходы.
Pavel
End user в системе может не иметь никакого отношения к получению прибыли от проудкта.
Pavel
Хороший UX может вообще противоречить хорошей прибыли для customer
Stanislav
Согласен с Павлом, заказчики бывают разные: как конечные пользователи, так и промежуточные - внутренние. В этом и состоит противоречие
Stanislav
И задача - удовлетворить своего заказчика
Pavel
Если вы хотите "настоящий Agile" и collaboration with business - изучайте бизнес кастомера.
Андрей
End user в системе может не иметь никакого отношения к получению прибыли от проудкта.
На b2b рынке всё так, как пишет Павел, вплоть до прямого конфликта интересов end users и заказчика разработки. Если же вы работаете на b2c, то ваш заказчик и ваш end user суть одно и то же, но начинаются другие пляски - массовость и непротиворечивость запросов от разных пользователей :) Балансировать всегда приходится, и «быть хорошим для всех» вряд ли выйдет, но помнить о ценностях и принципах Аджайла всегда стоит
============ FALCON ============
В контексте фейсбука кастомером кто является?
============ FALCON ============
Заказчик он и есть конечный пользователь?
Pavel
Заказчик он и есть конечный пользователь?
В конетксе фейсбука - является. Но не единственным.
Dmitry
коллеги, всем привет. есть вопрос, просьба не закидывать тапками и не предлагать устраивать революций
Grigory
Всем привет. так случилось что тимлид есть. вопрос: для развития технического лидерства видел кто нибудь какие нибудь игры?
Grigory
про чат рядом знаю, но там нет народа
Yehor
Привет, ребят подскажите может знаете чаты, группы по менеджменту. Заранее благодарен
Dmitry
итак: есть ли какой нибудь scaled-framework который можно применить в гибридной среде. т.е там, где частично - создание продуктов (в основном scrum), часть - классические проекты с проектной корп. методологией на основе PMBOK. задачи - синхронизация и отчетность руководству (да, руководство просит отчетность). цель - облегчить жизнь PO/SM/PM, чтобы все внепродуктовые и внепроектные активности (совещания, отчеты и т.д) протекали максимально безболезнено
Dmitry
А интеграция на нижнем уровне - это чьё требование? Раз PM сверху то может они и займутся?
не интеграция а синхронизация. если хотите - портефльное управление
Denis
не, я попутно пытаюсь работать
Незачем было рвать сообщения на 2, есть перенос строки
Grigory
полюбас safe и интеграция через ART
Max
не интеграция а синхронизация. если хотите - портефльное управление
Тогда поясните пожалуйста что понимается под синхронизацией. Если интегрировать результаты нескольких команд не требуется, то и scaled не нужен. Допустим, митингов хватить может.
« Rev
@agile_ru   428
Fwd »