Кажется, что гибкая разработка, в частности приёмы и советы каркаса Скрам, идёт вразрез реалиям мира аутсорсинга и fixed-price проектов. Это не так.
Мне часто говорят: «Ну да, конечно, это всё прекрасно работает у вас там в Европе в продуктовых компаниях. У нас же здесь — никак. Мы работаем в аутсорсинге». Это заблуждение.Вернее, аутсорсинг, конечно, можно использовать как оправдание своей некомпетентности. Но это ещё никому не помогало.
Fixed-price проекты, я считаю, это отличная возможность отточить своё мастерство менеджмента. Scrum, к слову, родился как раз в таких проектах. Если у вас в проекте не ограничены средства, зачем тогда вообще что-то менеджерить? Пусть течёт как течёт. Так что fixed-price и agile — они как раз очень даже мило уживаются, поддерживая друг друга. В противовес fixed-scope проектам, которых на самом деле не существует. Вернее, scope можно пытаться ограничивать... Но это идёт вразрез законам природы и всемирного тяготения к изменениям.
Я много бложуна темы близкие продуктовой разработке, проектному менеджменту и agile-мышлению в частности.
И несмотря на всё вышесказанное и ранее написанное, работа в аутсорсинге вызывает массу горячих споров, клеймя аджалистов оторванностью от реальности, упрощённой моделью мироздания и вообще чем только не.
И эта тема явно болезненная, судя по яркой реакции на мой недавний провокационный пост:
Так давайте же спокойно разберёмся, откуда идёт туман недопонимания, и разложим всё по полочкам. И начнём с начала — с того, с чего начинаются проекты — с составления контрактов.
Составление контракта — театр абсурда, в котором ничего от менеджмента
«Предсказания сложны, особенно, когда речь идёт о будущем» Нильс Бор, квантовый физик и игрок датской сборной по футболу
Попробую разъяснить мой подход работы с фиксированными проектами. Без лишних эмоций и холиваров (хоть это и не так свойственно мне, если вы знаете мой стиль). Что ж — пора взрослеть. Вот учусь.
И так. По порядку. Вы выиграли тендер (не приведи бог!), ну или — что чуть лучше — уговорили заказчика доверить вам разработку его бесценного (но ещё несуществующего) продукта за оговоренную сумму денег. Ну или же переписать старую систему на новые рельсы. Так что вместе с фиксацией суммы контракта (и вашей маржи), вы так или иначе оговариваете и сам фронт работ.
Это ок. Пока всё норм. Как вы это делаете — меня не сильно волнует:
Вы прикидываете объём проекта, расписывая спецификации больших фич... На это уходит, скажем, две недели. Для этой фазы ранее вы снимали с проектов людей. Но так как это оказалось «неэффективно», теперь у вас есть целый отдел аналитиков, которые очень «точно» оценивают объёмы проектов, которые никогда сами не делают (услышьте мой циничный смешок). Вы сравнили проект с имеющимися историческими данными по схожим проектам (очень, кстати, отличный метод, без цинизма). Поделили годовой проект на (под)проекты чуть поменьше (тоже очень разумный шаг, без иронии). Умножили на выстраданный опытом «менеджерский коэффициент» (ваше дело). Посыпали волшебным порошком (не зря этому учат в PMI = Project Magical Institute). И э-ге-гей — подписываете контракт!
«Банзай! Как-то выплывем!» — говорите вы себе.
«А-ага-га!» — лукавит вам эхо.
Я не углубляюсь в то, как вы делаете расчёты проекта. Это вне цели данной статьи (есть варианты ухода от подобного рода lose-lose контрактов, но эта статья не об этом). Я хочу здесь рассмотреть вариант «жёсткого аутсорсинга, как он есть, после факта составление нереального договора на цену и объём работ». Типа:
«Сделайте мне очень много работы за очень мало денег и времени» — говорит заказчик.
«ОК, сэр!» — крестимся мы, закладывая буфер меньший, чем у конкурентов, и всё-таки достаточный, чтобы как-то выплыть.
Все мы понимаем, что определение стоимости и объёма проекта до его начала — это самое нелогичное действие из всех, к которому нас вынуждает действительность проектной деятельности по схеме «fixed scope». Почему? Да потому что в этот момент времени мы знаем как раз меньше всего об этом проекте.
И неудивительно, что наши оценки и предсказания будут очень далеки от реальности, которая, к слову, ждёт нас уже за углом, с битой наготове. Ну да ладно. Предположим, у нас есть злополучный контракт.
#ШОТЕПЕРЬ?
Customer collaboration over contract negotiation
«Как задержать годовой проект на год? По одному дню в день» Кто-то из великих
Ха, а вот теперь начинается то, что я люблю и называю «реальнымменеджментом». Всё, что вы делали до этого — это жонглирование тупыми пластмассовыми ножами — трюк для тех, кто хочет поверить в сказки. Менеджмент ещё не начинался.
И он не про то «как нам сделать весь скоуп вовремя, внутри отведённого бюджета и с заложенной маржой» — это для любителей PMBoK. У всех школ должны быть свои поклонники. Представьте, как вам будет сложно конкурировать на рынке, когда все проекты успешны! Нет, нам с вами это не нужно. Так что пусть традиционные менеджеры действуют традиционно — тратят месяцы на оттачивание деталей договоров, занимаясь, так сказать «premature scope management». Рисуют цветные диаграмма Ганта и нити накала проектных страстей. Расписывают риски и делят ресурсы.
Мы же с вами погрузимся в реальное управление проектами и, причём, сразу.
Что же такое реальный менеджмент? Это значит каждый день делать лучшее из возможного, с учётом строгих рамок сроков, денег, людей и возможностей.
Заметьте, «лучшее из возможного каждый день», а не «всё и вовремя, но к концу проекта».
Мы с вами сразу — с самого первого дня проекта не верим в то, что можно сделать всё и вовремя. Это правильно! Это отрезвляет. Это вынуждает принимать трудные, но столь важные решения с первого дня проекта. Мировая статистика проектов тут с нами плечом к плечу: процент успешных IT проектов ниже, чем шансы выбраться из мирового кризиса — меньше трети проектов заканчиваются успешно. Причём больше половины выходят за начальный бюджет и сроки. Вы удивлены? Я нисколько. Вспомните, на какой день проекта мы составляет контракты?
Что же такое «делать лучшее из возможного»? Как минимум:
— то, что заложит фундамент доверия между клиентом и нами;
— самое важное для самых главных пользователей (key user journeys);
— самое рискованное с точки зрения технологий (fail fast, fail often);
— всё, без чего вообще нельзя выйти в продакшн (minimum viable product).
А что же со всем остальным, что прописано в опечатанном документе с требованиями по проекту? Советую забыть обо всём остальном. И не тратить на это ни секунды. Любая потраченная секунда на неважную работу, забирает секунду, которую вы могли бы потратить на важную. Кеп очевидность? Возможно.
Я, конечно, чуть преувеличиваю. Но мысль вы, надеюсь, поняли: если вы не сделаете самого важного, то никакие бантики и бубенчики вас уже не спасут. Нет, ну задурить клиента вы, возможно, и сможете — если на этом строится ваша бизнес-модель, то удачи. Я же всё-таки верю, что одной из ваших целей является сделать хороший продукт так, чтобы этот клиент вернулся к вам с бóльшим бюджетом, да ещё и привёл партнёров!
Как же понять «что важно и без чего нельзя»? Очень хороший вопрос. Скорее всего, без вовлечения заказчика и их пользователей — никак. Увы. Нет, вы-то, конечно, можете дуть щёки и утверждать, что фича «Z» должна быть уже в первом релизе продукта. Это хорошее предположение. Но если это окажется не так, в суде ваша былая уверенность не поможет.
Что же поможет в суде? Думаю, уже ничего. Важно до него не довести!
Но как?
— Устойчивые отношения с заказчиком — ваш козырь. Его ничем не побить.
— Формируйте доверие к вам путём постоянной демонстрации того, что вы каждый день делаете лучшее из возможного для продукта.
— При этом нельзя переоценить навык прозрачной визуализации прогресса и расходования бюджета (об этом будет следующая статья).
Никакой клиент не потащит вас в суд «выбивать из вас деньги и штрафы», если в течение проекта они видели, куда и как расходовались их средства. И при этом они получили продукт, который, может и без бантиков, но делает то, что нужно.
Это и есть тот самый «Agile mindset». Тут не с чем спорить. Бери и делай.
На «скра» начинается, на «м» кончается
Как же это делать?
Первое:научиться такивыпускать софт итеративно-инкрементально.
Когда заказчик видит работающий продукт, это существенно снижает давление в проекте, уменьшает внимание и придирки к «спецификациям». Ничего не налаживает лучших отношений между вендором и заказчиками, как «прокликивание сделанных на прошлой неделе фич». Это должно делаться регулярно. Так часто, как возможно. Но не реже раза в две недели. Do Scrum by the book.
Если вы, как вендор, не умеете выпускать рабочий продукт с регулярностью от нескольких дней до пары недель — вы занимаетесь не тем бизнесом. Вы дилетант и прохвост. Сорри, я обещал без холиваров, но тут уж никак по-другому не скажешь. Go back to school. Никакие контракты вас не спасут. Учитесь (это долго). Ну или же наймите трёх толковых программистов (не больше), каждого со стажем и знанием как минимум трёх различных платформ (вам нужны широкопрофильщики) и избавьтесь от всего остального «балласта». Некоторые программисты в десятки раз более продуктивны других (как следствие, другие в десятки раз менее продуктивны). Вдумайтесь в эти цифры. Поэтому на деле закладка никаких коэффициентов и буферов в бюджеты и сроки не помогает.
Вы или умеете выпускать продукты, или нет? Это навык, который нельзя переоценить, скрыть или выторговать. Это и есть философия Scrum.
Второе:регулярно показывая заказчику растущий продукт, вы незаметно вовлекаете его в вопросы приоритизации и управления продуктом. Но если же вы умеете выпускать продукт, не строя архитектур из песка, но растя продукт органично, — тогда перед вами открывается весь потенциал взаимодействия с заказчиком, о котором мы все так мечтаем.
Так, «Sprint Review» в Скраме — это крайне многомерная практика, недооцениваемая многими. Одним её измерением является возможность строить отношения с заказчиком. Ни раз и ни два. А постоянно.
К примеру, задавая заказчику вопрос сразу после демо текущего билда продукта: «Какую фичу нам сделать на следующей неделе X или Y?», вы вовлекаете заказчика больше, чем любой притянутый за уши контракт или менеджер продаж с навыками полтергейста. Это работает лучше любого корпоратива с хреновухой в качестве аперитива, экскурсий по вашему городу или похода в баню.
Приоритезируя, заказчик — уже на вашей стороне. Он видит продукт, работает с ним, начинает понимать невалидность ранних требований, генерирует новые (лучшие!) идеи. С этого момента — заказчик ваш, а вы его. Вы нужны друг другу. И контракт больше не разделяет вас. Он уходит на второй план. На первый план выходит продукт.
(Это всё, конечно, при условии, что вы имеете доступ к представителям заказчика, которые реально заинтересованы в продукте. Если нет — бегите прочь. Но лучше ищите на той стороне того, кто платит. Кто отвечает головой за возврат инвестиций. Там точно есть такой человек, и ему ой как не всё равно)
Но как же сам контракт? Оставьте его юристам. Ваша задача не довести дело до их вовлечения.
В следующей статье я расскажу о том, как просто и красиво визуализировать рост продукта и таяние бюджета в Excel. Таким образом, чтобы на регулярных ревью вы не только смотрели на продукт для его адаптации, но и поднимали смертельно важные вопросы пересмотра рамок проекта: скоупа, времени и бюджета.
И всё это внутри всё тех же fixed-price продуктов.