Определение целей и задач проекта. Планирование проекта в разных планировщиках задач Данный проект но и являются

Проектный подход к достижению поставленных целей даёт возможность:

1) Объединять значимые для компании цели, достижение которых возможно в обозримом будущем.

2) Эффективнее планировать выделение средств.

3) Согласовывать действия руководителей и исполнителей.

Что такое проект? Определение понятия

Слово «проект» (projectus) переводится с латыни как «выдающийся, выдвигающийся вперёд, выпирающий». А если воспроизвести это слово на оксфордском лексиконе, то получится: "хорошо спланированное начало бизнеса, лично созданная компания или совместный труд, необходимый для достижения конкретных целей". Если подойти к ответу на этот вопрос более детально, тогда проект - это:

• кампания (или список последовательных действий), через которую будут решены некоторые проблемные вопросы или осуществлена блестящая идея;

• одно или несколько разовых заданий, без которых будет затруднена реализация проекта, определение и достижение основных целей;

• временное поручение, которое необходимо выполнить в установленные сроки с задействованием определённого количества ресурсов;

• дело, завершение которого равнозначно получению желаемого результата;

• ограниченная временем и ресурсами совокупность усилий или проведение мероприятий, необходимых для приближения к цели (все работы осуществляет специальная созданная для таких задач организация);

• список мероприятий, обусловленных временем, реализация которых приведёт к достижению единственно правильного результата; как правило, подобные мероприятия направлены на качественные перемены или разработку нового продукта (услуги);

• популяризация и структуризация нескольких идей и определение целей проектов, являющихся частью главного проекта, совместное выполнение всевозможных планов действия (мероприятий);

• проектирование последовательных операций, реализация которых позволит достичь неких результатов в перспективе;

• детальное изложение действий, запланированных в конкретный период и в конкретных условиях, цель которых - изменение ситуации в будущем;

• мероприятие, требующее составления детального плана и предусматривающее проведение ряда операций, направленных на кардинальное изменение существующей ситуации;

• мечта, течение, механизм, посредством которого можно реализоваться в будущем, с последующим использованием пречисленных здесь понятий для самореализации;

• исследование интересующего предмета в настоящем ради составления плана действий на будущее.

По разновидности проекты могут быть личными (например, разработка персонального сайта) или развивающими, заставляющими социум измениться (иногда - до неузнаваемости).

Отличительные признаки

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

Если конечный результат должен быть получен к заранее оговоренному сроку, значит, отличительная черта данного проекта - лимит времени. А когда для претворения проекта в жизнь необходимо участие специалистов из разных сфер, определение проекта может «уместиться» в одном слове - интердисциплинарность.

Риски

Риски и сложности в разработке и управлении проектом возникают, главным образом, в том случае, если подобные задачи ранее не решались. Рискованность проекта напрямую зависит от его масштабов и экипировки исполнителей (наличия необходимой техники, материалов и инструментов). Множество рисков, например, несёт инвестиционный проект, определение источников которого невозможно без получения необходимых знаний.

Финансирование инвестиционных проектов

Определение проекта, финансируемого извне:

1) Наружное финансирование может осуществляться за счёт государства, финансовых и нефинансовых предприятий, населения, зарубежных инвесторов и дополнительных средств, находящихся в распоряжении учредителей.

2) Акционирования и паевых взносов.

3) Инвестиционных банковских кредитов и облигационных займов.

Ограничивающие факторы

Любой проект состоит из трёх ограничивающих факторов:

• Сроки выполнения. Чтобы правильно рассчитать продолжительность задачи разбивают на конструктивные блоки, затем оценивают «подъёмность» объёма работ и полученные результаты сверяют с опытом успешных разработчиков.
• Ресурсы. Например, человеческий ресурс: управление сотрудниками, определение работ проекта с использованием их талантов и способностей.
• Результат. Составляющими этого пункта являются: финансовая состоятельность, умелый маркетинг, экономическая эффективность, профессионализм руководителя проекта и исполнителей.

Проектные программы

Рассматривая работу какой-либо организации, почти всегда можно отметить два ключевых варианта её деятельности, существующих единовременно:

• так называемая "текучка" и периодически повторяющиеся операции или сделки;

• проекты.

Главные различия между этими двумя видами деятельности - цикличность повторяющихся процессов и подчинённость конкретному графику действий, ориентированных на достижение уникального результата.

