Programmer
  • Менеджмент Scrum-проекта: не слишком ли часто мы отступаем от правил

    Вы в другом топике кажется писали про приход к компании «пушного зверя» если у нее начались проблемы с финансами ? Чем проект в этом случае отличается ?

  • Менеджмент Scrum-проекта: не слишком ли часто мы отступаем от правил

    scrumguides.org/...​-guide.html#product-owner The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. — ключевое is accountable — подотчетный. Смотрим толковый словарь — slovar.cc/rus/tolk/82317.html
    1. Выдаваемый с условием последующего отчета о расходовании ( о деньгах ) .
    2.Обязанный отчитываться ( в своей работе, действиях, расходовании средств и т.п. )

    Надеюсь убедил, Product Owner — в Scrum человек прямо ответственный за финансирование. Если в каком то проекте — это не так, значит роли в нем определены не правильно. Скорее всего там и вообще Fragile со «спиралью». О чем и все статья.

  • Менеджмент Scrum-проекта: не слишком ли часто мы отступаем от правил

    а финансы тут при чем??

    «Хліб усьому голова». Возможно вы опишите как можно отвечать за достижение целей проекта (согласно PM Book временного мероприятия для достижения результата) — не имея рычагов управления? Если цели проекта — это продукт, вот вам и ответ кто принимает решения в процессе. Даже при строительстве Беламор-каналла или Колизея — зеков и рабов кормить нужно было, аналогично организовывать конвоиров и надзирателей. Не считая логистики с производством и доставкой строй материалов и всего необходимого. Так что все намного проще чем кажется «No money, no honey», и просто из практики — до того как подключается человек принимающий финансовые решения никакие вопросы не решаются. Scrum Muster — вообще другие вопросы призван решить в гибком процессе, а конкретно посредник балансирующий интересы сторон (Свиней и Куриц), известную проблему продавца и покупателя — " Покупать — дорого, продавать — дешево". Это осуществляется через введение процесса — т.е. рядя стандартных процедур (практик). Как то — постановка целей, оценка сложностей и объемов работ, выявление и управление рисков , контроль исполнения и т.д. Скрам мастер следит чтобы все процессы применялись и исполнялись.

  • Менеджмент Scrum-проекта: не слишком ли часто мы отступаем от правил

    Product Owner — он и есть лицо финансово отвечающее за проект и достижение им целей. Тоесть управляющий — manager. Реально такой человек (лицо принимающее решение) есть всегда. В общем — кто платит тот и главный как обычно. Есть правда ситуации когда в команде есть — Product Owner — но это на поверку бизнес аналист, контрагент и т.п. — тоесть человек который никаких финансовых вопросов полномочий решать не имеет. Тогда как настоящий менеджер — якобы «супервайзит».

    Підтримав: Anastasiia Moskalenko
  • Менеджмент Scrum-проекта: не слишком ли часто мы отступаем от правил

    Да даже с церемониями есть большой вопрос. Например когда зозвон по статусам задачь в ходе которого отслеживают что проект в диаграмме Ганта идет по намеченному плану (двигают джира тикеты по борде) — называют daily stand up. Но это вообще ничего общего не имеет с stand up-ом, и вообще с командной работой над проектом. В таком «стандапе» даже тупо молчать можно — если на тебе тикетов не за асайнено (скажем все сделал, и до релиза в беклоге больше ничего нет, за самоуправство вроде закрытие тех депта — еще и выговор схватишь).

    Підтримав: Yuriy Sultanov
  • Менеджмент Scrum-проекта: не слишком ли часто мы отступаем от правил

    Имеется в виду — что команде не нужны командиры на каждый чих. Они могут самостоятельно выполнять всю работу, и если нужно самостоятельно связаться с пользователями системы и решить все вопросы. В условиях аутсурсинга и тем более аутсафинга, почти что полностью невыполнимое требование из за особенностей бизнеса. Скажем некая команда в «СНГ» пишет софт для заказчика в Великобритании. Этот софт используют в колл-центре. Сам кол центр — это третья компания из Индии. Без контрагентов на стороне заказчика — разработчики вообще слепо-глухо-немые. Никаких прямых контактов между пользователями и разработчиками физически быть не может.

  • Менеджмент Scrum-проекта: не слишком ли часто мы отступаем от правил

    По статистике во всем IT — 75% не гибкие подходы, включая FANNG-и т т.д. Если руководитель не понимает как оценивать проекты по стоимости в гибких подходах — будет галера которая для моды будет заявлять что работает по гибкой методологии. Но ходить на тренинги руководству самим в западло и они поэтому посылают туда: программистов, аналистов и тестировщиков — а потом в работе все равно все по старому. Надо ещё учесть что половина — вообще не планирует работу даже через диаграмму Ганта. Просто есть распорядка — " закончить к Декабрю до Черной Пятницы«. И погонщики плетьми будут гнать всех в шею и овертаймы, даже если такой объем физически выполнить текущими силами невозможно. А под конец ещё и увеличат команду в двое понимая что никак не успеть. А тут вдруг «закон Брукса» ... В общем это уже к топику про «некомпетентность в ИТ».

    Підтримали: Serge Loboda, Yuriy Sultanov
  • Менеджмент Scrum-проекта: не слишком ли часто мы отступаем от правил

    В общем результаты опросов которые провели авторы только подтверждают результаты исследований которые провели NASA. Пытаясь понять почему введение agile не приносит результата в большой части команд, тогда как в других напротив к внушительные результаты — выяснилось что в тех командах где результата нет — никакого agile тоже нет. Там только декларируется что есть гибкие методологии — а на самом деле другие процессы, как правило бюрократические с откровенной тиранией. В итоге это назвали Fragile (липовый agile) также известен термин ScrumBan или Срам. По итогу ввели методику оценки проектов чтобы отделять настоящие гибкие методологии от фальшивки habr.com/ru/post/436866 и
    Из моей практики большая часть команд «работающих по Scrum» — в лучшем случае работают по водопадному подходу с диаграммой Ганта. А как правило вообще по «ляп ляп и в продакшн». Причем изменить процесс может фактически только профессионалы из специальных организаций или отделов вроде PMO. Причем смысла работать с рядовыми исполнителями сразу нет — на гибкие методологии должно пойти начальство. Иначе толку не будет никакого.

  • Что большая ценность для компании — люди или клиенты?

    «Жирный» заказ/подряд — совсем не обязательно принесет прибыль. Очень даже может быть что наоборот — убытки, ещё и все нервы выпьет. Как раз и держат бенчи поэтому те кто может себе это позволить — чтобы не попасть на бабки рекрутируя непосредственно перед подписанием контракта.

    Підтримали: Vi, Sergey Lysak
  • Як правильно отримати контроффер?

    HR директор может заставить менеджера дать денег даже против воли последнего. Допустим если у него мнение — что если он даст денег вот этому, то придут все и спросят дать и им. Поэтому принципиально всем кто так делает — до свидания. Однако найм сотрудника весьма не дешовое мероприятие, и увольнение тоже и вполне просчитывается математически. HR-ы регулярно это делают. Если менеджер не знает что с подобной ситуацией делать — предложить план и условия повышения зарплаты, и более того, потому что он не делал регулярные 1-1 и т.п. он сам пришел к этой ситуации — затаит обиду. Поэтому если вам дадут денег просто так — не предложив качественно более дорогостоящей работы, оставаться смысла нет. Т.е. риски более чем оправданные.

  • Чи вказуєте Ви досвід роботи з проваленого випробувального

    Насправді пробіл в три місяці нікого не цікавить. Якщо ви у випробувальний період не робили нічого цікавого — що буде корисним для вашого резюме, просто нічого не пишіть і все. Все що ви там напишете — це привід задати про це додаткове питання на співбесіді.

  • Пишемо консольний двопанельний менеджер на Linux shell

    Взагалі круто. Але є midnight commander, чому саме ця тема ? От кольорових du та df які одразу видають людський вивід замість скріптового — нема.

  • Что большая ценность для компании — люди или клиенты?

    Різне буває. І клієнти які на три місяці, і стрибуни на три місяці.

  • Тулсет разработчика 2021

    • Голова которой думать
    • Руки которыми делать
    • Попа на которой сидеть
    • Туловище которым переваривать хачи для работы головы
    • Компьютер с выходом в интернет
    Вроде пять, все остстальное не столь принципиально. Вот без git очень неудобно было бы. CVS, SVN, Perforce и Mercurial больше не хочу использовать- отвык.
    Підтримав: Сашко Чехоцький
  • Что большая ценность для компании — люди или клиенты?

    Умный директор был. К сожалению ситуация классическая.

  • Что большая ценность для компании — люди или клиенты?

    В большинстве хитрых комбинаций — жертвуют ферзем, тем самым загоняют оппонента в ловушку и ставят мат.

  • Что большая ценность для компании — люди или клиенты?

    Что тогда дело для менеджеров ? Малевать презентации для митапа с надписями «Very important» ?

  • Что большая ценность для компании — люди или клиенты?

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

    Підтримав: Микита Підлісняк
  • Что большая ценность для компании — люди или клиенты?

    Закроют позиции без проблем. Подберут правильных собеседующих и т.д. Однако Фредерик Брукс в «мифический человеко месяц» — назвал этот метод «тушить пожар бензином». Получите половину штата новичков которым надо найти: место, оборудование, заонбордить и пройти стажировку. Поэтому менеджмент их посадит ворон считать в окне чтобы не отвлекать команду пока она проекты допиливает в овертаймы. Новички в отместку будут снимать видосы где тетрадку к клавиатуре «подключают» за неимением ничего другого к чему ее можно подключить и лысый тимлид в свитере пчёлки бегает на цыпочках между джуниорами.

    Підтримали: Vi, Sergey Lysak
  • Что большая ценность для компании — люди или клиенты?

    Если работников найти легче зачем платить HR-ам с бонусами ? У кого то HR процесс сильный в конторе, у кого то Sales of Marketing. В общем — аргуметов в реплике не вижу.

← Сtrl 1... 766767768769770...796 Ctrl →