Модель Кеневин (Cynefin framework) и теория запутанности.

7 февраля 2014
49

В  предыдущем обсуждении, среди регулярных вопросов на конференциях и в проектах звучит одно и тоже мнение - нам надо спланировать весь проект от начала и до конца. Чем сложнее и длительнее проект, тем план должен быть точнее и тщательнее проработан.

Пример. В одной большой промышленной организации планируется проект по переходу с одной версии ПО (система документооборота и BPM) на другую. Активных пользователей системы порядка 600. В проекте предполагается сохранение всего старого функционала и перенос архивных данных. Участники проекта: Заказчик – директор по ИТ,  вендор – поставщик ПО и генеральный подрядчик (в другом городе), Исполнитель – местный интегратор.

Что требует Заказчик:

  • Строгий подробный план до конца проекта
  • Коммуникации ограничены
  • Фиксированный бюджет
  • Фиксированный срок
  • Изменения в старой версии проводить по требованию (нет гарантии заморозки)

Что делает хороший руководитель проекта? Бегает в мыле, готовит план, нарушает план, пинает команду и проклинает тот день, когда он взялся за проект. И так каждый раз.

Можно ли жить по другому?

Прежде чем продолжить обсуждение, я хотел бы вспомнить про Теорию запутанности (complexity theory) и Cynefin framework (подробнее можно почитать здесь). Теория запутанности довольно новая отрасль науки и используется в философии, биологии, кибернетике, менеджменте. Согласно этой теории мы живем в окружении различных по типу систем (если мы говорим о системе, то мы подразумеваем некую согласованность: делаю Х, получаю результат Y):

  • Системы упорядоченные простые: Х=Y. Мы делаем X и однозначно (линейно) получаем Y. Пример: производство табуреток.
  • Системы упорядоченные сложные: Х===Y. Мы делаем X и получаем Y, но между ними есть различные стадии процесса. Пример: полет A380. При наборе высоты пилот изменяет положение руля, самолет идет на взлет, но между действием и результатом происходит цепочка событий.
  • Системы хаотичные: X ~ Y?. Связь между Х и Y очень сложно определить (если она вообще есть). Пример: "хороший" пример - пожар в здании. События и процессы меняются настолько быстро и непредсказуемо, что результат невозможно предугадать.
  • Системы запутанные: XY. X и Y связаны между собой. Если делаем X, то получаем Y, что вновь повлияет на X и т.д. Пример: представьте себе любой живой организм или организацию.

Вернемся к ИТ-проектам. ИТ-проекты отличаются друг от друга спецификой и реализуются в разных по типу системах. Поэтому и наши действия по проектам будут отличаться. В простых системах мы будем придерживаться четких инструкций (установка ОС), в упорядоченных сложных нам нужны эксперты для достижения результата. Именно в упорядоченных сложных работают практики по проектному управлению (PMI, Prince2 и им подобные). Если же у нас проект развивается в запутанных системах (разработка ПО в подавляющем количестве случаев), где много неопределенного, изменений, то нам нужны эмпирические и адаптивные практики. Именно здесь хорошо работают гибкие фреймворки, позволяющие ставить эксперименты, менять направление движения и пр. И, заметьте, при правильном выборе никакого противостояния «Классика» vs Agile нет.

Теперь давайте посмотрим на тот кейс, который был описан в начале. Возможно ли менеджеру проекта пойти по другому пути?


13380
Поделиться
Коментарии: 49

