Boatman's Home:  О сайте   Новости   Карта  
Статьи и заметки о менеджменте и системном анализе в ИТ + мысли о трудовых отношениях, рынках труда, услуг и программных продуктов
Это страница на старом движке. Новые статьи здесь
2009-12-24 04:04    Boatman   Обсудить в Google Groups   Перейти на страницу обсуждений

Данная статья создана для размещения на сайте boatmanshome.ru. Автор и обладатель исключительного права на эту статью - Нужненко Сергей Александрович.
Для данной статьи автор разрешает размещение ссылок и цитирование, а так же воспроизведение в личных и учебных целях.
Без согласования с автором запрещается для данной статьи или любой ее части воспроизведение в коммерческих целях, а так же любые распространение, публичный показ, импорт с целью распространения, прокат, переработка, сообщение для всеобщего сведения.
Для согласования видов использования статьи можно связаться с автором по e-mail: haron@ru.ru с пометкой в теме "Boatmanshome-text-use".

Планирование проекта внедрения

Аннотация
Введение
В чем проблема
Какие бывают аналитики
Несколько зарисовок
   Шаблон ФТ - почти сказка
   Брильянтовая рука
   Обратный клапан
   Матрешка
   Access denied
   Мы делили апельсин
   Грузчики
Модель проекта
   Проблемы в проектах и их причины
   Риски, форс-мажор и результаты проекта
   Корневые причины проблем
Некоторые базовые принципы проектного управления
   Тест
   Маленькое экономическое введение
      Заинтересованные стороны и интересы
      Перетягивание одеяла
   Договариваемся на входе
   Учет проектов и закрепление рабочих групп
   Календарно-ресурсное планирование
   Фиксация приоритетов, рисков, допущений и требований
   Сквозная линия напряжения
   Главный секрет качества
   Ритм
   Правило проектного треугольника
   Технологичность
      Деление работ
      Инструменты выполнения работ
   Модель проектной работы
      Результат
      Работа, исполнители и инструменты
   Процесс планирования от технологии
Участие аналитика в планировании
   Общие положения
   Работа аналитика
   Сбор данных
   Анализ
   Синтез
   Представление и согласование
Стратегия
   Применение стратегического анализа
   Стратегия №1 - планируйте
   Стратегия №2 - устав
   Стратегия №3 - обеспечить работу всем необходимым
   Стратегия №4 - Документарный цикл
   Стратегия №4а протоколы - малый документарный цикл
   Стратегия №5 явное управление точностью решений и неопределенностью
   Стратегия №6 - бойтесь "культа Карго"
   Стратегия №7 всем строиться
Методы и приемы выполнения аналитических работ
   Сбор информации
      Обследование
      Совместная рабочая группа
      Макеты и прототипы
      Опытная эксплуатация
      Раннее согласование
   Анализ и синтез
   Согласование
Заключение

Аннотация  ^

17 ноября 2009 года я выступал на конференции Req Labs 2009 с докладом на тему "Задачи и функции аналитика требований в области планирования и управления проектом". По мотивам доклада написана эта статья, ее можно считать текстом доклада и пояснением к презентации, слайды которой с небольшими поправками перешли в иллюстрации к статье.

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

В этот момент произошло событие, которое меня убедило в своей правоте: вышла замечательная книга Тома Демарко, Тимоти Листера, Стива Макменамина, Джеймса и Съюзен Робертсонов и Питера Хрущка "Балдеющие от адреналина и зомбированные шалонами". Прочитав эту книгу я понял, что некоторые идеи и наблюдения, которые я обсуждаю в статье - это не моя личная негативная статистика или особенности отечественного ИТ, а закономерности, действующие во всем мире.

В книге изложены паттерны и антипаттерны приводящие к успеху или провалу ИТ-проектов. Под несколько другим углом относительно моей статьи там отмечены практически все отклонения и проблемы, которые я привожу в разделе "Несколько зарисовок" и множество других, которые я не привожу.

После описания отклонений в проектах пути книги и статьи расходятся. Книга - это отличный сборник на тему "что такое хорошо и что такое плохо в ИТ проекте".

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

Введение  ^

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

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

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

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

По маленькой статистике, собранной мной за предыдущих 1,5 года проектной работы и индивидуального консультирования, абсолютно все руководители и ключевые специалисты утверждают, что знают теорию: читали и разбираются (поверим им на слово) в PMBOK, RUP, TOGAF и других страшных словах.

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

Нет планов: технологического, коммуникационного, управления и т.п. 85%
Нет соглашения о моделировании 80%
Нет управления внутренним качеством 80%
Нет шаблонов документов 75%
Очевидные ошибки целеполагания 67%
Формальный подход к работе без учета внутренних потребителей 65%
Не используется сетевой график 60%
Грубые ошибки в оценках сроков и стоимости 56%
Нет состава и сроков работ 50%
Отсутствие доступа к адекватным потребителям 47%
Нарушения предпроектной технологии 46%
Пренебрежение требованиями адекватных потребителей 45%
Не сформулированы цели 40%
Нет состава РГ 15%

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

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

Оставшаяся половина не завершилась никаким результатом, даже формально.

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

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

Хотелось бы наблюдать обратную картину, чтобы хотя бы 80% завершались успешно, а еще лучше - все 100%.

Данная статья посвящена отклонениям в управлении проектами, порождающим риски и проблемы, которые я наблюдаю сегодня в отечественной сфере ИТ и консалтинга.

Мы поговорим о планировании консалтингового или внедренческого проекта с точек зрения руководителя проекта и аналитика.

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

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

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

В чем проблема  ^

Обсудим, в чем проблема и почему это проблема.

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

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

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

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

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

Все, что заведомо предназначено для извлечения прибыли без создания прибавочной стоимости, находит свои определения в Уголовном Кодексе РФ, в Кодексе об Административных Правонарушениях и других подобных документах, но к бизнесу относится слабо.

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

Чтобы не погружаться в философский диспут о том, что такое хорошо и что такое плохо, просто определим, что нормальный результат - это создание автоматизированной системы, полезной для потребителей при уровнях риска в пределах 10%. Это означает, что в 9ти случаях из 10ти лучше получать результат оговоренного на старте проекта качества и объема за оговоренные на старте сроки и стоимость.

Согласен, что это не совпадает даже с общемировой статистикой успешности ИТ-проектов. Пусть пока будет 25% риска, пусть даже, просто < 50%, но никак не 80-90%, которые мы наблюдаем в отечественном ИТ.

Для тех, кому интересно то же, что и мне, есть смысл читать дальше.

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

Я попробую, соблюдая приличия, раскрыть тему неудач, рисков проектов внедрения и как с этим бороться.

А пока последняя оговорка: кто такой аналитик.

Какие бывают аналитики  ^

Речь пойдет о трех терминах:
- аналитик требований,
- системный аналитик,
- бизнес-аналитик.

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

Чтобы понять различие между ролями, нужно понять области бизнеса, с которыми обычно приходится иметь дело. В самой простой классификации таких областей четыре:
- Бизнес в целом;
- Управление;
- Отдельные предметные области по получения каких-либо конкретных результатов;
- ИТ системы - информация, технологии ее хранения, транспортировки и переработки.



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

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



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

Несколько зарисовок  ^

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

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

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

Шаблон ФТ - почти сказка  ^

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

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

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