К примеру, на производстве, выпускающем автомобили, работа цеховых конвейеров, бухгалтерские расчёты и обработка корреспонденции относятся к повторяющимся операциям. Повторяющиеся сделки характеризуются довольно значительной степенью определённости и требуют системного подхода, цель которого - повысить производственную эффективность уже существующих средств и оборудования.

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

• проекты координационного становления (реорганизация предприятия, внедрение новшеств и так далее);

• проекты становления бизнеса (исследовательские разработки, производство новейших продуктов, формирование прогрессивных течений, выход на неизвестные ранее рынки);

• проекты формирования (сопровождения) инфраструктуры (плановая починка, замена оснащения и так далее);

• коммерческие планы, осуществляемые в рамках договора (изготовление и доставка оригинальной либо непрезентабельной продукции, застройки, оказание оригинальных услуг).

Этот перечень можно продолжить, если дополнить его примерами из разных индустриальных сфер, имеющих существенные отличия по масштабности работ, срокам выполнения, количеству работников и значимости результатов.

Нацеленность на получение результата

Цель любого проекта - получение конкретного результата, то есть, достижение цели. Конкретная цель - вот движущая сила проекта.

Определение проекта подразумевает выполнение взаимозависимых задач. Проекты, ориентированные на достижение цели, наделены глубоким внутренним смыслом, необходимым для их реализации. Первоочередная черта управления проектами - точность в определении и формулировке целей, начиная с верхнего уровня и заканчивая детализированной формулировкой менее значимых целей.

Помимо этого, проект можно расценивать как пошаговое достижение предельно ясно сформулированных простых задач, а его продвижение - как достижение более значительных задач. Проект считают завершённым только после того, как достигнута конечная цель.

Что такое портфель проектов

Портфель (Portfolio) - сборник проектов (программ), объединённых с одной целью: сделать управление более комфортным и успешным. Собранные в портфеле проекты могут быть не взаимосвязанными, не объединяться общей целью и существовать независимо друг от друга.

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

Начнем с того, что в различных методологиях управления проектами описываются немного отличающиеся друг от друга модели ролей в проекте. Отличия кроются как в составе ролей, так и в выстраивании ответственности за параметры проекта.

Рассмотрим ролевую модель, которая описана в самом популярном в мире (если верить исследованиям PWC) подходе к управлению проектами - PMBOK.

В этой ролевой модели очень четко описана ответственность руководителя проекта за все аспекты проектного треугольника: руководитель проекта должен обеспечить достижение всех целей проекта через выполнение запланированных работ в срок и в бюджет.

На примере кейса хочу продемонстрировать, как может происходить выбор конкретных лиц для выполнения описанных ролей в проекте.

Давайте рассмотрим проект по автоматизации процессов взаимоотношений с клиентами (CRM) в небольшой частной компании. Кто из сотрудников компании, внедряющей у себя CRM, может стать заказчиком такого проекта?

На мой взгляд, заказчиком проекта нужно назначать лицо, которое больше всего заинтересовано в результатах проекта. Вторым важным критерием выбора заказчика является наличие возможности у заказчика уделять достаточно времени работе в проекте.

Чтобы принять решение о назначении заказчика в проекте CRM, предлагаю последовательно ответить на следующие вопросы:

1. Сотрудники каких подразделений компании будут использовать программный продукт, автоматизирующий CRM?
2. Кто из руководителей этих подразделений больше всего заинтересован в том, чтобы CRM помогла ему решать его задачи?
3. Может ли потенциальный заказчик проекта CRM тратить на него 2-4 часа в неделю?

По данным Standish Group, на каждую $ 1000 стоимости времени людей в ИТ-проекте приходится принимать 1,5 решения. Предположим, проект внедрения CRM-системы оценен в 50 000$, из них стоимость лицензий - 10 000$, а оставшиеся 40000$ - стоимость времени людей. По статистике Standish Group получается, что в этом проекте нужно будет принять около 60 важных решений, причем заказчик должен принять участие в 20% из этих решений. Предположим, что в среднем на решение одного вопроса заказчик тратит 4 часа. 12 важных решений по 4 часа на каждое - получается 48 часов.

Если продолжительность проекта составляет примерно полгода, то 48 часов как раз распределятся на 24 недели по 2 часа в неделю. Однако заказчик будет тратить время не только на принятие важных решений. Ему нужно читать и согласовывать документы по требованиям к CRM, участвовать в приемке промежуточных результатов проекта, изучать отчеты руководителя проекта о ходе проекта. На эту работу, с моей точки зрения, уйдет не меньше времени, чем на принятие решений. Отсюда и появляется расчет, что на данный проект заказчику нужно планировать от двух до четырех часов в неделю. Конечно, это очень приблизительный расчет и в каких-то аналогичных проектах у заказчика может уходить намного больше времени на проект.

