Управление проектами

Кривая опыта

Денис Журавлев — Mon, 01 Feb 2010 15:28:29 +0000

Вначале немного теории:

Кривая опыта (Experience curve) – термин, примененный в 1966 году компанией Boston Consulting Group.

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

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

Эффект кривой обучения

Если работники учатся выполнять задачу лучше, то смогут выполнить ее быстрее. Если накопленный опыт удваивается, то производительность труда может увеличиваться на 10-15%

Эффект специализации

По мере роста производства и числа работников, компания может позволить себе вводить специализацию. Если 2 человека выполняют одну и ту же задачу, можно разделить ее между ними. Первый выполняет одну часть задачи, второй другую половину. Поэтому каждый может выполнить свою часть задачи дважды. Согласно описанному выше эффекту кривой обучения, специализация позволит снизить на 10-15% время на выпуск продукции, или на 10-15% увеличить объем.

Если опыт удваивается одновременно со специализацией, то эти 2 эффекта произойдут одновременно, что может увеличить производительность на 20-30%

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

Практическое применение

На этом позволю себе закончить с теорией и представить несколько свежих идей. Попробуем спуститься от уровня предприятия пониже:

Уровень команды

Очевидно, что одна и та же команда выполнит новый проект, аналогичный предыдущему, быстрее. Так как она уже сработалась, притерлась и выработала некие внутренние стандарты. Скорее всего, что примерно на эти же 10-15% (при условии что проект действительно аналогичный). Далее скорость выполнения типовых проектов будет расти незначительно – 7%, 3%, 2%, 1%. Однако суммарный эффект будет весьма ощутим. Дальнейшее увеличение производительности уже будет возможна только при внедрении новых технологий.

Выводы:
Используйте имеющуюся сработанную команды для выполнения повторных подобных проектов.

Уровень работника

Уровень персональных знаний работника также будет иметь с течением времени похожую тенденцию. Т.е. за первый год-два будут получены большинство знаний в некоторой предметной области, далее темпы углубления знаний в этой же области будут постепенно снижаться. Мастера, оттачивающие свое мастерство десятилетиями каждый последующий год получают все меньше знаний, чем в предыдущем, однако в суммарном отношении превосходят средних специалистов. Попробую грубо проиллюстрировать эту идею так:

Человек без опыта изготовит табуретку за 60 мин. Далее каждую последующую он будет изготавливать на 10% быстрее

Cкорость изготовления табуретки

Опыт (шт.)	0	1	2	3	4	5	6	7	8	9	10
Время	60	54	48,6	43,7	39,4	35,4	31,9	28,7	25,8	23,2	20.9

Человек с улицы (0 табуреток опыта) – 60 мин
Подмастерье (3 табуретки опыта) – 43,7 мин
Специалист (5 табуреток опыта) – 35,4 мин
Мастер (10 табуреток опыта) – 20,9 мин

Выводы:
При найме или оценке сотрудника справедливо от него ожидать N% процентный прирост производительности ежегодно, в зависимости от имеющегося у него опыта, так как он повышает уровень своих знаний.

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

Не всегда стоит нанимать мастеров, иногда будет достаточно специалиста, ведь зачастую это будет дешевле.

Про кривую опыта можно почитать тут:

Experience curve effects
Кривые опыта
О чем говорит кривая опыта?

Прибыльность проекта

Сергей Синькевич — Sun, 17 Jan 2010 20:34:19 +0000

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

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

Далее пробуем посчитать — насколько же ваш проект выгоден? :-)

Воспользуемся простейшим определением из википедии, гласящим о том что прибыль — это превышение в денежном выражении доходов от продажи товаров и услуг над затратами на производство и сбыт этих товаров и услуг. Существуют разные типы как учёта, так и классификации прибыли (бухгалтерская прибыль, экономическая прибыль, валовая прибыль, чистая прибыль). Однако, давайте для начала не усложнять, и рассмотрим простую формулу в виде разности двух упомянутых выше понятий: Прибыль = Доход – Затраты.

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

Давайте теперь посчитаем затраты на оказание этих услуг. Что же происходило? :) Программисты программировали, тестировщики тестировали, и так далее — обобщая, люди тратили рабочее время на заказчика. Зарплата всех работников, задействованых в проекте, суммарно составила 600 тугриков. И сколько же у нас получается прибыли для организации? 400 тугриков?

Конечно же, нет. Для начала давайте вспомним, что в прошедшем месяце мы дополнительно купили для нужд программистов специализированную программную компоненту, стоимостью 100 тугриков. Что ж, добавим её к затратам, проверим чтобы больше ничего не забыли — вуаля, получаем прибыль в 300 тугриков?..

И снова стоп. Кроме затрат на собственно оплату труда, компания несет множество других затрат: аренда офиса, затраты на оборудование (те же компьютеры, интернет и т.д.), оплата труда административных работников и прочие косвенные затраты, которые также надо учитывать при расчете прибыльности.

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

В следующих заметках мы попробуем составить нашу модель и научиться ею пользоваться.

Если у вас есть что добавить по этому вопросу — добро пожаловать в комментарии :-)

Исполнитель и многозадачность.

