10 Contracts for your next Agile Software Project | Agile Software Development

Может кому пригодиться:

10 Contracts for your next Agile Software Project

Источник: 10 Contracts for your next Agile Software Project | Agile Software Development.

Некоторые цитаты, относящиеся к подготовке коммерческого предложения

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

“Any proposal manager (or outside consultant, for that matter) who claims to know how to run a serious proposal effort without chaos should be quietly and briskly dismissed from reality. Chaos is the very nature of the proposal beast, and the manager who accepts this fact is ready to face another one: While the chaos of proposal work cannot be eliminated, it must be controlled. Otherwise, it will eat the managers, the proposal team, and the proposal itself alive.”

• Pugh, 1993, p. 82

“There are many ways to write proposals as there are companies, but many of these ways are crude, ineffective, expensive, and bound to repeat many previous mistakes…

We cannot stress enough that organized proposals are probably twice as likely to succeed as those ‘fly by the seat of the pants’ exercises…”

• Whalen, 1996, p 1-3

“….managing a proposal is one of the toughest, most challenging jobs you will ever encounter. It involves dealing with a wide variety of people with conflicting interests and organizing and directing the efforts of an ad hoc collection of people with diverse talents and expertise into a cohesive, motivated team under the most adverse circumstances in an intensive activity and under great pressure to achieve a goal against which the odds of success are not favorable. Can you think of a more daunting endeavor anywhere else in the world?

• Helgeson, 1994, p.206

“An enormous amount of time is wasted in aimless, rambling meetings replete with musings and irrelevant chatter of unfocused dilettantes intent on wasting everyone’s time while they run their mouths. I would wager that the man hours wasted every single day in the conference rooms of America would be equivalent to the number of man hours required to build the Taj Mahal.”

• Helgeson, 1994, p. 192

“A proposal must deliver critical ideas quickly and easily. Your writing must be clear if you want others to understand your project and become excited by it. It will be hard to accomplish this if you have not clarified your thoughts in advance.”

• Geever and McNeil, 1993, p. 17

“Developing a clear, comprehensive picture of what the client is seeking is the single most important part of your whole proposal preparation process – if you get the requirement wrong, you’ll get the solution wrong.”

• McCann, 1995, p.53

“You ought to be writing the proposal to sell stuff. Products, services, projects, ideas. Whatever you’ve got. The proposal is a marketing tool; it helps you make money by convincing people to contract with you for the kinds of things you can provide. The proposal positions your product or service as a solution to a business problem.”

• Sant, 1992, p. 9

Top 10 Procurement Risks – Tender Preparation – PM Hut

Top 10 Procurement Risks – Tender Preparation – PM Hut.

Управление проектом через управление рисками

Совсем недавно начал читать книгу «Deadline. Роман об управлении проектами» (Том ДеМарко). Не скажу, что данная книга «захватила» меня с первых страниц, как это сделала книга «Критическая цепь» (Голдратт М. Элияху), однако что-то в ней есть и останавливаться пока не собираюсь. Книга отличается от большинства технической литературы – она повествует о проблемах и способах их решений. Это роман. И этим все сказано.

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

Будем читать дальше… J

Риски при использовании новых инструментов.

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

Итак. По поводу начала работы. Скорее всего (и в большинстве ситуаций, которые мне приходилось наблюдать) сценарий будет следующим:

• Человек кратко ознакомиться с доступными материалами и очень поверхностно посмотрит на новый «инструмент» исходя из предыдущего своего опыта.
• Скорее всего, он найдет некоторые аналогии и сделает пагубный вывод – можно использовать предыдущий опыт, методы и в новом «инструменте».
• Произведет оценку работы и что хуже всего – выдаст оценку своему начальнику или заказчику.
• Во время исполнения он столкнётся с фактами, которые ранее не были замечены.
• Погрузится в изучение и потратит время
• Реализует задачу согласно скупым знаниям о новом «инструменте» и предыдущему опыту (вот только пришла мысль, что может возникнуть вопрос – неужели предыдущий опыт не нужен? Нужен и очень важно уметь видеть его слабые и сильные стороны, критически подходить к нему и главное использовать его в нужное время, в нужном месте и с умом.)
• А еще прибавьте то же самое для каждого члена команды. Итог – каждый делает по-своему и в силу своих возможностей. Проект – полная мешанина и в дальнейшем большие проблемы с интеграцией и качеством.
• Ну что – время потратили, проект не реализован (ну хорошо, если реализован хотя бы с задержкой), деньги перетрачены с лихвой, клиент не доволен, потеря репутации, потеря клиента и возможных проектов от него, потеря потенциальных клиентов и как результат всего – денег и развития.
• И при всем при этом исполнитель всегда найдет оправдание. Хорошо, если при этом клиента не назовут «последним придурком». При этом он как специалист и как человек просто отличный.

