чтобы соединить скорость генерации идей и зрелость оценки рисков в одном контур
К этому еще бы умение аргументировать свое мнение и слышать мнение других - вообще идеальная система получится. Только где столько идеальных управленцев взять...
В принципе, ничего сверхнового в этой системе нет :-) "сплав молодости и опыта" давно известен и пропагандируется, и не только в управленческой деятельности. Это универсальная концепция. Но периодически вспоминать про нее полезно :-)
Равновесие ответственности – молодые лидеры могут предлагать смелые инициативы, но проверка рисков остаётся за более опытными коллегами.
По-моему, это не равновесие ответственности, а перекладывание ответственности! Если "молодые и ръяные" будут отвечать за свой "fail fast", вышедший за пределы песочницы, из своего кармана, то количество безумных идей резко сократится, я полагаю... В песочнице, где это не влияет на основной контур, можно и нужно проверять любые, пусть кажущиеся просто бредовыми, идеи, и не только от молодых...
Посмотрел... Часть вопросов - на элементарные знания SQL. А есть вопросы с просто некорректными ответами. Например, на вопрос "...можно ли уменьшить размер дискового пространства в облачном хранилище?" дается "правильный" ответ - нельзя, поскольку сложно и ненадежно... Коллеги, сложно - значит можно!
Или вопрос про основное представление реляционной БД с ответом "таблица". Таблица - это элемент БД, а не её представление! В целом реляционная БД представляется ER-диаграммой...
А уж вопрос, где надо разглядеть опечатку в названии продукта - это за гранью, как мне кажется... Но если просто повеселиться - сойдет :-)
Немного странно видеть фактическое противопоставление сетевой диаграммы и диаграммы Гантта - по сути это одно и то же, только форма подачи разная. Критический путь на Гантте строится и отображается ничуть не хуже, чем на сетевом графике. Может быть, чуть менее удобно на Гантте смотреть резервы времени для некритичных задач, но тоже можно. А вот работа с ресурсами проекта в Гантте однозначно лучше.
Вообще, использование любого инструмента требует изучения и подготовки. Без знаний и навыков построить WBS достаточно крупного проекта тоже не сразу получится. Да и роль и место инструментов разные. Например, чем предлагаете заменить спорные SWOT и матрицу заинтересованных сторон из "стабильных" практик?
Вероятность того, что будет плохо, причем всем, намного выше. Чтобы семейный подряд работал "во благо", должно сложиться очень много условий. Поэтому эмпирическое, а где-то и закрепленное, правило - родственникам в прямом подчинении не работать. В другой отдел, с другой зоной ответственности - можно, а по другому - лучше не пробовать... ИМХО
Насчет выгодности Modus BI есть нюанс... У нас он есть, On-Premise, давно не обновлялся. Попробовали запросить стоимость восстановления/расширения лицензии, получили ответ: "У нас сейчас идет процесс переоценки, как будут утверждены новые тарифы, мы вам сообщим..." В итоге прошло три месяца, у нас информации так и нет, хотя неоднократно звонили, переспрашивали. В итоге начинаем раздумывать над сменой решения...
У нас тоже было организовано хранение фотографий в похожей иерархии - год, месяц, событие/место. Сейчас постепенно переворачиваем архив - событие/место, дата. Оказалось много фотографий из одних и тех же мест, но разных годов...
Из текста не совсем понял про тестовое ТЗ - это недоделанное другим аналитиком ТЗ, которое надо допилить, попутно указав недостатки, или же имелась ввиду постановка задачи от бизнеса, которую надо довести до разработки и внедрения? Это подразумевает несколько разные навыки...
Автор уже ответил, но добавлю свои пять копеек :-) - диаграмма Гантта, в первую очередь, визуализация плана, сроков и взаимозависимостей задач для руководителей/стейкхолдеров, а им, как правило, вообще пофигу на эджайл. Им нужен срок выкатки фичи и как быстро она начнет окупаться.
Плюсом к этому идет распределение и управление ресурсами (о чем тут тоже уже писали), то самое выравнивание. Эджайл - это внутри команды, а когда на проекте задействовано несколько команд, то без согласованности ресурсов и усилий не обойтись.
Вот вроде все правильно написано, но что-то царапает...
Во-первых, ситуационный центр - это не только, и не столько, комплекс средств автоматизации, это в первую очередь коллектив экспертов в своей предметной области, которые могут оценить обстановку и дать векторы решений.
Во-вторых, СЦ не нужен, когда ситуация может быть решена "по шаблону" - для этого достаточно диспетчера с набором инструкций. СЦ нужен в случаях, когда информации слишком много, либо, наоборот, слишком мало, а время на принятие решения ограничено. Отсюда одна из основных задач - представление всей имеющейся информации ЛПР в сжатом виде, облегчающем её восприятие...
Под это подстраивается весь технический комплекс СЦ - средства мониторинга, связи и оповещения, анализа и отображения...
Вы привели скорее User Story, которая распадается на 3 (или 4 - во втором случае) требования.
Tome-bound говорит об ограничении времени действия - задача должна быть выполнена к определенному сроку. В случае требований это выглядит странно: "Требование генерации отчета о текучести кадров действует до 5 числа следующего месяца, после этого его можно не учитывать"...
В очередной раз вижу применение к требованиям аббревиатуры SMART без адаптации. Как может хорошее требование быть Time-bound?? Это характерно для задач, а не требований.
Я уже где-то в комментариях писал, что T в случае требований - это, скорее, Testable как в INVEST. Мы должны заранее думать о том, как проверять выполнение требования, отсюда растут DoD.
Извините, а каким образом системный анализ на диаграммах оказался после архитектуры и оценки?? Мне кажется, их нужно поменять местами... Роль системного аналитика в проектировании архитектуры, на мой взгляд, не раскрыта...
Они немного про разное, как я писал :-) принципиальная разница именно в T. Пользовательская история должна быть тестируемой, т.е. из неё должны быть понятны критерии выполнения, а ограничения по времени она получает только после превращения в задачу. Более того, потенциально не все истории превратятся в задачи проекта, исходя из результатов приоритезации по перечисленным Вами методикам.
На мой взгляд, SMART в этой подборке лишняя, это всё-таки методика постановки задач, с точки зрения работы с пользовательскими историями её полностью заменяет INVEST...
В первом примере ошибка, кмк: DISTINCT во внешнем запросе уберёт однофамильцев. Во внутреннем запросе уже есть DISTINCT по Client_id, для задачи этого достаточно...
К этому еще бы умение аргументировать свое мнение и слышать мнение других - вообще идеальная система получится. Только где столько идеальных управленцев взять...
В принципе, ничего сверхнового в этой системе нет :-) "сплав молодости и опыта" давно известен и пропагандируется, и не только в управленческой деятельности. Это универсальная концепция. Но периодически вспоминать про нее полезно :-)
По-моему, это не равновесие ответственности, а перекладывание ответственности! Если "молодые и ръяные" будут отвечать за свой "fail fast", вышедший за пределы песочницы, из своего кармана, то количество безумных идей резко сократится, я полагаю... В песочнице, где это не влияет на основной контур, можно и нужно проверять любые, пусть кажущиеся просто бредовыми, идеи, и не только от молодых...
Посмотрел... Часть вопросов - на элементарные знания SQL. А есть вопросы с просто некорректными ответами. Например, на вопрос "...можно ли уменьшить размер дискового пространства в облачном хранилище?" дается "правильный" ответ - нельзя, поскольку сложно и ненадежно... Коллеги, сложно - значит можно!
Или вопрос про основное представление реляционной БД с ответом "таблица". Таблица - это элемент БД, а не её представление! В целом реляционная БД представляется ER-диаграммой...
А уж вопрос, где надо разглядеть опечатку в названии продукта - это за гранью, как мне кажется... Но если просто повеселиться - сойдет :-)
Немного странно видеть фактическое противопоставление сетевой диаграммы и диаграммы Гантта - по сути это одно и то же, только форма подачи разная. Критический путь на Гантте строится и отображается ничуть не хуже, чем на сетевом графике. Может быть, чуть менее удобно на Гантте смотреть резервы времени для некритичных задач, но тоже можно. А вот работа с ресурсами проекта в Гантте однозначно лучше.
Вообще, использование любого инструмента требует изучения и подготовки. Без знаний и навыков построить WBS достаточно крупного проекта тоже не сразу получится. Да и роль и место инструментов разные. Например, чем предлагаете заменить спорные SWOT и матрицу заинтересованных сторон из "стабильных" практик?
Вероятность того, что будет плохо, причем всем, намного выше. Чтобы семейный подряд работал "во благо", должно сложиться очень много условий. Поэтому эмпирическое, а где-то и закрепленное, правило - родственникам в прямом подчинении не работать. В другой отдел, с другой зоной ответственности - можно, а по другому - лучше не пробовать... ИМХО
Насчет выгодности Modus BI есть нюанс... У нас он есть, On-Premise, давно не обновлялся. Попробовали запросить стоимость восстановления/расширения лицензии, получили ответ: "У нас сейчас идет процесс переоценки, как будут утверждены новые тарифы, мы вам сообщим..." В итоге прошло три месяца, у нас информации так и нет, хотя неоднократно звонили, переспрашивали. В итоге начинаем раздумывать над сменой решения...
У нас тоже было организовано хранение фотографий в похожей иерархии - год, месяц, событие/место. Сейчас постепенно переворачиваем архив - событие/место, дата. Оказалось много фотографий из одних и тех же мест, но разных годов...
Из текста не совсем понял про тестовое ТЗ - это недоделанное другим аналитиком ТЗ, которое надо допилить, попутно указав недостатки, или же имелась ввиду постановка задачи от бизнеса, которую надо довести до разработки и внедрения? Это подразумевает несколько разные навыки...
Автор уже ответил, но добавлю свои пять копеек :-) - диаграмма Гантта, в первую очередь, визуализация плана, сроков и взаимозависимостей задач для руководителей/стейкхолдеров, а им, как правило, вообще пофигу на эджайл. Им нужен срок выкатки фичи и как быстро она начнет окупаться.
Плюсом к этому идет распределение и управление ресурсами (о чем тут тоже уже писали), то самое выравнивание. Эджайл - это внутри команды, а когда на проекте задействовано несколько команд, то без согласованности ресурсов и усилий не обойтись.
Можно считать мой комментарий неким предисловием к Вашему циклу статей о программно-технических подсистемах СЦ :-)
Вот вроде все правильно написано, но что-то царапает...
Во-первых, ситуационный центр - это не только, и не столько, комплекс средств автоматизации, это в первую очередь коллектив экспертов в своей предметной области, которые могут оценить обстановку и дать векторы решений.
Во-вторых, СЦ не нужен, когда ситуация может быть решена "по шаблону" - для этого достаточно диспетчера с набором инструкций. СЦ нужен в случаях, когда информации слишком много, либо, наоборот, слишком мало, а время на принятие решения ограничено. Отсюда одна из основных задач - представление всей имеющейся информации ЛПР в сжатом виде, облегчающем её восприятие...
Под это подстраивается весь технический комплекс СЦ - средства мониторинга, связи и оповещения, анализа и отображения...
И снова не соглашусь :-)
Вы привели скорее User Story, которая распадается на 3 (или 4 - во втором случае) требования.
Tome-bound говорит об ограничении времени действия - задача должна быть выполнена к определенному сроку. В случае требований это выглядит странно: "Требование генерации отчета о текучести кадров действует до 5 числа следующего месяца, после этого его можно не учитывать"...
В очередной раз вижу применение к требованиям аббревиатуры SMART без адаптации. Как может хорошее требование быть Time-bound?? Это характерно для задач, а не требований.
Я уже где-то в комментариях писал, что T в случае требований - это, скорее, Testable как в INVEST. Мы должны заранее думать о том, как проверять выполнение требования, отсюда растут DoD.
Вроде в тексте упоминается про 130 000 правил... Каких - не раскрыто, да :-)
Извините, а каким образом системный анализ на диаграммах оказался после архитектуры и оценки?? Мне кажется, их нужно поменять местами...
Роль системного аналитика в проектировании архитектуры, на мой взгляд, не раскрыта...
Ощущение, что прочитал выдержку из учебника...
Они немного про разное, как я писал :-) принципиальная разница именно в T. Пользовательская история должна быть тестируемой, т.е. из неё должны быть понятны критерии выполнения, а ограничения по времени она получает только после превращения в задачу. Более того, потенциально не все истории превратятся в задачи проекта, исходя из результатов приоритезации по перечисленным Вами методикам.
На мой взгляд, SMART в этой подборке лишняя, это всё-таки методика постановки задач, с точки зрения работы с пользовательскими историями её полностью заменяет INVEST...
В первом примере ошибка, кмк: DISTINCT во внешнем запросе уберёт однофамильцев. Во внутреннем запросе уже есть DISTINCT по Client_id, для задачи этого достаточно...
Надеюсь, это сарказм... :-)