Для нашего кейса допустим, что в результате ответов на первые два вопроса определились два кандидата на роль заказчика проекта - начальник отдела продаж и начальник отдела маркетинга. Осталось уточнить по обеим кандидатурам, могут ли они выделять на проект еженедельно от двух до четырех часов.

В своей практике я встречал ситуации, когда никто из потенциальных кандидатов не хотел брать на себя роль заказчика проекта. Причина такого поведения, скорее всего, в том, что они опасались брать на себя дополнительную ответственность. Во-первых, на работу в проекте нужно время, а если оперативные задачи могут отнимать все рабочее время, то проектные придется решать в нерабочее время. Во-вторых, если проект окажется провальным, то за него, как минимум, не похвалят. Вот и скажите, кому захочется брать на себя роль заказчика проекта при таком раскладе? Бывает, что у кого-то из руководителей подразделений появилось понимание, что без решения стоящей перед проектом задачи в дальнейшем решать оперативные задачи будет все сложнее. В таком случае у него все-таки есть мотивация стать заказчиком.

Итак, возможны следующие варианты: либо кто-то из этих двух кандидатов сам вызовется стать заказчиком проекта, либо заказчика выберет директор компании, либо старт проекта будет отложен, т.к. пока еще никому результаты проекта не нужны.

Предположим, все развивается по оптимистичному сценарию: один из кандидатов (пусть это будет директор по маркетингу) сам попросил назначить его заказчиком проекта после того, как ему объяснили, за что он будет отвечать и какими полномочиями он обладает в рамках проекта.

Спонсором проекта CRM, очевидно, станет директор компании. В небольшой компании эту роль больше некому поручить, ведь при возникновении ситуаций, когда руководитель проекта и заказчик не имеют полномочий или не хотят брать на себя ответственность за принятие решения, они пойдут к директору.

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

Так кого назначить руководителем проекта в нашем кейсе?

На самом деле при внедрении CRM руководителем проекта может стать представитель ИТ-компании, которая будет внедрять программный продукт. Но в таком назначении есть смысл, только если ИТ-компания берется сделать проект «под ключ», т.е. готова нести ответственность за достижение всех целей проекта. В случае если ИТ-компания выполняет только часть работ по проекту, придется назначать руководителя проекта из числа сотрудников нашей компании. И если у назначенного на роль руководителя проекта сотрудника нет навыков управления проектом, выполнение проекта в срок и в бюджет с достижением целей - под большим вопросом.

Предположим, что было принято решение отдать ИТ-компании проект CRM «под ключ», и вопрос с назначением руководителя проекта решен - им станет профессиональный руководитель проекта со стороны ИТ-компании, которую еще предстоит выбрать.

Ну и четвертая роль - команда проекта.

В проекте CRM будет 2 команды - со стороны заказчика и со стороны ИТ-компании. Команда со стороны заказчика будет участвовать в задачах по сбору требований и тестированию доработанного функционала CRM, а команда ИТ-компании будет дорабатывать продукт в соответствии с требованиями и готовить его к промышленной эксплуатации.

В команду проекта со стороны заказчика должны войти руководители всех подразделений, которые будут использовать программный продукт CRM. А заказчик проекта будет отвечать за выполнение назначенных его команде задач в срок и в соответствии с требованиями к результатам задач.

Пожалуй, мы разобрались в предложенном кейсе, хотя сделали много допущений. В реальном проекте по внедрению CRM при распределении ролей в проекте все может оказаться запутаннее и сложнее.

Делать какие-то обобщения на примере рассмотренного кейса не стоит. Проекты бывают очень разными как по своему масштабу, так и по предметной области. В некоторых случаях рассмотренная модель ролей может оказаться слишком простой и неэффективной. Например, в методологии управления проектами Prince 2 рассмотрена куда более сложная модель ролей, чем в PMBOK.

Несмотря на это, надеюсь, читателем стала понятна точка зрения на ролевую модель в проекте, описанная в подходе PMBOK.

И в завершение - одно наблюдение: чем четче описаны ответственность и полномочия для всех рассмотренных в статье ролей, тем лучше для всех участников проекта. А отсутствие одной из этих ролей приведет к резкому снижению шансов проекта на успех!

