Управление проектами «для чайников»: как все успевать и ничего не забывать

Выбор технологий

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

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

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

Перед тем как выбрать что-то конкретное, подумайте несколько раз

Составьте пресловутую таблицу преимуществ с коэффициентами важности для проекта.
Данный пример составлен для вымышленного проекта:

Название  функционала проекта.

Коэффициент важности для проекта

Работа с формами

3

Роутинг

1

Простота написания анимации

0,3

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

Название  функционала проекта.

Коэффициент важности для проекта

Технология 1

Технология 2

Работа с формами

3

+

±

Роутинг

1

+

±

Простота написания анимации

0,3

+

—

Исходя из данных таблицы, мы понимаем, что у “Технология 2” работа с формами и роутинг хромают, а создание анимации подобно вызову Сатаны. В итоге, удельный вес данной технологии составляет 2. Вы спросите почему 2? Всё просто! Если вы ставите ±, то в данной технологии конкретный функционал реализуем, но с какими-то “костылями”, либо же более трудозатратный. В нашем сравнении выгоднее будет “Технология 1 “, с итогом 4,3. Думаю пояснения по образованию сумм излишни. Данная таблица работает не только с технологиями, но и со всем, что требует сравнения и выбора из списка. Главное — не забывать, что чем больше критериев напишите, тем проще вам будет сделать выбор.

Направленность на достижение конкретных целей

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

Проект обычно предполагает целый комплекс взаимосвязанных целей. Например, основной целью проекта, связанного с компьютерным программным обеспечением, может быть разработка информационной системы управления предприятием. Промежуточными целями (подцелями) могут быть разработка базы данных, разработка математического и программного обеспечения, тестирование системы. В разработке базы данных, в свою очередь, также могут быть выделены цели более низкого уровня — разработка логической структуры базы данных, реализация базы данных с помощью СУБД, загрузка данных и так далее.

Тот факт, что проекты ориентированы на достижение цели, имеет огромный внутренний смысл для управления ими

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

Координированное выполнение многочисленных взаимосвязанных действий

Проекты сложны уже по самой своей сути. Они включают в себя выполнение многочисленных взаимосвязанных действий. В отдельных случаях эти взаимосвязи достаточно очевидны (например, технологические зависимости), в других случаях они имеют более тонкую природу. Некоторые промежуточные задания не могут быть реализованы, пока не завершены другие задания; некоторые задания могут осуществляться только параллельно, и так далее. Если нарушается синхронизация выполнения разных заданий, весь проект может быть поставлен под угрозу. Если немного задуматься над этой характеристикой проекта, становится очевидно, что проект — это система, то есть единое целое, складывающееся из взаимосвязанных частей, причем система динамическая, и, следовательно, требующая особых подходов к управлению.

Цель бизнес-плана

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

1. Анализ собственной перспективы реализации проекта (если бизнес-план составляется для личного пользования предпринимателя).
2. Убеждение инвестора в целесообразности участия в проекте (если бизнес-план составляется с целью привлечения инвестиций).
3. Убеждение банка в прибыльности кредитуемого мероприятия (если бизнес-план составляется для получения бизнес-кредита).

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

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

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

Шаг 1. Определите владельца проекта и ответственного

В начале проекта сразу найдите владельца, именно он принимает решение о запуске проекта. Например, это может быть собственник бизнеса или руководитель отдела маркетинга. Помимо владельца определите ЛПР — лиц, принимающих решения. К ним могут относиться сотрудники ниже рангом: маркетинг, PR. Или даже те, кто участвует в задаче только косвенно, но влияет на принятие решения. К таким людям можно отнести, например, финансового директора, который «оплачивает банкет», но не имеет маркетинговых компетенций. Ваша задача — выяснить зоны ответственности всех ЛПР и их вовлечённость в проект.

Хорошо, когда владелец участвует в проекте и общается с вами — тогда обсуждать и вносить изменения можно через него. Если владелец не принимает участие в обсуждениях, говорите только с ЛПР. Иначе может получиться так: вы будете встречаться и принимать решения, а потом придётся всё переделывать, потому что это не устраивает ЛПР.

Пример.

Основатель и генеральный директор.
Владелец проекта.

Операционный директор.
ЛПР.

Директор отдела маркетинга.
Главный ЛПР.

Digital-маркетолог.
ЛПР.

Штатный дизайнер.
ЛПР.

Понятие и суть бизнес-плана

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

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

Цель и задачи бизнес-плана можно наглядно представить вот такой схемой:

Какую методологию брать будете?

Команда есть, руководитель проекта тоже. Цель определили. И что с этим всем делать? Как работать-то?

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

Его здесь хорошо дополняют agile-методологии.

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

Антон Сержантов,

agile-коуч

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

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

Владимир Завертайлов,

руководитель scrum-студии «Сибирикс»

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

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

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

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

Шаг 6. Оцените задачи

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

1. которые вы делали раньше;
2. которые вы не делали, но знаете, как;
3. которые вы не делали и о которых вам нужно узнать больше.