Денис Журавлев — Mon, 11 Jan 2010 19:09:33 +0000

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

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

Честный программист оценил каждую задачу в 3 дня. И приступил к выполнению. Менеджер, как человек ответственный, не забывает напоминать несчастному программисту о том, что заказчик ждет с нетерпением его задачу уже вчера. В результате чего, программист, переключаясь между задачами все же успел уложиться в первоначальные оценки и выполнить все задачи без задержек.

Однако в результате переключений на выполнение каждой задачи потребовалось ~7 дней. Первый менеджер получил задачу на 4 дня позже чем мог бы, соответственно были задержаны другие задания связанные с выполненным далее по цепочке (тестирование, релиз и т.п.), была задержана оплата и т.п.

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

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

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

В заключение приведу несколько общих рекомендаций:

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

Менеджер и многозадачность

Сергей Синькевич — Sun, 10 Jan 2010 20:38:24 +0000

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

Достаточно много известных людей уже высказывались на эту тему. Приведу несколько ссылок:

Что ж, давайте попробуем самостоятельно взглянуть на этот аспект деятельности менеджера. Если взглянуть на ежедневную работу, выполняемую руководителем (например, менеджером проекта), то можно заметить, что переключение контекста происходит чрезвычайно часто. Работа с текущей почтой кажется однообразным занятием только для тех, кто не понимает что происходит. Мы же знаем, что каждое новое полученное или отправленное письмо представляет собой или новую задачу, или продолжение одной из старых. Сколько писем проходит через почтовый ящик среднего современного менеджера? 100? 300? Иногда это число измеряется не в сотнях, но в тысячах… А ведь еще есть работа с документацией, с различного рода системами таск-, баг- и ишью-трекинга. Каждый новый пункт, который мы открываем в такой системе — это новый контекст. Суммируя и усредняя, давайте будем считать, что в среднем число переключений будет равно 500.

Несложно посчитать что (8 часов рабочего дня * 60 минут) / 500 = около 1 минуты — это максимальное время переключения между контекстами, которое менеджер может себе позволить. А ведь еще необходимо провести обработку и регистрацию поступившей информации.

Ясно, что не каждый человек способен, да и не каждый желает работать в таком режиме. Что ж, для большинства из них профессия менеджера не подходит вовсе; меньшинство же продолжает этот путь, но старается избегнуть такого рваного ритма, применяя различные техники тайм-менеджмента. Это меньшинство часто прекрасно себя показывает на вторых ролях, когда основной задачей менеджера стоит нечастая обработка больших обьёмов информации.

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

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

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

Если что-то в моих рассуждениях осталось неясным, или же просто есть желание подискутировать на эту тему — милости прошу в комментарии к этому посту.

Бесплатный Хронометраж

Сергей Синькевич — Sun, 10 Jan 2010 18:19:28 +0000

Вновь подниму тему персональной эффективности, и напомню коллегам о пользе хронометража личного и рабочего времени. Чтобы не изобретать велосипед, дам ссылку на выдержку из книги известного гуру тайм-менеджента Глеба Архангельского: вот она.
Известно что любая идея чахнет без подходящего инструмента, поэтому в дополнение темы о программах измерения рабочих активностей по времени, позволю себе добавить бесплатный аналог, которым сам пользуюсь уже некоторое время: ManicTime.
По функциональности, из плюсов — возможность делать личные тэги по задачам/проектам (что реально очень удобно), интуитивно понятный интерфейс; из минусов — обьём потребляемой памяти (все-таки .NET :)

Microsoft Office 2010 – что нового?

Денис Журавлев — Sun, 03 Jan 2010 22:03:39 +0000

На нас надвигается новая волна продуктов от Microsoft. И вот уже до нас докатились отзвуки Office 2010 beta (оффициальный релиз запланирован в ближайшие пол-года). Что же можно ожидать в новой версии можно узнать из бесплатно распространяемой 200-страничной книги Катерины Мюрей “First Look Office 2010” (PDF, 10Mb)

Краткое оглавление:

Part I Envision the Possibilities
1 Welcome to Office 2010
2 Express Yourself Effectively and Efficiently
3 Collaborate in the Office and Around the World

Part II Hit the Ground Running
4 Create and Share Compelling Documents with Word 2010
5 Create Smart Data Insights with Excel 2010
6 Manage Rich Communications with Outlook 2010
7 Produce Dynamic Presentations with PowerPoint 2010
8 Organize, Store, and Share Ideas with OneNote 2010
9 Collaborate Effectively with SharePoint Workspace 2010
10 Create Effective Marketing Materials with Publisher 2010
11 Make Sense of Your Data with Access 2010

Part III Next Steps with Office 2010
12 Putting It All Together
13 Security in Office 2010
14 Training Made Easy

Московский метод

Денис Журавлев — Sun, 03 Jan 2010 21:44:04 +0000

Начну с истории из реальной жизни. Был у нас один заказчик, который предпочитал сам выставлять приоритеты требованиям и багам. Все начиналось классически — High, Medium, Low. Однако в какой-то момент он решил усовершенствовать эту систему и добавил Very High. Но со временем и этого оказалось мало, появился приоритет Urgent. Наверное, это может продолжаться и дальше.

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