В общем, дело большое затеяли.

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

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

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

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

И вообще, выполнили все необходимые повороты, кивки и приседания.

Расклад по приказу выпал такой:
- гадюкинская (по размещению штаб-квартиры) группировка из хозяйских холопов получила задание выполнить обследование с целью написания технических заданий на подсистемы и последующего контроля качества работ (их же люди и писали то ли концепцию, то ли стратегию);
- калиновским выпало руководить затем проектами внедрения (в этой истории мы их больше не встретим);
- из посторонних гастарбайтеров, обретающихся подаянием от дворовых хозяина и мелкой подработкой, выбрали 3-4 бригады субподрядчиков - не работать же самим. Будем звать их "южная группировка".
- смотрящими (на контроль качества документов) встали заморские, видимо, чтобы в ТЗ не попадало то, чего их программа делать не может.

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

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

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

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

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

В один день призывает Ванька наш Безотказный Димку Умного и говорит: "а сделайка нам, Димка, шаблон ФТ, чтобы работа по методике шла. Возьми Кольку Лобастого, пусть он соглашение о моделировании сделает поумнее и вообще давайте там, работайте...".

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

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

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

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

На этом бы и делу конец, да не тут-то было...

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

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

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

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

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

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

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

На все вопросы мастеров и своих менеджеров он отвечал то же самое: "читайте, там все написано".

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

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

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

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

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

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

Решили разбираться - назначили совещание.

Представьте себе эпическую картину: раннее утро, Речка-Вонючка, Калинов мост. На стрелку для серьезного разбора собираются 2 бригады.

Гадюкинские: Ванька наш Безотказный в статусе бригадного командира, Димка Умный - автор шаблона ФТ и смотрящий на том проекте, с которого все началось, Колька Лобастый - автор соглашения о моделировании, Елена Прекрасная - руководитель аналитической группы гадюкинских, держащая все шаблоны и регламенты по процессам разработки ФТ, пара смотрящих за проектами менеджеров.

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

Из рядов "южных " выступает менеджер проекта со стороны исполнителя и держит такую речь:
- Вот у вас в шаблоне отчета об обследовании дана раскладка процессов для одного юридического лица, а у нас в организационном объеме проекта 3 уровня юридических лиц (и 15 организаций): центр, дочки, внучки. Если мы будем следовать шаблону - у нас будет десятиуровневая нумерация разделов, в которой вы же сами и не разберетесь.
- Вот вы пишете в шаблоне ФТ, что оргструктура должна быть показана на диаграмме организационной структуры юрлица, а на приложенной для примера схеме изображена совсем другая диаграмма. И еще в нескольких местах точно так же картинка не совпадает с текстом.
- Вот вы требуете приложить матрицу участия подразделений в процессах, но список видов участия в пояснениях один, а в примере матрицы - другой.
- Вот вы строго требуете выносить на диаграммы верхнего уровня (VAD) абсолютно все продуктовые и информационные потоки. Если мы это сделаем, то диаграмма верхнего уровня не поместится даже на стене зала совещаний - не то, что на столе. Шутка ли - 15 организаций с их процессами и взаимодействием между собой.
- Все люди рисуют на EPC диаграмме носитель информации, например, документ в статусе, а у вас информационные потоки показаны техническими терминами - зачем?
- Вы требуете использовать VAD только на диаграмме верхнего уровня, а дальше использовать EPC и не использовать промежуточную декомпозицию на VAD, но если мы это сделаем, то получим верхнеуровневую диаграмму с несколькими сотнями "корабликов" или EPC уровня департаментов, катастрофически перегруженные продуктовыми и информационными потоками - читающий такие диаграммы в них никогда не разберется.
- Вы требуете, чтобы входы и выходы функций были как на EPC, так и в таблицах и в текстовом виде - это тройное дублирование информации, которое никому не нужно.
- Точно так же вы просите представить все процессы и функции в виде иерархического списка и одновременно с этим на одной диаграмме функциональной декомпозиции. Мало того, что это дублирование, так еще и площадь такой диаграммы будет сопоставима с площадью совещательного зала, в котором мы сидим.
- По многим процессам, которые вы требуете описать, нет подхода к четкому проведению границы процесса. Например, что такое управленческий учет, мы до сих пор спорим с представителями функционального заказчика...
- Вот вы требуете заполнить раздел "перечень информационных систем", а какую информацию о системах здесь надо указать не написано.

Много еще крупных и мелких несоответствий и внутренних противоречий в шаблоне ФТ и соглашении о моделировании озвучили южные.
- Поймите, сказал директор по качеству южных, - у нас на вашем проекте работают 20 человек и каждый понимает ваши документы так, как ему кажется. А ведь у вас еще 3 субподрядчика:

Стыдно было гадюкинским аналитикам, и особенно, Ваньке Безотказному - он потом сам в этом признался, когда устраивал легкий разнос Кольке с Димкой за такие некачественные шаблоны. А то, что он сам отправил на утверждение документы в статусе черновиков, все уже и забыли - он сам первый забыл.

С точки зрения оценки потерь от такой коллизии можно сказать следующее:
- примерно 40 аналитиков попали на переделки, которых могло бы не быть. Для хозяина мелочь, а людям неприятно.
- Встречая внутренние противоречия в инструкциях по заполнению, каждый второй аналитик, хотя бы на минуту, да задумался, а то и пошел подергал коллег и своего менеждера. Все потеряли немножко времени и нервов.
- Сроки и так сжатые, а коллизия обнаружилась уже почти в конце проекта. На подготовку повестки совещания, проектов решений, согласование и доведение исправлений до других 3х бригад потратили неделю времени.
- Получение 4х кусков аналитического отчета, а за ними и ФТ, оформленных в разном стиле, стоило смотрящему аналитику от гадюкинских ночных бдений по сборке одного итогового документа для отправки раз в неделю смотрящим заморским на контроль качества и счетоводам хозяина на контроль вообще.

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

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

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

Шутка ли сказать, а проблемы были не только субъективные:
- что делать с имеющимися автоматизированными системами: корчевать или интегрироваться? А счет этим системам был на сотни по всему бизнесу и у каждой свои пользователи и внедренцы...
- что делать с текущими проектами внедрения, куда уже вложены миллионы долларов?
- что делать с участками бизнеса, которые заморская программа, мягко говоря, автоматизировала слабовато?
- что делать с не всегда адекватной классификацией процессов, которая во многих местах пролегла поперек производственных цепочек? Это привело к тому, что на многих объектах автматизации границы пролегли поперек организации, поделили на две-три части конкретных людей и подразделения. В итоге некоторые объекты не попали в организационный объем ни одного проекта по созданию ФТ.
- что делать, когда при создании ФТ на подсистему Б коллеги считают, что заберут данные из подсистемы А, но ФТ на подсистему А уже написаны (и почти согласованы - 50 подписей уже есть) и там никто не позаботился о подготовке требуемых данных... И что делать, если подобные случаи, скорее норма, чем исключение?

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

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

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

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

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

Можно еще много привести всяких если, но всему свое время.

Брильянтовая рука  ^

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

И чем лучше мы знаем, как правильно, тем чаще нас пытаются прогнуть на мелкие или крупные отклонения.

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