Первую группу вы оцениваете как всегда. Вторую оцениваете на основе своего опыта и интуиции, умножаете на 1,5–2. То же самое с третьей, только умножаете уже на 2–3. Сначала может показаться, что это слишком много, но к концу проекта вы будете думать иначе.

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

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

План для маэстро

ГОСТ Р ИСО/МЭК 15910-2002технический проектПоппендикминимумудовлетворенность online-калькуляторJIRA: границы проекта

ранее приведенную1.макеты пользовательского интерфейсаuser story

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

2.3.оценку трудозатрат4.

О ключевых элементах успеха

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

• Отражаются объективные факторы и обстоятельства, которые благоприятно повлияют на развитие бизнеса.
• Приводится обзор мер, который видится предпринимателю решающим для достижения положительного результата.

Под ключевыми аспектами убеждения подразумеваются:

• Информационный, который демонстрирует уровень владения предметной областью
• Терминологический, показывает владение отраслевой и маркетинговой терминологией
• Логический, указывает на логичность изложения мыслей в бизнес-плане
• Методологический, проводит параллель с международными и национальными стандартами в области планирования бизнеса
• Лексический, отражает грамотность и полное соответствие деловому стилю изложения

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

Напишите свой вопрос в форму ниже

Планирование

Принципы планирования

1. Всякая работа займёт ровно столько времени, сколько на неё отведено или больше. (Закон Паркинсона).
2. Люди откладывают всякую работу на последний момент времени. (Синдром студента).
3. Люди склонны давать оптимистичные прогнозы относительно трудоёмкости небольших работ.Исключая случаи когда их лишали премии за нарушение оценок, в этих случаях оценка пессимистичная и завышенная.
4. Люди дают пессимистичные прогнозы относительно трудоёмкости больших работ.Потому, что хотят успеть «наверняка» и провести «победоносную войну».
5. Люди никогда не начинают работу именно в то время, когда работа запланирована и никогда не заканчивают выполнение задачи вовремя.
6. Все проекты связаны с неопределённостью. (Закон Мёрфи — если что-то может пойти не так, именно это и произойдёт. Мы никогда не знаем, когда закон Мёрфи себя проявит).
7. Реальность никогда не будет соответствовать плану. Как бы хорошо мы не планировали наш план не будет охватывать всё.
8. Объем работы по проекту не постоянен. Суть Проекта – в создании чего-то уникального, и мы никогда не знаем “что именно нужно делать”, пока не начнем это делать.
9. Люди никогда не делают ровно то, что написано в техническом задании. Они делают больше или меньше или другим способом.
10. Люди могут эффективно выполнять только одну задачу в один момент времени.

Описание слона не по ГОСТ

завершения
всегдапо мере необходимости

1. Перечень требований заказчика (которые будут реализованы в рамках проектного решения).
2. Список определений и сокращений.
3. Перечень нормативных документов, регламентирующих автоматизируемый процесс.
4. Описание порядка применения программного обеспечения (use case), которое может включать:
   • описание автоматизируемого процесса (как правило, в формате BPMN – не забывайте отмечать, как выполняется то или иное действие: автоматически, автоматизировано или вообще без компьютера) и предполагаемого результата;
   • перечень ролей и их полномочий;
   • определение необходимости ведения истории изменения объектов учета (необходимость хранения и последующего анализа предыдущих значений атрибутов объекта) — пренебрежение данным пунктом может увеличить время разработки в разы;
   • определение необходимости протоколирования действий пользователей (определение таких действий, связь с историей изменения объекта).
5. Описание доработки:
   • описание новых классификаторов и требования по доработке имеющихся, определение порядка их сопровождения;
   • описание пользовательского интерфейса (UI) и правил его отображения (в случае, если в рамках проектного решения определяются схемы процессов, все экранные формы должны быть связаны с действиями на этих схемах); 
   • описание печатных отчетов и правил (алгоритмов) их формирования.
6. Электронный обмен данными:
   • описание форматов и регламента взаимодействия через API;
   • описание форматов и регламента (последовательности) загрузки внешних данных в «ручном» режиме (в виде файлов);
   • описание форматов и регламента (последовательности) выгрузки данных в «ручном» режиме в виде файлов.

   В качестве примеров проектного решения по электронному обмену данными может здорово пригодиться пакет стандартов, разработанный некоммерческим партнерством «Стандарты некоммерческого обмена информацией» (партнерство распалось в 2011 г., в настоящее время эти стандарты продолжает сопровождать компания 1С). Также могут помочь нормативно-эксплуатационные документы, размещенные на техническом портале Системы межведомственного электронного взаимодействия (СМЭВ).

7. Определение полномочий доступа:
   • определение атомарных действий, по которым должно (может) производиться ограничение доступа, определение иерархии этих действий;
   • определение перечня атрибутов объекта, по которым должно (может) производиться ограничение доступа.
