Надеюсь Вы не станете утверждать, что, при прочих равных условиях, наличие профильных знаний у менеджера не способно уменьшить вероятность возникновения рисков при управлении проектом?
В этом и задача упраления рискам — что и как сделать так, что бы отрицательный риск(и) выбранные из идентифицированных возникли с минимальной вероятностью или минимизровать их ущерб.
Например — если есть риски «нет компетенций по XYZ», то нужно решить что делать:
обучать самому перед! началом проекта
нанять специалиста
исключить «XYZ» или заменить на «ABC»
обучать самому по ходу проекта, скорректировав план и бюджет
отказаться от проекта
зарезервировать некоторый «бюджет» если риск сработает
Или вы хотите сказать, что пункты 1...4 не снижают веростность риска?
Все в ваших руках :)
Вы же понимаете, что soft skills это общее название всего, что относится к взаимодействию с людьми? Это даже не вопрос менеджмента, это обязательное качество любого участника команды, просто менеджмент их более интенсивно использует.
Программисты между собой никак не общаются что бы код написать? или тестеры? или бухгалтера? А бизнес аналитикам общение не требуется? или все эти «ресурсы» между собой никак не общаются?
Возьмем к примеру такую «простую» штуку, как «Communication Plan» — документ регламентирующий процессы общения (кто, когда, о чем и как должен быть информирован) внутри команды\проекта.
Его же придумали по какой-то причине? Устав армейский, регламентирующий общение. Формализированные нотации (UML, IDFx, BPMN и т.д.)
В этом то все и дело.
Все человеческое общение сводится к первому шагу — общий словарь понятий (глоссарий). Не будет его — дальше не имеет смысла. Выделять какую-то группу "… их более интенсивно использует"? Это заблуждение.
Работа менеджера это именно коммуникации И настройка и поддержание процессов.
Мне больше нравится другое определение — менеджер, это человек который должен решать те проблемы, для которых еще нет решений (инструкций). Результат его работы — это инструкции, как поступать в некоторой ситуации, что бы достичь результата.
Для поддержания процесса — достаточно надсмотрищика или любой системы с движком бизнес процессов :)
Ни о каком «движении в противоположную сторону» речь не может идти от слова совсем.
Плодятся новые сущности (процессы), просто «потому что Soft Skills»? так это выглядит.
На мой взгляд, задается (обозначается?) весьма интересная проблема: использование всяких PMBok (Scrum) это движени в сторону более формализированного общения и взаимодействия. Попытки минимизировать какие-то субъктивные критерии и мехнизмы в проектном управлении.
А после делается рекомендация — надо применять «Soft skill», а это движение ровно в противоположную сторону.
Что-то вроде «я тебя не буду бить ногами если ты ...»?
Не вижу разницы между «бить ногами физически» и «психологическим давлением» что бы вести проект внутри команды. Либо карты на стол и соблюдение условий с обеих сторон — или одна из сторон начинает «вооруженный нейтралитет».
Изначально это не верная стратегия (на мой взгляд), хотя иногда необходимое зло.
Ты знаешь, мне кажется, что тебе не хватает знаний работы с людьми. Переговоры, решение конфликтов, убеждение, мотивация и типология людей, как люди ведут себя, в каких ситуациях и почему именно так.
То есть требуется еще знания психологии. Но ведь какой нюанс — психология подразумевает два правила: культурные различия и быть «вне процесса».
Культурные различия — подразумевает что вы не должны судить только по своим критериям, но и должны знать чужие (особенно если "… иншааллах", говядина для индусов и т.д.).
Быть вне процесса — не ругатья с «ленивым программером», а смотреть как с ним ругается Пупкин.
Обучение психологии — лет пять учебного заведения.
Таким образом в нормальном мире — проектный менеджер будет готов лет после 15 обучения и некоторой практики :)
Или под Management Soft Skills — подразумевется нечто другое? Есть какой-то чеклист, тесты-сертификаты для Soft Skills?
Управлять рисками можно с помощью управления рисков.
Управлять рисками можнонужно с помощью управления рисков.
Полагаю, что с этого нужно начинать :)
А все прочее — просто инструмент для управления рисками (хотя бы на этапах идентификации и анализа).
Как вы видите повышение эффективности менеджера если он знает программирование?
Менеджеру это скорее полезный навык, позволяющий повысить положительные риски и понизить отрицательные. Команда и технологии — это инструмент менеджера и он обязан их хотя бы понимать.
К примеру — корректно проектными метриками оперировать. Корректно понимать жизненный цикл решения. Корректно организовать работу с проектной документацией.
Корректно посчитать бюджет проекта.
Корректно объяснить Клиенту «почему именно так» и «что будет если ...».
Когда приходит менеджер проекта и говорит — я уже пообещал что «мы ЭТО сделаем к....» — это просто ()o().
Хотя бы что бы понимать, куда ему самому не стоит лазить без команды. Если менеджер проекта сможет просмотреть проектную документацию и найдет там проблемы, хотя бы на уровне не покрытого или противоречивого требования — вообще будет хорошо.
Skype вроде проходил аудит фсб когда его купили МС и начали «улучшать». Тогда много забавных вещей вылазило — и идентицикация IP логина, и куски переписки. В общем ФСБ одобрили :)
Разве в россии не поддерживаются юридически механизмы защиты?
Обычно есть формулировка типа: Заказчик обязан предоставить… Если простой по вине Заказчика, то оплачивается заказчиком… Процедура приемки, согласно…
Утверждаю — идеален на любом языке. Ибо язык собственно не причём. Почитайте на досуге про верификацию компиляторов.
В зависимости от языка и среды исполнения вам придется или специально проектировать код для такого механизма или извратиться так, что усилия превысят разумые пределы.
У вас есть С++ — в добрый путь :)
в .Net тоже можно извратиться весьма сходно — но «цена» и сложность превысит сложность проверяемого кода.
Модуль или юнит — минимальный кусок кода, который можно протестировать независимо от всего остального кода. Тестирование модулей так же известно как «юнит-тестирование».
1. А насколько независимо от остального кода? какой критерий «независимо»? Например код типа «трансформация данных» или «парсер»/сериализатор/десериализатор к какому будет относится типу?
2. К какому типа будет относится проверка «workflow» если вопрос стоит «корректный да-нет»?
Unit -Component — Integration?
Можно все позапрещать, но только на бумаге — люди будут использовать то, что им удобно. И многие захотят иметь в своей кубышке валюту, которую государство не сможет отнять или аннулировать, в отличии от банковского счета, имущества и иных способов сохранения вложений.
На мой взгляд все просто — у себя дома, делай что угодно. Но при выходе в Большой Мир, следуй его правилам. Хочешь дома варить самогон? да хоть бассейн и плавай в нем:) Но если на продажу — будь добр пройти санитарный контроль, лицензию на торговлю и т.д.
Так же и с крипто — майни себе сколько влезет. Только оплати электричество. Хотешь купить дом за критпо? Объясни доход в размере рыночной цены дома, оплати налоги и т.д.
Взял на себя обязательства? Исполняй их — пофиг в чем. крипто? доллары? акции и т.д.
что в случае банковских карт вы ДОВЕРЯЕТЕ кроме парня еще и банку, то я не знаю, что и сказать.
Не верно. это ДВЕ разные сделки. Сделка доставки денег «Тому Парню» — это банк. Это одна из тех сделок (операций), на которую предендуют криптовалюты :)
А тут, как Клиент, я не вижу вообще никакой разницы. Цена и скорость — эта два моих критерия :)
Я же говорю, доверие — не про честность сделки, а про ФАКТ перевода денег.
Вот как раз факт перевода денег вообще никого нет интересует.
Всех интересует доказательства факта отправки и факт получения денег. При этом всех интересует механизм гарантированной доставки денег, скорость и цена доставки.
Пока крипто не продемострировали ничего внятного из этого.
Обычный «мелкий» магазин с 10 кассами выдаст от 200 тразакций в час (без проблем). с учетом того что таких магазинов порядка 5 на 50 тыс населения, не считая аптек, ларьков, рынков мелких — не большой микрорайон положит платежную криптосеть за минут 10...30 на всем земном шаре :) сколько там идет транзакция в биткоине? 15 мин? :)
Удачи сходить за прохладными напитками :)))))))
А если развивать — так это лет 5...20 пока будет возможный эффект.
Так проще :)
В этом и задача упраления рискам — что и как сделать так, что бы отрицательный риск(и) выбранные из идентифицированных возникли с минимальной вероятностью или минимизровать их ущерб.
Например — если есть риски «нет компетенций по XYZ», то нужно решить что делать:
Или вы хотите сказать, что пункты 1...4 не снижают веростность риска?
Все в ваших руках :)
Программисты между собой никак не общаются что бы код написать? или тестеры? или бухгалтера? А бизнес аналитикам общение не требуется? или все эти «ресурсы» между собой никак не общаются?
Возьмем к примеру такую «простую» штуку, как «Communication Plan» — документ регламентирующий процессы общения (кто, когда, о чем и как должен быть информирован) внутри команды\проекта.
Его же придумали по какой-то причине? Устав армейский, регламентирующий общение. Формализированные нотации (UML, IDFx, BPMN и т.д.)
В этом то все и дело.
Все человеческое общение сводится к первому шагу — общий словарь понятий (глоссарий). Не будет его — дальше не имеет смысла. Выделять какую-то группу "… их более интенсивно использует"? Это заблуждение.
Мне больше нравится другое определение — менеджер, это человек который должен решать те проблемы, для которых еще нет решений (инструкций). Результат его работы — это инструкции, как поступать в некоторой ситуации, что бы достичь результата.
Для поддержания процесса — достаточно надсмотрищика или любой системы с движком бизнес процессов :)
Плодятся новые сущности (процессы), просто «потому что Soft Skills»? так это выглядит.
А после делается рекомендация — надо применять «Soft skill», а это движение ровно в противоположную сторону.
Что-то вроде «я тебя не буду бить ногами если ты ...»?
Не вижу разницы между «бить ногами физически» и «психологическим давлением» что бы вести проект внутри команды. Либо карты на стол и соблюдение условий с обеих сторон — или одна из сторон начинает «вооруженный нейтралитет».
Изначально это не верная стратегия (на мой взгляд), хотя иногда необходимое зло.
То есть требуется еще знания психологии. Но ведь какой нюанс — психология подразумевает два правила: культурные различия и быть «вне процесса».
Культурные различия — подразумевает что вы не должны судить только по своим критериям, но и должны знать чужие (особенно если "… иншааллах", говядина для индусов и т.д.).
Быть вне процесса — не ругатья с «ленивым программером», а смотреть как с ним ругается Пупкин.
Обучение психологии — лет пять учебного заведения.
Таким образом в нормальном мире — проектный менеджер будет готов лет после 15 обучения и некоторой практики :)
Или под Management Soft Skills — подразумевется нечто другое? Есть какой-то чеклист, тесты-сертификаты для Soft Skills?
Управлять рисками
можнонужно с помощью управления рисков.Полагаю, что с этого нужно начинать :)
А все прочее — просто инструмент для управления рисками (хотя бы на этапах идентификации и анализа).
Менеджеру это скорее полезный навык, позволяющий повысить положительные риски и понизить отрицательные. Команда и технологии — это инструмент менеджера и он обязан их хотя бы понимать.
К примеру — корректно проектными метриками оперировать. Корректно понимать жизненный цикл решения. Корректно организовать работу с проектной документацией.
Корректно посчитать бюджет проекта.
Корректно объяснить Клиенту «почему именно так» и «что будет если ...».
Когда приходит менеджер проекта и говорит — я уже пообещал что «мы ЭТО сделаем к....» — это просто ()o().
Хотя бы что бы понимать, куда ему самому не стоит лазить без команды. Если менеджер проекта сможет просмотреть проектную документацию и найдет там проблемы, хотя бы на уровне не покрытого или противоречивого требования — вообще будет хорошо.
Обычно есть формулировка типа: Заказчик обязан предоставить… Если простой по вине Заказчика, то оплачивается заказчиком… Процедура приемки, согласно…
В зависимости от языка и среды исполнения вам придется или специально проектировать код для такого механизма или извратиться так, что усилия превысят разумые пределы.
У вас есть С++ — в добрый путь :)
в .Net тоже можно извратиться весьма сходно — но «цена» и сложность превысит сложность проверяемого кода.
1. А насколько независимо от остального кода? какой критерий «независимо»? Например код типа «трансформация данных» или «парсер»/сериализатор/десериализатор к какому будет относится типу?
2. К какому типа будет относится проверка «workflow» если вопрос стоит «корректный да-нет»?
Unit -Component — Integration?
А-А-А-А-… как это развидеть ?!?!
На мой взгляд все просто — у себя дома, делай что угодно. Но при выходе в Большой Мир, следуй его правилам. Хочешь дома варить самогон? да хоть бассейн и плавай в нем:) Но если на продажу — будь добр пройти санитарный контроль, лицензию на торговлю и т.д.
Так же и с крипто — майни себе сколько влезет. Только оплати электричество. Хотешь купить дом за критпо? Объясни доход в размере рыночной цены дома, оплати налоги и т.д.
Взял на себя обязательства? Исполняй их — пофиг в чем. крипто? доллары? акции и т.д.
Не верно. это ДВЕ разные сделки. Сделка доставки денег «Тому Парню» — это банк. Это одна из тех сделок (операций), на которую предендуют криптовалюты :)
А тут, как Клиент, я не вижу вообще никакой разницы. Цена и скорость — эта два моих критерия :)
Вот как раз факт перевода денег вообще никого нет интересует.
Всех интересует доказательства факта отправки и факт получения денег. При этом всех интересует механизм гарантированной доставки денег, скорость и цена доставки.
Пока крипто не продемострировали ничего внятного из этого.
Обычный «мелкий» магазин с 10 кассами выдаст от 200 тразакций в час (без проблем). с учетом того что таких магазинов порядка 5 на 50 тыс населения, не считая аптек, ларьков, рынков мелких — не большой микрорайон положит платежную криптосеть за минут 10...30 на всем земном шаре :) сколько там идет транзакция в биткоине? 15 мин? :)
Удачи сходить за прохладными напитками :)))))))
Если Вас не затруднит, поясните мне, как на основе математики, «Тут Парень» должен у меня вызывать больше доверия чем Сбербанк/Raffaisen Bank & etc?