Другой вариант:
- гипс снимают, клиент уезжает, надо срочно, и если мы сделаем мощно - чемодан баксов наш! - Кто тут устоит? Да еще и с полудремы не так просто встать в защитную позу, да еще и с директором.

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

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

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

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

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

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

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

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

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

Обратный клапан  ^

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

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

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

Подчиненные взяли под козырек и понесли эту радостную новость исполнителям.

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

Подчиненные отвечали со слезами на глазах, хорошо представляя себе, сколько бумаги придется исписать при общении с ИТ-отделом, что все понимают, но ОН СКАЗАЛ, чтобы был почтовый сервер.

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

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

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

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

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

А ведь могли бы вовремя потратить чуть больше усилий при планировании.

Матрешка  ^

Как-то раз один большой заказчик объявил тендер на написание толи концепции, то ли стратегии автоматизации на ближайшие 3 года. Не то, чтобы это было новостью - обычная история.

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

Выиграл этот тендер один крупный интегратор - кто же еще...

Но не работать же самим - пошли искать, кто напишет документ. А пока не нашли - заключение договора приостановили от греха подальше.

Искали-искали нашли.

Одна фирма подрядилась на этот проект. Да вот беда - аналитиков у нее в штате не было.

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

Сделаем, я фиралансеров найму, - говорит директор фирмы.

Пошел искать аналитиков фрилансеров. Искал недолго - неделю-другую, а потом нашел.

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

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

Заказчик читает запрос, ничего в нем не понимает или не хочет понимать (кому охота работать или брать ответственность за решения) и говорит интегратору: "этого мы не можем/не хотим/не будем/не скажем выкручивайтесь по другому".

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

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

Так веселая детская игра в испорченный телефон превращается в мрачные взрослые игры передастов.

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

А сам бегом к интегратору докладывать, мол, аналитиков нашел, теперь все будет зашибись!

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

Тем временем аналитики заволновались - время идет, а дело стоит, как бы не пришлось потом информацию из пальца высасывать. Люди-то опытные.

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

А время все идет и идет.

Аналитики опять волнуются:
- когда мы план согласуем, когда о бюджете и оплате с вами договоримся?
- договоримся, - отвечет им директор фирмы, - все под контролем:

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

Звонит директор фирмы аналитикам и говорит:
- ребята, все отлично, завтра будет обследование - я обо всем договорился, нам к следующей пятнице нужен отчет об обследовании.
- Только завтра? - не верят своим ушам аналитики?
- Обижаете! Обследование завтра и послезавтра, - говорит директор - и еще у вас будет целых два дня на оформление отчета.
- Два дня? - офигевают аналитики, а с кем мы сможем там поговорить, дадут ли нам материалы? Собрана ли рабочая группа у заказчика, есть ли приказ, заключено ли соглашение о конфеденциальности, чтобы вынимать материалы, можно ли будет провести анкетирование? Мы же даже оргструктуру, регламенты, положения об отделах и должностные инструкции еще не запрашивали! Отделов-то там сколько?
- Господь с вами! - говорит директор, какое анкетирование, какой приказ, - у нас и договор-то не заключен, а через 4 дня срок сдачи отчета. Мы договорились по дружески, неофициально - вас внутрь пустят, но людям сильно не надоедайте, а то их уже замучали обследованиями. А мы с интегратором во вторник подпишем договор и тогда уже в среду сможем сдавать отчет. Отделов там 40 в 5ти департаментах, всего-то 500 человек. Как раз за 2 дня все и обойдете... - а про себя думает: "Два дня у заказчика люди покрутятся и достаточно - никто не скажет, что мы обследование не делали, а там парни что-нибудь напишут за пару ночей - они же профессионалы."

Аналитики крутят пальцем у виска и говорят:
- ясно, опять придется херню лепить - ни исходных данных, ни времени. Мы, кстати, с вами еще цену наших работ не согласовали, вы помните? - А сами думают - отлично! Мы договаривались о трехмесячном проекте, а теперь из нас выдавливают результат за 4 дня: По каким тарифам и за какую трудоемкость в этом случае мы будем рассчитываться?

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

Что делать аналитикам? А что бы вы сделали?

Как говорил один мой бывший босс: "бывают ситуации, когда дешевле не продавать".

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

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

Когда ваш план к середине проекта выглядит примерно так:
1. Управление
1.1 Заключить договор (через неделю) - выполняется
1.2 Поготовить и подписать акты по этапу 1 (через неделю) - не начиналось
1.3 Поготовить и подписать акты по этапу 2 (через месяц и неделю) - не начиналось
2. Аналитический отчет (через неделю) - выполняется
3. То ли концепция, то ли стратегия (через месяц и неделю) - не начиналось

Довольно трудно ожидать чего-то приличного на выходе.

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

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

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

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

Access denied  ^

Что делают аналитики, когда едут на обследование в другой город?

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

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

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

Они звонят внутрь, там их тоже никто не знает и разговаривать с ними не собираются.

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

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

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

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

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

Их ведут "за ручку" по отделам беседовать с людьми. Разговоры складываются по разному, кто-то идет на контакт, кто-то нет, кому-то нравится поговорить, кто-то зянят.

Каждый разговор начинается с расспросов о том, "кто такие?", "что за проект?", "что это будет за система?", "кто платит?", "не уволят ли всех после внедрения?", "а у вас трехзвенка или клиент-сервер?", "а будет ли ТАКАЯТОХРЕНЬ?" и т.д., что отнимает существенное время.

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

Так, в разговорах, проходит еще день-другой.

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

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

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

Мы делили апельсин  ^

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

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

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

При таком механическом подходе сразу возникает ряд открытых вопросов.

Допустим, Вася пишет общую постановку задачи на подсистему А, а Петя пишет общую постановку задачи на подсистему Б, при этом Маша пишет описание базы данных для обеих подсистем.

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

Кто увидит, если и Вася и Петя потребуют реализацию одной и той же интеграции с одной и той же внешней системой или оба понадеются друг на друга и не будут требовать интеграцию (и не будут вовремя инициировать договренности с владельцами смежной системы и принятие соответствующих решений)?

Кто увидит, что и Вася, и Петя описали частично перекрывающиеся функции заполнения нужных им справочников?

Что будет, когда на совещании по подсистеме А, где есть Вася, но нет Пети будет решено перенести функции интеграции в подсистему А (к Васе), а работу со справочниками полностью отдать в подсистему Б (к Пете)? Когда и от кого Петя узнает об этом решении?

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

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

Для двух подсистем и 2х человек проблема выглядит игрушечной, но что будет, когда у нас 22 подсистемы и 10 человек?

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

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

Грузчики  ^

Сегодня наша проектная команда занята важным делом - она лепит муляжи документации методом copy-paste.

Вася вставляет в куклы общей постановки задачи, программы методики испытаний и описания технологического процесса обработки данных - в нужные места формулировки из ТЗ по 22м подсистемам.

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

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

