AL
Т.е. он может сказать - "Задача в рамках срока и бюджета (не)выполнима". А вот дальше уже да, рабочей группой заказчика есть основания для принятия решения.
Size: a a a
2019 August 12
YR
А как может PM не вмешиваться в скоуп и бюджет? В смысле абсурдно отвечать за результат и не иметь полномочий управлять областью решения.
Александр, у РП должны быть очень ограниченные возможности вмешиваться в параметры проекта. РП должен доложить на верхний уровень (программу или портфель) о необходимости изменений. Из уррвня проекта ее видно того как будет использоваться пезультат
YR
Т.е. он может сказать - "Задача в рамках срока и бюджета (не)выполнима". А вот дальше уже да, рабочей группой заказчика есть основания для принятия решения.
А ему с вышестоящего уровня либо добавят ресурсов, либо времени либо разрешат не делать вообще. Но не он сам этотрешит.
2019 August 14
МД
Всем привет:)
Надеюсь, ничем меня не закидаете😊
Наш PM сейчас переходит на другую должность, очень нужна ему замена. Компания Piano.io
Общение с Нью-Йорком и Братиславой, поэтому очень важен английский язык)
Нужно будет координировать 2-3 проекта по аналитике данных.
Спасибо за внимание😊
Если кого-то заинтересовало, пишите в личку)
Надеюсь, ничем меня не закидаете😊
Наш PM сейчас переходит на другую должность, очень нужна ему замена. Компания Piano.io
Общение с Нью-Йорком и Братиславой, поэтому очень важен английский язык)
Нужно будет координировать 2-3 проекта по аналитике данных.
Спасибо за внимание😊
Если кого-то заинтересовало, пишите в личку)
2019 August 15
Е
Добрый день, хотела бы пригласить на конференцию по биг дата, к кому бежать за разрешением? или это не совсем релевантно вам?
2019 August 19
👉Б
✅✅✅
Друзья, привет!
Меня зовут Бобров Алексей.
Я бизнес брокер. Помогаю продать Ваш бизнес или купить для Вас при необходимости.
Создал 3 компании и успешно их продал с х15 💪.
❗ Моя история кто не знает (чтение займет 3 минуты) 👉 https://teletype.in/@alexey_bobrov
Пишите / звоните!
Я расскажу как выгодно продать Ваш бизнес от х6-36 прибылей за 1 день 💪!
Мой телефон 👉 +7 (926) 520 83 85
WhatsApp по ссылке 👉 https://clck.ru/HbfCH
Инстаграм 👉 https://www.instagram.com/_alexeybobrov/
✅✅✅
Друзья, привет!
Меня зовут Бобров Алексей.
Я бизнес брокер. Помогаю продать Ваш бизнес или купить для Вас при необходимости.
Создал 3 компании и успешно их продал с х15 💪.
❗ Моя история кто не знает (чтение займет 3 минуты) 👉 https://teletype.in/@alexey_bobrov
Пишите / звоните!
Я расскажу как выгодно продать Ваш бизнес от х6-36 прибылей за 1 день 💪!
Мой телефон 👉 +7 (926) 520 83 85
WhatsApp по ссылке 👉 https://clck.ru/HbfCH
Инстаграм 👉 https://www.instagram.com/_alexeybobrov/
✅✅✅
2019 August 29
YR
Товарищи, кто-нибудь читал или встречал русский текст статьи, Винстона Ройса которой приписывают основоположение Waterfall "Управление разработкой больших программных систем"?
2019 September 05
AM
Привет!
Решили поработать с рисками на старте нового проекта.
Появился такое мнение, что в среде софтварных разработок основные риски давно уже определены, и их можно где-то позаимствовать, не изобретая велосипед.
Так-ли это на ваш взгляд ? или всегда все зависит от проекта, команды, бюджета и тд
Решили поработать с рисками на старте нового проекта.
Появился такое мнение, что в среде софтварных разработок основные риски давно уже определены, и их можно где-то позаимствовать, не изобретая велосипед.
Так-ли это на ваш взгляд ? или всегда все зависит от проекта, команды, бюджета и тд
A
Привет!
Решили поработать с рисками на старте нового проекта.
Появился такое мнение, что в среде софтварных разработок основные риски давно уже определены, и их можно где-то позаимствовать, не изобретая велосипед.
Так-ли это на ваш взгляд ? или всегда все зависит от проекта, команды, бюджета и тд
Решили поработать с рисками на старте нового проекта.
Появился такое мнение, что в среде софтварных разработок основные риски давно уже определены, и их можно где-то позаимствовать, не изобретая велосипед.
Так-ли это на ваш взгляд ? или всегда все зависит от проекта, команды, бюджета и тд
Привет!
Всмысле позаимствовать способы их нивелировать?
По-моему в общем плане они будут какие-то похожие почти везде, типа "если не будет разработчиков, то мы сорвем проект". Но в итоге сам проект, обстоятельства со стороны клиента и с вашей стороны сделают детали этих рисков и способы их снижения индивидуальными.
Всмысле позаимствовать способы их нивелировать?
По-моему в общем плане они будут какие-то похожие почти везде, типа "если не будет разработчиков, то мы сорвем проект". Но в итоге сам проект, обстоятельства со стороны клиента и с вашей стороны сделают детали этих рисков и способы их снижения индивидуальными.
AM
Привет!
Всмысле позаимствовать способы их нивелировать?
По-моему в общем плане они будут какие-то похожие почти везде, типа "если не будет разработчиков, то мы сорвем проект". Но в итоге сам проект, обстоятельства со стороны клиента и с вашей стороны сделают детали этих рисков и способы их снижения индивидуальными.
Всмысле позаимствовать способы их нивелировать?
По-моему в общем плане они будут какие-то похожие почти везде, типа "если не будет разработчиков, то мы сорвем проект". Но в итоге сам проект, обстоятельства со стороны клиента и с вашей стороны сделают детали этих рисков и способы их снижения индивидуальными.
Ну, я думаю тут имеется ввиду «не реальный бюджет» или что-то в таком духе.
AM
Я просто думал всегда что общих рисков нет - все индивидуально
AM
Просто какой смысл заимствовать чужие риски? ( пусть даже они где-то и одинаковые были)
Суть идентификации рисков, чтобы кажды подумал и предложил свои варианты.
Суть идентификации рисков, чтобы кажды подумал и предложил свои варианты.
2019 September 07
YR
Артем, типизация,рисков действительно имеет место быть. В т.ч. и для разработки софта. Это:
Не уложиться в срок, превысить бюджет, не выполнить ТЗ/Requirements/Backlkog.
Не уложиться в срок, превысить бюджет, не выполнить ТЗ/Requirements/Backlkog.
YR
Привет!
Всмысле позаимствовать способы их нивелировать?
По-моему в общем плане они будут какие-то похожие почти везде, типа "если не будет разработчиков, то мы сорвем проект". Но в итоге сам проект, обстоятельства со стороны клиента и с вашей стороны сделают детали этих рисков и способы их снижения индивидуальными.
Всмысле позаимствовать способы их нивелировать?
По-моему в общем плане они будут какие-то похожие почти везде, типа "если не будет разработчиков, то мы сорвем проект". Но в итоге сам проект, обстоятельства со стороны клиента и с вашей стороны сделают детали этих рисков и способы их снижения индивидуальными.
Есть 4 типовых стратегии реагирования на любые риски.
2019 September 08
А
Есть 4 типовых стратегии реагирования на любые риски.
Жги! ))
YR
Я бы уклонение немного иначе сформулировал. Плюс у передачи есть разновидность: эскалация. А так нормальная картинка.
А
Я бы уклонение немного иначе сформулировал. Плюс у передачи есть разновидность: эскалация. А так нормальная картинка.
в лс загляни
AV
когда я думаю о рисках я вспоминаю... %)
2019 September 09
ЮЗ
Всем привет!
Есть такой вопрос.
В спринте как правило несколько релизов (релиз, хотфикс). Каждый новый релиз выпускает версию. Эти версии указываются в задачах в jira. В таком случае в задачах на хотфикс нужно менять версию, а также создавать релизы.
Этот процесс удобен разработчикам, но добавляет лишней работы менеджеру. Есть ли альтернативный вариант?
Поделитесь мнением на этот счет
Есть такой вопрос.
В спринте как правило несколько релизов (релиз, хотфикс). Каждый новый релиз выпускает версию. Эти версии указываются в задачах в jira. В таком случае в задачах на хотфикс нужно менять версию, а также создавать релизы.
Этот процесс удобен разработчикам, но добавляет лишней работы менеджеру. Есть ли альтернативный вариант?
Поделитесь мнением на этот счет