Архив за ‘Статьи’ категория

Кривая опыта

февраля 1, 2010

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

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

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

» Читать дальше: Кривая опыта

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

января 17, 2010

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

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

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

» Читать дальше: Прибыльность проекта

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

января 11, 2010

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

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

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

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

января 10, 2010

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

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

» Читать дальше: Менеджер и многозадачность

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

января 10, 2010

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

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

января 4, 2010

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

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

» Читать дальше: Московский метод

Хронометраж вести стало легче!

декабря 12, 2008

Нактулся в закромах интернета на интересную программу Slife.

Для установки скачал инсталяционный пакет в 400Kb с сайта, а после она еще выкачала себя (9Mb). Видимо исспользует ClickOnce.

day-small.png

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

Вот еще несколько аналогов,

TimeSnapper for Windows
RescueTime for OS X (also available for Windows)
Timecamp
Toggl
ActiveTimer

Еще одна родственная программа но которая делает снимки экрана через определенные промежутки времени TimeSnapper

Agile – это круто? Проверьте исходные предположения!

сентября 10, 2008

life-sport-rugby

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

Реальность такова:

1) Заказчик всегда хочет знать, во сколько ему обойдется проект до начала проекта. Если он не хочет этого знать, то он делает проект не за свои деньги, и вряд ли имеет финансовый интерес.

2) Редкий заказчик умеет адекватно ставить задачи и приоритеты, поэтому, скорее всего, придется это делать вам самим.

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

5) ЮнитТесты как правило удорожают проект, что не всегда оправдано.

6) Отсутствие документации по проекту это всегда недостаток, а не достоинство.

7) Постоянная доступность заказчика возможна в редких проектах, даже если заказчик доступен, хватает ли у него квалификации отвечать на вопросы, достаточно ли он компетентен в своей же области?

8) Парное программирование это круто? — если бы это было так, однажды попробовав, все бы писали в парах.

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

MS Project трюки

июня 9, 2008

images.jpg

Так как приходится много работать с MS Project, за последнее время накопилось много трюков, которые я использую, дабы облегчить понимание планов как для себя так и для стороннего наблюдателя. Я уже писал про горячие клавиши которые ускоряют работу. В этой статье речь пойдет больше о визуальном представлении данных. Большинство полезностей было подсмотрено у моих коллег, за что им отдельное спасибо!

Итак, начинаем новый проект.

База ответьте

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

Я приверженец 2-го подхода. И для удобства сравнения с начальной версией удобно сохранить первоначальный план как baseline.

Сохранение base line: Tools >Tracking > Set Baseline… > OK
Просмотр baseline: View > Tracking Gantt

И получаем примерно такой вид, на котором не сложно определить отклонения.

Baseline

Явное указание отпусков и болезней

Также, при начальном составлении плана, и в дальнейшем удобно в плане отражать отпуска исполнителей. Тут тоже мне известно 2 подхода. 1) Изменять календарь исполнителя и выставлять не рабочие дни и 2) явно указать отпуск в виде задания. Это более наглядно. Также можно таким же образом вносить в план и болезни сотрудников.

Vacations

Передвинуть задание

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

move.gif

Для того чтобы избежать разделения задания и передвинуть его установите % complete в 0, перенесите задание, а затем выставьте заново % complete в старое значение.

Отношение к прогрессу

Я пользуюсь следующим принципом в выставлении % complete задание не начато % complete = 0% в процессе 50% и закончено 100%, любые высказывания, что задание готово на 87% считаю бессмысленными, если только эта цифра не рассчитана на основании % готовности сабтасков, т.е. в идеале нужно стремиться оперировать минимально разумными единицами работы. (Помните что первые 80% процентов работы выполняются быстрее чем оставшиеся 20%)

Боевая раскраска

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

Colors

После токой процедуры чтобы понять на каком мы свете, даже стороннему человеку, достоточно несколько секунд.

Риски и внешние зависимости

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

Контрольные точки

Если план достаточно длительный, то контрольных точек в нём наберется достаточное количество. Для удобства их тоже можно вынести в отдельную группу. Также если вы не стартуете реализацию сразу после планирования, можно помещать в котрольные точки еще один пункт “Start Project A” и выставлять его как Predecessor у всего плана, т. о. мы сможем лекго сдвигать даты начала работ.

Семафор

Для автоматического вычесления показателей и определения “здоровья” проекта исспользуеться техника графических индикаторов. С помощью встроенных функций MS Project имеет возможность автоматически вычислять необходимые показатели и показывать результат в числовом и графическом виде.

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

Или можно воспользоваться более “модной” техникой.

1) Tools->Customize…->Fields.

2) Выбираем в выподающем списке Type: Duration

3) Жмем кнопку Formula… и вводим необходимую формулу

formula.gif

4) Далее жмем Graphical Indicators… И вводим необходимые условия и выбираем соответсвующие изображения.

indicator.gif

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

5) Далее жмем на заголовке колонок правой кнопкой и выбираем Insert Column… и выбираем только что созданную колонку.

plan.gif

При помощи этой техники можно вычислять самые разные показатели начиная от CV, SV, EAC и заканчивая какими-то специфичными именно для вашей области деятельности.

Также вы можете скачать пример в формате mpp (2007)

Полезные ссылки (English):
MS Project Templates
Help for Project 2007
Project 2007 Courses
Project Demos

А у вас не найдется в запасе пару хитростей чтобы пополнить этот список ?

Победить сегодня — значит проиграть в будущем

апреля 22, 2008

Наполеон Бонапарт

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

Так зачем же связываться со сложными проектами, и работать с неадекватными клиентами? Может лучше подбирать хороших исполнителей, а не безумных креативщиков?

Давайте попробуем выяснить стоит ли напрягаться. Предположим мы уже имеем за плечами большой опыт. Перед нами появляется новый проект, очень похожий на те, 100 предыдущих, которые уже успешно выполнены. Круто! Мы беремся выполнять этот проект используя весь накопленный опыт и инструментарий, все идет гладко и мы заканчиваем его в сроки и даже не вышли за отведенный бюджет. Мы победители?

НЕТ !

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

Поэтому, выйграв все сражения, проиграем войну.

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

Если вашим клиентам и подчиненным не хватает духу усомниться в ваших идеях, а их аргументы слабее ваших, в конечном счете уровень ваших идей снизиться. Буддистское изречение гласит: «Полное единодушие говорит о том, что никто не дал себе труда подумать».

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

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

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

Специалист по рекламе Дэвид Огилви сказал: Моя фирма занимается только двумя вещами 1) обслуживанием клиентов и 2) развитием своих талантов в области рекламы.

Давайте обратим внимание на наших клиентов. Достаточно ли они умны? Попробуйте вспомнить ваш последний отзыв о них, и разместим его на сайте вашей фирмы. Осталось ли там что-либо кроме предлогов?

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

Клиент — непревзойденный показатель качества.

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

Дэвид Огилви хвастался, что сам увольнял клиентов намного чаще, чем те увольняли его.

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

Ищите «крутых» клиентов, которые 1) определяют вас и 2) помогают вам расти. Инвестируйте в «крутых» клиентов, которые будут испытывать вас. И помогут вам вырасти в личном и профессиональном плане.

Книги по теме:
Том Питерс — Проект 50
Том Питерс — «Профессиональная сервисная фирма 50»