Добрый день. Вопрос №1 Какова стоимость получения диплома о мини-МБА по данному курсу? Или ориентироваться на указанную на сайте? Вопрос №2 Возможно ли начать обучение без потери результатов, не отправив документы на зачисление, а отправку выполнить позже? |
Обзор методологии
Аспекты
Методология MSF - больше чем набор правил, которым вы должны слепо следовать. Она призвана привить культуру, способствующую реализации успешных проектов. Аспект - это совокупность показателей, определяющая, как отдельный участник проекта оценивает ту или иную ситуацию и реагирует на нее. Участники проекта от его начала до завершения должны принимать во внимание аспекты при принятии решений, расстановке приоритетов, представлении своих интересов и при взаимодействии с другими участниками команды и прочими заинтересованными лицами. В MSF представлено девять аспектов.
Понимание практической ценности
Первый аспект акцентирует внимание участников проекта на его практических результатах. Каждая программная система создается с конкретной целью, например для решения некоторой проблемы в бизнесе. При построении программных систем, особенно крупных, они испытывают на себе множество воздействий, часть из которых требует в ответ приложения значительных усилий. В конечном же счете программный проект оценивается по его полезности для бизнеса. Каждый участник должен всегда помнить о практических результатах и должен быть нацелен на их достижение.
Представление интересов
С программными проектами обычно связаны многие заинтересованные лица со своими интересами, например, заказчикам нужна хорошо работающая система. Можно также представить неодушевленные "заинтересованные лица", например саму разрабатываемую систему. Система может быть рассчитана на работу в течение тридцати лет, а может использоваться только тридцать минут. Системы, рассчитанные на длительное использование, разрабатываются дольше. Каждая из заинтересованных сторон (будь то люди или нет) в проекте должна быть представлена защитником своих интересов. Каждому участнику проекта важно понимать, чьи интересы он представляет. Следует помнить, что модель представления интересов - это совокупность ограничений, поэтому для получения оптимальных результатов зачастую неизбежны компромиссы.
Гордость за участие в проекте
Чувство гордости за участие в проекте - важный фактор для получения качественного продукта. Из чувства гордости вырастает мотивация и ответственность за выполнение проекта. Разработка ПО сродни искусству, и качественные системы - любимые детища их создателей. Комфортные условия труда, доверие, возможности роста, мотивированные, профессиональные люди - все это составляющие, необходимые для создания качественного ПО. Поддержание чувства гордости за участие в проекте - задача и участников проекта, и организации. Применяйте определение общих затрат в проекте по принципу "от частного к общему", дайте проекту кодовое имя и четко идентифицируйте команду проекта - это поможет поддерживать чувство гордости. В MSF представители всех ролей ответственны за создание продукта самого высокого качества.
Своевременное выполнение своих обязанностей
Многие задачи при разработке ПО связаны между собой. Бывают моменты, когда мы не можем выполнить свою работу самостоятельно, без участия коллег. Для эффективной работы нужно своевременно решать задачи, от которых зависит деятельность других участников проекта, и держать их в курсе текущего состояния дел. Вы должны быть надежным и заслуживающим доверия партнером для своих коллег.
Видение системы в целом
При работе над конкретной частью системы есть риск "не увидеть за деревьями леса". Важно не только представлять свой отрезок работы, но и понимать, как ваша деятельность отражается на конечном продукте. Надо уделять больше внимания итогу, а не процессу. Это не значит, что процесс плох или не важен: процесс не самоцель, а средство достижения конечного результата. Нужно четко понимать, зачем вы выполняете то или иное действие и как результаты вашей работы интегрируются в общее решение. Думайте о том, что нужно для реализации системы, не вдаваясь в мелкие детали. Регулярно - не только во время плановых встреч - общайтесь с другими участниками команды.
Равнозначность участников
Аспект равнозначности участников команды означает их равноправие и равноценность, независимо от их ролей и представляемых ими интересов. Он может быть обеспечен за счет отсутствия ограничений в коммуникациях и прозрачности проекта. Этот аспект также предполагает взаимоуважение и заботу о каждом члене коллектива. Атмосфера взаимоуважения - необходимое условие максимальной эффективности в работе любой команды: она обеспечивает высокую коллективную ответственность, эффективные коммуникации и командный дух. Для успешной работы в команде равнозначных участников представители всех ролей должны заботиться о качестве создаваемого продукта, действовать как представители интересов заказчика и понимать решаемую бизнес-проблему.
Хозяйский подход
К ресурсам проекта, корпоративным и вычислительным ресурсам нужно относиться по-хозяйски. Такой подход нужно применять во всем - от использования эффективных методов управления проектом до оптимизации системных ресурсов. Дальновидным шагом будет снабжение описателей ошибок подробнейшими данными, которые помогут кому-то в дальнейшем. Также полезно давать точную оценку трудозатрат на выполнение задач разработки и тестирования. Существующие ресурсы должны использоваться везде, где это возможно.
Непрерывное обучение
Готовность к обучению включает в себя постоянное самосовершенствование участника команды путем накопления знаний и обмена ими с другими. Надо учиться на чужом опыте: не повторять ошибок и применять успешные подходы. В графике проекта нужно предусмотреть время для обучения членов команды, анализа текущего состояния дел и проделанной работы. Кроме того, важной индивидуальной чертой каждого участника команды должно быть стремление к обмену знаниями с другими.
Приверженность качеству
Аспект приверженности качеству предполагает такой подход к планированию и реализации решения, который учитывает все потребности конечного пользователя. При этом качество в таких областях, как производительность или безопасность, должно учитываться на всех этапах разработки. Без такого подхода к обеспечению качества систему, как правило, создают, делая неявные допущения о ее поведении. В результате функционирование системы не удовлетворяет заказчика. Для обеспечения качества нужно видеть систему в целом и не полагаться на неявные допущения, а руководствоваться явно сформулированными требованиями к качеству.