8. Сценарий (синопсис) проведения тестирования, который включает последовательность выполнения и названия отдельных тестовых заданий, а также ожидаемый результат выполнения этих тестовых заданий. При наличии времени на проектирование в этот раздел могут включаться описание тестовых заданий (по шагам) и краткое описание тестовых данных. Именно в этом разделе должны находить отражение пользовательские истории (собранные и запротоколированные во время проведения информационных обследований), начальные условия выполнения программы, условия (ограничений) успешного завершения, альтернативные варианты завершения процесса. Сценарий проведения тестирования в обязательном порядке должен быть «узнаваем» со стороны заказчика.

checklist

Обучение с помощью проектов

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

• самостоятельность;
• востребованность;
• реалистичность.

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

Профессиональное самовоспитание подрастающего поколения предполагает применение проектной методики.

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

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

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

Методы проектирования

Основная статья: Методы проектирования

• Эвристические методы
  • Метод итераций (последовательного приближения)
  • Метод декомпозиции
  • Метод контрольных вопросов
  • Метод мозговой атаки (штурма)
  • Теория решения изобретательских задач (ТРИЗ)
  • Метод морфологического анализа
  • Функционально-стоимостной анализ
  • Методы конструирования
• Экспериментальные методы
  • Цели и виды экспериментальных методов
  • Планирование эксперимента
  • Машинный эксперимент
  • Мысленный эксперимент
• Формализованные методы
  • Методы поиска вариантов решений
  • Методы автоматизации процедур проектирования
  • Методы оптимального проектирования

Лучше один раз увидеть

представляют
вне конкуренции множество разнообразных средствFigmaAxureАСУ IDEIntelliJ IDEAPhpStormтрех кликов

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

1. Все элементы управления формой должны располагаться в верхней части в форме панели инструментов — при этом вероятность того, что пользователь «потеряет» их, сводится практически к нулю. При этом практика показала целесообразность отказа от строки иерархического меню  в пользу ленточного интерфейса (ribbon). 
2. Для всех списков, как правило, на ленте должны присутствовать четыре группы элементов управления:
3. При формировании статистических отчетов (в т.ч. и для вывода на печать) желательно не создавать специализированные формы для предварительной настройки этих отчетов. Сама списковая форма с ее возможностями выборки, сортировки и отображения объектов должна обеспечивать предварительную настройку требуемых отчетов. Другими словами по возможности отчеты должны формироваться на основе выбранных критериев при формировании списков.

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

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

1. В случае, если в ходе разработки требуются изменения уже существующих интерфейсов, не стоит изобретать велосипед. Здесь лучше всего себя проявил Paint.NET (с помощью которого, кстати, подготовлены картинки к этой статье). Не имеет смысла заново перерисовывать формы, проще изменить готовый скриншот.
2. Если вы разрабатываете новый интерфейс пользователя, а ваш заказчик — «бумажная крыса», в таких случаях лучше всего себя зарекомендовал  MS Visio со стандартным набором элементов управления. Не раз видел, как заказчик, который наотрез отказывался посмотреть разработанный интерактивный прототип, увлеченно обсуждал предлагаемые проектные решения, выполненные с использованием MS Visio, и рисовал очень интересные каракули на макетах, распечатанных на бумаге в цвете, выполненных в стиле привычного ему Windows. 
3. Если вы разрабатываете новую подсистему, а ваш заказчик —  продвинутый пользователь, то интерактивные прототипы вне конкуренции. При этом с наилучшей стороны показал себя подход, когда эти прототипы строятся на основании того же самого фреймворка, который используется для создания интерфейса пользователя. В случае одного из моих успешных проектов прототип программного обеспечения строился на основе инструментов DHTMLX. Вместо базы данных для имитации работоспособности использовались статичные XML-файлы, сформированные на основе примеров таблиц, которые предоставил заказчик. Представления (view), созданные аналитиками в ходе прототипирования, использовались как заготовки для работы программистов. За счет низкого порога вхождения по использованию данного фреймворка, трудозатраты аналитиков на создание прототипов пользовательского интерфейса были соизмеримы с трудозатратами, если бы те же макеты экранных форм создавались в MS Visio. Правда, при этом некоторые представители заказчика не понимали, что еще надо программировать после того, как им продемонстрировали «рабочую программу».

Составьте план проекта

В 5 шаге вы получили задачи и подзадачи. Чтобы не выбиться из графика и сдать проект в срок, следите за выполнением задач. Воспользуйтесь программой по управлению проектами, например, Microsoft Project.

Интерфейс MS Project

В MS Project можно выбрать один из встроенных шаблонов и подстроить его под свой проект: поставить задачи, распределить их между командой, определить длительность и установить зависимости между ними. Здесь же можно делать отчёты — стандартные ежеквартальные или в режиме реального времени. Для наглядности можно использовать диаграмму Ганта.

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

Сейчас мы пользуемся таск-трекером Jira + Confluence. До этого был Trello и Basecamp, некоторые сотрудники пользовались другими трекерами — кому что удобно. Из-за работы сразу в нескольких трекерах сложно аккумулировать знания, которые мы получали на проектах, поэтому мы сделали общую систему.

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

Итого

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

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