Как мне кажется, лучше потратить время до старта проекта на определение необходимых ролей и назначение на эти роли конкретных лиц, чем по ходу разбираться с вопросами «кто виноват?» и «что делать?».

Успехов вам в определении ролей в проектах!

Шаги от «А» до «Я» для новичков и опытных

Проект : комплекс спланированных действий, предпринимаемых для решения проблемы определенной целевой группы, ограниченных по времени и ресурсам, с конкретными результатами.

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

Основные требования, которым должен отвечать проект:

актуальность – причина, основания реализации проекта должны соответствовать требованиям времени, отдельной целевой группы или иным аспектам, объясняющим появление идеи проекта;

время – проект должен быть ограниченным по времени;

ресурсы – проект должен иметь четкое описание потребностей;

оценка качества и результатов – шкала оценки эффективности проекта определяется в соответствии с вашими целями, но результаты, к которым вы стремитесь, должны быть четкими, поддающимися анализу и осмыслению.

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

Как написать и оформить проект? Шаги от «А» до «Я»

Шаг №1: Определитесь с идеей, проанализируйте проблему.

Что бы вы хотели изменить?

Чего и каким способом (в самом общем плане) бы вы хотели достичь?

Какую проблему хотите решить?

Записали ответ → перешли к определению сферы проектной деятельности, определению проблемы, над которой вы будете работать.
Проанализировали проблему → определили, что хотите изменить → возникла проектная идея → переход к детализации и описанию проекта.

Шаг №2: Пишем цель проекта.

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

Цель должна формулироваться так, чтобы её достижение полностью решало возникшую проблему. Формулировка цели должна опираться на формулировку проблемы. Можно сказать, что цель - это проблема наоборот.

Задайте вопросы для цели своего проекта:

Есть ли точное выражение того, что именно должно быть в итоге реализации проекта?

Сможем ли мы увидеть и измерить результаты проекта в целом и его отдельных частей?

Реальна ли поставленная цель? Возможно ли достижение заявленной цели с учетом имеющихся ресурсов?

Какая польза или выгода будет получена в результате достижения цели командой проекта, другими заинтересованными сторонами?

Шаг №3: Пишем задачи проекта.

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

В ажно помнить! Задач может быть несколько, все задачи - шаги к достижению цели, связанные между собой и связанные с целью проекта.

Используйте глаголы . Например, если вам надо построить дом, то задачами будет: заложить фундамент, возвести стены, построить крышу, провести коммуникации, сделать внутреннюю отделку и т.д.

Проверьте . Задачи должны полностью «закрывать» решение проблемы (поставленную цель).

Проанализируйте . Задачи должны быть результативными (в итоге изменения после проекта складываются из конкретных результатов).

Шаг №4: Проверяем цель и задачи по критерию smart.

Смотрим на нашу цель и задачи, проверяем их по критерию SMART, при необходимости корректируем.

Например: Цель: «Строительство дома» - может быть конкретизирована по критерию SMART следующим образом: «Строительство и сдача в эксплуатацию 2-этажного, 6-квартирного дома для семей молодых специалистов поселка Вычегда ко второму кварталу 2014 года».

Шаг №5. Из задач строим логическую цепочку действий.

Определили цель и задачи → Приступаем к планированию: как все это будет.

Из каждой задачи строим логическую цепочку действий: как мы добьемся результата. Иногда помогает нарисовать всю цепочку действий и заданий, чтобы понять логику проекта по каждому из направлений.

Например, если мы говорим о строительстве дома для семей молодых специалистов, то блоки задач у нас могут быть связаны с:

непосредственно строительством

согласованиями с органами государственной власти

с работой с целевой аудиторией – семьями молодых специалистов

работой с прессой по PR проекта и события в целом.

Эта логическая цепочка поможет нам написать план-график проекта в его логической последовательности.

Шаг № 6. Пишем план действий, график выполнения работ.

План определяет порядок выполнения всех работ: он описывает, что, кто и когда будет делать, в логической последовательности + дает понять, какие ресурсы необходимы. При планировании можно использовать различные формы, графики, планы.

Например: План реализации проекта. Пример №1

План реализации проекта. Пример №2

План реализации проекта. Пример №3

Также полезно будет сделать сетевой план – график.

Шаг №7. считаем, сколько будет стоить наш проект.

Каждый этап реализации проекта требует определенной затраты денежных средств и ресурсов:

сколько денег требуется для реализации проекта? На что они будут потрачены?

из каких источников предполагается получить деньги? Гранты, субсидии, спонсорские средства, иное?