...
- Откуда такая спешка?
- Очень просто - завтра срок сдачи.
- Как можно пропихнуть через приемку такую, мягко говоря, отвратительную документацию?
- Никак - она не пройдет приемку у генерального подрядчика.
- Зачем же вы тогда ее лепите?
Менеджер проекта отвечает и на это - завтра по договору мы должны отгрузить пакет доукументов, а при получении списка замечаний у нас будет еще 10 дней для исправления недочетов и отгрузки новой документации.
- Но это же 30-40 человеко-часов в трубу:
- Я знаю говорит менеджер но мы должны следовать договору:
- А почему не успели сделать нормальный технический проект?
- Сроки были пережаты в 4 раза.
- Как вас угораздило на такое подписаться?
-... (непереводимая игра слов) ...
- А как у вас с реальными решениями технического проекта?
- По всем подсистемам мы знаем, что писать - у нас система везде работает одинаково и мы вставили правильные формулировки в ТЗ, но есть затык по двум подсистемам.
- А что с ними?
- Пользователи присунули в ТЗ функции, для которых нам не ясна технология получения результатов.
- Вы хотите сказать, что вам не ясны их бизнес-процессы?
- Да.
- А вы выполняли обследование?
- Выполняли.
- И что?
- У нас есть три одностраничные заметки по итогам бесед с начальниками трех управлений и два образца документов: образец протокола и образец справки, а еще есть отчет об обследовании, в котором нарисована оргструктура (7 управлений и 40 отделов) и перечислены имеющиеся у заказчика системы атоматизации, а так же сформулированы потребности пользователей (на основе возможностей нашей системы), которые легли в основу формулировок ТЗ.
- ???
- мы говорили с ИТ отделом и было по одной встрече с начальниками 3х управлений, но это мало, что прояснило, а один из начальников управления сформулировал, что очет и вставил эти формулировки в ТЗ и сказал, что пока мы ему не покажем, как это будет - он ТЗ не подпишет.
- а почему вы не встретились с ним еще раз?
- он был занят.
- Но вы могли встретиться с его подчиненными, попросить создать рабочую группу...
- Это было невозможно.
- Почему?
-... (непереводимая игра слов) ...
- Но вы теперь получите отсрочку, возможно, сейчас удастся выйти на контакт с будущими пользователями и принять недостающие решения?
- Скорее всего - это будет невозможно.
- Но почему?
- Начальник управления все время занят, а его подчиненные не эксперты, они нам ничем не помогут...
- С чего вы взяли?
- ... (непереводимая игра слов) ...
- Так это что, проект по освоению бюджета?
- Нет, мы делаем реальную систему, с которой должны будут работать люди...
- ... (непереводимая игра слов) ...

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

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

Модель проекта  ^

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

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

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

Основные роли заинтересованных сторон вокруг проекта ясны из определения - это заказчик, руководитель проекта (РП), рабочая группа (РГ), потребители.

Четыре базовых параметра проекта - это длительность (T), объем результата (V), стоимость (C), качество (Q).

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

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

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

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

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

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



Делить деятельность в ходе проекта на кусочки можно по разному. По одной из самых простых классификаций проект имеет 2,5 фазы:
- Целеполагание,
- Планирование,
- Выполнение.

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

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

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



Проблемы в проектах и их причины  ^

Нас интересуют проблемы с выполнением проекта.

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

Давайте посмотрим какие бывают проблемы с ИТ-проектами и их возможные причины.

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

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

Стрелками показаны прямые зависимости причина-следствие.

Овальчики - это собственно финальные проблемы с проектом.

Прямоугольничками изображены причины.

Жирными сплошными рамками я выделил причины, которые можно считать корневыми - дальше них почти не копаем.

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

Риски, форс-мажор и результаты проекта  ^

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

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

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

Тут нам надо на время посмотреть на проект глазами пары заказчик+потребитель и капельку расширить модель проекта.

Любое дело, даже самое простое (типа, как почесать себе кончик носа) имеет в общем случае два исхода: получилось и не получилось. И как бы мы не хотели, чтобы всегда получалось, все равно надо предусматривать и вариант с неудачей.

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

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



Корневые причины проблем  ^

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

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

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

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

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

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

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

В конечном итоге мы получаем матрицу, классифицирующую корневые причины наших проблем с проектами:

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

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

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

Скажу лишь, что не зря говорят: "простота хуже воровства". Там, где одни проявляют невежество и глупость, другие проявляют нечистоплотность и злонамеренность. И поскольку есть первые, неизбежно будут и вторые. При том, что обратное неверно.

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

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

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

Некоторые базовые принципы проектного управления  ^

Тест  ^

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

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

Итак, я вышел с работы и направляюсь домой: В каких ситуациях я приближаюсь к своей цели?

1. Я иду (см. схему). Приближает ли это меня к цели?



2. Я иду в другую сторону (см. схему). Приближает ли это меня к цели?



3. Я стою. Приближает ли это меня к цели?



4. Я сижу. Приближает ли это меня к цели?



5. Я лежу. Приближает ли это меня к цели?



Надеюсь, у нас появились пять ответов на вопросы. Теперь разберем мои варианты ответов.

Если я вышел с работы и направляюсь к дому, к которому ведет прямая дорога или тропинка и расстояние 1-2км, то двигаясь пешком в сторону дома, я достигну цели.



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



Если я пришел на остановку и жду автобуса, то я стою и это приближает меня к цели.



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



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



В итоге, мои ответы на тест такие:
1. Все зависит от.
2. Все зависит от.
3. Все зависит от.
4. Все зависит от.
5. Все зависит от.

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

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

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

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

Первое, что необходимо предотвратить на старте проекта - это именно описанный подход к работе.

После того, как мы согласимся с тем, что проектная работа требует особого отношения, возникнет следующий вопрос: а какого отношения требует проектная работа? Об этом далее.



Маленькое экономическое введение  ^

Заинтересованные стороны и интересы  ^

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

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

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



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

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

Перетягивание одеяла  ^

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

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

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

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

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

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

На картинке ниже показано, за что борется каждая из сторон.

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

Рисков исполнители хотели бы избежать. Их риски в занижении фактической стоимости человеко-часа и необходимости работать слишком интенсивно и с большими переработками из за заниженных сроков и стоимости и/или завышенных требованиях к качеству и объему. Другой риск - не получить оплату за проделанную работу или получить ее не в полном объеме.

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

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

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

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



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

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

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

Договариваемся на входе  ^

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

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

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

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

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

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

А мы посмотри, что надо делать.

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

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

Для примера рассмотрим продажу проекта внедрения с двумя организациями: ООО "Заказчик" и ООО "Исполнитель".

Если Заказчик отказывается предоставить предоплату, то Исполнитель берет на себя риск "издержки понесены, но заказчик не расплатился" и роли распределяются так:
- ООО "Заказчик" - Потребитель, Покупатель;
- ООО "Исполнитель" или инвестор и исполнитель, или кредитор, страховщик и исполнитель. В обоих случаях к обычной цене работ исполнителя добавляется или дополнительная норма прибыли за риск, или страховая премия плюс проценты по кредиту. В развитой рыночной системе Исполнитель действительно может взять кредит на выполнение проекта и застраховать риски в страховой компании.

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

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

Учет проектов и закрепление рабочих групп  ^

Мне постоянно кажется, что я сейчас буду объяснять странные (своей банальностью) вещи для 21го века. Однако в 15% наблюдаемых мной случаев (по статистике, приведенной во введении) все проблемы начинались от элементарного отсутствия учета проектов, закрепления ответственных исполнителей и состава рабочих групп.

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

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

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

