Это пошаговые контракты одного проекта (включающего несколько систем-подсистем). Вы пытаетесь разрезать систему по контрактам не на подсистемы уже, а на шаги квартальные шаги.
В свою очередь этот метод тоже неплох, но срок и бюджет проекта в целом становится по определению неисчислимым. Тут свои грабли — раздражения коллектива заказчика от стресса длительного реверс-инжиниринга, необходимости задерживаться после работы для ведения и тестирования параллельной системы. В конце концов middle management саботирует работу напрочь.
В общем, аффтар скрылся, предпочитая на вопросы не отвечать.
Дык это живая практика, чего доказывать. Можно было бы и переписку по этому поводу приподнять, где-то на тех предприятиях она могла сохраниться. Но вам придётся поверить, что она была такая, эта переписка.
Директору отчитываться акционерам, день не закрыт, финансист предварительные цифры дать не могёт, главбух ждёт когда аналитик докрутит перегруженную им базу, потому, что аналитик тоже даёт главу в отчёт директора. Кроме того главбух ждёт завершения своих транзакций — в банке сбой их системы. Результат простой: директор в ярости, вместо решения проблем исполнитель преобразовал их в другие.
А вы рисуете какого-то сфероконического заказчика, который во всех головах имеет единое мнение и гладких контрагентов.
«придётся подумать над условием выхода из цикла, и как заказчика с этим смирить…»
Во-1 это = грабли№2
Во-2 писать главу «Перспективы развития и модернизации Системы» вы уже слишком поспешили. В итеративном подходе стороны сами не знает куда повернёт проект, хотя грабли №3 и №5 вроде решаются почти мягко. С другой стороны если исполнитель не знает куда заведёт проект, он просто прекращает им управлять. То есть вряд ли уложится в сроки&бюджет&качество (тут контроллируется только качество).
так я уже и сказал: OLAP vs OLTP, и это разные системы.
Пример два: главбух говорит, что кнопка должна быть слева, а бух говорит, что справа.
Пример три: директор говорит, что надо регистрировать начало рабочего дня по активности в системе, а оператор говорит, что до включения компа он перебирает стопки договоров.
Пример четыре: начальник отдела считает, что клиента надо заводить визардом, а оператор знает, что удобнее одной длинной формой.
Пример пять: директор считает, что система должна снимать проблемы, а финансист считает, что лучше потерпеть с закрытием опердня, но иметь более верные с его точки зрения цифры.
Пример шесть: один считает, что система должна быть модулями, нанизанными на его бизнес-процесс, второй считает, что система должна быть цепочкой модулей в свою очередь его бизнес процесса.
«Преждевременный рефакторинг — основа всех зол»/перефразированный Дейкстра/
Если вы в ТЗ таки акуратно учли главу «Перспективы развития, модернизации Системы», то это автоматически означает, что ТЗ написано почти окончательно, и вы натыкаетесь на грабли №3 «заказчик не может уточнить требования, пока не увидит реализацию».
во-1 это две системы (не подсистемы одного контракта). Вы выходите за рамки обсуждения одной системы. Сам заказчик сразу два параллельных контракта делать вряд ли будет — риск учетверяется.
во-2 это опять гемор с портированием данных, регулярно еженедельным. Какие-то кубы стареют, какие-то заново проектировать. Но это я ниже описал как №2. И опять это другой контракт — на оперирование OLAP.
Да? У вас случайно нет цифр доходов Toyota от продаж и сервиса? Я слышал краем уха, что объём сервиса настолько низок, что его выгодно сворачивать — надёжность продукции достаточно высока. Но Toyota не намерена снижать качество.
Неверно. Дополнительные требования увеличивают ожидания.
Если их реализовать, то упираемся в №2
Если их не реализовать, то сразу после внедрения ожидания не оправдываются — предприятие испытывало стресс реинжинринга, платило «огромные бабки», терпело часовые интервью, шло на всякие прочие жертвы, а система не удовлетворяет. По букве контракта да (и то если ТЗ однозначное), а по духу контракта (удалить проблемы заказчика) — нет. В лучшем случае будет плохая репутация. В худшем суд.
Простой пример: OLAP vs OLTP — для OLAP операторам нужна хорошая нормализация, для OLTP аналитикам нужна хорошая денормализация.
Из OLTP быстро глубокого отчёта не построишь, с OLAP бизнес-процесс почти невозможен.
В одной базе это не уместить.
Первичное построение куба на данных OLTP долгий процесс, а кубы аналитику нужны постоянно разные.
Если не считать db/2, то остальные продукты IBM вполне культурные :-)
Что касается некачественной работы, то тут есть три ситуации:
1) если вам разработка выгоднее, то выгоднее предыдущий проект завершить как можно полнее
2) если область постоянно меняется, как бухгалтерия, то в каждый конкретный момент у вас полностью завершённый продукт, но через месяц-два добавляются новые требования.
3) если вы не намерены делать проект в один год, то он вполне разумно бьётся на несколько лет поэтапно, так что в каждом конкретном этапе продукт завершён, а на следующем этапе развивается.
Но если вы пропагандируете что-то свыше трёх названных схем, то я бы с вами не работал — не хочется сидеть на игле халтуры.
В остальном статья тему сисек управления требованиями совсем никак, ни в малейшей степени не раскрывает.
Основные грабли, из виденных мной, это:
1) прочувствовать разницу между ожиданиями и требованиями. Если требования будут исполнены, а ожидания не удовлетворены, то обязательно настанет негативный результат проекта. Какие методики на этом поприще?
2) ограничить «хотелки» заказчика рамками бюджета/проекта. А это фактически половина так называемых «управлений требованиями». Есть хинты?
3) заказчик не может уточнить требования, пока не увидит реализацию требований (в раннем согласовании) в реальном продукте. Как только видит, сразу понимает, что хотел не этого. Тема не раскрыта.
4) проекция требований. Система может быть построена почти всегда с точки зрения одного человека: либо директора, либо оператора, либо финансиста, либо аналитика, либо ещё кого-то. Одновременно всем она оптимально отвечать не сможет (чисса математически), максимум двоим-троим из десяти. Как выбрать ключевых и как заставить остальных подвинуться, не обижаясь? Иначе визы от остальных невозможно будет получить.
5) актуализация требований. Даже не считая решения №3 прототипированием надо учитывать, что согласно «требованию момента» набор изменится просто в течение проекта или сразу после него — указ новый выйдет, новый номер вестника бухгалтера подоспеет. Что делать?
По ходу у бондюэля толковая фасоль, кукуруза средняя, а горошек позорный.
Горошек лучше балтимор или ваня. Кукурузу выбирать отчаялся, но бондюэль не возьму.
В свою очередь этот метод тоже неплох, но срок и бюджет проекта в целом становится по определению неисчислимым. Тут свои грабли — раздражения коллектива заказчика от стресса длительного реверс-инжиниринга, необходимости задерживаться после работы для ведения и тестирования параллельной системы. В конце концов middle management саботирует работу напрочь.
В общем, аффтар скрылся, предпочитая на вопросы не отвечать.
Директору отчитываться акционерам, день не закрыт, финансист предварительные цифры дать не могёт, главбух ждёт когда аналитик докрутит перегруженную им базу, потому, что аналитик тоже даёт главу в отчёт директора. Кроме того главбух ждёт завершения своих транзакций — в банке сбой их системы. Результат простой: директор в ярости, вместо решения проблем исполнитель преобразовал их в другие.
А вы рисуете какого-то сфероконического заказчика, который во всех головах имеет единое мнение и гладких контрагентов.
Во-1 это = грабли№2
Во-2 писать главу «Перспективы развития и модернизации Системы» вы уже слишком поспешили. В итеративном подходе стороны сами не знает куда повернёт проект, хотя грабли №3 и №5 вроде решаются почти мягко. С другой стороны если исполнитель не знает куда заведёт проект, он просто прекращает им управлять. То есть вряд ли уложится в сроки&бюджет&качество (тут контроллируется только качество).
Пример два: главбух говорит, что кнопка должна быть слева, а бух говорит, что справа.
Пример три: директор говорит, что надо регистрировать начало рабочего дня по активности в системе, а оператор говорит, что до включения компа он перебирает стопки договоров.
Пример четыре: начальник отдела считает, что клиента надо заводить визардом, а оператор знает, что удобнее одной длинной формой.
Пример пять: директор считает, что система должна снимать проблемы, а финансист считает, что лучше потерпеть с закрытием опердня, но иметь более верные с его точки зрения цифры.
Пример шесть: один считает, что система должна быть модулями, нанизанными на его бизнес-процесс, второй считает, что система должна быть цепочкой модулей в свою очередь его бизнес процесса.
«тысячи их»
Вы реально проекты внедряли? Реверс-инжиниринг делали, требования документировали?
Если вы в ТЗ таки акуратно учли главу «Перспективы развития, модернизации Системы», то это автоматически означает, что ТЗ написано почти окончательно, и вы натыкаетесь на грабли №3 «заказчик не может уточнить требования, пока не увидит реализацию».
во-2 это опять гемор с портированием данных, регулярно еженедельным. Какие-то кубы стареют, какие-то заново проектировать. Но это я ниже описал как №2. И опять это другой контракт — на оперирование OLAP.
Если их реализовать, то упираемся в №2
Если их не реализовать, то сразу после внедрения ожидания не оправдываются — предприятие испытывало стресс реинжинринга, платило «огромные бабки», терпело часовые интервью, шло на всякие прочие жертвы, а система не удовлетворяет. По букве контракта да (и то если ТЗ однозначное), а по духу контракта (удалить проблемы заказчика) — нет. В лучшем случае будет плохая репутация. В худшем суд.
Из OLTP быстро глубокого отчёта не построишь, с OLAP бизнес-процесс почти невозможен.
В одной базе это не уместить.
Первичное построение куба на данных OLTP долгий процесс, а кубы аналитику нужны постоянно разные.
Что касается некачественной работы, то тут есть три ситуации:
1) если вам разработка выгоднее, то выгоднее предыдущий проект завершить как можно полнее
2) если область постоянно меняется, как бухгалтерия, то в каждый конкретный момент у вас полностью завершённый продукт, но через месяц-два добавляются новые требования.
3) если вы не намерены делать проект в один год, то он вполне разумно бьётся на несколько лет поэтапно, так что в каждом конкретном этапе продукт завершён, а на следующем этапе развивается.
Но если вы пропагандируете что-то свыше трёх названных схем, то я бы с вами не работал — не хочется сидеть на игле халтуры.
В остальном статья тему
сисекуправления требованиями совсем никак, ни в малейшей степени не раскрывает.Основные грабли, из виденных мной, это:
1) прочувствовать разницу между ожиданиями и требованиями. Если требования будут исполнены, а ожидания не удовлетворены, то обязательно настанет негативный результат проекта. Какие методики на этом поприще?
2) ограничить «хотелки» заказчика рамками бюджета/проекта. А это фактически половина так называемых «управлений требованиями». Есть хинты?
3) заказчик не может уточнить требования, пока не увидит реализацию требований (в раннем согласовании) в реальном продукте. Как только видит, сразу понимает, что хотел не этого. Тема не раскрыта.
4) проекция требований. Система может быть построена почти всегда с точки зрения одного человека: либо директора, либо оператора, либо финансиста, либо аналитика, либо ещё кого-то. Одновременно всем она оптимально отвечать не сможет (чисса математически), максимум двоим-троим из десяти. Как выбрать ключевых и как заставить остальных подвинуться, не обижаясь? Иначе визы от остальных невозможно будет получить.
5) актуализация требований. Даже не считая решения №3 прототипированием надо учитывать, что согласно «требованию момента» набор изменится просто в течение проекта или сразу после него — указ новый выйдет, новый номер вестника бухгалтера подоспеет. Что делать?
Повыбирай, и, скорее всего ты поймёшь, что наболее правильные пельмени не связаны с известным тебе брендом, да и упакованы так себе.
Горошек лучше балтимор или ваня. Кукурузу выбирать отчаялся, но бондюэль не возьму.
this is a serious thread
однажды полистал лог антиспама, понял, что девчонки, которые не прошли… с ними действительно лучше не общаться.