Пользователь
0,0
рейтинг
8 марта 2010 в 23:13

Управление → Два протокола управления проектами

Доброго времени суток.

Я пришел в управление проектами из программирования. То есть, нет так давно, я еще писал код и мне это очень нравилось. Меня мало беспокоили волнения, происходящие где-то на верху — «у менеджеров». Все поменялось в 2004, когда меня назначили тим лидом.

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

Тогда я начал задумываться о причинах такой ситуации, начал читать посты и книги по менеджменту. Как программист, находящийся под впечатлением революционных архитектурных решений — таких, как MVC и паттерны Фоулера, я полагал, что есть *техническое* решение наших проблем с менеджментом — нужно его только отыскать и применить.

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

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


Люди vs Винтики

В наши дни в ИТ проектах идет война между двумя идеологиями управления проектами — детерминантной и эмпирической. Детерминантные процессы подходят для хорошо прогнозируемых областей — таких, как строительство, железная дорога, заводской конвейер… Детерминантные процессы можно и необходимо планировать. Методики и инструменты для таких процессов развивались вместе с индустриальным капитализмом и принесли миру Гантт, PERT, Критический путь, WaterFall, CMMI аттестацию, несколько десятков видов прикладного менеджмента.

Но есть и другой класс процессов. Это процессы, которые очень тяжело поддаются прогнозу и планированию — научные исследования, космические программы и, наконец, движение автомобиля такси. Процесс, который описывает такие области, можно назвать эмпирическим. К эмпирическим процессам, безусловно, относится и разработка ПО.

Чем отличаются эти две идеологии? Детерминантный процесс строится на полном понимании глубинных процессов и на возможности их просчитать и спланировать. Люди — участники процесса — рассматриваются как винтики, работающие по определенной программе и правилам. В эмпирическом процессе мы осваиваем проблему вслепую — мы сегодня получаем фидбек от системы, которую строим, и используем эти данные для того, чтобы спланировать наш завтрашний шаг. Нету общего плана. Мы идем так быстро, как получается и не знаем, где мы будем в дальней перспективе. Люди в эмпирическом процессе являются главной движущей силой и инструментарий такого процесса призван оптимизировать индивидуальную и командную производительность участников.

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

Какой подход лучше?

На этом этапе давайте сделаем привязку к конкретике управления проектами. В качестве примера детерминантного процесса будем рассматривать чистый WaterFall (Водопад), а в качестве примера эмпирического — Scrum (Скрам).

На самом деле, ответ на поставленный вопрос — «какой подход лучше?» — прозвучит несколько неожиданно. Эти подходы нельзя сравнивать, поскольку они отвечают за различные контексты процесса разработки. Нет смысла выяснять что лучше — отвертка или молоток, нога или рука — это инструменты, созданные для определенной работы. Если представить детерминантный и эмпирический подходы в виде языка или протокола общения, то мы увидим, что оба языка необходимы для успешного ИТ проекта. Нам просто нужно научится эти протоколы между собой не смешивать и использовать в правильном контексте.

На языке Водопада идет начальное обсуждение проекта на уровне заказчика, аналитика, CEO, финансового менеджера. Они должны понять сколько денег и времени нужно потратить на проект. Очень редко встречаются проекты с «резиновым» бюджетом. В моей практике, например, первые движения в проекте происходят по традиционному детерминантному сценарию. Идет быстрый, предварительный сбор требований, добавляются риск-факторы и мы выходим на некий виртуально-глобальный план выполнения проекта, выходим на волшебные цифры X денег и Y дней. Таким образом, мы проходим 2 фазы Водопада — сбор требований и анализ, архитектурный дизайн и планирование.

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

Скрам беспокоится о том, как наиболее эффективно решать сложные задачи с большим вкладом человеческого фактора и ему нет дела до Большого Плана. Интересно, что заказчику тоже более выгоден Скрам с его динамическим бэклогом (динамическим списком кусков функционала) и правилом 20/80. Получить функционал, тщательно подогнанный под бизнес и способный сразу приносить деньги — намного важнее формального чек-листа для прошлогоднего Большого Плана.

