Мне кажется, после такого вопроса от системного аналитика хотят услышать встречные, например, про объем данных, по которым нужно искать, их организацию, количество одновременных пользователей, требования по скорости ответа... Только после этого можно говорить о реализации. Причем опять-таки от аналитика ждут описание требований, а не алгоритмы работы и форматы обмена.
А если реально ждут то, о чем писали в статье, то им нужен не аналитик...
чтобы соединить скорость генерации идей и зрелость оценки рисков в одном контур
К этому еще бы умение аргументировать свое мнение и слышать мнение других - вообще идеальная система получится. Только где столько идеальных управленцев взять...
В принципе, ничего сверхнового в этой системе нет :-) "сплав молодости и опыта" давно известен и пропагандируется, и не только в управленческой деятельности. Это универсальная концепция. Но периодически вспоминать про нее полезно :-)
Равновесие ответственности – молодые лидеры могут предлагать смелые инициативы, но проверка рисков остаётся за более опытными коллегами.
По-моему, это не равновесие ответственности, а перекладывание ответственности! Если "молодые и ръяные" будут отвечать за свой "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. Пользовательская история должна быть тестируемой, т.е. из неё должны быть понятны критерии выполнения, а ограничения по времени она получает только после превращения в задачу. Более того, потенциально не все истории превратятся в задачи проекта, исходя из результатов приоритезации по перечисленным Вами методикам.
Мне кажется, после такого вопроса от системного аналитика хотят услышать встречные, например, про объем данных, по которым нужно искать, их организацию, количество одновременных пользователей, требования по скорости ответа... Только после этого можно говорить о реализации. Причем опять-таки от аналитика ждут описание требований, а не алгоритмы работы и форматы обмена.
А если реально ждут то, о чем писали в статье, то им нужен не аналитик...
Не совсем понял, что и, главное, зачем сравниваем? 140 заказчиков - это ни о чем.
Давайте посмотрим более реальный сценарий - 80 филиалов, 20000+ заказчиков, суммарно 1000000 заказов в год, история за 3-5 лет. Задачи:
1) Рассчитать доход от каждого клиента за текущий год по кварталам в разрезе филиалов и суммарно
2) Сравнить с доходами за аналогичные периоды прошлых лет
Мне кажется, это более показательная задача для сравнения. У меня нет PostgreSQL, чтобы провести такое сравнение, но было бы интересно посмотреть...
Коллеги, а вам не кажется, что если у процесса сложно определить владельца, то этот процесс должен быть декомпозирован?
К этому еще бы умение аргументировать свое мнение и слышать мнение других - вообще идеальная система получится. Только где столько идеальных управленцев взять...
В принципе, ничего сверхнового в этой системе нет :-) "сплав молодости и опыта" давно известен и пропагандируется, и не только в управленческой деятельности. Это универсальная концепция. Но периодически вспоминать про нее полезно :-)
По-моему, это не равновесие ответственности, а перекладывание ответственности! Если "молодые и ръяные" будут отвечать за свой "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. Пользовательская история должна быть тестируемой, т.е. из неё должны быть понятны критерии выполнения, а ограничения по времени она получает только после превращения в задачу. Более того, потенциально не все истории превратятся в задачи проекта, исходя из результатов приоритезации по перечисленным Вами методикам.