“Синтетические” методы оценки программных проектов

Здравствуйте!

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

Далее я решил замахнуться на то, что до меня так никто и не осилил – освоить, внедрить и научить других, применять одну из методик численной оценки программных проектов с которыми нам приходится работать (особенно на этапах пресейла, когда высокой точности достигнуть невозможно в принципе). Необходимость наличия такой методики я описывал в пункте 4 предыдущей заметки. Вообще говоря, для некоторых новых проектов, которые по своей сути были очень похожи на те, что мы уже реализовывали ранее с командой, и в которых технологические риски были минимальны, я вполне точно делал и продолжаю делать оценки на основании исторических данных. Зная производительность конкретно взятой команды, а так же метрические показатели других схожих проектов соотнесённые с фактическими трудозатратами и длительностью, получается достаточно точно оценить будущий проект (итоговое расхождение оценки и фактических затрат зачастую равняется +/- 10%). Но для проектов, в которых планируется использовать новые технологии, команда для которых ещё не сформирована и при этом приходится вникать в предметную область бизнеса нового заказчика, такой подход не подходит по понятным причинам.

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

• начальные требования заказчика в том виде, в котором они к нам поступили, когда мы делали оценку;
• наша начальная оценка;
• реальные трудозатраты и время, потраченное на реализацию и закрытие проекта с разбивкой по задачам и людям;
• извлечённые уроки;

Каждый менеджер берёт по проекту (только не тому, над которым он сам работал) и на основании первоначальных требований от заказчика рассчитывают ожидаемую трудоёмкость по двум методикам: классический метод оценки по функциональным точкам и его модификация - Mark 2. Затем на очередной встрече PMO мы посмотрим как “синтетические” оценки соотносятся с оценками, сделанными нами ранее до начала проекта, а так же с фактическими результатами. По результатам такого сравнения и анализа того, как были сделаны “синтетические” оценки, можно будет откалибровать расчётные коэффициенты и, возможно, немного модифицировать методику под специфику наших проектов.

О результатах напишу позже.

Кстати, если у читателей данной заметки есть опыт применения такого рода методик оценки – поделитесь, пожалуйста, опытом, посоветуйте что-нибудь – буду премного благодарен =)

Офис управления проектами - начало

Здравствуйте!

Совсем недавно меня назначили руководителем офиса управления проектами… В связи с этим передо мной возникла задача построения самого офиса управления проектами, т.к. до сих пор такой структуры в нашей компании не было. Исходя из всего того, что я читал про офис управления проектами (project management office или кратко PMO) я начал по методу набегающей волны разрабатывать планы по построению этого самого PMO внутри нашей компании.

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

1. Улучшить процедуру планирования ресурсов компании на ближайший месяц.
   Т.к. часть проектов работает по схеме fixed price, а часть по time and material, необходимо очень чётко понимать, когда, кто и сколько будет работать на каком проекте и кто будет за него платить.
   
   
2. Собрать метрики по всем существующим проектам в одно место и привести их, по возможности, к единому виду.
   Это значительно упростит и ускорит их использование при оценке новых проектов (пресейлы), а так же при извлечении уроков по проекту после его завершения.
   
   
3. Наладить надёжный процесс перехода работников из проекта в проект (от менеджера к менеджеру), что бы исключить ситуации, при которых разработчики, аналитики, тестировщики и т.д., закончившие работать над задачами в одном проекте, «простаивают» какое-то время из-за того, что не знают, чем им дальше заниматься. А такое хоть и редко, но случается.


4. Создать единую для компании методологию для оценки новых проектов.
   Это нужно, прежде всего, для того, что бы на этапе пресейла минимизировать время, которое затрачивается ведущими разработчиками, архитекторами и менеджерами для оценки потенциального проекта. Порой на это тратится неоправданно много времени.
   
   
5. Наладить постоянный надёжный процесс обмена положительным и отрицательным опытом между всеми командами в компании.
   Сейчас некоторые менеджеры после сдачи проекта проводят, как это называется в SCRUM’е, demo-показы, на которые приглашаются все желающие и на которых показывается продукт, над которым работала команда, рассказывается вкратце о его функционале, применённых технологиях, об успешном опыте и возникших проблемах. Думаю внедрить эту практику во всех командах.

И далее уже идёт список задач более общего характера и менее высокого приоритета.

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

Если у вас есть опыт по решению проблем, описанных мной в этих пяти пунктах – пишите, буду рад советам!

