Вероятность того, что будет плохо, причем всем, намного выше. Чтобы семейный подряд работал "во благо", должно сложиться очень много условий. Поэтому эмпирическое, а где-то и закрепленное, правило - родственникам в прямом подчинении не работать. В другой отдел, с другой зоной ответственности - можно, а по другому - лучше не пробовать... ИМХО
Насчет выгодности 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, для задачи этого достаточно...
Я бы ещё добавил, что роль "Аналитик" в команде должна быть, но совершенно не обязательно, что это будет отдельный человек :-) Вообще странно выглядит команда, где выделили скрам-мастера, но не упомянули ПМ или тимлида, которые действительно must have в команде. В небольшом проекте они же могут выполнять роль аналитика...
мне кажется, что вопросы из ТЗ (п.7) лучше оставить на собеседование, тем более часть ответов на них будет в резюме кандидата;
при подготовке тестового задания стоит учитывать, что хороший Продакт Овнер уже имеет работу, и тратить 6-8 часов (полный рабочий день!) на выполнение ТЗ он, скорее всего, не будет. 3-4 часа, ИМХО, оптимально.
По набору скиллов (это к комментарию mcast) джун, мидл и синьор мало отличаются, а вот по уровню их освоения могут и должны отличаться кардинально :-) опять-таки - ИМХО :-)
Вероятность того, что будет плохо, причем всем, намного выше. Чтобы семейный подряд работал "во благо", должно сложиться очень много условий. Поэтому эмпирическое, а где-то и закрепленное, правило - родственникам в прямом подчинении не работать. В другой отдел, с другой зоной ответственности - можно, а по другому - лучше не пробовать... ИМХО
Насчет выгодности 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, для задачи этого достаточно...
Надеюсь, это сарказм... :-)
Я бы ещё добавил, что роль "Аналитик" в команде должна быть, но совершенно не обязательно, что это будет отдельный человек :-)
Вообще странно выглядит команда, где выделили скрам-мастера, но не упомянули ПМ или тимлида, которые действительно must have в команде. В небольшом проекте они же могут выполнять роль аналитика...
Спасибо, интересная статья.
Есть пара замечаний по тестовому заданию:
мне кажется, что вопросы из ТЗ (п.7) лучше оставить на собеседование, тем более часть ответов на них будет в резюме кандидата;
при подготовке тестового задания стоит учитывать, что хороший Продакт Овнер уже имеет работу, и тратить 6-8 часов (полный рабочий день!) на выполнение ТЗ он, скорее всего, не будет. 3-4 часа, ИМХО, оптимально.
По набору скиллов (это к комментарию mcast) джун, мидл и синьор мало отличаются, а вот по уровню их освоения могут и должны отличаться кардинально :-) опять-таки - ИМХО :-)
Так медиана, а не максимум... 350-400 вполне есть вакансии...
User story mapping. Выделение набора задач на MVP, v1, v2 и т. д. Приоритизация.
Нарезка задач (эпики-стори-задачки).
Оценка — кто и как (стори пойнты, числа Фибоначчи, майки).
Вот здесь :-) Нарезание задач и их оценка - функционал тимлида. Да, аналитик может, а иногда должен, в этом участвовать, но он за это не отвечает...