Этот раздел проекта должен очень точно соотноситься с другими разделами проекта, особенно с механизмом реализации и календарным планом проекта.

Возможный вариант сметы расходов в рамках проекта:

«Бюджет» (смета) должен быть расписан по статьям.

Основные расходы:

аренда помещений и коммунальные платежи

командировочные и транспортные расходы

оборудование

связь и коммуникации

проведение специальных мероприятий

издательские расходы

расходные материалы

и другие прямые расходы, которые непосредственно идут в рамках вашего проекта.

«Прочие расходы» - это необязательная статья, которая включается в бюджет, если имеются расходы, не получившие отражения в других статьях. Данная статья должна быть особенно тщательно аргументирована.

«Оплата труда» - включает непосредственно заработную плату персонала проекта и привлекаемых на время по договору специалистов, а также “Начисления налогов на доходы” – 35,8% от общего фонда оплаты труда персонала и привлеченных специалистов.

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

Если организация, вы или спонсоры предоставляют для реализации проекта какую-либо оргтехнику, то в столбце «имеется» стоит указать её примерную стоимость с учетом срока эксплуатации.

В столбце «требуется» останется указать размер средств, которых недостает организации для реализации проекта.

Шаг №8. Пишем результаты.

При составлении плана действий и расчете бюджета у нас может возникнуть понимание, что результаты могут быть еще больше, чем мы планировали. Важно, чтобы наши результаты соответствовали цели проекта.

В проекте результаты можно прописывать текстом, здесь мы предлагаем вам заполнить рабочий листок по определению результатов:

Количественный результат (что будет сделано?) - фиксирует количество оказанных услуг, участников мероприятий, получателей конкретной помощи, количество выпущенных книг и т.д.

Качественный результат (что изменится?) - должен отражать позитивные изменения, которые произойдут в результате проведения мероприятий, оказания услуги и т.д.

Эффективность - соизмеримы ли полученные результаты с затраченными усилиями.

Критериями оценки эффективности проекта являются результаты, которые демонстрируют, насколько хорошо разработчики понимают, к чему они стремятся, и как будут этого достигать.

Шаг №9. оформляем проект.

Оформленный проект обычно содержит следующие разделы:

Краткая аннотация проекта: кратко опишите вашу идею (3-5 предложений), цели, результаты (не более 1 листа А4, 12-14 шрифт)

Подробное описание проекта:

Актуальность проблемы, почему именно ваш проект важен и нужен.

Цели и задачи проекта.

Целевая группа проекта: на кого рассчитан ваш проект, для кого вы его делаете.

Механизм реализации проекта: этапы, содержательная деятельность, мероприятия и т.д.

Календарный план реализации проекта (помните про наглядность, графики приветствуются).

Бюджет (смета).

Конкретные ожидаемые результаты (количественные и качественные), критерии и методы оценки результатов, эффект проекта в долгосрочной перспективе.

Возможное дальнейшее развитие проекта, если предполагается.

приложения (фото-материалы, схемы, эскизы и т.д.)

Оформление текста проекта также важно, как и его содержание. Используйте крупный шрифт (не менее 12) и полуторный интервал. Выделяйте главное, структурируйте текст, чтобы его было легче читать, используйте заголовки и подзаголовки, жирные шрифты и подчеркивания, маркированные списки и т.д.

Если вам необходимо сделать презентацию:

на каждый раздел не более 1-2 слайдов;

шрифт должен быть максимально крупным и читаемым даже издалека, заголовок и текст слайдов презентации должны быть напечатаны одним шрифтом, размер шрифта в презентации рекомендуется использовать не менее 20;

при использовании светлого фона шрифт должен быть черного или очень темного оттенка других цветов (коричневый, синий); при использовании темного цвета фона шрифт - белого цвета;

Многие даже не представляют себе, чем отличается планирование проекта в разных планировщиках задач, хотя отличия есть существенные. Нельзя сказать что у одного планировщика есть только достоинства, а у всех остальных недостатки. Каждый по своему хорош и подходит под те либо иные задачи.

Мысли о будущем, постоянные размышления о том, как сделать больше, порождают такое состояние ума, при котором ничто не кажется невозможным.(Генри Форд)

Чтобы увидеть это все наглядно — решил сделать этот обзор. Специально для вас рассмотрю один и тот же проект в различных планировщиках задач:

• MyLifeOrganized
• Wunderlist
• ToDoIst
• Microsoft To-Do

Для примера беру проект, который я уже рассматривал в своем видео . С реальным проектом будет интереснее.

