с чего начинается любой проект
Основные этапы любого успешного проекта: от начальной идеи до завершения
Независимо от размера проекта движение по этапам одинаково. Он инициируется или начинается с устава, который определяет управляющего и описывает важность всей предстоящей деятельности.
Что же происходит на самом деле при разработке любого бизнес-проекта? Разберемся подробнее.
Основные этапы
Как только проект был инициирован, переходят к этапу планирования. Здесь основные и рабочие группы определяют необходимую работу, которая должна быть выполнена для достижения масштаба деятельности, и разрабатывают сметы и оценки времени, затрат, ресурсов и рисков.
После фазы планирования работа начинается и происходит в определенном порядке, необходимом для перехода от предшествующей деятельности к последующей. Зависимости проекта играют важную роль на этом этапе.
В то время как выполнение продолжается, менеджер и члены команды следят, отчитываются и контролируют весь проект с акцентом на критических действиях пути. Эта работа продолжается до тех пор, пока не будет завершена фаза выполнения и проект не будет доставлен заказчику.
Заключительный этап, закрытие проекта, включает в себя завершение работы, оценку извлеченных уроков и перерыв команды, чтобы участники могли перейти к своей следующей инициативе.
Для гибких или итеративных проектов планирование и выполнение осуществляются в короткие периоды времени или с ускорением, причем этапы повторяются до тех пор, пока проект не будет завершен, а клиент удовлетворен.
Инициирование проекта
Надежная инициация проекта не только подготовит его к успеху, но и заложит основу для всех будущих этапов. Во время инициации вы получите назначение членов проектной команды, ознакомите их с общими целями проекта и зададите клиенту или владельцу как можно больше вопросов, чтобы вы могли эффективно планировать дальнейшую деятельность. Это также прекрасное время для создания командного энтузиазма по поводу проекта и сбора любых последних подробностей, которые могут повлиять на планирование. Дополнительные шаги включают в себя:
Планирование
Начав проект и собрав всю необходимую информацию, вы приступите к планированию. Этот этап зависит от размера вашего проекта, объема информации, которую вы должны организовать, и размера вашей команды. Результатом планирования должен быть четкий план или график, из которого каждый будет следовать своим назначенным задачам. Использование специальной программы, такой как Microsoft Project или Basecamp, чрезвычайно полезно. Если у вас нет доступа к одной из этих программ, выполните общий поиск в Интернете бесплатного программного обеспечения.
Хотя это не всегда необходимо. Использование Excel и Word для создания плана и передачи его команде одинаково эффективно.
Конкретные задачи на этапе планирования включают в себя:
Выполнение проекта
Теперь, когда у вас есть четкий план проекта, команда может приступить к выполнению в соответствии со своими задачами. Это этап, когда все начинают делать свою работу. Вы захотите официально начать этап исполнения с личных встреч, чтобы у каждого было то, что ему нужно, чтобы начать выполнять свою часть проекта. Начало работы команды в правильном направлении является неотъемлемой частью успеха, поэтому четко сформулируйте график и план коммуникаций.
Мониторинг и контроль
Пока проект находится в стадии выполнения, вы начнете контролировать его, чтобы обеспечить его движение в соответствии с планом. Существует множество способов мониторинга и управления проектом. Эффективны случайные проверки с руководителями групп, организованные ежедневные собрания или более официальные еженедельные статусные совещания. Информация, которая поступает с этих встреч или каналов связи, расскажет об обратной связи и в конечном итоге о любом перепланировании и корректировках, которые необходимы для проекта.
Дополнительные важные действия на этом этапе включают в себя:
Закрытие проекта
После того как все детали и задачи вашего проекта будут завершены и утверждены клиентом или владельцем, вы можете, наконец, закрыть свой проект. Это так же важно, как и инициация, планирование и выполнение. Вы захотите документировать всю информацию из проекта и аккуратно организовать ее, чтобы вы могли вернуться к ней при необходимости. Это также хорошее время для проведения анализа, чтобы все члены команды могли подумать о том, что было сделано правильно или неправильно.
С чего лучше начать проект или как сделать так, что бы не было потом мучительно больно
Доброго всем времени суток. Настала очередь поговорить о проектировании проектов. По собственному опыту знаю, что иногда сложнее создать проект с нуля, чем привести в порядок то, что уже есть. Во многом это связано с тем, какое наследие Вы или Вам, оставляют после себя. В этой статье постараюсь рассказать на что стоит обратить особое внимание и предложить краткий план следования.
Понимание проекта
Прежде чем что-то планировать, вам необходимо понять какой проект нужно реализовать. Для себя я выделил несколько категорий проектов, таких как:
Все градации условны и чаще всего встречаются перетекающие типы. Хочу заметить, что все типы могут мутировать друг в друга, единственный нюанс — в стоимости модернизации. Например, проект изначально был “одноразовая поделка”, а потом эволюционировал в “замкнутая система”. Обычно, подобное приводит к полному или почти полному переписыванию системы или ее рефакторингу. Как вы понимаете, это экономически нецелесообразно. По этой же причине желательно понять какой именно проект вам необходимо создать с нуля, и попытаться определить его дальнейшую судьбу.
Для определения типа проекта, ниже я привел вопросы, получив ответ на которые вам станет понятно, чего от Вас хотят:
Как вы видите, перечень не такой уж и большой. Правда, по какой-то неведомой причине, мало кто задаётся подобными вопросами до того, как начать что-либо делать. Вы спросите зачем мне понимать тип проекта?! Всегда надо делать так, чтобы проект жил вечность?! По большому счёту, вы правы, но есть нюансы, как в скабрезном анекдоте. Эти нюансы — ресурсы и сроки. Не стоит забывать, что мы трудимся на благо бизнеса и выполняем поставленные задачи. Когда вам известен тип проекта, вы можете без зазрения совести чем-то пожертвовать для достижения поставленных задач.
Выбор технологий
В выборе лучше придерживаться правила: технология не должна быть суперновой, но и устаревшей тоже. Если технология или фреймворк новые, это может обернуться такими проблемами как:
Данный перечень проблем актуален не только относительно технологий, но и к сторонним зависимостям. Всё вышеперечисленное может похоронить проект на корню.
Перед тем как выбрать что-то конкретное, подумайте несколько раз. Составьте пресловутую таблицу преимуществ с коэффициентами важности для проекта.
Данный пример составлен для вымышленного проекта:
С чего начинается любой проект
От того, как вы расставите приоритетность этих точек, как подготовитесь к ним и как зафиксируете результат, будет зависеть успех проекта.
Для начала немного теории. Что же такое проект?
Это выполнение уникальной работы. У вас есть начало и конец + некий путь между этими двумя точками. Этот путь вы представляете себе как прямую линию (или почти прямую линию), из точки А в точку Б, где вы и должны получить результат, по которому измеряется успешность вашего проекта.
Хотим отметить, что регулярные (рутинные) процессы, которые вы ежедневно выполняете — не равны проектной деятельности. Проектные и процессные задачи не должны перемешиваться между собой. Проектные задачи должны регламентироваться отдельными правилами и нормами в вашей компании или команде.
Итак, чем мы можем управлять в проекте:
Мы любим сравнивать IT проект со строительством. Так понятнее становятся многие вещи для Заказчика (ведь они превращаются в осязаемые процессы).
Давайте представим себе конструирование загородного дома. Его проектирование можно оптимизировать, выполнив адекватное планирование. Если создавать все в неверном (пусть даже местами) порядке — трудно будет создавать, тестировать и отлаживать процесс постройки (идея, проект, закупка материалов, закладка фундамента, возведение стен и т.д).
Очень часто причиной закрытия так и не вышедшего в свет проекта — является нехватка бюджета. Большая часть этой нехватки — связана с неверным планированием в начале пути.
Тщательное планирование необходимо.
«Вы можете спланировать основные структурные компоненты и позднее решать, чем покрыть пол, в какой цвет покрасить стены, какой использовать кровельный материал и т. д. Хорошо спланированный проект открывает больше возможностей для изменения решения на более поздних этапах работы.» (Цитата С. Макконнелл «Совершенный код»)
Разные проекты (CRM, ERP, e-commerce, агрегаторы объявлений и т.д.) — требуют разного подхода в планировании. Существуют классические и гибкие методологии (постепенность процессов против коротких повторяющихся итераций) для управления проектами. Все методологии помогают нам расставить приоритеты и минимизировать потери на проекте, но не дают «серебрянной пули».
Невозможно реализовать проект быстро, дешево, с максимально возможной функциональностью, без рисков для вас и с наивысшим качеством. Так или иначе, все аспекты придут в баланс и будут друг другу соответствовать.
Любой проект проходит через фазы развития. Каждую из них можно пройти циклично по несколько раз, перед тем как переходить к следующей.
Какие фазы проекта вас ожидают?
Если на предварительном этапе выработки требований к проекту, можно описать только малую часть, то рекомендуется придерживаться более гибких методологий разработки и управлять проектом фрагментарно, определив на старте минимальные жизненно важные требования к проекту. Дополнительные требования добавляются по мере развития проекта. 
Определите и зафиксируйте антирисковые мероприятия.
«Помните о бизнес-модели проекта. Многие проблемы с требованиями исчезают при воспоминании о коммерческих предпосылках проекта. Требования, которые сначала казались прекрасными идеями, могут оказаться ужасными, когда вы оцените затраты» (Цитата С. Макконнелл «Совершенный код»)
Обращайтесь за помощью к специалистам из финансовой, юридической, экономической, технической сферы, чтобы верно спланировать проект и не столкнуться в середине пути с тем, что нужно было решить вначале. Рекомендуем обращаться к потенциальным подрядчикам, т.к. это поможет определиться с выбором подрядчика и включиться им в работу.
«Внимание к требованиям помогает свести к минимуму изменения системы после начала разработки. Обнаружив при кодировании ошибку в коде, вы измените несколько строк, и работа продолжится. Если же во время кодирования вы найдете ошибку в требованиях, придется изменить проект программы, чтобы он соответствовал измененным требованиям. Возможно, при этом придется отказаться от части старого проекта, а поскольку в соответствии с ней уже написан некоторый код, на реализацию нового проекта уйдет больше времени, чем могло бы. Вы также должны будете отказаться от кода и тестов, на которые повлияло изменение требований, и написать их заново. Даже код, оставшийся нетронутым, нужно будет заново протестировать для гарантии того, что изменение не привело к появлению новых ошибок» (Цитата С. Макконнелл «Совершенный Код»)
Функциональные области в проекте это сроки, бюджет (стоимость), задачи (качество их выполнения), риски, выгоды, команда, интеграция (объединение всех областей). Всё нужно описать еще на старте и дальше переходить к выполнению этапов проекта.
Заказчик отвечает за грамотную постановку цели, а Исполнители — помогает в достижении этой цели, делиться своим опытом. Грамотное управление и планирование приведет проект к поставленной цели (но помните, что есть еще внешние факторы и держите «руку на пульсе»).
С чего начинается любой проект
Когда вы сталкиваетесь с созданием проекта (неважно, MVP это инновационной идеи или уже будущий highload-сервис, который вам поручило реализовать руководство), он всегда будет проходить через ключевые точки. От того, как вы расставите приоритетность этих точек, как подготовитесь к ним и как зафиксируете результат, будет зависеть успех проекта.
Для начала немного теории. Что же такое проект?
Это выполнение уникальной работы. У вас есть начало и конец + некий путь между этими двумя точками. Этот путь вы представляете себе как прямую линию (или почти прямую линию), из точки А в точку Б, где вы и должны получить результат, по которому измеряется успешность вашего проекта.
Хотим отметить, что регулярные (рутинные) процессы, которые вы ежедневно выполняете — не равны проектной деятельности. Проектные и процессные задачи не должны перемешиваться между собой. Проектные задачи должны регламентироваться отдельными правилами и нормами в вашей компании или команде.
Мы любим сравнивать IT проект со строительством. Так понятнее становятся многие вещи для Заказчика (ведь они превращаются в осязаемые процессы).
Давайте представим себе конструирование загородного дома. Его проектирование можно оптимизировать, выполнив адекватное планирование. Если создавать все в неверном (пусть даже местами) порядке — трудно будет создавать, тестировать и отлаживать процесс постройки (идея, проект, закупка материалов, закладка фундамента, возведение стен и т.д).
Очень часто причиной закрытия так и не вышедшего в свет проекта — является нехватка бюджета. Большая часть этой нехватки — связана с неверным планированием в начале пути.
Тщательное планирование необходимо.
“Вы можете спланировать основные структурные компоненты и позднее решать, чем покрыть пол, в какой цвет покрасить стены, какой использовать кровельный материал и т. д. Хорошо спланированный проект открывает больше возможностей для изменения решения на более поздних этапах работы.” (Цитата С. Макконнелл “Совершенный код”)
Разные проекты (CRM, ERP, e-commerce, агрегаторы объявлений и т.д.) — требуют разного подхода в планировании. Существуют классические и гибкие методологии (постепенность процессов против коротких повторяющихся итераций) для управления проектами. Все методологии помогают нам расставить приоритеты и минимизировать потери на проекте, но не дают “серебрянной пули”.
Невозможно реализовать проект быстро, дешево, с максимально возможной функциональностью, без рисков для вас и с наивысшим качеством. Так или иначе, все аспекты придут в баланс и будут друг другу соответствовать.
Любой проект проходит через фазы развития. Каждую из них можно пройти циклично по несколько раз, перед тем как переходить к следующей.
Если на предварительном этапе выработки требований к проекту, можно описать только малую часть, то рекомендуется придерживаться более гибких методологий разработки и управлять проектом фрагментарно, определив на старте минимальные жизненно важные требования к проекту. Дополнительные требования добавляются по мере развития проекта.
Определить критический путь проекта. Есть те работы, которые идут параллельно или идут последовательно и их невозможно сделать, не выполнив предыдущую задачу.
“Помните о бизнес-модели проекта. Многие проблемы с требованиями исчезают при воспоминании о коммерческих предпосылках проекта. Требования, которые сначала казались прекрасными идеями, могут оказаться ужасными, когда вы оцените затраты” (Цитата С. Макконнелл “Совершенный код”)
Совет:
Обращайтесь за помощью к специалистам из финансовой, юридической, экономической, технической сферы, чтобы верно спланировать проект и не столкнуться в середине пути с тем, что нужно было решить вначале. Рекомендуем обращаться к потенциальным подрядчикам, т.к. это поможет определиться с выбором подрядчика и включиться им в работу.
“Внимание к требованиям помогает свести к минимуму изменения системы после начала разработки. Обнаружив при кодировании ошибку в коде, вы измените несколько строк, и работа продолжится. Если же во время кодирования вы найдете ошибку в требованиях, придется изменить проект программы, чтобы он соответствовал измененным требованиям. Возможно, при этом придется отказаться от части старого проекта, а поскольку в соответствии с ней уже написан некоторый код, на реализацию нового проекта уйдет больше времени, чем могло бы. Вы также должны будете отказаться от кода и тестов, на которые повлияло изменение требований, и написать их заново. Даже код, оставшийся нетронутым, нужно будет заново протестировать для гарантии того, что изменение не привело к появлению новых ошибок” (Цитата С. Макконнелл “Совершенный Код”)
Функциональные области в проекте это сроки, бюджет (стоимость), задачи (качество их выполнения), риски, выгоды, команда, интеграция (объединение всех областей). Всё нужно описать еще на старте и дальше переходить к выполнению этапов проекта.
Какие же это будут этапы?
Как управлять проектом? Самый простой пошаговый план для новичков
Сегодня я расскажу о самом простом плане работы с проектом от его начала до его завершения. Этот план отлично подойдет для новичков. Если вы еще не освоили Agile, не знаете всех инструментов и лучших практик, но проект сделать нужно, то эта статья для вас.
Совсем немного введения
При разработке нового продукта важно выяснить каким конкретным требованиям он должен соответствовать, необходимо продумать основные функции и интерфейс, а также некоторые важные детали реализации.
Как правило, до начала процесса разработки подготавливается описание основных, самых важных компонентов и достаточно поверхностно, некоторые детали могут быть описаны подробнее, при необходимости. Детализация требований происходит параллельно с процессом программирования и фиксируется, обычно, в ТЗ, а также в виде задач для команды. Такой подход позволяет на этапе инициации проекта достаточно быстро подготовить информацию по проекту, которую можно использовать в оценке проекта, а также дает большую гибкость в реализации проекта, так как требования имеют свойство меняться в процессе (закладываем на это время в оценке).
Итак, ниже я опишу материалы, которые необходимо подготовить для проекта, а также основные этапы работы над проектам от инициализации до запуска и что вам нужно делать на каждом из них.
Для полноценного проектирования и детализации требований продукта необходимо подготовить следующее:
Техническое задание, где мы описываем в текстовом виде и с помощью диаграмм все требования и детали проекта.
Прототипы дизайна, где в общем виду показать какая информация будет размещаться на основных экранах
Смета проекта, где указаны все виды работ на проекте и их оценка в человеко-часах или в днях, а также стоимость проекта
Из второстепенных материалов:
Роадмап проекта, где указываем календарный план работ и майлстоуны
Устав, который часто разрабатывается вместе с контрактом на этапе инициации и где указываем правила работы над проектом (полезная вещь, особенно в неопытных командах)
Ниже я буду описывать процесс работы над проектом, где опишу немного подробнее разработку материалов:
Этап Инициации
На этом этапе идея продукта формируется в виде более подробных требований. Необходимо описать в техническом задании следующее:
Общая информация о проекте
Целевая аудитория проекта и ее проблемы (потребности), которые будет решать продукт
Ожидаемые выгоды от проекта (для ЦА)
Основные функции, которые пользователи смогут выполнять в системе. Составляется в общем виде с базовым описанием. Нужно разбить проект на компоненты, в состав которых может входить несколько функций.
Основные экраны и информация на них (в текстовом виде), которая составляется на основе требований к функциям из пункта выше.
На основе этого Технического Задания делаем Прототипы дизайна, где отображаем информацию, которая описана в последнем пункте. Стоит учесть, что в процессе могут возникнуть изменения и дополнения в ТЗ и это нормально.
После того, как готовы базовое ТЗ и прототипы, формируем Смету проекта, где указываем все виды работ, их оценку в часах, а также бюджет проекта. Иногда там же можно указать майлстоуны. Что касается оценки, то существует масса вариантов, но лично я предпочитаю оценку через бета-распределение (упрощенную версию)
Также можно составить Роадмап проекта на этом этапе, где указать календарный план работ и майлстоуны:
Этап Разработки
На этом этапе подготовленное ранее Техническое задание разбивается на части (функциональные компоненты, например), затем каждая часть описывается более детально, затем разбивается на конкретные задачи для команды и идет в разработку. Таким образом, пока идет проектирование и описание второй части, первая часть уже разрабатывается.
Для каждого компонента системы указывается следующее:
Список use cases (можно постепенно дополнять use case диаграмму или сразу сделать ее в полном объеме) с описанием каждого use case
Описание экранов (также можно постепенно составлять схему экранов или карту сайта)
База данных для компонента (может постепенно дополняться или разрабатываться сразу полностью)
Стоит отметить, что есть разные подходы к разработке Дизайна. В некоторых проектах дизайн полностью подготавливается до разработки, но я часто сталкиваюсь с тем, что дизайн делается частями в момент разработки. Таким образом, сперва подготавливаются основные экраны и компоненты, затем начинается разработка и по мере описания частей решения (о чем я писал выше) составляется дизайн для соответствующих компонентов, который также частями передается в разработку
Этап Запуска
Этап разработки завершается полноценным приемочным тестированием системы. Когда основные баги исправлены, проект запускается на сервере или (если это не серверное решение) отправляется в стор, после чего могут понадобится дополнительные настройки, которые лучше заранее расписать в ТЗ в виде требований к окружению (серверу).
Кроме того, в материалах, описанных выше, могут быть и другие составляющие или, напротив, отсутствовать некоторые из описанных, что вполне нормально и индивидуально для каждого проекта.
Это, конечно, очень упрощенное описание работы над проектом, но достаточное для понимания того, какие материалы и как нужно готовить. Самое важное при работе над проектом пользоваться не только правилами, а также и здравым смыслом.