Senior Project Manager
  • Фиксированный скоуп и сроки в эпоху Agile: как действовать PM’у

    Саша, привет. Годная статья, при этом brace yourself, comments are coming =)) Бьюсь об заклад, что сейчас повалят комменты типа «это не аджайл, это ватерфол» или «это порочная практика, аджайл это когда есть гибкость» итд, итп. При этом, увы, 80% коллег не сталкивались с разработкой софта в контролируемом энвайрменте для большого энтерпрайза, когда заинтересованные стороны клиента хотят нереальное количество всего в абсолютно нереалистичные сроки, доменная область обязывает быть compliant с процессами основанными, например, на IEC 62304 а у аджайла есть только один путь — стать ОЧЕНЬ дисциплинированным =)))). Остальные же 20% уверен, статью оценят и улыбнуться про себя, вспомнив свои проекты и набитые шишки.

  • Как мы сделали программу стажировки в компании — схема и выводы после 3 наборов PM’ов

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

    Підтримали: Maksym Streltsov, Max Shnurenok
  • Best practice по планированию работ. Опыт проектного менеджера

    Я там откомментил по поводу ревью дезайна. Конструктивная критика с вашей стороны была, теперь нужно разобраться с проблемой. Может я реально что-то упускаю. Посоветуйте, как быть.

  • Best practice по планированию работ. Опыт проектного менеджера

    P.S. для самоутверждения не отвечать на каждую строчку, комментария уже лет 10 как не модно.
    Я не ориентируюсь на моду). Мода — это не мое...увы.
    А ревью дизайна относится ко всем компонентам вместе. Вот давайте рассмотрим кейс вместе. Может вы что-то дельное посоветуете. Исходные данные:
    1. Есть WBS по разработке сайтика, построенная по компонентам. Каждый компонент — это страница сайта. Всего около 10 предположим.
    2. В каждый компонент входит конкретная работа, к примеру Component name:Design, Component name:Frontend итд.
    2. Необходима задача для дизайнера на ревью верстки. Примерно 3 часа.

    Куда бы вы ее засунули?

  • Best practice по планированию работ. Опыт проектного менеджера

    С удовольствием прокомментирую))
    1.

    Как по мне так лишний шаг, обычно достаточно задать последовательность работ прямо в ganter или ms project, но если вам и команде так удобно то вопроса нет, любой работающий инструмент хорош. Лично я использовал PERT для буферизации рисков и трех точечной оценки.
    Обычно, достаточно. Но дело в том, что моя точка зрения на последовательность работ может не совпадать с реально-возможной, а также инпутами от команды. Потому мы делаем это вместе. Лично я использую PERT всегда, когда мне нужно определить даты ключевых событий. Начиная от двухстадийного проектирования завода, заканчивая сайтиком как в примере.
    2.
    Вы пишете статью, о том как производить декомпозицию работ. Это основной посыл, так гласит заголовок. И делаете явную ошибку в первом же абзаце.
    Тут не понял. Статья называется «Вest practice по ПЛАНИРОВАНИЮ РАБОТ». Составление WBS это первый основной кейс этого планирования. Никакой ошибки не вижу.
    3.
    А потом эти люди(лиды, програмисты, QA, QA лиды), приходят к ПМ-у и морочат голову не корректной WBS с извращенной точкой зрения. Единственная моя цель указать на явную ошибку.
    Никакой ошибки нет, есть только ваше мнение. Да и ситуации такой не будет, если планировать работу вместе с командой, или снабдить команду простыми методическими указаниями по декомпозиции (снабжал ребят своего многуважаемого подрядчика вот такой штукой, как пример take.ms/yUlBl , take.ms/Ll1rW
    4.
    Я понимаю, что вы выделили ключевые практические результаты(deliverablies) , на своей доске, хороший подход. Только почему они не нашли отображения в WBS и календарном плане? А книжки как раз пишут об обратном. (и не только книжки)
    В WBS они как раз нашли отражение. Еще раз повторюсь, что мне лично было удобнее делать календарный план посмотрев на WBS с другой точки зрения. Проще говоря, WBS одна и это понятно. Это набор задач которые нужно выполнить, чтобы получить промежуточные и финальные цели. Представьте себе их в виде списка с такими аттрибутами для каждой позиции, как deliverable и work type. Я могу группировать эти данные как по одному аттрибуту, так и по другому. Задачи в остаются те же, их последовательность остается та же. А как я их сгруппирую в Ганнт чарте — мое дело, исходя из ситуации и здравого смысла. В данном случае чтобы считать время по компонентам (читайте, бюджет) — все сгруппировано в Redmine по deliverables. Это для начальства. Но график является моим личным инструментом для вычисления сроков по ключевым событиям и он лучше читался с WBS группированной по видам работ / типам задач.
    5.
    График работ рекомендуется делать таким образом чтобы он повторял структуру WBS и отображал практические результаты(deliverablies) в противном случае вам нужно вести двойной учет или делать дополнительные трансформации над данными учета, и вам очень повезет, если ваши учетные системы позволяют это сделать автоматически. Ваш выбор конечно, тут не поспоришь.
    Вы правы. Рекомендуется. И так и нужно делать, в контексте, если график работ является «общественным» артефактом и/или артефактом по которому ведется учет. В данном контексте — весь учет в Redmine/Jira/Youtrack. В IT не видел еще ни одну компанию, которая бы пользовалась учетом, скажем, в MS Project (ну правда, не встречал. Дорого, неудобно). Хотя встречал систему котрую сделали в одной большой фарм-компании. Совместили MS Project Server с Jira. В этом случае вы совершенно правы, двойной учет и оргомный головняк. Но это уникальный случай.
    6.
    Ваша апелляция к внутреннему проекту и внутреннему финансированию неуместна, проект есть проект стандарт, есть стандарт. Есть здравый смысл, наработки других компаний, практический опыт.
    Я опирался на здравый смысл, т.к. читать график в котором работы сгруппированы по deliverables take.ms/lr3tB было не так удобно, как читать график сгруппированный по work types take.ms/RjtC4. Мой инструмент, мой артефакт. Мое решение.
    7.
    Единственный аргумент который работает в вашем случае, что о такой структуре вы договорились с заказчиком, не важно, внутренний или внешний, и по такой структуре вы будете отчитываться. Другие аргументы не работают.
    В противном случае вас ждет увлекательный мир математики, ручной обработки отчетов, двойного учета, с неизбежным вопросам «а почему расхождение в N часов из прошлого периода???!!!!» при составлении отчета о ходе проекта. Если вам так удобно выбор безусловно ваш! Как руководитель вы несете ответственность и за свои решения тоже.
    Совершенно согласен. Потому учет ведется через таск-трекеры, а не через Gantter for google drive. Необходимое условие для избегания головняка — чтобы WBS была актуальна. За этим, увы, приходится следить.
    8.
    Простите, но давайте людям правдивую и правильную информацию. Правильный и грамотно составленный WBS помогает. Не корректный, это боль для всей команды без исключения, боль которую вы собственноручно создаете (... мне так удобно...) .
    Согласен. Одноко моя WBS составлена корректно и внесена в таск-трекинговую систему. Каждый таск заасайнен на исполнителя, проэстимирован и трекается ежедневно с логированием spent time. В Redmine. Члены команды работали над последовательностью вместе, каждый знает какой тикет у него в работе и какой следующий. Gantter — как инструмент ОПРЕДЕЛЕНИЯ СРОКОВ под которые мы с командой подписываемся.
    9.
    Я еще раз рекомендую вам пересмотреть свой взгляд и на Service Tasks в часности. И подумать куда все эти задачи можно положить, а их можно и нужно положить в компоненты. Если бы ваши практические результаты были в плане, то такой вопрос отпадает сам собой.
    Подумаю над этим. Если это будет удобно и полезно — обязательно запихну их в компоненты)
    10.
    Моя статья рассматривала ПОДХОД к декомпозиции и планированию на основе PERT применительно к разработке софта, а не единственно-правильный способ построения WBS по web проектам
    Более бредового ничего не слышал (... подход к декомпозиции через PERT...) в Ригу через Горловку на карете впереди лошади.
    PERT --- это из управление расписанием, а WBS --- это из области управления объемом работ. Скажите, по теории и на практике, что делается сначала? Определяется объем работ или составляется расписание? Не учите людей бредовым подходам!
    Еще раз продублирую фразу, только поставлю акцент на слове «планированию»:
    Моя статья рассматривала подход к декомпозиции и ПЛАНИРОВАНИЮ на основе PERT применительно к разработке софта
    Таким образом, PERT является техникой для оценки времени выполнения проекта (его части). Т.е. речь идет про планирование. Которое, конечно же, невозможно сделать без декомпозиции обьема работ и оценки продолжительности этих работ. Статья называется «Вest practice по ПЛАНИРОВАНИЮ работ». Первым идет кейс по созданию WBS, вторым идет кейс про сетевое и календарное планирование (основа — PERT). Что тут бредового?
    11.
    Не учите людей бредовым подходам!
    — т.е. по вашему, PERT это бредовый подход? Я думаю вы не это хотели сказать, уверен. А у людей есть мозг, чтобы думать и отличать берд от полезных вещей.
    12.
    Ваш личный пиар удался, вы привлекли внимание к своей персоне, поздравляю.
    Возможно. И если это так — то и благодаря вам в том числе=)) Уверен, если бы мы встретились в жизни — наверняка бы нашли общий язык. Во всяком случае, это пока лучший срач в комментах за время жизни моей статейки. И в любом случае, не смотря на возможные различия во взглядах — всегда готов пожать вам руку, коллега.
  • Best practice по планированию работ. Опыт проектного менеджера

    Конечно. Как будет время — сразу напишу. Приятно пообщаться с профессионалом. Хоть и не принимающим во внимание контекст кейсов )

  • Best practice по планированию работ. Опыт проектного менеджера

    Здравствуйте Михаил! Спасибо за такой обширный коммент. У уж было надеялся что обсуждение оляглось, но «опять скрепит потертое седло ©»)) Читая ваш коммент, я испытал целый спектр эмоций, но в итоге пришел к выводу, что вы очень занятой человек и внимательно посмотрели только на скриншот графика работ. Однако в то же время, мы с вами находимся on the same page, т.к. написали (я в статье, а вы в комменте) по сути об одном и том же.
    Итак, давайте по-порядку:
    1. Моя статья рассматривала ПОДХОД к декомпозиции и планированию на основе PERT применительно к разработке софта, а не единственно-правильный способ построения WBS по web проектам. Это нужно четко понимать. Подход. Это ключевое.
    2.

    Своей структурой WBS вы вводите людей в глубочайшее заблуждение. Объясняю:
    Backend, FrontEnd и Content это не компоненты, а типы работ, даже скорее типы ресурсов для выполнения работ.
    Спасибо большое за обьяснение. Однако если посмотреть в статью, можно обанаружить следующиее take.ms/6Dbai. По поводу точки
    3.
    Однако, узлы иерархической структуры работ(ИСР) (WBS-components) --- не просто группировка работ по компонентам, которые составляют части целого, а еще и точки, где аккумулируется часть бюджета, учитывается время и закладываются рисковые буфера, и управленческие резервы. Компонент может иметь отдельный источник финансирования, или исполняться сторонней компанией или быть другим проектом. ну это так к слову. А теперь давайте все вмести представим выполнение компонента Backend сторонней компанией в этом проекте... О, как!... сколько зависимостей и сложностей сразу рисуется. Получается сторонняя компания должна реализовать ВСЕ функции сайта. Как-то так-то.

    В данном конкретном РЕАЛЬНОМ кейсе контекст был следующий:
    — Заказчик: внутренний проект компании
    — источник финансирования: собственные средства компании
    — ресурсы: собственные разработчики компании
    — обьем: MVP версия по согласованному минимальному набору функционала с дизайном который уже был утвержден (монолит, не подлежащий изменениям в данном КОНКРЕТНОМ контексте).
    Исходя из такого конекста, я выбрал планировать WBS по deliverables (коими являлись как раз компоненты take.ms/6Dbai, или по вашему take.ms/lTrL6, аккумулирующие все о чем вы говорили (что было отражено в Redmine, т.к. все таски были собраны в свои контейнерные milestones представляющие конкретные компоненты с кол-вом estimated time and spent time). А график работ я решил делать по видам работ, т.к. MVP в данном КОНКРЕТНОМ контексте являлся монолитным обьемом и я волен выбирать способ построения графика работ так как МНЕ удобно для КОНКРЕТНОГО случая. В возможных конекстах которые описали вы — наверняка график работы строился бы по-другому, но это тоже зависило бы от ситуации.
    3.
    Минус вашей структуры: Если заказчик отказался от какой либо страницы или раздела сайта вам нужно «выпиливать» работы из разных узлов ИСР(WBS), но это мелочь.... И пересчитать бюджет(время, затраты, пересчитать буфера) всего проекта. На плане с 50 работами ---- это ерунда 2 минуты времени, а на 500(3-4 месячный проект)? на 5000(да есть и такие планы)?
    Но главное, компонент(не работы, а компонент) проходит приемку заказчиком, то что вы будете сдавать? Ну, вы понимаете нелепость сдачи компонента Frontend или Content при такой структуре, ПМ загоняет себя в угол либо все либо ничего! Ни какой сдачи по частям.
    Как профессионал, вы в курсе на самом верху иерархии стоит конечный продукт, а дальше его части, ответьте на вопрос: «Сайт состоит из разделов и страниц или из Frontend, BackEnd, Прочих работ?»
    При хорошо продуманной WBS можно выкинуть один из компонентов сайта всеми работами, и рисковыми буферами, и финансированием и общая структура не пострадает.
    Возвращаемся к пункту 2, там все раскрыто. Мой контекст — мои решения. Но приятно поговорить с профи, который понимает что такое декомпозиция. Правда, тут таких не много.
    4.
    Landing Page, About us, Ipmressum, Header, Footer Содержат работы по Backend, Frontend, Content.
    Конечно сейчас начнут возражать, а где мол, дизайн а где багофикс, --- это отдельная тема для беседы. В общем, зависит от проекта, куда включать дизайн, либо в структуру компонентов, либо выделять отдельным компонентом на уровне с сайтом или как часть сайта. (Многогранен мир)
    Преимущество: Заказчик захотел новый раздел. Вы делаете новый компонент, и рисуете под сайтом. Заказчик, не хочет тестирования, ну деньги закончились. а сайт хочет, выпилили тестирование и дело с концом.
    В МОЕМ контексте, дизайн уже был. Багофикс тоже был, как без него. Вы сами в данном фрагменте говорите о том, что включение этих моментов в структуру зависит от проекта (т.е. от контекста) и мир реально многогранен. Вы предлагаете сделать смешанное представление WBS (и это тоже неплохой вариант, на усмотрение PM’a в зависимости от контекста), т.е. представить WBS в смешанном виде, как deliverables (копоненты) и как виды работ (например тестирование, которое не хочет заказчик и которое нужно выпилить, т.е. убрать сразу целый вид работы). И deliverables и виды работ в таком случае будут жить вместе и никто не пострадает (разве что ваша психика, когда кто-то будет комментить ваш профессиональный контекстно-зависимый подход и говорить
    Ошибок на самом деле в плане много.

    5.
    Ошибок на самом деле в плане много. Но одна, про которую молчать не могу ---- это ослепительный компонент Service Task. Я такие компоненты называю своим именем «ПОМОЙКА для списывания временнЫх затрат.» или более дипломатично «Дальше мы не придумали структуру, сюда спишем все подряд».
    Итак давайте взглянем детально Service Tasks. И как он достигнет выполнения 100% и что получит заказчик в конце?
    Еще раз. Service tasks это контейнер для вспомогательных работ, которые были ЗАПЛАНИРОВАНЫ исходя из СУЩЕСТВУЮЩЕГО контекста, но не относились непосредственно ни к одному из deliverables. Но каждая из этих работ была реально необходима, т.к. она блокировала совершенно конкретные работы, которые относились к какому-либо из deliverables непосредстенно.
    6.
    1. Setup for new developer --- а если несколько разработчиков, а почему заказчику надо это показывать, и почему он за это должен платить? т.е. Палюбому надо засетапить девелопера чтобы сделать компонент. Окай.
    Конечно зависит от проекта, но можно было выделить компонент «Training» например.
    Да, надо было засетапить. Реально. Исходя из контекста — надо было показывать и за это нужно было платить. Нужно было показать, что исходя из ресурсной ситуации у нас есть конкретный кейс с сетапом нового вертальщика и это требует календарного времени и соответственно это вплияет.
    7.
    2. Маrkup review:Design --- что-то мне подсказывает что попытка нарисовать компонент дизайн была.. но мнение демократии «здравого смысла» команды программистов взяло вверх над волей ПМ-а. Бывает. Что делать с дизайном см. выше.
    Возвращаемся к контексту. Дизайн был. Маrkup review:Design — обязательная задача по ревью верстки дизайнером и выдача замечаний для правки. Хорошая практика, кстати.
    8.
    3. Test server setting — а почему здесь а не в Quality Assurance??????
    Потому что эта работа делалась не тестировщиком, а devops’ом и это инфраструктурная задача. В данном конкретном контексте. Что вы делаете и куда суете такие таски — сугубо ваше дело. Или нет?)
    9.
    4. Release #1 --- хм.... существительное... или глагол. Все таки глагол? потому что есть время на эти «Роды» 1.67h. Существительное было бы вехой(milestone). Понятно что при такой WBS положить эту задачу кроме как в «помойку» не куда. Не пилить же компонент «Administror lazy bastrad work» :)
    Возвращаемся к пункту 5.
    10.
    5. Teamplates refactoring ---- шаблоны, т.е много.наверняка к чему-то относились? К сайту, к контент странице, к landing page, к закоголовку, к хвосту(footer). Все в одну помойку, а куда же еще?! Это работа фронтенда, если я правильно помню, а может совместная с беэкндом. Пойди тут разбери теперь.
    Это относилось ко всему сайту. Работа для backend разработчика, в данном случае. Работа пошла в контейнер для работ, которые относятся к сайту в общем и/или не относятся напрямую к конкретному deliverables.
    11.
    Что будем сдавать заказчику по итогу:
    Засетапленого девелупера одна штука, Пересмотренный макет, 1.67 часов процесса родов, процесс установки тестового сервера при этом сам сервер не даем, процесс переделки шаблонов.
    Резонный вопрос, а заказчику все это надо?
    Сдаем заказчику согласованный обьем (возврат к пункту 3). Не больше, ни меньше. Монолитный согласованный обьем МVP версии.
    12.
    Анализируйте, думайте, пробуйте. и все у вас получиться, не со второго так с третьего раза.
    Спасибо. Постараюсь. В свою очередь посоветую вам читать материалы внимательно, выделать что именно является целевой информацией в материале (т.е. выделять главное, красную линию. в данном случае это пункт 1 моего коммента), не писать разгромных комментов для ситуаций, контекст которых вам до конца не ясен и самое главное — не думать, что вы умнее всех.
    Немного о себе, я любитель разработки софта и любитель проектного управления 7 лет работы в роли руководителя проектов в области разработки софта(от микроконтроллеров до e-Commerce сайтов).17 лет в индустрии, насмотрелся всякого.
    безусловно, заслуживает уважения. Но все же лучше разобраться в контексте, а затем излагать истины, с которыми я, кстати говоря, полностью согласен, т.к. смотрю на вещи в том же ключе.
  • 13 вредных советов для проектного менеджера

    То есть, подойдет для тех РМ-ов, которые пришли в профессию не из IT и работают в «шарашкиных конторах» (то есть для "РМ"-ов — в кавычках).
    А вот тут обидно было =D
  • Best practice по планированию работ. Опыт проектного менеджера

    Есть пример проекта по разработке мобильного приложения под Android и IOS в сумме чуть меньше 3000 часов по fixed price контракту (можем обсудить отдельно, если желаете).
    Также добавлю, что проект в 4000 часов с дедлайном в 4 месяца планируется немного по-другому, но на таком проекте составить еще более необходимо, чем на любом другом (есть фикс дедлайн, не дай Бог фиксированный бюджет и оооочень много рисков). Но принцип тот же — декомпозиция, увязывание в PND, назначение ресурсов, оптимизация PND и переход к календарным планам (исходя из условий задачи, дедлайнов и необходимых результатов). Подход описанный в статье легко масштабируется на любой размер проекта (где-то ниже уже писал об этом), т.к. этот подход классический и основан на математике и технике PERT (кстати, впервые был применен при разработке ракетной системы Polaris и оснащения ей субмарин, т.е. уровень масштабирования подхода вы, наверное, можете себе представить). План проекта в таком случае будет значительно более высокоуровневый и меня уже не слишком будут интересовать микроработы на уровне отдельной команды (для этого есть PM более низкой иерархии или тимлиды, пларирующие более низкий уровень работ в масштабах вверенных им юнитов/команд, и идующие потом по burndown chart’aм или как им там будет удобно, т.к. общая картина им не обязательна и часто не интересна). Меня будут интересовать отдельные дедлайны по отдельным высокоуровневым пакетам работ (в вашем случае это могут быть как компоненты мобильного приложения по отдельности, так и пакеты в которые входит несколько компонентов, или как вы решите исхдя из требований к финальным результатам и их кондиции). Т.е. весь вопрос в масштабировании подхода.

    И еще хотел уточнить по поводу

    P.S. Такие микропланы как у автора не панацея а самообман. Давно наблюдается уход от планов в сторону фиксированных затрат, сроков и не фиксированных фич. А дедлайны достигаются увеличением ресурсов и сверкой итеративно по burndown chart или % инкриза.
    . Я не совсем понял, что имелось в виду и как могут сосуществовать фиксированные затраты и сроки рядом с нефиксированными фичами. По поводу движения дедлайнов увеличением ресурсов — эта тема старая как мир и отлично раскрыта множеством уважаемых авторов, как современных, так и древних классиков (как Фредерик Брукс, например). Подход конечно работает, но в зависимости от задач. К примеру если копать котлован — то как правило работает. А если рожать ребенка — то девять мам всеравно не родят одного малого за 1 месяц)).
  • Best practice по планированию работ. Опыт проектного менеджера

    По оценке рисков в Agile проектах очень круто предподносит материал Сергей Поваляшко (был на его тренингах по этой теме). Очень толково и по существу. Перепечатывать его материал в своих статьях не рискну, т.к. будет плагиат и как следствие — плохая карма.

  • Best practice по планированию работ. Опыт проектного менеджера

    Да нет. Просто это тянет на отдельную статью и плюс все зависит от контекста, т.к. подходы к оценке рисков для проектов по Time and Material отличаются, скажем, от оценки рисков по Fixed Price модели. Потому, это довольно широкая тема, которая зависит от конекстов (и от этого становится еще шире))

  • Best practice по планированию работ. Опыт проектного менеджера

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

    Підтримав: anonymous
  • Best practice по планированию работ. Опыт проектного менеджера

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

  • Best practice по планированию работ. Опыт проектного менеджера

    Думаю, что заказчику нужно ОБЯЗАТЕЛЬНО попытаться продать время на ресерч и уведомить его о возможных вариантах, т.е. с ресерче и без. При этом лучше заранее подготовить ориентировочные «плюсы» и «минусы» этих подходов, желательно хотя бы ориентировочно выраженные в долларах США (или какая там актуальная валюта). Оба варианта рискоемкие, но заказчик должен быть проинформирован и он должен принять решение, а не вы за него. Я не знаю точного конекста, который вы имели в виду, но в контексте проекта по Agile методологии — я бы сделал именно так, т.к. видел другие варианты и это были фейлы.

  • Best practice по планированию работ. Опыт проектного менеджера

    Самая выжимка : take.ms/egy8g

  • Best practice по планированию работ. Опыт проектного менеджера

    Фикцию стараюсь не рисовать. Нет смысла, т.к. все равно не попаду в даты и еще и обманщиком буду. Но перед тем как озвучить дату, я планирую работу по методике описанной выше, плюс закладываю влияние рисков. И в 80% случаев попадаю в эту дату, или чуть раньше. И примерно в 20% попадаю за эту дату, но не на много и всегда имею возможность оценить насколько мы опаздываем и переиграть ситуацию. По поводу требователей — вы правы, но в моем случае их интересовали даты, т.к. требователи не редко дают обещания своим требователям и очень неловко себя чувствуют потом, когда фикция вскрывается. А уж как я бы себя чувствовал в этом случае — даже не фантазировать. Никто не любит «этих разговоров». Особенно их не люблю я))

  • Best practice по планированию работ. Опыт проектного менеджера

    Ну все же от меня требовали сроки. И к сожалению, я не знаю другого способа кроме планирования, чтобы иметь дело с этим take.ms/HTfmq когда от меня требуют сроки =)

  • Best practice по планированию работ. Опыт проектного менеджера

    Имелось в виду вот это take.ms/upYko

    Підтримав: Pavlo Yeremenko
  • Best practice по планированию работ. Опыт проектного менеджера

    Работает)) Делали проект по fixed price (была спека, API definition и все такое до начала разработки). Я заложился по срокам на возможные риски (которые также оценили). Попадали в сроки, все было нормально. Думаю, это зависит от проекта и его предметной области. Так что может быть по-разному. Но на интервале до 2х месяцев эта метода себя полностью оправдывает. Не говоря уже о проектах реального сектора экономики.

    Підтримав: Сергей Поволяшко
  • Best practice по планированию работ. Опыт проектного менеджера

    Илья, я понял Вашу точку зрения и согласен с ней. Однако вынужден заметить, что Waterfall это подход к разработке ПО где все стадии протекают последовательно (и его тоже существует несколько разновидностей). В статье же описывается методика планирования, а не методология. Т.е. это только сходство с Waterfall’ом, но это все же разные вещи.

← Сtrl 123 Ctrl →