С1. Введение

1. Все знают то, что для успешного завершения проекта, нужно им управлять, но вот как это делать? Какие инструменты использовать и в каких случаях какие технологии уместны, а какие нет?
2. В одном случае инструмент может быть полезен, в другом вреден;
3. В данной статье рассмотрим возможные варианты технологий и ситуации их применения;

С2. Понеслася!

1. Техника «Описание проекта» или «Отчет по проекту»
   1. Это основная техника, которая нужна практически в любых проектах.
   2. Можно использовать документ Word, Google Docs, или любой другой носитель, который можно периодически обновлять. Я когда-то использовал Word+DIRECTUM, сейчас использую Мегаплан. Там есть соответствующее поле у записей проектов;
   3. Состав описания зависит от размера проекта и ситуации
      1. Обязательные части
         1. Результат (куда идем, и как выглядит ситуация в которой мы должны оказаться в конце проекта)
         2. Цель (зачем идем, можно в общих выражениях аля «чтобы мир во всем мире», хотя чем конкретней, тем лучше, например, «повышение качества услуг» или «увеличение доходов» или «снижение операционных затрат»);
      2. Дополнительные части добавляем по ситуации
         1. Участники (контакты, роли …)
         2. Заметки
         3. Ссылки на важные материалы
         4. Любые другие разделы по желанию
   4. Материалы по теме
      1. Волшебное искусство планирования (там, где описание с чего начинается план)
      2. http://ru.wikipedia.org/wiki/GTD (надо читать саму книгу конечно, там по сути тоже речь о том что план начинается с описания результата, и дана хорошая техника того, как именно надо описывать результат)
2. Умение мыслить в стиле ВИСИ
   1. Кто не в теме, читаем описание техники «Будьте ВИСИ»
   2. Это также одна из наиважнейших техник, которая требуется на любом проекте.
   3. Но не все способны ее освоить, т.к. требуется природная предрасположенность к этому стилю мышления.
3. GTD
   1. Это название техники и книги Д.Алиена
   2. Гибкая и универсальная техника, подходящая для управления проектами лучше, чем что либо изученное мной ранее (а изучил много чего). Не зависит от платформы, можно хоть на бумаге применять.
   3. Кроме результатов, позволяет снизить напряжение на мозг и бомбежку воображения.
   4. В общем если задач у вас стало очень много, вы начали путать маму с папой или дочку с сыном, то вам срочно нужна эта книга. А лучше не доводить до этого состояния и освоить эту технику заранее.
4. Реестр проектов
   1. Это просто ведение списка проектов, с приоритетом, плановыми датой начала, датой окончания, описанием, фактическими датами и конечно же с указанием ответственного.
   2. Помогает в том случае, если проектов много, их нужно, во-первых, раскидать между людьми, во вторых по себе любимому видеть приоритеты (дабы не распылять силы), ну и просто эти данные иногда полезны при использовании дополнительных инструментов.
   3. Эта техника бесполезна в том случае если у вас 1-2-3 проекта, и/или вы один в поле воин.
   4. Чтобы понять смысл этой техники нужно, во-первых, изучить книгу GTD, а во-вторых, иметь соответствующий опыт.
5. Ведение списка задач в проектах
   1. Тут нужно сразу остановиться на ключевых элементах
      1. Доступ к списку нужен всем участникам, которые могут быть в разных организациях и раскиданы по территории. Да и просто бывает, что идея догонится вас дома и надо сразу привязать ее к контексту, чтобы мозг не нагружать.
      2. Тут же нужны обсуждения.
      3. Учет времени.
      4. Контроль сроков, состояния задач, ответственных.
   2. Пару месяцев назад начал искать подходящий инструмент и остановился на 2-х:
      1. Мегаплан
         1. Продуман, прост, удобен, дизайн от Артемия Лебедева;
         2. Соответствует техникам ВИСИ (п.2) и GTD (п.3)
         3. Стоит копейки, если брать под задачи и проекты.
         4. Чисто отечественный продукт;
         5. Прочий функционал стоит уже дороже, но лично мне он нафиг не нужен, он у меня на других платформах реализован.
         6. Поддержка мобильников в планах
         7. Мой выбор из-за п.1 и 2.
      2. Тимлаб
         1. Сложноват, интерфейс далек от эргономики
         2. Соответствует технике GTD (п.3), но не поддерживает ВИСИ (п.2).
         3. Бесплатен, как следствие заметны тормоза
         4. Есть поддержка русского языка
         5. Функционал зашкаливает, тут вам и WiKi и Jabber и много чего еще
         6. Есть поддержка мобильников
         7. Простота в использовании и соответствие ВИСИ для меня слишком важны, и даже важнее халявы, потому Тимлаб оставил в сторонке, но слежу за обновлениями, и когда они реализуют поддержку ВИСИ, то может быть даже перейду на него.
   3. Конечно все это нужно лишь там где проекты ресурсоемкие и долгоиграющие. Примерно от 2-х месяцев. Там где меньше, можно использовать п.4 (просто вести реестр проектов)