Да, забыл сказать, речь идёт о небольшой (менее 50 чел.), но давно работающей и стабильной компании с проектной структурой. Поэтому все в компании являются сторонниками небольших, но постоянных, изменений, нежели глобальных реформ за короткое время. Такой подход позволяет быстро вносить изменения в процессы на основании постоянно получаемой обратной связи, а так же достаточно быстро и эффективно подстраиваться под потребности заказчика.

Почему важно понимать бизнес заказчика.

Привет!

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

Уже больше года я руковожу рядом проектов в рамках одной программы, реализуемой для крупной российской компании, услугами которой пользуется, наверное, пятая часть населения страны. Один из проектов в рамках этой программы – разработка web-сайта для миллионной аудитории клиентов данной компании. Бизнес заказчиков этого сайта несколько: отдел маркетинга, отдел продаж, отдел работы с партнёрами компании и верхушка в лице нескольких заинтересованных лиц. И у всех этих заказчиков свои бизнес цели и, соответственно, свои требования к сайту и его функционалу. На выявление и документацию только бизнес требований всех заинтересованных сторон ушло два месяца очень и очень плотной работы – постоянные встречи, опросы, интервью, формулировка всего услышанного на бумаге и согласование. Я, как менеджер этого проекта, старался присутствовать на всех подобных встречах. Когда, наконец, все требования бизнеса были документированы и согласованы начался этап сбора функциональных и нефункциональных требований, но это отдельная история.

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

Через пару дней представитель отдела работы с партнёрами компании нашего заказчика звонит и говорит, что 1 ноября сайт должен работать кровь из носу и (внимание!!!) содержать новую функциональность, которая критична для партнёров. И сделать это нужно именно к 1 ноября, т.к. уже заключены ряд договоров с партнёрами компании. И в этих договорах прописаны пункты, согласно которым компания заказчика должна 1 ноября предоставить определённые сервисы клиентам партнёров посредством web-сайта, иначе – штрафы. С таким подходом (сначала заключаем договоры с указанием сроков, потом ставим в известность исполнителей), я думаю, встречались многие.

Что тут началось… Спонсор проекта со стороны заказчика звонит моему руководству и говорит, что 1 числа сайт должен работать и точка! Моё начальство звонит мне, предлагает взять в команду ещё людей, порвать тельняшки, ни шагу назад, за нами Москва и т.д. и за оставшийся месяц реализовать новую функциональность, провести полный цикл тестирования и установить сайт на пока отсутствующее железо =) Одним словом, запахло управленческим беспределом.

На предложение добавить людей в команду разработки сайта я сразу сказал “НЕТ!”. Согласно правилу Брукса, уже подтверждённому и моим опытом тоже, инъекция “неподготовленных” людей в проект разработки программного обеспечения, находящийся в завершающей фазе, лишь усугубляет ситуацию со временем окончания проекта. Это факт! Предложение “порвать тельняшки” в данном случае меня тоже не вдохновило, т.к. тельняшки рвать имеет смысл тогда, когда и менеджер и команда на 100% уверены в том, что после трёх недель работы по 14 часов в сутки они наверняка успеют и сделают то, что удовлетворит и их (команду разработки) и заказчика. Иначе, если три недели пота и крови заканчиваются разочарованием заказчика из-за нереализованных требований и неудовлетворённостью команды, общий моральных дух команды резко падает, желания работать и мотивация снижается ниже плинтуса. Хороший PM, на мой взгляд, никогда не должен допускать такой ситуации, т.к. люди в конечном итоге всегда важнее любых сроков.

Я сел и стал думать, что можно сделать, имея жёсткие временные ограничения, новые требования к функционалу и свободные ресурсы, не занятые на разработке сайта, но и не имеющие представления о проекте. В итоге, двигаясь в своих размышлениях снизу вверх, я дошёл до того, с чего, по-хорошему, нужно было начинать с самого начала. С бизнес требований данного конкретного заказчика. И подумав о бизнес целях, ещё раз их проанализировав, я понял, что отделу работы с партнёрами нужен на самом деле не сам сайт целиком, со всем его наполнением и возможностями, а только небольшая часть функционала, покрывающая потребности данного бизнес заказчика. Я прикинул, что если собрать, как пишет ДеМарко, “команду тигров” (команда из двух-трёх человек, способных “порвать” всё что угодно – реализовать любое сложное техническое решение в кратчайшие сроки =), то вполне можно реализовать до нужного срока отдельный сайт с ограниченным функционалом, который полностью покроет требования заказчика. Таким образом, минимизируются риски срывов сроков разработки, риски связанные с дальнейшими возможными проблемами с поставкой оборудования (т.к. этот небольшой сайт можно будет развернуть на существующем железе) и с переутомлением команды, занимающейся разработкой основного сайта. Красота =)

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

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

