Скоро наш журнал обновит свой дизайн
Close
Будь в курсе
Подпишитесь на рассылку, чтобы не пропускать новые выпуски журнала
лекция
Управление и результаты
Маршрут проекта и итерации
Зачем управлять проектами
Я не знаю, доводилось ли вам управлять проектами. Я думаю, доводилось. И думаю, что вы сталкивались с тем, что управление проектами — это боль. Потому что есть менеджер, управляющий проектами: назовём его управленцем. И есть у него всегда какой‑нибудь клиент: это может быть и внешний клиент, может быть внутренний заказчик‑начальник — кто угодно. И, обычно, у него есть помощники. Если это какой‑нибудь сайт, то это — программисты, дизайнеры, редакторы; если человек строит дом — строители. Ещё есть третьи компании: в программировании — это разработчики библиотек, издатели каких‑нибудь штук, субподрядчики и ещё кто‑то. И над этим всем может быть государство, какие‑то внешние силы, которые тоже могут прийти в любой момент и сказать, что что‑то пошло не так.

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

Всё зависит от вас
Но если вы посмотрите повнимательнее на эту картинку, кроме возможного ужаса, в котором вы тоже бывали, вы увидите, что человек, который управляет проектами, стоит в середине, и у него, единственного здесь, есть связь со всеми частями системы — у него есть все рычаги для этого. Это самое классное, это единственный человек здесь, который реально может сделать всё. То есть от него зависит, каким получится проект.
Когда вы управляете проектами, всё зависит от вас.

Проекты везде
Давайте обсудим, где мы сталкиваемся с проектами. Какие есть идеи? На работе, где ещё?

— Построить дом себе. Да всё, что угодно. Любое желание, которое ты хочешь исполнить — это проект.

— Так и есть. У меня тоже тут (в списке) есть дома.

А путешествие организовать, разве это не проект? Билеты купи, отель выбери, потом всех привези в нужное время, потом окажется, что в номере с потолка вода льётся и нужно номер менять, а в результате нужно получить хороший отдых. И это точно такой же проект. Если дальше вы будете думать, у вас будет миллион примеров, потому что, реально, проекты — везде. Даже в магазин вы собрались за хлебом — это тоже проект, потому что есть задача, можно план построить, можно обосраться в процессе и так далее.

Проекты везде.

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

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

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

Итак. Почему важно и полезно заниматься управлением проектами:

Когда вы управляете проектом, всё зависит от вас.

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

Гвозди в гусенице
Вот представьте, что проект — это гусеница. Если у вас есть один чекпоинт, вы начали, и у вас он один, то гусеница может растягиваться бесконечно. Время тянется. Даже если вы её с двух сторон прибили, у неё пузо может куда‑нибудь вылезти. Поэтому важно прибивать гусеницу гвоздями.

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

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

— А эти гвозди вы устанавливаете заранее?

— Заранее. Прямо в плане. По сути это могут быть недельные итерации, а если совсем короткая [задача], то каждый день, например. Благодаря гвоздям, благодаря прибитой гусенице, благодаря гвоздям‑чекпоинтам вы всё время держите проект под контролем и принимаете решения заранее, а не впритык.

«Не прибитая гусеница» растягивается бесконтрольно и бесконечно. Хорошая гусеница — прибитая гусеница.

Любой пример — обычно как бывает? С кем‑то договорился о чём‑нибудь… Это вообще стандартный менеджерский подход — пойти спросить, как дела. Обычно, чем моложе исполнитель, чем меньше вы его знаете, тем больше и чаще надо гвоздей забивать. Потому что вы договорились с ним на пятницу, то если в пятницу позвонить, он скажет: «Ой, точно!» или «Всё, да‑да‑да!», а сам ещё не брался. Поэтому у вас должны быть чекпоинты. Вы звоните и спрашиваете: «Как дела?». Если окажется, что в среду он ещё ничего не делал, у вас хотя бы два дня есть, а не полдня.


Принцип заряженного ружья
И вообще вот этот метод прибивания гусеницы — часть более глобального понятия «заряженного ружья». Знаете? У Ильи Синельникова было.

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

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

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

Видео «Отношения с клиентами: принципы „Ружьё всегда заряжено" и „Анду"»:
https://vimeo.com/41189708

Без Ганта
Давайте про Ганта поговорим. Вы знаете, что такое диаграмма Ганта? На всякий случай, напомню: диаграмма Ганта показывает, как работы связаны во времени.

Как вырыть яму? Сначала Вася должен принести лопату, потом копать, потом посадить дерево. И мы можем сказать, что если он нёс лопату один час, копал два часа и сажал дерево ещё час, то всего нам надо четыре часа. Бац! У нас план проекта есть. Выглядит эта штука обычно так:
Там есть всякие навороты прикольные, типа критический путь.