Однако прогресс не стоит на месте. И один из консультантов Oracle UK Consulting, Dai Clegg предложил логичный и понятный метод приоритизации для бизнес анализа и разработки ПО — MoSCoW prioritization.

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

MoSCoW — легко запоминающаяся аббревиатура:

M — MUST have this.

S — SHOULD have this if at all possible.

C — COULD have this if it does not affect anything else.

W — WON’T have this time but WOULD like in the future.

Must have — Жизненно необходимые

Требования отмеченные как MUST have должны быть включены в текущую поставку. Если хоть одно из требований не сделано, поставка считается провальной.

Should have — Обязательные

Требования SHOULD have также критичны для успеха проекта, но не необходимы в ближайших поставках. Такие требования имеют workarounds, то есть имеются обходные пути для выполнения требований, и могут быть отложены на будущие поставки продукта.

Could have — Пожалуй можно реализовать

Требования COULD have менее критичные требования, обычно относящиеся к «nice to have». Чаще всего менее трудоёмки чем первые 2 категории.

Won’t have (but Would like) — Можно и не делать, но хотелось бы

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

Ссылки:

http://en.wikipedia.org/wiki/MoSCoW_Method

http://www.projectsmart.co.uk/moscow-method.html

http://www.coleyconsulting.co.uk/moscow.htm

Microsoft Project 2010 Вооружен и опасен. Trial версия доступна всем.

Денис Журавлев — Thu, 10 Dec 2009 11:38:38 +0000

Новая версия народно-любимого Проджекта в триале доступна для скачивания:
Бета-версия Microsoft Project Professional 2010

Почитать информацию можно найти тут:
Официальный сайт продукта Чем богат Microsoft Project 2010 Портал по Microsoft Project 2010
An Overview of Project 2010

Fixed-price со скрытым конфликтом

Денис Журавлев — Fri, 11 Sep 2009 13:25:16 +0000

Последние полгода был занят на fixed price проектах, и что характерно несмотря на различния в сферах применения в них было много общего.

Сразу хочу выдвинуть Disclaimer: ниже речь пойдет о средних и больших проектах, которые выполняются штучно, а не на конвеерной основе.

Самое основное, что объеденяет проекты такого рода это изначальное наличие конфликтной ситуации:

Чтобы завершить проект, как планировалось, во время и в рамках бюджета, необходимо зафиксировать требования (freeze requirements), и не допускать дальнейшего изменения и разрастания требований.

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

Данную ситуацию можно изобразить с помощью следующей «грозовой тучи конфликта» которые исспользуют в теории ограничений

В основном заказчик зачастую сам не подозревает как сказываются на конечном результате фиксированые требования, и так как к этому вынуждает его существующая юридическая практика, а также его опыт работы с не-ИТ подрядчиками.

Итак заказчик объявляет тендер, и находит подходящего исполнителя. Подписываются все общепринятые документы в которых как правило фиксируется бюджет, сроки (с обозначены штрафами за их нарушение) и содержание проекта (в виде ТЗ или другого документа). Итак исполнитель приступает к работе и оказывается, что все стороны «проектного треугольника» зафиксированны.

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

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

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

Т.о. fixed-price проекты не ведут к win-win ситации как для заказчика, так и для исполнителя.

Вывод напрашивается сам собой: Осторожно fixed-price !!!

PS: А как же жить дальше попробуем разобратся в следующих выпусках.

Впечатления от Baseсamp (37 signals)

Алексей Горобчук — Tue, 30 Jun 2009 08:53:34 +0000

Сразу скажу, я получил то, что ожидал. Все просто, аскетично, функционально. Примерно в таком же духе множество отзывов об этой системе, и я подтверждаю это.Что такое BaseCamp? Это онлайн система ведения проектов. Работает по схеме SAS (Software As Service). Мне требуется вести 4—7 небольших проектов одновременно, в каждом из которых задействованы 2—3 человека. Для моего случая BaseCamp оказался очень удобным.В каждом проекте есть списки TODO, списки участников, milestones, whiteboard и сообщения. Как использовать все это богатство вы решаете сами.

Например в whiteboard я разместил несколько ссылок на ресурсы проекта, а сами ресурсы проекта находятся в моем SVN репозитории и в блокноте Google. В BaseCamp есть возможность хранить файлы, но я этой функцией не пользуюсь, потому что привык хранить все в SVN. Сообщения я использую для публикации еженедельных отчетов. Milestones привязываю к конкретным датам. А списки TODO привязываю к milestones. Каждую задачу в TODO можно назначать на конкретного человека.Благодаря тому, что система не перегружена функциями, работа с ней отнимает совсем немного времени.Любителей больших графиков, диаграмм ганта и подобных наворотов хочу огорчить, этого ничего нет. Есть правда API, я с ним еще не разбирался, может эти вещи реализованы через модули сторонних разработчиков с использованием API? Не знаю.Интересно узнать насколько удобно пользоваться BaseCamp для ведения крупных проектов, с 10—15 участниками. Если у вас есть подобный опыт, поделитесь.Ссылки:http://37signals.com/