Как происходит планирование проекта в MyLifeOrganized

Как я планирую свои проекты

Мои проекты в MyLifeOrganized выглядят следующим образом (в обзоре я для удобства отображения не устанавливал сроки и даты начала):

• есть четкая структура что и за чем идет
• используются зависимости — пока одна задача не будет сделана, какая-то другая не сможет начать выполняться ни при каких условиях
• в нужных местах установлены подзадачи по порядку — принцип «подачи патронов в обойме пистолета»

Что это нам дает?

Благодаря такому построению проектов у нас формируются списки активных действий, которые могут быть выполнены здесь и сейчас.

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

А с учетом использования контекстов, этот список разделен на места, где я могу это выполнить и на инструменты, которые мне для этого нужно:

Учтите, что это всего лишь один проект для примера. В реальной жизни такие списки формируются из

• множества проектов
• повторяющихся задач
• разовых (важных и не очень важных)

Без нужных навыков, упомянутых инструментов и построенной системы отследить и построить это все в отсортированные списки будет затруднительно.

Каких функций MLO нет в других планировщиках

Вычисляемый процент выполнения проекта

В зависимости от приложенного усилия к выполнению каждой задачи проекта автоматически формируется процент выполнения проекта. На самом проекте визуально видно насколько вы продвинулись, а какие проекты до сих пор не начались. Наглядно и удобно!

Статусы проекта

Если у вас 50-100-200 проектов, которые отображаются единым линейным списком, и вы будете пытаться ежедневно их все контролировать — на долго вас не хватит. MyLifeOrganized позволяет разделить проекты на статусы по состоянию проекта: Не начался, Идет, В ожидании, Завершен. Таким образом вы можете отсортировать большое количество проектов, которые вы в ближайшее время не будете выполнять, а сфокусироваться на небольшом количестве проектов со статусом «Идет».

Создать проект из шаблона

Если один и тот же проект повторяется у вас с какой-то периодичностью, вы можете один раз создать шаблон, а потом при необходимости создавать новый проект из шаблона.

Для примера, у меня есть шаблоны проектов моих индивидуальных тренингов. При поступлении нового заказа я на основании шаблона создаю новый проект и называю его именем обучаемого. При минимальных затратах на планирование — весь процесс тренинга я держу под контролем.

Задачи по порядку

После создания проекта мы часто видим, что огромное количество подзадач проекта вывалились в наш список активных действий. Хотя этого реально избежать всего лишь постановкой одной галочки «Подзадачи по порядку». Получается принцип обоймы в пистолете — пока один патрон находится в стволе, остальные ждут своей очереди и «не высовываются». Аналогично реализуется при необходимости и в МЛО: если задачи идут последовательно друг за другом, выставляем «Подзадачи по порядку» и в активных видим только одну задачу, на выполнении которой нам нужно сфокусироваться.

То, что «Подзадачи по порядку» действуют только на один уровень вложенности задач, позволяет нам назначать проектам индивидуальную последовательность со всевозможными поворотами событий.

Зависимости

Бывают ситуации, что проект зависает, и может продолжаться только после выполнения какого-то стороннего проекта. Как поступать в подобных ситуациях?

В МЛО переплетение проектов между собой не составляет никакой проблемы. Не нужно «придумывать велосипед» как это все отобразить и настроить. Устанавливаем зависимость одной задачи от другой (а можно даже и от нескольких). Пока задача не будет выполнена, остальные в активных действиях показываться не будут, не зависимо от их свойств и приоритетов.

Отложенная зависимость позволяет творить еще большие «чудеса». Например, вы делаете ремонт в квартире, выровняли штукатуркой стены и теперь вам нужно наклеить обои. Без отложенной зависимости, как только вы выполните задачу «Штукатурка», вам планировщик сразу предложит клеить обои. Сколько дней нужно, чтобы высохла штукатурка? Допустим, 3 дня (я не силен в ремонтах и строительстве). Ставим отложенную зависимость показывать задачу «Обои» через 3 дня после выполнения задачи «Штукатурка». Гениально!

Как такой план выглядел бы в Wunderlist

Для простых проектов, типа этого, вполне подойдет. Проект видно в целом, но не совсем понятно что, когда и зачем нужно делать.

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

• После многих лет использования МЛО, не могу привыкнуть к подзадачам в Wunderlist. Они ни в списках не показываются, хэштеги в них не отображаются как ссылки. Больше похоже на чек-лист
• Корректировать выполнение можно только с помощью срока. Если даты нет — задачи можно увидеть только в списке с проектом и больше нигде.

