, , web design, , , , web , , , , , web site development, , , , -, web-

Статьи: веб дизайн и разработка сайтов / Менеджмент веб проектов, управление программистами / Правила Ашманова / II. Неправильный проект и его лечение
 

Как вылечить неудачный проект

http://www.ashmanov.com

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

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

Вот какие основные этапы с необходимостью возникают при лечении проекта:

Разбор полетов и инвентаризация

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

Признание наличия проблем

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

Признание ошибок и вины

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

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

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

Создание новой команды

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

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

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

Лечение больных самолюбий

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

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

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

Кто старое помянет...

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

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

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

Правило 19. После разбора полетов нужно списать все долги и запустить проект заново.

Перезапуск проекта

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