Лишь понимание того, для чего именно в конечном итоге нужен web-сайт отдельно взятому бизнес заказчику, позволило мне принять оптимальное, на мой взгляд, решение.

А у вас есть usability-аналитик?

Привет!

Случилось так, что у нас в компании временно не стало usability-аналитика (человека, проектирующего интерфейс взаимодействия пользователя и разрабатываемого продукта). Аналитика не стало (он жив, просто сменил место работы =), но проекты идут своим чередом и запросы на изменение текущих требований и внешнего вида разрабатываемых продуктов продолжают приходить от заказчика, как и прежде. Раньше я, как менеджер проектов, в которых всё это происходит, регистрировал запрос, проводил первичный анализ, ставил задачу usability-аналитикам, затем принимал работу у аналитиков и вместе с командой разработчиков оценивал трудозатраты на реализацию доработки или изменения, а затем согласовывал оцененное изменение с заказчиком. Сейчас, когда не стало единого источника экспертного мнения относительно пользовательского интерфейса и взаимодействия пользователя с системой, всё изменилось.

Сейчас, принимая запрос на изменение (change request) от заказчика, я сам занимаюсь usability-анализом, постановкой задачи дизайнерам (раньше с дизайнером взаимодействовал usability-аналитик), аудитом результатов его работы и конечной приёмкой работ дизайнера.

У разработчиков в процессе их работы так же возникают вопросы относительно внешнего вида частей системы, которые по какой-то причине были недостаточно подробно описаны в описании содержания работ (спецификация, ТЗ). Раньше они шли с этими вопросами к usability-аналитикам, которые, дополняли рабочую спецификацию и обращались к менеджерам, что бы те согласовали новые прототипы с заказчиком, после чего доработанный документ передавался назад разработчикам. Сейчас разработчики идут с этими вопросами к менеджеру или же сами начинают додумывать интерфейс и варианты использования системы.

Что происходит, когда программисты проектируют интерфейс взаимодействия человек-машина хорошо и печально известно. Когда этой работой занимается менеджер проекта – результат не столь плачевен, т.к. менеджер ориентирован (должен быть) на удовлетворение заказчика. Но менеджеры всё же не аналитики и результат моих трудов, как usability-аналитика тоже на мой взгляд не удовлетворителен, даже не смотря на то, что мне часто приходилось выступать в роли не только бизнес- но и usability-аналитика. Проектирование взаимодействия, так же как и проектирование архитектуры системы, требует от человека сосредоточенности, погружения в т.н. “поток”. Только в таком состоянии приходят по-настоящему блестящие идеи и решения.

У руководителей проектов, так же как у программистов, дизайнеров и аналитиков, так же есть состояние “потока”, в котором их производительность и результативность сильно возрастает, но это совсем не тот “поток”, который нужен для работы над одной конкретной задачей. У меня в ежедневнике на каждый день записано десяток задач, каждую секунду в голове крутится ещё 3-4 и ежечасно возникают задачи, которые невозможно запланировать, но нужно решать прямо сейчас, не откладывая. В таком режиме, когда переключение между задачами происходит иногда по три раза в минуту, спроектировать действительно хороший сценарий взаимодействия невозможно.

Я знаю, что во многих компаниях считается, что иметь аналитика пользовательского интерфейса и usability-аналитика – это роскошь. Я сам работал в таких компаниях, где менеджерам приходилось самостоятельно проводить бизнес-анализ, затем анализ функциональности, затем usability-анализ и анализ внешнего вида системы, прорисовкой прототипов рабочих экранов и написанием спецификаций. Я сам всем этим занимался и знаю, что все эти задачи менеджер может сделать хорошо… но не блестяще. Сейчас мне крайне некомфортно, если в команде проекта нет выделенного аналитика, т.к. я точно знаю, что удобство использования будущего продукта, будь то сайт или десктопное приложение, значительно ухудшится при отсутствии такого рода эксперта. А значит, понизится лояльность конечного пользователя и заказчика, что с финансовой точки зрения гораздо “дороже” для компании, чем один эксперт в области usability в штате или на контракте.

