Uncategorized

Сайт для аналитиков в ИТ проектах

0

Начал работать новый сайт для аналитиков http://thinkersware.com/. ThinkersWare собирает не только полезные статьи – но и организовывает аналитическое сообщество. Первая аналитическая конференция пройдет 12 декабря 2014 для членов клуба. В планах на 2015 год – много интересного контента, несколько ежеквартальных конференций для аналитиков.

Об учёте времени в проектах разработки ПО

0

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

  • Нужно ли учитывать время по каждой задаче?
  • Нужно ли отчитываться каждый день?
  • Полезны ли «таймшиты» и как они должны выглядеть?
  • Кто должен заполнять отчёты и когда?

Различные варианты сводятся к трем базовым подходам:

  • Учёт потраченных человеко-часов с разбивкой по задачам
  • Учёт реализуемого функционала (backlog/requirements) и общая оценка стоимости работ
  • Творческая работа без списка функционала и контроля ресурсов

 

Timesheets
Учёт времени по каждой задаче
Backlog
Учёт совокупного времени, потраченного на итерацию и функции
Существует отдельная или интегрированная система учета рабочего времени (Timesheeting), обязывающая сотрудников вводить информацию о том, на что были потрачены его 8 рабочих часов в день. Крайним случаем детализации
можно назвать фиксацию времени, потраченного на каждый этап работы над задачей или даже обязательную разбивку затрат по конкретным датам, если задача длилась более 1 дня.Если система Timesheeting отделена от проектного управления, то учёт может вырождаться до второго случая, когда часы «списываются» на проект или крупную высокоуровневую задачу.
Команда имеет систему управления требованиями и методологию выбора
некоторого количества требований для реализации в итерацию. Это может быть backlog, список требований, запросов на изменения и дефектов, доска задач SCRUM или Kanban и т.п.Учитываются совокупные затраты всей команды на итерацию, при этом может также производиться условная оценка трудоёмкости требований  в storypoints или баллах сложности.

Подробнее читать тут - http://habrahabr.ru/post/149542/

План Б

0

Успех любой организации напрямую зависит от ее лидеров. И, прежде всего, это они ответственны за успешное управление и контроль над процессами в компании. Портал Training.com.ua (http://www.training.com.ua/) приглашает широкую бизнес-аудиторию менеджеров на форум для руководителей “План Б” (http://event.hrm.ua/action/2), посвященный вопросам управленческих решений. Мероприятие состоится 4-го октября в Киеве и будет организован в виде четырех параллельных потоков.

В нашей стране вопросы бизнес-администрирования зачастую все еще решаются внутренними силами компании. В то же время растет качественный уровень и спрос на профессиональные консультационные услуги в данной сфере. А значит, открытый диалог с экспертами управления представляет собой большой интерес для руководителей как малого и среднего бизнеса, так и крупных компаний. Портал Training.com.ua (http://www.training.com.ua/) провел отбор наиболее актуальных тем для мастер-классов по направлениям: управление компанией, управление продажами, управление персоналом и личная эффективность. Каждый 50-минутный мастер-класс посвящен конкретному инструменту, который руководители могут использовать на практике.  (more…)

Кто здесь

0

Количество участников проекта всегда больше чем вам кажется

The Blind man and the Elephant

Опубликованы российские национальные стандарты в области проектного управления

0

Издательством Федерального агентства по техническому регулированию и метрологии опубликованы российские национальные стандарты в области проектного управления. В их разработке принимали участие компания PM Expert и группа компаний (ГК) “Проектная практика”.

К утвержденным стандартам относятся:

  • ГОСТ Р 54869—2011 “Проектный менеджмент. Требования к управлению проектом”;
  • ГОСТ Р 54870—2011 “Проектный менеджмент. Требования к управлению портфелем проектов”;
  • ГОСТ Р 54871—2011 “Проектный менеджмент. Требования к управлению программой”.

Перечисленные выше стандарты вводятся в действие в Российской Федерации с 1 сентября 2012 г. Цель создания данных стандартов — введение общепринятых требований в области управления проектами, программами и портфелями проектов, и, как следствие, повышение эффективности проектного менеджмента в России. Утвержденные стандарты содержат основные требования к процессам управления проектом, программой и портфелем проектов. Положения стандартов применимы для различных организаций и любых типов проектов, в том числе на государственном уровне.

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

Закончена книга Иванова и Просницкого по MS Project

0

Владимир Иванов и Алексей Просницкий закончили самоучитель по MS Project в wiki-формате. За счет wiki вы можете сами исправлять или расширять самоучитель подобно как это делается в Википедии.

http://turboproject.ru/projectmanagement/MS_Project

чем дольше у вас все плохо, тем …

0

Нассим Талеб сформулировал довольно простую теорему: «чем дольше у вас все плохо, тем меньше вероятность, что у вас будет все хорошо».

Итак, у нас есть какой-нибудь проект, по которому просраны все сроки, но его вот еще чуть-чуть и наконец-то сдадут.

Надеетесь? Уже сами себя обманули? Еще раз прочитайте цитату в первом абзаце.

Михаил Завилейский: 5 способов управления ожиданиями

0

Как оправдывать ожидания? Непростые правила…

Как говорит Ицхак Адизес, залог процветания компании – в долговременных отношениях с удовлетворенными клиентами, а как говорит Дэвид Майстер, удовлетворенные клиенты – это те, кто получают то, чего ожидают, или чуть больше ;) . Таким образом, попадание в ожидания клиентов – это не просто важно, это самое важное, что есть в нашем бизнесе.

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

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

Что же делать? Конечно, надо умело управлять и ожиданиями, и восприятием клиента, вопрос только в том, как это делать. Как водится, простых правил нет, но есть разные способы, один из которых обычно помогает. Опишу основные известные мне, которые или использовал я сам, или другие использовали со мной. Начну с трех немного сомнительных и перейду к двум более симпатичным и одному великому и ужасному ;) .