Как такой план выглядел бы в Todoist

Древовидная структура задач очень похожа на структуру в MyLifeOrganized. Но из-за отсутствия отображения активных задач в отдельном списке, эта древовидная структура фактически бесполезна. Можно сказать, что дерево задач сделано не для работы, а для общего представления.

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

• Не возможно работать со списком как с проектом: добавлять информацию, описывать желаемый результат, прописывать критерии выполнения проекта. Это просто название и все!
• Бесполезное дерево задач в проекте. Больше запутывает, чем помогает. Был бы сложнее проект — запутался бы точно.
• Корректировать выполнение можно только с помощью срока. Если даты нет — задачи можно увидеть только в списке с проектом и больше нигде

А есть ли проекты в Microsoft To-Do?

Даже не знаю, стоит ли делать скриншот. Проектов просто нет. Списки есть, а проектов нет….

Может быть у меня какое-то особенное понятие про проекты, но такой список можно сделать в любом текстовом редакторе или написать на бумаге. В чем особенность?

И, кстати, я уже очень сильно сомневаюсь что Microsoft To-Do сможет заменить либо составить альтернативу, такому монстру продуктивности, как Wunderlist. Произошел вброс информации о супер-продукте, о котором я сразу же высказал свое мнение в своем блоге. Прошел почти месяц, а ни одной функции в планировщик не добавилось. Вообще ничего не добавилось. После анонса даже ни одной статьи не было по этому вопросу…

Может обломались? Оказалось «не по Хуану сомбреро», как говорят…?

Подводим итоги

Каждый планировщик по своему хорош и преследует определенные цели. Мне кажется, что дело

• в привычке
• в необходимой глубине проработки и планирования проектов. Не всем же быть стратегами
• в готовности попробовать что-то новое. Многие не хотят переходить на продвинутые продукты только потому, что «это же нужно в них разбираться»

Если бы я делал только то, что хотят от меня люди, они бы до сих пор ездили на каретах. (Генри Форд)

Спасибо за чтение этой статьи — я потратил много времени, создавая её для вас. Буду благодарен, если вы дадите свою обратную связь. Без информации от вас этот блог не может быть полным. Так что давайте оставаться на связи!

• Не забудьте оставить комментарий — ваши выводы, мысли и замечания на вес золота. Я читаю их все, обязательно отвечаю и создаю новые статьи на их основе.
• Поделитесь ссылкой на эту статью — если то, что я написал, полезно, интересно или трогательно для вас, сообщите об этом друзьям и знакомым.
• Присоединяйтесь ко мне в Instagram — там вы найдёте ситуации, мысли, впечатления из моей повседневной жизни, мои собственные взлёты и падения в борьбе за гармонию, а также множество фотографий, на которых изображено, как я пытаюсь следовать своим увлечениям и принципам жизни.
• Присоединяйтесь ко мне на

Подлинный оптимизм покоится не на убеждении, что все будет хорошо, а на убеждении, что не все будет плохо.
Жан Дютур

Управление рисками - пожалуй, самая часто обсуждаемая и вместе с тем самая непонятная часть науки об управлении. Если рассматривать ту область менеджмента, с которой я знаком лучше всего, - управление проектами, то и здесь как у хороших врачей: два врача - четыре диагноза и, как минимум десяток способов лечения, противоречащих друг другу. Спорят даже о том, что такое риск, не говоря уже о том, что с ним делать (и делать ли).

Изучение опыта работы коллег по цеху и своего собственного позволило сделать несколько интересных умозаключений, которые я и постараюсь обобщить в этой статье.

Для начала попробуем определиться с тем, что же такое риск. Если взять один из стандартов по проектному управлению, то прочитать можно следующее:

«риск проекта - это неопределенное событие или условие, которое в случае возникновения имеет позитивное или негативное воздействие по меньшей мере на одну из целей проекта, например сроки, стоимость, содержание или качество» .

Другие источники дают похожие определения. Что в них важно? На мой взгляд, четыре слова: «неопределенность», «цель», «позитивный», «негативный». Обычно больше всего вопросов у неподготовленной аудитории вызывает третье из перечисленных слов: словосочетание «позитивный риск» многим режет ухо. Оставим пока «позитивные риски» в покое, мы вернемся к ним через некоторое время, когда разберемся с остальными составляющими определения.

