Алексей Кулаков - Бизнес-фэнтези и другие истории

Ну и, в общем, начали мы военные действия. Во всяком случае, к ТВД приехали, пару раз в белый свет из нашей залповой штуки дали, говорят, даже кого-то накрыло… А тут и генерал из центра приехал. Посмотрел на нашего уродца и спрашивает: «Парни, а скажите мне: а что тут делает ПЯТЬ техников при одной машине? Когда должен быть один техник на три машины?» Ну, мы стоим, мнемся — бригадир выходит и объясняет: «Так эта… это ж был танк. Оно ж ломается все время. Мы ж на нем едем и прямо по ходу его переделываем и чиним. Не сбавляя хода. Ну и получается, что одного человека мало». Генерал на это посмотрел, глаза у него какие-то странные стали, и он спрашивает: «А вам, парни, в голову не приходило, что ОТДЕЛЬНО танк, а отдельно установка „Град“, а еще отдельно амфибии на воздушной подушке — это эффективней и при этом быстрей и дешевле?» Мы объясняем ему, что так, мол, и так, товарищ генерал, это ж и была наша изначальная идея! Просто кто-то сказал, что надо две пушки.

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

Так вот, я это все к чему: эта картина маслом — про любой инновационный проект в неизвестной ранее предметной области. И вот что я на эту тему думаю.

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

P.S.

В качестве тоста — так выпьем же, товарищи, за быструю победу!

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

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

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

Советы простые, ни один из них — не панацея.

1. У ПРОЕКТА ДОЛЖНЫ БЫТЬ ИЗМЕРИМЫЕ ГРАНИЦЫ

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

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

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

2. В ХОДЕ ПРОЕКТА ВАШЕ ПРЕДСТАВЛЕНИЕ О ЦЕЛИ БУДЕТ МЕНЯТЬСЯ

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