По итогам инвентаризации может выясниться множество интересных вещей. Например таких:
- О выдерживании сроков речи не идет.
- Рентабельных проектов нет и скажите спасибо, если кое-где есть выход на окупаемость при нулевой прибыли: то ли мы не умеем рассчитывать цену и сроки на старте, то ли не умеем потом вписываться в спланированные параметры.
- Некоторые проекты ушли в минус год-полтора назад и их уже давно пора прекратить любой ценой;
- Для достижения одного и того же результата существуют несколько паралельных проектов. При этом в одном случае команды проектов жестко конкурируют и мешают друг другу работать, а в других - каждая команда ждет, когда соседи принесут результат, чтобы (за компанию) отчитаться о выполненной работе.
- Существуют "волшебные темы", по которым за дело уже брались несколько групп или отдельных исполнителей, но никаких следов: окончательных (даже отрицательных) или промежуточных результатов не сохранилось.
- Там, где идет работа на реальный результат, ключевые специалисты раздерганы на многие проекты, и планировать свое время могут только они сами, в итоге менеджеры вынуждены нанизывать календарные графики проектов на планы нескольких "звезд".
- Есть группа сотрудников, трудящихся в поте лица, которая вообще не участвует ни в одном проекте. Это сложный случай, требующий серьезного внимания. Дело в том, что тут, как минимум четыре варианта:
-- происходит прямая имитация бурной деятельности или по инерции выполняются функции, давно утратившие актуальность;
-- технологические цепочки в действующих проектах выявлены не до конца (так часто бывает с косвенными работами и поддерживающими процессами), при этом в рабочие группы не включены соответствующие участники или чистая процессная деятельность вне проектов ошибочно отнесена к проектной (если вообще кто-то заморачивался делением на процессы и проекты);
-- не все проекты учтены и есть работы (иногда даже очень полезные или даже критически важные), которые (как бы) делаются сами и мало кому видны.
-- есть работы и проекты, результат которых может быть и востребован, но ни с кем (из начальства) не обсуждался, эти работы выполняются инициативными группами в рамках собственного понимания сотрудников, как лучше для компании или для самих себя.

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

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

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

Действительно - не дело сотрудника измерять и доказывать свою полезность - это работа менеждера. Но достаточно частыми мотивами отсутствия премий или отказа в повышении зарплаты являются именно экономические соображения: "проект не прибыльный".

Календарно-ресурсное планирование  ^

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

На вопрос: "почему так долго и дорого?", заказчику/начальнику высовывается километровый график, обосновывающий сроки и стоимость проекта.

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

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

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

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

При этом всем, присутствие календарно-ресурсного графика в общем повышает вероятность "угадать" цену и сроки проекта.

Фиксация приоритетов, рисков, допущений и требований  ^

Правильно составленный календарно-ресурсный график фиксирует сроки, стоимость и объем проекта. С четырьмя оговорками:
- во-первых - ПРАВИЛЬНО составленный (ниже это обсудим);
- во вторых - любые оценки и погнозы опираются на определенные допущения и предположения, без их фиксации мы закладываем неучтенные риски и, в частности, оставляем возможность оппонентам изменить трактовку договоренностей;
- в-третьих - требуемый уровень качества никак не отражается в календарно-ресурсном графике, для фиксации качества используется спецификация требований или подобный документ;
- в-четвертых - важно понимать, чем является данный конкретный график: обязательствами или оценками, какова точность указанных цифр и вероятность их достижения.

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



Для составления и проверки обсуждаемых артефактов существует ряд правил, самые важные из которых я приведу ниже.

Сквозная линия напряжения  ^

Правило сквозной линии напряжения гласит:
1. Результаты каждой работы кто-то ждет;
2. С этим "кем-то" можно:
- Согласовать требования к результатам;
- Получить замечания на предварительные результаты;
- Провести сдачу-приемку результатов.

Самый лучший способ подвесить работу в неопределенности - это удалить потребителя результата.

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

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

Главный секрет качества  ^

Необходимо сказать несколько слов о качестве.

Во-первых определение. Качество - это соответствие результата (и/или процессов) требованиям и ожиданиям потребителя: внешнего или внутреннего.

То есть, там, где есть требования, там всегда есть и качество. И наоборот: нет требований - качество не определено.

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

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

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

Отсутствие ответа на вопрос: "Каковы требования к результатам данной работы", означает серьезные дефекты в составе работ.

Ритм  ^

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

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

Для иллюстрации приведу пример графика.
1. Спецификация требований (3 месяца)
1.1. Обследование (1 месяц)
1.2. Написание спецификации требований (1 месяц)
1.3. Согласование спецификации требований (1 месяц)

С точки зрения ритма для данного примера мы должны задать несколько вопросов:
- Устраивают ли нас месячные паузы межу выходом результатов?
- В частности, что мы будем делать, если через месяц после старта встанем перед фактом: обследование не завершено и нам нужно еще 1, 2, 3 или вообще неизвестно сколько месяцев?

Рваный или слишком длинный ритм означает, что во время длинной паузы риск "схода проекта с рельсов" повышен.

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

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

Правило проектного треугольника  ^

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

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

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

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



Далее, когда мы говорим ресурсы - это означает ВСЕ ТРЕБУЕМЫЕ РЕСУРСЫ проекта. Например, если речь идет о заказном внедрении, то сюда необходимо включать, как трудоемкость внедренцев, так и все, что потребуется от заказчика/потребителей, а так же стоимость всех приобретаемых компонентов и т.д.

В объем включаются все окончательные и промежуточные результаты проекта.

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



Ну и, наконец, риски.

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

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

При этом в сфере ИТ мало того, что лучшие практики и стандарты пока не устоялись, так еще и в последнее время развелось очень много желающих выйти на пенсию в 35 лет (а лучше в 27). В итоге в отечественном ИТ мы наблюдаем обратную пропорцию, и старт проекта с вероятностью успеха 10-30% - это скорее норма, чем отклонение.

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

Два рычага ускорения - это изменения в технологии и повышение риска.

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

Технологичность  ^

Теперь обсудим технологию выполнения работ.

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

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

Деление работ  ^

На основе деления работ по видам мы получаем состав работ проекта.

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

Вот утрированный пример:
1. Спецификация требований (Иванов)
2. Настойка системы (Пертов)
3. Пуско-наладка (Петров)
4. Опытная эксплуатация (Заказчик)

Бывает и еще проще:
1. Все работы

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

Чтобы показать альтернативу приведу пример немного более детализированного состава работ:
1. Управление
1.1 Формирование РГ
1.1.1 Предварительный список РГ от заказчика
1.1.2 Проект приказа о старте проекта
1.1.3 Согласование приказа о старте проекта у заказчика
1.1.4 Издание приказа о старте проекта у заказчика
1.1.5 Совещания по статусу проекта
1.1.5.1 ...
...
1.2 Установочное совещание РГ
1.3 Управление на этапе "Концепция"
1.3.1 Перечень интервью
1.3.2 Создать график интервью
1.3.3 Согласовать график интервью
1.3.4 Направить запрос материалов
1.3.5 Получить материалы
...
2. Концепция
2.1 Изучение материалов (выходы - модель объекта автоматизации ред1, вопросник к интервью и досбору материалов, предварительные решения концепции)
2.2 Вопросники к интервью
2.3 Шаблон концепции
2.3.1 Шаблон концепции ред 1
2.3.2 Получить замечания на шаблон концепции ред 1
2.3.3 Решения по замечаниям на шаблон концепции ред 1
2.4 Интервью (наполнить после создания графика п.1.3.2)
...

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



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

