А что если я скажу, что есть решение которое решает все сложности календарного планирования проекта и перепланирования проекта, учитывает неопределённость оценок и интегрируется с Jira/YouTrack и другими трекерами без необходимости ручного перегона задач туда-сюда?
А понял! Если мы говорим про «монтажников», у которых только мобильник. то сейчас в BIPULSE есть возможность зарезать интерфейс в профиле «исполнитель» по максимуму. Но без реального Клиента с такой областью применения приоритет реализации такой функции весьма туманен %(
Благодарю за комплимент! Над эргономикой мы работаем, но ключевое для нас: готов ли Клиент использовать BIPULSE для решения своих задач. Если использует, то на основе обратной связи мы адаптируем интерфейс. После смены frontend движка у нас появилось много возможностей по калибровке.
Из недавних примеров изменений на основе запроса: добавили опцию режима ручного планирования задач и задание режима расчета буфера чисто по CCPM и его размера вместо «адаптивного» по Pulse Management.
>> циркулярный опрос команды «сколько осталось времени до завершения твоей текущей задачи?».
1. Собираем всех на «летучку»
2. Открываем «План / Оперативный / Задачи в работе» (там все факты есть сколько потратили времени и сколько хотели)
3. Идем по каждой задаче и задаём вопросы.
Если команда работает асинхронно и проект идет по CCPM (важно), и «летучку » не провести, то:
1. У исполнителя как правило есть своя задача «в работе» и карточка на неё уже открыта
2. Он тыкает в «осталось дней» и вводит значение +таб. Всё.
3. Мы на План/Тактический видим отклонение проекта.
Но этот метод плох тем, что мы не можем ускорить исполнение «в моменте». Так как на живой вопрос, мы получаем живой ответ и можем сразу предпринять корректирующие действия. Я соглашусь что дополнительный робот-пинатель будет хорошо, но его отсутствие пока это ни разу не являлось препятствием к внедрению.
>>Люди и так сопротивляются изменению устоявшейся практики, а тут вы им вгружаете дополнительные не самые простые инструменты…
Классное замечание! Мы это в версии 7.0, которая вышла в апреле этого года, преодолели! И теперь для исполнителей есть профили «исполнитель» — для тех кто «могу копать, могу не копать» и «инженер» — доски, списки задач и целей. А все стальное только для руководителя
Кирилл, со сравнению с 2017 годом, сейчас BIPULSE — почти не имеет проблем, однако для эффективного применения требует использования Метода управления «Pulse Management» pulsemanagement.org (цикл публикаций на Хабре habr.com/ru/post/462423)
Метод учитывает особенности применения CCPM для «реальной жизни» ИТ-проектов.
Проблема внедрения CCPM не в софте, а в головах. Так как требуется перестройка способа мышления и принятия решений.
Метод базируется на ТОС, и я об этом написал в самом начале цикла публикаций habr.com/ru/post/462423, но в CCPM есть ряд ложных предпосылок для среды с высокой неопределенностью. Так же CCPM не закрывает все аспекты управления проектами.
1. ТОС — это не только про узкое место, это еще и системные инструменты анализа и решения ситуации.
2. >> Не знаю, где Вы взяли данные о том,
Статистика TOCICO, CCPM — это только один из инструментов общего процесса. В одной из компаний которую мы консультировали, сокращение одновременных исполняющихся проектов (проектов, но не контрактов) с 30 до 8 заняло полгода.
Если Ваша позиция в том чтобы отрывать головы вместо решения задачи о возвращении проекта в норму — это ваше право. Возможно у Вас неограниченные ресурсы и бюджет для таких действий, чтобы восполнить оторванную голову новой. Однако, моя практика показывает, что владелец компании меняет свои привычки для того, чтобы обеспечить выполнение всех обязательств организации вовремя и в полном объеме.
Результат применения Метода один: Выполнение Организацией всех обязательств вовремя и в полном объеме. Если вы уже применили Метод и не получили этот результат, то нужно разбираться как вам это удалось. Статистика TOCICO — 90% проектов применяющих Критическую Цепь завершаются вовремя, Метод определяет правила игры с применением инструментов ТОС, Agile и проектного управления.
Границы применения Метода и его полнота опубликована в первой статье.
о ГОСТах: ГОСТы вещь хорошая, однако:
1. Они определяют правила, но не говорят «зачем так»
2. Их мало кто читает, если это не прописано в ТЗ к контракту.
Метод Пульса (Pulse Management) решает эти два препятствия за счёт компактности практик и цельного подхода для цикла PCDA
1. Какое влияние по Вашему мнению может оказывать доминирующая вершина на остальные?
2. Определение Пульса — в следующей публикации про инструменты Метода.
3. О потоках. Хороший вопрос! Поток — не процесс, это поток мышления. Состояние в которым мы думаем. Я раскрою эту главу лучше.
4. О «Чем отличается» Можете ли привести в процентах количество инженеров-конструкторов, инженеров-проектировщиков, инженеров-программистов (от всех) которые прочитали теорию управления производственным предприятием? Можете ли при вести в процентах количество менеджеров проектов и отделов которые прочитали приложение к PMBoK про управление программами и портфелями?
5. Как взаимодействуют: описано в методичке которая лежит на pulsemanagement.org или расскажу в последующих публикациях.
Если бы время не было ограничено, можно было бы развивать все потоки и не париться.
Верно!
Но Метод базируется на том что ресурсы ограничены. (позже опубликую эти части на Хабре). Но не учитывает их в модели организации.
Ограничение всегда есть. И хорошо, чтобы оно было внутри Организации а не снаружи. Но это уже вопросы ТОС. Метод формализует только одно из применений ТОС — управление проектной организацией, управление портфелем проектов.
Модель организации — не проектный треугольник. Организация развивается в трёх направлениях.
1. Развитие Организации в направлении «Технологии» идёт когда сотрудник работает в Потоке Реализации или Управления, при этом развитие Организации в направлении Правил и процессов происходит когда сотрудник работает в Потоке Улучшений.
Все действия в Потоке Управления это принятие решений в соответствии с Правилами.
Фокус внимания в каждом потоке на разных вещах, как и инициатор изменений:
— Цели — владелец компании, продажи.
— Правила и процессы — методолог, хозяин процесса-Scrum, Владелец процесса
— Технологии и профессионализм — технолог, архитектор, руководитель отдела
2. Я не вижу такого направления развития Организации как «Ресурсы». Организация может работать вообще без ресурсов, а покупать их на стороне и при этом нормально зарабатывать деньги. Однако, обладая Технологиями мы можем создавать новые продукты или услуги. А поднимая профессионализм мы можем улучшать технологии. Но это всё не поможет, если мы не обращаем внимания на способ работы. Именно на развитие этого направления и отвечает ось «Правила».
Перед тем, как подискутировать, я предлагаю уточнить границы:
Метод не является полным руководством по управлению компанией.
Метод не является сводом знаний (BOK) по управлению компанией.
Метод описывает способ организации работ в проектной организацией.
Метод может стыковаться с любыми другими практиками, которые обеспечивают реакцию на все предпосылки на которых базируются Правила Метода.
Есть «авторское право» которое неотторжимо в силу закона, и есть имущественные права. Всякие «право на распространение» и т.д. Передать можно только имущественные права.
В трудовом договоре обычно прописано о переходе имущественных прав созданное произведение, с указанием при каких условиях оно создано.: «всё что создается по поручению работодателя и при выполнении должностных обязанностей». В контракте на заказную разработку явно указывается о передаче имущественных прав.
Таким образом все регламентируется и вполне прозрачно.
Даже если их не скрещивать, все-равно все что выведено за скобки методологии просто забывается и перестает применяться. Консультанты Scrum говорят "как общаться", но не говорят "что нужно сделать чтобы получить качественный код."
S_A для выполнения прогнозирования выполнения проекта на самом деле столько всего и не нужно. В интеллектуальной сфере где задачи относительно схожие есть «скорость выполнения задач» и «скорость добавления задач» (XP, Agile) на основе которых можно делать прогнозы.
Если у проекта есть риски, то в план добить работы связанные с уменьшением риска или явно заложить буфер расписания и бюджета на известные риски. То есть тоже будет известная цифра для прогноза. А на совсем неизвестные события, где сработает неизвестный риск (Мерфи напомнит о себе) закладывается стандартный буфер критической цепи проекта (см CCPM, TOC)
Таким образом самая простая модель будет такая:
D = (( ((E + R)/ (Vi — Va) ) * Bs * Bb) / T) * W
D — расчетная календарная длительность
E — оцененный, наиболее вероятный объем проекта
Vi — скорость выполнения задач, сколько работы выполнено за календарное время
Va — скорость добавления задач, сколько добавили неизвестной работы за календарное время
R — известные риски, в оцененных чел/днях с учетом вероятности возникновения
Bs — буфер расписания 50% длительности
Bb — буфер бюджета, 50% оцененного объема
T — размер команды
W — пересчет рабочих дней в календарные, с учетом праздников
И её можно посчитать в Excel.
shtorman Касательно SaaS — уже есть, BiPulse использует схему моделирования для рекомендаций что делать руководителю проекта.
Это хороший комментарий Тимофей, а есть ли у Вас какие нибудь свои рецепты ускорения развития разработчика? Как научить его думать правильно?
как понять, как этот класс делить?
Мой рецепт такой, что если есть понимание что делить надо, то наиболее оптимально это разделение по ролям. И даже если разработчик будет вначале плодить слишком много классов это можно быстро вылечить, за счёт тех же обоснований «почему ты считаешь что это должно быть отдельным классом?»
Отвечая на Ваш вопрос, касательно фундаментальности статьи:
Возможно, мне не удалось правильно донести свою мысль и Ваши ожидания от статьи разошлись с реальностью. Однако у всяких паттернов есть ключевые условия их возникновения как и у антипаттернов. Именно их и хотелось рассмотреть и начать какую-то конструктивную дискуссию именно о простых базовых принципах, применимых в качестве отправной точки при аудите дизайна (вместо «у тебя здесь божественный объект — исправь»). Однако, к сожалению, не увидел от Вас, коллега, ни одного конструктивного комментария.
Что касается способа «RTFM паттерны»:
Коллега, Вы серьезно уверены что молодой специалист, почти без стажа работы, сможет удержать в голове все паттерны и антипаттерны?
Моя практика показывает, что беглый просмотр паттернов/антипаттернов без продолжительных навыков их применения не дает хорошего эффекта.
Поэтому, повторю вопрос: какой способ Вы считаете приемлемым для быстрого обучения навыкам хорошего дизайна молодых специалистов, кроме способа «RTFM паттерны»?
И, я полагаю, что у Вас, есть хороший опыт в аудите дизайна проекта и проведении рецензирования кода. Какими критериями Вы руководствуетесь при принятии решения, хороший дизайн проекта или нет и его нужно переписать?
А что если я скажу, что есть решение которое решает все сложности календарного планирования проекта и перепланирования проекта, учитывает неопределённость оценок и интегрируется с Jira/YouTrack и другими трекерами без необходимости ручного перегона задач туда-сюда?
Из недавних примеров изменений на основе запроса: добавили опцию режима ручного планирования задач и задание режима расчета буфера чисто по CCPM и его размера вместо «адаптивного» по Pulse Management.
1. Собираем всех на «летучку»
2. Открываем «План / Оперативный / Задачи в работе» (там все факты есть сколько потратили времени и сколько хотели)
3. Идем по каждой задаче и задаём вопросы.
Если команда работает асинхронно и проект идет по CCPM (важно), и «летучку » не провести, то:
1. У исполнителя как правило есть своя задача «в работе» и карточка на неё уже открыта
2. Он тыкает в «осталось дней» и вводит значение +таб. Всё.
3. Мы на План/Тактический видим отклонение проекта.
Но этот метод плох тем, что мы не можем ускорить исполнение «в моменте». Так как на живой вопрос, мы получаем живой ответ и можем сразу предпринять корректирующие действия. Я соглашусь что дополнительный робот-пинатель будет хорошо, но его отсутствие пока это ни разу не являлось препятствием к внедрению.
>>Люди и так сопротивляются изменению устоявшейся практики, а тут вы им вгружаете дополнительные не самые простые инструменты…
Классное замечание! Мы это в версии 7.0, которая вышла в апреле этого года, преодолели! И теперь для исполнителей есть профили «исполнитель» — для тех кто «могу копать, могу не копать» и «инженер» — доски, списки задач и целей. А все стальное только для руководителя
Кирилл, со сравнению с 2017 годом, сейчас BIPULSE — почти не имеет проблем, однако для эффективного применения требует использования Метода управления «Pulse Management» pulsemanagement.org (цикл публикаций на Хабре habr.com/ru/post/462423)
Метод учитывает особенности применения CCPM для «реальной жизни» ИТ-проектов.
Проблема внедрения CCPM не в софте, а в головах. Так как требуется перестройка способа мышления и принятия решений.
2. >> Не знаю, где Вы взяли данные о том,
Статистика TOCICO, CCPM — это только один из инструментов общего процесса. В одной из компаний которую мы консультировали, сокращение одновременных исполняющихся проектов (проектов, но не контрактов) с 30 до 8 заняло полгода.
Если Ваша позиция в том чтобы отрывать головы вместо решения задачи о возвращении проекта в норму — это ваше право. Возможно у Вас неограниченные ресурсы и бюджет для таких действий, чтобы восполнить оторванную голову новой. Однако, моя практика показывает, что владелец компании меняет свои привычки для того, чтобы обеспечить выполнение всех обязательств организации вовремя и в полном объеме.
Результат применения Метода один: Выполнение Организацией всех обязательств вовремя и в полном объеме. Если вы уже применили Метод и не получили этот результат, то нужно разбираться как вам это удалось. Статистика TOCICO — 90% проектов применяющих Критическую Цепь завершаются вовремя, Метод определяет правила игры с применением инструментов ТОС, Agile и проектного управления.
Границы применения Метода и его полнота опубликована в первой статье.
о ГОСТах: ГОСТы вещь хорошая, однако:
1. Они определяют правила, но не говорят «зачем так»
2. Их мало кто читает, если это не прописано в ТЗ к контракту.
Метод Пульса (Pulse Management) решает эти два препятствия за счёт компактности практик и цельного подхода для цикла PCDA
2. Определение Пульса — в следующей публикации про инструменты Метода.
3. О потоках. Хороший вопрос! Поток — не процесс, это поток мышления. Состояние в которым мы думаем. Я раскрою эту главу лучше.
4. О «Чем отличается» Можете ли привести в процентах количество инженеров-конструкторов, инженеров-проектировщиков, инженеров-программистов (от всех) которые прочитали теорию управления производственным предприятием? Можете ли при вести в процентах количество менеджеров проектов и отделов которые прочитали приложение к PMBoK про управление программами и портфелями?
5. Как взаимодействуют: описано в методичке которая лежит на pulsemanagement.org или расскажу в последующих публикациях.
Верно!
Но Метод базируется на том что ресурсы ограничены. (позже опубликую эти части на Хабре). Но не учитывает их в модели организации.
Ограничение всегда есть. И хорошо, чтобы оно было внутри Организации а не снаружи. Но это уже вопросы ТОС. Метод формализует только одно из применений ТОС — управление проектной организацией, управление портфелем проектов.
1. Развитие Организации в направлении «Технологии» идёт когда сотрудник работает в Потоке Реализации или Управления, при этом развитие Организации в направлении Правил и процессов происходит когда сотрудник работает в Потоке Улучшений.
Все действия в Потоке Управления это принятие решений в соответствии с Правилами.
Фокус внимания в каждом потоке на разных вещах, как и инициатор изменений:
— Цели — владелец компании, продажи.
— Правила и процессы — методолог, хозяин процесса-Scrum, Владелец процесса
— Технологии и профессионализм — технолог, архитектор, руководитель отдела
2. Я не вижу такого направления развития Организации как «Ресурсы». Организация может работать вообще без ресурсов, а покупать их на стороне и при этом нормально зарабатывать деньги. Однако, обладая Технологиями мы можем создавать новые продукты или услуги. А поднимая профессионализм мы можем улучшать технологии. Но это всё не поможет, если мы не обращаем внимания на способ работы. Именно на развитие этого направления и отвечает ось «Правила».
Перед тем, как подискутировать, я предлагаю уточнить границы:
А именно:
Глоссарий: pulsemanagement.org/glossary
В трудовом договоре обычно прописано о переходе имущественных прав созданное произведение, с указанием при каких условиях оно создано.: «всё что создается по поручению работодателя и при выполнении должностных обязанностей». В контракте на заказную разработку явно указывается о передаче имущественных прав.
Таким образом все регламентируется и вполне прозрачно.
Если у проекта есть риски, то в план добить работы связанные с уменьшением риска или явно заложить буфер расписания и бюджета на известные риски. То есть тоже будет известная цифра для прогноза. А на совсем неизвестные события, где сработает неизвестный риск (Мерфи напомнит о себе) закладывается стандартный буфер критической цепи проекта (см CCPM, TOC)
Таким образом самая простая модель будет такая:
D = (( ((E + R)/ (Vi — Va) ) * Bs * Bb) / T) * W
D — расчетная календарная длительность
E — оцененный, наиболее вероятный объем проекта
Vi — скорость выполнения задач, сколько работы выполнено за календарное время
Va — скорость добавления задач, сколько добавили неизвестной работы за календарное время
R — известные риски, в оцененных чел/днях с учетом вероятности возникновения
Bs — буфер расписания 50% длительности
Bb — буфер бюджета, 50% оцененного объема
T — размер команды
W — пересчет рабочих дней в календарные, с учетом праздников
И её можно посчитать в Excel.
shtorman Касательно SaaS — уже есть, BiPulse использует схему моделирования для рекомендаций что делать руководителю проекта.
Мой рецепт такой, что если есть понимание что делить надо, то наиболее оптимально это разделение по ролям. И даже если разработчик будет вначале плодить слишком много классов это можно быстро вылечить, за счёт тех же обоснований «почему ты считаешь что это должно быть отдельным классом?»
Тимофей, а какой Ваш рецепт в этом случае?
Возможно, мне не удалось правильно донести свою мысль и Ваши ожидания от статьи разошлись с реальностью. Однако у всяких паттернов есть ключевые условия их возникновения как и у антипаттернов. Именно их и хотелось рассмотреть и начать какую-то конструктивную дискуссию именно о простых базовых принципах, применимых в качестве отправной точки при аудите дизайна (вместо «у тебя здесь божественный объект — исправь»). Однако, к сожалению, не увидел от Вас, коллега, ни одного конструктивного комментария.
Что касается способа «RTFM паттерны»:
Коллега, Вы серьезно уверены что молодой специалист, почти без стажа работы, сможет удержать в голове все паттерны и антипаттерны?
Моя практика показывает, что беглый просмотр паттернов/антипаттернов без продолжительных навыков их применения не дает хорошего эффекта.
Поэтому, повторю вопрос: какой способ Вы считаете приемлемым для быстрого обучения навыкам хорошего дизайна молодых специалистов, кроме способа «RTFM паттерны»?
И, я полагаю, что у Вас, есть хороший опыт в аудите дизайна проекта и проведении рецензирования кода. Какими критериями Вы руководствуетесь при принятии решения, хороший дизайн проекта или нет и его нужно переписать?