6. Отчет по проекту
   1. Тут конечно на любителя, но я не даром назвал эту технику ключевой в своей прошлой статье…  1С Предприятие. 4 ключевые проблемы проектов внедрения
   1. Если соотносить ее с вышеназванными техниками, то:
      1. она объединяет в себе все основные элементы перечисленных выше технологий;
      2. ее можно применять зная обычный Word совершенно в полевых условиях и с деревянными людьми (кому тот же Мегаплан или эл.почту не освоить за все время проекта).
      3. да и просто ее освоить легко;
   2. У нее нет ограничений по масштабу… как минимум у меня лично есть проект в 7 чел/лет, с командой из 10 спецов и создание системы на 1000 пользователей, только лишь при использовании этой техники. Проект, которому все эксперты пророчили гибель, т.к. там были нарушены все базовые принципы проектного подхода. Но проект удалось вырулить, хоть и ценой отказа от личной жизни и урезанием премии всей команде из-за минусовой рентабельности.
7. ТЗ
   1. Самое главное это отличать ТЗ на программирование и ТЗ на внедрение.
   2. Это две совершенно разные задачи, мешанина которых приводит к провалу.
   3. В ТЗ на внедрение нужно ставить запрет на разработку и закреплять перечень процессов которые будут охвачены.
   4. А на все разработки, если без них ну ваще никак, выносить в ТЗ на разработку, где уже прописывать все требуемые алгоритмы и условия.
   5. Вообще стиль и состав ТЗ на внедрение пока что передается лишь между внедренцами. Мне его передали уважаемые люди умеющие реализовывать крупные проекты, я этот стиль передавал своим ребятам. ГОСТ есть только на ТЗ для программирования. Особенности описания ТЗ на внедрение надо как то будет сесть и попробовать выразить словами ) Хотя сам навык придет лишь с опытом в любом случае.
8. Устав проекта
   1. Спорный документ, использование которого нужно лишь с пониманием
   2. Вообще многие вещи, которые обычно пишут в Уставе, лучше сразу прописывать в ТЗ на внедрение (не путать с ТЗ на программирование)
   3. Но бывает так, что ТЗ уже написано, и вам его дают как данность. А в команде проекта куча быдла, без таких понятий как отвага и энтузиазм. Умеющих лишь свои должностные обязанности выполнять и то спустя рукава. Тут можно прописать п. Мотивация, с бонусами и штрафами. Тогда даже из быдла можно сделать людей прямо во время проекта.
   4. Или люди начинают от ответственности уходить, вилять… тогда можно п. Ответственность добавить и там записать все.
   5. Или в ТЗ забыли результат, цели и структуру задач описать. Тоже в целях вытаскивания проекта из жопы - это можно в Устав закинуть.
   6. Если видишь, что в проект залезла куча идеологов, со своими видениями правильности решения задач, просто в устав добавляешь нужные нормы, обосновываешь верхам, согласовываешь, утверждаешь. Дальше, если видишь что та или иная идея, действие нарушают или грозят нарушить норму и увести проект в жопу, то берешь идеолога, тыкаешь его носом в норму устава, и посылаешь на три буквы.
   7. В общем, Устав - это такой документ, который нужен как антикризисный инструмент, решения ошибок которые были допущены при постановке задачи в ТЗ или обнаруженных проблемах уже в ходе проекта. Хотя если проект знакомый и в ТЗ все риски предусмотрены точной постановкой задачи, то от Устава можно отказаться.
9. Программно-портфельные технологии из PM BOK
   1. Нужны когда вы начинаете отвечать не просто за какие то проекты, а за целые направления в крупных организациях и нужно свести все проекты в управляемую ситуацию;
   2. Основная ошибка в России это опять же усложнения. Взять тех же чиновников и ФЦП Электронная Россия или ФЦП Информационное общество.
   3. Ошибка в том что они употребляют слово Программа, но мало кто из чиновников понимает суть этого слова.
   4. Взять ту же Европу, там аналогичные программы называются просто «План действий «Е-Правительство 2011-2015″. И описаны очень простым и доходчивым языком, а как известно чем больше людей участвуют в задаче, тем проще нужно объяснять ключевые элементы деятельности.

С3. Резюме

1. Сразу оговорюсь, что это мое ИМХО основное на эмпирическом знании. Ни один ученый сидящий в каком нибудь НИИ не является для меня авторитетом. Единственные кого я слушаю это людей с практическим опытом.
2. Если вы точно знаете как управлять проектами, хотя не один проект в своей жизни еще не реализовали, то рекомендуется свои мысли оставить при себе, даже если вы отвечали за целый этап внутри проекта. Этап это не проект.
3. Под проектами понимается действие, со сроком и бюджетом. Выполнено в срок и в бюджет. Тепличные условия когда кучка программистов сидят и размышляют о правильности решения без ограничения срока и бюджета… проектом как мы знаем можно назвать лишь с натяжкой. Это просто игра в проект. Хотя часть описанных технологий конечно же пригодятся и в этом случае.
4. Основная полезность этих техник пригодится тем у кого есть задача, ресурсоемкая, сложная, с участниками от 3-х человек, где нужно не просто ковырять компьютеры и программы, а нужно еще охватывать и направлять множество людей (пользователей, сотрудников), при этом сверху на вас давит срок и бюджет,  и кровь из носу нужно сделать результат, уложившись в ограничения. Вот где вся веселуха!