Здорово… Не так ли? Знакома ситуация? Мне так очень!

Что ж, надо определить наличие этого риска в проекте. Как это сделать? Каждый новый «инструмент» практически всегда – риск. Хорошо если есть люди, уже немного поработавшие с ним. Наверное, самый быстрый и простой способ – произвести умеренный анализ «инструмента» (а кое-где и глубокий), сформировать список возможных методов работы, сопоставить с требованиями и определить возможные проблемы. Еще проще, наверное, проконсультироваться с людьми, которые хоть немного сталкивались с этим «инструментом» и выявить возникавшие проблемы и недостатки.

Ну а теперь, в случае наличия данного риска, надо его предотвратить.

Вот мои варианты:

• При наличии запаса времени, необходимо определить задачи, которые должны быть покрыты «инструментом», закрепить эти задачи за членами команды и выделить время для достаточно глубокого анализа возможностей «инструмента» и определить «подводные камни», затем провести совещание и поделиться полученными знаниями. Такой подход я использовал будучи менеджером одного из проектов для Tomson-Reuters на EPAMе. Ребята справились на «отлично». По-моему, это сыграло свою роль в дальнейшем развитии проекта.
• Другой вариант – изучить, как используется «инструмент» на других компаниях (подразделениях, проектах) и просто скопировать методику. Этот пункт может использоваться в комбинации с первым подходом.
• Для случая недостатка времени (когда проекты стартуют непредсказуемо) необходим другой подход. На Альторосе я предложил директору создать инновационную группу, которая бы отслеживала вместе с отделом маркетинга тенденции в области разработки, определяла наиболее перспективные, накапливала знания до некоторой глубины, реализовывала небольшой проект для «обкатки» знаний и в случае появления проекта из данной области человек из этой группы мог бы передать знания участникам проекта и некоторое время их сопровождать. Плюсы, я думаю, видны сразу, так же как и минусы. На сколько я знаю, такую группу на Альторосе всё же сформировали хоть и после моего ухода. Пока не знаю ничего про ее эффективность – надо разузнать J
• Ваш вариант?

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

1. Надо ли проводить review (кода, проекта, процессов)?
2. Если надо, то должна ли быть официальна процедура?
3. Связано ли review с какими-либо рисками? Если да – то, как и какими?
4. Естественно – как определить есть ли риск?
5. И если есть – что сделать чтобы предотвратить пагубное влияние на проект?

Ежедневные задачи и риски

Имея некоторое количество свободного времени, я начал «переваривать» прошлый практический опыт. И он, оказывается, есть J. Вспомнились моменты из EPAM-овской жизни, где я работал разработчиком и менеджером проекта, а также Альторосовской жизни в роли VP of Engineering Services. Вот это все и навеяло написать про конкретные риски, их влияние на проект, способы идентификации и возможные действия, и способы предотвращения.

Один яркий момент не дает мне покоя. Каждый разработчик, каждый управленец хоть раз сталкивался с ситуацией, когда необходимо использовать новый инструмент (новый фреймворк, новый язык программирования, новую модель бизнеса и т.д. – список может быть бесконечным. Я думаю – каждый может подставить что-то свое.). Теперь давайте взглянем на людей, которые будут непосредственно работать с этими новыми инструментами (как правило, еще и в сжатые сроки). Естественно, знаний про нововведение мало или вообще никаких. Что в это ситуации будет происходить? Задумайтесь на минутку, прежде чем читать дальше. Подумайте над следующими вопросами (представив себя в разных ролях на проекте):

• Что предпримут работники для начала работы?
• Как они будут использовать новый инструмент?
• Что произойдет с временными и денежными затратами?
• Как определить, что этот риск возможен на конкретном этапе конкретного проекта в конкретной ситуации?
• Какие шаги необходимо предпринять, для того чтобы минимизировать, а лучше предотвратить превращение риска в проблему?
• Что мешает выполнить эти шаги?
• Какие альтернативные варианты возможны для каждого шага?
• Кто и что может помочь на каждом этапе?
• В какие сроки эти шаги должны быть выполнены, чтобы риск не реализовался?
• А что если вообще ничего не делать?

Свои мысли я напишу в следующем посте.

Анализ проблем и рисков

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

Что же возможно измерять? Что можно анализировать?

Чуть ранее я уже затронул тему измерений и анализа. Сейчас попробую углубиться