Первое слово, которое характеризует риск, - это «неопределенность» или «вероятность». Если мы точно знаем, что риск может произойти, то это уже не риск. Это уже факт, который уже случился или случится в ближайшем будущем. Риск - это событие, которое произойдет (или не произойдет) в будущем, но знаем мы о нем сейчас. И управление рисками - это управление еще не произошедшими событиями (которые могут и не произойти). Мы управляем рисками ровно до тех пор, пока они не реализуются. Если риск реализовался - событие произошло, то все наши действия после - это уже не управление рисками. Это - управление изменениями.

Второй не менее важной характеристикой проектного риска является «цель проекта». Т.е. потенциальное событие можно считать риском для проекта, только если это событие влияет на достижение цели. Любую даже самую серьезную по последствиям ситуацию нельзя считать риском, если она не влияет на достижение целей. Например, землетрясение на другой стороне Земли нельзя расценивать как риск проекта, если оно никак не воздействует на его поставки, ресурсы или заинтересованных сторон.

Тут надо сделать два уточнения.

Первое касается ограничений проекта. Можем ли мы сказать, что цель проекта достигнута, если, например, нарушены сроки? В некоторых случаях - да, в некоторых - нет. Реализовать проект и покорить Эверест - не одно и то же. Если для скалолаза важно водрузить флаг на вершине и почти не важно, когда и какой ценой, то для менеджера проекта водружение флага - это только начало финишной прямой. После этого нужно еще убедить почти всех окружающих, что флаг водрузили именно на ту гору и потратили не больше времени, чем было необходимо, с деньгами тоже все в порядке, и, наконец, что флаг вообще именно тот, который нужно было тащить на вершину. И чем сильнее нарушены ограничения проекта, тем меньше шансов, что проект будет успешным.

Второе уточнение про возможные риски проекта и риски продукта. Есть риски, которые явно не влияют на ограничения проекта, но могут свести на нет все преимущества от его реализации. Например, строительство завода может стать неинтересным заказчику, если цены на продукцию упадут ниже определенного уровня. Формально проект может быть успешным, все ограничения будут выполнены, но цель достигнута не будет.

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

При всем этом чаще всего рисками считается не только то, что препятствует достижению целей, но и вызывает отклонение от плана. В этом есть здравое зерно. Сорванный срок первого этапа или невыполненные требования могут стать причиной прекращения проекта, даже если прямой угрозы целям нет. Т.е. можно переформулировать часть определения риска как «возможное событие, которое приводит к отклонениям от плана проекта».

Теперь вернемся к позитивным рискам и одновременно затронем риски негативные. Позитивные риски обычно называют возможностями, а негативные - угрозами. Если мы посмотрим на возможности с точки зрения достижения целей и планов проекта, то здесь любая возможность сделать быстрее или дешевле и будет тем самым позитивным риском.

Если продолжить аналогию с автогонками, то все, что приближает нас к финишу или позволяет экономить топливо, можно считать позитивным риском. Вернее, «может приблизить» или «может сэкономить», поскольку риски - всегда события вероятные.

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

Представим себе, что у нас идет сложный проект. Сейчас не важно, в какой именно сфере. Мы спланировали основные этапы и приступили к реализации первого из них. И сейчас у нас есть риск того, что заказчик изменит требования, что, в свою очередь приведет к задержке сроков этапа. Вероятность этого риска наши эксперты оценили в 60%. Это достаточно большая величина, и мы начали с этим риском бороться: продумывать пути выявления требований на ранних этапах, продумать возможные сверхурочные работы или, может быть, заранее готовить пользователей к тому, что много ждать не стоит. При этом есть и другой вариант.

Можно сразу заложить в базовый план возможное изменение сроков и связанную с ней задержку. Если это сделать, то появляется положительный риск: заказчик может все-таки требования и не поменять, и вероятность у него будет 40% (поскольку вероятность изменения мы оценили в 60%).

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

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

В любой ситуации руководитель проекта может выбрать, как минимум, одно из двух: запланировать менее вероятный вариант развития событий и потом «управлять рисками» или отразить в плане более вероятный и, соответственно, менее рискованный путь. В случае с перегруженным специалистом это означает, что можно оставить все как есть и считать, что человек вполне в состоянии справиться с пятью полноценными задачами одновременно и, конечно, есть риск того, что не справиться (и этим риском потом можно будет управлять). А можно взять двух человек и разделить работу между ними, и тогда на управление рисками придется тратить значительно меньше усилий.

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

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

В любом проекте есть место возможностям, и важно лишь правильно их спланировать и постараться использовать.