Основные этапы проекта: инициации, реализации и завершения
Проникая в тонкости сокровенного знания о проектной практике, начинающий профессионал-PM или человек, готовящий себя стать проект-менеджером, должен свободно ориентироваться в основном терминологическом аппарате этого рода деятельности. Часто приходится слышать вопрос о том, как грамотно сформулировать этапы выполнения проекта. Действительно, это задача сложная. Но давайте сначала задумаемся, а принято ли в профессиональной среде оперировать понятием этапов? И в каких случаях это не только возможно, но и необходимо делать?
Определение понятий
Те из нас, кто имеет определенный опыт управления проектами или хотя-бы небольшой теоретический задел, знакомы с рядом явлений, которые менеджер использует, чтобы представить жизненный цикл инвестиционной задачи и спланировать ее решение. Список этих категорий на первый взгляд прост, в его составе:
- фаза жизненного цикла;
- веха;
- стадия;
- этап;
- процесс управления.
Предложенные понятия в практике часто используют как синонимы. И если поискать в источниках, то есть вероятность обнаружить, что и словари «грешат» круговыми определениями данных философско-прикладных категорий. Можно заметить и в научной литературе, что «фаза – это стадия», «стадия – это этап» и даже веха определяется как некий этап пути. Как же быть, ведь нам нужно оперировать точным восприятием явлений?
Я предлагаю выполнить процедуру, которую мы уже однажды делали с категориями проектных задач, целей и проблем. Усилим здравое разумение и посмотрим на представленные выше понятия с позиции обычного эмпирического опыта. Ниже показана таблица, в столбиках которой проставлены исследуемые категории, а в табличной части мы будем помещать определения, образы, примеры, которые соответствуют им. Начнем с понятия «фаза». В чем состоит суть данного понятия? Чем его можно охарактеризовать, какими отличительными качествами?
Состав отличительных качеств базовых понятий проектирования
Фазам проектной реализации посвящена статья на тему жизненного цикла проектной задачи. Эмпирически больше всего я воспринимаю фазу как длящееся и выраженное состояние выполнения проекта, например, фаза разработки или фаза завершения. Этих положений у проектной задачи несколько, и они всегда повторяются, хотим мы этого или нет. Принципов разбиения проекта на фазы может быть несколько, но подход к их формулированию един – с позиции длящегося состояния.
Вариант разбиения проекта на фазы с позиции перехода ответственности от PM
Вариант разбиения проекта на фазы с позиции ЖЦ проекта
Выше в качестве иллюстрации приведен пример двух схем фазовой разбивки проекта. С точки зрения ЖЦ фазы проекта венчают вехи – важные, значимые события его реализации. По временной шкале они представляют собой событийные точки. Фазы проекта делятся на стадии – восходящие периоды развития, отделяющие собой качественные состояния фазы. Например, стадия принятия решения о старте проекта или стадия формирования проектной команды. Более динамической категорией, чем фазы и стадии, являются процессы управления, имеющие следующие черты:
- представляют собой последовательность работ;
- связаны с управлением, основаны на регламентирующей базе;
- могут относиться к проекту в целом или к отдельной его фазе.
Этапы же являются частями процессов управления, включающих в себя однородные по сути составы работ. Таким образом, этап – это динамическая категория, которая может повторяться на каждой фазе проекта. Например, этап анализа. В небольших проектах этапы, фазы и стадии действительно сливаются в синонимы. В крупных мероприятиях этапы наиболее выражены в процессах инициации, завершения, планирования и организации исполнения.
Этапы процессов инициации и завершения
Мы с вами исследуем процедуры регулярного управления проектами, принимая за основу достаточно высокую планку их развития в компании. Это вполне оправдано. Какой смысл детально описывать этапы каждого из процессов для небольшого по масштабам проекта? Как говорится, «бери и делай!». Другой вопрос, когда проекты включают сложные по реализации элементы, а масштаб решаемых задач значительный. Любой проект начинается с процедур инициации, этапы данной группы процессов следующие.
- Формирование инициативного предложения по проекту.
- Разработка бизнес-плана, ТЭО, концепции проекта.
- Принятие решения о необходимости выполнить проект.
- Назначение куратора.
- Уточнение и детализация целей, границ проекта и его результатов.
- Выяснение ограничений и дополнительных требований.
- Разработка черновой версии организационной структуры мероприятия.
- Составление черновой версии устава и издание приказа о старте проекта и назначении PM.
- Чистовое описание проектного продукта.
- Проработка ограничений, требований и рисков реализации.
- Прояснение интересов и ожиданий участников.
- Выработка показателей и КФУ проекта.
- Уточнение необходимого состава процессов управления.
- Формирование укрупненного плана работ.
- Согласование и утверждение итоговой версии устава и укрупненного плана.
Схема временной развертки процессов управления проектом. Источник: Руководство PMBOK 5
В настоящем разделе мы исследуем процессы инициации и завершения, которые имеют несколько схожих черт. Основными задачами инициации являются однозначное определение проекта и формулирование его целей, результатов, установление заинтересованных сторон и их ожиданий. Инициация выполняется на старте проекта и в начале каждой из его фаз.
Проект рано или поздно завершается, и очень важно грамотно его «припарковать». Помимо закрытия проекта по факту его успешной реализации данные процедуры могут быть выполнены на каждой фазе мероприятия, когда принимается решение о досрочном прекращении работ. Помимо процесса закрытия проекта или его фазы к данной группе относится также и процесс, связанный с процедурой извлечения уроков и приращения опыта. Процедуры закрытия включают следующие основные этапы.
- Передача результатов заказчику, ввод в эксплуатацию.
- Подготовка финального отчета и обмен финансово-учетными документами.
- Архивирование документации проекта.
- Закрытие проекта приказом по компании.
Работа по извлечению уроков – весьма интересный и полезный процесс. Сюда включаются: презентации для проектного комитета и для других менеджеров компании, анализ и документирование выводов по успехам, проблемам и ошибкам проекта. На итоговом совещании выводы озвучиваются и принимаются рекомендации, подлежащие последующему исполнению.
Этапы процессов планирования
Процессы планирования проекта начинаются от момента запуска проекта и реализуются вплоть до завершающих стадий. Это многократные процедуры, реализуемые на каждой фазе решения проектной задачи. Целями этих процессов являются: детальная разработка содержания, выработка плана действий по управлению проектом и составление календарного расписания работ. Визуальная поэтапная модель процессов планирования предлагается вашему вниманию далее.
Последовательность этапов процессов планирования
Рассмотрим основные этапы создания планов проекта.
- Планирование целей и границ проекта. Этот этап также называется определением содержания (продукта как предмета планируемого мероприятия и требований к нему). Результатами этапа являются концепция, ТЭО, ТЗ и проектно-сметная документация.
- Разработка структуры проекта. В наиболее полном варианте в этап входит создание деревьев целей, задач, организационной структуры, плана по вехам, начало разработки иерархической структуры работ (ИСР) и структуры потребляемых ресурсов.
- Определение (уточнение) состава работ. Целью этого этапа является представление всей совокупности операций, необходимых для того, чтобы возник продукт, и цели проектной реализации были достигнуты. Среди инструментов этапа выделяется ИСР, наилучшим образом подходящая для создания такого представления.
- Определение состава потребляемых ресурсов. Предыдущие два этапа подготавливают почву для оценки потребности в ресурсах трех видов: расходуемых, возобновляемых и финансовых. Человеческие ресурсы, основные средства относятся к возобновляемым, материалы и комплектующие – к расходным ресурсам.
- Определение последовательности работ. Данный этап позволяет выстроить логику взаимосвязей операций. Ключевым инструментом этапа выступает сетевая модель проекта.
- Оценка продолжительности операций. В ходе этапа выполняется параметрическая оценка, оценка длительности по аналогам, оценка предложений исполнителей, экспертная оценка и т.п.
- Оценка затрат на выполнение работ. Целью данного этапа является уточнение стоимостных характеристик проектных задач с учетом объемов задействованных ресурсов, включая временные возможности и финансовые средства.
- Календарное планирование проекта.
- Подготовка бюджета проекта.
- Выполнение вспомогательных планировочных мероприятий. В настоящий этап включается разработка планов поставок, коммуникаций и других обеспечительных планов. Помимо прочего выполняется организационное планирование, утверждается матрица ответственности, планируется привлечение, назначение персонала и его расстановка.
- Сбор сводного плана.
Этапы процессов организации исполнения
Процессы организации исполнения проекта находятся исключительно в зоне управленческих компетенций PM. Постановка задач, координация и оперативное реагирование, проявление качеств лидера и командного вдохновителя – все это должно выполняться на этапах данной группы процессов. Представим себе пример инвестиционного проекта по разработке и выводу на рынок новой услуги в компании, действующей на рынке B2С. Типовой состав этапов процессов организации будет включать следующее.
- Набор команды проекта. На этом этапе предстоит привлечь специалистов, владеющих технологией новой услуги. Следует решить вопрос о том, смогут ли эти люди стать лидерами инноваций, повести других за собой. Главное, чтобы в результате работы знания и навыки были распространены профессионалом по кругу исполнителей. Важно проработать вовлечение всех участников команды: систему мотивации, загруженность, распределение ролей и ответственности.
- Выбор поставщиков. Данный этап связан с потребностью формирования лучших рыночных и организационных условий для выполнения работ внешними подрядчиками и поставщиками. Часто используются инструменты конкурсного производства для отбора поставщиков на основе тендеров.
- Обеспечение надлежащего качества работ. В нашем примере этап состоит в том, чтобы установить параметры, определяющие понятие качества оказания услуги. Обязательно разрабатываются технологические требования к процедуре услуги, стандарт производства и коммуникаций с клиентами. Эти стандарты включаются в систему обучения персонала и аудита выполнения процедур.
- Обеспечение координации работ и исполнителей. Этап своей целью имеет обеспечение четкого взаимодействия участников за счет установленных приоритетов задач, согласований с функциональными руководителями, качественной информационной поддержки команды.
- Отладка управления ожиданиями заинтересованных сторон. Предполагается владение PM ценностными ориентациями и интересами стейкхолдеров проекта, построение эффективной модели коммуникаций с ними.
- Организация развития команды. Процедура делится на выполнение формальных управленческих задач и неформальных лидерских позиций: сплочения команды, укрепления духа коллективизма, товарищества и т.д.
- Организация распределения информации. Распределение и движение информации по адресатам в проекте должно быть организовано в принудительном, гарантированном режиме.
В настоящей статье мы разобрали понятие и содержание ключевых этапов основных процессов управления проектом. Сама природа и сущность этапа как объекта управления входит в противоречие с проектной действительностью. На мой взгляд, более верно говорить не об этапах, а о подпроцессах процессов управления. Причина этого состоит том, что процедуры управления носят растянутый, порой не диагностируемый по последовательности характер. В этих условиях выделить этап как отдельную часть проектного пути сложно. Во всяком случае, логика института PMI при разработке стандарта, сделавшего ставку на процессы, стала более очевидна.
3 обязательных шага для запуска проекта с нуля
Запуск и развитие любого нового проекта, оборудования, предприятия, видеоролика, сайта – шаг в доселе неизведанное пространство. Поэтому человек, которому доверяется выполнить этот шаг, как минимум, должен быть готов к нему морально, как максимум, должен обладать необходимыми теоретическими знаниями и практическими навыками. И готовить его к этому шагу нужно так же, как космонавта.
Но что такое практический опыт? Это не обязательная программа, как у фигуристов или гимнастов. У нас, менеджеров, это тот опыт, который поможет тебе в будущем стать успешным, станет точкой опоры в принятии важных и значимых решений, в конечном итоге определяющих правильное направление твоего проекта. И здесь неформальный подход не уместен.
К примеру, некоторое время назад мне было поручено возглавить развитие городского рынка «Калуга». Как руководителю мне раньше не доводилось запускать такого рода проекты, где задействовано большое количество людей, как со стороны заказчика – муниципалитета, так и со стороны обычных горожан, предпринимателей и прочих участников процесса. Но если неформально подойти к вопросу, то можно увидеть, что я вырос в семье, где был опыт рыночной торговли с 1990-х годов. Моим родителям пришлось стать предпринимателями, когда отцу, бывшему военному, не выплачивали и задерживали денежное довольствие. Соответственно, эта система организации торговли мне известна от процесса аренды помещения до закупки нового товара и сезонности продаж. И, кроме того, у меня имеется практический опыт взаимодействия с арендодателями, что является основой деятельности организаций, управляющих и эксплуатирующих недвижимость.
Важной составляющей также является твоя теоретическая база: насколько ты готов решать вопросы, постоянно возникающие в области экономики, финансов, работе с клиентами, подготовки отчетности, операционного управления.
Объективно оценить эффективность работы менеджера на новом месте работы в условиях высокого уровня неопределенности возможно, только лишь оценив его управленческие способности. Как мне предполагается, менеджер, обладающий способностями к руководящей работе, должен обладать определенной методикой вхождения в проект с нижнего старта, знать, как это сделать, что называется, step by step. Но чтобы создать такую дорожную карту, такой план работы, нужно иметь представление о том, куда двигаться, в каком направлении применять свои знания и расходовать время.
Мне, например, как опытному экономисту-производственнику не составило больших усилий разработать план запуска нового проекта в сфере, где я до сих пор не работал. При этом я опирался на достигнутые показатели деятельности рынка и на прогнозные финансовые результаты. Цифры для меня всегда и во всем имеют огромное значение. На основании своего опыта я рекомендую планировать проекты в три шага.
1. Просчитать экономику
- Оценить рынок (область деятельности) в целом и региона, в котором вы планируете проект: конкуренты, цены, спрос и предложение.
- Очень важно спрогнозировать риски, так как именно риски влияют на рост затрат, на выполнение планов по выходу на прогнозируемые объемы производства и продаж. В недвижимости, к примеру, рисками является конкурентная среда, место расположения объекта, транспортная инфраструктура, менталитет людей, населяющих регион.
- Необходимо применить креативный подход и абстрагироваться от планов, выстроенных совместно с представителями местных органов самоуправления. При реализации проектов в рамках частно-государственного партнерства взаимодействие с представителями государства является одним из серьезных рисков (при условии, что уровень лоббизма находится на обычном конкурентном уровне).
- По результатам экономической работы представить и интерпретировать физические, натуральные показатели деятельности: планы, перспективы, ценообразование, влияние различных факторов на стоимость продукта, работ и услуг. Планы составлять с учетом пессимистичного и оптимистичного вариантов реализации проекта.
2. Выстроить планы по всем направлениям
- Персонал. Потребности, штат, система оплаты труда, мотивация и подбор нужных кадров. Распределение обязанностей. Контроль.
- Подготовка к производству, эксплуатации, оказанию услуг. Пример для производственного предприятия: поставка оборудования, запуск и наладка, обслуживание, инвентаризация и система сохранности и обслуживания.
- Снабжение.
- Логистика.
- Бухгалтерский и управленческий учет.
- Налаживание и оптимизация технологических процессов.
- Коммерческая служба: договорная работа, работа с основными клиентами.
- GR, PR и маркетинг.
3. Создать адаптивную систему управления
- Определить показатели деятельности по каждому направлению.
- Провести плановые совещания, обсудить текущие и перспективные планы.
- Оценить текущую ситуацию и принять управленческие решения.
Отмечу, что самым важным в любой работе является правильно выстроенная работа с людьми: с персоналом, с клиентами, с партнерами, со всеми, с кем приходится взаимодействовать. Очень важно слышать людей, их потребности и желания и принимать решения только учитывая и взвешивая человеческий фактор в управлении.
Фото: pixabay.com
как запустить проект в одиночку
Немного слов обо мне: уже полтора года я консультирую молодые компании, как еще не получившие финансирования — pro bono, так и уже закрывшие минимум один инвестиционный раунд — уже не безвозмездно, если мои услуги команде все еще необходимы. Помимо этого, я, время от времени, преподаю в местном буткампе iOS разработку. Да-да, со смузиками, планшетиками, сойлентами и даже с двумя коворкингами в одном здании.
Параллельно занимаюсь своими проектами, и, к сожалению, ни один из них еще не выстрелил. Ну кроме одного. Который я сделал за 4 дня — Voicy — Telegram бот, автоматически переводящий все голосовые сообщения в текст. Спустя неделю после запуска сервис был установлен в 1734 чатах и перевел в текст 5671 войс. Данные в реальном времени всегда доступны на официальном сайте бота.
Так, как же у меня это получилось? В этой статье я постараюсь максимально просто описать ключевые составляющие хорошего продукта, а так же как и чем их можно заменить. Начнем с небольшой теории.
HHH
Считается, что для того, чтобы сервис стал успешным и приносил много шекелей, нужно иметь как минимум трех членов команды: hipster, hacker, hustler. Hipster рисует дизайн, hacker пишет код, а hustler рассказывает всем о продукте и находит инвестиции. Эти три пункта и есть главные составляющие успешного проекта. Но что делать, если у вас нет друзей или никто не хочет работать с вами за идею, а денег хватает только на завтраки? Логичным решением будет как-то заменить членов команды самостоятельно.
Благо, прошли те времена, когда для разработки программного обеспечения приходилось 4-5 лет учить язык машин, а потом лет десять его практиковать. Кануло и десятилетие, когда для создания простого графического интерфейса приходилось часами потеть в специализированных визуальных редакторах. Забыт век информационного вакуума, когда книги приходилось не гуглить, а искать по библиотекам. Пришла эра самообучения и свободного доступа к знаниям человечества. Добро пожаловать в Интернет, я буду вашим гидом.
Hustler
Это человек, который обладает выдающимися бизнес-навыками. Общение с людьми, планирование, разработка процессов, управление компанией, набор кадров, стратегические решения и еще много-много всего лежит на плечах этого титана мысли. Топ-менеджеры крупных компаний на подобных должностях, как правило, все имеют диплом какой-нибудь школы MBA на стеночке. Но так ли этот диплом необходим?
Какие грабли могут появиться у вас на пути? Как зарегистрировать компанию? Гуглим, «Как зарегистрировать компанию». Как оплатить налоги? Гуглим, «Как оплатить налоги». Как составлять договор с фрилансером? Гуглим, «Как составлять договор с фрилансером». Как делать это? А как делать то? Гуглим. Большинство вопросов уже заданы, а большинство ответов уже написаны в Интернете.
Но есть определенный набор навыков, которые не нагуглить — чаще всего, это комплексные концепты, например, «Теория ограничений» или тот же «Agile». Откуда выудить эти замечательные знания? Обязательный ряд книг указан на англоязычном ресурсе, а обязательная к прочтению книга уже давно переведена на русский язык. После того, как все это проглотите — поймете, какой продукт делать, как его делать и как продвигать. Подписаться на хорошие бизнес-блоги (лучше, англоязычные) тоже не помешает.
И так, предположим, бизнес-сторону вы познали и стали настоящим хастлером. У вас на это должно было уйти не больше одной-двух недель чтения книг и блогов. После — месяц-два практики в маркетинге и наработка связей, но больше особо и не нужно.
Hipster
Самый, наверное, больной для меня пункт — я никогда не славился своими крутыми дизайнами, а друзья, которым я дарю свои картины, перестают со мной общаться. Хотя что я вам вру, у меня нет друзей, поэтому картины я тоже не пишу. Как же заменить этого гуру цветов, красок и фотошопа? Не поверите, но информацию тоже можно найти в Интернете, а сделать красивый плоский дизайн сегодня не так уж и сложно.
Во-первых, гуглите. Во-вторых, скачайте себе бесплатный пробник Sketch и поиграйтесь с ним слегка. Это, можно сказать, Lego для дизайнеров — вы же умеете складывать дома из Lego? Со Скетчем тоже, значит, разберетесь. В зависимости от задачи, делайте правильные запросы в Google.
Например, чтобы понять, что такое верстка и как создаются сайты, можно глянуть вот эту статью. Чтобы создавать дизайн сайтов в Sketch, можно скачать элементы Bootstrap 4, или для iOS, или для Android — раз-два-три и вот дизайн готов. Чтобы не лохануться перед началом мобильной разработки, прочитайте официальные гайды от Apple и Google по дизайну. Можете еще и одну профильную книжку прочитать.
И я же не просто родился со знанием об этих ресурсах — я, так же, как и вы, просто гуглил. Итого, потратив недельку на штудирование литературы, вы готовы создавать собственный дизайн. И не забудьте про хорошие цветовые схемы — их тоже надо научиться подбирать. Алсо, если лень заморачиваться, можно купить готовые шаблоны дизайна в интернете от $5 — вытянуть оттуда элементы и цвета.
Hacker
Вот и подошли мы к львиной части создания продукта — разработка. Да, люди учатся этому годами, повышают свое мастерство. Но я открою вам секрет: большинство необходимых навыков программирования люди получают в первые 2-6 месяцев активной практики. Дальше мы годами грызем гранит науки — нарабатываем специфические навыки, разбираемся в определенных фреймворках, учим новые технологии и языки программирования.
Часто слышу от клиентов без денег отмазку, что, мол, программировать они не умеют, а фаундера-программиста найти не могут. Ну так что же ты, в 2016, не займешься-то разработкой самостоятельно? Да, сложно. Да, муторно. Да, долго. Но это того стоит.
Я сам начал разрабатывать в 2012 году без чьей-либо помощи. У меня был только интернет и голова на плечах — даже менторов не было. Ну так что же мешает сегодня начать учить новые технологии новичкам? Мое мнение — это лень и незнание, как оправдание. Так вот, после этой статьи вы узнаете, что нужно делать — оправдания у вас больше не будет. Да даже если вы не хотите становиться программистом, иметь опыт автоматизации процессов кодом просто необходимо в 21 веке.
Предположим, вы начинаете с нуля — идите на любые профильные сайты интерактивного обучения языкам программирования, сотни их. Например, Codecademy. Закончите все курсы, которые там есть — особенно, если они бесплатные. После, ставите себе цель создать свой продукт, продумываете его и начинаете гуглить туториалы по определенной технологии. Например, вот этот YouTube плейлист для серверной разработки на Node.js или вот этот сайт для разработки под iOS.
Проходите все туториалы, которые сможете откопать. Как правило, проходя их, вы будете собирать маленькие приложения. Когда уже более-менее начнете себя комфортно ощущать с кодом, переходите на написание микро-сервисов для самих себя. Возможно, ничего общего не имеющих с вашим конечным продуктом, который вы себе задумали, но решающих одну определенную вашу проблему.
Помните, что первые 5-20 приложений, которые вы напишите, будут ужасными. Этот этап нужно пройти как можно скорее и запустить минимум 5-20 маленьких сервисов. А дальше, начинайте потихоньку писать свой собственный продукт — знаний у вас уже должно быть достаточно, а Гугл окажется незаменимым помощником. Так же можно искать помощь в профильных сообществах того же Телеграма, например, чат Java разработчиков.
Что дальше и зачем я это прочитал?
Поздравляю, вы только что прошли курс молодого стартапера! Познав все три составляющие хорошего продукта, вобрав в себя знания всех трех H, вы готовы к запуску своего продукта.
Напомню, что ни единой ссылки из этой статьи я не получил от друзей, знакомых, менторов или бизнес-тренеров — я все нашел в Гугле, и вы тоже можете так поступить. Создание своего сервиса в столь сжатые сроки в одиночку было бы невозможным без заранее пройденных этапов из этой статьи.
Надеюсь, статья окажется хорошей отправной точкой для заблудших душ, которые искали путь истинный в мир стартапов. Путеводную нить я дал вам в руки, время самостоятельно идти вперед.
Спасибо большое, что дочитали до конца! Выразить свои благодарность или недовольство можно комментарием, а по-настоящему вы меня порадуете, если установите и попробуете мой новый продукт, Voicy.
Rock on!
Запуск проекта на разных хостах / Habr
Наверное, каждый разработчик встречался с задачей запуска одного проекта на разных компьютерах. В простом случае это машина разработчика и «боевой» сервер. Ещё сложнее ситуация, если в разработке участвуют несколько человек, и у каждого свои настройки.Сложность здесь в том, что разное окружение (доступ к БД, расположение файлов и проч.), будучи «жестко» прописанным в файле конфигурации, заставляет нас постоянно этот файл править. Кроме того, файлы настроек часто заливаются в репозиторий, и после очередного обновления кода у вас всё перестаёт работать.
Для решения проблемы я использовал два метода.
Первый — менее удачный, как мне кажется — заключается в привязке файла конфигурации, либо его части, к имени хоста, на котором запускается проект.
Примерно так выглядел мой XML-конфиг (то, что это XML, не важно — суть та же для любого типа конфигурации).
<?xml version="1.0" encoding="UTF-8"?>
<root>
<!-- You can set just ip or host without "www." -->
<server ip="127.0.0.1" host="localhost">
<!-- Database params -->
<param name="db_host">dm9</param>
<param name="db_port">3307</param>
<param name="db_user">root</param>
<param name="db_pass">123</param>
<param name="db_name">dm9_idsrv</param>
…
</server>
<server ip="12.34.56.78" host="my-production-host.ru">
…
Недостатков у этого метода было 2:
— у разных разработчиков (с разными параметрами окружения) может быть одинаковый хост — скажем, localhost;
— кроме того, при смене или добавлении хоста приходится править файл.
После этого я стал использовать другой метод — переменную окружения, которая указывает, на каком хосте мы сейчас работаем.
Установка переменной окружения проста. Для Апача достаточно добавить строку ‘setEnv DEV_HOST DM9’ в httpd.conf, чтобы создать переменную окружения DEV_HOST, значение которой равно DM9 (имя или ник разработчика). Переменная окружения может быть также установлена отдельно для каждого виртуального хоста. (Кстати, можете подсказать, как это делается под ngix, я добавлю.)
Я предпочитаю устанавливать переменные окружения только для машин, на которых ведётся разработка. Отсутствие такой переменной означает, что мы на «боевом» сервере.
Сейчас мой файл конфигурации (под PHP-проект) выглядит так:
if (isset($_SERVER["DEV_HOST"]) AND $_SERVER["DEV_HOST"] === "DVS") // первый разработчик
{
$config["db_host"] = "localhost";
$config["db_user"] = "root";
$config["db_pass"] = "";
$config["db_name"] = "xtr_ru";
}
elseif (isset($_SERVER["DEV_HOST"]) AND $_SERVER["DEV_HOST"] === "DM9") // второй разработчик
{
$config["db_host"] = "localhost";
$config["db_user"] = "root";
$config["db_pass"] = "123";
$config["db_name"] = "xtr";
}
else // рабочий сервер
{
$config["db_host"] = "localhost";
$config["db_user"] = "xtr";
$config["db_pass"] = "some_password";
$config["db_name"] = "xtr";
}
Опытный читатель заметит, что во всём этом есть один подвох: а как же запускать скрипты из консоли? Это важная задача — например, скрипты нужно уметь запускать планировщиком.
Тут вариантов тоже два — как говорится, на любителя.
Первый — запускать скрипт планировщика с параметром, равным значению хоста (для первого метода из описанных выше) или вашей переменной окружения (для второго метода). Если вы привязываетесь к имени хоста, только этот способ и будет работать.
Вот пример запуска скрипта, на вход которому подаётся имя хоста (содержимое bat-файла, которым я запускаю скрипт из-под Windows):
#clean_something.bat
cd «E:\myproject\utils»
php clean_something.php localhost
pause
(Если Вы используете PHP, параметры, переданные скрипту, можно получить через $_SERVER[«argc»] и $_SERVER[«argv»].)
Второй вариант — прописать глобальную переменную окружения в операционной системе. В этом случае её не придётся прописывать в файле конфигурации вашего веб-сервера. Под Windows это делается через свойства «Моего Компьютера» (далее закладка Advanced (Подробнее), кнопка Environment Variables (Переменные окружения), далее в разделе System Variables (Системные переменные) кнопка New (Добавить)). Перевод на русский может быть неточным — поправьте, пожалуйста. После этого, скорее всего, придётся перезагрузиться. Под NIX-платформы это делается немного сложнее, и это выходит за рамки данной статьи. Однако, если вы ведёте разработку под Windows, а на NIX выкладывате только релизы, это вам и не понадобится.
Да, почему я пишу эти очевидные для многих строки? Просто мне всё ещё слишком часто приходится работать с проектами, в которых используется один файл конфигурации, не настраиваемый под окружение. Делайте конфиги, которые не надо часто править. Пожалуйста 🙂
Использование MS Project для управления проектами по разработке ПО / Habr
Я хочу поделиться своим опытом использования MS Project для управления проектами по разработке программного обеспечения. Я уже лет 10 занимаюсь управлением проектами,и в результате у меня родилась некоторая методология использования MS Project, которая позволяет получить от него немалую пользу и при этом меньше зависеть от его недостатков.
Небольшое введение
Вся методология — это просто набор простых методов и рекомендаций по использованию MS Project для решения прикладных задач руководителя проекта. Сразу оговорюсь, что методология не претендует на универсальность, и применима только при некоторых ограничениях, которые я буду упоминать по ходу повествования.
Для начала, давайте вспомним, что обычно требуется от руководителя проекта. Для опытных руководителей это очевидно, а начинающим (или только собирающимся стать руководителями) будет полезно лишний раз вспомнить. Итак, проект по разработке программного обеспечения — это создание некоторое уникального продукта. На разных этапах жизненного цикла проекта от РП требуется решать различные задачи.
Перед началом проекта
Перед началом проекта от руководителя проекта обычно требуется ответить на два вопроса:
- сколько проект займет времени
- сколько проект будет стоить
При этом важно понимать, что никого не интересует ответ вида «не раньше чем через полгода». Требуется как раз оценка сверху.
Примечание. Мне никогда не приходилось иметь дела с явными денежными оценками проекта, и, как я сейчас понимаю, это серьезное упущение. Все проекты, которыми я руководил, исполнялись сотрудниками компании. Команда проекта формировалась на всё время проекта, некоторые специалисты привлекались на определенное время. Фактически, от меня требуется оценка количества требуемых исполнителей, а также сроки их привлечения. Как мне кажется, это достаточно типичная ситуация для компаний, занимающихся разработкой ПО. В итоге все сводится к оценке трудозатрат, которая, с использованием эмпирических формул, превращается в оценку стоимости проекта. Как видим, присутствует прямая зависимость стоимости проекта от его сроков.
В процессе выполнения проекта
В условиях упомянутых ограничений, основной задачей руководителя проекта является обеспечить выполнение проекта в заявленный срок, а это непосредственно
влияет на его стоимость. Непредвиденные обстоятельства, которые обязательно сопутствуют любому проекту, могут привести к срыву сроков. Строго говоря, сроки проекта могут неожиданно и сократиться, но, честно говоря, я такого никогда не видел. От руководителя требуется своевременно реагировать на такие события, чтобы уменьшить негативные последствия. Единственный известный мне способ решения этой задачи — это аккуратное планирование, регулярное отслеживание надвигающихся проблем и корректирование планов.
При завершении проекта
При завершении проекта руководитель обычно оглядывается назад и подводит итоги проекта. Чаще всего требуется оценить насколько проект выбился из плановых графиков и почему это произошло.
Что умеет MS Project
Несмотря на внешнюю сложность, MS Project очень прост в идейном плане. Он оперирует тремя сущностями — задачи, ресурсы, календарь и связи между ними. По сути — это база данных, пользовательский интерфейс для создания и редактирования сущностей и минимальная, довольно простая автоматизация (то, что Project делает сам, в ответ на введенные данные).
Разберем вкратце свойства сущностей.
Задача имеет длительность, объем, назначенный ресурс и еще чертову уйму различных свойств. Если встроенных свойств не хватает, можно добавить свои — этим мы потом воспользуемся. Задачи могут быть связаны между собой различными отношениями (предшественники, последователи и т.п.).
Ресурс имеет много описательных свойств, но самое главное — для него можно
задать доступность во времени, для этого используется календарь. Ресурс может быть
назначен на задачу.
На основе этих данных Project умеет делать различные представления с использованием
фильтров, группировок, сортировок и т.п. Кроме этого он умеет по некоторому алгоритму
вычислять сроки начала и окончания задач с учетом доступности назначенных ресурсов
и связей между задачами. Вот, собственно, и почти все что он умеет.
Давайте посмотрим, какую пользу можно из этого извлечь
Как это использовать
Примечание Чтобы было понятнее, я уточню некоторые общие свойства проектов,
с которыми я работал. Итак, речь идет о проектах по разработке программного обеспечения,
которые состоят из нескольких этапов. В конце каждого этапа мы должны получить некоторый
осязаемый результат, который будет предъявлен заказчику, поэтому для нас важно оценить
срок не только проекта в целом, но и каждого этапа. Повторяю, единственный вид ресурсов
который требуется — это люди, причем мы не нанимаем специалистов со стороны, а используем
возможности уже работающих сотрудников.
Подготовка плана
Итак, перед нами лежит техническое задание, и требуется дать ответ на три вопроса:
- Сколько времени займет этот проект?
- Сколько (и каких) специалистов для этого потребуется?
- Какие примерно трудозатраты ожидаются по этому проекту?
Для этого мы готовим прикидочный план выполнения проекта в MS Project. Т.е. просто последовательно выписываем задачи, которые необходимо выполнить. Методика превращения техзадания в набор задач — это отдельная история, я не буду на ней сейчас останавливаться.
Подготовка плана выполняется в несколько этапов:
- Готовим список задач
- Выставляем зависимости между задачами
(результат какой задачи необходим для перехода к следующей?). - Назначаем исполнителей задач
- Выравниваем загрузку ресурсов
- Балансируем то, что получилось
Общие рекомендации
При подготовке плана придерживаемся следующих рекомендаций:
- Не используем суммарные задачи для декомпозиции.
Все задачи помещаем в один линейный список. Сначала это может показаться неудобным,
но зато избавляет от многих проблем в дальнейшем. Для управления структурой задач
используем настраиваемые поля (см.ниже). - Очень часто для управления зависимостями задач используют Drag&Drop. Когда задач много это быстро становится неудобно. Я рекомендую в этом случае не использовать перетаскивание, а явное указывать номера задач-предшественников. для этого можно добавить в таблицу столбец «предшественники» и вписывать номера задач вручную.
- Срок каждой задачи не должен превышать двух недель.
Если срок задачи превышает неделю — это уже повод задуматься о её декомпозиции. Я придерживался очень простой методики оценки: примитивная задача — 2 дня, средней
сложности — 1 неделя, сложная задача — 2 недели. При этом сложных задач не должно быть много. Такой подход дает возможность подготовить оценочный план довольно быстро.
С одной стороны, полученная оценка, конечно, не будет точной, но, с другой стороны — а какая из них точная? По опытку практического применения могу сказать, что на
больших проектах погрешности оценок отдельных задач обычно нивелируются, а на малых часто можно (и нужно!) использовать и более точные оценки. - Всеми силами избегаем задач, у которых несколько исполнителей. Для каждой задачи должен быть назначен только один исполнитель. Двух исполнителей имеет смысл назначать
только если они действительно работают вдвоем (например, вы практикуете парное программирование). В прочих случаях лучше декомпозировать задачу. - При назначении исполнителей руководствуемся их профессией и квалификацией, пока не беспокоясь о равномерности загрузки.
- Используем суммарные задачи для разделения задач на этапы. Ставим зависимости между этапами, чтобы они шли последовательно. Разделение на этапы пока достаточно приблизительное.
Список задач, разделенный на этапы
Балансировка проекта
Самым главным в методике является именно балансировка. Цель этого процесса — подготовить план, в котором работы достаточно равномерно разделены между исполнителями на всем протяжении.
После первичной подготовки плана обычно получается полное безобразие, а не проект. Поэтому начинаем приводить его в порядок. Приведение в порядок заключается в ручной балансировке назначений исполнителей и разделений на этапы. Для этого используем группировку задач по исполнителям, чтобы увидеть как разложились задачи. Для удобства просмотра рекомендую сортировать задачи по дате начала.
Группировка задач по исполнителям
Примечание. Теоретически, для оценки загрузки полагается использовать графики
загрузки пользователей. Эти графики хороши (наверное) для начальства, когда они
оценивают готовый проект. Но они непригодны на этапе создания плана, так как показывают
что все плохо, но совершенно не дают информации почему это так и что можно сделать.
Дальше начинается магия балансировки. Требуется минимизировать сроки выполнения каждого этапа путем обеспечения более-менее равномерной нагрузки на всех участников проекта. Для этого мы выполняем следующие действия:
- Сменить исполнителя задачи.
Это имеет смысл сделать, если мы видим, что у одного исполнителя большой хвост задач,
а у другого есть явные «дыры», причем он может взять на себя некоторые работы у
первого. - Перенести задачу в другой этап.
Задача, которая приводит у удлинению срока этапа, но при этом не является необходимой
для получения результата этапа может быть перенесена на этап позже. И наоборот,
если в этапе присутствуют «дыры» в загрузке исполнителей, а изменить исполнителей
не получается, то можно попробовать взять задачи из следующего этапа.
Делать все это, к сожалению, приходится вручную, выполняя выравнивание загрузки ресурсов после каждого изменения. Несмотря на кажущуюся сложность, этот процесс обычно занимает конечное время. Проект на год из 8 участников, разбитый на 4 этапа я приводил в порядок менее чем за час.
Теперь еще раз внимательно смотрим на проект, убеждаемся, что связи между задачами расставлены правильно, что ничего не забыто, а назначения исполнителей соответствуют их специальностям и квалификации.
Учет рисков
Теперь — последний штрих: учет рисков. Честно признаюсь, я не занимался серьезным управлением рисками, но учитываю возможность возникновения определенных форсмажоров (таких как болезни исполнителей, забытые работы и т.п.). Для этого я добавляю в каждый этап фиктивную задачу с минимальным приоритетом, под названием «прочие работы» для каждого ресурса. После выравнивания ресурсов эти задачи оказываются в конце этапа. Длительность этих задач зависит от вероятности возникновения и степени вляния рисков, она зависит от способа определения оценок длительностей задач, здоровья членов команды и степени паранойи руководителя проекта. Обычно я выставлял длительность «прочих работ» примерно от трети до четверти длины этапа.
В результате всех перечисленных манипуляций у нас получается план выполнения проекта, с которым можно работать.
С этим планом мы можем:
- Назвать сроки выполнения проекта и его этапов. Аргументированно и с высокой степенью
достоверности. - Оценить примерные трудозатраты по проекту
Примечание. Часто случается так, что срок выполнения получается довольно большой, и возникает резонный вопрос, можно ли его уменьшить за счет привлечения дополнительных исполнителей. Для того чтобы ответить на этот вопрос, я балансировал новый план, используя тот же набор задач, но изменяя состав исполнителей. Ответ не получался мгновенно, но это не занимало много времени.
Работа с планом
Когда проект запускается в работу, исходный план, который использовался для оценки, можно использовать и для отслеживания выполнения проекта. От руководителя проекта требуется регулярно выполнять следующие действия:
- Выдавать задания исполнителями
- Отмечать выполненные задания в плане
- Корректировать план в случае значительных отклонений
Выдача заданий исполнителями может выполняться по разному. Можно разбить выполнение на короткие итерации, формировать пул задач на итерацию и по окончании итерации отмечать результаты. Можно сразу озвучить лнителям набор задач на этап, выдать каждому по экземпляру диаграммы Ганта и периодически опрашивать о прогрессе. Можно использовать интеграцию MS Project и TFS и загрузить проект непосредственно в TFS. Суть не в средствах. Главное — это регулярное обновление плана. Я делаю это примерно раз-два в неделю. Это дает возможность достаточно быстро увидеть проблемные участки.
Для определения проблемного участка удобно использовать различные группировки — по исполнителями, по компонентам и др. Часто может оказаться, что проект в целом идет даже с опережением, но в определенном разрезе наблюдается отставание, например один из разработчиков неожиданно уткнулся в серьезную системную проблему, которая привела к отклонениями. Использование только средней метрики не покажет этой проблемы — она всплывет только в конце этапа, когда что либо делать будет уже поздно.
Отслеживание выполнения с группировкой по компонентам
Примечание. Обычно я не двигаю задачи по календарю, а только отмечаю насколько они выполнены. Отклонение от плана я отслеживаю по отклонению суммарной задачи проекта от текущего момента.
Есть другая стратегия — внесение изменений в сроки задач, «выталкивая» невыполненные задачи вперед. При таком подходе для отслеживания отклонений от плана можно использовать другую полезную функцию MS Project — базовый план. Базовый план — это просто сохраненный снимок состояния задач. Его можно сделать в начале проекта. Для сравнения текущего плана с базовым, открываем «диаграмму Ганта с отслеживанием». Для динамичного плана, когда порядок выполнения задач часто меняется, это может оказаться неудобным, поэтому я вставляю в проект контрольные точки, отражающие некоторые важные результаты проекта, и отслеживать отклонения от базового плана только для них.
Диаграмма Ганта с отслеживанием
Управление структурой задач с помощью пользовательских полей
Я категорически рекомендую не использовать суммарные задачи в MS Project для функциональной декомпозиции или категоризации задач. Дело в том, что иерархия задач в MS Project сильно завязана на их последовательность. А часто хочется посмотреть на задачи в разной последовательности, при этом вся структура «рассыпается». Для управления структурой задач я рекомендую использовать Пользовательские поля. MS Project имеет предопределенный набор полей с неопределенным заранее поведением, которые мы можем использовать так, как нам удобно. Например, для разбивки задач по компонентам нужно на основе текстового поля Текст1 создать поле Компонент и задать для него список значений, соответствующий компонентам системы.
Создание пользовательского поля
После этого мы получаем возможность указать для каждой задачи компонент, к которому она относится, и, используя группировку задач по компонентам, отслеживать как идут дела.
Группировка задач по компонентам
Пользовательские поля позволяют разделять задачи по нескольким категориям, например, я разделял задачи по типу работ: Разработка, Тестирование, Документирование.
Упомяну для любопытных, что в MS Project также можно задать правила рисования диаграмм на основе свойств задач. При желании, можно сделать так, что задачи по разным компонентам будут иметь разные цвета, причем цвет будет определяться только свойством задачи, его не нужно задавать вручную для каждой задачи. Такие настройки не требуют написания сриптов, а делаются штатными средствами настройки диаграмм.
Использование пользовательских полей, а также встроенные в MS Project функции фильтрации, сортировки и группировки задач позволяют получить самые разные представления, которые позволяют получить ответы на многие вопросы, которые возникают у руководителя проекта.
Завершение проекта
В конце проекта мы получаем план, в котором все задачи выполнены. Обычно я стараюсь сохранять также и исходный план, хотя бы в качестве базового. Честно говоря, на этом этапе от MS Project мало проку, так как интересуют не плановые значения, а фактические. Какие-то решения этой проблемы предлагает MS Project Server, там есть возможность учитывать фактические трудозатраты, но это уже за пределами данной статьи.
Заключение
Я попытался обобщить свой опыт использования MS Project для практического решения задач, которые возникали передо мной, когда я руководил проектами по разработке ПО. Описанная методика не претендует не универсальность, но она, как мне кажется, достаточно проста и логична, при этом позволяет решать практические задачи руководителя проекта.
Использование этого подхода позволило мне успешно и в срок завершить не один проект.
Правда, случались и сбои. Это происходило, как правило, тогда, когда плохо была проведена подготовительная часть проекта, а именно — постановка задачи. Т.е. в результате проекта получалось не совсем то, что требовалось, а понимание этого приходило слишком поздно.
Наверняка я что-то упустил, не стесняйтесь задавать вопросы.
Как запускать проекты вовремя | Полезное чтение
С ним не соглашаются многие веб-студии и клиенты. Мне было
непросто на него перестроиться. Он требует дисциплины и ответственности. Но одно ясно: с ним проекты открываются
вовремя. В Бюро Горбунова убеждены, что этот принцип применим к любой сфере жизни. Давайте проверим.
Проектная работа бюро
Дизайн-бюро Артема Горбунова создает сайты, фирменные стили, придумывает интерфейсы и навигацию в общественных
местах. Бюро запускает проекты вовремя, потому что следует принципу «ФФФ» — fix time, fix budget, flex scope. Чтобы
понять этот принцип, для сравнения разберем типичную схему работы российской веб-студии.
Типичная проектная работа
Первая встреча. Клиент обращается в веб-студию за обновлением сайта. Менеджер составляет
техзадание, календарный план и смету. Заключают договор: веб-студия обязуется создать сайт по ТЗ в указанный срок,
а клиент обязуется эти работы поэтапно оплатить.
Главная страница. Ровно в срок студия присылает клиенту первые макеты главной страницы. Оказывается, клиент ожидал совсем другого, и нужно все переделать. За шесть дней страницу перекрашивают и утверждают. Переходят к внутренним. Небольшое недельное отставание планируют нагнать за счет будущих этапов.
Внутренние страницы. Отставание на 7 дней. Студия отправляет клиенту макеты внутренних страниц,
но клиент в отпуске. Согласование затягивается на две недели. Пока макеты зависли у клиента, дизайнеры получают
другие задачи, а проект на паузе. Спустя три недели менеджер вспоминает о проекте и добивается согласований.
Программирование. Отставание на 28 дней. Макеты закончены, передаем их программистам.
Просим сделать быстрее, чтобы нагнать отставание. Но быстрее не получится: дизайнеры не предусмотрели миллион
нюансов, и на переделку нужно не две недели, а шесть. Менеджер подключает к проекту еще одного дизайнера
и разработчика, чтобы проект шел быстрее. Меж тем, клиент настойчиво интересуется, почему «съехали» сроки.
Кризис. Отставание на 56 дней. Менеджер в панике. К проекту подключается директор студии:
лично едет к заказчику и договаривается об увеличении сроков на два месяца. Клиент соглашается, но не готов
оплачивать дополнительное время. Студия работает бесплатно. + 60 дней в план
Последние доработки. Следующие месяцы студия работает через силу: дизайнеры загружены другими
проектами, у программистов каждый день всплывают новые ошибки, менеджер деморализован и, скорее всего, выпивает.
За неделю до пуска понятно, что сайт сырой: миллион ошибок, всё на «костылях», и клиенту он в целом не нравится.
«На картинках было совсем другое», — говорит, — «Так открывать нельзя».
Клиент присылает досудебную претензию: работы в срок не выполнены, платите штраф. Директор приглашает клиента в ресторан и договаривается об отсрочке.
Проекту добавляют неделю, под личную ответственность директора студии. Он мобилизует все ресурсы и ставит на паузу
остальные проекты. Неделя проходит в аду, потом незаметно вторая и третья.
Запуск. В конце четвертой недели, с трехмесячным отставанием от срока в договоре, хромой
и косой сайт открывают для публики.
Публика никак не реагирует: сайт посредственный.
Веб-студия в минусе: половину проекта сделала бесплатно и в процессе заморозила несколько текущих проектов.
В портфолио этот проект не пойдет, потому что стыдно за результат.
Клиент в обиде: студия его подвела. Пообещала открыть хороший сайт за три месяца, а открыла калеку через полгода.
И тем, и другим кажется, что это просто неудачное стечение обстоятельств: слишком требовательный клиент,
разгильдяи-дизайнеры, сложный продукт, плохое планирование, ленивые разработчики. И что в следующий раз они уж точно
учтут все ошибки и сделают хорошо.
Но это самообман. В следующий раз все будет так же. И вот почему.
План — это иллюзия
Проект — это путешествие из точки «А» («Нет сайта») в воображаемую точку «Б» («Начались продажи с сайта»). На пути
заказчик и исполнитель столкнутся с сопротивлением окружающей среды: дизайнер заболеет, юристы запретят новый
слоган, программисты потребуют больше денег, обрушится база данных, изменится рынок. Что-то всегда происходит.
Наивно думать, что проект пойдет по плану.
План всегда описывает идеальную ситуацию. Никто в здравом уме не напишет в плане «А вот здесь
у нас заболеет дизайнер», «А тут вы захотите все переделать». Менеджер приносит клиенту сказочный план, в котором
все соблюдают сроки, а макеты согласовываются с первого раза. И этот заведомо сказочный план попадает в договор
и смету.
План становится предметом переговоров. «Нет, делать сайт 4 месяца — это слишком долго. Сделайте
за три, и проект ваш». Клиент запросто продавит менеджера по срокам, потому что рисовать план несложно. «Потом
разберемся», — думает менеджер, — «Главное — продать проект».
Исполнители не любят план. «Вы там напланировали себе две недели, но быстрее, чем за месяц
мы это не запрограммируем. Меняйте свои планы, значит. Или переделывайте дизайн». Всплывет это в середине проекта.
К концу проекта всем плевать на план. Клиенту уже не так важно уложиться в сроки, как сделать
хороший продукт: «Мы с вами и так потратили два месяца. Давайте потратим еще два, но зато не будет стыдно».
Исполнителям план изначально не важен, потому что они работают на зарплате. Утром пришли — поработали — поздно ночью
ушли. Сроки — это вопрос менеджера.
Менеджер перестает смотреть в план где-то в середине проекта, потому что план уже давно не соответствует
действительности, а времени его обновлять нет.
Переживает только директор: фирма получила деньги за три месяца работы, а работает уже пять, и конца не видно.
Это не значит, что не нужно готовиться к проекту (сориентируемся, мол, на месте). Наоборот. Зная, что все пойдет
не по плану, нужно готовиться вдвое тщательнее: предусматривать трудности, проводить разведку и тестировать
подрядчиков. Хороший менеджер готов к тому, что его план улетит в мусорное ведро через две недели, но ресурсов и сил
хватит до запуска, причем с запасом.
Без плана нельзя: студии нужно резервировать команду, строить финмодель, считать смету, заполнять кассовый разрыв,
брать новые проекты. Но и по плану нельзя: всегда все идет не так. Чтобы разрешить противоречие, в бюро особый
подход к планированию.
Короткие итерации
Типичный сайт — задача месяца на три. За это время делается главная страница, внутренние, каталог, обратная связь.
Чтобы соблюсти технологию, сначала дизайнеры рисуют картинки, а потом программисты превращают картинки в живой сайт.
Далее — тесты и запуск:
В реальности оказывается, что и дизайн, и программирование занимают больше времени, чем планировалось. А клиент,
к тому же, еще и не хочет принимать работу с первого раза. И сначала опаздывают дизайнеры, потом тормозит клиент,
потом программисты, и, наконец, все разом:
А что если не делать сайт целиком, а открыть только каталог? Информацию о компании поставить в «подвал», главную
страницу пока скрыть и запустить сайт с одним каталогом. Как тогда будет выглядеть план проекта? Не забудем, что
дизайн нужно еще и согласовать:
Здесь меньше макетов, согласований, разработки и тестирования. Даже если что-то «съедет» по срокам, нам легче
это контролировать. В итоге мы быстрее запустим продукт, клиент начнет продавать, а мы поймем, работает ли вообще
идея с каталогом.
Если работает, мы запланируем вторую короткую итерацию для главной страницы. Пока мы будем ее делать, клиент будет
зарабатывать на запущенном каталоге, а мы получим обратную связь от пользователей.
Мы все равно составляем план, но теперь это не многомесячный монстр, а короткие управляемые итерации. Мы меньше
рискуем и быстрее выводим продукт на рынок. В короткой итерации меньше гибкости и легче зафиксировать время
и деньги.
Фиксированное время и деньги
В бюро принят диктат дедлайна: дата запуска никогда не сдвигается. Это осознанный принцип, которому следуют бюрошники
и с которым должен согласиться клиент. Никто в бюро не рассматривает вариант сдвинуть дату запуска, чтобы «допилить»
проект. Этого варианта не существует. Все решения по проекту принимаются исходя из того, что дата запуска
не сдвигается.
Время фиксируется по двум причинам: философской и чисто прагматической.
Философское объяснение в том, что время человеческой жизни — ограниченный и невосполнимый ресурс. Каждый проживет
ровно столько, сколько ему отмерено, и разбрасываться временем на плохое управление — слишком жирно. Всем хочется
сделать больше.
ВРЕМЯ — ОГРАНИЧЕННЫЙ И НЕВОСПОЛНИМЫЙ РЕСУРС. ВСЕМ ХОЧЕТСЯ СДЕЛАТЬ БОЛЬШЕ
Прагматическая причина в том, что незапущенный проект — это потерянные деньги клиента. Когда в проект начинают
добавлять время, появляется соблазн заодно добавить и функций. Проект заболевает «фичеризмом». Клиент требует
добавить в каталог интеллектуальный поиск, но это отодвигает старт еще на две недели. Эти две недели сайт мог бы
работать и продавать.
Где время — там и деньги. Нельзя бросать в проект новых людей на «затыкание дыр»: вы тратите в первую очередь
их время. Нельзя из-за аврала бросать в проект новые деньги — это незапланированные траты, которые могут поставить
под угрозу коммерческую целесообразность всего проекта.
Любые решения по проекту принимаются исходя из того, что у нас нет дополнительных денег и времени. Что остается?
Гибкая функциональность
А вот с функциональностью все куда интереснее. Секрет бюро в том, что частью функций нового продукта можно
жертвовать, чтобы открыть продукт высокого качества и вовремя.
Запланировали, что у каждого раздела в каталоге будет индивидуальный дизайн. Понимаем, что
индивидуальный не успеем. Советуемся с клиентом: как мы навредим проекту, если все разделы будут одинаковые?
Оказывается, особенно не навредим. С согласия клиента «отрезаем» эту функциональность и запускаемся в срок. В бюро
это называется «пофлексить», от flex scope, «сделать охват проекта гибким».
Пишу рассылку о технологии
переговоров Джима Кемпа. Понимаю, что текст сдавать через два часа, а я охватил только половину книги. Ничего
страшного. Говорю, что в следующем выпуске мы продолжим разбирать эту технологию, и через неделю дописываю все
остальное. Со стороны кажется, что я сделал серию рассылок, на самом деле — просто «пофлексил» половину.
В бюро открыли «Коворкафе» — это кафе, коворкинг, офис бюро, место
встречи с клиентами и зал для проведения курсов. Когда его открыли, это были голые стены, столы, стулья, интернет,
розетки и электрочайник. Было пустовато, но этого хватало, чтобы проводить курсы и работать. Это была первая
итерация.
За два года в «Коворкафе» появилась вывеска, декор, маркиза, цветы; хозяин-«бюриста»,
который заботится о гостях; кофемашина, меню с закусками и десертами; абонементы, библиотека, пуфики и музыка. Новые
функции добавлялись постепенно, и все это время «Коворкафе» приносило пользу.
Отрезанную функциональность можно вынести в следующий этап проекта, а из ее запуска сделать инфоповод. Так как
пользователь не знал, что мы изначально планировали эту функцию, для него это будет выглядеть как забота,
а не запоздалые доделки проекта.
Как «флексят»
В бюро формализованы способы «отрезания» функций:
Заменить часть системы, решив задачу. Вместо формы обратной связи указать эл. адрес для писем. Вместо кнопки «Оформить заказ» — телефон отдела продаж.
Зафиксировать. Сделать часть системы статичной. Не программировать блок «самые популярные товары», а поставить в него товары вручную.
Перенести на следующую итерацию. Если совсем не успеваем — анонсируем функцию и пишем «откроется скоро».
Запрещено: закрывать глаза на недостатки. При любых обстоятельствах нельзя жертвовать качеством. Простое решение не значит плохое, а отсутствующая функция лучше, чем сломанная.
Всего в бюро применяется десять способов «флексить». Они подробно описаны в курсе «Управление
проектами, людьми и собой»; кое-что можно подсмотреть в раздаточных материалах.
Кажется, что гибкая функциональность несовместима с проектной работой. Клиент заказал сайт из 10 страниц, а бюро
предлагает ему открыться с тремя. Для многих клиентов это выглядит как попытка сделать меньше за те же деньги, и они
не соглашаются так работать. Это нормально. Не каждая компания станет клиентом бюро. Часто такие компании все еще
верят, что уж в следующий-то раз они точно найдут себе нормальных подрядчиков.
Жизненный принцип
«ФФФ» изначально сформулирован для разработчиков программ, сервисов и приложений. В Бюро Горбунова этот принцип адаптировали для дизайна. Однако в бюро уверены, что он применим к чему угодно. «ФФФ» — это больше жизненный принцип, чем технология управления проектами.
Работать по нему невозможно, если вы не умеете договариваться. Клиент должен согласиться «пофлексить» функцию ради
запуска в срок. В идеале — самостоятельно предложить, что и как «пофлексить». В бюро запрещен «скрытый флекс» —
когда исполнитель отрезает функцию в одностороннем порядке, не договариваясь с клиентом.
«ФФФ» заставляет команду проекта больше думать о цели, а не упираться в конкретные дела и задачи.
Нет времени открыть сайт из десяти страниц. Придется подумать, как добиться цели одной
страницей.
К открытию гостиницы не готов ресторан. Придется придумать, как кормить гостей: доставлять
еду в номер, накрыть столы в шатре на природе, договориться с соседними ресторанами.
Для квартального отчета не хватает подробной статистики продаж от отделов. Договариваемся,
что сейчас они пришлют общие цифры, а конкретную статистику внесут в отчет позже и самостоятельно.
Семья планировала поехать в субботу в торговый центр, но у папы на работе завал. Вместо
поездки заказывают товары из интернета.
Система
Подход «ФФФ» трудно применять в отрыве от других принципов бюро:
Техника
переговоров Джима
Кемпа помогает дизайнерам договариваться с клиентом и принимать взвешенные решения. У бюро не бывает «адовых клиентов», потому что любая просьба, даже самая «адовая», рассматривается с точки зрения пользы для проекта и в мире клиента.
Система удаленной работы «Ресурс» помогает встречаться с клиентами по скайпу, даже когда клиент
или дизайнер в отъезде. В бюро создана технология презентации макетов, внедрены правила их показа и хранения,
продуман процесс обсуждения и согласования замечаний.
Метод прогрессивного джипега помогает дизайнерам уже в первый день работы иметь
представление о результате. С каждым днем это представление уточняется. Если дизайнер заболел, у него все равно есть
полное решение задачи, пусть и проработанное не до конца. С некоторыми оговорками его можно показать клиенту.
Принцип
«сделывания» (18+) подразумевает, что задача не сделана, пока она не согласована у непосредственного заказчика — арт-директора или клиента. Мало нарисовать макет — нужно его согласовать, доработать и «сдать», чтобы заказчик принял работу. Ответственность по сдаче работы лежит на исполнителе. Исполнитель сам планирует свое время, чтобы успеть и сделать, и сдать.
Принцип «горы знаний» служит фильтром людей. Чтобы работать в бюро, дизайнер проходит ступени
профессионального роста, осваивает верстку, работу с клиентом, управление временем и проектами, дизайн интерфейса,
текст, юридическую сторону дизайна. Бюрошники, которые стоят на более высокой ступени иерархии, управляют и обучают
младших. Каждая ступень — это пот, кровь и бессонные ночи. До управления проектами доходят только стальные.
Школа стажеров бюро
Миссия бюро — распространение дизайнерских знаний.
Чтобы эти знания накопить, бюро делает проекты. Чтобы распространить — проводит курсы и дает советы. В 2014 году
в бюро открылась «Школа стажеров» —
школа дизайна, которая ставит на поток подготовку дизайнеров в системе знаний бюро. В школе дизайнер обучается
не только типографике, верстке и интерфейсу, но и переговорам, тексту, юридической стороне дизайна и управлению
проектами. Принципу «ФФФ» в школе посвящена отдельная дисциплина.
Автор — Максим Ильяхов.
Запуск проекта на сrowdfunding площадке Boomstarter
НОВИСТИКА. УЧЕБНИК ТВОРЧЕСТВА, ПРОЕКТ ЗАПУЩЕН!
Для начала, что же такое сrowdfunding? Википедиа пишет:
«Краудфа́ндинг (народное финансирование, от англ. сrowd funding, сrowd — «толпа», funding — «финансирование») — это коллективное сотрудничество людей, которые добровольно объединяют свои деньги или другие ресурсы вместе, как правило через Интернет, чтобы поддержать усилия других людей или организаций (реципиентов). Сбор средств может служить для различных целей — помощь пострадавшим от стихийных бедствий, поддержка со стороны болельщиков, поддержка политических кампаний, финансирование стартап-компаний и малого предпринимательства, создание свободного программного обеспечения, получение прибыли от совместных инвестиций и многого другого.
Изначально должна быть заявлена цель, определена необходимая денежная сумма, составлена калькуляция всех расходов, а информация по ходу сбора средств должна быть открыта для всех.»
Если кратко, то это сбор денег по известному методу «с миру по нитке».
Пожалуй самая знаменитая площадка сrowdfunding во всем мире это Kickstarter. Но к сожалению, для размещения там своего проекта необходимо быть только резидентом США.
Аналоги Кикстартера в России. Они есть, но их немного. Крупнейшими, по моим наблюдениями, являются: Бумстартер и Планета.ру. Хотя во всем мире количество краудфандинг площадок стремительно растет и у них появляются свои специализации (отдельно книги, музыка, кино и др.) и конкретная аудитория.
Так вот,
Знакомый профессор, автор многих интересных книг в области экономики, социологии, техники, написал, на мой взгляд, крайне важную и интересную книгу под названием «Новистика. Учебник творчества». К сожалению, ученые в нашей стране народ небогатый, а выпустить книгу хочется. Желание скорее не с целью «заработать», а для того чтобы «Высоким чинам» от образования донести и показать, что лучше детей в школах не накачивать переизбыточной информацией и научными фактами, а детей нужно учить видеть и понимать «как все работает», «что можно изменить в лучшую сторону» в нашей жизни, т.е. творческому подходу ко всему с чем они сталкиваются повседневно. И изменения в лучшую сторону в нашей жизни не заставят себя долго ждать.
Я предложил автору книги обратиться к системе краудфандинга. Эта система имеет большую перспективу и думаю она многих заинтересует. Может быть и Вас, читающих эти строки? 🙂 Тем более, что если проект соберет требуемую сумму на издание книги, то она покажет, что люди действительно не равнодушны к будущему наших детей и страны и тем весомее будут наши слова в министерстве образования.
Изучая отечественные площадки краудфандинга, в итоге было принято решение запускаться на Boomstarter (с учетом размера комиссии и целевой аудитории).
Надеюсь, многих заинтересует моя цель и добавит Вам мотивации, чтобы запустить уже свой собственный проект 😉 А от Вас мне бы хотелось получить обратную связь и отзывы.
Спасибо!
Успех проекта. Проект собирает необходимую сумму
Искреннее желание помочь человеку издать книгу