Пять наблюдений о планировании

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


    Почему нужно искать проблему в плане


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


    Остается причиной изменения фактических сроков при фиксации объема и качества — только "внутренняя кухня", что в каком порядке делается. Естественно, всё это для некоторого абстрактного программиста в рамках 40-часовой рабочей недели.
    Теперь еще дальше углубимся в конкретику.


    Какие бывают проблемы и что делать


    Кривизна анализа к сложности синтеза


    Неправильное разбиение на задачи ведёт к сложности их последующего обьединения в результат. Что значит неправильное разбиение? Это то разбиение, в котором все сделанные задачи не образуют конечный продукт, и в конце появляется задача "Интеграция". Её срок спрогнозировать невозможно, не зная промежуточных деталей. Но она есть, и её надо делать.



    Мораль — не стоит откладывать интеграционные риски на конец проектов. Если у вас есть, например, API, используйте подходящие инструменты для разработки — например mock-сервисы (заглушки, тестовые данные и тому подобное).


    Overplan => overtime


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



    Мораль — критерием достаточности детализации плана служит мера разброса его сроков. Если она ниже планки допустимого, план можно брать в работу.


    R&D в плане


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



    Мораль — всё, последствия чего нельзя оценить приемлемо точно — не должно присутствовать в плане проекта, сроки которого предмет оплаты.


    Оценка не по (трём) точкам


    Какова вероятность ошибиться в одной точке (дате) и какая в интервале (дат)? Естественно, под точкой понимают некий луч (влево), но и тогда мы имеем вероятность из разряда "встретить динозавра": либо до точки будем, либо после (вероятность 50% — это отсутствие информации в прикладном случае). Исходя из этого, интервальный срок проекта всегда точнее конкретной даты — он менее рискован. Конечно, интервал никто не пишет в договорах, там можно записать правый край для уверенности. Если бы вы оценивали всё сразу по максимуму (а не среднее по трём точкам с коэффициентами), то неизбежно столкнулись бы с неэффективностью на конкурентном рынке.



    Мораль — лучше взвесить разные оценки в одну, чем верить одной оценке (задачи).


    Белка в колесе или задачи-головы-Горыныча


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


    Все ваши недоотжались пару раз и недоподтянулись тройку раз на тренировках — это миллисекунды и секунды от первого места!

    Представьте, что каждая задача не доделана до конца: тогда чтобы доделать до конца следующую зависимую, вам нужно доделать уже две.



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


    Заключение об идеальном плане


    Суммируя все морали каждой истории, идеальный план выходит чуть ли не противоречивым:


    1. План растет органически, от малого к большому, а не от частей к целому.
    2. План должен быть проще того, что по нему реализуется (иначе план нереализуем),
    3. В плане одного проекта (речь не про серии) не должно быть роковых событий,
    4. Интервальные оценки дают большую надежность просто по своему определению,
    5. В плане не должно быть долгов, все что используется в последующем, должно быть работоспособным.

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


    Всем успешных проектов.

    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 10
    • +1
      Соглашаясь с приведенными принципами планирования, хотелось бы отменить, что они относятся к операционному (или оперативному) планированию. Не менее значимым (а может и более) является стратегическое планирование, заключающее в общем видении результата проекта. Например, делаем только движок какой-нибудь программы, а механизм интеграции в существующую информационную среду выполняем в виде API, который должны реализовывать уже пользователи движка.
      Причем стратегическое планирование является не менее итерационным, требующим получения регулярной обратной связи, что и оперативное планирование. Иначе можно сделать качественно и в строк то, что никому не будет нужно.
      • 0
        Согласен. Но об этом я когда-то писал ранее (несколькими годами раньше). В настоящее время я стал как тот самый, «о чем вижу, о том и пою» :) Потому вот так.
      • +1
        Мораль — всё, последствия чего нельзя оценить приемлемо точно — не должно присутствовать в плане проекта, сроки которого предмет оплаты.

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

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

          Так бывает, и достаточно часто. А потом, бывает, проект провален.


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

          • 0
            Согласен, тут только вопрос, что мы называем «осознанием».
            Архитектор осознает, что его оценка сроков — основывается только на некотором опыте + интуиция и следовательно может привести к значительной ошибке. Менеджер осознает, что до конца найденного им тендера осталась неделя и нужно сформировать предложение либо упустить интуитивно-выгодный контракт. Соответственно руководитель осознает, всё то, что осознают архитектор + менеджер и делает свой выбор… который называется «предпринимательский риск», а дальше… хм, хм… сценарии, планы, реализация… всё зависит на сколько развита была интуиция у всех трех этих персонажей :) Но это, конечно же, относится только к тем задачам, которые не очень похожи на ранее решаемые.

            По поводу планирования, есть очень интересный советский фильм 1974г «Премия». Очень рекомендую.
            • 0
              Я про то что я написал скажу по поводу этого пункта. Он означает то, что присутствие событий, влияющих на длительность дальнейших задач, повторюсь, проблема для плана. Если они есть — то это риск. Те, кто осознанно на себя его берет — крут и всё такое, только в тех случаях что я видел, никто его не то что в деньгах не считал, вообще не считал, скидывая все последствия по лестничке вниз. Были редкие исключения, когда я обсчитывал разные риски, но на то они и исключения.

              Фильм (про планирование) смотреть вряд ли буду. Обычно фильмы смотрю чтобы отвлечься :)
              • 0
                Собственно об этом и худ.фильм :)
                Довольно психологический и со смыслом, практически всё действие происходит в одном помещении типа «Двенадцать» или «Гараж», но смотреть конечно надо вдумчиво… как развлечение не подойдет.
        • +1

          Есть книжка Голдратта "Критическая цепь"(читал), и не помню автора "Вовремя и в рамках бюджета"(купил). Если вы читали их, то мне интересно ваше мнение о подходах, описанных в них.

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

            Про «Вовремя и в рамках бюджета» (и с надлежащим качеством;)) могу сказать только что скорее всего это про всевозможные риски (предполагаю). У меня скорее мысль в статье следующая — сроки съезжают не только из-за растяжения задач (как у студентов), но и из-за появления новых.
          • +1
            Отличное описание, все четко и ясно

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