Управление проектами
Управление проектами – это область деятельности, в ходе которой определяются и достигаются четкие цели при балансировании между объемом работ, ресурсами (деньги, труд, материалы, энергия, пространство и др.), временем, качеством и рисками в рамках некоторых проектов. Ключевым фактором успеха проектного управления является наличие четкого заранее определенного плана, минимизации рисков и отклонений от плана, эффективного управления изменениями.
В основе современных методов управления проектами лежат методики структуризации работ и сетевого планирования, разработанные в конце 50-х годов XX века в США.
Классическая форма Тройственной Ограниченности
Описывает баланс между содержанием проекта, стоимостью, временем и качеством. Качество было добавлено позже, поэтому изначально именована как тройственная ограниченность. Проект должен протекать и достигать финала с учетом определенных ограничений. Классически эти ограничения определены как содержание проекта, время и стоимость. Они также относятся к Треугольнику Управления проектами, где каждая его сторона представляет ограничение. Изменение одной стороны треугольника влияет на другие стороны.
Рис 1. «Треугольник управления проектами»
Ограниченность времени определяется количеством доступного времени для завершения проекта. Ограниченность стоимости определяется бюджетом, выделенным для осуществления проекта. Ограниченность содержания определяется набором действий, необходимых для достижения конечного результата проекта. Эти три ограниченности часто соперничают между собой. Изменение содержания проекта обычно приводит к изменению сроков (времени) и стоимости. Сжатые сроки (время) могут вызвать увеличение стоимости и уменьшение содержания. Небольшой бюджет (стоимость) может вызвать увеличение сроков (времени) и уменьшение содержания.
Подходы
Предположение о неограниченности ресурсов, критичен только срок выполнения. Метод PERT, Метод критического пути
Предположение о критичности качества (под качеством здесь понимается полнота удовлетворения потребностей, как известных, так и неизвестных заранее, часто создаваемых выходом нового продукта). Метод Гибкая методология разработки
Предположение о неизменности требований и низких рисках. Классические методы PMBOK, во многом опирающийся на модель водопада
Предположение о высоких рисках проекта. Метод Инновационные проекты (стартапы)
Варианты нейтральных (сбалансированных) подходов:
Акцент на взаимодействие исполнителей. Метод PRINCE2
Акцент на взаимодействие процессов. Метод Process-based management
Project Evaluation and Review Technique
Техника оценки и анализа, которая используется при управлении проектами. Это способ анализа задач, необходимых для выполнения проекта. В особенности, анализа времени, которое требуется для выполнения каждой отдельной задачи, а также определение минимального необходимого времени для выполнения всего проекта.
Этот подход был разработан главным образом для упрощения планирования на бумаге и составления графиков больших и сложных проектов. Он предназначен для очень масштабных, единовременных, сложных, нерутинных проектов. Метод подразумевал наличие неопределённости, давая возможность разработать рабочий график проекта без точного знания деталей и необходимого времени для всех его составляющих.
Самой популярной частью PERT является Метод критического пути, опирающийся на построение сетевого графика (сетевой диаграммы PERT).
В основе метода лежит определение наиболее длительной последовательности задач от начала проекта до его окончания с учетом их взаимосвязи. Задачи лежащие на критическом пути (критические задачи) имеют нулевой резерв времени выполнения и в случае изменения их длительности изменяются сроки всего проекта. В связи с этим при выполнении проекта критические задачи требуют более тщательного контроля, в частности, своевременного выявления проблем и рисков, влияющих на сроки их выполнения и, следовательно, на сроки выполнения проекта в целом. В процессе выполнения проекта критический путь проекта может меняться.
Гибкая методология разработки
Agile software development — это концептуальный каркас, в рамках которого выполняется разработка программного обеспечения. Существует несколько подобных методик.
Каждая итерация сама по себе выглядит как программный проект в миниатюре, и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, кодирование, тестирование и документирование. Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается, что гибкий программный проект готов к выпуску в конце каждой итерации. По окончании каждой итерации, команда выполняет переоценку приоритетов разработки.
Agile-методы делают упор на непосредственное общение лицом к лицу. Большинство agile-команд расположены в одном офисе, иногда называемом bullpen. Как минимум, она включает и «заказчиков» (product owner - заказчик или его полномочный представитель, определяющий требования к продукту; эту роль может выполнять менеджер проекта, бизнес-аналитик или клиент). Офис может также включать тестировщиков, дизайнеров интерфейса, технических писателей и менеджеров.
Основной метрикой agile-методов является рабочий продукт. Отдавая предпочтение непосредственному общению, agile-методы уменьшают объем письменной документации, по сравнению с другими методами. Это привело к критике этих методов, как недисциплинированных.
Экстремальное программирование
Двенадцать основных приёмов экстремального программирования (по первому изданию книги Extreme programming explained) могут быть объединены в четыре группы:
Короткий цикл обратной связи (Fine scale feedback)
Разработка через тестирование (Test driven development)
Игра в планирование (Planning game)
Заказчик всегда рядом (Whole team, Onsite customer)
Парное программирование (Pair programming)
Непрерывный, а не пакетный процесс
Непрерывная интеграция (Continuous Integration)
Рефакторинг (Design Improvement, Refactor)
Частые небольшие релизы (Small Releases)
Понимание, разделяемое всеми
Простота (Simple design)
Метафора системы (System metaphor)
Коллективное владение кодом (Collective code ownership) или выбранными шаблонами проектирования (Collective patterns ownership)
Стандарт кодирования (Coding standard or Coding conventions)
Социальная защищенность программиста (Programmer welfare):
40-часовая рабочая неделя (Sustainable pace, Forty hour week)
Тестирование
В XP особое внимание уделяется двум разновидностям тестирования:
тестирование модулей (unit testing);
приемочное тестирование (acceptance testing).
Разработчик не может быть уверен в правильности написанного им кода до тех пор, пока не сработают абсолютно все тесты модулей разрабатываемой им системы. Тесты модулей позволяют разработчикам убедиться в том, что их код работает корректно. Они также помогают другим разработчикам понять, зачем нужен тот или иной фрагмент кода и как он функционирует. Тесты модулей также позволяют разработчику без каких-либо опасений выполнять рефакторинг (refactoring).
Для XP более приоритетным является подход, называемый TDD (Test Driven Development) - сначала пишется тест, который не проходит, затем пишется код, чтобы тест прошел, а уже после делается рефакторинг кода.
Scrum
Scrum — методология управления разработкой информационных систем для гибкой разработки программного обеспечения. Scrum чётко делает акцент на качественном контроле процесса разработки.
Scrum — это набор принципов, на которых строится процесс разработки, позволяющий в жёстко фиксированные небольшие промежутки времени (спринты от 2 до 4 недель) предоставлять конечному пользователю работающее ПО с новыми возможностями, для которых определён наибольший приоритет. Строго-фиксированная небольшая длительность спринта придаёт процессу разработки предсказуемость и гибкость.
Действующие лица:
ScrumMaster — тот, кто ведёт Scrum митинги и следит, чтобы при этом соблюдались все принципы Scrum (роль не предполагает ничего кроме корректного ведения самого Scrum-а, руководитель проекта скорее относится к Product Owner и не должен являться ScrumMaster).
Владелец Продукта (Product Owner) — человек, который представляет интересы конечных пользователей и других заинтересованных в продукте сторон.
Команда (Scrum Team), состоящая как из разработчиков, так и из тестировщиков, архитекторов, аналитиков и т. д. (при этом размер команды в идеале составляет 7±2 человека). Команда является единственным полностью вовлечённым участником разработки, и отвечает за результат как единое целое. Никто кроме команды не может вмешиваться в процесс разработки на протяжении спринта.
На чем основан скрам:
Курица говорит свинье: «Давай откроем ресторан!» Свинья смотрит на курицу и отвечает: «Хорошая идея, и как мы его назовем?» Курица подумала и говорит: «Почему бы не назвать 'Яичница с беконом'?». «Так не пойдёт», — отвечает свинья, «ведь тогда мне придётся полностью посвятить себя проекту, а ты будешь вовлечена только частично».
Свиньи полностью включены в проект - Владелец Продукта (Product Owner), Руководитель (ScrumMaster), Команда (Scrum Team)
«Цыплята» - Пользователи (Users), Клиенты, Продавцы (Stakeholders), Эксперты-консультанты (Consulting Experts).
Водопадная модель
Каскадная модель (waterfall model) — модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки. В качестве источника названия часто указывают статью, опубликованную Уильямом Ройсом в 1970 году; забавно, что сам Ройс использовал итеративную модель разработки.
Преимущества итеративного подхода:
снижение воздействия серьезных рисков на ранних стадиях проекта, что ведет к минимизации затрат на их устранение;
организация эффективной обратной связи проектной команды с потребителем и создание продукта, реально отвечающего его потребностям;
акцент усилий на наиболее важные и критичные направления проекта;
непрерывное итеративное тестирование, позволяющее оценить успешность всего проекта в целом;
более равномерная загрузка участников проекта;
реальная оценка текущего состояния проекта и, как следствие, большая уверенность заказчиков и непосредственных участников в его успешном завершении.
затраты распределяются по всему проекту, а не группируются в его конце.
Стартапы
Старта́п — компания с короткой историей операционной деятельности. Как правило, такие компании созданы недавно, находятся в стадии развития или исследования перспективных рынков. Термин стартап стал популярным во времена пузыря доткомов, когда было создано большое количество интернет-компаний. Новые проекты в отраслях высоких технологий часто называют хайтек стартап. Следует отметить, что хотя этот термин можно применять ко всем сферам деятельности, преимущественное распространение он получил в сфере IT и интернет-проектов.
Стадии развития
PRE — STARTUP стадия
Pre-seed и seed стадия (pre- & seed stage)
Прототип (prototype)
Работающий прототип (working prototype)
Альфа-версия проекта или продукта (alpha)
Закрытая бета-версия проекта или продукта (private beta)
Публичная бета-версия проекта или продукта (public beta)
ЗАПУСК ПРОЕКТА в эксплуатацию или продукта в производство
Запуск, или ранняя startup-стадия (launch, or early startup stage)
Стадия startup (startup stage)
Работа с первыми клиентами, или поздняя startup-стадия (first clients, or late startup stage)
POST STARTUP стадия
Стадия роста (growth stage)
Стадия расширения (expansion stage)
Стадия выхода (exit stage)
Pre-seed стадия: стадия, когда есть идея что нужно рынку и потребителям, но четкого представления о том, как ее следует реализовывать технически (техническое задание) и как ее следует развивать, чтобы она приносила прибыль (бизнес-план), еще нет, или есть, но в самом общем виде.
Seed стадия: стадия изучения рынка, составления и реализации технического задания, составления бизнес-плана, тестирование созданного проекта или продукта, подготовка к запуску проекта, переговоры с первыми потенциальными клиентами.
Прототип: создание технического задание и проектирование интерфейсов.
Работающий прототип: создание проекта или продукта с самым общим функционалом.
Альфа-версия проекта или продукта: проект или продукт создан, но еще не оттестирован, в процессе тестирования и usability-тестирования в интерфейс еще добавляются некоторые мелочи, которые не были додуманы на стадии составления технического задания и проектирования интерфейса, начинаются переговоры с первыми потенциальными клиентами.
Закрытая бета-версия проекта или продукта: проект или продукт уже находятся в виде, близком к тому, каким его видят основатели стартапа, у проекта появляются первые немногочисленные пользователи, которые приглашаются основателями стартапа попробовать сервис и сообщать о том, чего им не хватает либо о тех багах, с которыми они столкнулись.
Публичная бета-версия проекта или продукта: начинается привлечение пользователей, которые осознали у себя потребность в услугах, предлагаемых вашим проектом, либо самых любопытных, пользователей, которые постоянно находятся в поиске чего-то нового, часто происходит через системы инвайтов (приглашений), ограничение количества пользователей определенным количеством (например, 500, или 5,000), подписываются полноценные договора с первыми клиентами.
Стадия роста: стадия, когда положение стартапа на первичном целевом рынке (т.е. на том рынке, с которого он намеревался начать работу, и который описывала в своем бизнес-плане) уже стабильно, и стартап уверенно идет к завоеванию на этом рынке той доли, которую он наметил себе в бизнес-плане.
Стадия расширения: стадия, когда стартап выполнил либо очень близок к выполнению бизнес-плана на первичном целевом рынке, и расширяет свой бизнес за счет экспансии на другие рынки. Расширение бизнеса может происходить как самостоятельно, так и за счет скупки других игроков.
Стадия выхода: Под выходом прежде всего имеется в виду выход из бизнеса (целиком либо частично) венчурных инвесторов, которые инвестировали в стартап на предыдущих стадиях. Выход может происходить через продажу компании стратегическим инвесторам, через вывод компании на IPO (то есть первичная продажа акций компании на бирже) и через частное размещение (продажа акций компании фондам прямых инвестиций). Венчурные фонды инвестируют лишь в быстрорастущий молодой бизнес, а, как правило, к стадии выхода рост бизнеса компании замедляется по сравнению с предыдущими стадиями, хотя сам бизнес становится более стабильным. Есть, правда, еще один вариант «выхода» и инвесторов и основателей из стартапа – это банкротство компании и прекращение бизнеса, однако я надеюсь, что ни у кого из вас такого «выхода» не будет.