Сразу скажу: я не претендую на объективность. Это мой топ-5 ошибок руководителей проектов, в результате которых хочется совершить греховные деяния по отношению к этим самым руководителям.
Ошибка 1. РП — передаст
Не подумайте ничего пошлого, ПЕРЕДАСТ — это человек, который передает информацию от одного другому. Руководитель проекта — это связующее звено между заказчиком и разработчиками. Разумеется, он должен получать информацию от заказчика и доносить до команды, но он также должен её обрабатывать.
-
Ошибка РП — в простой передаче информации без предварительной обработки. Причины — лень и экономия времени.
- Руководитель должен не просто получить информацию от разработчиков и разобраться в деталях, но и спрогнозировать вопросы заказчика, заранее их задать разработчику и уже потом доносить информацию до заказчика. Ошибка РП — когда он не понимает технические моменты и, не разбираясь в деталях, отправляет информацию заказчику. Хочется спросить: «Какого черта?» Заказчик, как правило, не тех. специалист. Он начнет задавать вопросы. И когда это происходит, РП просто их транслирует разработчику и передает ответы. И вот оно!!! РП становится просто ПЕРЕДАСТОМ.
Решение. РП должен всю получаемую информацию обрабатывать, предвидеть вопросы и заранее быть готовым на них отвечать! У нас, например, есть 2 проектных чата: внутренний и внешний (с заказчиком). Одним из наших принципиальных решений было запретить делать пересылку сообщений от заказчика во внутренний чат.
Ошибка 2. Ответственность
Руководитель проекта — это человек, на котором лежит ответственность за успешность выполнения проекта.
Руководитель проекта — это пионер (да, имеется ввиду тот, кто с красным галстуком): в советское время была фраза «Пионер, ты отвечаешь за все».
Ошибки
- РП передал задачу исполнителю, не контролирует её выполнение и не знает о проблемах, которые возникли у исполнителя. Причина: РП думает, что все ему должны — сделают, отчитаются, решат. Одним словом, все сделают без участия РП. Это называется передать ответственность, а ответственность нельзя передать, её можно только взять.
- Бывают проблемные заказчики, и РП сложно получить от них обратную связь. Пока проект в процессе работы, РП особо не переживает по этому поводу, но когда случается «fuck up», то тут слова РП: «Заказчик не предоставил что-то», «Заказчик не дал конструктивную обратную связь», «Заказчик не выходит на связь». НЕТ! НЕТ! НЕТ! Заказчик тут ни при чем. РП неправильно выстроил коммуникацию. Всегда ошибка РП.
- Отсутствие планирования. Нет планирования — нет контроля!
Решение. Решение лежит в нескольких правилах.
- Контролировать всё, быть в курсе статусов всех задач, которые в «In progress». Руководителю проекта должно быть до всего дело.
- Ответственность за успех и «fuck up» проекта лежит на РП — это ему необходимо выстраивать коммуникацию с заказчиком.
- РП должен чувствовать личную ответственность, контролировать и четко планировать работу исполнителей.
Ошибка 3. Эмоциональность
Руководитель проекта — это человек, который управляет эмоциональным состоянием команды.
Давайте представим: есть человек, о котором вы все время слышите страшные истории, — в вашем представлении он ужасен. И теперь вам для него нужно делать проект. С каким настроением вы будете его делать? Будете ли вы выкладываться? НЕТ!
Заказчики — это люди, бывает так, что РП сложно с заказчиком. И эту тяжесть коммуникации он передает команде:
-
ноет, что заказчик не может дать конструктивную критику;
- критикует решения клиента;
- просто сплетничает о нем.
Решение
- Исполнитель не должен участвовать в коммуникации с заказчиком.
- РП не должен передавать критику заказчика по отношению к команде разработчикам. Лучше просто в общении с клиентом защитить свою команду, но ей желательно об этой ситуации не знать.
- Какой бы сложный заказчик ни был, РП не должен показывать этого команде — исполнителям нужно транслировать только положительные эмоции.
- Важно не забывать: требовательность заказчика — это хорошо, а не плохо. Многие это воспринимают в штыки!
Ошибка 4. Страх
Интересный факт: когда мы переживаем за проект, нам психологически тяжело сообщать плохие новости.
Только представьте, как тяжело хирургу сообщить о смерти пациента его родственникам.
Ошибка
РП тянет до последнего и не сообщает о проблемах, надеясь на их решение. Последствия такого поведения очень тяжелые. Заказчик думает, что все хорошо, но в день сдачи узнает о FUCK UP’е. Реакция заказчика понятна: он озвереет, кто-то даже может пострадать:)
Решение
- Ребят, ну серьезно. Заказчик — это человек, он переживает за проект и понимает, что могут возникнуть сложности. Очень важно о них сообщить и предложить пути решения.
- Не надо тянуть до последнего. Попробуйте разрешить проблемы, а если не получится, сразу сообщайте заказчику. Вы сможете сказать, какие попытки предприняли, а дальше совместно с клиентом найдете решение.
Ошибка 5. Неправильная коммуникация
Тут можно говорить много. Сегодня остановимся на том, как правильно задавать вопросы.
Ошибка РП. Задать вопрос и ждать ответа. Далее при получении ответа идет коммуникация по уточняющим вопросам. Это долго!
Решение. Уменьшить время на коммуникацию правильной формулировкой вопросов.
В нашей компании я написал отдельную инструкцию о том, как правильно задавать вопросы. Во главе стоит тезис — «Задавая вопрос, ты должен знать на него ответ».
Когда я услышал эту фразу, не сразу понял.
Суть в следующем. Перед тем как задать вопрос, вы сами должны предположить, что может ответить заказчик. Таким образом, клиенту вы сбрасываете вопрос и варианты ответов. В ответ заказчик подтверждает определенный вариант ответа или формулирует свой.
Это значительно экономит время.
Важно! Этот способ требует тренировки, зато позволяет выстраивать эффективные коммуникации не только на работе, но и в личной жизни.
Нет плохих заказчиков — есть неправильная коммуникация
Бонус
Это уже про главное качество РП. Если этого качества нет или РП не стремится его развить, он будет совершать ошибки.
Это качество — гибкость. Оно позволяет РП мыслить нестандартно, не прямолинейно, не в лоб. Можно назвать это той самой предпринимательской жилкой, которая позволяет находить выход из любой ситуации.
Как развить гибкость?
- Необходимо наработать опыт решения сложных и разнообразных задач. Где взять этот опыт? Элементарно, в бытовых ситуациях. Дом – это наше поле для тренировок. Научитесь правильно выстраивать коммуникации в своей личной жизни, это умение вам пригодится и в профессиональной деятельности.
- Общайтесь с большим количеством людей, расширяйте кругозор и варианты коммуникаций. Это вам поможет побороть скованность, вы будете легче находить подход к каждому человеку.
- Научитесь не отступать. Но помните: не всегда все зависит от вас. Самое главное – сделать все от вас зависящее и ждать результата. Неудачи случаются, надо быть к ним готовыми, делайте из них выводы.
- Читайте больше книг, разного жанра.
- Путешествуйте. Даже просто на речку с друзьями.
- Займитесь танцами. Например, сальсой. Ритм, общение с новыми людьми, отдых – лучшее развитие гибкости.
- Просто занимайтесь саморазвитием.
Заключение
Надеюсь, статья была полезной. Если да, поделитесь ею, чтобы больше людей получили полезную информацию.
Буду благодарен комментариям, пополнению списка ошибок и дополнительным вариантам решений.
Никто не застрахован от ошибок. В том числе и руководитель проектов. Одни ошибки имеют высокую критичность. Другие же совершенно безобидны для бизнеса и даже иногда вызывают улыбку.
Поскольку наша компания имеет большой опыт выполнения проектов по комплексной автоматизации, мы решили поделиться с вами самыми частыми ошибками руководителя проектов, которые мы выявили в результате долгой работы. Само собой, мы выступаем за принцип «учись на чужих ошибках» и советуем также делать и вам.
Ошибка № 1. Нас это не касается!
Часто руководитель проекта отстраняется сам и не позволяет своим сотрудникам «нырнуть глубже» в суть процесса – т.е. изучить особенности функционирования фирмы, вникнуть в бизнес-процессы, потратить пару дней на анализ работы компании в режиме «изнутри». Это позволило бы всей команде лучше понять особенности работы и провести полноценный анализ. Благодаря этому, можно было бы точнее оценить, как трудоемкость, так и специфику предстоящей работы.
Кроме того, часто случается такая ситуация, что компания, занимающаяся автоматизацией, не имеет никакого представления о типе оборудования, которое используется в компании клиента. Значит и правильное построение системы будет весьма затруднительно.
Наш вам совет – не стоит отстраняться от реального участия в аналитике. Личное присутствие на объекте и подробный анализ всей имеющейся базы позволяют более тщательно выполнить весь проект. Может быть вам потребуется какое-то дополнительное оборудование для реализации или имеющееся несовместимо.
Ошибка № 2. Не учитывается время, необходимое на приемку работ
Как правило, для руководителя проекта становится сюрпризом, что нужно было заложить в план работ время для тестирования и сдачи приложения. Обычно это не закладывается ни в календарный план, ни в расчёт итоговой стоимости проекта.
Само собой, появляются объективные претензии как у исполнителя, так и у клиента.
Наш главный совет тут один – проговаривайте подробным образом все особенности сдачи проекта. У каждой организации свои правила приемки подобных проектов.
Если об этом не знать заранее, то потом придётся долго удивляться, что заказчик предполагал получить все эти услуги за уже обозначенную стоимость.
Ошибка № 3. Не учитывается, что проект может безмерно расти в процессе его выполнения
Рост проекта – это обычное явление для IT – сферы. Разве что, относиться к нему можно по-разному. Где-т овсе хотелки заказчика выделяются отдельным соглашением на дополнительные работы, а где-то заказчик подразумевает исполнение хотелок заказчика как дополнительный бесплатный бонус от исполнителя.
Именно поэтому, на ранней стадии руководитель проекта должен проговорить все аспекты с заказчиком и определить вариант решения конфликтных ситуаций в подобных случаях. Часто заказчик сам не понимает, что может упустить некоторые важные моменты, которые нужно будет доработать. Задача руководителя проекта тут серьезная – нужно не просто предупредить, а доходчиво разъяснить заказчику все подробности выполнения проекта.
Если в процессе такого обсуждения всплывают некоторые дополнительные работы, то нужно обсудить, каким образом будет оплачиваться их выполнение – либо это большее количество часов, либо это дополнительные работы. Но тут важнее всего проговорить, что каждая такая работа – это новый объем обязательств, предполагающий оплату. Если и после согласования заказчик будет недоволен тем, что придуманные сразу неоговоренные работы не выполняются, то руководитель проекта может отказать ему с чистой совестью.
Важно понимать, что знание особенностей каждого конкретного проекта и демонстрирует компетентность руководителя в конкретной отрасли.
Ошибка № 4. Регулярный срыв сроков сдачи проекта
Не сдерживать обещаний – это совсем неправильно. Но иногда, по независящим от нас причинам ситуация может меняться. В проекте всплывают некоторые сложности, работники подводят, меняются прочие обстоятельства. От срыва сроков сдачи не застрахован никто.
На удивление, заказчики обычно адекватно воспринимают нарушение сроков сдачи проекта. За одним исключением – обязательно следует сообщить заказчику предварительно, что срок будет нарушен и объяснить причину. Затем обозначить новую дату и согласовать её с заказчиком, ну а дальше строжайшим образом её соблюсти. Повторный перенос срока сдачи проекта вряд ли кому-то понравится.
Ни в коем случае нельзя пропадать и держать заказчика в неведении.
Подытожим – нарушать сроки сдачи проекта ни в коем случае нельзя. Но если такое и произошло, то максимально быстро сообщите об этом заказчику.
Каждый руководитель проекта иногда делает ошибки. Одни ошибки приводят к тяжелым последствиям для проекта или для одной из заинтересованных сторон, другие ошибки проходят незаметно или легко нивелируются. Проработав более десяти лет в роли руководителя проекта по обе стороны контракта, я в данной статье хочу поделиться личными наблюдениями о часто встречающихся ошибках руководителя проекта со стороны исполнителя в проектах автоматизации процессов и внедрения автоматизированных систем.
Это не наше
Зарисовка из жизни.
Начало проекта. Команды заказчика и исполнителя обсуждают взаимодействие, состав работ, примерный план работ, уточняют рамки проекта. Руководитель проекта заказчика просит исполнителя разработать календарный план-график работ с учетом тех работ, которые должен выполнить и сам заказчик. Заказчик готов активно помогать в составлении данного план-графика в части работ со своей стороны, но работы исполнителя он естественно спланировать не может. Руководитель проекта от исполнителя сообщает, что «проект – это только то, что мы должны сделать, а остальное мне не интересно»
В чем ошибка данной позиции и к каким последствиям это может привести? Большинство проектов внедрения автоматизированных систем требует не только разработки программного обеспечения, но и выполнения других задач:
- закупки оборудования для развертывания системы;
- возможных организационных изменений в подразделениях;
- проведения обучения пользователей;
- разработки внутренней нормативно-методической документации;
- и др.
Все эти задачи входят в рамки проекта. И без их выполнения проект не может считаться завершенным успешно. Даже если подрядчик разработал программное обеспечение, проект на этом не закончился. И, чаще всего, программное обеспечение не будет принято в эксплуатацию пока не будет развернуто оборудование и проведено обучение пользователей.
Поэтому руководителю проекта от исполнителя настоятельно рекомендуется принимать во внимание общий план-график проекта и обязательно привязывать свои работы к ключевым вехам общего плана. Это поможет правильно составить договор (план-график работ по договору) и избежать в дальнейшем проблем со сдачей-приемкой выполненных работ. Например, для начала работ по интеграционному тестированию необходимо, чтобы оборудование было уже развернуто и настроено, а системы, с которыми требуется интегрироваться, были доработаны в соответствии с планом.
Совет 1
«Проект – это не то, что делаете только вы. Проект – это все, что включено в содержание (scope) заказчиком. Принимайте во внимание те работы смежников и сроки их завершения, которые влияют на возможность выполнения ваших работ, особенно на их приемку»
В каждой избушке свои погремушки
Зарисовка из жизни.
Подходит время проведения приемки системы. Проводится встреча, для обсуждения подробностей проведения данного мероприятия. Исполнителю рассказывают о том, что собирается комиссия, проводится проверка всех функций системы в соответствии с методикой испытаний и тестовыми сценариями, а также проверяется всё, что касается информационной безопасности, восстановления системы после сбоя и другие нефункциональные требования, которые ранее выдвигались. Для исполнителя явилось сюрпризом то, что он участвует в испытаниях в активной роли – именно его задача последовательно демонстрировать все шаги, ронять систему и восстанавливать и т.д. А также сюрпризом явилось то, что данное мероприятие может занять 2-3 полных дня (они себе в план столько не закладывали).
В чем ошибка руководителя проекта исполнителя и что нужно сделать, чтобы ее избежать?
Думаю, всем известна поговорка «В каждой избушке свои погремушки». В каждой организации свои принятые правила и регламенты приемки систем в эксплуатацию. Мне встречались очень простые и формальные испытания, когда проходят по основному функционалу и подписывают Акт о вводе в опытную эксплуатацию, а затем получают большое количество ошибок и недовольных пользователей на опытной эксплуатации. Мне встречались испытания, которые проводились полностью в соответствии с ГОСТ34, Программа и методика испытаний содержали проверку абсолютно всех требований Технического задания, и эта проверка реально проводилась, включая даже проверку времени восстановления системы из резервных копий после «поломки» сервера.
Чтобы избежать сюрпризов на различных этапах проекта, а не только на этапе приемки, в случае, если для данного исполнителя это первый проект с данным заказчиком, настоятельно рекомендуется на старте проекта выяснять у заказчика все нормативные и регламентные документы, в соответствии с которыми проводится разработка и внедрение автоматизированных систем, а также договорная работа, согласование изменений, порядок оплаты и многое другое. Вы можете узнать для себя много нового и неожиданного, даже если вам кажется, что вы уже всё на свете видели.
Совет 2
«Помните о том, что в каждой избушке свои погремушки. Задайте заказчику вопрос «а как у вас происходит…?». Вы можете узнать что-то очень важное для планирования своих работ и оценки их трудоемкости».
За время пути собачка могла подрасти
Зарисовка из жизни
Проект находится на стадии завершения разработки Технического задания, проходит рабочее согласование. Исполнителю поступает замечание к разделу «Требования к документированию». В состав разрабатываемых документов требуют включить дополнительно еще пять различных документов, к тем «стандартным», которые исполнитель включил сам с учетом своего опыта. А в раздел «Требования по подготовке к вводу в эксплуатацию» вдруг просят включить подготовку обучающей презентации для пользователей.
Сколько копий сломано на теме «плывущего» объема работ. Исполнители обвиняют заказчиков в растущих аппетитах, заказчики обвиняют исполнителей в том, что они не уточнили требования… Можно ли найти тут правду, кто же виноват и что делать?
Причины роста объема требований, как показывает практика, действительно можно условно разделить на две группы:
- новые требования заказчика или существенные изменения ранее выставленных требований.
- упущенные исполнителем работы или неправильно понятые, а значит и неправильно оцененные, требования;
По субъективным ощущениям обе эти причины встречаются приблизительно с равной частотой.
Инструменты и методы работы с изменяющимися требованиями или появлением новых давно известны и описаны. Это запрос на изменение и при необходимости оценка трудоемкости/стоимости. В дальнейшем данные изменения, при наличии такой возможности, контрактуются, заключаются Дополнительные соглашения, либо, в случае невозможности увеличения стоимости проекта, ведутся переговоры с заказчиком об исключении других менее важных требований, для включения новых. Также для снижения рисков изменяющегося содержания (scope) проекта рекомендуется применять гибкие методологии, если это возможно с данным конкретным заказчиком на данном проекте.
Более тяжелым случаем для руководителя проекта исполнителя является ситуация неправильно понятых, недооцененных требований или выявление упущенных ранее работ. В такой ситуации доказать заказчику, что это новое требование, практически никогда не удается и даже попытка доказать это может привести к конфликту.
Как избежать данной ошибки или нивелировать ее последствия для исполнителя?
Один из самых очевидных методов – как можно раньше и как можно подробнее уточнять все требования заказчика. В первую очередь – это качество работы аналитика исполнителя. Это его основная задача.
Еще один способ раннего уточнения требований – прототипирование или макетирование. Простой «кликабельный» макет экранных форм зачастую творит чудеса и помогает выявить пропущенные нюансы требований и ожиданий пользователей.
Третий способ – это закладывание на стороне исполнителя временного резерва и управленческого резерва в бюджет проекта. Заложить резерв по времени на выполнение проекта – это то, что должен делать каждый руководитель проекта. При этом возможность сформировать резерв бюджета практикует не каждая компания и данный подход к управлению рисками проекта возможен далеко не всегда.
Еще один способ предотвращения возникновения проблем с упущенными работами – это ведение внутри компании исполнителя реестра таких работ.
Например, очень часто исполнители упускают следующие работы:
- подготовка и настройка среды тестирования на стороне заказчика, или подготовка инструкции для администраторов по настройке среды тестирования;
- настройка ролевого доступа до начала пользовательского тестирования у заказчика; многие недооценивают суровость служб информационной безопасности заказчика;
- проведение обучения пользователей или подготовка обучающих материалов (презентаций, видео-уроков, электронного курса и т.д.);
- проведение подготовительных работ перед переводом системы в промышленную эксплуатацию: настройка и тестирование интеграции с боевыми, а не тестовыми контурами других систем заказчика; снятие различных «заглушек», которые использовались при тестировании и другие работы.
Сбор такой информации и ведение базы знаний по ним в компании-исполнителе – существенно облегчает жизнь руководителей проектов и позволяет более качественно планировать состав работ на каждом проекте. Если в вашей компании такая база знаний не ведется, возьмите инициативу в свои руки – ведите свой реестр, поделитесь с коллегами, попросите поделиться их.
Совет 3
«Чтобы контролировать содержание проекта применяйте методы раннего прототипирования, уточнения требований, ведите реестр типовых работ на проектах внедрения для каждого конкретного заказчика».
Ожидания
Зарисовка из жизни
Очередная статус-встреча с исполнителем. Руководитель проекта исполнителя докладывает о результатах за истекший период и о планах на следующий период. Выясняется, что работа, срок завершения которой прошел 2 дня назад до сих пор не выполнена и будет закончена только через 2 дня. Заказчик возмущен. Возмущен не тем, что работа до сих пор не завершена, а тем, что он об этом узнает только спустя 2 дня от обещанного ранее срока.
Под управлением ожиданиями заказчика чаще всего понимают управление ожиданиями от результатов проекта, его продукта.
И крайне редко в понятие управления ожиданиями включают ожидания заказчика по процессам выполнения проекта.
Ситуация, описанная в зарисовке из жизни встречается настолько часто, что создается впечатление, что руководители проектов разучились управлять этим типом ожиданий или не считают это нужным.
К чему приводит такая ситуация? К возрастающему недоверию заказчика к команде исполнителя и непосредственно руководителю проекта исполнителя, к впечатлению, что руководитель проекта исполнителя не управляет проектом и командой, не знает, что у него происходит и в целом не профессионален. Мне известны случаи, когда в такой ситуации заказчик требовал сменить руководителя проекта исполнителя. Один случай привел к разрыву контракта и смене компании-исполнителя.
Как избежать подобных ситуаций? Рецепт максимально простой: держите слово. Если срок сорван по объективной причине, и вы выявляете этот факт до наступления этого срока – а чаще всего именно так и бывает – предупредите заказчика заранее. Сообщите причины сдвига сроков и новый срок. Но этот новый срок нужно выдержать всегда.
Ниже я перечислила ситуации, которые вызывают раздражение и последующее недоверие заказчика и которых следует избегать.
- Позднее сообщение об изменении срока выполнения задачи, особенно после наступления данного срока.
- Отсутствие отслеживания выполнения поручений, полученных во время различных рабочих встреч и статус-митингов.
- Неоднократный перенос сроков выполнения одной и той же задачи по причине недооценки трудоемкости. Неправильно оценили один раз – верим. Три раза – уже считаем некомпетентностью.
- «Скрылся в тумане». Исполнитель получил задачи и исчез на месяц их выполнять.
Совет 4
«Не скрывайтесь в тумане. Будьте максимально открытыми и держите постоянный контакт с заказчиком. Управляйте его ожиданиям от процессов управления, а не только от результатов».
И в заключение хочу пожелать всем учиться на ошибках других, делиться собственными выученными уроками с коллегами и не забывать, что главная наша задача — customer satisfaction.
Татьяна Белова
Просмотры: 8 252
Каждый руководитель проекта иногда делает ошибки. Одни ошибки приводят к тяжелым последствиям для проекта или для одной из заинтересованных сторон, другие ошибки проходят незаметно или легко нивелируются. Проработав более десяти лет в роли руководителя проекта по обе стороны контракта, я в данной статье хочу поделиться личными наблюдениями о часто встречающихся ошибках руководителя проекта со стороны исполнителя в проектах автоматизации процессов и внедрения автоматизированных систем.
Каждый руководитель проекта иногда делает ошибки. Одни ошибки приводят к тяжелым последствиям для проекта или для одной из заинтересованных сторон, другие ошибки проходят незаметно или легко нивелируются. Проработав более десяти лет в роли руководителя проекта по обе стороны контракта, я в данной статье хочу поделиться личными наблюдениями о часто встречающихся ошибках руководителя проекта со стороны исполнителя в проектах автоматизации процессов и внедрения автоматизированных систем.
Эпиграф
Умный учится на чужих ошибках, а дурак на своих…. (автор неизвестен)
- «Это не наше»
Зарисовка из жизни.
Начало проекта. Команды заказчика и исполнителя обсуждают взаимодействие, состав работ, примерный план работ, уточняют рамки проекта. Руководитель проекта заказчика просит исполнителя разработать календарный план-график работ с учетом тех работ, которые должен выполнить и сам заказчик. Заказчик готов активно помогать в составлении данного план-графика в части работ со своей стороны, но работы исполнителя он естественно спланировать не может. Руководитель проекта от исполнителя сообщает, что «проект – это только то, что мы должны сделать, а остальное мне не интересно».
В чем ошибка данной позиции и к каким последствиям это может привести? Большинство проектов внедрения автоматизированных систем требует не только разработки программного обеспечения, но и выполнения других задач:
- закупки оборудования для развертывания системы;
- возможных организационных изменений в подразделениях;
- проведения обучения пользователей;
- разработки внутренней нормативно-методической документации;
- и др.
Все эти задачи входят в рамки проекта. И без их выполнения проект не может считаться завершенным успешно. Даже если подрядчик разработал программное обеспечение, проект на этом не закончился. И, чаще всего, программное обеспечение не будет принято в эксплуатацию пока не будет развернуто оборудование и проведено обучение пользователей.
Поэтому руководителю проекта от исполнителя настоятельно рекомендуется принимать во внимание общий план-график проекта и обязательно привязывать свои работы к ключевым вехам общего плана. Это поможет правильно составить договор (план-график работ по договору) и избежать в дальнейшем проблем со сдачей-приемкой выполненных работ. Например, для начала работ по интеграционному тестированию необходимо, чтобы оборудование было уже развернуто и настроено, а системы, с которыми требуется интегрироваться, были доработаны в соответствии с планом.
Итак, совет 1. «Проект – это не то, что делаете только вы. Проект – это все, что включено в содержание (scope) заказчиком. Принимайте во внимание те работы смежников и сроки их завершения, которые влияют на возможность выполнения ваших работ, особенно на их приемку»
- «В каждой избушке свои погремушки»
Зарисовка из жизни.
Подходит время проведения приемки системы. Проводится встреча, для обсуждения подробностей проведения данного мероприятия. Исполнителю рассказывают о том, что собирается комиссия, проводится проверка всех функций системы в соответствии с методикой испытаний и тестовыми сценариями, а также проверяется всё, что касается информационной безопасности, восстановления системы после сбоя и другие нефункциональные требования, которые ранее выдвигались. Для исполнителя явилось сюрпризом то, что он участвует в испытаниях в активной роли – именно его задача последовательно демонстрировать все шаги, ронять систему и восстанавливать и т.д. А также сюрпризом явилось то, что данное мероприятие может занять 2-3 полных дня (они себе в план столько не закладывали).
В чем ошибка руководителя проекта исполнителя и что нужно сделать, чтобы ее избежать?
Думаю, всем известна поговорка «В каждой избушке свои погремушки». В каждой организации свои принятые правила и регламенты приемки систем в эксплуатацию. Мне встречались очень простые и формальные испытания, когда проходят по основному функционалу и подписывают Акт о вводе в опытную эксплуатацию, а затем получают большое количество ошибок и недовольных пользователей на опытной эксплуатации. Мне встречались испытания, которые проводились полностью в соответствии с ГОСТ34, Программа и методика испытаний содержали проверку абсолютно всех требований Технического задания, и эта проверка реально проводилась, включая даже проверку времени восстановления системы из резервных копий после «поломки» сервера.
Чтобы избежать сюрпризов на различных этапах проекта, а не только на этапе приемки, в случае, если для данного исполнителя это первый проект с данным заказчиком, настоятельно рекомендуется на старте проекта выяснять у заказчика все нормативные и регламентные документы, в соответствии с которыми проводится разработка и внедрение автоматизированных систем, а также договорная работа, согласование изменений, порядок оплаты и многое другое. Вы можете узнать для себя много нового и неожиданного, даже если вам кажется, что вы уже всё на свете видели.
Итак, совет 2. «Помните о том, что в каждой избушке свои погремушки. Задайте заказчику вопрос «а как у вас происходит…?». Вы можете узнать что-то очень важное для планирования своих работ и оценки их трудоемкости».
- «За время пути собачка могла подрасти»
Зарисовка из жизни
Проект находится на стадии завершения разработки Технического задания, проходит рабочее согласование. Исполнителю поступает замечание к разделу «Требования к документированию». В состав разрабатываемых документов требуют включить дополнительно еще пять различных документов, к тем «стандартным», которые исполнитель включил сам с учетом своего опыта. А в раздел «Требования по подготовке к вводу в эксплуатацию» вдруг просят включить подготовку обучающей презентации для пользователей.
Сколько копий сломано на теме «плывущего» объема работ. Исполнители обвиняют заказчиков в растущих аппетитах, заказчики обвиняют исполнителей в том, что они не уточнили требования… Можно ли найти тут правду, кто же виноват и что делать?
Причины роста объема требований, как показывает практика, действительно можно условно разделить на две группы:
- новые требования заказчика или существенные изменения ранее выставленных требований.
- упущенные исполнителем работы или неправильно понятые, а значит и неправильно оцененные, требования;
По субъективным ощущениям обе эти причины встречаются приблизительно с равной частотой.
Инструменты и методы работы с изменяющимися требованиями или появлением новых давно известны и описаны. Это запрос на изменение и при необходимости оценка трудоемкости/стоимости. В дальнейшем данные изменения, при наличии такой возможности, контрактуются, заключаются Дополнительные соглашения, либо, в случае невозможности увеличения стоимости проекта, ведутся переговоры с заказчиком об исключении других менее важных требований, для включения новых. Также для снижения рисков изменяющегося содержания (scope) проекта рекомендуется применять гибкие методологии, если это возможно с данным конкретным заказчиком на данном проекте.
Более тяжелым случаем для руководителя проекта исполнителя является ситуация неправильно понятых, недооцененных требований или выявление упущенных ранее работ. В такой ситуации доказать заказчику, что это новое требование, практически никогда не удается и даже попытка доказать это может привести к конфликту.
Как избежать данной ошибки или нивелировать ее последствия для исполнителя?
Один из самых очевидных методов – как можно раньше и как можно подробнее уточнять все требования заказчика. В первую очередь – это качество работы аналитика исполнителя. Это его основная задача.
Еще один способ раннего уточнения требований – прототипирование или макетирование. Простой «кликабельный» макет экранных форм зачастую творит чудеса и помогает выявить пропущенные нюансы требований и ожиданий пользователей.
Третий способ – это закладывание на стороне исполнителя временного резерва и управленческого резерва в бюджет проекта. Заложить резерв по времени на выполнение проекта – это то, что должен делать каждый руководитель проекта. При этом возможность сформировать резерв бюджета практикует не каждая компания и данный подход к управлению рисками проекта возможен далеко не всегда.
Еще один способ предотвращения возникновения проблем с упущенными работами – это ведение внутри компании исполнителя реестра таких работ.
Например, очень часто исполнители упускают следующие работы:
- подготовка и настройка среды тестирования на стороне заказчика, или подготовка инструкции для администраторов по настройке среды тестирования;
- настройка ролевого доступа до начала пользовательского тестирования у заказчика; многие недооценивают суровость служб информационной безопасности заказчика;
- проведение обучения пользователей или подготовка обучающих материалов (презентаций, видео-уроков, электронного курса и т.д.);
- проведение подготовительных работ перед переводом системы в промышленную эксплуатацию: настройка и тестирование интеграции с боевыми, а не тестовыми контурами других систем заказчика; снятие различных «заглушек», которые использовались при тестировании и другие работы.
Сбор такой информации и ведение базы знаний по ним в компании-исполнителе – существенно облегчает жизнь руководителей проектов и позволяет более качественно планировать состав работ на каждом проекте. Если в вашей компании такая база знаний не ведется, возьмите инициативу в свои руки – ведите свой реестр, поделитесь с коллегами, попросите поделиться их.
Итак, совет 3. «Чтобы контролировать содержание проекта применяйте методы раннего прототипирования, уточнения требований, ведите реестр типовых работ на проектах внедрения для каждого конкретного заказчика».
- «Ожидания»
Зарисовка из жизни
Очередная статус-встреча с исполнителем. Руководитель проекта исполнителя докладывает о результатах за истекший период и о планах на следующий период. Выясняется, что работа, срок завершения которой прошел 2 дня назад до сих пор не выполнена и будет закончена только через 2 дня. Заказчик возмущен. Возмущен не тем, что работа до сих пор не завершена, а тем, что он об этом узнает только спустя 2 дня от обещанного ранее срока.
Под управлением ожиданиями заказчика чаще всего понимают управление ожиданиями от результатов проекта, его продукта.
И крайне редко в понятие управления ожиданиями включают ожидания заказчика по процессам выполнения проекта.
Ситуация, описанная в зарисовке из жизни встречается настолько часто, что создается впечатление, что руководители проектов разучились управлять этим типом ожиданий или не считают это нужным.
К чему приводит такая ситуация? К возрастающему недоверию заказчика к команде исполнителя и непосредственно руководителю проекта исполнителя, к впечатлению, что руководитель проекта исполнителя не управляет проектом и командой, не знает, что у него происходит и в целом не профессионален. Мне известны случаи, когда в такой ситуации заказчик требовал сменить руководителя проекта исполнителя. Один случай привел к разрыву контракта и смене компании-исполнителя.
Как избежать подобных ситуаций? Рецепт максимально простой: держите слово. Если срок сорван по объективной причине, и вы выявляете этот факт до наступления этого срока – а чаще всего именно так и бывает – предупредите заказчика заранее. Сообщите причины сдвига сроков и новый срок. Но этот новый срок нужно выдержать всегда.
Ниже я перечислила ситуации, которые вызывают раздражение и последующее недоверие заказчика и которых следует избегать.
- Позднее сообщение об изменении срока выполнения задачи, особенно после наступления данного срока.
- Отсутствие отслеживания выполнения поручений, полученных во время различных рабочих встреч и статус-митингов.
- Неоднократный перенос сроков выполнения одной и той же задачи по причине недооценки трудоемкости. Неправильно оценили один раз – верим. Три раза – уже считаем некомпетентностью.
- «Скрылся в тумане». Исполнитель получил задачи и исчез на месяц их выполнять.
Итак, совет 4. «Не скрывайтесь в тумане. Будьте максимально открытыми и держите постоянный контакт с заказчиком. Управляйте его ожиданиям от процессов управления, а не только от результатов».
И в заключение хочу пожелать всем учиться на ошибках других, делиться собственными выученными уроками с коллегами и не забывать, что главная наша задача — customer satisfaction.
При ведении проекта, начинающие и матерые проджекты совершаю одни и те же ошибки. Чтобы не позабыть самому и помочь другим, я решил собрать самые распространенные ошибки… которые совершил сам и подсмотрел у коллег на рынке.
Общение только по почте или скайп.
В наш век высоких технологи, так удобно использовать почту… так здорово отправить моментальное сообщение с пачкой документов и графиков. Сама почта отличный инструмент, но большинство начинающих руководителей забывают про телефон и личные встречи. Если вопрос можно решить за 5 минут телефонного звонка, то лучше набрать номер и договориться, не стоит превращать почту в чат.
Использование только телефона и личных встреч.
Другая сторона медали – это звоники и встречи без фиксации результата. После каждой встречи или звонка, не лишним будет отправить команде или заказчику итоги разговора. С одной стороны это позволит задокументировать договоренности, а с другой – удостовериться, что все друг друга равноценно поняли.
Боязнь сказать «Нет».
Клиент платит деньги, ну как можно ему в чем-то отказывать? На самом деле и можно и нужно. Большая часть проектов превышает бюджет и сроки, только из-за того, что по ходу проекта реализуемый функционал вырос в несколько раз. Украшательства и доп.фичи всегда можно договориться отложить “на потом”, уже после реализации базовых задач.
Страх изменить срок реализации.
Не стоит тянуть до последнего, чтобы сообщить клиенту, о срывании сроков. Так же не стоит стараться сделать за две недели то, что команда оценила в два месяца работы только потому что клиенту “очень надо!”. Включаем голову, нельзя просто так взять и “ускориться”. И если клиент в течение месяца слышит, что все будет готово к 15 числу, то все должно быть готово к 15 числу… или если это не так, то стоит объяснить из-за чего сроки могут сдвинуться.
Говорят слишком много.
Работа руководителя проектов подразумевает частые коммуникации между свой командой и командой заказчика. Однако большую часть времени менеджер должен уметь слушать, заказчика, чтобы уметь определять его истинные потребности. А так же слушать команду, которая зачастую лучше менеджера знает, что нужно сделать.
Злоупотреблять человеко-часами.
Любой проект можно спрогнозировать в человеко-часах. Но нужно понимать, что важно не только количество, но и качество. Вряд ли команда будет эффективна, если вы добавите еще одни внеурочный рабочий час… Так же нужно понимать, что в сутках не 8 рабочих часов, а в лучшем случае шесть. Все мы люди, нам свойственно отвлекаться, общаться, есть, ходить в туалет, звонить родным… Это нужно учитывать при планировании загрузки команды.
Забывать про тестирование и обучение.
Даже при покупке техники в магазине, мы тестируем ее работу. Не стоит забивать все время команды на разработку. Любой функционал необходимо тестировать и настраивать. Время на тестирование – это не увеличение сроков реализации, это их сокращение, за счет возможности выявления и исправления ошибок на ранних этапах.
Если продукт сложный и им будут пользоваться другие люди, то стоит не забыть заложить время на обучение персонала.
Чернов Дмитрий© chernov.pro