Записи с метками инициирование проекта

Продолжаю серию статей «Старт проекта». Первая статья здесь – Старт проекта. Как это делать?, а вторая здесь Старт проекта. Что такое Управление Конфигурациями?

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

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

Из-за чего возникают проектные риски?

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

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

Вот здесь ключевая идея – объяснить, а точнее замаскировать реакции на риски с помощью понятного для заказчика языка. Даже может быть категорически противопоказано употреблять термины и жаргон из мира разработки ПО.

Скажу по себе, хотя и был много лет назад разработчиком, но когда сейчас мне нужно узнать на концептуальном уровне о каком-то техническом решении, и я слышу в ответ слова: ADO, MVC, Hibernate, XML и т.п. у меня отключаются чувства восприятия . Т.е. объясняющий совершенно профессионально объясняет техническое решение, но в силу разрыва понимания технологии получается недопонимание. Такие же разрывы случаются между парами тестировщик – разработчик, разработчик – менеджер проекта и т.д. И это между людьми, работающими в одном бизнесе! А что же говорить о заказчике, который хочет, чтобы мы поняли его бизнес потребности, а мы тут к нему с рисками?

Давайте посмотрим на неудачный и приемлемый варианты общения с заказчиком на этапе инициирования проекта. Беру условие практического задания «Маскировка» из тренинга «Управление рисками: классика, agile, бизнес, заказчик».

Условие:

Новый проект, примерно на год на команду 10 человек. Срок сдачи фиксирован. Требования слабо определены. Сложная предметная область. Заказчик примерно понимает приоритеты функционала, находится в США. Нужно как можно раньше четко осознать что успеется за год, т.к. нужно делать анонс продукта, продвигать и т.п. Не хватает 4 разработчика в команде, срок найма 1-2 месяца. Архитектура неясна, ориентировочно 2 подхода с разными ожиданиями по производительности, расширяемости и срокам разработки. Заказчик хочет 1-2 раза в месяц демо и прогнозы успеваемости по срокам. Прямо сейчас заказчик выбирает между 3-я поставщиками, понятно хочется выиграть заказ. Заказчик не очень техничен и от слова «риск» может «съехать».

Неудачные фразы:

• «Мы будем работать по СКРАМу и наши разработчики вам на демо все будут рассказывать» – вы можете представить каким языком разработчики расскажут? Да и хочет ли не техничный заказчик так общаться?
• «Мы по ходу разработки будем брать задачи из бэклога и по берндауну будем понимать наше велосити, а если не будем что-то успевать, то низкоприоритетные функции делать не будем» – несмотря на развитие гибких подходов у заказчика может случиться «вынос мозга» от такого заявления. К тому же от хочет «как можно раньше четко осознать что успеется за год».
• «У нас есть риск недобора команды, поэтому мы нагоним потом либо овертаймами, либо сокращением бэклога» – во-первых, состав команды это не есть проблема заказчика, ему по существу все равно как вы будете делать проект. Во-вторых, от такого «подхода» сразу же веет непрофессионализмом.
• «У нас есть риск неправильного выбора технического решения, поэтому мы заложим 20% времени на рефакторинг или имплементацию другого решения» – в понимании заказчика вы не знаете как правильно спроектировать его продукт, да еще и будете переделывать за его же деньги. И что это за мифический резерв в 20% времени?

Приемлемые варианты:

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

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

Серия статей «Старт проекта» выходит в поддержку тренинга «Успешный старт проекта», в котором темы статей рассматриваются подробнее и с практическими заданиями.