Естественно и излишняя и недостаточная детализация вредны.

В таблице ниже показано сравнение вариантов:

Цепочка преобразований Монолитные работы большого объема
- Более измерима и повторяема;
- Лучше управляема, так как нам доступны промежуточный контроль, обнаружение рисков, корректировки;
- Ее легче оптимизировать;
- Возможно четкое разделение труда;
- При больших потоках более производительна;
- несет с собой издержки на контроль и оформление промежуточных результатов;
- делает перепланирование при изменениях условий более трудоемким.
- Неуправляемы внутри;
- Опасны неувязками между результатами различных работ;
- Кажутся менее трудоемкими, чем есть, если имеют существенный объем;
- В целом, более рискованы;
- при этом требуют меньше затрат на управление, оформление и складирование результатов;
- не требуют перепланирования и позволяют исполнителю проявить гибкость при неожиданных изменениях условий.

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

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

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

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

В работах аналитика доля работ по непосредственному написанию документов занимает (по моей статистике) от 5 до 15%. Остальное время - это подготовка, сбор информации, анализ, подготовка и принятие решений, согласование и другие работы.

На этот самый порядок как раз обычно и ошибаются начинающие специалисты при оценке предстоящих работ.

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

Инструменты выполнения работ  ^

Второй способ воздействия на трудоемкость работ - это выбор инструментов автоматизации.

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

Ниже в таблице представлено сравнение тех и других:

Сложные инструменты Простые инструменты
Цена вопроса:
- Регламентация
- Настройка
- Администрирование
- Контроль использования
- Обучение
Окупаются:
- В длинных проектах
- В большой группе
- При больших потоках информации
Цена вопроса:
- Регламентация немного проще
- Без настройки (почти)
- Администрирование проще
- Сложнее контроль использования
- Обучение проще или не требуется
Окупаются:
- В коротких проектах
- В малой группе
- При малых потоках информации

Следует сказать по паре слов о каждой позиwии сравнения.

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

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

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

Обучение может не требоваться для привычных простых инструментов таких, как MS Word (хотя и ему иногда стоит поучиться), для сложных инструментов, новых для группы, обучение неизбежно. Другое дело, будет оно самостоятельным или общим, организованным для всех.

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

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

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

Так или иначе, сократить сроки небольшого проекта (допустим, с 6 месяцев до 3х-4х) за счет применения нового производительного (но сложного и неосвоенного), при этом (по отзывам или рекламе) отличного инструмента - сомнительная идея.

Модель проектной работы  ^

Выбрав иниструменты и состав работ необходимо проверить работы.

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



Результат  ^

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

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

Еще работы бывают поделены так, что результаты неизмеримы вообще. Это плохой вариант.

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

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

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

Работа, исполнители и инструменты  ^

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

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

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

Это поможет избежать неожиданностей типа:
- Нет доступа к запланированным инструментам. Например, лицензии не купили, или они заняты коллегами из другого проекта, или нет тестового сервера, или на нем стоит Unix, когда нам нужен Windows Server.
- Забыли включить в план действия по пуско-наладке, настройке, регламентации работы со сложными узкоспециализированными инструментами, а теперь эти работы отъели существенную трудоемкость.

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

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

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

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

Важно одно: отсутствие такой проработки - это путь к неожиданностям.

Процесс планирования от технологии  ^

В итоге мы получаем следующую приблизительную последовательность действий при планировании проекта:
1. Определить заинтересованные стороны проекта.
2. Определить цели и границы проекта, а так же роли участников, в том числе явно определить роли участников в отношении рисков, вознаграждения и издержек.
3. Получить спецификацию результата (качество, объем).
4. Получить состав работ:
5.1 Выбрать используемую технологию:
- методы и инструменты под ситуацию;
- состав промежуточных результатов;
- виды операций преобразования и их связи;
- роли/персоналии специалистов;
- типовые взаимосвязи между операциями по требованиям к результатам.
5.2 Получить состав работ путем наложения технологии на состав результата.
6. Вписать полученный состав работ в имеющиеся ресурсы и заданные сроки методами календарно-ресурсного планирования.
7. При необходимости можно выполнить сжатие графика за счет совмещения и/или дополнительной детализации операций, замены технологии, инструментов, исполнителей, аутсорсинга и т.п.



Участие аналитика в планировании  ^

Общие положения  ^

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

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

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

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

Тест о пути домой, приведенный выше, полностью описывает ситуацию с работами аналитиков на проекте внедрения.

Работа аналитика  ^

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



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



Здесь необходимо сделать уточнение по терминологии.

В западной терминологии в процессе разработки ПО четко выделяются ТРЕБОВАНИЯ, ассоциированные с Software Requirements Specification, которая по составу решений является подмножеством технического проекта в терминах ГОСТ серии 34.

У нас термин "требование" несет несколько иную нагрузку. По этому я уточняю ряд определений.

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

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

В зависимости от выбора методологии внедрения и разработки ПО создание требований по разному распределяется по этапам проекта.

Например, в ГОСТ серии 34 на создание требований отводятся стадии (см. ГОСТ 34.601) с 1 по 5: со стадии "Требования пользователя" по стадию "Технический проект". Из них стадии 1-2 (Требования пользователя, Концепция) считаются предпроектными, относящимися к целеполаганию, стадия 3 (Техническое задание)относится к планированию.

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

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

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



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

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



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

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

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



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

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

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

Сбор данных  ^

На старте сбора данных мы должны ответить для себя на следующие вопросы:
- Что собирать?
- Где (и у кого) собирать?
- Как собирать?

В ходе сбора данных мы длжны постоянно получать ответы на другие вопросы:
- Все ли собрали?
- Разрешены ли противоречия между "показаниями сторон"?
- Есть ли четкая идентификация объектов и процессов?
- Есть ли на что ссылаться: собрана ли "доказательная база"?
- Что будем делать при выявлении нестыковок в дальнейшем?

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

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

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



Анализ  ^

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

В процессе работы кроме самой модели анализа и ответов на вопросы относительно анализируемого объекта следует обеспечить управление сбором информации, то есть в каждый момент необходимо знать:
- Что еще искать?
- Какие требуются уточнения?

Для последующего синтеза модель анализа и оценки объекта должны быть подготовлены с требуемым качеством. Необходимо продумать и затем обеспечить
- Полноту;
- Точность;
- Непротиворечивость;
- Достоверность;
- Доказательность.

Синтез  ^

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

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

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

Представление и согласование  ^

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

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

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

Стратегия  ^

Применение стратегического анализа  ^

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

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

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



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

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

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

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



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

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

С другой стороны малые углы подъема удлинняют наш путь.



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

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

Стратегия №1 - планируйте  ^

В отношении планов встречаются два заблуждения менеджеров и исполнителей.

Первым частым заблуждением является то, что планы никому не нужны по следующим причинам:
1. имеющаяся неопределенность слишком велика, что планировать не ясно;
2. планы все равно будут нарушены;
3. начальство/заказчик от нас этого не требует;
4. это лишняя (или не наша) работа.

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