(more…)

Когда мы думаем что Duration и даты взбесились

0

Как показывает практика обучения многих начинающих руководителей проектов – при нестандартных ситуациях с календарем они впадают в ступор при наблюдении что происходит с полем длительность и датами по задаче.

Давайте рассмотрим ситуацию: Необходимо спланировать задачу “Демонстрация продукта” в течении 6 дней с 8 до 20-00. Задача выполняется без перерыва и должна быть обеспечена персоналом. Гуманное руководство разрешило задействовать два сотрудника отдела маркетинга и продаж по 6 часов без перевыва – с 8 до 14 и с 14 до 20 соответственно.

Для отображения данной задачи в Microsoft Project сделаем следующее:

  • Создадим календарь для задачи с понедельника по субботу, с 8 до 20 без перерыва
  • Назначим календарь на задачу
  • Создадим два календаря для ресурсов – с 8 до 14 и с 14 до 20 соответственно.
  • Введем ресурс продавцов в проект и определим для них календари индивидуально на основе согласованного графика с их руководителем
  • Назначим ресурсам индивидуальные календари
  • Назначим ресурсы на задачу

И когда мы посмотрим на соотношение Duration (Длительность) и Дат – мы найдем чему удивиться.

 

Получается что задача покрывает нужные нам даты с понедельника по субботу (6 календарных дней) только при указании длительности (Duration) в объеме 9 дней. Вот именно тут и начинают себя не комфортно чувствовать многие пользователи Microsoft Project.

Почему так? В большинстве своем мы интуитивно неправильно понимаем Duration.

Давайте посмотрим на оригинальное определение Duration в On line Help для Microsoft Project: ”The total span of active working time that is required to complete a task. This is generally the amount of working time from the start to finish of a task, as defined by the project and resource calendar.” Обратите внимание на выделенный кусок определения. Надо понимать длительность не как количество полных астрономических дней а как количество доступного рабочего времени.

Теперь давайте вспомним что есть настройки в Microsoft Project где дано определения дня, недели и месяца:

Именно в них дается определение сколько реальных часов рабочего времени понимать под условным обозначением День вводимых в поле Длительность (Duration).

Т.е. когда вы указываете длительность задачи 5 дней – вы на самом деле указываете длительность задачи как 40 рабочих часов – но никак не 5 рабочих дней. Отображение 5 дней – это всего лишь удобный (до таких ситуаций) способ отображения информации. Если мы с вами изменим календарь задачи и ресурса, например, на 2 часа – то задача длительностью в 5 дней будет выполнена за 4 календарных дня. Так как каждый день  мы предполагаем работать по 10 часов. Именно так и расшифровывается выше приведенная ситуация – учитывая что в задаче было спланировано 12 часов, то при настройке 8 часов как одного дня – длительность составила 9 дней при 6 календарных.

Go to Top