Очень хорошо, на мой взгляд, проблемы отсутствия проектирования взаимодействия человек-система описаны в книге Алана Купера “Психбольница в руках пациентов”, которая была написана в 1998 году, но которая останется актуальной ещё очень-очень долго. Всем менеджерам и техническим директорам рекомендую.

Вопрос к тем, кто дочитал до конца – как у вас в компании обстоят дела с разного рода аналитикой? Кто ей занимается – специально обученные люди (эксперты-аналитики) или те, на кого падёт перст начальства или у кого есть время?

 

Ещё одна причина для проведения ежедневного SCRUM-митинга

Привет!

В своих текущих проектах, количество разработчиков в которых не превышает пяти человек, я применяю один из инструментов, позаимствованных из методологии SCRUM. Это, так называемые, SCRUM-митинги (SCRUM-meetings).

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

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

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

Таким образом, правильно проведённая короткая встреча в начале каждого рабочего дня приносит в разы больше пользы, чем утомительно-скучное долгое заседание по пятницам, на котором, как правило, 80% участников стараются не заснуть.

Всё вышесказанное относится к небольшим командам (до 7-9 человек по моему опыту). Если участников становится больше, то временные “накладные расходы”, возникающие при таких ежедневных встречах, могут свести на нет положительный эффект от них.

Одним словом, пробуйте, сравнивайте, выбирайте!

P.S. Мы свои SCRUM-митинги проводим сидя, а не стоя, как рекомендуется в литературе по SCRUM =)

Удачи и хороших выходных!

Пятница – день отчётов

Привет!

Сегодня пятница. У меня пятница - день отчётов.

Я сейчас руковожу одновременно четырьмя “горячими” проектами. Под термином “горячие” я понимаю проекты, по которым ведётся очень активная деятельность, на которые направлены пристальные взоры начальства и заказчиков. По всем четырём проектам заказчики и начальство требуют от меня разного рода отчётность с разной периодичностью. По пятницам я всегда (ну… почти всегда) стараюсь выдавать заказчику отчёты в стандартной форме. Я верю в то, что периодическая отчётность является очень полезной практикой (даже если эти отчёты читает только менеджер со стороны заказчика) и вообще улучшает карму любого PM’а =)

Три из четырёх проектов я веду (пытаюсь, во всяком случае) по методологии SCRUM – очень много запросов на изменения от заказчика, очень короткие итерации, заказчик максимально вовлечён в процесс. По этим трём проектам заказчик требует минимум отчётности (или не требует вовсе), т.к. он и так постоянно в курсе того, что происходит, знает, куда уходит время и деньги. Именно поэтому по этим трём проектам отчётом, как правило, является краткое письмо, резюмирующее проделанные за неделю работы или даже пятиминутный разговор по телефону или Skype’у.

Четвёртым проектом я управляю по классической методологии описанной в PMBOK – проект разбит на фазы, объём работ на каждую фазу зафиксирован, запросы на изменения (change requests) обрабатываются согласно ранее принятому регламенту, форма отчётности по утилизации ресурсов зафиксирована... На этом проекте заказчик не так активно вовлечён в процесс разработки продукта, поэтому количество информации в отчётах о прогрессе проекта должно быть больше, нежели в предыдущих трёх.

Сам отчёт состоит из двух частей – календарный план проекта (в формате MS Project) и собственно описание текущего статуса (в MS Word).

С календарным планом в MS Project все, в общем-то, понятно, а вот про описание статуса стоит поговорить.

Практика показывает, что чем меньше отчёт, тем выше вероятность того, что заказчик вообще будет его читать. Поэтому я умещаю все отчёты на одну страницу, при этом пишу всё предельно простым языком. Отчётность по освоенному объёму (earned value) – это очень здорово, но, если честно, я не встречал ещё заказчиков, которые требовали бы такой отчётности и понимали разницу, к примеру, между CPI и SPI. Освоенный объём можно и нужно использовать, но до заказчика лучше доносить фразу “Мы опережаем график работ на 10% от планируемого!!!”, чем “Вууухуу! На этой неделе SPI = 1.1!!!” =)

Сам лист отчёта я разбиваю на четыре части:

1. Шапка, в которой описано по какому проекту данный отчёт, кто его составил, когда, и за какой период.
   