Чтобы развеять второе заблуждение я привожу состав организационно-технических решений относительно выполнения проекта, которые часто находят место в плане проекта, представлящем собой один документ или пакет докуменов:
- Цели, границы (объемы) и стратегия выполнения - основные критерии достижения результата с указанием, зачем и кому нужен этот результат, точная граница между тем, что войдет в проект и его результат, а что не войдет, указание выбранной стратегии выпонения проекта, влючая выбор приоритетов, опасности, возможности и выбранный нами способ достижения цели, а так же допущения на которых мы строим план.
- Спецификация результата - перечень требований, измеряя реализацию которых мы узнаем, достигнут ли результат.
- Технологический план - указание выбранных методов и инструментов, описание технологических цепочек, контрольных списков и регламентов по видам работ.
- Состав работ и сетевой график - полный детализированный объем проекта в двух плоскостях: (1) состав промежуточных и окончательных результатов; (2) объем работ, направленных на достижение результатов. А так же потребность в людских ресурсах и инструментах, материалах и внешних входах к работам и технологические связи работ между собой.
- Оргструктура, роли и ответственность - планирование состава рабочей группы (включая всех нужных нам специалистов заказчика) в ролях или в лицах, раздача полномочий и ответственности за работы, за принятие проектных решений и участие в управлении проектом; кроме этого можно указать все стороны вне рабочей группы и их роль по отношению к проекту.
- План коммуникаций - необходимо точно указать, как, какая и по каким каналам доставляется управляющая и рабочая информация проекта. К решениям из этой части плана относятся виды и шаблоны управленческих документов проекта, степень формализации (например, допустимы ли устные предупреждения и договоренности или требуются письменные, каков статус электронных писем и т.п.), как и где хранится информация проекта, кто получает какие оповещения и информацию и каким образом (например, требуется ли присутствие исполнителя на совещании по статусу или допустимы письменные отчеты, какие оповещения требуют письменного подтверждения "ознакомлен" и т.п.).
- План управления:
-- Календарно-ресурсный график - собственно расписание выхода результатов проекта, используемое для контроля выполнения и обнаружения отклонений;
-- Риски - реестр рисков, планы реагирования на риски;
-- Отчетность - частота, состав и шаблоны отчетов, ответственность за их составление.
-- Эскалация проблем и разрешение противоречий - регламенты обнаружения конфликтов и принятия решений при разногласиях.
-- план управления изменениями - какова процедура изменения целей, границ проекта и исходных требований к результату; в каких случаях и как будет изменяться и пересогласовываться сам план проекта, каковы подходы к созданию, хранению, распространению и контролю версий проектной документации.
- План управления качеством - как уже было сказано, при нулевом качестве возможен выпуск результатов в неограниченных объемах за нулевое время. Чтобы не получить проблемы при приемке результата необходимо планировать, как мы будем обеспечивать качество выходного результата на протяжении всего проекта. Как мы видели выше, требуется предъявлять требования к промежуточным результатам так, чтобы они обеспечивали требуемое выходное качество. Это значит, что выполнение требований к промежуточным результатам необходимо измерять и планировать корректирующие действия на случай отклонений.
- План завершения - необходимо планировать процедуры приемки результата. В случае с атоматизированными системами приемка - это целый комплекс мероприятий, обязанный своей сложностью собственной сложности самих систем и объему требований к ним.
- План управления контрактами - в случае, когда необходима закупка комплектующих и лицензий, услуг или найм персонала, правила и порядок заключения договоров следует планировать, чтобы не получить неожиданности при их согласовании и заключении. В крупных организациях могут действовать жесткие регламенты выбора поставщиков, найма персонала, а схема согласования договора может напоминать тарелку сапагетти; Одним из частых видов контрактов, напрямую касающихся работы аналитиков является соглашение о конфеденциальности, дающее право на сбор информации на территории заказчика.
- Бюджет проекта - постатейное обоснование стоимости проекта, основанное на составе работ и календарном графике.

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

Теперь, прояснив значения слова "план" в этой статье, я привожу ответ на возражения против планирования:
1. Чем выше неопределенность, тем больше мы нуждаемся в плане. При попытке спланировать действия мы задаем себе и окружающим ряд "неудобных вопросов", поиск ответов на которые должен уменьшать неопределенность. Попытка "замести проблемы под ковер" ни к чему не приведет, а только уменьшит оставшееся время и бюджет к тому моменту, когда мы встанем перед острой необходимостью принимать какое-то решение для движения вперед.
2. Планы пишутся для того, чтобы их нарушать. План - это не догма, нарушение которой карается отсечением головы и попаданием нарушителя прямо в ад, а что-то, подобное дорожной разметке и знакам, предупреждающим нас о том, что сейчас мы выедем на встречную полосу или о том, что впереди опасный поворот.
3. Хороший план составляется так, чтобы мы рано узнали об отклонениях и реалиации рисков и имели время и возможности для исправление ситуации. Другая важная функция плана - это общие договоренности, защищающие всех членов рабочей группы от "беззакония", такого, как непредвиденные изменения в требованиях, нарушения обещаний, сокрытие информации, скрытая передача рисков коллегам или подчиненным, проблемы с оплатой и т.д. И, наконец, если мы не планируем на бумаге и не сравниваем планируемое с фактическим, мы медленнее получаем опыт и быстро забываем преподнесенные реальностью уроки: даже шишки и шрамы рано или поздно заживают, а многие люди склонны надежно забывать былые неприятности. И тем более, отсутствие письменной фиксации планов и фактов не дает тем, кто идет следом за нами учиться на наших ошибках.
4. При планировании достаточно легко впасть в излишнюю детализацию, что сделает управление проектом громоздким и неудобным. Тут нельзя дать общий рецепт, но можно сказать следующее:
- не все вопросы нуждаются в бумажной фиксации, выбор, что записать, а что подразумевается в данном случае всегда остается за составителем плана;
- отсутствие записи и отсутствие проработки вопроса - это не одно и то же; проработке подлежат все вопросы по имеющимся контрольным спискам; при этом если вопрос неактуален или имеет простой ответ - он все равно не отнимет много времени;
- надо принять то, что затраты на планирование и подготовку работ могут занимать существенное время и даже могут превышать по трудоемкости сами работы - это выгодно, так как статистика показывает, что плохо структурированные работы (без планов и подготовки) проводят существенную долю времени в четырех состояниях:
-- проектный паралич, когда не хватает исходных данных или требований к результату;
-- ненужная работа: излишняя детализация, невостребованный результат, результат не того качества, требующий переделки;
-- неоптимальное, излишне трудоемкое совмещение операций (например, попытка сесть и написать документ без предварительной подготовки исходных данных, шаблона, моделирования и анализа);
-- непроизводительная растрата человеко-времени в ожидании поступления нужных входов и/или доступа к инстументам.

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

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

Стратегия №2 - устав  ^

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

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

Устав должен иметь статус неотъемлемой части договора. Если в проекте есть смежники, то устав должен включать и договоренности с ними.

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

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

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

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

Стратегия №3 - обеспечить работу всем необходимым  ^

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