Не секрет, что в большинстве компаний есть так называемые проекты. Они могут быть маленькими, могут быть большими. Зачастую план проекта представляет собой диаграмму Ганта с обозначенными работами, которые необходимо выполнить, их длительностью и стоимостью, количеством ресурсов (людей и материалов), основные точки контроля (так называемые вехи). Каждый такой проект обладает рядом показателей, которые позволяют анализировать текущее состояние проекта. Возьмем, к примеру, такие показатели как «базовая стоимость запланированных работ» (BCWS – budgeted cost of work scheduled), «базовая стоимость выполненных работ» (BCWP – budgeted cost of work performed) и «реальная стоимость выполненной работы» (ACWP – actual cost of work performed). Что они нам дают? Сравнение BCWS и BCWP позволяет определить, нет ли отклонений относительно запланированного времени. Сравнение BCWP и ACWP дает информацию об отклонениях в рамках бюджета. Есть еще масса стандартных показателей, которые можно использовать в проектах. Но если приглядеться – что они нам дают? Они позволяют определить, что что-то идет не так (ну иногда лучше ). Но все это постфактум. Как правило – на этом этапе уже надо предпринять что-то экстренное, чтобы вернуть проект в русло.

Наверное, многие сталкивались с ситуацией, когда, к примеру, работник говорит, что для выполнения какой-то конкретной задачи необходимо столько-то времени. Мы, конечно же, ждем, что через этот промежуток получим результат. Не тут то было! Я редко встречался с такой ситуацией, чтобы обещанное было выполнено. Как правило, в процессе работы находятся какие-то странные проблемы, которые никто и никогда не рассматривал. Или же более важные задачи (проекты) которые надо было выполнить именно сейчас.

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

Допустим, у нас есть проект, состоящий из 5 задач. Каждая задача идет последовательно одна за другой. Общая длительность работ равна 100 часам. Первые две задачи у нас не имели рисков, а оставшиеся имеют запланированные проблемы. Теперь предположим, что у нас выполнено 3 из 5 задач и это потребовало 60 часов. По стандартным измерениям у нас нет отклонений, и мы выполнили 60% работы. Супер!!! Вот только одно но. На две оставшиеся задачи у нас возможно возникновение проблем и соответственно рисков. Что же тогда получается?

• Вся оставшаяся работа (100%) имеет проблемы и риски
• Мы выполнили только 20 часов с рисками из 60 (это получается 33%)
• Освоенные риски только 20 часов. Похоже – у проекта есть проблемы!

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

Но вернемся к нашим «проблемам».

Какие бы показатели нам помогли в нашей работе:

• Ну, во-первых это возраст проблем. Зачем это нам, возможно, спросите вы. Попробую ответить… Каждая проблема имеет дату ее обнаружения. Что будет, если с ней ничего не делать? Работники буду вынуждены делать предположения, каким образом решить эту проблему. И, как правило, выполнять эту работу с четом собственных предположений, которые могут быть не верны. Как результат – потраченное впустую время. Чем дольше проблема остается неразрешенной, тем больше рисков возникает. Если же сравнивать несколько проектов по возрасту проблем, можно выявить – куда нам следует больше приложить усилий.
• Процент оставшейся работы с проблемами и рисками. Как правило, это показатель позволят определить производительность на проекте, и направление усилий по разрешению проблем.
  
• Распределение проблем и рисков по времени проекта – считаю, что стоит обращать пристальное внимание. Как я обозначил в примере выполнения работ с наличием рисков – необходимо учитывать периоды их возникновения и их количество.
  

Если посмотреть на эти два графика, то можно заметить, что «Проект 1» более продолжительный чем «Проект 2». Зачастую менеджеры могут принять неправильное решение и уделять в такой ситуации больше внимания проектам подобным «Проект 1». Однако если посмотреть на время, требуемое для реализации задач с наличием рисков относительно общего времени задач, мы придем к иному выводу – «Проект 2» требует больше внимания, чем предполагалось ранее.

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

• Количество открытых проблем, распределенных по времени и типу
• Время, потраченное на решение проблемы
• Распределение проблем по важности и силе влияния на проект
• Распределение проблем по ответственным

Дают возможность получать:

• Количество времени, потраченное на решение проблем за период
• Распределение проблем по процессам
• Среднее время на решение проблем (в различных разрезах – по типу, по ответственным и т.д.)
• Сравнивать проекты по сложности и получать реальную производительность сотрудников
• Сигналы о наличии проблемных мест

Конечно, очень важно пользоваться с умом этими показателями и максимально комбинировать со стандартными показателями проектов. Все, наверное, помнят слова Натана Ротшильда ставшие крылатыми будучи произнесенными Уинстоном Черчилем – «Кто владеет информацией – владеет миром». И это действительно так. Чем больше у нас есть информации, тем больше простора для аналитического ума. Хотя, иногда самые безумные вещи делаются людьми на основе личных ощущений. Но кто знает, на сколько сильно повлияла окружающая ситуация на те самые чувства.

Да, и самое главное чтобы иметь информацию – ее надо собирать . Надо иметь базы проблем и рисков. Как ее построить – вариаций много и ИТ-шники знают как это делается. При особом желании – могу рассказать и показать на примере. Так что – спрашивайте