Интегрируем Водопад и Скрам.

В начале статьи я обещал рецепт совместного использования этих двух протоколов. Давайте попробуем все сказанное упорядочить…

Итак, проект разбиваем на 3 этапа:
— Мини-Водопад для оценки финансового лимита.
— Скрам для разработки
— Согласовывающая последняя итерация.

На первом этапе мы создаем табличку со списком историй пользователя и оцениваем ее в контексте архитектуры, в которой будем реализовывать Систему. Далее, мы рисуем Гантт и моделируем выполнение проекта во времени при определенной конфигурации команды. Так мы выходим на финансовый лимит.

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

Третий этап — это, по сути, особая итерация, где мы согласовываем набор кусков функционала одновременно и с заказчиком, и с Большим Планом. Здесь мы опять переключаемся на язык Водопада для того, чтобы сдать проект в формальных рамках самой первой оценки — то есть, на уровне топ менеджмента и финансов. Приведу пример… Пусть в Большом Плане мы брали обязательства реализовать фичи A, B и C. В ходе разработки клиент выкинул фичу С и ввел новые фичи — D и E. Дальше, пусть фичу А мы сдали на предыдущих итерациях, а фичу B мы не успели закончить (она имела низкий приоритет). Тогда, во время согласовывающей итерации, мы должны закончить В, а также, если оценка С меньше суммы оценок D и E, то заказчик должен доплатить разницу нашей фирме.

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

Этот подход я взял на вооружение совсем недавно. На данный момент его мне удалось проверить только на одном проекте. Результат оказался положительным. Мне очень интересно услышать Ваше мнение, мысли и идеи по теме поста.

Спасибо за внимание и удачи!
Алексей Дробнич @adrobnych
карма
64,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Управление