Вот контрольный список, что должно быть обеспечено:
- Получить официальный статус:
-- Нас знают и признают в определенных ролях;
-- Получить доступ на территорию заказчика - не в каждую организацию можно войти без пропуска, не везде пропуск выдают всем желающим;
-- Право на выемку материалов, обеспеченное приказами и распоряжениями, и, при необходимости, соглашением о конфеденциальности;
- Найти с кем работать:
-- Выстроенная оргструктура у заказчика или совместная РГ, а так же ответственный менеджер/контактное лицо со стороны заказчика для реешния всех вопросов;
-- Отношения с ключевыми специалистами: они нас узнают и сотрудничают;
-- Согласовать план работ, требующих участие заказчика и требования к результатам - если часть работ будут делать люди заказчика, их надо нагрузить обязательствами, объяснить, что и в каком качестве требуется на выходе, а так же продумать управление этими участками работ.
- Уточнить состав необходимого с РГ - каждый специалист должен сказать, что еще ему нужно от заказчика;
- Отслеживать риски - по контрольному списку требований к заказчику следить, что работы проекта вовремя получают все необходимое.

Стратегия №4 - Документарный цикл  ^

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

В итоге (скорее всего) на официальном уровне (на уровне результатов договорного этапа) работать придется через документы.

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

Хочу отметить детализацию документарного цикла по сравнению с простой формулировкой "Написать документ".

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

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

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

Стратегия №4а протоколы - малый документарный цикл  ^

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

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

Иными словами, лучший способ обмануть себя и коллег - это перемещать большие объемы информации в голове на большие расстояния в пространстве и времени.

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

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

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

Ясность и четкость документации напрямую отражает ясность и четкость принятых решений как по системе, так и по дальнейшим шагам.

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

Стратегия №5 явное управление точностью решений и неопределенностью  ^

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

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

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

Частые проблемы с решениями - проектный паралич или размытые формулировки, вызваны попытками задрать угол подъема в "проектной воронке". Иногда лучше 3 раза уточнить или изменить одно и то же решение, чем до конца проекта опираться на общие фразы, допускающие произвольное толкование.

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

Вот правила, которые помогают избежать проектного паралича или расплывчатых формулировок, не допускающих уточнения:
1. В документах надо всегда писать четкие назначения и область применения. Если документы содержат предварительные решения, или являются черновиками для внутреннего согласования, или предназначены для рецензирования определенным кругом экспертов, или, вообще - это шаблоны с примерами заполнения - необходимо прямо указывать такие факты;
2. Для отсутствующих решений внутри документов необходимо прямо указывать границы неопределенности и планы по ее раскрытию. Тут бывают следующие варианты:
- решение не принято на данном уровне, то есть решение оставлено на усмотрение исполнителей следующих работ; типичная формулировка: "требование не предъявляется";
- решение о должно/может быть принято или уточнено позже, типичная формулировка: "ЧТОТО должно/может быть уточнено/детализировано КОГДА, КЕМ";
- имеется неопределенность, снять которую нужно как можно скорее (типичная формулировка "ЧТО будет описано/принято/разработано в данной редакции/версии документа к моменту начала согласования") при этом в список задач проекта должны попасть шаги (и ответственные исполнители) по снятию неопределенности, уточнению или принятию решения.

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

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

Стратегия №6 - бойтесь "культа Карго"  ^

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

В википедии написано : "В наиболее известных культах карго из кокосовых пальм и соломы строятся точные копии взлётно-посадочных полос [речь идет об островах Меланезии, где в свое время базировались американские военные базы], аэропортов и радиовышек. Члены культа строят их, веря в то, что эти постройки привлекут транспортные самолёты (которые считаются посланниками духов), заполненные грузом (карго). Верующие регулярно проводят строевые учения ("муштру") и некое подобие военных маршей, используя ветки вместо винтовок и рисуя на теле ордена и надписи "USA"."

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

Почему?

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

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

Что же на самом деле?

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



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

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



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

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



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

Стратегия №7 всем строиться  ^

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

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

Методы и приемы выполнения аналитических работ  ^

Сбор информации  ^

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

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

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



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

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

Допустимо использование и нескольких техник в сочетании при условии, что мы понимаем, что делаем.

Ниже мы обсудим каждую технику более подробно.

Обследование  ^

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

Дополнения к контрольному списку планирования обследования таковы:
- Найти адекватных опрашиваемых - кого интервьюировать и в каком порядке;
- Запрос и изучение материалов до интервью - по итогам изучения материалов необходимо составить вопросники;
- Составить и согласовать график встреч, а не валиться людям, как снег на голову;
- Присылать вопросники и повестки до интервью - некоторые из опрашиваемых захотят и смогут подготовиться к беседе;
- Составлять протоколы ВСЕГДА - согласование протоколов с интервьюируемыми дает возможность уточнить терминологию и формулировки, а так же волшебным образом повышает внимательность коллег к точности выдаваемой информации;
- Планировать возможность последующего уточнения - обязательно получить возможность позвонить/написать/прийти для уточнения;
- Планировать получение новых вопросов на основе извлеченных материалов - после каждого интервью или выемки материалов пополнять вопросники.

Совместная рабочая группа  ^

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

Макеты и прототипы  ^

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

Опытная эксплуатация  ^

Опытная эксплуатация предполагает работу с "сырым" продуктом и требует от группы опытной эксплуатации крепких нервов и упорства.

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

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

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

Раннее согласование  ^

Раннее согласование, как и прототипный метод, предполагает предъявление чего-то, что можно дополнять и/или критиковать.

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

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

Анализ и синтез  ^

Анализ исходных данных и синтез решений, в основном, выполняются внутри рабочей группы и по этому более управляемы.

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

Согласование  ^

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

Вот основные приемы:
- Разделение ответственности;
- Согласование шаблонов;
- Раннее согласование (см. выше);
- Промежуточное согласование;
- Жесткое согласование.

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

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

Промежуточное согласование подразумевает последовательное принятие важных решений и их промежуточное документирование в качестве предварительных решений, чтобы позже, при оформлении документов, нам осталось только переложить решения из протоколов в шаблоны. Если решения принимали те-же, кто будет согласовывать, их замечания уже не будут принципиальными. Шаги по промежуточному согласованию такие:
- Необходимо обеспечить, чтобы документы согласовывали те, кто принимал решения;
- Спланировать мероприятия по принятию решений: совещания, демонстрации, мозговые штурмы и т.п.;
- Протоколировать принятые решения сразу;
- Заложить накопленные решения в результирующие документы.

Жесткое согласование применяется в ситуации, когда заинтресованные стороны уклоняются от сотрудничества и стремятся затормозить дело на этапе согласования документов. Для жесткого согласования мы должны в первую очередь создать и согласовать регламент согласования:
- Кто на что выдает замечания;
- Замечания принимаются только в письменном виде и в установленном формате;
- Установить трпебуемое время реакции;
- Замечания после срока и в неустановленном формате не принимаются;
- Расписание совещаний по замечаниям с обязательным присутствием согласующих;
- Неявка на совещание = отзыв замечаний.

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

Так же необходимо принять жесткий регламент совещаний по согласованию:
- Повестка совещания = сводка замечаний + проекты решений по каждому замечанию;
- Протокол совещания = сводка + окончательные решения.

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

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

Заключение  ^

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

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

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

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

Частым итогом подобных историй является вывод: "этот метод, техника, методология или инструмент не работает". При этом более эффективным было бы понимание, что "это не сработало в данной ситуации", с переходом к вопросу: "что сработало бы в такой ситуации?".

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

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

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

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

Что еще хотелось бы сказать...

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

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

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

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

Хочется верить, что рано или поздно отечественное ИТ повзрослеет, а пока каждый получает то, к чему стремится.