Комментировать могут только авторизованные пользователи.
Предлагаем Вам в систему или зарегистрироваться.

  • Виктор Федько
    Рейтинг: 303
    АО МПО им.И.Румянцева
    Зам. начальника управления информационных технологий
    10.02.2014 21:30

    1. Если планируется проект по переходу с одной версии ПО (система документооборота и BPM) на другую., то мы уже имеем дело с системой не хаотичной, и не с запутанной.

    2. Не худо бы ответить на вопрос о цели такого перехода - ответ подскажет цепочку возможных действий.

    3. Заказчик - директор по ИТ. Да не может быть СИО Заказчиком такого проекта. Представителем заказчика для подрядчика - да. Но никак по другому. Подобный переход диктуется требованиями бизнеса, который это обосновывает и выделяет бюджет.

    4. Требования заказчика стандартны, не удивительны и не живучи. Благими намерениями....)). Серьезный СИО, с опытом проектов, таких требований никогда не выставит. Тем более, что коммуникации ограничены. Соответственно, и бизнесу, как основному заказчику, изложить всю пагубность и несбыточность подобных требований.

    5. Еще один вопрос - мы хотим то же самое на другом ПО или мы хотим измененные бизнес-процессы положить почему-либо на другое ПО ? Это серьезно, это тоже во многом предопределяет телодвижения менеджера проекта.

    Как бы действовал я :

    1. То же самое на другом ПО (Подразумеваем, что необходимость доказана и обоснована).

    Описанные БП - есть. Строим прототип на параллельных рельсах, делаем пилот. Постоянно сравниваем вход/выход, быстродействие и иные параметры. Эксплуатируем пилот месяц-два. Затем, с учетом доработок делаем следующий модуль. В ЭДО это , конечно, проблематично, там все слишком взаимоувязано. Но это самый простой путь. Ис какого-то понедельника запускаем на новой платформе. Пусть лучше еще месяц потрясет, но все доведется до конца. Если каждую "блоху" вычесывать до миллиметра - проект точно не впишем ни в сроки, ни в бюджет.

    2. Другие БП на новом ПО ( Подразумевается то же самое).

    Построение ,описание и фиксация новых БП.
    Создание модульного прототипа, при возможности конечно. Программирование, параллельный запуск со старым. Отладка по месту. Переход к следующему, тоже, по возможности параллельно.
    Это увеличивает нагрузку на пользователей, но не на все 600 в любом случае, а только на ключевых. На создателей правил и направлений. Затем - как в первом варианте.
    Организация промышленная, и бизнес, скорее всего не безумно зависbт от ЭДО или ВРМ. Производство не остановим точно.

    Есть два НО.
    Я бы не взялся за реализацию при фиксированном сроке внедрения, если бы -

    • не я этот срок устанавливал
    • не имел бы полной свободы действий в части описания и внедрения БП, т.е. не имел бы решающего слова, либо не имел бы Главного единого Заказчика , СEO и т.п - смотрящего и разводящего.
    • не представлял бы себе степени ограниченности коммуникаций и не имел бы возможности эту степень видоизменять.

    При таких подходах, и в первом и втором случаях, при фиксированном бюджете такой проект осуществить невозможно имхо. Начиная, мы не знаем жесткой этапности и всей подоплеки.
    Бюджет должен "плавать" в рамках разумного.

    • Алексей Пикулев Виктор
      Рейтинг: 10
      Unusual Concepts
      Agile Coach
      13.02.2014 12:45

      1. Переход с одной версии на другую.
      2. Цель - завершение поддержки.
      3. Возможно, но не суть в этом кейсе.
      4. Требования меняются и будут меняться. Бизнес-процессы - должны меняться. Срок жизни в среднем 2 месяца.
      5. То же самое ПО (особенности версии и ПО - один в один не перенести)

  • Марк Шварцблат
    Рейтинг: 10
    КТ "Акведук"
    ИТ-директор
    12.02.2014 10:33

    1. Если я правильно понял, то разговор идет о новой версии той же самой системы того же самого производителя. Как минимум с миграцией существующей информации. Это типовая задача и странно было бы, если бы банда подрядчиков не умела ее решать.
    2. С ограниченными коммуникациями тоже не понял совсем. Между кем и кем? ИТд и подрядчиками? Сотрудниками и подрядчиками?
    3. ИТд может быть Заказчиком, если смена версии не обусловлена требованиями бизнеса, а обусловлена, к примеру, окончанием поддержки или соображениями устойчивости.
    4. Я не вижу никаких требований по серьезному изменению функционала, что сразу упрощает задачу на порядок.
    5. Я не понимаю, почему ИТд пытается выставить такие требования. Вроде бы все прекрасно понимают, что в реальной жизни из 3-х базовых переменных (качество, время, ресурсы) в лучшем случае выдерживаются два.
    6. Я не понимаю в чем проблема с "вендор – поставщик ПО и генеральный подрядчик (в другом городе), Исполнитель – местный интегратор". Абсолютно рядовая сейчас ситуация. Вопрос выбора средства коммуникации. Гибкого.
    7. Срок при живой системе не сильно критичен. Качество крайне критично для данной темы. Аппетиты подрядчиков всегда безмерны :), посему контрить жестко по качеству и намертво по деньгам, а этапы делать гибкими-плавающими.
    8. И все равно не понимаю, что тут такого страшного и запутанного. Были проекты и пострашнее. Перевод центрального офиса банка из первой десятки на абсолютно новый софт за неделю до Нового Года из-за нового плана счетов. Вот тут запутанность была запредельная.

    • Алексей Пикулев Марк
      Рейтинг: 10
      Unusual Concepts
      Agile Coach
      13.02.2014 12:48

      1. Задача не типовая. Миграции прямой нет
      2. Заказчик хочет коммуникации только в начале проекта и в конце.
      3. Не важно. Согласен
      4. Никто не может дать гарантии, что требования не изменяться - процессы меняются.
      5. Это правильно
      6. Это не проблема - просто еще одна грань сложности
      7. Ок
      8. Рад, что вам кажется не сложным. Вообще задача была показать простой кейс, который точно все проходили.

      • Виктор Федько Алексей
        Рейтинг: 303
        АО МПО им.И.Румянцева
        Зам. начальника управления информационных технологий
        13.02.2014 12:56

        Ну так она и показала)). но не очень простой, учитывая некие условия.
        Я , собственно и написал, как бы действовал. Хотя, в жизни, на самом деле - все гораздо проще.

  • Марк Шварцблат
    Рейтинг: 10
    КТ "Акведук"
    ИТ-директор
    13.02.2014 10:54

    Как-то не идёт у нас дискуссия. Вероятно тема, для большинства, малоинтересная.

    • Виктор Федько Марк
      Рейтинг: 303
      АО МПО им.И.Румянцева
      Зам. начальника управления информационных технологий
      13.02.2014 11:17

      Скорее всего да, уж очень странные и жесткие исходные условия. Да и что-то подобное мы тут уже обсуждали в прошлом году. причем в разных дискуссиях .
      Ну, или у всех все уже внедрено, так чего обсуждать)))

      • Марк Шварцблат Виктор
        Рейтинг: 10
        КТ "Акведук"
        ИТ-директор
        13.02.2014 11:20

        Ну смысл-то был в том, чтобы отказавшись от жёсткого шаблона решать проблемы в рамках "гибкого мировоззрения".

        • Виктор Федько Марк
          Рейтинг: 303
          АО МПО им.И.Румянцева
          Зам. начальника управления информационных технологий
          13.02.2014 11:36

          Вот тут обсуждали. к примеру. Но, да, есть еще о чем поговорить, на самом деле.

        • Алексей Пикулев Марк
          Рейтинг: 10
          Unusual Concepts
          Agile Coach
          13.02.2014 12:54

          Да, почему такой пример кейса привел - именно про такие кейсы спрашивают, когда речь идет о применении Agile. Дескать к разработке ПО - понятно, но вот инфраструктурные проекты, как быть.

          • Марк Шварцблат Алексей
            Рейтинг: 10
            КТ "Акведук"
            ИТ-директор
            13.02.2014 14:31

            Достаточно свежий инфраструктурный проект. Не сильно сложный.

            Многие руководители ИТ в более-менее крупных организациях в стадии роста сталкивались с переездом ЦОДов. Большая часть нашей системы работает без выходных и значительно более 8 часов. Предпоследний раз пошли по традиционному пути - одномоментный перевоз. С планированием всего сразу, с предварительными согласованиями, с заказом потребного количества транспорта, с ночной работой. Было сложно. Ситуация все время менялась.

            Крайний раз пошли по другому пути. Выделили максимальное количество независимых частей и решили, что в связи с невозможностью точно спрогнозировать, на какие части в момент переезда будет максимальная нагрузка (максимальная критичность для бизнеса), то передислокацию будем проводить по ситуации. Да. Срок окончания отодвинулся. Но общие потери от простоя и потери нервных клеток значительно сократились.

        • Виктор Федько Марк
          Рейтинг: 303
          АО МПО им.И.Румянцева
          Зам. начальника управления информационных технологий
          13.02.2014 14:10

          Сильно подозреваю, что в рамках "гибкого мировоззрения" решается 99 % всех проблем с внедрением. А потом пишется шаблон и рассказывается, как по нему все было замечательно.

          • Марк Шварцблат Виктор
            Рейтинг: 10
            КТ "Акведук"
            ИТ-директор
            13.02.2014 14:43

            Задним числом подводится массивная теоретическая база... :)

            • Алексей Пикулев Марк
              Рейтинг: 10
              Unusual Concepts
              Agile Coach
              13.02.2014 14:54

              Не совсем. Я же не зря написал, что никакого противостояния «Классика» vs Agile нет. Нет лучших и правильных инструментов, но есть полезные.

              • Марк Шварцблат Алексей
                Рейтинг: 10
                КТ "Акведук"
                ИТ-директор
                13.02.2014 14:59

                А не согласен. Для каждого момента времени есть лучший и правильный инструмент. И лучший и правильный инструмент всегда наиболее полезный. В самом крайнем случае, самым правильным и полезным объявляется тот, который есть в наличии. :)

            • Виктор Федько Марк
              Рейтинг: 303
              АО МПО им.И.Румянцева
              Зам. начальника управления информационных технологий
              13.02.2014 15:12

              Именно так...

  • Виктор Федько
    Рейтинг: 303
    АО МПО им.И.Румянцева
    Зам. начальника управления информационных технологий
    13.02.2014 11:20

    Кстати, ВОТ. Почти то, что упомянуто в статье. Интересно, а каковы там были условия? И как все прошло.

    • Марк Шварцблат Виктор
      Рейтинг: 10
      КТ "Акведук"
      ИТ-директор
      13.02.2014 12:14

      Не совсем то. В явном виде про BPM не написано, а это критично. Да и про полноценных документооборот тоже.

  • Алексей Пикулев
    Рейтинг: 10
    Unusual Concepts
    Agile Coach
    13.02.2014 12:52

    Коллеги, увидел только сегодня свой опубликованный пост. Поэтому подключаюсь поздно к дискуссии. Спасибо за ваши решения, основная же цель поста (и кейса) была немного другая. Мы глядим на такие проекты (дял кого то простые или сложные) как на цепочку последовательных действий: План-Миграция-Тест-Исправление-Пром Эксплуатация. А вот можно пойти по другому? Хорошая мысль с пилотом - но если сделать цепочку пилотов?

    • Виктор Федько Алексей
      Рейтинг: 303
      АО МПО им.И.Румянцева
      Зам. начальника управления информационных технологий
      13.02.2014 14:05

      Что означает цепочка пилотов? По модулям ? Но в СЭД это в принципе очень затруднительно, там все слишком взаимоувязано. Или это всего лишь пример? Что тогда имеется в виду?

  • Алексей Пикулев
    Рейтинг: 10
    Unusual Concepts
    Agile Coach
    13.02.2014 14:11

    Цепочка пилотов - значит частые релизы. В СЭД (и особенно в BPM) системах это возможно. Кто вам мешает построить итерактивный процесс. Может по модулям, а помеж по глубине реализации. Сначала карточки документов и просто хранилище, потом движение документов, потом движение по улучшенным маршрутам

    • Марк Шварцблат Алексей
      Рейтинг: 10
      КТ "Акведук"
      ИТ-директор
      13.02.2014 14:20

      Есть некое противоречие. Или мы делаем две параллельно действующие системы, обеспечивая синхронизацию данных и постепенно маленькими кусочками с тестированием переносим функционал, либо мы переводим 600 пользователей на неготовую систему и итерационно ее дотачиваем. Второй путь, с точки зрения живого бизнеса, не особо реален. Первый сложный и недешевый.

      И в любом случае есть некое обязательное ядро, которое ДОЛЖНО обеспечивать минимально допустимую функциональность. Какое оно? Работающая система. 600 пользователей. Явно не простое хранилище.

      Ограничение на коммуникации выглядит очень странным. Это не самая затратная и дорогая часть проекта.

      • Виктор Федько Марк
        Рейтинг: 303
        АО МПО им.И.Румянцева
        Зам. начальника управления информационных технологий
        13.02.2014 15:30

        Или мы делаем две параллельно действующие системы, обеспечивая синхронизацию данных и постепенно маленькими кусочками с тестированием переносим функционал,

        Именно это проходил последние 3 года.Одну старую систему в 3 новые. С интеграцией. Пользователей чуть побольше. Путь архисложный, не безумно дорогой. Но все нервы, пот и кровь того стоили. Сейчас закончили.
        Второй путь даже не обсуждался - я бы доточить ничего не успел ))).

        • Марк Шварцблат Виктор
          Рейтинг: 10
          КТ "Акведук"
          ИТ-директор
          14.02.2014 13:19

          "Мсье нетонкий извращенец..." :) Прошу прощения за мой французский... :)

          • Виктор Федько Марк
            Рейтинг: 303
            АО МПО им.И.Румянцева
            Зам. начальника управления информационных технологий
            14.02.2014 13:54

            От мсье слышу..))). (читаю).
            А что делать? Простых путей не ищем, хотя и через выхлопную трубу карбюратор тоже не перебираем.))))

    • Виктор Федько Алексей
      Рейтинг: 303
      АО МПО им.И.Румянцева
      Зам. начальника управления информационных технологий
      13.02.2014 15:14

      Частые релизы - это чтобы было себя чем занять. Это внедрение ради внедрения делать - и надолго. А новые релизы - только по мере острой необходимости, если нельзя жить без этого.

      • Алексей Пикулев Виктор
        Рейтинг: 10
        Unusual Concepts
        Agile Coach
        14.02.2014 10:15

        Частые релизы - чаще получаем обратную связь. вовлекаем заказчика, тестируем и корректируем требования. И показываем ГОТОВЫЕ результаты. Конечно, проще показывать все в конце, но кто будет переделывать?

        • Виктор Федько Алексей
          Рейтинг: 303
          АО МПО им.И.Румянцева
          Зам. начальника управления информационных технологий
          14.02.2014 10:35

          Я бы не смешивал эти две вещи.

          Частые релизы - чаще получаем обратную связь. вовлекаем заказчика, тестируем и корректируем требования.
          Здесь еще надо добавить - и , соответственно, получаем дополнительный заработок. Это ведь бизнес, ничего личного )).
          О каких релизах мы говорим ? Если о релизах во время внедрения - то да, такое вполне реально. Step by step, нормальная практика.
          А вот если система готова, внедрена и работает - то выпуск слишком частых версий, патчей, релизов - это уже, зачастую, дополнительные финансируемые бантики. Не всегда, но встречается.

          Насчет показывать в конце - полностью согласен, переделки потом обойдутся дороже. Другое дело, что в любом варианте надо иметь предварительно ТЗ. где прописано четко - а что в конце. Иначе будет плохоуправляемый, перманентный процесс - Ты - мне (доп. задание) , Я - тебе ( очередной релиз).

          • Алексей Пикулев Виктор
            Рейтинг: 10
            Unusual Concepts
            Agile Coach
            14.02.2014 10:40

            Соглашусь конечно!
            Но вот как быть с ТЗ? Если мы хотим в окончательно варианте перед началом реализации получить ТЗ - то опять получаем последовательность. Интересно, был ли случай, когда ТЗ (или требования) становились гибкими? Те мы изначательно знаем, что все поменяется, и даже приветсвуем это.

            • Виктор Федько Алексей
              Рейтинг: 303
              АО МПО им.И.Румянцева
              Зам. начальника управления информационных технологий
              14.02.2014 10:59

              Сказал бы так, что гибкое ТЗ (если так , то так, а если вот так - то вот эдак) - это не ТЗ. Это больше то, что мы называем Vision.
              Если мы знаем, что все изначально поменяется - то надо дождаться, когда поменяется, а потом делать. Такого не бывает, все-таки.
              И уж, тем более - что тут приветствовать.
              Собственно, и о таких вот ситуациях писал Юрий Зеленков. И дискуссия потом была соответствующая.

              • Алексей Пикулев Виктор
                Рейтинг: 10
                Unusual Concepts
                Agile Coach
                14.02.2014 11:08

                Ну почему же, Vision - это Vision. Требования, это требования. Если сидеть и ждать перемен, то конкуренты быстрее обгонят. А что если мы делаем инновационные продукты - мы же не можем все требования сразу предугадать + рассчитать ROI. Как рынок отреагирует? Сделаем гипотезу, проведем эксперимент, научимся, изменим требования. Да и не только с инновационными продуктами. Заказчик часто не знает сам возможности системы и не может адекватно составить требования. Зачем все прописывать и делать ТЗ, если можно реализовывать, запускать, адаптировать?

                • Виктор Федько Алексей
                  Рейтинг: 303
                  АО МПО им.И.Румянцева
                  Зам. начальника управления информационных технологий
                  14.02.2014 13:02

                  Опять же, давайте тогда разделим.
                  Инновационные продукты - да. Это нестандартная разработка, исследования, тестирование, адаптация и т.п. Какое тут ТЗ ?. Тут надо просто понимать, что хотим получить на выходе. А все остальное касается уже вопросов "как".
                  Но и в этом случае определенные ограничения тоже должны быть. Временные. Финансовые. Иначе, есть риск уйти за горизонт и забыть , с чего начинали. Да и зачем помнить, если финансирование стабильное, тепло, светло и мухи не кусают ? )))
                  А вот если мы говорим о внедрении какого-то стандартного функционала (пусть и с понятными доработками). ERP, портал, MES, СЭД, CRM и далее везде - то ТЗ имхо необходимо. Мы обязаны знать, что хотим на выходе. обязаны определить некие сроки и финансовые рамки. Да можно в них не вписаться, но идеально - 10-15-29 %%, не более, думаю.
                  А уж внутри процесса годится и методология - делай-предъявляй-тестируй-исправляй-предъявляй-делай дальше. И т.д.

                  • Алексей Пикулев Виктор
                    Рейтинг: 10
                    Unusual Concepts
                    Agile Coach
                    17.02.2014 10:40

                    При внедрение стандартного функционала такое возможно. Но! По статистике при таком подходе больше 50% функций заказчиком не используется никогда. Да, можно фиксировать ТЗ, тратить на его написание много месяцев. А потом бюджетировать любое изменение в ТЗ. Но с другой стороны, мы помним, что в проектном треугольнике нельзя фиксировать все составляющее, а таким ТЗ как раз делаем наоборот. Я же не говорю, что его не должно существовать. (а это один из мифов про Agile, то в там ТЗ нет - с требованиями там как раз умеют работать). Мы просто говорим, что требования должны и могут меняться, при фиксированном бюджете, сроке (и качестве). Я не зря привел модель Cenefin.image2.jpg Почти все проекты живут в двух квадрантах: Запутанных и Сложных упорядоченных. И мы можем выбирать пут, как проект вести в зависимости от этого.

                    • Виктор Федько Алексей
                      Рейтинг: 303
                      АО МПО им.И.Румянцева
                      Зам. начальника управления информационных технологий
                      17.02.2014 11:12

                      Картинки не видно.

                      Мы просто говорим, что требования должны и могут меняться, при фиксированном бюджете, сроке
                      1. То, что требования должны и могут меняться я еще соглашусь. Не кардинально, в пределах разумного.
                      2. А вот как Вы себе представляете это при "фиксированных бюджетах и сроках" ? С некоторой натяжкой, можно это еще принять , если проект делаем своими силами. А если подрядчик сторонний?
                      Да и своими силами при фиксированных сроках с трудом себе представляю внедрение , когда требования меняются. А слоган "разумные пределы" имеет слишком широко толкование.
                      Извините, не поверю. В своей жизни сделал намало проектов разной степени сложности, и с подрядчиком и своими силами. Никогда не фиксировал жесткого срока - это на самом деле особо и не нужно никогда (если только в случае проекта по обеспечению ИТ-инфраструктуры Сочи-2014 и т.п.) , и никогда не фиксировал бюджет. Рамки очерчивал - да. Но не более.

                      • Алексей Пикулев Виктор
                        Рейтинг: 10
                        Unusual Concepts
                        Agile Coach
                        17.02.2014 12:16

                        Как можно? Например, каждую итерацию требования уточняются, появляются новые, приоритезируются - те регулярно идет работа с требованиями. Зная, что на берегу 100% все требования не прописать, что много из-того, что хочет Заказчик (и тем более если он первый раз систему видел) будет выглядеть по другому, когда он начнет это использовать в системе, и что определенная часть функционала не понадобиться.
                        Я не говорю,что первый варивант с ТЗ плохой, но есть второй - который тоже существует и работоспособен. Если только у компании-внедренца бизнес не строится на получении Change Request-ов.

                        • Виктор Федько Алексей
                          Рейтинг: 303
                          АО МПО им.И.Румянцева
                          Зам. начальника управления информационных технологий
                          17.02.2014 13:27

                          Да это понятно,Алексей. Я тоже только за такой подход! Скажите, как это сделать при фиксированном бюджете
                          У вас есть проект. Вам дали 10 млн., пусть даже рублей ))). и дали срок - 1 год. и сказали - гуляй как хочешь в этих рамках.И как гулять вот в этой ситуации - каждую итерацию требования уточняются, появляются новые, приоритезируются - те регулярно идет работа с требованиями.
                          У Исполнителя все по часам, по рейтам. Он Вам сто итераций сделает за Ваши деньги. А требования все меняются и меняются. И это хорошо, на самом деле, мы идем методом проб и ошибок, мы делаем нужную работу.И правильно делаем.
                          Только как вписаться в срок и бюджет?

                          • Марк Шварцблат Виктор
                            Рейтинг: 10
                            КТ "Акведук"
                            ИТ-директор
                            17.02.2014 16:00

                            В срок и качество вписаться можно, а вот как объяснить финдиру, что тебе надо денег от 0 до бесконечности. :)

                • Марк Шварцблат Алексей
                  Рейтинг: 10
                  КТ "Акведук"
                  ИТ-директор
                  14.02.2014 14:05

                  Тогда нужна система управления проектом, портал с рабочими группами, т.е. НЕПРЕРЫВНОЕ коммуницирование.

            • Марк Шварцблат Алексей
              Рейтинг: 10
              КТ "Акведук"
              ИТ-директор
              14.02.2014 14:03

              С Виктором соглашусь. Это уже не ТЗ. В лучшем случае граничные макетные требования. Причем "боковые", т.к. начало и конец заданы жестко. И вопрос достаточной гибкости макета - тоже непростой.

        • Марк Шварцблат Алексей
          Рейтинг: 10
          КТ "Акведук"
          ИТ-директор
          14.02.2014 13:58

          Обратная связь - это коммуникации. По условиям задачи - они у нас ограничены.

  • Алексей Пикулев
    Рейтинг: 10
    Unusual Concepts
    Agile Coach
    13.02.2014 14:36

    Никакого противоречи нет
    1. Мы можем делать две параллельно действующие системы
    2. Можем переводить итерационно.
    3. Можно последовательно

    Вопрос выбора подхода.

    А про коммуникации - это ведь не всегда очевидно (особенно заказчику) что они должны быть частые и регулярные

    • Марк Шварцблат Алексей
      Рейтинг: 10
      КТ "Акведук"
      ИТ-директор
      13.02.2014 14:57

      Если Заказчик в данном случае ИТд не хочет коммуницировать и не понимает важности этого, то какой он тогда ИТ-руководитель? Как минимум - странный.

      • Алексей Пикулев Марк
        Рейтинг: 10
        Unusual Concepts
        Agile Coach
        13.02.2014 15:02

        Марк Рудольфович, я бы не вешал ярлыки. Дело в том, что уровень управления совершенно разный и понимания отношения клиент-заказчик тоже. Не многие готовы строить Win-Win сотрудничество, что взаимодействия в рамках проекта это залог успеха. И здесь задача менеджера проекта без навешивания ярлыков вовлечь всех в процесс коммуникаций.

        • Марк Шварцблат Алексей
          Рейтинг: 10
          КТ "Акведук"
          ИТ-директор
          13.02.2014 15:11

          Лучше на "ты".

          Это не ярлык, а недоумение. :)

          И коммуницирование - это не синоним сотрудничества, а уже, тем более, не выбор стратегии сотрудничества. Это просто обмен информацией.

          Хорошо. Я могу принять такое допущение. (вот сейчас пошли ярлыки) ИТд-Заказчик - старый нелюдимый бука-мизантроп сильно занятый по основной работе. :)

          Тогда есть проблема. Без постоянной связи с заказчиком (если со стороны заказчика никого более нет) гибкое внедрение малореально. Как менять или уточнять что-то в пути, если между утверждением нанадцатитомного ТЗ и Актом сдачи-приемки пустота? Надо подумать. ТРИЗ нам в помощь.

        • Виктор Федько Алексей
          Рейтинг: 303
          АО МПО им.И.Румянцева
          Зам. начальника управления информационных технологий
          13.02.2014 15:20

          Не многие готовы строить Win-Win

          Если не готовы, то лучше не начинать совместный проект - не будет ничего иначе.

          • Алексей Пикулев Виктор
            Рейтинг: 10
            Unusual Concepts
            Agile Coach
            14.02.2014 10:16

            А вы будете готовы отказаться от проекта если заказчик не Win-Win. И если проект коммерческий?

            • Виктор Федько Алексей
              Рейтинг: 303
              АО МПО им.И.Румянцева
              Зам. начальника управления информационных технологий
              14.02.2014 10:44

              Трудно сказать. Надо конкретно смотреть на Заказчика. Если не win-win, то будет обычная схема - заказчик хочет побольше, получше и подешевле, а я хочу поменьше, подороже и как получится. Такое часто встречается.
              Иногда есть смысл и отказаться, потому что, если проект коммерческий (а что, бывают другие? ), то надо взвешивать все и смотреть на настроение заказчика, чтоб потом всю прибыль на адвокатов не тратить.
              С некоторыми лучше потерять, чем найти.

              Один друг другому :
              Первый : Что ж у тебя такая жена страшная ?
              Второй : Зато верная, а у тебя вот красавица, но гулящая.
              Первый : Так лучше иметь 50 % при хорошем гешефте, чем 100 - при плохом.
              Старо, конечно, но верно.

  • Михаил Муравьев
    Рейтинг: 10
    ГК "Омега"
    Руководитель ДИТ
    14.02.2014 20:59

    Вот вот, а то коммерческий проект быстро станет убыточным. С такими требованиями в ожидания заказчика всеравно не попадем, если только прокачаем нервную систему.

Предметная область
Отрасль
Управление