Комментарии (39)

  • +1
    Как бы тимлида вышеописанное не очень касается. Или вы были и тимлидом и PO в одном лице?
    Хотя, возможно, у нас различное понимание термина team leader.
    • +5
      Когда я был тим лидом, меня очень напрягали оценки задач, которые приходили сверху. Сейчас я менеджер проектов, и в мои обязанности входит построение и поддержка правильного Процесса Разработки.

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

      Кроме того, каждый тим лид со временем становится менеджером проектов как правило. :)
      • +3
        P.S. Термин тим лид я использовал для обозначения члена команды, который выполняет задачи «локального» менеджера (для 2-5 разрботчиков) и одновременно выполняет задачи по кодингу.
      • 0
        Предложение «Все поменялось в 2004, когда меня назначили тим лидом.» способствует восприятию изложенного от лица тимлида, а не PM :) Спасибо за разъяснение.
  • +4
    супер!!!

    интересны ваши результаты в следующих проектах
  • +4
    Ну вот CMMI аттестации не по заслугам досталось. На самом деле CMMI никому не мешает использовать тот же Scrum. CMMI не определяет конкретной методологии разработки. Я сам работал фирме, аттестованной по 3-ему уровню CMMI, и при этом все использовали Scrum и XP.
    • +2
      Спасибо за вопрос.

      Действительно, Скрам процесс может получить CMMI 3. Но это потолок. Уровни 4 и 5 получить нельзя, поскольку полный набор требований CMMI разработан из предположения детерминантного процесса.

      Кстати, вот в этой книге (по секрету — я нашел ее CHM в сети) — Agile Project Management with Scrum by Ken Schwaber  ISBN:073561993x Microsoft Press © 2004. — применению Скрам для CMMI посвящен небольшой раздел.
  • –1
    ценно, но всеравно как вы вкладываетесь в общий бюджет, если допустим заказчик _сильно_ хочет эту перделку и она сильно задежит всю команду, мне непонятно %)
    • +2
      Я не вижу тут противоречия на самом деле. Заказчик решил вкинуть мегафичу? На здоровье! Но при этом он, конечно, должен знать правила игры. Эта мегафича подвинет другие — с меньшим приоритетом. Заказчик может выбрать один из вариантов — либо бюджет увеличивается на вес оценки этой фичи — либо другим фичам не повезло в этот раз — они выходят за скоуп.
  • –8
    > Тогда я начал задумываться о причинах такой ситуации, начал читать посты и книги по менеджменту. Как программист, находящийся под впечатлением революционных архитектурных решений — таких, как MVC и паттерны Фоулера, я полагал, что есть *техническое* решение наших проблем с менеджментом — нужно его только отыскать и применить.

    > The original publication date of the book was October 21, 1994 with a 1995 copyright, and as of April 2007, the book was in its 36th printing. The book was first made available to the public at OOPSLA meeting held in Portland, Oregon in October 1994. It has been highly influential to the field of software engineering and is reg

    Вашей «революции в архитектуре» уже 15 лет.
    • +4
      Я так понимаю, что у вас претензии к фразе: «революционных архитектурных решений — таких, как MVC и паттерны Фоулера».

      Я не собираюсь спорить на тему «cтарые или новые» MVC и слоистый паттерн. Статья в общем, о другом. Вы можете в этом месте вставить любую *новую архитектурную революцию* на ваш вкус и читать статью дальше.

  • +3
    В описанной ситуации с изменениями фич нет ничего с чем не справился CMM. Просто нужно соответствующее управление изменениями в скопе проекта. При этом правда нужно ПМ-у активно поработать.

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

    В целом имхо это просто разделение уровней — есть управленческий, где ПМ и его руководство с заказчиком, и выполняющий, где ПМ же, исполнители и представитель заказчика же. Они вполне могут иметь разные процессы, наиболее удобные участникам. Главное что бы работало.
    • +1
      >>В описанной ситуации с изменениями фич нет ничего с чем не справился CMM. Просто нужно соответствующее управление изменениями в скопе проекта. При этом правда нужно ПМ-у активно поработать.

      На мой взгляд, попытки объединить оба протокола под одной крышей уже велись, да и будут продолжаться. Возьмем хоть RUP. Тяжелый итерационный процесс, который позволяет жанглировать фичами. Он идеален для CMMI. Но вот не прижился…

      Может это прозвучит слишком пафосно, но я хотел сказать, что смешивать эти протоколы Не Надо. Как с вечным двигателем… Люди тратили свои жизни на постройку тысяч механизмов, которые должны были бы работать вечно. Но в физике есть жестокий закон сохранения энергии. Имеет смысл направить усилия в другом направлении…

      >>Отодвигать решение проблемы с классической тройкой время-деньги-обьем на этап завершения нехорошо

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

      >> заказчик может думать что начальные деньги и сроки классный ПМ сопряг с новыми фичами, а контора верить в то что дополнительный обьем и увеличенные сроки будут финансово поддержаны спонсором проекта

      А вот это действительно самый опасный момент. Безусловно, все, и особенно клиент должны понимать условия игры. Мы клиенту предоставляем супер-сервис, но он морально и технически должен быть готов к нему. Если клиент делегирует все принятие решений на вас, не проявляет интерес к ранним версиям системы, то здесь лучше сразу идти по Водопаду.

      >>В целом имхо это просто разделение уровней — есть управленческий, где ПМ и его руководство с заказчиком, и выполняющий, где ПМ же, исполнители и представитель заказчика же. Они вполне могут иметь разные процессы, наиболее удобные участникам. Главное что бы работало.

      Я почти с вами согласен :)
      Я бы только слово «могут» заменил на «должны». Это и есть главный *месседж*, который я хотел отправить.

      Спасибо за ваш комментарий.

      • +1
        Если проводить аналогию с языками, RUP — это паскаль. Там есть еще много вариантов попроще. Согласен, что с точки зрения энергии лучше пользовать то что удобнее, чем «идеологически верно», но некоторые вещи для общего понимания сферы деятельности ПМу знать нужно — принципы в любом протоколе одинаковые, просто реализуются через разные места. Собственно не так важно как организован процесс, если он устраивает всех. И может быть даже искусство управления и состоит в том что бы придерживаясь общих правил, важных для команды, находить нужные способы решать проблемы.

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

        Спускаясь с теоретизирования, люди — разные. Одному может быть до фени те пять копеек что будут доплачены за доп.фичу по сравнению с ее выгодой, а другому для этого нужно согласовать изменение бюджета по 20-ти инстанциям и пофиг что от нее будет лучше и денег больше. Это нельзя не учитывать.
        • +1
          >>… может иногда казаться что некоторые вещи делаются для галочки — для бухгалтерии, для бумажки и так далее. Но эти вещи важны и не понимание причин их побуждающих может привести к срыву проекта, финансовым потерям и так далее. На самом деле в них своя достаточно жесткая логика — минимизация рисков, поддержка коммуникаций и в целом достижение целей проекта, которые состоят не только в продукте, а в основном в удовлетворении нужд заказчика, частью которого есть продукт.

          Именно, я набил эту шишку, когда увлекся Скрам и убедил своего топ менеджера, что мы обойдемся вообще без артефактов детерминантного процесса и все проведем по модели *постоянное общение + частые оценки + 2-недельные итерации с презентациями*. Тот проект мы завалили…

          Нельзя игнорировать *легаси* или исторически сложившийся массив связей между людьми, возглавляющими фирму и их клиентурой.

          Поэтому я предлагаю «панцирь» процесса строить и поддерживать в детерминантном подходе, а внутренности — в эмпирическом.

          >>Спускаясь с теоретизирования, люди — разные. Одному может быть до фени те пять копеек что будут доплачены за доп.фичу по сравнению с ее выгодой, а другому для этого нужно согласовать изменение бюджета по 20-ти инстанциям и пофиг что от нее будет лучше и денег больше. Это нельзя не учитывать.

          Я не претендую на универсальное решение проблемы. У нас — а это небольшая команда из 35 разработчиков — стратегия сработала (по крайней мере один раз). Но вполне возможно, что она не годится для компаний-флагманов рынка с командами в 200 или 400 человек.
  • 0
    «процессы, которые очень тяжело поддаются прогнозу и планированию — научные исследования, космические программы и, наконец, движение автомобиля такси»
    А что не так с этими процессами (особенно первые два), они может даже более строго детерминированы, чем Вы можете себе представить, просто вы не знаете, как это работает. С такси особая проблема — и тоже вполне предсказуема в современном мире.
    • +2
      Сложно предсказать когда и главное чем закончатся научные исследования. Можно дать лишь примерную оценку ожидаемому результату и ожидаемым временным затратам.
      • +1
        Нет. Научные исследования это строго детерминированный процесс. Сужу по своему 3х летнему опыту и опыту друзей, которые работают в больших лабораториях (Ферми Лаб, Церн). План научного исследования это строго определенная и ограниченная по времени задача.
        Прикладной пример — задача разработать методику распознавания испорченных продуктов в холодильнике. Составляется довольно детальный план измерений, исследований, испытаний, и приступают к делу — это в инженерной культуре. Никто не сидит и не ждет, пока к нему в голову придет гениальная мысль. Ученые так не работают.
        • +1
          Т.е. они приводят к гарантированному (с какой вероятностью?) результату?

          Я может не пойму, расскажите как не специалисту, что в данном случае является проектом? Я почему то представлял научные исследования как «найти лекарство от рака», и подозреваю что это слабо предсказуемо, я разве ошибаюсь?
          • 0
            Подобные проекты, как найти лекарство от рака, это очень небольшая часть исследований. Тем более, ни у кого нет конкретного проекта, «вылечить рак». К сожалению, это не представляется возможным. Потому выделяют деньги только на разработку перспективных конкретных направлений, у которых есть конкретные результаты и вполне определенные сроки. Очень часто эти результаты становятся основой для последующих исследований. Хотя, вообще-то часто подобные проекты это просто распил денег в мировых масштабах, где никому не выгодно найти решение, потому производят мистификацию своей работы.
            • 0
              подождите, а какие тогда результаты? это конечный продукт, который можно выводить на рынок? или это итерация, как шаг к получению продукта?
              • 0
                Продукт исследования?
                Исследования это часть продукта. Пример результата исследования — отчет на данных опроса людей, или 28нм технология, или просто ответ, реально ли делать схемы на 28нм технологии. И это очень даже ограниченные по времени и понятные по структуре процессы (для специалистов).

                З.Ы. Если вы о результате поисков лекарства от рака, то такое впечатление, что там никто и не озабочен чтобы продукт получился. Самим исследователям это не нужно — все верят, что это сверхсложная и важная проблема, поэтому туда текут громадные деньги. Как в анекдоте:
                Старый профессор на смертном одре, его сын, уже тоже профессор подходит к нему, и говорит умирающему: «отец, я вчера решил проблему, над которой ты всю жизнь работал»
                Отец отвечает: «дурак ты, дурак. Эта проблема меня всю жизнь кормила, могла б и тебя всю жизнь прокормить»
                • +1
                  Ну если это лишь итерация, то все получается тоже самое что и итерация в разработке ПО.
                  Продукт это то что что появится у конечного пользователя, и процесс от планирования «что же сделать» до «продажи конечно продукта» там слабо предсказуем. А вот каждая итерация, очень предсказуема, даже с высокой точностью. На выходе дает или отдельную функцию продукта, или ответ на вопрос «эта технология не подходит», или еще что то. Но ведь это никак не влияет на предсказуемость процесса получения продукта, разве нет?

                  Ведь например от результатов вашего «опроса людей» могут быть приняты разные решения, и их можно лишь предусмотреть, но никак не утвердить заранее, до опроса. Ведь так?
                  • 0
                    Да, конечно, на данных опроса могут приниматься решения, но это уже не часть исследования. Продуктом исследования в целом был отчет, составленный по исследованию.
                    По моему, проблема разработки ПО — это сильная незрелость области в плане менеджмента, что слабо позволяет точно детерминировать большие проекты, разбивать их на итерации. Это пройдет, как уже прошло в науке: большое исследование, это цепочка меньших исследований, который приносят ожидаемый результат. Если результат неожиданный — то значит были проблемы в планировании или заделали великое открытие. Последнее бывает крайне редко.
                    Проводя аналогию, в программировании «открытие» это как-то странно звучит, так что остаются только проблемы планирования.

                    Насколько мне известно, то современные методы разработки (всякие модный слова типа агилы, солид, скрам) это прежде всего борьба с меняющимися требованиями. Предсказуемость тут не причем. Даже больше, все эти методики предполагают точный расчет своих сил, как на мелких, так и на крупных дистанциях. Мой вывод — не нужно путать зеленое и теплое. Детерминизм в планировании не имеет отношения к скраму, все это о изменениях в требованиях по ходу работы… В исследованиях никто не станет просить «добавьте еще эту фичу»
    • 0
      Не могу с вами согласиться. Как может быть детерминированным процесс, построенный на серии черных ящиков?

      Возможно, вы имели ввиду микро-планы — такие как план расчетов методом Монте-Карло какой-нибудь мат. модели. Я имел ввиду макро-план — синтезировать новую керамику, устойчивую к перепадам температур и т.д. То есть планы, которые включают длительные промежутки времени и предполагают открытия новых эффектов.
      • 0
        Обычно ученым/инженерам, на подобную задачу дают сильно ограниченное время. И составляется детальный план исследований, с датами и т.п.
        Исследование — это скорее конвейер чем тыканье пальцем в небо, пытаясь попасть на нужный состав. Я выше чуть выше отписался.

        Как по мне, не детерминированность в разработке ПО связана с незрелостью области. Это пройдет.
        • 0
          Ну вот, например, составили вы чудный план исследований, взяв за основу некоторую модель явления.

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

          Так где тут детерминантность?
          • –1
            если у вас такое случается, то это, наверное, будет последнее исследование которым вы руководите.
            • 0
              Но оно будет у всех ученых, за исключением того одного который опроверг правильность текущего подхода. Если так, то еще тысячи лет назад все ученые провели бы по своему последнему исследованию и мы сейчас даже слова такого не знали.
              • 0
                в 99.9% случаев такого не бывает. Давайте ещё учитывать срыв планов, потому что лабораторию разломало землетрясением.
  • 0
    теперь надо сделать программный менеджер управляющий данным подходом
  • 0
    Схема интересная, но на мой взгляд имеет недостатки с точки зрения клиента:

    1. В начале проекта заказчику будет сложно объяснить схему. Многие клиенты не хотят даже вникать почему у подрядчика А будет качественнее подрядчика Б, не говоря уже о процессе, в котором нужно делать много телодвижений.
    2. У больших компаний всегда есть потребность, под которую выделяется бюджет и каждый новый проект проходит согласования на разных уровнях, поэтому поменять что-то в процессе будет очень сложно. Кроме того, ответственный менеджер не станет рисковать самостоятельно менять функционал.
    • 0
      Согласен, эти проблемы существуют и, наверное, являются общими для всех компаний, которые вводят Agile процессы в легаси структуру. Тут вопрос в выходе на новые горизонты рынка — нужно сохранить клиентов, которые привыкли к детерминантному процессу, и привлечь новых, кто ищет интерактив и готов идти по эмпирическому процессу.

  • +1
    Мне кажется, основа проекта должна быть детерминантной на всех этапах, т.е. в целом проект должен быть прогнозируемый и управляемый, а отдельные процессе будут эмпирическими, но в рамках отдельного этапа проекта, на который уже есть бюджет и сроки + запас бюджета и сроков на случайные риски, которые могут с высокой долей вероятности возникнуть. Ко всей схеме нужно прорабатывать процедуры, которые регулируют процесс и помогают эффективному достижению цели на всех этапах.

    Таким образом, мы получим проработанную и хорошо управляемую систему.
    • +2
      Я пытался построить простую работающую модель. На самом деле, для некоторых проектов, наверное, придется схему интеграции 2х протоколов усложнять. Возможно, нужно будет добавить повторяющиеся фазы типа детерминант — эмпирика — детерминант, которые будут поддерживать каркас для длительных проектов.

      Это не простой вопрос… Нужно подумать…

      Спасибо за комментарий.
      • +1
        Мы сейчас тоже думаем над системой проектного менеджмента (у нас создание сайтов, подобные услуги). Вернее стараемся улучшать эту систему. Сейчас работаем над вводом разных процедур, которые будут поддерживать смешанную систему, эффект положительный.
  • –3
    Я извиняюсь, конечно, но фраза «К эмпирическим процессам, безусловно, относится и разработка ПО.» выглядит больше как оправдание.
    Разработка ПО — нормальный, предсказуемый процесс даже при при полностью неадекватном менеджменте верхнего уровня. Предсказуемость достигается с одной стороны, за счет разбиения задач на минимальные, поддающиеся оценке, составляющие, с другой стороны — за счет стройной архитектуры.
    • +3
      К сожалению не все так просто… В большинстве случаев заказчик на старте проекта имеет только набор идей того, что он хочет получить в результате проекта. Нету магической книги, из которой вы могли бы взять задачи, «разбить их, и имплементировать в стройной архитектуре». Описанная вами картина больше напоминает работу программиста над своим личным небольшим проектом.
      • –2
        Зря Вы так категорично. Описанная мною картина подошла как для разработки решений в международной компании с высоким уровнем бюрократии, так и в небольших организациях с постоянной текучкой всего чего только можно.

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