2. Раздел “Прогресс проекта за отчётный период”, в котором обычными словами описываю, что именно произошло в проекте за отчётный период. В этом разделе я пишу только то, что может быть интересно и полезно заказчику и что он сможет понять. Т.е. фраза “Реализована страница, а так же соответствующий функционал, позволяющий пользователям входить в систему, используя свой логин и пароль” предпочтительнее, чем “Реализовали DAL и GUI для авторизации”.
   
3. Раздел “Текущие вопросы и проблемы. Способы их решения/предотвращения”. В данном разделе озвучиваются произошедшие риски, описываются их последствия, а так же озвучиваются наиболее актуальные угрозы и благоприятные возможности (threats and opportunities) и способы их предотвращения и усиления соответственно.
   
4. Раздел “Последующие шаги на следующий отчётный период” описывает планы на следующий отчётный период.

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

Всем удачного окончания рабочей недели!

Ежедневные митинги в стиле SCRUM

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

Так вот, на проекте работают два разработчика, архитектор, тестировщик и я, менеджер проекта и локализатор в одном лице =)

Решил попробовать на этом проекте методику SCRUM-митингов. Т.е. ежедневных собраний, продолжительностью не более 15 минут, на которых каждый участник команды отвечает на три вопроса: что было сделано вчера, что будет сделано сегодня и какие имеются проблемы. Я не ожидал, что эти собрания окажутся настолько эффективными. Раньше, в других проектах, когда одних разработчиков было 5-7 человек, плюс тестировщики, аналитики, архитектор и дизайнер – такие собрания были невозможны, т.к. на это уходило бы масса времени. А при маленькой команде – это то, что надо. Все проблемы вскрываются сразу же, нет такого, что разработчик сидит, пыхтит над проблемой, которая возникла у него во вторник и о которой все узнают только в пятницу на еженедельном статус митинге. К тому же о всех флуктуациях требований к реализуемой функциональности все участники проекта узнают как только они появляются.

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

Очень рекомендую прослушать подкаст (podcast) Рона Хологана, PMP (Ron Holohan, PMP) с сайта http://pm411.org/ под названием “Managing effective meetings (part 2 of 2)”, в котором он подробно рассказывает о такого рода собраниях. Очень рекомендую!

Зелёный свет

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

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

Ситуация усугублялась ещё тем, что в проекте задействован один подрядчик, от которого очень многое зависит. Подрядчик очень большой и очень медлительный. Срыв сроков для него – не вопрос. В том числе и поэтому я заложил достаточно много времени в раздел Риски.

В итоге, обдумав и оценив ситуацию, заказчик принял решение:
1. Сделать нас генеральными подрядчиками.
2. Увеличить бюджет в несколько раз.
3. Бюджет теперь будет выделяться по схеме “time and material”, т.е. не за человеко-часы, а за кол-во людей занятых в проекте умноженное на их полное рабочее время. Это очень радует! =)
4. Теперь ответственность за все проекты, реализуемые в рамках данной программы, лежит на нас.

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

Такие вот дела… =)

“Это НЕПРИЕМЛЕМО!!!”

Сегодня подготовил и отправил менеджеру заказчика календарный план первого этапа проекта. Объём работ был согласован, состав команды проекта утверждён, дело оставалось, по сути, за продолжительностью работ. Ok, составил график, согласовал и отредактировал с командой, всё отлично. Отсылаю менеджеру со стороны заказчика и через 2 минуты получаю в скайп: “Это НЕПРИЕМЛЕМО!”

Вот так вот. Никого не интересует реальность. Народ хочет пожить сказкой, а когда показываешь реальность, тебе говорят, что это неприемлемо =) Забавно, это уже не первый мой проект, который я оцениваю, и я нутром чую, что та дата, которая указана в колонке Finish – реальна процентов на 70. Т.е. даже с учётом летних отпусков разработчиков, задержек со стороны подрядчиков и наших задержек, с учётом основных рисков и того, что мы до сих пор не учли и не учтём - мы таки можем успеть к указанной в плане дате, если хорошо поработаем. Даже неумолимая статистика, которую я веду последние два года по всем своим проектам (собираю метрики до и после), говорит о том, что вероятность успеть раньше этого срока – крайне невелика.

И вот, блин-горелый, в который раз первые слова, которые приходится слышать после обнародования действительно реального плана – это “Это НЕПРИЕМЛЕМО!!!”.

Назначил на понедельник встречу по поводу обнародованного плана. Даже интересно, согласится ли заказчик с указанной датой, увеличит бюджет или урежет функциональность… Время покажет ;)