Lessons Learned - раскрой свой опыт управления проектами | Успешное управление проектами

Приобретение и распространение опыта управления проектами

Вход в систему

Регистрация

Подписка:

QR код подписки

 QR-Code rss feed

Использование материалов

Коллеги, перед использованием материалов данного сайта, пожалуйста, ознакомьтесь с
Правилами использования материалов сайта

Подписка на обновления

Коллеги, если вы желаете быть в курсе обновлений сайта, вы можете оформить бесплатную подписку. Это занимает 1 минуту. Далее, описаны способы подписки.

Опрос №2. Образование

Опрос об образовании в управлении проектами. Пожалуйста, заполните анкету (время заполнения 1-2 минуты).

Общий опрос №1:

Мы проводим небольшое исследование. Пожалуйста, помогите нам, заполните опросник (время заполнения опросника 1-2 минуты).

Изученный урок №121. Тщательно планируйте время на тестирование при разработке мобильных приложений

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

 
Вывод:

Изученный урок №120. Подключайте отдел тестирования к проекту на этапе создания технического задания

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

Изученный урок №119. Привлекайте квалифицированные внешние ресурсы на критичные работы

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

Изученный урок №118. Согласовывайте протокол встречи со всеми участниками

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

Изученный урок №117. Проверяйте наличие политик, шаблонов, процедур холдинга, влияющих на проект

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

Подписаться по email:

 

Ваш email:

Delivered by FeedBurner

 

 Ваш email:

Посетите Каталог Maillist.ru.

 

Напишите нам:

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