Инструменты менеджера Ответы на вопросы
Как оценивать задачи? В каких единицах оценивать задачи для инженера?
Обычно я рекомендовал оценку в человеко-днях, аргументируя "так честнее" по сравнению с "единицами сложности" (Story points). И меня спрашивали "А почему не в человеко-часах или идеальных человеко-часах?"
Любая система предназначена для решения каких-то задач. Если мы говорим об автоматизированной системе, то это может быть простая автоматизация рутины, или существенное подспорье для руководителя.
Agile Производительность Управление проектами
Когда у нас все специалисты кросс-функциональны это идеально, но так не бывает. Однако иногда, в редких случаях это можно достичь, особенно в смежных областях знаний.
Agile, как новая управленческая религия, захватывает все больше умов. Это хорошо, когда собственник или руководитель компании понимает необходимость изменений и думает как можно применить Agile для повышения прибыльности компании. Но что делать когда рядовые сотрудники хотят применить, а руководство их не поддерживает?
Для кого-то Agile - это культура или религия. Для меня Agile - это СПОСОБ достижения целей. И он всегда таким для меня был, с 2003 года, как внедряю Agile/XP. Но недавно, рассказывая об Agile для руководства одной крупной компании, я понял что...
Agile - это способ эффективной эксплуатации умных сотрудников, так, что они при этом счастливы.
Друзья, мы хотим сделать проектный мир не только лучше, но удобнее и проще!
Встречайте, новая версия интеллектуальной системы управления проектами BIPULSE уже ждет того, чтобы Вы ее попробовали. Если еще не пробовали, то мы готовы приехать с презентацией и демонстрацией к Вам в офис, или устроить демонстрацию удаленно.
Что мы улучшили и добавили в новой версии:
На 44 встрече Санкт-Петербургского Клуба Менеджером ИТ проектов (SPB SPM Club) Анатолий Иванов, руководитель разработки компании Embria, делился своими секретами успешного проекта, за его плечами построенный центр разработки для Тинькофф Банка и более 10 лет опыта работы ИТ директором.
Мы публикуем видео и тезисы выступления Анатолия.
Проекта не существует без Устава. Даже, если проект длительностью две недели как итерация или спринт в Agile, устав проекта нужен. Иначе как вы определите критерий успешности проекта или критерий завершения проекта?
При планировании проекта, устоявшейся нормой является наличие детального плана всех характеристик продуктов уже на начале проекта. Методология планирования проектов ТОС, которая называется CCPM (Управление Проектами по Методу Критической Цепи), исходит из предпосылки, что уже в самом начале проекта существует хорошее понимание требуемого результата проекта и все задачи, которые необходимо выполнить для достижения этого результата, также известны вначале проекта.
Является ли эта предпосылка соответствующей реальности в множестве проектов? Хорошо ли иметь детальное определение результата проекта до начала проекта? Это хороший способ выполнения проектов? Какой уровень детальности необходим для принятия решения о начале проекта и оценки его рационального бюджета? Что на самом деле нужно, чтобы оценить время выполнения проекта?
После того, как получены ответы на первые четыре вопроса, мы имеем две важные категории информации. Первая – это лучшее понимание ценности для клиента, а вторая – это вызов, связанный с переходом от одного набора политик, норм и поведения к другому. Вторая категория является ключом для поиска ответов на следующий вопрос.
Вопрос 5: Исходя из вышеизложенного, какие изменения/добавления нужно сделать в новой технологии?
Другими словами, какие характеристики должны быть включены в разрабатываемую технологию, чтобы поддержать использование политик, норм и поведения, позволяющих получить наибольшую ценность от новой технологии?
Пятый вопрос возвращает нас к планированию проекта и фокусирует его на том, что действительно необходимо. Несомненно, негативные ветви новой технологии должны быть изучены и найдены пути их «отсечения».
Вопрос 1: В чем сила новой технологии?
Первый вопрос – это единственный вопрос с точки зрения разработчика новой технологии. Его цель – собрать основную информацию для последующих вопросов. Здесь мы ожидаем получить понятный перечень возможностей для того, чтобы быть в состоянии ответить на другие вопросы.
Впервые эти шесть вопросов появились в книге «Цель-3. Необходимо, но недостаточно» (Голдратт, Шрагенхайм, Птак, 2000) и включали в себя анализ модулей ERP систем, заменяющих (в действительности — лишь расширяющих) MRP систему (изначально MRP1[i] позднее превратившейся в MRP2).
Прежде чем обсуждать эти шесть вопросов и то, как применить их к разработке новых продуктов, давайте обсудим некоторые вопросы, связанные с расплывчатым значением слова «ценность» и в особенности то, что влияет на восприятие ценности.
Применение общих подходов Теории ограничений, методологии составления графиков проектов и контроля за реализацией единичных проектов получила название Управление Проектами Методом Критической Цепи (CCPM). Позднее эта методология была также расширена на управление в условиях мульти-проектного окружения. Тем не менее, Теория ограничений до сих пор не внесла значительного вклада в другие критически важные области принятия решения в управлении проектами.
Самый обычный настенный "Календарь на год", как инструмент стратегического планирования лучше, чем любая программа. Как бы ни была хороша программа для планирования проектов, она не заменит "аналогового" календаря, висящего на стене.
Итак, мы, Алексей Васильев и Руслан Лазуков провели деловую игру по самым важным документам проекта в Санкт-Петербургском сообществе менеджеров ИТ проектов (SPB SPM Club). Точнее это был тренинг. Тренинг на отработку навыка написания Устава проекта и Плана управления проектом.
Никакое ИТ решение не может реально помочь, когда нет подкрепления методологией обеспечения коммуникаций в компании или команде проекта и фокусирования целях. Поэтому, BIPULSE будет наиболее эффективен если следовать принципам Agile, Теории Ограничений Систем и Бережливого производства которые мы свели в 7 простых правил.
Так часто бывает, что обещаешь выполнить какую-то работу в срок и не успеваешь. Особенно когда нужно сделать не одну маленькую задачу, а какой-то большой объем работ, на две недели, месяц или два. Причин не успевания может быть много:
И когда вы уже понимаете что явно не успеете, начинаются метания: "А что делать?"
Agile eXtreme Programming Scrum
Сейчас много говорят о гибких подходах к разработке программного обеспечения. И даже пытаются внедрить для выполнения государственных контрактов. С другой стороны, много компаний спотыкаются на этих подходах. И хотя в компаниях делают что нужно, и даже Скрам-мастер в них есть, программный Продукт почему-то перестает развиваться, и появляется много задач на исправление дефектов. Давайте разберемся почему так происходит.
Что такое качество команды? В каких попугаях его мерить?
Качество команды величина субъективная, однако его можно выразить через скорость поставки качественного продукта решающего задачу клиента. Если записать это в терминах ТРИЗ, через идеальный конечный результат, то получим, что качественная команда поставляет качественный Продукт за ноль времени, и потери связанные с переделкой сделанной работы отсутствуют.
Но если мы знаем, что такое качество, и оно нас не удовлетворяет, то как мы можем его улучшить? Как улучшить то, что нельзя пощупать?