В чём проблема в диаграмме Ганта? Первая проблема с диаграммой Ганта в том, что, в принципе, сама по себе как инфографика, инфодизайн, она довольно стрёмная. Потому что в реальном проекте куча всего происходит, и когда ты начинаешь так её рисовать, она становится нереально большая. Есть даже цитата с сайта Эдварда Тафти — это американский известный информационный дизайнер — ему пишет чувак на форуме: «Вчера я получил план проекта, сделанный в Микрософт Проджекте, сейчас в нем 770 строк (18 страниц) и его трудно прочесть. Что посоветуете? Как отобразить?». И Тафти ему рассказывает, что как‑то людям же удавалось за 3000 лет без Ганта обходиться: и пирамиды строили, и всякие чудеса света. И даёт такой совет: «Без Ганта — лучше».

Но есть ещё и вторая плохая штука с Гантом. Допустим, у нас была диаграмма про Васю и яму. Что происходит, если вдруг Вася нёс лопату не час, а два часа? Получается, что он два часа нёс — значит, второй этап сдвигается, и третий ещё дальше. И не дай бог здесь [на втором этапе] что‑нибудь случилось. Представьте, что у вас 10 человек участвуют — и получается, что [диаграмма] постоянно разрушается, потому что эти отклонения, о которых я вам говорил, никуда не деваются.

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

Если вы внимательно посмотрите на эту диаграмму Ганта, вы поймёте, что это есть та самая прямая линия из «А в Б», но просто её разложили, декомпозировали на составные части поподробнее, увеличили, приблизили. Диаграмма Ганта не способна отобразить реальность, потому что в проекте всё время всё меняется. И главное — достичь пользы, а не выполнить все эти шаги. Совет, который я вам даю: диаграмму Ганта и всё похожее не использовать, потому что вы только потратите на это время.

См. также совет:
Без Ганта

Маршрут проекта и итерации
Чем заменить диаграмму Ганта? Маршрутом проекта и итерацией.

Начнём с итерации. Итерация — это способ инкапсулировать ад. Представьте, что у вас есть какой‑то проект. Вы начинаете его делать и там — всё [плохо]: всё сломалось, всё развалилось, ничего не успели, но у вас была какая‑то конкретная польза, и к концу вы пришли и выпустили версию такую‑то. Меньше фич оказалось, каких‑то страниц не хватает на сайте, в книге не три тома, а один и так далее. Но вы пришли, выпустили, и у вас есть чекпоинт, и всё, что тут [во время разработки] творилось дальше не переносится, то есть, если бы у вас проект был на год, то у вас здесь [на первом этапе, до первого чекпоинта] всё на месяц сдвинулось — и дальше ещё на три, и в результате проект увеличился. Но когда у вас есть итерации короткие, ад инкапсулирован, то есть, дальше первого чекпоинта он не распространяется. Потому что когда вы придёте [в первый чекпоинт], вы вторую итерацию перепланируете: не успели что‑то сделать — в следующей итерации доделываете то, что не успели. Или вообще, обычно бывает, что [на второй итерации появляется] что‑то совершенно новое. И в этой точке вы всегда получаете обратную связь и делаете новую итерацию и так далее, корректируете свои действия.

Итерации должны быть минимальными, но должны приносить реальную пользу, пусть небольшую.

Картинка хорошая из интернета про Minimal Viable Product — это термин из подхода «бережливый стартап» — «минимальный жизнеспособный продукт». Слева просто попилили какую‑то функциональность — это не итерация. Справа небольшой кусочек целого, этот кусочек — итерация.
Маршрут проекта

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

Поэтому всегда важно понимать, куда мы идем, где наша глобальная цель. И для этого хорошо подходит принцип: «Думаем глобально, действуем локально» из градостроительства. В английском есть выражение «baby steps in the right direction» — «маленькими шагами идём в нужном направлении».

В чём идея: когда вы планируете любой проект, всё что угодно, всегда нужно постараться подумать глобально: что значит идеальный сервис для выбора сувениров? Идеальный — это какой? Что в далёком будущем будет? И когда ты эту цель представляешь, получается, что ты понял, что́ же [в конечной точке маршрута], а потом ты выбираешь какие‑то небольшие шаги: надо сначала майки продавать, потом ещё какие‑то безделушки и так далее. Но когда ты будешь идти, ты будешь знать хотя бы, куда ты идёшь. Может, конечно, будут отклонения — как всегда, какой‑то зигзаг — но он хотя бы будет куда‑то нацелен.

Как это делает бюро: всегда придумывает всё. У нас в бюро есть такая стандартная процедура: когда клиент приходит, две недели [занимаемся пониманием задачи и планированием]: первую неделю мы понимаем задачу, вторую неделю — планируем. И во время этого процесса бюро все идеи собирает. Там могут быть реально фантастические какие‑то поиски, нереальные, которые сразу не выдают [результат], их можно 15 лет делать, но всегда мы всё собираем, записываем, чтобы знать, куда мы идём. А потом мы предлагаем отложить на более поздние версии кучу всякого.

— Это всё вы делаете внутри команды или с клиентом?

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

— Версии — это что такое?

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